Proyecto Experiencia de. a software libre en la Conselleria de Infraestructuras y Transporte

Transcripción

1 Proyecto Experiencia de migración integral a software libre en la Conselleria de Infraestructuras y Transporte

2 Experiencia de migración integral a software libre en la Conselleria de Infraestructuras y Transporte

3 ÍndiceParte 1 Desarrollos 7 Corporativos y Web Capítulo 1 Una visión general 8 Coordinado y editado por Depósito Legal M Traducido al inglés por Crown Communication, S.L. C/. Archiduque Carlos, nº65, Valencia Diseño y maquetación Edit Lin Editorial, S,L Avda. de Portugal, 85-local Madrid Licencia Esta obra está distribuida bajo la licencia Reconocimiento-No comercial-compartir igual 2.5 España de Creative Commons Para ver una copia de esta licencia, visite licenses/by-sa/2.5/es/ Capítulo 2 Capítulo 3 Capítulo 4 Capítulo 5 Capítulo 6 gvdades: experiencias con Sistemas de Gestión de Bases de Datos 11 gvmétrica y MOSKitt: definición de una metodología de desarrollo y su soporte 17 gvhidra: desarrollo de un framework para PHP 22 Implementación de Sistemas de Control de Versiones: CVS y Subversion 24 Implementación de una herramienta de generación de informes 25 Capítulo 7 Migración del portal web e Intranet 28 Capítulo 8 Workflow para la tramitación y seguimiento de expedientes 31 Capítulo 9 gvadoc: sistema de gestión documental 33

4 Parte 2 Sistemas Operativos 37 y Comunicaciones Capítulo 10 Entorno de PC de usuario final 38 Capítulo 11 Entorno de servidores de red local 40 Capítulo 12 Entorno de comunicaciones y networking 43 Capítulo 13 Servidores corporativos 44 Parte 3 SIG y CAD: gvsig 47 Capítulo 14 gvsig: introducción 48 Capítulo 15 Capítulo 16 gvsig: descripción y justificación de la situación inicial 49 gvsig: evolución hasta la solución actual 52 Capítulo 17 gvsig: conclusiones 63 Capítulo 18 gvsig: próximas líneas de actuación 64 Referencias 65 Glosario 66

5 PRÓLOGO gvpontis, un caso de éxito gvpontis es el nombre con el que hemos identificado el proyecto de migración de todos los Sistemas de Información de la Conselleria de Infraestructuras y Transporte (CIT) desde los sistemas privativos hacia los Sistemas Libres. Los antecedentes al proyecto se localizan en 2003 cuando se produce un cambio importante en los costes de los permisos de uso de las licencias. Esta modificación de los criterios de venta, unida a la política que ya tenía la conselleria de mantener a todos nuestros usuarios con licencia legales, implicaba un incremento sustancial del coste en licencias que resultaba insostenible, porque la mayoría del presupuesto se dedicaba a cubrir ese coste. Por otra parte, se habían realizado muchos intentos para disponer de una información centralizada, veraz y única de los Sistemas de Información Corporativos, a ello se unía un uso masivo de herramientas informáticas de manejo individual necesarias para el trabajo de nuestro personal que también deberían integrarse. Como orden de magnitud de la complejidad del proyecto a acometer, indicar que el número de trabajadores que emplean los diversos sistemas de información ronda el millar, de los cuales unos seiscientos se ocupan de la administración general y casi cuatrocientos de la administración especial, fundamentalmente en ingenierías medias y superiores y arquitectura. Todos ellos distribuidos entre el Servicio Central, tres Servicios Territoriales y algunos Centros Comarcales. Ante esta situación propusimos a la Dirección General de Modernización iniciar un proyecto de migración integral de todas nuestras herramientas y sistemas a Software Libre. Una vez aceptada la propuesta y autorizado el plan de migración, en septiembre de 2003, dedicamos el último trimestre a estudiar la viabilidad técnica del proyecto. Encargamos a la Universidad de Valencia y a la Universidad Politécnica de Valencia diversos estudios sobre las alternativas del Software Libre en esos momentos en el mercado informático. También a algunas pequeñas empresas que estaban usando las nuevas tecnologías les encargamos la realización de pequeñas aplicaciones informáticas en las que utilizaban los nuevos conceptos que se aplicaban en el desarrollo informático. Tanto en los informes como en las aplicaciones no aparecía ningún aviso, impedimento, indicación o anuncio que recomendara no iniciar el proyecto o que manifestara unos peligros insalvables en el desarrollo del mismo. Todos estos informes están disponibles en la pagina web del proyecto: El único riesgo real era el del cambio tecnológico a realizar, y en este cambio es donde estaba el miedo al proyecto, pero eso lo veremos mejor en las páginas siguientes de la memoria. 4

6 Por fin, en enero de 2004 se inicia gvpontis como un proyecto a desarrollar en cuatro años y que debía incluir la migración de todos los Sistema de Información de la conselleria, realizándose de forma ordenada, gradual y completa y estableciéndose dos principios que regirán todo el proceso: dd El proyecto no se financiará con recursos nuevos. Sólo se utilizarán los recursos ya asignados al Servicio de Organización e Informática. dd Debe minimizarse la repercusión del proyecto en el trabajo diario del personal de la conselleria. Lo fundamental es el trabajo y no la herramienta. Una vez iniciado el proyecto hemos comprobado que incluso aquellas herramientas más verdes han evolucionado más que satisfactoriamente. La progresión ha sido casi geométrica y la implantación de los Sistemas Interoperables, de los Estándares Abiertos y de las herramientas y Sistemas Libres están ya en pie de igualdad en los Sistemas de Información. En 2008 sólo los temas de multimedia y similares tienen una mayor cobertura en el software privativo. Como se explica en las siguientes páginas, hemos tenido problemas, los hemos conseguido resolver y todavía tenemos algunos pendientes. Hemos dedicado un tiempo a la formación, no sólo de los usuarios, sino sobre todo para el personal propio del Servicio, formación que se hace necesaria y continua en este negocio de la informática. Debemos reconocer, tras los años transcurridos, que el mayor problema ha sido el miedo al cambio. Es el miedo al cambio tecnológico sin paraguas el que más ha frenado el desarrollo de este proyecto, un miedo que es un reto al mismo tiempo y que nuestra experiencia nos dice que siempre se puede asumir. En nuestro caso con formación, planificación y siempre un plan B por si acaso. En diciembre del año 2008 habremos finalizado el proceso de migración. Nos quedarán algunos reductos y algunas aplicaciones obsoletas sin migrar, pero sólo porque su coste no hace interesante económicamente su migración. El tiempo eliminará esos restos que no influyen en el trabajo de la conselleria porque hemos conseguido que sigan funcionando en el nuevo entorno de trabajo. Ahora nos dicen que a esto se le llama caso de éxito, pero para nosotros ha sido más bien una experiencia profesional única. Para finalizar, y como siempre, se hace necesaria la mención a los agradecimientos. En primer lugar, y el más importante, debo agradecer a todo el personal del Servicio de Organización e Informática. Han trabajado en estos cuatro años de forma admirable. El agradecimiento incluye a los técnicos y también a los administrativos. Todos han colaborado en superar los problemas que han surgido. No puedo citarlos aquí a todos, pero tanto el personal interno como externo del Servicio se merecen mi reconocimiento. También han apoyado y, en algunos momentos, protegido el proyecto las sucesivas Secretarías Generales Administrativas que han pasado por la conselleria durante estos años. Isabel Villalonga que lo impulsó al principio con su característica energía. José Manuel Palau que también apreció la importancia del proyecto. Ana Climent, que lo ha sufrido el mayor tiempo, pero que lo ha impulsado de forma decidida y continuada. Durante estos cuatro años también han influido los dos Consellers que ha tenido la conselleria. José Ramón García Antón lo aprobó en su momento y en algunas ocasiones tuvo que sufrirlo, y Mario Flores que lo ha conocido ya con los problemas resueltos pero que se ha involucrado sobre todo en la parte última y definitiva. Sólo una persona ha estado estos cuatro años como responsable último, Gaspar Peral, subsecretario de la conselleria, él ha sido el impulsor continuo del proyecto. Sin su apoyo y cobertura esta memoria no hablaría de un caso de éxito sino de un proyecto fallido o inacabado. Martín García Hernández Jefe del Servicio de Organización e Informática 5

7 Parte 1

8 Desarrollos Corporativos y Web Por la amplia diversidad de proyectos y tareas acometidas en el proyecto gvpontis en el ámbito del desarrollo de aplicaciones, se proporciona a continuación un breve resumen, a modo de visión de conjunto, de las principales líneas de trabajo llevadas a cabo. Posteriormente, en sucesivos apartados se proporciona una explicación más detallada de cada uno de los mismos. 7

9 CAPÍTULO 1 Una visión general Alineado en el marco del proyecto gvpontis, y a partir de las propuestas planteadas tras los estudios previos en materia de Desarrollos Corporativos y Web (contenidas en el informe de conclusiones), se empieza a planificar la puesta en marcha del proyecto de migración a Software Libre de manera que el desarrollo de nuevas aplicaciones sea realizado en open source. La migración de aplicaciones se ve afectada por la decisión simultánea de cambiar la arquitectura de desarrollo cliente/servidor, existente en las fecha de inicio del proyecto, por una arquitectura de tres capas (posteriormente múltiples capas). Si este cambio de paradigma inicialmente introducía una componente de incertidumbre más en el proyecto, con el tiempo nos ha resultado beneficioso debido a la abstracción que se produce en la programación de cada una de las capas en las que se divide el sistema de información (presentación, negocio y datos), permitiendo una especialización de nuestro personal de desarrollo y logrando una definición más clara de las funcionalidades de nuestros sistemas de información. En el punto de partida del proyecto de migración, las dos herramientas de trabajo utilizadas para el desarrollo de aplicaciones en el entorno cliente/servidor eran Oracle Developer y PowerBuilder. Con la finalidad de alcanzar la arquitectura de tres capas se decidió emplear PHP y Java para las nuevas aplicaciones a desarrollar, mientras que respecto a las aplicaciones que ya se encontraban en producción en cliente/servidor, se decidió implementarlas a tres capas manteniendo Oracle Developer, lenguaje en el que fueron programadas inicialmente. Gradualmente se convertirán a los lenguajes PHP o Java dependiendo de sus características. Los Sistemas de Gestión de Bases de Datos (SGBD) constituyen una de las piedras angulares del proyecto gvpontis, es por ello que se desarrolla el proyecto gvdades con el objeto de integrar los esfuerzos de investigación y puesta en práctica realizados en esta materia. La conselleria contaba con aplicaciones departamentales desarrolladas en Access, junto a aplicaciones corporativas que empleaban Oracle. Respecto a los desarrollos en Access, dado que no existían alternativas ofimáticas similares suficientemente maduras a las que migrar, se optó por realizar nuevos desarrollos en PHP conjuntamente con PostgreSQL o MySQL. Respecto a los desarrollos corporativos, se decidió mantener Oracle en las aplicaciones en producción y realizar los nuevos desarrollos independientes de la Base de Datos y que al menos tuviesen garantizado su funcionamiento en PostgreSQL. MySQL, por su sencillez, también sería empleado para soportar los portales web de la conselleria. La existencia de numerosos desarrollos existentes, así como la necesaria obligación de relacionarse con otras administraciones de la Generalitat que se hacían servir de Oracle, obligaba a la necesaria convivencia de Oracle en servidores Linux por lo que se precisó migrar de Oracle 8i a Oracle 10gR2. 8

10 Una visión general 1 Otro aspecto significativo a solucionar era la obtención de datos por las aplicaciones procedentes de dos SGBD distintos, siendo uno de ellos Oracle. Nos vimos en la obligación de desarrollar una herramienta que realizase replicaciones a nivel de tabla. Actualmente se está reemplazando esta solución por el empleo de WebServices. No podemos dejar de señalar los problemas que aún no se encuentran óptimamente resueltos. Entre estos, que son la base de nuestras principales líneas de actuación, se encuentran la búsqueda de mejores herramientas de administración y monitorización de PostgreSQL, así como la mejora de la gestión de la seguridad y control de accesos. En los párrafos anteriores se ha hecho referencia a los cambios tecnológicos llevados a cabo en el proyecto de migración. Pero también resultaba necesario realizar cambios culturales que contribuyeran a racionalizar la interacción de múltiples y diversos perfiles que colaborarían en las diversas fases de nuestros desarrollos, bien fuera por la migración de gran parte del inventario de aplicaciones (con la reingeniería que se decidió realizar a muchas de ellas debido a que se habían desarrollado bastantes años atrás), así como para afrontar con mayores garantías de éxito los nuevos desarrollos que por necesidades de la conselleria fueran surgiendo. Se imponía pues, en primer lugar, la necesidad de adoptar una metodología de desarrollo, que entre otros objetivos permitiera: dd Generar una sistemática de trabajo con tareas claramente definidas y asignadas a los diversos perfiles colaboradores. Con ello conseguiríamos integrar los trabajos realizados por el personal de Organización e Informática que participaba en cada uno de los proyectos de desarrollo. dd Homogenizar la documentación de los productos de salida que cada una de las tareas transmitía a la siguiente con objeto de aumentar la eficiencia de los proyectos. Siguiendo las recomendaciones del documento de conclusiones, resultó MÉTRICA la metodología adoptada debido a que soporta todo el ciclo de vida del software además de dar cobertura al desarrollo orientado a objetos. Se inicia pues el proyecto gvmétrica con el objetivo de adaptar MÉTRICA Versión 3 a las necesidades de la Conselleria de Infraestructuras y Transporte. A medida que avanza el proyecto y va siendo puesto en práctica en las fases de análisis y diseño de nuevas aplicaciones, se evidencia la necesidad de proveerse de una herramienta CASE 1 que le dé soporte a su implantación, minimizando en la medida de lo posible el empleo de plantillas propias. Este es el germen de gvcase, un subproyecto integrado en el proyecto gvpontis que tiene como objetivo desarrollar MOSKitt, una herramienta CASE libre desarrollada sobre la plataforma Eclipse. En la fase de programación, un aspecto importante a considerar cuando se van a desarrollar numerosas aplicaciones es el de proveerse de un framework 2. Surge con ello gvhidra, otro subproyecto integrado en gvpontis que tiene como objetivo convertirse en el marco de trabajo que sirva de base para el desarrollo en PHP de aplicaciones de gestión en entornos web siguiendo la Guía de Estilo 3 de la conselleria. gvcase, un subproyecto integrado en el proyecto gvpontis que tiene como objetivo desarrollar MOSKitt, una herramienta CASE libre desarrollada sobre la plataforma Eclipse Respecto al desarrollo de aplicaciones en Java la decisión sobre el framework a utilizar aún está en fase de análisis, si bien inicialmente se realizaron pruebas con Struts y Turbine. Actualmente se está trabajando con una combinación modular de JSF en capa de presentación, Spring en capa de negocio e Hibernate en capa de persistencia de datos. 1 Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software Asistida por Ordenador) son aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software en todos los aspectos del ciclo de vida. 2 Entorno de trabajo que agrupe un conjunto de programas, bibliotecas y lenguaje interpretado predefinidos que ayuden a desarrollar y unir los diferentes componentes de un proyecto. 3 Una guía para unificar los criterios de aspecto y usabilidad en el proceso de desarrollo de aplicaciones. 9

11 migración a software libre Experiencia de integral Una de las funcionalidades más importantes al contar con varios desarrolladores que concurren en el desarrollo de una aplicación es el de contar con un sistema de control de versiones que permita mediante un repositorio común, almacenar los ficheros que se están programando, así como comparar cambios que se hayan podido realizar en ellos. Para ello se adoptó inicialmente CVS. Actualmente, estamos implantando Subversion por las ventajas que presenta frente a CVS, al incorporar un control mediante permisos para acceder a los proyectos y mejorar el versionado de los archivos. Para facilitar las labores de programación de aplicaciones se requería proveerse de un Entorno de Desarrollo Integrado. Eclipse se constituía como el IDE 4 de código abierto más maduro en el momento de la toma de decisión. Tiene, entre otras ventajas, el contar con una gran comunidad de usuarios así como, mediante el empleo de plugins 5, permitir programar con varios lenguajes y ampliarle funcionalidades. Hasta la fecha no hemos hecho más que disfrutar de las ventajas de la aplicación y de su evolución, proporcionando cada vez mejores características. El tiempo ha confirmado el acierto en la elección de esta herramienta. El proyecto MOSKitt está siendo desarrollado como un plugin de Eclipse. Otro aspecto que debíamos cubrir era la generación de informes en código abierto. La herramienta seleccionada por la conselleria, ireport que incluye el motor JasperReports, se ha mostrado, por su madurez, ampliamente solvente. Es una herramienta multiplataforma desarrollada en Java que de entre sus principales ventajas ha destacado por su facilidad de uso para generar informes de mucha riqueza (gráficos, tablas cruzadas, etc.) con contenido dinámico, y por los múltiples formatos a los que es capaz de exportar la información, XML o PDF entre otros. Se pueden extraer los datos desde orígenes muy diversos, entre los que figuran todas las Bases de Datos, e incorpora un visor que permite previsualizar en pantalla los informes. 4 Programa compuesto por un conjunto de herramientas que ha sido empaquetado como un programa de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y un constructor de interfaz gráfica de usuario. 5 Aplicación informática que interactúa con otra aplicación para aportarle una función o utilidad específica. Constituye una forma de expandir programas de forma modular, de manera que se puedan añadir nuevas funcionalidades sin afectar a las ya existentes ni complicar el desarrollo del programa principal. Por último, el portal web y la intranet también han sufrido su correspondiente migración. Se ha procedido a realizar un rediseño y reestructuración de la información adoptándose Typo3 como gestor de contenido. Actualmente queda pendiente acoger soluciones para el desarrollo de formularios rellenables en PDF, así como para aspectos de edición avanzada de imágenes que no cubre GIMP. En resumen, hasta la fecha las principales líneas de trabajo en el ámbito de Desarrollos Corporativos y web, enmarcados en el proyecto gvpontis, son las que se detallan a continuación: >> Actuaciones de ámbito general: dd gvdades. Experiencias con Sistemas de Gestión de Bases de Datos. dd gvmétrica y MOSKitt. Definición de una metodología de desarrollo y su soporte. dd gvhidra. Desarrollo de un framework para PHP. dd Implantación de Sistemas de Control de Versiones. CVS y Subversión. dd Implantación de una herramienta de generación de informes. dd Migración del portal web e Intranet. >> Como principales actuaciones específicas y a modo de ejemplos ilustrativos encontramos: dd Migración de MASTIN. Workflow para la tramitación y seguimiento de expedientes. dd gvadoc. Sistema de gestión documental. A continuación, en cada uno de los siguientes capítulos, se amplían los detalles de cada una de las actuaciones acometidas. 10

12 gvdades: experiencias con Sistemas de Gestión de Bases de Datos CAPÍTULO 2 Cuando se inició el proyecto gvpontis de migración a Software Libre en la conselleria, se descompuso en varias partes.una de ellas dio origen al proyecto gvdades, que pretendía abordar el problema de la migración de los distintos gestores de bases de datos. Se empleaban principalmente dos gestores: d d d d Oracle, para aplicaciones corporativas como contenedor de los datos. Las aplicaciones que usan estos datos se desarrollaban con herramientas como PowerBuilder y Developer. Microsoft Access, para aplicaciones departamentales o de usuario. En este caso se usa tanto como base de datos como para desarrollar consultas, informes y aplicaciones con la propia herramienta. Debemos recalcar que los usuarios demandaban el uso de Access, ya que algunos lo manejaban con facilidad. Además, desde diversos sistemas se podía conectar, mediante ODBC, con otras bases de datos para capturar campos a incluir en la generación de documentos, hojas de cálculo, etc. Los principales problemas que debíamos resolver en principio consistían en encontrar: 1. Alternativas para el uso de Microsoft Access como base de datos departamental. En dicha fecha no existía versión alternativa en programas de oficina, pero para el uso como gestor de base de datos se vio que se podía conectar mediante ODBC con MySQL o PostgreS- QL, con lo cual existía la posibilidad de realizar instalaciones de dichos programas en los ordenadores de los usuarios o en servidores, si necesitaban compartir datos. 2. Alternativas para el uso de Microsoft Access como herramienta de desarrollo de aplicaciones, consultas, informes, etc. MS Access tenía dos ventajas:»»»» era fácil de usar por usuarios finales, los cuales podían definirse sus propias tablas, consultas e informes, era fácil desarrollar e implantar pequeñas aplicaciones departamentales. No se encontró ninguna herramienta alternativa que cumpliera estas expectativas en aquel momento. El desarrollo de aplicaciones se haría con otras herramientas, por ejemplo, PHP y como base de datos se usaría PostgreSQL o MySQL. 3. Alternativas para el uso de ODBC/OLE para el acceso desde aplicaciones como Word, Excel o desarrollos propios a las bases de datos. 11

13 migración a software libre Experiencia de integral En este caso no hubo problema para decidir pues existía una alternativa madura, UnixODBC, resultando fácil la realización de conexiones ODBC desde aplicaciones que lo soportaran, como OpenOffice. Por ello, se instaló en los ordenadores que lo precisaron, haciendo uso de los drivers ODBC proporcionados por los propios fabricantes. En las aplicaciones Java que lo han permitido, se han usado drivers JDBC estándar. 4. Alternativas para el sistema de bases de datos corporativo, Oracle, así como su uso sobre Linux. Nos marcamos dos objetivos primordiales: dd Convivencia de Oracle con Linux. Debíamos conseguir que el sistema operativo sobre el que corriera Oracle fuera libre. Éramos conscientes que no podíamos suprimir al 100% el uso de la base de datos de Oracle por dos motivos: la existencia de desarrollos antiguos la relación con otras administraciones de la Generalitat Valenciana que usan Oracle en sus soluciones. dd Elección de otro SGBD alternativo con las siguientes carac- terísticas: -- que cumpliera con los requisitos de los SGBD corporativos (administrador de transacciones, consultas, gestión de usuarios, gestión de almacenamiento, integridad, código en base de datos, así como escalabilidad, portabilidad, rendimiento, disponibilidad) existencia de clientes ODBC/JDBC existencia de software para conectarse desde clientes Windows, para aquellos casos en que no se pueda migrar -- que permitiera la migración de código. Aunque deseábamos hacer los desarrollos sin código en la base de datos, resultaba obligatorio para mantener las aplicaciones existentes que dispusiese de soporte para objetos grandes (raw, long, lob, etc.) que dispusiese de herramientas de conexión y administración. 2.1 Análisis de alternativas y selección Se realizó un estudio 1 en el que se compararon las tres principales bases de datos que habían entonces: PostgreSQL, MySQL e Interbase. Se hizo una comparativa técnica así como se estudiaron los modos de poder migrar datos en Oracle a estos otros gestores. Las conclusiones fueron: d d Interbase 6.0. Era estable, rápida, escalable y con las suficientes funcionalidades, pero encontramos poca documentación y pensamos que Borland debía apoyar más este proyecto para que tuviera éxito en la comunidad de Software Libre. d d MySQL 4. Vimos que era sencilla y rápida, la más usada, ampliamente documentada y soportada, pero no soportaba muchas funcionalidades necesarios (transacciones ACID, integridad referencial, no soporta código almacenado, triggers, etc.). d d PostgreSQL 7. Nos pareció la más completa, apoyada por la comunidad de Software Libre, permitía transacciones y concurrencia que cumplen las reglas ACID, integridad referencial, secuencias, lenguajes procedurales incluidos, sistema de copias de seguridad y tolerancia a fallos. Además, un valor añadido es que existía un módulo, PostGIS, bastante maduro, -- que permitiera la migración de datos 1 Ver Comparativa de distintos SGBD bajo Linux. 12

14 gvdades: experiencias con Sistemas de Gestión de Bases de Datos 2 que permitía el mantenimiento de datos geoespaciales, muy importantes en nuestra conselleria. Este estudio nos llevo a tomar la decisión de implantar PostgreSQL en su versión 7.3 como SGBD alternativo a Oracle, sin perjuicio de hacer un seguimiento de MySQL, dado que, al ser la más usada, imaginábamos que se le irían añadiendo funcionalidades. 2.2 Implantando la solución adoptada Una vez tomada la decisión, PostgreSQL, realizamos una instalación de dicha base de datos en dos servidores, uno para desarrollo y otro para producción. Se hicieron unos desarrollos iniciales para familiarizarnos con las características de esta base de datos, así como probar el funcionamiento. Tomamos la decisión de usar PostgreSQL para: dd todos los nuevos desarrollos, usándolo como nuestro nuevo servidor de bases de datos OLTP dd la base de datos del nuevo Archivo Documental que íbamos a desarrollar (ver gvadoc, Capítulo 9) dd la base de datos GeoEspacial usando PostGIS (necesario para gvsig) dd más adelante, hemos usado PostgreSQL como repositorio para la herramienta gforge. Con las líneas anteriores claras, empezamos una fase de adaptación en la que: dd tuvimos que tener en cuenta las incompatibilidades/com- patibilidades entre Oracle y PostgreSQL. Muchas de ellas las descubrimos durante el propio trabajo de desarrollo, por ejemplo, nombres distintos para los tipos de datos o comandos que en un sistema funcionaban de modo distinto al otro dd establecimos la forma en que las aplicaciones debían tra- bajar con la base de datos (definición de bases de datos, esquemas, objetos de la base de datos, usuarios, grupos, tablespaces, gestión de la seguridad, etc.) dd desarrollamos procedimientos para el mantenimiento de la base de datos (arranque, parada, copias de seguridad, respaldo, gestión de sesiones, etc.). Hemos ido avanzando con PostgreSQL en sus sucesivas versiones, llegando desde la 7.3 hasta la 8.2 (pasando por la 7.4 y la 8.1). En dichas migraciones de versiones no hemos tenido ningún problema para realizar las actualizaciones El problema de la replicación de datos Uno de los principales problemas que nos encontramos es que los desarrollos nuevos necesitaban acceder a los datos propios que se creaban en la base de datos nueva de PostgreSQL, pero también se necesitaba acceder a otros datos que estaban en otras bases de datos que, para más dificultad, estaban en Oracle. Qué hacer si necesitamos saber un dato que está en otra base de datos o necesitamos combinar tablas que están en otras bases de datos? Estos problemas no se presentan si hubiese una capa intermedia de acceso a los datos, como los WebServices o Hibernate, pero en aquella época no teníamos esa capa. Ante este problema, nos planteamos dos soluciones: 1. Que las aplicaciones nuevas mantuvieran varias conexiones, una a la base de datos nueva y otra a la antigua para recuperar el dato que necesitaban. 2. Replicar las tablas de la base de datos Oracle en la base de datos PostgreSQL, para los casos en que necesitaran trabajar con conjuntos grandes de datos en ambas bases de datos. Tanto Oracle como PostgreSQL tienen el concepto de dblink, enlaces de base de datos, que permiten relacionar datos entre bases de datos distintas, siempre que sean del mismo fabricante. Por todo lo anterior iniciamos una replicación de datos que se hacía mediante 13

15 migración a software libre Experiencia de integral volcados completos de datos de una base de datos a otra. Esta solución no resultaba satisfactoria por los siguientes motivos: dd Eran volcados completos, es decir, se borraban los datos de la tabla destino y se volvían a volcar, de modo que, para tablas pequeñas no había problema, pero si había muchas tablas y grandes, el sistema podía resultar ineficiente. dd Al borrarse datos de las tablas, no se podían definir claves aje- nas a las tablas, pues impedirían el borrado de los datos. dd Al ser volcados completos, se ejecutaban una vez al día, con lo que no disponíamos de la replicación instantánea, necesaria o conveniente en algunos casos. En la actualidad, hemos desarrollado una herramienta para mantener la replicación a nivel de tabla, tanto en modo refrescos completos como en modo refresco rápido, que consiste básicamente en la definición de un repositorio de tablas maestras y tablas copias, un sistema de triggers que se usan para los refrescos rápidos y unos programas en PHP que realizan los refrescos y el control de las replicaciones. Este sistema lo tenemos ya en producción y lo usamos para aquellos casos que no podemos resolver con WebServices Migración de Oracle a servidores Linux Paralelamente, iniciamos el estudio para poder usar Oracle sobre servidores Linux. La versión que teníamos entonces era la versión que no estaba certificada para las versiones de Linux que usábamos (Suse 8). De este modo, iniciamos una migración de Oracle 8i a Oracle 10gR2 (esta última versión está indicada expresamente para servidores Linux). En la actualidad, tenemos nuestros servidores de desarrollo en Oracle 10g sobre Red Hat ES 4 y estamos esperando pasar en breve a los servidores de producción Internacionalización En las sucesivas migraciones de versiones de bases de datos, hemos llegado a la versión de PostgreSQL, y durante estas migraciones hemos aprovechado para abordar el tema de la internacionalización de los conjuntos de caracteres, de modo que hemos pasado de soportar sólo el conjunto de caracteres ISO (Latin1) a soportar UTF MySQL Además, iniciamos una pequeña implantación de MySQL4, ya que hemos adquirido productos, como Typo3 e IdentityManager de SUN que usan esta base de datos como repositorio, lo cual nos sirve para ver funcionalidades de este motor de base de datos Clientes de acceso a las bases de datos Otro problema que suele ocurrir cuando se cambia de entorno es el de las herramientas que funcionaban perfectamente en entorno Windows contra Oracle (como SQL*Plus, TOAD, Enterprise Manager, etc.), y que ahora no funcionan en entorno Linux, y contra otras bases de datos. Las nuevas herramientas deben satisfacer algunos de los siguientes requerimientos: dd Funcionar sobre Linux dd Conectar a Oracle, PostgreSQL o MySQL (según la herra- mienta) dd Disponer de funcionalidades para creación de tablas, vistas y código dd Disponer de funcionalidades de administración y monitori- zación dd Ser Software Libre o gratuitas. La experiencia en la búsqueda ha sido buena, si bien es cierto que no hemos encontrado ningún producto que fuera tan completo como TOAD (u otras herramientas de pago), pero hemos llegado a una buena aproximación. En la siguiente Tabla 1 resumimos los clientes con los que hemos trabajado. 14

16 gvdades: experiencias con Sistemas de Gestión de Bases de Datos 2 Tabla 1. Clientes con los que hemos trabajado Cliente SGBD Descripción pgadmin3 PostgreSQL»» Útil para programadores y flojo para administradores.»» Dispone de versión web en PHP (phppgadmin3).»» Funciona en Linux y Windows Formación Al inicio del proyecto de migración, se organizó un curso en la Universitat Politècnica de València sobre Administración de PostgreSQL. A partir de aquí, hemos avanzado nosotros mismos, consultando la documentación y practicando. En estos momentos, ya desde la conselleria, se está en condiciones de preparar un curso de Administración de Bases de Datos con PostgreSQL. El manual del curso está disponible en la web de gvpontis.»» Propia de Oracle, certificada para conectar a versiones 9.x y 10.x Dificultades y Problemas SQLDeveloper Oracle MySQL»» Requiere JDK.»» Funciona en Linux y Windows. En este proceso nos hemos encontrado con problemas. Algunos no los hemos resuelto todavía:»» Útil para programadores. dd Falta de herramientas para administrar y monitorizar Post- gresql, al menos que sean GPL. Squirrel isqlplus Oracle MySQL PostgreSQL Oracle»» GPL, se pueden hacer plugins para incorporar funcionalidades.»» hecha en Java, funciona en Linux y Windows.»» se conecta por JDBC a cualquier SGBD.»» Cliente web de SQL*Plus para conectar a Oracle. Lo cierto es que, aunque perdiendo funcionalidades respecto a TOAD, hemos trabajado satisfactoriamente con las tres primeras, y ya es gusto personal de cada uno la preferencia sobre una u otra. Otro aspecto a considerar es el punto de vista del Administrador de Base de Datos. Para Oracle 10g no ha existido problema, pues Oracle proporciona una interfaz web para Enterprise Manager 10g muy potente. Para PostgreSQL, en cambio, no hemos encontrado herramientas GPL y gratuitas que nos satisfagan, sobre todo en el campo de la monitorización de la base de datos. dd Falta de empresas que den un soporte cualificado para Post- gresql. Este problema está empezando a solucionarse. dd Gestión de la seguridad y control de accesos, porque Post- gresql no tiene mecanismos finos de control, como Oracle Label, Oracle Vault, etc. La implementación de la seguridad debe hacerse con desarrollos propios, a los que no hemos llegado todavía. dd Pérdida de integración de productos. Frente a la oferta de Oracle que tiene infinidad de productos complementarios, PostgreSQL sólo ofrece la base de datos. Evidentemente, estas dificultades ya las imaginábamos cuando empezamos con el proyecto y las asumimos Impresión sobre la migración Tenemos una impresión positiva, hemos conseguido trabajar con PostgreSQL y MySQL y las pocas incidencias que han aparecido, las hemos resuelto recurriendo a los conocimientos y servicios de la comunidad de usuarios, principalmente. 15

17 El cambio se ha hecho con mucho respeto, pero sin miedo. Hay que tener claro que cambiar a Software Libre es un cambio de mentalidad grande. No se puede pretender obtener las mismas prestaciones en PostgreSQL que las que se tienen con Oracle. Ello no quita que veamos que nos está siendo muy útil esta migración. Asumimos determinadas pérdidas, que se pueden ver compensadas por las ganancias, tanto económicas como de colaboración en proyectos que son de interés para la sociedad y la conselleria. 2.3 Próximas líneas de actuación dd Mejora y posible migración del sistema de replicación de PHP a Java. dd Creación con PostgreSQL de un sistema Data Warehouse apoyándose en Mondrian y JasperETL. dd Integración de las bases de datos alfanuméricas con las geoespaciales de gvsig. dd Estudiar la viabilidad de uso de MySQL5, pues está evolu- cionando rápidamente, más ahora que está siendo impulsado por SUN. dd Poder implementar un sistema que nos permita la monitori- zación de las bases de datos, usando productos libres como Cacti o Munim. dd Desarrollar un módulo de seguridad para poder incorporarlo a las aplicaciones, que gestione los accesos de los usuarios, privilegios y audite los accesos, de modo que sea independiente de la base de datos. dd Para el caso del Microsoft Access, se va a usar como alter- nativa libre OpenBase2. dd Selección de empresas que estén dispuestas y preparadas a colaborar y dar soporte en PostgreSQL para mejorar las prestaciones, por ejemplo para poder implementar clusters de bases de datos, alta disponibilidad, etc. 2.4 Recomendaciones dd Si se usa Access o similares como motor de base de datos en pequeñas bases de datos, podemos sustituirlo por MyS- QL o PostgreSQL, pues resultan de fácil instalación y coste cero en licencias. dd Si se necesitan crear muchas bases de datos departamenta- les, por ejemplo, una organización que tiene muchos centros, y en cada uno debe tener una base de datos, si instalamos PostgreSQL, ahorramos costes, además de resultar muy fácil administrarlo en remoto desde un nodo centralizado. dd La implantación en una gran organización de estos sistemas, como es nuestro caso, implica la convivencia de varios sistemas de bases de datos heterogéneos que deben relacionarse entre ellos. En este caso, es muy importante convencerse de que no sólo consiste en un cambio de bases de datos, sino que se deben realizar procesos de modernización en los desarrollos de software, de modo que se supla desde las aplicaciones las carencias que se dan al no usar un único proveedor de software. Es fundamental una separación de los desarrollos en capas, para evitar acoplamientos. dd Perder el miedo a las novedades, estos gestores de bases de datos tienen la mayoría de las funcionalidades que se necesitan en muchos entornos. Animamos a las universidades a que empleen estos gestores de bases de datos, tanto para la enseñanza como para su trabajo, así como a muchas empresas tecnológicas para que vean que existen oportunidades de negocio con este software desarrollando mejoras o prestando soporte. dd Preguntarnos por las prestaciones que le vamos a solicitar a nuestras bases de datos puede evitar, si optamos por las alternativas libres existentes, tener que asumir los elevados costes de licencias y soportes de aplicaciones privativas. 16

18 gvmétrica y MOSKitt: definición de una metodología de desarrollo y su soporte CAPÍTULO 3 En el documento de conclusiones se establecía como uno de los objetivos principales del proyecto gvpontis la Determinación de un Entorno de Trabajo completo y adecuado al tipo de desarrollos que deben ser abordados por la CIT 1. Básicamente las dos líneas de trabajo principales a realizar en este ámbito eran las siguientes: dd Definición de una Metodología de Desarrollo de Software adaptada a la CIT. dd Definición e Implantación de la arquitectura de soporte a los desarrollos planteados. El alcance de estos trabajos era muy amplio, para abordarlos fueron creados varios proyectos integrados dentro del propio gvpontis. Estos proyectos necesitaban avanzar de manera coordinada, dado que la definición de la metodología de desarrollo debía adoptar, como parte de sus restricciones técnicas y operativas, las conclusiones alcanzadas respecto a arquitectura de soporte. El proyecto que desarrollará la primera línea de trabajo citada se denomina gvmétrica. 1 Ver Capítulo 2, las alternativas para los nuevos Desarrollos Corporativos y Desarrollos Web con herramientas Linux del documento de conclusiones. Se consensuaron los siguientes criterios 2 antes de abordar los trabajos: dd La metodología a adoptar deberá ser una adaptación de MÉ- TRICA Versión 3 3. dd Aunque la metodología propuesta deberá cubrir todo el pro- ceso de desarrollo, se prioriza la adaptación de las fases de análisis y diseño. dd Se deberán potenciar las técnicas de orientación a objetos en estas dos fases. De todo esto se deduce que el objetivo que se quiere alcanzar es el de definir para la CIT y sus empresas colaboradoras un enfoque especialmente adecuado para construir diversos sistemas de información similares, que automatizan procedimientos administrativos u otros procesos diseñados por los ingenieros de procesos de la CIT. 2 La justificación a cada una de estas decisiones se puede encontrar en el documento de conclusiones elaborado por el Grupo Linux. 3 MÉTRICA Versión 3 es una metodología desarrollada por el MAP (Ministerio de Administraciones Públicas) y de obligado cumplimiento en las Administraciones Públicas que divide el proceso de desarrollo en las siguientes fases, a las que denomina también procesos: Planificación, Estudio de Viabilidad, Análisis, Diseño, Construcción, Implantación y Mantenimiento. Para más información ver 17

19 migración a software libre Experiencia de integral 3.1 Desarrollo del proyecto gvmétrica De una forma gradual, a lo largo de la vida del proyecto, se han ido abordando fases cada una de las cuales ha ampliado el alcance del mismo. En una primera fase, se crea un equipo de trabajo formado por miembros de la CIT y de la Universidad Politécnica de Valencia. Este equipo adapta los procesos de Análisis y Diseño de MÉTRICA dando lugar a la primera versión de gvmétrica. Los trabajos abordados durante esta fase son: dd Se seleccionan las actividades y las tareas de MÉTRICA Versión 3 que se consideran necesarias en la conselleria en los procesos de Análisis y de Diseño. dd Se define una interfaz entre el personal de Organización y el de Informática, que integra a todos los miembros del departamento en el proceso de desarrollo. Las tareas iniciales de la fase de análisis son competencia de Organización, quien realiza un traspaso de conocimiento sobre el proceso a desarrollar a la Sección de Informática. dd Se determinan las técnicas y estándares a aplicar. Se decide que sea el Análisis de Sucesos la principal técnica de análisis, tomando a UML como lenguaje de especificación. Se define una Guía de Estilo que será de aplicación para todas las aplicaciones de la CIT. dd Se documenta el proceso de gvmétrica. Para cada una de las tareas se especifican los productos de entrada y de salida, el perfil de los participantes en la tarea y las técnicas a aplicar en la elaboración de cada uno de los productos. dd Se confeccionan el conjunto de entregables o plantillas que soportan el contenido de los productos que fluyen en el proceso. dd Integración de la metodología con el entorno de trabajo co- laborativo definido para la CIT por el proyecto gvpontis. A grandes rasgos consiste en el uso de gforge para la gestión de los proyectos y de Plone como Gestor de Contenidos para la Publicación de la documentación de los mismos. A continuación se inicia una fase de pruebas para validar la metodología. Aquí se pone de manifiesto la imposibilidad de abordar los desarrollos haciendo uso exclusivamente de las plantillas definidas por gvmétrica ya que la gestión de la documentación (su edición y posterior actualización), en muchos casos, terminaba siendo más costosa que los propios análisis. Se puso de manifiesto también la densidad de las plantillas, había demasiada información a rellenar en cada caso y no siempre era necesario, de modo que se tomó la decisión de revisar su publicación para facilitar su aprendizaje. Surgió entonces la necesidad de iniciar una nueva fase en el proyecto, cuyo objetivo principal era el de facilitar la aplicación de la metodología. Para conseguirlo había que (1) dotar a la CIT de herramientas para poder aplicar la metodología de una forma más eficiente, (2) definir los requisitos mínimos que deben cumplir los análisis en la CIT para equilibrar el esfuerzo entre las fases y (3) mejorar la documentación del proceso para hacerla más intuitiva y que, de este modo, resulte más sencilla la aplicación de la metodología. Los trabajos que se realizaron durante esta fase fueron los que se detallan a continuación: dd Se establece UML como el estándar a emplear en la especi- ficación de los sistemas de información. dd Se decide dar un mayor peso a los modelos UML en detri- mento de las plantillas. dd Se determina qué elementos del lenguaje UML van a ser uti- lizados para modelar los sistemas de información en la CIT. dd Se especifican los perfiles de UML necesarios para adaptar los modelos UML a los sistemas de información de la CIT y se determina el subconjunto de Plantillas de gvmétrica que van a ser sustituidas por estos modelos. 18

20 gvmétrica y MOSKitt: definición de una metodología de desarrollo y su soporte 3 dd 4 Se selecciona PowerDesigner v.11 como herramienta de análisis, principalmente por ser una herramienta ya conocida en la CIT. Hasta el momento había sido muy utilizada por los analistas en el marco de la definición e implementación de Bases de Datos Relacionales a partir de modelos conceptuales basados en modelos Entidad-Relación. Aún siendo una solución privativa, se considera válida como solución temporal, de este modo se evita incluir un elemento nuevo más y se deja para más adelante el abordar este tema. dd Se define la estructura completa, aplicando los criterios es- tablecidos en gvmétrica, que debe poseer cualquier proyecto modelizado en PowerDesigner. dd Se implementan los perfiles UML antes mencionados con la herramienta y se proporcionan los mecanismos necesarios para completar los análisis, enlazando los modelos con las plantillas que no pueden ser reemplazadas. dd Por último, se definen informes orientados a los usuarios y a los programadores. Llegados a este punto del proyecto, se considera que, aunque hay puntos que completar y otros se pueden mejorar, la metodología está ya lo suficientemente madura como para ser aplicada en la Consellería y se dispone de herramientas para hacerlo. Se inicia, por tanto, una fase de monitorización para detectar fallos y, sobre todo, priorizar las posibles mejoras. Esta tarea es continua durante todo el proyecto, celebrando reuniones periódicas y realizando un seguimiento y apoyo directo a todos y cada uno de los implicados. Paralelamente, muchos de los proyectos iniciados en gvpontis también alcanzan su primera versión, como es el caso de gvhidra (implementación de la Guía de Estilo de la CIT en PHP) con lo que ya es posible el abordar la fase de integración de la Metodología con las arquitecturas de soporte sobre las que deban construirse los desarrollos de la CIT. En este sentido: 4 Soporta UML 1.5. dd Se amplia el catálogo de modelos UML para incluir un perfil UML que facilite la definición de las Interfaces de Usuario, tomando como base los Patrones definidos por la Guía de Estilo e implementados por gvhidra. dd Se define un nuevo perfil UML para aplicarlo en los desarro- llos, cuyo objetivo es el de la automatización de los procedimientos administrativos sobre un motor de Workflow. Siguiendo el enfoque defendido en la estrategia de DSDM 5 (Desarrollo Dirigido por Modelos), y más concretamente MDA 6 (Model Driven Architecture), se intenta mantener a los modelos a un nivel de abstracción que permita describir los sistemas de información de la forma más independiente posible de la plataforma sobre la que se van a construir. Desgraciadamente esto no siempre es posible, debido, principalmente, a que no se dispone de las guías necesarias que recopilen todas las reglas que deben aplicar los programadores para transformar en código toda la información que reciben en los modelos. Esto último obliga a los analistas a incluir esta información de implemetación en los diagramas (los modelos) para hacérsela llegar a los programadores. Y es, en este punto, en la generación de las guías de implementación, en la que se encuentra actualmente el proyecto. Paralelamente, en la CIT se vuelve a revisar la herramienta escogida para aplicar la metodología por varias razones: dd El uso de PowerDesigner, una herramienta privativa que sólo funciona sobre Windows, plantea problemas de incoherencia con la estrategia general de gvpontis. dd La dificultad de abordar todo el proceso propuesto por gv- MÉTRICA, haciendo uso exclusivamente de modelos UML. UML y los perfiles definidos resultan insuficientes para es- 5 MDD es una aproximación al desarrollo de software basado en el modelado de sistemas software y su generación a partir de los modelos. 6 MDA es un estándar de OMG (Object Management Group) que promueve el MDD y agrupa varios lenguajes que pueden usarse para seguir este enfoque (UML es uno de ellos). MDA promueve explícitamente elevar el nivel de abstracción a la hora de describir los sistemas de información. 19