PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA ...

Pág. 1 de 243

PLIEGO DE PRESCRIPCIONES

TÉCNICAS QUE REGIRÁN LA

REALIZACIÓN DEL CONTRATO DE

“DESARROLLO DE LA INICIATIVA

ALBA-SMART 2020”

PROCEDIMIENTO ABIERTO

Exp: 093/16-AE

Código Seguro De Verificación: 4K23956sbqrjHkm2VUNGgw== Estado Fecha y hora

Firmado Por Daniel Noguera Tejedor - Director General de la Entidad Pública Empresarial Firmado 24/11/2016 13:47:09

Francisco Javier Garcia Vieira Firmado 18/11/2016 11:03:24

Observaciones Página 1/243

Url De Verificación https://portafirmas.red.es/verifirmav2/code/4K23956sbqrjHkm2VUNGgw==

https://portafirmas.red.es/verifirmav2/code/4K23956sbqrjHkm2VUNGgw==

Pág. 2 de 243

Pliego de Prescripciones Técnicas – Procedimiento

Abierto “Desarrollo de la Iniciativa Alba Smart 2020”.

Exp.093/16-AE

ÍNDICE

1. INTRODUCCIÓN ............................................................................................................... 8

1.1. Definiciones y Consideraciones Previas ............................................................... 10

1.2. Ámbito del proyecto ................................................................................................... 11

1.3. Situación Actual ......................................................................................................... 12

1.3.1. Ayuntamiento de Almendralejo ........................................................... 12

1.3.2. Ayuntamiento de Badajoz .................................................................... 19

1.4. Alcance ........................................................................................................................ 24

2. REQUISITOS TÉCNICOS .............................................................................................. 27

2.1. Requisitos generales ................................................................................................ 27

2.1.1. Compatibilidad ....................................................................................... 27

2.1.2. Hardware ................................................................................................. 28

2.1.3. Licencias .................................................................................................. 29

2.1.4. Diseño ....................................................................................................... 30

2.1.5. Software ................................................................................................... 31

2.1.6. Autenticación ......................................................................................... 34

2.1.7. Aplicaciones móviles ............................................................................ 35

2.1.8. Capacitación ........................................................................................... 38

2.1.9. Estándares .............................................................................................. 39

2.1.10. Identificación de equipos ................................................................. 39

2.1.11. Suministro e instalación de cartelería FEDER ................................. 41

2.1.12. Aceptación de entregas ................................................................... 42







Pág. 3 de 243



Exp.093/16-AE

2.1.13. Datos abiertos y reutilización de la información del sector

público ...................................................................................................... 42

2.1.14. Gestión del Proyecto ........................................................................ 42

2.1.15. Obligación de información y documentación .............................. 43

2.1.16. Documentación y cierre del proyecto ........................................... 44

2.1.17. Medidas de seguridad y cumplimiento de normativa ................ 45

2.1.18. Seguimiento del proyecto. .............................................................. 46

2.2. Componente 1. Adecuación CPD ............................................................................ 46

2.2.1. Componente 1.1: Sistema de almacenamiento de altas

prestaciones ........................................................................................... 46

2.2.2. ................................................................ Componente 1.2: Chasis Blade

................................................................................................................... 52

2.2.3. .... Componente 1.3: Servidor Blade de 2 vías de alta capacidad de

arquitectura x86 .................................................................................... 55

2.2.4. Componente 1.4: Servidor Blade de 1 vía para backup de

arquitectura x86 .................................................................................... 58

2.2.5. Componente 1.5: Conmutadores de Red Servidores.................. 62

2.2.6. Componente 1.6: Conmutadores de Red Usuarios ..................... 66

2.2.7. ................................ Componente 1.7: Licencia Windows Server 2016

................................................................................................................... 69

2.2.8. Componente 1.8: Licencias para Virtualización .......................... 70

2.3. Componente 2. Flujos de movilidad turística ...................................................... 73

2.4. Componente 3. Innovation hub .............................................................................. 78

2.4.1. Componente 3.1. Elaboración del Plan de Actuación. .................... 79

2.4.2. Componente 3.2. Programa de capacitación .............................. 86

2.4.3. Componente 3.3. - Página web ....................................................... 89







Pág. 4 de 243



Exp.093/16-AE

2.5. Componente 4. Portal de Transparencia y Datos Abiertos ............................. 97

2.5.1. Requisitos técnicos mínimos del diseño y construcción. ............. 97

2.5.2. Requisitos funcionales mínimos del frontend. ........................... 103

2.5.3. Requisitos funcionales mínimos del backend. ............................ 107

2.5.4. Catálogos de datos a publicar ....................................................... 109

2.5.5. Entregables. ........................................................................................ 113

2.6. Componente 5. Infraestructura Wifi ..................................................................... 114

2.6.1. Componente 5.1 Puntos de acceso Wifi ............................................ 114

2.6.2. Componente 5.2 Controladora Wifi ............................................... 116

2.6.3. Entregables ......................................................................................... 118

2.7. Componente 6. Aplicaciones móviles ................................................................... 119

2.7.1. Componente 6.1 Entorno Web ............................................................. 119

2.7.2. .................................................................... Componente 6.2 Lanzadera

.................................................................................................................. 126

2.7.3...................................................................... Componente 6.3 Autobuses

.................................................................................................................. 128

2.7.4. Componente 6.4 Aplicación de atención ciudadana ................. 133

2.7.5. ....... Componente 6.5 Aplicación móvil de guiado a aparcamientos

.................................................................................................................. 135

2.8. Componente 7. Gestión de flotas ......................................................................... 136

2.8.1. Componente 7.1. Dispositivo GPS ..................................................... 137

2.8.2. Componente 7.2. Sistema de gestión .......................................... 140

2.8.3. Entregables ........................................................................................ 142

2.9. Componente 8. Control de afluencia ................................................................... 142

2.9.1. Requisitos técnicos mínimos. ............................................................ 143

2.9.2. Entregables. ....................................................................................... 149







Pág. 5 de 243



Exp.093/16-AE

2.10. Componente 9. Encuestas a Ciudadanía y visitantes ...................................... 150

2.10.1. Requisitos mínimos técnicos. ........................................................ 150

2.10.2. Entregables ...................................................................................... 153

2.11. Componente 10. Plataforma “Smart” .................................................................. 154

2.11.1. Funcionalidades y características principales de la Plataforma

Smart ....................................................................................................... 155

2.11.2. Cuadro de mando integral: ............................................................. 162

2.11.3. Tareas a realizar ............................................................................... 166

2.11.4. Entregables ........................................................................................ 168

2.12. Componente 11. Gestión de aparcamientos ........................................................ 170

2.12.1. Requisitos técnicos .......................................................................... 174

2.12.2. Sistema de gestión. ......................................................................... 179

2.12.3. Procesos de Integración con parking subterráneos ................. 181

2.12.4. Entregables ....................................................................................... 182

2.13. Componente 12. Integración de datos en la plataforma .................................. 183

2.13.1. Requisitos mínimos técnicos. ........................................................ 183

2.13.2. Entregables ....................................................................................... 190

3. REQUISITOS DE LA IMPLANTACIÓN ...................................................................... 195

3.1. Instalación y configuración .................................................................................... 195

3.1.1. Documentación de la implantación ................................................... 195

3.1.2. Instalación y configuración Componente 1 ..................................... 196

3.1.3. Instalación y configuración Componente 3.3, Componente 4,

Componente 9, Componente 10. ...................................................... 198

3.1.4. Instalación y configuración Componente 5 .................................. 200

3.1.5. Instalación y configuración del Componente 6 .............................. 201







Pág. 6 de 243



Exp.093/16-AE

3.1.6. Implantación y configuración del Componente 7 ........................ 204

3.1.7. Instalación y configuración del Componente 8 ............................205

3.1.8. Instalación y configuración Componente 11 ...................................205

3.1.9. Inventariado de los elementos suministrados .............................. 207

3.1.10. Pruebas de funcionamiento ......................................................... 208

3.1.11. Entrega y Aceptación ........................................................................ 208

3.1.12. Gestión del Proyecto ......................................................................209

3.2. Plazos ........................................................................................................................209

3.2.1. Fase I ....................................................................................................... 210

3.2.2. ........................................................................................................... Fase II

.................................................................................................................. 210

3.2.3. .............................................................................................. Capacitación.

.................................................................................................................. 210

3.3. Requisitos de garantía ............................................................................................. 211

3.3.1. Declaración de Garantía ....................................................................... 211

3.3.2. ............................................................................ Duración de la Garantía

................................................................................................................... 211

3.3.3......................................................... Cobertura de la Garantía Hardware

.................................................................................................................. 212

3.3.4. Tiempos máximos de resolución de incidencias y consultas .. 215

3.3.5. ............ Parámetros de medida para el cómputo de penalizaciones

.................................................................................................................. 218

4. CONTROL ECONÓMICO Y DE FACTURACIÓN......................................................220

4.1. Control de facturación ...........................................................................................220

4.2. Hitos de facturación ...............................................................................................220







Pág. 7 de 243



Exp.093/16-AE

5. FORMATO Y CONTENIDO DE LA PROPUESTA .................................................... 223

5.1. Propuesta relativa a los criterios cuya valoración depende de un juicio de

valor (sobre “Criterios de juicio de valor”) .......................................................224

5.1.1. Introducción. ......................................................................................... 225

5.1.2. Verificación del cumplimiento de requisitos obligatorios .......... 226

5.1.3. Requisitos valorables mediante juicio de valor ............................ 226

5.2. Propuesta relativa a los criterios cuantificables mediante la mera aplicación

de fórmulas (sobre “Criterios cuantificables por fórmula”) .......................... 227

5.2.1. Proposición Económica ...................................................................... 227

5.2.2. Modelo de Proposición Económica .............................................. 232

ANEXO I LISTADO DE VEHÍCULOS A INSTALAR EL SISTEMA DE CONTROL DE

FLOTAS. .................................................................................................................... 235

ANEXO II DATASET CONTABILIDAD Y GESTIÓN TRIBUTARIA. ............................... 239

Nota: Cualquier consulta en relación con el presente procedimiento de adjudicación

debe dirigirse por correo electrónico a la dirección [email protected]

Indicando:

Asunto: número de expediente,

Cuerpo: nombre de la empresa, datos de la persona que realiza la consulta y texto

de la consulta.

El plazo de recepción de consultas finalizará 3 días hábiles antes del fin del plazo

de presentación de ofertas. Red.es no tendrá obligación de responder las consultas

realizadas transcurrido dicho plazo.







Pág. 8 de 243



Exp.093/16-AE

1. Introducción

Los Ayuntamientos de Almendralejo y Badajoz son las instituciones locales con

competencias, en los términos de la legislación del Estado y de las Comunidades

Autónomas, en las materias descritas en el artículo 25 de la Ley 7/1985, de 2 de

abril, Reguladora de las Bases de Régimen Local, entre las que se encuentran:

a) Urbanismo: planeamiento, gestión, ejecución y disciplina urbanística.

Protección y gestión del Patrimonio histórico. Promoción y gestión de la

vivienda de protección pública con criterios de sostenibilidad financiera.

Conservación y rehabilitación de la edificación.

b) Medio ambiente urbano: en particular, parques y jardines públicos, gestión

de los residuos sólidos urbanos y protección contra la contaminación

acústica, lumínica y atmosférica en las zonas urbanas.

c) Abastecimiento de agua potable a domicilio y evacuación y tratamiento de

aguas residuales.

d) Infraestructura viaria y otros equipamientos de su titularidad.

e) Evaluación e información de situaciones de necesidad social y la atención

inmediata a personas en situación o riesgo de exclusión social.

f) Policía local, protección civil, prevención y extinción de incendios.

g) Tráfico, estacionamiento de vehículos y movilidad. Transporte colectivo

urbano.

h) Información y promoción de la actividad turística de interés y ámbito local.

i) Ferias, abastos, mercados, lonjas y comercio ambulante.

j) Protección de la salubridad pública.

k) Cementerios y actividades funerarias.







Pág. 9 de 243



Exp.093/16-AE

l) Promoción del deporte e instalaciones deportivas y de ocupación del tiempo

libre.

m) Promoción de la cultura y equipamientos culturales.

n) Participar en la vigilancia del cumplimiento de la escolaridad obligatoria y

cooperar con las Administraciones educativas correspondientes en la

obtención de los solares necesarios para la construcción de nuevos centros

docentes. La conservación, mantenimiento y vigilancia de los edificios de

titularidad local destinados a centros públicos de educación infantil, de

educación primaria o de educación especial.

o) Promoción en su término municipal de la participación de los ciudadanos en

el uso eficiente y sostenible de las tecnologías de la información y las

comunicaciones.

En el ejercicio de dichas competencias, podrán promover toda clase de actividades

y prestar cuantos servicios públicos contribuyan a satisfacer las necesidades y

aspiraciones de la comunidad vecinal.

Por su parte, Red.es, Entidad Pública Empresarial adscrita anteriormente al

Ministerio de Industria. (ahora Ministerio de Energía, Turismo y Agenda Digital),

ante la SETSI (ahora Secretaría de Sociedad de la Información y Agenda Digital).,

tiene atribuida la realización de actuaciones encaminadas a la promoción y al

desarrollo de la Sociedad de la Información en todos los ámbitos de la actividad

económica y social, incluida la gestión de los fondos comunitarios previstos para

estos fines, en los Programas Operativos FEDER 2007-2013 y 2014- 2020 que le

corresponden, de acuerdo con lo dispuesto en el Artículo 3 del Real Decreto

164/2002, de 8 de febrero, por el que se aprueba el Estatuto de la Entidad Pública

Empresarial Red.es.

El 10 de julio de 2012, la Comisión Europea puso en marcha la iniciativa “Ciudades

y Comunidades Inteligentes” que trata de impulsar proyectos de demostración en

energía, transporte y tecnologías de información y la comunicación (TIC) en las

zonas urbanas. Las industrias de la energía, el transporte y las TIC están invitadas

a trabajar junto con las ciudades para combinar sus tecnologías con el objeto de

satisfacer las necesidades de las ciudades. De este modo, se pretende que la







Pág. 10 de 243



Exp.093/16-AE

utilización de tecnologías innovadoras, integradas y eficientes con capacidad de

penetrar en el mercado con facilidad, sitúe a las ciudades en el centro de la

innovación. Entre las fuentes de financiación de la UE, la Comunicación indica que

el Fondo Europeo de Desarrollo Regional (FEDER) es apropiado para estos fines.

Así mismo, y dentro del desarrollo de la Agenda Digital para España, Red.es ha

puesto en marcha la convocatoria de Ciudades Inteligentes, una iniciativa cuyo

objetivo es la colaboración con los Ayuntamientos en la transformación de las

ciudades en ciudades inteligentes de acuerdo a las dimensiones más adecuadas de

su propia idiosincrasia, centrando los esfuerzos en la mejora de los servicios para

sus ciudadanos y visitantes, y el desarrollo sostenible y energéticamente eficiente

de la ciudad. Resultado de esta Convocatoria los Ayuntamientos de Almendralejo y

Badajoz han sido elegidos para el desarrollo de la Iniciativa ALBA-SMART 2020

Dentro de este contexto, el 31 de Julio de 2015, se firma un Convenio de

Colaboración entre los Ayuntamientos de Almendralejo y Badajoz (en adelante “los

Ayuntamientos”) y Red.es con el fin de desarrollar actuaciones encuadradas

dentro de la Iniciativa ALBA-SMART 2020

La iniciativa ALBA-SMART 2020 se plantea como una herramienta para conseguir

un objetivo estratégico como es el bienestar social y económico de los ciudadanos

de los municipios de Almendralejo y Badajoz. A partir del uso de las tecnologías de

la información y las comunicaciones (TICs) basadas en la infraestructura digital y

en servicios digitales, se construye una ciudad que gestiona de forma más

eficiente y sostenible sus recursos y ofrece a sus ciudadanos mejores servicios.

1.1. Definiciones y Consideraciones Previas

En los siguientes apartados se detallan las características que debe cumplir el

contrato objeto de adjudicación.

Los requisitos enumerados en los siguientes apartados responden a la siguiente

tipología:







Pág. 11 de 243



Exp.093/16-AE

(√) Obligatorios: Requisitos de cumplimiento obligatorio. Las ofertas que

ofrezcan características que no se ajusten a estos requisitos no serán

tomadas en consideración en el presente procedimiento de licitación.

En algunos requisitos se utilizan abreviaturas para unidades de almacenamiento de

información cuyos valores son distintos si se refieren a almacenamiento en disco

(base decimal) o en memoria (base binaria).

1.2. Ámbito del proyecto

En este proyecto se contempla el desarrollo de un proyecto llave en mano que

contemple todos aquellos aspectos necesarios para la puesta en funcionamiento y

la operativa de los diferentes componentes descritos en el apartado 2.

Las actuaciones a abordar dentro del marco del Convenio de Colaboración, que

incluirán el hardware, el software y los servicios profesionales necesarios, son las

siguientes:

Flujos de movilidad turística

Hub de innovación

Puntos de acceso Wifi en edificios públicos

Gestión de aparcamientos

Gestión de flotas.

Control de afluencia.

Adecuación del CPD.

Sistema de comunicación multicanal para la recogida de información

de los visitantes y turistas.

Plataforma de Ciudad e integración de información.







Pág. 12 de 243



Exp.093/16-AE

Cuadro de mando integral.

Portal de datos abiertos.

Aplicaciones móviles para el ciudadano, autobuses y asistencia

técnica municipal.

1.3. Situación Actual

Este apartado describe brevemente la situación de partida tecnológica de los

Ayuntamientos.

1.3.1. Ayuntamiento de Almendralejo

SITIOS WEB

En la actualidad el Ayuntamiento tiene desarrollada una página web municipal

alojada en un hosting externo.

Página web municipal (http://www.almendralejo.es/): web de

información genérica del Ayuntamiento, con distintas secciones entre

las que se encuentran las descripciones del Ayuntamiento, Ciudadanía,

Concejalías y Servicios, etc. El dominio es propio, y la web está alojada

en la infraestructura de la Diputación de Badajoz accesible a través de

un enlace dedicado desde las instalaciones del Ayuntamiento.

SISTEMA DE GESTIÓN INTEGRAL

Sistema de Gestión Integral interna del Ayuntamiento que aglutina diversas

aplicaciones que proveen de contenido la parte pública de la Web Oficial del

Ayuntamiento, al mismo tiempo que facilita y dinamiza las tareas de gestión

internas de las diferentes áreas del Ayuntamiento. A modo de resumen, entre

otros, cuenta con los siguientes aplicativos:

Perfil del contratante.

Registro de Actividades realizadas en Urbanismo.

Registro y Gestión del Cementerio Municipal.







Pág. 13 de 243



Exp.093/16-AE

Gestión y contenido Ley de Transparencia.

Gestión de Policía Local (Agentes, Turnos, Incidencias, informes de

servicios, etc.)

Gestión del Voluntariado en Almendralejo.

Gestión de atenciones en los Servicios Sociales de Base

Gestión de los talleres y cursos de deportes, cultura y juventud así como

su inscripción electrónica.

Entorno de creación dinámica de formularios de participación ciudadana.

Servicios Varios, gestión de los servicios municipales (servicios del

parque de obras, infraestructuras eléctricas, carpintería, herrería,

jardines, etc.)

Gestión del tejido asociativo de Almendralejo.

Gestión de compras del Ayuntamiento de Almendralejo no sujetos a

procedimiento de contratación, con control de stock y proveedores.

Gestión de empleo para atención de peticiones de recursos humanos de

las empresas, principalmente de Almendralejo, creando bolsa de

currículos e interesados, facilitando la selección de la misma.

Esta aplicación ha sido desarrollada en un entorno de Intranet Municipal basado en

las tecnologías HTML5, CSS3, JavaScript, PHP por la Sección de Informática y

Nuevas Tecnologías de este Ayuntamiento.

ENTORNO DE COMUNICACIONES

A continuación, se describe el entorno tecnológico existente en el Ayuntamiento

de Almendralejo:

Los edificios principales del Ayuntamiento de Almendralejo están interconectados

mediante fibra óptica, a excepción de los Servicios Sociales de Base (en adelante

SSB), formando una estrella cuyo centro es el Palacio de Monsalud y cuyos

vértices son:







Pág. 14 de 243



Exp.093/16-AE

Conventual.

Centro Cívico.

Oficina Técnica.

Servicios Económicos – Policía Local.

Cabe mencionar por su relevancia los enlaces de fibra óptica existentes entre el

Palacio de Monsalud y Conventual y Centro Cívico con una extensión de

aproximadamente 0,9 Km.

Tanto SSB como los edificios no principales, salvo el nuevo Mercado Municipal de

las Mercedes (en adelante Mercado Municipal) que no tiene ningún tipo de

cobertura de red corporativa, se conectan a la Red de Comunicaciones Seguras del

Ayuntamiento mediante enlaces radio WiMax que proporcionan una cobertura en el

92% del área delimitada por el núcleo urbano.

Los enlaces radio WiMax cumplen su cometido básico de proporcionar servicios de

transporte de voz y datos a la mayoría de edificios periféricos.

Los edificios conectados mediante enlaces punto a punto disponen de un

ancho de banda de:

o Unos 25 Mbps en el caso de los edificios periféricos: Parque de

Obras, Matadero, Guardería Infantil, Polideportivo Tomás de la Hera,

Palacio del Vino y Albergue.

o Unos 50 Mbps en el caso de edificios que dan conectividad, a su vez,

a otros edificios: Silo, Servicios Sociales, Radio Comarca de Barros

(RCB, en adelante). Cabe mencionar aquí que el Palacio del Vino da

conectividad a la Guardería Infantil, al Polideportivo Tomás de la

Hera y, como veremos a continuación, a la Sede de San José de la

Policía Local; y sin embargo está conectado a sólo 25 Mbps.

Los edificios conectados mediante enlaces punto a multipunto disponen de

un ancho de banda asimétrico, en condiciones óptimas de cobertura, de 15

Mbps de bajada y 5 Mbps de subida: Sede de San José de la Policía Local,







Pág. 15 de 243



Exp.093/16-AE

Guardas Rurales, Polideportivo San Roque, Oficina de Información Juvenil,

Turismo y Cementerio.

El edificio central de la red de transporte WiMax actual es el Conventual. En

este edificio se concentran todas las comunicaciones WiMax y se encaminan

hacia el CPD del Palacio de Monsalud por un enlace de fibra óptica. Este

hecho hace que el Conventual sea un punto único de fallo, por lo que es

necesario conectar directamente el Palacio de Monsalud con otros edificios

de la Red WiMax, y hacerlo mediante fibra óptica, tanto por razones de

ancho de banda como por no ser viables nuevos radioenlaces.

El Ayuntamiento de Almendralejo cuenta con un circuito de videovigilancia para el

control de la circulación vial y el tráfico del área definida por varias vías de

circulación, que aprovecha la instalación de cableado de fibra óptica, que

transcurre por un recorrido de 1,4 Km, para interconectar todo el equipamiento

necesario con el centro de control de la Policía Local para crear una

infraestructura y canalización subterránea que permite disponer de un canal

redundante para la infraestructura WIMAX existente en la localidad.

ENTORNO TECNOLÓGICO

El centro neurálgico o CPD principal del Ayuntamiento de Almendralejo se ubica en

el Palacio de Monsalud, que alberga el área política y administrativa principal de la

ciudad.

El CPD cuenta con la siguiente infraestructura:

Sistema de almacenamiento de la información basado en la cabina de EMC

modelo CLARiiON CX4-120 con capacidad de 20 TB netos.

Sistemas de proceso compuestos por 10 servidores en chasis de Blade de

DELL, en los que se utilizan en mayor medida soluciones basadas en

software libre y en menor medida propietarias supeditadas a las

dependencias existentes con los aplicativos de gestión del Ayuntamiento

(Contabilidad, Recursos Humanos, Padrón de Habitantes, etc.)

Sistema de backup en cinta por medio de una librería Dell modelo TL2000.







Pág. 16 de 243



Exp.093/16-AE

La configuración de los servicios de integración de todos los elementos

anteriores de forma conjunta incluyendo conexiones de fibra, red, sistemas

operativos y procedimientos de uso habitual y manuales de los equipos

instalados.

Sistemas de alimentación ininterrumpida.

Sistemas de control de incendio.

Sistemas de control de acceso.

Sistemas de refrigeración a través de climatizador y redundante mediante

consolas split de aire acondicionado.

Sistemas de proceso y hardware de control de PBX sobre VOIP basado en

software libre.

Sistemas de concentración y centralización de la Infraestructura de

comunicaciones existente.

La arquitectura general de sistemas implantada se compone de una parte lógica y

una física. La parte lógica muestra la interconexión entre los sistemas de proceso

y almacenamiento de forma que pueda entenderse la foto final de la

infraestructura como una imagen de la capacidad de los servicios que se pueden

ofrecer con la solución implementada. La parte física muestra una foto real de la

ubicación de los distintos elementos instalados en el CPD del Ayuntamiento de

forma que pueda permitir localizar dichos elementos y permita percibir la

flexibilidad, capacidad de espacio y escalado de la plataforma.

El esquema del diseño lógico muestra “la red” instalada en base a capas de

almacenamiento, sistemas de proceso, aplicaciones, conectividad y acceso de los

usuarios tal y como se presenta a continuación:







Pág. 17 de 243



Exp.093/16-AE

Esquema

Lógico

Infraestructura Ayuntamiento Almendralejo

El Ayuntamiento dispone de varios racks de equipamiento. Son de importancia

para este proyecto los siguientes, que corresponden, uno para la cabina de

almacenamiento de EMC y otro para el chasis de Blade con los switches de red y

fibra, los servidores y la librería de cintas de DELL. A efectos prácticos

denominaremos al primero Rack de EMC y al segundo Rack de APC por ser los

fabricantes suministradores.

El esquema físico muestra la ubicación y forma de los elementos en el CPD y debe

facilitar la comprensión de la capacidad instalada y la posibilidad de crecimiento

futuro tal y como aparece en la siguiente imagen:

Esquema Físico Infraestructura Ayuntamiento Almendralejo







Pág. 18 de 243



Exp.093/16-AE

Adicionalmente se cuenta con un centro de control profesional y avanzado en la

Policía Local para la monitorización de los dispositivos de videovigilancia y un CPD

(centro de procesos de datos) que almacena la información captada por las mismas

cumpliendo con lo establecido en la LOPD y que sirve como CPD de respaldo para

el CPD central del Ayuntamiento de Almendralejo.

OTRO EQUIPAMIENTO

Actualmente, el Ayuntamiento de Almendralejo cuenta con una impresora de

tarjetas para las actuales tarjetas de biblioteca. Se trata de una Impresora de

tarjetas a color Pebble 4 Evolis.

ENTORNO VIRTUALIZADO

Actualmente el Ayuntamiento dispone de una infraestructura de servidores

virtualizados en una instalación con tecnología Vmware. La instalación virtual está

compuesta por

o 2 servidores Windows 2012 Server

o 2 servidores Windows 2003 Server

o 2 servidores Windows 2008 server

o 1 equipo con Windows XP aplicación Winsuite

o 17 servidores con diferentes versiones de linux (principalmente ubuntu

Server, debian).







Pág. 19 de 243



Exp.093/16-AE

Las máquinas virtuales están ubicadas en la cabina de almacenamiento del

Ayuntamiento.

1.3.2. Ayuntamiento de Badajoz

SITIOS WEB

PAGINA WEB AYUNTAMIENTO DE BADAJOZ.

http://www.aytobadajoz.es web de información municipal del Ayuntamiento, con

distintas secciones entre las que se encuentran las descripciones del

Ayuntamiento, Ciudadanía, Concejalías y Servicios, etc.

La página web esta soportada en un servidor externo dedicado Linux CentOs 6.4

con Parallels Panel, PHP versión 5.3.3, B.D. MySQL.

El gestor de contenidos es un desarrollo especifico y personalizado para el sitio

web del Ayuntamiento de Badajoz, basado en un gestor de contenidos bPanel 2.0,

desarrollado por la empresa Bittacora.

OTRAS APLICACIONES

ABISA

El Ayuntamiento de Badajoz ya ha publicado una aplicación que permite a los

ciudadanos reportar incidencias existentes en su vecindario (por ejemplo, farolas

rotas, coches abandonados, la falta de papeleras, etc). Estas incidencias

reportadas son transferidas directamente a los departamentos correspondientes

para que sean gestionadas. Esta aplicación se llama ABisa y está disponible:

Android:

https://play.google.com/store/apps/details?id=com.mk4droid.IMCity

_aBisa&hl=es9

Iphone:

https://itunes.apple.com/us/app/abisa/id950728926?l=es&ls=1&mt

=8

Web:







Pág. 20 de 243



Exp.093/16-AE

http://tramitesonline.aytobadajoz.es:8087/abisa/

El sistema ABISA tiene un desarrollo nativo para móviles Android y Apple. El

servidor web: Apache/2.2.29 (Win32) PHP/5.3.29 MYSQL/5.6.21(Win64).

La aplicación Web está montada sobre un gestor de contenidos Joomla versión

2.5.27 estable.

POPTEC

Para integración de la información de Turismo se trasladarán los datos al SISTEMA

DE INTELIGENCIA TURISTICA BADAJOZ-ELVAS (POPTEC). Este sistema está

actualmente en desarrollo y entrará en funcionamiento antes del comienzo de este

proyecto.

El proyecto POPTEC se desarrolla bajo la siguiente plataforma tecnológica:

Plataforma de integración de datos y business intelligence (Pentaho Community

Edition) soportado sobre la B.D. semántica MONGODB, con los siguientes módulos

y características de la versión Pentaho Community Edition:

Pentaho Data Integration.

Pentaho Business Analytics.

Pentaho Reporting.

Pentaho Dashboards.







Pág. 21 de 243



Exp.093/16-AE

ENTORNO DE COMUNICACIONES

La Red Corporativa del Ayuntamiento de Badajoz está formada por tres tipos de

conexiones de fibra óptica para todas sus sedes, siendo dos de ellas propiedad del

Ayuntamiento y una tercera contratada a la empresa de telecomunicaciones:

Red de fibra óptica propia con topología de estrella.

Red de fibra óptica propia con topología de anillo.

Red de fibra óptica alquilada.

Las sedes, según sean troncales, principales o normales y especiales, tienen

distintos tipos de conexiones para que en ningún caso puedan quedarse

incomunicadas:

Sedes troncales. Tienen tres tipos de conexiones:

o F.O. propia en estrella.

o F.O. propia en anillo.

o F.O. alquilada.

Sedes principales. Tiene dos tipos de conexiones:







Pág. 22 de 243



Exp.093/16-AE

o F.O. propia en anillo.

o F.O. alquilada.

Resto de sedes:

o F.O. alquilada.

SEGURIDAD Y REDUNDANCIA.

Todas las sedes troncales y principales están dotadas de un sistema de

redundancia o de seguridad, para que bajo ningún concepto queden sin conexión a

la Red Corporativa tanto de voz como de datos y garantizar el pleno acceso tanto

a la Red Corporativa como al exterior.

CRITERIOS DE DISEÑO DE LA RED CORPORATIVA.

Estos criterios que se han tenido en cuenta para el diseño de la Red Corporativa

son:

o Red transparente: La red es transparente de extremo a extremo, con

independencia del tipo de señales que se transmita (voz, datos, etc…).

Compatible con cualquier servicio de telecomunicaciones actual o futuro.

o Capacidad de la red: Tiene la capacidad suficiente para proporcionar unos

niveles óptimos de servicio.

o Capacidad de Migración o evolución: Capacidad de migrar a topologías más

avanzada que existan en el mercado.

o Capacidad de Ampliación: Estar dotada de la capacidad de ampliación de

forma que satisfaga las necesidades de crecimiento, con lo cual se debe de

emplear sistemas modulares y flexibles que permita el crecimiento de

nuevas sedes y nuevas tecnologías.

o Tecnología: Construida con la tecnología más probada y fiable y cumpliendo

los estándares y normativas nacionales e internacionales, para que permita

la conexión con otras redes públicas y privadas, lo que se denomina red

abierta.







Pág. 23 de 243



Exp.093/16-AE

o Fiabilidad: Garantiza la continuidad del servicio sin interrupciones, para lo

cual usa equipos redundantes y rutas para asegurar la continuidad del

servicio.

ELECTRONICA DE RED.

En cuanto a la electrónica de las redes de las distintas sedes, se utilizan switches

de Nivel 2 con PoE para que puedan gestionar la red de voz y datos (IP).

ACCESO A INTERNET

El acceso a internet es de un caudal de 100 Mbps simétricos a través de doble

acceso balanceado.

SEGURIDAD Y ACCESO A RED CORPORATIVA.

Para la seguridad, control de tráfico, monitorización y limitación del trafico hay

montados dos interfaces (funcionamiento en modo transparente) gigabit Ethernet,

para reconocimiento de firmas y protocolos, protección contra DDoS, gestión

remota, chequeo de antivirus, IPS, Web content, antispam, controlar políticas por

IP, sedes, grupos de usuarios y usuarios, gestión de ancho de banda gestión de

VPN’s etc .

ENTORNO TECNOLÓGICO

Gran parte de la infraestructura que da soporte a los servicios actuales del

Ayuntamiento de Badajoz así como otra infraestructura complementaria, que dan

soporte a servicios corporativos, tales como: Servicios de Autenticación, Bases de

Datos y Aplicativos, Servicios de Digitalización, herramientas de gestión, etc…

están soportados por la tecnología, software de base y plataformas físicas que se

detalla a continuación.

La comunicación entre centros y equipos está gestionada a través de

o 2 Switch FC HP StorageWorks 4/8 SAN Switch

o 1 Switch Eth HP ProCurve switch 2824

Dos Equipos HP-UX v11 con Base de Datos Oracle para HP-UX. Dichos nodos

están respaldados mediante la solución de Cluster HP ServiceGuard para

HP-UX.







Pág. 24 de 243



Exp.093/16-AE

Cabinas de Almacenamiento HP Eva 4000 para entorno de producción así

como HP P2100 para un proyecto de Digitalización.

Una serie de Servidores físicos HP Proliant DL de diversa generación.

o 3 Servidor HP ProLiant DL380 G5


o 2 Servidor HP ProLiant DL360 G4(2)




Los servidores están alojados en 3 cabinas Rack con su correspondiente

Switch KVM

1.4. Alcance

Desde los Ayuntamientos se han llevado a cabo una serie de iniciativas, destinadas

en su mayoría a acercar la información a los ciudadanos, proporcionar nuevos

canales de comunicación basados en las Tecnologías de la Información y las

Comunicaciones (TIC) y ofrecer herramientas que mejoren los servicios prestados.

Estas iniciativas están encabezadas a través de la Web municipal que sirve como

punto de acceso a los datos, noticias y servicios relevantes del municipio.

El alcance del presente proyecto incluye la ejecución de los servicios así como el

suministro e instalación del software y hardware necesario para la correcta

implantación y puesta en marcha de las distintas aplicaciones y plataformas

descritas en el apartado 2 del presente Pliego

El nuevo equipamiento requerirá de conectividad tanto a la red interna del

Ayuntamiento como a la externa para su acceso de forma pública y se integrará en

la arquitectura actual del Ayuntamiento.







Pág. 25 de 243



Exp.093/16-AE

El equipamiento objeto de suministro en el marco del presente Pliego se instalará

en la ubicación identificada por los Ayuntamientos de Almendralejo y Badajoz en

los plazos definidos.

Las soluciones que se oferten para los diferentes componentes incluirán todos

aquellos elementos y actuaciones que sean necesarios para el correcto

funcionamiento de los mismos y su integración con los sistemas existentes así

como la garantía in situ de los componentes suministrados e implantados.

El alcance del proyecto incluye los siguientes componentes que deberán ser

desarrollados y/o puestos en producción tras su suministro o desarrollo.

Componente 1. Adecuación CPD

Componente 2. Flujos de movilidad turística

Componente 3. Innovation hub

Componente 4. Portal de Transparencia y Datos Abiertos

Componente 5. Puntos de acceso Wifi

Componente 6. Aplicaciones móviles

o Componente 6.1. Entorno Web

o Componente 6.2. Lanzadera

o Componente 6.3. Autobuses

o Componente 6.4. Aplicación de atención ciudadana

o Componente 6.5. Aplicación móvil de guiado a aparcamientos

Componente 7. Gestión de flotas

Componente 8. Control de afluencia

Componente 9. Encuestas a Ciudadanía y visitantes

Componente 10. Plataforma “Smart”







Pág. 26 de 243



Exp.093/16-AE

Componente 11. Gestión de aparcamientos

Componente 12. Integración de datos en la plataforma







Pág. 27 de 243



Exp.093/16-AE

2. Requisitos técnicos

2.1. Requisitos generales

Todas las actuaciones desarrolladas en el marco del presente expediente de

licitación deberán cumplir los siguientes requerimientos generales:

2.1.1. Compatibilidad

2.1.1.1. (√) La solución ofertada debe garantizar la total compatibilidad

entre todos los elementos así como la compatibilidad con la

infraestructura existente en los CPDs de cada uno de los

Ayuntamientos que forman la agrupación.

2.1.1.2. (√) Toda integración, cambio o sustitución que resulten necesarios,

derivados de la no compatibilidad de los sistemas ofertados con los

existentes en cada uno de los Ayuntamientos será responsabilidad

del adjudicatario, quien deberá realizar todas las tareas oportunas

para conseguir el correcto funcionamiento del entorno final

requerido, sin que esto suponga ningún coste añadido para la

entidad ni para el organismo destinatario, sin pérdida de la

continuidad del servicio que se presta, y sin perjuicio de los plazos

establecidos en el apartado de condiciones de entrega e instalación

del presente Pliego.

2.1.1.3. (√) Deberá garantizarse la compatibilidad de todo componente

implantado y software desarrollado, en caso de actualización de

versión de los elementos de la arquitectura base que integre la

solución.







Pág. 28 de 243



Exp.093/16-AE

2.1.2. Hardware

2.1.2.1. (√) Todo el hardware suministrado por el adjudicatario deberá llevar

incorporado la última versión de software publicada por el

fabricante.

2.1.2.2. (√) Los elementos suministrados deberán ser conformes con la

normativa vigente de la Unión Europea y española en lo referente a

sus aspectos ergonómicos, de compatibilidad electromagnética y

de reducción de la radiación emitida.

2.1.2.3. (√) El suministro incluye todo el hardware, software, accesorios,

licencias, adaptadores, elementos de interconexión para integrarlos

con elementos existentes y materiales que sean necesarios para la

implantación de los elementos suministrados, así como para su

utilización y corrección de incidencias, hasta como mínimo el final

del periodo de garantía.

2.1.2.4. (√) Todo elemento suministrado debe ser totalmente compatible,

integrable y funcional con el resto del equipamiento suministrado.

2.1.2.5. (√) Los equipos a suministrar y entregar, incluidos sus

componentes, deberán ser nuevos. No será posible reutilizar ni

equipos, ni componentes reparados.

2.1.2.6. (√) Los elementos ofertados por el licitador deberán ser totalmente

compatibles e integrables con los elementos existentes en el

Ayuntamiento descritos en el apartado 1.3 “Situación Actual”, sin

requerir para ello ningún equipamiento, software, licencia o

prestación que no sea aportada por el adjudicatario; en su defecto,

el licitador incluirá en su oferta la sustitución de cualquier elemento

incompatible, por otro equivalente, hasta eliminar cualquier

incompatibilidad, de manera que las características, capacidades y

funcionalidades hardware y software de la infraestructura

resultante sean iguales o superiores a las existentes en la







Pág. 29 de 243



Exp.093/16-AE

actualidad, sin que esto suponga un aumento de la necesidad de

recursos (espacio, suministro eléctrico, etc.).

2.1.2.7. (√) El nuevo equipamiento requerirá de conectividad tanto a la red

interna del Ayuntamiento como a la externa para su acceso de

forma pública y se integrará en la arquitectura actual del

Ayuntamiento.

2.1.2.8. (√) Una vez concluida la instalación, el adjudicatario entregará un

conjunto de documentación en español que incluirá, al menos,

manuales de administración, operación y mantenimiento.

2.1.3. Licencias

2.1.3.1. (√) Todas las licencias ofertadas deberán tener una vigencia

temporal ilimitada o, en su defecto, de al menos CINCO (5) años. Así

mismo, todas las licencias deberán incluir un servicio de garantía

ajustado a los criterios y plazos descritos en el apartado 3.3

Requisitos de Garantía.

2.1.3.2. (√) Cualquier licencia ofertada concederá el derecho de instalar el

producto software objeto de licencia sobre el equipo informático o

infraestructura que Red.es determine, salvo indicación expresa

contraria o cuando no exista alternativa en el mercado que lo

permita.

2.1.3.3. (√) En el caso que alguna de las funcionalidades y prestaciones de

los elementos suministrados para el desarrollo de la Iniciativa Alba-

Smart 2020 necesitaran algún tipo de licencia para ser utilizadas

durante la implantación o la garantía, dicha licencia estará incluida

en la solución y será suministrada por el adjudicatario como parte

de la misma. Por tanto, estas licencias se proporcionarán sin coste

adicional, estarán vigentes hasta el final del plazo de garantía como

mínimo, y estarán ligadas a los criterios de garantía descritos en el

apartado 3.3 “Requisitos de garantía”.







Pág. 30 de 243



Exp.093/16-AE

2.1.3.4. (√) Cualquier licencia adicional a las disponibles que el

adjudicatario propusiese suministrar y poner en marcha como parte

de cualquiera de los trabajos contratados, deberá, una vez

aprobado su suministro y puesta en marcha por Red.es, poder ser

utilizada por los Ayuntamientos de Almendralejo y Badajoz sin más

limitaciones que las especificadas por el fabricante que la provea,

de modo que pueda ser utilizada en las evoluciones o ampliaciones

futuras de la solución implantada que fuesen precisas y sin coste

adicional alguno, por ningún concepto (infraestructura,

licenciamiento u otros) a Red.es ni a los Ayuntamientos. Asimismo,

en caso de que sean necesarias, la totalidad de licencias adicionales

suministradas por el adjudicatario deberán incluir el servicio de

garantía detallado en el apartado 3.3 “Requisitos de Garantía”.

2.1.4. Diseño

De cara a establecer un diseño común y homogéneo entre todos los componentes

se deberán cumplir los siguientes requisitos generales:

2.1.4.1. (√) Para definir el diseño se deberá realizar un análisis y

diagnóstico de las marcas actuales que posee el Ayuntamiento de

Almendralejo y Badajoz.

2.1.4.2. (√) Se estudiará los logotipos, colores, escudos e imagen

corporativa que actualmente poseen los municipios y se analizará

el grado de identificación corporativa que poseen.

2.1.4.3. (√) En base a las potencialidades identificadas en el diagnóstico, se

elaborará un Manual de Identidad Visual Corporativa que contendrá

la siguiente información:

Creación de un Logotipo Alba Smart, definición de

tamaños, áreas de reserva…

Variaciones del Logotipo teniendo en cuenta su uso en

web o en otros medios: versión en blanco y negro,







Pág. 31 de 243



Exp.093/16-AE

versión en escala de grises, negativo, posiciones no

horizontales, usos correctos e incorrectos…

Compatibilidad del Logotipo con los escudos

municipales.

Tipografía, usos permitidos y prohibidos, etc.

Tipografía compatibles con el logotipo, colores, etc

2.1.4.4. (√) El diseño de los logotipos tendrá en cuenta las obligaciones

FEDER.

2.1.5. Software

Cualquier pieza de software que se desarrolle y/o implante en el marco del

presente expediente de licitación deberá cumplir los siguientes

requerimientos.

2.1.5.1. (√) Deberá seguir la legislación vigente así como las

recomendaciones internacionales y estándares de usabilidad y

accesibilidad.

2.1.5.2. (√) El software que se desarrolle deberá basarse en fuentes

abiertas permitiendo su reutilización y distribución entre

Administraciones.

2.1.5.3. (√) Los desarrollos deberán realizarse con componentes

compatibles bien con el licenciamiento EUPL o bien con el

licenciamiento GPL. A tal efecto todas las entregas deberán tener

en cada uno de los ficheros las cabeceras necesarias para cumplir

los requisitos de este tipo de licencia. Adicionalmente con cada

entrega se aportará un listado de todos los módulos/componente

utilizados especificando el origen del módulo, la autoría del mismo y

el código de licencia que debe ser compatible con EUPL o con GPL.

Se debe especificar la relación entre los componentes del Sistema y

el tipo de relación (compilación, ejecución, etc.).







Pág. 32 de 243



Exp.093/16-AE

2.1.5.4. (√) Deberá hacer uso de lenguajes de desarrollo estándar de fácil

mantenimiento, ampliamente distribuido y multiplataforma.

2.1.5.5. (√) Los desarrollos en su parte servidora deberán desplegarse en

producción sobre un sistema operativo Linux de software libre. Se

deberá utilizar la última versión estable del sistema operativo que

tenga soporte.

2.1.5.6. (√) Se deberá garantizar su funcionamiento sobre equipos cliente

Windows/Linux. Los componentes y desarrollos destinados a

funcionar sobre entorno web soportarán los navegadores más

extendidos en el mercado (al menos Internet Explorer, Mozilla

Firefox y Google Chrome, en sus tres últimas versiones en el

momento de la entrega de los desarrollos) debiendo tener un grado

de accesibilidad AA en todos aquellos componentes que lo

soporten, por ello en todos los componentes que lo soporten se

seguirá una codificación XHTML Strict.

2.1.5.7. (√) Deberá ser compatible con el resto del software que forma

parte de la solución descrita en el presente Pliego, con las

plataformas de bases de datos y servidor de aplicaciones, así como

con el resto de aplicaciones y servicios que integran el resto de

componentes descritos en el presente Pliego.

2.1.5.8. (√) Se utilizará como sistema gestor de base de datos un sistema

de gestión de bases de datos multihilo, multiusuario y

multiplataforma.

2.1.5.9. (√) Para los gestores de contenidos y aplicaciones móviles, el

sistema gestor de base de datos debe ser el mismo para toda la

solución. Se creará un repositorio central de datos que contenga la

información de todas las aplicaciones, módulos y componentes.

2.1.5.10. (√) El servidor Web HTTP que se utilice deberá ser de código

abierto, modular, multiplataforma, extensible y que sea

ampliamente utilizado en plataformas Web.







Pág. 33 de 243



Exp.093/16-AE

2.1.5.11. (√) Se establecerán los medios para que toda la información

publicada en un componente y que sea susceptible de ser

georreferenciada, esté georreferenciada de origen de cara a

facilitar la interoperabilidad y reutilización de la misma por otros

componentes.

2.1.5.12. (√) El adjudicatario deberá garantizar en todo momento la calidad

de los productos desarrollados y su correcta entrega para la puesta

en el entorno de producción de la aplicación desarrollada. Para

asegurar la calidad de los productos desarrollados, Red.es se

reserva el derecho a realizar un proceso de certificación de los

productos entregados. En el caso de que en dicho proceso se

detectasen incidencias, el adjudicatario deberá asumir la resolución

de las mismas.

2.1.5.13. (√) Para la totalidad de tareas inherentes y propias de la fase de

desarrollo, el adjudicatario deberá disponer de un entorno de

desarrollo que será de su propiedad y responsabilidad, no debiendo

generar dicho entorno coste adicional alguno por ningún concepto

(infraestructura, licenciamiento u otros) a Red.es ni a los

Ayuntamientos. Como tal, no podrá incluir costes de licencias para

dicho entorno. Del mismo modo deberá disponer de un entorno de

preproducción con las mismas características del entorno de

producción en el cual se realizarán las pruebas con las mismas

condiciones descritas anteriormente para el entorno de desarrollo.

2.1.5.14. (√) Las subidas a producción se realizarán en el horario que Red.es

estime que menos impacto causa al proyecto.

2.1.5.15. (√) El licitador deberá entregar una guía de estilos y diseño de las

páginas web y de cada una de las aplicaciones a desarrollar en la

fecha que se designe en la reunión de arranque del proyecto, que

será validada por los Ayuntamientos de cara a implementar y

aplicar esta línea de diseño en todos los desarrollos. Esta guía de

estilos y diseño deberá seguir los requisitos de diseño definidos en

el apartado 2.1.4







Pág. 34 de 243



Exp.093/16-AE

2.1.5.16. (√) El tiempo de respuesta de cualquier petición web o de las

aplicaciones móviles no debe superar los 5 segundos, el tiempo de

respuesta se mide desde que se hace la petición HTTP hasta que se

obtiene la respuesta. Si dicha respuesta contuviese un fichero de

datos de un volumen elevado y requiriese un tiempo mayor de

procesado, no debería incluirse en dicha restricción, siempre que la

respuesta se haya producido en un tiempo inferior a 5 segundos a

pesar de que su procesado requiera de un tiempo mayor.

2.1.6. Autenticación

2.1.6.1. (√) Será un requisito el uso de un único sistema de autenticación

para las aplicaciones móviles y los portales, para ello se implantará

un sistema de directorio activo, LDAP o tecnología similar en las

instalaciones municipales. Será necesario mantener de forma

separada los usuarios de los Ayuntamientos de Almendralejo de los

de Badajoz. No será necesaria la integración con los servicios de

autenticación existentes de los Ayuntamientos.

2.1.6.2. (√) Se dispondrá de un conjunto de servicios web que permitan las

operaciones más habituales en este tipo de sistema entre las que

se encuentran: alta de usuario, baja de usuarios, autenticación de

usuarios, consulta de datos de usuarios, etc.

2.1.6.3. (√) El sistema permitirá definir una estructura de roles/permisos de

forma que el usuario pueda autenticarse en las

aplicaciones/portales que desee y tenga acceso a las

funcionalidades en las que tenga permiso en base a su perfil.

2.1.6.4. (√) El sistema tendrá configurado un conjunto de roles por defecto

(por ejemplo sistemas, administrador, editor, ciudadano) con

permisos definidos en base a las necesidades de estos usuarios,

permitirá crear nuevos roles y asignar nuevos permisos a los

nuevos roles o a los existentes.

2.1.6.5. (√) Los roles por defecto no podrán ser eliminados.







Pág. 35 de 243



Exp.093/16-AE

2.1.6.6. (√) La autenticación deberá permitir el registro automático o

moderado (supervisado) de usuarios (que deberán ser revisados

posteriormente antes de ser finalmente activados).

2.1.6.7. (√) El módulo de autenticación definido deberá integrarse con la

aplicación ABisa (en su aplicación y módulo web), definida en el

apartado 1.3, migrando los usuarios existentes al nuevo sistema.

Para ello se facilitará por parte del Ayuntamiento el código de las

aplicaciones y de la web para que se pueda realizar dicha

integración.

2.1.7. Aplicaciones móviles

2.1.7.1. (√) Deberá basar su desarrollo en estándares abiertos y de fácil

mantenimiento que permitan la creación, distribución y gestión de

contenidos que deberán ser accesibles y visualizados desde

dispositivos móviles que interpreten, al menos, las últimas

versiones de los 2 sistemas operativos móviles más utilizados 1

debiendo cumplir todos los requisitos necesarios para su

publicación en las principales tiendas de aplicaciones de estos

formatos.

1 Según datos del “Estudio de Apps Turísticas 2013” publicado por la Sociedad

Estatal para la Gestión de la Innovación y las Tecnologías Turísticas, S.A.

(SEGITTUR) (http://www.segittur.es/es/sala-de-prensa/detalle-documento/Estudio-

Apps-Tursticas-2013/ )







Pág. 36 de 243



Exp.093/16-AE

2.1.7.2. (√) Para aplicaciones móviles en plataforma Android la aplicación

será compatible con el sistema operativo SO 2.3 gingerbread en

adelante hasta la versión actualmente disponible, con resoluciones

hdpi, xhdpi y ldpi

2.1.7.3. (√) Para aplicaciones móviles en plataforma IOS será compatible

con iPhone, iPad e iPad Mini: sistemas operativos iOS8, iOS9 e

iOS10.

2.1.7.4. (√) Las aplicaciones móviles tendrán integrado un sistema gestor

de bases de datos soportada en los entornos de desarrollo de

movilidad para Android o IOS.

2.1.7.5. (√) La plataforma sobre la que se desarrolle las aplicaciones

móviles ofertadas deberá permitir escalar procesos en cualquier

momento y debe proveer al menos 100 procesos simultáneos

únicamente en la llamada de los servicios web de consulta, ya que

el resto de las acciones se ejecutarán directamente en cliente al

tratarse de desarrollos nativos.

2.1.7.6. (√) El diseño de navegación de la aplicación para Smartphone y

para Tablet será en base a carruseles u otro sistema alternativo

que propicien una navegación amigable e intuitiva, la aplicación

deberá caracterizarse por un manejo sencillo y una estética

agradable.

2.1.7.7. (√) La maquetación de la aplicación deberá seguir criterios de

elasticidad para permitir una adecuada adaptación al tamaño de la

ventana del dispositivo móvil, tanto en Smartphone como en Tablet,

permitiendo además una adecuada adaptación de contenidos ante

la rotación del dispositivo móvil.

2.1.7.8. (√) Las aplicaciones móviles tendrán que registrar la actividad de

navegación por parte de los usuarios registrados y no registrados,

siempre con su consentimiento explícito que deberán otorgar en el

momento de la descarga de la aplicación.







Pág. 37 de 243



Exp.093/16-AE

2.1.7.9. (√) El diseño gráfico de la aplicación deberá ser totalmente

corporativo a la vez que debe promocionar el aspecto turístico del

municipio, todo ello siguiendo la guía de estilo definida en el

apartado 2.1.4

2.1.7.10. (√) La aplicación debe presentar soporte para distintos dispositivos

móviles (tabletas y teléfonos móviles)

2.1.7.11. (√) La aplicación se conectará en el arranque con el servidor donde

comprobará si la información que presenta está actualizada,

actualizándola si fuera necesario a través de Servicios Web.

2.1.7.12. (√) Las aplicaciones móviles deberán almacenar o cachear en una

base de datos interna la información básica que se descargue.

2.1.7.13. (√) Las aplicaciones móviles deberán ofrecer un funcionamiento

básico sin necesidad de conexión a internet. Esto implica que

siempre podrán acceder a la información que tengan descargada en

los dispositivos.

2.1.7.14. (√) Desde la aplicación móvil los usuarios podrán compartir los

recursos en distintas redes sociales. Como mínimo

Facebook

Google +

Twitter

Instagram

2.1.7.15. (√) Los usuarios podrán recibir notificaciones de tipo “Push” en su

dispositivo, estas notificaciones podrán ser generadas

automáticamente o de forma manual por los administradores.

2.1.7.16. (√) Los datos de las aplicaciones móviles se almacenarán en el

mismo gestor de base de datos que el resto de componentes de

cara a que puedan ser capturados por la plataforma de ciudad.







Pág. 38 de 243



Exp.093/16-AE

2.1.7.17. Las aplicaciones móviles deben seguir las especificaciones de W3C-

buenas prácticas de usabilidad y accesibilidad

2.1.8. Capacitación

2.1.8.1. (√) El adjudicatario deberá realizar, para cada uno de los

componentes que incluyan el desarrollo y/o suministro de

elementos hardware y/o software descritos en este expediente, al

menos una sesión de capacitación para cada perfil. Esta debe cubrir

la utilización, administración y mantenimiento de dichos elementos

descritos en el presente Pliego tanto para el perfil de usuario como

para el perfil de administrador.

2.1.8.2. (√) Esta capacitación, deberá tener en cuenta los diferentes perfiles

de usuario, desarrollando capacitación específica y documentación

para cada uno de ellos con el fin de que los técnicos del

Ayuntamiento alcancen la mayor autonomía posible.

2.1.8.3. (√) Esta capacitación deberá garantizar que los usuarios

administradores puedan realizar todas las tareas de administración,

gestión y explotación de los diferentes sistemas instalados de modo

que sean autónomos en su uso, configuración y mantenimiento.

2.1.8.4. (√) Esta capacitación deberá garantizar que los técnicos

municipales puedan realizar todas las tareas en lo relativo a

utilización, administración y mantenimiento de los diferentes

desarrollos realizados.

2.1.8.5. (√) La duración mínima de la capacitación para cada uno de los

componentes y perfil será al menos de 4 horas.

2.1.8.6. (√) La sesión de capacitación se realizara previsiblemente en las

instalaciones de los Ayuntamientos, no obstante, a petición de

Red.es podrá requerirse que el licitador provea una ubicación en los

municipios para impartir la capacitación.







Pág. 39 de 243



Exp.093/16-AE

2.1.8.7. (√) Para el desarrollo de la capacitación exigida, el adjudicatario

desarrollará y pondrá a disposición de los asistentes a las jornadas

la documentación necesaria para el seguimiento de las mismas

(manuales de uso, información técnica necesaria etc.). Se deberán

generar los siguientes entregables:

Documentación de los procesos de actualización de la información.

Plan de formación.

Documentación de la formación.

Documentación del seguimiento de la formación: listas de

asistentes y cuestionario de evaluación de la formación.

2.1.8.8. (√) Para dar por realizada la capacitación, el adjudicatario deberá

entregar a Red.es un acta en la que se especifique los contenidos

impartidos, el material que se ha entregado y el listado de

asistentes así como la documentación que acredite la asistencia de

los mismos (acta de asistencia al curso firmada por los asistentes).

2.1.9. Estándares

2.1.9.1. (√) Los componentes descritos en los apartados siguientes estarán

basados en estándares no propietarios que aseguren la posibilidad

de desarrollos posteriores e integración con otros sistemas.

2.1.10. Identificación de equipos

2.1.10.1. (√) Los activos hardware objeto del contrato vendrán etiquetados

con el número de serie del fabricante, tanto en formato

alfanumérico como en formato de código de barras y/o código bidi.

En caso de que el número de serie no esté incluido de fábrica, no

contenga ambos formatos (alfanumérico y código de barras o bidi)

o no sea legible, dicho número de serie se incluirá por parte del







Pág. 40 de 243



Exp.093/16-AE

adjudicatario a través de un sistema de etiquetado que cumpla las

siguientes características:

Contenido:

o El número de serie del activo en formato alfanumérico.

o El número de serie del activo en formato código de barras y/o

bidi.

o Opcionalmente otro contenido (logos, etc.).

Material:

o Poliéster metalizado laminado.

o Resistente al desgaste.

o Resistente al agua.

o Resistente a los disolventes.

o Resistente a la luz.

2.1.10.2. (√) En el caso de aplicaciones software estas deberán mostrar los

Logotipos: de UE FEDER, y otros proporcionados por Red.es en una

zona visible de la misma.

2.1.10.3. (√) El equipamiento objeto del contrato deberá estar identificado

mediante grabado en superficies claramente visibles, por métodos

indelebles y no separables de las mismas. No se admite, sin

autorización previa de Red.es, el grabado sobre placa fijada

posteriormente por cualquier sistema al equipo. Los

procedimientos admitidos son pantografía, troquelado, grabación

térmica o grabación láser. Cualquier otro método necesitará la

previa aprobación por Red.es.

Se grabará la siguiente información:

Logotipos: de UE FEDER, y otros proporcionados por

Red.es.







Pág. 41 de 243



Exp.093/16-AE

Códigos de equipo: codificación proporcionada por

Red.es que contendrá letras y números.

2.1.10.4. (√) El adjudicatario proporcionará a Red.es imágenes y/o muestras

con la propuesta de ubicación y acabado del grabado de los

equipos, para su validación.

2.1.10.5. (√) En caso de sustitución del equipo por otro, en cumplimiento de

las condiciones de garantía, el nuevo equipo deberá ir grabado en

iguales condiciones que el equipo al que sustituye, logotipos y

mismos códigos de equipos.

2.1.11. Suministro e instalación de cartelería FEDER

A petición de Red.es, para el cumplimiento de la normativa

comunitaria en materia de publicidad de las actuaciones cofinanciadas

con fondos FEDER:

2.1.11.1. (√) El adjudicatario diseñará, producirá, suministrará e instalará, en

las ubicaciones donde se realicen los trabajos de instalación, salvo

que por la naturaleza del emplazamiento, Red.es indique lo

contrario, un cartel informativo con las siguientes características:

Contenido: Emblema de la Unión Europea, acompañado

de los logotipos institucionales y referencias que se

designen desde Red.es. A petición de Red.es, para la

validación de artes finales, podrá requerirse la entrega

de una muestra en la sede de la Entidad.

Dimensiones: 0,25 x 0,25 m

Material: Impreso en hexacromía sobre papel blanco de

170 gr. con laminado antirreflex en su cara anterior

montado sobre foam 10 mm, perfilado en aluminio

plata.







Pág. 42 de 243



Exp.093/16-AE

2.1.12. Aceptación de entregas

2.1.12.1. (√) El plazo de implantación de los elementos objeto de la licitación

una vez realizado el pedido por parte de Red.es, finaliza con la

aceptación por parte de Red.es de la entrega y puesta en marcha

de todos los elementos, prestaciones y documentación asociados.

El adjudicatario deberá tener en cuenta que los plazos incluyen la

corrección de disconformidades y errores que puedan detectarse

en los ciclos de pruebas.

2.1.13. Datos abiertos y reutilización de la información del sector público

2.1.13.1. () La información generada bajo el marco de ejecución de este

expediente de contratación estará disponible para publicación en

los diferentes portales de datos abiertos de los organismos públicos

competentes. Para ello el adjudicatario realizará las actuaciones

necesarias de modo que los principales conjuntos de datos

generados queden a disposición de los Ayuntamientos en un

formato de reutilización que al menos se podrá clasificar con tres

(3) estrellas según la clasificación de las cinco (5) estrellas del

Open Linked Data (formato estructurado no propietario como

pueda ser el formato CSV) .

2.1.14. Gestión del Proyecto

2.1.14.1. () El adjudicatario designará un Jefe de Proyecto, en dedicación

exclusiva, que será el interlocutor principal con Red.es durante la

ejecución del proyecto.

2.1.14.2. () El Jefe de Proyecto realizará un seguimiento continuo de la

evolución del proyecto y asistirá junto con los técnicos que se

estime conveniente a las reuniones de seguimiento y revisiones

técnicas que convoque Red.es en la sede y con la periodicidad que

este designe.







Pág. 43 de 243



Exp.093/16-AE

2.1.14.3. () Red.es se reserva el derecho a solicitar el cambio de

interlocutor en cualquier momento de la ejecución del proyecto,

siendo responsabilidad del adjudicatario la presentación de un

sustituto en un plazo no superior a una semana. Si durante la

ejecución del contrato, la empresa adjudicataria propusiera el

cambio del Jefe de Proyecto, esta circunstancia ha de ser

comunicada al Director Técnico de Red.es con una antelación de 15

días.

2.1.14.4. () El adjudicatario deberá adecuar su actuación en todo momento

a la metodología de gestión de proyectos que determine el Director

Técnico de Red.es. El adjudicatario se compromete a generar toda

la documentación que Red.es solicite para el seguimiento de los

trabajos realizados, de acuerdo con los criterios que establezca en

cada caso el Director Técnico de Red.es. Toda documentación

generada por el adjudicatario en ejecución del contrato será

propiedad exclusiva de Red.es en los términos expresados en el

apartado 3.2 del Pliego de Condiciones Particulares.

2.1.15. Obligación de información y documentación

2.1.15.1. () Durante la ejecución de los trabajos objeto del Contrato, el

adjudicatario se compromete, en todo momento, a facilitar a los

responsables designados por Red.es la información y

documentación que estos soliciten para disponer de un pleno

conocimiento de las circunstancias en que se desarrollan los

trabajos, así como de los eventuales problemas que puedan

plantearse y de las tecnologías, métodos y herramientas utilizados

para resolverlos. Asimismo, el adjudicatario se compromete, en

todo momento, a cumplir los procedimientos establecidos por

Red.es.

2.1.15.2. () En este sentido, el adjudicatario deberá informar a la persona a

cargo del proyecto, con la periodicidad necesaria, sobre distintos







Pág. 44 de 243



Exp.093/16-AE

aspectos del funcionamiento y la calidad de las actuaciones

realizadas.

2.1.15.3. () Como parte de las tareas objeto del Contrato, el adjudicatario se

compromete a generar la documentación de los trabajos realizados,

de acuerdo con los criterios que establezca en cada caso la persona

a cargo del proyecto.

2.1.15.4. () Toda la documentación generada por el adjudicatario en

ejecución del Contrato será propiedad exclusiva de Red.es sin que

el contratista pueda conservarla, ni obtener copia de la misma o

facilitarla a terceros sin la expresa autorización por escrito de la

persona a cargo del proyecto, que la concederá, en su caso, previa

petición formal del contratista con expresión del fin.

2.1.15.5. () Salvo indicación expresa en contrario, las especificaciones,

informes, diagramas, planos, dibujos y cualquier otro documento

relativo al objeto del Contrato serán aportados en castellano,

cualquiera que sea el soporte y/o formato utilizado para la

transmisión de información.

2.1.15.6. () La documentación entregada seguirá el procedimiento de

gestión de la documentación de Red.es. A petición de Red.es el

adjudicatario redactará las actas de las reuniones de seguimiento

del Proyecto mantenidas con Red.es, enviándolas para su validación

como máximo 4 días después de las mismas.

2.1.16. Documentación y cierre del proyecto

2.1.16.1. () El adjudicatario deberá enviar regularmente durante la

ejecución del proyecto en la frecuencia especificada por Red.es, un

fichero de seguimiento cuyo formato será definido por Red.es, en el

que quedará registrado, al menos, el histórico de la planificación de

las entregas, la fecha real de entrega e instalación de los diferentes

elementos.







Pág. 45 de 243



Exp.093/16-AE

2.1.16.2. () Toda la documentación del proyecto deberá ser entregada en

papel y soporte digital. Red.es definirá los formatos (PDF, HTML,

etc.) y procedimientos de entrega de la documentación. Esta

documentación no podrá contener ningún tipo de rectificación o

tachón, siendo esto motivo suficiente para su devolución y no

contabilizando como entregada hasta que no se reciba la

documentación correcta. La documentación no podrá ser elaborada

a mano, con la única excepción de los datos que deban ser

recabados en el momento de la entrega del equipamiento (datos del

firmante del documento, etc…).

2.1.16.3. () Adicionalmente, si Red.es lo considera oportuno, se entregará

un CD/DVD/USB o dispositivo de almacenamiento equivalente con

la recopilación de toda la información final de proyecto, incluyendo

además cualquier otra información relacionada con el proyecto

como por ejemplo actas de reuniones, especificaciones concretas…

2.1.17. Medidas de seguridad y cumplimiento de normativa

2.1.17.1. () El adjudicatario deberá satisfacer toda la normativa de obligado

cumplimiento asociada a cada una de las actuaciones a desarrollar.

2.1.17.2. () Todas las licencias, permisos, elementos de seguridad y riesgo

correrán a cargo del adjudicatario, que deberá disponer de todas las

autorizaciones necesarias para la implantación de los diferentes

elementos objeto de la licitación.

2.1.17.3. (√) El licitador deberá garantizar la seguridad e integridad de los

equipos modificando todas las contraseñas por defecto de todos los

elementos que se instalen, se redactará un documento donde se

incluirá un registro de los dispositivos, sus usuarios y contraseñas.

2.1.17.4. (√) El licitador deberá realizar un diseño de la solución, la red y los

sistemas fortificando la seguridad mediante los medios necesarios

(por ejemplo configuración de ACL, segmentación de redes, VPNs,

etc) de cara a minimizar el riesgo de penetración en la misma.







Pág. 46 de 243



Exp.093/16-AE

2.1.17.5. () El licitador deberá ejecutar un test de penetración sobre la

solución implantada realizando pruebas ofensivas contra los

mecanismos de defensa existentes en el entorno analizado. A partir

de este análisis redactará un informe con los resultados y las

vulnerabilidades detectadas, corrigiendo posteriormente todas

aquellas que se encuentren en su ámbito de actuación.

2.1.18. Seguimiento del proyecto.

2.1.18.1. () El adjudicatario deberá habilitar un gestor documental con

acceso vía web para facilitar la gestión de toda la documentación

del proyecto.

2.1.18.2. () El licitador deberá habilitar un gestor de incidencias software

con acceso vía web que permita hacer una comunicación y

seguimiento de las incidencias en los componentes software

desarrollados en el marco del presente procedimiento, durante las

fases de desarrollo y prueba antes de su puesta en producción.

2.2. Componente 1. Adecuación CPD

El objeto de este componente para el Ayuntamiento de Badajoz, es la

transformación, renovación y consolidación del entorno actual en un nuevo

entorno de virtualización para la plataforma x86 y así como la evolución y

renovación tecnológica para la plataforma IA64 que actualmente mantiene el

Servicio de Gestión de Bases de Datos Oracle. Adicionalmente para Almendralejo

se busca suministrar un entorno de similares características de forma que pueda

ser utilizado como entorno redundante para la solución objeto del presente

concurso. De esta forma los requisitos técnicos mínimos son los siguientes.

2.2.1. Componente 1.1: Sistema de almacenamiento de altas prestaciones

El Componente 1.1 describe las características mínimas de un Sistema de

Almacenamiento de altas prestaciones y altamente escalable. Las características







Pág. 47 de 243



Exp.093/16-AE

técnicas mínimas requeridas para este Componente se describen a continuación,

diferenciando entre los requerimientos mínimos de los equipos a implantar en cada

uno de los dos Ayuntamientos beneficiarios de las actuaciones:

REQUISITOS DEL COMPONENTE 1.1: SISTEMA DE ALMACENAMIENTO DE ALTAS PRESTACIONES

Número de unidades:

Badajoz: 1

Almendralejo: 1

Capacidad

Badajoz:

Nivel 0: 20,5 TiB netos sobre al menos 24 discos SAS de 1,2 TB en RAID-5.

Nivel 1: 136 TiB netos sobre al menos 48 discos SAS en RAID-6

Almendralejo:

Mínimo de 32 TiB netos sobre al menos 36 discos

SAS de 1,2 TB a 10K en RAID-5.

Requisitos Comunes

Para cada nivel, la tecnología, formato y tamaño de disco que se seleccione debe ser homogéneo para la totalidad del espacio ofertado.

Para el cálculo de la capacidad neta requerida no se incluirán spares. Adicionalmente a las capacidades requeridas, ha de ofertarse spare suficiente para la reconstrucción de, al menos, un disco de cada tipo ofertado.

Sistemas Operativos soportados

Windows Server 2008/2012







Pág. 48 de 243



Exp.093/16-AE


Solaris / HP-UX / IBM-AX

VMware / XenServer / MS Hyper-V

Red Hat EL / SuSE Linux / Oracle Linux

Controladoras

El sistema de almacenamiento ha de incluir 2 (dos) controladoras.

El sistema debe ser capaz de soportar la ampliación del sistema de almacenamiento hasta un total de 4 controladoras.

Las dos controladoras han de estar activas y serán completamente simétricas (quedan excluidas expresamente sistemas de tipo ALUA (Asymetric Logic Unit Access).

La caché mínima total ha de ser 64 GB, distribuida equitativamente entre las 2 controladoras. No se incluirán los discos SSD (Solid State Drives). Se excluye explícitamente para el cómputo de caché cualquier extensión de caché sobre discos SSD o similar.

El sistema de almacenamiento ha de tener integrado respaldo por baterías o mecanismo de persistencia equivalente, que evitará la perdida de información ante caídas de tensión.

Puertos El sistema de almacenamiento ha de incluir, como

mínimo, 4 puertos de 16 Gb Fibre Channel con todos los transceptores y cableado incluidos.

Protección RAID

El sistema ha de incluir la funcionalidad de protección de datos mediante redundancia RAID, con las siguientes características:

Soporte para RAID 10 con espejo simple (1+1) para ambos Ayuntamientos, espejo doble







Pág. 49 de 243



Exp.093/16-AE


(1+2) y espejo triple (1+3) únicamente para Badajoz

Soporte para RAID 50 con distribuciones 3:1, 4:1, 5:1, 6:1, 7:1 y 8:1

Soporte para RAID 60 con distribuciones 4:2, 6:2, 8:2, 10:2 y 14:2

El RAID 10 ha de ser hardware. Queda excluido cualquier sistema de almacenamiento que implemente RAID 10 como funcionalidad software.

El cálculo de la paridad de los RAID 50 y RAID 60 se ha de realizar por hardware especializado, descargando de esta tarea a los procesadores principales de las controladoras.

Características

El sistema debe poder soportar 576 discos como mínimo.

Conectividad a los discos SAS a 12 Gbps o superior.

Debe permitir la reparación y/o remplazo de cualquier componente Hardware o Software de forma no disruptiva.

Posibilidad de de-duplicación en línea. Queda excluido cualquier sistema de almacenamiento que implemente de-duplicación diferida o post-proceso.

Posibilidad de cambiar en caliente el tipo de RAID y el tipo de disco de un LUN.

Funcionalidades software

Todas las capacidades solicitadas deberán ser proporcionadas por el propio sistema de almacenamiento de manera directa, sin requerir ampliación de hardware o software posterior. En particular, las siguientes funcionalidades han de estar disponibles en el sistema ofertado, incluyendo las







Pág. 50 de 243



Exp.093/16-AE


licencias en caso de ser necesario y para toda la capacidad ofertada (Niveles 0 y 1):

Detección y notificación automática de errores.

Soporte ANSI T10 DIF (Data Integrity Field) para asegurar la integridad de los datos dentro de la cabina.

Thin Provisioning. El sistema deberá permitir sobre-aprovisionar LUNs superiores al espacio real ocupado, optimizando así los recursos de almacenamiento y evitando la existencia de espacio en disco no ocupado. Esta característica debe ser configurable por LUN.

Capacidad para realizar terceras copias basadas en snapshots y clones. Para cada LUN, el espacio de snapshots y de clones será configurable por el administrador y podrá ser sobre el mismo tipo de disco o sobre discos diferentes (por ejemplo, el espacio de snapshot de una LUN sobre discos SSD podrá definirse sobre discos SAS o NL).

El sistema de almacenamiento ha de soportar multi-path nativo de los sistemas operativos.

Deberá soportar la conexión de múltiples clusters de forma concurrente de los diferentes sistemas operativos soportados por la cabina.

Software de gestión que permita el movimiento online de la información entre dos LUNs dentro de la cabina de almacenamiento de forma no disruptiva para las aplicaciones.

El sistema deberá permitir recuperar espacio en los grupos de discos a medida que se eliminen máquinas virtuales VMware mediante la integración del Hypervisor con la cabina.

SW de gestión, administración y operación de cabina para capacidad ilimitada de







Pág. 51 de 243



Exp.093/16-AE


almacenamiento o, en su caso, para el máximo de capacidad bruta (TB brutos) direccionable por la cabina.

SW que permita ver el estado de los sistemas en tiempo real y recopilación de históricos tanto de estado de salud de los componentes de sistema, como de rendimiento y capacidad.

Licencias de monitorización a nivel de puerto y global y de obtención de estadísticas de rendimiento de la cabina directamente exportables para su explotación por herramientas ofimáticas comunes.

Funcionalidades de servicio

Todos los elementos activos han de estar redundados y ser reemplazables en caliente (incluyendo controladoras, memoria caché, ventiladores, fuentes de alimentación,…) que permitan la reparación y/o remplazo de cualquier componente Hardware o Software de forma no disruptiva.

La solución de almacenamiento no deberá tener punto único de fallo para ser admitida (Single Point Of Failure) en cualquiera de sus componentes internos.

Las actualizaciones de firmware se han de realizar en caliente.

En caso de parada de una de las controladoras, los WWN de los puertos FC de la controladora se han de activar en otra controladora con el fin de eliminar el impacto en el software de multipath de los servidores.

Garantía Garantía in situ (tal y como se describe en el

apartado 3.3) durante 5 años.







Pág. 52 de 243



Exp.093/16-AE


Condiciones de Suministro

Se deberá incluir en el suministro cualquier otro componente que sea estrictamente obligatorio para el funcionamiento normal del equipo, en función de la solución propuesta, y que no haya sido enumerado en esta lista de especificaciones técnicas.

Se ha de incluir un rack de 42U con las PDU´s, cables de alimentación y todos los elementos necesarios para el montaje y correcto funcionamiento del sistema de almacenamiento suministrado.

2.2.2. Componente 1.2: Chasis Blade

REQUISITOS DEL COMPONENTE 1.2: Chasis Blade

Numero de Chasis

Blade

Badajoz: 1

Almendralejo: 1

Chasis

Chasis blade para armario rack para servidores de 19”, compatible con los servidores blade solicitados en el presente documento. Se deberá indicar las RUs que ocupa, conexiones redundadas, ranuras de expansión, etc.

Altura máxima de 10U’s dentro del armario rack.

Capacidad de alojar simultáneamente en el mismo chasis los distintos tipos de servidores descritos en el presente Pliego de Prescripciones Técnicas (Componente 1.3 y Componente 1.7).







Pág. 53 de 243



Exp.093/16-AE


Conectividad

El chasis deberá venir equipado con los siguientes módulos:

2 módulos de conexión de red Ethernet virtualizado (se garantizará la independencia de las direcciones MAC con respecto a los servidores del chasis). Cada uno de ellos con:

Puertos downlink: al menos 16 puertos de 10Gb, cada uno de ellos virtualizable en 4 FlexNICs ó 3 FlexNICs y 1 iSCSI FlexHBA.

Puertos uplink: al menos 10 puertos 10Gb. Se deberá incorporar, al menos, 1 SFP+ SR de 10 Gbps y 2 SFPs RJ45 a 1 Gbps por módulo.

2 switches (o módulos de interconexión) FC 8Gbps con soporte NPIV. Cada uno de ellos con las siguientes características:

Puertos downlink: al menos una conexión directa con cada uno de los servidores instalados en el chasis

Puertos uplink: al menos 8 puertos con sus SFP a 8 Gbps para la interconexión con el sistema de almacenamiento (componente 1.1) y los cables fibra LC/LC OM4 de 5m necesarios.

Posibilidad de interconectar varios conmutadores SAN (conexión ISL) formando un único enlace lógico mediante varias conexiones físicas, gestión gráfica de los conmutadores de FC y monitorización del entorno SAN para detectar fácilmente potenciales problemas en el entorno SAN.

El número de elementos de conectividad (Ethernet y Fibre Channel (FC)) que deben venir montados en el chasis deberá garantizar la conectividad de todos los interfaces de los servidores especificados, la gestión de todos los elementos y dependerá de la configuración de conectividad que el







Pág. 54 de 243



Exp.093/16-AE


licitador incluya en su oferta de servidores.

El chasis deberá poder albergar tantos puertos y elementos de conmutación (Ethernet y Fibre Channel (FC)) como sean necesarios para garantizar la conectividad al exterior de todos los puertos (Ethernet y FC) ofertados para los servidores Blade del presente Pliego de Prescripciones Técnicas.

Los componentes ofertados deberán incluir todos los GBICs necesarios.

Los elementos de conmutación (Ethernet y FC) deben de estar integrados en el chasis.

Bahías

Frontal: como mínimo deberá permitir albergar 16 servidores x86 de 2 vías con las características de los solicitados en el presente documento (Componente 1.3). Paneles Dummy para todos los slots no usados.

Posterior: como mínimo deberá permitir albergar 8 elementos de conmutación (Ethernet, FC, FCoE, Infiniband, SAS) con las características de los solicitados en este apartado del presente pliego.

Gestión de Chasis Blade

Módulo redundante que proporcione control remoto (vía IP) para todos los componentes del chasis y los servidores Blade para la gestión y disponibilidad de los sistemas. Se deberá incluir el correspondiente software de gestión, compatible con el equipamiento y las plataformas de gestión operativas en el CPD distribuido.

1 x RJ45 10/100/1000.

El módulo de gestión (y SW asociado) deberá venir activado y totalmente operativo.

Indicadores luminosos (o pantalla LCD) de actividad y estado.







Pág. 55 de 243



Exp.093/16-AE


Alimentación y ventilación

Ventiladores y fuentes de alimentación redundantes e intercambiables en caliente (hot-plug) que garanticen la correcta alimentación y ventilación del chasis.

El chasis debe venir dotado de todos los ventiladores y fuentes de alimentación (redundancia n+n) necesarios para su correcto funcionamiento en el caso de que todos sus slots estuviesen ocupados por servidores Blade con las características de los descritos en el presente pliego (considerando el caso más desfavorable posible).

Las fuentes de alimentación han de tener una eficiencia superior al 94%.

Garantía Garantía in situ de acuerdo al apartado 3.3, durante 5 años

Otras características Acceso físico a los medios a través de unidad CD-DVD,

puerto USB, ranura SD o similares.

2.2.3. Componente 1.3: Servidor Blade de 2 vías de alta capacidad de

arquitectura x86

REQUISITOS DEL COMPONENTE 1.3: Servidor Blade de 2 vías de alta capacidad de arquitectura x86

Número de

servidores

Badajoz: 2

Almendralejo: 2







Pág. 56 de 243



Exp.093/16-AE


Tipo de Servidor Servidor Blade, compatible con el chasis Blade solicitado en

el Componente 1.2. Se deberá indicar el número de slots/altura que ocupa dentro del chasis.

Procesador

Procesadores x86/64 bits con tecnología integrada que favorezca la virtualización (facilite el cambio de contexto de máquinas virtuales y optimice procesos de I/O) y proporcione un sistema de ahorro de consumo de energía. Se deberá proveer siempre procesadores de la generación más nueva existente en el mercado en el momento de realizar el pedido del equipamiento.

2 (dos) procesadores con un mínimo de 10 núcleos por procesador, que permita la ejecución concurrente de un mínimo de 40 threads. La arquitectura de los procesadores debe permitir la conexión directa entre procesadores e integrar el controlador de memoria en el chip del procesador.

El conjunto de procesadores debe tener una puntuación igual o superior a 890 SPECint_rate2006, columna "Base", en el programa para el cálculo de rendimiento SPEC CPU2006.

Tarjeta de gestión y monitorización remota

Debe proporcionarse funcionalidad para gestionar el equipo individualmente y acceso a interfaz de gestión específica y no compartida con las interfaces con redirección gráfica y que permita obtener valores tales como temperatura, estado de los ventiladores, estado de las tensiones, consumo en W que está teniendo el servidor, y además, funcionalidad para el encendido y apagado remoto.

Se deberán especificar todas las funcionalidades activas incluidas, como KVM virtual, apagado/encendido remoto, acceso remoto al estado y logs del servidor, carga de imágenes del Sistema Operativo, etc.

La tarjeta de gestión (y sw asociado) deberá venir activada y







Pág. 57 de 243



Exp.093/16-AE


totalmente operativa.

Memoria RAM

Mínimo 256GB en DIMMS con tecnología DDR4 (en módulos de memoria de la misma capacidad) – tecnología advanced ECC support o superior.

Frecuencia mínima 2133 MHz

Se deberá justificar técnicamente la configuración de memoria (en cuanto a distribución, bancos, DIMMS) ofertada en base a la arquitectura del procesador y la tecnología de memoria presentadas, teniendo en cuenta que el uso de estos servidores puede ser tanto para propósito general como para entornos de virtualización.

Conectividad

Debe incluir una tarjeta de red Ethernet con al menos 2 puertos autosensing 10Gb/1Gb, con soporte TCP/IP offload engine.

Debe incluir un mínimo de 2 puertos FC con tecnología mínima de 8 Gb/s.

Se deberá indicar el tipo y número de ranuras de expansión del servidor. Al menos debe permitir la instalación de 2 tarjetas con soporte a x16 PCIe 3.0.

Los servidores deberán poder soportar la incorporación de tarjetas PCIe aceleradoras de IO (PCIe SSD).

Otras características 1 Puerto USB 3.0

Garantía Garantía in situ de acuerdo al apartado 3.3, durante 5 años.

Compatibilidad Soporte de los siguientes Sistemas Operativos: Windows

Server 2008 y 2012, Linux (RedHat y Suse).







Pág. 58 de 243



Exp.093/16-AE


Soporte de los siguientes sistemas de virtualización: VMware, Citrix, Microsoft Hyper-V.

Soporte Boot-from-SAN con el sistema de almacenamiento ofertado como Componente 1.1.

2.2.4. Componente 1.4: Servidor Blade de 1 vía para backup de

arquitectura x86

REQUISITOS DEL COMPONENTE 1.4:

Servidor Blade de 1 vía para backup de arquitectura x86

Número de

servidores Almendralejo: 1

Tipo de Servidor

Servidor Blade, compatible con el chasis Blade solicitado en

el Componente 3. Se deberá indicar el número de

slots/altura que ocupa dentro del chasis.

Procesador

Procesadores x86/64 bits y que optimice procesos de I/O) y

proporcione un sistema de ahorro de consumo de energía.

Se deberá proveer siempre procesadores de la generación

más nueva existente en el mercado en el momento de







Pág. 59 de 243



Exp.093/16-AE



realizar el pedido del equipamiento.

1 (un) procesador con un mínimo de 12 núcleos por

procesador, que tenga un mínimo de 2,4GHz de frecuencia

base. La arquitectura de los procesadores debe permitir la

conexión directa entre procesadores e integrar el

controlador de memoria en el chip del procesador.

El conjunto de procesadores debe tener una puntuación

igual o superior a 400 SPECint_rate2006, columna "Base",

en el programa para el cálculo de rendimiento SPEC

CPU2006.

Almacenamiento

interno

Mínimo de 2 (dos) discos internos cada uno con 450GB SAS

a 10K para la instalación del sistema operativo.

La controladora tiene que soportar Raid1.

Tarjeta de gestión y

monitorización

remota

Debe proporcionarse funcionalidad para gestionar el equipo

individualmente y acceso a interfaz de gestión específica y

no compartida con las interfaces con redirección gráfica y

que permita obtener valores tales como temperatura,







Pág. 60 de 243



Exp.093/16-AE



estado de los ventiladores, estado de las tensiones,

consumo en W que está teniendo el servidor, y además,

funcionalidad para el encendido y apagado remoto.

Se deberán especificar todas las funcionalidades activas

incluidas, como KVM virtual, apagado/encendido remoto,

acceso remoto al estado y logs del servidor, carga de

imágenes del Sistema Operativo, etc.

La tarjeta de gestión (y sw asociado) deberá venir activada

y totalmente operativa.

Memoria RAM

Mínimo 128GB en DIMMS con tecnología DDR4 (en módulos

de memoria de la misma capacidad) – tecnología advanced

ECC support o superior.

Frecuencia mínima 2133 MHz

Se deberá justificar técnicamente la configuración de

memoria (en cuanto a distribución, bancos, DIMMS) ofertada

en base a la arquitectura del procesador y la tecnología de

memoria presentadas, teniendo en cuenta que el uso de

estos servidores puede ser tanto para propósito general







Pág. 61 de 243



Exp.093/16-AE



como para entornos de virtualización.

Conectividad

Debe incluir una tarjeta de red Ethernet con al menos 2

puertos autosensing 10Gb/1Gb, con soporte TCP/IP offload

engine.

Debe incluir un mínimo de 2 puertos FC con tecnología

mínima de 8 Gb/s.

Se deberá indicar el tipo y número de ranuras de expansión

del servidor. Al menos debe de permitir la instalación de 2

tarjetas con soporte a x16 PCIe 3.0.

Los servidores deberán poder soportar la incorporación de

tarjetas PCIe aceleradoras de IO (PCIe SSD).

Otras características 1 Puerto USB 3.0

Garantía Garantía in situ de acuerdo al apartado 3.3, durante 5 años.

Compatibilidad Soporte de los siguientes Sistemas Operativos: Windows

Server 2008 y 2012, Linux (RedHat y Suse).







Pág. 62 de 243



Exp.093/16-AE



Soporte de los siguientes sistemas de virtualización:

VMware, Citrix, Microsoft Hyper-V.

Soporte Boot-from-SAN con el sistema de almacenamiento

ofertado como Componente 1.1.

2.2.5. Componente 1.5: Conmutadores de Red Servidores

REQUISITOS DEL COMPONENTE 1.5: Conmutadores de red con backplane apilable

Número de Switches apilables

Badajoz: 2

Almendralejo: 2

Número de puertos mínimo 10/100/1000 BaseT (cada Switch)

24 puertos

Número de slots SFP+ 10 Gigabit (cada Switch)

Nº mínimo de slots SFP+ (10 Gbit): 2.

Se incluirá el GBIC y cableado correspondiente o el cable DAC de conexión de al menos 3m.

Número de slots SFP 1000SX (cada Switch)

Nº mínimo de slots SFP 1000SX (Gbit): 4.

Apilamiento

Backplane apilable, con puertos dedicados para el

apilamiento que no consuman puertos de datos. Una vez creada una pila de equipos, el conjunto de equipos se comportará como una única entidad a todos los efectos,

tanto a nivel de gestión, nivel L2 y nivel L3.

Se suministrarán como mínimo 2 puertos dedicados a







Pág. 63 de 243



Exp.093/16-AE


stacking independientes de los puertos de servicio y datos ofertados. Incluyendo para ello los módulos de apilamiento necesarios que en ningún caso afectarán al número de

puertos de uplink ofertados.

Se incluirán los cables necesarios para el apilamiento. El 50% de los cables de stacking compatibles con los equipos ofertados tendrá una longitud de al menos 0,5 m. El otro

50% restante tendrá una longitud de al menos 1 m.

Requisitos Rendimiento

(cada Switch)

Capacidad de conmutación: 128Gbps

Throughput (En un entorno de prueba Fully Meshed y

calculado con paquetes de 64 bytes de longitud): 95Mpps

Ancho de banda agregado de apilamiento: 48Gbps Para

este cálculo, se tendrá en cuenta una pila con topología de anillo y el número de elementos máximo de la pila. El ancho de banda corresponde a la suma del ancho de banda de las conexiones con los 2 equipos vecinos en la pila de forma

simultánea.

La metodología seguida para las pruebas que garantizan los

datos de rendimiento mínimos debe seguir los estándares y

definiciones reflejados en los RFCs 2889 y 2285.

Funcionalidades

(cada Switch)

Nivel 3(L3) de gestión de tráfico. Routing IPv4/IPv6

estático y dinámico básico (RIPv1 y RIPv2)

8 colas por puerto

Soporte QoS y priorización de tráfico: 802.1p, ToS, DSCP.

Soporte para multicast.

Soporte para VLAN’s.

Soporte IPv4/IPv6.

Soporte SNMPv1/v2c/v3.







Pág. 64 de 243



Exp.093/16-AE


Soporte para agregación de enlaces.

Soporte port mirroring/port spanning.

Control de tormentas de broadcast.

Acceso remoto para gestión HTTPS SSHv2

Acceso local para gestión por puerto de consola.

Mecanismos de autenticación: RADIUS, TACACS+.

Soporte de ACLs.

Soporte para Jumbo Frames.

Apilables para la gestión.

Soporte STP, RSTP y MSTP como mecanismos de protección de bucles y gestión de la redundancia de

caminos.

Soporte de un protocolo para la asignación dinámica de

VLANs desde el core de la red al acceso.

Soporte de autenticación de usuarios:

o 802.1x

o Autenticación MAC

o Autenticación web

Soporte de múltiples usuarios autenticados por puerto

Soporte de protocolos de recolección de datos de tráfico IP:

sFlow y/o NetFlow.

Soporte RMON.

Mecanismos de seguridad:

o Protección DHCP para impedir la asignación de







Pág. 65 de 243



Exp.093/16-AE


direcciones IP desde servidores no autorizados

o Mecanismo de IP lockdown, que junto con la protección DHCP, bloquee el tráfico de clientes no

autorizados y prevenga el IP spoofing.

o Protección ARP

o Protección frente a BPDUs de protocolo STP y

funcionalidad “STP root guard”

Soporte OpenFlow. Soporte de un protocolo para el control

de flujos en el equipo de modo que permita desplazar el

plano de control de forma total o parcial para permitir despliegue de aplicaciones de red SDN. El equipo deberá poder integrarse con un controlador SDN y soportar OpenFlow v1.3.

Capacidad

(cada Switch)

Tabla de direcciones MAC con una capacidad mínima de 16000 entradas (Según definición de los RFCs 2889 y

2285)

Tabla de rutas con una capacidad mínima de 2048

entradas(IPv4) / 256 entradas(IPv6)

Garantía

(cada Switch)

Garantía in situ de acuerdo al apartado 3.3 durante 5 años.

Ayuntamiento de Almendralejo:

Los requisitos técnicos mínimos de los equipos a suministrar en el

Ayuntamiento de Almendralejo son los siguientes.







Pág. 66 de 243



Exp.093/16-AE

2.2.6. Componente 1.6: Conmutadores de Red Usuarios


Conmutadores de red

Número de Switches Almendralejo: 3

Número de puertos

mínimo 10/100/1000

BaseT (cada Switch)

48 puertos

Número de slots SFP

(cada Switch)

4 slots

Requisitos

Rendimiento

(cada Switch)

Latencia: < 5 microsegundos

Throughput: 77,4 Mpps

Capacidad de conmutación: 104 Gbps

Capacidad PoE: 370 W PoE+

Funcionalidades

(cada Switch)

Nivel 3(L3) de gestión de tráfico. Routing IPv4/IPv6

estático.

8 colas por puerto

Soporte QoS y priorización de tráfico: 802.1p, ToS, DSCP.







Pág. 67 de 243



Exp.093/16-AE


Conmutadores de red

Soporte para multicast.

Soporte para VLAN’s.

Soporte IPv4/IPv6.

Soporte SNMPv1/v2c/v3.

Soporte para agregación de enlaces.

Soporte port mirroring/port spanning.

Control de tormentas de broadcast.

Acceso remoto para gestión HTTPS, SSHv2.

Acceso local para gestión por puerto de consola.

Mecanismos de autenticación: RADIUS, TACACS+.

Soporte de ACLs.

Soporte para Jumbo Frames.

Apilables para la gestión.

Soporte STP, RSTP y MSTP como mecanismos de

protección de bucles y gestión de la redundancia de

caminos.







Pág. 68 de 243



Exp.093/16-AE


Conmutadores de red

Soporte de un protocolo para la asignación dinámica de

VLANs desde el core de la red al acceso.

Soporte de autenticación de usuarios:

o 802.1x

o Autenticación MAC

Soporte de múltiples usuarios autenticados por puerto

Soporte de protocolos de recolección de datos de tráfico IP:

sFlow y/o NetFlow.

Soporte RMON.

Mecanismos de seguridad:

o Protección ARP

o Protección frente a BPDUs de protocolo STP y

funcionalidad “STP root guard”

Capacidad

(cada Switch)

Tamaño tabla direcciones MAC: 16384







Pág. 69 de 243



Exp.093/16-AE


Conmutadores de red

Garantía

(cada Switch)

Garantía in situ de acuerdo al apartado 3.3 durante 5 años.

2.2.7. Componente 1.7: Licencia Windows Server 2016


Licencia Windows 2016 Server

Características

El adjudicatario suministrará software de sistema

operativo Windows 2016 Server.

Este software será instalado en un equipo virtualizado

que dará soporte a las aplicaciones de gestión del

Ayuntamiento de Almendralejo (Contabilidad, Padrón

Municipal de Habitantes, Gestión de Recursos Humanos,

I2ACronos, etc.) que únicamente soportan este sistema

operativo. La licencia es necesaria para poder integrar

estos servicios en el entorno virtualizado y proporcionar

los datos requeridos por la operativa de la plataforma de

ciudad licitada en el componente 10.







Pág. 70 de 243



Exp.093/16-AE


Licencia Windows 2016 Server

Garantía

Garantía de las licencias durante un mínimo de 2 años

incluyendo actualización de versiones.

2.2.8. Componente 1.8: Licencias para Virtualización

REQUISITOS DEL COMPONENTE 1.8: Licencias para Virtualización

Características

El adjudicatario suministrará software de virtualización, con sus correspondientes licencias, asociado a cada procesador de cada servidor de los

tipos descritos en el apartado 2.2 del presente pliego.

El software de virtualización incluirá licencia para un nodo de gestión virtual que permitirá gestionar la infraestructura virtual, compatible con el software

existente. Esta integración debe ser completa.

Debe disponer de gestión de memoria avanzada:

Posibilidad de hacer “over-provisioning” de memoria

virtual para maximizar la utilización de la memoria

reclamando la memoria no usada y haciendo

duplicación de páginas de memoria idénticas entre

múltiples máquinas virtuales. Posibilidad de usar







Pág. 71 de 243



Exp.093/16-AE


tecnología de compresión de memoria y swap a disco

de memoria. De esta forma la suma de RAM de las

máquinas virtuales puede ser superior a la cantidad de

memoria física del servidor.

El software de virtualización no impondrá ninguna

limitación de memoria en el servidor físico.

Debe proporcionar la opción arranque desde USB o

tarjeta Micro SD de un hipervisor o monitor de

máquinas virtuales, sin necesidad de disponer de

discos internos en el servidor físico.

El software de virtualización dispondrá, como mínimo,

de las siguientes funcionalidades:

Permitir la migración en caliente de máquinas virtuales y de sus discos virtuales, sin que suponga impacto en el servicio ofrecido tanto en lo que se refiere a fallos de hardware o sistema operativo.

El software de virtualización debe disponer de mecanismos de alta disponibilidad que reinicien las máquinas virtuales en otro servidor físico tras un fallo en el servidor físico que alojaba dichas Máquinas

Virtuales.

Soporte en una misma máquina a distintas particiones con posibilidad de carga de distintos sistemas

operativos sobre esas particiones.

Soporte de hasta 128 CPUs virtuales por máquina virtual para los sistemas operativos de servidor

soportados.







Pág. 72 de 243



Exp.093/16-AE


Capacidad de gestión de protección de antivirus y malware sin necesidad de integrar agentes dentro de

la máquina virtual.

Capacidad de ubicación de componentes esenciales en regiones de memoria fiables en dispositivos hardware.

Capacidad de ejecución de cargas de trabajo Hadoop con la incorporación de extensiones big data que permiten el despliegue, ejecución y gestión de clusters

Hadoop.

Capacidad de equilibrado de carga entre hosts optimizando el consumo de energía gestionando automáticamente el encendido y apagado de máquinas

virtuales en periodos de demanda reducida.

Gestión automatizada de equilibrado de carga en base a las características del almacenamiento, permitiendo la agrupación de recursos en base a políticas definidas

por el usuario.

Capacidad de asignación dinámica de recursos de CPU, Memoria, E/S y de red disponibles a las máquinas virtuales en base a las necesidades de la entidad sin

necesidad de parada del servicio de las mismas.

Capacidad de limitar el servicio de E/S a disco con el fin de priorizar el servicio de unas máquinas virtuales frente a otras, con independencia del servidor físico o

disco en el que se encuentren.

Posibilidad de definir una arquitectura de máquinas virtuales con tolerancia a fallos que en caso de fallo, de forma automática, continúe dando servicio sin

parada o pérdida en dicho servicio.

Capacidad de virtualización de la memoria flash del

servidor mediante una capa de caché de lectura.

Centralización del aprovisionamiento, administración y supervisión a través de la agregación de redes a nivel







Pág. 73 de 243



Exp.093/16-AE


de cluster.

Generación de plantillas de configuración a nivel de host, permitiendo la creación de servidores a partir de estas plantillas y monitorizando el cumplimento de las

normas definidas.

Funcionalidad para realizar copias de seguridad de las

VMs de forma eficiente. Funcionalidad para realizar

replicación de las Máquinas Virtuales con una

periodicidad de 15 minutos.

Garantía

Garantía de las licencias durante 2 años incluyendo actualización de versiones.

2.3. Componente 2. Flujos de movilidad turística

El análisis de flujos de movilidad turística trata de recopilar, anonimizar y agregar

datos, con el fin de entender cómo se comportan segmentos de la población en

conjunto. Se analizarán las tendencias y los comportamientos de las multitudes, no

de los individuos.

Esta información se utilizará para permitir a los Ayuntamientos de Almendralejo y

Badajoz comprender mejor a sus visitantes, para mejorar las propuestas de valor

hacia ellos.

Se utilizarán datos anonimizados, agregados y extrapolados que reflejan el

comportamiento real de grupos de personas. Esto permitirá analizar la estimación

de actividad en una zona geográfica delimitada de las ciudades de Almendralejo y

Badajoz por edad, género y franja temporal (hora, día, semana o mes) y hacer

comparaciones con cualquier otra localización. Esta información deberá ser







Pág. 74 de 243



Exp.093/16-AE

obtenida por el adjudicatario con el único objeto de la realización de este análisis

de flujos turísticos y sólo por el tiempo que dure el mismo. El grado de

anonimización y agrupación debe ser tal que cumpla con todos los requisitos de la

normativa existente sobre Protección de datos de Carácter Personal.

Este componente deberá satisfacer las siguientes necesidades:

2.3.1. (√) La zona geográfica objeto de estudio son los municipios de

Almendralejo y Badajoz.

2.3.2. (√) En caso de que la muestra ofrezca el dato se considerarán

como objeto de estudio los sujetos que hayan pasado más de 10

minutos en una zona geográfica delimitada.

2.3.3. (√) Cuando sea posible los estudios se realizarán incluyendo

detalles de fechas y horas, así como el promedio de su estancia,

todo ello segmentado por grupos de edad y sexo para visitantes

nacionales y por nacionalidad para los extranjeros.

2.3.4. (√) Para realizar este análisis con una precisión y con una

recurrencia necesarias para el exhaustivo conocimiento del

comportamiento estacional de los turistas no podrán utilizarse

técnicas estadísticas convencionales a base de muestreos de

población, será preciso que se utilicen técnicas de Big Data

basadas en la geolocalización de personas por medios

electrónicos, convenientemente anonimizadas y agregadas

partiendo de fuentes de datos externas como dispositivos móviles

y/o información de TPVs de tarjetas de crédito que proveen de







Pág. 75 de 243



Exp.093/16-AE

datos reales, no percibidos que deberán ser facilitados por el

adjudicatario.

2.3.5. (√) El periodo de estudio se definirá al inicio del proyecto con una

duración de un mes en un periodo que se definirá tras la

adjudicación del concurso.

2.3.6. (√) La muestra requerida estará compuesta por al menos el 25%

del universo de estudio.

2.3.7. (√) Se requerirá la entrega para cada municipio de una matriz de

datos en formato CSV, XLS o Json.

2.3.8. (√) Adicionalmente los datos en bruto y los datos ya tratados

debidamente organizados y categorizados serán puestos a

disposición de la plataforma Smart definida en el Componente 10,

para su integración en la misma y su explotación desde el cuadro

de mando definido en el apartado 2.11.2

2.3.9. (√) Las matrices de datos de los visitantes objeto de estudio

deberán tener las siguientes características.

2.3.9.1. (√) Dimensiones de estudio - Segmentación de los datos

Segmentación en base al sexo para turistas nacionales

Segmentación por rango de edades para turistas

nacionales

Segmentación por procedencia de la siguiente forma:







Pág. 76 de 243



Exp.093/16-AE

o Para usuarios internacionales: por nacionalidad

o Para usuarios nacionales:

Para Todos: Provincia origen.

Para una provincia a seleccionar: Municipios.

Para un municipio a seleccionar: con el

mayor grado de granularidad posible.

o Para usuarios locales (Almendralejo y Badajoz) con

el mayor grado de granularidad posible.

Segmentación por tipo de día: Laborable – Fin de semana

Segmentación por rango de horas: Mañana, tarde, noche

Segmentación por agregación geográfica con el mayor

grado de granularidad posible

2.3.9.2. (√) Variables de estudio serán el número de visitantes.

2.3.10. (√) La representación gráfica de los resultados deberá cumplir los

siguientes requerimientos:

2.3.10.1. (√) Catchment por provincias

Mapa con la representación de los orígenes de los usuarios

únicos detectados en la zona en cuestión durante más de

10 minutos en caso de análisis de fuentes de datos

provenientes de dispositivos móviles o que hayan utilizado

su tarjeta de crédito, en caso de análisis de fuentes de

datos provenientes de TPVs entre las fechas de estudio

Listado de provincias con % de visitantes sobre total

2.3.10.2. (√) Catchment por municipios







Pág. 77 de 243



Exp.093/16-AE

Mapa con la representación de al menos 20 municipios de

origen de los usuarios únicos detectados en la zona en

cuestión durante más de 10 minutos en caso de análisis de

fuentes de datos provenientes de dispositivos móviles o

que hayan utilizado su tarjeta de crédito, en caso de

análisis de fuentes de datos provenientes de TPVs entre

las fechas de estudio.

Listado de municipios con % de visitantes sobre total

2.3.10.3. (√) Catchment por códigos postales

Mapa con la representación de al menos 20 códigos

postales de origen de los usuarios únicos detectados en la

zona en cuestión durante más de 10 minutos en caso de

análisis de fuentes de datos provenientes de dispositivos

móviles o que hayan utilizado su tarjeta de crédito, en caso

de análisis de fuentes de datos provenientes de TPVs entre

las fechas de estudio.

Listado de CP con % de visitantes sobre total

2.3.10.4. (√) Catchment por países

Mapa con la representación de los países de origen de los

usuarios únicos detectados en la zona en cuestión durante

más de 10 minutos en caso de análisis de fuentes de datos

provenientes de dispositivos móviles o que hayan utilizado

su tarjeta de crédito, en caso de análisis de fuentes de

datos provenientes de TPVs entre las fechas de estudio.

Listado de países con % de visitantes sobre total







Pág. 78 de 243



Exp.093/16-AE

2.3.11. (√) Los informes generados por el adjudicatario cumplirán lo

dispuesto en la normativa existente sobre Protección de datos de

Carácter Personal.

2.3.12. Entregables.

2.3.12.1. () Datos en bruto de la muestra capturada para cada municipio

2.3.12.2. (√) Se requerirá la entrega para cada municipio de una matriz de

datos ya tratada y debidamente organizada y categorizada en

formato CSV, XLS o Json.

2.3.12.3. (√) Resultados del estudio e informe final con su representación

gráfica.

2.3.12.4. (√) Análisis de resultados y estudio de vías de aplicación de las

conclusiones en la gestión turística municipal.

2.4. Componente 3. Innovation hub

El objeto del presente componente consistirá en la elaboración de un Programa de

Actuación, que incluye por un lado un Plan de Actuación independiente para cada

una de las ciudades en el ámbito de las Ciudades Inteligentes dentro del proyecto

ALBA_Smart 2020 y por otro lado un Programa de Capacitación del personal de la

Administración asociado a la infraestructura desplegada.

Adicionalmente se habilitará una plataforma web conjunta que incluyan todos los

procedimientos previstos en el plan de actuación de cada ciudad.

El Ayuntamiento de Badajoz dispone de un Plan Estratégico Smart City que fija y

establece las principales líneas estratégicas de la ciudad en su transformación

hacia un modelo de Ciudad Inteligente, pero no así el Ayuntamiento de







Pág. 79 de 243



Exp.093/16-AE

Almendralejo debiendo tomarse como base y adaptarse para este ayuntamiento el

plan Estratégico Smart City de Badajoz para el desarrollo de los trabajos de

Almendralejo.

2.4.1. Componente 3.1. Elaboración del Plan de Actuación.

La elaboración del Plan de Actuación específico para Almendralejo y Badajoz que

se articulará en base al desarrollo de los elementos que se describen a

continuación:

Definición de un modelo y especificaciones

2.4.1.1. (√) A partir del Plan Estratégico Smart City del Ayuntamiento de

Badajoz y de la adaptación del mismo realizada para el

Ayuntamiento de Almendralejo, se realizará la definición de un

modelo que identificará aquellos servicios o actuaciones

susceptibles de ser puestos en marcha en un marco de 1 año a

partir de la puesta en producción de los componentes del presente

procedimiento que serán priorizadas y de las cuales se elegirán 4

sobre las que se desarrollarán los trabajos.

2.4.1.2. (√) Se desarrollará un Plan de Actuación independiente para cada

municipio, para cada eje estratégico y dentro de cada línea

estratégica se definirán con detalle todos los objetivos, el alcance y

el conjunto de funcionalidades a servir en cada una de las

Delegaciones Municipales del Ayuntamiento involucradas para

dichos proyectos.

2.4.1.3. (√) Para cada una de estas actuaciones seleccionadas en el Plan de

Actuación se redactarán el conjunto de especificaciones técnicas

que luego puedan ser incluidas en futuros pliegos que se liciten

para la implantación de las mismas. Se hará hincapié en la calidad

de la herramienta, tecnología o funcionalidad definida, y cómo se







Pág. 80 de 243



Exp.093/16-AE

relacionarán con el plan de actuación global de la ciudad

inteligente. Estas especificaciones incluirán:

Análisis de las tecnologías a implantar.

Definición de escenarios y alternativas de diseño

de soluciones. A nivel de detalle estas definiciones

deberán incluir especificaciones generales y

particulares de la iniciativa o actuación a

implantar, llegando a contener el documento hasta

tres niveles de desarrollo tecnológico: Global para

las dos ciudades como un todo, Particular para

cada iniciativa particular o actuación a relacionar y

Concreto para las cuestiones que en su aclaración

necesite un grado más de detalle.

Arquitectura tecnológica y fases de implantación

según el modelo global del propio plan de acción.

La arquitectura tecnológica de una institución

recoge el conjunto de decisiones significativas

sobre la organización del software, sus interfaces,

su comportamiento y su interacción, así como la

selección y composición de los elementos

estructurales (infraestructura tecnológica). La

arquitectura tecnológica solicitada tiene que ser

una definición de alto nivel sin desarrollar la

implementación de los sistemas. Deberá definir

conceptos como sus principios y factores, la

organización, estilos, patrones, responsabilidades,

colaboraciones, conexiones y motivaciones.

2.4.1.4. (√) Se debe establecer el modelo de relación entre los diversos

elementos tecnológicos y también los mecanismos para su

actualización constante.







Pág. 81 de 243



Exp.093/16-AE

2.4.1.5. (√) Con el fin de aportar un marco de referencia para la

construcción de nuevas soluciones tecnológicas, en la sección de

infraestructura tecnológica se realizará una propuesta de

arquitectura lógica, física y los principales elementos de

infraestructura.

2.4.1.6. (√) Se deben especificar en cada definición particular de

arquitectura, cómo se integran y relacionan con todo el sistema

global de la ciudad aquellos diseños particulares que sean objeto de

más detalle en su descripción.

Definición de un modelo de sostenibilidad

2.4.1.7. (√) Desde el punto de vista económico, se llevará a cabo una

estimación del coste de desarrollo e implantación de cada servicio

seleccionado. Este coste se detallará según las fases de

implantación de cada servicio. La evaluación económica se realizará

de forma individual por servicio, y de forma global considerando

todos los servicios seleccionados para su puesta en marcha a corto

plazo (y que se incluirán en el Plan de Actuación), incluyendo un

factor reductor por posibles sinergias.

Calendarización y plan de acción

2.4.1.8. (√) Una vez priorizadas las actuaciones a poner en marcha en el

marco del Plan de Actuación, se realizará una descripción de cada

una de las fases de desarrollo para su puesta en marcha:

Requerimientos administrativos previos:

aprobaciones, potenciales lanzamientos de

posibles licitaciones, etc.

Estimación de tiempo de desarrollo de las

iniciativas.

Asignación de responsabilidades y recursos.







Pág. 82 de 243



Exp.093/16-AE

Descripción de las acciones previstas para la

puesta en servicio.

Fases de implantación: duración, condicionantes,

camino crítico, etc.

Requerimientos de formación, comunicación,

integración, etc.

Definición de un modelo de seguimiento de indicadores

2.4.1.9. (√) El modelo de seguimiento de indicadores tiene por objeto la

puesta en marcha de los mecanismos necesarios para el

seguimiento, evaluación y control de las acciones y proyectos

asociados al Plan de Acción definido en el plan estratégico Smart

City de los municipios de Almendralejo y Badajoz. Para ello el

adjudicatario deberá identificar aquellos indicadores que permitan

medir el grado de avance, los recursos consumidos, el tiempo

empleado, los objetivos alcanzados...

2.4.1.10. (√) El seguimiento de cada Plan de Acción tiene por objetivo la

evaluación y control de las distintas medidas de puesta en marcha y

acciones que en el proyecto Smart se van a implantar o integrar.

Para alcanzar este objetivo global se deben de identificar un

conjunto de elementos e indicadores claves que nos muestren la

situación y el grado de implantación y funcionamiento (una vez

puesto en marcha), estos indicadores deberán formar parte del

Catálogo.

Catálogo de indicadores

2.4.1.11. (√) Se estima que el Catálogo de indicadores a diseñar en el

presente componente estará constituido por un máximo de 500

indicadores entre ambos ayuntamientos.

2.4.1.12. (√) El catálogo de indicadores deberá estar compuesto por los

indicadores identificados en el apartado anterior, adicionalmente

estará constituido por:







Pág. 83 de 243



Exp.093/16-AE

Indicadores identificados y definidos a partir de la

información obtenida en los componentes 4, 5, 6, 7, 8, 9 y 11.

Adicionalmente, se identificarán y/o definirán indicadores

sobre los datos a integrar en la plataforma indicados en el

componente 12.

Podrán identificarse y/o definir cualquier otro indicador que

sea considerado de interés a partir de la información

disponible en el Ayuntamiento o a través de la ejecución del

presente concurso.

2.4.1.13. (√) Por cada indicador del Catálogo se deberá gestionar, supervisar

y consolidar la recogida de la información necesaria para su gestión

y tratamiento. A modo orientativo, se debe recopilar y documentar:

su nombre, interpretación y significado, entidad proveedora de la

información, fuentes de datos para su obtención, objetivo

estratégico al que se vincula, actividad municipal con la que se

relaciona, perspectiva a la que pertenece, calidad del dato actual y

de los datos históricos, profundidad de los datos históricos, fórmula

de cálculo del indicador, periodicidad de carga de los datos,

métricas, unidades y formato de presentación del indicador, sus

límites, tolerancias y valores objetivo, los niveles de agregación, su

visibilidad y niveles de seguridad.

2.4.1.14. (√) A estos efectos, por cada indicador se deberá realizar una

localización de los aplicativos y bases de datos existentes en el

conjunto de cada municipio, que sirvan como fuentes de

información para la obtención de los datos del mismo, tanto

actuales como históricos, teniendo presente que los datos

históricos pueden residir en fuentes diferentes y responder a

modelos y fórmulas de cálculo diferentes que igualmente habrán de

documentarse. Detallando con exactitud la ubicación de las fuentes

de datos, la tecnología que los sustenta y el responsable de los

mismos







Pág. 84 de 243



Exp.093/16-AE

2.4.1.15. (√) Los indicadores se deben poder identificar fácilmente, y ser

claramente comprensibles, simples de calcular y, siempre que sea

posible, sus fuentes serán estructuras de datos ya existentes. La

medida que aporte tiene que ser precisa y confiable.

2.4.1.16. (√) En la medida de lo posible, los indicadores deberán estar

relacionados entre sí según su naturaleza, el objetivo de la

medición u otras dimensiones, de modo que se puedan efectuar

análisis cruzados o agrupaciones entre ellos, con un significado

específico. Estas agrupaciones podrán estar constituidas total o

parcialmente por indicadores compuestos a partir de otros de

inferior rango, ponderados en función de su importancia.

2.4.1.17. (√) Tomando como base los modelos definidos en los apartados

anteriores, y teniendo presente el objetivo final del diseño

conceptual del Cuadro de Mando Municipal, el adjudicatario deberá

elaborar un catálogo de indicadores en el que se recogerán

indicadores de gestión (estratégicos) municipales y de ciudad,

relevantes para la adecuada gestión de los servicios y gobierno

municipal de acuerdo a las líneas y mapas estratégicos

identificados tomando como base los servicios implantados en el

presente procedimiento y los proyectos identificados en este

apartado

2.4.1.18. (√) En el diseño propuesto de cuadro de mando se tendrán en

cuenta criterios de agrupación lógica de los servicios municipales

tratando de que dichos criterios tengan un sentido y vigencia

temporal más allá de las estructuras organizativas que en

determinado momento tenga la corporación municipal, de modo que

el impacto de los cambios organizativos sobre ellos y los costes de

mantenimiento del Cuadro de Mando Municipal que en base a ellos

se diseñe se minimicen.

Diseño conceptual del cuadro de mando







Pág. 85 de 243



Exp.093/16-AE

2.4.1.19. (√) El objetivo será proporcionar una definición conceptual de los

elementos integrantes del cuadro de mando municipal, la definición

de su estructura y contenido así como de un diseño que, desde ese

plano conceptual, favorezca el manejo y comprensión del mismo. El

primer modelo de la información mostrará ésta, además de en

informes, resúmenes y estadísticas, mediante gráficos que

permitan de un sencillo vistazo realizar el seguimiento de los

diferentes indicadores. Para cada indicador, y panel de indicadores,

se definirá un sistema de semáforos y gráficos que, combinado con

un sencillo código de colores, permitirá al usuario interpretar, visual

e intuitivamente, los datos. Para ello se medirá el grado de

cumplimiento de la medida y la desviación con los datos esperados.

2.4.1.20. (√) El cuadro de mando para cada ayuntamiento estará formado por

un máximo de 200 indicadores del catálogo definido en apartado

2.4.1.11 teniendo en cuenta que para su selección que los

indicadores deberían poder ser obtenidos de las fuentes de datos

resultantes de la ejecución de los componentes del presente

concurso o de manera excepcional a partir de ficheros Excel

2.4.1.21. (√) Adicionalmente se deberán diseñar, a partir de los indicadores

que constituyen el cuadro de mando diseñado conceptualmente en

el punto anterior, un máximo de 40 informes de los cuales, se

estima, que un 50% podrían tener complejidad alta y el resto

complejidad baja o media).

Definición de la planificación de la difusión de la iniciativa

2.4.1.22. (√) La planificación de la difusión de la iniciativa para las ciudades

inteligentes de Almendralejo y Badajoz, de forma independiente,

deberá adaptarse a las políticas que dentro del gobierno de la

ciudad sean definidas o consideradas oportunas de realizar. Así

pues, y con la responsabilidad de la Delegación o Área de Protocolo

o Comunicación del Ayuntamiento, se deberá diseñar una

planificación de la difusión externa e interna, identificando los







Pág. 86 de 243



Exp.093/16-AE

medios a través de los cuales dar a conocer las actuaciones

descritas.

2.4.1.23. (√) Asimismo, dicha planificación de la difusión, debe estar

completamente alineada con el planteamiento estratégico realizado

por el Ayuntamiento sobre la gestión y coordinación entre las

Delegaciones para la implantación del concepto de Ciudad

Inteligente. Por lo tanto, tanto el modelo de gobierno como la

planificación de la difusión deberán detallar y poner en marcha los

instrumentos y mecanismos que allí se indican.

Entregables.

2.4.1.24. () Plan de acción completo de acuerdo a los requisitos y

contenidos definidos en el presente componente.

2.4.1.25. () Catálogo de indicadores

2.4.1.26. () Diseño conceptual del cuadro de mando.

2.4.1.27. () Identificación y análisis preliminar de las fuentes origen de los

datos

2.4.1.28. () Planificación de la difusión

2.4.2. Componente 3.2. Programa de capacitación

La elaboración del Programa de Capacitación del Innovation Hub es independiente

de la capacitación de componentes definida en el apartado 2.1.8 y se articulará en

base al desarrollo de los elementos que se describen a continuación:

2.4.2.1. (√) La capacitación, deberá tener en cuenta los diferentes perfiles

de usuario, desarrollando capacitación específica y documentación

para cada uno de ellos con el fin de que los asistentes alcancen la

mayor autonomía posible.







Pág. 87 de 243



Exp.093/16-AE

2.4.2.2. (√) La sesión de capacitación se realizará en las instalaciones

designadas por los Ayuntamientos. Estas instalaciones contarán

con el equipamiento necesario para impartir la capacitación,

pizarra, conexión a internet, sillas y mesas y ordenadores.

2.4.2.3. (√) Para el desarrollo de la capacitación exigida el adjudicatario

desarrollará la estructura, unidades didácticas, contenidos y

talleres de la capacitación y pondrá a disposición de los asistentes

a las jornadas, la documentación necesaria para el seguimiento de

las mismas (manuales de uso, información técnica necesaria etc.).

2.4.2.4. (√) La inscripción y/o selección de asistentes para las sesiones de

capacitación serán gestionadas desde los Ayuntamientos.

2.4.2.5. (√) Se deberán generar los siguientes entregables:

Plan de capacitación.

Unidades didácticas

Documentación de la capacitación.

Para cada una de las sesiones, acta en la que se especifique los contenidos

impartidos, el material que se ha entregado y el listado de asistentes así como la

documentación que acredite la asistencia de los mismos (acta de asistencia al

curso firmada por los asistentes, y cuestionario de evaluación de la capacitación).

2.4.2.6. (√) Los contenidos formativos elaborados por el licitador se

entregarán en formatos de fuentes abiertas reutilizables a Red.es

para que puedan ser utilizados en otros entornos.

2.4.2.7. (√) El licitador elaborará un calendario de cursos que deberá ser

aprobado por los Ayuntamientos.

Capacitación in-Company

2.4.2.8. (√) Esta capacitación estará destinada a las diferentes estructuras

del personal de los Ayuntamientos de Almendralejo y de Badajoz,







Pág. 88 de 243



Exp.093/16-AE

siendo la selección de los asistentes responsabilidad de los

Ayuntamientos.

2.4.2.9. (√) Las sesiones de capacitación tendrán una asistencia máxima de

20 alumnos por sesión.

2.4.2.10. (√) Cada una de las sesiones tendrá una duración de 25 horas.

2.4.2.11. (√) El calendario de ejecución de la capacitación será consensuado

al inicio de los trabajos.

2.4.2.12. (√) Se podrá solicitar la impartición de sesiones en paralelo en

ambos Ayuntamientos.

2.4.2.13. (√) Esta capacitación estará organizada en 5 bloques.

Turismo

Movilidad

Datos abiertos

Smart economy

Innovación

2.4.2.14. (√) Se desarrollará una sesión de cada bloque por Ayuntamiento.

2.4.2.15. (√) Se potenciará y se buscará la sostenibilidad y puesta en valor de

todos los procesos de implementación tecnológica, gestión del

cambio prevista y su estabilidad y potencialidad con el fin de crear

un proceso participativo con la sociedad

Capacitación Living-lab/Innovation Lab

2.4.2.16. (√) Se trata de acciones de capacitación conjunta entre personal al

servicio de la Administración, Ciudadanos y Empresas, que

posibilite por un lado dar a conocer las infraestructuras







Pág. 89 de 243



Exp.093/16-AE

tecnológicas instaladas y por otro proceder a un proceso de

conocimiento compartido, muy útil para la optimización de recursos

y mejora de los servicios públicos.

2.4.2.17. (√) Las sesiones de capacitación tendrán una asistencia máxima de

10 alumnos por sesión.

2.4.2.18. (√) Esta capacitación estará organizada en 5 bloques, con una

duración concreta para cada sesión de cada bloque.

Taller de dinamización de modelos de negocios

(30 horas)

Taller cooperación ciudadana (15 horas)

Taller innovación social (15 horas)

Smart destinations (tourism lab) (30 horas)

Taller Open Data Lab (30 horas)

2.4.2.19. (√) Se desarrollará dos sesiones de cada bloque por Ayuntamiento.

2.4.2.20. (√) Se diseñarán talleres con labores de participación y de difusión

de la programación. Generando un proceso de capacitación y

participación del sector público y privado de asociaciones, de

comerciantes, etc., con el fin de dar a conocer las escalabilidad de

las acciones emprendidas y las potencialidades para la mejora

productiva, de gestión de gobierno, y de generación de

oportunidades en materia de negocio y de reducción de huella de

carbono.

2.4.3. Componente 3.3. - Página web

El objeto del presente componente es el diseño y la construcción de una página

web corporativa para la difusión periódica de los avances de la iniciativa Alba

Smart 2020.







Pág. 90 de 243



Exp.093/16-AE

Los objetivos vendrán determinados por la necesidad de dar a conocer los

servicios y soluciones que las Smart Cities en general y la iniciativa en particular

aportan a la ciudadanía. Y serán los siguientes:

Impulsar la creación de espacios de encuentro entre la

oferta del sector tecnológico y la potencial demanda

de las empresas y de la sociedad en el ámbito de la

Iniciativa de Ciudades Inteligentes.

Facilitar la transferencia de tecnología, servicios

especializados y conocimiento del área emergente de

las tecnologías de Smart Cities desde y hacia las

empresas del sector TIC.

Asesorar, capacitar y formar tecnológicamente a las

empresas para potenciar el ecosistema intensivo de

conocimiento de la Ciudad Inteligente.

Poner al servicio de las empresas los medios para la

realización de pruebas e innovación de tecnologías,

plataformas, productos, servicios, modelos de negocio,

procesos, metodologías, etc. del ámbito de las

Ciudades Inteligentes y las Tecnologías Ubicuas.

Sensibilizar a las empresas y a la sociedad sobre las

ventajas de la incorporación de las TIC y otras

tecnologías afines en los desarrollos las Smart Cities.

Convertirse en el mejor escaparate de productos y

servicios TIC vinculados a las Ciudades Inteligentes,

ofertados por y para las empresas interesadas.

Ser un referente para el encuentro entre empresas de

los sectores tecnológicos que facilite las sinergias en

un espacio singular de encuentro.







Pág. 91 de 243



Exp.093/16-AE

2.4.3.1. (√) Por ello el licitador deberá generar contenidos para alimentar la

página web, publicando al menos cuatro entradas mensuales hasta

la puesta en marcha y aceptación de todos los componentes del

proyecto, comunicando los avances del proyecto, dando a conocer

las características/tecnologías utilizadas y sus beneficios para la

ciudadanía y/o destacando los objetivos anteriormente

mencionados.

2.4.3.2. (√) El licitador será el responsable de la gestión de mantenimiento

de la página web durante la fase de ejecución del proyecto hasta la

aceptación de las actuaciones.

Los requisitos técnicos mínimos son los siguientes.

2.4.3.3. (√) A partir de este manual de identidad visual definido en el

apartado 2.1.4 se realizará la definición de las propuestas de diseño

de la página web que serán validadas por los Ayuntamientos de

Almendralejo y Badajoz previo a su desarrollo, incluyendo la

propuesta de dominio para la publicación de la página web.

2.4.3.4. (√) Tras la aprobación de la propuesta de dominio por parte del

Ayuntamiento, será adquirido por el licitador aunque será

propiedad del Ayuntamiento.

2.4.3.5. (√) La web incluirá una parte pública (frontend) y una parte privada

(backend) donde los administradores podrán gestionar el contenido

de la misma.

2.4.3.6. (√) La autenticación en el backend estará basada en el sistema de

autenticación definido en el apartado 2.1.6.

2.4.3.7. (√) De esta forma el backend incorporará un módulo de

administración de usuarios para gestionar el listado y los permisos

de los mismos que estará integrado con el sistema de autenticación

definido en el apartado 2.1.6.

2.4.3.8. () Se deberá disponer de un Gestor de contenidos con el que

administrar todos los contenidos municipales que se difundan y se







Pág. 92 de 243



Exp.093/16-AE

gestionen con la página Web. Este gestor de contenidos deberá ser

software libre, modular y altamente configurable que permita

publicar artículos, imágenes, archivos y otros contenidos además

de ofrecer servicios añadidos como foros, encuestas, votaciones,

blogs y administración de usuarios y permisos.

2.4.3.9. () La página web deberá ofrecer un sistema de administración Web

que facilite y simplifique el mantenimiento de la Información y de

los contenidos de la plataforma. De esta forma debe permitir la

gestión de la información de los contenidos municipales: alta, baja y

edición. La información deberá poder ser editada o insertada

mediante formularios sencillos y efectivos.

2.4.3.10. () La página web deberá crearse con un diseño lo más

personalizable posible. De igual forma, el diseño gráfico de la

aplicación deberá ser totalmente corporativo siguiendo la línea de

estilo definida en el apartado 2.1.4.

2.4.3.11. () La aplicación deberá estar diseñada conforme una estructura

modular que facilite su escalabilidad para la incorporación de

nuevas funcionalidades y herramientas en el futuro.

2.4.3.12. () El desarrollo debe tener un diseño “responsive” de forma que

sea visualizable en ordenadores y dispositivos móviles (tabletas y

teléfonos móviles).

2.4.3.13. () La herramienta debe presentar unos roles predefinidos:

Administrador, editor, publicador, usuario, etc. con permisos

adecuados al rol. Adicionalmente, la gestión de usuarios debe

permitir la creación de nuevos roles, así como la asignación de

permisos por funcionalidad a estos roles.

Requisitos para el Frontend del Gestor de Contenidos

2.4.3.14. () Es necesario que el adjudicatario realice una entrega

totalmente funcional de los desarrollos en producción, esto implica

que todas las secciones desarrolladas deberán tener contenidos.







Pág. 93 de 243



Exp.093/16-AE

2.4.3.15. () La sencillez de manejo de la web deberá ser uno de los

principales pilares en el diseño y construcción de la misma. La

organización de la información así como la interfaz gráfica que la

compone deberá ser intuitiva y eficaz a la hora de gestionar la

información que contiene.

2.4.3.16. () La información deberá poder ser editada o insertada mediante

formularios sencillos y efectivos.

2.4.3.17. () La información se mostrará correctamente organizada y

segmentada. La aplicación se estructurará en secciones según

dicha organización de la información. Esta organización debe

facilitar a los usuarios la búsqueda y consulta de la información

2.4.3.18. () Los usuarios deberán poder tener acceso y reproducir archivos

multimedia desde la plataforma.

2.4.3.19. () Este módulo deberá dar la posibilidad a los usuarios de poder

realizar cualquier notificación que necesiten mediante el envío de

un correo electrónico.

2.4.3.20. () Dispondrá de un motor de búsquedas y filtrados de información

eficiente que permita a los usuarios localizar la información que

necesiten de forma directa.

2.4.3.21. () En la web se permitirá la integración bidireccional con redes

sociales, de forma que al igual que se muestra en la web pública los

datos de los perfiles, habilitará a los usuarios visitantes la

posibilidad de compartir contenidos (definido por tipologías) a

través de sus perfiles personales.

2.4.3.22. () La aplicación deber utilizar servicios web para comunicarse con

otros módulos/aplicaciones, de esta forma se desarrollarán todos

los servicios web necesarios para dar servicio a estos

módulos/aplicaciones. Entre estos se incluyen los servicios web







Pág. 94 de 243



Exp.093/16-AE

para proveer contenidos a la Plataforma Smart definida en el

apartado 2.11 Componente 10.

2.4.3.23. () La página web tendrá una funcionalidad para mostrar una

agenda de eventos entre los que se encontrarán las sesiones de

capacitación del Componente 3.2. En la misma se mostrarán

eventos de tipo texto, fotográfico o mixto y su visualización

adicional en formato calendario.

2.4.3.24. () El frontend incluirá un módulo para la captación de datos de los

usuarios a partir de formularios/encuestas elaboradas en el

backend.

Requisitos para el Backend del Gestor de Contenidos

2.4.3.25. () El acceso a la administración de la plataforma estará protegido

mediante usuario y contraseña.

2.4.3.26. () La plataforma deberá ofrecer un sistema de administración

Web que facilite y simplifique el mantenimiento de la Información a

través de un gestor de contenidos.

2.4.3.27. () Deberá proveer de las herramientas adecuadas de

administración y mantenimiento de roles, permisos, usuarios y

contraseñas que estará integrada con el sistema de autenticación

definido en el apartado 2.1.6.

2.4.3.28. () El backend debe permitir la creación de cabeceras con

transición de imágenes mediante “Scroll” y otros contenidos

dinámicos.

2.4.3.29. () El sistema deberá ofrecer herramientas para la gestión de

seguridad antispam.

2.4.3.30. () El repositorio central de datos deberá estar formado por una

base de datos que permita el almacenamiento y gestión de la

información.







Pág. 95 de 243



Exp.093/16-AE

2.4.3.31. () Se deberán proporcionar herramientas que den soporte a la

generación e introducción de nuevos contenidos, debiendo entre

otras permitir la actualización de contenidos en:

o Blog

o Noticias

o Wiki

o Agenda

2.4.3.32. () El backend permitirá la organización de los contenidos en el

gestor de acuerdo a una taxonomía y categorización.

2.4.3.33. () La administración de contenidos deberá facilitar las labores de

publicación y ocultación de contenidos.

2.4.3.34. () Se deberán ofrecer funcionalidades de gestión y reproducción

de archivos multimedia.

2.4.3.35. () Se deberán generar los servicios web necesarios para que el

resto de sistemas y aplicaciones puedan acceder a información de

la plataforma y enviar información a la plataforma. Entre estos se

incluyen los servicios web para proveer contenidos a la Plataforma

Smart definida en el apartado 2.12 Componente 10.

2.4.3.36. () La página web deberá estar diseñada conforme una estructura



2.4.3.37. () El entorno debe permitir la gestión de posicionamiento SEO

2.4.3.38. () La solución propuesta deberá facilitar la gestión de las

actualizaciones de sistema.

2.4.3.39. () El backoffice estará accesible para la utilización de los técnicos

municipales o quien ellos determinen. Para ello, el sistema deberá







Pág. 96 de 243



Exp.093/16-AE

estar diseñado para soportar la carga de peticiones que realicen

dichos usuarios internos o externos.

2.4.3.40. () El backend debe incluir un módulo que permita generar y

almacenar formularios y encuestas con el fin de realizar la

captación de datos que se mostrarán en la web y que podrán ser

explotados desde la Plataforma Smart

2.4.3.41. () El backend debe incluir un módulo que permita la generación de

eventos de tipo texto, fotográfico o mixto. Deberá permitir el alta,

baja y modificación estableciendo los parámetros necesarios para

su publicación como fecha de publicación y fecha de caducidad y

todo el contenido necesario para la definición del evento.

2.4.3.42. () El backend debe incluir un módulo que permita gestionar el

registro a estos eventos permitiendo generar un correo electrónico

para comunicar a los asistentes la inscripción al evento.

2.4.3.43. () El backend deberá disponer de un módulo de auditoría que

registre todas las operaciones realizadas por los usuarios del

gestor de contenidos con un período de vigencia o almacenamiento

de la información según lo estipulado en el Esquema Nacional de

Seguridad.

2.4.3.44. () El backend deberá disponer de un módulo para realizar de forma

sencilla e intuitiva copias de seguridad del gestor de contenidos a

los niveles de contenido, estructura de carpetas y base de datos.

Entregables.

2.4.3.45. () Documentación de diseño de los aplicativos

Diseños gráficos de la web para su aprobación

Diseño gráfico aprobado

Documento de requisitos

Documento de diseño







Pág. 97 de 243



Exp.093/16-AE

Modelo de datos

Descripción de los casos de uso y especificación de las

pruebas que deberán incluir como mínimo, pruebas funcionales, de

diseño y de carga.

Documento de ejecución de las pruebas

Manual de instalación, administración y usuario.

2.5. Componente 4. Portal de Transparencia y Datos Abiertos

El Componente 4 tiene por objeto la construcción de un Portal de Transparencia y

Datos Abiertos basado en tecnologías de software de fuentes abiertas que permita

la publicación de los datos municipales y facilite el acceso y la reutilización de los

datos por terceros (ciudadanos y empresas). Para ello se empleará una plataforma

probada de catalogación de datos, así como un gestor de contenidos estándar para

la presentación de los mismos en un formato lo más usable y reutilizable posible.

Será necesaria la Integración del Portal de datos abiertos y transparencia en la

Plataforma Smart City.

Las actuaciones a llevar a cabo en este componente son el diseño y construcción

de un Portal de Transparencia y Open Data.

2.5.1. Requisitos técnicos mínimos del diseño y construcción.

Se pondrá a disposición de los Ayuntamientos de Almendralejo y Badajoz un Portal

de Datos Abiertos y Transparencia que proporcione una plataforma web para el

almacenamiento y la distribución de los datos y que deberá cumplir las siguientes

funcionalidades.

2.5.1.1. () Deberá estar basado en software de fuentes abiertas.

2.5.1.2. () La plataforma será flexible y extensible y diseñada para facilitar

la integración de nuevos sistemas y contenidos. Deberá emplear

componentes que hayan sido integrados con éxito en proyectos

similares.







Pág. 98 de 243



Exp.093/16-AE

2.5.1.3. () Arquitectura modular y escalable. Identificando al menos las

capas de presentación, catálogos de datos y capa de integración.

2.5.1.4. (√) El repositorio de datos deberá estar formado por una base de

datos que permita el almacenamiento y gestión de la información.

Esta base de datos estará integrada en el mismo entorno de base

de datos que el resto de componentes.

2.5.1.5. () Se utilizará una plataforma basada en software de fuentes

abiertas para la gestión y catalogación de datos abiertos mientras

que para la presentación y explotación de los mismos se utilizará un

gestor de contenidos de software libre, usando el mismo gestor de

contenidos definido para el Componente 3.3.

2.5.1.6. () Este Gestor de contenidos permitirá administrar todos los

contenidos municipales que se difundan y se gestionen a través del

portal. Este gestor de contenidos deberá ser software libre,

modular y altamente configurable que permita publicar artículos,

imágenes, archivos y otros contenidos.

2.5.1.7. () La plataforma deberá ofrecer un sistema de administración Web

que facilite y simplifique el mantenimiento de la Información y de

los contenidos de la plataforma. Debe permitir la gestión de la

información de los contenidos: alta, baja y edición. La información

deberá poder ser editada o insertada mediante formularios

sencillos y efectivos.

2.5.1.8. () El Portal deberá crearse con un diseño lo más personalizable

posible. De igual forma, el diseño gráfico de la aplicación deberá ser

totalmente corporativo, todo ello siguiendo la guía de estilo

definida en el apartado 2.1.4.

2.5.1.9. () El Portal deberá estar diseñado conforme una estructura









Pág. 99 de 243



Exp.093/16-AE

2.5.1.10. () El desarrollo debe tener un diseño “responsive” de forma que

sea visualizable en ordenadores y dispositivos móviles (tabletas y

teléfonos móviles).

2.5.1.11. () La herramienta debe presentar unos roles predefinidos:

Administrador, editor, publicador, usuario, etc. con permisos

adecuados al rol. Adicionalmente, la gestión de usuarios debe

permitir la creación de nuevos roles, así como la asignación de

permisos por funcionalidad a estos roles.

2.5.1.12. () Existirá una única base de datos de usuarios que autenticará de

forma centralizada a los usuarios para la gestión de los contenidos

del Portal, esta autenticación será común con la autenticación de

otros componentes del presente procedimiento definida en el

apartado 2.1.6.

2.5.1.13. () El módulo de visualización tendrá soporte multidioma, se

proporcionará con los textos en español e inglés, traducciones que

proporcionarán los Ayuntamientos.

2.5.1.14. () Deberá estar basado en la utilización de estándares

estructurados y no propietarios. Como pueden ser:

XML, HTTP y JSON.

Formatos de intercambios de información espacial como

Shapefile, GML, KML y estándares del Open Geospatial

Consortium (OGC) como WFS.

2.5.1.15. () Deberá tener funcionalidad de catálogo de datos.

2.5.1.16. () El catálogo de datos tiene que ser capaz de gestionar y exportar

metadatos descriptivos de los conjuntos de datos catalogados,

incluyendo al menos los metadatos propuestos en la Norma Técnica

de Interoperabilidad para la reutilización de recursos de

información.







Pág. 100 de 243



Exp.093/16-AE

2.5.1.17. () Será obligatorio el cumplimiento de la Norma Técnica de

Interoperabilidad de Reutilización de recursos de información (NTI),

en su última versión al inicio de los trabajos, conforme con lo

establecido en la Ley 37/2007, de 16 de noviembre.

Estas condiciones tienen el objetivo de facilitar y garantizar el

proceso de reutilización de la información de carácter público

procedente de las Administraciones públicas, asegurando la

persistencia de la información, el uso de formatos así como los

términos y condiciones de uso adecuados.

El adjudicatario deberá realizar las actuaciones oportunas para la

federación de los datasets que se publiquen en el portal objeto de la

licitación con el catálogo de datos abiertos nacional (datos.gob.es)

2.5.1.18. () El portal suministrado por el licitador se adecuará estrictamente

en su sección de Datos Abiertos a esta Norma Técnica en cuanto a:

Uso de la semántica y glosario empleados en la NTI

Ajustes a los esquemas de construcción de URIs

Metadatos del catálogo

Metadatos de los conjuntos de datos y de sus distribuciones

(recursos)

Generación de un DCAT en formato XML/RDF ajustado a la norma

y federable por el Catálogo Nacional de Datos (datos.gob.es)

Propuesta de generación de un DCAT ajustado a la norma europea

2.5.1.19. () Además de los metadatos indicados en el requerimiento del

apartado anterior, deberá permitir añadir nuevos metadatos

personalizados o especializados para casos de uso concretos.

2.5.1.20. () La documentación relativa a los metadatos utilizados en la

plataforma y sus características detalladas debe también incluirse

o referenciarse claramente desde la misma plataforma.







Pág. 101 de 243



Exp.093/16-AE

2.5.1.21. () El Componente se integrará con la Plataforma Smart definida en

el apartado 2.11 Componente 10. Se exigirá al adjudicatario conexión

del Portal de Datos Abiertos y Transparencia con la plataforma de

Smart City de Badajoz y Almendralejo, de manera que todos los

datos generados puedan ser utilizados por el Cuadro de Mando

integrado en la misma.

2.5.1.22. () El adjudicatario, una vez desarrollado e implantado el portal de

datos abiertos, aplicará la norma técnica PNE 178301 a cada uno de

los Ayuntamientos y propondrá medidas de mejora en la estrategia.

2.5.1.23. () Debe proporcionar al menos una forma de acceso directo a los

datos, ya sea a través de enlaces externos, a los conjuntos de datos

alojados por sus propios gestores o mediante descargas de datos

alojados en la propia plataforma.

2.5.1.24. () El portal debe ofrecer la posibilidad de consultar directamente

parte de la información, sin necesidad de descargarla.

2.5.1.25. () Debe proporcionar la posibilidad de realizar filtrados por tipo de

formato de descarga del dato.

2.5.1.26. () Deben generarse y poner a disposición APIs de acceso abierto.

Las APIs deberán seguir los principios de REST y utilizar formatos

de uso común y extendido, como JSON o XML.

2.5.1.27. () La búsqueda debe ser capaz de presentar resultados relevantes

combinando búsquedas simples con otros mecanismos más

avanzados como las búsquedas a través de filtros compuestos.

Debe permitir al menos búsqueda de texto generando resaltado de

resultados, búsqueda facetada (múltiples criterios), indexación en

tiempo real.

2.5.1.28. () Además, deberá aportar la flexibilidad suficiente como para

poder filtrar y combinar resultados según distintas preferencias de







Pág. 102 de 243



Exp.093/16-AE

los usuarios (temáticas, antigüedad de los datos, frecuencia de

actualización, formatos, etc…).

2.5.1.29. () Debe dar soporte también a la actualización automatizada de los

datos permitiendo conexiones “en vivo” con fuentes de datos de

actualización dinámica, como son por ejemplo las bases de datos de

origen.

2.5.1.30. () La plataforma debe incorporar una sección que, a modo de

galería de aplicaciones, recoja y promocione los servicios que se

desarrollen y que hagan uso de los datasets puesto a disposición en

la plataforma (tanto de elaboración propia como desarrollados por

terceros).

2.5.1.31. () La plataforma para la publicación y gestión de datos debe incluir

herramientas para poder:

Insertar, editar y mantener los datos.

Recopilar de formar automática información de repositorios

existentes.

De administración.

2.5.1.32. () La plataforma debe recoger e incorporar a su repositorio (o en

su caso recuperar cuando sea solicitada su publicación) la

información facilitada a través de las APIs de los distintos

componentes desarrollados en el presente expediente como por

ejemplo en la Gestión de Flotas definida en el apartado 2.8 o

directamente a través de la Plataforma Smart definida en el

apartado 2.11

2.5.1.33. () La plataforma debe incluir herramientas de difusión. Al menos

debe incluir las siguientes:

Descripción de la iniciativa: en esta sección se introducirá

brevemente los conceptos básicos de la reutilización del sector

público así como de la del plan de reutilización del Ayuntamiento.







Pág. 103 de 243



Exp.093/16-AE

Noticias, novedades y actualizaciones sobre la estrategia de

datos abiertos municipal.

Documentación y ayuda: esta sección recogerá las buenas

prácticas y estándares que se hayan aplicado en la plataforma, así

como manuales y guías de ayuda que se puedan generar.

Términos y licencias: información sobre el marco legal,

condiciones de reutilización y licencias aplicables a los datos.

Estadísticas de uso: sección que recoja las estadísticas de

acceso y uso de la plataforma, utilización de los datos (número de

descargas).

2.5.1.34. () La plataforma también contará con un canal abierto que permita

a los ciudadanos y reutilizadores aportar comentarios, ideas y

sugerencias así como realizar peticiones y sugerencias sobre los

datasets publicados.

2.5.1.35. () El portal debe tener un aspecto gráfico adaptado a la imagen

corporativa de los dos Ayuntamientos mostrándose una u otra en

base a la dirección de entrada al mismo.

2.5.1.36. () El portal permitirá la carga de distribuciones a partir de la

plataforma de Ciudad, por cada Ayuntamiento.

2.5.1.37. () El portal permitirá la creación de las vistas (widgets gráficos)

para la página de indicadores, para cada Ayuntamiento.

2.5.1.38. () La aplicación estará accesible para la utilización de los técnicos

municipales o quien ellos determinen. Para ello, el sistema deberá

estar diseñado para soportar la carga de peticiones que realicen

dichos usuarios internos o externos.

2.5.2. Requisitos funcionales mínimos del frontend.

2.5.2.1. () Existirá una página de inicio en la que se muestre claramente el

acceso a las dos secciones del Portal, Transparencia y Datos







Pág. 104 de 243



Exp.093/16-AE

Abiertos, donde se mostrarán los indicadores más importantes de

cada una de ellas. La página tendrá distinto diseño según la entrada

sea desde el Ayuntamiento de Almendralejo o de Badajoz

2.5.2.2. () Se realizará la carga inicial de la información relacionada con la

documentación de datos abiertos y condiciones de reutilización

según la Norma Técnica de Interoperabilidad.

2.5.2.3. () Transparencia. Creación del árbol de indicadores de

Transparencia para todos los Ayuntamientos según Transparencia

Internacional España (ITA2014). Se cargaran un máximo de 80

enlaces o ficheros en este árbol.

2.5.2.4. () Transparencia. Se recuperarán todos aquellos contenidos

susceptibles de ser reutilizados de las páginas de Transparencia

existentes:

Almendralejo:

(http://www.almendralejo.es/transparencia.php)

Badajoz

http://www.aytobadajoz.es/es/ayto/transparencia)

Se completará estos contenidos con toda la información necesaria

para el cumplimiento de la legislación vigente relativa a

transparencia

2.5.2.5. () En la sección de Datos abiertos se incluirá necesariamente la

siguiente información.

Acceder a la descarga del catálogo de datos disponible en el

portal en formato RDF/DCAT

Búsqueda de conjuntos de datos

Listado de los conjuntos publicados permitiendo búsquedas

facetadas por:

o Etiquetas







Pág. 105 de 243



Exp.093/16-AE

o Formato de datos

o Taxonomía de Sectores de Información

o Frecuencia de actualización

o Fecha de última actualización

o Organismo o área que los publica

o Grado de apertura según clasificación de Tim Berners-Lee

Enlace a la descripción de las APIs

2.5.2.6. () En los Conjuntos de datos se incluirá necesariamente la

siguiente información

Descripción y metadatos asociados al conjunto de datos.

Relación de distribuciones asociadas al conjunto de datos

2.5.2.7. () En las Distribuciones se incluirá necesariamente la siguiente

información:

Descripción y metadatos asociado a la distribución (incluida

URL para descarga)

Previsualización de las distribuciones (txt, html, htm, xml, rdf,

owl, n3, turtle, atom, rss, png, jpg, jpeg, gif, pdf, csv, kml, gml, wkt,

wfs, wms, ngsi10)

Utilidad de creación de visualizaciones o vistas (gráficos de

sectores, columnas, área, líneas, líneas interpoladas, dispersión, y

combinados de los anteriores, barras, burbujas y agregados).

Relación de vistas guardadas sobre la distribución.

Gestión de las vistas guardadas (Perfil Administrador).

Selección de las vistas a mostrar en la sección de indicadores

(Perfil Administrador).

2.5.2.8. () En la sección de Datos abiertos se incluirá una página con

elementos gráficos obtenidos a partir de conjuntos de datos del







Pág. 106 de 243



Exp.093/16-AE

portal. Este cuadro de indicadores (basado en los indicadores

identificados en el Plan de actuación definido en el apartado 2.4.1)

se construirá a partir visualizaciones desarrolladas con los datos

publicados en el portal y con herramientas proporcionadas por el

mismo, a las vistas indicadas en el punto anterior se pueden añadir

widget para mapas KML, GML, WKT y WMS multicapas.

Adicionalmente se permitirá la socialización de los indicadores en

distintas redes sociales y el acceso directo a las distribuciones

desde cada uno de los indicadores.

2.5.2.9. () Se incluirá documentación sobre Datos Abiertos, con las

definiciones básicas, información sobre cómo debe reconocerse la

fuente de los datos al reutilizarse, información sobre su

licenciamiento e información útil para reutilizadores.

2.5.2.10. () Se incluirán aplicaciones de reutilizadores. En el horizonte del

proyecto seguramente irán apareciendo aplicaciones desarrolladas

por terceros utilizando los datos expuestos, se ofrecerá una

sección que presentará las aplicaciones que se han ido creando con

una breve presentación de la misma, información sobre su autoría y

enlaces de descarga o de más información. Normalmente no se

habilita con la primera versión del Portal de Datos Abiertos.

2.5.2.11. () Canal de colaboración activo en el portal.

2.5.2.12. () En la sección de Transparencia, se mostrarán todos los

Indicadores siguiendo las recomendaciones de Transparency

International (TI), está sección permitirá generar una estructura en

árbol de todos los indicadores.

2.5.2.13. () La plataforma debe permitir la integración y colaboración con la

comunidad de usuarios mediante las redes sociales.







Pág. 107 de 243



Exp.093/16-AE

2.5.3. Requisitos funcionales mínimos del backend.

2.5.3.1. (√) El acceso a la administración del Portal estará protegido

mediante usuario y contraseña, basado en el sistema de


2.5.3.2. (√) La plataforma deberá ofrecer un sistema de administración

Web que facilite y simplifique el mantenimiento de la Información a

través de un gestor de contenidos.

2.5.3.3. (√) Deberá proveer de las herramientas adecuadas de

administración y mantenimiento de roles, permisos, usuarios y

contraseñas.

2.5.3.4. (√) El backend debe permitir la creación de cabeceras con

transición de imágenes mediante “Scroll” y otros contenidos

dinámicos.

2.5.3.5. (√) El sistema deberá ofrecer herramientas para la gestión de

seguridad antispam.

2.5.3.6. (√) En el área de gestión (backend) se podrán seleccionar los tipos

de contenido que deban soportar multilenguaje, de forma que para

cada tipo de contenido seleccionado, se habilitarán los

componentes necesarios para permitir la incorporación de

contenidos traducidos

2.5.3.7. (√) Se deberán proporcionar herramientas que den soporte a la

generación e introducción de nuevos contenidos, debiendo entre

otras permitir la actualización de contenidos en:

Blog

Noticias

Wiki

Agenda







Pág. 108 de 243



Exp.093/16-AE

2.5.3.8. (√) El backend permitirá la organización de los contenidos en el

gestor de acuerdo a una taxonomía y categorización.

2.5.3.9. (√) La administración de contenidos deberá facilitar las labores de

publicación y ocultación de contenidos.

2.5.3.10. (√) Se deberán ofrecer funcionalidades de gestión y reproducción

de archivos multimedia.

2.5.3.11. (√) El backend deberá estar disponible en castellano.

2.5.3.12. (√) El sistema deberá incorporar herramientas de importación de

datos desde formatos estándar: csv, xls, json, etc. También debe

poder recuperar contenidos de la Plataforma Smart definida en el

apartado 2.11.

2.5.3.13. (√) El sistema deberá ofrecer la posibilidad de exportar datos a

formatos estándar: csv, xls, json, etc. También debe poder exportar

contenidos hacia la Plataforma Smart definida en el apartado 2.11.

2.5.3.14. (√) La aplicación deberá estar diseñada conforme una estructura



2.5.3.15. (√) El entorno debe permitir la gestión de posicionamiento SEO.

2.5.3.16. (√) La solución propuesta deberá facilitar la gestión de las

actualizaciones de sistema.

2.5.3.17. (√) El sistema debe permitir la exportación de datos a distintos

formatos, como mínimo.

Exportación de gráficos a formatos de imagen (jpg, png)

Exportación de tablas a formatos abiertos (csv, json…) y propietarios (xls)

2.5.3.18. (√) El backend debe incluir un módulo que permita generar y

almacenar formularios y encuestas.







Pág. 109 de 243



Exp.093/16-AE

2.5.3.19. () A través del backend se permitirán realizar los ajustes generales

a la Gestión de datos abiertos.

2.5.3.20. () A través del backend se permitirá realizar la administración y

carga de la sección de Transparencia.

2.5.3.21. () A través del backend se permitirá realizar la administración y

carga de la sección de Participación ciudadana.

2.5.3.22. () El gestor de contenidos permitirá a los usuarios autenticados la

introducción de comentarios sobre los contenidos que serán

moderados en el backend, pudiendo decidir el administrador si

permite o no la introducción de comentarios.




de la información según lo estipulado en el ENS.




2.5.4. Catálogos de datos a publicar

2.5.4.1. () El adjudicatario deberá generar datasets al menos con los datos

potencialmente reutilizables de los Ayuntamientos de Almendralejo

y Badajoz listados más adelante.

2.5.4.2. () El adjudicatario deberá identificar datos de Almendralejo y

Badajoz publicados por otras fuentes externas oficiales al propio

Ayuntamiento que sean reutilizables para su publicación en el

portal de datos abiertos. Una vez identificados estos dataset

deberán ser consensuados con los Ayuntamientos de Almendralejo

y Badajoz.







Pág. 110 de 243



Exp.093/16-AE

2.5.4.3. () Con carácter general se publicarán las informaciones que serán

proporcionadas por los Ayuntamientos de los servicios existentes y

el adjudicatario deberá facilitar la información de los servicios

desarrollados en el presente concurso.

Municipio Juegos de datos

Ayuntamiento de

Almendralejo

Gestión de Basuras.

Sede electrónica.

Suministro eléctrico

Instalaciones deportivas

Ayuntamiento de

Badajoz

E Administración (AL-SIGEM)

Turismo (Proyecto POPTEC)

En ambos

municipios


Puntos de acceso Wifi


Gestión de flotas

Control de afluencia

Encuestas a Ciudadanía y visitantes

Aplicaciones móviles

Contabilidad

Padrón

Gestión Tributaria







Pág. 111 de 243



Exp.093/16-AE

En función de la tabla anterior la información puesta a disposición del

ciudadano será:

Juego de datos Detalle

Gestión de Basuras toneladas de basura por periodo de tiempo y tipología

Sede electrónica Caracterización de los trámites solicitados: número,

departamento,… por unidad de tiempo

Expedientes en curso

Contabilidad Presupuestos

Ingresos

Gastos y Costes.

Ejecución presupuestaria

Gestión Tributaria Tasas e impuestos

Cobros y morosidad.

Información de impuestos por identificador fiscal (para uso

interno del Ayuntamiento)

Turismo Reenvío y recepción de datos de afluencia, puntos Wifi,

encuestas, … del proyecto POPTEC


Puntos de acceso Wifi Número de conexiones por unidad de tiempo

Flujo de datos por unidad de tiempo







Pág. 112 de 243



Exp.093/16-AE


Gestión de

aparcamientos

Ocupación de plazas por aparcamiento y unidad de tiempo.

Gestión de flotas Rutas seguidas por los vehículos.

Información agregada por unidad de tiempo: km, distancia

recorrida y tiempo en ralentí.

Control de afluencia Número de visitantes por unida de tiempo

Encuestas a Ciudadanía

y visitantes

Resultado obtenido

Instalaciones deportivas Uso de las pistas deportivas

Recaudación

Aplicaciones móviles Consumo de datos desde la plataforma: Plazas de aparcamiento,

posición de la flota,…

Traslado de información hacia la plataforma: incidencias,

ejecución de partes de trabajo,…

Padrón Municipal Población:

Sexo

Rango de edad

Por sector urbano

Por distrito/sección.

Por vía.

Por nivel de estudios.







Pág. 113 de 243



Exp.093/16-AE


Por nacionalidad.

Por lugar de nacimiento.

2.5.5. Entregables.

2.5.5.1. () Documentación de diseño del Portal de Datos Abiertos

Arquitectura del Portal

Modelo de datos


pruebas

2.5.5.2. () Documentación de construcción del Portal de Datos Abiertos

Código fuente de los desarrollos específicos de la plataforma

correctamente documentado

paquetes desplegables del portal

informe de resultados del plan de pruebas de construcción del

portal

2.5.5.3. () Plan de Reutilización de la Información que defina la estrategia

de reutilización de cada uno de los Ayuntamientos de Almendralejo

y Badajoz. El documento podrá tomar como base los planes RISP

desarrollados por la Administración General del Estado y

disponibles en datos.gob.es adaptándolos al ámbito municipal. El

documento deberá tener entre otras las siguientes secciones:

Identificación y selección de la información reutilizable

Procedimiento de identificación, selección, preparación y

publicación de los conjuntos

Calendario de publicación de conjuntos de datos reutilizables







Pág. 114 de 243



Exp.093/16-AE

Condiciones de reutilización

Publicación y mantenimiento de los datos reutilizables

Medidas de evaluación y mejora de la calidad en la

reutilización y fomento del consumo de los mismos

Este documento se pondrá a disposición de los Ayuntamientos para

su aprobación como estrategia global de reutilización por los

estamentos municipales que procedan. Y conformará el esqueleto de

plan estratégico de reutilización de la información del Sector Público

Municipal (Plan RISP Municipal) con el fin de que pueda ser utilizado

por otros Ayuntamientos.

2.6. Componente 5. Infraestructura Wifi

El Componente 5 tiene por objeto facilitar el acceso a internet a ciudadanos en

dependencias municipales a la vez que se obtiene información sobre los visitantes,

referente al uso que realizan de la información, así como a su localización.

De esta forma se realizará la instalación de un conjunto de puntos wifi en cada

municipio. Estos puntos wifi se instalarán en el interior de las dependencias

municipales para dar servicio a los visitantes en zonas comunes. La conectividad y

gestión de dichos puntos se incorporará a la que proporciona actualmente el

Ayuntamiento Para la gestión de los distintos puntos de acceso se adquirirá una

controladora Wifi para cada Ayuntamiento con el fin de realizar la gestión remota

de los puntos de acceso

2.6.1. Componente 5.1 Puntos de acceso Wifi

Los requisitos técnicos mínimos del componente son los siguientes.

2.6.1.1. () Los dispositivos suministrados deben estar diseñados para su

instalación en el exterior o interior de edificios.

2.6.1.2. () Tecnología de radio: 802.11n







Pág. 115 de 243



Exp.093/16-AE

2.6.1.3. () Bandas de frecuencia de trabajo: 2,4 y 5 GHz

2.6.1.4. () El dispositivo debe permitir la selección de frecuencia dinámica

2.6.1.5. () Antenas: 4 antenas integradas omnidireccionales con ganancias

de 3,9 dBi a 2,44GHZ ó 4,1 dBi a 5,2 GHz

2.6.1.6. () Interfaces: Ethernet (RJ-45) 1 Gb/s, alimentación, Puerto Serie

para consola.

2.6.1.7. () Indicadores: Encendido, Estado de la red, estado de radio

2.6.1.8. () Ranura para candado

2.6.1.9. () Máxima velocidad de conexión por elemento de radio 300Mb/s

2.6.1.10. () El dispositivo debe permitir dar servicio de forma simultánea a

80 conexiones.

2.6.1.11. () Servicio de datos: Navegación

2.6.1.12. () Capacidad de gestión remota.

2.6.1.13. () Obtención remota de trazas de operación.

2.6.1.14. () Advanced Cellular Coexistence (ACC)

2.6.1.15. () Power over Ethernet 802.3af. Los puntos de acceso deberán ir

equipados con los correspondientes inyectores PoE.

2.6.1.16. () Los puntos de acceso WIFI deben contar con protección mínima

IP65 de acuerdo a la norma internacional IEC 60529.

2.6.1.17. () Rango de temperatura de operación de -20ºC a + 65ºC

2.6.1.18. (√) El Ayuntamiento proveerá de conectividad a la red de datos en

la ubicación donde se ubique el equipamiento.

2.6.1.19. () La instalación de los dispositivos se realizará en las ubicaciones

descritas a continuación debiendo realizar el adjudicatario un







Pág. 116 de 243



Exp.093/16-AE

análisis para, de acuerdo a las necesidades de los Ayuntamientos,

optimizar el servicio que ofrecen los equipos desplegados.

Ciudad Instalaciones Dirección Nº Dispositivos

Badajoz La Granadilla Calle José Miguel

Sánchez Hueso, 57

5

Badajoz Antiguo Vivero Avda. Manuel Saavedra

Martinez, s/n

5

Almendralejo Conventual San

Antonio

Centro Cultural San

Antonio 1ª Planta

Avda. San Antonio, S/N

3

Almendralejo Oficina de Turismo Plaza de la Iglesia, 16 1

Almendralejo Zonas comunes

polideportivo

Tomás de la Hera

Calle Nicolás Megías,

S/N

4

Almendralejo Polideportivo San

Roque

Calle Puebla de la Reina

S/N

1

Almendralejo Centro Cívico Calle Mérida, 11. 1

2.6.2. Componente 5.2 Controladora Wifi

Los requisitos técnicos mínimos del componente son los siguientes.







Pág. 117 de 243



Exp.093/16-AE

2.6.2.1. () Capacidad para gestionar hasta 75 puntos de acceso, 256

WLANs (BSSIDs) y 2000 estaciones concurrentes.

2.6.2.2. () Soporte de las siguientes aplicaciones: Hotspot (WISPr), acceso

de invitado, portal cautivo, mallado y voz (802.11e/WMM, U-APSD,

tunelización de puntos de acceso)

2.6.2.3. () Soporte de redundancia 1+1 con auto sincronización.

2.6.2.4. () Servidor DHCP.

2.6.2.5. () Capacidades de gestión:

() Configuración mediante interfaz Web, CLI y SNMP v1, v2, v3.

() AAA: RADIUS (primario y de respaldo)

2.6.2.6. () Aprovisionamiento de puntos de acceso:

() Auto-discovery de niveles 2 y 3.

() Actualizaciones automáticas de software.

() Optimización automática de canales y potencia.

2.6.2.7. () Aprovisionamiento de clientes:

() Zero-IT.

() Configuración auto proxy.

2.6.2.8. () Capacidades de seguridad:

() Estándares: WPA, WPA2, 802.11i.

() Encriptación: TKIP, AES.

() Autenticación: 802.1x, direcciones MAC.

2.6.2.9. () Base de datos de usuarios:







Pág. 118 de 243



Exp.093/16-AE

() Interna: Hasta 2000 usuarios.

() Externa: RADIUS, LDAP, Active Directory.

2.6.2.10. () Control de Acceso:

() De nivel 2: (basado en direcciones MAC)

() De niveles 3/4 (basado en IP y en protocolos)

() Aislamiento de clientes a nivel 2.

() Control de acceso a la interfaz de gestión.

2.6.2.11. () Wireless Instrusion Detection (WIDS):

() Detección de puntos de acceso “rogue”.

() Prevención de ataques DoS.

() Detección de ataques Evil-twin y AP spoofing.

() Detección redes ad-hoc.

() Protección frente a “password guessing”.

2.6.3. Entregables

2.6.3.1. Documento con la consultoría jurídico/técnica que recoja al menos:

La normativa aplicable a las redes de comunicaciones de

gestión pública.

Las diferentes posibilidades que tiene la Entidad Local de

prestar el servicio y las acciones necesarias para cada una de las

modalidades de prestación.

Los elementos de seguridad lógica que debe tener en cuenta

la Entidad Local para la prestación del servicio.







Pág. 119 de 243



Exp.093/16-AE

2.6.3.2. () Análisis y diseño de la solución y sus componentes.

Documento de análisis: definición del sistema, requisitos

Documentación de diseño: arquitectura, modelo de datos,

diseño de red, descripción de los casos de uso, especificación de

las pruebas, diseño de las integraciones

2.7. Componente 6. Aplicaciones móviles

2.7.1. Componente 6.1 Entorno Web

El objeto del presente componente es el desarrollo de un entorno web que unifique

en un único punto la administración de todas las aplicaciones licitadas en el

Componente 6 así como el frontend de las aplicaciones que lo requieran para su

acceso vía web.

2.7.1.1. () La autenticación de usuarios se realizará a través del sistema de


2.7.1.2. () Se ofrecerá un entorno web que proporcionará acceso (en base

a los perfiles/roles de los usuarios) a los entornos de

administración de las aplicaciones el usuario gestione o a la parte

pública de las aplicaciones en las que el usuario se haya registrado

y/o tenga permiso de uso.

2.7.1.3. () El backend incorporará un módulo de administración de usuarios

para gestionar el listado y los permisos de los mismos.

2.7.1.4. () El backend incorporará una funcionalidad de alta masiva de

usuarios así como funcionalidad para verificar y aprobar los

usuarios cargados de esta forma, la validación será individualmente

o de grupos de usuarios.

2.7.1.5. () Para cada una de las aplicaciones incluidas en el entorno web, el

componente permitirá realizar las funciones de administración







Pág. 120 de 243



Exp.093/16-AE

necesarias para su correcto funcionamiento en base a las

especificaciones definidas para cada una de ellas




de la información según lo estipulado en el ENS.




Módulo de administración de la Lanzadera.

2.7.1.8. () El backend permitirá administrar los contenidos publicados en la

aplicación.

2.7.1.9. () El backend guardará un inventario de las aplicaciones móviles

municipales, en sus distintas versiones publicando la versión

adecuada de acuerdo al criterio del administrador.

2.7.1.10. () El administrador podrá dar de alta nuevas aplicaciones u ocultar

aplicaciones obsoletas.

2.7.1.11. () El administrador tendrá capacidad de publicitar aplicaciones

externas incluyendo el enlace a su página de descarga cuando éstas

sean de interés para el Ayuntamiento.

Módulo de administración de la aplicación de gestión de autobuses.

2.7.1.12. () Desde el módulo de administración existirá un módulo de control

de usuarios donde se podrán definir usuarios administradores con

distintos permisos para realizar las tareas de gestión del servicio.

2.7.1.13. () El módulo de administración permitirá la creación, borrado,

ocultación, y modificación de rutas.







Pág. 121 de 243



Exp.093/16-AE

2.7.1.14. () El módulo de administración permitirá modificar de forma

temporal rutas de autobuses definiendo nuevas rutas y/o paradas

que se creen por necesidades del servicio pudiendo en todo

momento deshabilitar esta modificación y recuperar la ruta inicial.

2.7.1.15. () El alta de nuevas paradas o puntos de interés podrá realizarse

introduciendo la dirección o ubicando la situación de la misma en un

mapa.

2.7.1.16. () Para los puntos de interés se deberá dar de alta la información

asociada al mismo: nombre o razón social, dirección, teléfono,

dirección de correo electrónico, página web, descripción del

servicio ofertado.

2.7.1.17. () Los POI municipales serán dados de alta de forma fija mientras

que los POI extendidos serán dados de alta por un periodo de

tiempo o de forma indefinida en base al criterio del administrador,

pudiendo ser borrados o desactivados.

2.7.1.18. () El módulo de administración debe disponer de un planificador

que permita programar alertas para eventos que se conozca que se

vayan a producir por ejemplo cortes por eventos deportivos. Esta

programación podrá ser puntual o periódica (por ejemplo corte de

una calle por un evento –p.e. un mercado- semanal).

2.7.1.19. () El módulo de administración debe permitir recibir peticiones o

consulta por parte de los usuarios a las que se emitirá una

respuesta automática indicando que está siendo gestionada y

permitirá establecer una comunicación posterior ofreciendo

información sobre la resolución de su consulta. Del mismo modo

debe permitir redirigir su consulta a una dirección de correo

electrónico desde la que se realizará la gestión.

2.7.1.20. () Se permitirá la emisión de comunicaciones push ofreciendo al

usuario información de interés del Ayuntamiento, el estado del

servicio o cualquier otro tema que resulte de interés.







Pág. 122 de 243



Exp.093/16-AE

2.7.1.21. () El módulo de administración recibirá las peticiones de objetos

perdidos por parte de los usuarios permitiendo realizar las

gestiones pertinentes sobre el mismo.

Módulo de administración de la aplicación ciudadana

Se realizará el diseño, construcción y puesta en producción de una aplicación en la

que los ciudadanos podrán dar de alta incidencias en el mobiliario urbano o en

infraestructuras. Adicionalmente la aplicación servirá para que los responsables de

resolver las incidencias puedan hacer seguimiento y actualización de las mismas, a

través de una Plataforma de Movilidad Multidispositivo.

Dicha plataforma contará con un backend en el que se debe permitir el diseño de

flujos de trabajo, la creación de plantillas y la integración con sistemas ERP a

través de APIs de forma que se puedan movilizar los distintos procesos

municipales que requieran soporte en campo sin intermediación de terceros. Las

especificaciones mínimas del mismo son las siguientes.

2.7.1.22. () El backend debe contar con un módulo de administración de

usuarios, roles y permisos basado en el entorno de usuarios

definido en el apartado 2.1.6. Este módulo permitirá asignar

permisos a usuario y asignarlos a departamentos y/o tareas.

2.7.1.23. () El sistema implementará mecanismos de seguridad que

permitan a partir de los diferentes roles de acceso, la visualización

de la información, así como auditoría y trazabilidad de todas las

acciones realizadas.

2.7.1.24. () El backend contará con un módulo que permita definir la

tipología de eventos a gestionar incluyendo el

departamento/usuario responsable, los métodos posibles de

comunicación (correo electrónico, sms, etc), tiempo estimado de

resolución.

2.7.1.25. () El backend debe disponer de un módulo de definición de

procesos que permita definir flujos de trabajo estableciendo pasos,







Pág. 123 de 243



Exp.093/16-AE

puntos de verificación, comunicaciones, personas/departamentos

responsables, métodos de comunicación/notificación, etc.

2.7.1.26. () Estos procesos podrán definirse desde cero, a partir de

plantillas predefinidas o duplicando un procedimiento existente que

se podrá duplicar.

2.7.1.27. () El backend revisará periódicamente los eventos pendientes y

para cada uno de los que hayan alcanzado a su tiempo estimado de

solución enviará una comunicación a los responsables para que

informen del estado del trabajo.

2.7.1.28. () El backend recogerá las peticiones de la aplicación móvil por

parte de ciudadanos/operarios sobre trabajos nuevos o en curso

actualizando el sistema y generando los avisos oportunos de

acuerdo a los procedimientos definidos.

2.7.1.29. () El backend permitirá anexar documentación adicional a

incidencias abiertas, permitiendo además establecer un canal

adicional con el creador de la incidencia para obtener información

adicional.

2.7.1.30. () El backend contará con un módulo de administración que

permitirá revisar los trabajos existentes y realizar las acciones

oportunas: reenviar, reasignar, resolver, marcar como duplicado

indicando la referencia de la incidencia original.

2.7.1.31. () El backend permitirá la localización visual de las incidencias en

un mapa.

2.7.1.32. () A los encargados/responsables de subsanación de las

incidencias el sistema le permitirá imprimir partes de trabajo con la

información de la misma.

2.7.1.33. () El backend permitirá a usuarios del mismo el dar de alta

incidencias en el sistema.







Pág. 124 de 243



Exp.093/16-AE

2.7.1.34. () Tras la resolución de una incidencia original debe cerrar todas

las incidencias asociadas con la misma que hayan sido resueltas por

la incidencia original.

2.7.1.35. () El Backend podrá realizar notificaciones vía SMS, correo

electrónico y/o notificación push a los usuarios del sistema, para

ello se integrará con los sistemas centralizados del Ayuntamiento.

2.7.1.36. () El Backend permitirá realizar búsquedas de incidencias, por tipo,

operario, estado, departamento, rango de fechas, etc. permitiendo

generar informes y cuadros de mando con los resultados de la

misma.

2.7.1.37. () El Backend permitirá realizar la trazabilidad de los operarios

(sean internos o externos) a través de los dispositivos, líneas o

informes de operación.

2.7.1.38. () El backend pondrá a disposición de la plataforma de ciudad una

API de forma que ésta pueda recuperar información para alimentar

sus sistemas de forma periódica.

2.7.1.39. () Se definirán un conjunto de APIs que servirán como base para la

integración futura con la herramienta ERP del Ayuntamiento,

aunque esta integración estará fuera del alcance del presente

concurso el licitador deberá entregar documentación respecto a los

desarrollos realizados para facilitar esta tarea.

2.7.1.40. () El sistema contará con un interfaz web público (frontend) que

informe a los ciudadanos del estado de las incidencias permitiendo

realizar un filtrado por tipo de incidencia, estado, etc.

2.7.1.41. () El Frontend permitirá dar de alta incidencias a través de un

formulario en el que como mínimo incluirá:

Tipo de incidencia

Breve descripción







Pág. 125 de 243



Exp.093/16-AE

Fotografía o archivo (opcional)

Localización.

Módulo de administración de la aplicación de guiado a aparcamientos.

2.7.1.42. () El acceso a esta aplicación estará limitada a usuarios con

permiso habilitado para gestionarla.

2.7.1.43. () El administrador tendrá la posibilidad de gestionar la

información de los aparcamientos municipales. De esta forma

tendrá capacidad para dar de alta, baja o modificar la dirección,

datos o número de plazas disponibles.

2.7.1.44. () El administrador podrá registrar plazas en base a su tipología

ofreciendo información separada de plazas reservadas para

personas con minusvalías de plazas para el público general, deberá

permitir definir otras tipologías de plazas como por ejemplo plazas

reservadas o con preferencia para personas con dificultad de

movilidad (ancianos, mujeres embarazadas, personas con muletas)

que no tengan reconocida una minusvalía permanente.

2.7.1.45. () La aplicación debe definir un estándar de comunicación (en

relación a los datos que necesita para su gestión) de forma que se

puedan integrar a futuro otros parkings que proporcionen esa

información de forma automática.

2.7.1.46. () El administrador podrá dar de alta nuevos aparcamientos

registrando sus datos en la aplicación.

2.7.1.47. () El administrador podrá deshabilitar un aparcamiento de forma

temporal cuando este no esté disponible por algún de forma

temporal (mantenimiento, obras, cerrado el acceso por eventos,

etc),







Pág. 126 de 243



Exp.093/16-AE

2.7.1.48. () El administrador podrá programar con antelación alguna de las

situaciones descritas que se activarán y desactivarán en las fechas

que el administrador establezca.

2.7.1.49. () Se ofrecerá un servicio web/widget que ofrezca información

sobre la disponibilidad de las plazas de aparcamiento en lo parkings

de la ciudad que podrán ser publicadas en las distintas páginas

municipales.

2.7.1.50. () A partir de la información de afluencia, disponibilidad,

ocupación, etc, el sistema realizará informes que podrán ser

utilizados en la toma de decisiones, estos informes serán generados

en PDF, texto, csv, Excel entre otros

2.7.1.51. () A partir de la información indicada en el apartado anterior el

sistema generará un dataset que podrá ser publicado en el portal

de transparencia y datos abiertos para su uso por los reutilizadores

de información del sector público.

2.7.2. Componente 6.2 Lanzadera

El objeto del presente componente es ofrecer un acceso unificado a las

aplicaciones municipales y a aquellas que el Ayuntamiento considere que debe

promocionar.

2.7.2.1. () La autenticación de usuarios se realizará a través del sistema de

autenticación definido en el apartado 2.1.6

2.7.2.2. () El componente estará compuesto por una aplicación móvil que

cumpla los requisitos definidos en el apartado 2.1.6 y un sistema de

gestión web ya descrito en el Componente 6.1.

2.7.2.3. () Dentro de este componente existirán dos roles predefinidos:

usuario y administrador, pudiendo tener distintos permisos cada







Pág. 127 de 243



Exp.093/16-AE

uno de ellos en base a las aplicaciones que el usuario administre o

tenga descargadas.

2.7.2.4. () El componente ofrecerá navegación por las listas, diferenciadas,

de aplicaciones móviles del Ayuntamiento y aplicaciones móviles

recomendadas o de terceros.

2.7.2.5. () Para cada aplicación en dicha lista se mostrará el detalle o ficha

de cada aplicación, con el contenido explicativo o promocional

mantenido por personal municipal

2.7.2.6. () La invocación de la aplicación desde su ficha y/o desde la lista

provocará las siguientes de acciones

Si la app ya ha sido instalada se abre de la forma

habitual

Si no está instalada se invoca la ficha de la app en

App Store / Play Store

2.7.2.7. () La aplicación ofrecerá la posibilidad de generar y emitir

notificaciones push para indicar al usuario (centro de notificaciones

y globo en el icono de la app) las nuevas aplicaciones incorporadas

al catálogo.

2.7.2.8. () La aplicación guardará en local el catálogo de aplicaciones

ofrecidas por la aplicación lanzadera, con el nombre, identificador

único URI de cada app, y contenido de la ficha proporcionados por

el personal del Ayuntamiento. a través de la web de gestión, en el

arranque de la aplicación verificará si existen actualizaciones a las

mismas.

2.7.2.9. () La aplicación contará con una Splash screen: Pantalla inicial,

personalizada con la imagen institucional del Ayuntamiento en base

al perfil del usuario. Se mostrará durante el proceso de arranque y

carga inicial de la aplicación.







Pág. 128 de 243



Exp.093/16-AE

2.7.2.10. () La aplicación contará con una vista principal: Vista única que

mostrará el catálogo de aplicaciones disponibles, con un control

tipo pestañas para cambiar entre la lista de apps propias y la lista

de apps de terceros o recomendadas.

2.7.2.11. () La aplicación contará con una vista de Ayuda: Vista que dará al

usuario unas indicaciones básicas de uso, como configurar las

notificaciones, y un acceso a la información legal y condiciones del

servicio.

2.7.2.12. () La configuración de las notificaciones se ha de realizar, de

forma estándar, en las configuraciones propias del sistema

operativo, donde aparecerá el municipio entre la lista de apps

disponibles. En su instalación, el sistema operativo solicitará

permiso al usuario para la activación de las notificaciones sin

necesidad de ir a dicha pantalla de configuración, a la que se podrá

volver en cualquier momento para modificar las preferencias del

usuario.

2.7.3. Componente 6.3 Autobuses

Actualmente el Ayuntamiento de Badajoz cuenta con 22 líneas de autobuses.

Salvo excepciones las líneas diurnas circulan desde las 7:00 de la mañana hasta las

11:00 de la noche y las nocturnas de desde las 11:00 de la noche hasta las 4:00 de la

madrugada

Se pueden observar las líneas y sus recorridos en la imagen adjunta:







Pág. 129 de 243



Exp.093/16-AE

Por otro lado el Ayuntamiento de Almendralejo no cuenta con un sistema de

gestión de autobuses, aunque se utilizará la información de los GPS del sistema de

gestión de flotas implantado con el componente 7.

El objeto de este componente es la creación de una aplicación móvil que permita a

los usuarios acceder al servicio de autobuses urbanos de un modo fácil y cómodo

proporcionando de una forma útil y muy sencilla, información en tiempo real de los

servicios prestados, ubicación de paradas, líneas de autobuses, tiempos de espera,

etc. El principal objetivo es ayudar al usuario del servicio de autobuses urbanos a

hacer un uso óptimo y facilitar el desplazamiento desde su ubicación actual al

punto de destino. De esta forma esta aplicación debe contar con los siguientes

requerimientos.

2.7.3.1. () La aplicación estará personalizada con el aspecto visual basado

en la guía de estilo definida en el apartado 2.1.4 para cada

Ayuntamiento en base al perfil del usuario que la utilice.

2.7.3.2. () La aplicación ofrecerá al usuario la situación de las distintas

líneas de autobuses urbanos de Badajoz y Almendralejo, así como







Pág. 130 de 243



Exp.093/16-AE

las paradas situadas sobre el propio mapa y la ubicación del

usuario.

2.7.3.3. () La aplicación debe ofrecer otras funcionalidades basadas en la

localización en tiempo real de los vehículos de las distintas rutas,

calculando el tiempo restante para que el próximo coche llegue a la

parada.

2.7.3.4. () La aplicación ofrecerá información sobre la frecuencia de paso

por las paradas en una línea.

2.7.3.5. () El usuario podrá generar y almacenar alertas sobre el paso de

un coche por una determinada parada en un rango de horarios y de

días de la semana, así podrá acomodar su rutina a los eventuales

cambios en el servicio de transportes.

2.7.3.6. () Para el Ayuntamiento de Badajoz la aplicación hará uso de un

servicio ya desplegado y en funcionamiento de reporte de última

parada de cada uno de los vehículos de cada una de las rutas. Este

servicio de acceso web es ofrecido por la empresa concesionaria,

teniendo el desarrollador (y por tanto el usuario) acceso directo y

API que permita ejecutar y recibir respuesta a las peticiones sobre

posición y vehículo. Las especificaciones se entregarán al inicio de

los trabajos pero a título informativo el servicio web suministrará

como mínimo la siguiente información:

Referencias para la geoposición del autobús en

plano.

Identificación del autobús y línea a la que

pertenece.

Tiempo de llegada del autobús a la parada más

próxima.

2.7.3.7. () Para el Ayuntamiento de Almendralejo se realizará una

integración de los datos proporcionados por el sistema de gestión







Pág. 131 de 243



Exp.093/16-AE

de flotas del componente 7 por la que se mostrará la posición de los

autobuses en tiempo real sobre un mapa local a partir de la

información de los GPS de los vehículos.

2.7.3.8. () Se desarrollarán servicios web de forma que la información de la

aplicación pueda ser explotada en otras aplicaciones (como la

aplicación de ciudadanía) o en la web municipal y en la plataforma

Smart.

2.7.3.9. () La aplicación mostrará un mapa centrado en la posición del

usuario con un nivel de zoom predeterminado sobre todo el área

metropolitana de servicio.

2.7.3.10. () Sobre el mapa mostrado en la aplicación el usuario podrá activar

o desactivar las siguientes capas.

Líneas de autobuses: Se representarán en

diferentes colores las distintas líneas que están

operando. Además de representar sobre el mapa

las líneas, se muestra un listado con su número y

descripción, para facilitar su localización.

Paradas: Paradas de autobuses y líneas que operan

en ellas.

POI públicos: Directorio de lugares de interés

público situados en el mapa.

2.7.3.11. () La aplicación ofrecerá las siguientes funciones sobre el mapa.

Búsqueda paradas cercanas

Rutas más corta entre localización de usuario y

otro punto del mapa seleccionado

Dirección obtenida por buscador de calle o POI







Pág. 132 de 243



Exp.093/16-AE

2.7.3.12. () Una vez definida y obtenida la ruta se ofrece la siguiente

información:

Tiempo total hasta el destino separado en: Tiempo

hasta la primera parada y Tiempo hasta destino

Trazado en mapa.

2.7.3.13. () El usuario podrá seleccionar en el mapa o buscar una parada

concreta y para ella se ofrece información sobre las líneas que la

cruzan, así como del tiempo restante estimado hasta próximo

coche (por línea). Además se ofrece detalles relevantes como calle

y número.

2.7.3.14. () El usuario registrado podrá establecer alertas sobre la llegada

de un coche de una determinada línea a una parada concreta con

los siguientes parámetros: Parada, línea, días de semana y minutos.

2.7.3.15. () La aplicación mostrará información sobre las incidencias que

afecten al servicio prestado.

2.7.3.16. () La aplicación tendrá preconfigurado un conjunto de POI

facilitados por los Ayuntamientos entre los que se encuentren los

principales monumentos, servicios públicos, etc.

2.7.3.17. () La aplicación dispondrá de un directorio de POI extendido donde

empresas y negocios podrán incluir su negocio.

2.7.3.18. () La aplicación debe tener una funcionalidad para que los usuarios

puedan solicitar la creación, modificación y borrado de un POI

extendido.

2.7.3.19. () La aplicación ofrecerá al usuario información de las paradas

cercanas al punto en el cual se encuentra.

2.7.3.20. () La aplicación ofrecerá información sobre las tarifas aplicables

para el uso del servicio de autobuses







Pág. 133 de 243



Exp.093/16-AE

2.7.3.21. . () La aplicación establecerá un canal a través del cual el usuario

podrá recibir y/o comunicar incidencias relacionadas con el

servicio.

2.7.3.22. () El usuario podrá seleccionar paradas favoritas que serán

guardadas en su aplicación para una rápida consulta.

2.7.3.23. () Comunicación de objetos perdidos en autobuses a través de la

aplicación móvil proporcionando automáticamente toda la

información disponible (autobuses en los que el usuario ha viajado,

fecha, hora, etc).

2.7.4. Componente 6.4 Aplicación de atención ciudadana

Se realizará el diseño, desarrollo y puesta en producción de una aplicación en la

que los ciudadanos podrán dar de alta incidencias en el mobiliario urbano o en

infraestructuras. Adicionalmente la aplicación servirá para que los responsables de

resolver las incidencias puedan hacer seguimiento y actualización de las mismas, a

través de una Plataforma de Movilidad Multidispositivo.

Se implantará una plataforma que permita el diseño de flujos de trabajo, la

creación de plantillas y la integración con sistemas de backend a través de APIs de

forma que se puedan movilizar los distintos procesos municipales que requieran

soporte en campo sin intermediación de terceros, no es objeto de la licitación la

integración con estos sistemas de backend. Se considera que el uso será

fundamentalmente interno de forma que debe primar la usabilidad y el número de

dispositivos sobre los que funcione el app frente a otros criterios.

2.7.4.1. () La aplicación podrá trabajar con información online o en local

cuando no haya cobertura, almacenando la información necesaria

para sincronizarse cuando se recupere esta conexión

2.7.4.2. () En el arranque, la aplicación se conectará al servidor que

proporciona el servicio a la aplicación dónde verificará la validez de

la información almacenada en lo que se refiere a los procesos de







Pág. 134 de 243



Exp.093/16-AE

gestión de incidencias y el estado de las incidencias asignadas

al/notificadas por el usuario.

2.7.4.3. () La aplicación contará con un acceso a través de perfiles cada

uno con acceso exclusivo a la información a la que tenga permiso,

como mínimo se contará con perfiles de Ciudadano, Administrador,

Operario interno, Operario externo gestionando el acceso a través

del sistema de autenticación definido en el apartado 2.1.6

2.7.4.4. () La aplicación podrá hacer uso de otros elementos del teléfono

móvil: cámara, gps, etc solicitando autorización para ello en el

proceso de instalación / actualización de la aplicación.

2.7.4.5. () La aplicación permite que cuando un ciudadano observe una

incidencia en el mobiliario o infraestructura de la ciudad pueda

capturarla a través de un sencillo formulario clasificándola en base

a una categorización predefinida. Permitirá adjuntar imágenes del

suceso, y almacenará la ubicación GPS de la incidencia.

2.7.4.6. () Se permitirá que usuarios sin autenticar den de alta incidencias.

2.7.4.7. () La aplicación guardará un listado de las incidencias

comunicadas por el usuario indicándole el estado de la misma.

2.7.4.8. () El sistema realizará la trazabilidad de la incidencia reportando

las actualizaciones a los responsables y a la persona que la haya

notificado. El usuario podrá configurar la forma en la que prefiere

recibir esas notificaciones: vía notificaciones push, sms o correo

electrónico.

2.7.4.9. () Los operarios municipales o de empresas externas a través de la

aplicación móvil o en la web podrán actualizar el estado e incluso

incorporar imágenes o documentación a la incidencia en el proceso

de subsanación o cuando la hayan solucionado para documentar

este hecho.







Pág. 135 de 243



Exp.093/16-AE

2.7.5. Componente 6.5 Aplicación móvil de guiado a aparcamientos

El objeto del Componente 6.5 consiste en el desarrollo y puesta en producción de

una aplicación móvil básica de guía y localización de plazas de aparcamiento

disponibles para los ciudadanos en los parking municipales.

Los requisitos técnicos mínimos de la aplicación son los siguientes.

2.7.5.1. () La aplicación debe ofrecer en tiempo real la Información de la

disponibilidad de plazas en las bolsas de aparcamiento en superficie

de la ciudad proporcionada por los aplicativos de gestión de

aparcamientos del componente 11.

2.7.5.2. () En el arranque de la aplicación la aplicación se conectará al

servidor dónde verificará la validez de la información almacenada

en lo que se refiere a parking y tarifas, actualizándola si fuera

necesaria.

2.7.5.3. () Adicionalmente debe mostrar información de plazas de 3

parking públicos.

2.7.5.4. () La aplicación indicará las tarifas vigentes según tipo de zona de

aparcamiento o parking

2.7.5.5. () La aplicación debe mostrar un plano de situación e indicación de

ruta hacia el parking que haya seleccionado el usuario

2.7.5.6. () De cara el guiado al parking seleccionado la aplicación ofrecerá

un modo de guiado a plaza vía GPS con indicación vocal

2.7.5.7. () Durante el trayecto la aplicación verificará la existencia de

plazas en el aparcamiento seleccionado. Verificará cada 10 minutos

si en el aparcamiento existen más de 10 plazas disponibles, cada 5

minutos si existen entre 5 y 10 plazas disponibles y cada minuto si

existen 5 o menos plazas disponibles.







Pág. 136 de 243



Exp.093/16-AE

2.7.5.8. () En caso de que en el trayecto se ocupen las plazas disponibles la

aplicación comunicará este hecho al usuario y ofrecerá plazas de

parking alternativas en el aparcamiento más cercano al destino del

usuario.

2.7.5.9. () El usuario podrá configurar sus preferencias indicando entre

otros datos su preferencia a utilizar plazas reservadas a personas

con minusvalías.

2.8. Componente 7. Gestión de flotas

El objeto del Componente 7 es la creación de un sistema de gestión y seguimiento

de flotas que permita optimizar el parque de vehículos municipal y que dé

respuesta a problemas ligados a:

Visualización de los vehículos para su localización y seguimiento

Ahorro y productividad a través de la reducción de costes, la planificación y

la optimización de recursos

Sostenibilidad mediante el cumplimento de normativa medioambiental

Información al ciudadano de la prestación de servicios asociados a la flota.

Los trabajos a desarrollar consistirán en el suministro e instalación de dispositivos

de seguimiento en los vehículos de flota municipales, el suministro e implantación

de un sistema de gestión para el seguimiento de estos vehículos, incluyendo un

conjunto de APIs para que los datos de los mismos puedan ser explotados desde

otros servicios municipales.

La relación de vehículos a instalar estará compuesta por turismos, furgonetas,

vehículos industriales y autobuses, el inventario de vehículos definitivo será

facilitado al inicio de los trabajos, a modo informativo se detalla en el Anexo I el

listado provisional de vehículos.







Pág. 137 de 243



Exp.093/16-AE

Almendralejo (29 vehículos)

Badajoz (25 vehículos)

Características técnicas

2.8.1. Componente 7.1. Dispositivo GPS

Los dispositivos instalados en los vehículos deben tener las siguientes

características técnicas mínimas.

() Instalación Plug-&-Play al puerto de control del vehículo

() Ayuda al conductor en el vehículo con incorporación de alertas sonoras

() Obtención de datos del vehículo en tiempo real

() Tiempo rápido de adquisición de señal GPS

() Indicadores luminosos de diagnóstico del dispositivo

Más concretamente los requisitos técnicos mínimos que el dispositivo GPS debe

tener son los siguientes:

2.8.1.1. () El dispositivo dará soporte a los interfaces para la gestión del

motor que sean necesarios para la integración con los vehículos

objeto de instalación descritos en el Anexo I.

2.8.1.2. () El dispositivo dará soporte a los siguientes interfaces de

Entrada/Salida

Timbre

LED: Arranque, GPS, dispositivo móvil

Soporte IOX, debiendo soportar hasta 4 extensiones simultáneas

entre las que se pueden incluir,







Pág. 138 de 243



Exp.093/16-AE

o Identificación del Conductor

o Horas de servicio (HOS)

o Dispositivos Garmin o de características similares.

o Puerto de serie para la integración de un dispositivo de

terceros

2.8.1.3. () El dispositivo dispondrá de antenas GPS/móviles internas

2.8.1.4. () Respecto a las comunicaciones móviles como mínimo deberá

ofrecer acceso múltiple por división de código (CDMA). GSM/GPRS:

850/900/1800/1900 MHz

2.8.1.5. () Respecto a las funcionalidades GPS como mínimo el dispositivo

deberá aportar.

Dispositivo de 50 canales

En arranques en caliente y asistidos, el tiempo para la primera

posición deberá estar por debajo de 1 segundo

Motor GPS/SBAS híbrido (WAAS, EGNOS, MSAS)

Compatible con 3GPP

Incorporar A-GPS: Almanac diferencial

Incluir una precisión aproximada de 5 metros.

2.8.1.6. () El dispositivo incorporará un acelerómetro de 3 ejes con una

escala completa (±2g, ±4g, ±8g y ±16g), capaz de medir

aceleraciones con una tasa de salida de datos mínima de 100 Hz o

400 Hz.

2.8.1.7. () El dispositivo debe funcionar correctamente en un rango de

temperatura: de -20 a +70 °C







Pág. 139 de 243



Exp.093/16-AE

2.8.1.8. () El GPS debe dar soporte a voltaje compatible con los vehículos

listados en el Anexo I.

2.8.1.9. () Cumplimiento de certificaciones europeas para este tipo de

dispositivo (CE, WEEE, etc)

2.8.1.10. () El dispositivo debe permitir actualizaciones de firmware

2.8.1.11. () El dispositivo debe incluir un sistema de timbre en la cabina para

realizar avisos al conductor del vehículo.

2.8.1.12. () El sistema dispondrá de almacenamiento de memoria flash no

volátil, debiendo tener capacidad para almacenar un mínimo de

10.000 registros en modo apagado

2.8.1.13. () El sistema pondrá a disposición de la plataforma de gestión un

feed de datos que:

o Proporcione seguridad en el acceso

o Sea Ligera y escalable

o Permita realizar búsquedas por fechas.

o Permita el acceso a los datos disponibles en caché.

o Proporcione información tanto de datos calculados como

de datos no procesados.

o Permita acceder, obtener información sobre: vehículos,

estado de los vehículos, información sobre rutas, mapas,

logs, etc.

2.8.1.14. () Durante un periodo de 6 meses tras la aceptación de la puesta

en marcha del Componente 7, el adjudicatario tendrá que hacerse

cargo como parte de la solución, de la conexión/comunicaciones a

través de GPRS/3G/4G entre los elementos que conforman el

componente y la infraestructura de comunicaciones del







Pág. 140 de 243



Exp.093/16-AE

Ayuntamiento, posteriormente a estos 6 meses el Ayuntamiento se

hará cargo de la solución de conectividad.

2.8.2. Componente 7.2. Sistema de gestión

El sistema de gestión estará compuesto por una aplicación accesible a través de

navegador web que debe contar con las siguientes funcionalidades.

2.8.2.1. () Respecto a la localización y control de vehículos el sistema de

gestión cumplirá los siguientes requisitos mínimos.

Localización de los vehículos monitorizados en tiempo real.

Visualización de trayectos con posición segundo a segundo.

Visualización de tramos conducidos con exceso de velocidad.

Detectar vehículo más cercano a un punto / calle.

Creación de grupos.

Cuentakilómetros basado en GPS.

Control de tiempos de ralentí.

Gestión de áreas de control, permitiendo definir área geográfica,

horario y vehículos afectados por la misma.

Recogida de los principales parámetros del vehículo (para aquellos

vehículos que proporcionen esta información):

o Nº de bastidor

o Odómetro

o Uso de combustible

o Nivel de llenado y Consumo de combustible

o RPM







Pág. 141 de 243



Exp.093/16-AE

o Fallos de motor

Control de seguimiento de rutas de vehículos.

Establecimiento de permisos de visualización del seguimiento

definiendo vehículos con requisitos de seguridad específicos (de cara

a garantizar la seguridad de autoridades)

2.8.2.2. () Respecto a la seguridad, el sistema de gestión cumplirá con los

siguientes requisitos.

Gestión en tiempo real de alarmas, avisos vía SMS, Mail, etc.

Creación de alertas combinadas en base a todos los parámetros

medidos y definidos por la plataforma.

Posibilidad de incorporar botón de pánico.

Capacidad de localización en caso de robo.

A partir de los datos del acelerómetro: Detección de frenazos,

acelerones y giros bruscos y detección y reconstrucción de

accidentes.

2.8.2.3. () El sistema tendrá capacidad para la creación y exportación de

informes para el soporte en la toma de decisiones, cumpliendo con

los requisitos de seguridad y privacidad necesarios.

2.8.2.4. () Capacidad de exportar los informes en distintos formatos (PDF,

Excel, CSV, etc)

2.8.2.5. () El sistema ofrecerá a través URLs y de servicios web el acceso a

funcionalidades y datos específicos que puedan ser mostrados en

portales de los Ayuntamientos.

2.8.2.6. () El licitador proporcionará acceso a manuales de desarrollo que

incluyan ejemplos para facilitar el uso y la integración de las API en

otros servicios municipales.







Pág. 142 de 243



Exp.093/16-AE

2.8.2.7. () Se deberán desarrollar API de cara a poner a disposición de la

plataforma Smart Alba definida en el Componente 10 los contenidos

del sistema de Control de Flotas.

2.8.2.8. () Capacidad para integrar información de dispositivos móviles en

la gestión de flotas siempre que estos tengan el hardware adecuado

(GPS)

2.8.3. Entregables


Documento de análisis: definición del sistema, requisitos e

interfaces de usuario


descripción de los casos de uso, especificación de las pruebas,

diseño de las integraciones

2.8.3.2. () Construcción o puesta a disposición de la solución

Código fuente correctamente documentado, en caso de que

haya habido desarrollo de software

Paquetes desplegables e instalables de la solución

desarrollada o puesta a disposición

Manuales de instalación, administración y usuario

Informe de instalación de los componentes.

Informe de resultados de los casos de prueba

2.9. Componente 8. Control de afluencia

El Componente 8 tiene por objeto el suministro e implantación de un sistema que

permitirá la captura de información de datos de visitantes en puntos de interés en

los municipios de Almendralejo y Badajoz. A partir de estas capturas el sistema







Pág. 143 de 243



Exp.093/16-AE

proporcionará información sobre el uso de las instalaciones y los datos de

ocupación de las mismas.

Este control de afluencia se basará en implantar sistemas de control de entradas y

salidas de personas de edificios sin necesidad de introducir elementos mecánicos y

estarán destinados a controlar el flujo de personas en enclaves turísticos

relevantes.

Las ubicaciones contempladas son las siguientes.

Almendralejo (1 sensor de control de presencia) : Museo de las Ciencias del

Vino

o Dirección: C. Ciudad de Rubi, S/N. Almendralejo.

Badajoz (4 sensores de escaneo wifi/bluetooth) : Se indicará su ubicación

durante la ejecución del proyecto

2.9.1. Requisitos técnicos mínimos.

Ayuntamiento de Badajoz

Dado que en el Ayuntamiento de Badajoz ya existe una solución implantada de

control de presencia a través del aplicativo POPTEC, descrito en el apartado 1.3, el

objeto de este componente es proveer de 4 sensores para su implantación en las

ubicaciones definidas por el Ayuntamiento, así como su integración en el sistema.

El Ayuntamiento proporcionará información para la correcta configuración de los

sensores en el entorno de producción. Los sensores deben cumplir los siguientes

requisitos técnicos mínimos.

2.9.1.1. (√) Los elementos ofertados por el licitador deberán ser totalmente

compatibles e integrables con los elementos existentes en el

Ayuntamiento de Badajoz descritos en el apartado 1.3, Situación







Pág. 144 de 243



Exp.093/16-AE

Actual, sin requerir para ello ningún equipamiento, software,

licencia o prestación que no sea aportada por el adjudicatario; en su

defecto, el licitador incluirá en su oferta la sustitución de cualquier

elemento incompatible, por otro equivalente, hasta eliminar

cualquier incompatibilidad, de manera que las características,

capacidades y funcionalidades hardware y software de la

infraestructura resultante sean iguales o superiores a las

existentes en la actualidad.

2.9.1.2. (√) Conexión a la red eléctrica existente. Los puntos de conexión

eléctrica serán habilitados por parte del Ayuntamiento de Badajoz

en la ubicación de los elementos a implantar, de forma que el

adjudicatario únicamente, y en cuanto a la conexión eléctrica se

refiere, deberá conectarse a este punto de alimentación.

2.9.1.3. (√) Conexión a la red de datos existente. El Ayuntamiento proveerá

de conectividad a la red de datos en la ubicación donde se ubique el

equipamiento, el licitador usará preferiblemente este tipo de

conexión frente al uso de otros métodos que supongan un gasto

recurrente para el Ayuntamiento como tarjetas móviles. En caso de

no ser posible esta conectividad, durante un periodo de 6 meses

tras la aceptación de la puesta en marcha del Componente 8, el

adjudicatario tendrá que hacerse cargo como parte de la solución,

de la conexión/comunicaciones a través de GPRS/3G/4G entre los

elementos que conforman el componente y la infraestructura de

comunicaciones del Ayuntamiento, posteriormente a estos 6 meses

el Ayuntamiento se hará cargo de la solución de conectividad.

2.9.1.4. (√) El dispositivo electrónico debe tener la capacidad de

monitorización en tiempo real de señales WIFI y Bluetooth

2.9.1.5. (√) Capacidad de contar el número de dispositivos en un lugar y

tiempo determinado, sus entradas, tiempo de permanencia y salida,

así como el desplazamiento al ámbito de actuación de otro

dispositivo de monitorización del sistema.







Pág. 145 de 243



Exp.093/16-AE

2.9.1.6. (√) Capacidad de conexión al servidor mediante tarjeta Ethernet, o

tarjeta 2G/3G/4G

2.9.1.7. (√) Capacidad de seleccionar entre el tipo de comunicación a

escanear: Wifi, Bluetooth o ambas.

2.9.1.8. (√) Posibilidad de configuración del nodo a través de diversos

parámetros para adaptar los mismos a las necesidades de la red:

velocidad de transferencia, tamaño de paquetes, direccionamiento,

alarmas, así como la recepción de informes de estado tipo “log”

2.9.1.9. (√) Capacidad de conectar dispositivos externos a través de

conexiones de Entrada/Salida programables de forma que el

usuario pueda controlar un determinado elemento exterior o bien

recibir y gestionar una señal externa, muy útil para casos de

seguridad o alarma.

2.9.1.10. (√) Capacidad de equipar sistemas eléctricos de rearme

automático.

2.9.1.11. (√) Capacidad de comunicación con diferentes plataformas

contenedores de datos ya sean en Internet o de forma local

2.9.1.12. (√) Puerto de comunicaciones: RJ 45,Tarjeta SIM

2.9.1.13. (√) Protocolo de comunicaciones: TCP/IP

2.9.1.14. (√) Capacidad de comunicación con un ordenador PC

2.9.1.15. (√) Capacidad de memoria de almacenamiento de 2 GB

2.9.1.16. (√) Compatibilidad electromagnética: EN-55022-B

2.9.1.17. (√) Rango de temperatura de funcionamiento: -20ºC/50ºC

2.9.1.18. (√) Seguridad: WEP, WPA-PSK,HTTPS,SSH

2.9.1.19. (√) Antena: Omnidir/5dBi







Pág. 146 de 243



Exp.093/16-AE

2.9.1.20. (√) Protección mínima IP65 de acuerdo a la norma internacional IEC

60529

Ayuntamiento de Almendralejo

2.9.1.21. (√) La solución debe permitir conocer, con alta fiabilidad, el flujo de

entradas y salidas de personas, además de las pautas de circulación

sin necesidad de ningún elemento mecánico de control de acceso,

en el establecimiento donde esté instalada la solución.

2.9.1.22. (√) Conexión a la red eléctrica existente. El punto de conexión

eléctrica será habilitado por parte del Ayuntamiento de

Almendralejo en la ubicación de cada uno de los sensores de

presencia a implantar y del equipamiento necesario, de forma que

el adjudicatario únicamente, y en cuanto a la conexión eléctrica se

refiere, deberá conectarse a este punto de alimentación.

2.9.1.23. (√) Conexión a la red de datos existente. En la medida de lo posible

el Ayuntamiento proveerá de conectividad a la red de datos en la

ubicación donde se ubique el equipamiento, el licitador usará

preferiblemente este tipo de conexión frente al uso de otros

métodos que supongan un gasto recurrente para el Ayuntamiento

como tarjetas móviles. En caso de no ser posible esta conectividad,

durante un periodo de 6 meses tras la aceptación de la puesta en

marcha del Componente 8, el adjudicatario tendrá que hacerse

cargo como parte de la solución, de la conexión/comunicaciones a

través de GPRS/3G/4G entre los elementos que conforman el

componente y la infraestructura de comunicaciones del

Ayuntamiento, posteriormente a estos 6 meses el Ayuntamiento se

hará cargo de la solución de conectividad.

2.9.1.24. (√) El dispositivo de conteo de personas serán sistemas Ethernet IP

autónomos preferiblemente basados en inteligencia artificial, que

permiten obtener con máxima fiabilidad y almacenar los datos de







Pág. 147 de 243



Exp.093/16-AE

afluencia (bidireccional) en intervalos temporales no superiores a 5

minutos.

2.9.1.25. (√) La información de afluencia de un acceso en 1 día debe suponer

una carga de tráfico de red mínima asegurando la ausencia de

saturación en la red de comunicaciones.

2.9.1.26. (√) El sistema deberá cumplir la legislación vigente en lo que se

refiere a la LOPD respecto a la protección de datos / grabación de

imágenes

2.9.1.27. (√) El sistema estará compuesto por los siguientes elementos.

o Sensor de conteo

o Software gestor

o Servidor Central

o Ordenador de gestión

2.9.1.28. (√) El sensor de conteo es el elemento hardware ubicado en el

techo en las zonas de acceso o lugares estratégicos del

establecimiento donde se quiera realizar la medición del flujo de

visitantes. Es el encargado de contabilizar las entradas y salidas de

visitantes, y de enviar dicha información a una ruta predefinida al

Software Gestor para su tratamiento. Adicionalmente, dispondrá de

capacidad para almacenar en local la información de conteo de los

últimos 30 días.

2.9.1.29. (√) El sensor tendrá capacidad de conexión al servidor mediante

tarjeta Ethernet y opcionalmente WIFI y/o tarjeta 2G/3G/4G

2.9.1.30. (√) Alimentación con adaptador a corriente.

2.9.1.31. (√) El sensor contará como mínimo con los siguientes conectores:

Toma de CC, RJ-45 10/100 BASE-T

2.9.1.32. (√) Condiciones de funcionamiento: humedad relativa 10 – 80%,

Temperatura de -10º C a 50º C







Pág. 148 de 243



Exp.093/16-AE

2.9.1.33. (√) Comunicaciones: IP, TCP, DHCP

2.9.1.34. (√) Memoria: RAM/Flash interna (capacidad para 30 días a

intervalos de 5 minutos)

2.9.1.35. (√) Homologaciones: CE, FCC

2.9.1.36. (√) El alcance del conteo del sensor será la necesaria para ofrecer

el servicio en la instalación destino del mismo.

2.9.1.37. (√) El software gestor, es el software encargado de la gestión del

sistema. Este software estará encargado de la gestión del sensor

de conteo y el acceso a él de forma remota y obtendrá de forma

periódica la información de conteo del sensor.

2.9.1.38. (√) El software gestor almacena y clasifica los archivos de

información recibidos del sensor de conteo. La información

procesada estará accesible desde el PC a través de un interfaz web

para el conocimiento de datos de aforo de forma periódica.

2.9.1.39. (√) Pondrá a disposición de los usuarios una herramienta

estadística en entorno Web para la visualización de la información

de la afluencia.

2.9.1.40. (√) La aplicación controlará el acceso a través de usuario y

contraseña, al tratarse en este componente independiente no es

necesario que la autenticación esté integrada con el sistema de

autenticación definido en el apartado 2.1.6, por lo tanto debe incluir

un módulo para gestionar los usuarios y permisos.

2.9.1.41. (√) El sistema permitirá establecer un canal de acceso remoto

seguro para la administración del mismo.

2.9.1.42. (√) Debe permitir la gestión de diferentes perfiles de usuario con

acceso a específicas jerarquías de datos.

2.9.1.43. (√) Visualización de entradas, salidas, flujo, datos acumulados, etc…

con diferentes tipos de gráficos (líneas, barras) y tabla de datos

numéricos asociada.







Pág. 149 de 243



Exp.093/16-AE

2.9.1.44. (√) Visualización de días en intervalos horarios, comparativas de los

mismos, diferentes períodos temporales definidos, agregación por

día de la semana, etc…

2.9.1.45. (√) Visualización de períodos semanales, comparativas de los

mismos, agregación por semana del mes, etc…

2.9.1.46. (√) Visualización de meses o períodos mensuales, comparativas de

los mismos, agregación por mes del año, etc…

2.9.1.47. (√) Visualización de años y comparativas de los mismos.

2.9.1.48. (√) Datos en intervalos horarios configurables, cada 15 minutos o

cada hora, para cada una de las diferentes visualizaciones.

2.9.1.49. (√) Capacidad para definir informes configurables.

2.9.1.50. (√) Posibilidad de configuración de hora del cambio de día (ejemplo:

agregación de los datos por día de 5h a 5h).

2.9.1.51. (√) El sistema debe incluir un mecanismo (conector/servicio

web/etc) para proveer de datos a la plataforma ciudadana.

2.9.1.52. (√) El licitador incluirá en su oferta un servidor con capacidad para

dar servicio a la solución presentada, debiendo realizar una prueba

de carga para garantizar que el equipamiento ofertado es suficiente

para cubrir las necesidades del sistema.

2.9.1.53. (√) El licitador incluirá en su oferta un ordenador de sobremesa con

pantalla plana de tamaño mínimo 17’’, teclado y ratón con capacidad

suficiente para cubrir las necesidades del sistema.

2.9.2. Entregables.

2.9.2.1. () Documentación de diseño de los aplicativos

Documento de requisitos

Documento de diseño







Pág. 150 de 243



Exp.093/16-AE

Modelo de datos


pruebas que deberán incluir como mínimo, pruebas funcionales, de

diseño y de carga.

Documento de ejecución de las pruebas

Manual de instalación, administración y usuario.

2.10. Componente 9. Encuestas a Ciudadanía y visitantes

El objeto del presente componente es dotar a los Ayuntamientos de Almendralejo

y Badajoz de un mecanismo para recoger y valorar la opinión de los visitantes y

turistas. Así se pondrá a disposición del proyecto una herramienta de creación de

encuestas on-line accesibles a través de captura de QRs o hiperenlaces y un

conjunto de mecanismos de control y gestión de la respuesta.

2.10.1. Requisitos mínimos técnicos.

Para la valoración de las experiencias turísticas, los Ayuntamientos de Badajoz y

Almendralejo pondrán en servicio una solución de comunicación multicanal e

interactiva que permitirá a ambas entidades establecer un diálogo directo con sus

visitantes de manera rápida, libre y anónima en tiempo real.

Esta solución de comunicación permitirá poner en contacto al Ayuntamiento con

sus visitantes, permitiendo recoger y acceder a su opinión de forma:

Directa (sin ningún tipo de intermediarios).

Continua (24 x 7 x 365) y desde cualquier lugar.

Instantánea (en el momento que se produce la opinión ya se tiene

acceso a ella).







Pág. 151 de 243



Exp.093/16-AE

Segura (a través de una zona privada de acceso a las opiniones)

Los requisitos técnicos mínimos son los siguientes.

2.10.1.1. (√) El uso de la herramienta de administración estará restringida a

usuarios con permiso para ello. Esta gestión de permisos se

realizará a través del sistema de autenticación definido en el

apartado 2.1.6

2.10.1.2. (√) La herramienta de administración contará con la funcionalidad

necesaria para crear gestionar encuestas permitiendo la creación,

personalización, modificación o borrado de las mismas.

2.10.1.3. (√) El administrador tendrá la posibilidad de programar la

publicación de encuestas definiendo fecha de publicación y fecha de

finalización.

2.10.1.4. (√) El diseño de las encuestas debe permitir la segmentación de la

misma en páginas y/o secciones.

2.10.1.5. (√) Para la adquisición de información la encuesta permitirá la

recogida de datos:

Cuantitativos: Puntuación sobre calificadores (al menos selección

múltiple, checkboxes, lista desplegable, escala lineal, rejilla de

selección múltiple, fecha, hora).

Cualitativos: Mediante texto libre.

2.10.1.6. (√) La solución permitirá la comunicación bidireccional con los

participantes y deberá incluir un sistema completo de incentivos

(premios, promociones, cupones, etc.) totalmente configurable a

criterio de los Ayuntamientos para el desarrollo de este canal de

comunicación. A título de ejemplo (sin que suponga obligación o

vinculación alguna en el presente contrato): descuentos en

actividades de los polideportivos, agradecimiento en la web del

Ayuntamiento a las personas que más hayan aportado, etc.







Pág. 152 de 243



Exp.093/16-AE

2.10.1.7. (√) La solución permitirá la definición de varios tipos de incentivos

con distinto formato, incluyendo todos los datos necesarios para su

gestión, por ejemplo, fecha de validez y caducidad del incentivo,

fecha de publicación y de cancelación.

2.10.1.8. (√) La solución permitirá el alta, baja y modificación del incentivo

así como el seguimiento de la ejecución de la campaña (cupones

descargados, listado de cupones entregados, etc.).

2.10.1.9. (√) Los incentivos deben como mínimo permitir el control temporal

(inicio y fin de la campaña) y permitir la limitación del número de

incentivos entregados.

2.10.1.10. (√) La solución incorporará mecanismos para garantizar la validez

de los incentivos. Por ejemplo, en una entrega de entradas deberán

estar debidamente numeradas y/o asociadas a un usuario que se

pueda identificar de cara a gestionar el aforo.

2.10.1.11. (√) La solución permitirá incluir en el incentivo direcciones web y/o

códigos QR que permitan obtener información del mismo.

2.10.1.12. (√) La solución debe realizar una evaluación automática de opinión

de los encuestados:

Valoraciones cuantitativas: Mediante fórmulas

Valoraciones cualitativas: Mediante la objetivación de la opinión

emitida incorporando tecnología de procesamiento del lenguaje

natural. Esto permitirá identificar la polaridad del comentario (esto

es, si son positivas o negativas) en tiempo real

2.10.1.13. (√) La comunicación de la encuesta debe ser sencilla y permitir un

acceso multicanal (web, mail, etc) y multidispositivo (ordenador,

tableta, dispositivo móvil, etc).

2.10.1.14. (√) La distribución de las encuestas podrá realizarse a través de

URL, SMS, códigos BIDI/QR, correo electrónico o aplicaciones para

móviles.







Pág. 153 de 243



Exp.093/16-AE

2.10.1.15. (√) La solución debe permitir la personalización de la respuesta

hacia usuarios que han respondido la encuesta.

2.10.1.16. (√) La solución permitirá la presentación de los resultados de las

encuestas a través de un panel de control. Esta presentación ser

realizará de forma numérica o gráfica pudiendo el usuario elegir

entre distintos tipos de presentaciones.

2.10.1.17. (√) La información de la solución de comunicación deberá

integrarse dentro de la Plataforma Smart City de Badajoz y

Almendralejo descrita en el componente 10.

2.10.1.18. (√) La solución debe incluir mecanismos para el control del Spam.

2.10.1.19. (√) La solución permitirá la exportación de datos a través de

elementos que permitan la integración con los sistemas municipales

(html, xml, etc) y ficheros (pdf, Excel, csv, json, texto, etc)

2.10.1.20. (√) El licitador elaborará 5 encuestas para el Ayuntamiento de

Almendralejo y otras 5 para el Ayuntamiento de Badajoz

respectivamente, debiendo consensuar la temática y las preguntas

de la misma con la entidad local. Estas encuestas se publicarán en

la plataforma desarrollada en el presente componente en el periodo

de fechas que los Ayuntamientos estimen oportuno a lo largo de la

duración del contrato.

2.10.1.21. () El sistema dispondrá de mecanismos para poner a disposición de

la Plataforma Smart Alba los datos asociados a las encuestas

ejecutadas.

2.10.2. Entregables










Pág. 154 de 243



Exp.093/16-AE




Encuestas elaboradas en el marco del proyecto







2.11. Componente 10. Plataforma “Smart”

La Plataforma Smart constituirá el núcleo integrador del proyecto, permitiendo

interconectar todos los componentes y disponer de una visión única y gestión

integrada de la información (consumiendo y generando los datos de los diferentes

servicios y actividades), proporcionando así un mayor control sobre los procesos y

facilitando la toma de decisiones.

Esta actuación hay que entenderla como una solución llave en mano de

implantación de herramientas software que permitan la gestión horizontal de

servicios implantados en ambos municipios y deberá incluir todos los elementos

software, procedimientos para la lectura, recepción, transformación y extracción

de datos, cuadro de mando, capas de integración, publicación de información,

seguimiento y reporting necesarios para dar un servicio completo para los

Ayuntamientos de Almendralejo y Badajoz.







Pág. 155 de 243



Exp.093/16-AE

2.11.1. Funcionalidades y características principales de la Plataforma

Smart

2.11.1.1. () La plataforma a instalar e implantar deberá cumplir las

capacidades, funcionalidades y modelo de capas definido en la

norma UNE 178104:2015 basada en estándares abiertos, no

propietarios y estandarizado por organismos y consorcios

internacionales. El siguiente esquema recoge el modelo de capas

que deberá implementar la plataforma.

2.11.1.2. () El interfaz de usuario de la plataforma así como todos los

mensajes, alertas, popups, etc que muestre al usuario deben estar

en castellano.

2.11.1.3. () La plataforma deberá tener una alta escalabilidad permitiendo la

integración de nuevas fuentes de datos y nuevos servicios (capa de

servicios inteligentes), de modo que no sólo ofrezca soporte a los







Pág. 156 de 243



Exp.093/16-AE

servicios y fuentes de datos actuales sino que pueda evolucionar de

forma sencilla para la incorporación de nuevos servicios

inteligentes. Por ello el licitador en su propuesta deberá indicar qué

nuevos servicios es posible incorporar de forma inmediata a la

herramienta (gestión de residuos, movilidad urbana etc), así mismo

aportará información de los requerimientos de licenciamiento y

hardware necesarios para realizar este proceso de escalado para

diferentes escenarios de ampliación que incluyan al menos los

siguientes casos: (1) integración de un nuevo servicio con 100, 500

y 1000 sensores adicionales. (2) integración de 2 nuevos servicios

con 200, 1000 y 2000 sensores.

2.11.1.4. () La plataforma debe ser completamente horizontal en cuanto al

tratamiento de información ya que integrará esta información

desde diversos ámbitos y sistemas

2.11.1.5. (√) Capa de adquisición de datos: La plataforma permitirá la

integración con fuentes de datos diversos, entre ellos deberá ser

capaz de integrar entre otras la información proveniente de

sensores, información estructurada y no estructurada, información

proveniente de redes sociales, información proveniente de flujos de

datos (datastream), otros sistemas de gestión TI como SCADAS o

soluciones de gestión implantadas en los Ayuntamientos. Así

mismo:

Deberá incluir herramientas opensource con el fin de aumentar el

número de posibilidades de integración con la sensórica actual y

futura.

Permitirá la integración con protocolos estandarizados de

mensajería abierta M2M

Deberá ser independiente de la tecnología de acceso para lo que

deberá disponer de conectores específicos con los principales

protocolos utilizados en el mundo IoT entre ellos MQTT, MQTT-S,

CoAP, REST, XMPP.







Pág. 157 de 243



Exp.093/16-AE

Deberá permitir la adquisición de elementos multimedia (fotos,

audio, vídeo) que podrán incluir información de georreferenciación

asociada a los mismos.

Debe tener capacidad para trabajar con dispositivos conectados

por una red privada virtual (VPN). Los dispositivos conectados en

VPN sólo serán visibles desde la pasarela evitando accesos no

deseados desde internet.

Deberá suministrar la información a la capa de conocimiento con

independencia de los dispositivos dando una vista semántica de los

datos adquiridos, desacoplada de los protocolos de adquisición.

2.11.1.6. (√) Capa de Conocimiento: esta capa incluirá los elementos de

tratamiento, Gestión y Explotación de la información. Incluirá

módulos y funcionalidades que permitan:

Acceso a toda la información tanto histórica como en tiempo real

de esta forma podrá

o Identificar, analizar y reaccionar de forma inmediata a

patrones de eventos

o Disponer de una latencia mínima en la generación de

eventos

o Disponer de un motor de reglas asociadas a los patrones

Permitir el movimiento de datos entre las distintas capas

Soporte al tratamiento en tiempo real de los datos recibidos de la

capa de adquisición

Soporte al tratamiento Batch a través de procesos Extracción-

Transformación-Carga (ETL) y Machine Learning así como contar

con un motor Extracción-Carga-Transformación (ELT).

Disponer de un Componente de Big Data que proporcione:







Pág. 158 de 243



Exp.093/16-AE

o Capacidad de análisis y procesamiento de grandes

cantidades de datos

o Ejecución sobre clústeres de HW

o Se apoya en el almacenamiento de ficheros distribuido

o Permita la gestión de clústeres

Soporte al tratamiento analítico de los datos mediante

herramientas de BI.

Soporte al tratamiento GIS permitiendo georreferenciación y

consultas geográficas.

Seguridad al acceso de datos.

Semántica de ciudad con el fin de facilitar respecto a los datos la

interoperabilidad, la no dependencia de proveedores o servicios, la

escalabilidad y la apertura.

Se deberá suministrar la información a la capa de conocimiento

con independencia de los dispositivos dando una vista semántica

de los datos adquiridos, desacoplada de los protocolos de

adquisición.

2.11.1.7. (√) Capa de Interoperabilidad: Esta capa debe contar con una

catalogación e identificación de los servicios, mediante el uso de un

registro de servicios. El objetivo es independizar las aplicaciones de

la lógica de los servicios que necesitan, así como facilitar la

integración con los mecanismos actuales de control y seguimiento.

() Deberá incluir un Kit de desarrollo con SDK y APIs

() En cuanto a los requerimientos de seguridad, todas las APIs y la

invocación de servicios deberá estar securizada.

() Permitirá la interconexión entre aplicaciones y con otras

plataformas.







Pág. 159 de 243



Exp.093/16-AE

() Permitirá la publicación de datos integrándose con el portal de

datos abiertos y transparencia descrito en el Componente 4.

() Las APIs serán de fácil acceso y uso y estarán basadas en API-

REST

() Las APIs deberán soportar diferentes modos de acceso a los

datos incluyendo modo Push (subscripción y notificación) y Pull

(petición y respuesta). También deberá permitir consultas

georreferenciadas.

2.11.1.8. (√) Capa de Servicios: interactuará con la plataforma a través de la

capa de Interoperabilidad. Al menos incluirá los siguientes

servicios.

() Cuadro de mando e indicadores. Los requerimientos funcionales

de este servicio se desarrollan en el apartado 2.11.2

() Servicio de gestión de flotas. Los requerimientos funcionales de

este servicio se desarrollan en el apartado 2.8

() Servicio de gestión de puntos wifi. Los requerimientos

funcionales de este servicio se desarrollan en el apartado 2.6

() Servicio de gestión de control de afluencia. Los requerimientos


() Servicio de gestión de movilidad (plazas de garaje y guiado a

aparcamientos). Los requerimientos funcionales de este servicio se

desarrollan en el apartado 2.12

() Servicio de gestión de autobuses. Los requerimientos


() Servicio de gestión de aparcamientos Los requerimientos

funcionales de este servicio se desarrollan en el apartado 2.12 y

2.7







Pág. 160 de 243



Exp.093/16-AE

() Servicio de gestión de atención ciudadana. Los requerimientos


2.11.1.9. (√) Capa de Soporte: la plataforma deberá contar con una capa de

soporte que ofrezca al menos servicios de auditoría, monitorización

y seguridad.

2.11.1.10. () Deberá tener la capacidad de realizar una monitorización y

control de las actividades realizadas por los usuarios, generando

informes de actividad y auditorías de las actividades de cada

usuario o grupos de usuarios, con nivel de detalle como, por

ejemplo, el nivel de informes que consulta. Además, se debe tener

la posibilidad de generar informes de gestión que permitan ver, por

ejemplo, estadísticas de consulta de los informes. Todas estas

consultas relativas a la monitorización deben poder realizarse a

través de una interfaz que sea amigable y fácilmente utilizable por

el usuario.

2.11.1.11. () Deberá hacer uso de protocolos estándares de comunicación

con los dispositivos, no propietarios y estandarizado por

organismos y consorcios internacionales.

2.11.1.12. () Deberá poder enviar comandos de control, modificación de

configuración o actualización de software a los dispositivos

integrados.

2.11.1.13. () Deberá facilitar la integración con los mecanismos actuales de

control y seguimiento que disponga cada Ayuntamiento, a la vez de

proveer una consola de monitorización propia.

2.11.1.14. () El proceso de transformación de la información se realizará en

un área o base de datos intermedia de almacenamiento de la cual,

los datos, ya transformados, se descargarán a la zona de

repositorio de datos (data warehouse) del cual deben alimentarse

procesados posteriores o directamente la representación de los

datos obtenidos.







Pág. 161 de 243



Exp.093/16-AE

2.11.1.15. () La plataforma debe tener capacidad para integrarse con un

Sistema de Información Geográfica (GIS).

2.11.1.16. () La plataforma permitirá la integración con fuentes de datos

diversos, entre ellos deberá ser capaz de integrar la información

proveniente de los sensores a instalar objeto del presente convenio,

información estructura y no estructura, información proveniente de

redes sociales, información proveniente de datos movimiento (data

stream).

2.11.1.17. () La plataforma incluirá un sistema de gestión de usuarios con al

menos dos perfiles: perfil administrador y perfil de consulta. Los

usuarios se organizarán en función del Ayuntamiento al que

pertenezcan pudiendo solamente gestionar la información y los

elementos integrados en la plataforma que afecten a su

Ayuntamiento. No obstante existirán usuarios de administradores

de toda la plataforma. La gestión de usuarios estará integrada con

el sistema de autenticación definido en el apartado 2.1.6.

2.11.1.18. () Deberá recibir, tratar, visualizar, monitorizar y gestionar los

distintos servicios y sistemas que se integren proporcionando una

visión única y centralizada.

2.11.1.19. () Deberá ser capaz de integrar los dispositivos y gestionar la

información generada por los diferentes servicios que se describen

en los diferentes apartados de este pliego de condiciones técnicas,

permitiendo la gestión centralizada, e individualizada para cada uno

de los Ayuntamientos, de la información generada por la capa de

sensorización modularizada para cada servicio (parking, calidad de

agua, riego, gasto energético) así como por las diferentes entradas

de información procedentes de las fuentes disponibles.

2.11.1.20. () Deberá ser capaz de realizar una adaptación, si fuese necesaria,

del protocolo utilizado por los dispositivos, normalizándolo a un

lenguaje común para las aplicaciones que usen la información de la

plataforma.







Pág. 162 de 243



Exp.093/16-AE

2.11.2. Cuadro de mando integral:

La plataforma contará con un cuadro de mando integral particularizado para cada

uno de los Ayuntamientos que forma parte de esta iniciativa con las siguientes

características.

2.11.2.1. () La plataforma contará con una solución de Bussiness

Intelligence integrada que permita la generación de cuadros de

mando.

2.11.2.2. () La Herramienta de Cuadro de Mando ha de permitir la

explotación de los indicadores (KPIs) provenientes de los diferentes

sistemas servicios y sistemas que se integren en la plataforma,

para el análisis y seguimiento de sus diferentes servicios y sistemas

desde una perspectiva operativa.

2.11.2.3. () La interfaz deberá ser personalizable para cada usuario que

acceda a la misma, en función del ámbito al que pertenezca, perfil

del usuario, y otras configuraciones estéticas, idioma, etc. Las

preferencias que se definan para cada usuario deben mantenerse

cada vez que acceda el usuario a la Herramienta de Cuadro de

Mando.

2.11.2.4. () La Herramienta de Cuadro de Mando tiene que ser accesible vía

web, al menos para los usuarios generadores de informes y

usuarios consumidores de informes, para sus funcionalidades

básicas según se detalla más adelante. Para ello no debe requerir la

instalación de ningún software adicional al incluido en la propuesta.

Toda la funcionalidad de la Herramienta de Cuadro de Mando

relativa a estos usuarios como: realización de consultas, creación

de informes, creación de cuadros de mando, etc. debe estar

restringida a los permisos y las preferencias que tenga el usuario

que accede.







Pág. 163 de 243



Exp.093/16-AE

2.11.2.5. () La Herramienta de Cuadro de Mando debe poder explotar la

información integrada en la Plataforma.

2.11.2.6. () La Herramienta deberá proporcionar un repositorio que permita

almacenar de forma organizada, por ejemplo con estructura de

carpetas, todos los objetos y plantillas de los elementos que se

definan.

2.11.2.7. () Además, la Herramienta de Cuadro de Mando deberá

proporcionar un conjunto de elementos para los informes y

plantillas de informes y que la misma se pueda ir enriqueciendo con

la incorporación de elementos que se definan por parte de los

usuarios.

2.11.2.8. () El acceso a dicho repositorio y a los elementos depositados en

él, debe estar controlado por mecanismos de seguridad de acuerdo

con los permisos de los usuarios que accedan y sobre las acciones

que se realicen sobre los objetos, como por ejemplo, avisos

relativos a borrados de elementos, etc debiendo estar integrado

con el sistema de autenticación definido en el apartado 2.1.6

2.11.2.9. () Dependiendo de la naturaleza del objeto, un cambio en el mismo

ha de propagarse a los informes que hacen uso de él, por ejemplo,

un cambio en el valor de un indicador, de una dimensión, debe

actualizarse en todos los informes que lo utilicen, siempre que

dicha modificación se realice en los metadatos.

2.11.2.10. () Se requiere que al igual que los objetos del repositorio, los

informes generados puedan ser almacenados de forma organizada

según la estructura que defina el usuario con la autorización

correspondiente (por temas, por fechas, por prioridades, por áreas

geográficas o por cualquier otra categoría).

2.11.2.11. () La Herramienta de Cuadro de Mando debe permitir la consulta

de los datos históricos para su comparación con los datos, cuando

el usuario realice la consulta a través de las opciones habilitadas.







Pág. 164 de 243



Exp.093/16-AE

2.11.2.12. () Además, la Herramienta de Cuadro de Mando debe tener

capacidades para la administración de la misma, permitiendo

procedimientos de back-up, eliminación de objetos y elementos en

función de su antigüedad a partir de una determinada fecha

conforme a los criterios definidos por los usuarios administradores.

2.11.2.13. () Debe disponer de la funcionalidad de envío de alertas o avisos

que se distribuyan vía correo electrónico a los usuarios que se

considere oportuno en respuesta a eventos predefinidos, ya sean

faltas temporales de disponibilidad de la Herramienta de Cuadro de

Mando o mensajes de aviso en función de los eventos que se

determinen asociados a los indicadores, por ejemplo el envío de un

mensaje a los destinatarios definidos al sobrepasar un indicador un

determinado umbral.

2.11.2.14. () Características de los elementos generados por la Herramienta

de Cuadro de Mando: Los elementos generados por la Herramienta

de Cuadro de Mando son los entregables a través de los cuales se

pueda explotar y analizar la información como son los informes,

gráficos, cuadros de mando integrales, que agreguen indicadores a

nivel de análisis, seguimiento, estratégicos, etc. En adelante, los

distintos tipos de elementos generados por la Herramienta de

Cuadro de Mando se denominarán informes. A continuación, se

indican los requisitos mínimos que deben tener los informes

generados por la Herramienta de Cuadro de Mando.

2.11.2.15. () Los informes han de ser dinámicos y deben poseer filtros u otras

opciones de selección para el análisis de los indicadores

presentados en ellos. Los filtros permitirán al usuario seleccionar

las dimensiones que correspondan según el informe y que pueden

ser entre otros: dimensiones temporales (mes, trimestre, año etc.),

geográficas (Distrito, Barrio, Área, Sección, etc), ámbito

organizativo (Empresa, Área, etc.), por destinatario (ciudadanos,

empresas, etc)

2.11.2.16. En relación con la creación y edición de informes:







Pág. 165 de 243



Exp.093/16-AE

() Los informes podrán incorporar gran cantidad de elementos y

objetos y combinaciones de ellos, tales como: cuadros de texto,

mapas geográficos, mapas de barras, de relleno y mixtos (que

combinen las dos opciones anteriores), diferentes tipos de gráficos

(tales como columnas, barras horizontales, barras verticales,

líneas, circulares, dispersión o puntos, áreas, anillos, radial,

superficie, burbujas, cotizaciones, cilindro, cónico, piramidal en 2 y

3 dimensiones etc.).

() También se podrán crear informes que combinen objetos de

distintos informes ya definidos, por ejemplo, un informe 1 se podrá

generar añadiendo la tabla y el mapa geográfico del informe 2,

junto con el diagrama del informe 3, etc., permitiendo establecer

relaciones entre los elementos de los distintos objetos.

() Los informes podrán incorporar ítems calculados en tiempo real

y sin requerir desarrollo adicional para ello (por ejemplo suma de

los valores de dos indicadores).

() Un usuario con permisos para ello podrá crear plantillas de

informes que serán almacenadas en el repositorio de la

Herramienta de Cuadro de Mando para que estén disponibles para

otros usuarios que deseen generar un informe basándose en esa

plantilla. Las plantillas podrán ser adaptadas a las necesidades

concretas de cada usuario.

2.11.2.17. En relación con la consulta y visualización en navegadores web

convencionales, los informes:

Deben presentar la información que contengan actualizada en el

momento de la consulta o de la última actualización, con la

periodicidad establecida en los procesos correspondientes.

La Herramienta debe permitir la consulta de los informes que así

se determinen de forma “desconectada”. Es decir, si no hay acceso

a la Herramienta de Cuadro de Mando los informes que se







Pág. 166 de 243



Exp.093/16-AE

consulten seguirán manteniendo un cierto nivel de dinamismo y se

permitirá el filtrado u otras opciones de selección de las variables

que se definan. Si la visualización de los informes de forma

desconectada requiere software adicional, éste deberá estar

incluido en la propuesta del licitador.

2.11.3. Tareas a realizar

2.11.3.1. ()Todos los trabajos por parte del adjudicatario necesarios para

efectuar un Análisis Funcional y Técnico completo y exhaustivo que

permita acometer con éxito la implantación de la plataforma Smart,

el modelado de la base de datos analítica y la implantación del

cuadro de mandos sobre la plataforma de ciudad incluyendo la

creación de los informes definidos en el apartado 2.4.1 .

2.11.3.2. () Entre otras labores, el adjudicatario habrá de efectuar las

siguientes tareas:

toma de requisitos funcionales y técnicos,

despliegue y parametrización de la solución ,

pruebas (funcionales, de seguridad, pruebas de regresión y de

rendimiento),

labores de soporte a la implantación y configuración en los

diferentes entornos,

labores de formación y capacitación a usuarios y de generación,

actualización y gestión de manuales y documentación funcional y

técnica del sistema.

2.11.3.3. () Respecto al cuadro de mando el adjudicatario deberá:

A partir del plan de actuación elaborado en el Componente 3.1 apartado

2.4.1, donde se han identificado los indicadores para los diferentes

sistemas y fuentes de información que se integren en la plataforma. Se







Pág. 167 de 243



Exp.093/16-AE

realizará un análisis detallado de las fuentes de información origen,

formato de datos, definición de indicadores y metodología de

mantenimiento y gestión de los mismos.

Desarrollar una base de datos analítica que permita el almacenamiento

de los indicadores definidos. Esta base de datos podrá ser explotada

por la solución de Bussiness Intelligence de la Plataforma Smart por

cualquier otro componente de la plataforma que lo precise y será la

base del cuadro de mando integral.

El adjudicatario deberá proponer y generar el Modelo de Datos que

permita consolidar en un único repositorio destino, Datawarehouse

(que debería formar parte de la plataforma smart y ser una de las

piezas que la conformen), toda la información necesaria para la gestión

unificada e interrelacionada del subconjunto de indicadores del

Catálogo de Indicadores Municipal especificado, proveniente de las

distintas fuentes origen de datos que se identifiquen.

Se deberá realizar el diseño, creación e implantación del citado Modelo

de Datos, de forma que asegure la calidad e integridad de los mismos,

así como su seguridad y escalabilidad para, posteriormente, poder

explotarlos de una forma ágil y fiable.

El modelo diseñado deberá ser genérico y abstraerse de la estructura

de datos de los sistemas origen de información con el fin de aislarlo, en

la medida de lo posible, frente a los cambios que pudieran producirse

en las fuentes o sus datos.

El modelo diseñado ha de tener presente que la información deberá

almacenarse, como mínimo, al nivel de detalle que exijan los elementos

del Cuadro de Mando cuyo análisis funcional haya sido aprobado

durante la ejecución. Asimismo, deberá identificar y contemplar la

estrategia de almacenamiento más adecuada para llevar a cabo los

procesos de agregación, generación de campos calculados, etc. que

pudieran favorecer el rendimiento de las consultas previstas sobre la

Base de Datos Analítica de la Ciudad.







Pág. 168 de 243



Exp.093/16-AE

Como parte de los trabajos, el adjudicatario deberá contemplar el

“aspecto semántico” del sistema a implantar, teniendo en cuenta que

dicho Modelo no limite, en modo alguno, la posibilidad de abstraer a los

usuarios de la complejidad de definición física de tablas, campos,

elaboración de fórmulas, cláusulas de agrupación, etc. cuando éstos

procedan a la explotación de los indicadores sobre la Herramienta de

Inteligencia de Negocio de forma que los informes, gráficos, etc. se

elaboren y presenten a partir de conceptos de negocio.

El Modelo de Datos debe considerar en su diseño e implantación todos

los aspectos de seguridad a nivel de acceso, integridad,

confidencialidad y disponibilidad sobre los datos que contiene.

Asimismo, debe contemplar mecanismos de trazabilidad o auditoría

que permitan el control o incluso monitorización de las actividades de

los usuarios.

Efectuar el diseño técnico e implantación del Cuadro de Mando

Municipal (aprobado tras el análisis funcional solicitado en este

componente a partir del diseño conceptual del mismo obtenido tras la

ejecución de los trabajos del componente 3.1) sobre la Plataforma

Smart.

Asimismo el adjudicatario deberá efectuar todas aquellas operaciones

necesarias para posibilitar la obtención de aquellos indicadores que

adicionalmente las precisen, por ejemplo, cálculos previos para su

generación o para la agregación posterior hacia el Cuadro de Mando o

los informes.

Para la aceptación de los trabajos de este componente el licitador

deberá haber ejecutado e integrado correctamente en la plataforma

los datos provenientes de los componentes 4, 5, 8 y 12

2.11.4. Entregables

2.11.4.1. () Documentación de Análisis y diseño de la plataforma Smart y

Cuadro de Mando







Pág. 169 de 243



Exp.093/16-AE

Análisis de las fuentes origen de los datos, identificando los

responsables funcionales y técnicos de cada una de ellas, formato,

opciones de extracción automatizadas, etc.

Arquitectura del sistema, que incluirá no sólo la plataforma

sino también los sistemas con los que interactúa.

Modelo de datos


pruebas

2.11.4.2. () Documentación de construcción de la plataforma smart

código fuente de cualquier desarrollo realizado sobre la

plataforma Smart para cumplir los requerimientos del presente

pliego correctamente documentado

paquetes desplegables de la plataforma

informe de resultados del plan de pruebas de construcción de

la plataforma

2.11.4.3. () Documentación del cuadro de mando

Análisis funcional de la solución a implantar

Análisis pormenorizado de los indicadores a incluir en la base

de datos analítica

Diseño de base de datos analítica

Diseño y construcción del modelo de datos de indicadores

sobre la base de datos analítica.

Diseño de plantillas y diseño del cuadro de mando que deberá

ser aprobado por los Ayuntamientos.







Pág. 170 de 243



Exp.093/16-AE

2.12. Componente 11. Gestión de aparcamientos

Actualmente el Ayuntamiento de Badajoz cuenta con dos bolsas de aparcamiento

con una alta ocupación y que no cuentan con ningún sistema de control de

ocupación. Adicionalmente existen tres parking subterráneos de gestión privada

pero de uso público. Con el objetivo de mejorar la gestión del tráfico y el

aparcamiento en la ciudad, el Ayuntamiento busca integrar la disponibilidad de

plazas en estas ubicaciones dentro de la iniciativa SmartAlba de cara a su puesta a

disposición de los ciudadanos.

En el marco de la iniciativa Smart Alba, el Ayuntamiento de Badajoz considera

necesaria la implantación de un sistema de Aparcamiento Inteligente mediante la

instalación de una solución que permita conocer en tiempo real, el estado global

(libre/ocupado) de las plazas de aparcamiento existente en cada una de las dos

bolsas de aparcamiento situadas en la Calle Santo Domingo y en la Plaza de los

Alféreces, así como facilitar un servicio web que permita la integración futura de

los parkings de la calle San Antón, de la Calle Menacho y en el parking del Museo

Luis Morales. El objeto del Componente 11 es el desarrollo o puesta a disposición de

un sistema de gestión, almacenamiento y explotación de datos que alimentará la

aplicación móvil de guiado a aparcamientos definida en el apartado 2.7.5. Se trata

por tanto de una solución llave en mano de gestión inteligente de aparcamientos

que debe incluir todos los elementos hardware, software, procedimientos para la

lectura, recepción, tratamiento y almacenamiento de los datos de ocupación

generados por los sensores y las espiras, así como la instalación y puesta en

producción del mismo.







Pág. 171 de 243



Exp.093/16-AE

El funcionamiento propuesto será el siguiente: para las bolsas de parking cuando

entra un vehículo, el sistema debe ser capaz de detectar la entrada del vehículo en

el parking y, en el caso del parking de la Plaza de los Alféreces, la presencia del

vehículo en la plaza concreta y enviar una señal a la unidad de control. De igual

forma debe ser capaz de enviar la señal en el caso de que quede libre y salga del

parking.

La aplicación central de gestión, que se implantará en la infraestructura creada en

el Componente 1 en el CPD de los Ayuntamientos y deberá ser compatible con los

elementos descritos en el Componente 11, recibirá los datos que envían las

unidades de control. Estos datos serán procesados y almacenados en el repositorio

central de información, disponible para la aplicación móvil descrita en el

componente 6.5 y facilitando la información a la plataforma de ciudad definida en

el Componente 10.

En caso de que la solución propuesta implique obra civil todas las actuaciones

necesarias correrán a cargo del adjudicatario incluyendo las licencias necesarias,

las medidas de seguridad y salud que determine la normativa vigente así como los

posibles requerimientos de aceptación técnica de las actuaciones realizadas. En

este caso el Ayuntamiento de Badajoz actuará como promotor de la obra.

Se trata de una solución llave en mano, por tanto se incluirán todos los elementos

hardware y software necesarios para la puesta en marcha y funcionamiento de la

solución completa. El sistema estará compuesto al menos por:

Suministro de los dispositivos de detección de aforamiento de vehículos en

las entradas y salidas de las 2 bolsas de aparcamiento.

25 Sensores de aparcamiento, uno por cada plaza para el parking de la

Plaza de los Alféreces







Pág. 172 de 243



Exp.093/16-AE

Sistemas de comunicaciones necesarios para la conexión de los sensores,

dispositivos de detección de aforamiento y del sistema con los servicios

centrales del Ayuntamiento así como el conexionado de los mismos.

Sistema de visualización de estado de plazas para las entradas de las 2

bolsas de aparcamiento.

Software de gestión.

Desarrollo del servicio web para la integración futura de la información de

plazas libres proveniente de los 3 parking privados

Conectividad del sistema a la red del Ayuntamiento mediante GPRS/3G/4G

por un periodo de 6 meses, en caso de no disponer acceso a internet en las

instalaciones.

La solución objetivo busca la mayor robustez en comunicaciones y el menor

mantenimiento.

Las localizaciones para la implementación del equipamiento se realizarán en las

siguientes bolsas de aparcamiento:

Parking Tipo

C/Santo

Domingo

Parking de

superficie con 1

acceso E/S







Pág. 173 de 243



Exp.093/16-AE

Plaza de

los

Alférece

s

Parking de

superficie con 4

accesos: 2 E/ 2 S

La información disponible deberá ser provista en tiempo real a la plataforma de

ciudad y a la aplicación móvil de guiado a aparcamientos de forma que esta pueda

ser gestionada por el sistema y notificada al usuario por las distintas vías

consideradas en el proyecto.

Los aparcamientos subterráneos de los que se integrará la información son:

Aparcamiento Dirección Localización

Parking plaza de

san Antón

Plaza San Antón,

s/n,06002

Badajoz







Pág. 174 de 243



Exp.093/16-AE

Aparcamiento Dirección Localización

Parking de

Menacho

Avda. Santiago

Ramón Y Cajal, s/n

Parking museo

Luis de Morales

Calle Encarnación,

29,

Las tareas a realizar para llevar a cabo esta actuación deberán ser las siguientes:

Análisis y diseño de la solución y sus componentes.

Construcción y puesta a disposición de la solución.

2.12.1. Requisitos técnicos

2.12.1.1. () El Ayuntamiento deberá poder conocer los datos de ocupación

del parking en tiempo real y explotar la información de ocupación

de modo que puedan optimizar la gestión del mismo.

2.12.1.2. () Los usuarios deben poder conocer en tiempo real la situación

de la ocupación de las dos bolsas de aparcamiento y cuando esté

disponible el estado de las plazas de aparcamiento, así como







Pág. 175 de 243



Exp.093/16-AE

información de acceso al parking. Esta información deberá estar

disponible tanto en la aplicación móvil definida en el apartado 2.7.5

como físicamente en los paneles informativos situados en las

ubicaciones definidas por el Ayuntamiento de Badajoz.

2.12.1.3. (√) Conexión a la red eléctrica existente. Los puntos de conexión

eléctrica serán habilitados por parte del Ayuntamiento de Badajoz

en la ubicación de los elementos a implantar, de forma que el

adjudicatario únicamente, y en cuanto a la conexión eléctrica se

refiere, deberá conectar los equipos, al punto de referencia más

cercano que provea el Ayuntamiento, con las conexiones eléctricas

que correspondan.

2.12.1.4. (√) Conexión a la red de datos existente. En la medida de lo posible

el Ayuntamiento proveerá de conectividad a la red de datos en la

ubicación donde se ubique el equipamiento, el licitador usará

preferiblemente este tipo de conexión frente al uso de otros

métodos que supongan un gasto recurrente para el Ayuntamiento

como tarjetas móviles.

2.12.1.5. () Durante un periodo de 6 meses tras la aceptación de la puesta

en marcha del Componente 11, en caso de no disponer de una

conexión de datos, el adjudicatario tendrá que hacerse cargo como

parte de la solución, de la conexión/comunicaciones a través de

GPRS/3G/4G entre los elementos que conforman el componente y

la infraestructura de comunicaciones del Ayuntamiento,

posteriormente a estos 6 meses el Ayuntamiento se hará cargo de

la solución de conectividad.

2.12.1.6. () Las entradas y salidas de las bolsas de parking contarán con

espiras para controlar tanto el paso de un vehículo, como el sentido

del paso incluyendo todos los componentes necesarios para su

funcionamiento. Será necesario en la instalación de las espiras,

asegurar que la temperatura del sellado no supera la temperatura

máxima de aislamiento del lazo inductivo. En caso de que sea







Pág. 176 de 243



Exp.093/16-AE

soportado se utilizará para tapar la roza, aglomerado en caliente o

similar de modo que se maximice la durabilidad de la superficie.

2.12.1.7. () Amplificador de señal alojado en cuadro eléctrico en caso de ser

necesario para la prestación del servicio.

2.12.1.8. () Alimentación 220 VAC

2.12.1.9. () Los dispositivos estarán correctamente instalados para

garantizar su funcionamiento y durabilidad debiendo el licitador

tener en cuenta la ubicación de los mismos y asegurar el anclaje y

correcta implantación.

2.12.1.10. () Los sensores deberán instalarse en el suelo de modo que se

prevengan situaciones de hurto o vandalismo (para el parking de

Plaza de los Alféreces).

2.12.1.11. () El sistema estará construido de tal forma que en caso de fallo

de uno de los sensores, éste se pueda sustituir sin necesidad de

realizar ningún tipo de obra.

2.12.1.12. () Con el fin de optimizar las comunicaciones al máximo, en caso

de que el sistema de comunicaciones propuesto sea cableado, para

la conexión entre los diferentes componentes, se utilizarán las

soluciones de canalización necesarias según las características y

restricciones de instalación en el parking, no quedando visibles en

superficie tubos o canaletas.

2.12.1.13. () El mantenimiento del sistema deberá ser lo más sencillo

posible, de modo que en caso de avería de alguno de los sensores,

que deberá ser detectada por el propio sistema de forma

automática, se minimice la reparación y no requiera obra civil. En

cualquier caso, en caso de que el cumplimiento de las garantías

requiera obra civil, ésta correrá a cargo del adjudicatario sin que

esto suponga una ampliación de los tiempos de respuesta exigidos

en el apartado 3.3.







Pág. 177 de 243



Exp.093/16-AE

2.12.1.14. () La solución deberá minimizar las necesidades de comunicación

entre los diferentes elementos que la constituyan.

2.12.1.15. () El sistema dispondrá de una o más unidades de control por cada

bolsa de aparcamiento, encargadas de recoger los datos de los

dispositivos de acceso, y en su caso de los sensores y facilitar la

información de ocupación al sistema de gestión.

2.12.1.16. () El sistema dispondrá de capacidad de autochequeo de los

diferentes elementos que lo componen (sensores, unidades de

control, display). En caso de fallo de alguno de ellos, se enviará el

aviso automático al puesto central y éste deberá poder

redireccionarlo automáticamente al personal de mantenimiento vía

e-mail.

2.12.1.17. () Los sistemas de detección de estado de plazas deben ser

capaces de autochequear su estado de actividad enviando una

señal tipo ‘hearbeat’ a los servicios centrales cada cierto tiempo

para indicar que está operando correctamente, este tiempo podrá

ser programable desde el sistema de gestión central. La unidad de

control debe detectar situaciones de no envío de estas señales de

actividad y transmitir la información al puesto central. El sistema

estará configurado para dar un aviso automático a los responsables

de mantenimiento.

2.12.1.18. () El sistema permitirá la generación de informes, estadísticas y

cuadros de mando sobre los datos de ocupación almacenados.

2.12.1.19. () El sistema permitirá la detección del estado de todas las plazas

de aparcamiento existentes en el parking municipal de la Plaza de

los Alféreces y será capaz de diferenciar entre los diferentes tipos

de vehículo (moto, coche).

2.12.1.20. () El sistema incluirá todos los elementos y sistemas de

comunicación entre los diferentes componentes que lo forman.







Pág. 178 de 243



Exp.093/16-AE

2.12.1.21. () Todos los componentes instalados en los parking deben contar

con protección mínima IP65 de acuerdo a la norma internacional

IEC 60529, aunque deberá ser la suficiente para garantizar el

servicio en la ubicación en la que se encuentre.

2.12.1.22. () Se suministrarán 3 sistemas de visualización de plazas libres

(uno para el parking de la calle Santo Domingo y dos para el parking

de la Plaza de los Alféreces que se ubicarán en la localizaciones

definidas por el Ayuntamiento de Badajoz al inicio de los trabajos.

2.12.1.23. () Cada sistema de visualización de plazas libres o panel, deberá

mostrar el número de plazas disponibles, el número de plazas de

minusválidos disponibles y el número total de plazas y tendrá al

menos las siguientes características técnicas:

Módulo de Comunicación al menos M2M (GPRS/3G) y

Ethernet.

Deberá reflejarse con texto estático el nombre del parking.

La parte electrónica estará formada por tres dígitos

numéricos en LED de color blanco de alta luminosidad con tamaño

de 200mm, con ángulo de visión de 120º y control de luminosidad

por software que mostrarán el número de plazas libres. Así como

la disponibilidad de plazas reservadas para discapacitados, cuando

la información esté disponible.

Las dimensiones de referencia del panel serán de 960 mm. de

ancho x 290 mm. de alto x 70 mm de fondo.

Carcasa de aluminio

Debe contar con protección mínima IP65 de acuerdo a la

norma internacional IEC 60529

Temperatura de funcionamiento -30º C a +70ºC







Pág. 179 de 243



Exp.093/16-AE

Poste de instalación en ciudad; para sujeción del panel y

cabecera de 2,4 metros de altura. Tubo de acero galvanizado y

pintado, con herrajes para la base de cimentación incluida.

Distancia de lectura 80 metros

2.12.2. Sistema de gestión.

El sistema incluye la puesta a disposición de una aplicación de gestión,

almacenamiento y explotación de datos. Los siguientes apartados recogen las

características técnicas mínimas que deben cumplir dicha solución software

ofertada:

2.12.2.1. () Deberán estar basadas en la utilización de estándares

estructurados y no propietarios.

2.12.2.2. () La solución software deberá tener la imagen corporativa del

Ayuntamiento de Badajoz siguiendo la línea de diseño definida en el

apartado 2.1.4

2.12.2.3. () La aplicación central de gestión, almacenamiento y explotación,

deberá contar con una parte privada y otra pública, permitiendo la

gestión de usuarios y asignación de permisos para acceder a la

parte privada.

2.12.2.4. () La parte privada de la aplicación central de gestión accederá al

repositorio central de información para explotar la información y

ofrecer al menos los siguientes servicios y funcionalidades sobre

los datos:

Herramienta que facilite la administración de la red y

visualización de posibles alarmas.

La aplicación deberá ser accesible desde internet mediante

usuario/contraseña utilizando el sistema de autenticación definido

en el apartado 2.1.6







Pág. 180 de 243



Exp.093/16-AE

Los datos deberán ser visualizados en un mapa, mostrando la

disponibilidad y ocupación por zona.

Generación de informes, estadísticas y cuadros de mando

sobre los datos de ocupación almacenados del parking en

formatos tabulares y gráficos:

Tiempo de estancia media

Grados de ocupación del parking por horas/días/meses

Generación de consultas ad-hoc

Generación de microdatos relativos a variables asociadas a la

ocupación como los relativos a duración, etc.

Envío en tiempo real de los datos de la ocupación del parking

al panel informativo para que los conductores interesados en

aparcar en el parking, estén informados.

Generación de servicios web de integración que ofrezcan los

datos de ocupación, a la aplicación móvil definida en el apartado

2.7.5, para que éstas puedan ofrecer los datos de ocupación a sus

usuarios.

Gestión, almacenamiento y explotación de datos a la

aplicación móvil y al display.

Almacenamiento de la información de los sensores, cambios

de estado (de libre a ocupado y ocupado a libre) así como los

status de funcionamiento de los equipos implantados en el

momento que se producen.

Los datos generados deberán almacenarse en un formato

abierto reutilizable generando datasets que puedan ser publicados

en el portal de datos abiertos.

Tiempo de refresco de datos (siempre que se produzca alguna

variación)







Pág. 181 de 243



Exp.093/16-AE

Posibilidad de encendido y apagado del display en un

determinado horario (por ejemplo durante la noche)

Frecuencia de consulta del estado de los diferentes sistemas

que se integran en el display y los sensores.

La aplicación web deberá permitir vía APIs/servicios web

recoger información proveniente de los 3 parking subterráneos y

presentarla al usuario.

La información disponible será provista en tiempo real de

forma que pueda ser gestionada por el sistema y notificada al

usuario por las distintas vías consideradas en el proyecto.

Debe proveer de APIS/servicios web de cara a permitir la

integración los datos relativos a la ocupación de aparcamientos en

la Plataforma Smart definida en el Componente 10.

2.12.2.5. () La parte pública de la aplicación central de gestión deberá

proporcionar al menos la siguiente información:

Ser accesible a través de la Web oficial del Ayuntamiento.

Información básica mínima del estado del parking: número de

plazas disponibles, plazas libres así como información de acceso al

parking.

Indicación en plano (sobre cartografía oficial del

Ayuntamiento) de las plazas libres y ocupadas, en tiempo real

para cada bolsa de aparcamiento.

Indicación de la ruta para llegar al parking.

2.12.3. Procesos de Integración con parking subterráneos

2.12.3.1. El licitador desarrollará un servicio web para que los parkings

privados puedan proveer la información que se necesite para la

integración







Pág. 182 de 243



Exp.093/16-AE

2.12.3.2. El sistema deberá estar preparado para a partir de la información

suministrada por el API, integrar información proveniente de 3

parking subterráneos, facilitando la siguiente información a la

aplicación móvil y al software de gestión:

Número total de plazas disponibles por aparcamiento en

tiempo real

Dirección del parking georreferenciada.

Horarios de Apertura y Cierre

Características físicas como limitación de altura, accesibilidad

para PMR, etc.

Información de Contacto

2.12.3.3. El Software de gestión deberá permitir vía APIs/webservices

recoger dicha información proveniente de los parking subterráneos

y presentarla al usuario.

2.12.3.4. La información disponible será provista en tiempo real de forma

que pueda ser gestionada por el sistema y notificada al usuario por

las distintas vías consideradas en el proyecto.

2.12.4. Entregables
















Pág. 183 de 243



Exp.093/16-AE




2.13. Componente 12. Integración de datos en la plataforma

De cara a dotar de contenidos a la plataforma Smart definida en el Componente 10,

el objeto de este componente es integrar las fuentes de datos de existentes en los

Ayuntamientos de Almendralejo y Badajoz en la plataforma Smart. De esta forma

se asegura el flujo de información entre todos los componentes de la solución

global, así como posibilitar su uso por parte de terceros ya sea para análisis y

gestión (Cuadro de mando), impulso al emprendimiento (Datos Abiertos), etc.

También se posibilita el tener una visión única de la Ciudad y poder actuar sobre

los distintos sistemas desde un punto central.

2.13.1. Requisitos mínimos técnicos.

2.13.1.1. () Las integraciones con aplicaciones y servicios que no sean

objeto de la actuación requerirán que los ayuntamientos

proporcionen los web services o las cadenas de conexión a las

bases de datos.

2.13.1.2. () Las integraciones propuestas se desarrollarán sobre las APIs y

Servicios Web que proporcionen los aplicativos. De no ser posible

conectarlos se construirán sobre los datos disponibles.

2.13.1.3. () Algunas de las integraciones serán sólo de consulta destinadas

a fines estadísticos y de gestión. Otras tendrán capacidad de acción







Pág. 184 de 243



Exp.093/16-AE

sobre los actuadores. La distinción vendrá dada por las capacidades

de las APIs de los sistemas.

2.13.1.4. () Se realizará una integración para las siguientes fuentes de datos

del Ayuntamiento:

Ayuntamiento de Almendralejo:

Sede electrónica.

Contabilidad

Padrón

Gestión Tributaria

Empresa suministro eléctrico (Integración 100 contadores

GSM)

Ayuntamiento de Badajoz:


Contabilidad (WS sobre SAGE)

Padrón (WS sobre Unit4)

Gestión Tributaria (WS sobre OAR y WS sobre INFAPLIC)

2.13.1.5. () Se desarrollará un servicio web, que será puesto a disposición

del Ayuntamiento y que establecerá las especificaciones para la

integración futura con los siguientes servicios


Instalaciones deportivas (I2ACronos)

Ayuntamiento de Badajoz:







Pág. 185 de 243



Exp.093/16-AE



2.13.1.6. () Para los servicios de Turismo, Contabilidad, Padrón y Gestión

tributaria el Ayuntamiento de Badajoz (aplicable también a

Almendralejo) facilitará la cadena de conexión a la B.D., que en

todos los casos es Oracle, y el/los select necesarios para obtener el

dataset a partir de la cual el licitador deberá realizar la integración

con al menos los siguientes datos:

Padrón de Habitantes: Con objeto de poder generar cualquier tipo

de pirámide por intervalos de edades referente a una fecha

determinada y agrupada por:

o Municipio

o Distrito

o Sección

o Sector Urbano

o Nacionalidad

o Nivel de Estudio

o Municipio Nacimiento

o Provincia Nacimiento

o País nacimiento

Se adjunta documento de pirámide de edades agrupada por

estudios en el Anexo II.

Contabilidad y Gestión Tributaria: La información

correspondiente a este dataset se adjunta al pliego como Anexo

II

Sede Electrónica (AL-SIGEM): El dataset contendrá:







Pág. 186 de 243



Exp.093/16-AE

o Unidad tramitadora

o Tipo de procedimiento

o Código postal solicitante

o Fecha de inicio

o Fecha fin

o Unidad administrativa

2.13.1.7. () Adicionalmente también se integrarán los sistemas a implantar

en el marco del presente expediente.




Gestión de flotas




2.13.1.8. () Los datos integrados en la plataforma deberán estar

disponibles para su uso por parte de del cuadro de mandos y otros

componentes del sistema.

2.13.1.9. () El objeto de este intercambio de datos es tener capacidades de

análisis, gestión y explotación, por ello se deberán obtener

información que permita conocer:








Pág. 187 de 243



Exp.093/16-AE

o Euros y toneladas de basura por periodo de tiempo y

tipología.

o Incidencias y quejas sobre el servicio

Sede electrónica.

o Tramitación en curso

o Caracterización de los trámites solicitados: número,


o Canal de tramitación, % de población

Contabilidad

o Presupuestos

o Ingresos

o Gastos y Costes.

o Ejecución presupuestaria

Gestión Tributaria

o Tasas e impuestos

o Cobros y morosidad.

o Información de impuestos por identificador fiscal (para

uso interno del Ayuntamiento)

Padrón de Habitantes

o Pirámides de edades por distintos conceptos: sexo,

nacionalidad, sector urbano, código postal, nivel de

estudios, etc.

o Estadísticas varias.


o Tramitación en curso

o Caracterización de los trámites solicitados: número,








Pág. 188 de 243



Exp.093/16-AE

o Canal de tramitación, % de población


o Renvío y recepción de datos de afluencia y flujos

turísticos


o Al ser información estática se deberá poder cargar los

datos en el sistema con una estructura que permita su

reutilización.


o Número de conexiones por unidad de tiempo

o Contenidos descargados por unidad de tiempo.

o Flujo de datos por unidad de tiempo

o Características de los terminales conectados.


Ocupación de plazas por aparcamiento y unidad de tiempo.

o Flujo de vehículos por periodo de tiempo.

Gestión de flotas

o Posición instantánea de los vehículos

o Rutas seguidas por los vehículos.

o Información agregada por unidad de tiempo: km,

distancia recorrida y tiempo en ralentí.


o Número de visitantes por unida de tiempo


o Resultado obtenido

Instalaciones deportivas







Pág. 189 de 243



Exp.093/16-AE

o Uso de las pistas deportivas

o Recaudación

o Reservas

o Control de acceso a instalaciones.


o Consumo de datos desde la plataforma: Plazas de

aparcamiento, posición de la flota,…

o Traslado de información hacia la plataforma: incidencias,

ejecución de partes de trabajo,…

2.13.1.10. El licitador debe determinar el tipo de procesos de extracción que

resulten más eficientes para cada subconjunto de datos en cuanto

a, por ejemplo, reducir el tiempo empleado en extraer y cargar la

información (ventana de carga), minimizar el impacto de las

extracciones en los sistemas origen, preservar la consistencia e

integridad de la información durante la carga, etc. Los procesos de

transformación desarrollados no podrán ser intrusivos en los

sistemas origen, para evitar interferencias en la operación o caídas

en el rendimiento de los mismos.

2.13.1.11. Identificar, establecer y documentar los criterios de calidad y las

políticas de los procesos de extracción, transformación y carga: los

protocolos de actuación ante valores no válidos, duplicados,

pérdidas de referencias de integridad, datos incompletos,

identificación de patrones, unicidad de criterios de transformación

(por ej.: tipologías, formatos,…), criterios de reutilización, buenas

prácticas, etc.

2.13.1.12. Efectuar la extracción de los subconjuntos de datos de cada

sistema origen a integrar en la Base de Datos Analítica teniendo en

cuenta que durante la extracción, y salvo que estuviera justificado,

los datos deberán recibirse desde los sistemas origen completos y

puros, es decir, tratando de desacoplar la extracción de datos de su

posterior transformación. La carga inicial habrá de incluir además







Pág. 190 de 243



Exp.093/16-AE

los datos históricos hasta la profundidad temporal que se

determine en cada caso, debiendo el adjudicatario determinar la

estrategia de carga más adecuada para esa carga inicial

considerando el volumen de datos y el impacto de la carga sobre el

sistema origen.

2.13.1.13. Determinar e implantar las diferentes transformaciones sobre los

datos extraídos que conviertan a los mismos en información

preparada para su posterior explotación. Entre dichas

transformaciones estarán las necesarias para la validación, filtrado

y limpieza de los datos, decodificaciones, renombrados, gestión y

limpieza de sus claves, etc.

2.13.1.14. Documentar todo el mapeado de flujos de datos desde el sistema

origen a la Base de Datos Analítica de la Ciudad, así como todo el

conjunto de transformaciones efectuadas sobre los mismos.

2.13.1.15. Efectuar todas las pruebas necesarias (funcionales, integración,

rendimiento,…) para asegurar el correcto funcionamiento de los

procesos ETL desarrollados.

2.13.1.16. Todo el proceso de extracción, transformación y carga deberá

contar con instrumentos de control y auditoría (logs,

monitorización, etc.) que permitan hacer una detección temprana y

gestión eficaz de los errores que se pudieran darse durante el

mismo y de las medidas correctoras/mitigadoras que sean de

aplicación en cada caso para minimizar el impacto del fallo.

2.13.2. Entregables

2.13.2.1. () Documentación de Análisis de la integración de datos y plan de

acción

Análisis

Base de datos Analítica







Pág. 191 de 243



Exp.093/16-AE

Descripción de los casos de uso de los componentes a integrar

y especificación de las pruebas

2.13.2.2. () Documentación Integración del cuadro de mando

Parametrización de indicadores estratégicos con datos

cargados

Parametrización y configuración de informes

2.14. Medios Personales

De conformidad con lo establecido en el artículo 64.2 del texto refundido de la Ley

de Contratos del Sector Público, aprobado por Real Decreto Legislativo 3/2011, de

14 de noviembre, los licitadores se comprometerán a adscribir a la ejecución del

contrato los medios personales o materiales suficientes para ello.

A este compromiso se le atribuye el carácter de obligación esencial a los efectos

previstos en el artículo 223 letra f) del texto refundido de la Ley de Contratos del

Sector Público, aprobado por Real Decreto Legislativo 3/2011, de 14 de noviembre,

y de conformidad con lo indicado en el apartado 12 del Pliego de Condiciones

Particulares.

Para la prestación de los Servicios descritos en los apartados 2.2 y 2.6 del

presente Pliego, el adjudicatario se compromete a disponer de los medios

personales suficientes que deberán cumplir con la cualificación establecida a

continuación para los perfiles definidos.

Hasta la entrega del Componente 1 descrito en el apartado 2.2 del presente

documento, el adjudicatario se compromete a adscribir un mínimo de 3 medios

personales que podrá reducirse a 1 medio personal tras la entrega hasta el fin del







Pág. 192 de 243



Exp.093/16-AE

periodo de garantía de los equipos implantados en el presente concurso del Perfil

Instalador de Hardware y Software descrito a continuación:

Perfil Instalador de Hardware y Software

Titulación Titulación Universitaria en Tecnologías de la

Información (Telecomunicaciones, Informática…) o

equivalente.

Perfil

técnico

Experiencia en (3) proyectos de implantación y

configuración de soluciones software en entornos

virtualizados en los últimos dos (2) años.

Certificación del fabricante que lo califique como apto

para la manipulación, ensamblaje y reparación de su

equipamiento. Se acreditará mediante certificado oficial

o escrito del fabricante del equipamiento, que califique

al perfil como apto para la manipulación, ensamblaje y

reparación del equipamiento ofertado en el componente

1

Hasta la entrega del Componente 5 descrito en el apartado 2.6 del presente

documento, el adjudicatario se compromete a adscribir un mínimo de 2 medios

personales del Perfil Instalador y Configurador de Redes Wifi descrito a

continuación:

Perfil Instalador y Configurador de Redes Wifi

Titulación Titulación Universitaria en Tecnologías de la

Información (Telecomunicaciones, Informática…) o

equivalente.







Pág. 193 de 243



Exp.093/16-AE

Perfil Instalador y Configurador de Redes Wifi

Perfil

técnico

Experiencia en dos (2) proyectos de diseño, despliegue

y configuración de redes wifi en los últimos (2) años.

Certificación del fabricante que lo califique como apto

para la manipulación, ensamblaje y reparación de su

equipamiento. Se acreditará mediante certificado oficial

o escrito del fabricante del equipamiento, que califique

al perfil como apto para la manipulación, ensamblaje y

reparación del equipamiento ofertado en el componente

5

El licitador que haya obtenido la mayor puntuación total tras la valoración de los

criterios cuantificables mediante la mera aplicación de fórmulas deberá poner a

disposición de Red.es, en un plazo máximo de tres días hábiles desde la solicitud

de la información por parte de Red.es, dos (2) Currículum Vítae de los medios

personales que se comprometa a adscribir del perfil Instalador de Hardware y

Software y un (1) Currículo del Instalador y Configurador de Redes Wifi requeridos

para la prestación del servicio con objeto de que Red.es pueda realizar la

verificación del cumplimiento de los requisitos de cualificación anteriormente

indicados.

Para acreditar la cualificación de los medios personales, se deberá presentar

Currículum Vítae y las certificaciones de los profesionales que se comprometa a

adscribir para la prestación del servicio descrito, acompañado de declaración

responsable firmada en la que se declare que se ha contrastado por el licitador el

contenido de los currículos que se aportan.







Pág. 194 de 243



Exp.093/16-AE

En los Currículum Vítae aportados se deberá especificar cómo se han

adquirido los conocimientos requeridos (cursos de formación, trabajos

realizados), indicando los siguientes aspectos:

• Descripción de los cursos o trabajos realizados especificando

en este caso las tareas realizadas.

• Tecnologías utilizadas.

• Duración de los cursos de formación o trabajos realizados.

Esta cualificación mínima del equipo de trabajo tiene carácter esencial.

Se utilizará para la presentación del Curriculum Vitae el modelo Europass

(http://europass.cedefop.europa.eu/es/home), indicando en el Curriculum Vitae

los proyectos en los que ha trabajado que demuestran la aplicación de los

conocimientos solicitados con información suficiente de los proyectos

(empresa u organismos, persona de contacto, teléfono y correo electrónico)

que permitan su comprobación efectiva de los datos aportados, con objeto de

que Red.es pueda realizar la verificación del cumplimiento de los requisitos de

cualificación anteriormente indicados.

En los Curriculum Vitae aportados se deberá especificar la formación y trabajos

realizados de manera que estos evidencien de forma clara, concisa y sin

ambigüedades el cumplimiento de la totalidad de requisitos del perfil al que

corresponda. Será preciso, por ello, reflejar las fechas de inicio y fin de cada

trabajo o formación y la descripción de tareas realizadas así como tecnologías y

prácticas empleadas de forma que exista certeza clara y manifiesta del

cumplimiento del perfil.







Pág. 195 de 243



Exp.093/16-AE

3. Requisitos de la Implantación

La implantación consiste en la instalación, configuración y puesta en marcha de

todos los componentes descritos en el apartado 2 y que son objeto de desarrollo y

suministro en el marco del contrato, incluyendo la realización de las pruebas

necesarias para asegurar el correcto funcionamiento de los elementos

suministrados, capacitación y documentación.

(√) El adjudicatario deberá disponer de todas las herramientas, aparatos, equipos

de medida y otros materiales, así como del personal técnico adecuado con la

preparación y experiencia necesarias para llevar a cabo todas las tareas

requeridas para la ejecución del contrato.

3.1. Instalación y configuración

3.1.1. Documentación de la implantación

3.1.1.1. (√) Para poder dar por finalizada la instalación de cada uno de los

componentes, el adjudicatario entregará un conjunto de

documentación en español que incluirá, al menos para cada

componente implantado, manual de instalación y configuración,

manual de mantenimiento, manual de usuario y manual de

administración, operación y mantenimiento así como los

correspondientes Informes de resultados de Planes de Prueba.

3.1.1.2. (√) El adjudicatario especificará y realizará una propuesta de Plan

de Pruebas para cada componente que permita verificar el correcto

funcionamiento e integración en la red, de todos los elementos HW

instalados y de todos los componentes SW instalados, tanto desde

el punto de vista individual, como desde el punto de vista de

integración de todos los componentes HW y SW incluidos en la

solución y pruebas de carga para cada componente. En el mismo se

incluirán el conjunto de casos de prueba propuestos que

contendrán al menos los siguientes apartados:







Pág. 196 de 243



Exp.093/16-AE

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

comprobar)

Las condiciones previas

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

El resultado del caso

3.1.1.3. (√) A la finalización de los trabajos, el adjudicatario deberá entregar

un documento en el que se especifiquen los resultados de las

pruebas realizadas del protocolo de pruebas en un Informe de

resultados de pruebas, con una estructura acorde al protocolo de

pruebas propuesto.

3.1.1.4. (√) El adjudicatario utilizará para realizar las pruebas su

equipamiento de medición y personal propio.

3.1.1.5. (√) Red.es se reserva el derecho de no ejecutar alguna de las

pruebas incluidas en los protocolos de pruebas cuando las

condiciones de ejecución de las mismas lo desaconsejen, y podrá

solicitar al adjudicatario la inclusión de pruebas adicionales en los

protocolos de pruebas.

3.1.1.6. (√) La planificación de las pruebas se coordinará con Red.es.

3.1.2. Instalación y configuración Componente 1

3.1.2.1. (√) La instalación ha de incluir todos los elementos y actuaciones

necesarias para el correcto funcionamiento de los elementos

suministrados para cada Ayuntamiento, entre los que como mínimo

se encuentran:

Traslado, instalación, conexionado y etiquetado de los equipos en

los lugares designados por Red.es o quien ésta determine.

Instalación y configuración del software y firmware suministrado

según las directrices de Red.es o quien ésta determine.







Pág. 197 de 243



Exp.093/16-AE

Configuración e integración con la red de comunicaciones de los

Ayuntamientos, garantizando la puesta en marcha de todo el

conjunto.

Instalación de las licencias y configuración de entorno de

virtualización

Configuración de un servicio de replicado entre los dos entornos.

Configuración del entorno en Almendralejo como nodo de respaldo

para su uso en caso de caída del servicio. La puesta a disposición de

una línea de comunicación entre ambos centros será

responsabilidad de los Ayuntamientos.

3.1.2.2. (√) El adjudicatario instalará y configurará todo el hardware y

software descrito en el Componente 1.

3.1.2.3. (√) El adjudicatario deberá realizar el tendido y conexión de todos

los cables y latiguillos necesarios para la conexión entre los

distintos equipos o módulos suministrados, así como a las tomas y

cuadros de distribución de energía, etiquetando los cables de

conexión y de alimentación eléctrica. Todo el cableado será

identificado en sus extremos, conexiones y repartidores.

La configuración incluye reglas de filtrado de los actuales equipos de

firewalling y de los archivos de configuración de los DNS, así como la

integración a que hubiere lugar con otros módulos software o hardware

(routers, balanceadores, etc.).

3.1.2.4. (√) El adjudicatario realizará la instalación de los elementos

suministrados, así como su integración con otros sistemas que ya

se encuentren en funcionamiento, en fechas y horarios que se

estimen tengan el mínimo impacto sobre los servicios en operación,

que se habrán acordado previamente con Red.es, pudiendo ser

fuera del horario laboral.

3.1.2.5. (√) Capacitación, deberá tener en cuenta los diferentes perfiles de

usuario desarrollando capacitación específica y documentación







Pág. 198 de 243



Exp.093/16-AE



3.1.2.6. (√) El adjudicatario diseñará, suministrará e instalará en las

ubicaciones donde se realicen las instalaciones, salvo que por la

naturaleza del emplazamiento Red.es indique lo contrario, un cartel

informativo con las siguientes características:

Contenido: Emblema de la Unión Europea, acompañado de los

logotipos institucionales y referencias que se designen desde

Red.es. A petición de Red.es, para la validación de artes finales,

podrá requerirse la entrega de una muestra por proyecto en la

sede de la Entidad.

Dimensiones: 0,25 x 0,25 m

Material: Impreso en hexacromía sobre papel blanco de 170 gr.

con laminado antirreflex en su cara anterior montado sobre

foam 10 mm, perfilado en aluminio plata.

3.1.3. Instalación y configuración Componente 3.3, Componente 4,

Componente 9, Componente 10.

3.1.3.1. () El adjudicatario deberá implantar los Componentes 3.3, 4, 9 y 10

garantizando el cumplimiento de la totalidad de requisitos y

conjunto de actuaciones detallados en los apartados 2.4.3, 2.5, 2.11

y 2.12. Para ello, deberá suministrar e instalar todos los

componentes software así como configurar, parametrizar y

efectuar desarrollos adicionales que sean necesarios.

3.1.3.2. (√) Instalación, configuración y parametrización de la solución

desarrollada en dichos componentes 3.3, 4, 9 y 10 en la

infraestructura virtualizada implantada y configurada en el

apartado 3.1.2. en el Ayuntamiento de Badajoz creando un nodo

espejo en el Ayuntamiento de Almendralejo y estableciendo los

mecanismos de respaldo que sean necesarios para su actualización.







Pág. 199 de 243



Exp.093/16-AE

La puesta a disposición de una línea de comunicación entre ambos

centros será responsabilidad de los Ayuntamientos.


necesarias para el correcto funcionamiento de los desarrollos,

entre los que como mínimo se encuentran:

Creación, Instalación, y configuración de las máquinas virtuales

necesarias para alojar los citados componentes.

Instalación y configuración del software base suministrado

según las directrices de Red.es o quien ésta determine.

Configuración e integración con la red de comunicaciones del

Ayuntamiento de Badajoz, garantizando la puesta en marcha de

todo el conjunto.

3.1.3.4. (√) El adjudicatario deberá realizar la instalación y configuración de

los elementos software y parametrización de componentes base

necesarios para el correcto funcionamiento de las plataformas

objeto de implantación en el presente Pliego, descritos en el

presente Pliego (gestor de contenidos, bases de datos, etc) así

como cualquier otro ofertado por el licitador para el correcto

funcionamiento del entorno.

Este software será implantado por el adjudicatario en el entorno virtual

configurado en el presente procedimiento de licitación. El adjudicatario

realizará desde la más básica instalación del RAID de discos si fuera

necesario, Sistema Operativo, etc, hasta el bastionado, virtualización,

configuración y ajuste de la solución software, que constituya una solución

integral.











Pág. 200 de 243



Exp.093/16-AE











3.1.3.7. (√) Entregables:

Informe de instalación y configuración en el que se reflejen todos los

aspectos de instalación y configuración del sistema.

Informe de carga de datos básicos en el que se reflejen todos los

datos cargados en el sistema.

Informe de ejecución del plan de pruebas

Acta de aceptación de los trabajos

3.1.3.8. (√) Presentación y aprobación del sistema.

3.1.3.9. (√) Capacitación, en la utilización de las funcionalidades de los

distintos componentes, mantenimiento de la información,

tratamiento de datos, carga y publicación de éstos y administración

de la solución, siguiendo los requisitos generales descritos en el

apartado 2.1 del presente Pliego. El adjudicatario deberá impartir un

mínimo de 4 horas de capacitación al perfil de usuario y un mínimo

de 4 horas al perfil de administrador.


3.1.4.1. (√) Instalación configuración y parametrización de todos los

elementos integrantes del Componente 5.







Pág. 201 de 243



Exp.093/16-AE


o Estudio de ubicación y estudio de cobertura que demuestre que el

equipamiento a implantar objeto de la licitación cumple los requisitos

definidos en el apartado 2.6

Diagramas físicos y lógicos de la solución.

Ubicación de cada uno de los elementos hardware.

Propuesta de conectividad entre los diferentes elementos de

la red.

o Equipamiento suministrado e instalado: documentación de soporte,

inventariado, ubicación, fotografías, etc.

o Informe de instalación y configuración en el que se reflejen todos los


o Informe de pruebas

3.1.4.3. (√)Mapa físico y lógico de la red de puntos de acceso generada


3.1.5. Instalación y configuración del Componente 6

3.1.5.1. () El adjudicatario deberá implantar el Componente 6 garantizando

el cumplimiento de la totalidad de requisitos y conjunto de

actuaciones detallados en el apartado 2.7. Para ello, deberá







Pág. 202 de 243



Exp.093/16-AE

suministrar e instalar todos los componentes software así como

configurar, parametrizar y efectuar desarrollos adicionales que

sean necesarios.

3.1.5.2. (√) Publicación de las aplicaciones en los repositorios de los 2

sistemas operativos móviles más utilizados 2

3.1.5.3. (√) Despliegue de todas las herramientas de administración de

estas aplicaciones en la infraestructura virtualizada implantadas en

el apartado 3.1.2. en el Ayuntamiento de Badajoz creando un nodo

espejo en el Ayuntamiento de Almendralejo y estableciendo los

mecanismos de respaldo que sean necesarios para su actualización.


necesarias para el correcto funcionamiento de los desarrollos,

entre los que como mínimo se encuentran:

Creación, Instalación, y configuración de las máquinas virtuales

necesarias para alojar los citados componentes.

Instalación y configuración del software base o en su caso

integración con el software base existente (en el caso de

reutilización del sistema gestor de base de datos por ejemplo)

2 Según datos del “Estudio de Apps Turísticas 2013” publicado por la Sociedad

Estatal para la Gestión de la Innovación y las Tecnologías Turísticas, S.A.

(SEGITTUR) (http://www.segittur.es/es/sala-de-prensa/detalle-documento/Estudio-

Apps-Tursticas-2013/ )







Pág. 203 de 243



Exp.093/16-AE

suministrado según las directrices de Red.es o quien ésta

determine.

Configuración e integración con la red de comunicaciones del

Ayuntamiento, garantizando la puesta en marcha de todo el

conjunto.

3.1.5.5. (√) El adjudicatario deberá realizar la instalación y configuración de

los elementos software y la parametrización de los componentes

base necesarios para el correcto funcionamiento de las plataformas

objeto de implantación descritas en el presente Pliego (gestor de

contenidos, bases de datos, etc) así como cualquier otro ofertado

por el licitador para el correcto funcionamiento del entorno.

Este software será implantado por el adjudicatario en el entorno virtual

configurado en el presente procedimiento de licitación. El adjudicatario

realizará desde la más básica instalación del RAID de discos si fuera

necesario, Sistema Operativo, etc, hasta el bastionado, virtualización,

configuración y ajuste de la solución software, que constituya una solución

integral.











3.1.5.7. (√) Configuración y parametrización de los entornos de las

aplicaciones móviles, incluyendo la creación perfiles de usuario,

formularios y de ayuda en línea de la misma.







Pág. 204 de 243



Exp.093/16-AE





3.1.5.9. (√) Entregables



Informe de publicación de aplicaciones en las tiendas online.

Informe de ejecución del plan de pruebas

Acta de aceptación de los trabajos

3.1.5.10. (√) Presentación y aprobación de las aplicaciones móviles y sus

entornos.

3.1.5.11. (√) Capacitación, en la utilización, administración y mantenimiento

de los desarrollos implementados. Siguiendo los requisitos

generales descritos en el apartado 2.1.8 del presente Pliego. El

adjudicatario deberá impartir un mínimo de 4 horas de capacitación

al perfil de usuario y un mínimo de 4 horas al perfil de

administrador.

3.1.6. Implantación y configuración del Componente 7

3.1.6.1. (√) Ejecución de todos los trabajos descritos en el Componente 7

3.1.6.2. (√) Ejecución de la integración de todos los componentes en la

plataforma Smart Alba descrita en el Componente 10, ejecutando

para ello todas las tareas que sean necesarias (importación de

datos, conexión a través de APIs o servicios web, integración de

sensores o dispositivos hardware en la plataforma de ciudad, etc)








Pág. 205 de 243



Exp.093/16-AE



Informe de pruebas


3.1.7. Instalación y configuración del Componente 8

3.1.7.1. (√) Instalación configuración y parametrización de todos los

elementos integrantes del Componente 8 (Hardware y Software)


Estudio de ubicación y estudio de cobertura que demuestre que el

equipamiento a implantar objeto de la licitación cumple los

requisitos definidos en el apartado 2.9

Equipamiento suministrado e instalado: documentación de soporte,


Informe de instalación y configuración en el que se reflejen todos

los aspectos de instalación y configuración del sistema.

Informe de pruebas



Las actuaciones del Componente 11 se desarrollarán en las ubicaciones de

los estacionamientos identificados en el aparatado 2.12, si bien estas

tareas pueden requerir actuaciones en el CPD del Ayuntamiento.

3.1.8.1. (√) Instalación de todos los elementos integrantes del Componente

11: dispositivos de detección de aforamiento, sensores de

aparcamiento, sistemas de comunicaciones, sistema de

visualización de estado de plazas, software de gestión.







Pág. 206 de 243



Exp.093/16-AE

3.1.8.2. (√) Dispositivos de detección de aforamiento: El licitador deberá de

proceder a la instalación de los mismos en los lugares indicados,

junto con todo el equipamiento necesario para su funcionamiento.

La obra civil (en caso de ser necesaria) así como la instalación de

todos los elementos que lo componen deberá ser realizada por el

licitador

3.1.8.3. (√) Sensores de aparcamiento: El licitador deberá de proceder a la

instalación de los mismos en los lugares indicados.

3.1.8.4. (√) Sistema de comunicaciones: La obra civil así como la instalación

de todos los elementos que lo componen deberá ser realizada por el

licitador.

3.1.8.5. (√) Sistema de visualización de estado de plazas: La obra civil así

como la instalación de todos los elementos que lo componen deberá

ser realizada por el licitador.

3.1.8.6. (√) Software de gestión: Instalación, configuración y

parametrización de todos los elementos que lo componen (así como

integración con los parking subterráneos) en el Ayuntamiento de

Badajoz en el entorno virtualizado creando un nodo espejo en el

Ayuntamiento de Almendralejo y estableciendo los mecanismos de

respaldo que sean necesarios para su actualización.

3.1.8.7. (√) Integración de la instalación con la aplicación móvil de Guiado a

Aparcamientos descrita en el componente 6.


Equipamiento suministrado e instalado: documentación de soporte,


Informe de instalación y configuración en el que se reflejen todos

los aspectos de instalación y configuración del sistema.

Informe de pruebas







Pág. 207 de 243



Exp.093/16-AE


3.1.9. Inventariado de los elementos suministrados

3.1.9.1. (√) Es responsabilidad del adjudicatario proporcionar la información

de inventario necesaria para el correcto seguimiento de todos los

activos, identificando los elementos HW y los SW tanto durante el

suministro e instalación como durante la garantía, incluyendo

números de serie, marcas y modelos, fechas y lugares de

suministro e instalación, identificación de albaranes o actas de

recepción y otros datos que especifique Red.es asociados a la

entrega y aceptación.

3.1.9.2. (√) La información de activos se considera parte de la entrega de

los mismos, y es necesaria para su aceptación.

3.1.9.3. (√) El adjudicatario se obliga al uso de la herramienta de Gestión de

Activos de Red.es, accesible vía web, adecuándose a las

instrucciones de uso que le proporcionará Red.es.

3.1.9.4. (√) El soporte y formato de dicha información será especificado por

Red.es para todos los activos y sus elementos, tanto hardware

como software, y su introducción en la herramienta de Gestión de

Activos de Red.es se realizará a través de carga de ficheros, según

plantillas suministradas por Red.es y cumplimentadas por el

adjudicatario con los datos de los activos.

3.1.9.5. (√) Asimismo, el adjudicatario deberá mantener actualizado dicho

inventario por los mismos medios frente a los cambios debidos a

sustituciones o recambios hasta el fin de la duración de la garantía.

3.1.9.6. (√) El adjudicatario deberá adecuarse a cualquier cambio en los

procedimientos y la tecnología que soporte el proceso de Gestión

de Activos vigente en Red.es.







Pág. 208 de 243



Exp.093/16-AE

3.1.10. Pruebas de funcionamiento

3.1.10.1. (√) El adjudicatario propondrá los protocolos de pruebas a realizar

para verificar el correcto funcionamiento de los elementos

instalados.

3.1.10.2. (√) Estos protocolos de pruebas contendrán, al menos, los

siguientes apartados:

Descripción del equipamiento a probar.

Conjunto de casos de prueba. Para cada uno:

o Objeto (elemento, parámetro o funcionalidad a

comprobar).

o Descripción detallada de los pasos para realizar la

prueba.

o Resultados esperados.

3.1.10.3. (√) El adjudicatario entregará los resultados de la aplicación del

protocolo de pruebas en un informe de pruebas, con una estructura

acorde al protocolo de pruebas.

3.1.10.4. (√) El adjudicatario utilizará para realizarlas su equipamiento de

medición y personal propio.

3.1.10.5. (√) Red.es se reserva el derecho de no ejecutar alguna de las

pruebas incluidas en los protocolos de pruebas cuando las

condiciones de ejecución de las mismas lo desaconsejen, y podrá

solicitar al adjudicatario la inclusión de pruebas adicionales en los

protocolos de pruebas.

3.1.10.6. (√) La planificación de las pruebas se coordinará con Red.es.

3.1.11. Entrega y Aceptación

3.1.11.1. (√) Para formalizar la entrega de los diferentes elementos y

prestaciones objeto del contrato el adjudicatario redactará las







Pág. 209 de 243



Exp.093/16-AE

correspondientes actas, las presentará para su firma y sellado a los

representantes de las entidades receptoras de dichas prestaciones,

y las remitirá a Red.es para su aceptación.

3.1.11.2. (√) Red.es definirá los formatos y contenido de las actas e

información asociada (que podrán incluir, entre otros, resultados de

pruebas, fotos generales y de detalle, esquemas, etiquetados

inventarios de las instalaciones) e indicará al adjudicatario los

representantes designados para la firma y sello de las mismas.

3.1.12. Gestión del Proyecto

3.1.12.1. (√) El adjudicatario designará un Jefe de Proyecto como

interlocutor principal con Red.es durante la ejecución del proyecto.

3.1.12.2. (√) El Jefe de Proyecto realizará un seguimiento continuo de la

evolución del proyecto y asistirá junto con los técnicos que se

estime conveniente a las reuniones de seguimiento y revisiones

técnicas que convoque Red.es en la sede y con la periodicidad que

ésta designe.

3.2. Plazos

Los plazos descritos en los siguientes apartados, una vez realizado el pedido por

parte de Red.es, finalizan a la aceptación por parte de Red.es de la entrega y

puesta en marcha de todos los elementos, prestaciones y documentación

asociados al pedido. El adjudicatario deberá tener en cuenta que los plazos

incluyen que los entregables de cada componente hayan sido validados por los

técnicos de Red.es (o los que la Entidad determine) que levantarán un acta de

conformidad indicando expresamente su aprobación y en su defecto las

deficiencias encontradas y que deberán ser subsanadas en el menor tiempo

posible, así como la corrección de disconformidades y errores que puedan

detectarse en los ciclos de pruebas. Red.es se reserva el derecho a validar y

aceptar dichos documentos y solicitar al adjudicatario cuantas aclaraciones o

modificaciones sean necesarias para la aceptación de los mismos.







Pág. 210 de 243



Exp.093/16-AE

Cualquier incumplimiento de plazo con independencia de la fase en la que se

produzca acopio de material, envío de equipamiento, desarrollo, instalación,

integración, envío de documentación, etc…) acarreará las penalizaciones descritas

en el apartado 6 del Pliego de condiciones Particulares.

3.2.1. Fase I

3.2.1.1. (√) El plazo máximo para completar los trabajos de suministro e

implantación descritos para el componente 1 en los apartados 2 y 3

del presente Pliego será de 60 días naturales desde la emisión del

correspondiente pedido por parte de Red.es.

3.2.1.2. (√) El plazo máximo para completar los trabajos de desarrollo

descritos para los componentes 2, 3.1 y 3.3 en los apartados 2 y 3

del presente Pliego será de 90 días naturales desde la emisión del

correspondiente pedido por parte de Red.es.

3.2.1.3. (√) El plazo máximo para completar los trabajos de suministro e

implantación descritos para los componentes 5, 7, y 8 en los

apartados 2 y 3 del presente Pliego será de 150 días naturales

desde la emisión del correspondiente pedido por parte de Red.es.

3.2.2. Fase II

3.2.2.1. (√) El plazo máximo para completar los trabajos de desarrollo,

suministro e implantación descritos para los componentes 4, 6, 9,

10, 11 y 12 en los apartados 2 y 3 del presente Pliego será de 270

días naturales desde la emisión del correspondiente pedido por

parte de Red.es.

3.2.3. Capacitación.

3.2.3.1. (√) El plazo máximo para completar los trabajos de descritos para

el componente 3.2 en los apartados 2 y 3 del presente Pliego







Pág. 211 de 243



Exp.093/16-AE

estará comprendido entre la entrega del componente 3.3 y la

finalización del contrato.

3.3. Requisitos de garantía

3.3.1. Declaración de Garantía

(√) La contratación del suministro y prestaciones para la implantación de

los equipos suministrados incluye una garantía integral in-situ prestada

por el adjudicatario que asegure que todas las infraestructuras, software,

funcionalidades y elementos suministrados se conservan en condiciones

óptimas y están disponibles para su utilización.

3.3.2. Duración de la Garantía

(√) El inicio del plazo de garantía se produce a la aceptación por parte de

Red.es de las actuaciones objeto del Contrato. Una vez aceptado por

Red.es cualquier elemento o prestación del Contrato, dicho elemento o

prestación entrará en garantía en función de lo siguiente:

1. (√) Software

El adjudicatario deberá garantizar el resultado de los desarrollos que se

realicen en relación a la solución ofertada para los Componente 1, 3, 4, 6,

7, 8, 9, 10, 11 y 12. El período de garantía tendrá una duración de 12 meses,

a contar desde la fecha de aceptación de Red.es de la puesta en

producción del software.

En el caso de que alguna de las funcionalidades y prestaciones de los

elementos suministrados para el desarrollo de la iniciativa, necesitaran

algún tipo de licencia para ser utilizadas durante la implantación o la

garantía, dicha licencia estará incluida en la solución y será suministrada

por el adjudicatario como parte de la misma. La vigencia de las licencias

suministradas así como la garantía de las mismas será de 5 años







Pág. 212 de 243



Exp.093/16-AE

(atendiendo a las obligaciones FEDER) a contar desde la fecha de

aceptación de las actuaciones por parte de Red.es

2. (√) Hardware

El adjudicatario estará obligado a prestar un servicio de garantía para

todos los activos que conforman los Componentes 1, 5, 7, 8 y 11. El periodo

de garantía tendrá una duración de 5 años (atendiendo a las obligaciones

FEDER), a contar desde de la fecha de aceptación del equipamiento por

parte de Red.es, que coincidirá con la instalación y configuración de los

activos (hardware o software) en su ubicación final. Esta garantía no

incluye desperfectos ocasionados por el mal uso del equipamiento o actos

vandálicos.

(√) Red.es se reserva el derecho de gestionar la garantía directamente o a

través de terceros: apertura de incidencias, aceptación de su resolución,

control de los tiempos de resolución, etc.

3.3.3. Cobertura de la Garantía Hardware

(√) La contratación incluye una garantía integral in-situ prestada por el

adjudicatario que cubre todos aquellos materiales, equipos, elementos de

conexión, software, documentación y en general sobre todos los

elementos suministrados y cualquier trabajo y prestación que el

adjudicatario haya realizado como parte del contrato.

(√) Aunque se establezca este ámbito de responsabilidad, el equipamiento

suministrado se integra en un Centro de Proceso de Datos en los que

conviven e interactúan diversos sistemas que deben estar operativos con

los mismos criterios de calidad para prestar un servicio homogéneo. En

este sentido, la colaboración entre los distintos suministradores de la

infraestructura global es un requisito. Por tanto, en aquellos casos en los

que algún componente incluido en el presente contrato, esté conectado o

interactúe con elementos cuyo suministro u operación corresponda a

empresas diferentes de la adjudicataria del presente contrato, el

adjudicatario deberá responder del correcto funcionamiento de los







Pág. 213 de 243



Exp.093/16-AE

elementos suministrados, debiendo demostrar los casos en los que

considere que un mal funcionamiento de dichos elementos sea causado

por fallos imputables a otros suministradores.

(√) Se requiere que el adjudicatario colabore en todos los supuestos de

fallos con el resto de entidades suministradoras para detectar y eliminar

cualquier problema que esté afectando a la operatividad de los elementos

suministrados.

(√) El adjudicatario dispondrá de un centro de gestión de incidencias y

soporte. Este centro estará accesible a Red.es y a quien ésta designe,

durante un horario de 8x5h de lunes a viernes, de 9:00 a 17:00h, a través

de teléfono y mediante una dirección de correo electrónico para la

notificación de incidencias y realización de consultas. El idioma que se

utilizará en todas las comunicaciones será el castellano.

(√) El adjudicatario realizará todas las intervenciones in-situ que sean

necesarias para la corrección de cualquier defecto, problema de

funcionamiento, degradación o incidencia en el sistema suministrado y en

los trabajos realizados, incluyendo su diagnóstico y su corrección

mediante sustitución o reparación del elemento o elementos afectados y

la aportación y carga de versiones y actualizaciones (“patches”) de

software y firmware que resuelvan problemas o defectos.

(√) El adjudicatario asumirá todos los suministros, transportes y gestiones

para la reparación o reposición de los elementos averiados o defectuosos.

(√) El adjudicatario asegurará la mínima interrupción del servicio durante

la resolución de las incidencias, actuando en cualquier caso de acuerdo

con las ventanas de actuación que establezca Red.es o quien ésta designe.

(√) Cuando por rotura de stock o descatalogación no sea posible

reemplazar un equipo o elemento por otro igual, será sustituido por otro

de mayores prestaciones.







Pág. 214 de 243



Exp.093/16-AE

(√) Se mantendrá informado a Red.es o quien ésta determine en todo

momento y de manera detallada de cualquier acción a tomar para la

resolución de una incidencia.

(√) El adjudicatario deberá adecuarse a cualquier cambio en los

procedimientos y la tecnología que soporte el proceso de Reporte de

Incidencias vigente en Red.es.

(√) El adjudicatario debe proporcionar a Red.es, con una periodicidad al

menos mensual, enviado antes del día 5 de cada mes, en el formato digital

definido por Red.es, un Informe de Garantía de Servicio con las incidencias

reportadas y los tiempos de resolución de las mismas. El informe deberá

contener, al menos, la siguiente información:

Identificador de incidencia

Día y Hora de notificación de la incidencia

Severidad

Ubicación donde se produce la incidencia, cuando proceda

Análisis de la incidencia, causas y forma de resolución

Cuando la resolución de la incidencia implique la sustitución de un

equipo o componente:

Marca y modelo del equipo averiado e identificación del

componente

Nº de Serie del equipo (o componente) averiado

Marca y modelo del equipo repuesto e identificación del

componente

Nº de Serie del equipo (o componente) repuesto

Día y hora de resolución de la incidencia







Pág. 215 de 243



Exp.093/16-AE

Tiempo de resolución

(√) El adjudicatario debe proporcionar a Red.es, con una periodicidad al

menos semanal, enviado antes del miércoles de cada semana en el

formato digital definido por Red.es, un Informe de Incidencias Pendientes

con detalle de las incidencias aún abiertas en la fecha de envío de dicho

informe. El informe deberá contener, al menos, la siguiente información:

Identificador de incidencia

Día y Hora de notificación de la incidencia

Severidad

Ubicación donde se produce la incidencia, cuando proceda

Identificación del elemento averiado, cuando proceda

Día y hora de resolución prevista

En todos aquellos casos en los que el adjudicatario se demore en el envío de estos

informes, Red.es procederá a la aplicación de las penalizaciones establecidas al

efecto en el apartado 6 del Pliego de Condiciones Particulares.

3.3.4. Tiempos máximos de resolución de incidencias y consultas

Este nivel de servicio aplica a todos los elementos con periodo de garantía

vigente conforme lo detallado en el apartado 3.3. “Requisitos de

Garantía”.

3.3.4.1. (√) Red.es se reserva el derecho de solicitar al adjudicatario, sin

coste adicional, la puesta a disposición del servicio de alguna

herramienta propia para la gestión centralizada de las incidencias

que deberá ser accesible online y telefónicamente.

3.3.4.2. (√) El adjudicatario estará en disposición de recibir comunicaciones

de soporte e incidencias, mediante canal online o telefónico, con

disponibilidad 8x5h de lunes a viernes, de 9:00h a 17:00h.







Pág. 216 de 243



Exp.093/16-AE

3.3.4.3. (√) El tiempo de respuesta, entendido como el periodo transcurrido

desde la comunicación de la incidencia hasta la respuesta del

centro de gestión de la empresa adjudicataria, con indicación de la

causa probable de la incidencia y del tiempo estimado de resolución

deberá ser inferior a 4 horas para todo tipo de incidencias.

3.3.4.4. (√) El tiempo de resolución de una incidencia o consulta se define

como el comprendido entre el momento en que Red.es o quien ésta

determine solicita la apertura de la incidencia o consulta y el

momento de su resolución.

3.3.4.5. (√) Las incidencias y consultas se clasifican en cuatro tipos, en

función de su severidad. El nivel de severidad será asignado por

Red.es o quien ésta determine en el momento de abrir una

incidencia. Se definen los siguientes niveles de severidad y el

tiempo de resolución asociado a ellos:







Pág. 217 de 243



Exp.093/16-AE

Nivel de

severidad

Descripción Tiempo de

resolución

Crítico Incidencias que impiden el funcionamiento

de alguno de los elementos software

suministrados

24 horas

Incidencias que impiden el funcionamiento

de alguno de los elementos hardware

suministrados

8 horas

Alto Incidencias que afecten parcialmente al

funcionamiento de alguno de los elementos

software suministrados

72 horas

Incidencias que afecten parcialmente al

funcionamiento de alguno de los elementos

hardware suministrados

12

Medio Incidencias o defectos en las prestaciones

del adjudicatario, incluyendo documentación,

que no afectan al funcionamiento de los

elementos software suministrados

Cinco días

laborables

Incidencias o defectos en las prestaciones

del adjudicatario, incluyendo documentación,

que no afectan al funcionamiento de los

elementos hardware suministrados

48 horas

Bajo Consultas: requerimientos de información y

clarificación sobre aspectos técnicos

relacionados con los elementos

suministrados

Cinco días

laborables

3.3.4.6. (√) Una incidencia se cerrará cuando Red.es o quien ésta

determine haya aceptado dicho cierre, lo que se dará cuando el







Pág. 218 de 243



Exp.093/16-AE

servicio se haya restablecido y estabilizado, y se haya informado a

Red.es o a quien ésta designe.

3.3.4.7. (√) Si después de cerrar una incidencia se vuelven a presentar los

mismos fallos que se dieron por resueltos, se reabrirá la misma

incidencia anterior.

3.3.5. Parámetros de medida para el cómputo de penalizaciones

3.3.5.1. (√) A efectos de no tener en cuenta en el cómputo la existencia de

posibles demoras no imputables al adjudicatario, a través de la

herramienta de gestión de las incidencias se establecerán periodos

que no serán computables a efectos del establecimiento de

penalizaciones. En este sentido, cualquiera que sea la herramienta

utilizada para la gestión de incidencias ésta contemplará estados

de “parada de reloj” (p.e. cuando se necesita la acción del cliente),

que implican que el tiempo transcurrido desde su inicio hasta su

terminación no se computa a efectos de penalizaciones.

3.3.5.2. (√) El adjudicatario únicamente podrá activar el estado “parada de

reloj” cuando se produzca una causa justificada, que deberá, en

todo caso, acreditar de forma pormenorizada y exhaustiva. Red.es

auditará el uso por parte del adjudicatario del estado “parada de

reloj”, en caso de no justificarse, se contabilizará el tiempo total de

incidencia, desde su apertura hasta su cierre.

3.3.5.3. (√) Red.es revisará mensualmente el nivel de prestación del

servicio del adjudicatario a efectos de valorar si procede o no la

imposición de penalizaciones de acuerdo con el sistema previsto en

el presente apartado. No obstante lo señalado anteriormente,

Red.es podrá aumentar o reducir el periodo que se tendrá en

cuenta, en cuyo caso será notificado con antelación al

adjudicatario.







Pág. 219 de 243



Exp.093/16-AE

3.3.5.4. (√) La tabla siguiente detalla los niveles del servicio, que serán

utilizados para el cómputo de las penalizaciones, en función al

porcentaje de cumplimiento del servicio.

Nivel de prestación

del Servicio

% Cumplimiento del servicio (x)

(porcentaje de incidencias o

peticiones que no superan los

Tmax)

óptima X >= 90%

no óptima X <90%

3.3.5.5. En todos aquellos casos que el adjudicatario no alcance un nivel de

cumplimiento en la prestación del servicio igual o mayor al 90%,

Red.es procederá a la aplicación de las penalizaciones establecidas

al efecto en el Apartado 6 del Pliego de Condiciones Particulares.

Sin perjuicio de lo anterior, en aquellos casos en los que Red.es

considere, se exigirá al adjudicatario la adopción del

correspondiente plan de mejora.







Pág. 220 de 243



Exp.093/16-AE

4. Control económico y de facturación

4.1. Control de facturación

El adjudicatario emitirá las facturas correspondientes previa aceptación por Red.es

de la correcta realización de los trabajos, que tendrá que ser avalada por la

aportación de la documentación requerida para acreditarlo.

Las facturas deberán emitirse con el formato fijado por Red.es, en todo caso

deberán contener el desglose de los impuestos indirectos aplicables indicando el

número de expediente del Contrato, y se corresponderán en forma y contenido con

el correspondiente pedido realizado por Red.es debiendo hacer constar el número

de pedido.

Además de la información de suministro e instalación del equipamiento se cargará

en la herramienta de Gestión de Activos de Red.es la información de la factura

vinculada a esos equipos. Esta información es independiente de la gestión de la

facturación a través de e-albarán/e-factura.

4.2. Hitos de facturación

Los hitos de facturación se corresponden con los precios unitarios especificados

en el modelo de proposición económica del apartado 5.2.2 del presente Pliego, y

que se describen a continuación, y se irán facturando a medida que Red.es vaya

aceptando las distintas entregas y la documentación de soporte que acredite su

efectiva realización y tras la comprobación de la información introducida por el

adjudicatario en la herramienta de inventario de Red.es:

P1: Precio unitario (impuestos indirectos aplicables excluidos) para el

Componente 1.1, Suministro e instalación del sistema de Almacenamiento

de Altas Prestaciones, según lo descrito en el apartado 2.2.1 del

presente Pliego







Pág. 221 de 243



Exp.093/16-AE


Componente 1.2, Suministro e instalación del Chasis Blade, según lo

descrito en el apartado 2.2.2 del presente Pliego


Componente 1.3, Suministro e instalación del Servidor Blade de dos vías,

según lo descrito en el apartado 2.2.3 del presente Pliego


Componente 1.4, Suministro e instalación del Servidor Blade de una vía,



Componente 1.5, Suministro e instalación de Conmutadores de red para

Servidores, según lo descrito en el apartado 2.2.5 del presente Pliego



usuarios, según lo descrito en el apartado 2.2.6 del presente Pliego


Componente 1.7, Suministro e instalación de una licencia Windows

Server 2016, según lo descrito en el apartado 2.2.7 del presente Pliego


Componente 1.8, Suministro e instalación de Licencias de Virtualización,



Componente 2, Flujos de Movilidad Turística, según lo descrito en el

apartado 2.3 del presente Pliego


Componente 3.1, Elaboración Plan de Actuación, según lo descrito en el

apartado 2.4.1 del presente Pliego


Componente 3.2, Desarrollo y ejecución del Programa de Capacitación,








Pág. 222 de 243



Exp.093/16-AE


Componente 3.3., Desarrollo e instalación de Página Web, según lo



Componente 4, Desarrollo e instalación del Portal de Transparencia y

Datos Abiertos, según lo descrito en el apartado 2.5 del presente Pliego


Componente 5.1, Suministro e instalación de Puntos de Acceso Wifi,



Componente 5.2, Suministro e instalación de Controladora Wifi, según lo



Componente 6.1, Desarrollo e instalación del Entorno Web para

aplicaciones móviles , según lo descrito en el apartado 2.7.1 del presente

Pliego


Componente 6.2, Desarrollo e instalación de aplicación web lanzadera,



Componente 6.3, Desarrollo e instalación de aplicación web de gestión

de Autobuses , según lo descrito en el apartado 2.7.3 del presente

Pliego


Componente 6.4, Desarrollo e instalación de aplicación móvil de Gestión

Ciudadana, según lo descrito en el apartado 2.7.4 del presente Pliego


Componente 6.5, Desarrollo e instalación de aplicación móvil de guiado a

aparcamientos, según lo descrito en el apartado 2.7.5 del presente

Pliego







Pág. 223 de 243



Exp.093/16-AE


Componente 7.1, Suministro e implantación de dispositivos GPS , según

lo descrito en el apartado 2.8.1 del presente Pliego


Componente 7.2, Suministro e implantación de Sistema de Gestión para

Control de Flotas, según lo descrito en el apartado 2.8.2 del presente

Pliego


Componente 8, Suministro e implantación de sistema de control de

afluencia, según lo descrito en el apartado 2.9 del presente Pliego


Componente 9, Encuestas a ciudadanía y visitantes, según lo descrito en

el apartado 2.10 del presente Pliego


Componente 10, Desarrollo e implantación de la plataforma Smart Alba

2020, según lo descrito en el apartado 2.11 del presente Pliego


Componente 11, Suministro e implantación de sistema de Gestión de

aparcamientos, según lo descrito en el apartado 2.12 del presente Pliego


Componente 12, Servicio de Integración de datos en la Plataforma Smart

Alba 2020, según lo descrito en el apartado 2.13 del presente Pliego

5. Formato y contenido de la propuesta

Con carácter general, la información presentada en la propuesta debe estar

estructurada de forma clara y concisa. La propuesta no debe contener referencias

a documentos externos o anexos no incluidos cuando éstos sean puntos clave en la

valoración de la propuesta.







Pág. 224 de 243



Exp.093/16-AE

Red.es se reserva el derecho a exigir a los licitadores que presenten

documentación que acrediten la veracidad de la información presentada en la

oferta o bien información adicional sobre el contenido de la misma, estando el

licitador obligado a ello.

Red.es podrá requerir a los licitadores que formulen por escrito las aclaraciones

necesarias para la comprensión de algún aspecto de sus proposiciones. En ningún

caso se admitirá que en proceso de aclaraciones el licitador varíe los términos

expresados en su propuesta. Sólo se admitirá la información que facilite el análisis

de la solución propuesta inicialmente.

Se dará la posibilidad de que todo licitador pueda realizar de forma previa a la

presentación de su oferta, si lo considera necesario, una visita a las instalaciones

de los ayuntamientos (parking, CPD e instalaciones para el control de afluencia).

La fecha para la correspondiente visita se publicará en el perfil del contratante de

Red.es.

La presentación de propuestas deberá cumplir las prescripciones del Pliego de

Condiciones Particulares. Adicionalmente, la propuesta relativa a los criterios

cuantificables mediante la mera aplicación de fórmulas (Sobre “Criterios

cuantificables por fórmula”) deberá incluir la información y presentar la estructura

que se detalla a continuación.

5.1. Propuesta relativa a los criterios cuya valoración depende

de un juicio de valor (sobre “Criterios de juicio de valor”)

IMPORTANTE: A los efectos del cumplimiento de lo establecido en los artículos 26

y 30.2 del Real Decreto 817/2009, de 8 de mayo, por el que se desarrolla

parcialmente la Ley 30/2007, de 30 de octubre, de Contratos del Sector Público,

el licitador no deberá incluir en el sobre 3 información de la oferta que, de

conformidad con el apartado siguiente, sea valorada de forma cuantificable







Pág. 225 de 243



Exp.093/16-AE

mediante la mera aplicación de fórmulas. En caso contrario, la oferta de dicho

licitador NO será tenida en cuenta en el presente procedimiento.

En este sentido, cuando el licitador deba referirse a aspectos relacionados con

alguno de los datos incluidos en el Sobre 4, se incluirá la mención “Ver dato en

Sobre 4”.

La propuesta relativa a los criterios cuya valoración depende de un juicio de valor,

además de presentarse por escrito, deberá adjuntarse en soporte electrónico,

ambas por duplicado.

Con carácter general, la información presentada en la oferta técnica debe estar

estructurada de forma clara y concisa. La propuesta no debe contener referencias

a documentos externos o anexos no incluidos, cuando éstos sean puntos clave en

la valoración de la propuesta.

La propuesta deberá incluir los siguientes apartados y en el mismo orden:

5.1.1. Introducción.

Deberá incluir:

• Identificación de la oferta.

• Relación a modo de índice de la documentación incluida en la que el

licitador deberá numerar y nombrar los documentos aportados.

• Aceptación con carácter general de las condiciones de los pliegos.

• Datos de la empresa licitadora.

• Confidencialidad de la información contenida en la oferta: se deberá

indicar si la información contenida en la oferta tiene carácter

confidencial.

Esta introducción no deberá superar las dos (2) páginas.







Pág. 226 de 243



Exp.093/16-AE

5.1.2. Verificación del cumplimiento de requisitos obligatorios

El licitador deberá incluir la información necesaria que permita a Red.es para

verificar el cumplimiento de los todos los requisitos requeridos de los

componentes 10, 11 y 12 del presente pliego.

5.1.3. Requisitos valorables mediante juicio de valor

5.1.3.1. (√) Propuesta de solución para el Componente 10 e integración con

los componentes 4, 5, 6, 7, 8, 9 y 12.

Para lo cual se aportarán grafos lógicos de las diferentes relaciones

y flujos de datos entre componentes. Se deberá detallar las

relaciones y dependencias funcionales entre los diferentes

componentes así como los flujos de información entre ellos. Se

aportarán procedimientos de escalado horizontal y vertical. Se

valorará la forma en que se plantee la integración y la gestión de los

datos, dando cumplimiento a los requisitos mínimos de integración

establecidos en el pliego.

Tal como se establece en el Pliego de Condiciones Particulares, se

valorarán los mecanismos y herramientas previstas en la propuesta

de solución que, con el objeto de obtener una solución global

eficiente, robusta, flexible y escalable: Plantee la integración de

sistemas y la gestión de los datos entre ellos, facilitando el escalado

a futuro de la solución propuesta con los mínimos medios y

componentes necesarios y minimice el coste de mantenimiento y

escalado de la solución

5.1.3.2. (√) Mejoras. Se entenderá por mejora toda propuesta de servicios o

prestación adicional formulada por los licitadores en relación al

objeto del contrato no incluida en los requisitos de los Pliegos. En

ningún caso se podrá proponer como mejora el ofrecimiento de un

número superior al requerido de los mismos servicios que







Pág. 227 de 243



Exp.093/16-AE

constituyen el objeto del contrato. El importe de estas mejoras

estará necesariamente incluido en el precio global ofertado.

5.2. Propuesta relativa a los criterios cuantificables mediante la

mera aplicación de fórmulas (sobre “Criterios cuantificables por

fórmula”)

El licitador presentará su propuesta siguiendo los modelos que se adjuntan al

presente Pliego para la proposición económica y para la proposición del resto de

los criterios cuantificables mediante la mera aplicación de fórmulas.

A los efectos del cumplimiento de lo establecido en los artículos 26 y 30.2 del Real

Decreto 817/2009, de 8 de mayo, por el que se desarrolla parcialmente la Ley

30/2007, de 30 de octubre, de Contratos del Sector Público, el licitador NO

deberá incluir la siguiente información cuantificable mediante la mera aplicación

de fórmulas en el sobre de “Documentación Administrativa”. En caso contrario, la

oferta de dicho licitador no será tenida en cuenta en el presente procedimiento.

5.2.1. Proposición Económica

La proposición se presentará siguiendo el modelo en formato hoja de cálculo que

se incluye en el siguiente apartado y que se adjunta al presente pliego (es de uso

obligatorio).

La proposición económica se estructurará proporcionando precios para los

conceptos que se enumeran a continuación. Todos los precios se deben

proporcionar en Euros, calculados y presentados con DOS decimales e Impuestos

indirectos aplicables excluidos.


Componente 1.1, Suministro e instalación del sistema de Almacenamiento

de Altas Prestaciones, según lo descrito en el apartado 2.2.1 del

presente Pliego







Pág. 228 de 243



Exp.093/16-AE


Componente 1.2, Suministro e instalación del Chasis Blade, según lo



Componente 1.3, Suministro e instalación del Servidor Blade de dos vías,



Componente 1.4, Suministro e instalación del Servidor Blade de una vía,




Servidores, según lo descrito en el apartado 2.2.6 del presente Pliego



usuarios, según lo descrito en el apartado 2.2.7 del presente Pliego


Componente 1.7, Suministro e instalación del Licencia Windows Server

2016 según lo descrito en el apartado 2.2.4 del presente Pliego


Componente 1.8, Suministro e instalación de Licencias de Virtualización,



Componente 2, Flujos de Movilidad Turística, según lo descrito en el

apartado 2.3 del presente Pliego


Componente 3.1, Elaboración Plan de Actuación, según lo descrito en el

apartado 2.4.1 del presente Pliego


Componente 3.2, Desarrollo y ejecución del Programa de Capacitación,








Pág. 229 de 243



Exp.093/16-AE


Componente 3.3., Desarrollo e instalación de Página Web, según lo



Componente 4, Desarrollo e instalación del Portal de Transparencia y

Datos Abiertos, según lo descrito en el apartado 2.5 del presente Pliego


Componente 5.1, Suministro e instalación de Puntos de Acceso Wifi,



Componente 5.2, Suministro e instalación de Controladora Wifi, según lo



Componente 6.1, Desarrollo e instalación del Entorno Web para

aplicaciones móviles , según lo descrito en el apartado 2.7.1 del presente

Pliego


Componente 6.2, Desarrollo e instalación de aplicación web lanzadera,



Componente 6.3, Desarrollo e instalación de aplicación web de gestión

de Autobuses , según lo descrito en el apartado 2.7.3 del presente

Pliego


Componente 6.4, Desarrollo e instalación de aplicación móvil de Gestión

Ciudadana, según lo descrito en el apartado 2.7.4 del presente Pliego


Componente 6.5, Desarrollo e instalación de aplicación móvil de guiado a

aparcamientos, según lo descrito en el apartado 2.7.5 del presente

Pliego







Pág. 230 de 243



Exp.093/16-AE


Componente 7.1, Suministro e implantación de dispositivos GPS , según

lo descrito en el apartado 2.8.1 del presente Pliego


Componente 7.2, Suministro e implantación de Sistema de Gestión para

Control de Flotas, según lo descrito en el apartado 2.8.2 del presente

Pliego


Componente 8, Suministro e implantación de sistema de control de

afluencia, según lo descrito en el apartado 2.9 del presente Pliego


Componente 9, Encuestas a ciudadanía y visitantes, según lo descrito en

el apartado 2.10 del presente Pliego


Componente 10, Desarrollo e implantación de la plataforma Smart Alba

2020, según lo descrito en el apartado 2.11 del presente Pliego


Componente 11, Suministro e implantación de sistema de Gestión de

aparcamientos, según lo descrito en el apartado 2.12 del presente Pliego


Componente 12, Servicio de Integración de datos en la Plataforma Smart

Alba 2020, según lo descrito en el apartado 2.13 del presente Pliego

La fórmula que se establece para el cálculo del PRECIO DE OFERTA, es la

siguiente:

Precio Oferta (Pi) = 2 x P1+ 2 x P2+ 4 x P3 + 1 x P4+ 4 x P5 + 3 x

P6+ 1 x P7 + 2 x P8+ 1 x P9 + 1 x P10 +1 x P11+ 1 x P12+ 1 x P13 + 20 x P14

+ 2 x P15 + 1 x P16+ 1 x P17 + 1 x P18+ 1 x P19+ 1 x P20 + 54 x P21 + 1 x

P22 + 1 x P23 + 1 x P24 + 1 x P25 + 1 x P26 + 1 X P27







Pág. 231 de 243



Exp.093/16-AE

El precio de la oferta (Pi) no podrá exceder la cantidad de UN MILLÓN QUINIENTOS

TREINTA Y SEIS MIL QUINIENTOS DOCE EUROS CON TREINTA Y CUATRO

CÉNTIMOS DE EURO (1.536.512,34 €) impuestos indirectos aplicables excluidos.

Cualquier oferta que supere dicha cantidad no será tomada en consideración en el

presente procedimiento de adjudicación.







Pág. 232 de 243



Exp.093/16-AE

5.2.2. Modelo de Proposición Económica







Pág. 233 de 243



Exp.093/16-AE







Pág. 234 de 243



Exp.093/16-AE

DANIEL NOGUERA TEJEDOR

DIRECTOR GENERAL DE LA ENTIDAD

PÚBLICA EMPRESARIAL

FRANCISCO JAVIER GARCÍA VIEIRA

DIRECTOR DE SERVICIOS PÚBLICOS

DIGITALES







Pág. 235 de 243



Exp.093/16-AE

ANEXO I Listado de vehículos a instalar el

sistema de control de flotas.

El listado de vehículos en los cuales hay que realizar la instalación del

equipamiento para el control de flotas es el siguiente.

Almendralejo (29 vehículos)

Vehículo Marca Modelo

Turismo Citroen Xsantia 16 v

Dumper nº 8 Agria Dh15

Camión Daf Fa-lf55

Retropala Carterpilar 428d

Dumper nº 9 Agria Dh15

Turismo Ford Escort

Turismo Seat Marbella

Furgon grande Ford Transit

Camión Nissan Trade 100

Furgoneta Renault Kangoo

Dumper nº 12 Ausa D175

Camión Nissan Cabstar

Furgoneta Citroen C15







Pág. 236 de 243



Exp.093/16-AE



Turismo Opel Vectra

Camiión Mercedes Atego

Furgón Ford Transit

Motocarro Vespa Vespacar

Camión Nissan Trade 3.0

Furgoneta mixta Renault Kangoo

Todoterreno Land rover Defender

Motocicleta Honda

Motocicleta Honda

Turismo Peugeot 308 1.6 hdi



Autobus urbano 1

Autobus urbano 2

Badajoz (25 vehículos)

Sección Modelo







Pág. 237 de 243



Exp.093/16-AE

Alcaldia Volvo s80

Alcaldia Volvo s80

Empleo y

formacion

Opel vivaro

Proteccion

animal

Renault Kangoo

Proteccion

animal

Nissan tl 110.35

Colegios Nissan primastar

Alumbrado Nissan ke-1111

Alumbrado Renault express

Alumbrado Renault kg

Alumbrado Reanult

Alumbrado Nissan tl 110.35

Alumbrado Opel combo

Alumbrado Land rover

Alumbrado Opel combo c

Alumbrado Opel combo







Pág. 238 de 243



Exp.093/16-AE

Alumbrado Nissan cabstar

Limp. Y rec. Res.

Soli

Opel corsa

Cementerios Reanault

Cementerios Opel combo

Festejos Citroen

Medio ambiente Renault


Medio ambiente Ford


Medio ambiente Nissan







Pág. 239 de 243



Exp.093/16-AE

ANEXO II Dataset Contabilidad y gestión

tributaria.

GESTIÓN TRIBUTARIA Información sobre DEUDAS

Organismo

Organismo Gestor

Municipio

Tipos de deuda

Tributo

Tasa

Fecha

Ejercicio de la deuda

Ejercicio original de la deuda

Periodo liquidado

Fecha de la última modificación

Fecha de liquidación

Estado de las deudas

Voluntaria / Ejecutiva

Pendiente / Cobrada / Baja / Suspendida

Domiciliación

Entidades bancarias

Devoluciones

Notificación

Fraccionamiento

Devoluciones

Importes

Principal

IVA

Recargo

Costas

Intereses

Varios

Formas de cobro

Bonificaciones

Tipos de operación







Pág. 240 de 243



Exp.093/16-AE

Cargos

Información sobre CONTRIBUYENTES

General

Sexo

Población

Código Postal

Calle

Información sobre OBJETOS TRIBUTARIOS

Inmuebles / Parcelas

Uso

Valores

Catastral

Suelo

Construcción

Cultivos

Superficie

Ejercicio revisión

Nº Titulares

Vehículos

Fecha matriculación

Marca y modelo

Tipo vehículo

Tipo fiscal

Combustible

Emisiones

Tipo movimiento tráfico

Empresas

Epígrafe

Tipo de actividad

Superficie







Pág. 241 de 243



Exp.093/16-AE

CONTABILIDAD Ingresos







Pág. 242 de 243



Exp.093/16-AE

Gastos







Pág. 243 de 243



Exp.093/16-AE

Tipo

Ingreso

Gasto

Nivel de desglose

Capítulo

Artículo

Concepto

Subconcepto

Aplicación

Ejercicio

Entidad

Clasificación Económica

Clasificación Programática

Clasificación Orgánica

Previsiones Iniciales

Modificaciones sobre las previsiones

Previsiones definitivas

Derechos Netos

Ingresos Realizados

Devoluciones Ingresadas

Recaudación Líquida

Pendiente de Cobro

Estado de Ejecución Presupuestaria







PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA ...

Documents

Transcript of PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA ...