Embed Size (px)
Citation preview
1
PLIEGO DE CLÁUSULAS TÉCNICAS QUE HAN DE
REGIR EN EL CONTRATO DE SERVICIOS PARA LA
ADAPTACIÓN DE LOS SISTEMAS CENTRALES DE LA
ITG A LA INTEROPERABILIDAD EN LA COMUNIDAD
AUTÓNOMA DE EUSKADI, A ADJUDICAR POR
PROCEDIMIENTO ABIERTO CON PLURALIDAD DE
CRITERIOS.
1. INTRODUCCIÓN y ANTECEDENTES
EL Gobierno Vasco lidera el proyecto para permitir el uso cruzado de las tarjetas
BAT, BARIK y MUGI en Araba, Bizkaia y Gipuzkoa. En dicho proyecto participan las
entidades responsables de la integración tarifaria y tarjetas de transporte BAT,
BARIK y MUGI, Euskotren y Diputación Foral de Araba (DFA) como representantes
de la futura Autoridad de Territorial de Transportes de Araba (ATTA), Consorcio de
Transportes de Bizkaia (CTB) y la Autoridad Territorial de Transportes de Gipuzkoa
(ATTG).
En Junio de 2013 se finalizó una primera fase que se culminó con la elaboración del
Masterplan BAT-BARIK que definía funcionalmente las reglas de operación del
marco de interoperabilidad BAT-BARIK y que valoraba en coste y plazo las acciones
a realizar en cada territorio para posibilitar el uso cruzado de ambas tarjetas en el
territorio invitado.
Como segunda fase, en Octubre 2013 se iniciaron los trabajos para incorporar a la
tarjeta MUGI de Gipuzkoa en este escenario de interoperabilidad, que finalizaron en
el primer semestre de 2014.
En paralelo y con objeto de dar un paso más hacia la consecución del objetivo
buscado, se acordó la puesta en marcha de tres proyectos piloto:
En Bizkaia: tranvía de Bilbao (operado por Euskotren)
2
En Araba: tranvía de Vitoria (operado por Euskotren)
Gipuzkoa: Dbus: (operador por la CTSS)
La implantación de los pilotos requiere la participación de todas las partes, tanto del
territorio donde se implanta cada piloto, como de los restantes territorios, cuyas
tarjetas podrán usarse como invitadas, empleando la seguridad correspondiente y
remitiendo la información a cada centro de compensación en el formato adecuado.
1.1. TARJETAS DE TRANSPORTE SIN CONTACTO
1.1.1. MUGI
La tarjeta MUGI es una tarjeta sin contacto (TSC) NXP Mifare Classic 1K que
contiene un monedero electrónico interno que permite descontar los viajes
realizados en cada modo de transporte según el tipo de servicio y recorrido
realizado.
El sistema MUGI está implantado en Euskotren, autobuses de Lurraldebus,
autobuses urbanos de Donostia, Errenteria, Irun, Arrasate, Hernani, Eibar y
Zarautz. Asimismo está RENFE en el cual se acepta MUGI sólo como medio de pago
para la obtención de un título propietario de RENFE.
La tarjeta y sus características técnicas están definidas en la correspondiente
documentación que dispone ATTG.
1.1.2. BAT
La tarjeta BAT es una Tarjeta Sin Contacto (TSC) con chip (NXP Mifare DESFire
D40 y EV1) empleada en el transporte urbano de Vitoria-Gasteiz, la cual permite
incluir títulos interoperables de transporte que pueden ser usados en el Tranvía
(Euskotran) y en los Autobuses Urbanos de Vitoria (Tuvisa). Por su parte, la
Diputación Foral de Alava (DFA) tiene previsto incorporar sus servicios de
transporte público (líneas regulares y servicio a la demanda) al sistema BAT a lo
largo del 2015. Esta tarjeta es emitida actualmente por Euskotren como Ente
Gestor de la BAT (EGB).
La tarjeta BAT tiene las dimensiones de una tarjeta de crédito, está fabricada en
material plástico y contiene un circuito integrado o chip y una antena.
La tarjeta y sus características técnicas están definidas en la correspondiente
documentación que dispone Euskotren, como actual Ente Gestor de la BAT (EGB).
3
1.1.3. BARIK
La tarjeta BARIK es la tarjeta sin contacto (TSC) emitida por el CTB que contiene
títulos de transporte que pueden ser usados en los diferentes modos de transporte
adheridos al sistema: Metro Bilbao, Euskotren, Tranvía de Bilbao, Bilbobus,
Bizkaibus, RENFE, autobuses urbanos de Erandio, Etxebarri y Barakaldo, Funicular
de Artxanda y de Larreineta, Puente Colgante, Ascensor de Ereaga y Bizimeta.
La tarjeta BARIK tiene las dimensiones de una tarjeta de crédito, está fabricada en
material plástico y contiene un circuito integrado o chip y una antena. El circuito
integrado se corresponde con el modelo NXP Mifare DESFire EV1 de 4K de NXP,
antes Phillips Semiconductors.
La tarjeta y sus características técnicas están definidas en la correspondiente
documentación que dispone CTB.
1.2. PILOTO DE TRANVÍA DE BILBAO
La puesta en servicio de la implantación de la interoperabilidad BAT-BARIK-MUGI
en el piloto del tranvía de Bilbao se realizó el 30 de Julio de 2014.
En el proyecto piloto del tranvía de Bilbao se realizaron algunas simplificaciones con
objeto de realizar su implantación en un tiempo razonable sin actuar sobre todos
los modos de transporte.
En este sentido, en el proyecto piloto de interoperabilidad en el tranvía de Bilbao
permite a los usuarios validar las tarjetas BAT y MUGI como medio de pago de los
viajes que realicen en el tranvía de Bilbao, manteniéndose la operativa y
funcionalidades que los usuarios disponen actualmente con su tarjeta BARIK.
Asimismo y con objeto de no permitir el uso de tarjetas fraudulentas, en el tranvía
de Bilbao se pueden bloquear tarjetas BAT y MUGI de modo equivalente a como se
realiza para tarjetas BARIK.
1.3. PILOTO DE TRANVÍA DE VITORIA
Actualmente se está trabajando en la implantación de la interoperabilidad BAT-
BARIK-MUGI en el piloto del tranvía de Vitoria, habiéndose realizado la puesta en
servicio de la interoperabilidad BAT-BARIK a finales del mes de Diciembre de 2014
y estando prevista la incorporación de MUGI a lo largo del primer semestre de
2015.
4
En el proyecto piloto del tranvía de Vitoria se han mantenido las simplificaciones
realizadas para el tranvía de Bilbao con objeto de realizar su implantación en un
tiempo razonable sin actuar sobre todos los modos de transporte.
En el proyecto piloto de interoperabilidad en el tranvía de Vitoria se va a permitir a
los usuarios validar las tarjetas BARIK y MUGI como medio de pago de los viajes
que realicen en el tranvía de Vitoria, manteniéndose la operativa y funcionalidades
que los usuarios disponen actualmente con su tarjeta BAT.
Asimismo y con objeto de no permitir el uso de tarjetas fraudulentas, en el tranvía
de Vitoria se podrán bloquear tarjetas BARIK y MUGI de modo equivalente a como
se realiza para tarjetas BAT.
1.4. PILOTO DBUS
Actualmente se está trabajando en las tareas administrativas previas cara a la
implantación de la interoperabilidad BAT-BARIK-MUGI en DBUS, estando prevista la
puesta en marcha de este proyecto para 2016
1.5. LÍNEA GENERAL DE EUSKOTREN
La Línea General de Euskotren recorre de forma continua los territorios de Bizkaia y
Gipuzkoa, lo que le convierte en un elemento de especial consideración en el marco
de la interoperabilidad BAT-BARIK-MUGI. Por ello, su operativa en condiciones de
interoperabilidad y su afección al resto de modos de Araba, Bizkaia y Gipuzkoa será
estudiada en detalle durante el primer cuatrimestre de 2015 para poder culminar
los trabajos de su puesta en marcha a finales de 2015.
5
2. COMUNICACIÓN ENTRE LOS SISTEMAS DE COMPENSACIÓN
ESCENARIO DE INTEROPERABILIDAD
La implantación de la interoperabilidad BAT-BARIK-MUGI va a suponer a nivel de
Centro de Compensación:
Recibir en el SAGB (Bizkaia):
o Validaciones, regularizaciones y bloqueos de tarjetas BARIK en los
operadores de Araba y Gipuzkoa
o Validaciones, regularizaciones y bloqueos de tarjetas BAT y MUGI en
Bizkaia
o La lista de bloqueo de tarjetas BAT y MUGI que se deberán ejecutar en
Bizkaia
Recibir en el CCBAT (Araba):
o Validaciones, regularizaciones y bloqueos de tarjetas BAT en los
operadores de Bizkaia y Gipuzkoa
o Validaciones, regularizaciones y bloqueos de tarjetas BARIK y MUGI en
Araba
o La lista de bloqueo de tarjetas BARIK y MUGI que se deberán ejecutar en
Araba
Recibir en el CCMUGI (Gipuzkoa):
o Validaciones, regularizaciones y bloqueos de tarjetas MUGI en los
operadores de Araba y Bizkaia
o Validaciones, regularizaciones y bloqueos de tarjetas BAT y BARIK en
Gipuzkoa
o La lista de bloqueo de tarjetas BARIK y BAT que se deberán ejecutar en
Gipuzkoa
6
3. MODELO DE RELACIÓN ENTRE CENTROS DE COMPENSACIÓN
El modelo acordado por su operatividad es el de mantener la relación entre los
operadores y el Centro de Compensación del mismo Territorio y establecer una
relación entre los Centros de Compensación de los 3 consorcios/autoridades, de
forma que no sea necesario establecer múltiples acuerdos y convenios cruzados
entre todos los agentes y las autoridades o consorcios de los otros territorios
históricos.
La siguiente figura recoge el esquema de interfaces entre los Centros de
Compensación:
4. Para la implementación de la interoperabilidad de las tarjetas BARIK BAT y
MUGI en cada Territorio serán necesarias una serie de modificaciones de los
sistemas Centrales de cada sistema. El presente documento detalla las
modificaciones necesarias en el sistema MUGI y que son objeto de este pliego.
7
5. OBJETO DEL PROYECTO
El objeto del presente proyecto es la puesta en marcha de las modificaciones
necesarias en los sistemas centrales de la Autoridad Territorial del Transporte de
Gipuzkoa (ATTG) para llevar a cabo la interoperabilidad de las tarjetas BARIK, BAT
y MUGI en los tres Territorios Históricos.
Para ello se describe en el presente documento la información necesaria a
almacenar e intercambiar entre los sistemas de los tres centros compensadores
actuales:
- Centro de compensación de la tarjeta MUGI (CC-MUGI)
- Sistema de Administración y Gestión BARIK (SAGB)
- Centro de compensación de la tarjeta BAT (CC BAT)
De igual forma el presente proyecto debe permitir la explotación de la información
necesaria en el marco de la interoperabilidad de las tarjetas BARIK, BAT y MUGI por
parte de la ATTG.
8
6. ALCANCE DE LOS TRABAJOS EN LOS SISTEMAS CENTRALES DE LA ATTG
El presente pliego detalla los trabajos necesarios a implementar para que los
sistemas centrales del sistema Mugi puedan tratar la información generada y la que
se generará en el marco de la interoperabilidad de las tarjetas Barik, Bat y Mugi.
- No están incluidos los desarrollos en los sistemas de validación de los
operadores del sistema Mugi, ni ninguno de sus sistemas centrales corporativos
de cada operador.
Las tareas que el contratista deberá desarrollar para llevar a cabo la correcta
implementación de la Adaptación de los Sistemas Centrales de la ATTG para la
interoperabilidad de las tarjetas sin contacto Bat, Barik y Mugi, son las siguientes:
Adaptación de los sistemas centrales de la ATTG:
Adquisición de equipamiento Hardware para la ampliación de los sistemas de
Monética y Compensación en la ATTG. Tanto desde un punto de vista de
mayor capacidad de proceso y rendimiento, así como de almacenamiento.
Almacenamiento de viajes realizados con tarjetas Barik y BAT en los
sistemas centrales de la ATTG: modificación de la Base de Datos de
Monética actual.
Modificación de la Base de Datos SAE actual (Sistema de ayuda a la
explotación de la DFG) para la parametrización de las nuevas entidades
correspondientes a las concesiones de los sistemas SAGB y CC BAT.
Modificación de la Base de Datos SICOT actual (sistema de distribución de
ingresos) para el tratamiento de validaciones Mugi en Territorios invitados y
BAT y Barik y validaciones BAT y Barik en Territorio Mugi.
Adaptación del intercambio de comunicación con otros Sistemas de Compensación:
Desarrollo de los canales de comunicación en la ATTG necesarios para la
comunicación con SAGB y CC BAT.
Generación de ficheros con información Barik y BAT para los sistemas SAGB
y CC BAT.
Recepción y tratamiento de ficheros con información Mugi desde los
sistemas SAGB y CC BAT.
Generación de Lista Negra Mugi para SAGB y CC BAT y tratamiento de
anulaciones realizadas.
9
Recepción y tratamiento de ficheros de Lista Negra Barik y BAT y envío de
anulaciones realizadas.
Adaptaciones de las aplicaciones y servicios actuales de la ATTG:
Modificación de los informes estadísticos actuales para la ATTG y la DFG.
Adaptación de los módulos de control de errores y fraude para tener en
cuenta las nuevas realidades del proyecto.
Adaptación de los Webservices de la ATTG:
o Servicio Web para el sistema de Atención al Usuario de la ATTG
o Servicio Web para el área privada de la página Web del Sistema Mugi
Modificación del proceso de exportación SAP de Euskotren y sistema de
réplicas de Euskotren y empresas del Grupo PESA.
Adaptación de la aplicación de Contrato Programa para la inclusión de las
nuevas modalidades de pago Bat y Barik.
Adaptaciones del Sistema de Distribución de ingresos:
o Inclusión de lógica de validación Barik y BAT en Gipuzkoa
o Inclusión de lógica de validaciones Mugi fuera de Gipuzkoa
Monitorización de ficheros y gestión de registros inválidos intercambiados.
Cada una de estas tareas, es desarrollada en los siguientes apartados del presente
pliego.
El siguiente esquema resume las mismas de forma no exhaustiva:
10
El licitador deberá asegurar y demostrar de forma objetiva en su propuesta, la
capacidad de actuación total sobre cada uno de los sistemas hardware y software
ya existentes en los sistemas centrales de la ATTG y sobre los que se solicitan las
adaptaciones y modificaciones necesarias para cumplir con el alcance del presente
pliego.
Como premisa general se debe observar que todas las modificaciones a realizar
para la implantación del nuevo sistema de tarificación deben ser completamente
compatibles con las funcionalidades específicas actuales, y en la memoria técnica se
debe describir cómo se va a garantizar dicha compatibilidad. Se debe asegurar la
integración de todas las modificaciones solicitadas en los sistemas actuales.
Por otro lado, se debe tener en cuenta que la implantación del nuevo sistema no
debe afectar a la normal explotación de las instalaciones existentes, debiéndose
garantizar la máxima operatividad de los sistemas de ticketing, sistemas de
información y compensación. El licitador describirá en detalle cómo garantizará
dicha operatividad.
11
6.1 Adquisición de equipamiento Hardware para la ampliación de los
sistemas de Monética y Compensación.
El licitador deberá realizar el análisis de dimensionamiento de los sistemas de
Monética y Compensación actuales del sistema Mugi para incorporar las
validaciones de Mugi en Araba y Bizkaia y las validaciones de Bat y Barik en
Gipuzkoa en los sistemas centrales de la ATTG, de forma que se garantice la
capacidad de proceso.
Producto de dicho análisis, el licitador deberá ampliar las máquinas actuales
para dicho objetivo. La instalación, configuración y puesta en marcha, serán
por cuenta del adjudicatario previa coordinación con la ATTG.
6.2 Almacenamiento de viajes realizados con tarjetas Barik y BAT en la
ATTG: Modificación de la Base de Datos de Monética actual.
El licitador deberá proponer las modificaciones necesarias en los sistemas de
monética de la ATTG para el almacenamiento de los datos de validaciones con
tarjetas BAT y Barik, de forma que los mismos puedan ser analizados,
explotados y exportados mediante las herramientas solicitadas en los apartados
siguientes del presente pliego.
Dichas modificaciones deberán permitir la incorporación de datos de validación
de tarjetas Barik y Bat de los siguientes modos de transporte:
- Lurraldebus (entrada / salida y venta asistida)
- EuskoTren Ferrocarril (entrada / salida)
- Compañía del Tranvía de San Sebastián (validación única)
- Urbano de Irun (validación única)
- Urbano de Errenteria (validación única)
- Urbano de Arrasate (validación única)
- Urbano de Hernani (validación única)
- Urbano de Zarautz (validación única)
- Urbano de Eibar (validación única)
- Urbano de Oiartzun (validación única). Operador no integrado en la ITG
- Urbano de Lasarte (se prevé su incorporación a la ITG a finales de 2015 o
comienzos de 2016)
Se deberá modificar la generación de ficheros de compensación actuales con la
información antes mencionada. En caso de que hubiera más operadores dentro
12
del sistema de tarificación integrada, antes de la fecha de finalización del
contrato, el adjudicatario dejaría el sistema de manera que se permitiera la
incorporación de datos de validación de tarjetas Barik y Bat
En caso sea necesaria la adquisición de nuevas licencias para motores de base
de datos las mismas serán acordadas, gestionadas y adquiridas por la ATTG.
6.3 Modificación de Base de Datos SAE para almacenamiento de nuevas
entidades Barik y BAT
El licitador deberá proponer las modificaciones necesarias en el Sistema de
Ayuda a la Explotación (SAE) para la incorporación de las nuevas entidades de
Bizkaia y Araba.
Se deberá registrar al menos la siguiente información en el sistema Mugi:
- Concesión
- Empresa
- Líneas
- Paradas
El licitador deberá justificar la inclusión de dicha información y su impacto en los
sistemas actuales de la ATTG.
6.4 Modificación de Base de Datos Sicot: Sistema de Distribución de
Ingresos
El licitador deberá proponer las modificaciones necesarias en la base de datos
del sistema de Distribución de Ingresos para contemplar las nuevas casuísticas
en la interoperabilidad:
- Viajes y regularizaciones con tarjeta Mugi en Territorios invitados.
- Viajes y regularizaciones con tarjeta Barik y Bat en servicios “Mugi”.
Dichas modificaciones deberán permitir la correcta asignación de importes para
su distribución, así como la diferenciación de pagos con tarjetas Bat y Barik en
el sistema Mugi.
6.5 Desarrollo de los canales de comunicación con sistemas SAGB y Centro
de Control BAT
13
El intercambio de información entre los centros compensadores se realizará
diariamente mediante FTPs. En los siguientes apartados se identifican los
ficheros a exportar e importar.
El licitador deberá especificar en su propuesta los mecanismos de comunicación
para el intercambio de ficheros con los centros de compensación SAGB y CC
BAT.
6.6 Exportación de validaciones BAT y Barik a los sistemas SAGB y Centro
de Control BAT
Se exportarán en el formato que defina cada centro de control:
Exportación a SAGB desde sistema Mugi (realizados en sistema Mugi):
- Viajes y Regularizaciones con tarjeta Barik en sistema Mugi.
- Regularizaciones con tarjeta Bat de viajes en sistema Barik.
- Regularizaciones con tarjeta Mugi de viajes en sistema Barik.
Exportación a CC BAT desde sistema Mugi (realizados en sistema Mugi):
- Viajes y Regularizaciones con tarjeta Barik en sistema Mugi.
- Regularizaciones con tarjeta Bat de viajes en sistema BAT.
- Regularizaciones con tarjeta Mugi de viajes en sistema BAT.
La exportación será un proceso programado diario:
- Proceso configurable (hora de ejecución, carpetas de generación, etc.).
- Proceso automatizado.
Tratamiento de viajes realizados en la línea general de EuskoTren ferrocarril:
6.7 Importación de validaciones Mugi desde los sistemas SAGB y Centro de
Control BAT
Se importará en el formato que defina la ATTG (según acuerdo con SAGB y CC
BAT):
Importación desde SAGB hacia sistema Mugi (realizados en sistema Barik):
- Viajes y Regularizaciones con tarjeta Mugi en sistema Barik.
- Regularizaciones con tarjeta Bat de viajes en sistema Mugi.
- Regularizaciones con tarjeta Barik de viajes en sistema Mugi.
Importación desde CC BAT hacia sistema Mugi (realizados en sistema BAT):
14
- Viajes y Regularizaciones con tarjeta Mugi en sistema BAT.
- Regularizaciones con tarjeta Barik de viajes en sistema Mugi.
- Regularizaciones con tarjeta Bat de viajes en sistema Mugi.
La importación será un proceso programado diario:
- Proceso configurable (hora de ejecución, carpetas de generación, etc.).
- Proceso automatizado.
6.8 Exportación Lista Negra Mugi y recepción de anulaciones Mugi
El licitador deberá detallar el proceso de exportación de las listas negras Mugi a
SAGB y CC BAT.
De igual forma se exportará la lista de tarjetas Bat y Barik anuladas en el
sistema Mugi. El licitador deberá detallar el proceso de anulación de dichas
tarjetas en los sistemas centrales de la ATTG.
6.9 Recepción Lista Negra Barik y BAT y exportación de anulaciones BAT y
Barik
El licitador deberá detallar el proceso de recepción y tratamiento de las listas
negras Barik y Bat. Dicha lista se dejará accesible a los sistemas de validación
del sistema Mugi. La incorporación de la funcionalidad de anulación en los
sistemas de validación del operador está fuera del presente alcance.
De igual forma se recibirá la lista de tarjetas Mugi anuladas en otros Territorios.
El licitador deberá detallar el proceso de anulación de dichas tarjetas en los
sistemas centrales de la ATTG.
6.10 Modificación informes estadísticos ATTG y DFG y adaptaciones
módulos de control
El licitador deberá realizar las modificaciones necesarias en el aplicativo PRO-
Informes de la ATTG y de la DFG para que se incluyan los viajes realizados con
tarjetas Barik y Bat en el sistema Mugi.
De igual forma el licitador deberá realizar las modificaciones necesarias en el
aplicativo Errores y Fraude de la ATTG para que se incluya el análisis de los
viajes realizados con tarjetas Barik y Bat en el sistema Mugi.
15
6.11 Modificación Web Service CAU y Web
Los servicios de Atención al Cliente (CAU) y Área privada del usuario (Web
Mugi) deberán proporcionar la información de los viajes con tarjeta Mugi
realizados en otros Territorios.
De igual forma desde el CAU se deberá poder visualizar el detalle de las
validaciones con tarjetas Barik y BAT en los servicios “Mugi”.
El licitador deberá proponer los nuevos métodos o modificaciones sobre los
métodos ya existentes en los Web Services actuales del CAU y de la WEB para
cumplir dicha funcionalidad.
6.12 Modificación Exportación SAP y réplicas PESA y EUSKOTREN
El licitador deberá detallar las modificaciones necesarias en los sistemas
actuales de exportación SAP y réplicas para los sistemas corporativos de PESA y
EUSKOTREN.
6.13 Modificación Contrato Programa
El licitador deberá detallar las modificaciones necesarias en el sistema actual de
Contrato Programa de la Diputación Foral de Gipuzkoa de forma que se tenga
en cuenta las validaciones realizadas con tarjetas Barik y BAT.
6.14 Modificación Sistema de Distribución de Ingresos
El licitador deberá detallar las modificaciones necesarias en el sistema de
Distribución de Ingresos actual SICOT para contemplar la lógica de validación y
distribución de ingresos de:
- Viajes con tarjeta Mugi en otros Territorios:
o Tarificación por saltos y operador.
o Modo de pago (sin descuentos) en otros territorios.
o Tarifa diferenciada por cada perfil para no aplicar bonificaciones Mugi
de recarga.
o Distribución de importes de regularización.
- Viajes con tarjeta Barik y Bar en sistema Mugi:
o Tarificación por saltos.
o Modo de pago (sin descuentos) en sistema Mugi.
o Tarifa única por cada perfil (no existen bonificaciones en recarga).
o Distribución de importes de regularización.
16
Los informes actuales deberán incluir las validaciones compensadas por viajes con
tarjetas Barik y Bat.
El aplicativo SI-Informes no será instalado en otros operadores de las concesiones
de Bizkaia o Araba, únicamente tendrá acceso la ATTG que será quien distribuirá la
información resultante del proceso de distribución de ingresos.
6.15 Monitorización de ficheros intercambiados y ficheros inválidos
Se considera adecuado que cada Centro de Compensación pueda monitorizar de
forma remota los datos que ha remitido a los otros dos Centros de Compensación y
que han sido incorporados por éste a su sistema.
El licitador deberá proponer una solución para que el SAGB y el CC BAT puedan
visualizar:
Informe de validaciones y regularizaciones enviadas y cargadas en el sistema
con la posibilidad de aplicar diferentes filtros:
o Temporal
o Operador de transporte
o Otros que se puedan definir
Informe de validaciones y regularizaciones incorrectas: aquellas que no han
pasado las reglas de verificación. Del mismo modo que para el informe anterior,
sería conveniente disponer de diferentes filtros (p.e por Id Tarjeta).
Informe de validaciones y regularizaciones no liquidables
Informe de liquidación mensual y/o de liquidación parcial hasta el momento de
su consulta
17
7. DIRECTOR DEL PROYECTO
Los trabajos se efectuarán bajo la supervisión del Director del Proyecto, el cual será
designado por parte de la ATTG. El mismo podrá ser personal propio de la ATTG o
persona contratada a tal fin. En todo caso, la ATTG podrá actuar y participar en
este proyecto con la colaboración de una asistencia técnica
Durante la ejecución de los trabajos objeto del contrato, el contratista se
compromete en todo momento a facilitar al Director del Proyecto la información y
documentación que ésta solicite 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 los métodos utilizados para resolverlos.
Las funciones del Director del Proyecto son:
a) Interpretar el Pliego de Prescripciones Técnicas y demás condiciones técnicas
establecidas en el contrato o en disposiciones oficiales.
b) Exigir la existencia de los medios y organización necesarios para la ejecución del
contrato en cada una de sus fases.
c) Ejercer de una manera continuada y directa la inspección y vigilancia del trabajo
contratado.
d) Convocar cuantas reuniones estime pertinentes para el buen desarrollo de los
trabajos y su supervisión, a la que estará obligada a asistir la representación de la
empresa adjudicataria, asistida de aquellos facultativos, técnicos, letrados o
especialistas de la misma que tengan alguna intervención en la ejecución del
contrato.
e) Dar las órdenes oportunas para lograr los objetivos del contrato.
f) Programar las modificaciones que convenga introducir durante la ejecución del
proyecto.
g) Tramitar cuantas incidencias surjan durante el desarrollo del contrato.
h) Aprobar el trabajo realizado previamente al abono del precio del contrato.
i) Expedir, en su caso, las certificaciones parciales en el caso de que asó se
determinara. y conformar las facturas correspondientes a los trabajos realizados
según los plazos de ejecución y abono que se señalen en el pliego administrativo.
18
Al menos una vez al mes, el adjudicatario informará por escrito al Director del
Proyecto sobre el estado de los trabajos hasta la fecha realizados y solicitará de él
las instrucciones pertinentes para la continuación o modificación de aquellos.
De todas las reuniones que se mantengan entre la Dirección de Proyecto y el
Adjudicatario se levantarán ACTAS donde se recojan las propuestas,
modificaciones, instrucciones y conclusiones que se adopten. El adjudicatario será
el encargado de levantar actas. Para que tengan consideración de definitivas, se
requerirá la aprobación expresa de la ATTG.
La adjudicataria designará una persona Coordinadora – Responsable del Servicio,
que será la encargada de coordinar los trabajos de seguimiento y control del
cumplimiento de plazos y la calidad de los mismos, y actuará como interlocutor con
la ATTG, tanto para recibir las explicaciones técnicas referentes al funcionamiento
de las instrucciones de trabajo, como para redactar los informes de seguimiento y
asistir a las reuniones a las que sea requerido por la ATTG.
La adjudicataria se compromete a poner en marcha todos los recursos humanos y
materiales que sean necesarios para el correcto desarrollo del objeto del contrato,
siendo de su competencia la relación jurídica o laboral de dicho personal y las
sustituciones de personas que pudieran ser necesarias para la correcta y eficaz
prestación del objeto del contrato.
En este orden de cosas, se hace constar que la ATTG queda desvinculada, a todos
los efectos, de cualquier relación laboral con el personal de la entidad adjudicataria.
19
8. PLAN DE CONTROL DE CALIDAD
El Contratista es el responsable del Control de Calidad del Contrato, por lo que,
independientemente del equipo de desarrollo e instalación, deberá disponer de una
organización dedicada al control de calidad del Contrato.
La organización de calidad del Contratista deberá elaborar y someter a la
aprobación de la Dirección Técnica un Plan de Control de Calidad, donde se
establezca la metodología que permita un adecuado control de la calidad,
comprobándose que la calidad de todos los desarrollos se realizan de acuerdo al
Contrato.
En este Plan de Control de Calidad deberán quedar definidos las organizaciones,
autoridades, responsabilidades y métodos que permitan una prueba objetiva de la
Calidad para todas las fases del Contrato.
El Control de Calidad comprende tanto los desarrollos, como los trabajos de
instalación y pruebas previas a la puesta en marcha así como durante la misma.
El Plan de Control de Calidad deberá describir los siguientes conceptos:
Esquema de la organización de calidad del Contratista, con organigrama
funcional y nominal específico para el contrato, así como la relación de
medios que pondrá en práctica a lo largo de los trabajos.
Procedimientos, instrucciones de trabajo y otros documentos que desarrollen
detalladamente lo indicado en los Planos y Pliegos del Proyecto.
8.1 Plan de aseguramiento de la calidad
El Plan de Aseguramiento de la Calidad deberá describir los siguientes conceptos:
Descripción y objeto del plan.
Códigos y Normas de aplicación.
Procedimientos de desarrollo / instalación.
Procedimientos de ensayo y pruebas.
Documentación a generar relativa a los desarrollos, instalaciones y pruebas.
Lista de verificación.
20
Tras la finalización de la fase de desarrollo o instalación o de la actividad deberá
existir una evidencia documentada, por medio de protocolos o de firmas en el libro
de órdenes, de que todas las organizaciones involucradas han realizado todas las
inspecciones, ensayos y pruebas programadas.
8.2 Plan de pruebas de los sistemas
El Plan de pruebas deberá definir las pruebas a realizar sobre los equipos y
sistemas del Contrato. El plan deberá ser sometido a la aprobación de ATTG e
incluirá las pruebas de aceptación de los desarrollos realizados.
8.3 Pruebas a realizar
Las pruebas a realizar sobre los distintos desarrollos podrán ser:
Pruebas de funcionalidades con tarjetas MUGI, BAT y BARIK en condiciones
de interoperabilidad.
Funcionalidades con tarjetas BAT y BARIK en modos de transporte de Bizkaia
y Araba tras su validación en DBUS.
Pruebas de funcionalidades con tarjetas MUGI (verificar que los nuevos
desarrollos no afectan a la implantación actual)
Pruebas de compensación en el Sistema de distribución de ingresos.
Pruebas de intercambio de ficheros (exportaciones de validaciones a SAGB y
Centro de Control BAT e importación de validaciones Mugi en Bizkaia y Araba
Pruebas de funcionalidades con los elementos de seguridad.
Pruebas de aceptación de puesta en servicio
Para cada sistema a probar será de aplicación un Protocolo de Pruebas y sus hojas
de registro de verificaciones.
El Contratista deberá presentar a la Propiedad, para su aprobación, un Plan de
Pruebas para todo el conjunto de equipos y
Cada Plan de Pruebas de aceptación en fábrica, a realizar por el Contratista para su
aprobación por la Dirección Técnica, deberá incluir una relación de documentación
de referencia, una lista de verificaciones a realizar y unas hojas de registro de los
resultados de las pruebas.
21
Cada Plan de Pruebas de aceptación de puesta en servicio e instalación, , deberá
incluir una relación de documentación de referencia, una lista de verificaciones a
realizar y unas hojas de registro de los resultados de las pruebas. Asimismo, en
este caso, se deberá detallar las necesidades de disponibilidad o limitación de otras
instalaciones, ajenas al presente contrato, que el Contratista considera necesario
para la realización de las pruebas.
Las hojas de registro de los resultados de las pruebas serán firmadas tanto por el
responsable del Contratista como por la Dirección Técnica.
8.4 Programa de pruebas
El Contratista realizará y someterá a la aprobación de la Dirección Técnica, un
programa que incluya las pruebas a realizar para cada desarrollo, incluyendo las
fechas previstas para la realización de las pruebas y las personas participantes y
responsables.
Este programa de pruebas se deberá actualizar de forma homogénea con el
desarrollo global de las instalaciones.
El Contratista deberá presentar igualmente para su aprobación por la Dirección
Técnica, la documentación aplicable a la realización de las pruebas, con la
antelación definida en el Plan de Calidad.
8.5 Plan de fiabilidad y disponibilidad
El Contratista deberá entregar un Plan de Fiabilidad donde se recoja, entre otros
aspectos:
Índice de fiabilidad general
Cadena de fiabilidad
Recursos técnicos y humanos en el periodo de garantía
Asimismo, el Contratista deberá establecer la disponibilidad del Sistema, que no
deberá ser inferior al 99,90%.
22
9. PLAN DE IMPLANTACIÓN, GARANTÍA Y DOCUMENTACIÓN
El contratista propondrá la metodología y fases asociadas al plan de implantación
las modificaciones de los sistemas centrales de la ATTG, siempre teniendo en
cuenta que debe estar operativo en un plazo inferior a 12 meses.
En dicho plan de implantación se detallarán las pruebas y homologaciones previas
necesarias antes de la puesta en marcha de dichas modificaciones.
La documentación a entregar a lo largo del desarrollo del proyecto será la
siguiente:
Plan de Proyecto: Planificación detallada de las tareas a llevar a cabo cara a
desarrollar el proyecto, incluyendo cronograma, identificación de recursos
comprometidos en el proyecto, acciones formativas y riesgos.
Análisis funcional del proyecto: Especificación formal de las funcionalidades a
cubrir cara a la implantación.
Informes de Seguimiento del Proyecto: elaborado tras cada reunión periódica de
proyecto según el calendario establecido. Se definirá la adecuación del progreso
del proyecto respecto a la planificación inicial, identificando desviaciones y
problemas encontrados para su consecución y las medidas tomadas cara a
solventarlos.
Actas de reunión: Documento elaborado tras cada reunión del proyecto en la
que se especifican las personas que forman parte, el resumen de los temas
tratados, las conclusiones obtenidas, y la asignación de los temas pendientes.
Debe ser remitida a todas las personas que han participado en la reunión
señalando los compromisos expresados por todas las partes.
Plan de pruebas: De acuerdo a lo señalado en el punto anterior.
Manual/es de instalación: Conjunto de instrucciones que detallen los pasos a
seguir para realizar la instalación y configuración de los aplicativos y
adaptaciones desarrolladas expresamente para este concurso.
Manuales de operación y explotación: Orientado a los administradores de
sistemas, complementa el Manual de Instalación añadiendo la información
referente al mantenimiento de la aplicación, como vinculación con bases de
datos y sistemas externos.
Manuales de usuario: Conjunto de manuales que definen las funcionalidades de
los desarrollos desde el punto de vista de los usuarios finales con carácter
23
didáctico. Debe cubrir la totalidad de las funciones con las que debe interactuar
el usuario.
El código fuente de las modificaciones realizadas en los sistemas
exclusivamente para este proyecto. Además, se deberá entregar el software
necesario para permitir modificar el código fuente del software recepcionado y
obtener una versión que sea posible poner en producción. Dicho software se
entregará con licencia a nombre de ATTG, siendo dicha licencia válida durante la
duración de la garantía, como mínimo.
Los protocolos de comunicaciones expresamente desarrollados bajo las
actividades de este proyecto.
Todo el software, de alto o bajo nivel, desarrollado o modificado al amparo del
presente contrato será propiedad de ATTG y será entregado a éste,
entendiéndose por software cualquier ejecutable, driver, biblioteca o librería,
etc.
Es decir, el contratista deberá entregar a ATTG la totalidad del código fuente
desarrollado o modificado en el presente contrato, así como cualquier protocolo
de comunicaciones empleado en la comunicación de los distintos elementos
suministrados e instalados. Con la entrega del código fuente se realizarán
sesiones formativas de la arquitectura general del sistema y de los
componentes software que engloban la solución.
ATTG deberá validar de forma previa al inicio de los trabajos los lenguajes de
programación empleados en el desarrollo de los distintos drivers, aplicaciones,
etc.
El contratista deberá incluir en su presupuesto un periodo de garantía de dos años,
a partir de la fecha de recepción del proyecto, contra mal funcionamientos o
funcionamientos incorrectos del software.
24
10. ASISTENCIA
Con independencia de la información que el adjudicatario pueda obtener de otras
fuentes, la ATTG pondrá a su disposición durante la ejecución del proyecto de
cuanta información relativa al objeto del presente contrato exista en la misma y
apoyará las gestiones del adjudicatario con terceros si esto fuera necesario.
25
11. ANEXO 1
Masterplan de interoperabilidad de las tarjetas de transporte en Euskadi: BAT /
BARIK / MUGI
12. ANEXO 2
Definición conceptual de las Comunicaciones entre los Centros de Compensación de
Tarjetas de Transporte de Euskadi
![vacon nxp/c...En el manual Convertidores de frecuencia NXP, instalación de módulo IP00, tamaños FR10 a FR14] (ud01118A) ofrece información sobre la instalación del convertidor](https://img.pdfslide.es/doc/110x75/612da31a1ecc515869425035/vacon-nxpc-en-el-manual-convertidores-de-frecuencia-nxp-instalacin-de-mdulo.jpg)
