Universidad de CórdobaServicio de Sistemas de Gestión

Aplicaciones Microinformáticas

Proyecto MAGO

Introducción.

A principios de 2008 la Universidad de Córdoba inicia un proyecto para desple-gar escritorios corporativos basados en Linux en todos los puestos de trabajo centralizados de su personal de administración y servicios. Este despliegue permtió mejorar los procedimientos de administración y, como consecuencia, los servicios de soporte a los usuarios.

Sin embargo, el proceso evidenció la necesidad de prestar una mayor atención al uso que se estaba haciendo de soluciones microinformáticas, muy particular-mente herramientas como Microsoft Access.

Aplicaciones microinformáticas.

No es fácil definir qué entendemos por Aplicación Microinformática. En gene-ral, hace referencia a una aplicación de alcance limitado, que se utiliza a nivel departamental, es decir por una o dos personas, que no comparte datos con las Aplicaciones Corporativas y que está desvinculada de los procedimientos habi-tuales de administración de sistemas (seguridad, copias, disponibilidad,...).

Tradicionalmente estas aplicaciones surgen como respuesta a una demanda no satisfecha por el Servicio de Informática. Ante una necesidad de automatización el usuario busca una alternativa local. Al principio, la programación de estas aplicaciones era costosa y estaba ligada a la existencia de un usuario con cono-cimientos informáticos.

Con el desarrollo y popularización de herramientas como Microsoft Office, la creación de Aplicaciones Microinformáticas se hace más accesible.

La escasez de recursos informáticos y las exigencias de horas de programación de las Aplicaciones Corporativas hace que el Servicio de Informática vea con buenos ojos la colaboración de estos usuarios y, en ese entendimiento, contribu-ye a la capacitación de los mismos en los diferentes Planes de Formación.

Problemática de las Aplicaciones Microinformáticas.

La respuesta ideal a las necesidades de los usuarios es la automatización de sus procesos con herramientas de desarrollo corporativas, de probada eficacia y  di­

Proyecto MAGO Abril 2012 1/11

señadas por especialistas con parámetros de calidad. Estas aplicaciones se des­pliegan como módulos de las Aplicaciones Corporativas ya existentes o como nuevas aplicaciones pero perfectamente integradas.

Sin embargo esto no es siempre posible y la existencia de un número reducido de Aplicaciones Microinformáticas puede considerarse como una situación ad­misible.

La migración de los escritorios corporativos a entorno Linux puso de manifies­to  una situación desconocida  por   su magnitud:   la  existencia  de docenas  de Aplicaciones Microinformáticas desarrolladas y mantenidas por los usuarios, algunas de considerable complejidad.

Los problemas que presenta el uso indiscriminado de este tipo de aplicaciones son muchos. Podemos destacar:

El diseño de las aplicaciones puede no ser el más adecuado, bien por limi­taciones de la herramienta utilizada o bien por desconocimiento técnico del desarrollador.

Nos encontramos conjuntos de datos aislados, cuya existencia no es siem­pre conocida por la dirección pero que su importancia es relevante para el buen funcionamiento de un servicio.

Esto hace que los datos presenten incoherencias, estén incompletos o mal validados.

Dificulta la gestión del dato único ofreciendo cada servicio información diferente según sus fuentes de datos. Es difícil correlacionar estos datos con los corporativos, incluso para personal especializado, debido a la no utilización de técnicas habituales de bases de datos.

El mantenimiento de la aplicación es muy personalizado haciendo que, en muchas ocasiones, el traslado de la persona que la ha diseñado dificulte la continuidad de las tareas que se apoyaban en la misma.

Muchas aplicaciones mueren de éxito. En los niveles iniciales cumplen su cometido por lo que se complica su diseño buscando un mayor alcance, algo que no es posible con estas herramientas.

No se cumplen medidas habituales de protección de datos, integridad y seguridad, exponiendo la información y dificultando las Auditorías Infor­máticas, cada vez más comunes.

Microsoft Access y OpenOffice Base.

Encontrarnos con esta situación durante el proceso de migración de los Escrito­rios Corporativos supuso la búsqueda de una alternativa transitoria que permi­

Proyecto MAGO Abril 2012 2/11

tiera a los usuarios continuar con el trabajo en las Aplicaciones Microinformá­ticas hasta que se encontrara una solución satisfactoria.

La sustitución de hojas de cálculo no ha supuesto, en general, ningún problema salvo   en   algunas   situaciones   específicas.   Sin   embargo,   la   sustitución   de Microsoft Access por OpenOffice Base sí que ha sido bastante costosa.

OpenOffice Base es la alternativa natural en Linux a Microsoft Access. Sin embargo, el grado de madurez de la herramienta es muy inferior al resto de la suite OpenOffice. La aparición de nuevas versiones supuso un adelanto consi­derable sobre todo en aspectos como la estabilidad, pero no tanto en la usabili­dad.

La programación de varias baterías de cursos sobre OpenOffice Base nos ha permitido disponer de usuarios con unos niveles adecuados de formación en la herramienta, pero aún así dicha herramienta sigue presentando limitaciones.

Durante más de un año hemos migrado y mantenido todas las Aplicaciones Mi­croinformáticas que hemos encontrado. Hemos utilizado técnicas avanzadas, no accesibles a los usuarios finales, como la programación de scripts en Python o la utilización de Sun Report Builder.

Y a pesar de ello los usuarios no obtienen los beneficios de aplicaciones desa­rrolladas por profesionales dado que no se han utilizado herramientas adecua­das. Las aplicaciones siguen presentando muchas de las carencias que enume­rábamos en el punto anterior.

Las   Encuestas de Satisfacción, realizada en Febrero de 2010,   aunque no se centraba en estas Aplicaciones, vino a confirmar la necesidad de buscar alter­nativas.

Proyecto MAGO.

Dado que el Servicio de Sistemas de Gestión se estaba implicando en el desa­rrollo y mantenimiento de Aplicaciones Microinformáticas sin obtener los re­sultados deseados, nos planteamos la conveniencia de dedicar estos recursos y esfuerzos a buscar una alternativa real a Microsoft Access. Este fue el inicio del proyecto que, con cierta dosis de humor, hemos llamado Proyecto MAGO (Microsoft Office Goes Out).

La alternativa debía cumplir unos objetivos básicos:

Debe permitir  almacenar  los datos en gestores relacionales reales, prefe­rentemente en Oracle que es el gestor usado por las Aplicaciones Corpo­rativas.

Ha de estar orientada al desarrollo rápido de aplicaciones (RAD) y sería preferible que permitiese el prototipado de modo que se pueda obtener el 

Proyecto MAGO Abril 2012 3/11

feedback de los usuarios en las etapas más tempranas del desarrollo. Esto es importante dado que se trata de abordar Aplicaciones de pequeño al­cance en las que las fases de análisis y diseño son casi inexistentes.

Sería interesante que ofreciese la posibilidad de que los usuarios finales, no técnicos, pudiesen realizar cambios en la aplicación, especialmente en lo referente a generación de informes personalizados.

Debe capacitar el uso multiusuario de forma simultánea.

El acceso a la aplicación debe poderse hacer desde cualquier escritorio corporativo, preferentemente vía web y sin la instalación de software lo­cal. 

Con estos requisitos básicos las deficiencias del modelo anterior quedan subsa­nadas. Así, por ejemplo, el uso de un gestor de bases de datos Oracle nos per­mite seguir políticas de seguridad, integridad, disponibilidad,... idénticas a las empleadas en las Aplicaciones Corporativas. La integración con estas aplica­ciones, aunque no sea un requisito inicial, se facilita al estar los modelos de da­tos basados en la misma tecnología.

Con la tecnología actual se plantean dos alternativas básicas para la elección de herramienta: el uso de soluciones empresariales (tipo java o .net) o bien el uso de soluciones web (tipo PHP o Zope).

La experiencia acumulada en los últimos años por la Universidad de Córdoba hizo que nos decantáramos por tecnologías web, en especial para el despliegue de aplicaciones de alcance limitado como las que nos ocupan. El problema que presentan las tecnologías web es la existencia de numerosos  frameworks  in­compatibles entre sí, con dificultades para separar las capas de visualización de las capas de control y negocio  y con recorridos que, a veces, no llegan al año de vida.

Herramientas de desarrollo de Oracle.

Con casi  20  años  de  experiencia   satisfactoria   en  el  uso  de   las   tecnologías Oracle parece sensato que nuestro primer intento fuera buscar en el porfolio de este proveedor.

Sus recomendaciones fueron en la línea de usar java como base y el framework ADF como capa complementaria. Con el objetivo de sustituir las grandes Apli­caciones Corporativas parece que la recomendación puede ser acertada, pero para abordar pequeñas aplicaciones microinformáticas entendimos que era una tecnología excesivamente compleja.

Por ello buscamos alternativas soportadas por Oracle en el entorno web, como PHP o Zope, pero encontramos que no se amortizaban los conocimientos ad­quiridos   por   nuestros   programadores   durante   tantos   años   (básicamente 

Proyecto MAGO Abril 2012 4/11

PL/SQL) y que los ciclos de vida, modelización, separación de capas, estanda­rización,... no eran siempre los más adecuados, al menos sin frameworks auxi­liares.

Continuando con el análisis del porfolio de Oracle encontramos la evolución de una herramienta, HTMLDB, que, en 2007 sufre una reorientación clara hacia el mercado microinformático como alternativa creíble para la sustitución de Microsoft Access. La herramienta se llama actualmente Oracle Application Ex-press1.

Oracle Application Express.

Oracle Application Express (Apex) nació como HTML DB a principios de 2004. La tecnología base de esta herramienta ya la utilizamos en nuestra univer-sidad para la programación de los primeros portales web, como la Consulta de unidades de gasto. La trayectoria de esta herramienta no fue la más adecuada para nuestras necesidades por lo que finalmente cambiamos a otro framework de desarrollo web: Zope. Con él se han realizado aplicativos como la Automa-trícula o el portal del Investigador de Metis.

En 2006 se reorienta Apex hacia el desarrollo rápido y se empaqueta en Oracle XE, la versión de sobremesa del gestor Oracle. Pero no es hasta finales de 2007 cuando se da un nuevo cambio de rumbo apuntando hacia la sustitución de so-luciones ofimáticas tipo MS Access.

Si bien la estrategia comercial de Oracle durante años no contemplaba la poten-ciación de Apex, lo cierto es que la bondad de la herramienta, la capacidad del equipo de desarrollo que hay detrás de la misma y la actividad de la comunidad creada alrededor (4,6 millones de visitas a la semana), ha hecho que ésta evolu-cione de forma sorprendente en los últimos años.

La publicación de la versión 3.2 supuso el respaldo definitivo de Oracle, incluyendo funcionalidades que van más allá del uso casual que puede darle el programador mi-croinformático. Aún así Oracle mantiene sus reservas sobre la utilización de Apex en grandes proyectos, orientando la herra-mienta hacia la sustitución de aplicaciones microinformáticas, creación de aplicacio-nes departamentales con uso intensivo de datos o generación de listados. La publica-ción, en 2010, de la versión 4.0 consolidó la herramienta y ofreció una mayor con-

fianza en la misma para desarrollos de tamaño medio.

Como vemos en el gráfico, Oracle considera Apex una herramienta que puede satisfacer las necesidades del usuario final (tipo MS Access) pero también se

1 Información de referencia en: http://www.oracle.com/technetwork/developer-tools/apex/overview/index.html

Proyecto MAGO Abril 2012 5/11

puede emplear como herramienta RAD por programadores, con un alcance su-perior a otras alternativas RAD basadas en PHP o Python.

Según Oracle, Apex no llega al nivel de desarrollo empresarial necesario para desplegar Aplicaciones Corporativas pero es curioso que en los últimos gráfi­cos la propia Oracle incluya a Forms, su buque insignia durante años, con simi­lares niveles de alcance. No debemos olvidar que en estos gráficos subyacen estrategias comerciales que tal vez pretendan reservar un nicho importante al desarrollo java donde Oracle ha hecho grandes inversiones.

Características de Apex.

Oracle Application Express es un entorno de programación que nos permite consolidar todo el desarrollo de aplicaciones en la base de datos. No sólo cen-tralizamos los modelos de datos en el gestor Oracle sino que todo el código fuente de las aplicaciones se almacena también, en forma de metadatos, en el propio gestor. Una aplicación es un fichero sql.

Tanto el desarrollo como la ejecución final por parte de los usuarios se realiza desde una interfaz web estándar, sin ningún añadido, si bien se hace uso intensi-vo de técnicas AJAX para conseguir interfaces Web 2.0 atractivas.

Toda la programación interna se realiza en PL/SQL lo que nos permite amorti-zar la inversión realizada por nuestra universidad en esta tecnología durante casi 20 años.

Proyecto MAGO Abril 2012 6/11

El producto se incluye sin coste adicional en el gestor de base de datos e incor-pora, de forma predeterminada, un conjunto de opciones muy interesante.

Uso de Apex para el desarrollo de Aplicaciones Microinformáticas.

En el marco del Proyecto MAGO, la utilización de Apex como herramienta de desarrollo parecía una opción a considerar.

Si bien las características de desarrollo rápido son interesantes lo cierto es que, como era de esperar, no son todo lo productivas que parecen en un principio. Es una situación similar a la que vivimos en los inicios de la programación con Oracle Forms.

Se realizó un proceso intensivo de formación autodidacta y se diseñó el entorno básico de explotación centralizada, incluyendo los esquemas de plantillas y es-tándares, proceso de login, autorización,...

Con esta base se procedió a rediseñar un conjunto limitado de aplicaciones mi-croinformáticas.

El proceso se inicia contactando con el usuario final, en ocasiones el mismo que ha programado la versión MS Access/OpenOffice Base o que, al menos, la co-noce bie. Con esta información, se hace un estudio de requisitos independiente de la implementación concreta que el usuario ha hecho.

Uno de los aspectos clave del proceso es decidir el esfuerzo que debemos reali-zar en el modelado de datos. Diseñar un buen modelado tiene efectos positivos a medio plazo, aunque ahora suponga un retraso inicial. Presenta, sin embargo, el inconveniente de que no es fácil migrar los datos a partir de modelos total-mente desnormalizados y con registros no validados.

Proyecto MAGO Abril 2012 7/11

Decidido el modelo de datos se procede a la programación de los formularios e informes necesarios y se muestra el resultado al usuario como un prototipo ini-cial mejorable de forma continua en sucesivas actualizaciones (spiral methodo-logy).

Valoración de riesgos.

Como todo Proyecto, MAGO no está exento de riesgos. Superadas las pruebas de concepto las principales dificultades técnicas fueron la evaluación de la curva de aprendizaje y el paso a producción.

El núcleo duro de la programación estaba resuelto al utilizarse PL/SQL. Sin em-bargo, era necesario utilizar nuevas técnicas propias de la programación web así como múltiples particularidades de la propia herramienta y su API.

El paso a producción supuso el despliegue de una infraestructura basada en We-blogic sobre Solaris, así como la realización de pruebas de rendimiento para comprobar la capacidad de respuesta del sistema.

En el ámbito organizativo también se intuían algunos riesgos. Considerando el alto grado de aceptación que la solución ha tenido entre los usuarios podemos crear expectativas que son imposibles de cumplir. Nuestro objetivo es progra-mar aplicaciones microinformáticas, que resuelven problemas puntuales de los usuarios, pero cuyo alcance es limitado. Si estas aplicaciones crecen, con requi-sitos funcionales mayores, entonces se deben reconducir los esfuerzos a su inte-gración en las Aplicaciones Corporativas, con la posible migración de los datos disponibles. Esto debe entenderlo muy bien el usuario y el propio Servicio.

Otro posible riesgo organizativo es la relativa pérdida de control que sufre el usuario respecto a “su” base de datos local. Si los tiempos de respuesta del Servicio son adecuados la mayoría de los usuarios no percibirán esta dificultad. Para aquellos que deseen una implicación mayor, se puede plantear la realiza-ción de cursos de programación Apex a los usuarios finales.

No obstante, Apex nos permite desplegar listados interactivos que están tenien-do una enorme aceptación entre los usuarios ya que les permiten realizar fácil-

mente sus propios in-formes. Un listado in-teractivo posibilita se-leccionar los campos a visualizar, establecer condiciones y filtros, ordenaciones, resaltar información de forma condicional, realizar cálculos, gráficos, ex-portar datos,...

Proyecto MAGO Abril 2012 8/11

Para aquellos informes y preimpresos oficiales, opta-mos por el uso de Oracle Business Intelligence Pu-blisher, una solución profesional para la generación de informes que se integra perfectamente con Apex.

Primeros resultados.

El proyecto se inició con el despliegue de un conjunto limitado de aplicaciones que tuvieron un éxito inme-diato. Entre los criterios para seleccionar las aplica-ciones incluidas se tuvo en cuenta:

La conveniencia de diversificar los servicios involucrados para dar a co­nocer la solución entre los mismos.Que sean aplicaciones sin alternativa a corto plazo.La disponibilidad de los usuarios para colaborar en el desarrollo y des­pliegue de la aplicación.Se buscó  que cada aplicación aporte alguna singularidad de forma que, tecnológicamente, se pudiera obtener experiencia en diferentes ámbitos.

Actualmente, el conjunto de Aplicaciones Microinformáticas se organiza en tor-no a un aplicativo central, que hemos llamado Zeus, y que ofrece un acceso ho-mogéneo a todas las aplicaciones así como servicios para la gestión de accesos, monitorización, notificaciones o autenticación, incluyendo el uso para la misma de certificados digitales.

Las aplicaciones disponibles ac-tualmente superan la veintena y dan servicio a muchas de las áreas de gestión de nuestra universidad. La complejidad de estas aplicacio-nes es variable. Algunas son con-ceptualmente sencillas con una o dos tablas principales y varias ta-blas auxiliares para soportar un modelo normalizado. Sin embargo, otras aplicaciones van más allá y plantean soluciones con decenas de tablas, listados y formularios.

Además, al tratarse de tecnología actualizada, las aplicaciones pueden integrarse perfectamente con otros servicios complementarios como los ofrecidos por nuestra plataforma de administración electrónica, haciendo uso intensivo del port@firmas o de la agenda de tramitación.

Proyecto MAGO Abril 2012 9/11

Valoración de objetivos.

Como se preveía, los requisitos tecnológicos se han cubierto sobradamente. Las aplicaciones utilizan el gestor de base de datos Oracle, al igual que las Aplica-ciones Corporativas; se construyen con técnicas de desarrollo rápido (RAD) que facilitan la colaboración con el usuario en el diseño; el acceso es universal sin instalación de software y todas las aplicaciones tienen carácter multiusuario.

Además, las aplicaciones desplegadas incluyen muchas otras funcionalidades que han despertado el interés de los usuarios.

Hemos buscado el uso de una interfaz Web 2.0 sencilla a la vez que productiva que, de forma homogénea, se utiliza en todas las aplicaciones del proyecto. El uso vía navegadores permite, como requeríamos, la utilización desde cualquier escritorio. Hemos implementado, además, una pasarela SSL para que las aplica-ciones puedan ser utilizadas con seguridad desde redes externas a la universidad (domicilio particular, por ejemplo).

La generación de informes a por los propios usuarios es valorada muy positiva-mente así como la inclusión de preimpresos diseñados a medida o la posibilidad de volcar los datos a herramientas externas como OpenCalc o Microsoft Excel.

Hemos incluido opciones para adjuntar documentos y ficheros a las aplicacio-nes, lo cual permite, por ejemplo, que junto a la informa-ción de un Convenio se encuentre el propio documento o que junto a una justificación se inclu-ya una imagen de la factura.

No obstante, el nivel de integración puede ser mucho mayor incluyendo, por ejemplo, el envío al port@firmas para su firma.

Gracias al uso de estas funcionalidades y la capacidad de respuesta que nos ofrece la programación con Apex, las encuestas de satisfacción de los usuarios muestran que el 92,86% considera que el servicio ofrecido es bueno o

Proyecto MAGO Abril 2012 10/11

muy bueno. En proporción similar, se valoran las soluciones aportadas para resolver incidencias e imple-mentar modificaciones. Estos resul-tados son un gran aliciente para el Proyecto Mago y para el equipo que lo desarrolla.

De los riesgos valorados anteriormente, a día de hoy, sólo cabe mantener el aso-ciado a la percepción del usuario que, mostrándose muy satisfecho con las nue-vas aplicaciones, intenta que éstas se extiendan hasta cubrir funcionalidades pro-pias de las Aplicaciones Corporativas.

Por otro lado, las recientes auditorías informáticas a las que nos han sometido distintos organismos financiadores han puesto de manifiesto la debilidad de las soluciones microinformáticas tradicionales y la necesidad de migrarlas a entor­nos empresariales. Creemos que la oferta de aplicaciones que estamos realizan­do en el marco del Proyecto Mago cubren estas necesidades y nos permiten así no comprometer futuras financiaciones.

La reciente entrada en vigor del Esquema Nacional de Seguridad y las impor-tantes medidas de seguridad, integridad o disponibilidad que impone a las admi-nistraciones públicas es un motivo adicional para impulsar la migración de las aplicaciones microinformáticas a entornos empresariales como el que ofrecemos con el Proyecto Mago.

Proyecto MAGO Abril 2012 11/11