Servicio de Nuevas Tecnologías Avenida de la Paz, 11 ......Servicio de Nuevas Tecnologías Avenida...

Servicio de Nuevas Tecnologías Avenida de la Paz, 11

26071 – Logroño (La Rioja)

Tfn: +034 941.27.70.00

Fax: +034 941.27.70.25

Pliego de Prescripciones Técnicas que han de regir el

contrato destinado a la Implantación de la Plataforma

Corporativa de Portales y Webs así como el desarrollo sobre

la misma de la Nueva Web Municipal y la Web de Turismo

del Ayuntamiento de Logroño

SOL21-2018/0309

PPT Implantación Plataforma Corporativa Portales y Webs - Web Corporativa y de Turismo 2 /48

Versión 8.0


Contenido

1. INTRODUCCIÓN ...................................................................................................... 6

2. OBJETO DEL CONTRATO ......................................................................................... 9

3. ELABORACIÓN DE LA GUÍA DE ESTILO ELECTRÓNICA (GEADL) .............................. 11

3.1 Principios ................................................................................................ 11 3.1.1 Universalidad, accesibilidad y usabilidad .................................................. 11 3.1.2 Diversidad de medios y público objetivo .................................................. 12 3.1.3 Homogeneidad y diversidad .................................................................. 13 3.1.4 Características; elementos y disposición .................................................. 13

3.2 Aprobación .............................................................................................. 14

4. SITIOS WEB. ....................................................................................................... 14

4.1 Gestor de Contenidos y licenciamiento. .......................................................... 14

4.2 Arquitectura de la solución .......................................................................... 15 4.2.1 Infraestructura técnica disponible en AdL................................................. 15 4.2.2 Estadísticas de Uso ............................................................................ 15 4.2.3 Requisitos tecnológicos de la solución. .................................................... 15 4.2.4 Componentes de la solución. ................................................................ 17

4.2.4.1 Gestor de contenidos (CMS) ................................................................ 17 4.2.4.2 La Base de Datos del CMS ................................................................... 24 4.2.4.3 El Buscador .................................................................................... 24 4.2.4.4 El Buscador orientado a desarrolladores ................................................. 26 4.2.4.5 Directorio de Identidades (LDAP) .......................................................... 27

4.3 Seguridad e identidad de sitios Web. .............................................................. 28

4.4 Accesibilidad de sitios Web. ......................................................................... 28 4.4.1 Validación, declaración e informe de accesibilidad ..................................... 28 4.4.2 Accesibilidad: Penalización especial ....................................................... 28 4.4.3 Navegación accesible e inclusiva ........................................................... 29 4.4.4 Accesibilidad de sitios Web. Enlaces rotos ................................................ 29

4.5 Sitio Web Corporativo. ............................................................................... 30 4.5.1 Estructura de contenidos existente ........................................................ 30 4.5.2 Migración de contenidos existentes ........................................................ 32

4.5.2.1 Guía útil. Guías y directorios ............................................................... 32 4.5.2.2 Catálogo de Servicios Municipales ......................................................... 33 4.5.2.3 Funcionalidades, propias y de servicio existentes ...................................... 33 4.5.2.4 Propuesta de Diseño, estructura y servicios ............................................. 34

4.5.2.4.1 Diseño. ................................................................................... 34 4.5.2.4.2 Estructura. ............................................................................... 35 4.5.2.4.3 Evolución temporal de contenidos. .................................................. 35 4.5.2.4.4 Servicios .................................................................................. 35 4.5.2.4.5 Formularios: Generación y recogida de Información. Opción firma y CVS. ... 36 4.5.2.4.6 Callejero ................................................................................. 37


4.6 Sitio Web Turismo. .................................................................................... 37 4.6.1 Contenidos existentes ........................................................................ 37 4.6.2 Migración de contenidos ...................................................................... 37 4.6.3 Creación del sitio web ........................................................................ 38 4.6.4 Redirección de contenidos ................................................................... 38 4.6.5 Agenda de Eventos. Planes .................................................................. 39

5. PLAN DE FORMACIÓN ........................................................................................... 39

6. PRODUCTOS A ENTREGAR .................................................................................... 40

6.1 Guía de Estilo Electrónico del AdL (GEAdL) ...................................................... 40

6.2 Arquitectura de sistemas involucrados ........................................................... 41

6.3 Maqueta Sitio Corporativo ........................................................................... 42

6.4 Maqueta Turismo de Logroño ....................................................................... 42

6.5 Buscador ................................................................................................. 42

6.6 Plan de formación ..................................................................................... 43

7. PLAZO DE EJECUCIÓN .......................................................................................... 43

8. PLANIFICACIÓN Y CONTROL DE LA EJECUCIÓN ........................................................ 43

8.1 Planificación ............................................................................................ 44

8.2 Control y seguimiento de ejecución .............................................................. 45

9. PRECIO DE LICITACIÓN ......................................................................................... 45

10. FINANCIACIÓN ................................................................................................... 45

11. FORMA DE PAGO ................................................................................................ 46

12. GARANTÍA ......................................................................................................... 46

13. CONSULTAS PLIEGO DE PRESCRIPCIONES TÉCNICAS ........................................... 46

14. PROPIEDAD INTELECTUAL, SEGURIDAD Y CONFIDENCIALIDAD ................................ 46

14.1 Propiedad intelectual ............................................................................... 46

14.2 Seguridad .............................................................................................. 47

14.3 Confidencialidad ..................................................................................... 47

15. PROTECCIÓN DE DATOS ...................................................................................... 48


1. Introducción

En septiembre de 2012 el Ayuntamiento de Logroño (en adelante AdL) ponía a

disposición de la ciudadanía la nueva web www.logroño.es, desarrollo que suponía una

evolución significativa de la web municipal anterior y el establecimiento de la misma

como nuevo portal corporativo que permitía entre otros aspectos:

Un mayor acercamiento del ciudadano a la Administración Electrónica.

La publicación directa por parte de los gestores municipales de los diferentes

contenidos.

Cumplimiento de los criterios de accesibilidad WCAG AA 1.0.

Una mayor participación social en los asuntos municipales.

Durante más de 6 años de funcionamiento, dicho portal ha evolucionado

permanentemente mediante la incorporación de múltiples desarrollos destinados a

mejorar tanto el número y calidad de los contenidos y servicios prestados así como la

experiencia de usuario, llegando a convertirse en una de las herramientas más utilizadas

por la ciudadanía. Pero, simultáneamente, este periodo de tiempo también ha puesto de

manifiesto la existencia de diversas deficiencias o problemáticas, tanto técnicas como

organizativas, que en muchos casos dificultan e incluso llegan a imposibilitar la

prestación de un servicio satisfactorio a una ciudadanía y usuarios cada vez más

formados y exigentes. Aspectos tales como la ausencia de un buscador optimizado, la

falta de dinamismo en la gestión y renovación de los contenidos de algunas de las

secciones, la excesiva complejidad en la estructura de los contenidos, el incremento en

el tiempo de la amplitud temática de los contenidos, la lentitud de carga de algunas

páginas, etc., son aspectos a los que el AdL necesita dar solución de forma urgente y

efectiva.

Asimismo, el asentamiento y normalización de nuevas formas de comunicación digital,

cimentadas en el uso de dispositivos diferentes a los tradicionales, así como la aparición

de nuevas herramientas tecnológicas que ofrecen oportunidades de servicio a los

ciudadanos basadas en el concepto de web 2.0 han llevado a que el modelo plasmado en

su momento en el portal municipal no resulte el más adecuado para materializar la

estrategia actual de presencia del AdL en Internet siendo necesaria la adecuación del

mismo a las necesidades actuales y futuras.

Por otro lado, resulta importante considerar que la presencia en Internet del AdL se

materializa a través de varios portales y websites diferentes, de entre los cuales y como

se ha mencionado, el principal es el portal corporativo concebido como un portal de

información, gestión, participación y comunicación. En realidad, se trata de un canal

más de atención a ciudadanos y usuarios, gestionado con medios propios y personal

municipal y fuertemente orientado a las necesidades del ciudadano. En él, los

contenidos se gestionan de forma descentralizada por parte de las áreas y/o unidades

responsables de cada sección, de tal forma que ellos (o en quien deleguen) son los

responsables de los contenidos vertidos en las mismas y por tanto los encargados de la


publicación, revisión, modificación y eliminación de los mismos (cuando procede) de

forma autónoma y directa utilizando para ello el gestor de contenidos (Content

Management System o CMS) de la familia de herramientas de IBM WebSphere Portal

versión 6.1.5.

Pero como se ha anticipado, el ecosistema web del AdL, está formado también por otras

webs, portales o sitios web diversos con diferente entidad y características (tecnología,

imagen, organización, indexación, gestor de contenidos, políticas de gestión, etc.) y

vinculados a distintos servicios o unidades municipales con una presencia significativa

y particular en Internet (Teatro Bretón, Biblioteca Rafael Azcona, Transportes

Municipales, Unidad de Juventud, etc.). Dichas webs han ido surgiendo, por lo general,

de forma independiente al Servicio de NNTT y al amparo de diferentes contratos de

prestaciones de servicios por lo que no existe ninguna relación ni entre ellas ni tampoco

con el portal corporativo, lo que ha derivado en la aparición de islas de contenidos

difícilmente integrables. Cada una de ellas resulta, en esencia, totalmente independiente

y, habitualmente, vinculada a las necesidades específicas del servicio o unidad

responsable. En estos casos, la gestión de los contenidos, herramientas y tecnologías

con las que se han desarrollado son dispares y se encuentran vinculadas a contratos de

prestación de servicios por parte de empresas externas a quienes, entre las obligaciones

establecidas en su contrato, se les ha incluido el diseño y creación inicial de la web, el

posterior mantenimiento, gestión y organización de los contenidos publicados en ella y,

en algunos casos, también el alojamiento y el soporte técnico. Si bien esta práctica ha

proporcionado a dichas unidades una gran autonomía y un mecanismo para la gestión de

la publicación en Internet de sus propios contenidos que puede resultar acorde a sus

necesidades y recursos, también ha hecho surgir una serie de problemas, entre los que se

encuentran:

Generación de islas de contenidos. A pesar de que los contenidos de cada uno de los

websites, son contenidos municipales, no existe forma de que el ciudadano pueda

acceder a ellos de forma única y sistematizada, debiendo realizar la misma búsqueda

en varias webs para tener garantía de una respuesta completa. Del mismo modo ocurre

en el caso del portal corporativo ya que tampoco puede accederse desde él a los

contenidos de ninguno de los otros al ser desarrollos independientes en tecnologías y

sistemas completamente diferentes y no integrados entre sí.

Apariencia no homogénea. Se presentan muy diferentes apariencias o estéticas para

cada web, sin lazo o nexo de unión entre ellas que las identifique como una parte más

de la web municipal, con la consiguiente confusión para la ciudadanía. Si bien el

objetivo no sería eliminar esa autonomía, sí que resulta imprescindible que todas ellas

compartan ciertos aspectos o características base en el diseño que permitan a los

usuarios establecer un nexo o enlace con el portal web municipal que las vincule con

el AdL y su ecosistema de webs.

Dependencia y servidumbres respecto del adjudicatario del servicio. En muchos

casos, no solo la tecnología de dichos websites, sino también la gestión y el

alojamiento de los mismos se materializa en sistemas propios de los diferentes

adjudicatarios. Este hecho, si bien libera a las unidades municipales de muchos de los

problemas de gestión y mantenimiento de una web, también causa una serie de

problemas que no deben ser desdeñados. Así, acaba surgiendo una enorme


dependencia entre el proveedor y la gestión de la correspondiente web, manifestada en

el momento de finalizar la prestación del servicio y sobre todo cuando además se

produce cambio de adjudicatario. Es entonces cuando se hace necesaria la

recuperación de todo el sistema por parte del AdL (infraestructura, contenidos,

desarrollos, etc.), y el traslado del mismo desde los sistemas del antiguo adjudicatario

a los sistemas municipales o a los del nuevo adjudicatario, tareas estas no exentas de

dificultades y costosas en dinero y tiempo, ya que suponen la participación y

coordinación de todas las partes.

Por último y no por ello menos importante existe otro aspecto que debe ser tenido en

cuenta y son los inconvenientes que presenta la infraestructura del actual portal

corporativo basada en el gestor de contenidos WebSphere Portal Server v6.1.5. Por un

lado, el carácter propietario de la herramienta y su elevado coste de licenciamiento

acaba restringiendo de forma drástica la concurrencia de licitadores a la hora de

formalizar contratos para el mantenimiento, ampliación o renovación de la web,

habiéndose constatado durante los últimos años que resulta muy difícil (y también

costoso económicamente) conseguir técnicos cualificados en dichas herramientas y, por

otro lado, la obsolescencia del actual gestor de contenidos WebSphere Portal Server

v6.1.5, derivada del conjunto de servidumbres impuestas por la compleja y azarosa

instalación inicial del sistema llevada a cabo en el año 2012 han desaconsejado la

actualización de versión del gestor de contenidos sobre el que se encuentra desarrollada

la web corporativa municipal, debido fundamentalmente a que, cualquier cambio a

versiones superiores del CMS, implicaba un nuevo proyecto y la práctica recodificación

del sistema debido a la incompatibilidad descendente de las versiones del producto. Esta

inmovilidad obligada, si bien en un momento resultó asumible, en la actualidad genera

una serie de problemas y necesidades que deben ser resueltas con rapidez, entre las que

se encuentran:

No disponibilidad de soporte. Como consecuencia de no haber sido evolucionada, la

vigente versión 6.1.5 del producto WebSphere Portal Server se encuentra

descontinuada en su soporte por parte del fabricante. Si a ello se une el carácter

propietario de la misma, se concluye que cualquier incidencia carece de soporte y

mantenimiento y, por tanto, acaba resultando muy costosa, en tiempo y dinero, así

como difícil de solucionar.

Dificultades añadidas en la mejora y evolución del sistema. Debido

fundamentalmente a la imposibilidad de disponer de un sistema actualizado con

parches y mejoras, muchos de los errores, necesidades y deficiencias detectadas no

pueden ser corregidas de forma normal, lo que obliga a plantear, en el mejor de los

casos, soluciones alternativas mucho más costosas y, en otros casos, a dejar pendiente

su resolución.

Sin solución para nuevos requerimientos. Al encontrarnos anclados en una versión

antigua del producto y sin posibilidades de actualización, muchas de las nuevas

necesidades que han venido surgiendo quedan sin solución puesto que la resolución de

las mismas está vinculada a la instalación de versiones más actuales tales como,

mejoras en el sistema de indexación de los contenidos, gestión de los contenidos sin


Java, disponibilidad de estadísticas de uso y valoración de los contenidos, desarrollo

de formularios, uso de URLS’s amigables, etc.

Si a todo lo expuesto con anterioridad se le suman otros requerimientos como, la cada vez mayor exigencia tanto interna (unidades y servicios) como externa (ciudadanos y empresas) en la publicación y gestión de contenidos, la creciente inclinación de la ciudadanía a la utilización y consumo de contenidos e información digital, la mayor diversidad y complejidad de los contenidos y formatos generados, la cada vez más importante imagen virtual de las organizaciones, las nuevas dinámicas de uso y gestión de los contenidos, la rápida evolución del entorno tecnológico, etc., se concluye que resulta necesario abordar el diseño e implantación de una nueva solución que permita mejorar la experiencia digital de los ciudadanos con su ciudad, al tiempo que se optimizan los recursos utilizados para ello.

Todo ello justifica el inicio por parte del Servicio de Nuevas Tecnologías del AdL de un proyecto destinado a realizar una renovación integral del ecosistema web municipal tanto desde el punto de vista tecnológico como de imagen y contenidos, que proporcione solución satisfactoria a las deficiencias mencionadas con anterioridad y que permita la consolidación de la web municipal como un medio eficaz de intercomunicación entre el AdL, ciudadanos y usuarios.

2. Objeto del contrato

El objetivo del presente contrato es la implantación y puesta en marcha de una

infraestructura común (Plataforma de portales y webs para el AdL) que permita la

gestión centralizada y coordinada tanto de la Web Corporativa como de las diferentes

webs municipales, estableciendo un entorno base único, homogéneo y robusto para la

publicación de contenidos en el que se integre todo el ecosistema de portales que el AdL

ofrece al ciudadano. Dicho objetivo, se concreta en los siguientes aspectos particulares:

1. Creación de la Guía de Estilo Electrónica del AdL (GEAdL): Será también objeto

del contrato la elaboración de una guía de estilo, imagen corporativa web y

comportamiento de los contenidos expuestos en cualquiera de sus medios de

representación (escritorio, dispositivos móviles, etc.) por parte del AdL. Dicha guía

deberá establecer el conjunto de recursos de imagen, (gráficos, tonos, colores,

tipografías, distribución, organización, etc.) y las normativas y patrones básicos

relacionados con la navegación, el diseño, la accesibilidad, independencia de

dispositivo, arquitectura de la información, etc., en dicho entorno tecnológico,

conformándose en la nueva imagen corporativa web del AdL. Es por ello que deberá

promover una cuidada imagen de la ciudad de Logroño a través de los distintos

servicios de información en Internet, modernizar el estilo y la imagen de todos de cada

uno de los diferentes subsitios municipales, proporcionando e integrando variantes

reguladas que permitan, por un lado, dotar a cada uno de ellos de una imagen

específica y particular asociada a la naturaleza y necesidades del mismo (por ejemplo

web municipal de Turismo) y, por otro, proporcionar un nexo o hilo conductor que

permita a los ciudadanos asociar con claridad que cada una de dichas web o portales

satélites pertenece y está relacionado con la propia web corporativa aunque su

visualización y presentación sea diferente. Asimismo, la GEAdL, deberá incorporar en

su planteamiento las consideraciones, aspectos o atributos necesarios para conseguir

una accesibilidad inclusiva que permita la navegación no diferenciada por los sitios


web municipales de todos los colectivos, con o sin discapacidad. Para todo ello, el

adjudicatario dispondrá del estudio de imagen corporativa del AdL existente, que

deberá ser tenido en cuenta a la hora de elaborar el GEAdL extrayéndose los

elementos del mismo cuya incorporación resulte de interés en el nuevo diseño tales

como logotipos, colores oficiales, tipos de letra, etc.

2. Implantación Plataforma de Portales y Webs: La solución ofertada deberá

suministrar todos los productos, soluciones y desarrollos que permitan el

establecimiento de un marco completo, una estructura base homogénea y robusta

donde establecer un ecosistema de portales integrados que permita albergar la

información y los servicios municipales ofrecidos al ciudadano. La solución ofertada

lo será sobre Liferay Portal 7.0 o versión posterior y estable, o producto equivalente.

3. Servicio Ininterrumpido, calidad de servicio. Arquitectura de sistemas. La

arquitectura de sistemas ofertada garantizara que la información esté disponible de

forma permanente y continua. Se implantara una configuración acorde de los sistemas

que soporten los servicios involucrados, así como de los protocolos de actuación ante

las tareas de mantenimiento y resto de incidencias de puedan influir en la prestación de

los servicios.

4. Creación del sitio web corporativo (www.logroño.es): El adjudicatario deberá

elaborar y poner en producción la web corporativa municipal que deberá ser

desplegada sobre la plataforma y arquitectura suministrada. Para tal fin el

adjudicatario tendrá en cuenta la estructura, contenidos y funcionalidades presentes en

el actual portal corporativo y planteará su diseño de forma acorde a lo establecido en

la GEAdL, llevando a cabo el diseño y desarrollo de una nueva web corporativa que

deberá ser: Accesible, con contenidos geolocalizados, adaptada a medios y

dispositivos, colaborativa y participativa con los ciudadanos, etc.. Asimismo, el

adjudicatario será responsable también de la migración y adaptación de los contenidos

y funcionalidades ya existentes a la nueva web.

5. Creación de sitio web de Turismo de Logroño (logronoturismo.es ó

turismo.logrono.es): En base a los contenidos de turismo actualmente existentes en el

AdL y de acuerdo a lo establecido en la GEAdL, el adjudicatario deberá desarrollar,

desplegar y poner en producción sobre la plataforma instalada, la nueva web de

turismo. Para ello, propondrá una estética y estructuración de contenidos de la misma

que deberá ser aprobada por el AdL antes de su implementación. Con todo ello se

pretende la creación de un nuevo sitio web que habrá de ser moderno, atractivo,

dinámico, con contenidos geolocalizados, ágil e interactivo con el ciudadano. El

adjudicatario será responsable de la migración, adaptación y adecuación de los

contenidos y funcionalidades de turismo ya existentes a la nueva web.

6. Búsqueda de contenidos global: El conjunto de webs municipales se encontrara

dividido en dos grupos, uno será el desarrollado sobre el CMS objeto de esta licitación

y el segundo grupo lo será el de aquellos sitios web ya existentes que no forman parte

de esta licitación. La plataforma proporcionará una indexación continua, completa e

incremental de los contenidos web alojados en la base de datos del Gestor de


Contenidos y adicionalmente permitirá el rastreo de URL’s de ámbito municipal que

estén en otros CMS para su posterior indexación y búsqueda, casos como

sedeelectronica.logrono.es, logronodeporte.es, teatrobreton.org,

transporteurbano.logro-o.org, etc.

7. Repositorio de credenciales o identidades: La nueva plataforma de portales y webs

municipales deberá permitir la integración con el servicio de directorio existente en las

instalaciones del AdL bajo el protocolo LDAP para la delegación de gestión de

contenidos del CMS propuesto. La autenticación de credenciales se posibilitara

mediante el acceso de usuario/contraseña y certificado electrónico, e inicialmente

servirá para la gestión centralizada de autoridades para cualquier zona de cualquiera de

los sitios web del ecosistema de portales y webs municipales.

8. Entornos de desarrollo y producción. Si bien el desarrollo objeto del contrato podrá

serlo en las instalaciones del licitador, las entregas programadas por hitos del proyecto

lo serán en las instalaciones del AdL, tanto en el entorno de desarrollo como en el

posterior de producción, pudiéndose acordar, en caso de ser preciso, un tercer entorno

de pre-producción. La creación y configuración de entornos serán parte necesaria de la

entrega de productos del contrato y será responsabilidad del adjudicatario.

9. Formación y Transferencia Tecnológica: Será responsabilidad del adjudicatario la

planificación y realización de un plan de formación dirigido al personal del Servicio

de NNTT del AdL orientado a la formación en el uso, manejo y gestión de las

herramientas utilizadas. Esta formación será desarrollada presencialmente en las

instalaciones municipales. Deberá realizarse de forma intercalada e imbricada

temporalmente en la ejecución del contrato antes de que, o tan pronto como, finalice el

hito o marca temporal del proyecto asociado a su uso, siendo previsible que se

necesiten varios periodos de formación.

3. Elaboración de la Guía de Estilo Electrónica (GEAdL)

Tal y como se ha comentado con anterioridad la Guía de Estilo Electrónica del AdL

(GEAdL) se asentará o partirá del estudio de imagen corporativa expuesto públicamente

en:

http://www.logroño.es/wps/portal/web/inicio/ayuntamiento/gabinetePrensa/imagenCorpora

tiva

Asimismo, seguirá los siguientes principios y características;

3.1 Principios

3.1.1 Universalidad, accesibilidad y usabilidad

El diseño cubrirá las características de visualización de los dispositivos móviles (teléfonos,

tabletas) con pantallas pequeñas y de baja resolución hasta monitores de mayor tamaño y

resolución, para adaptar la representación de los contenidos de forma limpia, amplia y

clara. El diseño será testeado en las versiones recientes de los dispositivos de referencia,

navegadores como Chrome, Firefox, IExplorer y Safari en sus versiones recientes, así

como los navegadores de referencia de dispositivos móviles, Android y IOS.

http://www.logroño.es/wps/portal/web/inicio/ayuntamiento/gabinetePrensa/imagenCorporativa

http://www.logroño.es/wps/portal/web/inicio/ayuntamiento/gabinetePrensa/imagenCorporativa


Sera requisito de obligado cumplimiento que la GEAdL sea diseñada para el cumplimiento

de la norma europea EN 301 549:218 y RD 1112/2018, (referenciadas a WCAG AA 2.1).

Detallará las normas a seguir en los elementos presentes en el diseño para tal

cumplimiento. Se debe considerar que la GEAdL especificará tanto la presentación de

datos como el diseño de captura de datos y formularios. Para una mayor claridad o ligereza

en la presentación de contenidos se podrá contemplar la aparición u ocultación de

contenidos mediante acción manual o temporizada, sliders o similares, siempre que el

movimiento de contenidos no implique incumplimientos de las recomendaciones WCAG,

en particular no se permitirá parpadeos o contrastes invertidos en la representación de

contenidos.

La GEAdL especificará los criterios necesarios para que la experiencia de usuario y

usabilidad de las webs diseñadas siguiendo sus directrices alcancen la máxima valoración

posible, grado de satisfacción, usabilidad, uniformidad y predicción de comportamiento. Al

igual que en el párrafo anterior se debe ser consciente de que la GEAdL regirá tanto la

mera representación de información como la interacción con el ciudadano en la captura de

información, donde la disposición de elementos, la información previa del formato de

campos, la predicción de textos o valores, la representación de errores de validación, las

ayudas en línea o globos informativos, etc., adquieren una importancia adicional para

lograr el mayor grado de usabilidad. Asimismo, la GEAdL detallará el esquema de

mensajes de error, la secuencia de controles o campos de formularios, determinará el orden

de validación y el resto de aspectos relacionados para conseguir un comportamiento

uniforme y predecible.

3.1.2 Diversidad de medios y público objetivo

La GEAdL especificará adicionalmente las características para la adaptación a la impresión

del contenido visualizado, especificará criterios específicos para la impresión de

contenidos (media print), detallando la disposición de elementos y la traslación del

contenido visualizado al medio, pudiendo implicar criterios de selección de contenido a

trasladar o imprimir. No todo el contenido visualizado ha de ser forzosamente trasladado a

la impresión, pudiendo determinar la GEAdL ciertos criterios de selección de contenidos a

imprimir.

Así mismo, detallará como alterar el contenido visualizado en relación a:

1. Texto. Aumento o disminución de tamaño del contenido. Determinará que partes

del contenido de verán afectados por la acción y como se adaptara al espacio de

visualización, pudiendo implicar la no visualización de contenidos previamente

visualizados.

2. Contraste. Visualización de contenido en modalidad de Alto Contraste.

3. Conexión Red. Elección manual de calidad de elementos gráficos a representar,

que permita la adaptación a conexiones de red de diferente calidad.

4. Redes Sociales. Publicación en redes sociales, determinando que se ha de publicar

o compartir, imagen, URL, título, etc.

5. Anónimo o Identificado. Visualización de sesión anónima o autenticada tras la

lectura y validación de credenciales, ya sea para acceder a servicios privados

abiertos al público o para acceder a la modalidad de gestión de contenidos.


6. Modo de Navegación. Indicará como alternar entre las diferentes representaciones

del mismo contenido, cuando estas existan. Cuando un contenido tenga

representación en lengua de signos o lectura fácil, además del contenido base, la

GEAdL indicará que modalidad de visualización esta activa y cuales están

disponibles para el contenido, y determinara como alternar entre la modalidad de

representación de forma puntual y permanente durante la navegación mediante

botón de alternancia o listbox que permita seleccionar el modo de navegación.

La GEAdL determinará la ubicación y diseño gráfico de elementos que permitan el acceso

a las funcionalidades anteriores, así como criterios de selección sobre en qué contenidos

deben aparecer esos elementos. Además deberá considerar el paradigma mobile first para

la especificación de las recomendaciones que serán implantadas posteriormente en los

portales municipales.

3.1.3 Homogeneidad y diversidad

La GEAdL guiara el diseño de todas las webs municipales, estableciendo criterios

homogéneos que identifiquen cualquier web como perteneciente al AdL. Pero también

permitirá una necesaria libertad de implementación que posibilite la opción de atender o

satisfacer la diversidad de público objetivo que reúne el conjunto de webs de las diferentes

unidades municipales.

Así por ejemplo, dentro del objetivo del presente contrato, la Web corporativa y la Web de

Turismo del AdL deberán seguir las especificaciones de la GEAdL, debiendo ser ambas

claramente identificables como titularidad del AdL, pero adaptadas a las necesidades del

público objetivo o los fines específicos de cada una de ellas.

3.1.4 Características; elementos y disposición

HTML5 y CSS3: La GEAdL será diseñada considerando las versiones recomendadas de

HTML y CSS salvo exposición argumentada del licitador, que será estudiada por el AdL.

La elección de versiones diferentes a HTML5 y CSS3 será evaluada pudiendo suponer la

eliminación de la propuesta en caso de que los argumentos explicitados por el licitador no

sean considerados suficientes para su elección.

La cabecera de todos los diseños de página deberá incluir elementos claramente

vinculados con el AdL que sirvan como identificación y deberán permitir el enlace con la

web municipal. Así mismo contendrá elementos destinados a identificar y seleccionar

grandes grupos de público objetivo tales como la selección de idioma, el acceso a redes

sociales, el acceso a herramientas o información sobre accesibilidad, la información de

contacto y acceso a buscador, etc.

Miga de Pan: Sera un elemento que estará presente en todos los diseños (layouts) de los

contenidos presentados, al considerarse un requisito de accesibilidad de los sitios web del

AdL. La portada o home de las webs podrán ser una excepción a esta norma, pudiendo

existir otras excepciones, siempre que existan argumentos que así lo justifiquen.

Disposición de elementos (layouts o diseños): La GEAdL contendrá inicialmente un

número finito de diseños o plantillas disponibles para la creación de sitios webs, así como

los criterios armonizados para la creación posterior de diseños adicionales si es que fuera

preciso. No obstante la GEAdL partirá de un conjunto suficiente de diseños que permitan,

al menos, la cobertura de las necesidades establecidas en el presente pliego con relación a


las webs corporativa y de turismo. Será preciso que la nueva GEAdL determine la

distribución de elementos acorde al medio de representación así como las dimensiones o

proporciones del espacio de representación que deben ocupar tanto los bloques de

información como los elementos que forman parte del bloque. Por ejemplo, deberá indicar

qué proporción o dimensión debe ocupar la cabecera y dentro de esta qué proporción debe

ocupar otros elementos tales como el escudo u otros diseños específicos. Esta información

puede quedar implícitamente especificada en los diferentes diseños propuestos.

El pie de página contendrá información sobre la propiedad de los contenidos, datos de

contacto (email o enlace formulario), política de privacidad, mapa web, entre otras

informaciones.

Tipos de letra o fuentes: La GEAdL propondrá los tamaños, cuerpos, interlineados y

espaciados para los distintos elementos de contenido en las distintas versiones,

describiendo con detalle la tipografía utilizada y las normas de uso o combinación a tener

en cuenta en el desarrollo de contenidos. Determinará los valores del rango, tamaño

mínimo y máximo del fuente a ser representado dependiendo de la jerarquía del texto

dentro del documento, que puede ser modificado para adaptar a las necesidades o

experiencia de usuario mediante selección manual del incremento o disminución del

tamaño de letra. Así mismo deberán suministrarse los diferentes archivos de tipo de letra

necesarios para poder utilizarlos en la creación de contenidos.

Colores: Parte fundamental de la imagen y diseño e incluso de la identificación

corporativa. Se propondrán paletas de colores para las webs objeto de esta licitación, así

como normas para complementar secciones con paletas o subpaletas de colores o para la

creación de futuros sitios web.

Marcado HTML. La GEAdL especificara normas a seguir para el marcado de etiquetas o

elementos HTML, tanto visibles como no visibles. Por tanto especificará normas para

representar enlaces externos al sitio web, enlaces internos, especificaciones a detallar en el

contenido alternativo de imágenes ALT, etc., características necesarias para el

cumplimiento de las recomendaciones de accesibilidad.

3.2 Aprobación

La GEAdL contendrá lo anteriormente enumerado así como el material gráfico que sea

requerido inicialmente para las webs objeto de la licitación. Previamente a su utilización en

el diseño de las diferentes webs objeto del presente contrato, la GEAdL deberá ser

aprobada por el AdL.

4. Sitios Web.

4.1 Gestor de Contenidos y licenciamiento.

En el año 2016 el AdL llevó a cabo una consultoría para la estandarización de la

plataforma de desarrollo municipal de la que, entre otros aspectos, se determinó que el

gestor de contenidos más adecuado a las necesidades municipales era la herramienta

Liferay Portal. Teniendo en cuenta dicha premisa, todos los desarrollos y arquitectura que

los licitadores oferten, lo serán sobre el producto Liferay v7.0 o posterior, edición


Community Edition (CE), o equivalentes, sin implicar costes de licenciamiento,

entendiéndose que la misma permite la cobertura de todos los requisitos de arquitectura y

funcionalidad detallados en este PPT.

No obstante lo anterior, deberá preverse en el presente proyecto que es posible que el AdL

deba realizar el licenciamiento de dicha herramienta a versiones Digital Experience

Platform (DXP) en futuras actuaciones, por lo que deberá evitarse cualquier desarrollo o

acción que implique una dependencia de la versión de la herramienta que pueda impedir o

dificultar la evolución del tipo de licenciamiento en el futuro, debiendo ser esta, cuando se

lleve a cabo, rápida, sencilla y que no implique costes adicionales más allí de los propios

del cambio de licenciamiento.

4.2 Arquitectura de la solución

4.2.1 Infraestructura técnica disponible en AdL

El AdL dispone de los siguientes recursos tecnológicos que deberán ser utilizados por la

adjudicataria para la implantación de la arquitectura técnica propuesta:

Entorno de virtualización VMWARE VSphere 5.5 Update 3 con suficiente capacidad de memoria, almacenamiento y procesamiento para el objeto del presente pliego.

Entorno para backup y contingencia se utiliza el sistema Netbackup Appliances de la empresa Veritas.

Seguridad y estructura de red, dispone de varias zonas de red según los criterios de acceso exigidos.

Cualquier otro recurso necesario para la implantación de la propuesta, sea esta hardware o

software deberá ser suministrado por la adjudicataria.

4.2.2 Estadísticas de Uso

Con el objetivo de ayudar al licitador a diseñar y configurar una arquitectura y a

dimensionar los sistemas involucrados en la solución que proponga de tal forma que se

adapten al volumen de uso de la web actual del AdL, se aporta el siguiente cuadro de

utilización del sitio www.logroño.es. Debe tenerse en cuenta que, en cualquier caso, ha de

tenerse en cuenta a la hora de dimensionar la arquitectura, la posible evolución en la

demanda del servicio que se produzca en el futuro.

Períod

o

Nº páginas Sesiones Períod

o

Nº páginas Sesiones

2017 2.256.177 990.481 2017.12 156.333 65.659

2016 1.251.671 445.473 2017.11 188.586 85.834

2015 1.110.665 379.686 2017.10 194.839 90.611

2014 941.204 268.510 2017.09 193.211 95.066

2013 653.903 170.760 2017.08 178.305 82.787

2012 106.956 24.898 2017.07 170.490 80.018

2017.06 188.855 89.825

2017.05 250.016 112.611

2017.04 213.884 93.681

2017.03 274.231 112.214

4.2.3 Requisitos tecnológicos de la solución.

Las ofertas deberán describir las características tecnológicas de la solución propuesta,

teniendo en cuenta los siguientes requisitos y condicionantes:

http://www.logroño.es/


1. Instalación. La empresa adjudicataria será la responsable de la instalación de la

solución en los entornos establecidos que al menos comprenderán un entorno de

Desarrollo (interno) y otro de Producción de exposición pública, dentro de las

instalaciones de CPD municipal que se encuentran basadas actualmente en Linux

CentOS 7. Los entornos deberán ser homólogos para simplificar su mantenimiento.

2. Configuración. La configuración, comunicación e integración de servidores, gestor

de contenidos, bases de datos, indexación y búsqueda, gestión de directorios de

identidades (LDAP) serán así mismo responsabilidad de la empresa adjudicataria.

3. Compras adicionales. En principio, no es objeto de esta licitación la adquisición de

ningún elemento que no esté explícitamente descrito en el presente PPT. No

obstante lo anterior, si la propuesta de la adjudicataria supusiera la utilización de

elementos software y/o hardware no previsto, será responsabilidad de la misma su

suministro e instalación.

4. Disponibilidad y escalabilidad. El AdL desea prestar a la ciudadanía y usuarios un

servicio web continuo por lo que la arquitectura del conjunto de elementos deberá

estructurarse para cumplir dicho objetivo. Para ello se propondrá un sistema

redundante de elementos configurados en clúster o con varios frontales, balanceado

de carga y mantenimiento de sesión. La configuración de la arquitectura permitirá

con facilidad el aumento del número de servidores, así como el reemplazo de alguno

de ellos por otros de mayor potencia o mejor rendimiento, sin interrupción del

servicio, escalabilidad horizontal y vertical.

5. Backup y contingencias. Los niveles de disponibilidad propuestos a implementar

por el adjudicatario deberán obligan a que las propuestas incluyan las previsiones y

propuestas para llevar a cabo la ejecución de backup, restauración y contingencias

del conjunto de los sistemas. Tales propuestas serán implementadas con los medios

de los que dispone el AdL, previo consenso y aprobación con los técnicos

municipales.

6. Esquema Nacional de Seguridad. Las empresas licitantes deberán establecer las

medidas de seguridad que sean precisas para que el funcionamiento del sistema sea

acorde a lo establecido en el Esquema Nacional de Seguridad (Real Decreto

3/2010).

7. Canal Seguro. Establecimiento y asistencia. Los contenidos de los sitios web

objeto de este PPT serán accesibles mediante canal seguro, protocolo HTTPS, para

lo cual el AdL pondrá a disposición los certificados necesarios para lograr dicho

objetivo en todo el dominio (*.logrono.es) y los subdominios de éste.

A tal efecto debe señalarse que, el AdL cuenta con la propiedad de varios dominios

para los sitios objeto de este PPT, como por ejemplo logroño.es, logrono.es y

logroñoturismo.es, logronoturismo.es, admitiéndose una ejecución de lo requerido

en el presente PPT en estructura de dominio y subdominios como Logroño.es para

el sitio corporativo y turismo.logroño.es para el sitio turismo (en caso de problemas

o en aras de una mayor internacionalización (omitir el carácter “ñ”), pudiéndose

optar por implementar la capa de seguridad en logrono.es y redirigir las peticiones

de Logroño.es).

Para la aceptación por parte del cliente del certificado de intercambio de los

sistemas del AdL, deberá desarrollarse un mecanismo que compruebe en el

navegador cliente la instalación de la autoridad certificadora emisora de dicho

http://logroño.es/

http://www.logrono.es/


certificado de sitio web. Actualmente los certificados utilizados por AdL son

emitidos por la AC Administración Pública, AC Raíz FNMT, incluidos en las

versiones recientes de navegadores de los diferentes sistemas operativos y

plataformas, pero esta situación puede cambiar, por lo que el valor de AC del

certificado de sitio utilizado deberá ser parametrizable para poder alterarlo de forma

sencilla y cómoda. En aras de una mejor experiencia de usuario, el sistema capturara

el posible error e instruirá al ciudadano en la instalación de la AC requerida para el

establecimiento del canal seguro.

8. Monitorización. En la actualidad el AdL dispone de la herramienta Zabbix para la

monitorización de sistemas Linux CentOS 7 en uso en la instalación actual.

Teniendo esto en cuenta, la adjudicataria y será responsable de suministrar, instalar

y configurar los posibles plugins o elementos necesarios para que los diferentes

sistemas involucrados (CMS, Base de Datos, gestión de directorio LDAP,

Indexador, etc.) se incluyan en dicha monitorización. Por tanto deberá poderse llevar

a cabo la integración y seguimiento de los sistemas involucrados en la propuesta de

solución, así como la monitorización centralizada desde Zabbix de aspectos tales

como las conexiones, el número de usuarios, el consumo de recursos, etc.

9. Visualización de anotaciones. La adjudicataria propondrá herramientas para el

estudio de anotaciones del servidor Http así como de posibles herramientas de

control de anotaciones del resto de sistemas que conformen la arquitectura. La

adjudicataria será la responsable de su instalación.

4.2.4 Componentes de la solución.

4.2.4.1 Gestor de contenidos (CMS)

Gestor de Contenido (CMS). Establecido que el producto base a utilizar debe ser Liferay

v7.0 ó superior, o producto equivalente, el licitador especificara para las características

descritas a continuación la solución que propone o como ésta se sustenta en el producto y

versión que proponga (presente en el core del producto y versión propuesta, incorporada

mediante plugin de producto o plugin de terceros de libre licenciamiento, mediante

desarrollos propios de su solución ofertada, etc.).

Los licitadores adjuntaran en su propuesta una relación que enumere las características de

la instanciación del CMS ofertado que permita la valoración del mismo atendiendo,

detallándose a continuación las características del CMS que estarán sujetas a

consideración:

CMS-1.Servidor aplicaciones JAVA. La plataforma deberá permitir el despliegue de

aplicaciones J2EE realizadas en Java.

CMS-2. Multibrowser, Multihost. El CMS podrá funcionar con total normalidad para la

gestión diaria de contenidos (modalidad edición) independientemente del navegador

utilizado y la dirección URL donde resida o visualice el contenido. Es posible que un

mismo sitio o contenido, pueda ser accesible mediante varias URLs, interna o externa a la

red corporativa, pero no afectara a la gestión de contenidos.

CMS-3. Multiidioma. Permitirá alternar la visualización y gestión de los contenidos en

diferentes idiomas de entre los que se encuentren disponibles. Se posibilitara que solo


algunas zonas o subsitios se encuentren en varios idiomas. En esos casos deberá permitirse

la selección de idioma de entre los disponibles elección que se mantendrá durante la

navegación por la Web mientras exista el idioma seleccionado y retornándose al idioma

básico o por defecto en el momento de ausencia de contenidos traducidos.

CMS-4. Elección de contenido adaptado. El CMS permitirá con facilidad la alternancia

entre contenidos de una misma página, así el contenido de una misma página podrá

ocultarse y presentar un contenido alternativo en lectura fácil si existe tal contenido (para

lo cual se habrá visualizado y seleccionado el icono apropiado), o si está presente un video

en Lengua de Signos (LdS) si de igual manera está presente el icono de LdS. Así mismo la

GEAdL suministrara las acciones o botones de tamaño de texto, alto contraste para que el

contenido sea alterado en su visualización.

CMS-5. Sitio, multisitio y jerarquía. El CMS soportara una estructura multisitio

jerarquizada, permitiendo el establecimiento de diferentes permisos y roles del sitio o de

subáreas del sitio, para la gestión de contenidos.

CMS-6. Mapa de sitio. El CMS permitirá la creación con facilidad del mapa de sitio de

forma sistematizada y automática. Adicionalmente el resultado del mapa de sitio deberá ser

fácilmente manipulable para poder simplificar su contenido si se considerase, por lo que

será conveniente disponer de la capacidad de generar el mismo en un formato sitemap.xml.

Esta característica podrá ser nativa al CMS o añadida mediante un plugin estándar o

incluso un desarrollo particularizado.

CMS-7. Áreas especiales. Permitirá la integración de áreas especiales con contenidos

permanentes o periódico (casos como Transparencia o Semana Santa en Logroño), que por

su carácter transversal o por la imposibilidad de encajarlos armoniosamente en la jerarquía

de un determinado sitio requieran de una ubicación neutra. Podrá ser configurado como

sitio o subsitio.

CMS-8. Contenido cíclico, temporal o sucesivo. Permitirá la creación de elementos

temporales de un conjunto de contenidos o de una subestructura jerarquizada del sitio, así

por ejemplo se permitirá con facilidad crear una estructura anualizada para noticias dentro

de la sección noticias, o presupuestos anualizados dentro de su zona o estructuras

organizativas más amplias como la composición de una Corporación Municipal. Siempre

serán representados inicialmente los valores del contenido vigente (instancia temporal

actual) permitiendo la selección de otra instancia temporal de entre las existentes.

CMS-9. Autorizaciones y delegación. El CMS se integrara con el servicio de directorio

ligero del AdL mediante protocolo LDAP, permitiendo delegar las diferentes

responsabilidades o roles de zonas del sitio web a grupos definidos y gestionados mediante

LDAP. Así mismo, el CMS deberá adaptar la complejidad de la visualización de opciones

al rol de persona autenticada, pudiéndose definir al menos dos tipos de visualización: Una

para técnicos del servicio de NNTT y otra para el personal del AdL que cree o modifique

contenidos.


CMS-10. El CMS permitirá de forma segura la delegación en la gestión de contenidos a

terceros o empresas externas que mantengan una relación con el AdL basada en contratos o

relación temporales específicas. El sistema deberá permitir en dichos casos la delegación

de las autorizaciones necesarias para permitir la realización de las tareas de creación,

publicación, modificación y revisión de contenidos en determinadas secciones de la web

municipal limitando el alcance de la misma a la zona afecta a las funciones del contrato e

imposibilitando la alteración del resto de contenidos fuera de su ámbito de actuación.

CMS-11. Sesión de edición. Se posibilitará el acceso a una sesión autenticada, privada o

de edición, mediante el uso de certificado digital así como mediante usuario y contraseña.

En ambos casos se usarán las credenciales residentes en el directorio, LDAP.

CMS-12. Mantenimiento de sesión de edición. El CMS deberá suministrar un rango de

tiempo suficiente para la gestión de contenidos sin que se produzca el caducado de la

sesión. Debe tenerse en cuenta que determinados contenidos pueden contener un número

elevado de elementos o que alguno de ellos puede requerir de largos períodos de escritura

en cliente sin comunicación con el servidor. Sera deseable que el establecimiento de ese

valor de expiración de sesión sea fácilmente parametrizable o incluso que sea adaptable a

los diferentes perfiles de edición que pueden concurrir en el mantenimiento del sitio web.

CMS-13. Gestión de credenciales y roles del LDAP. Sera deberá posibilitar la gestión de

credenciales y grupos de usuarios registrados en el LDAP desde el CMS, ya sea por

características incluidas en su núcleo, o bien mediante la aportación de la funcionalidad

mediante plug-in u otros elementos. Se permitirá que las credenciales existan en el CMS,

siempre que exista algún sistema de sincronización con repositorios de credenciales,

LDAP, existentes.

CMS-14. Edición on-line o previsualización de contenidos. La edición de contenidos se

realizara en un entorno autenticado integrado con LDAP, mediante una navegación web

similar a la navegación anónima de cualquier usuario web, minimizando las diferencias

entre el entorno de edición y visualización web. Los formularios de edición web deberán

ser fácilmente configurables en cuanto a la disposición de elementos y contar con las

características de previsualización, planificación de publicación y expiración de validez de

publicación, elección de versiones y visualización de auditoria o historial de

modificaciones. Permitirá mostrar autoría de las alteraciones realizadas en un contenido.

CMS-15. Editor de texto enriquecido. El editor de texto deberá ser ligero,

preferiblemente realizado mediante JavaScript, que pueda ser personalizable o

configurable para impedir la inclusión de contenidos que incurran en perdida de

homogeneidad con la GEAdL, perdida de validez del fichero HTML resultante (documento

bien formado), incumplimiento de validación accesibilidad, etc.

CMS-16. EN-301-549:2018. El CMS validara el cumplimiento de la norma EN 301

549:2018 y RD 1112/2018 de los contenidos creados o modificados, avisando,

proponiendo o realizando acciones a este respecto. Algunas consideraciones a tener en

cuenta serán:


ALT. Los textos alternativos en imágenes serán obligatorios para permitir su

publicación.

CSS. Los estilos o atributos de visualización no podrán especificarse en el contenido,

siempre será presentado mediante reglas CSS. No se permitirá estilos en línea.

Marcado HTML. El código HTML estará siempre bien formado y el CMS

impedirá la perdida de esta cualidad.

Saltos Enlaces. Se explicitarán en el código HTML de forma que puedan ser leídos

por los programas lectores web. Adicionalmente podrá visualizarse con iconografía

la acción de apertura en nueva pestaña, ventana o salida del sitio web, que pueda

producirse como consecuencia de la pulsación de un enlace.

Meta-Información de archivos. Los contenidos de tipo fichero (documentos,

videos, audios, etc.) permitirán la introducción de información relativa a su tamaño,

duración de video o audio, fecha de creación, fecha de validez o vigencia,

periodicidad de creación, etc. Se posibilitara la visualización o consulta de esta

información con carácter previo a su visualización o descarga mediante una capa de

visualización, tooltip o ayuda en globo, etc.

Así mismo se consideraran otras funcionalidades que pueda aportar el CMS o

desarrollos propios para validar el cumplimiento de las mencionadas normas, como

análisis de contrastes de imágenes, etiquetado de acrónimos o abreviaturas, corrector

ortográfico, etc., y en particular la incorporación de Lectores de contenido.

CMS-17. Validación HTML y Navegadores. El contenido HTML producido por los

sitios Web será siempre bien formado y estándar, no pudiendo incluir particularidades

HTML propias para navegadores. Excepcionalmente podrá codificarse algún criterio de

particularización si fuera ineludible para que el contenido fuera homogéneo o

independiente para la representación en el navegador. Sera compatible con cualquier

navegador y sistema operativo e independiente del medio. El grado de compatibilidad con

los navegadores será en versiones recientes a la adjudicación de esta licitación y al menos

2 versiones anteriores.

CMS-18. SEO (Optimización para motores de Búsqueda): No es un objetivo principal

del AdL la obtención del posicionamiento en los buscadores aunque por otras

consideraciones sí que deberán cumplir las reglas y recomendaciones sobre

posicionamiento, así y en concreto se observara el cumplimiento de reglas y

recomendaciones PageSpeed Insights.

CMS-19.El diseño de los portales deberá realizarse bajo el paradigma Mobile First,

aportándose una mejora adicional de posicionamiento en la indexación realizada por los

buscadores generales.

CMS-20. URL’s amigables. El CMS propondrá en el momento del guardado del

documento o contenido, la URL corta o amigable con la que será publicado el contenido,

permitiendo su modificación por parte del gestor del contenido.


CMS-21. Suscripción a contenidos. El CMS contara con la funcionalidad de creación de

canales de suscripción de contenidos RSS, ATOM, debiendo ser fácil y rápida la creación

de sindicadores de contenidos de una zona seleccionada.

CMS-22. Notificaciones Web. Se habilitaran las llamadas Push Notifications o Web Push,

permitiendo el CMS definir al personal responsable de contenidos este tipo de

notificaciones para que puedan ser ofertadas al público. Un caso concreto de interés seria

la comunicación de los contenidos de Avisos y Noticias presentes en la Web Municipal sin

necesidad de navegar por el sitio web que las contiene, incidencias de tráfico, etc.

CMS-23. Redes Sociales.

Compartir. El CMS contendrá la capacidad de compartición de contenidos,

detallando la presentación del enlace a compartir con las siguientes redes de amplia

difusión, WhatsApp, Twitter, Facebook, etc.

Visualizar actividad social. Permitirá la integración con facilidad de widgets para las

identidades digitales en redes sociales gestionadas por el AdL o entidades

relacionadas.

Estadísticas y Seguimiento. Se valorara la posibilidad y facilidad de extracción de

estadísticas al respecto de la compartición de contenidos en las redes sociales,

pudiendo especificar datos por red social y/o zona de la web (por ejemplo noticias

compartidas por Twitter). Esta característica podrá ser implícita al CMS, aportada

mediante plugin o mediante desarrollo especifico.

CMS-24.Valoración de contenidos. El CMS contara con la posibilidad de que los

visitantes puedan valorar contenidos a los que previamente se les haya especificado que

puedan registrar puntuaciones. una vez emitida la valoración, se informara al usuario de

que el voto ha sido almacenado y actualizara el número de votos y o puntuación del

contenido. Esta característica suele implementarse con una estética de 5 estrellas que se

completan a medida que se valora.

CMS-25.Chat. El licitador aportara la posibilidad de ubicar a discreción del AdL el

servicio de chat que suministre el CMS de origen, mediante plugin o mediante desarrollo

específico.

CMS-26. Así mismo se incluirá la utilización del api WhatsApp para permitir una

comunicación sencilla del ciudadano mediante envío de mensajes desde su teléfono móvil

o WhatsApp Web hacia el WhatsApp municipal existente.

CMS-27.Comentarios: El CMS permitirá seleccionar si ciertos tipos de contenidos o

contenidos concretos permiten la posibilidad de introducir comentarios o no y si estos

deberán ser moderados antes de su publicación o no. Los comentarios podrán obtener

valoraciones positivas o negativas del resto de personas que lea el contenido y el

comentario.

CMS-28. Flujos de Aprobación: El CMS tendrá la capacidad de especificar si

determinados contenidos siguen un flujo de aprobación. Permitirá la inclusión de acciones


personalizadas dentro de ese flujo de personalización. Las autorizaciones para las fases del

flujo de aprobación serán registradas mediante roles existentes en el LDAP. En aquellos

casos en los que se consideraran adecuados, la adjudicataria deberá implementar los

mismos en la gestión de los contenidos.

CMS-29.Exportación a Calendarios, iCalendar, Google Calendar. El CMS permitirá

incorporar o trasladar los datos de contenidos a los calendarios del cliente, en formato ical

(ics) o inclusión directa a Google Calendar, así se permitirá trasladar información de

eventos u otros contenidos al calendario del ciudadano

CMS-30.Vigencia de Contenidos. El CMS permitirá planificar el período de publicación,

archivado y caducidad de los contenidos. Además, permitirá configurar que sucede con un

contenido una vez alcanzada una fecha determinada (si se expone o no públicamente, si se

archiva moviendo el contenido a un área de archivo, hemeroteca, si simplemente caduca y

se elimina, etc.). Estas características permitirán la gestión de contenidos previos a su

exposición pública, su eliminación desatendida o programada, o si se requiere la creación

de archivos de contenidos similares a hemerotecas de noticias.

CMS-31. Staging mode ó puesta en escena. El CMS permitirá la modificación de un

conjunto amplio de contenidos (detrás de escena) en el mismo servidor local u otro (por

ejemplo de desarrollo) permitiendo posteriormente la publicación de todos ellos de forma

sencilla y conjunta.

CMS-32. Publicación de contenidos desde directorio. El CMS permitirá la exposición

pública de contenidos existentes en ubicaciones concertadas y accesibles mediante la

infraestructura de red. Los contenidos serán accesibles por el CMS mediante conexión

directa, FTP, u otro protocolo automatizado. Teniendo esto en cuenta, se deberá posibilitar

que los diferentes gestores de contenidos puedan determinar, como último paso del proceso

de gestión, la publicación o exposición pública de los mismos (por ejemplo exponer un

presupuesto aprobado y revisado) de tal forma que el almacenamiento de la documentación

en una ruta predeterminada sea visible por el público en Internet, sin exigir al gestor de

contenidos el acceso al CMS para subir o publicar dichos contenidos.

CMS-33. Geolocalización de Contenidos. El CMS suministrado, bien mediante

complemento estándar o mediante desarrollo a medida, permitirá añadir información de

geolocalización a aquellos contenidos que se determine. Para ello la adjudicataria podrá

contar, si así lo desea, con WS municipales de localización de calles y portales del

municipio. Estará permitido la utilización de cualquier otro medio sencillo y cómodo de

geolocalización para asociarlo al contenido, siempre y cuando se cubra la necesidad

expuesta.

CMS-34. Opción Llévame. Guiado hacia localización del contenido. Los contenidos

que tengan asociada información de Geolocalización, ofrecerán la posibilidad de calcular

la ruta o seguir la ruta mediante servicios de Google desde la ubicación en la que en ese

momento se encuentra el ciudadano (si este la suministra). Podrá valorarse discriminar la

opción de guiado según el medio de representación, optando por la representación de los

pasos a seguir para llegar al destino si estamos navegando con un ordenador de sobremesa,


o en caso de navegar con móvil arrancar Google Maps tras obtener la ubicación del

dispositivo y que esta nos guie al destino.

CMS-35. Presentación geolocalizada resumida. El CMS permitirá la visualización

localizada de forma resumida de un conjunto de contenidos, ejemplo sobre un mapa

representara puntos sobre los eventos que cumplan con los criterios de selección, sería una

alternativa o complemento a listar un conjunto de contenidos, noticias, eventos,

monumentos, etc.

CMS-36. Galerías fotográficas. El CMS deberá contar con la funcionalidad de creación

de galerías fotográficas, así como con la posibilidad de permitir o impedir, con facilidad, la

descarga de las imágenes visualizadas a discreción del creador de contenidos.

CMS-37. Inclusión de videos. El CMS permitirá la inclusión y reproducción de videos

almacenados en plataformas de streaming (Youtube, etc.) de tal forma que sea obtenga una

integración armoniosa mediante un reproductor embebido, ocultando en la medida de lo

posible la ubicación última del video. Asimismo permitirá la reproducción de videos

almacenados de forma local, codificado mediante las etiquetas propias de HTML. La

inclusión de este tipo de videos exigirá de la validación previa de que dicha funcionalidad

se encuentra soportada en el navegador cliente, avisando en caso contrario o aportando

alternativa de reproducción en alguna plataforma de almacenamiento de videos.

CMS-38. Visualizador en línea de PDF. El CMS incluirá un visualizador ligero para la

previsualización de ficheros libres de amplia difusión, pdf. Se valorara la existencia de

desarrollos estándar (plugin) o a medida para la previsualización de otros formatos de

carácter propietario (doc, docx, xls) y de carácter libre ODF (odt, ods, etc.,). En todo caso,

el visualizador o el CMS permitirá la descarga del mismo.

CMS-39. Transversalidad de contenidos. El CMS permitirá el etiquetado de contenidos

con facilidad, mediante uso de etiquetas agrupadas en taxonomías para que posteriormente

sean mostrados en diferentes ámbitos, así por ejemplo las noticias se podrán etiquetar con

el identificador de la concejalía asociada, la materia afectada, el programa o proyecto

relacionado, etc., de forma que en otro ámbito puedan llegar a consultarse las noticias

asociadas a una concejalía, materia, proyecto, etc. Esta característica podrá ser inherente al

CMS ofertado, o bien ser incorporada al mismo mediante un desarrollo estándar (plugin) ó

particular.

CMS-40. Estadísticas. El CMS contara o permitirá la incorporación con facilidad de la

gestión de estadísticas de uso de portales de forma diferenciada. Las estadísticas podrán ser

propias del CMS (siempre que éstas sean a Google Analytics que sería el estándar o

referencia a conseguir), o la utilización de las propias estadísticas de Google Analytics. El

licitador deberá proponer y argumentar razonadamente la elección del sistema de

estadísticas. Se valoraran estadísticas de seguimiento a nivel de detalle inferior a la página,

como es el seguimiento de pulsaciones de clics sobre botones o referencias que pudieran

producir la salida del sitio.

CMS-41. Sincronización de entornos. El CMS permitirá la sincronización entre entornos

desarrollo (DESA) y producción (PRO) de forma sencilla y eficaz permitiendo seleccionar


manualmente o mediante criterios de fechas, autoría, áreas de sitio, etc. los contenidos que

se desea sincronizar entre los dos entornos. La sincronización deberá poder ser

seleccionable en su sentido (DESA a PRO, o viceversa) y en los contenidos y también en

los componentes o códigos a sincronizar, todo ello tendente a igualar o homogenizar

entornos completos o desarrollos específicos.

CMS-42. Actualización y seguridad. El CMS permitirá la actualización de sus

componentes de forma fácil, tanto de la parte central del CMS como de los posibles

desarrollos incorporados. Asimismo deberá ser sencillo retraer una actualización

erróneamente incorporada o que sea aconsejable su retirada de la exposición pública. El

acceso a repositorios de actualización deberá ser fácil, rápido y gratuito.

CMS-43. Monitorización del rendimiento. El CMS incorporara o permitirá la

incorporación de módulos que realicen el estudio del rendimiento, el rastreo de errores y

aspectos tendentes a resolver problemas existentes o prevenirlos en un futuro, así mismo

será considerado la posibilidad de integración de herramientas similares para la

herramienta de monitorización de sistemas Zabbix, utilizada sobre las maquinas Linux

CentOS.

CMS-44. Se valorara la posibilidad de identificar sesiones abiertas (autenticadas) en el

CMS.

CMS-45. Trazabilidad. El CMS deberá contar con la propiedad de versionado de sus

contenidos, así como el historial de las modificaciones realizadas.

CMS-46. Modularidad funcional. El CMS permitirá con facilidad la incorporación de

nuevos módulos funcionales a los ya existentes, incorporados, particularizados o

desarrollados inicialmente.

4.2.4.2 La Base de Datos del CMS El licitador aportara la solución de Base de datos (BD) para soportar el CMS. Será el

encargado de la instalación en los entornos ofertados y de la configuración para cumplir los

objetivos de disponibilidad requeridos, así mismo propondrá las estrategias de respaldo y

restauración de la BD y el plan de actuación ante contingencias.

Sera valorada la existencia de desarrollos para realizar el seguimiento, monitorización y

sistemas de alerta de la BD propuesta y su posible integración con el sistema Zabbix para

su monitorización.

La elección de la BD será argumentada para soportar los contenidos que sean gestionados

por el CMS y cumplan con los rendimientos objetivos.

Adicionalmente el licitador incluirá en el plan de formación y transferencia tecnológica la

instalación y gestión de la BD.

4.2.4.3 El Buscador Uno de los aspectos fundamentales para los nuevos sitios web municipales habrá de ser el

Buscador. A este respecto los licitadores podrán optar en sus propuestas por utilizar el

motor de búsqueda que consideren siempre que ésta opción no suponga gastos adicionales

para el AdL. En cualquier caso, la propuesta de motor de búsqueda deberá estar

argumentada indicando los motivos por los que resulta adecuada para cubrir las


necesidades del AdL. Independientemente del motor de búsqueda propuesto, la interfaz

búsqueda deberá ser:

Simple. A ser posible compuesta por una única y sencilla caja de texto

Amigable. Deberá predecir, corregir y sugerir ayudas para la búsqueda.

Eficiente. Deberá conseguir localizar aquello que se desea buscar.

Personalizado. Aprenderá de las búsquedas anteriores. Opcionalmente podrá

especificarse el sitio web, subsitio o temática donde realizar la búsqueda de entre los

sitios web propiedad del AdL.

Multiidioma: Debido a que la web puede ser multiidioma deberá considerarse la

gestión separada de rastreo, creación de índices y realización de búsquedas según el

idioma seleccionado de navegación, para ello el buscador deberá seleccionar

automáticamente el índice sobre el que se efectuara la búsqueda así como el resto de

sus funcionalidades como texto predictivo, sugerencias, etc.

Asimismo, la búsqueda no será una simple indexación de contenidos sino una

interpretación semántica del contenido y una interpretación semántica de la búsqueda. El

mantenimiento de índices de los contenidos será inmediato tanto en la creación o

modificación de contenidos, si bien el rastreo e indexación de contenidos accesibles

mediante URL a webs relacionadas con el AdL podrá ser programada o planificada.

Por simplicidad y comodidad, bajo el termino buscador residirá la funcionalidad y no se

especificaran detalles sobre rastreo, análisis, indexación o búsqueda, pudiendo ser

referenciado a lo largo del presente documento como búsqueda o buscador. En cualquier

caso el licitador deberá detallar como implementa y divide esta funcionalidad entre los

diferentes componentes, así como especificar que producto concreto propone para cada

funcionalidad (rastreo, análisis, indexación y búsqueda) y los medios o configuración

adicional requerida para dotar de capacidad semántica y predictiva al buscador.

Asimismo el buscador será capaz de realizar búsquedas sobre la base de datos del CMS,

diferenciando o singularizando los resultados de búsqueda por sitios que pueda contener el

mismo CMS, así como URLs de sitios web de propiedad del AdL, ejemplo:

www.logronoturismo.es, sedeelectronica.logrono.es. Los resultados de la búsqueda serán

estructurados por sitio web, y agrupados o jerarquizados por taxonomía o áreas de sitio.

Otras características del buscador serán:

Texto predictivo o autocompletado de palabras durante la introducción de términos

de búsqueda. A medida que vaya finalizando palabras, se deberá informar del

resultado de coincidencias, así el ciudadano puede optar por ir detallando más la

búsqueda o finalizarla si considera aceptable el número de resultados.

Las palabras tecleadas serán contrastadas contra diccionario/s de datos para evitar

errores de tecleo con teclas próximas o errores ortográficos, para ello podrán

mostrarse resultados bajo epígrafes como “quizás quiso decir” que muestre la

corrección realizada.

Ordenamiento de resultados de la búsqueda según número de visitas, fecha de

publicación de contenidos u otros aspectos. El objetivo no es que el usuario

http://www.logronoturismo.es/


determine como ordenar la colección de resultados sino el establecer un valor

asociado a la página de contenido que sea devuelto por el buscador y sirva para

ordenar la presentación de resultado, así como que considere todos o algunos de

estos criterios al objeto de que el resultado de la búsqueda sea presentado de la forma

y en el orden más útil para el ciudadano.

Posibilidad de almacenar cookies de búsqueda para apoyar la escritura predictiva

futura de búsquedas.

Posibilidad de ordenar resultados de búsqueda acordes en función de la

geolocalización de los resultados y la ubicación del demandante.

Para la indexación de contenidos se minimizará la acción de las personas que

gestionen el contenido. A tal fin, éstas deberán centrarse en el contenido sin pensar

en el establecimiento de palabras claves, términos de búsqueda u otros elementos

para que el contenido pueda ser localizado. De requerirse esta acción deberá ser

mecanizada por el CMS o desarrollo implementado para tal finalidad.

4.2.4.4 El Buscador orientado a desarrolladores Además del buscador especificado con anterioridad, las propuestas deberán incluir también

un buscador (debe entenderse como funcionalidad de búsqueda) de uso “interno” que

permita:

Localizar cadenas de texto dentro del código (jsp, html, etc.) del propio CMS

Referencias cruzadas de componentes, widgets, etc. del CMS, ej.: donde se usa el

componente menuNoticias

A diferencia del buscador público, que realiza búsquedas en los contenidos publicados,

éste otro será una herramienta/mecanismo que facilite el mantenimiento del código y/o

etiquetado del contenido presentado o resuelto, sirviendo así como mecanismo de

evaluación de cambios en la presentación de contenidos o búsqueda de errores. Del mismo

modo permitirá evaluar de forma anticipada el impacto de ciertas modificaciones o

cambios en reglas de estilo CSS u otras porciones de código en la que se soporta la

presentación de contenidos.

Adicionalmente se considerará la posibilidad de buscar y reemplazar cadenas de texto de

forma automática y masiva para cubrir necesidades de actualización en código y/o

etiquetado.

Este buscador o funcionalidad de búsqueda orientada a desarrolladores puede

materializarse de alguna de las formas siguientes:

Una capacidad existente en el CMS o añadida a él que permita realizar la función

descrita.

Un documento que describa los pasos a realizar para cubrir la función descrita

mediante el uso combinado y secuenciado de herramientas existentes. En caso de que

se precisen herramientas adicionales, el licitador deberá suministrarlas libres de

licenciamiento y cualesquiera requerimientos para su instalación será responsabilidad

de la adjudicataria.

Otra solución aportada por el licitador.


El licitador especificara y detallara cuál de las opciones adoptara en su oferta. En caso de

que pueda aportar varias de ellas, deberá indicar el orden de preferencia para cubrir la

necesidad descrita de la forma más cómoda y rápida para los desarrolladores de código.

4.2.4.5 Directorio de Identidades (LDAP) En la actualidad el AdL dispone de:

Un sistema LDAP propietario, Active Directory, AD, que gestiona las identidades de

Gestores de Contenido y usuarios registrados en la Sede Electrónica.

Otro AD que gestiona las identidades de los empleados municipales.

La intersección entre ambos AD’s constituye el conjunto de empleados municipales que

realizan gestiones de mantenimiento de contenidos en el CMS. Esta distribución de

identidades consigue aislar los usuarios web, que pueden ser externos, de los usuarios

internos, pero presenta el inconveniente de que hay usuarios en dos directorios internos que

mantienen contenidos web lo que complica su gestión y mantenimiento.

La nueva arquitectura de sistemas, CMS y LDAP, debe evitar los problemas expuestos y

mantener los beneficios del esquema anterior. Para ello el licitador detallara un esquema de

identificación en cascada LDAP, sindicación de credenciales u otro medio que cumpla con

los objetivos expuestos, permitiéndose la confluencia del almacenamiento de credenciales

en el propio portal Liferay o producto equivalente.

La gestión de identidades, y autenticación de las mismas permitirá el establecimiento y

gestión de roles o grupos que permitan limitar el acceso a los contenidos del CMS.

La gestión de roles o grupos deberá estar centralizada y las modificaciones de las mismas

no incurrirán en la perdida de coherencia de los sistemas involucrados.

Se valorara que además de la identificación y autenticación mediante usuario y contraseña

se permita la identificación autenticada con credenciales existentes en los certificados

digitales residentes en el almacén de certificados del navegador mediante el acceso a datos

públicos del certificado como DNI, nombre y apellidos, dando así acceso a sesiones

privadas que permitan el mantenimiento de contenidos. Adicionalmente se podrá

considerar el acceso mediante certificado digital almacenado en otros dispositivos de

seguridad como DNIe.

Las identidades existentes en el vigente AD, corresponden a las credenciales de los

gestores de contenido actuales agrupados en roles o grupos asociados a áreas de la

estructura actual de contenido, por tanto serán evaluadas para la migración al sistema

LDAP propuesto mediante el formato de intercambio de datos LDIF, pudiendo resultar de

esta evaluación una migración completa o parcial de identidades, el reemplazo de

credenciales por la incorporación manual de las mismas, o el complemento de pertenencia

a grupos de nueva creación para gestionar contenidos web. En todo caso esta actividad

será responsabilidad de la empresa adjudicataria. Los datos, de requerirse, serán aportados

por el AdL en un fichero .ldif, una vez acordado que campos del LDAP a exportar.


El licitador deberá instalar dentro de la arquitectura de sistemas propuesta, si lo precisara,

el producto de su elección, que en cualquier caso deberá ser libre de licenciamiento e

instalado en los sistemas Linux CentOS indicados.

4.3 Seguridad e identidad de sitios Web.

Todos los contenidos publicados en los sitios Web objeto de este pliego lo serán bajo el

protocolo https, haciendo uso de diferentes tipos de certificado de servidor. Para ello el

AdL cuenta con certificados de servidor de validación extendida (EV) y certificados

comodín (Wildcard) dependiendo la elección de uno u otro del sitio web al que se aplique.

Esta capa de seguridad tiene como finalidad:

Garantizar la autenticidad de los contenidos visualizados así como,

La custodia legal de los datos de carácter personal aportados.

Sera necesario redirigir tráfico desde dominios propiedad del AdL, de los cuales no se

dispone certificado, a otros dominios que si dispongan de ellos. En algunos casos será por

imposición técnica como es el caso de www.logroño.es a www.logrono.es para responder

peticiones bajo un certificado de validación extendida SSL (EV), mientras que en otros

casos será por no disponer del certificado del dominio concreto, caso de logronoturismo.es.

El dominio logrono.es contara con un certificado SSL EV mientras que para el resto de

sitios o subsitios serán ofertados mediante certificados de tipo comodín (SSL Wildcard)

bajo el dominio logrono.es, caso de turismo.logrono.es, así como para otros que pudieran

llegar a crearse.

4.4 Accesibilidad de sitios Web.

4.4.1 Validación, declaración e informe de accesibilidad

Sera un requisito ineludible para la aceptación de la entrega de cualquiera de los sitios web

requeridos en el presente PPT, el cumplimiento de las normas de accesibilidad EN 301

549:2018 “Requisitos de accesibilidad de productos y servicios TIC aplicables a la

contratación pública en Europa”, que a su vez enlaza con WCAG AA 2.1. Para ello el

adjudicatario deberá realizar la evaluación de accesibilidad del sitio web desarrollado con

carácter previo a su entrega. La validación de accesibilidad deberá realizarse de forma

manual y automática mediante herramientas de diagnóstico de accesibilidad de amplia

difusión y consenso.

Los portales o sitios Web entregados deberán contar con una declaración de accesibilidad

de sitio web siguiendo el modelo europeo disponible para tal efecto disponible en:

http://eur-lex.europa.eu/legal-content/ES/TXT/?uri=uriserv:OJ.L_.2018.256.01.0103.01.SPA&toc=OJ:L:2018:256:FULL.

El informe de accesibilidad del portal o sitios web detallara los aspectos de accesibilidad

estudiados, las herramientas automáticas de validación utilizadas, las páginas del sitio web

estudiadas y cuantos aspectos sean relevantes sobre accesibilidad. Este informe de

evaluación será aportado en el momento de la entrega del sitio Web.

4.4.2 Accesibilidad: Penalización especial


http://www.logrono.es/


El incumplimiento de las normas de accesibilidad establecidas en los epígrafes anteriores

será considerado motivo suficiente para realizar la resolución del contrato.

4.4.3 Navegación accesible e inclusiva

Se requiere de una navegación web selectiva a las necesidades físicas y cognitivas del

ciudadano, y con carácter inclusivo, que se materializara con la selección del tipo de

navegación web disponible en la cabecera a seleccionar entre las siguientes:

Original (por defecto)

Lengua de signos.

Lectura fácil.

Alto contraste.

De idéntica forma se dispondrá de un selector de idioma de navegación en la web que

permita la visualización en el idioma seleccionado o en el idioma por defecto en caso de no

existir el contenido en el idioma seleccionado, actuándose de forma similar a lo expresado

para la selección de forma de navegación web. La navegación en alto contraste será

resuelta mediante el establecimiento de reglas CSS.

Para el resto de modalidades de navegación, la estructura de contenidos dispondrá de

varios campos o elementos para un mismo contenido. De ese modo dispondremos del

contenido por defecto (texto original) que será incorporado al sistema por el personal

destinado al realizar sus tareas de creación y gestión de contenidos y, también, otros

contenidos alternativos asociados tales como el contenido en lengua de signos o el

contenido en lectura fácil. A éste respecto el sistema ha de habilitar un mecanismo que

permita que, una vez establecida una navegación específica (por ejemplo en lengua de

signos), esto implique la selección de este contenido para ser mostrado allí donde este

exista, mostrando el contenido por defecto en caso de no existir el contenido en el formato

seleccionado. La navegación web y la estructura del sitio no se altera, será inmutable o

común a la modalidad de navegación, simplemente existirá una coexistencia de contenidos

adaptados.

Adicionalmente, las páginas mostraran iconos que permitan:

Aumentar o disminuir texto de la pagina

Cambiar a modalidad de Alto contraste la pagina

Alternar a lengua de signos, reproducción de video, en caso de su existencia

asociada.

Alternar a lectura fácil, en caso de su existencia asociada.

Estos iconos, barra de botones o como quieran ser denominados serán ubicados en las

páginas de acuerdo a lo establecido como norma en el GEAdL. Los iconos serán mostrados

cuando la página tenga contenido asociado a una característica, esta acción solo tomara

efecto en la página mostrada, no como la opción seleccionada en la cabecera que marcara

la predilección de navegación. El valor por defecto será una navegación por defecto,

seleccionando el contenido principal o contenido por defecto.

4.4.4 Accesibilidad de sitios Web. Enlaces rotos


El licitador deberá diseñar un mecanismo para proteger al visitante del sitio web de la

aparición de enlaces rotos (solo para sitios o subsitios web gestionados por el CMS objeto

de este PPT) de forma que:

Muestre un contenido informativo de lo ocurrido y proponga la reanudación de la

visita web o mantenga la visita en la página donde está ubicado el enlace.

Informe de forma automática a webmaster de la aparición de este error, para

proceder a su arreglo.

4.5 Sitio Web Corporativo.

4.5.1 Estructura de contenidos existente

La estructura presente en la Web Municipal responde a unas necesidades determinadas en

el año 2009. La estructura se basa en las siguientes zonas o áreas:

1. El Ayuntamiento: Conteniendo información estructurada sobre la corporación, la

estructura administrativa de servicios y el gabinete de prensa.

2. Sede Electrónica: Conteniendo los servicios electrónicos proporcionados por el

AdL, pero los mismos se encuentran fuera del ámbito del presente PPT.

3. La Ciudad: Comprende información turística, histórica, climatológica, etc. acerca

de Logroño.

4. Logroño por temas: Es un conjunto de 16 temas, que clasifican la información

contenida en el resto de la web acorde a la temática tratada.

5. Otros contenidos: Agenda cultural, guías y directorios, transparencia.

Área El Ayuntamiento: http://www.logroño.es/wps/portal/web/inicio/ayuntamiento

http://www.logrono.es/wps/portal/web/inicio/ayuntamiento

1. El Ayuntamiento 1.1 El Gobierno Local 1.1.1 La Alcaldesa 1.1.2 Tenientes de Alcalde 1.1.3 Áreas de Gobierno 1.1.4 Pleno Municipal 1.1.5 Junta de Gobierno Local 1.1.6 Comisiones 1.1.7 Grupos Políticos 1.1.8 Tribunal Económico Administrativo 1.1.9 Consejo Social de la Ciudad 1.1.10 Información Judicial 1.1.11 Distritos Municipales 1.2 Normativa Municipal 1.3 Presupuesto Municipal (Anualizado) 1.4 Auditoria y Fiscalización 1.5 Contratación (Enlaces) 1.6 Información administrativa 1.6.1 Avisos Municipales 1.6.2 Formularios y Solicitudes 1.6.3 Oferta de Empleo Público 1.6.4 Información acceso a pruebas selectivas 1.6.5 Becas y Subvenciones 1.6.6 Relación de Puestos de Trabajo 1.8 Gabinete de Prensa 1.8.1 Noticias 1.8.2 Agenda 1.8.3 Información de servicio 1.8.4 Publicaciones 1.8.5 Imagen Corporativa 1.9 Servicio de Información 1.10 Servicios Municipales

http://www.logroño.es/wps/portal/web/inicio/ayuntamiento

http://www.logrono.es/wps/portal/web/inicio/ayuntamiento


El área Servicios Municipales, representa la estructura administrativa del AdL, resultado

adecuada para su utilización en las labores de mantenimiento por parte de los empleados

públicos encargados de la gestión de contenidos asociados. Pero, por otro lado, implica un

conocimiento de la estructura municipal por parte de la ciudadanía que no siempre es

posible. Adicionalmente esta estructura sufre cambios de forma periódica, lo que implica

que dichos cambios se han de repercutir en la web. Esta tarea de mantenimiento no

proporciona ningún beneficio adicional al ciudadano en la búsqueda de contenidos o en la

realización de gestiones municipales. Más al contrario, generalmente supone múltiples

inconvenientes para aquellos que están habituados a utilizar la web como medio de

relación o búsqueda de información municipal. Por todo ello, se indica que el licitador no

está obligado a mantenerla en su propuesta ya que el foco de atención quiere trasladarse

hacia el ciudadano que consulta la web y no al empleado que la mantiene.

El área Sede Electrónica, se encuentra fuera del alcance del presente proyecto, aunque

deberán existir referencias, o enlaces desde la web corporativa hacia la Sede Electrónica

para posibilitar la realización de trámites administrativos.

El área La Ciudad, será tratada en el apartado de la web de Turismo, puesto que se

entiende que una reestructuración de contenidos puede implicar el traslado de este conjunto

de información a la futura web de Turismo.

El área Logroño por Temas, no contiene en si misma contenidos nuevos sino que supone

la representación de contenidos o enlaces según su relación con uno de los 16 temas de

clasificación. Esta rama o su objetivo estaría sujeto a revisión en este PPT, optándose por

su eliminación o el reemplazo de este objetivo por otra forma de clasificación.

Otros contenidos: Constituido por el conjunto de contenidos que, formando parte de la

web actual, no se encuentran incluidos en la estructura anteriormente citada por su menor

relevancia o carácter transversal. Entre ellos podemos encontrar:

Agenda de eventos de la ciudad:

http://www.logrono.es/wps/portal/web/inicio/agendaEventos. Muestra los eventos

que se desarrollan en la ciudad y dispone de un buscador según temática, o fechas de

realización.

Transparencia:

http://www.logrono.es/wps/portal/web/inicio/especiales/transparenciamunicipal

Responde a una estructuración propia que permite exponer eficientemente una

colección de enlaces a informaciones presentes en la Web municipal, y

excepcionalmente muestra información que no está presente en la Web.

Accesibilidad:

http://www.logrono.es/wps/portal/web/inicio/accesibilidad

Es un conjunto información relativa a esta temática y que contiene actualmente 4

páginas de contenido.

Guías y directorios:

http://www.logroño.es/wps/portal/web/inicio/guiasDirectorios

Es una guía estructurada o clasificada de entidades de la ciudad, alojamientos,

bodegas, teatros, sindicatos, etc. Debido a la dificultad del mantenimiento de esta

http://www.logrono.es/wps/portal/web/inicio/agendaEventos

http://www.logrono.es/wps/portal/web/inicio/especiales/transparenciamunicipal

http://www.logrono.es/wps/portal/web/inicio/accesibilidad

http://www.logroño.es/wps/portal/web/inicio/guiasDirectorios


información, unido al hecho de que la información expuesta no es objeto del AdL y

que adicionalmente la web municipal no es un canal de búsqueda o uso por parte del

ciudadano de esta información, este contenido no será migrado o continuado en

presente contrato.

4.5.2 Migración de contenidos existentes

El personal del AdL será el encargado de proporcionar a la adjudicataria el conjunto de

contenidos existentes para que ésta pueda realizar la adecuación e incorporación de los

mismos a la nueva web municipal. Dichos contenidos se proporcionarán en formato CSV

(plano separado por comas). Caso de que la adjudicataria deseara el suministro de los

mismos en un formato diferente, deberá solicitarlo al AdL quien evaluará el cambio para

determinar si es posible entregarlos en el formato requerido. En caso de que los nuevos

contenidos no precisen de la totalidad de campos existentes, la empresa adjudicataria podrá

demandar solamente aquellos campos del contenido existente que precisa para

incorporarlos a los nuevos contenidos.

Actualmente existen contenidos que están etiquetados o clasificados en taxonomías que

deberán ser exportados para su incorporación en contenidos nuevos o ser reemplazados por

nuevos valores dentro de la taxonomía o sistema de clasificación que exista. La

clasificación de contenidos será una cualidad exigible, ya que permitirá enlazar contenidos

así como posibilitar búsquedas o criterios de selección.

Los mecanismos diseñados para la incorporación de contenidos migrados a la nueva web

serán responsabilidad del adjudicatario, quien será también el encargado de incluirlos en la

nueva web y clasificarlos o etiquetarlos de acuerdo a las taxonomías que se definan. Estos

mecanismos de incorporación de contenidos deberán estar diseñados para permitir la

incorporación gradual de contenidos de una misma zona, así como la eliminación de

contenidos previamente cargados para posibilitar una posterior carga parcial o completa.

Ha de tenerse en cuenta que mientras se esté diseñando y cargando datos en la nueva web,

la existente deberá permanecer en funcionamiento y por tanto continuará generando

nuevos contenidos que deberían volver a migrarse. Este aspecto debe ser valorado por la

adjudicataria a fin de establecer cuál es el mecanismo más adecuado para realizar la

transición de una a otra sin producir menoscabo en la prestación del servicio al ciudadano.

4.5.2.1 Guía útil. Guías y directorios La sección o apartado de Guías y Directorios existente en la actual web no será migrada

ni en contenido ni en estructura. Se extinguirá debido a que no aporta valor informativo al

ciudadano ya que el mantenimiento de la información resulta imposible de llevar a cabo de

forma adecuada. En su lugar se estudiara la incorporación de una Guía de Servicios que

recoja la relación de servicios públicos, autobuses, taxis, farmacias, polideportivos, policía

local, bomberos, etc.

Podrá ser una ampliación, rediseño y reescritura del actual servicio de información

http://www.logroño.es/wps/portal/web/inicio/ayuntamiento/servicioInformacion

complementando la información de contacto, localización electrónica, ubicación física. Los

servicios podrán ser representados mediante su representación en un callejero y

geolocalizada. También se podrán filtrar servicios.

http://www.logroño.es/wps/portal/web/inicio/ayuntamiento/servicioInformacion


4.5.2.2 Catálogo de Servicios Municipales La sección de Servicios Municipales tal y como actualmente se encuentra estructurada

deberá desaparecer en la nueva web, si bien los contenidos existentes serán incorporados

en la nueva web mediante la creación y diseño de una estructura más acorde a las

necesidades del ciudadano, incluso ofertando su visualización bajo diferentes criterios o

temas. En ese sentido, se deberá plantear la creación de una estructura y contenidos de

Servicios Municipales desde una perspectiva de las necesidades del ciudadano, atemporal y

que no implique alteraciones por cambios organizativos internos y que responda o informe

al ciudadano sobre el lugar donde puede realizar sus gestiones municipales.

El Catálogo de Servicios puede estar organizado mediante temas, hechos vitales u otros

criterios. En cualquier caso será el licitador el encargado de plantear la alternativa a la

actual estructuración de Servicios Municipales para cumplir con los objetivos de ser más

cercana al ciudadano y estable en el tiempo.

Debe tenerse en cuenta que secciones de la web actual tales como Subvenciones,

Convenios, Formularios y Solicitudes, Documentos Destacados, Instalaciones

relacionadas, Eventos relacionados y Notas de Prensa, etc. aportan contenidos comunes a

todos los Servicios Municipales aunque éstos se deberán encontrar etiquetados

internamente con el servicio apropiado permitiendo así que puedan ser expuestos de una

forma particular o general según se filtre o no por dicha etiqueta su visualización.

Estos contenidos pueden responder a un mismo patrón o plantilla de creación o ser un

contenido totalmente singular como puede ser el caso de Población dentro del Servicio de

Estadística.

Tal y como se comentó con anterioridad la actual estructura de servicios municipales solo

reporta beneficios organizativos a la hora de configurar áreas de actuación al personal

administrativo, pero no aporta información al ciudadano que, por lo general, desconoce la

organización vigente. Adicionalmente el mantenimiento de una estructura acorde a la

organización vigente, que puede sufrir cambios por iniciativa de la corporación, implica

tareas de mantenimiento laboriosas y sin reporte de beneficio externo. Por todo esto, el

licitador deberá incorporar estos criterios en el diseño de su propuesta, y ser consciente de

que será necesario trasladar los contenidos actualmente existentes, no se contempla

inicialmente perdida de contenidos.

4.5.2.3 Funcionalidades, propias y de servicio existentes En la actual Web Municipal existe un conjunto de funcionalidades que han de ser

consideradas para su migración o reescritura, existen tres tipos de estas llamadas

funcionalidades:

Portlet, componentes Java ejecutados en el actual WebSphere Portal Server que

además ejecuta el CMS, utilizando el API del WPS.

Servicios Web (WS), escritas en Java e interactuando contra el CMS del

WebSphere Portal Server para extraer contenidos con destino a la App Logroño.es.

Deberán reescribirse manteniendo el actual interface de comunicación para no

propagar la necesidad de cambio a la App,

https://play.google.com/store/apps/details?id=com.jig.ayuntlogrono.

Otros con menor número, pueden estar desarrollados en JavaScript, asp, java.

https://play.google.com/store/apps/details?id=com.jig.ayuntlogrono


El inventario de dichas funcionalidades es el que se resume a continuación:

Portlet

Buscador General

http://www.logrono.es/wps/portal/web/inicio/buscador Permite la selección según tipo de contenido, posibilita particularizarlo en otras zonas de la web para filtrar formularios, ordenanzas, etc.

Calles de Logroño

http://www.logroño.es/wps/portal/web/inicio/laCiudad/moverte/CallesLogrono/libro Permite buscar una calle del conjunto de calles existentes en el libro Muestra la hoja del libro y la geolocalización con un mapa Google

Alta de Eventos

http://www.logroño.es/wps/portal/web/inicio/agendaEventos/solicitudInclusionEventos Envió de información mediante email acerca de un evento para ser incluido por webmaster

Inscripción Boletín

http://www.logroño.es/wps/portal/web/inicio/solicitudAltaBoletin Envió de información para registrarse en el newsletter.

Cámaras de Trafico

http://www.logroño.es/wps/portal/web/inicio/laCiudad/moverte/trafico/camaras Muestra las imágenes depositadas en un FTP

MeteoLogroño http://www.logroño.es/wps/portal/web/inicio/laCiudad/presentacionCiudad/climatologia/estacionClimatologica Presenta información textual y grafica obtenida mediante una ubicación FTP

Visor fotos Archivo

http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/archivo/catalogo Aplicación que mediante filtros por autor, año, lista las fotografías existentes y permite acceder a la fotografía e información asociada, existen un fondo de aproximadamente 5000 fotografías

Convenios Urbanísticos

http://www.xn--logroo-0wa.es/wps/portal/web/inicio/unidadesMunicipales/urbanismo/transparencia/conveniosUrbanisticos Utiliza WS para acceder al sistema de Expedientes de URB y muestra la información relativa a los convenios municipales

Licencias Urbanísticas

http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/urbanismo/licencias/publicacionLicencias Utiliza WS para acceder al sistema de Expedientes de URB y muestra la información relativa a los convenios municipales

JavaScript

Visor de Redes WiFi

http://www.logroño.es/wps/portal/web/inicio/mapaWifi Permite el posicionamiento de puntos WIFI y dibuja sus áreas de influencia a diferentes colores

App asp

Visor de Logroño 3D

http://www.logroño.es/wps/portal/web/inicio/logronoMapa3D Permite seleccionar una calle y muestra varias vistas de una calle y permite realizar mediciones,

App Java Tomcat

LifeGreenTIC http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/medioAmbienteAguas/lifeGreenTIC/sondaMar http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/medioAmbienteAguas/lifeGreenTIC/sondaMer http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/medioAmbienteAguas/lifeGreenTIC/smartLuix Extraen información de una BD Oracle y la presenta.

Servicios Web WSEventos: Extrae información eventos desde CMS para proporcionarla a la App Logroño.es WSPublicaciones: Extrae información publicaciones desde CMS para proporcionarla a la App Logroño.es WSNoticias: Extrae información noticias desde CMS para proporcionarla a la App Logroño.es

Como se deduce de la relación anterior la mayoría de elementos detallados son Portlets

(aplicación java de servidor), cuya problemática podemos concentrarla en la presentación

de información, ya que la lógica e interacción con la base de datos reside en WS, que no se

verá alterada ya que única y exclusivamente deberán ser utilizados.

4.5.2.4 Propuesta de Diseño, estructura y servicios

4.5.2.4.1 Diseño.

El nuevo sitio web www.logroño.es deberá tener un diseño actual, acorde a las estéticas

presentes en las webs de Administraciones Locales, que respete las normas establecidas en

la GEAdL y que, además, cumpla con las normas de accesibilidad EN 301 549:2018 y RD

1112/2018.

http://www.logrono.es/wps/portal/web/inicio/buscador

http://www.logroño.es/wps/portal/web/inicio/laCiudad/moverte/CallesLogrono/libro

http://www.logroño.es/wps/portal/web/inicio/agendaEventos/solicitudInclusionEventos

http://www.logroño.es/wps/portal/web/inicio/solicitudAltaBoletin

http://www.logroño.es/wps/portal/web/inicio/laCiudad/moverte/trafico/camaras

http://www.logroño.es/wps/portal/web/inicio/laCiudad/presentacionCiudad/climatologia/estacionClimatologica

http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/archivo/catalogo

http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/urbanismo/transparencia/conveniosUrbanisticos

http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/urbanismo/licencias/publicacionLicencias

http://www.logroño.es/wps/portal/web/inicio/mapaWifi

http://www.logroño.es/wps/portal/web/inicio/logronoMapa3D

http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/medioAmbienteAguas/lifeGreenTIC/sondaMar

http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/medioAmbienteAguas/lifeGreenTIC/sondaMer

http://www.logroño.es/wps/portal/web/inicio/unidadesMunicipales/medioAmbienteAguas/lifeGreenTIC/smartLuix



Las características detalladas y exigidas en la elección del CMS serán de aplicación en las

webs municipales, entre ellas www.logroño.es, algunas de estas características son

adaptabilidad a medios, accesibilidad, usabilidad, etc.

4.5.2.4.2 Estructura.

La licitadora elaborara una o varias propuestas de estructuración de los contenidos a

migrar, así como las funcionalidades existentes y aquellas que sean de nueva incorporación

suministradas por los requerimientos al CMS. Las propuestas podrán ser presentadas

mediante maquetas o bocetos (mockups) o wireframe, que muestren cual es el carácter

visual esquemático y el sistema de navegación por los contenidos. Se ha de considerar que

el carácter visual no será definitivo al estar sujeto a la confección y aprobación del

GEAdL. Las propuestas deberán ser particularizadas para, al menos, los medios de

representación de móvil y escritorio, indicando cuales son las reglas de comportamiento o

adaptación a otras resoluciones de dispositivo de representación.

Para la estructuración de contenidos se deberá contemplar la posibilidad de publicación de

los mismos como rutas dentro del sitio o como subsitios, si así se determinara en la

necesaria fase de presentación y análisis del proyecto.

Para la estructuración de contenidos se deberá contemplar la posibilidad de archivado de

contenidos fuera de línea, todo ello tendente a no destruir información y mantener un nivel

de rendimiento adecuado. Será el nivel de rendimiento el que determine como estructurar

este crecimiento de contenidos para aunar información y rendimiento.

La clasificación de contenidos mediante etiquetas de taxonomías será un requisito para

poder mostrar contenidos bajo diferentes perspectivas de visualización, a representar en

diferentes partes del sitio. Así mismo, se deberá contemplar la creación de taxonomías

temporales para la clasificación o etiquetado de contenidos que permitirá por ejemplo

realizar búsquedas específicas.

4.5.2.4.3 Evolución temporal de contenidos.

Es importante señalar que existen contenidos con vigencia temporal. A modo de ejemplo

se puede indicar que los presupuestos vigentes en un año serán reemplazados por la

aprobación de unos nuevos presupuestos al año siguiente. Pero si se desea mantener cada

una de esas “versiones de la información” clasificadas, marcadas y organizadas de acuerdo

con la temporalidad con la que se originaron para poder realizar consultas retroactivas,

surge una necesidad que debe ser tenida en cuenta a la hora de estructurar y organizar los

contenidos. En general, este tipo de información se mantiene vigente únicamente durante el

año de su generación, pero una vez que es reemplazada pierde su vigencia, aunque

permanece como información vinculada al año de aprobación.

Estas consideraciones deben ser tenidas en cuenta a la hora de estructurar y/o etiquetar el

correspondiente contenido, para que no queden enlaces perdidos o inconexos a pesar de la

evolución temporal del contenido.

4.5.2.4.4 Servicios

Los servicios a incluir serán los expuestos en el apartado anterior y deberán suponer una

integración completa, funcional y estética con el resto del portal, por lo que el adjudicatario

deberá proceder a su reescritura en el lenguaje de programación apropiado al CMS y

adaptar su maquetación y estilos para el cumplimiento de la nueva GEAdL. Debe tenerse

en cuenta que la mayoría de servicios son multicapa, contando con la existencia de



servicios web encargados del acceso a los datos, motivo por el cual será aconsejable la

reescritura de la capa de visualización de los mismos.

Se debe considerar que el uso de estos WS, no clusterizados, producirá la denegación de

servicio en caso de caída del sistema que los soporta, por lo cual, el licitador puede

plantear alternativas para cumplir con las exigencias de servicio del sistema, siendo él, el

encargado de su implementación.

4.5.2.4.5 Formularios: Generación y recogida de Información. Opción firma y CVS.

El licitador deberá suministrar una herramienta, plugin o desarrollo particular sobre la

infraestructura propuesta que permita la generación de formularios web.

Todos los formularios generados por la herramienta deberán cumplir las normas de

accesibilidad detalladas en este pliego.

Dicha herramienta deberá presentar las siguientes características:

1) Posibilidad de impresión o salvado como formulario vacío en formato PDF.

2) Posibilidad de cumplimentación en línea y posterior impresión.

3) Posibilidad de cumplimentación en línea con opciones añadidas o configurables;

a. Integración con servicio de Quejas y Sugerencias mediante el Web Service,

suministrado.

b. Integración con la Base de Datos corporativa mediante Web Service, que

permita validar la existencia de las credenciales presentadas.

c. Integración con el sistema de firma electrónica, Autofirma.

d. Posibilidad del envío de ficheros adjuntos o no.

e. Posibilidad de configurar protección o no para el formulario mediante captcha

u otro sistema.

f. Posibilidad de especificar un contenido genérico o singular, que explicite el

tratamiento de los datos de carácter personal que puedan ser aportados, así

como un campo de aceptación de las condiciones o finalidad del tratamiento.

Asimismo, la adjudicataria deberá desarrollar los siguientes formularios:

Formulario de contacto que permita adjuntar ficheros y enviarlos posteriormente

mediante correo electrónico, para que el ciudadano pueda comunicar las

consideraciones que sean precisas.

Formulario para solicitar la inclusión de eventos o actividades en las agendas

municipales, corporativa, turismo, etc., este formulario ya ha sido citado con

anterioridad.

Adicionalmente, se indica que en la web actual, existe un contenido denominado

Formularios y Solicitudes donde se recoge un conjunto de documentos, en su mayoría

PDF, que permiten al ciudadano su descarga para que con posterioridad los imprima,

rellene y aporte a la hora de realizar su tramitación de forma presencial en el AdL. No es

objeto del presente contrato la transformación de los mismos a formularios web, pero sí

que deberán ser tenidos en cuenta a los efectos de trasladarlos y enlazarlos para su

descarga en la nueva web, tal y como se realiza actualmente.


El Plan de Formación y Transferencia Tecnología tratará específicamente la

transformación de documentos PDF a formularios Web para que dicha transformación

pueda ser llevada a cabo por el equipo de desarrollo del AdL utilizando las nuevas

herramientas incorporadas en el CMS. Tras la formación, los actuales Formularios y

Solicitudes serán trasladados o incorporados en la web hasta su progresiva sustitución por

formularios realizados mediante la herramienta aportada.

4.5.2.4.6 Callejero

Será objeto del contrato la realización de un callejero que permita la representación

geolocalizada de elementos del tipo:

Punto, como colegios, guarderías, polideportivos, etc.

Polilíneas, como aparcamientos regulados ORA, carril bici, etc.

Áreas, como zonas WiFi, zonas comerciales, parques, distritos, etc.

Como el callejero contara con un elevado número de elementos, este deberá permitir la

estructuración de contenidos para realizar la selección y representación sobre el mapa. Se

ha de considerar que el callejero puede representar elementos muy variados tales como

colegios, guarderías, institutos, ludotecas, edificios municipales, centros sociales, centros

formativos, teatros, cines, cámaras de tráfico, ORA, aparcamientos de moto, reserva de

plazas de minusvalía, zonas peatonales, parques, etc.

Adicionalmente se ha de considerar la necesidad de ampliar o detallar la información sobre

cualquiera de los elementos representados mediante la selección e incorporación de la

información al mismo mediante una ventana emergente o similar que exponga información

e incluya posibilidades basadas en las características del CMS como el detalle de una ruta,

la incorporación al calendario de eventos, etc.

4.6 Sitio Web Turismo.

4.6.1 Contenidos existentes

En la actualidad no existe un sitio web de turismo específico para la ciudad de Logroño. En

su lugar se dispone de varias secciones de la web corporativa dedicada exclusivamente a

contenidos relacionados con el turismo en la ciudad, como lo son las secciones La Ciudad

y Logroño por temas (tema Turismo).

Asimismo existen también varios desarrollos externos de páginas web, llevados a cabo por

terceras partes y en diversas herramientas que aun siendo propiedad del AdL se encuentran

alojados en sitios externos y en diferentes estados de elaboración y/o ampliación de

contenidos tales como:

http://lacalleesunmuseo.es/, catálogo y descripción de las obras escultóricas más

representativas de la ciudad de Logroño.

http://www.logronoturismo.es/qr/, sección de la web corporativa dedicada al

turismo en Logroño y acciones más importantes al respecto en la ciudad.

http://www.logronoturismo.es/qr/bodegas-es/ catálogo, descripción y otros aspectos

sobre las bodegas de la ciudad., iglesias, etc.

4.6.2 Migración de contenidos

http://lacalleesunmuseo.es/

http://www.logronoturismo.es/qr/

http://www.logronoturismo.es/qr/bodegas-es/


Los contenidos relacionados con el Turismo en la ciudad alojados en la web corporativa

(www.logroño.es), se encuentran en las siguientes secciones dentro de la estructura de la

web actual:

3. La Ciudad 3.1 Presentación de la Ciudad 3.1.1 Situación Geográfica 3.1.2 Historia de la Ciudad 3.1.3 Meteorología 3.1.4 La ciudad en Cifras 3.2 Turismo 3.2.1 Como llegar a Logroño 3.2.2 ¿Qué hacer? 3.2.3 ¿Dónde quedarse? 3.2.4 Lo que no te puedes perder 3.2.5 Guía Turística de Logroño 3.2.6 Guía SICTED 3.2.7 Folletos Turismo 3.2.8 Videos 3.3 Logroño Ciudad Comercial 3.4 Moverte por Logroño 3.4.1 A pie 3.4.2 En bicicleta 3.4.3 En coche 3.4.4 En transporte publico 3.4.5 Estado del tráfico 3.4.6 Callejero 3.4.7 Calles de Logroño 3.4.8 Planos y Mapas

Dichos contenidos serán proporcionados en formato CSV o similares a la adjudicataria

para su consideración, estudio y migración a la nueva web de turismo a desarrollar dentro

del CMS propuesto y siempre con la estructura de información y presentación acorde a lo

establecido en la GEAdL.

4.6.3 Creación del sitio web

Del mismo modo que se ha establecido para la web corporativa, la adjudicataria deberá

elaborar y presentar una o varias propuestas de estructuración de los contenidos indicados

a migrar y de todas las funcionalidades existes y de nueva incorporación de acuerdo con

los requerimientos del CMS.

Las propuestas deberán ser presentadas mediante maquetas o bocetos (mockups) o

wireframe, que muestren cual es el carácter visual esquemático y el sistema de navegación

por los contenidos propuesto. Dichas propuestas deberán ser particularizadas para medios

de representación móvil y de escritorio, señalando cuales son las reglas de comportamiento

o adaptación a otras resoluciones de dispositivo de representación.

Asimismo la adjudicataria deberá especificar como resolver campañas temporales de

publicación de contenidos, tales como Semana Santa, Fiestas Patronales, etc., para su

encaje en la estructura organizativa del sitio web logroñoturismo.es.

Las características expuestas en el apartado del Gestor de Contenidos (CMS) pero que no

se mencionan explícitamente en presente apartado de creación del sitio deberán ser tenidos

en cuenta y podrán ser exigidos por el AdL en la creación de plantillas de autoría o de

creación de contenido, así como en las plantillas de presentación, como por ejemplo las

capacidades de geolocalización, exportación a calendarios, creación de rutas Google Maps,

etiquetado de contenidos con valores de taxonomía, insertado de galerías fotográficas,

incrustación de videos, etc.

4.6.4 Redirección de contenidos

De forma general, y no solo para esta sección, se deberá poder redirigir con facilidad

peticiones realizadas a una URL a una nueva ubicación, como por ejemplo aquellos



contenidos que dispongan de códigos QR de referencia tales como cartelería impresa,

señalizaciones, etc.

4.6.5 Agenda de Eventos. Planes

La web de Turismo deberá contar con una agenda de actividades o eventos de interés

turístico en la ciudad. Dicha agenda deberá permitir la incorporación y registro de eventos

de carácter periódico y/o eventual, para posteriormente poder realizar búsquedas o filtros

por categorías y fechas.

Dicha agenda cultural de turismo deberá estar integrada con la agenda corporativa y con el

resto de agendas de entidades municipales (si las hubiera) para hacer posible la búsqueda

de eventos que, aun habiendo sido registrados por otras unidades hayan sido catalogados

de interés turístico.

Se deberá dotar de la capacidad o funcionalidad para que ciudadanos, organizaciones, etc.,

puedan solicitar el alta de eventos mediante la cumplimentación y envió electrónico de un

formulario diseñado para tal fin, que fue incluido en la lista de funcionalidades a adaptar.

5. Plan de formación

Será responsabilidad del licitador la elaboración y ejecución de un Plan de Formación al

respecto de los contenidos, materias y temas objeto del presente contrato, debiendo

impartirse el mismo en las instalaciones del AdL, para lo cual el adjudicatario deberá

indicar cual son los requisitos necesarios para hacerlo efectivo.

El Plan de Formación deberá ser de un mínimo de 30 horas lectivas debiendo detallarse

en la propuesta el número de contenidos, materias y horas de dedicación así como el

detalle de la planificación propuesta para llevarlo a cabo.

Al respecto de la planificación del mismo, el Plan de Formación se estructurara, al menos,

en dos períodos de realización:

Primer período. Se deberá imbricar en las fases iniciales del proyecto y

contemplara las partes generales del funcionamiento de la plataforma Liferay Portal

o producto equivalente, teniendo como objetivo fundamental formar en el uso y

principales características de la misma al personal de NNTT del AdL de forma que

pueda ser independiente en su uso y gestión.

Segundo período. Se llevará a cabo en las fases finales del proyecto y contemplara

el resto del temario de formación, centrándose en la descripción, funcionamiento y

gestión de las particularidades utilizadas e implementadas en la ejecución de las

webs objeto del presente contrato.

El Plan de Formación deberá incluir en su alcance al menos los siguientes contenidos:

Liferay o equivalente ofertado. Conceptos Generales. Configuración y

parametrización. Actualización de paquetes y aplicación de parches.

Administración del sistema, etc.

CMS. Núcleo central de la formación al que deberá dedicarse al menos el 50% del

número de horas propuestas. En este apartado se incluirá la utilización del CMS,

incluyendo plugins o características adicionales incluidas o desarrolladas

específicamente para dar solución a características indicadas, adaptación a

dispositivos, creación de formularios, encuestas, etc.


Accesibilidad: Características de accesibilidad implementadas y consideraciones

para su mantenimiento en durante el mantenimiento y creación de nuevos

contenidos.

Entornos: Descripción de la arquitectura propuesta y Formación para la

sincronización entre entornos de Desarrollo y Producción, diferentes nodos de

Producción, así como el sistema de balanceado.

Programación de servidor: Se tratará la creación de Portlets y el despliegue,

parametrización, depuración contra el servidor, etc. de los mismos. Debe

considerarse que el personal de NNTT no está familiarizado con el uso de la nueva

herramienta ya que la programación realizada hasta ahora está basada en

Websphere Portal Server.

Control de Versiones, GIT. Los desarrollos que produzca el licitador deberán ser

realizados sobre GIT, y la formación comprenderá el intercambio de forma de

trabajar (idiosincrasia) por parte del adjudicatario, con la finalidad de que el

personal del AdL, no encuentre obstáculos en el posterior mantenimiento del

código entregado.

BD CMS: gestión de Base de Datos del CMS propuesto, backup, recuperación,

optimización, etc.

Formularios. Diseño e integración de formularios web. Consideraciones de

accesibilidad, utilización de captchas, firmado electrónico, etc.

Buscador: Formación sobre los elementos necesarios para el rastreo, indexación y

búsqueda.

Monitorización de Rendimiento y Análisis Forense: Formación herramientas y

procedimientos para el estudio del rendimiento en su conjunto y la búsqueda de

problemas ocurridos durante la ejecución del sistema.

6. Productos a entregar

6.1 Guía de Estilo Electrónico del AdL (GEAdL)

La Guía de Estilo Electrónico para el Ayuntamiento de Logroño (GEAdL) deberá incluir:

Manual de Estilo: Que además deberá incorporar una rápida explicación del

proyecto, él porque del diseño general y de sus elementos en particular.

Material gráfico: Que ha de servir como base y referencia del material gráfico para

las webs licitadas, tanto en los elementos comunes como en los elementos propios

de cada una de las webs, y que habrán de servir de guía general sobre lo que es la

GEAdL.

Tipografías utilizadas: Ficheros de las fuentes tipográficas y variantes,

especificadas en la GEAdL.

Layouts (disposición de elementos): Se deberá incluir un conjunto de layouts que

cubran las necesidades de exposición pública de las webs municipales, tanto de las

dos webs objeto de la presente contratación (corporativa y turismo), así para las

nuevas webs municipales que pudieran surgir.

Manual de Usuario: Con inclusión de los pasos en detalle a seguir para el

mantenimiento y evolución de GEAdL, los criterios de combinación de elementos


para crear nuevos layouts y las pautas de accesibilidad a considerar al modificar la

GEAdL. Los licitadores podrán utilizar como referencia de lo que se espera al

respecto de la GEAdL, el Manual de Estilo Web 2.0 de la Universidad de Málaga

que puede consultarse online en la siguiente referencia

https://www.uma.es/media/files/GUIA_WEB.pdf

6.2 Arquitectura de sistemas involucrados

Los licitadores deberán presentar un documento en el que se describa y argumente la

arquitectura propuesta y la forma en que ésta se adecua a los requisitos establecidos al

respecto por el AdL, con inclusión de la interrelación y coordinación de los diferentes

sistemas involucrados en la solución, incluyendo el CMS, LDAP, BD del CMS, Buscador

(rastreador, analizador, indexador e interfaz de búsqueda), etc.. En la misma se deberá

detallar también:

El dimensionamiento de los elementos para soportar la carga de peticiones actual,

así como las recomendaciones a tener en cuenta para poder modificar el

dimensionamiento manteniendo la calidad de servicio teniendo para ello como

referencia el cuadro de estadísticas de uso aportado en este PPT.

El dimensionamiento de los elementos para soportar la continuidad del servicio

ante tareas de mantenimiento o incidencias (alta disponibilidad).

El procedimiento a seguir para aumentar la capacidad de respuesta o disponibilidad

de su propuesta tanto horizontalmente (número de elementos), como verticalmente

(capacidad de cálculo, ancho de banda, etc.)

El conjunto de pruebas o test del sistema a realizar para comprobar la calidad del

servicio ante situaciones de estrés. El licitador detallara el conjunto de pruebas y la

herramienta que utilizara para crear y ejecutar los test de carga del sistema,

herramientas del tipo Jmeter, LoadRunner, etc. que no podrán suponer coste

adicional de licenciamiento y que quedaran en las instalaciones del AdL para

testear discrecionalmente la calidad del servicio prestado.

Adicionalmente, dentro del mismo documento se deberá incluir;

Herramientas de Monitorización, de los diferentes elementos que intervienen en

la estructura, explicando los elementos de monitorización y análisis propios de cada

componente CMS, LDAP, BD, Buscador, así como su integración en el sistema de

monitorización Zabbix del sistema anfitrión.

Plan de actuación ante contingencias, y como realizar las copias de seguridad y

proceso de restauración, uso de versionado de contenidos.

Plan mantenimiento y sincronización. En donde se establecerán los mecanismos

a seguir para actualizar los sistemas de Producción y Desarrollo con los parches o

actualizaciones que devengan con el tiempo, así como la sincronización de

elementos redundantes en los entornos existentes.

Plan de puesta en producción (PRO). Documentara la estrategia del paso de

elementos nuevos o modificaciones realizadas en entorno de desarrollo al entorno

de producción, estableciendo el detalle del mismo y las consideraciones o pruebas

de aceptación y verificación que han de realizarse, detallando igualmente como

deshacer los cambios ante cualquier eventualidad si fuera necesario.

https://www.uma.es/media/files/GUIA_WEB.pdf


6.3 Maqueta Sitio Corporativo

El licitador presentara la propuesta de estructura de contenidos sobre el CMS ofertado así

como las maquetas sobre varios dispositivos, monitores de escritorio y móviles, como los

criterios de maquetación para adaptarse a las dimensiones variables de los entornos de

representación.

En su propuesta se deberán documentar las propuestas de adaptación de las

funcionalidades expuestas en este PPT al producto base sobre el que se soportaran (plugin,

característica del CMS, etc.).

También se deberá describir las funcionalidades implementadas y la forma de utilización

de la propia funcionalidad.

En su propuesta argumentara como se garantizara el cumplimiento inicial de las normas:

De accesibilidad EN 301 549:2018.

RD 1112/2018 sobre accesibilidad de los sitios web y aplicaciones para dispositivos

móviles del sector público.

WCAG AA 2.1

así como las acciones que implantara para su mantenimiento posterior una vez que la

edición de contenidos sea delegada al personal del AdL.

6.4 Maqueta Turismo de Logroño

A este respecto se deberá presentar una propuesta con los mismos contenidos que en el

apartado anterior, pero particularizada para el sitio web de turismo.

6.5 Buscador

Respecto al buscador, los licitadores deberán especificar los siguientes aspectos:

Funcionalidades. El buscador deberá responder a los requerimientos establecidos en

el presente PPT con respecto a la problemática planteada de búsqueda de contenidos

(diccionarios, interpretación semántica, selección de idioma, orden de presentación

de resultados, etc.). De forma adicional y como apoyo para la descripción de las

funciones de búsqueda que el licitador propone incluir, podrá aportar referencias que

permitan contrastar y verificar de forma pública instalaciones realizadas por él y que

aporten soluciones al conjunto o parte de las funcionalidades expuestas en este

pliego.

Arquitectura. Se deberá detallar con concreción y concisión la solución tecnología,

elementos software a incorporar y relación entre ellos y con el resto de sistemas

involucrados en este proyecto, algoritmos, para resolver todas las problemáticas

planteadas con respecto a la búsqueda, texto predictivo, validación de diccionarios,

orden o rango de presentación de las páginas, etc. Podrán formar parte de la

documentación a presentar en este apartado referencias a sus productos que estén

actualmente en funcionamiento y cuya funcionalidad pueda ser contrastada de forma

pública, mediante una navegación web anónima

Interfaz o maqueta. El licitador presentara propuesta de la interfaz del buscador y

una maqueta de interacción con el servicio de búsqueda. Una vez debe considerarse

la relevancia del buscador, tanto en su ubicación para ejecutarlo, como la

visualización del buscador y resultados una vez ejecutado, podrá optase por una

implementación en capa semitransparente sobreimpresa.


Plan de mantenimiento. Detallara la estrategia de mantenimiento de los sistemas

involucrados en la búsqueda, actualizaciones de versiones, etc.

Estrategia de búsqueda. Se deberá detallar de forma argumentada la estrategia de

rastreo e indexación de contenidos para mantener unas búsquedas actualizadas que

no produzcan resultados caducados ni dirijan a páginas inexistentes. Enumerará los

procesos de mantenimiento y/o actualizaciones a realizar en los elementos del

buscador (rastreo, índices, CMS, etc) –caso de precisarse- al crear contenidos,

modificar o decaer en caducidad planificada o manual, eliminación de contenidos,

etc.

También detallara como crear nuevas colecciones de búsqueda, recrearlas y

asociarlas al mecanismo o interfaz de búsqueda.

6.6 Plan de formación

El plan de formación detallará el contenido de las materias y temas que han de abarcarse

para cubrir las necesidades especificadas en el presente PPT, las herramientas y elementos

a utilizar para desarrollarlo, el detalle completo de la planificación y estructura de la misma

que se propone, etc. En cualquier caso, la formación deberá impartirse en las instalaciones

de AdL, para lo cual el adjudicatario deberá especificar también cuales son los requisitos

que se necesitarían para llevarlo a cabo.

Adicionalmente los licitadores deberán especificar también cual es Curriculum Vitae y la

experiencia del o los docentes que habrán de impartir dicha formación al objeto de

determinar la adecuación de los mismos para dicha tarea.

7. Plazo de ejecución

El plazo máximo de ejecución total del contrato será de 28 semanas (7 meses), contadas a

partir de la fecha de firma del Acta de Inicio de los trabajos. A dicho efecto se indica que el

plazo de ejecución será un criterio de adjudicación ponderado objetivamente, por lo cual se

estará a lo expresado en el artículo 193 de la LCSP 9/2017 en lo que respecta a demoras de

la ejecución y su posible particularización en el Pliego de Cláusulas Administrativas

Particulares (PCAP).

La aceptación de los trabajos realizados se formalizará mediante la correspondiente Acta

de Recepción.

Por otro lado, se establece un plazo máximo de presentación y aceptación para el Prototipo

Wireframe del sitio Web Corporativo de 10 semanas contadas a partir de la fecha de la firma del Acta de Inicio. A éste respecto se indica que dicho plazo se utilizará como criterio de valoración objetiva.

8. Planificación y control de la ejecución

El proyecto contara con varios hitos de control en la planificación que serán los siguientes:

1. Entrega, revisión y aceptación de la GEAdL.

2. Entrega, revisión, aceptación y presentación del prototipo funcional (wireframe) de

un conjunto significativo de al menos 15 páginas de la nueva web corporativa del

AdL.


3. Entrega, revisión, aceptación y presentación del prototipo funcional (wireframe) de

un conjunto significativo de al menos 10 páginas de la nueva web de turismo del

AdL.

4. Entrega definitiva y completa de la nueva web corporativa del AdL, con inclusión

de la migración de datos existentes y todas las funcionalidades asociadas (gestión de

contenidos, buscador, etc) de acuerdo con lo establecido en el presente PPT.

5. Entrega definitiva y completa de la nueva web de turismo del AdL, con inclusión de

la migración de datos existentes y todas las funcionalidades asociadas (gestión de

contenidos, buscador, etc) de acuerdo con lo establecido en el presente PPT.

6. Formación.

8.1 Planificación

La realización en plazo del proyecto objeto del pliego será determinante para el éxito de la

relación contractual entre las partes y la consecución de los objetivos del presente PPT. A

dicho respecto la licitadora deberá de proporcionar una planificación completa, detallada

de las tareas a realizar para llevar a cabo el objeto del contrato.

La planificación aportada deberá ser realista y comprenderá hitos funcionales de

comprobación, pudiendo incorporar puntos de control temporales periódicos sin mediar

hitos de ejecución, en los que se podrán debatir problemas y necesidades a los que se

enfrenta el proyecto y que requieran de impulso o ayuda para la continuación de las tareas

programadas.

La planificación propuesta por la adjudicataria solo podrá llevarse a cabo siempre que se

encuentre debidamente justificada y previo acuerdo negociado con el AdL. En aras de

conseguir una mayor independencia en la consecución de los plazos establecidos en

planificación, se deberán tener en cuenta las siguientes consideraciones:

1. Se deberá planificara la demanda de contenidos a migrar tras la entrega de la

GEAdL y previamente al inicio de la creación de cada sitio web para que el AdL

pueda prever la extracción de los mismos.

2. Para la creación del sitio web de turismo, le será entregado a la adjudicataria el

resultado de la exportación de contenidos existentes en el actual gestor de

contenidos (WordPress), siendo por cuenta del adjudicatario su tratamiento e

incorporación al sitio web destino.

3. Para minimizar posibles desviaciones temporales se deberá planificar un intervalo

de 10 días laborales desde la entrega de un hito hasta la aceptación o presentación de

reparos por parte del AdL.

4. Tras la expresión de reparos por parte del AdL, se incorporarán las modificaciones

detectadas y se dará por alcanzado el hito.

5. Los reparos presentados ante la entrega de un hito parcial deberán ser atendidos de

forma conjunta y completa, sin generar alteraciones con el trabajo entregado y

aceptado previamente.

6. No se aceptará el proyecto completo hasta que no lo sean todos los hitos parciales.

7. Durante las reuniones de seguimiento de la ejecución del proyecto podrán exponerse

apreciaciones sobre el desarrollo de los trabajos, que aun no siendo vinculantes,


podrán ser consideradas por el adjudicatario en aras de una aceptación diligente de

hitos parciales.

8.2 Control y seguimiento de ejecución

Para el seguimiento y supervisión de la ejecución del proyecto, la adjudicataria deberá

nombrar un interlocutor único (Director de Proyecto) que llevará a cabo las labores de

coordinación técnica junto con el Jefe del Proyecto establecido por el AdL. Asimismo, la

adjudicataria propondrá y aportara los métodos y herramientas necesarias para realizar el

control y seguimiento del proyecto, previendo la formación en las mismas para los técnicos

del AdL que lo precisen.

Las herramientas que se requieran para estos fines no supondrán coste alguno (ni por su

uso, ni por formación) para el AdL. Sera, por tanto, aconsejable el uso de herramientas de

acceso libre tanto para el seguimiento del proyecto como para la gestión de incidencias que

puedan ocurrir durante la realización el proyecto y con posterioridad. La elección de estas

herramientas se deja a criterio de la adjudicataria.

Tanto la herramienta de seguimiento del proyecto como la de gestión de incidencias serán

aportadas por el adjudicatario listas para ser utilizadas por ambas partes desde el inicio del

proyecto. Estas herramientas utilizarse en modalidad “cloud” o bien “on-premise”. Si la

opción fuese esta última, será responsabilidad el suministro de los recursos necesarios para

su instalación y puesta en marcha.

Adicionalmente, se establecerán reuniones de seguimiento del proyecto destinadas a la

vigilancia de los plazos ofertados, así como cualesquiera otras que, durante la ejecución del

proyecto, sean consideradas convenientes por cualquiera de las partes. Tras cada una de las

reuniones, la adjudicataria elaborará y entregará acta de los avances e incidencias que

hubieran surgido, estableciéndose, en su caso, las acciones correctoras oportunas que

deberán estar acordadas con el AdL.

9. Precio de licitación

El valor total de licitación estimado para el presente contrato asciende a la cantidad de

120.879,00 € (ciento veinte mil ochocientos setenta y nueve euros) correspondientes a 99.900,00 €

(noventa y nueve mil novecientos euros) de importe base y 20.979,00 € (veinte mil novecientos

setenta y nueve euros) de IVA al 21%.

10. Financiación

La financiación del importe total del proyecto, se realizará de acuerdo a lo expresado en el

siguiente cuadro resumen por partidas presupuestarias:

Partida

Presupuestari

a

Descripción 2018 Total

G2 920.20 641.99 Gastos en aplicaciones informáticas 120.879,00 120.879,00

Total 120.879,00


11. Forma de pago

Como consecuencia de la dimensión de los trabajos a desarrollar y el plazo de ejecución de

los mismos, se considera la realización de pagos parciales según la programación temporal

de productos entregables y cumplimiento de hitos que se describen a continuación.

La siguiente tabla resume los hitos a considerar, estableciendo para cada uno de ellos, los

productos a entregar así como el porcentaje sobre el importe total de la adjudicación, que

permitirá la emisión de factura por el importe calculado, toda vez que se formalizada la

entrega mediante firma de la correspondiente Acta de Recepción Parcial.

Las facturas serán revisadas y contrastadas por el técnico municipal correspondiente que

procederá a su validación. Una vez validadas y aceptadas por el mismo, se procederá a su

abono en los plazos legalmente establecidos para ello.

Hito Descripción Porcentaje

Facturación

1 Guía de Estilos del Ayuntamiento de Logroño 10 %

2 Wireframes/Prototipos web Corporativa y web Turismo 15%

3 Implantación Web Corporativa. 40%

4 Implantación Web Turismo 20%

5 Cierre Final Proyecto 15%

12. Garantía

El licitador deberá incluir en su oferta un mínimo de 1 año de garantía a contar desde el

momento de la firma del Acta de Recepción de los trabajos, todo ello sin coste adicional

para el AdL, debiendo comprometerse a realizar la corrección de los fallos o deficiencias

detectados en cualquiera de los trabajos realizados y/o productos entregados sin coste

adicional para el AdL.

13. Consultas Pliego de Prescripciones Técnicas

Durante el plazo de licitación y ante cualquier necesidad de aclaración que pudiera surgir

sobre cuestiones referidas con las especificaciones u otros aspectos del presente PPT, los

licitadores podrán enviar sus dudas a [email protected] que tras estudio y revisión

de las mismas, se procederá a dar cumplida respuesta de las mismas tanto de forma

individualizada a quien lo hubiera solicitado, como pública mediante exposición en el

Perfil del Contratante del AdL, en la sección Documentación Administrativa y Técnica.

14. Propiedad intelectual, seguridad y confidencialidad

14.1 Propiedad intelectual

El adjudicatario aceptará expresamente que los derechos de propiedad intelectual de

todos los documentos y resultados generados al amparo de los trabajos de éste contrato

corresponden únicamente al AdL, que podrá utilizarlos, reproducirlos o divulgarlos total

o parcialmente.

Toda la documentación quedará en propiedad del AdL sin que el adjudicatario pueda

conservarla o facilitarla a terceros sin expresa autorización de este Ayuntamiento.

mailto:[email protected]


14.2 Seguridad

La empresa adjudicataria, dentro del marco de la ejecución del presente contrato deberá

seguir estrictamente las siguientes pautas de seguridad:

No conectar ningún equipo dentro de la red informática del AdL con ningún otro

sistema informático o de telecomunicaciones ajeno al propio Ayuntamiento. Los

equipos o sistemas que por su actividad pudiesen requerir conexión a servicios

externos al AdL deberán estar aislados, es decir, separados física y lógicamente de

la red informática.

En el caso de ser necesario realizar algún tipo de conexión externa, está deberá ser

solicitada al Servicio de Nuevas Tecnologías del AdL quien determinará si procede

o no dicha conexión, autorizándola o denegándola según el caso. En todo caso,

cuando una conexión sea autorizada, se llevará siempre a cabo de acuerdo con las

condiciones y restricciones determinadas por éste último.

No difundir ni publicar los sistemas de seguridad de la información existentes o

previstos.

No instalar dispositivos de comunicaciones de ningún tipo en equipos (PCs,

Servidores, etc.) conectados a la red del AdL, tanto durante el desarrollo del

proyecto como en la configuración o implantación definitiva el mismo.

14.3 Confidencialidad

El adjudicatario estará obligado a mantener la más absoluta confidencialidad y reserva

de todos aquellos datos, documentos e informaciones que maneje. A éstos tendrán

acceso, exclusivamente, las personas estrictamente imprescindibles para el desarrollo de

las tareas inherentes al contrato. Todas ellas serán advertidas del carácter confidencial y

reservado de la información.

Todos los ficheros, documentos e información que se pongan a disposición del personal

de la empresa para la ejecución de los servicios contratados, son propiedad del AdL y

estarán registrados y sometidos a la salvaguardia que establece la legislación vigente, en

especial la relativa a la protección de datos personales (LOPD). Toda utilización con

propósito distinto del contratado y en especial toda cesión de información a terceros,

será perseguida antes los tribunales.

En particular, el adjudicatario y todo el personal asignado al proyecto se comprometerá

a cumplir de modo estricto las siguientes normas de comportamiento y confidencialidad

respecto a los trabajos objeto de contratación:

1. Tratar toda la información que se le suministre, o aquella a la que pudiera tener

acceso, de forma confidencial con independencia del soporte en que se encuentre

contenida.

2. Entregar todo el material que originado durante el desarrollo del proyecto, y a no

realizar copias de ninguna clase de datos o de cualquier material con fin distinto al

objeto de la asistencia, así como a no difundir ni utilizar los mismos.


3. No introducir en los sistemas municipales software microinformático ajeno al

Ayuntamiento.

4. No divulgar la estructura de ficheros, la existencia de los mismos, ni las

funcionalidades de las aplicaciones desarrolladas o de aquellas de las que tuviera

conocimiento en el desempeño de sus funciones.

5. No revelar la información obtenida de los Sistemas de Información Geográfico, ni la

documentación que se le suministre o aquella a la que pudiera tener acceso en el

desempeño de sus funciones, con independencia del soporte en que se encuentre

contenida.

6. Acceder únicamente a la información necesaria para el desempeño de las funciones

encomendadas.

15. Protección de datos

En el caso de que durante la ejecución del presente servicio, fuera necesaria la cesión de

datos de carácter personal a la empresa adjudicataria, y de conformidad con lo previsto

en el art. 12 de la LO 15/1999, de 13 de diciembre, de Protección de Datos de Carácter

Personal (LOPD) y el Real Decreto 1720/2007, de 21 de diciembre, de desarrollo de la

LOPD, el adjudicatario será considerado como “encargado del tratamiento” de los datos

responsabilidad del Ayuntamiento, debiendo garantizar en todo momento la

confidencialidad de los datos de carácter personal y de todo tipo recibidos, tanto antes

como después de ser tratados, así como que el uso de los mismos será exclusivamente

para el desarrollo de las tareas precisas para poder prestar los servicios acordados. A tal

fin se formalizará un contrato de cesión de datos conforme a lo aprobado por el Comité

de Seguridad de la Información del Ayuntamiento de Logroño.

Logroño, 21 de noviembre de 2018

Analista Adjunta al Jefe de Servicio

Fdo: Blanca García Blanco

Servicio de Nuevas Tecnologías Avenida de la Paz, 11 ......Servicio de Nuevas Tecnologías Avenida...

Documents

Transcript of Servicio de Nuevas Tecnologías Avenida de la Paz, 11 ......Servicio de Nuevas Tecnologías Avenida...