Proyecto Piloto TDT

Proyecto Piloto TDT

Septiembre 2008 – Mayo 2009

Raúl Sanz de Acedo

Responsable del Centro Java y Open Source

CEIN, S.A.

This work is licensed under the Creative Commons Atribución 3.0 Unported License. To view a copy of

this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons,

444 Castro Street, Suite 900, Mountain View, California, 94041, USA.

http://creativecommons.org/licenses/by/3.0/

http://creativecommons.org/licenses/by/3.0/

INDICE

DEFINICIÓN 3

FASE 1 10

DESCRIPCIÓN PROCESO LANZADERA 12

DESCRIPCIÓN PROCESO SERVICIOS HACIENDA 16

CONCLUSIONES 22

FASE 2 23

METEOROLOGÍA 26

SELECCIÓN SIGUIENTES SERVICIOS 34

FARMACIAS DE GUARDIA Y FICHAS 35

CENTROS DE SALUD Y SERVICIO INTERACTIVO EDUCA 37

REFLEXIÓN 40

EXPERIENCIA (ORGANIZACIÓN) 40

EXPERIENCIA (TÉCNICA) 41

VISTA AL FUTURO 42

2 Proyecto Piloto TDT

Definición

15 de Octubre del 2006: “Has sido seleccionado para Responsable del Centro Java y Open Source”, no cabía en mi de gozo...eso ayudaría a afrontar lo que se avecinaba, “el 23 de Noviembre hay una reunión en NGA para conocer la encomienda del proyecto que nos han encargado y para presentarte como responsable, hazlo bien, mucho depende de este proyecto”.

Esta frase marcaría mi periplo durante el 2007, cuya experiencia trataré de transmitir a lo largo de este y los próximos artículos.

Así pues, allí me encontraba, el 23 de noviembre, esperando mi bautismo como “responsable” ante NGA y Gobierno, frente a un conjunto de personas que posteriormente se perfilarían como el comité de seguimiento y la dirección del proyecto, es decir, las personas con las que tenía que trabajar y aquellas a las que debía informar.

En esa dirección estábamos yo, como responsable, una persona de NGA y otra de la DGpSI. Nuestras funciones consistían en dirigir el avance del proyecto llevándolo a buen puerto, cumpliendo los objetivos marcados, tomando las decisiones pertinentes y llevando a cabo las acciones necesarias, todo de forma consensuada. Así mismo, este equipo debía rendir cuentas ante el comité sobre el avance y acciones. Este comité lo formaban representantes de CEIN, NGA y DGpSI.

Esa reunión nos puso caras a todos y nos fue entregada oficialmente la encomienda del proyecto que llevaba por título: PLIEGO DE PRESCRIPCIONES TÉCNICAS DE LA ENCOMIENDA A NGA PARA EL DESARROLLO EN LOS CENTROS DE EXCELENCIA DE UN PROYECTO PILOTO PARA EL DISEÑO E IMPLANTACIÓN DE UNA PLATAFORMA SOFTWARE PARA DESARROLLAR Y MANTENER SERVICIOS INTERACTIVOS A TRAVES DE LA TELEVISIÓN DIGITAL TERRESTRE (TDT)

A continuación resumo los puntos más importantes:

¿Porque la TDT y su papel para la administración? La tendencia actual es que la información sea accesible desde cualquier parte y con cualquier terminal. La familiaridad, comodidad, penetración y alcance de la TV la convierten en un dispositivo preferente para extender la Sociedad de la Información, para favorecer participación del tele-espectador (interactividad) y reducir la “brecha digital”: aquella población sin posibilidades de acceder a Internet por edad, reticencia, disposición, educación o poder adquisitivo. Por tanto, la TDT permite acercar la administración electrónica a aquellos ciudadanos a los que resulta difícil llegar a través de Internet: ancianos, niños, discapacitados, desempleados, ciudadanos con retas más, menor formación, etc, proporcionando a la ciudadanía un nuevo canal de Servicios Administrativos de interés público y la posibilidad de participar = una sociedad de la información amplia, participativa y democrática.

Objetivos Creación de aplicaciones sobre el estándar MHP (Multimedia Home Platform) que

permitan la integración de contenidos interactivos en la TDT (Televisión Digital Terrestre), y establecer un nuevo canal entre la Administración y los ciudadanos


potenciando el desarrollo de la e-Administración. Aprendizaje y transferencia de conocimiento a las empresas del sector TIC de

Navarra mediante el desarrollo del proyecto en los Centros de Excelencia. Había una serie de objetivos añadidos entres lo que cabe destacarse: potenciarla TDTy modernizarla administración.

Alcance del proyecto Definición de especificaciones y puesta en marcha de la plataforma tecnológica

necesaria para la generación y mantenimiento de aplicaciones interactivas en TDT sobre el estándar MHP.

Desarrollo de un conjunto de servicios hacia el ciudadano (priorizando los correspondientes a la Hacienda Tributaria),que abarquen todas las tipologías (Informativos, Interactivos y Transaccionales).

Plan inicialLa ejecución no podrá exceder 12 meses desde la formación del equipo de trabajo. En cualquier caso los trabajos estarán finalizados a 31 de diciembre de 2007.

Fase I: transferencia de conocimiento al equipo de trabajo, análisis funcional, especificación y puesta en marcha de la plataforma tecnológica necesaria para la generación y mantenimiento de aplicaciones interactivas en TDT sobre el estándar MHP

Fase II: implantación de servicios informativos sobre la plataforma base de Televisión Digital

Fase III: ampliación de funcionalidades de la plataforma de Televisión Digital, habilitando el canal de retorno (interactividad).

Equipo de trabajo Comité de dirección: dirección del proyecto, formado por el responsable del Servicio

de Promoción de la Sociedad de la Información, un responsable de NGA y el Jefe de Proyecto en el Centro de Excelencia.

Equipo de Trabajo: técnicos destinados al desarrollo del proyecto:o 1 persona del Servicio de Promoción de la Sociedad de la Información que

coordinará los contenidos a incluir (dedicación 10%).o 1 persona de NGA encargada de coordinar al equipo y los trabajos realizados

(dedicación 10%)o Responsable del Centro de Excelencia Java y Open Source (dedicación 60%)o Becario del Centro de Excelencia Java y Open Source con conocimientos de

Java (dedicación 100%)o 1 analista especializado en proyectos de desarrollos servicios TDT encargado

de aportar su experiencia y conocimiento (dedicación 50%)o ingeniero de desarrollo especialista en MHP (dedicación 60%)o técnicos de empresas del sector TIC de Navarra, con experiencia de 2 a 3

años en Java (dedicación %)

PlanificaciónSe elaborará un Plan de Trabajo que defina las tareas a realizar, los responsables de su ejecución y los resultados a obtener en cada caso. Se aportará también la secuencia y el cronograma de módulos o agrupación de funcionalidades que se proponga seguir.

En cualquier caso existirá una 1ª Fase a finalizar a 30 de abril de 2007, en cual estarán


para poner en producción un mínimo de 2 de servicios en el ámbito de la Hacienda Tributaria.

Tras leerlo mi primera impresión fue confusa: en la planificación y en el alcance, dos aspectos muy delicados.

El título del proyecto sugería un alcance concreto: el desarrollo de toda una plataforma que soportase los contenidos de la administración para la TDT. Sin embargo, el contenido del texto vislumbraba otro alcance añadido: el desarrollo de un conjunto de servicios de la administración para TDT. Se trataba de alcances y trabajos diferentes, una ambigüedad que presagiaba dificultades a futuro.

Por otro lado, había dos planificaciones incoherentes entre si. Una contemplaba 3 fases: una para formar, preparar el equipo y definir la plataforma, a continuación otra en la cual se incorporaban a la plataforma servicios informativos y una última donde se incorporaban servicios interactivos. Un planteamiento lógico y de dificultad gradual. Por el contrario, luego se hablaba de otra planificación en 2 fases: una en la cual se desarrollaban los servicios para Hacienda (interactivos), y una segunda aún por definir. Se empezaba por tanto por la parte más compleja y con el equipo probablemente sin preparar. Sugería que la fecha de la campaña de la renta había comprometido el planteamiento inicial.

En esta situación, las 4 prioridades para la fase 1 parecían ser: identificación de los servicios para TDT de Hacienda, montaje del equipo, plataforma de servicios TDT e identificación servicios para la fase 2. Esto es, una primera fase bastante completa.

ASPECTO A MEJORAR: a futuro debe esclarecerse el objetivo del proyecto, su alcance y las condiciones.

En cualquier caso, aún había muchas cosas por aclarar y concretar. Por esa razón, durante el mes de diciembre se sucedieron una serie de reuniones en los CES, el centro de operaciones de ese momento en adelante, de las cuales pueden extraerse las siguientes informaciones útiles:

Limitaciones de la TDT: Interfaz: se cuenta con un espacio muy reducido, además el aprovechamiento no es

muy eficiente dado que debe ser visible desde el sofá. Así mismo, el tele-espectador no tiene porque ser un usuario habituado a las tecnologías, con lo que la navegación y uso de la aplicación debe ser lo más sencilla posible, guiando al tele-espectador en todos los pasos. A todo esto hay que añadir el bilingüismo propio de la Comunidad Foral de Navarra y la guía de estilos dewww.navarra.es con el fin de que se identifiquen los servicios con la marca del Gobierno de Navarra en la web.

Capacidad: tanto el ancho del banda del llamado carrusel (donde se emiten las aplicaciones) en torno a 2Mbits compartido, como la escasa capacidad de procesamiento y memoria del deco, obligan a tener mucho cuidado en el peso de la aplicación.

Existen varias implementaciones diferentes del estándar MHP en el mercado, pero la preponderantes son dos, Alticast y Osmosys, con lo que el comportamiento de las aplicaciones puede diferir de un deco a otro. Esto obliga a realizar pruebas exhaustivas en una amplia batería de decos comerciales.

La llamada interactividad en la TDT no viene de “serie”, sino que precisa de un canal de retorno a través de Internet por parte del deco bien por módem o bien por ADSL.


Tratamiento de la información: Se acuerda diseñar la aplicación de modo que la lógica esté desacoplada de la

información de modo que esta sean fácilmente modificable en emisión sin afectar a la funcionalidad. Esta información, consumida por la aplicación, se presentará en forma de fichero XML, dada la estandarización de este formato.

Toda esta información se acuerda introducirla en la aplicación para su emisión de forma “manual”, sin llegar a integrarlo en el gestor de contenidos. Esto queda fuera del alcance.

Así mismo, el intercambio de datos entre los servicios sobre TDT y los sistemas de información del portal web se realizarán en base a servicios web. Aquí se quedó fuera del tintero que ocurría si no existían esos servicios web, quién debía desarrollarlos.

Servicios a desarrollar: Con información estática aún por determinar a modo de teletexto. Con información dinámica (modificable en emisión) aún por determinar pero

priorizando los más demandados en www.navarra.es. (Ej: meteorología, farmacias, boletín, carreteras, empleo, etc)

Interactivos: servicios de Hacienda para la campaña de la RENTA. Portal o lanzadera: se precisa de un menú que de acceso a todos estos servicios del

Gobierno de Navarra.

Servicios Hacienda: Los dos servicios que más interés podían tener porque habían funcionado a nivel

nacional se descartaron: la “cita previa” era demasiado compleja y la “petición o aceptación de borrador” no existía en Navarra. Por esa razón todo apuntaba a los siguientes dos servicios:

“Cuanto me sale a pagar o devolver” y “Cuando me devuelven”. Estado del back-end:existen servicios web implementados y reutilizables por lo que tan

solo faltaba recibir sus especificaciones (XML) para verificar su viabilidad e integración con TDT.

Funcionalidad: el usuario se identifica mediante un DNI y un PIN que le proporciona Hacienda.

Plazos: La campaña de la RENTA comenzaba la segunda quincena de Mayo, lo cual daba un poco más margen respecto al hito inicial de Abril.

Organización: Reuniones semanales de la dirección del proyecto: NGA, DGpSI; CES y el asesor

técnico. Existirá una reunión de arranque con el comité entorno a Enero-Febrero y otra

coincidente con la campaña de la RENTA. El resto dependerá del Plan de Acción. Debía definirse un plan de comunicación al comité para informar de los progresos,

dificultades y decisiones pendientes que la dirección no podía tomar. Así mismo, debía detallar los entregables de cada fase, perfiles, tareas, fechas y riesgos.

Las cosas empezaban a tomar forma pero aún había mucho por hacer. Por lo menos entonces teníamos claro lo que debía hacerse para seguir avanzando y concretando puntos.

De entre todas esas tareas, puesto que el desarrollo para Hacienda (RENTA) era de lo más acuciante, tenía una absoluta prioridad. Había que comenzar por aquí, además era lo más tangible y sólido de todo el proyecto.


No obstante, había otra serie de tareas también importantes que se pretendían acometer en paralelo: Determinar el proceso de incorporación de las empresas: perfiles requeridos, selección,

contrato y transferencia de conocimiento. elección de los servicios a implementar durante la segunda fase: reuniones con jefes de

sección. Definición de la metodología y herramientas de trabajo.

Todo esto debería haberse contemplado dentro de un Plan de Acción, aún sin definir, que planificase todas las tareas antes de entrar en acción, para lo cual se hubiera necesitado recopilar algo de información previamente, no obstante, la premura de las cosas no lo permitió, todo iba sobre la marcha. La sensación era que había demasiadas cosas a realizar, mucha urgencia, pocos recursos y bastante indeterminación.

Definición de la metodología y herramientas de trabajoComo cualquier otro proyecto de software había unas herramientas básicas necesarias: un gestor de proyectos, un sistema de control de versiones de código y una metodología. Puesto que aún no contaba con equipo para poner en marcha todo esto, debíamos salir adelante con lo que fuese. Casualmente, contábamos con una instalación de dotproject para la gestión del proyecto y en última estancia con un CVS para el control de versiones de código (posteriormente trabajaríamos con subversion).Esto era lo mínimo imprescindible con lo que empezar. En cuanto a la metodología, se decidió asumir la que el asesor técnico sugiriese en estos casos, lo cual también sería parte de esa transferencia tecnológica.

Así pues parecía estar todo, pero me surgía una duda, ¿necesitamos algo más para desarrollar aplicaciones para TDT? La respuesta no estaba muy clara, así que se indagó y se elaboró un informe que contemplaba las necesidades hardware y software. Este informe se publicó en ediciones anteriores del boletín (TDT: herramientas para desarrollo MHP (Parte 1) y TDT: herramientas para desarrollo MHP (Parte 2)). En resumidas cuentas, había que hacer una fuerte inversión en un laboratorio de pruebas y en unas herramientas de desarrollo específicas para TDT. Las herramientas de desarrollo específicas para TDT aunque facilitaban el diseño y el desarrollo no eran estrictamente necesarias, y dado que se buscaba entre otras cosas una transferencia de conocimiento, se barajó no emplearlas. No obstante, esto habría incidido en el ritmo de trabajo y dadas las circunstancias no era factible.

Esta decisión tomó largo tiempo en tomarse y unas cuantas conversaciones.

Selección de los servicios a implementar durante la segunda fase: reuniones con jefes de secciónEsta tarea requería sin lugar a dudas una intervención por parte de NGA y la DGpSI, por lo que, decidí delegar y depender de ellos en este punto y concentrarme en otras tareas que recaían directamente en los CES.

Determinar el proceso de incorporación de las empresas: perfiles requeridos, selección, contrato y transferencia de conocimientoJunto con el análisis de los servicios de la RENTA, la formación del equipo parecía ser otra tarea muy urgente, debían estar preparados para el desarrollo de la RENTA lo antes posible. Esta responsabilidad recaía en los CES.

Este fue el planteamiento tomado:


Es decir, la búsqueda del becario comenzó en cuanto se supo de esta necesidad en el proyecto. No obstante, la selección de los profesionales exigía definir un perfil más específico, que debía establecerse según los requerimientos del proyecto. Este no pudo establecerse hasta finales del 2007 cuanto ya se tenía claro la experiencia y profesional buscado. En cualquier caso, se trató de un proceso contra-reloj, como se puede observar en la planificación, con el fin de que el equipo estuviera listo a finales de enero y el proyecto pudiera arrancar con la primera reunión del comité, teniendo aproximadamente un margen de un mes para recibir y seleccionar las candidaturas válidas.

Para lo cual, se establecieron unas bases de participación en el proyecto que incluían el perfil establecido y que se distribuyó de diversas formas: prensa, mail electrónico y web. Cabe decir que algunos aspectos dieron lugar a ciertas confusiones, probablemente por no estar suficientemente claras en las bases: fue el caso, por ejemplo, del objetivo de estas bases, se buscaban empresas para participar en el desarrollo de un proyecto ya concedido, no para conceder el desarrollo del proyecto a un tercero, número de candidaturas por empresa, etc. En cualquier caso, tras la recepción de candidaturas se estableció un mecanismo por el cual se contrastaban con el perfil buscado, descartando aquellas que no lo cumplían. Una vez hecha esta criba quedaba decidir entre las que restaban, cuales participaban y cuáles no. Teníamos 3 candidatos válidos técnicamente, decantarnos por uno u otro hubiera sido partidista. Con el fin de ser neutral, se decidió sacarlo a suertes, aunque hubo cierto desacuerdo con este método. Finalmente no hubo necesidad, puesto que una de las candidaturas abandonó el proceso por fuerza mayor. Esto puso de manifiesto las carencias del sistema elegido que habría que pulir y corregir.

ASPECTO A MEJORAR: a futuro, para evitar estas ambigüedades, definir ámbito de las bases, tabular las condiciones y emplear un proceso más objetivo.

Con el comienzo del año 2007, volvimos a reunirnos para seguir atando cabos, retomar los trabajos y preparar la primera reunión del comité de Enero-Febrero. Las cosas no habían cambiado mucho. Todo se centraba en preparar la reunión del comité, que era la presentación del arranque del proyecto, y por tanto, los puntos en que había que trabajar:

Equipo de trabajo. Plan de Acción. Presupuesto inversiones para entorno de desarrollo y pruebas. Estado servicios de la RENTA. Portal (lanzadera).


Propuesta de servicios a implementar.

Por tanto, seguíamos más o menos donde lo habíamos dejado. Las tareas del equipo de trabajo ya estaban lanzadas y se habían detectado así mismo, las necesidades para el entorno de desarrollo y pruebas, tan solo quedaba ponerles “números”. No obstante, los puntos más importantes que aún estaban abiertos y que eran claves: no habíamos avanzado en cuanto a la propuesta de servicios puesto que antes debíamos reunirnos con las personas indicadas en Gobierno de Navarra, tampoco estaba definido el Plan de Acción dentro del cual debían enmarcarse la propuesta de servicios, el análisis de los servicios de la RENTA, y la definición del portal (lanzadera).

Así pues, el mes de enero resultó bastante “movido”, centrándonos en elaborar ese Plan de Acción y en recopilar información para poder llevarlo a acabo: análisis de los servicios de RENTA, definición de la Lanzadera y selección de los siguientes servicios. El caso es que, como se puede observar, dada la premura, la definición empezaba a diluirse con la primera fase de ejecución.

No obstante, estas andaduras se comentarán en el próximo artículo.


Fase 1

Continuo describiendo lo que fue la gestión de esta fase y después comentaré más profundamente los detalles de cada tarea y actuación.

Se empezó elaborando el borrador de un plan de acción para esta primera fase con la planificación de tareas, asignación de recursos y descripción de necesidades (necesidades técnicas, necesidades de información, etc). Este borrador debía abarcar finalmente los siguientes trabajos:

Infraestructura necesaria para el desarrollo del proyecto. Identificación de otros servicios. Incorporación y formación del equipo local. Desarrollo de una lanzadera (tal y como se adelantó en el artículo anterior, esta es una

aplicación que da acceso a los servicios en TDT) Desarrollo de los servicios de Hacienda para la campaña de la Renta. Desarrollo de un posible servicio informativo adicional.

Esto es:



Descripción proceso Lanzadera

Este proceso aparentemente sencillo en primera instancia también tuvo sus dificultades. La lanzadera es una aplicación que permite el acceso a un número determinado de servicios. La primera decisión a tomar fue el tipo de lanzadera a desarrollar:

Opción 1:Lanzadera que presenta la lista de servicios disponibles superpuesta a la emisión de televisión y que ocupa un espacio mínimo. Es decir, se da prioridad a la emisión de televisión frente a la aplicación de la lanzadera. Es una opción menos intrusiva.

Opción 2:Lanzadera que ocupa el tamaño completo de la pantalla de televisión, a modo de portal, relegando a un segundo plano la emisión de ese momento. Se trata de una opción más intrusiva puesto que se puede perder la emisión actual. Esto no se recomienda, por lo que se evita superponiendo dicha emisión en un pequeño cuadro ubicado en algún punto de la pantalla. Esta segunda opción permite un aprovechamiento mayor del espacio, que ya de por si es limitado.

Finalmente, se decidió realizar la segunda opción por ese mejor aprovechamiento del espacio.

Así pues, se empezó a trabajar en una propuesta más concreta de lanzadera. No obstante, el anuncio de la gala del 3 de abril, nos hizo ser conscientes de una cuestión muy importante que habíamos pasado por alto hasta el momento, el resto de entidades propietarias del canal


de datos de la TDT: Canal 4 y Canal 6. Se trata de un canal de datos compartido entre estas dos entidades y el Gobierno de Navarra, con lo que esa aplicación de Lanzadera debería representar a las 3 entidades y dar acceso a todos los posibles servicios.

La solución consistió finalmente en del tipo 2, en la que estuvieran entidades y que diese acceso, para Navarra, a otra lanzadera, también de portal, es decir, la lanzadera instancia. Las siguientes imágenes la solución elegida:

Lanzadera común

Portal Gobierno de Navarra: el cuadrado rectangular marca el área de visionado, fuera de este margen y dependiendo de modelos, no se asegura que se visualice la información.

Cómo se puede apreciar, a esta altura se establecieron algunos elementos que el resto de aplicaciones irían heredando:

Cabecera con el logotipo del Gobierno de Navarra Menú superior: en este caso usado para el acceso a todos los servicios.


Posición y tamaño de la emisión de televisión: zona inferior izquierda. Funciones asociadas a los cuatro botones de colores que suele tener los mandos a

distancia:

Por coherencia, esta asociación de botón y funcionalidad se arrastraría en todas las aplicaciones siguientes. Con la salvedad de que en la Lanzadera común, no se cuenta con todas las posibilidades, dado que algunas no tenían sentido. Esta asociación de botón y funcionalidad fue la siguiente:

Botón rojo: salir de la aplicación y volver a la emisión de TV. Botón verde: cambio de idioma. Botón amarillo: acceso a una página de ayuda. Botón azul: acceso al menú superior de la aplicación. El contenido informativo incluido en la lanzadera y denominado “Así es navarra”,

consistió en información general acerca de la comunidad navarra y sus instituciones.

El aspecto fue este:

Aquí, vuelven a darse otras características de diseño que marcarían las aplicaciones siguientes por desarrollar:

Un área superior para la cabecera y el menú que, a diferencia del portal del Gobierno de Navarra, tan solo permitía reiniciar el servicio actual o bien volver al portal para acceder a otros servicios. Es decir, no se mostraba la lista completa de servicios, esto hubiese


supuesto modificar el menú de todas las aplicaciones en emisión cada vez que se introdujese un nuevo servicio.

Un área donde se despliegan las secciones cada servicio en particular. Otra área donde se visualizan los datos.

Esta será, en mayor o menor medida, la disposición de la información del resto de aplicaciones MHP.

Por simplicidad y dado que tampoco iban a sufrir constantes cambios, todos los contenidos de texto eran estáticos. No en un sentido estricto de la palabra, si no en el sentido de que debían ser modificados a mano en caso de necesitarse. La inclusión de un gestor de contenidos para TDT quedaba fuera del alcance de este proyecto ya que suponía prácticamente el esfuerzo y dedicación de un proyecto completamente nuevo. Como se irá viendo, cada servicio marcaba las necesidades de información, su inserción y mantenimiento de una manera u otra.

A finales de febrero ya se contaba con un diseño de la lanzadera para ser implementado y a finales de marzo el desarrollo estaba completado, a tiempo para el 3 de abril.

La lanzadera su había configurado de modo que estuviese en auto-start, esto es, que tras un cambio al canal de televisión al que va asociado el canal de datos (en este caso, Canal 4 o Canal 6) por parte del tele-espectador esta aplicación se arrancase de forma automática. Dado que se trataba de una lanzadera a pantalla completa, se trataba de una acción muy intrusiva desde el punto de vista del usuario, pero no fue hasta finales de marzo que se planteó realizar un cambio de modo que el usuario tuviese la opción de entrar en la Lanzadera o no. Cambio que no se produjo hasta después de la gala por la falta de recursos y que se tradujo en lo siguiente:

De este modo el usuario no perdía la emisión de televisión de ese momento y tenía la opción si así lo deseaba de acceder a la Lanzadera. En cualquier caso, este desarrollo se realizó con posterioridad a la gala del 3 de abril.

Posteriormente, con más calma se hizo una propuesta de diseño nueva para el portal del Gobierno de Navarra en TDT. Este daba protagonismo a los servicios y el acceso a los mismo, realizando un mejor aprovechamiento del espacio:


Descripción proceso Servicios Hacienda

El desarrollo de los servicios de Hacienda para la campaña de la Renta resultaron más complicados. Se trataban de aplicaciones que hacían uso del canal de retorno para la petición de datos personalizados para cada usuario mediante una identificación.

No fue hasta enero del 2007 prácticamente, cuando se tomó la determinación de realizar dos servicios de Hacienda relacionados con la campaña de la Renta:

Servicio “Cuando”: servicio por el cual se notificaba al contribuyente cuando se produciría la devolución de Hacienda, si ese era el caso, y de cuanto sería el importe. Por descarte, este mismo servicio podía indicar, en función del valor positivo o negativo del importe, si no se producía ninguna devolución, es decir, a pagar por el contribuyente a Hacienda.

Servicio “Enviada”: este otro servicio indicaba si se había enviado el borrador de la declaración por correo postal al contribuyente, y si no se había realizado, las causas.

La decisión por estos dos servicios se basó principalmente en la simplicidad, en la sencillez del interfaz y en la existencia de servicios web que abstrayeran la petición de la implementación del sistema de back-office.

No obstante, no fue prácticamente hasta febrero que no se pudo empezar con el análisis de dichos servicios dado que no se contaba aún con la consultora experta en TDT. Fue, por tanto, a lo largo de febrero cuando fuimos, a través de reuniones con Hacienda y Azertia, adjudicataria de los desarrollo de la campaña de la RENTA, realizando la captura de requisitos y el análisis técnico de la solución.

Tras redactar el documento de requisitos, se identificó el siguiente escenario (no detallaré los casos de uso porque este artículo sería interminable):


Diagrama de casos de uso servicio “Cuando”

Diagrama de casos de uso servicio “Enviada”

A partir de este momento se debían identificar las comunicaciones entre la aplicación MHP en TDT y los servicios web en el back-office del Gobierno de Navarra. En dicha comunicación debían establecerse protocolos (SOAP = Simple Object Access Protocol, protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML), parámetros y formato de la información (DNI, fechas, cadenas de texto, etc). Era obvio que muchos de estos aspectos venían determinados por los propios servicios web ya existentes. Para este análisis se contaba con las especificaciones WSDL (Web Services Description Language, un formato XML que se utiliza para describir servicios Web) de dichos servicios web.

Cómo se puede observar en los diagramas, los procesos determinaban varias peticiones por separado: Una primera identificación del usuario a través del DNI y un número PIN que proporcionaba

Hacienda a través de correo postal. Una segunda petición para la obtención de la información requerida. En algunos casos una tercera petición para información adicional dependiente de la

respuesta anterior.

Esto en TDT, dado que el canal de retorno habitual de comunicaciones es el módem


ralentizaba mucho las peticiones con lo que en siguientes conversaciones con Azertia, se propuso la posibilidad de crear otros dos servicios web específicos para TDT que actuasen a modo de fachada y permitiesen agrupar en una sola petición la identificación de usuario y la petición de información. Se trataba de un desarrollo pequeño puesto que delegaban en la lógica de los ya existentes, con lo que fue aceptado y el trabajó asumido por Azertia.

En esta situación, por tanto, se tenía lo siguiente: Servicio “Cuando”: en la primera solicitud el contribuyente (usuario) se identifica y realiza

la petición de datos al servicio web. La respuesta consistía en un código y en la información caso de existir. Con el fin de evitar una segunda solicitud que tradujese dicho código (en caso de no información a mostrar), se insertó la información de los códigos en la propia aplicación MHP de modo que supiese identificar el código dado por el servicio web.

Servicio “Enviada”: en este caso la primera solicitud también identificaba al contribuyente y realizaba la petición de datos. De no obtenerse una respuesta positiva, es decir, de no haberse enviado al hogar la propuesta de la declaración por parte de Hacienda, existe una segunda solicitud que pide los motivos de ese “no” envío. De igual forma, para evitar esta segunda solicitud, en la primera petición, se mandaban los códigos de los motivos en caso de no haberse enviado la declaración y se insertaban, de igual forma, la información de los códigos en la aplicación MHP.

Tras los desarrollos faltaba una parte muy importante, las pruebas. Aquí había que conjugar una serie de aspectos. Por un lado, el proceso que marcaba Hacienda y el departamento de sistemas en la puesta en producción de los desarrollos.

Por otro lado, la coordinación con Azertia dado que en paralelo ellos debían realizar las adaptaciones de los servicios web a probar y por último la existencia de datos con los que realizar las pruebas.

El proceso marcado por el departamento de sistemas establecía 3 niveles: Desarrollo Pre-producción Producción

La aplicación debía probarse en cada uno de estos niveles y no pasaba al siguiente hasta que en el anterior las pruebas no hubiesen sido satisfactorias. Cada nivel requerían de condiciones de acceso diferentes. Para el caso de los dos primeros se precisaba de canal directo, en este caso, desde CEIN a la red corporativa del Gobierno de Navarra. Casualmente CEIN ya contaba con un acceso a dichos sistemas, tan solo hubo que configurar los permisos y el encaminamiento, no sin alguna que otra dificultad. Para las pruebas en producción, aparentemente, no había mayor dificultad puesto que se podían realizar a través de Internet por medio de la conexión módem del decodificador, no obstante, había que contar con el hecho de que la comunicación en este caso estaría cifrada por un certificado de servidor, escenario que no se podría probar hasta llegar al paso de producción.

Por otro lado, el desarrollo de la adaptación de los servicios web se iba a realizar con posterioridad al resto de desarrollos que la campaña de la Renta precisaba ese año, lo cual prácticamente no dejaba margen para las pruebas. Por esa razón, se empezó a trabajar contra los servicios web existentes sabiendo que posteriormente habría que realizar los cambios y adaptaciones necesarios para los nuevos servicios web.


Por último, tampoco se contaba con un número suficiente de datos de prueba que que abarcase todos los escenarios posibles.

Todo esto se tradujo en un proceso de pruebas bastante traumático.

A finales de abril los desarrollos estaban terminados, las pruebas habían sido satisfactorias y se pudo iniciar la comunicación con al radiodifusor Abertis para poner en producción estos servicios dentro del plazo acordado, a finales de abril.

A continuación se muestran algunas capturas de pantalla del resultado:

Identificación


Servicio “Enviada”

Servicio “Enviada”


Servicio “Cuando”




Conclusiones

En esta primera fase se juntaron el arranque y configuración del proyecto con la ejecución y desarrollo del mismo. Por otro lado, las circunstancias obligaron a empezar por los servicios más complejos, los de Hacienda. Todas estas circunstancias unidas a la fuerte presión en fechas, dieron como resultado una fase bastante caótica. No obstante, afortunadamente todo salió de forma satisfactoria.

La presión en fechas impidió que el equipo local pudiese participar de forma activa en los primeros desarrollos, lo cual hubiese sido muy beneficioso para ellos. En cualquier caso, aún quedaba mucho camino por recorrer para el proyecto y múltiples oportunidades para el equipo.

Esta fase en definitiva, se caracterizó por el amplio número de decisiones que se tuvieron que tomar sobre la marcha con muy poco margen de tiempo, decisiones que en muchos casos marcarían el resto del proyecto.

El siguiente artículo comenzará con la segunda reunión de comité donde se concluían los trabajos desarrollados en la primera fase y se proponía el planteamiento de la siguiente.


Fase 2

Esta segunda fase arrancó con el segundo comité. Comité en el cual se presentaban los trabajos realizados hasta ese momento, es decir, la primera fase completada, ya comentada en artículos anteriores, y el planteamiento del proyecto desde ese momento hasta el final del proyecto.

Este planteamiento consistía en establecer los trabajos a realizar por parte del equipo local, número y planificación, junto con la transferencia de conocimiento y papel que SiTVi debía ejercer durante esta segunda fase. Para ello se partía del resultado del análisis de servicios a adaptar a TDT realizados durante la primera fase, que trajeron no pocos quebraderos de cabeza y de la finalización de la preparación formal del equipo local.

Del análisis teníamos como resultado una lista de posibles servicios a implementar en TDT, no obstante, no había identificados unas fuentes fiables de información en ninguno de ellos y tampoco había asegurada la incorporación de ningún servicio interactivo (con capacidad de realizar peticiones mediante el uso del canal de retorno) dada la imposibilidad de contar con una interacción con los sistemas de Gobierno de Navarra (a través de servicios web) en la fecha presente. Dado que había muchos flecos en prácticamente todos los servicios que se irían aclarando con el estudio concreto de cada uno y dada la existencia de un plan de modernización paralelo que iba afectar a los sistemas de la información y por tanto, cambiar la situación actual, la lista, prioridad y posición de cada servicio dentro de la misma podía variar. De hecho, debía irse adaptando conforme se obtuviese más información de los mismos a lo largo de los desarrollos de la segunda fase. En resumen, había una gran indeterminación.

Servicio Prioridad FuenteMeteorología Alta Extracción automatizada de la información

directamente de la fuenteInformación estática Alta Inserción manualAgenda de ocio y cultura Alta Extracción directa de BBDDFarmacias de guardia Alta Extracción directa de BBDDCentros de salud Alta Extracción directa de BBDDCarreteras Alta Tempos 21: analizar alternativasEmpleo público (convocatorias) Alta Tempos 21: previo filtrado de la informaciónVivienda Alta-Media A determinarBON Media Dentro del plan de modernización: a

determinar en octubreEmpleo privado Media Dentro del plan de modernización: a

determinar en otoño

Esto es, se habían identificado 10 posibles servicios, de los cuales, los 7 primeros eran informativos mientras que los 3 últimos podían presentar algo de interactividad.

No obstante, existía una gran indeterminación en el posible uso de estos 3 últimos puesto que en el momento del análisis, tal y como he comentado, no existía ningún servicio web disponible para implementar la interactividad en el servicio, circunstancia que podía cambiar por el plan de modernización que afectaba directamente a dos de estos servicios.


Entre los informativos, tras muchas averiguaciones se vio la dificultad y riesgo de emplear el desarrollo de Tempos21 como fuente de información ya procesada con lo que se planteó buscar la fuente de datos original. Para los dos primeros ya se tenía detectada una alternativa útil y por tanto podían implementarse en TDT, mientras que en los restantes se sabía de la existencia de bases de datos que almacenaban cierta información necesaria para cada uno de los servicios pero se desconocía con certeza su naturaleza y por tanto, no se podía asegurar en todos los casos su uso. De echo, para los servicios de Carreteras y Empelo público, ni siquiera se tenía constancia de la existencia de una base de datos, lo cual implicaría el uso de Tempos21 como fuente de información ante la inexistencia de una alternativa.

Por otro lado, el equipo local se encontraba “preparado”, había recibido la formación adecuada relacionada con conceptos generales de la TDT, el estándar MHP y el uso de la herramienta de autor a emplear iDesginer. No obstante, como hemos adelantado, la formación no terminaba ahí, esta tan solo había sido la parte teórica. A continuación comenzaría la formación práctica basada en la experimentación real con los trabajos a realizar, para lo cual se definió junto con SiTVi un planteamiento de transferencia de conocimiento: se identificaron una lista de habilidades a adquirir y unos niveles para cada una de ellas, A, B y C, siendo A el nivel más básico y C el más avanzado. Estas habilidades o conocimiento se agruparon según su aplicación a las tareas de desarrollo, quedando el siguiente planteamiento:

NivelesA B C

Toma de requisitosIngeniería de software – Metodología de desarrollo: toma de requisitos, análisis, diseño aplicación.Análisis funcionalIngeniería de software – Metodología de desarrollo: toma de requisitos, análisis, diseño aplicación.DiseñoDesarrollo MHP – Diseño y usabilidadIntegración y formateo de datos de entradaBackend – Proceso de datosBackend – Tratamiento de XML, XSLTConocimiento del entorno – Desarrollo con el entorno de IDesginerJava – Desarrollo basado en Java (bajo nivel, sin uso de iDesginer)Implementación del interfazDesarrollo MHP – Interfaz gráfico (disposición/layout de componentes)Java – Desarrollo de plugins (personalización y creación de componentes gráficos para IDesginer)Java – Desarrollo basado en Java (bajo nivel, sin uso de IDesigner)Conocimiento de entorno – Desarrollo con el entorno de IDesignerImplementación de funcionalidadesDesarrollo MHP – Uso de formularios de entrada (procesado de datos).Java – Desarrollo de plugins (personalización y creación de componentes gráficos para IDesigner).Java – Desarrollo basado en Java (bajo nivel, sin uso de IDesigner).Conocimiento del entorno - Desarrollo con el entorno de IDesignerIntegración con servicios webDesarrollo MHP - Canal de retorno.


Backend - Interacción con servicios web: post/xml, get/xml, soap.Java – Desarrollo basado en Java (bajo nivel, sin uso de IDesigner).Conocimiento del entorno - Desarrollo con el entorno de IDesignerEjecución de pruebasConocimiento del entorno - Conocimiento de puesta en producción de aplicaciones en el laboratorio: encapsulador (iMux).Conocimiento del entorno - Realización de pruebas X de aplicaciones.Backend - Parametrización de aplicaciones.Ingeniería de software - Metodología de pruebas.Puesta en emisión:Backend - Parametrización de aplicaciones.Puesta en producción de aplicaciones: comunicación con Abertis.

Dada la nula experiencia en TDT del equipo local se decidió comenzar con un servicio sencillo de implementar en el que participasen todos los miembros del equipo. Además, esto permitía arrancar la segunda fase del proyecto con un servicio concreto y definido y así tener un colchón suficiente para ir concretando el resto. Posteriormente, tras la experiencia adquirida, se podían ir acometiendo más servicios en paralelo mediante la distribución del trabajo entre los miembros del equipo local. Se trabajaría con la lista identificada anterior como si fuera un “pool” de servicios, decidiendo su incorporación al desarrollo según la información recopilada en cada caso, la viabilidad y evolución de las circunstancias:


MHP = Desarrollo MHP

RAD = Requisitos, análisis y diseño

IDE = Integración datos de entrada

IWS = Integración web services

PIC = Pruebas, integración y cambios

Prod = Producción

Por tanto, este plan nos daba 5 servicios a incorporar de aquí al final del proyecto, 4 informativos y un último interactivo aún por determinar dependiendo del plan de modernización. Se decidió comenzar por un servicio de modo que todo el equipo pudiera participar e ir adaptándose al desarrollo de aplicaciones interactivas con MHP para TDT de forma paulatina. De este modo, en este primer servicio se podía hacer más hincapié en la labor de transferencia de conocimiento que posteriormente se iría diluyendo a lo largo del proyecto conforme el equipo adquiriese soltura y conocimientos y convirtiéndose más bien en una labor de consultoría. Así pues, en los servicios posteriores, tras esta toma de contacto y adaptación, podía configurarse un equipo más eficiente de modo que se dividiesen los trabajos y se pudiesen implementar y afrontar dos servicios en paralelo cada vez. Dada la disponibilidad de 4 personas (se contaba con 3 personas en el equipo local y un becario cedido por SiTVi como refuerzo y apoyo), se podía dividir el equipo en 2 grupos de 2 personas cada uno. De modo que en los servicios informativos, una persona del grupo pudiese dedicarse a las labores de extracción y formateo de datos y la otra persona del grupo concentrarse en el desarrollo MHP. En el caso del servicio interactivo, no existía extracción y formateo de datos, pero la interacción complicaba el desarrollo MHP que podía equilibrarse con la dedicación de dos personas en este caso. Los roles y responsabilidades de cada participante así como los propios grupos irían cambiando y rotando con cada desarrollo de modo que todos los miembros del equipo local experimentasen con todas las partes del desarrollo. La lista de conocimientos y niveles antes citada encajaba dentro de este planteamiento de la siguiente manera:

Esto es, los conocimientos de nivel A, se adquirirán con el desarrollo del primer servicio. Durante el desarrollo del siguiente servicio, se asimilarán los conocimientos de nivel B, consolidando, a su vez, los de nivel A adquiridos en el desarrollo anterior. De igual modo, durante el último servicio, se aprenderán los conocimientos de nivel C, consolidando los de nivel B adquiridos en anteriores desarrollos y asumiendo la completa responsabilidad de las tareas de nivel A.

Así pues, como se ha adelantado, se determinó comenzar con un servicio, buscando el más sencillo y a la vez el que más garantías de éxito pudiese ofrecer de la lista de servicios


posibles. De entre todos ellos, serios candidatos eran: Meteorología, Farmacias de Guardia, Centros de Salud, Información Estática y Agenda de cultura y ocio. Dado que de todos ellos, tan solo Meteorología teníamos realmente identificada la fuente de información se decidió comenzar con el.

Meteorología

Para profundizar en el análisis de la fuente de información y el servicio, se organizó una reunión con el área de Meteorología del Departamento de Agricultura, Ganadería y Alimentación del Gobierno de Navarra, responsables del desarrollo de meteorología para el portal web www.navarra.es.

Aunque se propuso un servicio muy interesante por el cual se proporcionaba información en tiempo real de estaciones meteorológicas, este hubiese requerido un análisis más profundo y tratándose de un desarrollo más complejo hubiese retrasado el desarrollo, por lo que fue descartado y se continuó con los planes iniciales. Así pues, se determinó que el servicio a implantar en TDT sería el de la predicción meteorológica. En concreto, las siguientes predicciones:

Predicción meteorológica en Navarra para hoy. Predicción meteorológica en Navarra para mañana. Predicción meteorológica en Navarra para los próximos días. Predicción meteorológica en el pirineo. Predicción nivológica, sólo disponible en temporada de nieve. Predicción avisos y alertas cuando los hubiere. Imagen de radar.

Esta información, ofrecida en el portal web, se extraía del Instituto Nacional de Meteorología (en adelante INM), ahora la actual Agencia Estatal de Meteorología (AEMET). El formato de datos proporcionado por el INM venía heredado de mucho tiempo atrás, cuando no se empleaban los caracteres particulares del español como los acentos, las eñes, etc. Esto unido al uso exclusivo de mayúsculas y a la inexistencia de traducciones a diferentes idiomas (entre ellos el euskera) dificultaba las cosas. La aplicación a diseñar sería multilingüe, como en todos los casos, aunque la disponibilidad de la información estaría sujeta a su existencia. En este caso, la información tan solo podía ser servida en español.

NOTA: posteriormente, a finales del 2007, los responsables del portal realizaron un filtrado de la información de modo que esta se visualizaba en minúsculas y realizaban correcciones ortográficas para incluir los acentos y las eñes. No obstante, esta información contenía tags html, con lo que requería un procesado previo antes de poder ser incluida en TDT. Esta novedad no pudo ser incorporada finalmente al proyecto por falta de tiempo y recursos.

Toda esta información era facilitada en forma de ficheros individuales por cada una de las predicciones anteriores. Estos ficheros estaban localizados en un servidor de FTP al que nos dieron acceso para la conexión y descarga de la información.

La visualización de esta información, interfaz, presentó algunos problemas en TDT. En el portal www.navarra.es, la información de predicción correspondiente al día actual, el día siguiente y los próximos días, eran visualizadas de forma conjunta. Esta información consistía en un texto y en la imagen de un mapa de navarra actualizados diariamente pero de forma


http://www.navarra.es/

independiente. La imagen del mapa se correspondía con la predicción para el día siguiente, no obstante, esta información se actualizaba en torno al medio día, con lo que en las primeras horas del día el mapa se correspondía con la predicción del día anterior, o visto de otra forma, la previsión del día actual realizada el día anterior.

El interfaz en TDT impedía mostrar las 3 predicciones anteriores de forma conjunta por problemas de espacio. Por esa razón se implementaron de forma separada, lo cual, planteaba el problema de donde ubicar el mapa de predicción común. Finalmente se decidió que la predicción del día siguiente contendría el texto y la imagen del mapa correspondiente, actualizado a medio día, momento en el cual, la imagen del mapa anterior pasaría a la predicción del día actual. Probablemente esta circunstancia podrí haberse resuelto de forma más óptima de poder haber tenido más libertad sobre la disposición de componentes en el interfaz, no obstante, la herencia de los servicios en TDT anteriores marcaba una línea gráfica de la cual no era posible salir.

Otro escollo asociado al interfaz en TDT resultaron ser las propias imágenes por el origen de las mismas. Se trataba de imágenes con tamaño y formato adaptado al entorno web, además de tratarse de imágenes de calidad reducida, óptima para entorno web. Estas debieron ser escaladas para adaptare al interfaz de TDT, acentuando la mala calidad. Esto unido a la diferente visualización de los colores en TDT dieron como resultado unas imágenes bastante pobres, no obstante, no se contaba con otra fuente de datos alternativa.

A continuación se muestran unos bocetos del interfaz que indican la ubicación de cada elemento gráfico:


Es decir, y como se ha mencionado, por coherencia se mantuvo el diseño gráfico establecido en las aplicaciones anteriores:

Menú superior de acceso a otros servicios en TDT. Menú inferior con los controles directos del mando de televisión. Menú propio del servicio actual situado a la izquierda. La emisión del vídeo en la esquina inferior izquierda. El espacio útil de visualización situado en el centro.

En este caso, el menú izquierdo se correspondía con cada una de las predicciones a visualizar de forma independiente a modo de secciones.

El área útil mostraba la información de predicción correspondiente a la sección elegida. Para el caso de la predicción de hoy y mañana, se desarrolló un componente que conmutaba entre la predicción de texto y la predicción con la imagen, dado que las limitaciones del interfaz en TDT impedían su visualización simultánea.

De igual modo, se mantuvo (como se verán en las imágenes de resultado final) el estilo heredado de las aplicaciones anteriores en cuanto a uso de colores, diseño de botones, etc.

En cuanto al proceso que recogía, procesaba y publicaba la información en TDT, el sistema presentaba la siguiente arquitectura:


Esto es:

1. Proceso de adquisición de datos: se trataba de un sistema independiente que monitorizaba los ficheros determinados ubicados en el servidor FTP. En caso de que hubiese cambios, los descargaba y procesaba para construir los ficheros XML que servirían como fuente de información a la aplicación MHP a ejecutar en el televisor. Este proceso dejaba los ficheros XML generados en unas ubicaciones de carpetas preestablecidas en un servidor local.

2. Proceso de publicación: se trataba de un sistema que conjugaba los ficheros obtenidos y formateados en el proceso anterior y los mezclaba con los fuentes de la aplicación para generar el empaquetado compilado final. No obstante, no se enviaba a publicación el empaquetado completo, puesto que sería requisito indispensable que la aplicación ya se encontrase disponible en el aire, por lo cual, tan solo se actualizaría la parte correspondiente a la información, manteniendo la aplicación intacta. Tal y como se explicó en el artículo anterior, esto se hace así, puesto que cada actualización de la lógica conlleva un proceso de validación previo por parte de Abertis que sería inmanejable en el día a día de una aplicación informativa de contenidos actualizables diariamente como es el caso. La actualización se realiza de nuevo mediante un acceso por FTP a la información publicada en TDT proporcionada por Abertis.

Aquí surgió por primera vez, el concepto de la plataforma de TDT. Como era de esperar, esta consistía en una extracción de información del back office y su procesado para emisión en TDT. Debía establecerse un mecanismo que fuese común y reutilizable en todos los servicios que independizasen información y presentación. Lógico, pero muy difícil. Cada servicio requería procesos de extracción diferentes, como posteriormente se vería, según la fuente de datos y la propia información a extraer en cada caso. No obstante la filosofía en todos los casos fue la misma, definiendo un formato de fichero XML particular para cada aplicación que independizaba al menos la información de la aplicación MHP, la lógica. El proceso, no obstante, que si podía ser común o al menos reutilizado era el de publicación. Una vez procesada la fuente de información y generado el XML base, los pasos a partir de ahí eran los mismos en todos los casos, compilar, empaquetar y enviar la información a Abertis para su actualización en emisión.

En torno a esta cuestión, empezaron a tenerse las primeras reuniones con sistemas de Gobierno de Navarra para definir esta plataforma de extracción de datos y publicación en TDT, tanto a nivel hardware como software. Para esto se redactaron una serie de documentos solicitados por sistemas en los cuales se trataba de definir la plataforma, pero de forma bastante abstracta puesto que no se conocían las implicaciones ni requerimientos del resto de servicios por desarrollar. De nuevo, todo se debía ir definiendo sobre la marcha. En cualquier caso, sistemas estableció una serie de condicionantes que aplicaban tanto a nivel hardware como software que daban una idea de por donde debían ir las cosas. Se comenzó definiendo que estos procesos podían ser aplicaciones Java que corriesen como demonios, sin necesidad de ningún framework o requisito adicional que el propio proceso, lo cual limitaba mucho las posibilidades. No obstante, como se verá más adelante, estos requerimientos y condicionantes irían cambiando a lo largo del proyecto.

La dificultad para ir definiendo todo esto, hizo que la plataforma estuviese alojada de forma temporal en la infraestructura proporcionada por los CES, hasta el momento en que fuera viable su traspaso a sistemas de Gobierno, una vez definida por completo la plataforma y disponible una infraestructura donde alojarla. No fue, como se verá posteriormente, hasta el final del proyecto que pudo hacerse esta migración.


Todos estos trabajos se planificaron de la siguiente manera:

Puede verse que para este servicio había un gran esfuerzo en lo que era la parte de adquisición y formateo de los datos para construir los ficheros XML base que alimentarían la aplicación MHP. También existía una gran dependencia entre la aplicación cliente MHP y el proceso de adquisición de datos debido al fichero XML que relacionaba ambas aplicaciones. El diseño del interfaz marcaba la organización de la información en el XML, el cual, a su vez, incidía directamente en el proceso de adquisición de datos y obtención del XML. El publicador, por el contrario, era un proceso que podía ser desarrollado de forma independiente.

Finalmente, el equipo local estaba constituido por 3 personas (ante la baja del miembro proporcionado por SiTVi, lo cual complicaría la planificación acordad inicialmente) para tres desarrollos: proceso de adquisición de datos, proceso de publicación y aplicación MHP. Las responsabilidades de cada miembro, tal y como se ha dicho, iría rotando en cada servicio para que todos los participasen en los diferentes desarrollos y comprendiesen de esta forma


el sistema global.

Las pruebas del sistema completo, adquisición y publicación, eran cruciales. Se realizaron una serie de pruebas del sistema completo en un entorno de pre-producción habilitado en el laboratorio del CES para asegurar el correcto flujo y procesado de la información, así como una prueba del sistema completo en producción, pactado con Abertis.

Previo a la emisión, se realizó una demostración de la aplicación al área de Meteorología del Departamento de Agricultura, Ganadería y Alimentación del Gobierno de Navarra para que solicitasen cambios y diesen su aprobación final.

En dicha demostración, se detectó que se precisaba de la autorización del INM para el empleo de sus datos en TDT, algo que, no obstante, no supuso ningún impedimento ni inconveniente pudiéndose resolver de forma satisfactoria a tiempo.

En cualquier caso, un retraso aproximadamente de una semana en las pruebas y la coincidencia de las fiestas de San Fermin con la emisión, pospusieron los planes, ante posibles eventualidades, hasta finales de julio. Un retraso pequeño pero que unido a la baja de un miembro del equipo, iría pesando a lo largo de los siguientes desarrollos.

A continuación se muestran algunas imágenes de lo que fue e aspecto final de la aplicación:



Selección siguientes servicios

Durante el desarrollo del servicio de meteorología, se recabó la información correspondiente al siguiente bloque de servicios a desarrollar. Para ello, se partía de la lista de servicios candidatos.

De entre ellos, los siguientes eran: Información estática: servicio informativo del Gobierno de Navarra cuya fuente de

información estaba por determinar. Agenda de ocio y cultura: servicio informativo, aunque daba cabida a un posible servicio

interactivo, cuya fuente de información también estaba por determinar. Farmacias de guardia: servicio informativo cuya fuente de información era el desarrollo de

Tempos21 a la espera de encontrar una alternativa. Centros de salud: servicio informativo cuya fuente de información era el desarrollo de

Tempos21 a la espera de encontrar una alternativa.

Para determinar cuáles de estos servicios se iban a realizar a continuación se organizaron una serie de reuniones con los responsables de cada servicio para detectar su viabilidad y la fuente de información a emplear.

Para el caso del servicio de información estática, la cosa estaba clara y era aparentemente sencilla. Se trataba de publicar información de interés para el Gobierno de Navarra en TDT, como si fuese una página web. Dado que, desde un principio, se estableció que interconectar el gestor de contenidos existente en el Gobierno de Navarra con la publicación de información en TDT quedaba fuera del alcance del presente proyecto dado que tenía suficiente complejidad como para embarcarse en un proyecto nuevo con entidad propia, esta información a publicar en TDT sería introducida de forma “manual” e independiente del gestor de contenidos. En este escenario, teníamos total libertad y control para elegir que, como y donde se almacenaba la información.

Así pues, derivado del análisis previo de servicios del portal web y móvil del Gobierno de Navarra, se buscó que información existía publicada que podía emplearse en este uso. Se partió de lo que denominaban catálogo de servicios, compuesto por una serie de “fichas”. Se trataba de información descriptiva acerca de todos los servicios que el Gobierno de Navarra presta al ciudadano a través de cualquier medio. No obstante, las diferencias de interfaz y limitaciones de TDT no permitían su reutilización directa. El contenido descriptivo de estos servicios debía filtrarse y resumirse manualmente para adecuarse a la TDT reafirmando la dificultad de interconectarlo con el gestor de contenidos.

En cuanto a la agenda de ocio y cultura, tras la reunión con el técnico responsable se observó que existía una base de datos como fuente de información. Curiosamente, esta se almacenaba en formato HTML, descartado como fuente útil, y XML, que si se podía emplear como base para la aplicación interactiva a desarrollar. Incluso, según cual fuese el formato de este XML podía emplearse directamente sin falta de un procesado previo, lo cual simplificaba las cosas. No obstante, la cantidad ingente de eventos programados y almacenados en la base de datos hacía inviable su traslado a la TDT tal cual. Se vio la necesidad de realizar algún tipo de filtro, seleccionando los más recientes (en el plazo de una semana) y determinando un máximo de eventos por categoría, dado que aún así la lista podía ser muy grande, en base a una selección de eventos destacados. Estos criterios de filtrado y destacado requerían consenso con el departamento correspondiente. Finalmente, estas


decisiones no pudieron tomarse a tiempo con lo que tuvo que descartarse el servicio en favor de los siguientes.

Así pues, se tantearon los dos siguientes conjuntamente por su similitud, Farmacias de Guardia y Fichas descriptivas de los servicios de Gobierno de Navarra.

Farmacias de Guardia y Fichas

En este bloque de servicios, siguiendo la línea de transferencia de conocimiento y los objetivos marcados a este respecto, debía plantearse un nuevo desafío para los desarrolladores. Durante meteorología, el desafío fue enfrentarse por primera vez al desarrollo de aplicaciones interactivas, en estos dos servicios se daría un paso más, aprendiendo a desarrollar componentes gráficos reutilizables. Componentes que debían definirse y detectarse en servicio.

Configuración equipo

La siguiente parte consistía en organizar el equipo para llevar a cabo estos dos servicios de forma paralela. Contábamos con cuatro técnicos, así que la división, en principio, era sencilla. No obstante, el becario proporcionado SiTVi cayó de baja hasta prácticamente finales de proyecto, lo cual hizo que debiéramos reconfigurar el planteamiento para minimizar el impacto en los compromisos de plazos y trabajos establecidos, los cuales estaban dimensionados para un equipo de 4 personas. Las circunstancias hicieron que se pudiese distribuir el trabajo sin demasiados problemas para estos dos servicios, tal y como se describe en cada uno de ellos, aunque supuso una carga de trabajo mayor al final del proyecto.

Planificación



Centros de Salud y servicio interactivo EDUCA

Entramos en la última fase de los desarrollos, caracterizada por la acumulación de compromisos y un retraso global de en torno a 2 semanas, complicado panorama.

Recopilando tenemos:

Servicio informativo: centros de saludEra nuestra mejor opción de entre todos los posibles servicios candidatos que aún nos quedaban. Por tener una con problemática similar al de Farmacias de Guardia permitiría reutilizar trabajos y análisis, siendo más ágil en su desarrollo de este modo.

Servicio interactivo: ¿?Aquí había más dificultades puesto que, simplemente, no existían. Todo apuntaba a que el plan de modernización iba a permitir contar con servicios web que pudieran aportar interactividad a los servicios, pero los plazos y detalles de este plan no estaban precisados, pudiéndonos dejar en una situación precaria. Por esa razón, se tanteó la posibilidad de realizar algo en colaboración con el proyecto EDUCA, a pesar de salirse de la línea marcada en www.navarra.es. Tras contrastarlo, primero, con el equipo técnico del proyecto EDUCA se llegó a la conclusión que era factible y se propuso, entre las muchas posibilidades, realizar la consulta de las Faltas de Asistencia del alumnado a través de TDT. Tras esta valoración positiva inicial, se procedió a la aprobación por parte del comité del proyecto y de la parte correspondiente en Educación.

A esto había que añadir el desarrollo pendiente de la aplicación de mantenimiento de las fichas y la implantación de la plataforma.

Así mismo, siguiendo el plan de transferencia tecnológica marcado, estos servicios debían desarrollarse sin la ayuda de la herramienta de autor iDesigner empleada hasta ahora. Debido a la complejidad de uno de los desarrollos (interactivo), la falta de tiempo y escasez de recursos, lamentablemente, tuvo que optarse por ser conservador. La prioridad era tener los desarrollos completos en el tiempo previsto, 31 de diciembre del 2007, cuando la encomienda moría, y con ella el proyecto. Así pues, se continuó usando la herramienta de autor, pero incluyendo una labor formativa adicional en desarrollo MHP con Eclipse.

La transferencia tecnológica se centró en la parte interactiva de uno de los servicios más todos los componentes a desarrollar adicionales, que en este caso fueron numerosos.

La planificación final fue la siguiente:


http://www.navarra.es/



Reflexión

Llegamos a la última etapa, una reflexión de lo que fue mi experiencia personal y una vista al futuro.

Experiencia (organización)

Quizás, una de las características a destacar dentro de este proyecto fue la organización de los grupos de trabajo: el comité al cual se le informaba acerca de los avances, dificultades y decisiones a plantear, y el grupo de seguimiento, dentro del cual estaba yo, que dirigía el proyecto. Esto favoreció un férreo control del proyecto asegurando que los compromisos se pudiesen cumplir.

La metodología empleada fue heredada de la forma de trabajo de SiTVi basada en RUP. Esta metodología, como caracteriza a RUP, en principio exigía un esfuerzo muy grande para acotar todo el proyecto al comienzo y auguraba un proceso posterior muy estricto. Por esa razón, es una forma de trabajar que ante imprevistos responde muy mal, pudiendo echar por tierra todo el trabajo de definición, convirtiéndose más en un estorbo que en una ayuda. Por el contrario si todo va según el plan, es una herramienta muy válida para controlar el proyecto. Fue toda una fortuna que todo saliese según lo previsto más o menos, puede que gracias a ese control.

Puede que una metodología ágil hubiese funcionado bien, dado que manejábamos constantemente una gran incertidumbre en todos los trabajos ante la falta de información, lo cual implicaba que no podían darse ciertos pasos hasta contar con esta información.

En este caso, puesto que el proyecto se configuró en base a módulos a desarrollar de forma separada, lo cual fue todo un acierto, rompía un poco con la metodología RUP. Esta nos hubiese exigido un plan de inicio al final completo y detallado, algo imposible por la dificultad de definir muchas cosas ante la falta de datos. Eso hizo que se pudiese plantear una metodología RUP acotada a cada módulo. Es decir, se estableció un planteamiento global a grandes rasgos y al inicio de cada módulo se detallaba el plan del mismo. Cada módulo tenía una duración aproximada de 2 meses, lo cual dificultaba que hubiese desviaciones demasiado grandes y permitía encajar la metodología RUP con facilidad. No obstante, exigió un constante trabajo de definición y control con cada módulo, manteniendo, por así decirlo, una tensión constante a lo largo del proyecto.

La incertidumbre fue un escollo que nos atosigó a lo largo de todo el proyecto. Resultó muy difícil contar en todos los casos con la información necesaria para las tomas de decisiones, e incluso, en los propios desarrollos de cada módulo. Afortunadamente, la labor de NGA en este punto fue inestimable gracias a su conocimiento interno de la organización del Gobierno de Navarra que permitió llegar a las personas adecuadas en cada caso.

Desde mi propia experiencia, fue un año de mucho estrés, pasaba de trabajar como programador y hacer pequeños pinitos como analista a la jefatura de un proyecto de golpe. Sobre todo en los comienzos, cuando mi inexperiencia resultaba palpable y tenía muchos ojos apuntándome. Por esa razón, el inicio fue muy duro y existió una gran presión para llevar


adelante las cosas, que por otro lado, me ayudó a espabilar más rápidamente, hasta que al final del proyecto, me sentía bastante cómodo.

Algo que mi salud hubiese agradecido haber hecho de otra forma fue asumir los trabajos de jefe de proyecto y analista al mismo tiempo por no asignar tal figura dentro del equipo. Los candidatos más firmes a sumir este perfil hubiesen sido los dos técnicos provenientes de empresas, lógicamente, por su contrastada experiencia. Decantarme a favor de uno de ellos me pareció inapropiado por haberse entendido de forma errónea y confundirse con alguna clase de favoritismo, algo que preferí evitar por precaución.

Experiencia (técnica)

Desde el punto de vista técnico, hubo cosas que estoy seguro se pudieron hacer mejor, pero también peor.

Una decisión que aún hoy me plantea dudas razonables fue el uso de la herramienta de autor iDesigner. Sin duda facilitó enormemente los desarrollos y las pruebas, de otra forma, seguramente no hubiésemos podido llegar a realizar todo lo desarrollado. Por ejemplo, una gran ventaja era que abstraía bastante (pero no del todo) de la implementación de pila sobre la cual se ejecutaba la aplicación, que de otra forma, seguramente hubiese sido un infierno. No obstante, esto supuso no llegar tan lejos en la transferencia de conocimiento como hubiese deseado. En definitiva, se trató de una decisión que buscó un compromiso entre aprendizaje y cumplimiento (eficacia).

Otro aspecto que debería haberse trabajado mejor era la plataforma de TDT a instalar en Gobierno de Navarra. Esta plataforma era la clave y la base de todas las aplicaciones además de un pilar de evolución a futuro. La falta de recursos y definición clara de la misma impidió dedicarle el tiempo suficiente.

Desde el punto de vista de MHP, es una tecnología que presenta grandes limitaciones. El espacio útil de la pantalla es muy reducido, la fuente recomendada usar es muy grande, debido a la distancia de visión natural de la TV, lo cual reduce aún más las posibilidades del interfaz. Por otro lado, el lenguaje de programación y las librerías disponibles son también reducidos. Eso sin contar con el propio decodificador donde se ejecuta, de escasa memoria y capacidad. Hay que ser ingenioso para desarrollar cosas interesantes, que por otro lado, se pueden hacer, muchas, y muy interesantes.

Un factor que no debe descuidarse nunca es el canal de emisión, o carrusel. Es un aspecto muy influyente en el resultado final debido a que es un bien muy escaso. Existe muy poco ancho de banda, a pesar de que en Navarra afortunadamente se cuenta con un canal dedicado, que debe utilizarse con mucha responsabilidad y que exige un mimo en el desarrollo y optimización de las aplicaciones que el IDesginer, por ejemplo, al igual que otras herramientas de autor no permite.

Muchas de estas cuestiones, de forma errónea y por desconocimiento (aquí tiene sentido el concepto piloto), no se tuvieron en cuenta en el desarrollo de las aplicaciones, resultando, en la práctica, en una uso inadecuado por nuestra parte del canal y en una latencia de carga de las aplicaciones demasiado alta.


Vista al futuro

El futuro de la interactividad en la TDT, en mi opinión, pasa por evolucionar el estándar MHP con mayor agilidad. Por ejemplo, la versión 1.0.X hace uso de una parte de Personal Java 1.1.8, una versión bastante obsoleta de Java mientras que la 1.1.X parte de JavaME, bastante más avanzado pero que han tardado mucho en adoptar. Si JavaFX parece ser el sucesor de JavaME y Swing sería lógico que MHP acabase adoptándolo, pero la cuestión es cuando. Todas las tecnologías precisan de un periodo de madurez, pero en el caso de MHP resulta excesivo. Por otro lado, la versión MHP también especifica los requerimientos mínimos de los decodificadores, cuyas prestaciones son bastante reducidas. Este debería ser otro aspecto a mejorar, incorporando más capacidad, memoria y sin duda alguna, mejores conexiones: USB, Bluetooth, Wifi, etc. Así mismo, una regulación y medidas de calidad en el uso del carrusel favorecerían mucho la experiencia con aplicaciones MHP. Puede, como parece que apuntan algunos del sector (en un artículo más adelante comentaré este punto), que las aplicaciones debieran cargarse a través del canal de retorno mediante una conexión ADSL y que el carrusel tan solo sirviese para señalizar y publicar las aplicaciones. Sin duda esto mejoraría la experiencia final del usuario, reduciendo tiempos de carga, y liberaría bastante las restricciones sobre las aplicaciones que marca el carrusel por la escasez del ancho de banda, abriendo más posibilidades.

En cualquier caso, un aspecto que nunca hay que perder de vista cuando se desarrollan aplicaciones MHP es que estas tienen sentido tanto en cuanto apoyen y estén ligadas a la televisión, ofreciendo contenidos interesantes complementarios y asociados a esta. Seamos sinceros, ¿por qué llevas toda la vida viendo la TV?

La TDT, al menos de momento, no ha cambiado la forma de ver la televisión, aunque lo prometía, pero sí que podría hacerlo con la ayuda de MHP. No obstante, para que suceda debe existir un modelo de negocio que lo soporte, algo que por el momento parece no estar muy claro.

Este escenario, no obstante, no es replicable al caso de aplicaciones de la administración, como fue el ámbito de proyecto piloto que he descrito. En este caso, las aplicaciones no están asociadas al contenido audiovisual, pero lo que es indudable es que deben aportar algo al telespectador.

Dado que se trata de un nuevo canal de comunicación, la administración debe determinar su estrategia de acercamiento al ciudadano a través de la TDT, anteponiendo los intereses del ciudadano, sino los esfuerzos serán en vano, dado que este ciudadano nunca utilizará las aplicaciones en caso contrario. Este proyecto ha sido una primera experiencia para la T-Administración en Navarra, pero no debería ser la única. Ahora toca reflexionar sobre lo que se ha hecho, las posibilidades de la TDT, y lo que desea el ciudadano y en función de todo esto la evolución de la T-administración en Navarra. Siempre con una mirada crítica, puesto que en la TDT no cabe todo, es necesario un ejercicio de responsabilidad sobre el mejor uso del carrusel, sobre lo que es primordial que esté y lo que no lo es tanto.

Seguramente, a lo largo de este escrito he podido resultar muy denso en numerosas ocasiones. Disculpas a todo aquel que se hay quedado por el camino, y mi más sincero agradecimiento a aquel me haya seguido hasta el final. Si alguien siente curiosidad en algún aspecto del proyecto no dude en ponerse en contacto conmigo.


Proyecto Piloto TDT

Documents

la encomienda

y establecer

seguimiento y

pblico y

nga y dgpsi

nga y otra

generacin y mantenimiento

interactivos y transaccionales