PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA ... · Exp.054 /16-AE 1 INTRODUCCIÓN El...

PLIEGO DE PRESCRIPCIONES

TÉCNICAS QUE REGIRÁN LA

REALIZACIÓN DEL CONTRATO DE

“DESARROLLO DE LA INICIATIVA

TOLEDO CIUDAD INTELIGENTE”

EXP. 054/16-AE

PROCEDIMIENTO ABIERTO

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

Firmado Por Daniel Noguera Tejedor - Director General de la Entidad Pública Empresarial Firmado 25/10/2016 09:51:45

Francisco Javier Garcia Vieira Firmado 20/10/2016 22:07:57

Observaciones Página 1/134

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

https://portafirmas.red.es/verifirmav2/code/nWr2QdPYLpGFXa9IhKsyFg==

Pág. 2 de 134

Pliego de Prescripciones Técnicas – Procedimiento Abierto

“Desarrollo de la Iniciativa Toledo Ciudad Inteligente.

Exp.054/16-AE

ÍNDICE

1 INTRODUCCIÓN 4

1.1 DEFINICIONES Y CONSIDERACIONES PREVIAS 6 1.2 ÁMBITO DEL PROYECTO 6 1.3 SITUACIÓN Y ENTORNO TECNOLÓGICO ACTUAL 7 1.3.1 PLATAFORMA DE CIUDAD INTELIGENTE Y APLICACIÓN MÓVIL MUNICIPAL 8 1.3.2 PLANIFICADOR DE RUTAS INTERMODAL 13 1.3.3 EXTENSIÓN EDUROAM 13 1.3.4 INFRAESTRUCTURA DEL CPD MUNICIPAL 14 2 REQUISITOS TÉCNICOS 20

2.1 REQUISITOS GENERALES 21 2.1.1 COMPATIBILIDAD 22 2.1.2 HARDWARE 22 2.1.3 SERVICIO DE IDENTIFICACIÓN DE EQUIPOS 23 2.1.4 SUMINISTRO E INSTALACIÓN DE CARTELERÍA FEDER 26 2.1.5 INVENTARIADO DE LOS ELEMENTOS SUMINISTRADOS E INSTALADOS 26 2.1.6 LICENCIAS Y SOFTWARE DE FUENTES ABIERTAS 28 2.1.7 SOFTWARE 29 2.1.8 ENTREGAS Y ACEPTACIÓN 31 2.1.9 GESTIÓN DEL PROYECTO 31 2.1.10 OBLIGACIÓN DE INFORMACIÓN Y DOCUMENTACIÓN 32 2.1.11 DOCUMENTACIÓN Y CIERRE DEL PROYECTO 33 2.2 COMPONENTE 1: PLATAFORMA DE CIUDAD INTELIGENTE 34 2.2.2 CUADRO DE MANDO 35 2.2.3 CANAL SMART 58 2.2.4 PULSO DE LA CIUDAD 60 2.2.5 ANALÍTICA PREDICTIVA 61 2.2.6 CAPACITACIÓN 62 2.3 COMPONENTE 2: APLICACIÓN MÓVIL MUNICIPAL 64 2.3.1 DESCRIPCIÓN 64 2.3.2 TAREAS A REALIZAR Y ENTREGABLES 69 2.3.3 REQUISITOS GENERALES DE LA APLICACIÓN MÓVIL 71 2.4 COMPONENTE 3: PLANIFICADOR DE RUTAS INTERMODAL 74 2.4.1 DESCRIPCIÓN 74 2.4.2 TAREAS A REALIZAR Y ENTREGABLES 76 2.5 COMPONENTE 4: EXTENSIÓN EDUROAM 78 2.6 COMPONENTE 5: SUMINISTRO DE SERVIDORES 87 2.7 COMPONENTE 6: SUMINISTRO DE SISTEMAS DE ALMACENAMIENTO 90 2.8 COMPONENTE 7: SUMINISTRO DEL MÓDULO LAN 96 2.9 COMPONENTE 8: SUMINISTRO DE LICENCIAS DE SISTEMA OPERATIVO 97 2.10 COMPONENTE 9: INSTALACIÓN, PUESTA EN MARCHA Y CAPACITACIÓN DE LOS

COMPONENTES 5, 6, 7 Y 8 99 2.11 COMPONENTE 10: SUMINISTRO E INSTALACIÓN DE UN ESCÁNER PARA EL

ARCHIVO MUNICIPAL 102 3 REQUISITOS DE LA IMPLANTACIÓN 107







Pág. 3 de 134



Exp.054/16-AE

3.1 REQUISITOS GENERALES DE SUMINISTRO 107 3.1.2 HARDWARE 108 3.1.3 PRODUCTOS SOFTWARE 108 3.2 REQUISITOS GENERALES DE INSTALACIÓN 109 3.2.2 HARDWARE 110 3.2.3 PRODUCTOS SOFTWARE 111 3.3 REQUISITOS GENERALES APLICABLES A LAS PRUEBAS 112 3.4 PLAZOS 113 3.5 REQUISITOS DE GARANTÍA 115 3.5.1 DECLARACIÓN DE GARANTÍA 115 3.5.2 GARANTÍA SOBRE EL SOFTWARE OFERTADO 115 3.5.3 GARANTÍA SOBRE LOS TRABAJOS DE DESARROLLO 116 3.5.4 GARANTÍA SOBRE EL HARDWARE OFERTADO 116 3.5.5 COBERTURA DE LA GARANTÍA 117 3.5.6 TIEMPOS MÁXIMOS DE RESOLUCIÓN DE INCIDENCIAS 120 3.5.7 PARÁMETROS DE MEDIDA PARA EL CÓMPUTO DE PENALIZACIONES 121 4 CONTROL ECONÓMICO Y DE FACTURACIÓN 123

4.1 CONTROL DE FACTURACIÓN 123 4.2 HITOS DE FACTURACIÓN 123 5 FORMATO Y CONTENIDO DE LA PROPUESTA 126

5.1 PROPUESTA RELATIVA A LOS CRITERIOS CUYA VALORACIÓN DEPENDE DE UN JUICIO DE VALOR

(SOBRE 3 “CRITERIOS DE JUICIO DE VALOR”) 126 5.2 PROPUESTA RELATIVA A LOS CRITERIOS CUANTIFICABLES MEDIANTE LA MERA APLICACIÓN DE

FÓRMULAS (SOBRE 4“CRITERIOS CUANTIFICABLES POR FÓRMULA”) 130 5.2.1 PROPOSICIÓN ECONÓMICA 130 5.2.2 MODELO DE PROPOSICIÓN ECONÓMICA 133

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. 4 de 134



Exp.054/16-AE

1 INTRODUCCIÓN El Ayuntamiento de Toledo es la institución local 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.

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.







Pág. 5 de 134



Exp.054/16-AE

ñ) 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á 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 al Ministerio de

Industria, Energía y Turismo, a través de la Secretaría de Estado de

Telecomunicaciones y para la Sociedad de la Información, 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

el Programa Operativo FEDER 2014- 2020 que le corresponde, 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 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 el Ayuntamiento de Toledo ha sido

elegido para el desarrollo de la iniciativa Toledo Ciudad Inteligente.







Pág. 6 de 134



Exp.054/16-AE

Dentro de este contexto, el 13 de abril de 2015, se firma un Convenio de

Colaboración entre el Ayuntamiento de Toledo (en adelante “el ayuntamiento”) y

Red.es con el fin de desarrollar actuaciones encuadradas dentro de dicha iniciativa.

La iniciativa Toledo Ciudad Inteligente se plantea como una herramienta para

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

ciudadanos del ayuntamiento. 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:

() 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:

Plataforma de ciudad inteligente







Pág. 7 de 134



Exp.054/16-AE

Aplicación móvil municipal.

Planificador de rutas intermodal.

Extensión de Eduroam.

Suministro e instalación de equipamiento hardware

1.3 Situación y Entorno Tecnológico Actual

A continuación, se describe la situación actual y elementos del entorno

tecnológico existente en el Ayuntamiento de Toledo por cada componente o

subconjunto de componentes a ejecutar dentro del presente proyecto

(componentes descritos en el apartado 2). Para ello, se indica cuál es su situación

de partida y los elementos de su entorno tecnológico con algún tipo de relevancia

o impacto sobre los trabajos a desarrollar en cada uno de ellos.

La situación de partida, aplicable a los diferentes componentes, no resulta la

ideal al carecer de:

Un núcleo de equipamiento tecnológico insuficiente para la instalación

de nuevas aplicaciones.

Funcionalidad de análisis de datos centralizada.

Capacidad de integración de datos y sistemas.

Así y todo, la ciudad de Toledo dispone de múltiples aplicaciones y servicios

para la operativa diaria con una serie de características e información que le

confiere un punto de partida para alcanzar el concepto de Smart City pretendido.

Las actuales aplicaciones y servicios del ayuntamiento se dividen en dos

grandes grupos en base al modo de explotación:

Aplicaciones instaladas en el propio ayuntamiento: entre las que, a

modo de ejemplo, se encuentran las siguientes:







Pág. 8 de 134



Exp.054/16-AE

Aplicaciones de un proveedor de servicios en modo hosting: entre las

que, a modo de ejemplo, se encuentran las siguientes:

Teniendo presente todo lo anterior, se describe a continuación la situación y

entorno tecnológico de partida con mayor relevancia para los trabajos previstos en

cada componente o subgrupo de componentes del presente proyecto:

1.3.1 PLATAFORMA DE CIUDAD INTELIGENTE Y APLICACIÓN MÓVIL MUNICIPAL

La situación actual y entorno tecnológico de los distintos elementos

relacionados con la Plataforma de Ciudad Inteligente o con la Aplicación Móvil

Municipal a implantar, ambas mediante los trabajos del presente proyecto, se

describe a continuación.







Pág. 9 de 134



Exp.054/16-AE

El adjudicatario deberá implantar la Plataforma de Ciudad Inteligente así como

la parte servidor de la Aplicación Móvil Municipal solicitados respectivamente en

los apartados 2.2 y 2.3 sobre la infraestructura del CPD del Ayuntamiento descrito

en el apartado 1.3.4 del presente documento y sobre aquellos nuevos elementos

que, para ampliación de dicho CPD, se hubieran instalado mediante la ejecución del

presente proyecto.

El Ayuntamiento no dispone actualmente de ninguna herramienta para la

realización de cuadros de mando ni para la extracción, transformación y carga de

datos desde distintos orígenes a un repositorio centralizado.

En relación con las fuentes de datos origen de las que, con mayor probabilidad,

se deberán extraer los datos para nutrir al Cuadro de Mando, se identifican, sin

carácter exhaustivo- las siguientes aplicaciones y bases de datos municipales:

APLICACIÓN DESCRIPCIÓN TIPO/TECNOLOGÍA NOMBRE DE LAS BASES

DE DATOS

GESPOL Policía Local c/s VBASIC, SQLSERVER

2008

GESPOL

GPA Gestión Patrimonial c/s VBASIC, SQLSERVER

2005

BIB, FORMAGPA, GPA,

GPAMU, GPATU

GTT Gestión Tributaria y

Recaudación

web, ASP, ORACLE v.8 GTT

KNOSYS Gestión del archivo

municipal

c/s, java, base de datos

propia

KNOSYS

PADRÓN Padrón de

Habitantes

c/s, Vbasic, SQLSERVER

2005

PADRO002

REGISTRO Registro de

Entrada/Salida

web, ASP, SQLSERVER

2005

2011_2013_REGISTRO,

ABSIS,

ABSISREGHISTORICO,

GISAL,

GISALREGHISTORICO







Pág. 10 de 134



Exp.054/16-AE

SICALWIN Contabilidad e

Intervención.

Contabilidad

Patronato Deportivo

y Música

c/s VBASIC, JAVA,

SQLSERVER 2005

ADMSICAL, AYTO1997 a

AYTO2015, PMMU2002

a PMMU2015,

PMMU2002 a

PMMU2015, AYTOS_CES

SIGEP Recursos humanos y

nóminas

c/s VBASIC, SQLSERVER

2005

SGAM_TOLEDO

SICAT Fiscalización Web php y MYSQL sicat, sicat.deporte,

sicat.musica,

sicat.teatro,

sicat.turismo

Cementerios Cementerios FoxPro CEMENTERIO

Las páginas web municipales más importantes están actualmente

desarrolladas con:

SITIO TECNOLOGIA EN SERVIDOR

OBSERVACIONE

S

www.toledo.es

PHP bajo Symfony 2.6 - MYSQL -

Apache Portal, índice

www.ayto-toledo.org

ASP clásico - ACCESS - IIS (Internet

Information Server)

Portal del

Ayuntamiento

ocv.toledo.es SAP

Oficina

Ciudadana

abierto.toledo.es


Apache

Portal de

transparencia

tst.toledo.es


Apache

Portal de

tributos

www.ayto-toledo.info Wordpress Sala de prensa

www.diego-ortiz.com Joomla

Escuela de

Música

www.teatroderojas.com no es un cms abierto Teatro

www.emvtoledo.es PHP - MYSQL - Apache

Empresa

vivienda

www.patronatodeportiv

otoledo.com no es un cms abierto Deportes

http://www.toledo-

turismo.com MySQL 5.5.43







Pág. 11 de 134



Exp.054/16-AE

Repositorios de contenidos o datos:

En la actualidad el Ayuntamiento tiene en marcha un proyecto con objeto de

implantar un gestor de contenidos municipal, dicho gestor estará basado en el

producto WordPress en su última versión disponible (Versión 4.3.1). El

adjudicatario podrá hacer uso de dicho sistema para la gestión de aquellos

contenidos que la Plataforma de Ciudad Inteligente, solicitada y descrita en el

apartado 2.2 1.3.1del presento documento, precise para su puesta en marcha con

las funcionalidades especificadas.

El Ayuntamiento dispone de una base de datos en MySQL vers. 5.6.26 que

podría ser utilizada para implantar aquellos repositorios de datos que el

adjudicatario precise para la puesta en marcha de la Plataforma de Ciudad

Inteligente y/o Aplicación Móvil Municipal, descritas en el apartado 2.2 y 2.3, con

las funcionalidades allí especificadas.

No obstante, el licitador incluirá en su oferta todos los elementos software

(licencias incluidas) que precise para implantar la totalidad de repositorios que su

solución necesitase, teniendo presente que todos ellos deberán ser compatibles

con el resto de elementos de la infraestructura del ayuntamiento y que estarán

sujetos a las mismas condiciones de suministro, instalación y garantía

especificadas para los restantes elementos de la solución. Cualquier coste

derivado de los mismos se considerará incluido en la oferta presentada, no

pudiendo generar costes adicionales posteriores para Red.es o el Ayuntamiento.

Gestión de incidencias:

El Ayuntamiento está implantando una aplicación de gestión de incidencias

llamada OsTicket. Es un sistema automatizado de soporte al cliente, la aplicación

es de código abierto, gratuita y desarrollada en lenguaje de programación PHP. Los

datos están almacenados en una base de datos MySQL. Las versiones utilizadas

son:

OSTICKET 1.9.8.1

PHP 5.6.8

MySQL MySQL Community Server 5.7.9

Redes sociales:







Pág. 12 de 134



Exp.054/16-AE

En lo que respecta a presencia en redes sociales, de especial relevancia para

las actuaciones solicitadas en el apartado 2.2.4, actualmente el ayuntamiento

emplea varios perfiles en las principales redes, tanto de carácter general como

específicos de determinadas Concejalías, si bien no se efectúa un seguimiento

organizado de ellos. Los principales son:

Facebook:

www.facebook.com/ayuntamientodetoledo

En esta cuenta se enlazan principalmente las noticias que se generan desde el

Gabinete de Prensa y que se cuelgan en la wwww.ayto-toledo.info

Twitter:

@toledoayto

Cuenta principal. Se publican las noticias que genera el Ayuntamiento.

Gestionada por el Gabinete de Prensa.

@toledoturismo

Información y recursos turísticos. Gestionada por el Patronato de Turismo.

@toledojoven

Información de la Concejalía de Juventud, que gestiona la cuenta (actualmente

con poca actividad).

@toledocultura

Cultural (actualmente inactiva).

@toledodeporte

Información del Patronato de Deportes (con poca actividad).

@toledomovilidad

Información del tráfico, incidencias etc. Gestionada desde la Sala de Control

Turriano.

@teatroderojas







Pág. 13 de 134



Exp.054/16-AE

Programación e información del Teatro. La gestiona personal del centro.

@emvtoledo

Cuenta de la Empresa Municipal de la Vivienda.

Instagram: el ayuntamiento dispone de dos cuentas:

una genérica del Ayuntamiento (poco uso)

otra del Patronato de Turismo.

Además, el Ayuntamiento dispone de perfiles en Flickr (con poca actividad),

Google +, YouTube y Pinterest (inactivas).

Adicionalmente, la alcaldesa y los concejales gestionan sus propios perfiles

personales o públicos.

1.3.2 PLANIFICADOR DE RUTAS INTERMODAL

El adjudicatario deberá implantar el Planificador de rutas intermodal solicitado

en el presente proyecto dentro del CPD del Ayuntamiento descrito en el apartado

1.3.4 del presente documento.

1.3.3 EXTENSIÓN EDUROAM

Eduroam (Education Roaming) es el servicio mundial de movilidad segura

desarrollado para la comunidad académica y de investigación. El servicio permite

que estudiantes, investigadores y personal de las instituciones participantes

tengan conectividad Internet a través de su propio campus y cuando visitan otras

instituciones participantes.

Eduroam ES es una iniciativa englobada en el proyecto RedIRIS que se encarga

de coordinar a nivel nacional los esfuerzos de instituciones académicas con el fin

de conseguir un espacio único de movilidad.

Eduroam en la Universidad de Castilla-La Mancha (UCLM), es un servicio que

se presta gracias a la infraestructura de comunicaciones basada en una solución

de controladores de ARUBA NETWORKS.

Actualmente la infraestructura de red inalámbrica de la UCLM está compuesta

por dos controladoras Aruba Networks 7220 ejecutando Aruba OS versión







Pág. 14 de 134



Exp.054/16-AE

6.4.3.9_55230 en modo activo/pasivo garantizando alta disponibilidad del

servicio.

El sistema dispone actualmente de capacidad suficiente de licenciamiento para

el alta de nuevos puntos de acceso, a disposición de los solicitados para la

ampliación de Eduroam, incluyendo capacidades de cortafuego de nueva

generación.

El sistema sirve en la actualidad a 509 puntos de acceso tipo 105, 1 tipo 135,

42 tipo 205, 128 tipo 225, 2 tipo RAP-155, con un total de 682 puntos de acceso

distribuidos por todas las sedes de la UCLM en Albacete, Almadén, Ciudad Real,

Cuenca, Talavera de la Reina y Toledo.

Los usuarios deberán disponer de capacidad de conexión a redes inalámbricas

basadas en estándares 802.11 a/g/n/ac y software que permita la validación en la

red a través de WPA2-Enterprise, cifrado de datos AES o TKIP (en extinción), tipo

de EAP protegido (PEAP) y método de autenticación EAP-MSCHAP v2.

1.3.4 INFRAESTRUCTURA DEL CPD MUNICIPAL

El Centro de Proceso de Datos (o CPD) del Ayuntamiento está ubicado en la

planta baja del mismo, Plaza del Consistorio, 1, 45071, Toledo. Con una superficie

de 30 metros cuadrados dispone de un sistema de refrigeración mural tipo Split y

está conectado a un sistema de alimentación ininterrumpida.

Contiene 5 bastidores tipo rack de dos metros de altura y 43 Us cada uno. La

anchura útil de los bastidores es de 18,5 pulgadas (47 cm). De ellos, hay

actualmente 2 disponibles, uno con 27 Us libres y otro con 16 Us libres.

Dicho CPD consta de los siguientes elementos hardware y software relevantes:

Un Directorio Activo soportado en dos (2) equipos HP DL380p Gen8

con las siguientes características cada uno de ellos:

o Sistema Microsoft Windows Server 2012 Standard R2

o 2 procesadores Intel Xeon E5-2667 v2 y 8 Core

o 64 Gb 2Rx4 PC3L-12800R de RAM

o 2 discos de 146GB SAS







Pág. 15 de 134



Exp.054/16-AE

o 8 port Ethernet 1Gb

o 2 Fuentes de Alimentación HP 460 w

o 1 Unidad de Backup HP DAT 160 SAS Internal Tape Drive

o Ocupando 2U de Rack cada uno

Un Servidor de Virtualización HP DL380p Gen8 con Microsoft Windows

Data Center hospedando servidores virtualizados ( Servidores de

impresión, Escritorio Remoto y Aplicaciones) con HyperV, con las

siguientes características:

o 2 procesadores Intel Xeon E5-2667 v2 y 8 Core

o 64 Gb 2Rx4 PC3L-12800R de RAM

o 2 discos de 146GB SAS

o 6 discos de 500Gb SATA

o 8 port Ethernet 1Gb

o 2 Fuentes de Alimentación HP 460 w

o 1 Unidad de Backup HP DAT 160 SAS Internal Tape Drive

o Ocupando 2U de Rack

Un Sistema de Almacenamiento HP StoreEasy 1640 con las siguientes

características:

o Sistema Microsoft Windows Storage Server 2012

o Procesador Intel Xeon E5-2407 v2

o 16 Gb de RAM ( 4x4GB Single Rank x4 PC3L-12800R DDR3-

1600)

o 32TB SAS Storage (8 x 4TB 6G 7.2K rpm LFF SAS HDDs) con 4

slots LFF libres para expandir con más discos

o 1 Unidad de Backup HP DAT 160 SAS Internal Tape Drive con

software HP Data Protector







Pág. 16 de 134



Exp.054/16-AE

o 4 ports Gigabit Ethernet

o 2 Fuentes de Alimentación 750w

o Ocupando 2U de Rack

Módulo Central de Comunicaciones LAN y VoIP CISCO CATALYST

4510R+E

Un Librería de Cintas de Backup HP Autoloader 1/8 G2, para 8 cintas

LTO de 1,8Tb

Una granja de 10 servidores físicos de Aplicaciones, Ficheros y Bases de

Datos modelos HP DL350, HP DL370 y HP DL380

El modelo, rol y sistema operativo de los servidores y almacenamiento

actuales es:

Modelo Rol SISTEMA OPERATIVO

HP Proliant DL380p

G8

Server Controlador de Dominio en

Hyper-V y Replicación Segundo

Controlador de Dominio

Windows Server 2012 STD

R2

HP Proliant DL380p

G8

Segundo Controlador de Dominio

en Hyper-V y Replicación


Windows Server 2012 STD

R2

HP Proliant DL380p

G8

Servidor Data Center con Hyper-V:

- Servidor WSUS - Servidor

Terminal Server -Servidor

Impresión - Servidor Gestión

Incidencias - Servidor

Aplicaciones Cementerio, AutoCad

y WKNOSYS

Windows Server 2012

Datacenter R2

HP Storage 1640 NAS Almacenamiento en Red Windows Server Storage

HP Proliant DL380R

G4

Servidor miembro - Intranet, WIS,

Reloj, IIS para Registro, Padron e

Intranet, Repositorio Instaladores

de Software

Windows Server 2003

Agente Acronis y Sonicwall

HP Proliant DL380R

G5 Servidor miembro

Windows Server 2003 R2

Std







Pág. 17 de 134



Exp.054/16-AE

- SQL 2005 de Base de Datos de

Registro , Padron, SicalWin

(contabilidad) BD Nóminas SIGEP,

GPA ( Gestión Patrimonial) y BIB

de doc escaneados (Gestión

Documental)


- Repositorio de Copias en Lib

Cintas HP y Symantec Backup

Server 12.5

- Periférico Autoloader

Librería Cintas

- Repositorio de Imágenes de

Servidores por Acronis

complementado con disc USB

- Programas SicalWin y GPA

HP Proliant DL580R

G5

Servidor miembro SAP Producción

Gestor de Expedientes, con

Acceso desde WAN


x64 Enterprise


HP Proliant DL580R

G5

Servidor miembro SAP Desarrollo

– Portal Ciudadano, WebServices

Registro y Padron, con Acceso

desde WAN


x64 Enterprise


HP Proliant ML370R

G3

Servidor miembro – En desarrollo :

Plataforma acceso externo Web de

Pagos del ciudadano

Windows Server 2003


HP Proliant ML350T

G2

Terminal Server Y Serv Windows Server 2000

– BD Cementerios, Nóminas

Turismo SIN Acronis

– Con acceso desde WAN SIN Sonicwall

Equipo PC HP dc5700

Terminal Server (AUXILIAR) Y

Serv – Extranet, ACAD 2006-

2008 y FTP, Servicios WEB port

8080 y 555

Windows Server 2003


Equipo PC HP Servidor miembro Windows Server 2003

530 CMT

- Consola Antivirus Corporativo

PANDA y BD Access Almacén

Consumibles, con acceso desde

WAN


HP Proliant DL380R

G3 Servidor miembro

Windows Server 2008 Std

32bits







Pág. 18 de 134



Exp.054/16-AE

-Acad 2006- 2008, ACAD 2011/13

y CYPE Ingenieros Agente Acronis y Sonicwall

HP Proliant ML370T

G5

Servidor miembro EXCHANGE

(Agendas) – WSUS



Appliance Reservorio de Copias de Seguridad

de los Servidores Linux

HP Proliant ML350T

G4p

Controlador de Dominio Policía –

Carpetas INTERCAMBIO y

Buzones, Copias Seguridad

Windows Server 2003

HP Proliant ML350 G6

Servidor Miembro Policía –

Aplicación GESPOL ( En proceso) y

SQL 2008. Carpetas ATESTADOS


Std

HP Proliant ML350T

G4p


SECUNDARIO

Windows Server 2003


El esquema gráfico de la arquitectura actual que presentan los principales

elementos señalados anteriormente es:







Pág. 19 de 134



Exp.054/16-AE

A nivel orientativo, el esquema gráfico que a nivel de arquitectura se

pretendería obtener tras la ejecución de los trabajos requeridos para ampliación

del CPD municipal sería:







Pág. 20 de 134



Exp.054/16-AE

2 REQUISITOS TÉCNICOS Los requisitos mínimos, detallados en este apartado, no pretenden ser una

relación exhaustiva de las características técnicas de los equipos o una descripción

exhaustiva de los trabajos demandados. Recoge lo más relevante de los mismos.

Se especifican los requisitos mínimos que deberán cumplir los equipos

ofertados, si bien los mismos podrán ser mejorados por los licitadores. Las

propuestas que ofrezcan características inferiores a las especificaciones técnicas

mínimas requeridas no serán tomadas en consideración en el presente

procedimiento.

Al presentar la oferta, el licitador deberá ajustarse a la terminología utilizada

en este apartado.

Para la adecuada ejecución del proyecto, el adjudicatario deberá mantener

cuantas reuniones sean precisas para definir el esquema operativo del proyecto,

realizando una puesta en común con Red.es y el Ayuntamiento para el

establecimiento de los hitos de actuación necesarios para la correcta ejecución del

mismo.

El licitador deberá garantizar la total compatibilidad e integración de la

totalidad de los elementos ofertados con cualquiera de los existentes, señalados

en el apartado 1.3 Situación y Entorno Tecnológico Actual del presente documento,

así como con el resto de nuevos elementos ofertados con los que precise

interactuar para ofrecer las funcionalidades requeridas.

Del mismo modo, la solución deberá integrarse plenamente con el entorno

tecnológico existente sin interferir en las funcionalidades que ya esté prestando el

mismo.

Toda integración, cambio, sustitución o adquisición que resulten necesarios,

derivados de la no compatibilidad de cualquier elemento propuesto con los

existentes, será responsabilidad del adjudicatario, quien deberá realizar todas las

tareas oportunas para conseguir el funcionamiento total del entorno final

requerido, sin que esto suponga ningún coste añadido para la entidad Red.es ni

para el Ayuntamiento, sin pérdida de la continuidad de servicios que se vengan

prestando, y sin perjuicio de los plazos establecidos en el apartado 3.4 Plazos del

presente documento.







Pág. 21 de 134



Exp.054/16-AE

El adjudicatario deberá garantizar la prestación y cumplimiento del servicio

siendo responsable del cumplimiento de todas y cada una de las funciones

encomendadas.

2.1 Requisitos Generales

Todas las actuaciones desarrolladas en el marco del presente expediente de

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







Pág. 22 de 134



Exp.054/16-AE

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 el

Ayuntamiento.

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 el Ayuntamiento serán

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 3.4 de plazos 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.

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 y materiales que sean necesarios para la

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







Pág. 23 de 134



Exp.054/16-AE

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 apartado 1.3 Situación y Entorno Tecnológico

Actual, sin requerir para ello ningún equipamiento, software,

licencia o prestación que no sea aportada por el adjudicatario;

en su defecto, el 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, sin que esto

suponga un aumento de la necesidad de recursos (espacio,

suministro eléctrico, etc.).

2.1.2.7 (√) Si la instalación del hardware suministrado forma parte de

las tareas a ejecutar, una vez concluida la misma, el

adjudicatario entregará un conjunto de documentación en

español que incluirá, al menos, manuales de administración,

operación y mantenimiento de los componentes implantados.

2.1.3 SERVICIO DE IDENTIFICACIÓN DE EQUIPOS

Todos los activos suministrados, instalados y/o mantenidos por el

adjudicatario, estarán obligatoriamente identificados a través de los dos siguientes

medios:

Etiquetado:







Pág. 24 de 134



Exp.054/16-AE

2.1.3.1 (√) El número de serie del equipamiento suministrado deberá

ser visible en alguna superficie del mismo.

2.1.3.2 (√) 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 adjudicatario a

través de un sistema de etiquetado que cumpla las siguientes

características:

Contenido:

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

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

y/o bidi.

Opcionalmente otro contenido (logos, etc.).

Material:

Poliéster metalizado laminado.

Resistente al desgaste.

Resistente al agua.

Resistente a los disolventes.

Resistente a la luz.

Resistencia a altas temperaturas.

Resistente a la abrasión.

Alta resistencia a rotura.

Adhesivo:







Pág. 25 de 134



Exp.054/16-AE

Adhesivo antivandalismo.

Adhesivo permanente.

Adhesivo universal adaptable a distintas superficies.

Resistente a temperaturas de -40 ºC a +145 ºC.

Impresión:

Admite Código de barras y/o bidi.

Admite logotipos

Tinta indeleble de larga duración.

2.1.3.3 (√) 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.

Grabado:

2.1.3.4 (√) El equipamiento objeto del contrato deberá estar

identificado mediante grabado en superficies tal y como se

indica en el apartado 3.8.1 del Pliego de Condiciones

Particulares.

2.1.3.5 (√) Se grabará la siguiente información:

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

Códigos de equipo: codificación proporcionada por Red.es que

contendrá letras y números.







Pág. 26 de 134



Exp.054/16-AE

2.1.3.6 (√) 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.3.7 (√) 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.4 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.4.1 (√) El adjudicatario diseñará, producirá, suministrará e

instalará el cartel 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

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.

2.1.5 INVENTARIADO DE LOS ELEMENTOS SUMINISTRADOS E INSTALADOS

2.1.5.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







Pág. 27 de 134



Exp.054/16-AE

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.

2.1.5.2 (√) 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.

2.1.5.3 (√) La información de activos se considera parte de la

entrega de los mismos, y es necesaria para su aceptación. El

adjudicatario se comprometerá a registrar en dicha

herramienta los activos suministrados e instalados al mismo

ritmo que el especificado en el apartado 3.4 Plazos del

presente Pliego, estableciéndose un compromiso de una

semana para el registro de la información.

2.1.5.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.

2.1.5.5 (√) Además de la información de suministro e instalación de

los activos se cargará en la herramienta de Gestión de

Activos de Red.es la información del e-Albarán vinculada a

esos activos. Esta información es independiente de la gestión

de la facturación a través de la herramienta de facturación e-

albarán. Es condición indispensable el registro de esta

información en la herramienta de Gestión de Activos de

Red.es para poder validar la gestión de la facturación en la

herramienta de facturación e-albarán.

2.1.5.6 (√) No se podrá integrar el registro de información de

suministro e instalación, siendo cada fase independiente y con







Pág. 28 de 134



Exp.054/16-AE

su propio flujo de registro en la herramienta de Gestión de

Activos de Red.es.

2.1.5.7 (√) 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.

2.1.5.8 (√) 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.

2.1.5.9 (√) Tasa de Fallos. En caso de auditoría del equipamiento

desplegado, el número de errores entre los números de serie

de los equipos realmente suministrados y los registrados en la

base de datos de activos de Red.es no podrá superar el 3%.

Un nivel de error, por encima de este límite, dará lugar a la

aplicación de penalizaciones establecidas en el apartado 6 del

Pliego de Condiciones Particulares.

2.1.6 LICENCIAS Y SOFTWARE DE FUENTES ABIERTAS

2.1.6.1 (√) En el caso que alguna de las funcionalidades y

prestaciones de los elementos suministrados para el

desarrollo de la Iniciativa Toledo Ciudad Inteligente

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.5

Requisitos de Garantía.

2.1.6.2 (√) En el caso de que el licitador oferte soluciones ya

existentes basadas en software de fuentes abiertas para el

desarrollo de alguno de los componentes, la solución ofertada

debe basarse en un software estable, robusto, ampliamente







Pág. 29 de 134



Exp.054/16-AE

utilizado y con un gran respaldo por una comunidad de

usuarios y desarrolladores que garantice su evolución y

viabilidad futuras.

2.1.6.3 (√) Se deberá garantizar su funcionamiento sobre equipos

cliente con los sistemas operativos implantados en el

Ayuntamiento. Los componentes y desarrollos destinados a

funcionar sobre explorador soportarán los navegadores más

extendidos en el mercado 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.

2.1.6.4 (√) Los servicios que incorpore el software se deben ofrecer

bajo tecnología de servidor de aplicaciones libre (ej.: Apache,

Tomcat, Jboss…), si bien los servicios se deben poder ejecutar

bajo cualquier otro servidor de aplicaciones.

2.1.6.5 (√) Deberá haber compatibilidad entre todo el software que

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

los sistemas operativos implantados en el Ayuntamiento, con

las plataformas de bases de datos y servidor de aplicaciones,

así como con el resto del aplicaciones y servicios que integran

el resto de componentes descritos en el presente Pliego.

2.1.7 SOFTWARE

Cualquier pieza de software que se desarrolle en el marco del presente

expediente de licitación deberá cumplir los siguientes requerimientos.

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

recomendaciones internacionales y estándares de usabilidad

y accesibilidad. Se deberá alcanzar, al menos, un Nivel de

Conformidad "AA" (Doble A). En el caso de páginas web se

deberá cumplir así mismo la norma UNE-EN 301 549,

“Requisitos de accesibilidad de productos y servicios TIC

aplicables a la contratación pública en Europa”– “Accessibility







Pág. 30 de 134



Exp.054/16-AE

requirements suitable for public procurement of ICT products

and services in Europe” o equivalente

2.1.7.2 (√) Deberá, salvo justificación aceptada por Red.es, hacer uso

de lenguajes de desarrollo estándar de fácil mantenimiento,

ampliamente distribuido y multiplataforma.

2.1.7.3 (√) Deberá desarrollarse en fuentes abiertas permitiendo su

reutilización y distribución entre Administraciones.

2.1.7.4 (√) 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.).

2.1.7.5 (√) 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.7.6 (√) El adjudicatario tendrá un entorno de desarrollo propio, y

un entorno de integración, donde se realizaran todas las

pruebas por parte del usuario, previo a la instalación en el

entorno final de explotación.

2.1.7.7 (√) Las subidas a producción se realizarán en el horario que

Red.es estime que menos impacto causa al proyecto.







Pág. 31 de 134



Exp.054/16-AE

2.1.8 ENTREGAS Y ACEPTACIÓN

2.1.8.1 (√) Todos los suministros, instalaciones y pruebas requeridos

como parte de los trabajos solicitados quedarán sujetos a las

condiciones generales de suministro, de instalación y de

pruebas especificadas en los apartados 3.1, 3.2 y 3.3

2.1.8.2 (√) El plazo de implantación de los elementos objeto de la

licitación finaliza a la aceptación por parte de Red.es de la

entrega y puesta en marcha de cada uno de 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.8.3 (√) Para formalizar la entrega de los diferentes elementos y

prestaciones objeto del contrato el adjudicatario redactará

las 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.

2.1.8.4 (√) 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.

2.1.9 GESTIÓN DEL PROYECTO

2.1.9.1 (√) El adjudicatario designará un Jefe de Proyecto como

interlocutor principal con Red.es durante la ejecución del

proyecto.

2.1.9.2 (√) El Jefe de Proyecto realizará un seguimiento continuo de

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







Pág. 32 de 134



Exp.054/16-AE

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.

2.1.9.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.9.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.1 del Pliego de Condiciones Particulares.

2.1.10 OBLIGACIÓN DE INFORMACIÓN Y DOCUMENTACIÓN

2.1.10.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 éstos soliciten para disponer de un pleno

conocimiento de las circunstancias en que se desarrollan los

trabajos, así como de los eventuales problemas que puedan

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

utilizados para resolverlos. Asimismo, el adjudicatario se

compromete, en todo momento, a cumplir los procedimientos

establecidos por Red.es.







Pág. 33 de 134



Exp.054/16-AE

2.1.10.2 (√) En este sentido, el adjudicatario deberá informar a la

persona a cargo del proyecto, con la periodicidad necesaria,

sobre distintos aspectos del funcionamiento y la calidad de

las actuaciones realizadas.

2.1.10.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.10.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.10.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.10.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.11 DOCUMENTACIÓN Y CIERRE DEL PROYECTO

2.1.11.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







Pág. 34 de 134



Exp.054/16-AE

histórico de la planificación de las entregas, la fecha real de

entrega e instalación de los diferentes elementos.

2.1.11.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.11.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, etc.

2.2 COMPONENTE 1: PLATAFORMA DE CIUDAD INTELIGENTE

El Componente 1 contempla la ejecución de todos los trabajos necesarios

para la implantación de una Plataforma de Ciudad Inteligente en el Ayuntamiento

de Toledo con las funcionalidades mínimas especificadas en este apartado.







Pág. 35 de 134



Exp.054/16-AE

2.2.1.1 (√) La plataforma requerida deberá ofrecer un conjunto de

módulos comunes a los diferentes servicios o verticales de la

ciudad.

2.2.1.2 (√) Su arquitectura de información y comunicaciones deberá

ser robusta, abierta, transversal, escalable, segura y con

garantías de privacidad para hacer realidad el concepto Smart

City.

2.2.1.3 (√) Todos los suministros, instalaciones o pruebas precisos

para la correcta implantación de este componente deberán

realizarse cumpliendo, respectivamente, lo descrito en los

apartados 3.1, 3.2 y 3.3 del presente pliego.

2.2.1.4 (√) Las funcionalidades principales que deberá ofrecer la

plataforma, en el marco de este proyecto, son:

Cuadro de mando

Canal smart:

Pulso de la ciudad

Analítica predictiva

2.2.2 CUADRO DE MANDO

2.2.2.1 (√) El cuadro de mando debe constituir la herramienta que

permita representar los principales indicadores municipales.

Su objetivo será posibilitar que indicadores con relevancia

para el Ayuntamiento o sus áreas municipales puedan ser

analizados y representados desde distintas ópticas

(temporales, organizativas, temáticas,…). La herramienta

debe favorecer asimismo que determinados indicadores

puedan hacerse públicos en el portal del Ayuntamiento.

La parte más importante del cuadro de mando serán los informes e

indicadores relativos a los índices de transparencia obtenidos de las aplicaciones

informáticas más importantes del Ayuntamiento (ver apartado 1.3.1 )







Pág. 36 de 134



Exp.054/16-AE

2.2.2.2 (√) Los bloques de trabajo a abordar para su creación y

puesta en marcha serán, sin que estos respondan a una

secuencia temporal obligatoria, los siguientes:

a) Suministro e Instalación de las herramientas software

Comprende el suministro de una Herramienta de Cuadro de Mando y de una

Herramienta ETL (Extract, Transform and Load) conforme a los requisitos

detallados en los apartados f) y g) respectivamente, junto con las licencias que

sean necesarias para su uso conforme al apartado h), el servicio de garantía

asociado -descrito en el apartado 3.5 Requisitos de Garantía- y su correcta

instalación sobre los entornos del Ayuntamiento.

Este bloque conllevará las siguientes tareas:

La adquisición y suministro de una Herramienta de Cuadro de Mando,

cuyos requisitos se describen de forma más amplia en el apartado f)

Requisitos de la Herramienta de Cuadro de Mando, para consulta y

análisis de la información, elaboración de informes y cuadros de

mando así como las licencias necesarias para su utilización según las

condiciones reflejadas en el apartado h) Licencias y conforme a lo

indicado en el apartado 3.1 “Propiedad Intelectual” del Pliego de

Condiciones Particulares.

La adquisición y suministro de una Herramienta de ETL, cuyos

requisitos se describen de forma más amplia en el apartado g)

Requisitos de la Herramienta de ETL, para realizar procesos de

extracción, transformación y carga de la información desde las

distintas fuentes de datos (ver apartado Plataforma de Ciudad

Inteligente y Aplicación Móvil Municipal 1.3.1) así como las licencias

necesarias para su utilización según las condiciones reflejadas en el

apartado h) Licencias y conforme a lo indicado en el apartado 3.1

“Propiedad Intelectual” del Pliego de Condiciones Particulares.

Servicio de garantía durante CINCO (5) años de las herramientas

suministradas conforme a lo descrito en el apartado 3.5 Requisitos

de Garantía.







Pág. 37 de 134



Exp.054/16-AE

Instalación de las Herramientas suministradas sobre el entorno

tecnológico del Ayuntamiento con las adaptaciones y

configuraciones que se requieran para su adecuada puesta en

marcha.

o El adjudicatario deberá realizar todas las tareas inherentes a

esta actuación sobre los entornos de preproducción y

producción. No se contempla la adquisición de licencias

adicionales a las contempladas en el Pliego para el despliegue

sobre los distintos entornos (preproducción y producción),

debiendo incluirlas el licitador en su propuesta si las

considera necesarias. El entorno de desarrollo, será

propiedad y responsabilidad exclusiva del licitador, no

debiendo generar dicho entorno coste adicional alguno, por

ningún concepto (ni infraestructura ni licenciamiento de

ningún tipo), a los costes reflejados en la propuesta del

licitador.

o Previo a iniciar su instalación, el adjudicatario deberá elaborar

la propuesta de la arquitectura lógica y física que considera

más adecuada para el despliegue de dichas herramientas,

adaptada a los requisitos arquitecturales y de entorno

tecnológico del Ayuntamiento.

o La autenticación de los usuarios de la Herramienta de Cuadro

de Mando propuesta deberá efectuarse a través del protocolo

LDAP autenticándose mediante usuario y clave

implementados a través del Directorio Activo de Microsoft

Server 2012 R2. La identificación del usuario podrá realizarse

a través de usuario y contraseña o mediante certificado

electrónico.

o La arquitectura propuesta por el adjudicatario debe satisfacer

los requisitos de rendimiento, escalabilidad y disponibilidad al

menos activo-pasivo, y preferiblemente activo-activo en el

CPD del Ayuntamiento, de forma que el servicio se pueda

seguir prestando en caso de caídas temporales del mismo.







Pág. 38 de 134



Exp.054/16-AE

o Sobre la arquitectura aprobada, el adjudicatario –a elección

del Ayuntamiento- deberá efectuar la instalación, puesta en

marcha (parametrización y configuración) y prueba de las

herramientas o bien proporcionar el soporte presencial

necesario, con los medios más adecuados, al equipo que el

Ayuntamiento pudiera designar para efectuarlas. Las

instalaciones se realizarían en el CPD del Ayuntamiento.

b) Análisis Funcional.

Comprende la toma de requisitos y labores necesarias por parte del

adjudicatario para, sobre esa base, efectuar un análisis funcional completo y

exhaustivo que permita acometer con éxito el posterior modelado de la Base de

Datos Analítica y la implantación del Cuadro de Mando pretendido por el

Ayuntamiento, en el marco de este proyecto, sobre las herramientas

suministradas.

Se estima que el Cuadro de Mando a implantar en el presente proyecto

estará constituido por un máximo de 300 indicadores y 50 informes de los cuales,

se estima, que un 50% podría tener complejidad alta y el resto complejidad baja o

media.

El adjudicatario deberá llevar a cabo las acciones necesarias para:

Identificar y/o definir los indicadores de Transparencia del

ayuntamiento (de acuerdo a la Ley 19/2013, de 9 de diciembre, de

Transparencia, Acceso a la Información Pública y Buen Gobierno y al

propio Portal de Transparencia del ayuntamiento) así como los

informes predefinidos asociados.

Identificar y/o definir los indicadores relativos a los servicios de

Turismo y Movilidad así como los informes predefinidos asociados.

Adicionalmente, se identificarán y/o definirán:

o Una serie de indicadores que permitan efectuar determinados

análisis sobre los contratos de concesionarias del

ayuntamiento.

o Una serie de indicadores e informes que permitan efectuar

análisis acerca de la actividad ciudadana sobre el canal smart







Pág. 39 de 134



Exp.054/16-AE

(descrito en el apartado 2.2.3), muy especialmente acerca de

las incidencias reportadas a través del mismo como pudieran

ser: nº incidencias para servicio y estado de la incidencia o

tiempos de resolución de las mismas.

o Una serie de indicadores e informes que permitan efectuar

análisis presupuestarios, financieros y socioeconómicos de la

ciudad, que deberán ser extraídos de las aplicaciones y bases

de datos municipales señaladas en el apartado 1.3.1, en

concreto, de las siguientes: Registro, SICALWIN, GTT,

GESPOL, PADRÓN, GPA, SIGEP y Cementerios.

El Cuadro de Mando a diseñar deberá permitir dar acceso diferenciado a sus

contenidos en función del rol que ostente el usuario (usuario administrador,

usuario de reporte/análisis o usuario de consulta) y su posición en la estructura

organizativa municipal (departamento o área municipal).

El adjudicatario deberá proceder a un estudio en profundidad de la

documentación de partida proporcionada por el Ayuntamiento así como de la

información recogida en las distintas reuniones, con el fin de eliminar cualquier

duda o incertidumbre que pudiera posteriormente afectar a labores de recopilación

de los datos base que se precisen para la obtención de cualquier indicador, a

cuestiones de uso y/o explotación de los indicadores municipales sobre la propia

Base de Datos Analítica o sobre el Cuadro de Mando a implantar, etc.

Este bloque de trabajos conllevará, entre otras, las siguientes tareas:

Análisis y comprensión de la documentación de partida y del

contexto de las distintas áreas municipales involucradas en esta

parte del proyecto. Toma de requerimientos con las distintas áreas o

entes municipales involucrados.

Identificación y selección de indicadores e informes que constituirán

el Cuadro de Mando a diseñar e implantar.

Identificación y análisis de datos origen a partir de los cuales se

generan los indicadores y de los sistemas en que residen (si hubiera).

El adjudicatario deberá recabar de cada responsable funcional y

técnico designado por cada Área o Sistema de Información que deba







Pág. 40 de 134



Exp.054/16-AE

proveer datos, toda la información necesaria para comprender el

contexto tecnológico y funcional asociado a cada uno de los

indicadores. Por ejemplo, y sin que constituya un listado exhaustivo,

los datos concretos necesarios para la generación del indicador,

tecnología, estructura concreta en la que residen los mismos,

atributos relevantes, dimensiones por las que se precisa

analizar/explotar el mismo, tipología de cada dato que participa en

su generación, etc.. Asimismo, el adjudicatario deberá identificar,

analizar y resolver todas aquellas cuestiones y dudas relativas a

medidas y tipos de datos, dependencias, uniones, etc. que le

permitan acometer con éxito las posteriores tareas de data profiling.

Elaborar un Diseño Conceptual del Cuadro de Mando a implantar.

Entre otros, deberá concretar los tipos de visualización y

necesidades de interfaz de usuario (informes, análisis OLAP, cuadros

de mando dashboard) y los requisitos de seguridad aplicables en

cada caso, siempre alineados con los perfiles de usuario que la

Herramienta de Cuadro de Mando permita configurar. Será necesario

documentar cada uno de los Casos de Uso del Cuadro de Mando

propuesto.

Elaborar un documento funcional que recoja y consolide toda la

información relevante de cada sistema proveedor de información

recolectada durante ésta fase.

Efectuar una estimación de la volumetría de datos del almacén que

aloje el Catálogo de Indicadores Municipales considerando su

periodicidad mínima de actualización y la profundidad de datos

históricos que requiera cada uno de ellos.

c) Modelado de la Base de Datos Analítica.

Comprende el modelado de la Base de Datos Analítica, almacén del que se

nutrirá el posterior Cuadro de Mando a implantar. El modelado se efectuará a

partir de los resultados y conclusiones del Análisis Funcional llevado a cabo en el

bloque anterior.

La Base de Datos Analítica resultante deberá permitir el almacenamiento de

todos aquellos datos, atributos, etc. que sean necesarios para la generación de los







Pág. 41 de 134



Exp.054/16-AE

indicadores e informes identificados y aprobados en el bloque anterior así como

para su adecuada explotación posterior sobre la Herramienta de Cuadro de Mando.

El adjudicatario deberá proponer y generar un Modelo de Datos que permita

consolidar en un único repositorio destino, Datawarehouse, construido sobre el

gestor de base de datos relacional existente (ver apartado 1.3 “Situación y Entorno

Tecnológico Actual”) y/o sobre el ofertado, toda la información necesaria para la

gestión unificada e interrelacionada de los citados indicadores, proveniente de las

distintas fuentes origen de datos identificadas por cada uno de ellos.

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 datos, así como su

seguridad y escalabilidad para, posteriormente, poder explotarlos de una forma

ágil y fiable sobre la Herramienta de Cuadro de Mando suministrada para tareas de

análisis o generación de nuevos informes que se precisen así como desde el Cuadro

de Mando a implantar sobre dicha herramienta.

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 aprobado, a nivel de diseño conceptual, durante el bloque anterior de

trabajos (Análisis Funcional). 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.

A este respecto, durante la ejecución de este bloque de trabajos, el

adjudicatario deberá llevar a cabo un análisis con el fin de determinar qué modelo

teórico (estrella, copo de nieve,…) resulta más adecuado para el modelado del

Datawarehouse y efectuar una propuesta de diseño donde se justifique su elección

teniendo en cuenta la arquitectura preexistente y las necesidades de explotación

del sistema detectadas. Del mismo modo, deberá proponer y justificar el número

de capas o niveles que conformarán el Modelo de Datos resultante indicando el

propósito de cada una de las capas planteadas y los beneficios (escalabilidad,

tiempos de respuesta, rendimiento, flexibilidad, etc.) que proporciona. Dicha

propuesta deberá ser aprobada por Red.es.







Pág. 42 de 134



Exp.054/16-AE

Asimismo, el adjudicatario deberá identificar las dimensiones troncales,

atributos y metadatos que intervienen en la explotación de los distintos KPIs a

almacenar y proceder a analizarlos previamente con los responsables de los

sistemas proveedores de información, así como con los usuarios finales (analistas,

generadores de informes, etc.) para su correcta comprensión y establecimiento.

Este es un aspecto crucial del modelado dado que su reutilización en distintas

partes de la solución condiciona la forma en que han de proporcionarse y

transformar los datos, así como las necesidades de homogeneización de los

mismos para su adecuado almacenamiento sobre el modelo.

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 Cuadro de Mando de forma que los informes, gráficos, etc. se

elaboren y presenten a partir de conceptos de negocio.

El Modelo de Datos resultante debe permitir y favorecer las necesidades de

los usuarios finales respecto a las posibilidades de buceo sobre informes o

cualquier elemento del cuadro de Mando Diseñado que requiera esta funcionalidad,

“drilldown”, navegación jerárquica, etc.

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.

Durante la ejecución de este componente, el adjudicatario deberá ir

documentando todas las directrices que, de manera general, deban considerarse a

la hora de efectuar la extracción, carga y transformación de manera que los datos

que posteriormente se almacenen sobre la Base de Datos Analítica desde sus

distintas fuentes origen se adecúen a una serie de reglas comunes que favorezcan

su homogeneización y explotación cruzada. No obstante, dichas directrices no

deberán limitar, salvo justificación, el futuro objetivo de emplear mecanismos de

conexión y procedimientos de adquisición de datos que presenten el menor







Pág. 43 de 134



Exp.054/16-AE

impacto posible en el origen de información y que liberen las conexiones en el

menor plazo de tiempo.

d) Diseño Técnico e Implantación del Cuadro de Mando.

El adjudicatario, a partir de los trabajos resultantes de los dos bloques de

trabajo anteriores, deberá efectuar como parte de este bloque, el diseño técnico e

implantación del Cuadro de Mando sobre la Herramienta de Cuadro de Mando

instalada previamente.

El Cuadro de Mando deberá presentar todos los KPIs y funcionalidades

recogidas en el Análisis Funcional aprobado. Asimismo, deberá permitir el uso, con

los perfiles y condiciones de seguridad establecidas en los Casos de Uso de todos

aquellos elementos (informes, gráficos, dashboards, etc.) identificados en el diseño

conceptual del mismo con las posibilidades de buceo, filtrado, “drilldown”,

navegación jerárquica, etc. que sobre cada uno de dichos elementos se hubiera

acordado y establecido.

El adjudicatario deberá implantar la gestión de permisos de manera

integrada con el LDAP existente y mediante usuario/clave para usuarios externos.

Al igual que durante el Modelado de La Base de Datos Analítica, el

adjudicatario deberá tener en cuenta la importancia del “aspecto semántico” del

Cuadro de Mando Municipal a implantar debiendo abstraer a los usuarios de la

complejidad del sistema de manera que los informes, gráficos, etc. a elaborar y

presentar sean en base a conceptos de negocio, nunca en base a su traducción

técnica, con un lenguaje que resulte razonablemente próximo al usuario final.

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.

El Cuadro de Mando implantado debe contemplar mecanismos de

trazabilidad o auditoría que permitan el control o incluso monitorización de las

actividades de los usuarios.

Con carácter previo a la implantación del mismo, el adjudicatario deberá

establecer un Plan de Pruebas específico que permita verificar el cumplimiento de

los requerimientos expresados. Durante la implantación, el adjudicatario será

responsable de efectuar todas las pruebas necesarias para asegurar su correcto







Pág. 44 de 134



Exp.054/16-AE

funcionamiento, elaborando un informe de resultados de las mismas y procediendo

a la corrección de todos los aspectos en que se detecten desajustes respecto a los

requisitos acordados durante la fase de análisis para el Cuadro de Mando.

e) Extracción, carga y transformación de datos desde los orígenes

Comprende la totalidad de tareas inherentes a la extracción de los distintos

conjuntos de datos, residentes en diferentes sistemas y fuentes origen del

Ayuntamiento (u otros), así como las tareas y actuaciones necesarias para su

correcta transformación y carga hacia la Base de Datos Analítica implantada, con

la finalidad de nutrir a la misma de toda la información necesaria para la

generación y explotación, a través del Cuadro de Mando, de los indicadores e

informes acordados y definidos en la fase de Análisis Funcional. Es decir,

comprende la extracción, carga y transformación de los datos necesarios para

explotar sobre el Cuadro de Mando los indicadores de Transparencia, los

indicadores de Movilidad y Turismo, los relativos a contratos de concesionarios y

los relativos a al canal smart que se hubieran identificado y definido al término de

la fase de Análisis Funcional (apartado b) anterior).

Entre dichas tareas, sin considerarse un listado exhaustivo, el adjudicatario

deberá:

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 performance de

los mismos.

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.







Pág. 45 de 134



Exp.054/16-AE

Efectuar la extracción de los subconjuntos de datos de cada sistema

o fuente 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 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.

Determinar e implantar las diferentes transformaciones sobre los

datos extraídos que los conviertan 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., así como aquellas transformaciones o reglas de negocio

específicas identificadas durante la fase previa de análisis funcional.

Documentar todo el mapeado de flujos de datos desde el sistema

origen a la Base de Datos Analítica, así como todo el conjunto de

transformaciones efectuadas sobre los mismos.

Efectuar todas las pruebas necesarias (funcionales, integración,

rendimiento,…) para asegurar el correcto funcionamiento de los

procesos ETL desarrollados.

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.

f) Requisitos de la Herramienta de Cuadro de Mando

La Herramienta de Cuadro de Mando ha de permitir la explotación de los

indicadores más relevantes– cuyos datos provendrán de los diferentes sistemas a

integrar- para el análisis y seguimiento de diferentes servicios y sistemas

municipales.







Pág. 46 de 134



Exp.054/16-AE

A continuación, se indican las características que, como mínimo, debe tener

la Herramienta de Cuadro de Mando, teniendo presente además que ésta debe

poseer una alta escalabilidad que no sólo ofrezca soporte a los requisitos actuales,

detallados a continuación, sino que también pueda evolucionar de forma sencilla

para su ampliación futura.

Interfaz de la Herramienta de Cuadro de Mando

La interfaz debe ser intuitiva y de fácil uso en toda la funcionalidad que

ofrezca, con acciones del tipo "arrastrar y soltar", “cortar y pegar”, navegación

jerárquica organizada, de forma que los Usuarios Consumidores sean

autosuficientes en la utilización de la misma sin necesidad de conocimientos

informáticos y los Usuarios de Reporte y Usuarios de Administración sean

autosuficientes en la utilización de la misma sin necesidad de conocimientos

informáticos avanzados una vez, todos ellos, hubieran sido capacitados en su

manejo.

La Herramienta debe ser especialmente usable en funcionalidades relativas

a creación y consulta de informes y en aquellas relativas a incorporación de

fuentes para explotar la información por parte de la Herramienta de Cuadro de

Mando.

La interfaz deberá ser personalizable (elementos visibles, configuraciones

estéticas, idioma) para cada usuario que acceda a la misma, en función de por

ejemplo su perfil del usuario y el ámbito organizativo al que pertenezca. Las

preferencias que se definan para cada usuario deben mantenerse cada vez que

acceda el usuario a la Herramienta de Cuadro de Mando.

La interfaz debe proporcionar la funcionalidad de previsualización de los

informes, al menos del formato de los mismos, durante la definición y creación del

informe.

Toda la navegación de la Herramienta de Cuadro de Mando tiene que estar

en castellano, incluyendo todos los textos, mensajes de cualquier tipo o

información que proporcione la Herramienta al usuario.

La Herramienta de Cuadro de Mando tiene que ser accesible vía web, al

menos para los Usuarios Consumidores y los Usuarios de Reporte, 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







Pág. 47 de 134



Exp.054/16-AE

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. tiene que estar integrada en un único interfaz, aunque restringido a los

permisos y las preferencias que tenga el usuario que accede.

Fuentes de datos de la Herramienta de Cuadro de Mando

La Herramienta de Cuadro de Mando debe poder explotar la información

procedente de una gran variedad de fuentes de datos de naturaleza muy diversa

como bases de datos relaciones y no relacionales, ficheros de formatos variados

(Excel, Word, Access…), XML, cubos OLAP, servicios web, Google Analytics,

ficheros planos, etc. sobre un datawarehouse consolidado.

Además, la Herramienta de Cuadro de Mando debe permitir de forma

sencilla e intuitiva la explotación de información que provenga de una o varias

fuentes de datos que sea precisa, con carácter temporal, para incorporar nuevos

indicadores a informes ya definidos o en informes nuevos que se definan a tal

efecto. Un ejemplo de fuente temporal sería incorporar a la Herramienta de Cuadro

de Mando información procedente de una campaña de comunicación para realizar

el análisis y seguimiento de la misma.

Repositorio de objetos de la Herramienta de Cuadro de Mando

La Herramienta deberá utilizar 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. Además, la Herramienta deberá

proporcionar un conjunto de elementos para facilitar la generación informes y

plantillas de informes que, además, se pueda ir enriqueciendo con la incorporación

de los nuevos elementos definidos por parte de los usuarios durante su posterior

uso.

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.

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.







Pág. 48 de 134



Exp.054/16-AE

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).

Seguridad y Gestión de usuarios de la Herramienta de Cuadro de

Mando

La Herramienta de Cuadro de Mando debe poder integrarse con la seguridad

estándar de gestión de usuarios del LDAP.

La Herramienta de Cuadro de Mando deberá disponer de un módulo

centralizado y de fácil acceso (vía web) para poder realizar gestiones de

administración de los usuarios (asignación de permisos, etc.).

Según el perfil del usuario, éste accederá a la información que tenga

permiso a través de la consola de usuario. Sólo realizarán trabajos de análisis y/o

administración aquellos usuarios que tengan permiso para ello.

El acceso a la Herramienta de Cuadro de Mando debe realizarse de forma

segura, con los correspondientes mecanismos de autenticación basados en usuario

y contraseña y en certificado electrónico.

La gestión de roles/permisos se establecerá como mínimo respecto a tres

niveles de seguridad:

o Acceso a los datos: Limitar la información que puede visualizar cada

usuario. Por ejemplo: un usuario de determinada Área sólo tendrá

acceso a la información correspondiente a los datos de su Área y a

datos generales como medias globales, desviaciones u otros que se

obtengan del tratamiento conjunto de los datos correspondientes a

todas las Áreas.

o Acceso a los elementos de la Herramienta de Cuadro de Mando:

Limitar el acceso a los informes configurados en la Herramienta de

Cuadro de Mando. Por ejemplo un usuario de un Área sólo podrá

acceder a los informes definidos con los datos correspondientes a su

ámbito.







Pág. 49 de 134



Exp.054/16-AE

o Funcionalidad: Delimitar las acciones que puede realizar un

determinado usuario en función de su perfil. Por ejemplo: un Usuario

de Reporte podrá determinar a qué informes, a qué objetos tiene

acceso un Usuario Consumidor. O, por ejemplo, los usuarios

consumidores sólo podrán realizar consultas en los informes a los

que tengan permiso de acceso.

La Herramienta de Cuadro de Mando deberá tener la capacidad de realizar

una monitorización y control de las actividades realizadas por los usuarios. 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.

Características de los elementos generados por la Herramienta de

Cuadro de Mando

Los elementos generados por la Herramienta de Cuadro de Mando serán

aquellos 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. A continuación, se indican los

requisitos mínimos que deben tener:

Los informes, y resto de elementos que lo permitan, 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.), por origen de datos, etc.

En relación con la creación y edición de informes:

o 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,







Pág. 50 de 134



Exp.054/16-AE

áreas, anillos, radial, superficie, burbujas, cotizaciones,

cilindro, cónico, piramidal en 2 y 3 dimensiones etc.).

o 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.

o Los informes podrán incorporar ítems calculados en tiempo

real sin requerir desarrollo adicional para ello (por ejemplo

suma de los valores de dos indicadores).

o 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.

o La Herramienta de Cuadro de Mando debe tener capacidades

de edición de los informes y resto de elementos, de tal forma

que los usuarios autorizados puedan incorporar hipervínculos,

textos, imágenes, etc.

La Herramienta de Cuadro de Mando debe proporcionar un mínimo

de trazabilidad que permita identificar el impacto de cambios en la

información de las fuentes origen en los distintos elementos

generados por la Herramienta de Cuadro de Mando.

En relación con la consulta y visualización en navegadores web

convencionales, los informes y resto de elementos de la herramienta:

o Deberán ser accesibles desde los principales navegadores

web, Microsoft Internet Explorer (versión 9 en adelante),

Mozilla Firefox (versión 3.6 en adelante), Google Chrome

(versión 8 en adelante), sin necesidad de instalar software

adicional en cada equipo con el que se quiera consultar o

modificar informes.







Pág. 51 de 134



Exp.054/16-AE

o 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.

o Deberán poder consultarse, en los casos que así se determine,

de forma “desconectada”. Es decir, si no hay acceso a la

Herramienta de Cuadro de Mando los informes que se

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.

o Deberán poder ser consultados y visualizados sobre

dispositivos móviles (PDA´s, Tablets, smartphones, etc.)

mediante alguna de estas dos alternativas:

1. Bien desde una aplicación web que pueda ser visualizada

correctamente en los navegadores habituales de un amplio

espectro de dispositivos móviles basados en distintos

sistemas operativos (iOS, Android, Firefox OS, Blackberry

OS, Windows Mobile, Symbian, etc). Como mínimo habrán

de visualizarse adecuadamente sobre los dos primeros.

2. Bien mediante aplicaciones nativas creadas a tal efecto

para plataformas móviles concretas, en este caso, han de

crearse aplicaciones nativas al menos para iOS y Android

al ser las más utilizadas en el mercado. Será admitida la

necesidad de instalación de algún elemento software en el

dispositivo, si bien, el licitador ha de incluir en su oferta el

licenciamiento que fuese necesario para permitir esta

funcionalidad.

En cualquiera de los dos casos, el formato de los informes y resto de

elementos debe tratar de adaptarse, en la medida de lo posible, a las

características del terminal con mayor presencia entre los usuarios

consumidores del ayuntamiento que vayan a hacer uso efectivo de esta

funcionalidad para tratar de optimizar su visualización.







Pág. 52 de 134



Exp.054/16-AE

En relación con la exportación de informes, la herramienta deberá:

o Permitir una amplia variedad de formatos de salida, entre

ellos, y sin carácter exhaustivo: HTML, PDF, Microsoft office

(Excel, Word), CSV. Se requiere no tener que retocar el

informe obtenido cada vez que se genere, sino que éste se

adapte al formato elegido para exportarlo.

o Posibilitar el envío de informes exportados por correo

electrónico o bien de forma programada, envíos de acuerdo

con una planificación programada o bien a demanda del

usuario de la Herramienta de Cuadro de Mando.

o La Herramienta de Cuadro de Mando debe poder permitir la

posibilidad de edición de los informes antes de proceder a

exportarlos. Asimismo debe ser posible editarlos una vez que

hayan sido exportados al formato correspondiente, siempre

que este formato permita funciones de edición.

Gestión de Históricos de la Herramienta de Cuadro de Mando

La Herramienta de Cuadro de Mando debe permitir la consulta de los datos

históricos para su comparación con los datos vigentes, cuando el usuario disponga

de los permisos para realizar la consulta a través de las opciones habilitadas para

ello.

Además, la Herramienta 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.

Servicio de notificaciones de la Herramienta de Cuadro de Mando

La Herramienta de Cuadro de Mando deberá 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 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.







Pág. 53 de 134



Exp.054/16-AE

g) Requisitos de la Herramienta de ETL

La herramienta ETL debe permitir la integración con las diferentes fuentes

de datos tanto origen como destino, así como la facilidad de creación y

mantenimiento de los procesos de extracción, transformación y carga que se

requieran para la obtención de la información necesaria.

A continuación se detallan los requisitos mínimos de la Herramienta de ETL:

Conectividad con soporte a orígenes y destinos de datos: la

herramienta debe ser capaz de conectarse con gran variedad de

fuentes de datos. En los análisis previos se han identificado como

proveedoras de información, fuentes de distinta naturaleza de los

distintos sistemas del Ayuntamiento como: bases de datos

relacionales y no relacionales, variados formatos de ficheros (Excel,

Word, Access, etc), XML, servicios web, Google Analytics entre otros.

Basado en el análisis de los indicadores y de las fuentes que sea

preciso integrar, el adjudicatario deberá definir los procesos que

resulten óptimos para cada fuente original de datos.

Debe permitir acceder y definir diferentes tipos de transformaciones

a los datos procedentes de las diversas fuentes de información

existentes.

Tiene que tener capacidades de Metadatos y Modelado de Datos que

permita recuperación de los modelos de datos desde los distintos

orígenes de datos, creación y mantenimiento de modelos de datos,

mapeo de modelo físico a lógico, repositorio de metadatos abierto

(con posibilidad de interactuar con otras herramientas),

sincronización de los cambios en los metadatos en los distintos

componentes de la Herramienta de ETL, etc.

Tiene que adaptarse a la plataforma hardware y software del

Ayuntamiento descrita en el apartado 1.3.1. Debe permitir realizar

actuaciones para su administración a través de una interfaz sencilla

que facilite la monitorización y control de los procesos de

integración de datos con gestión de errores, recolección de

estadísticas de ejecución, controles de seguridad, etc.







Pág. 54 de 134



Exp.054/16-AE

Debe contar con una interfaz gráfica para la gestión y administración

de los datos: modelos de datos, flujos de datos, y los elementos que

forman parte de la definición y ejecución de los procesos de

extracción, transformación y carga.

Debe permitir realizar unas verificaciones mínimas en relación a la

calidad del dato.

Debe poder disponer de todos los procesos necesarios para efectuar

la extracción, transformación y carga de los datos de las distintas

fuentes de información destinadas a ser explotadas por la

Herramienta de forma que:

o La configuración de todos ellos se ha de realizar mediante de

una interfaz sencilla.

o La Herramienta debe permitir planificar la ejecución de los

procesos.

o Los procesos han de ser robustos garantizando su ejecución

programada, y con mecanismos de contingencia que

garanticen su ejecución ante incidencias que pudiesen

ocasionarse durante su ejecución.

o Los procesos deben estar automatizados, ofreciendo además

la capacidad de lanzar su ejecución de modo manual si los

administradores lo considerasen necesario en algún momento

puntual.

o Será admitida la programación sencilla por parte del usuario

en alguno de los procesos, si así lo requiriese, si bien deberá

poder realizarse mediante una interfaz sencilla que facilite

dicha tarea.

o La herramienta deberá ofrecer facilidades de gestión y

configuración de los procesos que favorezcan la autonomía de

los usuarios administradores y, con ello, eviten o reduzcan al

máximo cualquier tarea de programación.







Pág. 55 de 134



Exp.054/16-AE

La Herramienta de ETL debe proporcionar un mínimo de trazabilidad

que permita identificar el impacto que cambios que se produzcan

pueden ocasionar sobre los procesos que se encuentran definidos.

h) Licencias

El adjudicatario deberá incluir todas las licencias que resulten

necesarias para implantar las herramientas y solución descritas en el

apartado 2.2.2 Cuadro de mando.

Además, el licitador deberá incluir todas las licencias de uso necesarias

para que sobre la solución implantada en los entornos del Ayuntamiento, se

puedan configurar cada uno de los perfiles descritos a continuación con el número

mínimo de usuarios concurrentes y las capacidades especificadas:

Usuario Administrador/Arquitecto: usuario con capacidad de

administración total de la solución, incluyendo la Herramienta de Cuadro

de Mando y la Herramienta de ETL. Su capacidad de administración será

tanto a nivel de infraestructura hardware (configuración y control de

back-ups, rendimiento, disponibilidad…) como software, desde

funcionalidad (acceso a la totalidad de la funcionalidad de la aplicación),

gestión de usuarios, etc. Asimismo tendrá capacidad para la gestión

total sobre la Herramienta de ETL y de la base de datos en la que se

consolida la información. Por ello, algunas de las funciones que realizará

este perfil son: la incorporación de una nueva fuente de datos, crear u

modificar indicadores incluyéndolos en la base de datos, creación de los

metadatos para la generación de los informes por parte de los usuarios

de reporte. Además, estos usuarios tendrán capacidades sobre la

Herramienta de Cuadro de Mando, como por ejemplo la incorporación de

una fuente de datos de la que la Herramienta de Cuadro de Mando

obtenga información, etc.

Número mínimo de usuarios con este perfil:

Para el entorno productivo, se establece un mínimo de UN (1) usuario

con perfil de Administrador/Arquitecto.

Para entornos no productivos se admitirá activar un número menor

de usuarios de cada perfil descrito, siempre y cuando con los que se







Pág. 56 de 134



Exp.054/16-AE

activen sea posible probar y comprobar las capacidades y

funcionalidades requeridas a las distintas tipologías.

Usuario de Reporte (solo para la Herramienta de Cuadro de Mando):

usuario con las capacidades correspondientes a la gestión y

funcionalidad de la Herramienta de Cuadro de Mando. Por ello, entre las

funciones más significativas de este perfil son las relativas a la creación

de nuevos informes, modificación de los existentes, incluyendo la

asignación de los permisos de consulta de los informes para los distintos

usuarios con aspectos tales como el diseño, información que pueden

acceder, funcionalidad disponible para cada uno de ellos, etc.


Para el entorno productivo, se establece un mínimo de CUATRO (4)

usuarios (que deberán poder ser concurrentes) con perfil de Reporte.





Usuario Consumidor (solo para la Herramienta de Cuadro de Mando):

usuario con las capacidades correspondientes para la consulta de

informes Por ello, el usuario podrá acceder a los informes a los que

tenga permiso y que mediante filtros u otro tipo de selecciones

predefinidas pueda realizar consultas con mayor o menor nivel de

detalle en los mismos. Estos usuarios pueden consultar los informes en

las distintas formas que se definan: accediendo a la Herramienta, su

consulta a través de los informes que se publiquen en los portales,

envíos vía correo electrónico, exportaciones off-line de los informes, etc.


Para el entorno productivo, se establece un mínimo de CUARENTA

(40) usuarios (que deberán poder ser concurrentes) con perfil de

Usuario Consumidor.









Pág. 57 de 134



Exp.054/16-AE



Además, el adjudicatario deberá considerar la existencia de un tipo especial

de Usuarios Consumidores, los Ciudadanos, dado que éstos consumirán

determinados informes predefinidos del Cuadro de Mando que el Ayuntamiento

considere de interés para ellos. Si bien hay un número ilimitado de “Usuarios

Consumidores Ciudadanos”, se debe tener en cuenta que todos los informes

predefinidos a consumir por ellos habrán de ser publicados -mediante mecanismos

automáticos- a través de alguno de los portales municipales que se determine, de

manera que los “Usuarios Consumidores Ciudadanos” nunca accederán

directamente al Cuadro de Mando sino que consumirán sus informes a través de

otros front-end municipales a los que el Cuadro de Mando deberá suministrar los

mismos.

El adjudicatario habrá de efectuar la implantación del Cuadro de Mando

sobre los entornos de preproducción y producción del Ayuntamiento, sin que pueda

repercutirse ningún coste adicional por licencias distintas a las contempladas por

el licitador en su oferta.

Para la totalidad de tareas inherentes y propias a 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 al

Ayuntamiento. Como tal, no podrá incluir costes de licencias para dicho entorno.

La totalidad de licencias suministradas por el adjudicatario deberán incluir

el servicio de garantía detallado en el apartado 3.5 Requisitos de Garantía.

Las licencias suministradas podrán ser utilizadas por el Ayuntamiento, sin

más limitaciones que las especificadas por el fabricante que la provea, dentro de

las evoluciones o ampliaciones futuras de su sistema.

Cualquier licencia adicional a las ofertadas que el adjudicatario propusiese

suministrar y poner en uso como parte de cualquiera de los trabajos, estará -una

vez aprobado su suministro y puesta en marcha por Red.es- sujeta a las

condiciones especificadas en el presente apartado para el resto de licencias

suministradas.







Pág. 58 de 134



Exp.054/16-AE

2.2.3 CANAL SMART

2.2.3.1 (√) Sistema que debe posibilitar y favorecer la interacción

ciudadana con el ayuntamiento. Concebido como un lugar

para realizar aportaciones efectivas y participación

cualitativa en los temas públicos.

2.2.3.2 (√) El acceso al canal smart deberá poder efectuarse a través

de dos front-end:

A través de aquella web municipal que el Ayuntamiento

determine al inicio de los trabajos

A través de la app móvil municipal descrita en el apartado 2.3

COMPONENTE 2: APLICACIÓN MÓVIL MUNICIPAL, de modo

que su funcionalidad deberá estar disponible y ser soportada

por dicha app móvil.

2.2.3.3 (√) Para la implementación del back-end del canal smart se

podrá hacer uso de los elementos hardware y software que

pudieran estar disponibles en la infraestructura actual para

este propósito (ver apartado 1.3.1 ) así como emplear aquellos

que se requieran dentro de los que conformen la Plataforma

de Ciudad Inteligente ofertada por el adjudicatario para dar

respuesta a los requisitos del apartado 2.2.

2.2.3.4 (√) El canal smart, deberá ofrecer:

a) A nivel de Reporte y Gestión de Incidencias:

Ofrecer un canal al ciudadano y personal municipal para poder

reportar incidencias de los servicios u otras detectadas en la vía

pública, así como para adjuntar imágenes explicativas de la

incidencia.

Integrarse con la aplicación de incidencias municipal (ver apartado

1.3.1) de modo que:







Pág. 59 de 134



Exp.054/16-AE

o Cada incidencia reportada a través del canal smart genere

automáticamente una incidencia en dicha herramienta.

o El canal smart tenga acceso a la información del estado de las

distintas incidencias reportadas a través de él.

Enviar por correo electrónico la incidencia o consulta al servicio

municipal implicado para su resolución.

Proporcionar datos al Cuadro de Mando del Componente 1 que, junto

a los datos proporcionados al mismo por la aplicación de incidencias

municipal, permitan la generación y seguimiento de los indicadores

relativos a las incidencias gestionadas mediante este canal y de

aquellos otros indicadores relacionados con este canal que se

determinen –en fase de análisis- al implantar el Cuadro de Mando.

b) A nivel de Participación Ciudadana en Plenos Municipales:

Ofrecer un canal interactivo de modo que el ciudadano pueda

conocer, comentar y opinar en relación con los plenos municipales

que disponga de:

Un foro donde los ciudadanos puedan efectuar propuestas y

sugerencias para ser tenidas en cuenta en los plenos. Asimismo

constituirá un espacio de debate y opinión ciudadana sobre

aspectos vinculados a cada pleno.

Funcionalidades que permitan a los ciudadanos la subida de

ficheros de video a este canal que no superen el minuto de

duración en las calidades y formatos que durante la fase de

análisis se determinen como más adecuados al rendimiento y

requerimientos de almacenamiento asociados a esta

funcionalidad y en base a las limitaciones de la infraestructura

municipal.

Funcionalidades de moderación que permita el control de la

actividad de dicho foro así como su administración.

Acceso a aquella información relacionada con cada pleno

municipal que el ayuntamiento ponga a disposición del ciudadano

para su conocimiento y consulta, entre ella, enlaces a los videos







Pág. 60 de 134



Exp.054/16-AE

correspondientes a las sesiones de plenos municipales que el

ayuntamiento pudiera tener grabados y desee poner accesibles a

los ciudadanos.

2.2.4 PULSO DE LA CIUDAD

2.2.4.1 (√) El adjudicatario deberá implantar una solución que habrá

de permitir la monitorización de medios sociales digitales

(redes sociales, blogs) con el objeto de obtener información

acerca de la opinión de los ciudadanos respecto a la ciudad de

Toledo. A través de esta funcionalidad se podrá conocer las

tendencias y palabras asociadas al término Toledo en las

redes sociales, de cara a identificar el impacto de actuaciones

municipales en la percepción acerca de la ciudad y tomar

actuaciones correctoras.

2.2.4.2 (√) La solución ofrecida deberá rastrear distintas fuentes de

información con objeto de analizar dos aspectos

fundamentales:

Análisis de actividad: frecuencia de mensajes municipales y su

forma de uso por parte de los usuarios.

Análisis de Influencia: cómo y cuánto de visible son los

mensajes/contenidos municipales, números de seguidores y

su percepción o sentimiento.

2.2.4.3 (√) Para ello la solución deberá rastrear como mínimo sobre

Twitter, Facebook e Instagram para identificar y extraer

comentarios relativos a los conceptos que se pretenden

estudiar permitiendo además evaluar la percepción o

sentimiento del ciudadano en dichos comentarios (por

ejemplo: positiva, negativa o neutra).

2.2.4.4 (√) La solución generará informes a medida sobre los datos

de análisis, permitiendo, por ejemplo, obtener información

sobre número de comentarios en un periodo de tiempo







Pág. 61 de 134



Exp.054/16-AE

determinado con posibilidad de efectuar filtrados sobre los

resultados obtenidos.

2.2.4.5 (√) La herramienta también determinará que sitios y/o

usuarios son los más influyentes para un contenido

determinado. Asimismo deberá permitir identificar cuáles son

los contenidos estrella, es decir, aquellas áreas o temas que

más interesan a los usuarios.

2.2.5 ANALÍTICA PREDICTIVA

2.2.5.1 (√) El adjudicatario deberá implantar una herramienta

especializada en la realización de análisis predictivos y de

patrones de comportamiento sobre, inicialmente, los

conjuntos de datos e información manejados en el marco del

presente proyecto que, no obstante, permita su uso futuro

sobre otros conjuntos de datos e información que el

ayuntamiento vaya teniendo disponibles y se consideren de

interés para estos fines.

2.2.5.2 (√) Para ello, deberá suministrar e instalar una herramienta de

analítica predictiva con capacidades para efectuar Text

Minning y Data Minning así como funcionalidades para la

visualización de los resultados de forma intuitiva.

2.2.5.3 (√) La herramienta a implantar deberá ser compatible con la

norma PMML para representar los modelos de predicción, de

modo que esté garantizado el intercambio de los modelos

realizados con el resto de herramientas de analítica que sean

compatibles con dicha norma.

2.2.5.4 (√) La herramienta o solución ofertada no deberá implicar

costes de licenciamiento al Ayuntamiento.

2.2.5.5 (√) Así mismo, como parte de los trabajos a llevar a cabo, el

adjudicatario deberá desarrollar 2 modelos de predicción,

dentro del contexto informacional del presente proyecto, que







Pág. 62 de 134



Exp.054/16-AE

serán determinados en fase de análisis por Red.es y el

Ayuntamiento.

2.2.6 CAPACITACIÓN

2.2.6.1 (√) Como parte de los trabajos, y siempre previa solicitud de

Red.es, el adjudicatario deberá impartir capacitación teórico-

práctica en sesiones formativas grupales a los distintos

perfiles de usuario que deban utilizar cualquiera de los

elementos que constituyen el sistema implantado en el

Componente 1 (apartado 2.2).

2.2.6.2 (√) Esta capacitación podrá ser requerida sobre aspectos que

comprendan el uso, administración, configuración, etc. de la

Base de Datos Analítica o del Cuadro de Mando puesto en

marcha así como sobre los procesos de extracción,

transformación y carga implementados o aspectos de

seguridad a administrar, teniendo siempre presente que la

formación debe estar orientada a maximizar el grado de

autonomía de los distintos usuarios. Así mismo podrá ser

requerida sobre el uso, administración, configuración, etc. de

las soluciones implantadas como parte del Canal smart, Pulso

de ciudad y Analítica Predictiva.

2.2.6.3 (√) Cuando se requieran estas sesiones de capacitación

grupales su duración exacta se acordará con anterioridad al

inicio de la formación, en función de la disponibilidad y

jornada laboral de los asistentes a la misma, así como de la

duración que debería tener dicha capacitación concreta para

asegurar una adecuada transmisión de conocimientos según

las necesidades de los perfiles de usuario.

2.2.6.4 (√) La capacitación deberá estar dirigida a los distintos

perfiles de usuarios que se solicite e incluirá la entrega de

toda la documentación asociada perfectamente adaptada y

acorde a la implementación llevada a cabo en el

Ayuntamiento. El adjudicatario se encargará de elaborar y

entregar toda la documentación en castellano. Esta







Pág. 63 de 134



Exp.054/16-AE

documentación, en el formato especificado por Red.es,

comprenderá todos aquellos documentos que se faciliten a los

asistentes: manual de usuario, manual de administrador, guías

básicas, guías rápidas de utilización, etc.

2.2.6.5 (√) Los medios para impartir la capacitación, a excepción de

los medios propios que deban usar los propios capacitadores,

serán puestos por el Ayuntamiento a disposición de la

capacitación, debiendo el adjudicatario, con anterioridad a la

fecha de cada acción, comprobar junto a los técnicos que el

Ayuntamiento determine, si son adecuados para la correcta

impartición de la misma.

2.2.6.6 (√) El número total de sesiones grupales solicitadas no

excederá de 20.

2.2.6.7 (√) De manera excepcional, Red.es podrá solicitar al

adjudicatario horas de capacitación in-situ destinada a

aquellos usuarios de perfil más complejo (administradores,

usuarios de análisis, reporte, etc.) previamente formados en

sesiones grupales que precisen refuerzo para ejecutar las

tareas que son inherentes a sus perfiles, con el objetivo

principal de profundizar en el uso del sistema y agilizar el

cambio sobre el personal implicado en la organización.

2.2.6.8 (√) El número total de horas de capacitación in-situ solicitadas

no excederá de 40h.

2.2.6.9 (√) Red.es y el Ayuntamiento, de acuerdo con el adjudicatario,

determinarán las fechas de impartición de cada acción de

capacitación solicitada, dentro del periodo de la vigencia del

contrato.

2.2.6.10 El adjudicatario deberá generar las Actas de Capacitación por

cada una de las sesiones realizadas, siguiendo las

indicaciones de Red.es. Deberán ser remitidas a Red.es,

correctamente cumplimentadas y con la firma de los

asistentes y el responsable de la capacitación o formador.







Pág. 64 de 134



Exp.054/16-AE

2.3 COMPONENTE 2: APLICACIÓN MÓVIL MUNICIPAL

Mediante esta actuación se pretende disponer de una herramienta adicional

que, de manera general, por un lado facilite a los ciudadanos un nuevo canal de

información municipal que a su vez permita la participación y colaboración

ciudadana con la administración local y por otro lado facilite a los técnicos

municipales la obtención en tiempo real de información municipal relevante

remitida por los ciudadanos.

2.3.1 DESCRIPCIÓN

En este apartado se describen las principales características técnicas y

funcionalidades que deberá incorporar la aplicación móvil a desarrollar por el

adjudicatario. No obstante lo anterior, el diseño final será consensuado entre el

equipo del adjudicatario y la Dirección Técnica del proyecto designada a tal efecto.

2.3.1.1 (√) Será necesario desarrollar la aplicación móvil municipal

para dispositivos móviles Android e IOS ( al ser los más

utilizados por la población) y publicar dicha app.





2.3.1.3 (√) Para evitar una dispersión y multiplicidad de aplicativos

móviles que dificulten la interacción ciudadanía-

ayuntamiento, se pretende, mediante los trabajos de esta

actuación, implantar una única aplicación móvil municipal que

aglutine toda la operativa aquí descrita y favorezca la fácil

localización de sus contenidos y servicios estructurados

todos ellos en base a distintos canales. En concreto, se

deberán poner operativos, como parte de la aplicación móvil

municipal a implantar, los siguientes cuatro canales: el canal

turismo, el canal smart, el canal archivo municipal y el canal

movilidad.







Pág. 65 de 134



Exp.054/16-AE

a) Canal turismo

2.3.1.4 (√) Dentro de la aplicación móvil municipal se deberá

implantar un canal específico que ofrezca información

turística de una forma más dinámica, atractiva y adaptada al

perfil del visitante del siglo XXI, acostumbrado a viajar y

comparar destinos. El objetivo es que a través un soporte

físico móvil interactivo (tablet o smartphone) conjugado con

la infraestructura física y recursos turísticos, culturales,

patrimoniales y de ocio, reales de la ciudad, y complementado

con tecnologías de realidad aumentada y/o entornos

virtuales, la experiencia de la visita turística al destino Toledo

será más atractiva y diferenciadora con respecto a la visita

turística tradicional, así como la obtención de un nivel de

satisfacción superior por parte de un segmento de turista

especialmente acostumbrado y sensibilizado con el uso y

manejo de determinados soportes para la obtención de la

información concreta, y presentado de una forma adaptada a

dicho perfil.

2.3.1.5 (√) A través de este canal, el sistema también deberá extraer

información relevante del visitante que permita al

ayuntamiento definir estrategias turísticas para mejorar

aspectos como: la comercialización del destino (antes de la

visita), la promoción del destino (antes, durante y después de

la visita) y la fidelización del turista (posterior a la visita), así

como procedencia (nacional o extranjero, y mercado

concreto), motivación principal (cultural, congresos,

vacacional, gastronómica), transporte utilizado (vehículo

privado, o transporte público: AVE, autobús, taxi).

2.3.1.6 (√) Para ello, este canal deberá contemplar la puesta a

disposición de los ciudadanos de contenidos turísticos

diversos en cuanto a su base tecnológica, en concreto, deberá

ofrecer:

Información turística dinámica o estática (en forma de texto o

imágenes) acerca de museos, descripción de monumentos de







Pág. 66 de 134



Exp.054/16-AE

la ciudad, puntos de interés, recomendaciones, guías

turísticas, guías de comercios, barrios, parques…

Adicionalmente, permitirá la descarga de audioguías, sistema

que permite realizar guías personalizadas en museos, centros

históricos de ciudades e itinerarios turísticos. Proveen

información histórica, técnica y sonora del objeto que se está

viendo mejorando la experiencia del turista.

Información de varios monumentos de Toledo usando técnicas

de realidad aumentada y modelado en 3D. Los monumentos

para los que el ciudadano tendrá disponibles contenidos de

este tipo serán los siguientes:

o Catedral

o El Alcázar

o La Mezquita del Cristo de la Luz

o Sinagoga del Tránsito

o Cuadro del Greco “el Entierro del Señor de Orgaz”

Corresponderá al adjudicatario la generación de dichos

contenidos que conllevará, entre otros, la modelación de los

recursos/monumentos en 3D, incorporar locuciones sonoras,

vídeos u otros posibilitando que, en tiempo real, el

visitante/turista a través de marcadores de Realidad Aumentada

(RA) y/o de códigos QR, pueda llegar a interactuar desde un

dispositivo tecnológico con el propio monumento (ej.: rotación

y/o ampliación del monumento para poder ver los detalles desde

todos los ángulos posibles), convirtiendo su búsqueda de

información en una experiencia interactiva. Asimismo, aplicado a

cada uno de los mencionados monumentos, el usuario deberá

poder disfrutar de una visión sobre su dispositivo de un entorno

físico del mundo real cuyos elementos habrán sido combinados

por el adjudicatario con elementos virtuales para la creación de

una realidad mixta en tiempo real. En consecuencia, el







Pág. 67 de 134



Exp.054/16-AE

adjudicatario deberá añadir información virtual a la información

física ya existente de cada monumento anteriormente señalado.

Información de varios monumentos de Toledo usando técnicas

de realidad virtual de modo que se incorpore el interior de los

edificios en una visita virtual de los monumentos de Toledo

seleccionados, sin la necesidad de estar en ellos, pudiendo

adentrarse en su espacio interior desde su dispositivo

electrónico (smartphone o tablet). Los monumentos para los

que el ciudadano deberá tener disponibles contenidos de este

tipo serán los siguientes:

Catedral

Sinagoga del Tránsito

Rutas turísticas guiadas de manera que el turista/visitante

pueda realizar una ruta/visita cuyo guía será un personaje

histórico que actué de cicerone (mediante breves locuciones

en varios idiomas, al menos deberá estar disponible en

castellano, inglés y francés) para indicarles cuáles son los

hitos turísticos más relevantes por los espacios de Toledo que

conformen su ruta (ej.: las culturas y civilizaciones que se

establecieron en Toledo, espacios donde hay obras de El

Greco, relación de Cervantes con ciertos espacios y calles

toledanas). Las rutas implantadas sobre este canal deberán

poder señalarse sobre el mapa turístico en papel suministrado

en las Oficinas de Turismo mediante marcas (realidad

aumentada u otras). Al llegar a un punto de la ruta al turista

se le mostrará el edificio/monumento en realidad aumentada

o, en el caso de no estar disponible mediante esa tecnología,

se mostraría mediante otras alternativas como fotos o un

vídeo sobre ese lugar que se esté visitando. El adjudicatario

deberá asimismo efectuar el modelado del personaje y

animación con movimiento asociado a cada uno de los hitos de

las rutas en base a los textos que el Ayuntamiento ya tiene

preparados para cada uno de estos hitos.







Pág. 68 de 134



Exp.054/16-AE

Las rutas turísticas guiadas que el ciudadano deberá tener

disponibles en el canal serán las tres siguientes:

Ruta 1: Toledo Patrimonio de la Humanidad

Personaje: Cervantes

Itinerario: Museo de Santa Cruz, iglesia de San Román,

convento de Santo Domingo el Antiguo, Alcázar,

sinagoga de Santa María la Blanca, San Juan de los

Reyes, iglesia de San Idelfonso. Probable guía

Cervantes

Ruta 2: Toledo tres culturas

Personajes: Al-Mamún (musulmán), Samuel ha-Levi

(judío) y Emperador Carlos V (cristiano)

Itinerario: Mezquita del Cristo de la Luz, Sinagoga del

Tránsito y la Catedral.

Ruta 3: Espacios Greco en Toledo

Personaje: El Greco

Itinerario: Sacristía Mayor de la Catedral de Santa

María. Convento de Santo Domingo de Silos (“El

Antiguo”). Iglesia de Santo Tomé (Obra maestra Greco:

“El Entierro del Señor de Orgaz”). Hospital de Tavera

(o de Afuera). Capilla de San José. Museo de El Greco.

Museo de Santa Cruz.

2.3.1.7 (√) Corresponderá al adjudicatario la generación de todos los

contenidos de este canal así como su implementación y

puesta en marcha debiendo, para la generación de contenidos,

tomar como punto de partida aquellos ya disponibles en la

Biblioteca Digital del Ayuntamiento de Toledo u otros que el

Ayuntamiento pudiera poner a su disposición.

2.3.1.8 (√) Los principales contenidos de este canal deberán ser

accesibles también mediante diferentes marcadores de







Pág. 69 de 134



Exp.054/16-AE

realidad aumentada (RA), códigos QR o cualquier otro tipo de

marca o señal que permita al turismo llegar directamente

hasta ellos. Los códigos o marcas deberán poder ser incluidos

dentro de los mapas en papel que se proporcionan a los

visitantes en las Oficinas de Turismo o sobre aquellos otros

materiales/elementos informativos que el Ayuntamiento

considere.

b) Canal smart

2.3.1.9 (√) El canal smart descrito anteriormente en el apartado

2.2.3, deberá estar soportado por la aplicación móvil

municipal como un canal a través del cual los distintos

usuarios puedan hacer uso de las funcionalidades descritas en

dicho apartado también desde dispositivos móviles.

c) Canal archivo municipal

2.3.1.10 (√) Este canal, dentro de la aplicación móvil municipal,

consistirá en un enlace con la Biblioteca Virtual, de modo que

el usuario pueda acceder a los contenidos de la misma a

través del móvil sin necesidad de recordar ni escribir su URL.

d) Canal movilidad

2.3.1.11 (√) Este canal, dentro de la aplicación móvil municipal,

consistirá en un enlace con el planificador de Rutas

Intermodal a implantar (descrito en el apartado 2.4), de modo

que el usuario pueda acceder a sus contenidos a través del

móvil sin necesidad de recordar ni escribir su URL.

2.3.2 TAREAS A REALIZAR Y ENTREGABLES

Las tareas a realizar para llevar a cabo la ejecución de este componente

deberán ser las siguientes:

a) Análisis y diseño de la aplicación móvil municipal.

2.3.2.1 (√) El adjudicatario deberá efectuar todas las tareas de toma

de requerimientos, análisis funcional y técnico que le







Pág. 70 de 134



Exp.054/16-AE

permitan efectuar el diseño conceptual y técnico de la

solución solicitada en este componente, descrito

funcionalmente en el apartado 2.3.1.

2.3.2.2 (√) Como resultado de estas tareas, el adjudicatario deberá

generar los siguientes entregables:

Documentación de análisis funcional: Definición del sistema,

requisitos (funcionales, de seguridad y técnicos), interfaces

de usuario, estructura de contenidos e integraciones.

Descripción de los Casos de Uso.

Arquitectura

Modelo de datos

Plan de pruebas

b) Desarrollo e implantación de la aplicación móvil municipal.

2.3.2.3 (√) El adjudicatario deberá efectuar todas las tareas

necesarias de desarrollo de la solución diseñada y efectuar su

posterior implantación sobre la herramienta ofertada por el

adjudicatario que satisfaga los requisitos especificados en el

apartado 2.3.3.

2.3.2.4 (√) Como resultado de la ejecución de estas tareas, el

adjudicatario deberá generar, al menos, los siguientes

entregables:

Código fuente correctamente documentado del software

desarrollado

Paquetes desplegables e instalables del software necesario

para implantar la aplicación móvil

Manual de instalación y despliegue.

Manual de administración

Manual de usuario







Pág. 71 de 134



Exp.054/16-AE

Documentación relativa a los suministros, instalaciones o

pruebas precisos para la correcta implantación del

componente según lo descrito en los apartados 3.1, 3.2 y 3.3

del presente pliego.

2.3.3 REQUISITOS GENERALES DE LA APLICACIÓN MÓVIL

2.3.3.1 (√) Toda la información accesible desde la aplicación estará

gestionada y mantenida, preferiblemente, desde el gestor de

contenidos del ayuntamiento descrito en el apartado 1.3.1 o, si

fuese necesario, mediante aquel ofertado adicionalmente para

este cometido por el adjudicatario.

Compatibilidad

2.3.3.2 (√) Sistemas operativos: La aplicación que desarrolle el

adjudicatario deberá ser compatible con las dos plataformas

más utilizadas para dispositivos móviles, iOS y Android.

Diseño de la aplicación:

2.3.3.3 (√) La aplicación móvil ofertada deberá basar su desarrollo en

estándares abiertos y de fácil mantenimiento.

2.3.3.4 (√) La aplicación móvil deberá seguir las especificaciones

proporcionadas por W3C –Mobile Web Best Practices relativas

a usabilidad.

2.3.3.5 (√) La aplicación móvil deberá seguir las especificaciones

establecidas en la norma UNE 139803:2012, equivalente o

superior en materia de accesibilidad.

2.3.3.6 (√) La aplicación móvil tendrá la imagen corporativa del

Ayuntamiento de Toledo.

2.3.3.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







Pág. 72 de 134



Exp.054/16-AE

adaptación de contenidos ante la rotación del dispositivo

móvil.

2.3.3.8 (√) La plataforma sobre la que se desarrolle la aplicación

ofertada deberá permitir escalar procesos en cualquier

momento y debe proveer al menos 100 procesos simultáneos.

2.3.3.9 (√) El tiempo de respuesta de cualquier petición no debe

superar los 5 segundos.

Navegación

2.3.3.10 (√) El diseño de navegación deberá proporcionar una

navegación amigable e intuitiva.

2.3.3.11 (√) La aplicación móvil tendrá que registrar la actividad de

navegación por parte de los usuarios registrados y no

registrados, siempre con su consentimiento tácito que

deberán otorgar en el momento de la descarga de la

aplicación.

2.3.3.12 (√) La aplicación móvil deberá capturar y almacenar los datos

de navegación de los usuarios que hayan dado su

consentimiento con el fin de que sea explotada a través de un

Panel de Control de la misma. Al menos se deberá enviar

datos que permitan obtener la siguiente información:

Cada acceso que se realice (nuevos y recurrentes).

Número de usuarios concurrente en tiempo real.

Origen geográfico de los accesos.

Tiempos de navegación y permanencia.

Análisis de puntos de escape de la plataforma.

Recursos consultados.







Pág. 73 de 134



Exp.054/16-AE

2.3.3.13 (√) En el caso de dispositivos móviles que no posean de

conexión de datos, toda esta información se deberá

almacenar en el dispositivo y será enviada cuando el

dispositivo tenga conexión de datos.

Multidioma:

2.3.3.14 (√) La aplicación móvil será diseñada y desarrollada

preparada para soportar varios idiomas.

Seguridad:

2.3.3.15 (√) Se establecerán los mecanismos necesarios para evitar

vulnerabilidades, tales como Cross Site Scripting (XSS),

inyecciones de códigos, ejecución maliciosa de código, Cross

Site Request Forgery (CSRF), fuga de información o fallos en

el manejo de errores que informen sobre la infraestructura y

robo de sesión.

2.3.3.16 (√) La aplicación móvil deberá poder mostrar contenidos y/o

funcionalidades de acceso libre a cualquier usuario sin

necesidad de registro, y también contenidos y funcionalidades

que precisen ser un usuario registrado y con permisos para su

acceso. Será en fase de análisis funcional (punto a) Análisis y

diseño de la aplicación móvil municipal. cuando se determine

qué contenidos y/o funcionalidades concretas serán de cada

tipo.

Registro de usuario para el acceso a los contenidos y/o

funcionalidades que lo requieran con carácter previo:







Pág. 74 de 134



Exp.054/16-AE

2.3.3.17 (√) Para acceder a determinados contenidos y/o

funcionalidades será necesario identificarse, si ya es un

usuario registrado, o bien darse de alta introduciendo los

datos correspondientes (a modo de ejemplo: nombre,

apellidos, email, sexo, nacionalidad, dirección, etc.), si aún no

está registrado.

2.3.3.18 (√) El usuario podrá recuperar sus datos de acceso a la

aplicación, en el caso de que se hubiera dado de alta y

modificarlos.

2.3.3.19 (√) El usuario se podrá dar de baja.

2.4 COMPONENTE 3: PLANIFICADOR DE RUTAS INTERMODAL

2.4.1 DESCRIPCIÓN

El Componente 3 contempla la implantación de una aplicación, a la que se

deberá poder acceder vía web y también vía tablet o Smartphone, con las

siguientes funcionalidades:

1. Geolocalización

2.4.1.1 (√) La aplicación mediante funcionalidades de geolocalización

deberá poder, con permiso del usuario, conocer su situación

física más aproximada y combinarla de manera efectiva con

los mapas online (a modo de ejemplo, con Google Maps) para

mostrarle su ubicación sobre ellos.

2.4.1.2 (√) El conocimiento de la posición del viajero deberá servir

también para definir el inicio de la ruta de usuario y buscar el

punto de acceso más cercano a la red de transporte.

2. Sistema de gestión de activos físicos de la red de transporte

2.4.1.3 (√) Deberá ofrecer georreferenciados sobre los mapas online

los activos físicos de la red de transporte (paradas de

autobús, estaciones de bicicletas u otros que el ayuntamiento

pudiera ofrecer georreferenciados) de modo que el usuario







Pág. 75 de 134



Exp.054/16-AE

pueda consultar sobre el mapa donde se encuentran

localizados y, además, sirvan como base al planificador de

rutas descrito a continuación.

2.4.1.4 (√) Además deberá ofrecer las rutas georreferencias del

recorrido de las distintas líneas de autobús así como las rutas

de carril bici.

3. Planificador de rutas

2.4.1.5 (√) El planificador es la funcionalidad que evalúa las rutas a

mostrar al usuario en función de sus preferencias dando al

usuario la ruta óptima.

2.4.1.6 (√) A partir de la geolocalización del usuario y de los activos

físicos de la red de transporte, el planificador deberá poder

calcular el trayecto más corto al punto de acceso a la red de

transporte en función del destino especificado. Para ello, la

aplicación deberá permitir generar las combinaciones

necesarias para optimizar la ruta del usuario en función de

sus preferencias y mostrarlo sobre mapas online. El usuario

podrá elegir como opciones para desplazarse entre:

modo “en coche”

modo “a pie”

modo “en transporte público”, que debe permitir hacer

combinaciones de rutas a partir de los medios de

transporte público georreferenciados y las rutas de los

mismos.

4. Sistema de gestión de horarios de los medios de transporte

2.4.1.7 (√) Deberá permitir la carga de los horarios de paso por cada

una de las paradas a lo largo del día para todos los días de la

semana, de modo que, por una parte dichos horarios puedan

ser consultados por los usuarios desde alguna parte de la

aplicación y, por otra, puedan ser empleados para optimizar







Pág. 76 de 134



Exp.054/16-AE

las rutas ofrecidas al usuario por el planificador de rutas

(funcionalidad descrita en el punto anterior).

2.4.1.8 (√) Para el cumplimiento y desarrollo de los trabajos y previo

al inicio de los mismos, el ayuntamiento entregará al

adjudicatario una serie de ficheros en formato .dwg con la

siguiente información:

Planta de la red viaria.

Ejes de la red viaria.

Carril bici

Remontes mecánicos

Estaciones de la red de bus

Ejes de la red de bus.

Informe de intensidades de tráfico del viario principal

2.4.2 TAREAS A REALIZAR Y ENTREGABLES

Las tareas a realizar para llevar a cabo la ejecución de este componente

deberán ser las siguientes:

a) Análisis y diseño de la aplicación.

2.4.2.1 (√) El adjudicatario deberá efectuar todas las tareas de toma

de requerimientos, análisis funcional y técnico que le

permitan efectuar el diseño conceptual y técnico de la

solución solicitada en el este componente, descrita

funcionalmente en el apartado 2.4.1.

2.4.2.2 (√) Como resultado de estas tareas, el adjudicatario deberá

generar, al menos, los siguientes entregables:

Documentación de análisis funcional: Definición del sistema,

requisitos (funcionales, de seguridad y técnicos), interfaces







Pág. 77 de 134



Exp.054/16-AE

de usuario, estructura de contenidos e integraciones.

Descripción de los Casos de Uso.

Arquitectura

Modelo de datos

Plan de pruebas

b) Desarrollo, configuración e implantación de la aplicación

2.4.2.3 (√) El adjudicatario deberá efectuar todas las tareas

necesarias de desarrollo o configuración de la solución

diseñada y efectuar su posterior implantación.





2.4.2.5 (√) Para la implementación e instalación de la aplicación, el

adjudicatario podrá hacer uso de los elementos hardware y

software que pudieran estar disponibles en la infraestructura

actual para este propósito (ver apartado 1.3.1) así como

emplear aquellos que requiera dentro de los que conformen la

Plataforma de Ciudad Inteligente ofertada por el adjudicatario

para dar respuesta a los requisitos del apartado 2.2.

2.4.2.6 (√) Como resultado de la ejecución de estas tareas, el

adjudicatario deberá generar, al menos, los siguientes

entregables:

Código fuente correctamente documentado del software

desarrollado

Paquetes desplegables e instalables del software

necesario para implantar la aplicación

Manual de instalación y despliegue.







Pág. 78 de 134



Exp.054/16-AE

Manual de administración

Manual de usuario

Informe de resultados de las pruebas

2.5 COMPONENTE 4: EXTENSIÓN EDUROAM

El proyecto eduroam@city tiene como objetivo fundamental complementar

a la red inalámbrica municipal dotándola de un acceso diferenciado destinado a la

comunidad universitaria, así como a otros usuarios de servicios universitarios

accesibles por ciudadanos, como los ofertados de forma electrónica por la

Biblioteca universitaria. Estos usuarios podrán acceder a la red inalámbrica del

mismo modo que si estuvieran en el campus universitario, accediendo de forma

segura y con alta calidad a los contenidos ofertados por la universidad.

Por otro lado, el uso del servicio eduroam como mecanismo de

autenticación y acceso de usuarios entre las diferentes universidades tiene un alto

nivel de madurez, como así lo constata la extensión internacional a 69 países

desde 2003, año de nacimiento de la iniciativa en Europa. En el caso de la UCLM,

se trata del único acceso proporcionado a su comunidad universitaria en todo el

ámbito de cobertura de su extensa red inalámbrica.

2.5.1.1 (√) Haciendo uso de las infraestructuras ya desplegadas, el

proyecto eduroam@city permitirá el despliegue de la red

inalámbrica eduroam en los espacios públicos descritos a

continuación para que los usuarios de cualquier universidad

adscrita a eduroam puedan utilizar el servicio inalámbrico

identificándose con sus credenciales contra los servicios de

autenticación y autorización de la UCLM.

2.5.1.2 (√) La inversión destinada al despliegue del proyecto

eduroam@city se focaliza en la ampliación de la

infraestructura de puntos de acceso con 3 nuevos puntos.

2.5.1.3 (√) La infraestructura de puntos de acceso deberá permitir su

instalación en zonas de exteriores, como fachadas o farolas, y

deberá ser compatible con infraestructura y plataforma de







Pág. 79 de 134



Exp.054/16-AE

gestión inalámbrica de la UCLM para poder desplegar el

servicio de eduroam descritas en el apartado 1.3.3.

2.5.1.4 (√) Se han identificado los siguientes puntos dentro del casco

antiguo de Toledo, como zonas de tránsito donde desplegar el

servicio:

Plaza de San Vicente

Plaza de Padilla

Plaza de Juan de Mariana

2.5.1.5 (√) Dadas las características de las plazas a cubrir sería

necesario un total de 3 antenas direccionales y 2

omnidireccionales con las siguientes características mínimas:

Doble radio 5GHz 802.11 ac y 2,4GHz 802.11n.

Dynamic frequency selection (DFS)

Soporte a las tecnologías de radio:

o 802.11b: Direct-sequence spread-spectrum

(DSSS)

o 802.11a/g/n/ac: Orthogonal frequency-division

multiplexing (OFDM)-

o 802.11n/ac: 3x3 MIMO with up to three spatial

streams

Cyclic delay diversity (CDD)

Space-time block coding (STBC)

Low-density parity check (LDPC)

Power over Ethernet 802.3at

2 enlaces hasta 1000Base-T







Pág. 80 de 134



Exp.054/16-AE

Capacidad de formar redes mesh para interconectar

los equipos a la vez que se da servicio a los clientes por los

canales de 5 y 2,4GHz simultáneamente

IP66 y IP67

2.5.1.6 (√) El adjudicatario deberá asimismo suministrar como parte

de este componente:

o 3 inyectores power over ethernet POE+ 802.3at

o 3 soportes de exteriores en pared

o 2 soportes de exteriores para postes

o todos los elementos de conexionado y cables

adicionales que sean necesarios, en número

suficiente para cumplir con los requisitos de este

pliego, que garanticen el conexionado e integración

de los nuevos elementos ofertados en este

componente con las redes e infraestructura

existente descritas en el apartado 1.3.3.

Tal y como se refleja en el apartado 1.3.3, la UCLM dispone de las licencias

necesarias para la conexión de los nuevos puntos de acceso a sus controladoras

para el servicio de eduroam.

2.5.1.7 (√) Deberá ofertarse la instalación de los puntos de acceso en

cada una de las ubicaciones con los siguientes requisitos:

PLAZA DEL PADRE JUAN DE MARIANA







Pág. 81 de 134



Exp.054/16-AE

o Instalación de un punto de acceso en edificio San Pedro Mártir de la

UCLM. Se requiere panel de parcheo 24 puertos RJ45 cat6, así

como su instalación en el rack del edificio. Será necesarios 60

metros de cable Ethernet cat 6 debidamente parcheado en los

armarios de comunicaciones de la UCLM, así como la instalación del

punto de acceso en los exteriores del edificio. Puede utilizarse toma

de datos existente en edificio, sustituyendo cable actual por otro de

cat6.

o Instalación de punto de acceso en plaza, para los que será necesario

la instalación del punto en poste.

o Necesidades eléctricas para el nodo mesh de la Plaza Juan de

Mariana. El mesh estará situado en el brazo del farol de pared

instalado en un lateral de la plaza. El farol aparece señalado en

amarillo en la imagen siguiente y el centro de mando desde donde se







Pág. 82 de 134



Exp.054/16-AE

alimentará el nodo mesh está señalado en rojo. Será necesario

instalar:

1 automático bipolar 2x10A; dentro del centro de mando de

alumbrado anexo.

1 interruptor diferencial 2x25A, 30mA, tipo superinmunizado;

dentro del centro de mando de alumbrado.

30 m cable RV 0,6/1Kv 3x2, 5mm2, con parte proporcional de

elementos de fijación, tacos, bridas, tubo metálico de

protección.

o Pequeño material y montaje.

PLAZA DE PADILLA







Pág. 83 de 134



Exp.054/16-AE

o Instalación de un punto de acceso en edificio Facultad de

humanidades de la UCLM. Se requiere panel de parcheo 24p RJ45

cat6, así como su instalación en el rack del edificio. Será necesarios

90 metros de cable Ethernet cat. 6 debidamente parcheado en los


punto de acceso en los exteriores del edificio. Puede utilizarse toma

de datos existente en edificio, sustituyendo cable actual por otro de

cat6.

o Instalación de punto de acceso en la fachada del Centro Cívico del

casco histórico situado en la plaza, para los que será necesario la

instalación del punto en fachada.

o Necesidades eléctricas para el nodo mesh situado en la fachada del

Centro Cívico del Casco Histórico. El mesh estará situado en el brazo







Pág. 84 de 134



Exp.054/16-AE

del farol de pared instalado en un lateral de la plaza. El farol aparece

señalado en amarillo en la imagen siguiente y el centro de mando

desde donde se alimentará el nodo mesh está señalado en rojo. Será

necesario instalar:

1 automático bipolar 2x10A; dentro del centro de mando de

alumbrado anexo.

1 interruptor diferencial 2x25A, 30mA, tipo superinmunizado.;

dentro del centro de mando de alumbrado.

30 m cable RV 0,6/1Kv 3x2,5mm2, con parte proporcional de

elementos de fijación, tacos, bridas, tubo metálico de

protección.

o Pequeño material y montaje.

PLAZA DE SAN VICENTE

o Instalación de un punto de acceso en edificio Cardenal Lorenzana de

la UCLM. Se requiere panel de parcheo 24 puertos RJ45 cat6, así

como su instalación en el rack del edificio. Será necesarios 30

metros de cable Ethernet cat 6 debidamente parcheado en los


punto de acceso en los exteriores del edificio.







Pág. 85 de 134



Exp.054/16-AE

2.5.1.8 (√) Para la conexión de los puntos de acceso a la red de la

UCLM de forma securizada será necesario suministrar un

equipo de routing nivel 3. Las características técnicas

mínimas de este equipo serán:

Equipo enracable en armarios de 600mm

16 puertos SFP+ a 10Gb

Fuentes redundadas con cambio en caliente

Elementos de ventilación redundados con cambio en

caliente

Al menos, 400Gbps de conmutación

Capacidades de enrutamiento: IPv4, IPv6 (soportado en

hardware) y multicast, ACL y QoS con un mínimo de 8

colas por puerto y políticas integrales de seguridad por

puerto

Compatible con (Border Gateway Protocol) BGP y Virtual

Routing

Soporte de hasta 4094 VLANS

32000 grupos IGMP

Seguridad: Port security, IEEE 802.1X, extensiones 802.1X

, VLANes, enrutamiento, ACL’S (128K), ACL por puerto,







Pág. 86 de 134



Exp.054/16-AE

uRPF en hardware, protecciones contra DoS, Vlanes

privadas

Para la conexión del equipo de enrutamiento de nivel 3 con

los equipos de la UCLM se deberán suministrar 2 módulos

SFP+ 10G-Base-SR, 2 módulos X2 10G-Base-SR y 2

latiguillos de bifibra LC-SC OM3 con pulido UPC.

El equipo irá conectado al router troncal de la UCLM,

basado en Cisco WS-6509-E, en un puerto de 10Gbps

disponible en una tarjeta modelo WS-X6708-10GE, por lo

que deberá ser compatible con dicho elemento. La

instalación de éste elemento concreto (equipo de routing

nivel 3) será efectuada por la UCML no formando parte de

los trabajos solicitados dentro de este componente.

2.5.1.9 (√) El adjudicatario deberá asimismo suministrar todos los

elementos de conexionado y cables adicionales que sean

necesarios, en número suficiente para cumplir con los

requisitos de este pliego, que garanticen el conexionado e

integración de los nuevos elementos ofertados en este

componente dentro de la red eduroam en Toledo.

2.5.1.10 (√) La instalación y puesta en marcha de los elementos

suministrados en el presente componente incluye las

siguientes actuaciones:

Instalación de todos los elementos entregados, a

excepción del equipo de routing nivel 3 cuya instalación

llevará a cabo la UCLM.

Conexionado, instalación/actualización de firmware,

configuración e integración de todos los elementos

entregados con la infraestructura existente, descrita en el

presente apartado así como en el apartado 1.3.3.

Pruebas de verificación de la instalación, configuración y

montajes efectuados.







Pág. 87 de 134



Exp.054/16-AE





2.6 COMPONENTE 5: SUMINISTRO DE SERVIDORES

2.6.1.1 (√) Este componente contempla el suministro de servidores

físicos necesarios para soportar, junto a la infraestructura

existente (ver apartado 1.3.4) y el resto de nuevos elementos

suministrados mediante el presente proyecto, la implantación

de las soluciones descritas en los Componentes 1 al 4.

La cantidad de unidades a suministrar es la especificada en el

apartado 5.2.2 para este componte.

2.6.1.2 (√) Los servidores suministrados deben ser idénticos (misma

marca, modelo, versión, etc.).

2.6.1.3 (√) No debe superar 2 RU de altura. El bastidor donde se

alojarán los servidores será facilitado por el Ayuntamiento de

Toledo en su CPD (ver apartado 1.3.4).

Características de cada uno de los servidores:

Procesador







Pág. 88 de 134



Exp.054/16-AE

2.6.1.4 (√) Cada servidor deberá tener 2 procesadores multinúcleo

con arquitectura X86 de 64 bits con 16 núcleos por

procesador, 32 núcleos en total.

2.6.1.5 (√) Debe permitir la ejecución concurrente de un mínimo de 4

threads.

2.6.1.6 (√) Al menos 20 MB Memoria Caché de segundo nivel o

superior.

2.6.1.7 (√) Puntuación igual o superior a 500

SPECint_rate_base2006, en el programa para el cálculo de

rendimiento (Benchmark) SPEC CPU2006 (ver apartado

¡Error! No se encuentra el origen de la referencia.):

Placa Base

2.6.1.8 (√) La placa base soportará, al menos, 16 ranuras de memoria.

Memoria RAM

2.6.1.9 (√) Cada servidor deberá disponer de un mínimo de memoria

RAM de 96 GB DDR4 o superior y debe poder admitir

ampliación de memoria hasta al menos 768 GB.

Disco duro y controladora de cada servidor:

2.6.1.10 (√) Cada servidor deberá tener como mínimo 3 discos de 480

GB netos en RAID 1, como mínimo que deberán ser

proporcionados mediante discos SSD o bien mediante discos

SAS a 10K rpm o superior.

2.6.1.11 (√) Controladora de disco con soporte para el máximo

número de discos que pueda llevar cada servidor. Además,

deberá soportar, al menos, RAID 0, 1 y 5.

Conectividad:







Pág. 89 de 134



Exp.054/16-AE

2.6.1.12 (√) Al menos 12 puertos de red Ethernet a 1 GB integrada en

placa base o en tarjetas de expansión (necesario para cubrir

las necesidades de ancho de banda de la aplicación)

2.6.1.13 (√) Al menos, 2 puertos FC a 8 Gb.

Puertos de E/S

2.6.1.14 (√) Cada servidor dispondrá de unidad de DVD de

lectura/escritura integrada.

2.6.1.15 (√) Mínimo 2 puertos USB 3.0 externos.

Sistema Operativo

2.6.1.16 (√) Cada servidor debe estar soportado para Sistemas

Microsoft Windows Server 2012, Microsoft Windows

DataCenter y Linux. (Sistemas operativos actualmente

implantados en el Ayuntamiento de Toledo2.9)

Otros

2.6.1.17 (√) Fuentes de alimentación redundantes.

2.6.1.18 (√) Sistema de refrigeración mediante ventiladores, con

posibilidad de ser intercambiados en caliente, sin parada del

servidor.

2.6.1.19 (√) Posibilidad de instalación de, al menos, una tarjeta SD de

16 GB de capacidad, para la instalación de SSOO o

hipervisores












Pág. 90 de 134



Exp.054/16-AE

componente dentro de la infraestructura existente descrita

en el apartado 1.3.4.

2.6.1.21 (√) El adjudicatario será el responsable de realizar el

suministro y entrega de los equipos en la ubicación o

ubicaciones finales que Red.es designe.

2.6.1.22 (√) Todos los suministros y pruebas precisos para la ejecución

de este componente deberán realizarse cumpliendo lo

descrito en los apartados 3.1 y 3.3 del presente pliego.

2.7 COMPONENTE 6: SUMINISTRO DE SISTEMAS DE

ALMACENAMIENTO

2.7.1.1 (√) Este componente contempla el suministro de sistemas de

almacenamiento unificado SAN/NAS para soportar, junto a la

infraestructura existente (descrita en el apartado 1.3.4) y los

nuevos elementos suministrados mediante el presente

proyecto, la implantación de todas las soluciones descritas.

La cantidad de unidades a suministrar es la especificada en el

apartado 5.2.2 para este componte.

2.7.1.2 (√) Deberán incluir las correspondientes guías para el

montaje en rack.

2.7.1.3 (√) Los sistemas de almacenamiento suministrados deben ser

idénticos (misma marca, modelo, versión, etc.).

Características de cada unidad de sistema de almacenamiento

SAN/NAS:

Capacidad







Pág. 91 de 134



Exp.054/16-AE

2.7.1.4 (√) Debe soportar discos con las tecnologías: SSD, SAS y NL-

SAS.

2.7.1.5 (√) Debe soportar al menos discos de los siguientes tipos:

Tipo 1: SAS de 10 Krpm de 900 GB o equivalente o superior

Tipo 2: NL SAS 7.200 rpm de 2, ó 3 TB o equivalente o superior

2.7.1.6 (√) Como mínimo un 40% del almacenamiento ofertado se

proporcionará en discos de Tipo 1.

2.7.1.7 (√) Debe incluir una capacidad mínima de 30 TB netos.

2.7.1.8 (√) Debe ser escalable hasta 125 TB netos como mínimo, sin

ningún tipo de componente adicional, hardware software

(licencias), excepto el aumento del número de discos.

2.7.1.9 (√) Debe soportar un mínimo de 120 discos.

Rendimiento

2.7.1.10 (√) Rendimiento con capacidad para poder alcanzar, al menos,

4.000 IOPs (de 8KB con un tiempo de respuesta menor a

10ms, ratio lectura/escritura de 60/40 y con un éxito en

caché del 60%).

Memoria Caché

2.7.1.11 (√) Al menos, 8GB por controladora, ampliable al menos a

24GB.

Controladora







Pág. 92 de 134



Exp.054/16-AE

2.7.1.12 (√) Como minimo, doble procesadora (controladora) en

arquitectura activo-activo.

2.7.1.13 (√) Las controladoras deben tener capacidad de sustitución en

caliente, sin que ello provoque disrupción del servicio.

Conectividad

2.7.1.14 (√) Debe soportar conectividad mediante, al menos, los

protocolos:

Fibre Channel (FCP).

iSCSI.

2.7.1.15 (√) Con, al menos, los siguientes números y tipos de puertos

activos:

4 puertos Fibre Channel de 8 Gbps o superior.

4 puertos iSCSI a 1 ó 10 Gb

Disponibilidad y fiabilidad

2.7.1.16 (√) Deberá contemplar elementos HW completamente

redundados sin puntos únicos de fallo, incluyendo doble

fuente de alimentación en todos los elementos HW.

2.7.1.17 (√) Ofrecer una disponibilidad acreditada del sistema de

almacenamiento superior a 99,99%.

2.7.1.18 (√) Flexibilidad de configuración del nivel de protección RAID

controlado a nivel HW por la propia solución. Soporte para al

menos RAID 1, 5 y 6. Todos los discos instalados en esta

unidad deberán estar configurados en RAID según el tipo que

se decida durante el proceso de instalación.

2.7.1.19 (√) Debe permitir una gran escalabilidad y flexibilidad del

almacenamiento, permitiendo mezclar en la misma bandeja

discos de cualquiera de los tres tipos soportados (los







Pág. 93 de 134



Exp.054/16-AE

detallados en los requisitos de “capacidad” para este

componente).

2.7.1.20 (√) Debe disponer de una arquitectura de prevención y

reemplazo ante el fallo individual de un disco a modo de hot-

spare o mecanismo equivalente, de forma que un disco de

spare pueda servir para reemplazar un disco de cualquier

raid-group de la misma tecnología.

2.7.1.21 (√) Ante fallos de discos o posible fallos futuros en un disco, el

sistema debe reemplazarlo de forma proactiva por el mas

equivalente que encuentre que se parezca al que presenta el

problema.

2.7.1.22 (√) Debe ofrecer intercambio de componentes, disco y

bandejas, en caliente, es decir, sin interrupción del

funcionamiento del sistema.

2.7.1.23 (√) Actualización de firmware sin disrupción del sistema.

2.7.1.24 (√) Consistencia de la información ante caídas. En caso de

fallo total de la corriente eléctrica el sistema de

almacenamiento deberá disponer de un mecanismo que

asegure la consistencia de la información.

Funcionalidad







Pág. 94 de 134



Exp.054/16-AE

2.7.1.25 (√) Capacidad de reorganizar los discos en caliente,

pudiéndose extraer estos y reubicarlos en nuevas bandejas,

todo ello sin pérdida de capacidad de servicio, siempre y

cuando el tipo de RAID configurado lo permita.

2.7.1.26 (√) El sistema debe tener la capacidad de clonado y

snapshots. Deberá permitir al menos 255 snapshots o clones

por cada volumen minimizando el impacto sobre el

rendimiento y baja ocupación de disco.

2.7.1.27 (√) El sistema incorporará la funcionalidad de Thin

Provisioning.

2.7.1.28 (√) El sistema tiene que ofrecer una consola de gestión única

en modo gráfico que permita la gestión del sistema de

almacenamiento desde un solo punto.

2.7.1.29 (√) Debe ofrecer herramientas gráficas de monitorización,

rendimiento, alarmas y generación de informes que permitan

conocer el estado de funcionamiento global y en detalle del

sistema.

Software







Pág. 95 de 134



Exp.054/16-AE

2.7.1.30 (√) Debe incluir todas las licencias de software y firmware

necesarias para cubrir todas las funcionalidades solicitadas

en este apartado, compatible además con los elementos HW y

SW de la infraestructura existente (ver aparado 1.3.4) así

como con los nuevos elementos suministrados en el presente

pliego destinados al CPD Municipal.






componente dentro de la infraestructura existente descrita

en el apartado 1.3.4.







En el contexto del presente componente se define y considera:

1 KB 1024 Bytes

1 MB 1024 KB

1 GB 1024 MB

1 TB 1024 GB

1 PB 1024 TB

1 U 44,45 mm de altura (1,75”)







Pág. 96 de 134



Exp.054/16-AE

Asimismo, Terabyte (TB) neto se entiende y considera como Tebibyte

(TiB) neto en RAID 5 (4+1), sin incluir para su cálculo los discos de paridad

de raid group ni discos de spare. Esta definición se establece como unidad

de medida, con independencia del tipo de RAID que se decida finalmente

configurar e implantar durante el transcurso de los trabajos.

2.8 COMPONENTE 7: SUMINISTRO DEL MÓDULO LAN

2.8.1.1 (√) Este componente contempla el suministro de un módulo

LAN de expansión para ampliación de CISCO CATALYST

4510R+E existente en el CPD Municipal, descrito en el

apartado 1.3.4, donde se centraliza la LAN del Ayuntamiento.

Deberá integrarse y presentar total compatibilidad con este

elemento así como con los restantes descritos en el apartado

1.3.4 y los nuevos ofertados.

Características de cada unidad de módulo LAN

2.8.1.2 (√) 48 puertos PoE 10/100/1000 RJ45 (de 60W a 1440W por

puerto) con estas características:

Medios de conectividad:

Trenzado par 10/100/1000Base-T

Velocidad de transferencia de datos:

10 Mbps/ 100 Mbps Fast Ethernet y 1 Gbps Gigabit Ethernet

Dimensiones: 1.20 ' ' Altura x 14,25 ' ' ancho x 10.75 ' ' profundidad

Información adicional:

L2-4 Jumbo Frame compatible (hasta 9216 bytes) Soporte hasta 30W de PoE por puerto

Compatibilidad: Switches Cisco Catalyst 4500 Series







Pág. 97 de 134



Exp.054/16-AE

2.8.1.3 (√) Energy Efficient Ethernet 802.3az

El adjudicatario deberá, asimismo, y como parte de este componente:

2.8.1.4 (√) Suministrar:

4 módulos de patch-pannel de 24 puertos RF45H de 1U

48 latiguillos RJ45M de 2 m Y 48 de 3 m

500 m de cable UTP Cat 6 para interconectar módulos patch

de servidores con módulo patch del bastidor del CISCO

CATALYST 4510R+E

2.8.1.5 (√) Todos los elementos de conexionado y cables adicionales

que sean necesarios, en número suficiente para cumplir con

los requisitos de este pliego, que garanticen el conexionado e


componente con las redes e infraestructura existente

descritas en el apartado 1.3.4.







2.9 COMPONENTE 8: SUMINISTRO DE LICENCIAS DE SISTEMA

OPERATIVO

2.9.1.1 (√) Este componente contempla el suministro de licencias

de uso de sistema operativo multiventana 64bits para

servidores x86. Se deberán suministrar licencias,

destinadas a los servidores suministrados en el

Componente 5. La cantidad de licencias a suministrar es







Pág. 98 de 134



Exp.054/16-AE

la especificada en el apartado 5.2.2 para este componte,

y cada una de ellas deberá presentar las siguientes

características:

o Debe permitir la ejecución de un número ilimitado de

máquinas virtuales en hasta 2 procesadores sin

necesidad de adquirir licencias adicionales a las

suministradas en este pliego.

o Debe permitir crear y administrar un entorno

informático virtualizado mediante la tecnología de

virtualización integrada en el propio SO.

o Debe incluir los siguientes servicios:

Plataforma de aplicación/web: plataforma de

servicios y aplicaciones web.

Virtualización: plataforma de virtualización.

Servicio de escritorio remoto: habilitar conexión

vía https para administración remota haciendo

no necesario el establecimiento de una VPN.

Gestión remota y del consumo energético:

Gestión remota gráfica y mediante scripts.

Analizador de mejores prácticas para cada uno

de los servicios del sistema para que ayude a

preestablecer tareas de configuración.

Clasificación de la información: Infraestructura

de clasificación de ficheros.

Servicio de directorio que permita gestionar

usuarios, grupos, servidores, impresoras,

aplicaciones de forma segura y centralizada.

Plataforma de gestión derechos digitales

(Information Rights Management - IRM):

Plataforma de gestión de derechos digitales que







Pág. 99 de 134



Exp.054/16-AE

permite no sólo cifrar la información digital sino

también establecer los derechos de cada una de

las identidades sobre la misma.

Plataforma de federación.

Plataforma PKI.


suministro y entrega de las licencias solicitadas en la

ubicación o ubicaciones finales que Red.es designe




2.10 COMPONENTE 9: INSTALACIÓN, PUESTA EN MARCHA Y

CAPACITACIÓN DE LOS COMPONENTES 5, 6, 7 Y 8

Este componente comprende la instalación, configuración e integración de

todos los elementos hardware y software suministrados (ver apartado 2.1.8

Entregas y aceptación) de forma integrada con la infraestructura preexistente

(ver apartado 1.3.4).

2.10.1.1 (√) Incluye las siguientes actuaciones:

o Instalación de todos los elementos entregados

conformando una infraestructura de alta disponibilidad

física entre los servidores ofertados y los sistemas de

almacenamiento integrada con la infraestructura

existente actualmente en el Ayuntamiento. La parada

de un servidor o sistema de almacenamiento no debe

producir una parada de servicio, como mucho, un

microcorte del mismo para la transición entre

servidores físicos.

o Conexionado, instalación/actualización de firmware,

configuración e integración de todos los elementos

entregados con la infraestructura existente.







Pág. 100 de 134



Exp.054/16-AE

o Todos los trabajos necesarios para instalar, cablear e

interconectar los módulos patch entre bastidores

servidores con CISCO CATALYST 4510R+E.

o Desembalaje, ensamblado de todos los elementos

hardware suministrados en los Componente 5, 6, 7 y 8,

así como el anclaje de los sistemas de almacenamiento

y chasis.

o Retirada del embalaje y material sobrante del CPD

o Instalación física del conjunto hardware y software de

cualquier dispositivo incluido en su oferta, en la

infraestructura de los CPD del Ayuntamiento.

Conexionado y etiquetado de todo el conjunto.

Actualización del software y firmware de las cabinas y

de la virtualización del almacenamiento a sus últimas

revisiones.

o Configuración de cada cabina a nivel lógico que permita

su integración con el entorno de explotación de los

sistemas del Ayuntamiento. El sistema una vez

instalado debe soportar como mínimo el fallo de dos

discos simultáneamente, garantizando la consistencia

de la información.

o Pruebas de verificación de la instalación y montajes

efectuados. El protocolo de pruebas debe incluir,

además de aquellos otros aspectos que proponga el

licitador, los siguientes:

Correcto encendido y apagado de los equipos.

Verificación de la escritura y lectura de datos en

la plataforma.

Verificación de las funcionalidades y

características requeridas así como de las

ofertadas adicionalmente.







Pág. 101 de 134



Exp.054/16-AE

o Pruebas de integración y funcionamiento en real de las

cabinas en el entorno descrito.

o El transporte desde el lugar de suministro a lugar de la

instalación correrá a cargo del adjudicatario.





Capacitación

2.10.1.3 (√) El adjudicatario deberá llevar a cabo la capacitación

presencial de un máximo de 5 personas del Ayuntamiento de

Toledo, que se encargarán de la futura administración y

operación de los componentes 5, 6 y 7 objeto de la presente

licitación.

2.10.1.4 (√) Los cursos se llevaran a cabo con una duración total de,

como mínimo, 20 horas impartidas en varias sesiones.

2.10.1.5 (√) El objetivo es efectuar una capacitación teórica y práctica

de todo aquello que comprende la operación, administración,

configuración, gestión, monitorización, etc. de los elementos

hardware y software incorporados sobre la infraestructura

actual como resultado de la ejecución del contrato, así como

la entrega de la documentación asociada a la formación en

formato electrónico (PDF, RTF o similar). Adicionalmente,

podrán ser solicitadas copias en papel, de toda o parte de la

documentación, destinadas a los alumnos que participen en

las sesiones de capacitación.

2.10.1.6 (√) El adjudicatario se encargará de elaborar y entregar toda

la documentación de los cursos de capacitación en castellano.

Podrán ser admitidos como documentos de apoyo manuales

proporcionados por los fabricantes o propietarios de los







Pág. 102 de 134



Exp.054/16-AE

productos en inglés pero, únicamente, en aquellos casos en

que dichos manuales o documentos no existan traducidos al

castellano. En cualquier caso, dicha documentación será

considerada de apoyo, correspondiendo al adjudicatario la

elaboración de la documentación específica de los cursos a

impartir.

2.10.1.7 (√) Teniendo presente que esta capacitación persigue

maximizar el grado de autonomía de los administradores y

operadores, el adjudicatario deberá elaborar un Plan de

Capacitación con la agenda, detalle de los cursos y lugar de

impartición, que será en las instalaciones del Ayuntamiento

de Toledo, y que habrá de ser validado por Red.es con

carácter previo a su impartición.

2.10.1.8 El adjudicatario deberá generar las Actas de Capacitación por

cada una de las sesiones realizadas, siguiendo las

indicaciones de Red.es. Deberán ser remitidas a Red.es,

correctamente cumplimentadas y con la firma de los

asistentes y el responsable de la capacitación o formador.

2.11 COMPONENTE 10: SUMINISTRO E INSTALACIÓN DE UN

ESCÁNER PARA EL ARCHIVO MUNICIPAL

2.11.1.1 (√) Este componente contempla el suministro de un escáner

con las siguientes funcionalidades y características mínimas:

Captura cenital de imágenes para la

digitalización de bienes del patrimonio

bibliográfico y documental.

Formato máximo admitido de originales de DIN

A2 (apaisado).

Dotado de balanza prensalibros y “prensa” de

cristal con ajuste de presión, de funcionamiento

manual o semiautomático. Este sistema permite

una manipulación cuidadosa y respetuosa con







Pág. 103 de 134



Exp.054/16-AE

los bienes del patrimonio (documentos) y

minimizando la posibilidad de deterioro de los

documentos.

Rango de trabajo: Color RGB (24 bit por pixel).

Igualmente debe permitir la captura directa en

escala de grises (8 bit por píxel).

Resolución óptica mínima de 400 dpi en formato

A2 1:1 sobre todo el área del documento original.

Funcionamiento como cámara–escáner digital

autónomo. Que no dependa de equipación

externa suplementaria para ser totalmente

operativo. (PC, Monitor).

Monitor en columna/integrado no inferior a 17 “

Full HD para la previsualización del documento

en tiempo real.

Formatos de salida de fichero, como mínimo,

Tiff, Jpeg, Pdf.

Requerimientos de iluminación: Luz sin emisión

de radiación IR/UV y/o ausencia de iluminación

auxiliar (para trabajos en entornos donde se

requieran dichas características).

Ajustes automatizados, tanto de foco como de

color (balance automático de blancos y negros

con corrección de gamma) y tiempo de

exposición.

Detección automática del formato de la

documentación a digitalizar con ajuste del área

de digitalización.

Sistema de reconocimiento de formas que

discrimine automáticamente el área de tablero

ajena al documento.







Pág. 104 de 134



Exp.054/16-AE

Previsualización en tiempo real del documento.

Posibilidad de trabajo por separación de páginas

(izquierda y/o derecha individualizada, partición,

izquierda y/o derecha a partir de la misma toma

o en conjunto, fotograma completo).

Incorporación de metadatos para que queden

vinculados a la imagen (que el fichero tenga

unos campos que permitan saber la procedencia,

el archivo y copyright del documento con

independencia de los datos técnicos intrínsecos)

Posibilidad de conexión a impresora para la

obtención de copias; posibilidad de obtención de

imagen en bruto (imagen RAW) y posibilidad de

obtención de imagen tratada para su

optimización (aplicación de filtros), tanto de

forma individualizada como en conjunto

(aplicación simultánea de las tres formas de

trabajo).

Software incorporado para la optimización y

corrección de las imágenes digitales en tiempo

real (enderezamiento, eliminación de dedos,

etc.).

Este escáner debe ser de fácil montaje y

desmontaje para su transporte, para permitir

asignarlo a las distintas oficinas en función de

los planes de trabajo establecidos y en función

de las prioridades que se estimen oportunas.

Opcionalmente, permitirá incorporación perfiles

ICC para la adecuada reproducción del color.

Posibilidad de conexión remota del escáner a

través de Internet o de la Intranet corporativa

del Ayuntamiento (Facilita la las tareas de

configuración y de resolución de averías.).







Pág. 105 de 134



Exp.054/16-AE

Capacidad de comunicación directa del escáner

con ordenadores personales, discos duros

externos, entornos de red y/o envío de ficheros

a direcciones IP.

Opcionalmente, podrá tener un disparador de pie

(pedal) para facilitar la captura.






componente dentro del Archivo Municipal.

2.11.1.3 (√) La instalación y puesta en marcha del escáner deberá

efectuarse en las instalaciones ubicadas en el Archivo

Municipal situado en el edificio del Archivo Municipal situado

en la calle Trinidad c/v Plaza del Salvador de Toledo, e incluye

las siguientes actuaciones:

Instalación de todos los elementos entregados.

Conexionado, instalación/actualización de

firmware, configuración e integración de todos

los elementos entregados con la infraestructura

existente, básicamente, ordenadores personales

con sistemas operativos Microsoft Windows 7 y

8 y directorio activo basado en Microsoft

Windows Server 2012.

Pruebas de verificación de la instalación,

configuración y montajes efectuados.







Pág. 106 de 134



Exp.054/16-AE











Pág. 107 de 134



Exp.054/16-AE

3 REQUISITOS DE LA IMPLANTACIÓN La implantación consiste en la realización de todos los trabajos indicados en

cada uno de los componentes descritos en el apartado REQUISITOS TÉCNICOS2

incluyendo la realización de las pruebas necesarias para asegurar su correcta

ejecución, la capacitación en aquellos que hubiera sido requerida así como las

prestaciones y entrega de la documentación asociada.

El adjudicatario deberá disponer de todas las herramientas, aparatos,

equipos de medida y otros materiales, así como del personal técnico adecuado con

la preparación y experiencia necesarias para llevar a cabo todas las tareas

requeridas para la ejecución del contrato.

3.1 Requisitos generales de suministro

Como parte de cualquier servicio de suministro requerido como parte de los

trabajos solicitados en el presente pliego o lo adicionalmente ofertado, el

adjudicatario deberá:

3.1.1.1 (√) Cumplir los requisitos mínimos aplicables a los servicios de

suministro indicados, a continuación, en el apartado 3.1.2, si

se tratase de elementos hardware, y/o en el apartado 3.1.3, si

se tratase de productos software.

3.1.1.2 (√) Cumplimentar un Acta de Suministro que deberá

acompañar al hardware y/o productos software suministrados

en el momento de la entrega para su verificación y posterior

firma por parte del responsable de la ubicación y del propio

adjudicatario. Una vez firmada el Acta de Suministro deberá

ser remitida a Red.es.

3.1.1.3 (√) Proceder al inventariado de los elementos conforme a las

condiciones establecidas en el apartado 2.1.5.







Pág. 108 de 134



Exp.054/16-AE

3.1.2 HARDWARE

3.1.2.1 (√) Requisitos de embalaje:

El embalaje posibilitará una perfecta protección durante todo

el proceso de transporte y almacenaje del material.

Deberán inmovilizarse interiormente aquellos bultos en los que

puedan producirse desplazamientos interiores de los

elementos.

Deberá minimizarse el volumen y peso de los bultos

resultantes. En cuanto la forma, se tendrá en cuenta la

facilidad de apilamiento.

Todo el material del embalaje deberá ser depositado en un

punto destinado a tal efecto, bien sea del propio centro

destinatario o no.



ubicaciones finales que Red.es designe, conforme a los plazos

que hubieran sido establecidos para dichos trabajos en el

apartado 3.4 Plazos.

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

componentes y elementos de conexionado deberán ser

nuevos. No será posible reutilizar ni equipos ni componentes

reparados.

3.1.2.4 (√) Los equipos deberán ir serigrafiados e identificados tal y

como se indica en el apartado 2.1.3 del presente Pliego.

3.1.3 PRODUCTOS SOFTWARE

3.1.3.1 (√) El suministrador deberá proporcionar cada producto

software requerido y/o ofertado a través de aquellos medios

físicos o mecanismos que, a criterio de Red.es, mejor se

adecuen a las características del software a suministrar y sus

modos de distribución. En caso de existir varias alternativas







Pág. 109 de 134



Exp.054/16-AE

de suministro, el adjudicatario podrá plantear las mismas a

Red.es que determinará la finalmente aceptada.

3.1.3.2 (√) El suministrador deberá proporcionar toda la

documentación asociada a cada producto software

suministrado, como mínimo, el manual de instalación y

administración del producto.

3.2 Requisitos generales de instalación

Como parte de cualquier servicio de instalación requerido dentro de los

trabajos solicitados en el presente pliego o lo adicionalmente ofertado, el

adjudicatario:







Pág. 110 de 134



Exp.054/16-AE

3.2.1.1 (√) Antes del inicio de cualquier instalación, elaborará un Plan

de Implantación que deberá ser aprobado por Red.es. En

dicho plan deberá garantizarse que los servicios que se

estuvieran prestando actualmente y pudieran verse afectados

como consecuencia de los trabajos de instalación a acometer,

no queden sin cubrir en ningún momento, salvo los periodos

de paradas programadas que se establezcan de acuerdo con

Red.es y los técnicos del ayuntamiento.

3.2.1.2 (√) Deberá cumplir con los requisitos mínimos aplicables a los

servicios de instalación indicados a continuación en el

apartado 3.2.2, si se tratase de elementos hardware, y/o en el

apartado 3.2.3, si se tratase de productos software.

3.2.1.3 (√) Deberá cumplimentar el Acta de Instalación

correctamente cumplimentada y asociada a cada una de los

trabajos que habrá de entregar para su verificación y

posterior firma por parte del responsable autorizado en el

beneficiario y del propio adjudicatario. Una vez firmada el

Acta de Instalación deberá ser remitida a Red.es.

3.2.1.4 (√) Deberá proceder al inventariado de los elementos

conforme a las condiciones establecidas en el apartado 2.1.5.

3.2.2 HARDWARE

Desembalaje, ensamblado de todos los componentes internos,

anclaje, si procede, en el armario y/o el chasis

suministrado/existente y entrega de los elementos auxiliares

que corresponda para su puesta en servicio (soportes del

software de base, licencias,…).

Actualización de firmware o cualquier microcódigo de todos

los componentes hardware ofertados, en caso de que así se

requiera.







Pág. 111 de 134



Exp.054/16-AE

Los elementos de conexionado (cables de pares y fibra) serán

suministrados por el adjudicatario en número suficiente para

cumplir con los requisitos de este documento.

Suministro de cualquier hardware o software adicional a que

obligue la solución propuesta por el licitador.

Instalación física y configuración del conjunto hardware en

cada ubicación especificada incluyendo, si así se requiere, su

enracado y conexionado a las diferentes redes.

A petición del responsable del CPD o lugar donde se instalen

los equipos, y siempre que haya acometida eléctrica, se

procederá a comprobar el encendido de los equipos.

Pruebas de verificación de la instalación y montajes

efectuados.

Transferencia de conocimiento del hardware y software

suministrado.

Actualización y entrega del Manual de instalación y

administración de los elementos instalados.

Y adicionalmente aquellas tareas que se consideren

necesarias para que los diferentes elementos queden

plenamente operativos y en explotación.

3.2.3 PRODUCTOS SOFTWARE

Instalación física y configuración del software sobre la

infraestructura, sistemas y entornos correspondientes.

Actualización y entrega del Manual de instalación y

administración de los elementos instalados.

Pruebas de verificación de la instalación.

Transferencia de conocimiento del software suministrado.







Pág. 112 de 134



Exp.054/16-AE

3.3 Requisitos generales aplicables a las pruebas

Para la realización de las pruebas necesarias para asegurar la correcta

ejecución de los trabajos del presente pliego o lo adicionalmente ofertado, el

adjudicatario deberá:

3.3.1.1 (√) Elaborar un Plan de Pruebas específico que permita

verificar el cumplimiento de los requerimientos solicitados y

ofertados para cada Componente (total o parcial) a probar.

Dicho Plan deberá ser aprobado por Red.es y por el

Ayuntamiento de Toledo con carácter previo al inicio de las

mismas.

3.3.1.2 (√) El plan deberá prever y garantizar que los servicios que se

están prestando actualmente no se vean afectados por el

desarrollo de las pruebas, salvo, si fuese imprescindible, en

aquellos periodos que se establezcan de acuerdo con Red.es y

los técnicos del Ayuntamiento.

3.3.1.3 (√) El Plan de Pruebas deberá permitir verificar el correcto

funcionamiento e integración de todos los elementos

(hardware, productos software y/o desarrollos software)

objeto de prueba, tanto desde el punto de vista individual,

como desde el punto de vista de integración de la solución. La

propuesta incluirá un conjunto de casos de prueba que

contendrán al menos los siguientes apartados:

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 esperado del caso

El resultado obtenido del caso

3.3.1.4 (√) Tras la ejecución de las pruebas, el adjudicatario entregará

un Informe de Resultados de las Pruebas en el que se







Pág. 113 de 134



Exp.054/16-AE

especifiquen los resultados de las pruebas realizadas, con una

estructura acorde al plan de pruebas acordado. Las pruebas

podrán darse por finalizadas una vez evidencien la ejecución

exitosa de las mismas.

3.3.1.5 (√) Red.es se reserva el derecho de no ejecutar alguna de las

pruebas incluidas en el plan 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 el plan de pruebas.

3.3.1.6 (√) Para la realización de las pruebas el adjudicatario deberá

utilizar equipamiento de medición y personal propio sin que

ello pueda representar coste adicional alguno para el

proyecto.

3.4 Plazos

Los plazos descritos a continuación finalizan a la aceptación por parte de

Red.es de los trabajos solicitados en cada caso. El adjudicatario deberá tener en

cuenta que los plazos incluyen que los entregables hayan sido validados por los

técnicos de Red.es (o los que la Entidad determine) que indicarán expresamente su

aprobación o, en su defecto, las deficiencias encontradas, deficiencias que deberán

ser subsanadas en el menor tiempo posible. Incluyen así mismo 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.

3.4.1.1 (√) Plazo de ejecución global. El plazo máximo para completar

la ejecución de los trabajos definidos para los Componentes 1,

2 y 3, descritos en los apartados 2.2, 2.3 y 2.4, del presente

Pliego, será de 10 meses a contar desde la fecha de inicio del

contrato .

3.4.1.2 (√) Plazo de ejecución EDUROAM. El plazo máximo para

completar la ejecución de los trabajos definidos para el

Componente 4, descrito en el apartado 2.5, del presente







Pág. 114 de 134



Exp.054/16-AE

Pliego, será de 120 días naturales a contar desde la emisión

del correspondiente pedido por parte de Red.es.

3.4.1.3 (√) Plazo de ejecución del equipamiento hardware del CPD. El

plazo máximo para completar la ejecución de los trabajos

definidos en los Componente 5, 6, 7 y 8, descritos en los

apartado 2.6, 2.7, 2.8 y 2.9, será de 60 días naturales a

contar desde la emisión del correspondiente pedido por parte

de Red.es.

3.4.1.4 (√) Plazo de ejecución del Componente 9: El plazo máximo

para completar la ejecución de los trabajos definidos en el




3.4.1.5 (√) Plazo de ejecución del Componente 10. El plazo máximo

para completar la ejecución de los trabajos definidos en el




3.4.1.6 (√) Tiempo máximo de registro de datos de inventario

asociados a cada Acta de Suministro o Acta de Instalación. El

plazo máximo para registrar en la herramienta de gestión de

activos de Red.es, tal y como se define en el apartado 2.1.5.3,

la información de activos suministrados e instalados es de 1

semana a contar desde la fecha de suministro reflejada en el

Acta de Suministro correspondiente, para el caso de

suministro, o a contar desde la fecha de instalación reflejada

en el Acta de Instalación correspondiente, para la fase de

instalación.

En el caso de encontrarse errores en el registro de los datos,

el adjudicatario deberá subsanarlo en un plazo máximo de 2

días desde la notificación o rechazo del activo.







Pág. 115 de 134



Exp.054/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.5 Requisitos de Garantía

3.5.1 DECLARACIÓN DE GARANTÍA

La contratación del suministro y prestaciones para la implantación de los

activos (hardware o software) 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.

Adicionalmente, para los servicios de configuración se exige, como mínimo,

una garantía de 3 meses tras la aceptación de los sistemas por parte de Red.es,

para corregir los posibles problemas que pudieran surgir tras su ejecución.

3.5.2 GARANTÍA SOBRE EL SOFTWARE OFERTADO

El adjudicatario deberá garantizar el software ofertado y suministrado en el

marco de este proyecto y efectuar las configuraciones que precise para su

correcta instalación y funcionamiento en el entorno tecnológico del Ayuntamiento

descrito en el apartado 1.3, durante un periodo de DOS (2) años a partir de la

aceptación del suministro por parte de Red.es, a excepción de las herramientas

software descritas y solicitadas en el apartado 2.2.2 cuya garantía deberá

ser, tal y como se señala en dicho apartado, de CINCO (5) años.

Durante el periodo garantía, el adjudicatario:

Garantizará la disponibilidad, sin coste adicional, de nuevas

actualizaciones principales (nuevas releases y versiones, parches o

alertas de seguridad) en un plazo máximo de tres (3) meses a partir

de su liberación por el fabricante. Las actualizaciones principales

incluirán tanto los productos como la documentación asociada. El

adjudicatario deberá proporcionar estas nuevas actualizaciones en







Pág. 116 de 134



Exp.054/16-AE

cualquiera de las plataformas para las que esté disponible el

producto.

Atenderá dudas o cuestiones relativas a la instalación o

configuración.

Resolverá incidencias detectadas en los productos suministrados.

El adjudicatario deberá entregar toda la documentación en castellano salvo

que no exista documentación oficial disponible en este idioma, en cuyo caso, podrá

entregar la documentación en inglés acompañando la misma de un breve manual

en castellano con todas las instrucciones esenciales para poder ejecutar la

actualización y conocer su alcance y efectos; dicho manual habrá de ser revisado y

aprobado por Red.es y el Ayuntamiento.

3.5.3 GARANTÍA SOBRE LOS TRABAJOS DE DESARROLLO

El adjudicatario deberá garantizar el resultado de los desarrollos e

integraciones realizados en el marco del presente contrato por un período de UN

(1) año. Este plazo se iniciará con la aceptación por parte del Director Técnico de

Red.es de la totalidad de los trabajos realizados.

3.5.4 GARANTÍA SOBRE EL HARDWARE OFERTADO

El adjudicatario estará obligado a prestar un servicio de garantía para todo

el hardware ofertado y los servicios asociados durante un periodo de CINCO (5)

AÑOS (atendiendo a las obligaciones FEDER). La fecha de inicio del servicio de

garantía comenzará a partir 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 en su

ubicación final. Excepcionalmente, y cuando por causas ajenas al adjudicatario, la

instalación y configuración se distancie del suministro, la fecha de inicio de

garantía del equipamiento se entenderá en los 60 días naturales siguientes al de la

fecha de aceptación del suministro.

Durante este periodo el adjudicatario:

Llevará a cabo la actuación en el lugar en el que esté instalado el

elemento.







Pág. 117 de 134



Exp.054/16-AE

El adjudicatario será responsable de los elementos objeto de la gestión

de garantía in situ, y en caso de que se produzca cualquier incidencia en

relación a los mismos deberá articular los mecanismos que sean

necesarios para su resolución de la forma siguiente:

o Utilización de stock existente para la sustitución de los

elementos averiados o defectuosos. El adjudicatario dispondrá de

un stock mínimo de materiales que le permita garantizar el

cumplimiento de los tiempos máximos de resolución de

incidencias según se indica en el apartado 3.5.6.

o Sustitución del elemento averiado por otro de iguales o

superiores características hasta que se haya producido la

reparación del elemento averiado.

o El adjudicatario deberá mantener operativos los equipos en todo

momento cualquiera que sea la incidencia acontecida.

o El adjudicatario estará en disposición de recibir comunicaciones

de avería o incidencias y de prestar un servicio atención de las

mismas con una disponibilidad de lunes a viernes de 9:00 a 18:00

horas. Este procedimiento contemplará, al menos, la apertura de

incidencias a través de vía telefónica o mail.

o En cuanto al software integrado en el hardware, el adjudicatario

deberá proporcionar el derecho de actualización a nuevas

versiones del producto y la disponibilidad de parches y revisiones

menores, siempre y cuando sea necesario, en cualquiera de las

plataformas para las que esté disponible el producto.

El adjudicatario debe garantizar la adecuada integración de sus servicios

de atención técnica con los servicios de atención técnica indicados por

Red.es.

3.5.5 COBERTURA DE LA GARANTÍA

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 componentes







Pág. 118 de 134



Exp.054/16-AE

suministrados y cualquier trabajo y prestación que el adjudicatario haya realizado

como parte del contrato.

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, de lunes a viernes de

9:00 a 18:00 horas, a través de teléfono o 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 los componentes suministrados y en los trabajos

realizados, incluyendo su diagnóstico y su corrección mediante sustitución o

reparación del componente 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.

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.

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.







Pág. 119 de 134



Exp.054/16-AE

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

Día y hora de resolución de la avería

Tiempo de respuesta

Tiempo 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

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







Pág. 120 de 134



Exp.054/16-AE

Ubicación donde se produce la incidencia, cuando proceda

Identificación del elemento averiado, cuando proceda

Día y hora de resolución prevista

Tiempo de respuesta

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.5.6 TIEMPOS MÁXIMOS DE RESOLUCIÓN DE INCIDENCIAS

El adjudicatario deberá cumplir con el Acuerdo de Nivel de Servicio para la

gestión de la garantía establecida para las incidencias, en función de la prioridad

asignada.

El tiempo de resolución de una incidencia se define como el comprendido

entre el momento en que Red.es o quien ésta determine solicita la apertura de la

incidencia y el momento de su resolución, y se computarán en horario de lunes a

viernes de 09:00 a 18:00, salvo que se indique explícitamente otro cómputo.

Las incidencias se clasifican en tres 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:

Prioridad Tiempo Máximo de Resolución

Baja 24 horas

Media 16 horas

Alta 12 horas

1 - Alta

El incidente se debe atender a la mayor brevedad posible.

2 – Media







Pág. 121 de 134



Exp.054/16-AE

El incidente puede ser aplazado o está planificado lo suficientemente lejos

en el tiempo para permitir una respuesta sin pérdida de productividad.

3 – Baja

No existe una urgencia formal para atender la incidencia y el trabajo normal

puede continuar hasta la respuesta.

Una incidencia se cerrará cuando Red.es o quien ésta determine, haya

aceptado dicho cierre, lo que se dará cuando el servicio se haya restablecido y

estabilizado, y se haya informado a Red.es o a quien ésta designe.

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.5.7 PARÁMETROS DE MEDIDA PARA EL CÓMPUTO DE PENALIZACIONES

A efectos de no tener en cuenta en el cómputo la existencia de posibles

demoras no imputables al adjudicatario, bien a través del sistema de ticketing de

Red.es o bien a través de cualquier otra herramienta para la 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 por Red.es, se contemplan

estados de “parada de reloj” (p.ej. 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.

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.

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, lo que, en su caso será notificado con antelación al adjudicatario.







Pág. 122 de 134



Exp.054/16-AE

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 T máx)

óptimo X >= 90 %

no óptimo X < 90 %

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. 123 de 134



Exp.054/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 la comprobación de la información

introducida por el adjudicatario en la herramienta de inventario de Red.es:

Tras la finalización y aceptación del componente COMPONENTE 1:

PLATAFORMA DE CIUDAD INTELIGENTE: facturación

correspondiente al importe del Concepto P1 del Modelo de

Proposición Económica del apartado 5.2.2 del presente Pliego.


APLICACIÓN MÓVIL MUNICIPAL: facturación correspondiente al

importe del Concepto P2 del Modelo de Proposición Económica del

apartado 5.2.2 del presente Pliego.







Pág. 124 de 134



Exp.054/16-AE


PLANIFICADOR DE RUTAS INTERMODAL: facturación




EXTENSIÓN EDUROAM: facturación correspondiente al importe del

Concepto P4 del Modelo de Proposición Económica del apartado

5.2.2 del presente Pliego.


SUMINISTRO DE SERVIDORES: facturación correspondiente al




SUMINISTRO DE SISTEMAS DE ALMACENAMIENTO: facturación




SUMINISTRO DEL MÓDULO LAN: facturación correspondiente al




SUMINISTRO DE LICENCIAS DE SISTEMA OPERATIVO: facturación




INSTALACIÓN, PUESTA EN MARCHA Y CAPACITACIÓN DE LOS

COMPONENTES 5, 6, 7 Y 8: facturación correspondiente al importe

del Concepto P9 del Modelo de Proposición Económica del apartado

5.2.2 del presente Pliego.


SUMINISTRO E INSTALACIÓN DE UN ESCÁNER PARA EL ARCHIVO

MUNICIPAL: facturación correspondiente al importe del Concepto







Pág. 125 de 134



Exp.054/16-AE

P10 del Modelo de Proposición Económica del apartado 5.2.2 del

presente Pliego.







Pág. 126 de 134



Exp.054/16-AE

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.

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.

La presentación de propuestas deberá cumplir las prescripciones del Pliego

de Condiciones Particulares. Adicionalmente, la propuesta relativa a los criterios

cuya valoración depende de un juicio de valor y de los criterios cuantificables

mediante la mera aplicación de fórmulas (Sobres 3 y 4 respectivamente)”) 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 3 “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 los sobres 1, 2 o 3 información de la

oferta que, de conformidad con el apartado siguiente, sea valorada de forma

cuantificable 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.







Pág. 127 de 134



Exp.054/16-AE

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:

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.

El licitador deberá incluir la información técnica relativa a los

componentes 5 y 6, (apartados, 2.6 y 2.7, del presente pliego), en

concreto:

Componente 5:

o Marca y modelo de los servidores







Pág. 128 de 134



Exp.054/16-AE

o Documentación técnica relativa a lo especificado en el

apartado 2.6.

Componente 6:

o Marca y modelo de los sistemas de almacenamiento

o Documentación técnica relativa a lo especificado en el

apartado 2.7.

Programa utilizado para el cálculo de rendimiento (Benchmark)

SPEC CPU2006, en el que se deberá aportar:

o En caso de que el modelo de procesador ofertado no tenga

este benchmark oficialmente publicado en la web de SPEC

(http://www.spec.org/cpu2006/results/rint2006.html), el

licitador deberá acreditar el método de cálculo utilizado

para determinar el SPECint_rate2006 presentado y cuyo

valor será vinculante.

o En caso de el servidor ofertado tenga publicada la

comparativa para un número superior a un procesador, se

podrá considerar el menor valor resultante de dividir cada

comparativa publicada del mismo servidor, entre el

número de procesadores de dicha comparativa.

Se recuerda que al aportar la documentación anteriormente referida el

licitador no deberá incluir en el presente sobre 3 información de la oferta que, de

conformidad con el apartado 5.2 Criterios Cuantificables mediante la mera

aplicación de fórmulas, sea valorada de forma cuantificable 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.

2. Requisitos valorables mediante juicio de valor

2.1 Propuesta de integración de los componentes y datos que intervienen en la plataforma de ciudad inteligente

El licitador deberá presentar una memoria de la plataforma de ciudad inteligente,

descrita en el apartado 2.2 detallando, al menos:







Pág. 129 de 134



Exp.054/16-AE

Arquitectura lógica propuesta, relación y dependencia operativas entre los

diferentes módulos propuestos.

Se deberá indicar además cómo se integra esta plataforma de ciudad inteligente

propuesta con la situación y entorno tecnológico que actualmente dispone el

Ayuntamiento de Toledo.

Este apartado se valorará de conformidad con lo establecido en el apartado 10.1 del


2.2 Propuesta de solución para la aplicación móvil municipal

El licitador deberá presentar una memoria de la aplicación móvil municipal,

descrita en el apartado 2.3 detallando, al menos:

Arquitectura lógica de la aplicación móvil propuesta. El licitador deberá

tener en cuenta en su propuesta que la información podrá estar accesible,

preferiblemente, desde el gestor del ayuntamiento descrito en el apartado

1.3.1 o, si fuera necesario, mediante aquel ofertado adicionalmente por el

adjudicatario como se indica en el punto 2.3.3.1 de este documento.

Flujos de información

Las funcionalidades del visor 3D y sus capacidades de navegación e

interacción con el espacio 3D y las técnicas de realidad virtual propuestas

Se deberá indicar además cómo se integra esta aplicación con la plataforma de

ciudad inteligente propuesta por el licitador y/o con la situación y entorno

tecnológico que actualmente dispone el Ayuntamiento de Toledo.



2.3 Propuesta de solución para el planificador de rutas intermodal

El licitador deberá presentar una memoria de las aplicaciones de cálculo de rutas

(móvil y web, descrita en los apartados 2.4) detallando, al menos:

La funcionalidad para el cálculo de rutas concretando cuáles son las

capacidades para construir rutas según el perfil del usuario y cómo va a

mostrar los resultados.

Las funcionalidades de navegación de la aplicación

Se deberá indicar además cómo se integra esta aplicación con la plataforma de

ciudad inteligente propuesta por el licitador y/o con la situación y entorno

tecnológico que actualmente dispone el Ayuntamiento de Toledo.







Pág. 130 de 134



Exp.054/16-AE



5.2 Propuesta relativa a los criterios cuantificables mediante la

mera aplicación de fórmulas (sobre 4“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.

P1: Precio unitario (impuestos indirectos aplicables excluidos) para el

Componente 1, Plataforma de Ciudad Inteligente, según lo descrito

en el apartado 2.2 del presente Pliego.

P2: Precio unitario (impuestos indirectos aplicables excluidos) para

el Componente 2, Aplicación Móvil Municipal, según lo descrito en el

apartado 2.3 del presente Pliego.


el Componente 3, Planificador de Rutas Intermodal, según lo descrito

en el apartado 2.4 del presente Pliego.







Pág. 131 de 134



Exp.054/16-AE


el Componente 4, Extensión Eduroam, según lo descrito en el



el suministro del Componente 5, Servidores, según lo descrito en el



el suministro del Componente 6, Sistemas de Almacenamiento,

según lo descrito en el apartado 2.7 del presente Pliego.


el suministro del Componente 7, Modulo LAN, según lo descrito en el



el suministro del Componente 8, Licencias del Sistema Operativo,

según lo descrito en el apartado 2.9 del presente Pliego.


el Componente 9, Instalación, puesta en marcha y capacitación de

los componentes 5, 6, 7 y 8, según lo descrito en el apartado 2.10 del

presente Pliego.


el suministro y la instalación del Componente 10, Escáner para el

Archivo Municipal, según lo descrito en el apartado 2.11 del

presente Pliego.

La fórmula que se establece para el cálculo del PRECIO DE OFERTA, es la

siguiente:

Precio Oferta (Pi) = P1 x 1 + P2 x 1 + P3 x 1 + P4 x 1 + P5 x 2 + P6 x 2 + P7 x

1 + P8 x 2 + P9 x 1 + P10 x 1

Los precios unitarios de la fórmula se corresponden con los hitos de

facturación especificados en el apartado 4.2 del presente Pliego.







Pág. 132 de 134



Exp.054/16-AE

El precio de la oferta (Pi) no podrá exceder la cantidad de QUINIENTOS

SESENTA Y OCHO MIL CIENTO SESENTA Y UNO CON SESENTA Y SEIS CENTIMOS

DE EURO (568.161,66 €), 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. 133 de 134



Exp.054/16-AE

5.2.2 MODELO DE PROPOSICIÓN ECONÓMICA

Apellidos, nombre y DNI del firmante de la proposición económica.

Relación que une al firmante con el licitador.

Razón social del licitador, NIF, domicilio, teléfono, fax y e-mail (del representante)

a) Tabla de desglose de los importes

Código Concepto CantidadPRECIO UNITARIO

(IVA excluido)

PRECIO TOTAL

(IVA excluido)

P1 Componente 1. Plataforma de Ciudad Inteligente 1 0,00 €

P2 Componente 2. Aplicación móvil municipal 1 0,00 €

P3 Componente 3. Planificador de rutas Intermodal 1 0,00 €

P4 Componente 4. Extensión Eduroam 1 0,00 €

P5 Componente 5. Servidores 2 0,00 €

P6 Componente 6. Sistemas de Almacenamiento 2 0,00 €

P7 Componente 7. Módulo LAN 1 0,00 €

P8 Componente 8. Licencias del sistema Operativo 2 0,00 €

P9Componente 9. Instalación, puesta en marcha

y capacitación de los componentes 5, 6, 7 y 81 0,00 €

P10 Componente 10.Escaner para el archivo municipal 1 0,00 €

0,00 €

Oferta aceptada

568.161,66 €

Firmado

El abajo firmante, en virtud de la representación que ostenta, se compromete, en nombre de su representado, a la ejecución del contrato de “DESARROLLO

DE LA INICIATIVA TOLEDO CIUDAD INTELIGENTE" Exp. 054/16-AE, en los términos establecidos en los pliegos y de conformidad con los precios referidos en

la tabla anterior con IMPUESTOS INDIRECTOS APLICABLES EXCLUIDOS

IMPORTE MÁXIMO DE LICITACIÓN (impuestos indirectos aplicables excluidos)

BASE IMPONIBLE (Pi) = P1 x 1 + P2 x 1 + P3 x 1 + P4 x 1 + P5 x 2 + P6 x 2 + P7 x 1 + P8 x 2 + P9 x

1 + P10 x 1

En [ ] a [ ] de [ ] de 2016

PROPOSICIÓN ECONÓMICA DE [razón social del licitador]

PARA LA REALIZACIÓN DE UN CONTRATO DE “DESARROLLO DE LA INICIATIVA TOLEDO CIUDAD INTELIGENTE" Exp. 054/16-AE







Pág. 134 de 134



Exp.054/16-AE

DANIEL NOGUERA TEJEDOR

DIRECTOR GENERAL DE LA ENTIDAD PÚBLICA EMPRESARIAL

FRANCISCO JAVIER GARCÍA VIEIRA

DIRECTOR DE SERVICIOS PÚBLICOS DIGITALES







PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA ... · Exp.054 /16-AE 1 INTRODUCCIÓN El...

Documents

Transcript of PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁN LA ... · Exp.054 /16-AE 1 INTRODUCCIÓN El...