[Transparencia y Apertura de Datos] - Euskadi.eus

[Transparencia y Apertura de Datos / Presencia Web]

Servicios para la Apertura de Datos Meteorológicos y Renovación de los canales de difusión de información

Página:

i/100

[Transparencia y Apertura de Datos]

Servicios para la Apertura de Datos Meteorológicos y Renovación de los Canales de Difusión de

Información (Web / Móvil / etc)

Exposición de datos meteorológicos y presencia web / móvil

Pliego de Condiciones Técnicas

Fecha: Marzo 2018 EJIE-032-2018

EJIE S.A. Mediterráneo, 14 01010 Vitoria-Gasteiz Posta-kutxatila / Apartado: 809 01080 Vitoria-Gasteiz Tel. 945 01 73 00* Fax. 945 01 73 01 www.ejie.es

Este documento es propiedad de EJIE, S.A. y su contenido es confidencial. Este documento no puede ser reproducido, en su totalidad o parcialmente, ni mostrado a otros, ni utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A.. En el caso de ser entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato. EJIE, S.A. no podrá ser considerada responsable de eventuales errores u omisiones en la edición del documento.

http://www.ejie.es/



Página:

ii/100

Control de documentación

[Transparencia y OpenData] – Servicios para la Apertura de Datos Meteorológicos y Renovación de la Presencia Web

Pliego de Condiciones Técnicas

Histórico de versiones

Código: Versión: Fecha: Resumen de cambios:

1.0 Enero 2018 Versión inicial

Cambios producidos desde la última versión

Primera versión.

Control de difusión

Responsable: Alex Lara Garachana

Aprobado por:

Firma: Fecha: Enero 2018

Distribución:

Referencias de archivo

Autor:

Nombre archivo:

Localización:



Página:

iii/100

Contenido

Capítulo/sección Página

1 Necesidad de Contratación 1

2 Perfil de la Compañía 2

3 Introducción 3

4 Necesidad de Negocio 4

4.1 Situación Actual 4

4.1.1. Canales de difusión / distribución web 4

4.1.2. Datos Abiertos 5

4.1.3. Bajo Demanda 6

4.1.4. Visión técnica 7

4.2 Problemas Detectados 9

4.3 Solución propuesta 10

5 Proyecto 20

6 Descripción del Proyecto 22

6.1 FASE I: Análisis de datos disponibles y exposición de servicios 22

6.1.1. Objetivo 1: Análisis 22

6.1.2. Objetivo 2: Documentar 44

6.1.3. Objetivo 3: Construir 46

6.1.4. Objetivo 4: Componentes Web 49

6.2 FASE II: Obtención de datos backend y exposición final de servicios 56

6.2.1. Objetivo 1: Análisis de los orígenes de datos 56

6.2.2. Objetivo 2: Construcción 58

6.2.3. Objetivo 3: Despliegue 61

7 Entregables 63

7.1 Descripción de Entregables 63

7.1.1. Entregables relacionados con el [producto] del proyecto 63

7.1.2. Entregables relacionados con la [Gestión del Proyecto] 64

7.2 Aceptación de Entregables 65

8 Planificación inicial 66

8.1 Planificación de Alcance 67



Página:

iv/100

8.2 Planificación de RRHH: Previsión de Recursos 70

8.3 Planificación de tiempos 72

8.4 Planificación de Costes 74

8.5 Riesgos 76

8.6 Planificación de la Calidad 77

8.7 Comunicaciones 78

9 Gestión del Proyecto 79

9.1 Metodología 79

9.2 Equipo de Trabajo 81

9.2.1. Constitución inicial del equipo de trabajo 82

9.2.2. Modificaciones en la composición del equipo de trabajo 83

9.2.3. Horario y lugar de realización de los trabajos. 83

9.3 Organización del Proyecto / Estructuras de Control 85

9.4 Transferencia Tecnológica. 86

10 Presupuesto y Plazo 87

10.1 Presupuesto 87

10.2 Plazo 87

11 Plazo de Vigencia del Contrato 87

12 Contenido de las Ofertas 88

12.1 Solvencia 88

12.2 Propuesta Técnica 90

12.3 Propuesta Económica 92

13 Criterios de Adjudicación 93

14 Facturación 95

15 Contacto 96



Página:

1/100

1 Necesidad de Contratación

El proyecto objeto de la presente contratación de Servicios para la Apertura de datos meteorológicos: Exposición como datos abiertos [OpenData] de datos procedentes de [euskalmet] y renovación de los canales de difusión de información, está enmarcado dentro de la [Encomienda de Gestión] por la que el [Departamento de Gobernanza Pública y Autogobierno] encarga a [Eusko Jaurlaritzaren Informatika Elkartea-Sociedad Informática del Gobierno Vasco, S.A.] la prestación de diversos servicios y actuaciones de mantenimiento, desarrollo y soporte de la [Administración Electrónica]

En la siguiente tabla se presenta un resumen de los problemas detectados tanto en la [publicación de datos abiertos] (opendata) como en los [canales de distribución] de información (web / móvil) por los que ahora se distribuyen los contenidos / información / datos meteorológicos y para cuya solución se propone abordar el proyecto objeto del presente documento de condiciones técnicas

Situación actual Situación objetivo

Publicación de datos abiertos

(OpenData)

No todos los datos meteorológicos se ofrecen en abierto

Los datos que se publican no siguen un formato uniforme

La ergonomía de los datos abiertos es muy mejorable (difíciles de consumir)

No hay un mecanismo técnico homogéneo para la publicación de datos en [OpenData Euskadi]

Publicar todos los datos de interés que puedan ser publicados y que ahora residen en los sistemas de información internos

Publicar datos en un formato uniforme (y si es posible estándar)

Publicar servicios de una forma más ergonómica (más fácilmente consumibles)

Crear un mecanismo estándar de publicación de datos en [OpenData Euskadi]

Canales de distribución

(web / tv / móvil / etc)

Dispersión tecnológica (cada canal se basa en una tecnología diferente)

Inestabilidad puntual de los sistemas

Actualización del diseño a la nueva imagen de Euskadi.eus

El canal de distribución [móvil] es el más demandado frente a la versión web de escritorio

Crear un sistema tecnológicamente homogéneo y fiable independientemente del canal de salida

Mejorar el diseño en el que se presenta la información

Mobile First

La actividad objeto de contratación descrita en el presente [Pliego de Condiciones Técnicas] es necesaria para la prestación de un servicio que es competencia de EJIE y que según las [Instrucciones sobre las buenas prácticas en la contratación de servicios de Gobierno Vasco]

Está incluida entre los servicios que pueden ser contratados, conforme a la [Instrucción sexta].

Su objeto NO contiene prestaciones que con arreglo a la [Instrucción quinta] deben ser satisfechas con medios propios.

Su prestación NO puede ser asumida con los recursos humanos y técnicos de que dispone el EJIE siendo además inconveniente o imposible su reorganización.

Los documentos contractuales elaborados en la fase de preparación del contrato incorporan las debidas garantías para dar cumplimiento a la [Instrucción octava], sobre la celebración de contratos de servicios a fin de evitar que se incurra en los supuestos de cesión ilegal de trabajadores.

http://www.jusap.ejgv.euskadi.eus/contenidos/informacion/contratos_servicios/es_def/adjuntos/14_04_29_INSTRUCCIONES.pdf

http://www.jusap.ejgv.euskadi.eus/contenidos/informacion/contratos_servicios/es_def/adjuntos/14_04_29_INSTRUCCIONES.pdf



Página:

2/100

2 Perfil de la Compañía

EJIE, Eusko Jaurlaritzaren Informatika Elkartea – Sociedad Informática del Gobierno Vasco, es la Empresa pública de servicios de las tecnologías de la información y las comunicaciones (TIC), cuya razón de existir es contribuir a la concesión de un Sector Público Vasco, moderno y eficiente, en el Marco Legal establecido por el Gobierno, con la seguridad y calidad necesarias y con el debido respeto al medio ambiente.

EJIE tiene como meta final la consecución de la satisfacción de sus clientes, siendo el instrumento común de prestación de servicios TIC en el sector Público Vasco, y comprometiéndose en:

Construir y mantener con eficiencia y calidad la infraestructura de los Sistemas de Información, posibilitando su continuidad y seguridad

Garantizar la interoperabilidad entre las distintas administraciones

Servir de apoyo a las necesidades de planificación y realización de la función informática de los Departamentos y Organismos Autónomos del Gobierno, asegurando la cobertura de sus demandas con el compromiso y profesionalidad adecuados a las relaciones contractuales que se establezcan

Por tanto EJIE debe ser, un instrumento común de referencia para la prestación de servicios TIC en el Sector Público Vasco:

Aportando valor añadido

Proporcionando soluciones competitivas

Transmitiendo confianza a sus clientes

Contando con personas cualificadas y comprometidas

Se puede obtener información más detallada y extensa en nuestra dirección de Internet http://www.ejie.eus

http://www.ejie.eus/



Página:

3/100

3 Introducción

El proyecto objeto de la presente contratación se enmarca en dos estrategias:

La estrategia de la [Dirección de Atención de Emergencias y Meteorología] para prestar el mejor servicio posible a través de múltiples canales: web / móvil / tv, etc

La estrategia de [datos abiertos] del [Gobierno Vasco]: Opendata Euskadi liderada por la [Dirección de Atención a la Ciudadanía, Mejora y Administración Electrónica] (DACIMA)

En el marco de estas estrategias, se dan las dos circunstancias que hacen prioritario abordar el proyecto objeto de la presente [Documento de Condiciones]:

En la [presencia web], tanto en la [Dirección de Atención de Emergencias y Meteorología] -responsable de la web euskalmet- como en la [Dirección de Atención a la Ciudadanía, Mejora y Administración Electrónica] -responsable de la presencia web del [Gobierno Vasco] en su totalidad-, hay interés y obligación en renovar la web (www.euskalmet.euskadi.eus) tanto en su versión web como móvil para actualizar la usabilidad, diseño, accesibilidad, etc

A nivel de [datos abiertos] es necesario:

o Mejorar la forma en que los datos meteorológicos se abren en formatos reutilizables (opendata) puesto que la ergonomía de los datos abiertos actualmente es muy mejorable

o Abrir todos los datos que sea posible publicar -y que actualmente NO se estén publicando-

En base a estos objetivos y contando con la financiación del [Plan de Ciencia y Tecnología del Gobierno Vasco], se publica el presente documento de condiciones técnicas para la contratación de un proyecto al efecto en un esfuerzo conjunto entre la [Dirección de Atención a la Ciudadanía, Mejora y Administración Electrónica] y la [Dirección de Atención de Emergencias y Meteorología] en el que participaran muchas otras entidades (servicios de otros departamentos propietarios de algunos datos como Salud, Geo-Euskadi y otros)

http://www.euskadi.eus/web01-s2segur/es/contenidos/institucion/1706/es_5128/r01hRedirectCont/contenidos/organo/1449/es_4616/es_dir_emergencias.html

http://www.opendata.euskadi.eus/

http://www.euskadi.eus/web01-s2jusap/es/contenidos/institucion/1701/es_5148/r01hRedirectCont/contenidos/organo/1399/es_5278/es_dir_innovacionadmin.html

http://www.euskalmet.euskadi.eus/



Página:

4/100

4 Necesidad de Negocio

4.1 Situación Actual

Actualmente en lo que se refiere a la publicación de información meteorológica se puede hacer la siguiente agrupación:

Canal Formato Destinatario

Canales de difusión / distribución web

Web euskalmet

TV

Móvil responsive

App móvil nativa

Personas: público en general

Datos Abiertos Ficheros (Excel, csv, etc) publicados en [opendata Euskadi]

Infomediarios que están interesados en hacer productos derivados a partir de los datos en crudo

Bajo demanda Certivicaciones Personas, empresas, juzgados, etc

4.1.1. Canales de difusión / distribución web

WEB Sitio web principal del servicio, accesible en wwww.euskalmet.euskadi.eus Incluye -entre otras- las siguientes informaciones:

Pronósticos generales, por comarcas y por pueblos actualizados cada 12 horas.

Pronóstico diario de mar.

Pronósticos automáticos por horas de rayos ultravioletas, estado de la mar, mapas de precipitación, temperatura...

Mapas de lluvia y temperaturas en tiempo real.

Información de precipitación en tiempo real, a partir de información de radar.

Información de corrientes superficiales de la mar en tiempo real.

Información de parámetros meteorológicos y oceanográficos en boyas y plataformas costeras en tiempo real.

Información de viento en altura procedente del perfilador de Punta Galea en tiempo real.

Rayos detectados mezclados con información del radar meteorológico también en tiempo real.

Otras muchas informaciones.

Twitter a través de @Euskalmet informando con carácter general como en situaciones de emergencia

TV Canal [Web-TV] que informa de:

La predicción meteorólogica correspondiente a tres días (hoy, mañana y pasado mañana)

Predicciones del estado de la mar

Mapas de temperatura, precipitaciones y radar,

Alertas meteorológicas, en caso de que existan

http://www.euskalmet.euskadi.net/



Página:

5/100

Web Móvil (responsive) Predicción meteorólogica a tres días (hoy, mañana y pasado mañana)

Predicciones del estado de la mar

Mapas de temperatura, precipitaciones y radar

Avisos meteorológicos

App móvil nativa App oficial del [Departamento de Seguridad] que ofrece información es actualizada en tiempo real desde los sistemas informáticos de Euskalmet

Información meteorológica de la situación actual

Predicción a 7 días vista

Evolución de las próximas 72 horas en los municipios de la CAPV

Avisos meteorológicos a tres días vista y su nivel de riesgo

Información de radar (precipitación, largo alcance y máxima reflectividad).

Diversos enlaces a información de interés y accesos rápidos a los teléfonos oficiales de emergencias.

AVISOS, ALERTAS y ALARMAS

meteorología adversa

Webs privadas Orientadas a usuarios de emergencias y relacionados (Vialidad invernal, inundaciones...).

4.1.2. Datos Abiertos

Actualmente en [OpenData Euskadi] se ofrecen 52 data-sets (a fecha de Enero 2018) relacionados con la meteorología (ver listado en OpenData Euskadi)

Dado que algunos de los [DataSets] se repiten en función del año, en el siguiente listado se recogen un resumen de los [DataSets]:

Predicción Marítima / año

Itsaseus: predicción marítima detallada en 11 puntos marítimos / año

Predicción meteorológica actual y datos acumulados / año

Red de estaciones meteorológicas de Euskadi

Estaciones meteorológicas: lecturas recogidas / año

Sondeos de la estación de Arteaga (Bizkaia): lecturas recogidas / año

Medias diarias y mensuales de datos hidrológicos (clasificadas por año natural)

Medias diarias y mensuales de datos hidrológicos (clasificadas por año hidrologico)

Datos diezminutales del último año hidrológico

Isoyetas

Isotermas

Territorio, clima y medio ambiente; datos históricos

Se pueden incluir en el listado algunos [DataSets] relacionados con la [meteorología] de manera más indirecta:

Calidad del aire / año

Niveles de pólen / año

http://www.opendata.euskadi.eus/

http://opendata.euskadi.eus/catalogo-datos/?r01kQry=tC:euskadi;tT:ds_meteorologicos;m:documentLanguage.EQ.es,OpendataEstadistic.IN.(0,1);pp:r01PageSize.10;p:Inter_portal,Inter



Página:

6/100

4.1.3. Bajo Demanda

Certificaciones Certificaciones a particulares, compañías de seguros, juzgados, etc sobre condiciones meteorológicas en un determinado lugar y momento



Página:

7/100

4.1.4. Visión técnica

A nivel técnico, los datos se importan en [opendata Euskadi] utilizando el siguiente proceso:

Toda la información meteorológica se captura, procesa y genera en sistemas localizados en EUSKALMET; para poder utilizar esta información desde Euskadi.eus es necesario transferir esta información a sistemas en EJIE. Con este objetivo, la infraestructura de transferencia de información desde los sistemas en euskalmet a los sistemas en EJIE es la siguiente

Paso Descripción

1a Algunos datos (medidas, previsiones, etc) se replican en una base de datos en EJIE desde una base de datos en euskalmet

1b Una serie de ficheros con mapas, avisos, textos, etc se pasa desde los servidores de euskalmet a un servidor intermedio de intercambio de ficheros en EJIE

2 La aplicación de [sindicación de datos] de [PLATEA Web] utiliza los datos en BBDD y los ficheros con mapas, avisos, textos, etc para generar:

[Contenido Web] para Euskadi.eus

Datos reutilizables para [OpenData]

3 Los activos generados por la aplicación de [sindicación de datos] de [PLATEA Web] se publican en Euskadi.eus

Extranet

Predicciones /

Datos

PLATEA WEB

Proceso de

importación de datos

de euskalmet y

generación de

contenidos

Euskadi.eus

Las predicciones,

mapas, y datos

meteorológicos en

general se GENERAN

en los servidores de

Euskalmet

1

2Las predicciones, mapas, y

datos meteorológicos en

general se traspasan a

servidores de EJIE

Las predicciones, mapas, y

datos meteorológicos en

general se TRANSFORMAN en

contenidos de euskadi.eust

3 Los contenidos generados se

PUBLICAN en euskadi.eus4

Portal

euskalmet

PLATEA WEB

DB Meteorología

1a

Los datos que residen en DB

de euskalmet se sincronizan

en DBs de EJIE

1b

Los datos que residen en

ficheros en euskalmet se

sincronizan a una zona de

intercambio en EJIE (PIF)Intercambio de ficheros

Proceso de


de euskalmet a

[PLATEA Web]

3

El proceso de importación

de datos genera contenido

web y datos reutilizables

2

www.euskalmet.euskadi.eus



Página:

8/100

Como se puede ver en la figura anterior, la información de euskalmet se “traspasa” a los sistemas de EJIE con dos fines:

Ser utilizada por una aplicación IIS que “pinta” el portal www.euskalmet.euskadi.eus

Ser utilizada por la [sindicación de datos de PLATEA] para

o Generar contenidos web que se utilizan en WebTV y versión móvil de euskalmet

o Publicar datos en formato reutilizable

A nivel general, técnicamente la situación es:

Canales de difusión / distribución web

Web euskalmet Aplicación IIS que usa:

Directamente la DB de euskalmet

Ficheros sincronizados en la web desde euskalmet

TV Contenidos web generados en [PLATEA Web] por el [sistema de sindicación de datos]

Móvil responsive Contenidos web generados en [PLATEA Web] por el [sistema de sindicación de datos]

App móvil nativa Aplicación móvil que usa como fuente de información:

Datos disponibles en la Web Euskalmet

Ficheros sincronizados desde los servidores Euskalmet

Datos Abiertos Ficheros (Excel, csv, etc) generados en [PLATEA Web] por el [sistema de sindicación de datos]

Como se puede ver hay una gran dispersión en las tecnologías para difundir la información y abrir los datos.




Página:

9/100

4.2 Problemas Detectados

En la siguiente tabla se presenta un resumen de los problemas detectados tanto en la [publicación de datos abiertos] (opendata) como en los [canales de distribución] de información (web / móvil)

Situación actual Situación objetivo

Publicación de datos abiertos

(OpenData)

No todos los datos meteorológicos se ofrecen en abierto

Los datos que se publican no siguen un formato uniforme

La ergonomía de los datos abiertos es muy mejorable (difíciles de consumir)

No hay un mecanismo técnico homogéneo para la publicación de datos en [OpenData Euskadi]

Publicar todos los datos de interés que puedan ser publicados y que ahora residen en los sistemas de información internos

Publicar datos en un formato uniforme (y si es posible estándar)

Publicar servicios de una forma más ergonómica (más fácilmente consumibles)

Crear un mecanismo estándar de publicación de datos en [OpenData Euskadi]

Canales de distribución

(web / tv / móvil / etc)

Dispersión tecnológica (cada canal se basa en una tecnología diferente)

Inestabilidad puntual de los sistemas

Actualización del diseño a la nueva imagen de Euskadi.eus

El canal de distribución [móvil] es el más demandado frente a la versión web de escritorio

Crear un sistema tecnológicamente homogéneo y fiable independientemente del canal de salida

Mejorar el diseño en el que se presenta la información

Mobile First

Algunas de las necesidades concretas se detallan en la siguiente tabla:

Web Se trata de una aplicación IIS “integrada” en un portal de PLATEA Web que utiliza fundamentalmente los datos de la BBDD Oracle, ficheros de texto e imágenes

Necesidades detectadas

Es necesario actualizar el diseño de la web

En ocasiones puntuales presenta problemas de rendimiento

OpenData Algunos datos de [euskalmet] se publican en [OpenData] (no todos) para ello se ha trabajado con [meteorología] para construir un mecanismo ad-hoc

Necesidades detectadas:

Publicar más información en formato reutilizable (actualmente solo se publica un subconjunto de los datos de [meteo])

Publicar los datos en formatos más ergonómicos (ej: APIs)

Diseñar un mecanismo uniforme de intercambio de información [euskalmet] [opendata]

Web Móvil (responsive)

A partir de la información [OpenData] se generan de forma estática algunos widgets


El mecanismo técnico de la web móvil es diferente al de la web “normal”; sería deseable que ambas web se construyeran en base al mismo mecanismo

WebTV Se basa en la información que se publica en [OpenData]

(es muy similar al caso de la web móvil)

App Móvil Desarrollada ad-hoc por vitesia


Actualmente la app móvil utiliza mecanismos ad-hoc para “pintar” los datos que obtiene de la página web de Euskalmet.

http://www.euskalmet.euskadi.eus/s07-5853x/eu/meteorologia/home.apl?e=8

http://www.euskalmet.euskadi.eus/mobile/inicio/s07-mobile/es/?e=5

http://www.vitesia.com/



Página:

10/100

4.3 Solución propuesta

La solución propuesta pasa por abrir los datos de los [sistemas backend] de [euskalmet] para que puedan ser reutilizados internamente y externamente por entidades infomediarias para crear productos derivados. La forma de abrir los datos de los [sistemas backend] de [euskalmet] pasa fundamentalmente por:

1. Crear APIs (Application Programming Interface) accesibles públicamente desde Internet

2. Exponer los APIs que dan acceso a los datos [OpenData Euskadi] y [Euskalmet]

3. Reconstruir la web [euskalmet.euskadi.eus] en base a contenido estático pre-generado

periódicamente a partir de los datos expuestos en los [APIs]

La situación actual es la que se ha resumido anteriormente:

Básicamente existen dos infraestructuras casi paralelas para servir la información en la web y como datos abiertos.

Como solución se propone crear un único pipe-line basado en:

El esquema final se muestra en la figura:

La pieza central de la solución es el [repositorio común] que tiene los datos adaptados desde su formato en origen al formato en el que van a ser expuestos en el [API]

Portal

euskalmet

PLATEA WEB

DB Meteorología

1a



en DBs de EJIE

1b

Los datos que residen en



intercambio en EJIE (PIF)Intercambio de ficheros

Proceso de


de euskalmet a

[PLATEA Web]

3




2


APP Server

DB Meteorología

1a



en DBs de EJIE

1bLos datos que residen en



intercambio en EJIE (PIF) Intercambio de ficheros


de dato adapta la

información al formato en el

que va a ser expuesta y la

almacena en el [repositorio

común]

REPOSITORIO

COMUN

Proceso de

importación de

datos de

euskalmet

2

PLATEA WEB

Proceso de


de euskalmet a

[PLATEA Web]

5

El proceso de importación de

datos genera componentes web

y datos reutilizables

4

Los datos almacenados se

exponen como servicios

REST

(NO debería ser necesaria

ninguna transformación de

datos)

3




Inte

rfaz d

e a

ctu

aliz

ació

n

Inte

rfaz d

e C

on

su

lta


1. Analizar los datos disponibles y cómo deberían exponerse como [APIs] abiertos

2. Crear un [repositorio común] con los datos transformados y adaptados tal y como van a ser expuestos en el [API]

3. Construir la web y los datos abiertos a partir de los datos expuestos en el [API]

https://en.wikipedia.org/wiki/Application_programming_interface



Página:

11/100

Como se puede observar en la [solución propuesta] hay un pipeline único tanto para exponer datos como para publicar en la web:

Paso Descripción

1a Algunos datos (medidas, previsiones, etc) se replican en una base de datos en EJIE desde una base de datos en euskalmet

1b Una serie de ficheros con mapas, avisos, textos, etc se pasa desde los servidores de euskalmet a un servidor intermedio de intercambio de ficheros en EJIE

2 Un [módulo de transformación e importación] de datos utiliza los datos de origen para insertar datos en un [repositorio común]

Los datos en el [repositorio común] están almacenados en el formato en el que van a ser expuestos esto implica que el [módulo de transformación e importación] en muchas ocasiones va a tener que:

Mezclar datos de varios orígenes

Enriquecer los datos con información que no está en el origen (ej: datos de NORA)

… y otras operaciones

3 Los datos del [repositorio común] se exponen en forma de [servicios REST] (API)

NO debería ser necesaria ninguna transformación de los datos ni consultas complejas puesto que los

datos YA están almacenados en el formato en que van a ser expuestos

4 El módulo de [sindicación de datos de PLATEAWeb] utiliza los [servicios REST] (API) expuestos para:

Generar [componentes web] reutilizables para construir la web www.euskalmet.euskadi.eus

Generar y actualizar los [DataSets] de [OpenData Euskadi]

Por otra parte, la web [euskalmet.euskadi.eus] puede ser construida en base a [componentes] HTML (ficheros HTML) que simplemente se despliegan (copian) en el [servidor web]

Los [servidores de aplicación], [bases de datos], [APIs], etc únicamente intervienen en el momento de generación de los [componentes], es decir, los/las visitantes de la web NO interactúan nunca directamente con ellos y por lo tanto la carga que soportan es mínima.

El objetivo de estos cambios es:

1 Simplificar la infraestructura técnica necesaria para “pintar” la

web

Cuando más simple sea la infraestructura técnica de la web, menor probabilidad de fallo existe, por lo tanto si para servir el contenido en

la web NO intervienen servidores de [base de datos], [servidores de aplicaciones], sincronizaciones, servicios, etc y se sirve el contenido únicamente utilizando [servidores web] que entregan contenido estático (HTML, CSS, JS, etc), la probabilidad de no disponibilidad es

mínima

2 Dotar a [euskalmet.euskadi.eus] de mayor capacidad para absorber picos de carga

Al simplificar la infraestructura técnica de la web es mucho más sencillo:

Sobre-dimensionar la infraestructura sin aumentar

exponencialmente los costes

Ampliar fácilmente la infraestructura ante picos puntuales

… y por otro lado, las necesidades operacionales (personas, soportes) se minimizan

3 Reutilizar los APIs El contenido estático se pre-genera periódicamente utilizando los APIs construidos: si internamente se consumen los mismos servicios que se ofrecen al exterior, éstos se mejoran y mantienen actualizados

4 Proporcionar componentes reutilizables

Otras iniciativas internas en Euskadi.eus o externas pueden re-utilizar estos [componentes] a modo de widgets en sus propias web

En general la base de la [solución propuesta] son los [APIs REST], así que de cara a un mayor entendimiento de la solución, a continuación se introduce someramente qué es un [API REST] y se analizan algunos ejemplos de su utilización en el ámbito meteorológico




Página:

12/100

En grandes líneas, un API es una exposición de la funcionalidad de un sistema (en este caso los sistemas de [euskalmet]) en forma de métodos públicos utilizables desde otros sistemas externos sin necesidad de que estos conozcan los detalles de la implementación interna del sistema expuesto (ej: detalles tecnológicos como base de datos, servidor de aplicaciones, lenguaje de programación, etc)

Cuando se trata de exponer funcionalidad en Internet, los APIs en la mayor parte de las ocasiones la implementación web del API se basa en [servicios web] (web services) y en más específicamente, [servicios REST] (REST Services: REpresentational State Transfer) que a muy alto nivel se basan en:

Asignar URIs inmutables a los

recursos

Por ejemplo, el tiempo de hoy puede tener una URL como

http://api.euskalmet.eus/weather/forecasts/today

Utilizar los verbos del protocolo HTTP

GET PUT POST DELETE

Elemento http://api.euskalmet.eus/weather/forecasts/today

http://api.euskalmet.eus/weather/forecasts/2017-01-01

Previsión del día dado

Remplazar una previsión por otra nueva

Crear una nueva previsión

Borrar la previsión

Colección http://api.euskalmet.eus/weather/forecasts

Listar todas las previsiones

Remplazar todas las previsiones por una nueva colección

Crear una nueva colección de previsiones

Borrar la colección de previsiones

Obviamente en la web muchas veces NO se exponen todos los métodos (por ejemplo los que modifican el recurso si el api es únicamente de consulta)

Descubrimiento dinámico de

acciones y recursos

Hypermedia As The Engine Of

Application State: HATEOAS

Utilizando HATEOAS un cliente REST utiliza la hipermedia para descubrir cómo interactuar con un servicio web, es decir, no necesita un conocimiento previo de cómo interactuar con el servicio web. Por ejemplo, la siguiente solicitud al servicio REST que obtiene la observación actual en bilbao:

puede tener una respuesta como:

Como se ve en el ejemplo, se [servicio REST] devuelve indicación de otros recursos como las previsiones para hoy y mañana también en bilbao

Existen más de 200 APIs relacionados con la [meteorología] registradas en [Programmable Web] https://www.programmableweb.com/category/weather/api; a continuación se resumen algunos de ellas como ejemplo de la solución:

GET /weather/current/bilbao HTTP/1.1 Host: api.euskalmet.eus Accept: application/xml

HTTP/1.1 200 OK Content-Type: application/xml Content-Length: ... <?xml version="1.0"?> [Datos de la observación en Bilbao] <links> <link rel="today" href="http://api.euskalmet.eus/forecasts/today/bilbao" /> <link rel="tomorrow" href="http://api.euskalmet.eus/forecasts/tomorrow/bilbao" /> ... </links>

https://en.wikipedia.org/wiki/Web_service

https://en.wikipedia.org/wiki/Representational_state_transfer

https://en.wikipedia.org/wiki/HATEOAS

https://www.programmableweb.com/

https://www.programmableweb.com/category/weather/api



Página:

13/100

API ACCU Weather: [API DOCS]

Toolkit / SDK Toolkit Java / JS / otros

Widgets HTML / Android / TV / ..

Capas geográficas (Mapas)

Radar / Satélite

Datos meteorológicos

Alertas

Observación / localización

- Datos de la localización (lat / long / alt)

- Fecha / hora

- Temperatura actual

- Sensación de temperatura - Temperatura max / min últimas 6 h / 12 h / 24 h

- Precipitaciones (ultimas 1 h / 6 h / 9 h / 12 h / 18 h / 24 h) - Humedad

- Viento (velocidad / dirección) - presión atmosférica

- % nubosidad

- visibilidad

- humedad

- Indice UV

- Nivel de polen

- Iconos

- Texto

Datos históricos observación / localización

Datos de observación / localización para una fecha dada

Previsión / localización Por días 1 / 5 / 10 / 15 días

Datos:

- Salida / puesta del sol - Horas de sol - Fase lunar

- Nivel de polen - Dos predicciones: día / noche con los siguientes valores

o Temperatura (máx / min) o Sensación de temperatura o Lluvia (mm) o Nieve o Hielo o Horas de precipitación o % de nubosidad o visibilidad

o Probabilidad de lluvia/ tormenta / nieve / hielo o Viento (velocidad, dirección) o Ráfagas de viento (velocidad / dirección) o Iconos o Texto

Por horas 1 h / 12 h / 24 h / 72 h / 120 h

Datos:

- Temperatura (máx / min)

- Sensación de temperatura

- Lluvia (mm)

- Nieve

- Hielo

- Horas de precipitación

- % de nubosidad

- Probabilidad de lluvia/ tormenta / nieve / hielo - Viento (velocidad, dirección)

- Ráfagas de viento (velocidad / dirección) - Iconos

- Texto

Datos históricos previsión / localización

Previsiones / localización para una fecha dada (pasada)

Índices Los índices dan una medida sobre la posibilidad de que las condiciones ambientales sean buenas para actividades tan dispares como [ciclismo], [barbacoa], [vuelos], etc

- MetaData: Consulta de los índices disponibles (ver lista completa de índices)

- Consulta de los valores de los índices de 1 día, 5 días, 10 días o 15 días

Otros Locations Obtener una lista de las localizaciones para las que se hacen predicciones

https://www.accuweather.com/

https://developer.accuweather.com/

http://downloads.accuweather.com/

https://developer.accuweather.com/accuweather-imagery-api/apis

https://developer.accuweather.com/accuweather-weather-alarms-api/apis

https://developer.accuweather.com/accuweather-current-conditions-api/apis





https://developer.accuweather.com/accuweather-forecast-api/apis



https://developer.accuweather.com/accuweather-indices-api/apis

https://developer.accuweather.com/list-available-daily-indices

https://developer.accuweather.com/accuweather-locations-api/apis



Página:

14/100

API Open Weather Map: [API DOCS]


Widgets


Precipitaciones

Nubes

Presión

Temperatura

…


Alertas


- Datos de la localización (lat / long / alt)

- Fecha / hora

- Temperatura

- Sensación de temperatura - Lluvia (mm

en las últimas 3 horas)

- Nieve (volumen en las últimas 3 horas) - Humedad

- Viento (velocidad / dirección) - Ráfagas de viento (velocidad / dirección) - presión atmosférica (a nivel del mar y en la localización) - % nubosidad

- humedad

- Iconos

- Texto

Índice UV / localización

Índice de polución (CO2) / localización


Datos de la observación / localización a una fecha dada

Es posible una descarga completa de los datos

Previsión / localización

Por días: hasta 16 días

Por horas: hasta 5 días en tramos de 3 horas

Datos (en ambas consultas)

- Datos de la localización

- Temperatura (max / min / mañana / mediodía / noche)


- Viento (velocidad / dirección) - Ráfagas de viento (velociad / dirección) - presión atmosférica (a nivel del mar y en la localización) - Lluvia (mm) - Nieve

- % nubosidad

- humedad - Iconos sobre diversos parámetros (lluvia / nieve / nubosidad…)

- Texto


descarga completa de las previsiones realizadas a lo largo del tiempo

Otros Datos de estaciones Conectar estaciones personales al sistema y enviar datos

Consulta de datos de estaciones

https://openweathermap.org/

https://openweathermap.org/api

https://openweathermap.org/widgets-constructor

https://openweathermap.org/api/weathermaps

https://openweathermap.org/triggers

https://openweathermap.org/current

https://openweathermap.org/current

https://openweathermap.org/api/uvi

https://openweathermap.org/api/uvi

https://openweathermap.org/history



https://openweathermap.org/forecast16

https://openweathermap.org/forecast5

https://openweathermap.org/stations



Página:

15/100

API AerisWeather: [API DOCS]

Toolkit / SDK Android / iOS

JavaScript

Maps


Radar

Satélite

Radar + Satélite


Alertas


- Localización (lat / long / alt / nombre…) - Fecha / hora

- Salida / puesta de sol



- Lluvia

- Nieve

- Humedad

- Viento (velocidad / dirección) - presión atmosférica

- % visibilidad - humedad

- Índice UV

- Iconos

- Texto




Hasta 14 días en intervalos de 1 o 3 horas

Datos

- Datos de la localización (lat / long) - Temperatura (max / min / media)

- Sensación de temperatura (max / min)

- Viento (velocidad / dirección: max / min) - Ráfagas de viento (velocidad / dirección) - presión atmosférica (en la localización) - Lluvia (mm) - Nieve

- % nubosidad

- Humedad

- Índice UV

- Iconos sobre diversos parámetros (lluvia / nieve / nubosidad…)

- Texto


descarga completa de las previsiones realizadas a lo largo del tiempo


…también de que las condiciones ambientales influyan en enfermedades como artritis o resfirados

Otros Mareas

Astronomía fase lunar

hora salida-puesta de sol

Inundaciones

Terremotos

Fuegos

Rayos

Places - Ciudades - Aeropuertos - Códigos Postales - Ríos

https://www.aerisweather.com/

https://www.aerisweather.com/support/docs/api/

https://www.aerisweather.com/support/docs/toolkits/

https://www.aerisweather.com/support/docs/api/reference/endpoints/advisories/

https://www.aerisweather.com/support/docs/api/reference/endpoints/forecasts/

https://www.aerisweather.com/support/docs/api/reference/endpoints/forecasts/

https://www.aerisweather.com/support/docs/api/reference/endpoints/indices/

https://www.aerisweather.com/support/docs/api/reference/endpoints/tides/

https://www.aerisweather.com/support/docs/api/reference/endpoints/sunmoon/

https://www.aerisweather.com/support/docs/api/reference/endpoints/droughts-monitor/

https://www.aerisweather.com/support/docs/api/reference/endpoints/earthquakes/

https://www.aerisweather.com/support/docs/api/reference/endpoints/fires/

https://www.aerisweather.com/support/docs/api/reference/endpoints/lightning/

https://www.aerisweather.com/support/docs/api/reference/endpoints/places/

https://www.aerisweather.com/support/docs/api/reference/endpoints/places-airports/

https://www.aerisweather.com/support/docs/api/reference/endpoints/places-postalcodes/

https://www.aerisweather.com/support/docs/api/reference/endpoints/rivers/



Página:

16/100

API Weather Underground: [API DOCS]


Widgets

Consola de test


Radar

Satélite

Radar + Satélite


Alertas


- Datos de la localización (lat / long / altura / nombre / estado / zip code…) - Estación

- Fecha / hora

- Salida / puesta de sol


- Sensación de Temperatura

- Lluvia (última hora) - Nieve

- Humedad

- Viento (velocidad / dirección) - presión atmosférica (actual y tendencia) - % visibilidad

- humedad

- Índice UV

- Iconos

- Texto - URL de la previsión




Próximos 3 días / 10 días

Por horas: hoy / próximos 10 días

Datos

- Datos de la localización (lat / long) - Temperatura (max / min / media)

- Sensación de temperatura (max / min)

- Viento (velocidad / dirección: max / min) - presión atmosférica (en la localización) - Lluvia (mm) - Nieve

- % nubosidad

- Humedad

- Índice UV

- Iconos sobre diversos parámetros (lluvia / nieve / nubosidad…)

- Texto



…también de que las condiciones ambientales influyan en enfermedades como artritis o resfirados

Otros GeoLookup A partir de un identificador de una localización (ej: San_Francisco) devuelve datos geográficos (latitud / longitud), código postal y la lista de estaciones meteorológicas cercanas

https://www.wunderground.com/

https://www.wunderground.com/weather/api/d/docs

https://www.wunderground.com/weather/api/d/docs?d=resources/apigee-console

https://www.wunderground.com/weather/api/d/docs?d=layers/radar

https://www.wunderground.com/weather/api/d/docs?d=layers/satellite

https://www.wunderground.com/weather/api/d/docs?d=layers/radar-satellite

https://www.wunderground.com/weather/api/d/docs?d=data/alerts

https://www.wunderground.com/weather/api/d/docs?d=data/conditions

https://www.wunderground.com/weather/api/d/docs?d=data/conditions

https://www.wunderground.com/weather/api/d/docs?d=data/history



https://www.wunderground.com/weather/api/d/docs?d=data/forecast



https://www.wunderground.com/weather/api/d/docs?d=data/forecast10day

https://www.wunderground.com/weather/api/d/docs?d=data/hourly

https://www.wunderground.com/weather/api/d/docs?d=data/hourly10day

https://www.aerisweather.com/support/docs/api/reference/endpoints/indices/



Página:

17/100

API AEMET: [API DOCS]

Observación convencional

- Mensajes de observación

- Datos de observación

Redes especiales - Radiación global, directa o difusa

- Perfiles verticales de ozono

- Datos de contaminación de fondo

- Contenido total de ozono

Red de Rayos - Mapa con los rayos registrados

Información de satélite

- Imágenes de productos derivados de satélite

Red de radares - Imagen gráfica radar regional

- Imagen composición nacional radares

Valores climatológicos

- Climatologías diarias / mensuales / anuales

- Valores normales / extremos

- Inventario de estaciones

Productos climatológicos

- Balance hídrico nacional

- Resumen mensual climatológico nacional

- Avance mensual climatológico

- Capas SHAPE de estaciones climatológicas

Predicción climática

(redirige a la web -no es dato consumible-)

- Proyecciones regionalizadas de cambio climático para el siglo XXI: datos y gráficos

- Predicción mensual del tiempo actual estandarizado

- Boletín de predicción estacional

Predicciones normalizadas en texto

- Predicción nacional / comunidad autónoma / provincia para hoy / mañana / pasado / pasado mañana

- Predicción nacional / comunidad autónoma / provincia a medio plazo

- Predicción nacional / comunidad autónoma / provincia de tendencia

Predicción marítima - Predicción marítima de alta mar

- Predicción marítima costera

Mapas y gráficos - Mapas significativos

- Mapas de análisis

Avisos - Fenómenos meteorológicos adversos

Índices de incendios - Niveles de riesgo

La web [open data] de [AEMET] merece un análisis detallado puesto que como entidad de servicio público es similar a euskalmet. En un primer análisis a muy alto nivel se pueden destacar los siguientes aspectos:

Estrategia de exposición de datos

La orientación (estrategia técnica) es ofrecer el acceso a nivel fino (fine-grained), es decir, se ofrecen gran cantidad de datos individuales que el reutilizador debe orquestar o componer para crear una visión propia. Esta estrategia es opuesta a la de servicios más generalistas como ACCU-WEATHER que ofrecen servicios que devuelven datos más agregados -quizá mezclando predicciones de meteorología, mar, UV, etc- para facilitar el consumo

… en definitiva: los datos se exponen desde la oferta en lugar de hacerlo desde el punto de vista de la demanda, lo cual es lógico dado AEMET es la

http://www.aemet.es/

https://opendata.aemet.es/centrodedescargas/inicio



Página:

18/100

fuente de los datos

… sin embargo, para el caso de [euskalmet], quizá hay que hacer la reflexión de que estrategia seguir:

1. Ofrecer los datos a nivel fino (desde el punto de vista de la oferta)

2. Ofrecer los datos agregados (desde el punto de vista de la demanda)

3. Ambas

Acceso y Documentación Como se ha señalado en el punto anterior, los datos se ofrecen a nivel fijo y desde el punto de vista de la oferta;

El acceso a los mismos puedes ser un poco complejo y técnicamente una parte de los servicios simplemente devuelve una URL donde está accesible un fichero con los datos (lo que sugiere que posiblemente estos ficheros sean pre-generados periódicamente para mejorar el rendimiento y no “atacar” directamente a la DB o fuente de los datos)

La documentación de los servicios es exhaustiva y en la línea de lo que se pretende en el presente proyecto

… por lo tanto, [AEMET] es una referencia en cuanto a que es una entidad similar a [euskalmet] pero se tendrán también en cuenta otros servicios desde la iniciativa privada.



Página:

19/100

A la vista de las APIs anteriores, se pueden extraer una serie de conclusiones y buenas prácticas:

Obviamente [euskalmet] dispone de muchos y más variados datos que los ejemplos anteriores, pero estos son una buena base a la hora de tomar referencias en cuanto a cómo crear los [APIs] y gestionarlos

1. Todas las APIs ofrecen tres grandes bloques con los siguientes datos (caso más completo) en los que se mezclan datos diversos para dar una visión general

Alertas

Observación actual / localización

- Datos de la localización (lat / long / alt / código postal / nombre / provincia…) - Identificador de la estación - Fecha / hora de la observación

- Salida / puesta del sol - Horas de sol - Fase lunar - Temperatura actual


- Temperatura max / min últimas 6 h / 12 h / 24 h - Lluvia (ultimas 1 h / 6 h / 9 h / 12 h / 18 h / 24 h)

- Nieve (ultimas 1 h / 6 h / 9 h / 12 h / 18 h / 24 h) - Humedad

- Viento (velocidad / dirección) - Ráfagas de viento (velocidad / dirección) - presión atmosférica (a nivel del mar / en la localización) - % nubosidad

- visibilidad

- humedad

- Índice UV - Nivel de polen

- Iconos (general / nubosidad / precipitaciones) - Textos

Previsión / localización La previsión se realiza a uno / varios días vista y por horas

Por días 1 / 5 / 10 / 15 días

- Datos de la localización (lat / long / alt / cp / nombre…) - Salida / puesta del sol - Horas de sol - Fase lunar

- Nivel de polen - Índice UV (dia) - Dos predicciones: día / noche con los siguientes valores

o Temperatura (máx / min) o Sensación de temperatura o Lluvia (mm) o Nieve o Hielo o Horas de precipitación o % de nubosidad

o visibilidad o Probabilidad de lluvia/ tormenta / nieve / hielo o Viento (velocidad, dirección) o Ráfagas de viento (velocidad / dirección) o Iconos o Texto

Por horas 1 h / 12 h / 24 h / 72 h / 120 h

- Temperatura (máx / min)


- Lluvia (mm)

- Nieve

- Hielo - Horas de precipitación

- % de nubosidad

- Probabilidad de lluvia/ tormenta / nieve / hielo

- Viento (velocidad, dirección)

- Ráfagas de viento (velocidad / dirección) - Iconos

- Texto

Mapas Radar + Satélite

(la [observación] / [previsión] de [nivel de polen] / [índice UV] se incorpora en los datos de previsión / localización en la mayor parte de los ejemplos, aunque en algún caso se ofrecen como APIs independientes)

2. Algunas APIs incorporan funcionalidades HATEOAS, por ejemplo, se indican las URIs de [previsiones] al devolver la [observación] actual

3. Existe un sitio web específico para la documentación de las APIs y en ocasiones se ofrece una herramienta de TEST

4. Para utilizar las APIs es necesario registrarse previamente y obtener un [API Key]; dado que la mayor parte de

los servicios son de pago, este [API Key] limita el número de llamadas posibles o las funcionalidades que se ofrecen



Página:

20/100

5 Proyecto

De cara a conformar un proyecto gestionable, los objetivos se pueden agrupar en dos fases con sub-objetivos:

FASE I:

Análisis de datos disponibles y exposición de servicios

Objetivo 1

Análisis 1. Analizar los datos disponibles en los sistemas [backend] de

[euskalmet] para:

a. Identificar los datos disponibles y que pueden ser expuestos como datos abiertos En esta FASE I no se pone el foco en el origen del dato (dónde está el dato); únicamente se identifica qué datos hay disponibles

b. Diseñar los [APIs] REST: URIs / mensajes

2. Análisis y arquitectura técnica del [repositorio común]

3. Diseñar exposición en la infraestructura [LOD] de [OpenData Euskadi] y en otros servicios como [GeoEuskadi]

Objetivo 2

DOCs Diseñar y construir un sitio web api.euskalmet.euskadi.eus/docs donde se accederá a:

Documentación de los APIs y datos disponibles

TEST de los APIs

Objetivo 3

Construir 1. Construir el [repositorio común] de información del que se

alimentarán los [servicios REST]

2. Construir los [APIs] REST en api.euskalmet.euskadi.eus

a) Aplicación web para la auto-gestión y gestión interna de [API Keys]

b) API common services: (authentication, logging, accounting, throtling / rate limiting, API routing, etc)

c) Implementar las funciones definidas en el análisis en base a orígenes de datos mock (datos origen simulados)

3. Despliegue completo de la solución en tres entornos: DES/PRU/PROD

4. Validar la solución a nivel funcional y técnico (escalabilidad)

Objetivo 4

Componentes Web / Móvil

Reutilizando los [APIs] REST, construir los servicios de [servidor de aplicaciones] que generan [componentes HTML] para la web / móvil

IMPORTANTE

FASE II: Objetivo 1 1. Analizar los orígenes de los datos en los [sistemas backend]

Apertura de datos meteorológicos: Exposición como datos abiertos

[OpenData] de datos procedentes de [euskalmet] y renovación de los canales de difusión de información

Los [APIs] REST construidos según los objetivos anteriores se basan en datos simulados (datos mock) puesto que NO se ha abordado aún la FASE II en la que se analiza y construye la extracción de datos reales desde [sistemas backend] de [euskalmet] y se hace la importación en el [repositorio común]

Esta FASE I tiene como objetivo validar la solución y construir la infraestructura básica (ver schema-first API design)

https://dev.to/yos/schema-first-api-design--41de



Página:

21/100

Obtención de datos backend y exposición final de servicios

Análisis de [euskalmet] y diseñar los sistemas de extracción de los datos para que estos sean accesibles a los servicios [APIs] REST y a la infraestructura [LOD] de [opendata Euskadi]

En esta FASE II una vez que se ha identificado qué datos en la FASE I, se pone el foco en el origen del dato (dónde está el dato) y cómo hacerlo accesible

Objetivo 2

Construcción 1. Construir los mecanismos de extracción / transformación y

carga en el [repositorio común] de los datos para cada origen

2. Conectar los [servicios REST] construidos en la FASE I al [repositorio común] para que devuelva datos reales

Objetivo 3

Despliegue 1. Desplegar y validar la solución

2. Carga inicial de datos y validación de los sistemas de actualización periodica

3. Reconstruir el portal [www.euskalmet.euskadi.eus] en base a

los [componentes web] creados en la FASE I y que ahora se basan en datos reales (ver nota a continuación)

IMPORTANTE:

Para re-construir la presencia web / móvil / tv en base a los datos expuestos, es necesario hacer previamente un trabajo de:

- Diseño gráfico de la web

- Usabilidad

- Accesibilidad

- Creación del marcado HTML / CSS / JS de los [componentes web]

para la globalidad de la web así como para cada [componente]

El producto de este trabajo de diseño / usabilidad / creación de marcado / etc, es la entrada para los objetivos de:

Creación de [componentes] a partir de los datos (FASE I – Objetivo 4)

Creación de la web [www.euskalmet.euskadi.eus] (FASE II – Objetivo 3)

Este trabajo de diseño / usabilidad / creación de marcado / etc NO forma parte del alcance del proyecto objeto del presente documento y será abordado aparte en otra contratación ad-hoc

En el presente proyecto:

Se construirán los mecanismos para transformar los datos expuestos en los APIs en [componentes] web individuales

Se colaborará con la empresa adjudicataria del proyecto de diseño en la construcción de la página web [euskalmet.euskadi.eus] en lo que se refiere a la integración de los [componentes web] en dicha página

Es decir, NO está en el alcance de este proyecto la construcción del portal [euskalmet.euskadi.eus], pero SI la construcción de los [componentes web] a partir de los datos y el soporte a la empresa que construya finalmente el portal



Página:

22/100

6 Descripción del Proyecto

En el presente puntos se describe en detalle cada una de las fases y objetivos resumidos anteriormente.

6.1 FASE I: Análisis de datos disponibles y exposición de servicios

6.1.1. Objetivo 1: Análisis

6.1.1.1. Identificar datos a exponer

A partir de:

Ejemplos de otras entidades que ofrecen datos meteorológicos en formato API (ver conclusiones de la [solución propuesta] anteriormente en el presente documento)

Los datos actualmente ofrecidos por [euskalmet] ya se en [opendata.euskadi.eus] o en la propia web www.euskalmet.euskadi.eus

Los datos que funcionalmente se consideren necesarios para cumplir los objetivos del proyecto

… se debería tener una visión general de qué datos se quieren exponer

Un punto de partida es el análisis de la información disponible en [euskalmet.euskadi.eus] y que se adjunta en el mapa mental incrustado en este documento y que se resume a continuación separando la relación por los siguientes bloques (que NO sigue la estructura de la web sino una agrupación que se ha considerado más conveniente para la exposición del presente documento)

1 Alertas Datos / Mapas

2 Predicciones Datos / Mapas

3 Lecturas Datos / Mapas

4 Mapas Mapas

5 Modelos Mapas

Durante la ejecución de esta tarea de [identificación] de datos se intentará hacer un ejercicio de abstracción de la situación actual: si bien los datos actuales y como éstos se ofrecen es un excelente punto de partida, en esta fase se debería intentar dar un paso más y mejorar -si es posible- la ergonomía de los datos:

Exponiendo servicios que mezclen datos que ahora se ofrecen independientemente

Enriqueciendo los datos incorporando otros formatos, datos de otras fuentes, etc

Comparando cómo se ofrecen los datos actualmente en [euskalmet] frente a cómo lo hacen otras iniciativas como las anteriormente resumidas

etc

Es posible que finalmente no haya margen de mejora respecto a la situación actual, aun así, la realización de esta actividad se intentará buscar estos puntos de mejora y no se asumirá la situación actual tal cual para trasponerla directamente a la nueva infraestructura técnica.

Esta FASE I tiene como objetivo validar la solución y construir la infraestructura básica.

El producto de esta fase es una infraestructura de exposición de servicios en forma de API REST en la que se han implementado a modo de maqueta aquellos identificados en el análisis.

Si bien el producto NO es usable directamente (no se basa en datos reales) si sirve para tener una visión global del producto final antes de abordar la parte más compleja del proyecto: la extracción y adecuación de los datos desde los [sistemas backend]




Página:

23/100

[1] - Alertas

Avisos meteorológicos:

Hoy

Mañana

Pasado mañana

(móvil)

[2]-Predicciones

Predicción meteorológica Euskadi - General

Euskal Herria – Eguraldia

(versión móvil)

Por comarcas / población



Página:

24/100

Zona Litoral Valles Cantábricos Montaña Catábrica Cuencas Interiores Montaña Meridional Valle del Ebro Pirineo Gran Bilbao Donostialdea Vitoria-gasteiz

Península Ibérica

Madrid

Bilbao

Barcelona

Valencia

Sevilla

Santiago de Compostela

Lisboa

Europa

Madrid Paris Londres Roma Varsovia Estocolmo Berlin Budapest Atenas

Predicción meteorológica:

Tendencias de 6 días



Página:

25/100

Predicción marítima:

Hoy

Manaña

Pasado mañana

(versión móvil)

ItsasEus:

(Mediciones costeras)

Hoy

Mañana

Pasado

Previsión índices de ultravioleta:

Hoy

Mañana

Pasado mañana

Predicción por zonas para temperaturas altas persistentes y temperaturas altas extremas



Página:

26/100

[3] – Lecturas

Lectura de estaciones meteorológicas:

(Lecturas horarias)

Velocidad media del viento

Velocidad máxima del viento

Dirección media del viento

Sigma de la velocidad del viento

Sigma de la dirección del viento

Temperatura del aire

Humedad relativa del aire

Presión atmosférica

Irradiación solar


(Estadísticas diarias)









Irradiación solar



Página:

27/100


(Gráficos Hidrometeorológico)

Lecturas Control viento

Control calidad aguas

Viento

Temperatura y humedad

Precipitación

Presión

Irradiación solar

Nivel/Caudal

Oleaje

Múltiple (temperatura, humedad, precipitación,presión)

Rosa de los vientos

Estadísticas Temperatura y humedad

Prueba para acumulados


(Boletines diarios)

Temperatura

Humedad

Precipitaciones

Viento

Nicel cm

% datos


(Climatología mensual por dias)

Temperatura

Humedad

Precipitaciones

Viento

Nicel cm

% datos



Página:

28/100


(Comparativa de estaciones por meteoros)








Precipitación


Irradiación solar

Radiación solar ultravioleta


(Exportación de datos)

Lecturas

Estadísticas

Mediciones de polen

Bilbao

Vitoria-Gasteiz

Donostia-San Sebastián

(los datos los facilita el dpto de salud)



Página:

29/100

Oceonometeorológico;

Boya

Oleaje

Meteorología

Corrientes

Salinidad

Temperatura del agua

Radar

Velocidad del viento

Plataforma

Dirección

Temperatura / presión

Velocidad

Radiación/visibilidad

Vigilancia de avenidas

Niveles y precipitación en gráfica

Temperatura

Humedad

Precipitación

Viento

Nivel 1

Nivel 2

Nivel 3



Página:

30/100

[4] - Mapas

Mapa de temperatura

Hoy

Último valor

Temperatura media del aire

Temperatura minima del aire

Temperatura maxima del aire

Ayer

Temperatura minima del aire

Temperatura máxima del aire

Mapa de precipitación

Hoy

Último valor

Precipitación acumulada en la última hora

Precipitación acumulada

Precipitación máxima en los 10 minutos

Precipitación máxima en 1 hora

Ayer

Precipitación acumulada

Precipitación máxima en 1h

Mapas (Euskadi)

Precipitación (último valor)

MAX-Rayos (último valor)

Isobaras

Indice ultravioleta

Humedad

Viento

Temperatura



Página:

31/100

Mapas (Mar Cantábrico)

Altura de la ola y viento a 10 metros

Longitud media de ola período y dirección

Período y dirección de la ola pico)

Mapas (Península Ibérica)

Temperatura

Precipitación

Viento

Presión

Geopotencial e Isotermas a 500 hPa


Mapas (Europa)

Frentes y presión

Temperatura

Precipitación

Viento

Presión





Página:

32/100

Mapas: (Meteosat)

Infrarojo

Visible

Vapor de agua

Radar kapildui

Hoy


Mapas de largo alcance

Productos de máxima reflectividad

Ayer




Anteayer




Mapas

PPI

CAPPI

Max-Rayos

Perfilador punta galea

Hoy

VIENTO, Alta resolución

VIENTO, Baja resolución

TEMPERATURA VIRTUAL

Ayer



TEMPERATURA VIRTUAL

Anteayer



TEMPERATURA VIRTUAL



Página:

33/100

[5] - Modelos

- Europa - Península Ibérica

Geopotencial e isotermas a 500 hPa

Geopotencial e isotermas a 850 hPa

Presión a nivel del mar

Temperatura en superficie

Viento en superficie

Precipitación cada 6 horas

- Norte de la Península ibérica - Mapa regional - Euskadi

Humedad relativa en superficie




- Euskadi

Humedad relativa en superficie




- Mar Cantábrico + océano atlántico - Mar Cantábrico - Mar Costa vasca

Altura de ola (m) y viento a 10 metros (knots)

Longitud media de ola, periodo y dirección

Periodo y dirección de ola pico



Página:

34/100

6.1.1.2. Viabilidad de obtener el dato

Identificar si es posible obtener el dato en los [sistemas backend] de [euskalmet] (o en otros orígenes de datos), es decir, si el dato está disponible

IMPORTANTE: En esta fase I NO se trata de analizar el origen del dato, únicamente se trabajará si el dato está disponible o no y se identificará el origen; en la fase II se trabajará la extracción del dato

Para cada uno de los datos (alertas / observaciones / previsiones / mapas / localizaciones / etc) se cumplimentará una ficha, una versión muy simple de la cual puede ser:

Área alertas / observaciones / previsiones / mapas / localizaciones etc

Dato Ej: Temperatura

Entidad Responsable Ej: Euskalmet / Dpto de Salud / etc

Origen(es)

Formato

Frecuencia de actualización

Condicionantes técnicos

Otros datos

NOTA: Estas fichas -o una adaptación de las mismas- pueden ser interesantes para describir el dato en el

área de documentación de api.euskalmet.euskadi.eus en incluso en las fichas de los [DataSets] de [OpenData Euskadi] (ver más adelante en el documento)

6.1.1.3. Diseñar APIs REST para cada dato

Diseñar los [servicios REST] de cada funcionalidad / dato expuesto en el [API]

Para ejecutar esta actividad se propone ampliar la ficha anterior con algunos datos específicos acerca del [servicio REST]


Dato Previsión 1 día


Origen(es)

Formato



Otros datos

EndPoint URI /forecast/{fecha}/{localización}

Métodos HTTP GET / POST / PUT / DELETE

Parámetros Explicar los parámetros

Fecha La fecha para la que se quiere obtener la previsión

Localización El identificador de la localización para la que se quiere obtener la previsión



Página:

35/100

Cabeceras HTTP Versionado

API-Key / HMAC

Mime-Type (accept)

…

Códigos de retorno Detallar los códigos de retorno:

200 La petición se ha ejecutado correctamente

404 Recurso NO encontrado (ej: NO existe la localización indicada o no hay previsión para la fecha suministrada)

400 Error de cliente (ej: algún parámetro no tiene el formato adecuado)

500 Error al procesar la petición en el servidor (error interno)

Mensajes de retorno Detallar los mensajes de retorno en los siguientes casos:

La llamada sea correcta

La llamada no sea correcta por un error de cliente

La llamada resulte en un error interno en el servidor

Los mensajes de respuesta se describirán de una forma agnóstica al formato (xml / json /…), como estructuras de datos, por ejemplo:

location Localización

lat Latitud

long Longitud

alt Altitud

name Nombre

es Español

eu Euskera

nora Códigos en NORA de la localización

code ..

Vínculos Vínculos a otros recursos REST (ver HATEOAS)

Esta aproximación metodológica va en la línea de diseñar en primer lugar el esquema del API (Schema API-First)





Página:

36/100

6.1.1.4. Análisis y arquitectura técnica del [repositorio común]

La técnica más óptima para la exposición de datos de diferentes orígenes es la creación de un [repositorio común] donde residan los datos ya transformados al formato definido para ser devueltos en los [servicios REST] del [API] público.

Este [repositorio común] es un módulo software que expone dos interfaces:

Privado de actualización de datos

Utilizado por los procesos que extraen y transforman los datos desde diferentes orígenes: se crean / actualizan y borran datos

Público de consulta de datos

[servicios REST] del [API] público utilizado por:

Internamente por el módulo de [sindicación de datos de PLATEAWeb] responsable de generar los [componentes web] y actualizar los [DataSets] [OpenData]

Externamente por las aplicaciones cliente para consultar los datos

En esta actividad, y en base al análisis sobre cada uno de los datos / funcionalidades a exponer ( las fichas) se identificarán:

Las funciones que el [repositorio común] debe exponer

La persistencia en el [repositorio común] de cada uno de los datos

A la hora de definir la persistencia de los datos en el [repositorio común] hay que tener en cuenta:

Variedad de grupos de información a publicar

Hay varios grupos de información a publicar: Alertas

Predicciones

Mediciones

Mapas

Modelos

NO todos los datos de los grupos anteriores tienen que ser obligatoriamente almacenados en una misma tecnología (ej: todo en base de datos); es perfectamente posible que cada tipo de dato tenga una persistencia propia (ej: unos datos en [DB] otros en ficheros, etc)

DB Meteorología

1a



en DBs de EJIE






de dato adapta la




común]

REPOSITORIO

COMUN

Proceso de

importación de

datos de

euskalmet

2

PLATEA WEB

Proceso de


de euskalmet a

[PLATEA Web]

5




4



REST



datos)

3




Inte

rfaz d

e a

ctu

aliz

ació

n

Inte

rfaz d

e C

on

su

lta


REPOSITORIO

COMUN

Inte

rfaz d

e a

ctu

aliz

ació

n

Inte

rfaz d

e C

on

su

lta

REPOSITORIO

COMUN

Inte

rfaz d

e a

ctu

aliz

ació

n

Inte

rfaz d

e C

on

su

lta



Página:

37/100

En cualquier caso:

La tecnología en la que los datos están almacenados (persistencia) debe ser transparente para quien utiliza el [repositorio común]:

los procesos internos de extracción / trasformación de datos

los [servicios REST] del [API] público y el módulo de [sindicación de datos de PLATEAWeb]

es decir, el [repositorio común] debe exponer servicios utilizables y abstraer de la implementación concreta de la persistencia

La cantidad de datos a almacenar

Hay casos en los que el volumen de datos a almacenar es relativamente manejable (ej: alertas, predicciones mapas o modelos), PERO hay otros casos como las mediciones donde el volumen de datos es enorme ya que hay datos disponibles de:

Lecturas horarias

Estadísticas diarias

Boletines diarios

Climatología mensual por dias

Comparativa de estaciones por meteoros

Gráficos Hidrometeorológico

Niveles de Pólen

…

lo anterior multiplicado en algunos casos por el número de estaciones (más de 100) y por el número de muestras (horarias) implica que el número de registros va a ser muy grande

En cualquier caso como ya se ha descrito, los datos se almacenarán ya transformados al formato en el que van a ser expuestos (por ejemplo si los datos se almacenaran en una DB SQL, NO debiera ser necesario hacer complejas JOINS sql)

Ejemplo: Lecturas de las estaciones

Como se puede ver en la captura de pantalla, los datos de las estaciones se pueden filtrar por [fecha / hora] y [estación], devolviéndose una serie de mediciones

Durante el análisis se decidiera exponer estos datos como en la actualidad, en el [repositorio común] se almacenaría una “fila” / ”registro” para cada combinación [fecha / hora / estación] con los datos ya agrupados y transformados en el

formato que se decida y representados por ejemplo en JSON / XML etc



Página:

38/100

Por lo tanto en esta actividad se:

Identificará la tecnología más adecuada para persistir los datos en función de su naturaleza (dato / imagen / etc) y su volumen

Se definirá la estructura de persistencia (ej: estructura de tablas -si se usa una DB-, estructura de carpetas si se usan fileSystems, esquema en backends NoSQL, etc)

Hay que recordar que desde [euskalmet] se facilitan datos e imágenes (mapas / predicciones / modelos etc)

Actualmente:

Los datos(en su mayor parte) se sincronizan utilizando la [Base de Datos]

Los ficheros se sincronizan utilizando una [fileSystem] de intercambio

Un trabajo importante a la hora de diseñar la persistencia de los datos (tomando como datos también las imágenes) se diseñar cómo han de guardarse los ficheros (imágenes fundamentalmente), es decir: la estructura de carpetas, nombre de ficheros, formatos, etc con el objetivo de que sea más sencillo:

La exposición de estos assets como datos abiertos

La construcción de los [componentes web] (ver más adelante)

Además de decidir sobre la persistencia, hay que tomar algunas decisiones arquitectónicas sobre los [servicios REST]

[1] Mecanismo de versionado del [API]

Hay varias opciones para versionar el API, entre otras:

Utilizar un versionado en el URI del endpoint

http://api.euskalmet.euskadi.eus/v1/...

http://api.euskalmet.euskadi.eus/...?version=v1

Utilizar un header de la request HTTP (como por ejemplo el media-type o una cabecera propia)

Client ===> GET /forecasts/today/bilbao HTTP/1.1 Accept: application/v1+json

Vincular el [API Key] con la versión del [API]

Se basa en:

Cada aplicación cliente tiene su propio [API Key]

Se puede almacenar la versión del [API] vigente en el momento en que se generó el [API Key]

Para cada llamada al [API] se contrasta la versión vigente en la actualidad con la versión vigente en el momento de generar el [API Key] (se supone que el cliente usa esta versión del API)

El sistema de forma transparente al cliente traduce la llamada en una versión obsoleta del API a la versión vigente

(obviamente si la aplicación cliente se adapta a la versión vigente del API deberá generar y empezar a utilizar un API Key)

Cada una de las alternativas anteriores así como otras que se puedan proponer tiene sus ventajas e inconvenientes que habrá que analizar y valorar en el ámbito del proyecto



Página:

39/100

[2]: Mecanismo de autorización / securización de uso de los servicios

Para utilizar los servicios REST es necesario que las aplicaciones cliente se registren previamente en api.euskalmet.euskadi.eus y el sistema genere una [API Key] que estará vinculada a esta aplicación cliente y que permitirá (si se considera necesario):

Limitar el uso del API (ej: número de llamadas al API / tiempo)

Limitar las funcionalidades del API (ej: en función del cliente se pueden limitar las funcionalidades disponibles)

Conocer la versión del [API] que se utiliza

Expirar los [API Key] para un cliente en caso necesario

Durante esta actividad se analizará:

El protocolo de generación del [API Key] y ciclo de vida de la misma

Crear una aplicación web de [auto-gestión] disponible en api.euskalmet.euskadi.eus donde el usuario/a responsable de la

aplicación cliente que va a hacer uso del API:

1. Registro sus datos para crear una cuenta de usuario/a

2. La aplicación envía de un correo electrónico de confirmación con un link que le redirige a una página donde:

a. Si se utiliza usuario / password el responsable del cliente debe indicar una password

b. Si se utiliza un sistema común de identificación como [giltza / B@K] simplemente se hace login

3. Una vez loggeado, el responsable solicitaría la generación de un [API Key] que podría descargarse en cualquier momento desde la web de auto-gestión

La forma de enviar el [API Key] a la hora de invocar los servicios

Cuando una aplicación invoca un [servicio REST] del [API] debe identificarse utilizando el [API Key] previamente obtenido para lo que técnicamente la forma más común es utilizar un header HTTP

Client ===> GET /forecasts/today/bilbao HTTP/1.1 Accept: application/json api-key:{the api key}

La securización de los [servicios REST]

La seguridad es un aspecto importante a analizar puesto que hay que balancear el nivel de seguridad vs ergonomía del [API REST]

Disponer mayores medidas de seguridad implican una menor facilidad de uso del API (ergonomía)

Hay que analizar la conveniencia de utilizar mecanismos como:

Protocolo seguro HTTPS

Utilizar mecanismos de firma simétrica como HMAC (ver detalles)

Client ===> GET /forecasts/today/bilbao HTTP/1.1 Host: api.euskalmet.euskadi.eus Accept: application/json Authentication: hmac {client_id}:{digest}

El {digest} es calculado por el cliente aplicando una firma hmac a la URI

utilizando el {api key} (que el cliente mantendría en secreto)

digest = base64encode( hmac("sha256", {the api key}, "GET+/forecasts/today/bilbao"))

El servidor (que también conoce el {api key} secreto compartido con el cliente)

volvería a calcular el {digest} de la misma forma y si ambos coinciden se puede concluir que el cliente es legítimo

Para evitar ataques de replay de las llamadas (un man-in-the-middle puede

http://www.izenpe.euskadi.eus/informacion/bak/s15-content/es/

https://es.wikipedia.org/wiki/HMAC

http://restcookbook.com/Basics/loggingin/



Página:

40/100

capturar las llamadas al API y volverlas a ejecutar sin necesidad de conocer el [API Key]) se puede incluir un time-stamp en el texto que se firma:

digest = base64encode( hmac("sha256", {the api key}, "GET+/forecasts/today/bilbao+{timestamp}"))

En la validación en el servidor, NO se admitirán llamadas en las que haya pasado un umbral razonable de tiempo desde el indicado en el time-stamp

En el caso de los datos de [euskalmet] quizá no tiene sentido disponer de grandes medidas de seguridad puesto que:

Son [APIs] eminentemente de consulta (no se modifican datos)

Son datos públicos

Un ataque del hombre del en medio (MIMA=Man in the Middle Attack) que pueda alterar los datos originales, en principio no tiene gran impacto

… en cualquier caso, es un análisis que ha de hacerse en el ámbito del proyecto

De lo anterior se deriva que será necesario Construir la aplicación web de [auto-gestión] de [api-keys] con las siguientes funcionalidades:

Públicas

(accesible a cualquier persona responsable de una aplicación cliente)

Registro

Acceso: se ofrecerán dos opciones usuario / password o utilizar un sistema común de identificación como [giltza], [google], [Facebook] o [twitter]

Auto-gestión de [API-KEYs]: solicitud de generación / descarga / eliminación

Eliminación de cuenta

Privadas

(para responsables del servicio)

Con el objetivo de atender a incidencias y gestionar el servicio, se construirá un módulo privado de la aplicación web de [auto-gestión] de [api-keys] cuyo acceso estará limitado a usuarios/as corporativos identificados con [XLNets] y que tendrá las siguientes funcionalidades:

Buscar usuarios/as a partir del correo electrónico y otros parámetros que se soliciten al usuario/a durante el registro

Gestionar las [API-Keys]: solicitud de generación / descarga / eliminación

Eliminación de la cuenta

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

https://en.wikipedia.org/wiki/Man-in-the-middle_attack



Página:

41/100

[3]: Otros servicios comunes del [API REST]

Es posible que sea necesario implementar algunos otros servicios comunes además de los anteriormente mencionados;

Logging Log de las llamadas

Accounting Contabilizar el uso de servicios a nivel global y por API-Key

Throtling / rate limiting / function limiging

Modulación del número de invocaciones al [API] o las funciones disponibles en función de:

La aplicación cliente

La carga del sistema

Otros parámetros

API Routing Enrutado de llamadas al [API] en función de la URI

El objetivo de este proyecto es disponer una infraestructura de exposición de [servicios REST] para datos de [euskalmet], NO se trata de crear una infraestructura general / común de exposición de [servicios REST] por lo que se intentará minimizar la complejidad técnica prescindiendo de aquellos componentes que NO sean estrictamente necesarios (ej: [rate limiting], [API routing], etc)

En cualquier caso, los componentes a desplegar se analizarán y decidirán en el ámbito del proyecto

En este [paquete de trabajo] por lo tanto, el producto a obtener el análisis de requisitos del [repositorio común] lo cual incluye (entre otros):

Tecnología de exposición de servicios REST

Tecnología(s) de persistencia de los datos



Página:

42/100

6.1.1.5. Exposición en la infraestructura [LOD] de [OpenData Euskadi] y otros servicios

1.1.1.1. OpenData euskadi

La infraestructura [LOD=Linked Open Data] de [OpenData Euskadi] tiene los siguientes componentes:

El [núcleo] del sistema es el [triple store] que a un nivel de abstracción alto es una [base de datos de grafos (triples)] que es donde residen los datos enlazados.

Los datos del [triple-store] pueden ser consultados desde la web de [opendata euskad]

o Por personas utilizando una interfaz de usuario que (basada en YASGUI) que permite lanzar consultas [SPARQL] al [triple-store] y visualizar los resultados

o Por agentes automáticos lanzando directamente consultas [SPARQL] al [triple-store]

Los datos almacenados en el [triple-store] se pueden consultar también en formato web utilizando ELDA

En [opendata Euskadi] se han normalizado las URIs (Universal Resource Identifier) de los recursos de forma que cualquier recurso almacenado en el [triple-store] tendrá una URI consistente con la NTI (Norma Técnica de Interoperabilidad):

{es|eu}.euskadi.eus/{sector}/{domain}/{class}/{identifier}

Un [middleware: URI handler], que enruta las URIs al sistema concreto (ELDA, YASGUI, [triple-store]…) en función de la URL y del MIME-Type solicitado.

Cuando datos de un sistema [backend] interno (ej: una base de datos) se quiere exponer como datos enlazados en la infraestructura LOD de [opendata Euskadi] se construye un sistema de [extracción / transformación] de datos que utilizando el [API] de la infraestructura [LOD] carga la información en el [triple-store]

En este caso, los datos meteorológicos almacenados en el [repositorio común] se exportarán al [triple-store] de [open data euskad] como datos enlazados.

Sistemas INTERNOS

Middleware

ELDA

BackEnd

Extracción / Transformación de Datos

Triple Store

REST Service

API

UI SPARQL EndPoint

YASGUI

http://yasgui.org/

http://epimorphics.github.io/elda/



Página:

43/100

Habitualmente cuando se aborda un proyecto de carga y exposición de datos en la infraestructura LOD las actividades a realizar son:

6.1.1.6. Datos GeoEspaciales: Directiva Inspire

Se analizará el impacto de la directiva inspire para la exposición de datos geo-espaciales y su impacto en el proyecto, contando con la colaboración del servicio [GeoEuskadi]

En función de este análisis puede ser necesaria la construcción de integraciones de algunos datos con [geo-euskadi]

1. Identificar la [ontología] en base a la que representar los datos

Una ontología a un nivel de abstracción de datos muy alto es una definición estándar de un objeto y sus propiedades

Habitualmente las ontologías ya están definidas (son estándares) y se suelen re-utilizar aunque también es posible extender ontologías existentes e incluso crear otras nuevas

2. Identificar las [relaciones] entre los objetos

La web semántica se fundamenta en las [relaciones] por lo que es muy importante trabajar este punto

3. Definir las URIs de los objetos

En este punto es de aplicación la normativa que se ha definido para las URIs en [opendata Euskadi] aunque en ocasiones la URI puede venir dada externamente y hay que mantenerla; en estos casos el [middleware] se encarga de la traducción de URIs

4. Analizar la trasposición de los datos del [sistema backend] a la [ontología] definida

5. Implementar la extracción de los datos y la carga en el [triple-store] utilizando como ayuda los [API]s de la infraestructura [LOD]

http://www.idee.es/europeo-inspire



Página:

44/100

6.1.2. Objetivo 2: Documentar

A partir de toda la información obtenida en el análisis (objetivo I), se abordarán las siguientes actividades para crear un sitio web de documentación en api.euskalmet.euskadi.eus/docs

Diseño gráfico y arquitectura de la

información

Diseño gráfico del sitio web

Arquitectura de la información: o Secciones de la web o Contenidos de cada sección y su tipo (ej: información, noticia, faq, etc) o Otros

Construcción del sitio de

documentación

Para la construcción del sitio de documentación se utilizarán las herramientas comunes que soportan la presencia web del [Gobierno Vasco]: [PLATEA Web] lo que incluye:

1 Creación de las plantillas de página de portal

2 Carga de los contenidos generales -información / faqs / etc-(en euskera, español e inglés) utilizando las plantillas de [PLATEA Web] identificadas durante la actividad de [diseño gráfico y arquitectura de la información]

3 Carga de la documentación de los [servicios REST] del [API] en base a las fichas elaboradas durante el análisis (objetivo 1)

Para lograr este objetivo hay -en grandes líneas- dos opciones NO excluyentes:

Utilizar una herramienta de documentación de APIs

(opción preferida)

La iniciativa [Open API] tiene como objetivo estandarizar un formato de descripción de los API REST independiente del fabricante

En base a esta iniciativa hay múltiples herramientas que permiten cargar la documentación de los servicios REST como [swagger] que en base al formato OAS=Open API Specification facilita la creación de la documentación utilizando un fichero JSON o YAML a partir del que se genera:

La documentación en formato HTML

Una UI para interactuar con el API

[swagger] facilita entre otras dos herramientas:

Editor: facilita la creación del fichero JSON / YAML que documenta el servicio REST

UI genera una UI para interactuar con el API

Capturar la documentación en una plantilla del [Gestor de Contenidos] ad-hoc

(opción complementaria a la anterior)

A pesar de que [swagger] proporciona un editor que ayuda a la hora de crear la documentación, sigue siendo necesario conocer la especificación [OAS]

Una alternativa más cercana a los/las usuarios/as que gestionan el sitio de documentación podría pasar por la creación de una [plantilla de captura] en el [gestor de contenidos] de [PLATEA Web] que tenga exclusivamente los campos de la ficha anteriormente descrita en el análisis

A partir de lo que se cargue en estas fichas, se puede generar el HTML e incluso la especificación [OAS] para a su vez generar el UI de TEST

Si finalmente -tras analizar las alternativas- se decide por esta opción, la construcción de la [plantilla de carga de información] en el [gestor de contenidos] de [PLATEAWeb] queda fuera del alcance del presente proyecto

IMPORTANTE: La opción preferida para la documentación del API REST es la primera

(utilizar una herramienta adherida a la especificación [Open API]), pero en cualquier caso esta documentación debería complementarse con contenido generalista cargado en eukadi.eus con las herramientas comunes de [PLATEAWeb] (ver [1])

https://www.openapis.org/

https://swagger.io/

https://swagger.io/specification/

https://swagger.io/swagger-editor/

https://swagger.io/swagger-ui/

https://swagger.io/swagger-editor/






Página:

45/100

Está en el alcance del proyecto la traducción a euskera / inglés de todos aquellos contenidos que únicamente estén disponibles en español

4 UI de TEST de los [servicios REST]: construir una interfaz de usuario/a final que le permita hacer pruebas de invocación sin necesidad de programación

El UI generado por [swagger] es una solución, pero se pueden valorar otras

5 Suite de pruebas de los servicios test de documentación

Esta aproximación es consistente con la estrategia de [diseñar y testar el API en primer lugar] frente a construir el API y posteriormente documentarlo (API schema first)

Es importante recalcar que NO solo está en el alcance del proyecto la identificación de la herramienta de documentación, entra explícitamente dentro del alcance del proyecto la carga de la documentación de cada uno de los servicios ofrecidos en el API en los idiomas que se decida (euskera / español / inglés o solo inglés)


https://swagger.io/




Página:

46/100

6.1.3. Objetivo 3: Construir

En base a:

El análisis realizado en el [objetivo I]

La documentación / tests realizada en el [objetivo II]

en este [objetivo] se pretende construir un [API REST] totalmente funcional en base a datos simulados (la exposición de los datos reales se hará en la FASE II). Para conseguir este objetivo será necesario construir / desplegar toda la infraestructura técnica necesaria:

6.1.3.1. Aplicación de Gestión de [API-Keys]

Construir la aplicación web de [auto-gestión] de [api-keys] donde:

Los/las responsables de las aplicaciones que hacen uso del [API] puedan registrarse y auto-gestionar las [API-Keys] (crear, consultar, revocar, renovar, etc)

Responsables internos de [meteo] puedan gestionar mínimamente las [API-Keys] generadas (crear, consultar, revocar, renovar, etc)

Cualquier agente infomediario que quiera utilizar los datos de los [APIs] deberá disponer de un [API Key] que le identifica unívocamente y le habilita a utilizar los [APIs]. El propio infomediario podrá auto-gestionar la creación, revocación, renovación, etc de su [API Key] en una aplicación web que:

1. Solicitará los datos identificativos que se consideren necesarios

2. Generará un API-Key que puede:

Enviarse por correo electrónico

Dejarse en una zona privada asociada al usuario (perfil) para su descarga

Ambas

NOTAS DE IMPLEMENTACIÓN:

En la fase da análisis y en función de las necesidades funcionales del negocio, se decidirá si la emisión de [API-Keys] debe ser pre-aprobada por responsables de [euskalmet] o no; en principio NO lo será

La opción de que el usuario/a se descargue el [API-Key] en la web exigiría proveer a los usuarios/as de un login en el sistema de auto-gestión de [API-Keys] para acceder a su cuenta y descargar las [API-Keys] generadas

Esto añade un grado más de complejidad al sistema de [auto-gestión de API-Keys] puesto que requerirá

- Integrar un login (OAUTH público -github, Google, etc-, usuario/password, XLNets, Giltza, etc)

- Construir una pequeña aplicación de gestión del perfil del infomediario donde este puede auto-gestionar sus datos personales y [API-Keys]

En un primer estadio podría ser suficiente con un formulario de solicitud, generación del [API-Key] y remisión por correo electrónico que tiene la ventaja de ser simple y fácil de construir, pero algunos inconvenientes

- (para el infomediario): si pierde el [API-Key] debe volver a generar otro

- (para los/las responsables de euskalmet): NO se dispone de un registro de infomediarios puesto que cada emisión de [API-Key] es una nueva solicitud NO ligada con un perfil

… en cualquier caso, se ha de construir una UI interna de gestión donde los/las responsables de [euskalmet] podrán:

- Consultar las solicitudes de [API-Key]

- Consultar los usuarios/as infomediarios registrados (si se decide crear un perfil para los infomediarios)

- Consultar el uso de cada [API-Key] (por ejemplo listar los X [API-Keys] que más utilizan los servicios)

- Hacer operaciones sobre [API-Keys] individuales (ej: revocar, renovar, etc)

- Operaciones de revocación masiva de [API-Keys] (para situaciones en las que se compromete la seguridad)

- Otros



Página:

47/100

Durante el análisis también se decidirá si los [API-Keys] tienen o no caducidad y hay que renovarlos periódicamente (ej: anualmente) o en función del uso (revocar [API-Key] si no se usa)

En cualquier caso, si un [API-Key] se va a revocar se avisará al solicitante

6.1.3.2. Construir el [Repositorio Común]

En la construcción del [repositorio común] se realizarán las siguientes actividades:

Instalación y configuración de productos

En el análisis del [repositorio común] se tomaron decisiones tecnológicas que pueden requerir la instalación y configuración de productos (bases de datos, sistemas de ficheros, NoSQL, etc)

En esta actividad se:

Provisionará el software y la infraestructura necesaria en todos los entornos

Instalará y configurará

En esta fase del proyecto, el [repositorio común] únicamente va a contener datos mock / simulados

Servicios REST En el [repositorio común] se persisten los datos en DB / filesystem / etc dependiendo del dato concreto, pero se exponen a través de un interfaz uniforme que abstrae al cliente de la tecnología subyacente

Este interfaz uniforme son los [servicios REST] que se basan en una serie de funciones comunes que habrá que implementar según lo analizado:

Versionado

Autenticación / seguridad

Logging

Accounting

Throtling / rate limiting / function limiting

Enrutado a la implementación de la lógica de negocio

etc



Página:

48/100

6.1.3.3. Implementación Mock de cada dato a exponer

Se implementarán todas las funciones (datos) a exponer como [servicios REST] en el [API] previamente identificadas.

La implementación se basará en datos mock (simulados), es decir NO se utilizará el origen real de datos puesto que:

El objetivo en esta fase del proyecto es sentar las bases del sistema

El esfuerzo a realizar para extraer los datos de sus orígenes y adaptarlos a los formatos definidos es considerable y distraería los esfuerzos del proyecto en la fase actual

Los datos mock / simulados pueden ser muestras de datos que previamente se han cargado en el [repositorio común] o simplemente una rutina que genera datos aleatorios

6.1.3.4. Despliegue y validación

La solución completa (documentación, infraestructura, servicios mock, sitio de test, etc) se instalará completamente en tres entornos: DES / PRU y PROD

En esta actividad se validará en base una [test-suite]

La aplicación de auto-gestión de las [API Key]

La infraestructura y servicios comunes para la exposición de servicio

El sitio de documentación y TEST

Las funciones expuestas

La escalabilidad del sistema

Se desarrollará una [test-suite] que permita automatizar las pruebas de los API y que en la FASE II ayude en la validación de los procesos de extracción de datos desde sus orígenes



Página:

49/100

6.1.4. Objetivo 4: Componentes Web

Una vez analizada (objetivo I), documentada (objetivo II) y construida (objetivo III) la solución de exposición de [servicios REST]-[API], aunque en esta FASE I del proyecto los datos son simulados (mock) es posible empezar a construir productos derivados que una vez los datos sean reales serán totalmente funcionales.

El primero de los productos derivados a construir dentro del alcance de la FASE I del proyecto son una serie de [componentes web] que permitan:

Reconstruir la web www.euskalmet.euskadi.eus en base a los mismos

Ser utilizados como [widgets] en otras iniciativas de Euskadi.eus o fuera de ella (ej: webs de otras administraciones)

Para la consecución de este [Objetivo IV] se ejecutarán las siguientes acciones:

1 Análisis Identificar qué [componentes web] hay que implementar

El inventario de [componentes web] viene marcado por:

Los datos disponibles

Los datos que se quieren pintar en los canales web / móvil / tv, etc

Dado que el diseño del canal web / móvil / tv es un proyecto ad-hoc al margen del actual, la fase de análisis de este proyecto también es una entrada a la realización de este inventario

2 Diseño técnico Selección tecnológica en base a la que implementar los [componentes web]

3 Construcción Construcción de los [componentes web] en base a los [servicios REST]

4 Validación Validación del producto

Es importante tener en cuenta que:

El diseño gráfico, usabilidad, accesibilidad, marcado, etc de los [componentes web] queda fuera del alcance de este proyecto de forma que todo lo que tenga que ver con estas actividades será proporcionado externamente




Página:

50/100

6.1.4.1. Análisis

El catálogo de [componentes web] a implementar a partir de los [servicios REST] construidos se basa también en la agrupación que se hizo anteriormente:

1. Alertas

2. Predicciones

3. Mediciones

4. Mapas

5. Modelos

[1] - Alertas

(móvil)

Las alertas NO presentan mayor problema para pre-generarse como contenido web estático de forma que NO sea necesario obtener los datos del [repositorio común] para pintar los avisos cada vez que estos se solicitan.

[2]-Predicciones

Predicción meteorológica

Euskadi - General Euskal Herria –

Eguraldia

Por comarcas / población

Península Ibérica Europa Tendencia

Predicción marítima / ItsasEus



Página:

51/100

Previsión índices de ultravioleta:

Predicción por zonas para temperaturas altas persistentes y temperaturas altas extremas

Los datos se ofrecen a nivel general o a nivel de [zona] / [población] por lo que hay que pre-generar un [componente web] para cada combinación de [zona] / [población] cada vez que se hace una predicción (2 o más veces al día)

Según esto, el número de [componentes web] a pre-generar en un año sería:

Componentes web / año = 10 zonas x 40 poblaciones de media en cada zona x predicciones diarias (2 o 3) x 365

El número de [componentes web] / año es muy grande (decenas de miles de ficheros html e imágenes), lo cual NO es mayor problema para un servidor web; simplemente se almacenarán ficheros html e imágenes en carpetas que el servidor web se encarga de entregar al navegador web.

NOTA: En realidad el número de ficheros baja puesto que muchas [poblaciones] dentro de una [zona] comparten el mismo [componente web] (son los mismos datos)

[2] – Lecturas


Lecturas horarias

Estadísticas diarias

Boletines diarios

Climatología mensual por dias

Comparativa de estaciones por meteoros

Gráficos Hidrometeorológico

Exportación de datos

Mediciones de polen



Página:

52/100

Oceonometeorológico;

El caso de las [lecturas] de las [estaciones meteorológicas] es similar al anterior en cuanto al número de [componentes web] a generar / año:

Componentes web / año = 24 horas x 100 estaciones aprox x 365

El número de [componentes web] / año es muy grande (decenas de miles de ficheros html e imágenes), lo cual NO es mayor problema para un servidor web; simplemente se almacenarán ficheros html e imágenes en carpetas que el servidor web se encarga de entregar al navegador web.

Alternativamente a pre-generar los [componentes web] en base a ficheros HTML / CSS / imágenes, se podría plantear una solución en la que los datos se pintan dinámicamente en base a los datos devueltos por los [servicios REST] del [API]

Esta solución es perfectamente posible puesto que como ya se ha señalado, el [API] NO tiene que hacer ningún cómputo / cálculo para devolver los datos, los devuelve según están almacenados en el [repositorio común] (ya transformados por ejemplo en formato JSON). El cliente web (navegador) lo único que tiene que hacer es pintar el JSON en una tabla de datos HTML, algo que NO tiene ninguna complejidad

Esta solución disminuiría el número de ficheros HTML pero seguirán existiendo miles de ficheros de imagen para los mapas

… así que no parece tampoco una solución mejor a pre-generar todo el [componente-web] y NO utilizar el [repositorio] (la persistencia de datos) -y por lo tanto el servidor de aplicaciones-



Página:

53/100

[3] - Mapas

Temperatura Precipitación Isobaras Índice UV Humedad Viento

Euskadi

Península

Europa

Mar

Meteosat

Radar kapildui

Perfilador Punta Galea

Los [mapas] tampoco presentan ningún problema para ser pre-generados como [componente-web], de hecho hoy en día prácticamente ya lo son puesto que los mapas son ficheros de imágenes

[5] - Modelos

- Europa - Península Ibérica

- Norte de la Península ibérica - Mapa regional - Euskadi

- Euskadi

- Mar Cantábrico + océano atlántico - Mar Cantábrico - Mar Costa vasca

Los [modelos] tampoco presentan ningún problema para ser pre-generados como [componente-web], de hecho hoy en día prácticamente ya lo son puesto que los mapas son ficheros de imágenes



Página:

54/100

6.1.4.2. Diseño Técnico

A partir de:

El análisis anterior sobre los componentes web

El análisis sobre la persistencia de los datos (y especialmente los activos como imágenes -mapas, etc)

Se diseñará la estructura de carpetas y ficheros de cada [componente web] teniendo en cuenta éstos deben tener las siguientes características técnicas

HTML / CSS / JS / img estático

Los [componentes web] se pre-generarán como HTML / CSS / JS estático que se desplegará en [PLATEAWeb]

El hecho de que los [componentes web] se pre-generen periódicamente y desplieguen en los [servidores web] aligera la carga de computación del sistema y la dota de estabilidad y escalabilidad puesto que como ya se ha descrito, para pintar la web NO es necesaria la intervención de [servidores de aplicaciones], [servicios web], [bases de datos], etc

Se preferirá HTML / CSS con un mínimo de JS frente a componentes basados exclusivamente en JS (ej: componentes vue o componentes react)

Sin embargo, en función de los casos de uso puede llegar a plantearse la construcción de algún componentes JS alineados con los propuestos en iniciativas como:

- WebComponents

- Vue

- React

Responsive / multi-dispositivo

El marcado generado debe ser [responsive]: adaptable a múltiples dispositivos (desktop / mobile / tv…)

En cualquier caso, es posible que sea necesario pre-generar diferentes marcados en función del tipo de dispositivo puesto que estos NO soportan determinadas funcionalidades de las tecnologías en las que se basa el [responsive web design] (HTML5 / CSS3); este puede ser el caso de la [WebTV] que son dispositivos con capacidades limitadas.

Basado en librerías / frameworks estándar de código abierto

Se utilizarán librerías / framewoks estándar (de uso generalizado en la web) como:

Frameworks CSS Frameworks / Librerías JS

- Bootstrap - Material / Materal Design Lite /

Materialize - Foundation - SemanticUI - HTML5 Boilerplate

- VUE - React - JQuery

En el entorno de desarrollo local, se utilizará [webpack] como module bundler

Multi-idioma Los componentes deben ser multi-idioma: euskera / español / ingles

Está en el alcance del proyecto la traducción a euskera / inglés de todos aquellos contenidos que únicamente estén disponibles en español

Accesibles Se tendrá en cuenta la accesibilidad a la hora de construir los componentes

Micro-marcado El marcado HTML se micro-marcará (micro-data): ver microformats o schema.org

(ver punto dedicado a la exposición [Linked Open Data])

https://www.webcomponents.org/

https://vuejs.org/v2/guide/components.html

https://reactjs.org/docs/components-and-props.html

https://en.wikipedia.org/wiki/Responsive_web_design

https://getbootstrap.com/

https://material.io/

https://getmdl.io/

http://materializecss.com/

https://foundation.zurb.com/

https://semantic-ui.com/

https://html5boilerplate.com/

https://vuejs.org/

https://reactjs.org/

https://jquery.com/

https://webpack.github.io/

http://microformats.org/



Página:

55/100

El diseño gráfico de los [componentes web] queda fuera del alcance de este proyecto de forma que todo lo que tenga que ver con estas actividades será proporcionado externamente

6.1.4.3. Construcción

En base a los datos devueltos por los [servicios REST] se construirán los [componentes web] identificados durante el análisis.

Recordar que los requisitos de usabilidad / accesibilidad, etc así como el diseño gráfico y marcado HTML / CSS / JS serán proporcionados desde el proyecto ad-hoc de [rediseño de euskalmet.euskadi.eus]

En esta actividad lo único que hay que abordar es la trasposición de los datos devueltos por los API a la diseño / marcado etc proporcionado externamente

6.1.4.4. Validación

Validar que los [componentes web] construidos cumplen los requisitos funcionales y técnicos analizados

La validación de estos componentes construidos será externa y se hará en el proyecto ad-hoc de [rediseño de euskalmet.euskadi.eus] que es donde se van a utilizar

Esta actividad NO se dará por finalizada hasta que los componentes web cumplan los requisitos marcados



Página:

56/100

6.2 FASE II: Obtención de datos backend y exposición final de servicios

Una vez finalizada la [FASE I] donde se tienen los [servicios REST] totalmente funcionales (aunque en base a datos simulados) y completamente documentados en todos los entornos de explotación, se puede abordar esta [FASE II] que tiene como objetivo que los [servicios REST] devuelvan datos reales en lugar de los datos simulados (mock) de la [FASE I].

Este objetivo es técnicamente complejo puesto que exige un laborioso análisis de los orígenes de datos en los [sistemas backend] de [euskalmet] y el diseño de los mecanismos técnicos para extraer estos datos y ponerlos a disposición de los [servicios REST] construidos en la [FASE I].

Para conseguir el objetivo de la [FASE II], se han identificado 3 sub-objetivos:

6.2.1. Objetivo 1: Análisis de los orígenes de datos

Analizar los orígenes de los datos en los [sistemas backend] de [euskalmet] y diseñar los sistemas de extracción de los datos para que estos sean accesibles a los servicios [APIs] REST y a la infraestructura [LOD] de [opendata Euskadi]

En esta FASE II una vez que se ha identificado qué datos en la FASE I, se pone el foco en el origen del dato (dónde está el dato) y cómo hacerlo accesible

Para cada una de las funcionalidades a exponer en el [API] (alertas / observaciones / previsiones / mapas / localizaciones / etc), se propone ampliar la ficha de cada funcionalidad utilizada en el [análisis] de la [FASE I] (ver anteriormente en este documento), manteniendo las secciones de [descripción general] y [exposición como servicio REST] puesto que contienen información necesaria para definir por ejemplo cómo se transforman los datos. Una plantilla de la ficha a utilizar en este análisis podría ser:


Dato Ej: Temperatura


Origen(es) Base de Datos / fichero en una zona de intercambio / etc

Formato



Otros datos

EndPoint URI /forecast/{fecha}/{localización}

Métodos HTTP GET / POST / PUT / DELETE

Parámetros Explicar los parámetros

Cabeceras HTTP Versionado /

API-Key / HMAC

Mime-Type (accept)

Códigos de retorno Detallar los códigos de retorno:

Mensajes de retorno Detallar los mensajes de retorno en los siguientes casos:

La llamada sea correcta

La llamada no sea correcta por un error de cliente

La llamada resulte en un error interno en el servidor

Los mensajes de respuesta se describirán de una forma agnóstica al formato (xml / json /…), como estructuras de datos

Vínculos Vínculos a otros recursos REST (ver HATEOAS)



Página:

57/100

Información técnica para acceder al origen de datos

- Información de la conexión de base de datos

- Ruta en una zona de intercambio

- etc

Estructura interna de los datos

- Descripción de las tablas y columnas de las base de datos donde residen los datos / SQLs para extraer los datos / etc

- Estructura de los ficheros de intercambio

- etc

Aproximación técnica del componente que extrae los datos y los transforma

Diseño técnico del componente que extrae los datos del [sistema backend] origen y los transforma en la información que necesitan los [servicios REST]

En función de la [frecuencia de actualización de los datos], la aproximación a la extracción es diferente:

- Si la información se actualiza periódicamente en el origen, se pueden implementar procesos que extraen la información, la transforman y la publican en un nuevo repositorio ya transformada que es de donde se alimentarán los [servicios REST]

- Si la información es en tiempo real, la aproximación será diferente y dependerá del origen

En base al trabajo anterior se obtendrá una visión general de los [orígenes de datos] y los mecanismos necesarios para acceder y transformar los datos en base a la cual diseñar un repositorio de información de la que se alimentarán los [servicios REST]

Recordar que desde [euskalmet] se facilitan datos e imágenes (mapas / predicciones / modelos etc)

Actualmente:

Los datos(en su mayor parte) se sincronizan utilizando la [Base de Datos]

Los ficheros se sincronizan utilizando una [fileSystem] de intercambio

En la [FASE I] se diseñó la persistencia de los datos (tomando como datos también las imágenes) y se tomó

la decisión sobre:

La tecnología a utilizar para persistir cada tipo de dato

La estructura interna de la persistencia (ej: estructura de tablas en una DB o estructura de carpetas en un fileSystem)

En este punto hay que revisitar estas decisiones y ampliarlas / adecuarlas para cada uno de los orígenes de datos.



Página:

58/100

6.2.2. Objetivo 2: Construcción

Recordando la arquitectura general del sistema propuesto:

… y tomando como base el análisis anterior, en este sub-objetivo hay que:

1 Construir los mecanismos de extracción y transformación de datos de cada origen

2 Conectar los [servicios REST] a los dato reales (sustituir los datos mock / simulados)

3 Construir en [PLATEA Web] los mecanismos que orquestan la publicación de información

A continuación, se detallan cada uno de los paquetes de trabajo anteriores:

DB Meteorología

1a



en DBs de EJIE






de dato adapta la




común]

REPOSITORIO

COMUN

Proceso de

importación de

datos de

euskalmet

2

PLATEA WEB

Proceso de


de euskalmet a

[PLATEA Web]

5




4



REST



datos)

3




Inte

rfaz d

e a

ctu

aliz

ació

n

Inte

rfaz d

e C

on

su

lta


Proceso de

importación de

datos de

euskalmet

Proceso de


de euskalmet a

[PLATEA Web]



Página:

59/100

6.2.2.1. Construir los mecanismos de extracción y transformación de datos de cada origen

En este [paquete de trabajo], para cada dato identificado en el análisis se construirá un componente que extrae los datos del [sistema backend] origen y los transforma en la información que necesitan los [servicios REST] y que se almacena en el [repositorio común].

En función de la [frecuencia de actualización de los datos], la aproximación a la extracción es diferente:

- Si la información se actualiza periódicamente en el origen, se pueden implementar procesos que extraen la información, la transforman y la publican en un nuevo repositorio ya transformada que es de donde se alimentarán los [servicios REST]

- Si la información es en tiempo real, la aproximación será diferente y dependerá del origen

Una pieza importante del sistema es la orquestación de la lógica que implica la extracción, transformación e importación en el [repositorio común] de cada uno de los orígenes; para este fin se construirá un módulo similar (aunque más sencillo) al [Sistema de Sindicación de Contenidos] de [PLATEA Web] utilizado para importar datos en [OpenData Euskadi] desde múltiples orígenes

Este módulo de [Sindicación de datos meteorológicos] será responsable de:

1 Extraer información del sistema corporativo interno

El caso más habitual es que la información esté en Bases de Datos relacionales, aunque en otros casos, la información origen está en ficheros Excel, Zip, etc que se dejan manual o automáticamente en zonas de intercambio de ficheros o en URLs accesibles

2 Transformar y enriquecer la información

En ocasiones, la información origen se enriquece con datos de otros sistemas, por ejemplo:

- Se geo-cataloga la información obteniendo datos de geo-posicionamiento a partir de direcciones en texto

- Se cataloga la información en las taxonomías normalizadas del Gobierno Vasco

3 Actualizar el [repositorio común]

Una vez se han recuperado y enriquecido los datos, se cargan en el [repositorio común] utilizando las interfaces de actualización previamente definidas y construidas

Dado que la información es dinámica (cambia en el origen), el [Sistema de Sindicación de PLATEA-Internet] es capaz de periódicamente repetir el proceso anterior en función del ratio de cambio de los datos de origen: si los datos de origen cambian cada 5 min el proceso se repite cada 5 min mientras que si lo hace cada 6 meses se repite solo dos veces al año.

6.2.2.2. Conectar los [servicios REST] a los dato reales

En este [paquete de trabajo] se sustituirán los datos simulados / mock en base a los que está funcionando el [API] público de [euskalmet] por los datos reales del [repositorio común]; si el trabajo en la [FASE I] se ha hecho correctamente, este cambio debería ser transparente y no afectar al resto de productos de la [FASE I] (documentación, componentes web, etc), sin embargo, es posible que sea necesario hacer algún ajuste

En este punto se utilizarán el [test-suite] desarrollado en la FASE I para comprobar los servicios construidos; todas las integraciones deberán verificar estos test

DB Meteorología

1a



en DBs de EJIE





REPOSITORIO

COMUN

Proceso de

importación de

datos de

euskalmet

2

Inte

rfaz d

e a

ctu

aliz

ació

n

Inte

rfaz d

e C

on

su

lta



Página:

60/100

6.2.2.3. Construir en [PLATEA Web] los mecanismos que orquestan la publicación de información

Una vez que los datos residen ya en el [repositorio común] ya transformados al formato más adecuado para ser expuestos en los [servicios REST] y consumidos desde la web, el siguiente paso es automatizar:

La generación de [componentes web]

La publicación como [datos abiertos enlazados=LOD]

Para esta función se utilizará un componente de [PLATEA Web]: el [Sistema de Sindicación de PLATEA-Web] que es

un módulo que permite automatizar las tareas anteriores

El [sistema de sindicación de PLATEA Web] es modular de forma que en torno a un núcleo común que contiene las funciones comunes se instalan módulos conectores con cada origen de datos

Algunos ejemplos de datos sindicados en el [Sistema de Sindicación de PLATEA-Web]: - Registro de Fundaciones - Registro de Asociaciones - Registro de Entidades Locales - Red de Bibliotecas de euskadi - Publicaciones del Gobierno Vasco - Muchos de los [DataSet] de opendata.euskadi.eus - Contenidos jurídicos de legegunea.euskadi.eus - Noticias importadas en euskadi.eus desde Irekia - Datos meteorológicos - Calidad de las aguas - Calidad del aire - …

A un nivel de abstracción alto, el [Sistema de Sindicación de PLATEA-Internet] es fundamentalmente un sistema ETL (Extraction / Transformation / Load) muy adaptado a las necesidades de publicación de información utilizando [PLATEA-Web] / [OpenData Euskadi]

En este caso concreto, se construirá un módulo del [sistema de sindicación de PLATEA Web] que utilizará los [servicios REST] del [repositorio común] para generar [contenido web] y publicar [datos abiertos]

REPOSITORIO

COMUN

PLATEA WEB

Proceso de


de euskalmet a

[PLATEA Web]

5




4




Inte

rfaz d

e a

ctu

aliz

ació

n

Inte

rfaz d

e C

on

su

lta


Sindicaciónde

contenidos

BBDDDepartamental

ConectorORIGEN 1

Gestorde

Contenidos

ConectorORIGEN 2

ConectorORIGEN N

Zona de intercambio de ficheros

Servidor Web



Página:

61/100

6.2.3. Objetivo 3: Despliegue

Finalizado el [Objetivo II], se tiene:

- Un [repositorio común] con los datos adaptados para su exposición en el [API]

- Los servicios [REST] del [API] público conectados al [repositorio común]

- La generación de [componentes web] automatizada en [PLATEA Web]

pero queda pendiente:

1. Desplegar y validar la solución

2. Carga inicial de la información de los diferentes orígenes y validación de los procesos que actualizan los datos periódicamente

3. Reconstruir el portal [www.euskalmet.euskadi.eus] en base a los [componentes web]

6.2.3.1. Desplegar y validar la solución

Todos los módulos software construidos ([repositorio común], [módulos de extracción / transformación / importación], etc) han de implantarse finalmente en los tres entornos: DES / PRU y PROD

6.2.3.2. Carga inicial

Con todo el sistema por fin completamente desplegado en los entornos de DES / PRU y PROD, se procederá a:

1. Ejecutar una carga inicial de datos del sistema

2. Validar que los procesos periódicos de actualización de datos desde los diferentes orígenes funciona correctamente

3. Validar que los datos web y LOD se publican y actualizan correctamente



Página:

62/100

6.2.3.3. Reconstruir el portal [www.euskalmet.euskadi.eus] en base a los [componentes web]

En este momento, una vez que todo el sistema utiliza datos reales, los [componentes web] construidos en la [FASE I] deberían mostrar datos reales sin necesidad de cambios.

… por lo tanto, en este momento es posible reconstruir el portal www.euskalmet.euskadi.eus en base a

estos [componentes web] y páginas / contenidos web gestionados en [PLATEA Web]

El portal pasará a ser totalmente estático (HTML / CSS / JS puro) de forma que NO será necesaria la intervención de [servidores de aplicaciones], [bases de datos], [servicios web], etc para pintar el portal: se basará únicamente en [servidores web] que aportan una fiabilidad prácticamente del 100% así como una escalabilidad también prácticamente sin límite (basta con añadir nuevos [servidores web] si se detectan picos de carga)

El diseño gráfico, la arquitectura de la información, usabilidad, accesibilidad, marcado, etc queda fuera del alcance de este proyecto de forma que todo lo que tenga que ver con estas actividades será proporcionado externamente

Se contratará otro proyecto ad-hoc que tendrá como objetivos:

1. Diseñar los componentes web individuales (este producto será la entrada para el punto anterior de este proyecto)

2. Diseñar el portal euskalmet.euskadi.eus

3. La trasposición técnica a [PLATEA Web]: construir lo diseñado en base a:

[Gestor de Contenidos]

[Gestor de Portales]

[Componentes Web] de meteorología

En esta tarea el alcance se limita a dar soporte a la empresa adjudicataria del re-diseño del portal [euskalmet.euskadi.eus] en cuanto a la integración de los componentes web construidos en el presente proyecto, de forma que se harán los ajustes necesarios en estos últimos en función de las necesidades / incidencias que vayan apareciendo en el proyecto ad-hoc de rediseño del portal.




Página:

63/100

7 Entregables

7.1 Descripción de Entregables

Los entregables del proyecto se dividen en dos áreas:

Entregables relacionados con el [producto] del proyecto

Entregables relacionados con la [Gestión del Proyecto]

7.1.1. Entregables relacionados con el [producto] del proyecto

En base a los objetivos generales del proyecto:

FASE I:

Análisis de datos disponibles y exposición de servicios

Objetivo 1

Análisis Análisis de los datos disponibles en los sistemas [backend] de [euskalmet]

Análisis del [repositorio común]

Objetivo 2

DOCs Sitio web de documentación de los APIs y datos disponibles así como de TEST de los mismos: api.euskalmet.euskadi.eus/docs

Objetivo 3

Construir

[Repositorio Común]

a) Sistema de persistencia de los datos en todos los entornos DES / PRU / PROD

b) [Servicios REST] en api.euskalmet.euskadi.eus en todos los entornos DES / PRU / PROD

Aplicación web pública de auto-gestión de [API Keys] e interna de gestión

API common services

Implementar las funciones definidas en base a orígenes de datos mock (datos origen simulados)

Objetivo 4

Componentes Web [componentes HTML] para la web

FASE II:

Obtención de datos backend y exposición final de servicios

Objetivo 1

Análisis 1. Análisis de los orígenes de los datos en los [sistemas backend] de

[euskalmet] y diseño de los sistemas de extracción de los datos para que estos sean accesibles a los servicios [APIs] REST y a la infraestructura [LOD] de [opendata Euskadi]

2. Análisis del [repositorio común] base para la [exposición de servicios]

Objetivo 2

Construcción 1. Mecanismos de extracción y transformación de datos de cada origen

2. Módulo del [sistema de sindicación de PLATEA Web] que orquesta la publicación de información a partir de los datos expuestos en los [servicios REST]

Objetivo 3

Despliegue 1. Solución desplegada en DES / PRU y PROD con los datos cargados y

actualizados periódicamente

2. Soporte a la construcción del portal [www.euskalmet.euskadi.eus]

en base a los [componentes]



Página:

64/100

7.1.2. Entregables relacionados con la [Gestión del Proyecto]

Descripción Entregables

Tareas de gestión del proyecto en todas sus fases:

Inicialización: definir el alcance del proyecto

Planificación: plan de gestión del proyecto para conseguir el alcance

Ejecución: llevar a cabo aquello especificado en el alcance

Monitorización y control: verificar y controlar que se está trabajando única y exclusivamente en el ámbito marcado en el alcance, con la calidad requerida y en el coste y tiempo previstos.

Cierre: obtención de las lecciones aprendidas y cierre administrativo

Documentación de Gestión de proyecto:

Inicialización Oferta

Project Charter

Alcance inicial

Planificación Descomposición de tareas (WBS)

Definición de entregables y su verificación (criterios de aceptación)

Planificación temporal

Equipo de trabajo y roles

Plan de comunicación

Ejecución Informes de ejecución de las tareas de la descomposición-WBS

Historial de cambios y aceptación de los mismos

Diario de ejecución: entrega de paquetes de trabajo, implantaciones, etc

Monitorización y control

Informes de seguimiento: avance, riesgos, etc

Cierre Lecciones aprendidas

Cierre administrativo del proyecto



Página:

65/100

7.2 Aceptación de Entregables

Todos los entregables deberán pasar dos validaciones:

Validación Objeto Quién la realiza

Validación técnica Cumplimiento de los requerimientos y niveles de calidad técnica exigibles

Técnicos/as de EJIE de todas las áreas implicadas

Validación funcional Cumplimiento de los requerimientos funcionales

Técnicos/as de la [Dirección de Emergencias y de Meteorología]

Técnicos/as responsables de la [Transparencia] del [Gobierno Vasco] en [DACIMA]

Técnicos/as de EJIE

NOTAS IMPORTANTES

Ninguno de los entregables descritos anteriormente se darán por finalizados hasta no tener la validación técnica y funcional.

En la medida de lo posible, durante la planificación del proyecto se definirán y documentarán los criterios de aceptación de cada uno de los entregables que serán utilizados en los procesos de monitorización y control del proyecto.

En ocasiones será complicado definir sin ambigüedad por escrito los criterios de validación de entregables puesto que intervienen criterios subjetivos. Será responsabilidad del adjudicatario del proyecto documentar los criterios de la forma menos ambigua posible alcanzando un acuerdo con los validadores interesados en cada caso.

En caso de conflicto sobre la aceptación de algún entregable, el Jefe de Proyecto de EJIE tendrá la capacidad de decidir sobre la aceptación o no del entregable.

En cualquier caso el adjudicatario del proyecto en caso de conflicto debería hacer iteraciones para intentar adaptar el entregable a los requerimientos de validación expuestos por los validadores



Página:

66/100

8 Planificación inicial

La planificación definitiva del proyecto se realizará durante la fase de planificación del proyecto una vez adjudicado, en el presente punto se incluye una plantilla de planificación que el ofertante deberá concretar y extender en su propuesta.

La planificación incluida en este punto tiene como objetivo servir como base para que el ofertante haga una valoración propia que ha de incluir en su oferta

Además, hay que tener en cuenta que en la fase actual del proyecto y con el conocimiento que se tiene del mismo, el margen de error de la planificación es de entre un 25%-30%:

De todas las áreas planificables (costes, alcance, calendario, recursos humanos, riesgos, calidad, etc), la planificación en costes, alcance y RRHH incluidas en la propuesta se considerarán como vinculantes; otras áreas planificadas en la propuesta (ej: calendario) serán consideradas como orientativas puesto que es difícilmente exigible atenerse a una planificación temporal o de recursos cuando no se conocen todos los condicionantes organizativos y técnicos.

En líneas generales, la [Triple Constraint] (Project management triangle) establece tres variables relacionadas en un proyecto: [alcance], [coste] y [tiempo].

Si se fijan dos de las variables (alcance y coste) en base a la oferta, la tercera NO puede fijarse de antemano y debe ser definida en la planificación una vez iniciado el proyecto

La planificación temporal final se definirá a partir de la descomposición de tareas en la fase de planificación.

No obstante de lo anterior, a nivel orientativo y para valorar el entendimiento del proyecto, los ofertantes deberán incluir una planificación temporal tentativa que sirva de base para valorar el entendimiento del proyecto

https://en.wikipedia.org/wiki/Project_management_triangle



Página:

67/100

8.1 Planificación de Alcance

El alcance del proyecto se recoge en el siguiente diagrama de descomposición de tareas:



Página:

68/100

Los elementos de la [descomposición del trabajo] son los siguientes:

Cod Elemento

0 Gestión del Proyecto

0.1 Iniciación

0.2 Planificación

0.3 Ejecución

0.4 Cierre

1 FASE I

1.1 Objetivo 1: Análisis

1.1.2 Identificación de datos a exponer

1.1.3 Viabilidad de obtención del dato

1.1.4 Diseño del API REST

1.1.4.1 Dato 1

1.1.4.2 Dato 2

1.1.4.3 …

1.1.5 Repositorio común

1.1.5.1 Persistencia

1.1.5.2 Versionado

1.1.5.3 Autorización / securización

1.1.5.4 Otros

1.1.5 Exposición Linked OpenData / geo-euskadi

1.2 Objetivo 2: Documentación

1.2.1 Diseño gráfico / arquitectura de la información

1.2.2 Sitio web de documentación

1.2.2.1 Plantillas de Portal

1.2.2.2 Carga de contenidos generales

1.2.2.3 Selección de la tecnología para documentar APIs

1.2.2.4 Carga de documentación servicios REST

1.3 Objetivo 3: Construcción

1.3.1 Gestión de API Keys

1.3.1.1 Servicios CORE

1.3.1.2 UI pública

1.3.1.3 UI privada



1.3.2.2 Rest Services

1.3.2.2.1 Authentication

1.3.2.2.2 Log

1.3.2.2.3 Rate limit

1.3.2.2.4 …

1.3.3 Implementación mock (simulada)

1.3.3.1 Dato 1

1.3.3.2 Dato 2

1.3.3.4 …

1.3.4 Despliegue y validación

1.4 Objetivo 4: Componentes Web

1.4.1 Análisis

1.4.2 Diseño Técnico

1.4.3 Construcción

1.4.3.1 Componente 1


1.4.3.3 …

1.4.4 Validación

2 FASE II

2.1 Objetivo 1: Análisis Orígenes de datos

2.1.1 Dato 1

2.1.2 Dato 2

2.1.3 …


2.2.1 Extracción de datos



Página:

69/100

2.2.1.1 Dato 1

2.2.1.2 Dato 2

2.2.1.3 …

2.2.2 Conectar los servicios REST a los datos reales

2.2.3 PLATEAWeb: publicación de información

2.3 Objetivo 3: Despliegue

2.3.1 Despliegue

2.3.2 Carga Inicial

2.3.3 Reconstrucción del portal euskalmet

4 Gestión del Cambio

4.1 Técnico: entornos y despliegues

4.2 Organizativo: formación



Página:

70/100

8.2 Planificación de RRHH: Previsión de Recursos

Los ofertantes deberán hacer una previsión de recursos en base a la descomposición de trabajos anterior o a la que se proponga en base a esta.

Para la previsión de recursos y costes se utilizarán los siguientes perfiles y otros propuestos por el ofertante:

Cod Recurso

PM Project Manager

ARQ Arquitecto

AN Analista Funcional / Analista de datos

PR Programador / Técnico de sistemas / Diseñador web

Y en base a esto se cumplimentará el número de jornadas previsto para cada paquete de trabajo (elemento de último nivel) de la descomposición de tareas:

Cod Elemento PM ARQ AN PR


0.1 Iniciación

0.2 Planificación

0.3 Ejecución

0.4 Cierre

1 FASE I





1.1.4.1 Dato 1

1.1.4.2 Dato 2

1.1.4.3 …



1.1.5.2 Versionado


1.1.5.4 Otros

1.1.5 Exposición Linked OpenData / Geo-euskadi











1.3.1.2 UI pública

1.3.1.3 UI privada







Página:

71/100

1.3.2.2.2 Log


1.3.2.2.4 …


1.3.3.1 Dato 1

1.3.3.2 Dato 2

1.3.3.4 …



1.4.1 Análisis


1.4.3 Construcción



1.4.3.3 …

1.4.4 Validación

2 FASE II

2.1 Objetivo 1: Análisis de orígenes de datos

2.1.1 Dato 1

2.1.2 Dato 2

2.1.3 …



2.2.1.1 Dato 1

2.2.1.2 Dato 2

2.2.1.3 …




2.3.1 Despliegue

2.3.2 Carga Inicial





El número de jornadas es relevante para evaluar la viabilidad técnica de la propuesta ya que en este apartado se valorará una adecuada distribución de jornadas en cada uno de los perfiles.

… pero hay que recordar que la planificación temporal incluida en la oferta NO es vinculante puesto que el objetivo del proyecto es construir el producto definido (alcance) con el coste planificado que SI están vinculados a la oferta.



Página:

72/100

8.3 Planificación de tiempos

La planificación temporal es orientativa y se definirá completamente durante la planificación del proyecto una vez comenzado el mismo, sin embargo, en la oferta se incluirá una planificación inicial que será utilizada para:

Identificar las fases del proyecto

Valorar el entendimiento del proyecto (ver [Criterios de Valoración])

Prever recursos por parte de EJIE

De esta forma, se utilizará esta información orientativa para valorar la idoneidad del dimensionamiento del equipo de trabajo propuesto y su adecuación a la consecución de los objetivos. No obstante, este desglose de horas no se considera vinculante, al no tratarse de una contratación de horas de trabajo, sino un proyecto “llave en mano” según el importe total ofertado

Los hitos principales del proyecto que el ofertante deberá “calendarizar” son:

Fase I Objetivo 1: Análisis

Objetivo 2: Documentación

Objetivo 3: Construcción

Objetivo 4: Web components

FASE II Objetivo 1: Análisis


Objetivo 3: Despliegue

En la [oferta] se incluirá un calendario de hitos así como un calendario detallado similar a la que se incluye a continuación, en base a los paquetes de trabajo identificados por el ofertante:

Cod Elemento

Month1 Month2 Month3 Month4 Month5 …

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11


0.1 Iniciación

0.2 Planificación

0.3 Ejecución

0.4 Cierre

1 FASE I





1.1.4.1 Dato 1

1.1.4.2 Dato 2

1.1.4.3 …



1.1.5.2 Versionado


1.1.5.4 Otros




Página:

73/100











1.3.1.2 UI pública

1.3.1.3 UI privada





1.3.2.2.2 Log


1.3.2.2.4 …


1.3.3.1 Dato 1

1.3.3.2 Dato 2

1.3.3.4 …



1.4.1 Análisis


1.4.3 Construcción



1.4.3.3 …

1.4.4 Validación

2 FASE II



2.1.2 Orígenes de datos

2.1.2.1 Dato 1

2.1.2.2 Dato 2

2.1.2.3 …



2.2.1.1 Dato 1

2.2.1.2 Dato 2

2.2.1.3 …




2.3.1 Despliegue

2.3.2 Carga Inicial







Página:

74/100

8.4 Planificación de Costes

En la [Propuesta Económica] se incluirá el [Presupuesto Total] del proyecto (valor estimado) que será el utilizado para valorar económicamente la oferta (ver [Criterios de Valoración])

No obstante, de lo anterior, y con el objetivo de tener una mayor información sobre el origen de este presupuesto total, en la [Propuesta Económica] se incluirá un detalle orientativo del cálculo del presupuesto:

El presupuesto total debería basarse en la agregación de los costes unitarios de cada actividad calculada en función de las tarifas de los recursos y el número total de jornadas planificadas para dicha actividad:

𝑐𝑜𝑠𝑡𝑒 𝑎𝑐𝑡𝑖𝑣𝑖𝑑𝑎𝑑 = 𝑐𝑜𝑠𝑡𝑒 𝑟𝑒𝑐𝑢𝑟𝑠𝑜𝑠 𝑥 𝑗𝑜𝑟𝑛𝑎𝑑𝑎𝑠 𝑝𝑙𝑎𝑛𝑖𝑓𝑖𝑐𝑎𝑑𝑎𝑠

Por lo que en base a un cuadro de tarifas por perfil como:

Cod Recurso Tarifa € / jornada

Coste (€)

PM Project Manager

ARQ Arquitecto

AN Analista funcional / analista de datos

PR Programador / Técnico de sistemas

DIS Diseñador web

(añadir a la tabla aquellos otros perfiles que se propongan en la oferta)

Se obtiene un detalle del presupuesto:

Cod Elemento PM ARQ AN PR

Jo

rnad

as

Co

ste

Jo

rnad

as

Co

ste

Jo

rnad

as

Co

ste

Jo

rnad

as

Co

ste


0.1 Iniciación

0.2 Planificación

0.3 Ejecución

0.4 Cierre

1 FASE I





1.1.4.1 Dato 1

1.1.4.2 Dato 2

1.1.4.3 …



1.1.5.2 Versionado


1.1.5.4 Otros


IMPORTANTE: En ningún caso se deberá incluir información Económica en el Documento de [Propuesta Técnica]; TODA la información económica debe incluirse en su totalidad en la [Propuesta Económica]



Página:

75/100











1.3.1.2 UI pública

1.3.1.3 UI privada





1.3.2.2.2 Log


1.3.2.2.4 …


1.3.3.1 Dato 1

1.3.3.2 Dato 2

1.3.3.4 …



1.4.1 Análisis


1.4.3 Construcción



1.4.3.3 …

1.4.4 Validación

2 FASE II

2.1 Objetivo 1: Análisis orígenes de datos

2.1.1 Dato 1

2.1.2 Dato 2

2.1.3 …



2.2.1.1 Dato 1

2.2.1.2 Dato 2

2.2.1.3 …




2.3.1 Despliegue

2.3.2 Carga Inicial





(*) Una vez más, este desglose de horas basado en la planificación temporal se considerará como orientativo (ver planificación RRHH - calendario).



Página:

76/100

8.5 Riesgos

Se han identificado los siguientes puntos de riesgo antes los cuales se deberán exponer acciones mitigadoras en la oferta.

Así mismo, si el ofertante identifica algún punto de riesgo no recogido en esta lista, deberá exponerlo en su oferta junto con la acción mitigadora correspondiente puesta que los riesgos formarán parte del contrato inicial y serán tenidos en cuenta y evaluada a lo largo de la vida del proyecto.

Área Descripción Categoría Impacto Acciones

Gestión del proyecto

Variación en el alcance debido a la variación de los requisitos funcionales

Planificación Alto Evitar

- Informar de los movimientos y acciones a ejecutar

- Trabajar en base a prototipos

- Crear servicios REST MOCK progresivamente según se va confirmando la viabilidad

Técnica Disponibilidad de entornos para el despliegue del producto

Ejecución Medio Evitar:

- Adelantar la provisión de entornos - Implantar en EJIE versiones iniciales

de las aplicaciones sin esperar a tener todo el producto construido

Técnica Falta de colaboración por parte de los responsables técnicos / funcionales de los orígenes de datos

Falta de documentación de los datos en su origen

Disponibilidad / acceso a los orígenes de datos

Ejecución Alta Evitar:

- Definir los orígenes de datos en cuanto sea posible para que se puedan iniciar cuanto antes las tareas relacionadas

- Avanzar en los trabajos de construcción en base a muestras de los datos

- Avanzar la construcción para orígenes bien definidos definiendo en paralelo el acceso a los menos claros

- Monitorizar el avance de la construcción de tareas por parte de [PCI-EJIE]

Técnica Capacidad por parte de PCI-EJIE a la hora de implementar funciones en el CORE y exponerlas en los API

Ejecución Alta Mitigar

- Apoyo técnico y humano en las tareas de construcción al equipo PCI-EJIE

Evitar

- Definir las necesidades del CORE / API en cuanto sea posible para que se puedan adelantar los trabajos por parte de PCI-EJIE

Técnica Dificultad a la hora de cargar la información debido a inconsistencias, volumen de datos, incapacidad para correlar registros, etc

Ejecución Alta Evitar

- Hacer pruebas de concepto lo más reales posible

- Empezar los procesos de migración en fases tempranas

Para cada uno de los riesgos identificados y aquellos que pueda identificar el licitante, se propondrá:

Acciones destinadas a mitigar la aparición riesgo

Acciones a tomar en caso de la eventual aparición del riesgo



Página:

77/100

8.6 Planificación de la Calidad

EJIE contempla la calidad en dos ámbitos de aplicación:

Calidad en los procesos

Para asegurar la calidad en el proceso de gestión del proyecto, durante le ejecución del mismo el adjudicatario deberá contemplar lo especificado en el punto anterior [Gestión del Proyecto]

Calidad en los productos

El adjudicatario del presente proyecto, deberá contemplar la ejecución de las tareas propias de una metodología de pruebas que al menos debe incluir:

Definición y gestión del plan de pruebas (incluyendo la definición de checklists de verificación)

Ejecución de los checklists de verificación en los momentos definidos en el plan de pruebas

Realización del Informe Final de Pruebas en el momento de puesta en marcha del sistema

Seguimiento y gestión de incidencias post puesta en marcha y durante la duración del periodo de garantía

Lo anterior es una visión general de las pruebas, pero específicamente de deben diseñar e implementar los mecanismos técnicos para automatizar los siguientes conjuntos de pruebas:

Pruebas de conformidad con las especificaciones

Pruebas de carga y alta disponibilidad de los componentes individuales del sistema

Estas pruebas unitarias deben automatizarse y obtenerse reportes de las mismas que serán entregables finales del proyecto tal y como se ha descrito anteriormente.

En este punto, se considera de vital importancia el diseño de un buen plan de test y la previsión de la automatización de las mismas para validar el funcionamiento de los APIs expuestos

Recordar que el diseño y creación de los TEST se hace en la FASE I contra los datos mock simulados y se reutiliza en la FASE II contra los datos reales cargados para su validación



Página:

78/100

8.7 Comunicaciones

Las entidades participantes en el proyecto son las que se detallan a continuación:

Entidad Rol

DACIMA Sponsor

Definición de requisitos funcionales

Gestión del cambio organizativo

Dirección de Atención de Emergencias y Meteorología

Definición de Requisitos funcionales

Gestión del cambio organizativo

Coordinar y facilitar acceso a los orígenes de datos

Responsables de OpenData / Transparencia en DACIMA

Definición de requisitos funcionales

Usuarios/as finales

Servicio web de DACIMA Directrices de presencia en internet

Servicio de Geo-Euskadi Exposición de datos geográficos / directiva INSPIRE

PCI-Web (EJIE) Gestión técnica del proyecto

Construcción, implantación y pruebas de las aplicaciones informáticas

Construcción de algunas partes del sistema:

Apoyo en el conocimiento de [PLATEA-Web] / [LOD]

A.T. Seguridad EJIE Definición funcionar y técnica

Apoyo técnico

Empresa de servicios adjudicataria

Análisis

Construcción del producto

Implantación y pruebas de los productos



Página:

79/100


9.1 Metodología

La gestión del proyecto objeto del presente Pliego de Condiciones Técnicas se basará en la adaptación al mismo de la metodología y buenas prácticas descritas en el Project Management Body Of Knowledge publicado por el Project Management Institute que identifican un ciclo de gestión basado en cinco grupos de procesos:

La gestión de proyectos es iterativa: el producto se va definiendo cada vez más conforme se va conociendo más acerca del mismo durante la ejecución del proyecto.

Iniciación Fundación del proyecto: definición de objetivos generales (alcance inicial), equipo, riesgos, etc.

NOTA: El Presente Pliego de Condiciones técnicas y la

oferta correspondiente se pueden considerar como un documento del grupo de procesos de iniciación ya que define en algún grado el alcance

Planificación Definir con el mayor grado de precisión posible el alcance del proyecto.

Planificar los costes, calendario y recursos

Definir estándares de calidad y aceptación

Identificar riesgos y definir estrategias de mitigación y actuación.

Ejecución Dirigir la ejecución del trabajo según lo especificado en el plan

Monitorización y Control

Verificar que el trabajo que se está realizando se ajusta a lo especificado en el plan en cuanto a costes, calendario, calidad.

Identificar la aparición de riesgos

Cierre Archivado de documentación de proyecto

Lecciones aprendidas

Cierre administrativo

En este punto hay que señalar que la metodología anterior es una metodología de gestión del proyecto que no es lo mismo que el ciclo de vida de un proyecto que es:

Las fases en que se divide un proyecto: aquellas que conectan el principio del proyecto con el final del mismo.

Describe qué hay que hacer para hacer el trabajo del proyecto

En el presente proyecto, el software y las infraestructuras se definirán y construirán iterativamente enfocando hacia la solución a medida que se vaya definiendo el sistema, esto implica que la ejecución comenzará una vez alcanzado un grado suficiente de planificación, específicamente sin esperar a tener un análisis funcional o un diseño técnico cerrados. Esta estrategia tiene un cierto riesgo de repetición de trabajo, pero controlando el riesgo adecuadamente, puede contribuir a una mayor calidad y menor tiempo de construcción.

Esta estrategia de “comienzo temprano” del desarrollo permitirá detectar riesgos técnicos en estadios iníciales y redundará en una involucración y conocimiento técnico del sistema por parte de todo el equipo desde el principio de proyecto.

Planning

Processes

Group

Executing

Processes

Group

Closing

Processes

Group

Initiating

Processes

Group

Monitoring & Controlling

Processes Group



Página:

80/100

En la práctica, una vez adjudicado el proyecto:

1. La dirección del proyecto EJIE “fundará” el proyecto:

a. Nombrando un Project Manager que será la autoridad responsable de la gestión del proyecto

b. Proporcionando el entorno para la ejecución del mismo

c. Identificando las personas y entidades implicadas o afectadas por el proyecto

d. Definiendo los objetivos de alto nivel del proyecto

e. Definiendo las restricciones (de tiempo, expectativas, etc.) y asunciones iníciales

2. La empresa adjudicataria, trabajando bajo la autoridad de la dirección del proyecto definirá el plan de proyecto:

a. Definirá con la mayor exactitud posible el alcance del proyecto

b. Realizará una descomposición de los trabajos y tareas al mayor nivel de desglose posible

Se utilizará un diagrama de descomposición de tareas (WBS) exhaustivo que permita gestionar la ejecución de cada una de las tareas en iteraciones.

La descomposición de tareas se mantendrá permanentemente actualizada y cualquier elemento (paquete de trabajo) en el que se esté trabajando en un momento dado deberá quedar reflejado en WBS

c. Realizará una planificación en tiempo y costes para la ejecución de los trabajos identificados

d. Realizará un plan de comunicación fundamentalmente encaminado a:

i. Obtener informes puntuales y exactos del rendimiento de la ejecución de cada uno de los trabajos

ii. Mantener a los implicados / afectados en el proyecto al día de aquello que les interesa

e. Identificará los riesgos y los planes de respuesta

f. Definirá los estándares de calidad para la aceptación de cada uno de los entregables

3. Una vez definido el plan de proyecto, el equipo de proyecto comenzará la ejecución de las tareas definidas en el plan.

4. La monitorización y control del proyecto será realizado por el Project Manager del proyecto contando con la colaboración del staff de gestión de la empresa adjudicataria para:

a. Identificar cambios en el alcance

b. Detectar desviaciones en tiempo y costes

c. Detectar desviaciones en la calidad de los trabajos realizados.

d. Identificar la eventual aparición de un riesgo identificado

NOTA: Cualquier cambio, corrección, mejora, etc que impacte en el alcance definido. requerirá de aprobación formal por parte de EJIE / DACIMA y re-planificación

5. Finalmente, cuando todos los entregables del proyecto se hayan llevado a cabo, se entrará en la fase de cierre del proyecto que implica principalmente:

a. Recopilación de la documentación del proyecto

b. Recopilación de lecciones aprendidas

c. Liberación del equipo

Es importante recalcar que el procedimiento de gestión del proyecto es iterativo en línea con los ciclos de mejora PDCA (Plan-Do-Check-Act), por lo tanto, los grupos de proceso anteriores no son grupos cerrados ni secuenciales, sino que debido a la naturaleza de elaboración progresiva de los proyectos, podrán ser “visitados” de forma iterativa a lo largo de la vida del proyecto.



Página:

81/100

9.2 Equipo de Trabajo

Los intervinientes en el proyecto, tanto del Gobierno Vasco (Liburutegiak / DACIMA) como de EJIE, o de la empresa adjudicataria, participaran desempeñando los roles indicados en la siguiente tabla:

DACIMA Rol Funciones Funciones en el proyecto

Dirección Sponsor. o Sponsor del proyecto o Proporciona las condiciones para la

realización del proyecto o Actúa como cliente y puesto que es el

destinatario del producto.

Responsables del área de [OpenData] / [Transparencia]

Responsable funcional o Definición funcional o Participa en el análisis o Participa en las pruebas o Valida entregables

Técnico/a del servicio web

Directrices acerca de la presencia web

o Participa en los diseños web o Establece las directrices de usabilidad /

accesibilidad

Dirección de Atención de Emergencias y Meteorología

Rol Funciones Funciones en el proyecto

Dirección Responsable funcional Propietario de los datos

o Proporciona las condiciones para la realización del proyecto

o Actúa como cliente y puesto que es el destinatario del producto.

Técnicos/as Responsable funcional o Definición funcional o Participa en el análisis o Participa en las pruebas o Valida entregables

Otras áreas del GV

Rol Funciones Funciones en el proyecto

Dirección Propietario de los datos o Autoriza el uso de los datos.

Técnicos/as Conocimiento de los datos o Facilita el acceso a los datos

EJIE Rol Funciones Funciones en el proyecto

Project Manager de

la Asistencia Técnica EJIE

Responsable de la ejecución del proyecto.

o Project Management: gestión del alcance, comunicaciones, riesgos, calidad y recursos del proyecto.

o Coordinación con el resto de áreas de EJIE

Staff técnico de

EJIE adscrito al proyecto

Apoyo técnico o Especificaciones técnicas o Pruebas técnicas o Coordinación técnica: implantación, pruebas,

etc.

Responsables funcionales de otras áreas de EJIE (Sistemas / Explotación / Cambios)

Soporte técnico al proyecto o Participan en la validación de la solución y arquitectura técnica

o Prescriben requisitos técnicos de albergue o Proporcionan recursos especializados al

proyecto si así lo requiere



Página:

82/100

Empresa adjudicataria

Las empresas que opten a la ejecución del proyecto objeto del presente Pliego de Condiciones Técnicas, propondrán un equipo de trabajo eminentemente funcional y técnico con las siguientes figuras:

Rol Conocimientos Funciones en el proyecto

Jefe de proyecto Project Management

Colabora en el management del proyecto junto con el Project Manager de EJIE en: o Verificación de que el proyecto se está ajustando a

lo especificado en el plan o Supervisión de las tareas realizadas por el equipo:

medida del rendimiento o Reporte del rendimiento (tiempo-avance / costes)

de los trabajos en curso o Identificación de riesgos o Identificación de cambios en el alcance o Gestión de recursos del proyecto

Analistas Análisis de sistemas

o Análisis o Coordinación de los trabajos de construcción

Desarrolladores / Especialistas Web

Construcción o Construcción del software o Carga de datos

NOTAS sobre el Equipo de Trabajo y Organización: El presente proyecto como todos los proyectos es un esfuerzo temporal en el que se comprometen una serie de recursos para crear un producto único y como tal es muy importante que el equipo de proyecto tenga la capacidad suficiente para abordar el trabajo y que además permanezca estable durante el desarrollo del

mismo.

Por la razón descrita, el adjudicatario intentará mantener un equipo estable de personas que intervendrán en el proyecto según lo planificado en el Plan de Proyecto.

El equipo de trabajo propuesto estará formado por personal técnico con categoría profesional y nivel de especialización adecuados a las necesidades planteadas en cada momento, de acuerdo con las actividades que se vayan desarrollando.

9.2.1. Constitución inicial del equipo de trabajo

El equipo técnico a incorporar tras la formalización del contrato para la ejecución de los trabajos deberá estar formado por componentes y perfiles incluidos en la oferta adjudicataria y consecuentemente valorados.

Si tras la adjudicación se observara que el equipo de proyecto no se corresponde con el establecido en la oferta y:

Caso que el adjudicatario presente justificación escrita, detallada y suficiente, explicando el

motivo que suscita el cambio, se procederá a:

La presentación por el adjudicatario de sustituto/s con un perfil de cualificación técnica

igual o superior al de la persona que se pretende sustituir.

Aceptación del sustituto/s por parte de la Dirección del Proyecto de EJIE

Caso de que se demostrase que el cambio no se corresponde con causa justificada, EJIE se

reserva el derecho no solo a la aprobación del sustituto/s sino incluso a la revisión de la

adjudicación y en su caso la rescisión del pedido/contrato, si este hecho fuera elemento

determinante en la mencionada adjudicación.



Página:

83/100

9.2.2. Modificaciones en la composición del equipo de trabajo

El licitador se compromete, en caso de ser adjudicatario, a mantener el equipo, según lo establecido en la oferta, y durante el periodo fijado en cada actividad específica.

Los recursos asignados a la ejecución del contrato deberán estar asignados desde el inicio del mismo

Las modificaciones del equipo pueden tener dos orígenes:

EJIE La valoración de la calidad de los servicios objeto del presente [Pliego de Condiciones Técnicas] corresponde a la Dirección del Proyecto de EJIE, siendo su potestad solicitar el cambio de cualquiera de los componentes del equipo de trabajo por las siguientes razones:

- inadecuación de los recursos

- incumplir los requisitos tanto de solvencia como técnicos exigidos

para llevar a cabo este cambio, EJIE debe preavisar al adjudicatario con quince días de antelación y este debe sustituir al/la componente del equipo por otro/a de igual categoría o superior, si existen razones justificadas que lo aconsejen.

En el caso extremo de haber declarado el contratista unas circunstancias respecto al equipo de trabajo que no son veraces EJIE podrá rescindir del contrato y adjudicar al licitador siguiente en las calificaciones

Adjudicatario Si el adjudicatario propusiera el cambio de alguna de las personas del equipo de trabajo, se deberá solicitar por escrito con quince días naturales de antelación, y requerirá de las siguientes condiciones:

Justificación escrita, detallada y suficiente, explicando el motivo que suscita el

cambio.

Presentación de sustituto/s con un perfil de cualificación técnica igual o

superior al de la persona que se pretende sustituir.

Aceptación del sustituto/s por parte de la Dirección del Proyecto de EJIE

En todo caso:

El/la sustituto/a o sustitutos/as tendrán un perfil igual o superior al ofertado, o recurso a sustituir

Los posibles inconvenientes de adaptación al entorno de trabajo y al proyecto debidos a las

sustituciones de personal, deberán subsanarse mediante periodos de solapamiento, durante el

tiempo necesario.

En cualquier caso, al tratarse de un proyecto cerrado (llave en mano) la sustitución de un/una

componente del equipo NO implica ningún tipo de coste adicional.

9.2.3. Horario y lugar de realización de los trabajos.

Los trabajos de desarrollo se realizarán normalmente en las dependencias del adjudicatario en cuyo caso:

La jornada de trabajo estará de acuerdo a la establecida por el adjudicatario,

Los componentes del grupo de trabajo deberán estar en una única ubicación y desarrollarán su

labor con hardware y software propiedad del adjudicatario.

Se deberá garantizar una presencia rápida en EJIE, ante cualquier eventualidad que pudiera

surgir.

Las reuniones, pruebas de integración, carga, aceptación y la puesta a punto de los productos se realizarán en los locales de EJIE



Página:

84/100

En aquellos casos en que los trabajos deban ser realizados en las dependencias de EJIE, estos se realizarán en las siguientes condiciones:

La jornada de trabajo estará de acuerdo a la establecida por EJIE,

Con carácter general los componentes del grupo de trabajo deberán desarrollarán su labor con

hardware y software propiedad del adjudicatario, salvo para labores de instalación,

implantación, y puesta en marcha, que se realizará mediante los puestos asignados por la

Dirección del Proyecto de EJIE

Si por circunstancias excepcionales y cuando la realización efectiva de los trabajos no se

ajuste a la planificación o así se requiera por las necesidades del servicio, el adjudicatario

deberá comprometerse a una plena disponibilidad incluso fuera del horario habitual (salvo

acuerdo previo por la Dirección del Proyecto de EJIE), sin que la realización del trabajo tenga

una consideración especial a efectos de cómputo de horas o tarifa aplicable a las mismas (el

proyecto es cerrado –llave en mano-)



Página:

85/100

9.3 Organización del Proyecto / Estructuras de Control

Pese a que la organización exacta del proyecto tal y como se ha descrito anteriormente se definirá exactamente en las fases de iniciación y planificación del proyecto, hay una estructura mínima que existirá a lo largo de la vida del proyecto:

Visión del proyecto a nivel de dirección

Dirección y cambios

Componentes Responsable de DACIMA

Responsable de Dirección de Meteorología

Responsable [Transparencia] de [DACIMA]

Dirección de Proyecto de EJIE

Dirección de Proyecto del Adjudicatario

Cualquier persona de la que se considere necesario su asistencia

Reuniones Lugar: EJIE

Periodicidad: mensual o en función de las necesidades puntuales del

proyecto, en base a convocatorias formales por parte de la dirección de proyecto del Adjudicatario o de EJIE

Temas Entorno del proyecto: protección de las condiciones de existencia del mismo.

Evolución y seguimiento del proyecto

Verificación del alcance: verificar que se está trabajando única y exclusivamente en el alcance definido.

Variaciones en el alcance: aprobación / Rechazo de cambios de alcance Certificaciones parciales

Cualquier tema relativo al proyecto que se considere necesario

Comité técnico: tratar de minimizar riesgos técnicos.

Técnico Componentes Staff técnico de EJIE

Tecnico/a funcional de [transparencia] de [DACIMA]

Técnico/a funcional de [meteorología] de la [Dirección de Meteorología]

Staff técnico del adjudicatario

Cualquier persona de la que se considere necesario su asistencia

Reuniones Lugar: EJIE

Periodicidad: en función de las necesidades puntuales del proyecto, en

base a convocatorias formales por parte de la dirección de proyecto del Adjudicatario o de EJIE

Temas Aspectos técnicos o de diseño del sistema

Identificar riesgos técnicos.



Página:

86/100

NOTAS IMPORTANTES A TENER EN CUENTA:

El control y seguimiento del proyecto se hará utilizando la metodología, herramientas y directrices designadas por EJIE que en líneas generales se han descrito en el presente documento

Se levantará acta de cuantas reuniones formales se realicen en los comités de decisión señalados en este punto [Organización del proyecto y estructuras de control] donde se tomarán decisiones relevantes para la marcha del proyecto.

Es responsabilidad del adjudicatario el levantamiento de las actas de reunión.

En las reuniones informales / técnicas o de seguimiento habitual no es necesario el levantamiento de actas, aunque sí que se considera una buena práctica.

Las decisiones tomadas en este tipo de reuniones menos “formales” no son vinculantes ya que la propia filosofía de ejecución ágil e iterativa del proyecto puede hacer que se cambien criterios o decisiones.

De la misma forma la documentación, el código del proyecto y en general todo el material compartido debe ser almacenado y versionado en servidores de trabajo colaborativo (sharepoint para la documentación, subversion para el código, etc) de forma que cualquier integrante del proyecto pueda tener acceso a toda la documentación del mismo.

Si alguna de estas normas no es respetada, puede dar lugar a la no aceptación de los entregables involucrados.

9.4 Transferencia Tecnológica.

Durante la ejecución de los trabajos objeto del contrato el adjudicatario se compromete, en todo momento, a facilitar a las personas designadas por la Dirección del proyecto de EJIE, y a tales efectos, la información y documentación que ésta solicite para disponer de un pleno conocimiento de los trabajos desarrollados, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos, y herramientas utilizados para resolverlos.



Página:

87/100

10 Presupuesto y Plazo

10.1 Presupuesto

Presupuesto Máximo 66.115 €+ IVA

Valor estimado (incluidas prórrogas) 66.115 €+ IVA

10.2 Plazo

La [Planificación Temporal / Calendario] incluida en la [Propuesta Técnica] se utilizará como base orientativa y será definida una vez empezado el proyecto cuando el adjudicatario tenga completo conocimiento del entorno, restricciones, alcance detallado, etc.

11 Plazo de Vigencia del Contrato

El contrato tendrá una duración máxima de 18 meses.

IMPORTANTE: En ningún caso se deberá incluir información Económica en el Documento de Propuesta Técnica; TODA la información económica debe incluirse en su

totalidad en la [Propuesta Económica]



Página:

88/100

12 Contenido de las Ofertas

El contenido de las ofertas se deberá atener a los requisitos expresados en el presente [Pliego de Condiciones Técnicas] poniendo especial interés entre otros en:

Analizar la solución funcional y técnica recogida en el presente documento evidenciando el entendimiento del objetivo del proyecto.

Proponer un equipo con capacidad contrastada para abordar el proyecto que demuestre la capacidad del licitante para ejecutar el trabajo.

Proponer una metodología de gestión que asegure una correcta iniciación, planificación, ejecución y cierre del proyecto.

De esta forma, y específicamente las ofertas deben contener al menos:

12.1 Solvencia

Las empresas interesadas en participar en el concurso objeto del presente [Pliego de Condiciones Técnicas] han de demostrar -además de otros requisitos recogidos en otros documentos de condiciones del concurso- que tienen la capacidad suficiente para abordar el proyecto.

Esta capacidad es un requisito necesario por lo que NO demostrar la capacidad (solvencia técnica) implica la exclusión del proceso de valoración.

Para su valoración, en el documento de [Solvencia] se incluirá:

Know-how de la empresa

Proyectos similares Descripción de proyectos similares abordados por el ofertante en

otras Administraciones incluyendo:

- Año de puesta en servicio (o de inicio del proyecto en caso de no estar aún operativo)

- Descripción detallada de los objetivos del proyecto, así como sobre la solución técnica implementada

- Personas de contacto

- Otros datos que se consideren que puedan proporcionar una visión del proyecto

La empresa debe haber participado en:

Al menos DOS proyectos en los últimos 4 años en los que uno de los objetivos sea el análisis / documentación y exposición de servicios REST en tecnología Java preferentemente aunque se aceptan como válidas de cara a esta faceta de la solvencia otras tecnologías base

Al menos DOS proyectos en los últimos 4 años relacionados con la depuración y consolidación de datos de diversas fuentes.

Al menos DOS proyectos en los últimos 4 años en tecnología Java EE



Página:

89/100

Equipo de trabajo

Para todos/as los/las componentes del equipo se incluirá:

Breve currículum incluyendo conocimientos y participación en proyectos similares (abstenerse de incluir aquello no aplicable a este proyecto)

Descripción de proyectos similares abordados por el ofertante

Los conocimientos mínimos exigibles para cada perfil, así como las evidencias de los mismos

son los siguientes:

Cod Recurso Conocimiento Evidencia

PM Project Manager Gestión de Proyectos Certificación reconocida en [Gestión de Proyectos] como:

- Project Management Professional-PMP del Project Management Institute

- Certification del International Project Management Institute (IPMA)

- Otra certificación equivalente

ARQ Arquitecto Tecnología Java EE

Stores de datos relacionales y no relacionales

Exposición de servicios REST

Tecnologías OpenData

Participación en:

Al menos dos proyectos en los que se analice / documente y expongan servicios REST

Al menos dos proyectos relacionados con la consolidación de datos

Al menos un proyecto relacionado con la apertura de datos (open data)

AN Analista Análisis de datos

Documentación y exposición de servicios REST

Tecnologías OpenData

PR Programador

Técnico de sistemas

Se deben proponer personas con los conocimientos necesarios para abordar el proyecto en base a las tecnologías propuestas por el ofertante

- Titulación universitaria superior o técnica en Ingeniería (informática, telecomunicaciones, u otras de carácter técnico ciencias exactas, físicas,etc)

- Experiencia demostrada en tecnologías Java / EE

PR Diseñador web - Experiencia demostrada en:

o Diseño Web

o HTML / CSS / JS y frameworks propuestos

NOTA: La documentación de solvencia se incluirá en el [SOBRE A]

http://www.pmi.org/certification.aspx

http://www.pmi.org/certification.aspx

http://www.ipma.world/certification/certify-individuals

http://www.ipma.world/certification/certify-individuals



Página:

90/100

12.2 Propuesta Técnica

El contenido de la [Propuesta Técnica] tiene como objetivo evaluar tres áreas:

- Entendimiento del proyecto y el entorno

- Viabilidad de la Propuesta

- Capacidad de Gestión

Área a evaluar Descripción

Propuesta técnica básica



Desarrollar el pre-análisis mínimo contenido en el presente documento de [Pliego de Condiciones Técnicas] para detallar los objetivos del proyecto:

Fase I Objetivo 1: Análisis Metodología de análisis, propuestas de fichas, formatos, etc

Objetivo 2: Documentación Metodología de documentación, herramienta a utilizar, etc

Objetivo 3: Construcción Descripción funcional y técnica detallada del subsistema de auto-gestión y gestión interna de API-Keys

Tecnología de almacenamiento de datos

Tecnología de exposición de servicios REST y gobernanza de los mismos

Objetivo 3: Web Components Metodología

Tecnología

FASE II Objetivo 1: Análisis Metodología de análisis, propuestas de fichas, formatos, etc

Objetivo 2. Construcción Metodología de ejecución


En definitiva:

En la [propuesta técnica básica] el ofertante ampliará lo recogido en el presente documento en cuanto a análisis funcional / tecnología y planificación (tiempos / recursos / riesgos / etc) con el objetivo de demostrar:

El entendimiento del alcance

El entendimiento funcional / técnico de los objetivos del proyecto

El conocimiento funcional / técnico de la empresa

La viabilidad funcional / técnica de la propuesta



Página:

91/100

Enfoque de Gestión




En base a las especificaciones en lo que a la gestión del proyecto se refiere recogidas en el punto [Gestión del Proyecto], se desarrollará el enfoque para iniciar, planificar, ejecutar, monitorizar / controlar y cerrar el proyecto en el que se detallarán:

Metodologías de gestión del proyecto

Gestión de involucrados

Órganos de seguimiento / control

Documentación de gestión e Informes tipo

Enfoque de gestión de riesgos

Enfoque, metodologías y herramientas a utilizar para el aseguramiento de la calidad en los procesos y control de la misma en los productos.

Planificación de alcance, recursos y calendario




Estimación del proyecto tomando como base orientativa la estimación recogida en el punto [Planificación], la oferta incluirá:

Identificación de involucrados (stakeholders)

Estructura de descomposición del trabajo a alto nivel

Recursos involucrados en cada uno de los elementos de la estructura de descomposición de trabajo y carga en jornadas

Planificación temporal (calendario) de la ejecución indicando los recursos a

utilizar en cada uno de los elementos de la estructura de descomposición del trabajo, así como las fases de ejecución

La planificación temporal únicamente se utilizará para estimar la viabilidad de la propuesta y en general el entendimiento del proyecto; es decir, no es vinculante

como SI lo son el alcance y coste.

La planificación definitiva del proyecto será realizada por el equipo del proyecto en la fase de Planificación y en base al conocimiento del proyecto que se vaya adquiriendo en sus fases iniciales.

Planificación de Riesgos que el ofertante identifica (ampliando y modificando la pre-identificación recogida en este documento) y acciones mitigadoras que eviten la aparición del riesgo o contingencias en caso de una eventual incidencia del mismo.



Página:

92/100

12.3 Propuesta Económica

En la [Propuesta Económica] se incluirá el [Presupuesto Total] del proyecto (valor estimado) que será el utilizado para valorar económicamente la oferta (ver [Criterios de Valoración]).

No obstante de lo anterior, y con el objetivo de tener una mayor información sobre el origen de este presupuesto total, en la [Propuesta Económica] se incluirá un detalle orientativo del cálculo del presupuesto tal y como se ha descrito anteriormente:

El presupuesto total debería basarse en la agregación de los costes unitarios de cada actividad calculada en función de las tarifas de los recursos y el número total de jornadas planificadas para dicha actividad:

𝑐𝑜𝑠𝑡𝑒 𝑎𝑐𝑡𝑖𝑣𝑖𝑑𝑎𝑑 = 𝑐𝑜𝑠𝑡𝑒 𝑟𝑒𝑐𝑢𝑟𝑠𝑜𝑠 𝑥 𝑗𝑜𝑟𝑛𝑎𝑑𝑎𝑠 𝑝𝑙𝑎𝑛𝑖𝑓𝑖𝑐𝑎𝑑𝑎𝑠

Por lo que en base a un cuadro de tarifas por perfil como:

Cod Recurso Tarifa € / jornada

Coste (€)

PM Project Manager

Perfil A Descripción del perfil

Perfil B Descripción del perfil

Perfil Z Descripción del perfil

Se obtiene un detalle del presupuesto:

Cod Elemento Perfil 1 Perfil 2 … Perfil Z

Jo

rnad

as

Co

ste

Jo

rnad

as

Co

ste

Jo

rnad

as

Co

ste

Jo

rnad

as

Co

ste


1 Actividad 1

2 Actividad 2

3 Actividad 3

… …

N Actividad N

Total

Conformando un total de:

Total €

El importe máximo del contrato es de 66.115 €+ IVA

IMPORTANTE: En ningún caso se deberá incluir información Económica (COSTES) en el Documento de [Propuesta Técnica]; TODA la información económica debe incluirse en su totalidad en la

[Propuesta Económica]



Página:

93/100

13 Criterios de Adjudicación

En el punto anterior ([Contenido de las Ofertas]) se ha detallado el contenido mínimo exigible en las ofertas, indicando además el fin por el que se solicita de cara a la evaluación de la propuesta según la siguiente tabla:

Puntos Criterio

55 Valoración económica: [Propuesta Económica]

Se adjudicarán 55 puntos a la oferta más baja y al resto los puntos resultantes de aplicar la siguiente fórmula:

55 × 𝑃𝑟𝑒𝑐𝑖𝑜 𝑂𝑓𝑒𝑟𝑡𝑎 𝑚á𝑠 𝑏𝑎𝑗𝑎

𝑃𝑟𝑒𝑐𝑖𝑜 𝑂𝑓𝑒𝑟𝑡𝑎 𝐸𝑣𝑎𝑙𝑢𝑎𝑑𝑎

45 Viabilidad de la propuesta y entendimiento del proyecto en función de lo expresado en el punto anterior al respecto del contenido de la [Propuesta Técnica]

Se asignará una puntuación de entre [0 y 10] en base a la siguiente tabla:

Puntuación Entendimiento del alcance

(entendimiento del objeto requerido)

Detalle de la propuesta técnica Viabilidad técnica

(posibilidades de implementar la propuesta)

0 NO se entiende el objetivo Ningún detalle Imposible de implementar

3 Entendimiento mínimo Detalle mínimo Implementación compleja

6 Entendimiento aceptable Detalle aceptable Implementación plausible

10 Entendimiento excelente incluyendo alternativas

Detalle excelente Implementación plausible incluyendo alternativas

NOTA: Tomando estos valores de 0, 3, 6 y 10 se podrán asignar valores intermedios (ej: 2 o 5)

Área a evaluar Descripción Puntos

Propuesta técnica básica

Desarrollar el pre-análisis mínimo contenido en el presente documento de [Pliego de Condiciones Técnicas] para detallar:

Modelo lógico común

Posibles orígenes de datos y su adaptación al modelo lógico común para consolidar dato único

Posibles mecanismos de extracción de datos para cada origen de datos

Exposición en OpenData Euskadi

etc

4

Enfoque de Gestión Enfoque de la gestión del proyecto 2

Planificación orientativa del alcance, recursos y calendario

Identificación de involucrados (stakeholders)

Estructura de descomposición de trabajo

Recursos involucrados en cada paquete de trabajo

Planificación temporal

Planificación de riesgos

NOTA: La planificación temporal únicamente se utilizará para estimar la viabilidad de la propuesta y en general el entendimiento del proyecto; es decir, no es vinculante como SI lo son el alcance y coste.

La planificación definitiva del proyecto será realizada por el equipo del proyecto en la fase de Planificación y en base al conocimiento del proyecto que se vaya adquiriendo en sus fases iniciales.

4



Página:

94/100

En base a la tabla de valoración anterior

1. Se valorará cada ítem de cada [Propuesta Técnica] asignando puntos de [0 a 10]

2. Se sumarán los puntos

3. UMBRAL TÉCNICO: Cualquier oferta que NO supere en la parte [técnica] los 5 puntos sin ponderar de los 10 posibles será automáticamente descartada

4. Se adjudicarán 45 puntos a la oferta con más puntos y al resto los puntos resultantes de aplicar la siguiente

fórmula de ponderación:

45 × 𝑃𝑢𝑛𝑡𝑜𝑠 𝑡𝑜𝑡𝑎𝑙𝑒𝑠 𝑑𝑒 𝑙𝑎 𝑜𝑓𝑒𝑟𝑡𝑎 𝒆𝒗𝒂𝒍𝒖𝒂𝒅𝒂

𝑃𝑢𝑛𝑡𝑜𝑠 𝑡𝑜𝑡𝑎𝑙𝑒𝑠 𝑑𝑒 𝑙𝑎 𝑜𝑓𝑒𝑟𝑡𝑎 𝑐𝑜𝑛 𝒎𝒂𝒚𝒐𝒓 𝑝𝑢𝑛𝑡𝑢𝑎𝑐𝑖ó𝑛



Página:

95/100

14 Facturación

Teniendo en cuenta los hitos principales del proyecto:

Fase I Objetivo 1: Análisis

Objetivo 2: Documentación


Objetivo 4: Web components

FASE II Objetivo 1: Análisis



la facturación por parte del ofertante una vez adjudicado el mismo se ligará a los siguientes hitos de facturación:

HITO Descripción Importe

H0 Adjudicación del proyecto 10%

H1 FASE I: Objetivo 1 (análisis) y Objetivo 2 (documentación) finalizados

20%

H2 FASE I: Objetivo 3 (construcción) y Objetivo 3 (web components) finalizados

20%

H3 FASE II: Objetivo 1 (análisis) y Objetivo 2 (construcción) finalizados

30%

H4 FASE II: Objetivo 3 (despliegue) finalizado 20%



Página:

96/100

15 Contacto

Alex Lara Garachana

Responsable de Proyectos de Presencia en Internet / Atención a la Ciudadanía (Zuzenean) e Interoperabilidad con las Entidades Financieras

Tfno: 688671967

e-mail: [email protected]

Alex Lara Garachana

Responsable de Proyectos:

Presencia en Internet/Intranet

Zuzenean: Atención a la Ciudadanía

Interoperabilidad con Entidades Financieras

Tel.: (+34) 688671967

Mail:[email protected]

Avda. Mediterráneo, 14

01010 Vitoria-Gasteiz

Tel. (+34) 945 01 73 00*

Fax. (+34) 945 01 73 01

www.ejie.eus

Con el objetivo de responder a cualquier duda sobre lo recogido en el [Presente Condiciones de Bases Técnicas], si así lo desea el ofertante, recibirán consultas en el correo electrónico [[email protected]]

Las consultas recibidas se responderán en un máximo de 7 días a partir de la recepción de la consulta por lo que se sugiere a los ofertantes que agrupen las consultas/dudas en un único correo.

mailto:[email protected]



Date post:	27-Apr-2023
Category:	Documents
Upload:	khangminh22
View:	0 times
Download:	0 times

[Transparencia y Apertura de Datos] - Euskadi.eus

Documents