Gvpontis Cast

69
Experiencia de integral migración a software libre en la Conselleria de Infraestructuras y Transporte Proyecto 2004-2008

Transcript of Gvpontis Cast

Page 1: Gvpontis Cast

Experiencia deintegralmigración

a software libreen la Conselleria de Infraestructuras y Transporte

Proyecto

2004-2008

Page 2: Gvpontis Cast

Experiencia deintegralmigración

a software libreen la Conselleria de Infraestructuras y Transporte

Page 3: Gvpontis Cast

Índice Parte 1 Desarrollos 7 Corporativos y Web

Capítulo 1 Una visión general 8

Capítulo 2 gvDADES: experiencias con Sistemas de Gestión de Bases de Datos 11

Capítulo 3 gvMÉTRICA y MOSKitt: definición de una metodología de desarrollo y su soporte 17

Capítulo 4 gvHIDRA: desarrollo de un framework para PHP 22

Capítulo 5 Implementación de Sistemas de Control de Versiones: CVS y Subversion 24

Capítulo 6 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

Coordinado y editado por

Depósito LegalM-54647-2008

Traducido al inglés porCrown Communication, S.L.C/. Archiduque Carlos, nº65, 146018 - Valencia

Diseño y maquetaciónEdit Lin Editorial, S,LAvda. de Portugal, 85-local28011 - Madrid

LicenciaEsta 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 http://creativecommons.org/licenses/by-sa/2.5/es/

Page 4: Gvpontis Cast

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 gvSIG: descripción y justificación de la situación inicial 49

Capítulo 16 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

Page 5: Gvpontis Cast

4

gvPONTIS, un caso de éxito

el Servicio Central, tres Servicios Territoriales y algunos Centros Comarcales.

Ante esta situación propusimos a la Dirección General de Moder-nización iniciar un proyecto de migración integral de todas nues-tras 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éc-nica 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 apli-caciones informáticas en las que utilizaban los nuevos conceptos que se aplicaban en el desarrollo informático. Tanto en los infor-mes como en las aplicaciones no aparecía ningún aviso, impedi-mento, 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:www.gvpontis.gva.es.

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 vere-mos mejor en las páginas siguientes de la memoria.

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 acome-ter, indicar que el número de trabajadores que emplean los diversos sistemas de información ronda el millar, de los cuales unos seis-cientos se ocupan de la administración general y casi cuatrocien-tos de la administración especial, fundamentalmente en ingenierías medias y superiores y arquitectura. Todos ellos distribuidos entre

PR

ÓLO

GO

Page 6: Gvpontis Cast

5

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ándezJefe del Servicio de Organización e Informática

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:

El proyecto no se financiará con recursos nuevos. Sólo se dutilizarán los recursos ya asignados al Servicio de Organiza-ción e Informática.

Debe minimizarse la repercusión del proyecto en el trabajo ddiario 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.

Page 7: Gvpontis Cast

Parte 1

Page 8: Gvpontis Cast

Desarrollos Corporativos y Web

7

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.

Page 9: Gvpontis Cast

8

Oracle Developer, lenguaje en el que fueron programadas inicialmen-te. Gradualmente se convertirán a los lenguajes PHP o Java depen-diendo 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 es-fuerzos de investigación y puesta en práctica realizados en esta ma-teria. La conselleria contaba con aplicaciones departamentales desa-rrolladas 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 conjuntamen-te con PostgreSQL o MySQL.

Respecto a los desarrollos corporativos, se decidió mantener Oracle en las aplicaciones en producción y realizar los nuevos desarrollos in-dependientes de la Base de Datos y que al menos tuviesen garantiza-do su funcionamiento en PostgreSQL. MySQL, por su sencillez, tam-bién sería empleado para soportar los portales web de la conselleria.

La existencia de numerosos desarrollos existentes, así como la ne-cesaria 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ó mi-grar de Oracle 8i a Oracle 10gR2.

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 (conte-nidas 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 simul-tánea de cambiar la arquitectura de desarrollo cliente/servidor, exis-tente en las fecha de inicio del proyecto, por una arquitectura de tres capas (posteriormente múltiples capas). Si este cambio de paradig-ma 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 perso-nal de desarrollo y logrando una definición más clara de las funciona-lidades de nuestros sistemas de información.

En el punto de partida del proyecto de migración, las dos herramien-tas de trabajo utilizadas para el desarrollo de aplicaciones en el en-torno 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

Una visión general

CA

PÍTU

LO 1

Page 10: Gvpontis Cast

Una visión general

9

1

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 CASE1 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 desa-rrollar 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 pro-veerse de un framework2. Surge con ello gvHIDRA, otro subproyec-to 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 Estilo3 de la conselleria.

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 inicial-mente 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 au-mentar 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 in-terpretado 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 desa-rrollo de aplicaciones.

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 herra-mienta 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 en-cuentran óptimamente resueltos. Entre estos, que son la base de nuestras principales líneas de actuación, se encuentran la búsque-da 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 contri-buyeran 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 de-bido 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:

Generar una sistemática de trabajo con tareas claramente ddefinidas 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.

Homogenizar la documentación de los productos de salida dque cada una de las tareas transmitía a la siguiente con ob-jeto 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 de-sarrollo orientado a objetos. Se inicia pues el proyecto gvMÉTRICA

gvCASE, un subproyecto integrado en el proyecto gvPONTIS que tiene

como objetivo desarrollar MOSKitt, una herramienta CASE libre desarrollada

sobre la plataforma Eclipse

Page 11: Gvpontis Cast

10

Experiencia deintegral

migracióna software libre

Por último, el portal web y la intranet también han sufrido su corres-pondiente migración. Se ha procedido a realizar un rediseño y rees-tructuració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 aspec-tos 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 pro-yecto gvPONTIS, son las que se detallan a continuación:

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 es-tán programando, así como comparar cambios que se hayan podido realizar en ellos. Para ello se adoptó inicialmente CVS. Actualmen-te, estamos implantando Subversion por las ventajas que presenta frente a CVS, al incorporar un control mediante permisos para acce-der a los proyectos y mejorar el versionado de los archivos.

Para facilitar las labores de programación de aplicaciones se re-quería proveerse de un Entorno de Desarrollo Integrado. Eclipse se constituía como el IDE4 de código abierto más maduro en el mo-mento de la toma de decisión. Tiene, entre otras ventajas, el contar con una gran comunidad de usuarios así como, mediante el empleo de plugins5, permitir programar con varios lenguajes y ampliarle fun-cionalidades. 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 com-pilador, 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 mo-dular, de manera que se puedan añadir nuevas funcionalidades sin afectar a las ya existentes ni complicar el desarrollo del programa principal.

A continuación, en cada uno de los siguientes capítulos, se amplían los detalles de cada una de las actuaciones acometidas.

Actuaciones de ámbito general: >

gvDADES. Experiencias con Sistemas de Gestión dde Bases de Datos.

gvMÉTRICA y MOSKitt. Definición de una dmetodología de desarrollo y su soporte.

gvHIDRA. Desarrollo de un framework para PHP. d

Implantación de Sistemas de Control de Versiones. dCVS y Subversión.

Implantación de una herramienta de generación de dinformes.

Migración del portal web e Intranet. d

Como principales actuaciones específicas y >a modo de ejemplos ilustrativos encontramos:

Migración de MASTIN. Workflow para la tramitación dy seguimiento de expedientes.

gvADOC. Sistema de gestión documental. d

Page 12: Gvpontis Cast

111111

Cuando se inició el proyecto gvPONTIS de migra-ció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:

Oracle d , para aplicaciones corporativas como contenedor de los datos. Las aplicaciones que usan estos datos se desarro-llaban con herramientas como PowerBuilder y Developer.

Microsoft Access d , 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 con-sistían en encontrar:

1. Alternativas para el uso de Microsoft Access como base de datos departamental.

gvDADES: experiencias con Sistemas de Gestión de Bases de Datos

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 servi-dores, si necesitaban compartir datos.

2. Alternativas para el uso de Microsoft Access como herramien-ta 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 aplicacio-nes 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 des-de aplicaciones como Word, Excel o desarrollos propios a las bases de datos.

CA

PÍTU

LO 2

Page 13: Gvpontis Cast

12

Experiencia deintegral

migracióna software libre

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 preci-saron, 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:

Convivencia de Oracle con Linux. Debíamos conseguir que del 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.

Elección de otro SGBD alternativo con las siguientes carac- dterí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 datos -

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 estudio1 en el que se compararon las tres principales bases de datos que habían entonces: PostgreSQL, MySQL e Inter-base. 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:

Interbase 6.0. d Era estable, rápida, escalable y con las sufi-cientes funcionalidades, pero encontramos poca documenta-ción y pensamos que Borland debía apoyar más este proyecto para que tuviera éxito en la comunidad de Software Libre.

MySQL 4. d Vimos que era sencilla y rápida, la más usada, ampliamente documentada y soportada, pero no soportaba muchas funcionalidades necesarios (transacciones ACID, in-tegridad referencial, no soporta código almacenado, triggers, etc.).

PostgreSQL 7. d Nos pareció la más completa, apoyada por la comunidad de Software Libre, permitía transacciones y con-currencia que cumplen las reglas ACID, integridad referen-cial, 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,

1 Ver “Comparativa de distintos SGBD bajo Linux”.

Page 14: Gvpontis Cast

gvDADES: experiencias con Sistemas de Gestión de Bases de Datos

13

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 familiari-zarnos con las características de esta base de datos, así como probar el funcionamiento. Tomamos la decisión de usar PostgreSQL para:

todos los nuevos desarrollos, usándolo como nuestro nuevo dservidor de bases de datos OLTP

la base de datos del nuevo Archivo Documental que íbamos da desarrollar (ver gvADOC, Capítulo 9)

la base de datos GeoEspacial usando PostGIS (necesario dpara gvSIG)

más adelante, hemos usado PostgreSQL como repositorio dpara la herramienta gForge.

Con las líneas anteriores claras, empezamos una fase de adapta-ción en la que:

tuvimos que tener en cuenta las incompatibilidades/com- dpatibilidades 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 coman-dos que en un sistema funcionaban de modo distinto al otro

establecimos la forma en que las aplicaciones debían tra- dbajar 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.)

desarrollamos procedimientos para el mantenimiento de la dbase de datos (arranque, parada, copias de seguridad, res-paldo, 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.

2.2.1 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 conexio-nes, 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’, enla-ces 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

Page 15: Gvpontis Cast

14

Experiencia deintegral

migracióna software libre

volcados completos de datos de una base de datos a otra. Esta so-lución no resultaba satisfactoria por los siguientes motivos:

Eran volcados completos, es decir, se borraban los datos de dla 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.

Al borrarse datos de las tablas, no se podían definir claves aje- dnas a las tablas, pues impedirían el borrado de los datos.

Al ser volcados completos, se ejecutaban una vez al día, con dlo que no disponíamos de la replicación instantánea, nece-saria o conveniente en algunos casos.

En la actualidad, hemos desarrollado una herramienta para mante-ner la replicación a nivel de tabla, tanto en modo refrescos comple-tos 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 re-plicaciones. Este sistema lo tenemos ya en producción y lo usamos para aquellos casos que no podemos resolver con WebServices.

2.2.2 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 8.1.7 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 servi-dores de desarrollo en Oracle 10g sobre Red Hat ES 4 y estamos esperando pasar en breve a los servidores de producción.

2.2.3 Internacionalización

En las sucesivas migraciones de versiones de bases de datos, he-mos llegado a la versión 8.2.3 de PostgreSQL, y durante estas mi-graciones hemos aprovechado para abordar el tema de la interna-

cionalización de los conjuntos de caracteres, de modo que hemos pasado de soportar sólo el conjunto de caracteres ISO8859-1 (La-tin1) a soportar UTF8.

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

2.2.5 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 Mana-ger, 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:

Funcionar sobre Linux d

Conectar a Oracle, PostgreSQL o MySQL (según la herra- dmienta)

Disponer de funcionalidades para creación de tablas, vistas dy código

Disponer de funcionalidades de administración y monitori- dzación

Ser Software Libre o gratuitas. d

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.

Page 16: Gvpontis Cast

gvDADES: experiencias con Sistemas de Gestión de Bases de Datos

15

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

SQLDeveloper OracleMySQL

Propia de Oracle, certificada para »conectar a versiones 9.x y 10.x.

Requiere JDK. »

Funciona en Linux y Windows. »

Útil para programadores. »

Squirrel OracleMySQLPostgreSQL

GPL, se pueden hacer plugins »para incorporar funcionalidades.

hecha en Java, funciona en Linux »y Windows.

se conecta por JDBC a cualquier »SGBD.

isqlplus Oracle Cliente web de SQL*Plus para »conectar a Oracle.

2.2.6 Formación

Al inicio del proyecto de migración, se organizó un curso en la Univer-sitat Politècnica de València sobre Administración de PostgreSQL. A partir de aquí, hemos avanzado nosotros mismos, consultando la docu-mentació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.

2.2.7 Dificultades y Problemas

En este proceso nos hemos encontrado con problemas. Algunos no los hemos resuelto todavía:

Falta de herramientas para administrar y monitorizar Post- dgreSQL, al menos que sean GPL.

Falta de empresas que den un soporte cualificado para Post- dgreSQL. Este problema está empezando a solucionarse.

Gestión de la seguridad y control de accesos, porque Post- dgreSQL 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.

Pérdida de integración de productos. Frente a la oferta de dOracle que tiene infinidad de productos complementarios, PostgreSQL sólo ofrece la base de datos.

Evidentemente, estas dificultades ya las imaginábamos cuando em-pezamos con el proyecto y las asumimos.

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

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.

Page 17: Gvpontis Cast

16

El cambio se ha hecho con mucho respeto, pero sin miedo. Hay que tener claro que cambiar a Software Libre es un cambio de mentali-dad grande. No se puede pretender obtener las mismas prestacio-nes 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 compensa-das 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

Mejora y posible migración del sistema de replicación de dPHP a Java.

Creación con PostgreSQL de un sistema “Data Warehouse” dapoyándose en ‘Mondrian’ y ‘JasperETL’.

Integración de las bases de datos alfanuméricas con las dgeoespaciales de gvSIG.

Estudiar la viabilidad de uso de MySQL5, pues está evolu- dcionando rápidamente, más ahora que está siendo impulsado por SUN.

Poder implementar un sistema que nos permita la monitori- dzación de las bases de datos, usando productos libres como ‘Cacti’ o ‘Munim’.

Desarrollar un módulo de seguridad para poder incorporarlo da las aplicaciones, que gestione los accesos de los usuarios, privilegios y audite los accesos, de modo que sea indepen-diente de la base de datos.

Para el caso del Microsoft Access, se va a usar como alter- dnativa libre OpenBase2.

Selección de empresas que estén dispuestas y preparadas da 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

Si se usa Access o similares como motor de base de datos den pequeñas bases de datos, podemos sustituirlo por MyS-QL o PostgreSQL, pues resultan de fácil instalación y coste cero en licencias.

Si se necesitan crear muchas bases de datos departamenta- dles, 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.

La implantación en una gran organización de estos sistemas, dcomo es nuestro caso, implica la convivencia de varios siste-mas de bases de datos heterogéneos que deben relacionar-se 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.

Perder el miedo a las novedades, estos gestores de bases de ddatos tienen la mayoría de las funcionalidades que se necesi-tan 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 tec-nológicas para que vean que existen oportunidades de negocio con este software desarrollando mejoras o prestando soporte.

Preguntarnos por las prestaciones que le vamos a solicitar da 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.

Page 18: Gvpontis Cast

17

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 CIT1”. Básicamente las dos líneas de trabajo principales a realizar en este ámbito eran las siguientes:

Definición de una Metodología de Desarrollo de Software dadaptada a la CIT.

Definición e Implantación de la arquitectura de soporte a los ddesarrollos planteados.

El alcance de estos trabajos era muy amplio, para abordarlos fueron creados varios proyectos integrados dentro del propio gvPONTIS. Es-tos 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 al-canzadas 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 “Desa-rrollos Web” con herramientas Linux del documento de conclusiones.

Se consensuaron los siguientes criterios2 antes de abordar los trabajos:

La metodología a adoptar deberá ser una adaptación de MÉ- dTRICA Versión 33.

Aunque la metodología propuesta deberá cubrir todo el pro- dceso de desarrollo, se prioriza la adaptación de las fases de análisis y diseño.

Se deberán potenciar las técnicas de orientación a objetos den 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 in-formación similares, que automatizan procedimientos administra-tivos 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 documen-to de conclusiones elaborado por el Grupo Linux.

3 MÉTRICA Versión 3 es una metodología desarrollada por el MAP (Ministerio de Admi-nistraciones 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 pro-cesos: Planificación, Estudio de Viabilidad, Análisis, Diseño, Construcción, Implantación y Mantenimiento. Para más información ver www.csi.map.es/csi/metrica3/index.html

CA

PÍTU

LO 3

gvMÉTRICA y MOSKitt: definición de una metodología de desarrollo y su soporte

Page 19: Gvpontis Cast

18

Experiencia deintegral

migracióna software libre

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:

Se establece UML como el estándar a emplear en la especi- dficación de los sistemas de información.

Se decide dar un mayor peso a los modelos UML en detri- dmento de las plantillas.

Se determina qué elementos del lenguaje UML van a ser uti- dlizados para modelar los sistemas de información en la CIT.

Se especifican los perfiles de UML necesarios para adaptar dlos 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.

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:

Se seleccionan las actividades y las tareas de MÉTRICA dVersión 3 que se consideran necesarias en la conselleria en los procesos de Análisis y de Diseño.

Se define una interfaz entre el personal de Organización y el dde Informática, que integra a todos los miembros del depar-tamento 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 de-sarrollar a la Sección de Informática.

Se determinan las técnicas y estándares a aplicar. Se decide dque 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.

Se documenta el proceso de gvMÉTRICA. Para cada una dde 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.

Se confeccionan el conjunto de entregables o plantillas que dsoportan el contenido de los productos que fluyen en el pro-ceso.

Integración de la metodología con el entorno de trabajo co- dlaborativo definido para la CIT por el proyecto gvPONTIS. A

Page 20: Gvpontis Cast

gvMÉTRICA y MOSKitt: definición de una metodología de desarrollo y su soporte

19

3

Se amplia el catálogo de modelos UML para incluir un perfil dUML 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.

Se define un nuevo perfil UML para aplicarlo en los desarro- dllos, cuyo objetivo es el de la automatización de los procedi-mientos administrativos sobre un motor de Workflow.

Siguiendo el enfoque defendido en la estrategia de DSDM5 (Desarrollo Dirigido por Modelos), y más concretamente MDA6 (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:

El uso de PowerDesigner, una herramienta privativa que sólo dfunciona sobre Windows, plantea problemas de incoheren-cia con la estrategia general de gvPONTIS.

La dificultad de abordar todo el proceso propuesto por gv- dMÉ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.

Se selecciona PowerDesigner v.11 d 4 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 concep-tuales 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.

Se define la estructura completa, aplicando los criterios es- dtablecidos en gvMÉTRICA, que debe poseer cualquier pro-yecto modelizado en PowerDesigner.

Se implementan los perfiles UML antes mencionados con la dherramienta y se proporcionan los mecanismos necesarios para completar los análisis, enlazando los modelos con las plantillas que no pueden ser reemplazadas.

Por último, se definen informes orientados a los usuarios y a dlos 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.

Page 21: Gvpontis Cast

20

Experiencia deintegral

migracióna software libre

Un primer estudio pone de manifiesto la inexistencia de una herramienta CASE de Software Libre de este tipo que cubriese ‘mínimamente’ los requerimientos propuestos por la CIT. Como parte del EVS se establece un proyecto de colaboración entre el grupo OO-Method del DSIC (Departamento de Sistemas Informáticos y Computación) de la U.P.V. (Universidad Politécnica de Valencia) y la CIT para elaborar un estudio de soluciones candidatas al desarrollo de una herramienta CASE libre que proporcione soporte a la metodología gvMÉTRICA.

De este estudio se desprende, como primera conclusión, que es posible el uso de una plataforma existente para el desarrollo del proyecto, en lugar de empezar desde cero o de adaptar una herramienta CASE libre.

Esta plataforma es Eclipse, incluyendo los plug-ins propuestos por el proyecto EMP (el Eclipse Modeling Project unifica los plug-ins relacionados con el modelado que están desarrollados directamente dentro del proyecto Eclipse).

Como documento final de la fase de EVS se obtiene el Pliego de Condiciones Técnicas del proyecto gvCASE. Esto da lugar, en mayo de 2007, al inicio del proyecto gvCASe cuyo objetivo es la construcción de MOSKitt, una herramienta CASE libre, basada en Eclipse, para dar soporte a la metodología gvMÉTRICA. El proyecto gvCASE queda también integrado en gvPONTIS.

Este objetivo inicial del proyecto ha evolucionado para convertirlo en la primera Plataforma de Modelado en Software Libre para la construcción de herramientas CASE, con soporte al proceso de desarrollo establecido para distintas organizaciones. Es decir, dota de versatilidad a la herramienta para poder dar soporte a la aplicación de metodologías, orientadas a diferentes tipos de sistemas de

pecificar las Interfaces de Usuario de los sistemas; por otra parte, algunas de las plantillas siguen teniéndose que definir sobre documentos OpenOffice.

Se construye una base teórica para documentar los distintos dmodelos UML que se consideran necesarios para completar el análisis de un Sistema de Información con PowerDesig-ner. Estos modelos están relacionados entre sí de forma que entre todos completan la información correspondiente a los distintos conceptos planteados por la metodología: hay un modelo para especificar las funcionalidades del sistema, un modelo para definir la entidades necesarias para satisfacer dicha funcionalidad, un modelo que determina la interfaz grá-fica a través de la cual el usuario puede acceder a dicha funcionalidad y cómo afecta esto a las distintas entidades del sistema etc. Sin embargo, estas relaciones entre los dis-tintos modelos no puede ser definidas en PowerDesigner y, por tanto, no pueden construirse unos modelos a partir de los otros, ni por supuesto mantenerlos sincronizados entre sí de forma automática. Los principales problemas que plantea este punto son que, además de suponer un sobrecoste para los analistas (editores de los modelos), impide garantizar la consistencia y la corrección de los análisis realizados ha-ciendo uso de la metodología.

En este momento, la metodología es ya conocida por la ma- dyoría del personal del Servicio. Por ello, plantear un cambio de una herramienta CASE a otra distinta ya resulta ‘asumi-ble’.

3.2 Concepción de MOSKitt

Todo esto lleva a la CIT a realizar varios Estudios de Viabilidad para determinar a qué herramienta (de Software Libre preferentemente, o al menos que funcione sobre una distribución de Linux) debe migrar. Durante esta fase de estudio de viablidad (EVS) se analizan las herramientas CASE de Software Libre desarrolladas hasta ese momento a partir de una lista de requisitos elaborada por la CIT.

MOSKitt permitirá dotar a la CIT, y en general a las organizaciones, de herramientas que permitan aplicar

Ingeniería del Software en sus procesos de desarrollo

Page 22: Gvpontis Cast

gvMÉTRICA y MOSKitt: definición de una metodología de desarrollo y su soporte

21

3

3.3 Próximas líneas de actuación

Completar la adaptación de gvMÉTRICA para incluir todos los dprocesos e interfaces. En esta línea se ha concluido ya la adap-tación de la Interfaz de Gestión de Proyecto, el próximo hito con-siste en la presentación a los Jefes de Proyecto de la CIT para su posterior aplicación con el consiguiente tutelaje por parte del grupo de gvMÉTRICA. Se ha iniciado ya la revisión del Plan de Pruebas.

Preparar la Migración del proceso de gvMÉTRICA de Power- dDesigner a MOSKitt.

Dotar a la herramienta MOSKitt de la capacidad de producir au- dtomáticamente sistemas software completamente funcionales, que cumplan las necesidades de la CIT a partir de modelos.

Siguiendo el esquema de los proyectos en Software Libre, dMOSKitt también pretende construir, divulgar y dar soporte a una comunidad que interactúe y colabore para ampliar el al-cance del proyecto, y mejorar los resultados obtenidos para permitir que MOSKitt se adapte a la evolución natural de las necesidades de las organizaciones en el ámbito de la Ingenie-ría del Software.

Adaptación de la metodología y de MOSKitt a otro tipo de apli- dcaciones que no sigan un patrón clásico de las aplicaciones de gestión e incluso a cualquier otro tipo de aplicaciones (siste-mas de tiempo real, sistemas empotrados, etc.).

información. Se trata de un proyecto con un fuerte componente Investigador e Innovador. MOSKitt permitirá dotar a la CIT, y en general a las organizaciones, de herramientas que permitan aplicar Ingeniería del Software en sus procesos de desarrollo, siguiendo el paradigma del Desarrollo de Software Dirigido por Modelos (DSDM), una propuesta en la que se le atribuye a los modelos el papel principal de todo el proceso, frente a las propuestas tradicionales basadas en lenguajes de programación y plataformas de objetos y componentes software:

Seleccionando aquellas técnicas (UML2, BPMN etc.), que dmejor se adapten al tipo de sistemas que se deseen cons-truir en cada organización.

Definiendo y dando soporte a los procesos de desarrollo de soft- dware para aplicar el método de desarrollo que mejor se ajuste a su organización y a los sistemas de información a desarrollar.

Para más información de los proyectos ver www.moskitt.org y www.gvpontis.gva.es/index.php?id=gvmetrica.

Page 23: Gvpontis Cast

22

La idea básica del proyecto era realizar un framework de trabajo, basado en el modelo-vista-controlador (MVC)

e implementado en PHP, para crear aplicaciones de gestión en entornos web y que permitiese integrar la guía de estilo de la CIT.

El entorno gvHIDRA tenía una serie de objetivos iniciales:

1. La herramienta debía facilitar la migración de aplicacio-nes de pequeña y mediana envergadura desarrolladas en cliente-servidor con MS-Access y/o PowerBuilder.

2. Debía alejar (en la medida de lo posible) a los programa-dores de los entresijos del HTML y el Javascript, de tal manera que un programador de MS-Access y/o Power-Builder, pudiese comenzar a desarrollar aplicaciones sim-plemente con conocimientos básicos de PHP, imitando el modelo de desarrollo que se usaba hasta el momento con PowerBuilder y MS-Acces donde el papel destacado lo jugaba el SQL (aplicaciones totalmente orientadas a expedientes).

Para su realización se han utilizado multitud de herramientas de carácter GPL: Eclipse, Apache, CVS, etc. y siguiendo el espíritu open source, se han incorporado al proyecto otras como: Phrame, Smarty, PEAR, etc.

4.1 evolución de gvHIDRA

Lograr alcanzar el objetivo inicial fue trabajo duro. El proyecto partía de un desarrollo externo con claras deficiencias, del cual apenas pudo aprovecharse nada. Debimos aprender a “buscar” antes de “hacer”, dado que en el mundo open source siempre hay alguien que ha intentado algo parecido, y del cual puedes aprovechar como mínimo su experiencia. Esto nos ha enseñado a contemplar el “es-tado del arte” antes de acometer nuevas tareas.

Cuando conseguimos alcanzar los objetivos iniciales, pudimos juz-gar las ventajas e inconvenientes de los mismos. Algunos de los factores que incorporaron a gvHIDRA como ventaja, aportaron también recortes en la flexibilidad de la herramienta, por ejemplo:

Aislar a los programadores de las dificultades del HTML y dJS, implica que NO puedan utilizar los mismos en casos no contemplados por el framework. Esto ha obligado a que el equipo gvHIDRA esté continuamente incorporando la nue-va funcionalidad al framework. Tal vez hayamos sido “dema-siado” estrictos. Algo que haga “menos cosas” supone más esfuerzo para un programador, pero más posibilidades tam-bién. Debemos buscar el compromiso entre flexibilidad (es-calabilidad, adaptación...) y la facilidad de uso (utilidades, paradigmas de patrones...) por parte de los programado-res. Actualmente los componentes del equipo de desarrollo

gvHIDRA: desarrollo de un framework para PHP

CA

PÍTU

LO 4

Page 24: Gvpontis Cast

gvHIDRA: desarrollo de un framework para PHP

23

4

soletos. Se apuntaba hacia modelos de arquitectura soft-ware diversos: análisis orientado a servicios, orquestación de servicios y un amplio etcétera, que tiene como base la orientación a objetos en todo el ciclo de vida del software. En esta línea existen proyectos concretos como gvMÉTRI-CA y MOSKitt, con los que hemos de coordinarnos nece-sariamente.

La “migración” de una aplicación existente, no es simple- dmente analizar cómo funciona y ponerle encima una nueva interfaz a través del navegador. Implica siempre una revisión de la misma con el usuario, que siempre “aprovecha” para añadir funcionalidad. En la mayoría de los casos dichas re-visiones no han ido acompañadas de ningún análisis (o por lo menos dicho análisis ha sido informal y no ha quedado documentación sobre el mismo). Este escollo también se ha abordado desde el proyecto gvMÉTRICA.

La hoja de ruta de gvHIDRA siempre contempla como objetivo facilitar la labor a los programadores e incorporar funcionalidades al framework. Dicha evolución continua se basa en las nuevas necesidades internas que surgen de las distintas aplicaciones, tanto en las de nuevo desarrollo como en el mantenimiento de las existentes.

Otra fuente de mejoras se obtiene por la vigilancia tecnológica del exterior para detectar nuevas tendencias y alternativas.

del framework emplean tiempo, tanto en su mantenimiento y desarrollo, como en la construcción de aplicaciones sobre el mismo. Este doble perfil del equipo permite ver de cerca los problemas del framework, pero dilata en el tiempo el aporte de mejoras y soluciones.

Implantar la guía de estilo tuvo una doble problemática. El daspecto de la guía de estilo limitaba la audiencia del fra-mework al personal de la CIT, perdiendo el potencial ex-terno que todo proyecto, basado en Software Libre debe tener. Por otro lado, la guía de estilo sólo eran “colores y aspecto” sobre el papel, en ningún sitio se explicaba el CÓMO debía funcionar, ni su interacción con el usuario. Este escollo se va resolviendo en colaboración con el equi-po de gvMÉTRICA.

El SQL y el paradigma de análisis y diseño estructurado ddel que partían PowerBuilder y MS-Access, resultaban ob-

Debimos aprender a “buscar” antes de “hacer”, dado que en el mundo open source siempre hay alguien que ha intentado algo parecido, y del cual puedes aprovechar como mínimo su experiencia. Esto nos ha enseñado a contemplar el “estado del arte” antes de acometer nuevas tareas

Page 25: Gvpontis Cast

24

Una de las funcionalidades más importantes al contar con varias programaciones que concurren en el desarrollo

de una aplicación es el tener 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.

En un primer momento se decidió CVS, por su uso maduro en de-trimento de Subversion, como herramienta de control de versiones. Ya era suficiente adelanto con que esta herramienta sustituyera al hasta entonces utilizado procedimiento de copia en el servidor, para compartir los ficheros de una aplicación en desarrollo y rea-lizar el control manual de la última versión. El único problema a afrontar era la necesidad de formación de los desarrolladores en el uso de la nueva herramienta.

En un determinado momento surgió la necesidad de incorporar, para algunas aplicaciones en desarrollo, un control de usuarios más sofisticado o más cómodo que el usado por el CVS (nece-sitábamos migrar todo el repositorio a una versión distinta de la herramienta). Se pensó en la herramienta Subversion, que en ese momento ya era suficientemente madura para llevar a cabo ese control de los accesos a las aplicaciones.

Dado que no todas las aplicaciones precisaban de ese control de usuarios, y las que lo requerían eran de nuevo desarrollo, se deci-

dió no migrar todo el repositorio de proyectos (como inicialmente estaba previsto) manteniendo en el repositorio CVS las aplicacio-nes que no precisaban dicho control de acceso de los usuarios, y ubicando en el repositorio de Subversion aquellas que sí lo re-quiriesen.

En esta ocasión las necesidades de formación fueron menores, puesto que la práctica en el uso de Subversion es muy similar a la del uso de CVS.

Aunque las herramientas tienen operativas distintas, las tareas que realiza el usuario resultan muy similares en el uso día a día de cualquiera de las dos.

Actualmente seguimos considerando que no compensa la migra-ción de todas las aplicaciones a Subversion, mientras no surjan otros condicionantes que lo contradigan. Por tanto, se puede decir que la situación actual se mantendrá en el futuro inmediato.

Por nuestra experiencia en el uso de ambas herramientas, reco-mendamos encarecidamente el uso de cualquiera de estas dos herramientas de control de versiones (CVS y Subversion son las más difundidas en el mundo del Software Libre) para compartir código entre programadores, sobre todo si se encuentran disper-sos geográficamente. Una vez vencida la curva de aprendizaje, compensa con creces los beneficios que se obtienen con su uso.

CA

PÍTU

LO 5

Implantación de Sistemas de Control de Versiones: CVS y Subversion

Page 26: Gvpontis Cast

25

iReport (que incluye el motor de informes JasperReport) es una herramienta de diseño

de informes que sustituye a las herramientas de pago que se incluyen en los entornos de programación de PowerBuilder y Oracle Developer. El estudio de viabilidad que se hizo antes de adoptar esta herramienta, puso de manifiesto sus ventajas e inconvenientes. De entre las ventajas que aporta el empleo de esta herramienta destacan las siguientes:

Multiplataforma. d Por ser una herramienta escrita en Java.

Disponibilidad de un entorno de creación de informes. d Muy similar a las herramientas profesionales de pago.

Funcionalidad. d La herramienta no tiene ninguna carencia cuando se la compara con un producto de pago. Algunas funcionalidades remarcables: dispone de un gran control de tablas cruzadas, subinformes, un gran abanico de gráficos y la posibilidad de generar etiquetas o códigos de barras, así como muchas posibilidades de parametrización y personali-zación de los informes y también de modificación y creación de informes en tiempo de ejecución.

Madurez del proyecto. d Este proyecto tiene varios años de experiencia acumulada y ya lleva muchas versiones, por lo que tiene un nivel muy bajo de errores y resulta fácil

encontrar documentación de ejemplos y experiencias de otras organizaciones. También existen empresas españolas y valencianas que realizan formación sobre la herramienta o bien que trabajan habitualmente con ella para, por tanto, poder aprovechar su conocimiento.

Adaptabilidad. d El entorno gráfico (que es el producto iRe-port) y la librería que realiza realmente el trabajo (que es el producto JasperReports) son proyectos completamente separados, por lo que es posible optar por otros entornos gráficos lo que asegura, sobre todo, que la interfaz de pro-gramación que permite crear informes en tiempo de eje-cución es una librería completa que tiene el 100% de las posibilidades que ofrece iReport, ya que al fin y al cabo, iReport no genera informes por sí mismo sino que delega todo el trabajo en la librería de JasperReports.

Formatos de exportación. d Una de las principales venta-jas de JasperReports es la cantidad de formatos a los que puede exportar sus informes. Entre estos figuran no sólo los formatos open source sino también privativos.

Los principales inconvenientes se localizan en:

Conversiones. d No es capaz de leer un fichero con el diseño de un informe realizado con otra herramienta de generación

CA

PÍTU

LO 6

Implantación de una herramienta de generación de informes

Page 27: Gvpontis Cast

26

Experiencia deintegral

migracióna software libre

Para cuando se planifique la migración de los informes creados con Oracle Developer, JasperReports incorpora otra herramienta open source externa que permite ejecutar código PL/SQL de Oracle como si fuera código SQL estándar, lo que facilita la reutilización de todo el código PL/SQL que contengan los informes de Oracle Developer, si bien esta herramienta no ha sido todavía probada porque todavía no hemos necesitado migrar ninguno de estos informes.

JasperReports ha tenido una introducción rápida entre nuestros desarrolladores al constatar la gran cantidad de herramientas com-plementarias disponibles para JasperReports como JasperServer, JaperAnalysis y JasperETL, que incorporan funcionalidades en los diseños de informes que no existían en las herramientas presen-tes hasta la fecha en la conselleria.

Asimismo, otra de las cosas que más ha impulsado la introducción de JasperReports ha sido el buen soporte de gráficos que presen-ta, el cual está resultando muy del agrado de los usuarios finales, que ya demandan que se les entregue la mayor cantidad posible de información gráfica.

6.2 Próximas líneas de actuación

La herramienta JasperReports ofrece otras soluciones muy interesantes que hemos probado y que tienen mucha probabilidad de implantarse:

JasperServer. d Herramienta donde se pueden publicar infor-mes que admite el control de permisos a varios niveles (mo-dificación del diseño del informe, lanzamiento de un informe

de informes y transformarlo automáticamente en un diseño JasperReports.

traducción. d Existe un proyecto open source de traducción, por el que gente desinteresadamente colabora traducien-do el programa. En el caso del español, esta traducción se orienta a la forma de hablar hispanoamericana y de momento se centra en los programas. La mayor parte de la documen-tación escrita producida por JasperSoft sólo está en inglés.

Compilaciones. d Al tratarse de un proyecto open source que utiliza a otros, si hay que modificar y compilar algún fuen-te que proviene de otro proyecto, te obliga a buscar la docu-mentación de otros productos de los que se aprovecha, ya que JasperSoft no ofrece una documentación integrada de todo el conjunto sino que cuando desees cambiar las con-figuraciones o modificar algo de otros proyectos te remite a ellos. Eso complicaría la compilación completa de todos los fuentes en el caso de que ésta fuera necesaria, puesto que cada subproyecto tiene su propia compilación documentada en su propio espacio web. Afortunadamente, JasperSoft ya ofrece versiones compiladas que contienen las compilacio-nes de todos los subproyectos.

Una vez analizadas las ventajas e inconvenientes de la aplicación optamos por adoptarla y se procede a su implantación, proceso que aún se encuentra en sus estadios iniciales.

6.1 Implantación de la herramienta

Al no resultar posible convertir automáticamente los informes ya existentes al formato JasperReports, y dado que no existe ninguna limitación en cuanto a la cantidad de herramientas de generación de informes que pueden coexistir en un mismo equipo, hace que inicialmente no sea necesario establecer ningún plan de conversión paulatina de los informes existentes. Pasando a elaborarse en JasperReports los nuevos informes que se precisan, o bien aquellos ya existentes a los que se les debe realizar modificaciones importantes en el diseño.

Al no resultar posible convertir automáticamente los informes ya

existentes al formato JaserReports, y dado que no existe ninguna limitación en cuanto

a la cantidad de herramientas de generación de informes que pueden coexistir en un mismo equipo, hace que inicialmente no sea necesario establecer ningún plan de conversión paulatina

Page 28: Gvpontis Cast

Implantación de una herramienta de generación de informes

27

6

para que se obtengan datos actualizados, control de quién puede acceder a los informes que se obtengan como re-sultado, etc.), y permite que mediante estándares abiertos, como web services, cualquier programa lo invoque o bien se utilice una página web provista por la propia herramienta para hacerlo interactivamente (con lo que el informe no tie-ne por qué estar accesible desde ninguna aplicación con-creta) y permite también la ejecución planificada y automá-tica de los informes para que se aprovechen determinados horarios en los que los ordenadores están infrautilizados,

recogiendo informes automáticamente de todas las inciden-cias que se produzcan.

JaperAnalysis. d Herramienta muy potente para realizar Data Warehouse.

JasperetL. d Herramienta para automatizar las migraciones de datos, etc., que recoge informes automáticamente de to-das las incidencias que se produzcan. Permite también la conversión de información entre formatos muy distintos.

Recomendaciones >

Nuestra experiencia nos recomienda no limitarse exclusivamente al empleo de la herramienta iReport. Si se desea dexplotar toda la funcionalidad de JasperReports se puede programar directamente sobre la librería de JasperReports. Muchas funciones han sido documentadas mediante el uso de la herramienta jdk. La documentación de todas estas funciones se distribuye gratuitamente y además está accesible al público general en Internet.

Mostrar las posibilidades de generación de gráficas de la herramienta así como las herramientas complementarias como dJasperAnalysis para Datawarehouse, para despertar el interés por ellos.

Estudiar los ejemplos que acompañan tanto a iReport como a JasperReport. Hay que hacer notar que la web de dJasperReports ofrece una instalación de esta herramienta e incorpora ejemplos adicionales que pueden ser modificados también con la herramienta iReport.

Consultar el propio foro de JasperSoft cuando se tenga una duda sobre la programación con esta herramienta. d

Page 29: Gvpontis Cast

28

En el momento en que arranca el proyecto gvPONTIS, la conselleria disponía de un portal corporativo accesible por

el ciudadano, www.cit.gva.es, y otro portal corporativo de uso interno. También empezaba a despuntar como aplicación de Software Libre de la conselleria la herramienta gvSIG, de la cual también se tenía una página web oficial del proyecto, www.gvsig.gva.es.

Los diseños de los diferentes portales corporativos fueron desa-rrollados a principios del año 2000, por lo que tanto los avances tecnológicos como las nuevas necesidades creadas, exigían reali-zar ciertas modificaciones para adaptarlo a las nuevas demandas que habían ido surgiendo durante este tiempo. A mediados del 2005 se plantea el rediseño y la reestructuración de la informa-ción, tanto de su web externa (Internet) como de su Intranet.

El trabajo por parte del equipo de web se podía resumir en dos partes. Una consistía en la actualización y mantenimiento de contenidos web de ambos portales corporativos. Estos contenidos estaban formados por páginas estáticas, ficheros html agrupados en directorios de acuerdo a las pautas seguidas hasta ese momento.

Otra consistía en tareas de mantenimiento de los portales, como la revisión de enlaces rotos del portal, la creación de backups de las diferentes estructuras de ficheros, etc. También se llevaban a cabo otras tareas como la generación de estadísticas y retoques de imágenes para publicar en la web.

La tecnología que se empleaba antes de iniciar el proyec-to de migración era un servidor de páginas web open source, el cual se ejecutaba sobre una máquina con sistema operati-vo UNIX. Los portales web corporativos estaban optimizados para ser consultados con navegadores con una versión igual o superior a la 4.0 y una resolución gráfica de 800x600. Se ga-rantizaba la visibilidad en los dos navegadores más impor-tantes del momento, Internet Explorer y Netscape-Mozilla.

A excepción del servidor de páginas web y el sistema ope-rativo de la máquina, en el equipo de web empleábamos software privativo para las herramientas de diseño grá-fico, programa de edición de páginas web, así como la herramienta de diseño de impresos en formato PDF, entre otras.

La elección, en Software Libre, de cada uno de los componentes a emplear en la nueva plataforma de trabajo, vienen marcados bien por la interacción con otros departamentos del servicio de informática, como pueden ser Sistemas, Base de Datos o Desarrollo, o bien por las necesidades o requisitos propios del equipo de web a la hora de desplegar las aplicaciones propias para trabajar.

Desde Sistemas, evaluados los requisitos necesarios, se optó por la elección de SUSE Sless (servidor Linux), así como por el servidor de páginas web Apache.

Migración del portal web e Intranet

CA

PÍTU

LO 7

Page 30: Gvpontis Cast

Migración del portal web e Intranet

29

7

alcanzar casi la totalidad del uso herramientas de Software Libre para el desarrollo de los portales web corporativos en el trabajo del día a día. Algunas de estas herramientas son la base de datos, el servidor de páginas web, el lenguaje de programación interpretado para la creación de páginas web dinámicas y el gestor de contenidos web (CMS).

Aunque en la fase inicial del proyecto gvPONTIS, por parte del equipo de base de datos, se descartó el uso de la base de datos MySQL1, con posterioridad hemos incorporado su uso dado que así garantizábamos un mayor rendimiento por parte de TYPO3.

En la actualidad, trabajamos con diferentes versiones para cada una de las herramientas. Esto es debido a la diferencia en el tiempo, desde 2005 hasta la fecha, para la implantación de los diferentes portales que actualmente ofrece la conselleria.

Los primeros portales que hemos puesto en marcha con la tec-nología LAMP+TYPO3 son www.cit.gva.es, www.gvsig.gva.es y www.gvPONTIS.gva.es. Actualmente están con la versión de TY-PO3 3.8.1, Apache 2.0.59, PHP 4 y MySQL 4.1.

Con posterioridad se han desarrollado los portales web www.paseopo-niente.es y www.jornadasgvsig.gva.es, y ya disponen de una versión más actualizada de TYPO3, pero la misma configuración base de LAMP.

Los portales más recientes son www.moskitt.org y www.ideacv.gva.es. Este último tiene la misma configuración base para LAMP que los anteriores, pero con una versión más nueva y estable de TYPO3, concretamente la versión 4.1.5.

1 Consultar informe de Conclusiones.

TYPO3 resultó elegido como gestor de contenidos. TYPO3 es un Sistema de Gestión de Contenidos (CMS) de código abierto y desarrollado bajo licencia GPL. Se consideró en su momento que era el que mejor se ajustaba a las necesidades del equipo de trabajo.

Algunas de sus características que nos resultaron más relevantes tras su análisis fueron:

Eficacia en la gestión de contenidos y creación de workflows dsimplificados.

Flexibilidad debido a que se adapta a diferentes necesida- ddes e instalaciones.

Rapidez y simplicidad gracias a la utilización de una interfaz dpráctica e intuitiva.

Multilingüe, ya que tiene total integración en más de 16 len- dguas.

Calidad profesional de los resultados. d

La tecnología que emplea TYPO3 es un paquete comúnmente denominado LAMP (Linux, Apache, MySQL y PHP).

El acrónimo LAMP se refiere a un conjunto de subsistemas software necesarios para alcanzar una solución global, en este caso configurar los portales web. Los subsistemas que se utilizan son Linux, como sistema operativo, Apache, como servidor web, MySQL, para la gestión de bases de datos y Perl, PHP o Python, como lenguajes de programación. En nuestro caso utilizaremos PHP.

TYPO3 se ejecuta en un navegador, por lo que no requiere ningún software especial en el lado del usuario. Cualquier navegador actual con soporte de gráficos es válido.

Durante el transcurso del proyecto gvPONTIS, los portales web corporativos, al igual que otros proyectos del departamento de informática, también han sido migrados a Software Libre, intentando

Aunque en la fase inicial del proyecto gvPONTIS, por parte del equipo de base de

datos, se descartó el uso de la base de datos MySQL, con posterioridad hemos incorporado su uso dado que así garantizábamos un mayor rendimiento por parte de TYPO3

Page 31: Gvpontis Cast

30

Experiencia deintegral

migracióna software libre

Cabe destacar el portal web www.moskitt.org, ya que se diferencia de los demás por las versiones que se utilizan en este portal en al-gunas de las herramientas. Concretamente se ha utilizado la misma versión de TYPO3 que en ideacv, pero el paquete LAMP difiere en las versiones de los productos. Para MySQL y PHP se ha instalado la versión 5 y como servidor web se ha configurado el producto NGINX, que también está basado en código abierto.

La combinación de herramientas a la que hemos llegado y con las que actualmente trabajamos, nos ha permitido una mayor flexibilidad a la hora de mantener, actualizar los portales web que tenemos, así como también nos permite desarrollar portales nuevos.

Diseñamos las web con compatibilidad para diferentes versiones de navegador, Firefox e Internet Explorer principalmente y además tuvimos en cuenta Mozilla. Para Linux, la versión de Internet Explorer es una versión beta, que funciona bien, pero no lo hace igual que en Windows, por lo que es necesario disponer de un Internet Explorer bajo Windows para realizar las pruebas de funcionamiento y aspecto de las páginas.

En lo que ha diseño gráfico se refiere, en Software Libre, disponemos del programa GIMP, el cual es un buen candidato

para sustituir a la herramienta Adobe Photoshop. El inconveniente que le hemos encontrado es que tiene una curva de aprendizaje alta y no conseguimos los mismos resultados que con Adobe Photoshop.

En el ámbito del mantenimiento de los portales web, una de las tareas que se realiza es la generación de estadísticas. La herramienta de Software Libre elegida ha sido Awstats, pero no llega a alcanzar todo el potencial, en comparación con la que se utilizaba en Windows. En la herramienta para la revisión de enlaces rotos, nos ha ocurrido el mismo problema que con las estadísticas. No hemos encontrado una herramienta de Software Libre que funcione de forma similar a como lo hace la herramienta de pago Linkbot.

Como conclusión, a fecha de hoy empleamos básicamente Software Libre para desempeñar nuestro trabajo diario, exceptuando determinados puntos como son la confección de formularios rellenables, elaborados con Adobe Acrobat Writer, así como la edición avanzada de imágenes con Adobe Photoshop. También, resulta necesario disponer de una plataforma Windows por la necesidad de realizar comprobaciones de navegabilidad y apariencia de las páginas web empleando el navegador Internet Explorer.

Page 32: Gvpontis Cast

31

La herramienta de Seguimiento de Expedientes (WorkFlow o BPMS) empleada en la conselleria es MASTIN. Se trata también

del WorkFlow definido como estándar en el ámbito de la GVA.

La transición a Software Libre requería de la adaptación de esta aplicación que al inicio del proyecto de migración partía de un entorno tecnológico compuesto por:

d Oracle como SGBD.

d Developer como herramienta de desarrollo.

d Sistema operativo de clientes: Windows.

d Navegador: Internet explorer.

d Paquetes ofimáticos: MSOffice 97 (Word y Excel).

En el transcurso del proyecto, este entorno tecnológico totalmente propietario está evolucionando en dos fases muy diferenciadas:

1. Migración a sistema operativo Linux, navegador Firefox y paquete ofimático OpenOffice.

2. Migración a PostgreSQL como SGBD y Java como herra-mienta de desarrollo.

La primera de las fases se ha concluido con éxito, mientras que la migración a Java, independiente de la base de datos, aún se encuentra en curso.

Centrándonos en la primera fase (migración a sistema operativo Linux, navegador Firefox y paquete ofimático OpenOffice), los aspectos más relevantes que se han tratado, antes y durante la migración, se resumen en los siguientes:

Respecto a tareas previas a la migración, se realizaron éstas: d

Pruebas, detección y solución de errores de la aplicación »(WorkFlow) en las diferentes versiones de Linux instaladas en la CIT.

Estudio de las diferentes versiones de OpenOffice existentes »en ese momento, para saber manejarla y conocer lo que se puede o no hacer.

Pruebas, detección y solución de los problemas al usar »OpenOffice.

La propia migración ha afectado a los siguientes puntos: d

Se ha adaptado tanto el núcleo del WorkFlow como la »programación de ciertos aspectos de la aplicación, que

WorkFlow para la tramitación y seguimiento de expedientes

CA

PÍTU

LO 8

Page 33: Gvpontis Cast

32

Experiencia deintegral

migracióna software libre

El empleo de Linux, en algún aspecto puntual, presenta el dproblema de que lo que funciona en una distribución Linux puede no funcionar con otra, como es el caso del código de barras que usan los documentos de pago, que en Xaloc funciona y en Lliurex no.

Respecto a la segunda fase (evolución a una versión que emplee PostgreSQL como SGBD y Java como herramienta de desarrollo), actualmente se está implementando dicha versión.

Previamente se ha aprovechado para realizar reingeniería de los procesos organizacionales que actúan en la tramitación de los expedientes y a los que da soporte MASTIN, con objeto de maximizar la eficiencia de las tareas, una vez implantada la herramienta.

Los beneficios que se obtendrán con esta versión serán: d

Renovación tecnológica. »

Eliminación de licencias. »

Para ello se deberán solventar los siguientes problemas: d

Readaptar el personal informático a las nuevas tecnologías/ »herramientas utilizadas en la nueva aplicación.

Readaptar y formar a los usuarios en la tecnología utilizada »en la nueva aplicación.

sólo funcionaban en Windows, para que funcionen en Linux.

A pesar de que la ejecución de la aplicación ya pueda »realizarse en Linux, el desarrollo en Developer de formularios y listados sólo puede realizarse en Windows.

La CIT está convirtiendo paulatinamente los documentos »Word a OpenOffice, marcados por el paso a Linux en los Servicios en los que se va instalando progresivamente. Tras finalizar este proceso la aplicación podrá ser ejecutada totalmente en Linux.

El empleo de OpenOffice en la generación de documentos de dsalida (propuestas, resoluciones y notificaciones) del Work- Flow en sustitución de MSOffice, ha resultado costoso en el tiempo debido a los siguientes problemas o desventajas:

Ha sido necesario modificar todas las consultas de los »documentos Word que tenían condiciones y crear funciones de base de datos nuevas para obtener los datos que debían mostrarse en el documento. Todo ello por no existir el tratamiento de las condiciones en OpenOffice. Esto supone una duración extra en la creación y modificación de documentos para MASTIN.

Ha sido necesario recalcular las fórmulas existentes en los »documentos Word, ya que OpenOffice no sabía interpretar algunas de ellas.

Problemas de compatibilidad de versiones de OpenOffice. »Los documentos creados con una versión de OpenOffice no pueden generarse con cualquier versión instalada en el PC del usuario sin una modificación en todos esos documentos.

El tiempo de diseño y creación de los documentos en »OpenOffice es mayor, ya que es más complicado dibujar e insertar todo lo necesario.

La primera de las fases se ha concluido con éxito, mentras que la migración a Java,

independientemente de las bases de datos, aún se encuentra en curso

Page 34: Gvpontis Cast

33

Dentro del plan de migración a Software Libre, gvA-DOC (aplicativo de Archivo Documental) se

convirtió en la primera experiencia de migración de una aplicación privativa. En ella se completaron las fases de planificación, coordi-nación y seguimiento del proceso de migración.

La conselleria viene utilizando aplicativos de gestión documental desde el año 1998, evolucionando los servidores y los sistemas de almacenamiento físico de las imágenes (guardándose en sistema de ficheros o en base de datos). gvADOC se convierte en la ter-cera aplicación de gestión documental después de experiencias anteriores con Keonview y Poseidoc.

gvADOC permite el almacenamiento de imágenes de documentos por Áreas Documentales independientes, con conexión a las aplicaciones alfanuméricas que gestionan cada uno de los expedientes que son tramitados por la conselleria.

El aplicativo tiene como objetivo permitir un acceso rápido y fácil a la documentación contenida en cada expediente, bien sea documentación generada por la conselleria, como la recibida del exterior. Todo ello sin necesidad de acudir al archivo físico, que puede estar ubicado incluso en otro edificio.

Asimismo, la documentación digitalizada es fácilmente visualizable, en consultas a través de Internet, por aquellas empresas y/o

ciudadanos implicados en el expediente, siempre y cuando se cumplan las condiciones de seguridad preestablecidas.

La aplicación permite y facilita, de una manera sencilla, la definición y puesta en marcha de nuevas Áreas Documentales en el resto de Servicios de la conselleria, con una inversión mínima en tiempo y personal informático.

gvADOC es un aplicativo hecho a la medida de nuestras necesi-dades, resultante de la suma de aquellas funcionalidades que de la aplicación anterior se habían demostrado necesarias, junto a la incorporación de nuevas sugeridas por los usuarios.

Para determinar dichas funcionalidades fueron encuestados todos los usuarios de la conselleria que empleaban el anterior aplicativo. Se aprovechó para realizar un cambio de entorno tecnológico muy importante, que además pretendía eliminar la dependencia con las empresas propietarias externas y productos del mercado. De tal forma que el aplicativo debía ser totalmente mantenible por la propia conselleria.

Dentro del plan de migración a Software Libre, gvADOC se convirtió en la primera

experiencia de migración de una aplicación privativa

gvADOC: sistema de gestión documental

CA

PÍTU

LO 9

Page 35: Gvpontis Cast

34

Experiencia deintegral

migracióna software libre

Directamente a través de la aplicación gvADOC. d

Con un navegador en Internet donde, a modo de ejemplo, dun ciudadano puede ver directamente la información de un Contrato Administrativo en Licitación (pliegos de condicio-nes...) e información sobre una expropiación en concreto.

El mayor problema que se ha tenido que abordar se ha localizado en las interfaces de los escáneres. Para conseguir una aplicación multiplataforma/GPL, a la hora de la digitalización de imágenes, se optó por una solución hardware (caja AXIS).

Esta solución, que resulta económicamente más cara, se impone a otras soluciones software en el entorno Linux y GPL que han sido descartadas, de momento, por la inexistencia de drivers de escáneres actualizados a los últimos modelos de mercado.

Otra dificultad fue la de convencer a la empresa que realizó la aplicación para que liberara en GPL sus propias librerías utilizadas en el desarrollo de gvADOC.

En el lado positivo destacar que el SGBD PostgreSQL ha solucionado sobradamente las necesidades referidas a la base de datos.

Poco a poco nuevos Servicios/Departamentos van incorporando al sistema sus archivos manuales. Asimismo, se tiene previsto la evolución de la herramienta con nuevas funcionalidades, por ejemplo, incorporación de procesos de Firma Electrónica y mejora de los accesos externos a través de Web Services.

A modo comparativo, un resumen del cambio en el entorno tec-nológico es:

Aplicativo anterior ADOC

Windows Multiplataforma

cliente-servidor 3 capas

Oracle PostgreSQL

C-Basic Java

Interfaz propio Guía de estilo de la CIT

Como servidor de aplicaciones emplea TOMCAT.

Inicialmente sólo se implantó en dos servicios de la conselleria, y en la actualidad, ya se ha extendido su uso a siete servicios. Cada una de estas Áreas tiene sus propias características, pues uno de los principales valores de la herramienta es su versatibilidad. La organización de los “armarios digitales“ y la forma de las fichas de los documentos se define según las necesidades de cada servicio.

El volumen de información digitalizada en la actualidad alcanza los 114 GB de memoria, en formatos tan dispares como: tif, pdf, doc, odt, etc. El acceso a la documentación se puede realizar de varias formas según las necesidades:

A través de la correspondiente aplicación departamental de dseguimiento de expedientes, de forma que de manera rápida y sin pasos intermedios se visualiza la documentación reque-rida del expediente actual en pantalla.

Page 36: Gvpontis Cast
Page 37: Gvpontis Cast

36

Parte 2

Page 38: Gvpontis Cast

37

Sistemas Operativos y Comunicaciones

37

En el Departamento de Sistemas y Comunicaciones se han evaluado, estudiado e implantado diferentes herramientas si-tuadas todas ellas en los siguientes ámbitos:

1. Entorno de PC de usuario final :

Sistema operativo y escritorio gráfico en el entorno del »PC de usuario final.

Herramientas ofimáticas en el entorno del PC de »usuario final: procesador de texto, hoja de cálculo, cliente de correo, navegador web, etc.

2. Entorno de servidores de red local que proporcionan servicios horizontales de impresión, de compartición de archivos y de autenticación de usuario.

3. Entorno de comunicaciones y networking.

4. Entorno de servidores corporativos tanto de base de datos, como de servidores de aplicaciones y servicios web.

A continuación se indica para cada una de los ámbitos y las tareas acometidas dentro del marco gvPONTIS.

Page 39: Gvpontis Cast

38

En el momento que iniciamos el estudio, enero de 2004, partíamos de la siguiente situación técnica: parque de

aproximadamente 1.000 PCs con Windows 98, cliente de correo Outlook Express, MS-Office para procesador de texto y hoja de cálculo, mensajería instantánea, antivirus de Panda y gestión remota de equipos con dos herramientas propietarias, LiveHelp y Tivoli.

El entorno de trabajo de los PC de usuario constituye una de las áreas de más sensibilidad en la migración debido a que:

Las aplicaciones eran cliente/servidor, es decir, se ejecuta- dban en los PCs.

El entorno Windows era el único conocido por los usuarios. d

Dado que las herramientas en las que estaban desarrolladas las aplicaciones no disponían de módulos para funcionar sobre Linux, era necesario conseguir una solución técnica a corto plazo que nos pertimitiera proseguir con la migración en los puestos de usuario.

Optamos por la virtualización que nos ofrecía las siguientes ventajas:

Implantar Linux en los PC de usuario, sin esperar a que las daplicaciones se migraran.

Nos ofrecía una forma de interactuar con otros organismos dde nuestro entorno que utilizaban herramientas del entorno Windows.

Para llevar adelante esta opción se evaluaron diferentes distribucio-nes y todas ellas eran adecuadas. Elegimos primero la apariencia del escritorio y las diferentes herramientas software que sustituían a aquellas que utilizamos en el entorno Windows, y quedó una pla-taforma que validamos y preparamos para implantar. Se trataba de una disribución SUSE Linux 9.0 con escritorio KDE, OpenOffice, Mozilla para navegar por Internet y para el correo electrónico, y un emulador Win4Lin con un Win98 completo.

Esta plataforma se implantó en un número reducido de usuarios (en concreto diez). Estos fueron formados con anterioridad, eran favorables al cambio y les ofrecimos una asistencia técnica personalizada que les permitiera resolver al instante dudas de uso y fallos imprevistos.

Con posterioridad, y una vez comprobada la posibilidad de la experiencia, la tendencia en las distribuciones Linux nos hizo pensar que seríamos capaces de personalizar una distribución propia, y así surgió Xaloc. Consistía en una plataforma de gestión de paquetes, una herramienta de detección de hardware. Nos facilitaba la gestión del parque de PC, ya que nos permitía hacer instalaciones masivas y desatendidas. Al aumentar el número de equipos nos dimos cuenta

Entorno de PC de usuario final

CA

PÍTU

LO 10

Page 40: Gvpontis Cast

Entorno de PC de usuario fina l

39

10

En el momento en que se necesita hacer cualquier cambio al usuario de una de estas distribuciones, se aprovecha para migrarlo a la nueva.

Para el control remoto de ordenadores se utiliza VNC, programa de Software Libre basado en una estructura cliente-servidor. Éste nos permite tomar el control total de cualquier ordenador-servidor remotamente a través de un ordenador-cliente, también llamado software de escritorio remoto.

VNC permite que el sistema operativo en cada ordenador sea distinto: es posible compartir la pantalla de una máquina de cualquier sistema operativo conectándose desde cualquier otro ordenador o dispositivo que disponga de un cliente VNC. Esto es especialmente útil en nuestro caso, debido a la coexistencia de distintos sistemas operativos y de distintas distribuciones de los mismos.

Para resolver la problemática de las aplicaciones que sólo se ejecutan en entorno Windows se ha optado por el software VMware, que consiste en un sistema de virtualización por software, es decir, un programa que simula un sistema físico con unas características hardware determinadas. Cuando se ejecuta el programa simulador, proporciona un entorno de trabajo similar, a todos los efectos, a un ordenador físico, excepto en el puro acceso físico al hardware simulado.

VMware es un producto que permite correr máquinas virtuales creadas con otros productos de VMware, pero no permite crearlas él mismo. Las máquinas virtuales se pueden generar con productos más avanzados, como VMware Workstation.

que no éramos capaces de crear nuevas versiones estables de Xaloc, al ritmo que los cambios de hardware (por ejemplo, de discos IDE a discos SATA), las nuevas versiones de las herramientas (por ejemplo, de Mozilla a Firefox y Thunderbird) y la demanda de nuevas funcionalidades exigían.

Decidimos abandonar esta línea y acogernos a algún otro proyecto que tuviera personal especializado y con dedicación exclusiva a la labor de generar la distribución. Por suerte, en la Generalitat Valenciana maduraba LliureX, un proyecto que se ajustaba a nuestras necesidades. Aunque éste está muy enfocado al entorno de la educación, nos permitía incorporar nuestras necesidades a esa distribución. Así se diseñó un plan de implantación de LliureX en todos los PCs de la conselleria (que finalizará en diciembre de 2008).

En la actualidad se está instalando la versión 7.11 de LliureX, que es una distribución basada en la UBUNTU 7.04 “Feisty”. Esta distri-bución, que entre otras aplicaciones incorpora el paquete ofimático OpenOffice, navegador Firefox y gestor de correo Thunderbird, al estar pensada para entornos educativos, tiene una lista de paquetes más orientada a tal fin y por eso nos hemos visto obligados a com-plementarlos añadiendo los siguientes:

Kprinter. d

Java 1.5. d

Adobe Acrobat Reader. d

emulador VMware. d

Con todo este conjunto de paquetes se ha generado una imagen para configurar los ordenadores de la CIT.

Respecto al mantenimiento de las distribuciones en el cliente, y debido a estos cambios excesivos, en la actualidad en la conselleria conviven varias distribuciones: SUSE 9.0, SUSE 10 y Xaloc. Estas distribuciones, por economía de tiempo, se mantienen en los PCs de los usuarios sin pasar a LliureX, mientras no generen ningún problema.

Por suerte, en la Generalitat Valenciana maduraba LliureX, un proyecto que

se ajustaba a nuestras necesidades, permitiéndonos incorporarlas a esa distribución.

Así, se diseñó un plan deimplantación de LliureX en todos los PCs de la conselleria (que

finalizará en diciembre de 2008

Page 41: Gvpontis Cast

40

La decisión de migrar a Linux como sistema operativo de propósito general, también afectaba a la estructura y montaje

de la red local de servidores corporativos, tanto en las oficinas centrales como en todas las delegaciones. La situación que deseábamos alcanzar era poder prescindir de los equipos Windows 2000 que ofrecen los servicios de:

Impresión. d

Validación de usuarios. d

Compartición de archivos. d

La decisión que tomamos fue que los clientes Linux utilizaran servicios que proporcionaran los servidores Linux de nueva instalación, y que los clientes Windows hicieran lo mismo con los servidores Windows que ya existían. Es decir, disponer de infraestructuras paralelas en ambos entornos. Esto nos obligaba a mantener una estructura de servicios para los equipos Windows hasta la extinción de estos en la red y crear otra infraestructura homóloga para los servicios Linux, que cada vez tendría más clientes conforme la migración de los PC avanzara.

Tomamos esta decisión después de comprobar que los equipos Windows 9x no iban a integrarse bien en la nueva infraestructura de serviciores Linux, por incompatilidad de protocolos. Tampoco nos

parecía buena solución que los clientes Linux siguieran utilizando los servicios proporcionados por servidores Windows 2000. Esta última opción hubiera traicionado el objetivo de migrar todo el software utilizado al mundo libre.

Esta estrategia tenía la desventaja de que duplicaba el trabajo del administrador, pero nos independizaba de la velocidad de migración de otros entornos y garantizaba el servicio a los usuarios fuera cual fuera su sistema operativo, un objetivo básico que ha orientado siempre el proyecto de migración.

Una vez los usuarios están utilizando la distribución de Linux de SUSE v.9.0 como sistema operativo de cliente, se habilitó un servidor con Linux SLES v.8.0 como servidor de ficheros y directorios compartidos mediante Samba. También hemos creado un directorio en cada máquina de usuario, como recurso compartido para que el resto de usuarios, tanto en Windows como en Linux, lo puedan utilizar.

En el campo de la investigación de las redes locales, las alternativas técnicas existentes en el mundo del Software Libre a los servicios que nosotros necesitábamos, era muy clara en algunos casos y apenas se vislumbraba en otros. Pero un inconveniente que resultaba evidente es que las soluciones en el mundo del Software Libre no estaban integradas en un único interfaz gráfico que facilitara la administración de los recursos. Sin embargo, en casi todos los casos, resultaban alternativas claras y seguras.

Entorno de servidores de red local

CA

PÍTU

LO 11

Page 42: Gvpontis Cast

Entorno de servidores de red local

41

11

ñas y otros atributos necesarios para la administración de perfiles de usuario. Encontrar la solución apropiada en el año 2004 no fue nada fácil, ya que los fabricantes no tenían productos maduros ni experiencia en proyectos de gestión de identidades.

El servidor LDAP Linux es un OpenLDAP2, que es el encargado de mantener la base de datos con todos los usuarios, grupos de usuarios y máquinas de nuestra red en Linux. Aquí se almacenan todos los datos necesarios de cada usuario y máquina, siendo así como los usuarios con Linux se validan en la red (aproximadamente 500, de un total de 900).

A medida que se avanzaba en el proyecto, nuestro objetivo se con-cretaba en disponer de una interfaz común de provisión de usuarios.

Buscamos la manera de administrar los usuarios de forma única, es decir, que los usuarios de Windows y de Linux sean los mismos, inde-pendientemente de la máquina desde la que se conectan a la red.

Para conseguir este objetivo, iniciamos un proyecto de gestión de identidades con el producto de Sun Identity Manager, al no haber encontrado productos equivalentes de Software Libre.

Hemos hecho un gran esfuerzo técnico y organizativo de integración de nuestros repositorios de usuario en la conselleria: Active Directory, OpenLDAP y Oracle.

En este momento tenemos un único punto de provisión de usuarios y el Identity Manager mantiene los repositorios sincronizados.

El siguiente paso en este entorno será integrar también otros repositorios de usuario dentro de la Generalitat Valenciana, como las cuentas de correo electrónico y los usuarios de otras aplicaciones de otras consellerias.

Partíamos de una estructura de servidores PDC (Primary Domain Controler) en red, con el sistema operativo Windows 2000 SP4 (un total de 14 servidores). Son servidores de ficheros e impresión en red, donde los usuarios de los servicios centrales y territoriales validan la seguridad de permisos y la sesión de red para poder acceder a los recursos compartidos e impresoras.

Los clientes iniciaban la sesión bajo Windows 98 SE, Windows 2000 estación de trabajo y Windows XP SP1/SP2, obteniendo los permi-sos necesarios de los controladores de dominio principales (PDC) y secundarios (BDC), donde se mantenían las bases de datos en Active Directory de los usuarios, grupos y máquinas de la red Windows.

Los accesos a la estructura de la red eran anunciados por los controladores de dominio de Windows 2000 SP4 PDCs y BDCs, con sus funciones de servidores de nombres (DNS) que resuelven los nombres de las máquinas de nuestra red en los distintos dominios de la CIT. La seguridad está proporcionada por la estructura del LDAP propietaria de Microsoft (es decir, Active Directory).

Para la autentificación de usuarios en la red local elegimos OpenLDAP. En este caso el objetivo era doble, ya que la tendencia en las nuevas aplica-ciones n-capas también era autenticarse contra servicios LDAP, de mane-ra que pensamos que podríamos integrar ambos repositorios de usuarios.

A continuación se describen los servicios incluidos en esta nueva infraestructura.

11.1 LDAP

En ese momento de migración, una vez optado por OpenLDAP, se inicia un proyecto de gestión de identidades que pretende unificar en un sólo metadirectorio el repositorio de usuarios de directorio activo de Windows, el de autenticación de usuario en la red Linux, el de usuarios de base de datos para las aplicaciones antiguas y el de usuario de aplicación para las nuevas aplicaciones y portales.

Conocíamos la dificultad de controlar la autenticación de usuarios, derechos y restricciones de acceso, perfiles de cuentas, contrase-

El servidor LDAP Linux es un OpenLDAP2, que es el encargado de

mantener la base de datoscon todos los usuarios, grupos de usuarios y máquinas

de nuestra red en Linux

Page 43: Gvpontis Cast

42

Experiencia deintegral

migracióna software libre

11.2 CUPS1

Para el servicio de impresión se ha utilizado un servidor CUPS, que puede gestionar las impresoras remotas de una red. Este servicio de impresión trabaja a través del protocolo IPP, permitiendo utilizar impresoras configuradas desde clientes Linux.

Por lo que hace referencia a la administración y control de la impresión, CUPS posee una interfaz web bastante amigable, mediante la cual permite administrar las impresoras instaladas en el servidor CUPS, ver todos los trabajos impresos en cada impresora, cambiar cuotas y permisos, modificar dispositivas, manejar colas de impresión y trabajos, crear nuevas impresoras, configurarlas, etc., desde cualquier punto de nuestra red (Intranet).

El único problema que se ha detectado es la falta de “drivers” para algunas impresoras muy antiguas. Pero al final se han resuelto los problemas con la instalación de dispositivos de emulación de impresoras HP modo GIMP+CUPS, o dispositivos genéricos (estilo Postcript). Este escollo se ha ido suavizando ya que las impresoras nuevas disponen en su totalidad de drivers para Linux.

1 CUPS son las siglas de Sistema de Impresión Común de Unix (Common Unix Printing System). Se trata de un sistema que permite que un ordenador central actúe como servidor de impresión, y así centralizar la gestión de las impresoras y listados dentro de un entorno de red local. Utiliza el protocolo IPP (Internet Printing Protocol) como base para tareas de impresión y de colas de impresión, y se distribuye bajo licencia GNU General Public License.

11.3 BInD

Para el servicio de nombres elegimos BIND, que ya se empleaba con anterioridad en la CIT para publicar nuestras máquinas en Internet y en la red corporativa de la Generalitat.

11.4 SAMBA

Para la compartición de archivos utilizamos SAMBA2, que ya era un producto más que probado en la conselleria. Actualmente se sigue empleando, aunque la intención final es prescindir de este producto, detectar y analizar las necesidades de compartición de conocimiento y diseñar alguna estrategia con la intención de hacer desaparecer el trasiego de ficheros entre PCs.

Nuestro deseo es evitar pérdidas de datos por falta de copia de segu-ridad, dispersión de datos personales en PCs sin conocimiento de los responsables de seguridad, etc.

La estrategia se orientará a buscar una herramienta colaborativa junto con un portal, de manera que los usuarios puedan intercambiar ficheros y datos, pero dentro de un entorno controlado por los administradores.

2 SAMBA es una implementación sobre TCP/IP de un conjunto de protocolos y servicios propietarios de Microsoft, que constituyen lo que se llama NetBIOS o SMB. Permite que un equipo Linux se comporte como un cliente y/o servidor Windows.

Page 44: Gvpontis Cast

43

Partíamos de una red de comunicaciones que ofrece servicio continuado 24/7

a todas las dependencias de la conselleria, seguridad perimetral basada en firewalls y gestión de acceso a Internet basado en proxy. Nuestro objetivo consistía en seguir manteniendo la situación de partida durante y tras la migración a entornos abiertos.

Debido a la naturaleza multiplataforma del protocolo TCP/IP utilizado en la conselleria, no encontramos ninguna dificultad en lo referente a las comunicaciones de red para hacer funcionar los servicios que la migración precisaba sobre la red existente, de manera que la red física WAN y LAN no sufrieron ningún cambio.

El servicio de seguridad perimetral se basaba en un cortafuegos constituido por procesadores SPARC con sistema operativo Solaris. Se actualizó tanto el hardware como el software del firewall, pasando a una plataforma basada en procesadores Intel y sistema operativo Linux. Con este cluster Linux ganamos en redundancia y en rendimiento. No se encontró ningún problema, de hecho mejoró bastante el rendimiento, aunque también influyó la mejora en el hardware.

El servicio de proxy que utilizábamos para que los usuarios salieran a Internet y se accediera a algunas aplicaciones desde la Red, ya pertenecía al mundo del Software Libre. Squid, el software que utilizamos para el proxy, está licenciado bajo GNU/GPL y desde

que se instaló (el año 1999) siempre ha corrido sobre plataforma Intel/Linux, con lo que no hemos encontrado ningún problema en su actualización (se actualizó tanto el hardware - Intel -, como la versión de Squid).

Por último, las herramientas de gestión y monitorización (MRTG y Nagios) que se utilizaban antes de comenzar el proyecto de migración, también estaban licenciadas bajo GNU/GPL y corrían sobre plataformas Linux, con lo que tampoco ha surgido ningún problema al actualizar versiones.

Como resumen del ámbito de comunicaciones y networking, dado que antes de que comenzara el proyecto de migración ya se utilizaban aplicaciones y entornos Linux, no podemos hablar de “migración” como tal, sino de un proceso normal de actualización y mejora de dichos entornos, exceptuando el caso del firewall, para el cual, aprovechando la necesidad de actualizar el hardware, se pasó de un entorno Solaris a un entorno basado en Linux.

Con este cluster Linux ganamos en redundancia y en rendimiento. No

se encontró nngún problema, de hecho, mejoró bastante el rendimiento, aunque

también influyó la mejora del software

Entorno de comunicaciones y networking

CA

PÍTU

LO 12

Page 45: Gvpontis Cast

44

Los servidores corporativos eran equipos con sistema operativo Unix y procesadores SPARC, y hemos ido

sustituyéndolos, cuando quedaban obsoletos, por máquinas con sistema operativo Linux y procesadores Intel.

En este área, el impacto del cambio fue pasar de la mentalidad de máquina con gran capacidad tipo mainframe, que cargaba con todas las necesidades de proceso de la conselleria, a máquinas con arquitectura Intel con otra filosofía más distribuida y orientada a entornos abiertos. Es decir, el número de servidores necesarios para dar servicio a los usuarios se multiplicó debido a los siguientes factores:

En el entorno de red local se duplicaban los servidores man- dteniendo los entornos Windows y Linux separados (ver Ca-pítulo 11, “Entorno de servidores de red local”).

En el entorno de base datos también se duplicaron los ser- dvidores, ya que fue necesario instalar equipos con Postgre- SQL y MySQL, tanto para los entornos de producción como para los de desarrollo y preproducción. (Ver Capítulo 2, “gv-DADES: experiencias con Sistemas de Gestión de Bases de Datos”).

Puesto que las aplicaciones pasaban del modelo cliente-ser- dvidor al de tres capas, también se instalaron nuevos equipos

sobre los que se ejecutaban los servidores de aplicaciones, tanto en el entorno de desarrollo como en el de producción y preproducción. Estos servidores de aplicaciones eran Apache+PHP para los desarrollos con gvHIDRA y Tomcat, para aplicaciones Java. Más tarde llegaría Jboss para aplica-ciones de mayor complejidad.

Se instalaron una serie de equipos con servicios diversos dpara la organización del trabajo en el seno del propio ser-vicio de informática. Algunos de estos servicios son CVS, Subversion, Gforge y Zope.

La dificultad de este área también fue asumir la administración de todas estas herramientas nuevas, además de la administación de los sistemas operativos de las máquinas que los alojaban.

Debido al incremento en el número de servidores, se tuvieron que rediseñar los sistemas de copias de respaldo existentes en la conselleria. Se buscó una solución cuyo servidor corriera sobre Linux, pero que fuera lo suficientemente hetereogénea para permitirnos hacer copias de respaldo, tanto de los nuevos servidores Linux como de los Windows existentes en la conselleria.

La solución elegida fue el software de backup LEGATO, ejecután-dose la parte servidor sobre una máquina Intel con una distribución Red Hat. Para el almacenamiento se instaló una librería de cintas

Entorno de servidores corporativos

CA

PÍTU

LO 13

Page 46: Gvpontis Cast

Entorno de servidores corporativos

45

13

Storagetek L20, con una capacidad teórica de 4 terabytes, que más tar-de fue sustituida por el modelo L40 de Storagetek, alcanzando así los 8 terabytes teóricos de capacidad de almacenamiento para respaldo.

Se buscó una solución cuyo servidor corriera sobre Linux, pero que fuera lo suficientemente heterogénea para permitirnos hacer copias de respaldo, tanto de los nuevos swervidores Linux como de los Windows existentes en la conselleria

Actualmente estamos en proceso de ampliar los sistemas de respaldo lógico con una solución basada en máquinas Intel, sistema operativo Red Hat y el software Bacula, cuya licencia es GPL.

Por suerte, el mercado también ha ido cambiando y los fabricantes han ido poniendo máquinas cada vez más potentes y con más facilidades para implantar alta disponibilidad, clusters y balanceo de carga en los entornos Intel y Linux.

Page 47: Gvpontis Cast

Parte 3

Page 48: Gvpontis Cast

47

El área de SIG/CAD es la encargada de llevar a cabo la migración de aquellas herramientas conocidas como Sistemas de Información Geográfica (SIG) y Diseño Asistido por Ordenador (CAD).

SIG y CAD: gvSIG

Page 49: Gvpontis Cast

48

Los programas de CAD son aplicaciones orientadas a la edición vectorial de precisión, cuyo usuario tipo son los

ingenieros, arquitectos y otros profesionales del diseño.

Estos programas gestionan una base de datos de entidades geométricas (puntos, líneas, arcos, etc.) con la que se puede operar a través de una pantalla gráfica en la que se muestran éstas, el llamado editor de dibujo. La interacción del usuario se realiza a través de comandos, de edición o dibujo, o a través de una interfaz gráfica de usuario, que automatiza el proceso.

Aunque los programas de CAD tienen un amplio abanico de usos, en el caso de la CIT su utilización está orientada. Mayoritariamente, a la edición de cartografía como paso previo a su uso por aplicaciones SIG.

Los SIG son programas que permiten analizar, gestionar, manipular, mantener y capturar información georreferenciada, es decir, relacionada espacialmente con el territorio.

El SIG funciona como una base de datos con información geográfica (datos alfanuméricos), que se encuentra asociada por un identificador común a los objetos gráficos de un mapa digital. De esta forma, señalando un objeto se conocen sus atributos e, inversamente, preguntando por un registro de la base de datos se puede saber su localización en la cartografía.

La razón fundamental para utilizar un SIG es la gestión de informa-ción espacial.

El sistema permite separar la información en diferentes capas te-máticas y las almacena independientemente, permitiendo trabajar con ellas de manera rápida y sencilla, y facilitando al profesional la posibilidad de relacionar la información existente a través de la topología de los objetos, con el fin de generar otra nueva que no podríamos obtener de otra forma.

En el caso de la CIT (con competencias directamente relacionadas con el territorio, en materia de obras públicas, transporte, puertos, aeropuertos y energía, además de actuaciones propias en materia de arquitectura, patrimonio arquitectónico y urbano, equipamientos, y suelo y costas) los SIG se convierten en una herramienta fundamental.

Por tanto, para la CIT, se entienden las tecnologías SIG y CAD como herramientas que se integran en los flujos de trabajo, directamente relacionadas y sin nichos de uso independientes.

Los SIG son programas que permiten nalizar, gestionar, manipular, mantener y capturar

información georreferenciada, es decir, relacionada espacialmente con el territorio

gvSIG: introducción

CA

PÍTU

LO 14

Page 50: Gvpontis Cast

49

El primer paso para llevar a cabo el plan de migración en el área de SIG/CAD debía pasar por un conocimiento de la realidad en

la CIT. Se planteaba como necesario conocer el número de usuarios de estas tecnologías, qué aplicaciones informáticas utilizaban, qué usaban realmente de estas aplicaciones, etc. Para ello se realizó una encuesta que mostró la siguiente realidad:

Existían 90 usuarios de tecnologías SIG/CAD. d

En el campo del CAD se utilizaban diversas versiones de los dproductos AutoCAD y MicroStation.

En el campo del SIG se utilizaban fundamentalmente distin- dtas versiones de la familia de productos de ESRI.

Se usaban datos vectoriales, siendo casi inexistente el uso dde información raster (salvo como información visual).

Más del 90% de los usuarios de estas tecnologías, utilizaba drealmente una mínima parte de las funcionalidades que ofre-cían estos programas, existiendo un número muy pequeño de usuarios que usaban herramientas avanzadas.

En el caso del CAD se utilizaban para la edición avanzada de dcartografía, como paso previo a la realización de topología ya propia de los SIG.

Tanto en el campo del CAD como del SIG no existía una duniformidad en el uso de formatos, utilizándose una variedad de versiones y formatos que dificultaban el intercambio de información entre el personal de la CIT y con el exterior. Se trabajaba con ficheros en local, no se usaban estándares ni bases de datos espaciales.

Una vez conocida la realidad en la CIT, era preciso saber el estado de estos productos en el mundo Linux. La situación inicial presentaba un panorama de lo más árido en el proyecto de migración global, por la ausencia de soluciones maduras dentro del Software Libre que cubriera los requisitos de los usuarios de tecnologías SIG y CAD dentro del seno de la conselleria. El estudio de las soluciones disponibles en el mercado y la comunidad del Software Libre nos llevó a las siguientes conclusiones:

En la comunidad del Software Libre, en el campo del CAD, dexistían algunos proyectos destacados, aunque no lo sufi-ciente evolucionados como para suplir a las herramientas privativas que se utilizaban. De entre todos los proyectos destacaban, principalmente, QCAD y SAGCAD.

En cuanto a formatos en el campo de CAD, no hay un es- dtándar de uso común eficiente. Está extendido el uso del formato privativo y cerrado DWG, lo que dificultaba más, si cabe, el encontrar una alternativa libre.

gvSIG: descripción y justificación de la situación inicial

CA

PÍTU

LO 15

Page 51: Gvpontis Cast

50

Experiencia deintegral

migracióna software libre

Si bien no se encontraban aplicaciones de sustitución di- drecta, había un amplio conocimiento (código, librerías, pro-yectos...) en la comunidad del Software Libre que hacían posible el construir una herramienta libre que cubriera las necesidades de la gran mayoría de usuarios de la CIT.

Había que orientar la solución hacia nuevas formas de dtrabajo más eficientes, trabajando con estándares, datos accesibles en remoto y almacenados en bases de datos espaciales.

Si bien había que centrar los esfuerzos en el escritorio, no ddebía dejarse de lado el estudio de posibles usos del resto de familias SIG, como los servidores de mapas, que podían ampliar las posibilidades de gestión de la información terri-torial. Por tanto, el desarrollo de un cliente de escritorio de-bía abordarse con la visión de ser parte de un sistema más amplio, una apuesta por las denominadas Infraestructuras de Datos Espaciales (IDE).

Por todo ello, la situación inicial tenía como hito inicial, principal y a desarrollar durante el proceso de migración gvPONTIS, el desarrollo de una aplicación SIG que cumpliera con una serie de requisitos básicos:

d Ser una aplicación que integrara el mundo del SIG y del CAD.

d Ser libre. Se partía de un conocimiento albergado y cons-truido por la comunidad del Software Libre, que iba a ser ampliado y potenciado y, por tanto, debía ser devuelto a esa comunidad. La licencia por la que se optó fue la GNU GPL.

d Multiplataforma. La aplicación debía funcionar indepen-dientemente del sistema operativo del usuario. El motivo principal era el proceso de migración, de cuatro años de duración, tiempo durante el cual en la CIT iban a convivir usuarios de distintos sistemas operativos, en concreto Win-dows, Linux y Mac OS X. Esto llevo a tomar la decisión de utilizar Java como lenguaje de programación.

Dentro de la SIG se utilizaban clientes de escritorio, no sien- ddo la CIT usuaria de tecnologías SIG como servidores de mapas, bases de datos espaciales, etc.

En el campo del SIG no existía ninguna aplicación lo suficien- dtemente evolucionada, potente y de uso amigable para susti-tuir a las herramientas privativas de uso común en la CIT. Las aplicaciones más destacadas eran GRASS y JUMP. Si bien GRASS es un software excelente, tiene una orientación más raster que vectorial y, en aquel momento, no disponía de una interfaz amigable. Con JUMP había un problema de potencia y rendimiento que desaconsejaba optar por dicha opción.

Sin embargo, en la comunidad del Software Libre, existían dun gran número de librerías y código, de amplio uso por dis-tintas aplicaciones (incluso privativa, como es el caso de la librería GDAL por tecnología de ESRI) que podrían servir de base para el desarrollo de aplicaciones.

En cuanto a formatos, en el campo del SIG, empezaba a ha- dblarse de forma generalizada de las Infraestructuras de Da-tos Espaciales y los estándares definidos por el Open Geos-patial Consortium (en su día, Open GIS Consortium) que permitían el acceso a datos geográficos en remoto. Además, los formatos de fichero más habituales tenían sus especifi-caciones abiertas, por lo que este aspecto no suponía una barrera para llevar a cabo la migración.

Existía una iniciativa de la Comunidad Europea, que final- dmente se ha convertido en directiva, denominada INSPIRE, enfocada al acceso de cartografía de las administraciones de los países miembros mediante estándares OGC.

Partiendo de la relación de ambos estudios (necesidades y soluciones disponibles) se llegaron a las siguientes conclusiones:

En el caso de la CIT se podía abordar de forma conjunta la dmigración de las herramientas SIG y CAD, ya que el uso de los CAD, como editores de cartografía, era parte del proce-so del uso de herramientas SIG.

Page 52: Gvpontis Cast

gvSIG: descripción y justificación de la situación inicial

51

15

d Seguimiento de estándares OGC y de la Directiva InS-PIRe (en aquel entonces Iniciativa).

d extensible. Desde un principio se plantea el proyecto con una arquitectura escalable, que permita su evolución hacia nuevos campos de uso de la información geográfica.

En el caso de la CIT se podía abordar de forma conjunta la migración de las herramientas SIG y CAD, ya que el uso de los CAD, como editores de cartografía, era parte del proceso del uso de herramientas SIG

d Interfaz amigable. La interfaz debía tener como objetivo el fácil aprendizaje por parte de los usuarios, de modo que la migración fuera lo menos traumática posible y no pre-sentara problemas de comprensión respecto a los hábitos adquiridos durante años de uso de otras aplicaciones.

d Multiidioma. La aplicación debía disponer de la posibi-lidad de ser traducida, con facilidad, a otros idiomas, es-tando disponible inicialmente en castellano, valenciano e inglés.

El proyecto de desarrollo de esta herramienta, así como el nombre de la misma, se denominó gvSIG.

Page 53: Gvpontis Cast

52

El proceso de puesta en marcha y seguimiento del proyecto de migración en el área SIG/CAD de estos cuatro años,

hasta alcanzar la situación actual, viene marcado por una constante evolución tanto a nivel tecnológico como institucional, con una repercusión en la comunidad del Software Libre y en el mundo de los Sistemas de Información Geográfica insospechada en sus inicios.

Este proceso se puede enlazar tanto desde el puento de vista técnico, gracias a la calidad del producto obtenido, como evaluando otro tipo de aspectos de similar o superior relevancia, como es la adopción del proyecto por otras administraciones, el uso en los ciclos formativos universitarios o la creación de un reconocido tejido empresarial. Todo ello ha situado a gvSIG como un proyecto emblemático de la CIT primero y la Generalitat Valenciana después, y ha situado a la Comunidad Valenciana como un referente mundial en el campo de la geomática libre.

16.1 el proceso desde un punto de vista técnico

Desde el punto de vista de producto hay una serie de hitos que han permitido la evolución de los objetivos y la aplicación gvSIG, respecto a los inicialmente establecidos. Estos hitos se corresponden con la extensión de gvSIG a nuevas ramas de desarrollo.

Si bien en una primera fase se orientó el desarrollo de gvSIG con el fin de cubrir las necesidades de la mayor parte de usuarios de la CIT, una vez logrado el objetivo, se lanzaron nuevas etapas de desarrollo con el objetivo de cubrir las necesidades de la totalidad de los usuarios de la conselleria (cada vez más creciente, en paralelo a la evolución del proyecto, y con nuevas necesidades surgidas de la extensión del uso de esta herramienta de gestión territorial), y del resto de consellerias de la Generalitat que, del mismo modo, han ido adoptando el proyecto e integrándolo como parte de sus herramientas informáticas de uso necesario. Estos proyectos se pueden estructurar en las siguientes fases:

gvSIG vectorial. d Proyecto inicial que concluye con la ob-tención de una herramienta SIG que dispone de los instru-mentos básicos para el manejo de información vectorial.

gvSIG como cliente IDe. d Acorde a la directiva europea INSPIRE, se desarrollan en gvSIG una serie de estándares

gvSIG: evolución hasta la solución actual

CA

PÍTU

LO 16

Page 54: Gvpontis Cast

gvSIG: evolución hasta la solución actual

53

16

16.1.1 gvSIG como herramienta SIG vectorial

Como se ha comentado con anterioridad, la primera fase que se abordó en el proyecto gvSIG fue la de cubrir las necesidades propias de un usuario-tipo de un SIG vectorial, usuario medio dentro de la CIT. Necesidades que se han ido cubriendo en los dos primeros años, desde el inicio del proyecto, de manera progresiva, abordando en primer lugar las herramientas más utilizadas, para pasar, a continuación, a implementar aquellas de uso menos frecuente.

Actualmente podemos considerar a gvSIG como un completo SIG vectorial, de gran potencia y que permite trabajar con los formatos de datos más usuales en cartografía, tanto vectorial como raster.

Los formatos vectoriales con los que permite trabajar son: .SHP (shape), .DXF (formato de intercambio de AutoCAD), .DWG (formato propio de AutoCAD), .DGN (formato propio de MicroStation) y .GML (estándar), además de con bases de datos espaciales como PostGIS, MySQL, ArcSDE u Oracle Spatial.

Entre las herramientas disponibles encontramos las propias de carga de datos, navegación (zooms, encuadres, desplazamientos…), consulta de información (información de un elemento, medición de distancias…), cartografía temática (leyendas por valores únicos, por intervalos, autoetiquetado…), selección de elementos (selección gráfica, selección por atributos, espacial…), tablas (estadísticas, ordenar, relacionar tablas, enlazar tablas…), constructor de mapas, herramientas de geoprocesamiento...

En definitiva, todo aquello que se necesita para poder trabajar con información vectorial.

El proyecto gvSIG continúa trabajando en la mejora de esta línea, desarrollando herramientas avanzadas de SIG vectorial, que ampliarán la potencia de gvSIG en este campo. Dentro de esta línea veremos nuevas herramientas de simbología y etiquetado avanzado, incluyendo un constructor de símbolos, gestión de redes, diagramas, informes y soporte de nuevos formatos como los propios de MapInfo, conexión a ArcSDE, etc.

de acceso, localización y búsqueda de información espacial. Este apartado se ampliaría con el desarrollo de herramientas que permitieran la publicación de datos según estándares.

gvSIG+CAD. d Proyecto que busca prescindir del uso de he-rramientas CAD de modo independiente a las herramientas SIG, llevando a cabo el desarrollo de funciones de edición cartográfica avanzada dentro del propio gvSIG.

gvSIG raster. d Con el abaratamiento de las imágenes satéli-te, ortofotos, etc., así como con el acceso a una multitud de datos raster ubicados en servidores remotos y accesibles mediante estándares OGC, se amplían las posibilidades de acceso a información raster y, por tanto, se plantea el de-sarrollar funciones para su análisis dentro de gvSIG. Ade-más, esta línea de trabajo permitirá la integración con otro proyecto de Software Libre orientado al análisis territorial, denominado SEXTANTE1.

gvSIG 3D. d Consiste en añadir la tercera dimensión como una forma adicional de analizar el territorio, incluyendo en este apartado funciones relacionadas con la animación y si-mulación.

gvSIG vectorial avanzado. d Es la evolución directa de la primera fase, complementándola con herramientas avanza-das de gestión de cartografía en formato vectorial, como es la construcción de simbología espacial o la dotación al gvSIG de la capacidad de generar informes de manera au-tomática.

gvSIG mobile. d gvSIG para dispositivos móviles, comple-mentando al cliente de escritorio y permitiendo llevar el SIG al campo para la toma y comprobación de datos.

Pasamos a continuación a describir con más detalle la capacidad técnica lograda en cada una de estas áreas.

1 SEXTANTE (Sistema Extremeño de Análisis Territorial) es un proyecto desarrol-lado por la Universidad de Extremadura y financiado por la Junta de Extremadura, y que se distribuye con licencia GNU/GPL.

Page 55: Gvpontis Cast

54

Experiencia deintegral

migracióna software libre

INSPIRE3, con la que el proyecto mantiene una estrecha relación en forma de colaboración directa con la Dirección General que la promueve (Joint Research Centre).

La Directiva INSPIRE reconoce el hecho de que la mayoría de la información espacial de calidad se produce y está disponible a nivel local y regional, pero que dicha información es difícil de utilizar en un contexto más amplio. Los problemas más importantes de la situación de la información espacial en Europa son la fragmentación, la falta de información homogénea entre estados miembros, la duplicación de esfuerzos en la creación de la información y problemas para identificar la información existente y poder acceder a la que está disponible.

Para poder hacer frente a estos problemas INSPIRE define una serie de principios fundamentales, los cuales serán seguidos al construir el sistema y los datos en él contenidos. Estos principios se resumen en la siguiente tabla:

Principios de INSPIRE >

3 El objetivo principal de la Directiva Europea 2007/2/EC del 14 de marzo de 2007 INSPIRE (INfrastructure for SPatial InfoRmation in Europe) es el de proporcionar información geográfica relevante, homogénea y de calidad con el fin de dar soporte a la formulación, implementación y evaluación de las políticas comunitarias.

16.1.2. gvSIG como cliente de Infraestructura de Datos Espaciales. INSPIRE

gvSIG es un proyecto que ha decidido apostar desde sus primeros pasos por la interoperabilidad y el seguimiento de estándares, que en el caso de información espacial vienen marcados por el OGC2, consorcio formado principalmente por compañías privadas, organizaciones gubernamentales y universidades, y del cual el proyecto gvSIG, por medio de la CIT, es miembro. gvSIG es una de las primeras herramientas SIG que comenzó a implementar estos estándares, por delante, incluso, de las aplicaciones privativas más extendidas del mercado.

Además de por principios de interoperabilidad, el seguimiento de estándares es básico para llevar a cabo la directriz europea

2 El OGC (Open Geospatial Consortium) es un consorcio industrial cuyos miembros trabajan en un proceso colaborativo y consensuado para mejorar y conseguir la interoperabilidad en el campo de las geotecnologías. La visión del OGC es un mundo en el que todos se beneficien de servicios e información espacial dispo-nibles a través de cualquier red, aplicación o plataforma. La misión del OGC es la de proporcionar interfaces espaciales y especificaciones de codificación de forma abierta y públicamente disponibles para su uso generalizado y que se materializa en las OpenGIS Specifications. Es decir, OGC no produce estándares sino espe-cificaciones técnicas, de forma similar al W3C. El OGC fue creado en 1994 para ayudar a la industria SIG a escapar del aislamiento en el que se estaba quedando en el contexto más general de las Tecnologías de la Información.

Vista de gvSIG con acceso a datos vectoriales. >

Los datos deben ser recogidos sólo una vez y ser dmantenidos en el nivel donde se logre efectividad.

Debe ser posible combinar IG con total continuidad dpara toda Europa desde fuentes diversas, y compartirla entre usuarios y aplicaciones.

Debe ser posible que la información recogida en un dnivel sea compartida por otros niveles.

La IG debe ser abundante y disponible bajo dcondiciones que no inhiban su uso extensivo.

Debe ser fácil descubrir la IG disponible, y en qué dcondiciones puede conseguirse y usarse.

Los datos geográficos deben ser fáciles de entender e dinterpretar, y ser seleccionables amigablemente.

Page 56: Gvpontis Cast

gvSIG: evolución hasta la solución actual

55

16

WMS d es el acrónimo de Web Map Service. Produce ma-pas de datos espaciales referidos de forma dinámica a partir de información geográfica. Este estándar internacional de-fine un “mapa” como una representación de la información geográfica en forma de un archivo de imagen digital conve-niente para la exhibición en una pantalla de ordenador. Un mapa no consiste en los propios datos. Los mapas produ-cidos por WMS se generan normalmente en un formato de imagen como PNG, GIF o JPEG.

En gvSIG podremos acceder a estos servicios WMS y car-gar estas imágenes de mapa como una capa más.

WFS d es el acrónimo de Web Feature Service. Si el WMS utiliza formatos raster (PNG, GIF, JPEG) para compartir las capas, el estándar WFS utiliza GML, Geography Markup Language. El WFS permite el acceso avanzado a informa-ción vectorial, lo que se traduce en gvSIG en poder traba-jar con los datos como si fuera información vectorial local, realizando análisis, leyendas temáticas, geoprocesamientos, etc.

WCS d es el acrónimo de Web Coverage Service. En este caso la información son capas raster en formatos SIG ori-ginales. Con gvSIG podremos cargar estas capas, normal-mente imágenes satélite u ortofotos, y realizar las acciones propias que gvSIG permite sobre cualquier capa raster.

Así pues, gvSIG permite, como cliente IDE, añadir, cruzar con información local, y trabajar con capas remotas de distintos orígenes en cualquiera de las variantes propuestas por el Open Geospatial Consortium (OGC), WMS, WFS y WCS.

Además de estos servicios, dentro de la Infraestructuras de Datos Espaciales podemos encontrar lo que se denominan servicios de descubrimiento que, como su nombre indica, nos van a servir para encontrar información que cumpla unos criterios de búsqueda.

Existen dos servicios de descubrimiento para las IDE, ambos implementados en gvSIG:

De acuerdo a estos principios, INSPIRE visiona una red distribuida de repositorios de información, unidos por estándares y protocolos que aseguren la compatibilidad e interoperabilidad de los datos y servicios geoespaciales. De esta forma, al asegurar que los datos y servicios electrónicos residen en organizaciones regionales y nacionales y que se implementan con estándares comunes, estos deben ser fácilmente accesibles y pueden ser combinados independientemente de fronteras administrativas, creando con ello la parte técnica de la IDE.

Para poder alcanzar la armonización de las distintos IDE Nacionales existe un grupo de trabajo encargado de definir la arquitectura y estándares de INSPIRE. En España ese grupo de trabajo está coordinado por el Instituto Geográfico Nacional y el proyecto gvSIG, por medio de la Conselleria de Infraestructura y Transportes, es miembro de oficial del grupo de trabajo, así como de algunos subgrupos destacados como el de UNSDI (Infraestructura de Datos Espaciales de Naciones Unidas).

Dentro de la arquitectura de INSPIRE, gvSIG juega el papel de cliente pesado o rico de acceso a información espacial.

gvSIG, como cliente avanzado de las IDE, pasa a formar parte de una familia de programas que permiten montar el sistema IDE en Software Libre. Existen aplicaciones como MapServer, GeoServer, Deegree, PostGIS o Geonetwork, que junto con gvSIG ponen a nuestra disposición un abanico de posibilidades, en definitiva, de elección, para no estar subordinados al software privativo.

gvSIG se desarrolla alrededor del concepto de Sistema Integral de Información Geoespacial. Esto significa que en gvSIG podemos encontrar una gran variedad de herramientas para analizar, gestionar y trabajar con información geoespacial de todo tipo.

El ser un cliente IDE va a permitir que no sea discriminatorio el origen de los datos a la hora de aplicar esas herramientas, permitiendo trabajar tanto con datos remotos como locales.

gvSIG es cliente compatible con varias especificaciones de interfaces OGC: WMS, WFS, WCS, catálogo y nomenclátor.

Page 57: Gvpontis Cast

56

Experiencia deintegral

migracióna software libre

Actualmente el proyecto gvSIG sigue evolucionando la rama de cliente IDE, con el fin de soportar nuevos estándares y facilitar el trabajo con el resto de piezas de una IDE.

Así, recientemente se ha desarrollado el estándar WFS-T y una extensión de publicaciones, cuyo objetivo es poder exportar las Vistas de gvSIG a los distintos servidores de mapas libres del mercado, según los estándares OGC.

16.1.3 gvSIG como editor de cartografía

Como se ha comentado en apartados anteriores, un programa de CAD es un programa de diseño asistido por ordenador. Como tal, un CAD tiene multitud de usos, desde el diseño industrial al arquitectónico, pasando por la edición de cartografía. En gvSIG el objetivo no era crear un CAD, sino implementar, dentro de la aplicación, aquellas herramientas necesarias para permitir edición cartográfica rigurosa, eliminando la dependencia de cualquier programa de CAD.

Así, gvSIG dispone de herramientas de edición vectorial que permiten modificar, crear y eliminar elementos. Desde gvSIG podemos editar un fichero shape, una capa de nuestra base de datos espacial o un fichero CAD.

En todo momento gvSIG tiene en mente al usuario como cliente final y, por tanto, se intenta que las distintas funciones que va integrando sean de fácil uso y no supongan una ruptura con los hábitos del usuario. Por ello, en la parte CAD se ha habilitado una consola de comandos que permite trabajar de forma muy similar a alguno de los programas más extendidos del mercado.

gvSIG implementa herramientas de ayuda al dibujo, desde las rejillas o los comandos de deshacer, como la pila de comandos, a selecciones complejas de elementos (dentro de círculo, fuera de rectángulo…).

gvSIG dispone de herramientas para la inserción de elementos, como puntos, polígonos, líneas, elipses, etc., del mismo modo que dispone de herramientas para la modificación de los mismos, como la rotación de elementos o la simetría.

1. Servicio de Catálogo. Nos va a permitir la búsqueda de re-cursos cartográficos mediante campos clave como nombre, escala, tema…devolviendo una lista de metadatos (datos que definen los recursos cartográficos) coincidentes. El acceso a estos recursos puede ser directo, cargándolo gvSIG como una capa, o indirecto, mostrando una referencia del modo de obte-ner ese recurso. Por tanto, al utilizar gvSIG como cliente de ca-tálogo, introduciendo unos criterios de búsqueda, la aplicación nos devolverá como resultado aquellos recursos, ubicados en el servidor indicado, que los cumplen.

2. Servicio de nomenclátor. Un nomenclátor, en nuestro caso, es una lista de topónimos georreferenciados, es decir, una lista en el que cada topónimo contiene información de las coorde-nadas geográficas donde se ubica. Con gvSIG podemos utili-zar el servicio de nomenclátor para buscar la ubicación de un determinado topónimo, devolviéndonos la aplicación un zoom a la zona geográfica a la que se refiere dicho topónimo.

Además de poder trabajar con los estándares, gvSIG implementa servicios no estándar, como el ArcIMS de ESRI o el ECWP. gvSIG permite interoperar los distintos servicios IDE dentro de un cliente SIG avanzado, poniendo a disposición del usuario las herramientas necesarias para cubrir desde las necesidades básicas de consulta a las complejas de análisis espacial.

Vista de gvSIG con acceso a distintos servicios estándar WMS. >

Page 58: Gvpontis Cast

gvSIG: evolución hasta la solución actual

57

16

Algunas de sus utilidades son: análisis de puntos, análisis de patrones, análisis hidrológico básico, estadísticas de celda para múltiples capas raster, estadísticas por vecindad para una capa raster, geoestadística, geomorfometría y análisis del relieve, herramientas básicas de análisis y cálculo para capas raster, herramientas para capas discretas e información categórica, iluminación y visibilidad, perfiles, índices de vegetación e hidrológicos, etc., ampliando con cada nueva versión el número de funcionalidades.

16.1.5 gvSIG como herramienta de análisis territorial en tres dimensiones

Esta rama del proyecto gvSIG tiene como objetivo disponer de aquellas funcionalidades de 3D y animación que permitan convertirlo en una herramienta con capacidad de presentar y analizar información de manera efectiva y atractiva.

Para conseguir este objetivo se está extendiendo gvSIG para que sea capaz de trabajar en tres dimensiones con datos masivos de tipo raster o vectorial, incluyendo servicios remotos y formatos comunes para objetos 3D, y también trabajar con imágenes y datos vectoriales organizados en series temporales, o con atributos que indican su rango temporal, que requieren de una presentación animada para su mejor comprensión.

Es interesante reseñar que, normalmente, se aborda el mundo del SIG y del CAD como contrapuestos, cuando son, en realidad, complementarios. Por eso, desde gvSIG lo que se busca es su integración.

En próximas versiones aparecerán nuevas herramientas de CAD, que completen a las actuales (alargar, recortar, autocompletar polígonos, etc.) y que vayan consolidando a gvSIG como una herramienta destacada para la edición cartográfica de precisión.

16.1.4 gvSIG como SIG raster y herramienta de teledetección

gvSIG disponía, en sus primeras versiones, de unas pocas herra-mientas propias de un Sistema de Información Geográfica raster, que en las últimas versiones han aumentado considerablemente.

Actualmente en gvSIG disponemos de funciones básicas de SIG raster, funciones de visualización y análisis visual (histogramas, filtros, tablas de color…), funciones de tratamiento digital de imágenes (álgebra de mapas, funciones de transformación, fusión de imágenes…), funciones de análisis espacial (funciones estadísticas, generación de modelos digitales del terreno, interpolación de superficies, perfiles de imagen…) y funciones de análisis temporal/multi/hiperespectral.

Como parte del SIG, raster se ha preparado gvSIG para llevar a cabo su integración con el proyecto SEXTANTE. Esta colaboración ha permitido a gvSIG disponer de más de doscientas funciones de análisis adicionales orientadas, principalmente, al estudio de modelos digitales del terreno y a la hidrología.

Inicialmente se desarrolló sobre el núcleo de SAGA, y que en sus últimas versiones ha migrado a gvSIG, enriqueciéndose mutuamente ambos proyectos.

SEXTANTE es un software de procesamiento de información geográfica, que se centra principalmente en el modelado y análisis de la información mediante imágenes raster, aunque dispone también de un buen número de funciones para trabajar con datos vectoriales.

SEXTANTE en gvSIG. >

Page 59: Gvpontis Cast

58

Experiencia deintegral

migracióna software libre

16.2 el proceso desde un punto de vista no técnico

Tras describir la evolución técnica del producto hasta llegar a la versión actual, pasamos a comentar otras tareas llevadas a cabo:

Jornadas gvSIG. d Realización de unas jornadas anuales del proyecto como punto de encuentro de la comunidad de usuarios y desarrolladores de gvSIG.

Difusión. d Acciones que tienen como objetivo dar a conocer el proyecto gvSIG, tanto en el mundo tradicional de usuarios de los Sistemas de Información Geográfica como en aque-llos que siendo usuarios potenciales, no habían llegado a utilizar este tipo de tecnologías. Estas acciones incluyen la publicación de artículos, difusión de noticias, presentación de ponencias en congresos, etc.

Creación de espacios para la comunidad. d Acciones que persiguen el habilitar espacios para la puesta en contacto de la comunidad: creación de listas de distribución, espacios web para catálogo de proyectos no oficiales, etc.

Relación interadministrativa. d Relaciones con otras admi-nistraciones y universidades que querían utilizar el proyecto, que en algunos casos se ha formalizado por medio de con-venios.

Cada uno de estos apartados conlleva una serie de subtareas y procedimientos que están documentados y accesibles para usuarios con permisos en la web:

www.gvsig.org/

16.1.6 gvSIG mobile: un SIG para dispositivos móviles

Ésta es la última rama de trabajo que se ha comenzado dentro del proyecto gvSIG, y que tiene como objetivo dotar a gvSIG de aquellas funcionalidades que le permitan su integración en dispositivos móviles, como teléfonos, ordenadores de mano (PDA) y Tablet PC. Hay disponible una primera versión piloto y gradualmente, durante los próximos meses, serán publicadas nuevas versiones gvSIG para dispositivos móviles.

Existe una hoja de ruta pública en la web de gvSIG que describe todas las funcionalidades implementadas, así como las que se encuentran implementándose en gvSIG:

www.gvsig.gva.es/index.php?id=funcionalidades&L=0

Así mismo, todo el proceso técnico, que incluye tareas como desarrollo, testing, documentación..., está documentado y de acceso público en la web:

www.gvsig.org/

Vista de gvSIG con acceso a distintos servicios estándar WMS. >

Aspecto de >gvSIG Mobile.

Page 60: Gvpontis Cast

gvSIG: evolución hasta la solución actual

59

16

En palabras de Don Gaspar Peral Ribelles, subsecretario de la Conselleria de Infraestructuras y Transporte:

“En tan sólo cuatro años las jornadas de gvSIG se han convertido en un referente internacional en el mundo de los Sistemas de Información Geográfica y de las Infraestructuras de Datos Espaciales”.

Otro de los indicadores del éxito de las Jornadas y, por tanto, del proyecto es el número de patrocinadores y colaboradores con el que cuenta. Un indicador importante, además, por marcar el crecimiento del tejido empresarial directamente relacionado con la inclusión de gvSIG como parte del modelo de negocio de las empresas.

Las jornadas de gvSIG han contado, en estos años, con la participación de ilustres ponentes como Max Craglia, responsable de INSPIRE en el Joint Research Centre de la Comisión Europea.

Toda la información de las 4as Jornadas, así como de las anteriores, se puede encontrar en:

www.jornadasgvsig.gva.es

El estudio de los resultados obtenidos como fruto de estas tareas nos da unos indicadores de la evolución del proyecto que conviene conocer.

16.2.1 Jornadas gvSIG

Las jornadas de gvSIG se han celebrado en tres ocasiones, una por año desde el comienzo del proyecto. La cuarta edición tendrá lugar en diciembre de 2008 con el lema “Avanzando juntos”.

Las jornadas se plantearon con el objetivo de ser un punto de encuentro anual de la comunidad de gvSIG, y un reflejo de los avances del proyecto. Cada año ha aumentado considerablemente el número de participantes, tanto en cantidad como en diversidad. Si en las primeras jornadas los asistentes eran, principalmente, de la Comunidad Valenciana, en las terceras tuvimos asistentes de una gran variedad de países (Alemania, Francia, Venezuela, Italia...). Y si en las primeras jornadas se presentaba el proyecto gvSIG, en las últimas se presentó una diversidad de experiencias de empleo del mismo, desde el uso en la arqueología por la Universidad de Valencia a la gestión del urbanismo en Extremadura, pasando por la gestión del agua en Tanzania en zonas de difícil acceso a la misma. Para las jornadas de este año se prevé que asistan cerca de un millar de personas.

35

30

25

20

15

10

5

01as Jornadas gvSIG

evoluCión de paTroCinadores en las jornadas gvsig

2as Jornadas gvSIG 3as Jornadas gvSIG

600

500

400

300

200

100

0

1as Jornadas gvSIG“ Comparte el Conocimiento”

evoluCión de asisTenTes a las jornadas gvsig

2as Jornadas gvSIG “Construyendo realidades”

3as Jornadas gvSIG “Consolidar y Avanzar”

Page 61: Gvpontis Cast

60

Experiencia deintegral

migracióna software libre

Publicación de artículos. d Las principales revistas de tec-nología SIG y software, tanto nacionales como internacio-nales, han dedicado espacios a publicar artículos sobre el “fenómeno gvSIG”, como llegó a ser descrito en la revista “Directions Magazine”. Algunas de estas revistas son: “Auto-CAD Magazine” (España), “Mapping” (España y Latinoamé-rica), “GIS Business” (Alemania), GIS Development (Mun-dial), GEOinformatics (Europa), GIM internacional (Europa y Norteamérica), TodoLinux (España), Revista IGP (Portugal), etc. En libros como los de las Jornadas de Infraestructuras de Datos Espaciales de España de 2006 y 2008, se le ha dedicado un capítulo al proyecto.

noticias en prensa. d La aparición de gvSIG en distintos medios de prensa, principalmente especializados, ha sido constante y abundante. El medio millón de entradas en Go-ogle son un indicador de ello y se estima que ha aparecido en más de un centenar de medios distintos, tanto de presa digital como escrita.

Google trends. d Una herramienta de Google que marca las tendencias de búsqueda de los usuarios y de aparición de un “término” en la red, en nuestro caso gvSIG, es otro indi-cador a evaluar para ver la difusión del proyecto.

En el siguiente gráfico tenemos una comparación de tendencias con uno de los programas privativos de SIG clásicos y más difundidos (Geomedia):

16.2.2 Difusión gvSIG

La difusión de gvSIG ha sido parte fundamental para extender el uso del proyecto. Ésta conlleva una gran variedad de acciones como:

Asistencia a eventos. d Congresos, jornadas, seminarios, talleres, charlas en las universidades... La entidad del pro-yecto gvSIG respecto a su participación en eventos ha ido aumentado, del mismo modo que aumentaban las capacida-des de la aplicación. Si bien los dos primeros años la parti-cipación estuvo concentrada en eventos nacionales, en los últimos años gvSIG ha sido presentado en diversos países del mundo, en muchos casos como proyecto principal. To-das las ponencias se encuentran disponibles en:

www.gvsig.gva.es/index.php?id=ponencias

3as Jornadas de gvSIG. Palacio de Congresos. >

gvSIG (azul) en comparación con Geomedia (rojo) en Google Trends. >

Page 62: Gvpontis Cast

gvSIG: evolución hasta la solución actual

61

16

En un primer estadio gvSIG era usado por un número míni- dmo de usuarios de la CIT, que gradualmente fue avanzando hasta superar considerablemente a los usuarios iniciales de tecnologías SIG; de los 90 usuarios iniciales en la actua-lidad hay más de 400 en el seno de la conselleria.

En una segunda fase fue adoptándose en otras consellerias dcomo la Conselleria de Medio Ambiente, Agua, Urbanismo y Vivienda, la Conselleria de Industria, Comercio e Innovación o la Conselleria de Educación. En definitiva, pasó a ser lo que se denominó como “el SIG libre de la Generalitat”.

En una tercera etapa se extendió su uso a una amplia varie- ddad de administraciones, a nivel mundial, de un número cre-ciente: Ayuntamiento de Munich, Centro Nacional de Tecno-logías de la Información de Venezuela, Instituto Geográfico Nacional Agustín Codazzi de Colombia, Instituto Geográfico Militar de Argentina, Joint Research Centre de la Comisión Europea, EMSHI, Ayuntamiento de Valencia, Ministerio de Fomento, Gobierno Vasco, Colegio de Registradores de la Propiedad, Cabildo Insular de La Palma, etc.

Además de su introducción en la Administración Pública, gvSIG se está convirtiendo en una herramienta cada vez más usada en el ámbito universitario. Algunas de las universidades directamente relacionadas con el proyecto son la Universidad Politécnica de Valencia, Universidad Jaume I, Universidad de Castilla-La Mancha, Universidad Politécnica de Madrid, Universidad de Girona, Universitat Oberta de Catalunya, Universidad de la Patagonia, Universidad de Rennes, Univesidad de Salzburgo...

Otras organizaciones, como Ingeniería Sin Fronteras o Geógrafos Sin Fronteras, son usuarios del proyecto y lo utilizan en las acciones de cooperación que llevan a cabo en países de África y Latinoamérica.

Todo ello ha conllevado una serie de tareas orientadas a mantener una relación de colaboración con dichos organismos. Muchos de estos usuarios no sólo utilizan gvSIG como tal, sino que, bien por medios propios o mediante empresas, están desarrollando

16.2.3 Creación de espacios para la Comunidad gvSIG

En este área se ha optado por las siguientes acciones:

Abrir el proyecto a la Comunidad d , no sólo distribuyendo binarios y fuentes, sino dando acceso a toda la información po-sible. Ésta se encuentra en las dos páginas web del proyecto:

www.gvsig.gva.es y www.gvsig.org

Habilitar espacios de intercambio de información y dsoporte. Para ello se crearon tres listas oficiales, una lista internacional en inglés (medio millar de usuarios) y dos en castellano para usuarios y desarrolladores (más de un millar de usuarios). Recientemente se ha habilitado un espacio para la lista en italiano del proyecto, administrada por la propia co-munidad (cuenta ya con más de un centenar de usuarios).

Creación de un catálogo de proyectos. d Un espacio don-de aquellos que quieran realizar aportaciones no oficiales puedan hacerlo y ponerlas en conocimiento de la comuni-dad, ya sean desarrollos, manuales, etc. El catálogo de pro-yectos se puede consultar en:

https://gvsig.org/web/plugins/downloads

Soporte a la internacionalización. d Aquellos voluntari-os de la comunidad que quieran disponer de gvSIG en su idioma, lo pueden hacer de manera muy sencilla. Desde el proyecto se les mandan los ficheros e instrucciones para que lo lleven a cabo. gvSIG está ya disponible en más de una decena de idiomas (inglés, castellano, valenciano, fran-cés, portugués, chino, alemán...) y se está llevando a cabo la traducción de la aplicación en diez nuevos idiomas (ruso, japonés, griego...).

16.2.4 Relaciones interadministrativas del proyecto

El proyecto ha seguida la siguiente evolución:

Page 63: Gvpontis Cast

62

Experiencia deintegral

migracióna software libre

personalizaciones y mejoras de la aplicación adaptadas a sus necesidades. Ejemplos de esto último tenemos en la propia CIT, en la que se han desarrollado proyectos como la personalización de gvSIG para la División de Puertos y Costas para llevar a cabo la

Países con descargas de gvSIG (en amarillo). >

gestión costera, o la de Seguridad Vial para la gestión de toda la infraestructura de carreteras. El siguiente mapa muestra aquellos países en los que se han producido descargas de la aplicación gvSIG:

Page 64: Gvpontis Cast

63

Como conclusiones principales podemos decir que: El proyecto gvSIG ha conllevado el conocimiento de las d In-fraestructuras de Datos espaciales dentro de la CIt, se ha implementado la propia, como un nodo de la IDE de España y acorde a la directiva europea INSPIRE. Esto ha permitido optimizar la gestión de la información espacial, pa-sando de trabajar con ficheros a trabajar con bases de datos espaciales y estándares.

El proyecto ha sido adoptado por la Generalitat primero y por dla comunidad de Software Libre después, convirtiéndose en una herramienta de referencia a nivel internacional.

La d Comunidad Valenciana se ha convertido en un cen-tro de referencia de la Geomática Libre, y con ello las em-presas y universidades valencianas que están desarrollando el proyecto.

Ha aumentado el número de usuarios de tecnologías SIG/ dCAD en la CIT, pasando de 90 a 400. No sólo se han cu-bierto las necesidades, sino que el SIG ha llegado a conver-tirse en una herramienta transversal, cada vez más usada en la conselleria.

Ha aumentando el d nivel de uso de los SIG en la CIT. Los usuarios actuales disponen cada vez de más herramientas, y si bien en el inicio del proyecto el 90% de los usuarios usaba sólo un 10% de éstas, este último porcentaje está aumentando y cada vez se dan más y más usos a gvSIG. Ha aumentado el número de usuarios pero parejo a ello ha au-mentado también el nivel de conocimiento de los usuarios.

gvSIG: conclusiones

CA

PÍTU

LO 17

Page 65: Gvpontis Cast

64

Las próximas líneas de actuación siguen dos premisas fundamentales:

Seguir evolucionando gvSIG. d Añadiendo nuevas herramien-tas que se integren con las actuales, como son: las propias de las aplicaciones de topografía, las de gestión de infraestructu-ras viarias, geoestadística o sensores, que permitirán ampliar todavía más el uso de estas tecnologías y la optimización de la gestión del territorio, tan fundamental en las administraciones públicas y en concreto en la CIT.

Fomentar la colaboración. d Continuar fomentando la comu-nidad gvSIG, la participación de cada vez más actores que co-laboren en la construcción del proyecto. De nuevo, en palabras de Don Gaspar Peral Ribelles:

“El lema de estas jornadas es el de: gvSIG. Avanzando Juntos. Recordamos que las anteriores jornadas fueron con el lema Consolidar y Avanzar, en ellas la reflexión que planteábamos era la siguiente: gvSIG había crecido mucho y muy rápido, era el momento de poner orden, de consolidar todo ese crecimiento de manera que nos permitiera seguir avanzando. Pues bien, ya estamos preparados para seguir avanzando. Nuestra propuesta ahora no es la de construyamos ese nuevo camino. Que nos veamos, que hablemos entre nosotros, que intercambiemos ideas, opiniones, etc., con la finalidad de seguir avanzando. Pero como decimos en el lema de las jornadas: Avanzando juntos”.

gvSIG: próximas líneas de actuación

CA

PÍTU

LO 18

Page 66: Gvpontis Cast

65

Proyecto gvPONTIS d

http://www.gvpontis.gva.es

Proyecto gvSIG d

http://www.gvsig.gva.es

Proyecto MOSKitt d

http://www.moskitt.org

IDABC d

http://ec.europa.eu/idabc

Wikipedia d

http://es.wikipedia.org

Referencias

Page 67: Gvpontis Cast

66

GlosarioACID

Atomicidad, Consistencia, Aislamiento y Durabilidad. En bases de datos se denomina ACID a un conjunto de características necesarias para que una serie de instrucciones puedan ser consideradas como una transacción.

BDC Backup Domain Controller.

BInD Berkeley Internet Name Domain.

BPMn Business Process Modeling Notation. Representación gráfica para el flujo de trabajo de procesos.

BPMS Business Process Management.

CAD Diseño asistido por computador.

CASe

Computer Aided Software Engineering. Aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en términos de tiempo y de dinero.

CIt Conselleria de Infraestructuras y Transporte.

CMS Sistema de Gestión de Contenidos.

CVSConcurrent Versioning System, es una aplicación informática que implementa un sistema de control de versiones.

DnS Domain Name System.

DSDM Desarrollo Dirigido por Modelos.

eMP Eclipse Modeling Project.

eSRIEnviromental Systems Research Institute. Empresa dedicada al desarrollo y comercialización de Sistemas de Información Geográfica.

eVS Estudio de Viabilidad del Sistema.

GB Gigabyte. Unidad de medida informática.

GDALGeospatial Data Abstraction Library. Biblioteca de software para la lectura y escritura de formatos de datos geoespaciales.

GnU/GPLGeneral Public License. Licencia orientada principalmente a proteger la libre distribución, modificación y uso de software.

GPLGeneral Public License. Licencia orientada principalmente a proteger la libre distribución, modificación y uso de software.

HtML HyperText Markup Language. Lenguaje de marcado predominante para la construcción de páginas web.

IDe Entorno de Desarrollo Integrado.

IDe Infraestructuras de Datos Espaciales.

IDe Integrated device Electronics. Controla los dispositivos de almacenamiento masivo de datos.

IPP Internet Printing Protocol.

ISO8859-1 Norma de la ISO que define la codificación del alfabeto latino.

JDBCJava Database Connectivity. Es una API que permite la ejecución de operaciones sobre bases de datos desde el lenguaje de programación Java.

JSF JavaServer Faces framework para aplicaciones web en Java EE.

KDe K Desktop Environment. Es un entorno de escritorio e infraestructura de desarrollo para sistemas Unix/Linux.

LAMPConjunto de subsistemas software necesarios para alcanzar una solución global. Estos son Linux, Apache, MySQL y PHP.

LAn Local Area Network. Red de área local.

Page 68: Gvpontis Cast

67

LDAPLightweight Directory Access Protocol. Protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido.

MDA Model Driven Architecture.

MDD Model-driven Development.

MVC

Modelo Vista Controlador. Patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos.

MySQL Sistema de gestión de base de datos relacional, multihilo y multiusuario.

ODBC Open Database Connectivity. Estándar de acceso a Bases de Datos.

ODBC/OLeObject Linking and Embedding, Database.Tecnología desarrollada para tener acceso a diferentes fuentes de información, o bases de datos, de manera uniforme.

OGC Open Gis Consortium.

OLtPProcesamiento de Transacciones En Línea. Tipo de sistemas que facilitan y administran aplicaciones transaccionales.

PC Personal Computer. Ordenador personal.

PDC Primary Domain Controler

PDFPortable Document Format. Formato portátil de documento. Formato de almacenamiento de documentos.

PHP PHP Hypertext Pre-processor. Lenguaje de programación interpretado.

PostgreSQLPostgreSQL es un servidor de base de datos relacional orientada a objetos de Software Libre, publicado bajo la licencia BSD.

SAtASerial Advanced Technology Attachment. Interfaz de transferencia de datos entre la placa base y algunos dispositivos de almacenamiento

SGBDSistemas de gestión de base de datos. Software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan.

SIG Sistema de Información Geográfica.

SQL Lenguaje de consulta estructurado.

tCP/IP

Transmission Control Protocol / Internet Protocol. Conjunto básico de protocolos de comunicación de Internet que permiten la transmisión de información en redes de computadoras.

UMLLenguaje Unificado de Modelado. Lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software.

UnSDI Infraestructura de Datos Espaciales de Naciones Unidas.

UtF-8Unicode Transformation Format. Norma de transmisión de longitud variable para caracteres codificados utilizando Unicode.

VnCVirtual Network Computing. Nos permite tomar el control del ordenador servidor remotamente a través de un ordenador cliente.

WAn Wide Area Network o red de área amplia.

WCS Web Coverage Service.

WFS Web Feature Service.

WMS Web Map Service.

XML Extensible Markup Language.

Page 69: Gvpontis Cast

Experiencia deintegral

migracióna software libre