Embed Size (px)
Citation preview
Tesis de Grado
Integrador de fuentes de datos para la gestión por indicadores
Iris Figini
Directores Dr. Roberto Gustavo Illescas.
Ing. Mariano Martínez
TRABAJO FINAL - INGENIERÍA DE SISTEMAS
FACULTAD DE CIENCIAS EXACTAS UNIVERSIDAD NACIONAL DEL CENTRO DE LA PROVINCIA DE BUENOS AIRES
Tandil, 28/02/2018
Índice de Contenido
Índice de Contenido 1
1. Introducción 2 1.1. Motivación 6 1.2. Objetivos 7 1.3. Estructura de la tesis 11
2. Estado del Arte 13 2.1. Herramientas y aplicaciones similares en el mercado 14 2.2. Selección del tipo de aplicación 22 2.3. Selección del ambiente de desarrollo 24 2.4. Selección de herramientas 24 2.5. Diagnóstico de fortalezas, oportunidades, debilidades y amenazas 26
3. Diseño e Implementación 28 3.1. Introducción 28 3.2. Requerimientos del prototipo 28 3.3. Conexión de las distintas bases de datos 29 3.4. Editor de código 34 3.5. Almacenamiento y ejecución de consultas 36 3.6. Modelado de Tareas 40 3.7. Calendario de tareas 44 3.8. Sincronización de tareas automatizadas 44
3.8.1. CRON 46
4. Caso de estudio 48 4.1. Introducción 48 4.2. Caso de estudio aplicado en el prototipo 48
5. Conclusiones y trabajos futuros 63
Anexo 64
Bibliografía 66
1/69
1. Introducción De manera frecuente los sectores directivos de las organizaciones diagnostican la
necesidad de mejorar algún aspecto de su gestión, para lo cual establecen posibles
hipótesis que deben poder validar en pos de ejecutar las estrategias y políticas
definidas.
Para realizar formalmente esta tarea, se establecen indicadores y objetivos que deben
poder ser medibles y que permitirán establecer una medida de logro de la mejora
esperada.
En este sentido podemos definir a un indicador como una descripción compacta de
una determinada observación. Estas pueden referirse a una temática concreta o
pueden resumir un cierto número de cuestiones vinculadas.
Más específicamente un indicador es una variable o factor que proporciona un medio
sencillo y fiable para medir logros, reflejar los cambios vinculados con una intervención
o ayudar a evaluar los resultados de una organización. Es un signo, señal o valor que
permite establecer diferencias, comportamientos y tendencias, su medición puede ser
cuantitativa o cualitativa y en un período determinado de tiempo.
Resumidamente, los indicadores sirven:
- Para poder interpretar lo que está ocurriendo
- Para tomar medidas cuando las variables se salen de los límites establecidos
- Para definir la necesidad de introducir cambios y/o mejoras y poder evaluar sus
consecuencias en el menor tiempo posible.
Los resultados obtenidos a través de la medición permiten mejorar la planificación,
dado que es posible observar hechos en tiempo real, logrando tomar decisiones con
mayor certeza y confiabilidad. Una frase muy utilizada para graficar esta situación nos
anticipa que: Lo que no se mide no se puede controlar, y lo que no se controla no se
puede gestionar.
2/69
Para colaborar en este aspecto, en lograr una gestión con mejor toma de decisiones,
se desarrolló un prototipo en el marco de una tesis de grado en Ingeniería de Sistemas
elaborada por Federico Etchepare y Agustín Servat bajo la dirección del Dr. Gustavo
Illescas, denominada “Herramienta para dar soporte a la gestión de indicadores”, el
cual es un sistema de gestión por indicadores para el soporte de toma de decisiones,
que administra la creación y modificación de indicadores y presenta los resultados a
través de tableros de control. Estos indicadores se registran en una base de datos
propia del sistema de gestión de indicadores, implementada en MySQL (BDI).
Esta BDI no tiene sentido por sí sola sino que es “alimentada” por los sistemas
transaccionales de la organización. Como ejemplo de esto podemos citar los sistemas
propios de gestión (contables, ERP -Enterprise Resource Planning-, CRM -Customer
Ralation Management-, etc.) y como caso particular en nuestra casa de estudios
(mencionado más adelante en el caso de estudio desarrollado), el sistema Guarani,
Kolla, Araucano, Kune, Majen, entro otros.
Dada la complejidad que tienen los procesos de integración de las distintas fuentes de
datos surge la necesidad de contar con una herramienta que permita implementar una
secuencia ordenada de actividades sobre estos procesos.
Como explica el Dr .Gustavo Illescas en su Tesis de Doctorado [ILLE2014], a partir de
la definición de los indicadores seleccionados para la gestión de la organización, se
determinan las fuentes de datos necesarias para la conformación de lo que se
considera debe constituir una nueva BD específica para alojar dichos indicadores.
Generalmente estas fuentes de datos se componen de las BD del proceso
transaccional primario y de otras fuentes por ejemplo de organismos externos (datos
provenientes de las entidades bancarias, tarjetas de crédito, organismos de control
estatal, padrones externos y otros) o bien de un Data Warehouse (DW) que resuelve la
integración de dichas fuentes.
El Dr. Illescas define el ciclo de vida de la implementación de indicadores en
herramientas de inteligencia de negocios, compuesto de:
a) La definición e informatización de los indicadores,
b) la conformación de la BD específica a partir de las fuentes de datos
disponibles,
3/69
c) la informatización de los indicadores en herramientas de inteligencia de
negocios (CMI, TC, OLAP, otros),
d) la implementación de herramientas de control y seguimiento, construcción de
perfiles de uso y responsabilidad,
e) el mantenimiento de los indicadores, agregar/quitar/modificar a las
herramientas seleccionadas, monitorear el uso, y
f) las decisiones de la organización tomadas en función de la información que
proveen las herramientas.
En la Figura 1 se puede apreciar un esquema simplificado del ciclo mencionado que
permite visualizar mejor el contexto del prototipo a desarrollar.
Figura 1 - Esquema simplificado con el ciclo de vida de la implementación de
indicadores en herramientas de inteligencia de negocios [ILLE2014]
4/69
Por consiguiente, para poder arribar a una solución integral, el Dr. Gustavo Illescas
propone agregar al prototipo para dar soporte a la gestión de indicadores
anteriormente mencionado, un dispositivo de integración que permita incorporar un
conjunto de indicadores (y sus valores) a la BDI ya sea que provengan de las bases de
datos transaccionales (BDT), por el ejemplo de sistemas como Guaraní, o de otras
fuentes de datos, que como se explicó anteriormente pueden estar o no integradas en
la misma BDT. El dispositivo será el encargado de proveer un conjunto de formatos
estándar tal que previa validación de los datos, los valores sean agregados con motivo
de actualización o inserción.
Para la actualización de datos de un indicador, la información a incorporar consta de la
fecha y el valor del indicador. Esto se debe a que tanto desde las BDT o las BD de
otras fuentes pueden provenir datos del indicador de distintos períodos. Por otro lado
se procede a clasificar los estados de los valores ingresados de acuerdo con el rango
de aceptación definido en el período.
Una vez validados los datos e incorporados a la BDI, se procede a registrar el valor de
la última fecha de actualización para que sirva de contexto al decisor cuando éste
visualiza los indicadores.
Resumiendo, el objetivo del presente trabajo se puede observar en el esquema
presentado en la Figura 2.
5/69
Figura 2 - Esquema del diseño del integrador de fuentes de datos [ILLE2014]
1.1. Motivación
La motivación del presente trabajo surge como propuesta de trabajos futuros de la
tesis doctoral del Dr. Gustavo Illescas, sumado a la necesidad y el interés institucional
de la Facultad de Ciencias Exactas de analizar grandes volúmenes de datos
provenientes de diferentes fuentes para actualizar y completar la Base de Datos de un
Sistema de Gestión de Indicadores.
Además, el desarrollo de esta tesis está enmarcado dentro del proyecto integral PEFI,
el cual se trata de un plan de mejora de indicadores académicos para la formación de
ingenieros, impulsado por la Secretaría de Políticas Universitarias, con la finalidad de
incrementar la cantidad de graduados en ingeniería, para asegurar en cantidad y
calidad los recursos humanos necesarios, y hacer de Argentina un país desarrollado.
Por otro lado, el prototipo que se propone desarrollar en el presente trabajo tiene
características de lo que hoy conocemos como procesos de Extracción,
6/69
Transformación y Carga (ETL). En esto encontramos diversas herramientas como IBM
Websphere DataStage, Pentaho Data Integration, Oracle Warehouse Builder, Microsoft
SQL Server Integration Services, entre otros, como se podrá ver en el capítulo 3, en
donde se detalla el estado del arte. Pero que no satisfacen las necesidades
específicas que se buscan cumplir en la presente tesis, o tienen un alto costo. Es
decir, otra de las oportunidades para la elaboración del presente trabajo es la carencia
de software dedicado a este fin a un costo accesible.
1.2. Objetivos
El presente trabajo se basa en desarrollar un prototipo que permita integrar distintas
fuentes de datos, automatizar las tareas de extracción, resumen, preprocesamiento y
actualización de los valores de indicadores para la gestión y visualización de los
mismos.
Es decir, el objetivo es desarrollar un prototipo que actúe de interfaz entre los sistemas
transaccionales existentes en la institución y el Sistema de Gestión de Indicadores
(BDI) , y que por medio de un conjunto de funcionalidades implemente la programación
de tareas automatizadas de actualización de los indicadores.
El dispositivo será el encargado de proveer un conjunto de formatos estándar tal que,
previa validación, el conjunto de indicadores y sus valores sean incorporados al BDI
con motivo de actualización de los mismos.
Este prototipo podrá ser utilizado en cualquier organización que tenga múltiples
fuentes de datos y la necesidad de visualizar la información a partir de indicadores.
Como caso de estudio principal, de aplicación y demostración, el presente trabajo
estará abocado a extraer e integrar valores para indicadores de los distintos sistemas
que se utilizan en la Facultad de Ciencias Exactas de la U.N.C.P.B.A. como ser el
sistema SIU-Guarani, el de Planta Docente (Majen) o el de Concursos (Kune).
Es decir, si bien el caso de estudio será aplicado en una primer instancia a las
entidades educativas, bien podría utilizarse sin problemas en otro ámbito empresarial
que cuente con datos recolectados a través de bases de datos y tenga el interés de
7/69
hacer un análisis de los mismos para mejorar algún aspecto de su organización o
negocio llegando incluso a los procesos de generación de la estrategia.
Hoy en día se cuenta con grandes volúmenes de datos gracias al avance de las
tecnologías de información y comunicaciones (TICs) en todos los escenarios. Para que
la información pueda ser utilizada por los niveles que toman decisiones, la misma debe
ser procesada, agrupada, resumida, etc. y normalmente existe un desacople entre los
sectores informáticos y gerenciales, de manera que cada vez que estos últimos
necesitan información relevante, la misma no se encuentra actualizada o no está
disponible. Es interesante poder resumir dichos datos en información relevante para la
gestión de gobierno de una universidad o el área gerencial de una empresa. Una
manera interesante y práctica, es a través de indicadores, ya que aportan una
información sensible y muy relevante dado que los mismos permiten conocer a ciencia
cierta realidades del ámbito, y en caso que corresponda, promover políticas que
permitan la corrección de aquellos indicadores que se encuentran mal o por debajo de
lo esperado.
Por otro lado, sumado a lo anterior, el gran inconveniente que se presenta hoy en día
es la dificultad de poder hacer una recolección periódica y fiable de dicha información,
ya que por lo general son procesos manuales, que suelen fallar, o estar ausentes por
ciertos períodos de tiempo.
Este trabajo permitirá la gestión de las actualizaciones, de manera que se pueda
generar reportes con los resultados de las mismas, tanto manuales como
automatizadas. El poder automatizar dicha recolección aportaría a un sistema, ya
existente, de gestión de indicadores que se cuente con la información precisa, en
tiempo y forma, para poder tomar las decisiones más adecuadas a tiempo, y en el
caso particular de la unidad académica, poder mejorar la calidad educativa, disminuir
la deserción estudiantil, o el retraso en los estudios de los alumnos, entre otras
cuestiones.
Existen en el mercado muchas herramientas que visualizan indicadores. Sin embargo,
en nuestra composición del estado del arte no hemos encontrado una herramienta que
permita extraer indicadores desde distintas y diversas fuentes de datos e integrarlos
con una solución de visualización.
8/69
En general todas requieren de un proceso manual que extrae la información
transaccional registrada y se las suministra a dichos sistemas. Además con la
posibilidad de que la información visualizada no se encuentre debidamente
sincronizada al periodo de interés para el área de gestión, y con el inconveniente de
ser tareas manuales y de manipulación directa sobre los datos. Es por ello que se
planteó la necesidad de desarrollar un prototipo que automatice dichas tareas.
El prototipo a desarrollar contempla la posibilidad de poder realizar diversas y
complejas consultas a distintas y variadas fuentes de datos, ofreciendo
estandarización en el formato y validación en el resultado, concentrándose en la
gestión y actualización de los indicadores, permitiendo registrar:
● Quién realiza la extracción
● Cuándo se efectúa la consulta
● De dónde se extrae el valor (de qué base)
● Qué resultado tuvo la extracción y actualización en el sistema de visualización
● Creación de tareas automáticas de extracción con supervisión y con resultados
igual que si se hicieran en forma manual
De esta forma el proceso de extracción de indicadores se puede gestionar y supervisar
y tener un registro de éxitos o errores y tomar decisiones en consecuencia.
Los indicadores se mantienen actualizados y al gestionar la actualización de los
mismos se pueden establecer métricas de calidad de los mismos.
Para la automatización de las tareas, se proveerá de un calendario donde se pueda
visualizar el estado de las actualizaciones en un tablero que refleje si las mismas se
ejecutaron con éxito o no.
Como se mencionara, existe un prototipo para dar soporte a la gestión de indicadores,
el cual permite crear indicadores, visualizarlos en tableros con distintas posibilidades
de graficación y definición de umbrales para facilitar la toma de decisiones,
permitiendo elegir los rangos de fechas que se desean observar sumado a
9/69
presentación de resúmenes y emisión de reportes con distintos niveles de detalle. En
la Figura 3 se puede observar la visualización de un indicador.
Figura 3 - Visualización de un indicador en el prototipo para dar soporte a la gestión de indicadores
En la Figura 4 se puede observar un reporte resumido de tablero, el cual muestra un
resumen de cada indicador.
Figura 4 - Visualización de un tablero en el prototipo para dar soporte a la gestión de indicadores
10/69
El objetivo principal del presente trabajo es actualizar en la base de datos de este
prototipo los valores de los indicadores, de una manera segura, eficiente, y automática.
Permitiendo consultar una diversidad de fuentes de datos ya sean transaccionales o
no. Es decir, integrar las diferentes fuentes donde se encuentra la información para el
cálculo de los valores de los indicadores, permitiendo realizar las consultas y los
cálculos correspondientes, de una manera simple y automática, evitando así posibles
inconsistencias, olvidos o fallas que se dan cuando la tarea es manual y dependiente
de la intervención humana.
1.3. Estructura de la tesis
El trabajo se encuentra estructurado en cinco capítulos, cuyo contenido se resume a
continuación.
En el Capítulo 1 se presenta una breve introducción a la problemática de la obtención
de valores de indicadores para la gestión de los mismos y las motivaciones que llevan
a la creación de un prototipo que integre diversas fuentes de datos para lograr los
objetivos propuestos.
El Capítulo 2 se centra en el estudio de las diferentes herramientas existentes en el
mercado que tienen funcionalidades semejantes al prototipo, la justificación sobre el
ambiente de desarrollo y las herramientas seleccionadas para la construcción del
prototipo y el diagnóstico de las fortalezas, oportunidades, debilidades y amenazas del
presente trabajo.
En el Capítulo 3 se presenta una solución al problema planteado detallando el
prototipo creado y describiendo sus requerimientos, funcionamiento, uso e
implementación.
En el Capítulo 4 se presenta y detalla un caso de estudio aplicado al prototipo
desarrollado y en funcionamiento, mostrando los resultados obtenidos de las pruebas
realizadas, gráficos y tablas.
11/69
En el Capítulo 5 se exponen las conclusiones a las que se ha arribado y se de detallan
los posibles trabajos futuros y mejoras que se pueden tener en consideración e
implementar.
En el Anexo se listan los indicadores trabajados dentro del proyecto integral PEFI.
Por último se especifica la bibliografía que ha servido de soporte y consulta para la
presente tesis.
12/69
2. Estado del Arte El presente capítulo presenta información relevada durante la investigación previa a
realizar el prototipo. Esta investigación consistió en buscar herramientas de software
con funcionalidad semejante al prototipo a desarrollar, es decir que permitan extraer
valores desde diversas fuentes de datos y normalizarlos.
Existen en el mercado diversas herramientas destinadas a satisfacer el proceso de
Extracción (E), Transformación (T) y Carga (L, de Load en Inglés) -ETL- de datos
desde múltiples fuentes, reformatearlos, limpiarlos, y cargarlos en otra base de datos,
data mart, o data warehouse para analizar y apoyar un proceso de toma de decisiones.
[ETL]
La idea es que una aplicación ETL lea los datos primarios de distintas bases de datos
de sistemas principales, realice transformación, validación, filtrado y por último escriba
los datos en otro almacenamiento para que en este momento estén disponibles para
ser analizados por los usuarios (Figura 5).
Figura 5 - Proceso ETL
La primera parte del proceso ETL consiste en extraer los datos desde los sistemas de
origen. La mayoría de los proyectos de almacenamiento de datos fusionan datos
provenientes de diversos sistemas de origen. Cada sistema separado puede usar una
organización diferente de los datos o formatos distintos. Los formatos de las fuentes
normalmente se encuentran en bases de datos relacionales o ficheros planos, pero
pueden incluir bases de datos no relacionales u otras estructuras.
13/69
En general, la fase de extracción tiene como objetivo convertir los datos en un único
formato apropiado para el procesamiento de transformación. Una parte intrínseca de la
extracción implica la validación de datos para confirmar si los datos extraídos de las
fuentes tienen los valores correctos o esperados en un dominio dado. Si los datos
fallan, las reglas de validación se rechazan por completo o en parte. Los datos
rechazados se informan idealmente al sistema de origen para un análisis posterior
para identificar y corregir los registros incorrectos. En algunos casos, el proceso de
extracción puede tener una regla de validación de datos para aceptar los datos y fluir a
la siguiente fase.
Por ejemplo, si el dato a extraer se refiere a la fecha de nacimiento de un alumno
universitario, se debe verificar que esté dentro de un rango esperado, como ser
posterior al 1 de enero de 1900 y anterior al día de hoy menos 17 años.
La segunda parte del proceso es la de transformación, la cual aplica una serie de
reglas de negocio o funciones sobre los datos extraídos para convertirlos en datos que
serán cargados. Algunas fuentes de datos requerirán alguna pequeña manipulación de
los datos.
Por ejemplo, distintas fuentes de datos pueden almacenar fechas en diferentes
formatos. En este punto, se deben transformar los datos para que todas tengan el
mismo, como ser dd/mm/aaaa.
La tercer parte del proceso ETL es la de carga, es decir, es el momento en el cual los
datos de la fase anterior (transformación) son cargados en la base de destino.
2.1. Herramientas y aplicaciones similares en el mercado
Entre las herramientas y aplicaciones ETL del mercado más populares podemos
encontrar:
● IBM Websphere DataStage (anteriormente Ascential DataStage y Ardent
DataStage)
● Pentaho Data Integration (Kettle ETL) - Una herramienta Open Source
Business Intelligence
14/69
● SAS ETL Studio
● Oracle Warehouse Builder
● Informatica PowerCenter
● Cognos Decisionstream
● Ab Initio
● BusinessObjects Data Integrator (BODI)
● Microsoft SQL Server Integration Services (SSIS)
IBM Websphere DataStage
IBM InfoSphere DataStage es una herramienta ETL y parte del conjunto de soluciones
de IBM Information Platforms e IBM InfoSphere [Websphere]. Utiliza una notación
gráfica para construir soluciones de integración de datos y está disponible en varias
versiones, como Server Edition, Enterprise Edition y MVS Edition. Utiliza una
arquitectura cliente-servidor. Los servidores se pueden implementar tanto en Unix
como en Windows.
Es una poderosa herramienta de integración de datos, utilizada frecuentemente en
proyectos de Data Warehousing para preparar los datos para la generación de
informes.
WebSphere DataStage ofrece la funcionalidad, la flexibilidad y la escalabilidad
necesarias para dar respuesta a requisitos de integración de datos. Transforma y
mueve datos de sistemas de origen a sistemas de destino por lotes y en tiempo real.
Incluye las siguientes posibilidades:
● Integrar datos desde una amplia gama de orígenes de datos empresariales y
externas
● Incorporar reglas de validación de datos
● Procesar y transformar grandes volúmenes de datos mediante procesos
paralelos escalables
● Manejar transformaciones muy complejas
● Gestionar varios procesos de integración
● Proporcionar conectividad directa a aplicaciones empresariales como orígenes
o destinos
● Utilizar metadatos para el análisis y el mantenimiento
15/69
● Operar por lotes, en tiempo real o como servicio web
Pentaho Data Integration (Kettle ETL)
Kettle es una herramienta de la suite de Pentaho, también conocida como PDI o
Pentaho’s Data Integration [Pentaho]. Es una herramienta ETL (Extract – Transform –
Load), es decir, de Extracción de datos de una fuente, Transformación de esos datos,
y Carga de esos datos en otro sitio. Estas tareas son típicas en procesos de migración,
integración con terceros, explotación de Big Data.
Kettle es un intérprete de procedimientos escritos en formato XML. Proporciona un
motor de JavaScript (así como uno de Java) para afinar el proceso de manipulación de
datos. Es también una buena herramienta, con todo lo necesario para crear incluso
procedimientos complejos de ETL. Kettle es un intérprete de los procedimientos de
ETL escritos en formato XML. Kettle proporciona un motor Java o JavaScript para
tomar el control del procesamiento de datos. Kettle (PDI) es la herramienta
predeterminada en Pentaho Business Intelligence Suite. Los procedimientos también
se pueden ejecutar fuera de la plataforma Pentaho, siempre que estén instaladas
todas las bibliotecas de Kettle y el intérprete de Java.
SAS ETL Studio
La integración de datos es el proceso de consolidación de datos de una variedad de
fuentes con el fin de producir una vista unificada de los datos. [SAS] SAS admite la
integración de datos de las siguientes maneras:
● Conectividad y metadatos. Un entorno de metadatos compartidos proporciona
una definición de datos coherente en todas las fuentes de datos. El software
SAS permite conectarse, adquirir, almacenar y escribir datos de una variedad
de fuentes de datos, aplicaciones y sistemas en diversas plataformas y
entornos.
● Limpieza y enriquecimiento de datos. Permite perfilar, limpiar, aumentar y
monitorear datos para crear información consistente y confiable. Proporciona
una serie de transformaciones y funciones que pueden mejorar la calidad de
los datos.
16/69
● Extracción, transformación y carga. Permite extraer, transformar y cargar datos
de toda la empresa para crear información coherente y precisa. Proporciona
una interfaz gráfica que permite a los diseñadores crear flujos de procesos,
identificar rápidamente las entradas y salidas, y crear reglas de negocios en
metadatos, todo lo cual permite la generación rápida de data warehouses, data
marts y data streams.
● Migración y sincronización. Permite migrar, sincronizar y replicar datos entre
diferentes sistemas operacionales y fuentes de datos. Las transformaciones de
datos están disponibles para alterar, reformatear y consolidar información. La
integración de calidad de datos en tiempo real permite que los datos se limpien
a medida que se mueven, replican o sincronizan, y puede crear una biblioteca
con reglas reutilizables.
● Virtualización de datos. Permite consultar y utilizar datos en múltiples sistemas
sin el movimiento físico de los datos de origen. Proporciona acceso virtual a
estructuras de bases de datos, aplicaciones ERP, archivos heredados, texto,
XML, colas de mensajes y una gran cantidad de otras fuentes. Permite unir
datos a través de estas fuentes de datos virtuales para obtener acceso y
análisis en tiempo real. La capa de metadatos de negocios semánticos protege
al personal de negocios de la complejidad subyacente de los datos.
● Gestión de datos maestros. Permite crear una vista unificada de datos
empresariales desde múltiples fuentes. Las descripciones de datos semánticos
de las fuentes de datos de entrada y salida identifican de forma única cada
instancia de un elemento del negocio y estandarizan el modelo de datos
maestro para proporcionar una fuente única de verdad. Las transformaciones y
los procesos integrados de calidad de datos garantizan que los datos maestros
sean correctos.
Oracle Warehouse Builder
Oracle Warehouse Builder (OWB) es una herramienta ETL producida por Oracle que
ofrece un entorno gráfico para construir, gestionar y mantener procesos de integración
de datos en sistemas de inteligencia de negocios. [OWB]
17/69
El uso principal de OWB es la integración de fuentes de datos heterogéneas en el
almacenamiento de datos y la migración de datos desde sistemas heredados.
Además, ofrece capacidades para el modelado de datos relacionales, dimensionales y
de metadatos, creación de perfiles de datos, limpieza de datos y auditoría de datos.
Mientras que la funcionalidad principal es parte de la base de datos Oracle desde la
versión 10gR2, algunas de las últimas funciones se venden por separado como
opciones.
Informatica PowerCenter
PowerCenter ETL de Informatica es una plataformas de integración de datos capaz de
impulsar y acelerar las iniciativas de integración de datos en proyectos de Business
Intelligence, data warehousing, migración e integración de aplicaciones en la nube y
data governance. [PowerCenter]
Características y funcionalidades principales de PowerCenter ETL:
● Gestión basada en metadatos. Ofrece vistas gráficas de los flujos de datos.
● Reutilización. Los usuarios disponen de herramientas gráficas y libres de
código que permiten aprovechar opciones de transformaciones pre-integradas.
● Autonomía. Brinda independencia entre los distintos usuarios del negocio.
● Escalabilidad.
● Supervisión operacional y de gobierno. Provee sistema de alertas.
● Creación de prototipos, validación y perfilado rápidos. Los analistas pueden
colaborar para crear prototipos rápidamente y validar los resultados de forma
ágil e iterativa.
● Datos en tiempo real para las aplicaciones y los análisis.
● Automatización, integración y conectividad. Pruebas de validación
automatizadas en cualquier entorno, facilidad de acceso a la información e
integración de datos desde cualquier tipo de fuente.
Cognos Decisionstream
IBM Cognos Data Manager (formalmente conocido como Cognos DecisionStream)
proporciona capacidades ETL para inteligencia empresarial de alto rendimiento
18/69
[Cognos]. Crea repositorios de datos para informes, análisis y gestión de rendimiento.
Funciona extrayendo datos operativos de múltiples fuentes, transformando y
fusionando los datos para facilitar informes y análisis en toda la empresa, entregando
los datos transformados a centros de datos coordinados. Algunas de sus
características son:
● Admite análisis de alto rendimiento de datos relacionales mediante la creación
de tablas agregadas en múltiples niveles dentro y entre jerarquías en las tablas
dimensionales.
● Brinda soporte multilingüe para mejorar las capacidades de integración de
datos y permite crear rápidamente una plataforma de integración global de
datos.
● Automatiza muchos de los procesos asociados con la creación y administración
de tablas dimensionales, sin la necesidad de una codificación manual.
● Permite que múltiples desarrolladores compartan información.
Ab Initio
Se especializa en aplicaciones de procesamiento de datos de gran volumen e
integración de aplicaciones empresariales. Ab Initio es una potente herramienta de
procesamiento paralelo basada en la interfaz gráfica de usuario para la gestión y
análisis de datos ETL. [Ab]
Los productos Ab Initio se proporcionan en una plataforma homogénea y heterogénea
fácil de usar para aplicaciones de procesamiento de datos en paralelo. Estas
aplicaciones realizan funciones relacionadas con análisis de datos de cuarta
generación, procesamiento por lotes, eventos complejos, procesamiento de datos
cuantitativos y cualitativos, software de procesamiento paralelo basado en la interfaz
gráfica de usuario (GUI) que se usa comúnmente para extraer, transformar y cargar
(ETL) datos.
Una característica no menor de Ab Initio es que mantiene un alto nivel de secreto con
respecto a sus productos, es decir que no revela información técnica al público.
19/69
BusinessObjects Data Integrator (BODI)
El BusinessObjects Data Integrator es una herramienta de integración de datos y ETL
[BODI]. Las versiones más recientes del software incluyen características de calidad
de datos y se denominan SAP BODS (BusinessObjects Data Services). El producto
Data Integrator consiste principalmente en un servidor y un diseñador de integración
de datos. Se usa comúnmente para construir data marts, sistemas ODS, data
warehouses, etc.
Se pueden realizar transformaciones adicionales utilizando un lenguaje de scripts para
usar cualquiera de las funciones de manejo de datos ya provistas para definir
transformaciones complejas en línea o crear funciones personalizadas.
El diseñador de Data Integrator almacena los trabajos y proyectos creados en un
repositorio. También facilita el desarrollo ETL basado en equipos dado que incluye un
sistema de control de versiones del Repositorio Central. Aunque este sistema de
control de versiones no es tan robusto como los VCS independientes, proporciona las
funciones básicas.
El proceso de integración de datos de BusinessObjects se divide en las siguientes
operaciones:
● Unificación de datos
● Perfiles de datos
● Auditoría de datos
● Limpieza de datos
Microsoft SQL Server Integration Services (SSIS)
Microsoft Integration Services es una plataforma para la creación de soluciones
empresariales de transformaciones de datos e integración de datos [SSIS]. Integration
Services sirve para resolver complejos problemas empresariales mediante la copia o
descarga de archivos, el envío de mensajes de correo electrónico como respuesta a
eventos, la actualización de almacenamientos de datos, la limpieza y minería de datos,
y la administración de objetos y datos de SQL Server . Los paquetes pueden funcionar
en solitario o junto con otros paquetes para hacer frente a las complejas necesidades
20/69
de la empresa. Integration Services puede extraer y transformar datos de diversos
orígenes como archivos de datos XML, archivos planos y orígenes de datos
relacionales y, después, cargar los datos en uno o varios destinos.
Integration Services contiene un variado conjunto de tareas y transformaciones
integradas, herramientas para la creación de paquetes y el servicio Integration
Services para ejecutar y administrar los paquetes. Las herramientas gráficas de
Integration Services se pueden usar para crear soluciones sin escribir una sola línea
de código. También se puede programar el amplio modelo de objetos de Integration
Services para crear paquetes mediante programación y codificar tareas personalizadas
y otros objetos de paquete.
El SSIS Import/Export Wizard permite mover datos de origen a destino sin modificar
los datos del origen y permitiendo hacer iteraciones y cambios de información antes de
llegar al destino dentro de tablas de ETL. Se pueden importar datos de fuentes
diferentes a SQL Server.
Con la herramienta Business Intelligence Development Studio, se pueden realizar
tareas de migración fácilmente usando tareas visuales. Si se desea crear nueva
funcionalidad, se pueden crear scripts en C# o Visual Basic.
Los paquetes, que son las unidades de almacenamiento de estas tareas de migración
se pueden guardar en archivos dtsx o en la base de datos en formato XML. Una vez
implementado el paquete puede ser depurado.
En lo que respecta a este trabajo, las etapas inicialmente necesarias son la extracción
y la carga de datos para calcular valores de indicadores a partir de diversas fuentes de
datos. Es decir, se centra en la capacidad de poder realizar consultas (simples o
complejas) para calcular los valores de un determinado indicador para un período de
tiempo estipulado, y poder almacenarlo en el BDI en un formato preestablecido.
Esto sumado a la necesidad de realizar los cálculos e inserciones de manera
automática, hace que las herramientas existentes en el mercado no sean las más
indicadas. Para esto es necesario el desarrollo de un prototipo que tenga en
21/69
consideración las particularidades de la situación. Un prototipo que sea lo más flexible
posible para que sea aplicable en cualquier ámbito, y que permita la conexión a una
gran variedad de motores de bases de datos diferentes. Además, debe otorgar la
sencillez y simplicidad suficientes para que el usuario sólo deba escribir la consulta
necesaria, pudiendo estar enriquecida con código php, para obtener el cálculo de los
indicadores, despreocupandose de todo lo demás.
Por otro lado, las herramientas de visualización de indicadores, tal como el prototipo
desarrollado por Federico Etchepare y Agustín Servat en su tesis de grado,
“Herramienta para dar soporte a la gestión de indicadores”, tienen falencias a la hora
de integrarse con los sistemas transaccionales, ya que, si bien permiten
actualizaciones a partir de importaciones de archivos en formatos estándar, a través
de procesos manuales, no permiten hacerlo de la manera automática que lo propone
este trabajo.
Teniendo en consideración el caso de estudio en el que se aplicará la solución, el cual
estará orientado a extraer valores para indicadores de los distintos sistemas que se
utilizan en Universidad, para integrarse al prototipo de Gestión por Indicadores (BDI),
las herramientas actualmente existentes en el mercado no se adaptan a estas
necesidades concretas.
Por este motivo se hace necesario el desarrollo de un prototipo que permita integrar
distintas fuentes de datos, automatizar las tareas de extracción, resumen,
preprocesamiento y actualización de los valores de indicadores para la gestión y
visualización de los mismos. Es decir, desarrollar un prototipo que actúe de interfaz
entre los sistemas transaccionales existentes en la institución y el BDI, y que por
medio de un conjunto de funcionalidades implemente la programación de tareas
automatizadas de actualización de los indicadores.
2.2. Selección del tipo de aplicación
Hoy día existen amplia variedad de alternativas de soluciones. A partir de ciertas
características que no tienen que ver con la funcionalidad, se pueden analizar dos
tipos de soluciones, que se presentan en el siguiente cuadro comparativo:
22/69
Ventajas Desventajas
Stand Alone. Se
instalan en la
computadora del
usuario final
● Mejor interfaz gráfica
● Pueden utilizarse sin
conexión a internet
● Fuerte dependencia del sistema
operativo
● Sensibles a cambios del
sistema operativo u a otras
aplicaciones (ejemplo Antivirus)
● Las mejoras requieren
re-instalar o correr
actualizaciones
● La responsabilidad de los
backups depende del usuario
Cliente Servidor.
Se utilizan
accediendo a un
servidor.
● Accesibilidad desde
cualquier lugar
● Independiente del sistema
operativo, generalmente
requieren solo de un
navegador
● Las actualizaciones
siempre están disponibles
● Backups automáticos y
periódicos dentro del
mismo servidor.
● Requieren de una conexión con
acceso al servidor
● Deben analizarse cuestiones de
seguridad
Considerando el caso particular del prototipo que se desea desarrollar, se optó por la
opción de Cliente Servidor, dadas las siguientes razones:
1. La aplicación se utilizará en ambientes institucionales, que ya cuentan con
servidores disponibles permanentemente, con condiciones de seguridad
óptimas
2. El sistema se utilizará por Usuarios de perfil técnico, con lo cual la experiencia
gráfica del usuario no es relevante.
3. Es importante que todos las mejoras se encuentren siempre disponibles.
23/69
2.3. Selección del ambiente de desarrollo
Por tratarse de una solución que en principio se utilizará en una Universidad Pública, la
tecnología a utilizar se reduce a elementos Open Source. Por lo tanto quedan dos
grupos con sus ventajas y desventajas que se presentan a continuación:
Ventajas Desventajas
J2EE Java to Entreprise Edition
- Robustez de la solución
- Mayores posibilidades de alta calidad
- Se enseña Java en las carreras de Ingeniería
- Alta curva de aprendizaje
- Requerimientos de hardware elevados
- Alta latencia para generar soluciones
LAMP ó LAPP Linux-Apache-MySQL-PHP/Python/Perl Linux-Apache-PostgreSQL-PHP/Python/Perl
- Baja curva de aprendizaje
- Pocos requerimientos de hardware
- Dificultad para testeo automático, implica más difícil detectar errores
- No se enseña PHP en carreras de ingeniería
Considerando el alcance de la aplicación, se elige la opción LAPP.
2.4. Selección de herramientas
Existen muchas herramientas que permiten desarrollar aplicaciones a partir de PHP.
A nivel internacional la que más está creciendo en este momento es Symphony. Este
entorno de desarrollo permite elaborar una aplicación a partir de una base de datos. Es
muy eficiente, aunque tiene una curva de aprendizaje alta.
Por otro lado, a nivel nacional existe un ambiente denominado SIU-Toba, el cual es
una herramienta de desarrollo que permite crear sistemas transaccionales en forma
rápida, utilizando tecnología web open-source, con el cual se desarrollan aplicaciones
para el ámbito de las universidades nacionales.
24/69
Esto permite realizar la siguiente comparativa:
Ventajas Desventajas
Symphony Mayor uso internacional, mayor cantidad de soporte
Alta curva de aprendizaje
SIU-Toba Foro de usuarios a nivel nacional Acceso directo a los desarrolladores Se cuenta con amplia experiencia
Interfaz gráfica final pobre, no responsive
La mayor desventaja de SIU-Toba es el resultado gráfico final, que si bien es suficiente
puede no ser tan atractivo como el de Symphony, que está pensando para un público
más amplio. Pero esto no es un problema, porque el usuario del producto será un
usuario técnico, con lo cual la interfaz de SIU-Toba es más que suficiente.
Por otro lado, como la herramienta pretende ser utilizada inicialmente en ambientes
universitarios, en estos se contará seguramente con técnicos que tengan instalados en
su institución sistemas desarrollados con SIU-Toba.
Además, el prototipo intenta agilizar el proceso de construcción y el mantenimiento del
mismo, a través de la reducción de tareas repetitivas, permitiendo al desarrollador
enfocar su actividad en la lógica del dominio. Con lo cual se estaría reutilizando parte
de esos recursos.
Por lo expuesto, la tecnología seleccionada para este proyecto es:
● Lenguaje programación (PHP/Javascript)
● Ambiente de desarrollo web SIU-Toba
● Bases de datos (MySQL, Postgres, Informix)
● Servidores (linux Debian/Ubuntu)
25/69
2.5. Diagnóstico de fortalezas, oportunidades, debilidades y
amenazas
Fortalezas Debilidades
Análisis Interno
Se cuenta con el conocimiento tecnológico e informático necesario para desarrollar el prototipo.
La interfaz gráfica se orienta a técnicos por lo cual no es muy atractiva.
Se encuentran disponibles copias de todas las bases de datos reales que almacenan la información operativa.
Se desarrolla con un framework conocido solo en el ámbito universitario.
Existe financiamiento parcial para el desarrollo del sistema.
Este prototipo es el último requisito para la graduación del autor de esta tesis de grado.
Esta prototipo registrará detalladamente quién y cuándo actualizó un indicador, además del resultado. En otras herramientas, generalmente es una operación manual realizada por un operador, y la idea de este proyecto es automatizar y registrar detalladamente todas las acciones que se realicen.
Oportunidades Amenazas
Análisis Externo
Directivos de diversas Facultades han planteado la necesidad de contar con herramientas similares.
El prototipo será utilizado por técnicos especializados.
Fracaso de otras experiencias similares (de otros productos) al no contar con un mecanismo fácil de actualización.
Si bien el sistema es Web, pueden aparecer nuevos dispositivos o interfaces para las cuales el sistema no sería apto.
Existen Universidades con sus respectivas Facultades o Departamentos con gran volumen de información que no cuentan con personal técnico para este tipo de desarrollos.
Interés institucional en el desarrollo del sistema.
Las herramientas existentes son muy costosas.
26/69
Como principio fundamental, cabe destacar que todos los elementos comparados se
encuentran dentro del principio de Open-Source el cual suscriben las Universidades
Nacionales. Ninguna pieza de software comparada o seleccionada, escapa de esta
premisa. Por el mismo principio, la selección del sistema operativo de soporte para los
sistemas es de tipo Linux Debian/Ubuntu.
27/69
3. Diseño e Implementación
3.1. Introducción
En este capítulo se mostrarán las decisiones de diseño e implementación que fueron
tenidas en cuenta durante el desarrollo del prototipo, como así también las
expectativas y requerimientos expresadas en los objetivos de este trabajo.
3.2. Requerimientos del prototipo
Como se mencionara en la introducción, el objetivo de este trabajo es permitir
consultar una diversidad de fuentes de datos para la extracción de los valores de los
indicadores, para luego actualizarlos en el prototipo que da gestión y visualización a
los mismos. Esto será detallado en la sección correspondiente a la conexión de las
distintas bases de datos.
Para poder calcular dichos valores se propone un editor de código que permita escribir
las consultas necesarias dando la posibilidad de escribirlas en SQL enriquecidas con
un lenguaje de programación como PHP.
Dichas consultas podrán ser almacenadas en archivos planos dentro del servidor para
luego ser procesadas de manera manual o automática de acuerdo a un calendario,
con la frecuencia de actualización definida en cada indicador, tal como se detalla en la
sección 3.5 Almacenamiento y ejecución de consultas.
Para poder administrar y ejecutar esas consultas de manera automática se aplicó el
concepto de tarea, con persistencia en la base de datos, para que el usuario pueda
gestionarlas de manera sencilla, permitiendo crear nuevas, modificar las existentes,
consultar sobre la ejecución de alguna de ellas. Esto de detalla en el apartado 3.6
Modelado de tareas.
Otro aspecto importante es la necesidad de poder tener un seguimiento de la
ejecución de dichas tareas y los estados de las mismas. Para ello se brinda un
28/69
calendario que visualice las mismas, y será detallado en la sección 3.7 Calendario de
tareas.
Por último se expondrá la automatización de las mismas para brindar solución a la
necesidad de realizar las actualizaciones en la BDI de manera automática y sin la
necesidad de intervención de un operario.
3.3. Conexión de las distintas bases de datos
Para poder extraer la información y definición de los indicadores existentes, la
herramienta se debe poder conectar al prototipo que da soporte a la gestión de
indicadores (BDI), sobre los cuales se va a ofrecer la posibilidad de escribir la consulta
correspondiente para el cálculo y extracción de los valores de los mismos, permitiendo
conectarse a diferentes bases de datos externas, y el posterior volcado de los
resultados en el BDI. Esto proceso se grafica en la Figura 6.
Figura 6 - Proceso de conexión entre las distintas bases de datos
Como se puede ver en la Figura 7, desde la BDI se lee información sobre los
indicadores. Con esta información y a partir de la información del sistema transaccional
se genera un flujo de actualización de nuevo hacia la base de datos de gestión de
indicadores.
29/69
Figura 7 - Flujo de consultas y actualizaciones hacia la base de indicadores
Se registra la información relativa al proceso de actualización, como ser quién y
cuándo realizó la última actualización, y cómo fue el resultado. El resultado de la
actualización, podrá ser exitoso, con observaciones o con errores. El usuario, entonces
contará con información para tomar decisiones al respecto. Por lo tanto este prototipo,
requiere tener su propia base, para registrar su actividad. Esto se refleja en la Figura 8.
Figura 8 - Incorporación de una propia base de datos al prototipo integrador
Como este tipo de actividades, de alta carga de consultas a la base de datos, podría
alterar la eficiencia del sistema transaccional, se propone trabajar con una réplica
actualizada, lo que se denomina Base de datos de Soporte de Decisiones, tal como se
representa en la Figura 9.
30/69
Figura 9 - Incorporación de una Base de datos de Soporte de Decisiones
Esta metodología de replicación para el soporte de decisiones, debería utilizarse para
todos los orígenes de datos. De acuerdo a la definición de frecuencia y mecanismo
para los procesos de actualización, los mismos podrían iniciarse a partir de un evento
de usuario o de un evento programado en el sistema. Esto se refleja en el bosquejo
final de la arquitectura del sistema, que se representa en la Figura 10.
31/69
Figura 10 - Bosquejo de la arquitectura del prototipo
Para el diseño de la solución de contempló la posibilidad que el prototipo tenga la
capacidad de consultar varias bases de datos como un sólo origen de la información.
Esto surgió a partir del caso de estudio analizado, ya que algunos sistemas SIU
requieren una base de datos por ejercicio, por ejemplo el sistema de Preinscripción
requiere que se genere una nueva base de datos para cada año. Con lo cual es
posible obtener información para un mismo indicador a partir de distintos orígenes.
Este grupo de bases de datos, mantiene la idea conceptual de un solo origen para
cada indicador, tal como se puede observar en la Figura 11.
32/69
Figura 11 - Grupo de bases de datos como origen de una misma consulta.
La situación analizada se implementa definiendo un grupo de conexiones a bases de
datos, que contiene las conexiones propiamente dichas, con la configuración de
conexión específica de cada caso particular. Inicialmente y para atender a los
requerimientos del caso de estudio, este prototipo considera tipos de conexión a los
motores Informix, Postgres, MySQL, brindando la posibilidad de extender a más de ser
necesario, como se detallará más adelante. Cada indicador tiene definido un grupo de
bases que es sobre el que se va a efectuar la consulta correspondiente para calcular y
extraer los valores de cada indicador. Un grupo puede contener una conexión a una
única base de datos o a varias.
En cuanto a la conexión a la base de datos del prototipo para dar soporte a la gestión
de indicadores (BDI) es siempre la misma, con lo cual se define como parámetro del
sistema. Si bien la definición de la conexión está incluída en la tabla de las conexiones
a las bases de datos, se selecciona a través de un parámetro definido en el prototipo.
El prototipo no lleva registro de la definición de los indicadores ya que se consultan
directamente en la BDI, sólo se cuenta con una tabla de indicadores, con el
33/69
identificador a los mismos. Esto es así para evitar la replicación de información con su
consecuente disminución de acoplamiento entre los prototipos evitando así los
inconvenientes en la falta de consistencia.
En la Figura 12 se muestra con un diagrama de entidad relación cómo se modelan en
la base del integrador de fuentes las conexiones particulares a cada base de datos y
los grupos de conexión.
Figura 12 - Diagrama entidad relación del modelado de las conexiones a las bases de datos
3.4. Editor de código
Para la funcionalidad de edición de código, que permite escribir las consultas
necesarias para el cálculo de los valores del indicador, se pensó en la posibilidad de
escribir consultas SQL enriquecidas con un lenguaje de programación como PHP. Este
tipo de consultas permite calcular y extraer los valores correspondientes para un
34/69
indicador permitiendo realizar cálculos más amplios y de manera más sencilla que con
una exclusiva sentencia SQL.
Por ejemplo, si se quisiera calcular el indicador cantidad de egresados
correspondientes a una determinada cohorte, por ejemplo cohorte 2010, se puede
realizar una consulta sobre la base que retorne todos los inscriptos cohorte 2010 que
ya han egresado. Luego mediante la funcionalidad que provee PHP se contaría
cuantos de ellos egresaron en 2014, cuántos en 2015, y así sucesivamente. Realizar
esta operación completa en una única consulta SQL sería excesivamente compleja y
muy poco legible, y hasta en algunos casos imposible de realizar. Proveyendo
funcionalidad extra se enriquece mucho las posibilidades de cálculo y extracción de
valores en algunos casos.
Cuando se define un indicador por primera vez, se carga un código predefinido a
manera de plantilla guía o template, la cual incluye comentarios correspondientes a los
campos definidos de Nombre, Ficha Metodológica, Fórmula, Frecuencia y Unidad de
medida, para que sirva de modo orientativo al usuario del sistema para escribir el
código necesario, como se muestra en la Figura 13.
Figura 13 - Plantilla base para el editor de código
35/69
También, es necesario definir en este momento la fuente de consultas, es decir a qué
grupo de bases de datos se conectará para efectuar la consulta correspondiente para
la obtención de los valores del indicador en cuestión.
El template incluye una función obligatoria denominada “get_valores” la cual debe
estar definida y debe retornar en todos los casos un arreglo con los campos fecha y
valor del indicador definido. De no ser así, el prototipo contempla la emisión de
excepciones para registrar la falla y notificar al usuario del error.
3.5. Almacenamiento y ejecución de consultas
Como parte fundamental del diseño se optó por almacenar las consultas en archivos
para ser procesadas de manera manual o automática de acuerdo a un calendario, con
la frecuencia de actualización definida en cada indicador.
Para esto, el código escrito en el editor se almacena como un archivo php dentro del
sistema. Con lo cual se puede recuperar y modificar en el momento que se desee.
También existe la posibilidad de eliminarlo, luego de lo cual si se desea volver a definir
el código que calcula los valores para el indicador se vuelve a cargar la plantilla
original por defecto. El texto a visualizar en el editor de código se selecciona de
acuerdo al diagrama de flujos que se muestra en la Figura 14.
36/69
Figura 14 - Diagrama de flujo para el texto a visualizar en el editor de código
En todos los casos, al momento de guardar los cambios, se valida la sintaxis, para
corroborar que sea código php válido.
Lo más interesante de esta parte es que para ejecutar este código generado por el
usuario, dinámicamente se carga en memoria y se procesa. Es decir, a la hora de
ejecutar un determinado indicador, se incluye dinámicamente la clase que lo define, y
se llama a la función “get_valores”, previa verificación que exista, dado que debe estar
definida necesariamente, como se explicaba antes. Esto se puede observar en el
diagrama de flujo expuesto en la Figura 15. En este proceso se vuelve a realizar un
chequeo de sintaxis, para evitar errores o mal funcionamiento debidos a una posible
modificación externa al sistema del archivo php.
37/69
Figura 15 - Diagrama de flujo de la ejecución de la consulta
Ante cualquier eventual falla, por no existencia de la clase o del método, error de
sintaxis, falta de definición de las bases a las cuales debe conectarse, o error en la
consulta sql procesada, se capturan las excepciones emitidas, se registra en la base el
inconveniente y se notifica al usuario con el mensaje correspondiente.
38/69
Por otro lado, el prototipo para dar soporte a la gestión de indicadores gestiona
estados para los valores de cada indicador, definidos por el usuario, por ejemplo
podrían ser: "Malo" - "Regular" - "Bueno" - "Muy bueno", acorde a entre qué umbrales
se encuentre cada valor.
Una vez calculados los valores para el indicador, se almacenan en la BDI a través de
web services, tecnología que utiliza un conjunto de protocolos y estándares que sirven
para intercambiar datos entre aplicaciones y que provee el prototipo para dar soporte a
la gestión de indicadores.
Un ejemplo de actualización de un indicador dado en la BDI utilizando web services
sería el siguiente:
<?php //--1- Arma el mensaje $datos = [
"id" => "358", "valorIndicador" =>
[ [ "fecha"=> "01-06-2004",
"idIndicador"=> "358", "valor"=> "88"
], [ "fecha"=> "02-06-2005",
"idIndicador"=> "358", "valor"=> "80"
], [ "fecha"=> "03-06-2006", "idIndicador"=> "358", "valor"=> "58"
], [ "fecha"=> "04-06-2007", "idIndicador"=> "358",
"valor"=> "50" ],
[ "fecha"=> "06-06-2008", "idIndicador"=> "358",
"valor"=> "65" ]
] ];
//En action se detalla la operación a invocarse $opciones = array('action' => 'importar'); $mensaje = new toba_servicio_web_mensaje($datos, $opciones); //--2- Arma el servicio $opciones = array(); $url = 'http://localhost:8080/pgi/rest/indicadores'; $servicio = toba::servicio_web($url, $opciones);
39/69
//-- 3 - Muestra la respuesta $respuesta = $servicio->request($mensaje); toba::notificacion()->info($respuesta->get_payload());
?>
3.6. Modelado de Tareas
Si bien el cálculo de un indicador y la correspondiente inserción de sus valores puede
ser actualizado de manera manual utilizando la funcionalidad del prototipo para dar
soporte a la gestión de indicadores, se planteó la necesidad de independizarlo del uso
de un operario.
Para cumplir con esta la necesidad, se creó un modelado de tareas en el sistema, con
persistencia en la base de datos. De esta forma, y a través de la interfaz del sistema,
el usuario, en forma clara y sencilla, puede:
● Definir nuevas Tareas
● Modificar Tareas
● Eliminar Tareas
● Anular o inhabilitar tareas en forma momentánea
● Consultar sobre la ejecución
Para esto se diseñó la posibilidad de definir una tarea asociada a un indicador en
particular, con fecha de inicio y fin, es decir por qué período de tiempo estará
disponible, la posibilidad de definir una hora en particular deseada para la ejecución de
los cálculos, la definición de si está habilitada a ejecutarse o no, sumado a algunos
datos estadísticos de los resultados de la ejecución.
Esta funcionalidad implica configurar las tareas instanciadas en base a dicha
definición, es decir, las tareas concretas que serán ejecutadas. Es decir, una tarea
puede ser por ejemplo calcular el indicador “x” con una frecuencia mensual durante un
período de 5 años. Las tareas concretas serán las que tengan definido el día
específico a ser ejecutadas. El calendario muestra estas tareas concretas.
La frecuencia que se contempló es diaria, semanal, mensual o anual, pudiendo
incorporar más variantes a futuro.
40/69
Se definió un organizador (scheduler) de tareas, el cual es una clase que tiene la
posibilidad de coordinar las mismas, revisar todas las tareas y seleccionar las que
corresponda que sean ejecutadas. Las mismas se encolan en una lista de prioridades.
Una vez que el organizador selecciona todas las tareas a ejecutar, las va tomando de
la cola de prioridades.
A su vez, cada una de las tareas tiene un posible estado de ejecución:
● pendiente
● activo
● ejecutado exitosamente
● ejecutado exitosamente sin almacenar nuevos datos
● ejecutado con error
Cada uno de esos estados tiene asociado un color distinto para poder ser
representado de una manera intuitiva y visual en el calendario, como se explicará más
adelante en el apartado correspondiente al calendario.
El organizador sólo selecciona de entre aquellas tareas cuyo estado sea pendiente, ya
que los otros indican que de una manera u otra la tarea ya fue ejecutada o lo está
siendo. Esto evita que una misma tarea puede ser seleccionada más de una vez.
Es decir, los estados (en especial Activo) anulan el riesgo de algún tipo de trashing 1
por demora en la ejecución. Supongamos que como frecuencia se tiene 15 minutos y
se dispara una tareas que demora 30 minutos, en el siguiente chequeo, si la tarea no
tiene un flag de estado indicando que aún está en ejecución, podría volver a iniciarse,
cuando aún no ha terminado, con la posibilidad de un bloqueo si espera recursos que
están en uso.
El módulo de tareas programadas inicia una instancia del Scheduler. El Scheduler
recupera todas las tareas habilitadas y las organiza en una fila de primero entrada,
primero salida (FIFO). Esto se puede observar en el esquema de la Figura 16. Luego
extrae, una a una todas las tareas de la fila y verifica si debe ejecutarlas. Aquellas
1 Trashing: situación que se produce cuando el subsistema de memoria virtual de una computadora se encuentra en un estado constante de paginación, intercambiando rápidamente datos en la memoria por datos en el disco, con exclusión de la mayoría del procesamiento a nivel de aplicación. Esto hace que el rendimiento de la computadora se degrade o se colapse. La situación puede continuar indefinidamente hasta que se aborde la causa subyacente.
41/69
tareas que deban ser ejecutadas se inician. Al finalizar genera un reporte con el
resultado de la ejecución.
Figura 16 - Diagrama de clases correspondiente al scheduler de tareas
Se agregó un seguimiento de todas las tareas realizadas. Por cada actualización que
se hace en la BDI, se lleva un registro de qué valores se insertaron, en qué tabla, a
qué hora, por quién, si la inserción fue exitosa o hubo algún inconveniente. Con esto
se permite poder observar y hacer un seguimiento de las operaciones realizadas.
Es decir, una vez calculado el valor para un indicador, además de actualizar la
información correspondiente en la BDI, se registra a modo de log: qué resultado, en
qué momento, por quién y qué bases fueron las que se consultaron para dicho cálculo.
Para esto se utilizan las tablas log_indicador, que sería un reflejo de lo que sucede en
la tabla “indicador” del otro prototipo, y log_valor_indicador que registra lo que sucedió
en la tabla que almacena los valores y estados para el mismo. El diseño se puede ver
en la Figura 17. Esto se implementó a modo de llevar una auditoría de lo que se
actualiza en cada ocasión en el otro prototipo.
42/69
Figura 17 - Diseño de tablas para registro de auditorías
Además se incorporó la información de cuánto demoró el cálculo de los valores para el
indicador, de manera de poder a futuro y como mejora programar en un orden eficiente
la ejecución de las tareas de actualización.
43/69
3.7. Calendario de tareas
Otro aspecto de diseño muy relevante a la hora de dar seguimiento a las tareas de
actualización, es la posibilidad de contar con un calendario que brinda información
visual y detallada acerca del estado de la ejecución de las consultas realizadas a la
manera de tareas programadas.
En el caso que la tarea no se ejecute debidamente, la misma se marca de color rojo. Si
está pendiente de ser ejecutada, o debe hacerlo en un futuro se verá amarilla. Si se
ejecutó normalmente quedará en color verde, en caso de ser con actualización de
datos será verde oscuro y si la ejecución fue exitosa pero sin actualización de valores
será verde claro. Por último, para el caso de la tarea que se esté ejecutando en el
momento será de color azul. De esta manera con una simple visualización del
calendario el usuario tendrá un panorama del estado de las ejecuciones.
3.8. Sincronización de tareas automatizadas
Normalmente los sistemas de gestión se implementan para responder a eventos que
devienen de la interacción con el usuario. El usuario agrega, elimina, modifica o
consulta piezas de información y esta actividad genera una reacción en el sistema.
Cuando como parte de los requerimientos funcionales se necesita implementar tareas
automatizadas, el modelo anterior debe ser adaptado a tal fin. Los eventos deben ser
iniciados por un agente exterior al sistema. El mejor candidato para esta tarea es el
sistema operativo [SO].
En el presente trabajo, el sistema operativo será el encargado de invocar al módulo de
tareas programadas, tal como se puede observar en la Figura 18, el cual a su vez
iniciará una instancia del Scheduler como fue explicado en la anterior sección. De esta
manera se logra la automatización necesaria sin la intervención de un operario para
que las tareas puedan ser ejecutadas.
44/69
Figura 18 - Esquema para el módulo de tareas programadas
Los sistemas operativos cuentan con rutinas que pueden ser programadas para
ejecutar un programa o script en determinadas frecuencias o periodos.
El sistema operativo Unix, cuenta con un administrador regular de procesos en
segundo plano, denominado CRON, que ejecuta procesos a intervalos regulares (por
ejemplo, cada minuto, día, semana o mes). Los procesos que deben ejecutarse y la
hora en la que deben hacerlo se especifican en el archivo crontab del sistema
operativo. El nombre cron viene del griego chronos (χρόνος) que significa "tiempo". El
CRON se podría definir como el "equivalente" a Tareas Programadas de Windows.
De esta forma, la adaptación necesaria para el prototipo, requerirá de una extensión
que, con las debidas medidas de seguridad, permita que el SO invoque, para indicarle
al mismo el evento que se desea automatizar.
Se debe considerar que podrían existir muchos eventos, y también el usuario final del
sistema podría gestionar (crear nuevos, eliminar, modificar, cancelar la ejecución, etc.).
Una alternativa sería generar en el SO tantos CRON y módulos de invocación, como
tareas existieran, pero esto requeriría también eliminarlos si desde el sistema se
eliminan las tareas o se desactivan. La interacción del usuario con el SO aunque fuera
a través del mismo prototipo, sería bastante amplia, con un nivel de acople al SO
45/69
bastante alto, para ello el programador del sistema debería conocer como
hacer/modificar tareas en el SO, sea Windows o Linux o todas sus versiones o
variantes. Por el contrario se puede hacer un solo CRON, con la menor frecuencia de
actualización permitida, que permanentemente interactúe con el prototipo a través de
un solo módulo. La desventaja de esta solución puede ser la sobrecarga del sistema
con consultas permanentes, pero si la frecuencia es una vez al día, esto es
insignificante. Por otro lado la ventaja es enorme, ya que reduce al mínimo la
interacción entre la extensión y el SO.
Para ésto, se agregó un archivo php que desencadena la búsqueda y ejecución de las
tareas programadas, el cual va a ser invocado por el sistema operativo con cierta
frecuencia regular, como será detallado un poco más adelante.
<?php
require_once ('class.Organizador.php');
$scheduler = new Organizador();
$scheduler->ejecutar();
?>
3.8.1. CRON
Se trata de una funcionalidad en el SO. En las distintas variantes de Windows, se
definen como Tareas Programables, donde por medio de una interfaz gráfica se puede
definir la frecuencia y el programa o archivo de proceso por lotes a ejecutar. En los
sistemas Linux, varían un poco según la distribución, pero básicamente se configura
un archivo de texto especial, donde se indican las frecuencias y programa, comando o
script de shell a ejecutar. En cualquiera de los dos casos existe abundante
documentación al respecto y no es una tarea compleja [PT-Win] y [Cron]. Además, en
ambos casos, se deberá ejecutar el mismo script o archivo de proceso por lotes, con
muy pequeñas diferencias, pero siempre invocando al mismo módulo de extensión que
se describe en la siguiente sección. Se deberá tener la precaución de establecer como
frecuencia de actualización, la menor frecuencia posible de todas las tareas
programables. Esto quiere decir que si se programan tareas que se deben ejecutar
una vez a la semana y tareas que deben ejecutarse una vez al día, esta última implica
un horario en particular. Si este horario se segmenta por cada 30 minutos, la tarea
46/69
programada deberá tener un período de 30 minutos. Si por otro lado este horario,
utiliza solo horas exactas, la tarea programada deberá tener un período de 1 hora.
En definitiva, basta con incorporar en el CRON del SO la siguiente línea:
# m h dom mon dow command
0 * * * * php $PATH_PROTOTIPO/iniciar.php
Esto sería, ejecutar a los 0 minutos, de cada hora, de todos los días, de todas meses,
el comando especificado. En este ejemplo el comando estaría corriendo cada una
hora. Como se puede observar es muy simple cambiar la frecuencia en caso de
requerir.
En la siguiente figura se puede observar un diagrama de secuencias del proceso de
ejecución automática de tareas.
Figura 19 - Diagrama de secuencias del proceso de ejecución automática de tareas
47/69
4. Caso de estudio
4.1. Introducción
En el siguiente capítulo se expone un caso de estudio aplicado a la Facultad de
Ciencias Exactas de la UNCPBA en el cual se extraen valores de los distintos sistemas
que se utilizan en la unidad académica para integrarlos en la BDI.
El caso de estudio desarrollado se basó en el cálculo de los valores y actualización
para los siguientes indicadores, entre otros (como se detalla en Anexo):
1. Aspirantes Sistemas
2. Nuevos Inscriptos Sistemas
3. Reinscriptos Sistemas
4. Estudiantes Sistemas
5. Duración promedio de la carrera Ingeniería en Sistemas
6. Egresados Sistemas
4.2. Caso de estudio aplicado en el prototipo
En esta sección se muestran funcionalidades específicas, como la conectividad de las
distintas bases de datos para poder extraer datos de los sistemas transaccionales
(ejemplo Guaraní) y poder actualizar automáticamente la base de datos de
indicadores.
Para poder calcular valores para los indicadores definidos en la Base de Datos de
Indicadores (BDI) primero se deben configurar y establecer las conexiones a las
diversas bases de datos que deseamos consultar, siguiendo el proceso de conexión
que se mostró en la Figura 6.
Para ello el sistema ofrece una operación que permite gestionar las diferentes
conexiones, pudiendo filtrar las mismas por el tipo de conexion (Informix, Postgres,
MySQL), tal como se puede observar en la Figura 20.
48/69
Figura 20 - ABM de conexiones a las bases de datos
Como se puede observar, se listan los parámetros a las bases de datos ya
configuradas. Y se permite dar de alta una nueva conexión.
En este caso de estudio particular, se pueden observar:
● 4 conexiones informix a distintas bases de datos que gestionan el curso de
ingreso, cada una de ellas corresponden a un año académico distinto. Estas
son: ingr_guarani_2014, ingr_guarani_2015, ingr_guarani_2016 e
ingr_guarani_2017.
● 1 conexión informix a guarani que gestiona todas las carreras de grado:
siu_guarani.
● 1 conexión mySql a la BDI: bdi_exa.
● 4 conexiones postgres a distintas bases de datos que gestionan las
preinscripciones a nuestra facultad, una por cada año académico:
preinscripcion_2014, preinscripcion_2015, preinscripcion_2016 y
preinscripcion_2017..
49/69
Para dar de alta una nueva conexión se debe establecer primero el motor de base a
utilizar, por el momento el sistema gestiona los siguientes motores: Informix,
PostgresSQL y MySQL, pudiendo ampliar las posibilidades a futuro. Esto se muestra
en la Figura 21.
Figura 21 - Alta de una nueva conexión a base de datos
Luego de seleccionar el tipo de servidor de base de datos, se deben establecer los
parámetros de la conexión, que varían levemente de acuerdo al motor seleccionado,
como se puede observar en los ejemplos de la Figura 22, Figura 23 y Figura 24:
Figura 22 - Parámetros para el alta de una nueva conexión Informix
50/69
Figura 23 - Parámetros para el alta de una nueva conexión mySql
Figura 24 - Parámetros para el alta de una nueva conexión Postgres
Para validar la definición correcta de los parámetros de conexión, el sistema además
de verificarlo automáticamente, también permite testear la conexión, ante lo cual se
emite un mensaje indicativo de acuerdo al resultado de la prueba, y en caso de falla
indicando el inconveniente encontrado, tal como se muestra en la Figura 25 y en la
Figura 26 respectivamente.
Figura 25 - Testeo de conexión exitosa a una determinada base de datos
51/69
Figura 26 - Testeo de conexión fallida a una determinada base de datos
Una vez definidas las conexiones específicas a cada una de las bases de datos, se
hace necesario definir los grupos de conexiones. Esto se implementó de esta manera
teniendo en consideración que el caso de estudio puede requerir consultar a más de
una base de datos como único origen de la información, manteniendo así la idea
conceptual de un sólo origen para cada indicador, según se detalló anteriormente y se
observa en la Figura 11.
Un caso particular de esto es la información gestionada para el curso de ingreso, que
requiere de una base de datos por ejercicio. Como se mostrara en la creación de las
conexiones (Figura 20), existen 4 bases de datos informix, una para cada año
académico: ingr_guarani_2014, ingr_guarani_2015, ingr_guarani_2016 e
ingr_guarani_2017.
Por este motivo, se deben definir los grupos de conexiones a las bases de datos, que
contienen las conexiones propiamente dichas y que serán necesarias para efectuar la
consulta correspondiente para calcular y extraer los valores de cada indicador (Figura
27). Un grupo puede contener una conexión a una única base de datos o a varias.
Figura 27 - ABM de grupos de conexiones a BD
52/69
En la Figura 28 se puede observar un ejemplo de grupo de conexión con una única
base de datos como conexión, como es el caso del sistema Guaraní que gestiona las
carreras de grado, y que por ejemplo se utilizará para calcular el indicador “Estudiantes
Sistemas”.
Figura 28 - Grupo de conexión con una única base de datos como conexión
En la Figura 29 se puede observar un ejemplo de grupo de conexión con varias bases
de datos específicas como conjunto de conexiones, como es el caso del sistema que
gestiona el curso de ingreso, y que por ejemplo se utilizará para calcular el indicador:
“Aspirantes Sistemas”.
Figura 29 - Grupo de conexión con varias bases de datos como conexión
53/69
Una vez especificadas las posibles conexiones, se deben escribir las consultas
correspondientes para el cálculo de cada indicador.
Para esto, el prototipo cuenta con una operación que lista los indicadores definidos en
la BDI (destinada a dar soporte a la gestión de indicadores), que es donde se
encuentra la definición de los mismos (Figura 30). El listado se puede filtrar por parte
del nombre del indicador o por su identificador, caso contrario lista todos los
existentes:
Figura 30 - Listado de Indicadores definidos en BDI
Ingresando en la lupa correspondiente al indicador deseado, se despliega el editor de
código que permite escribir las consultas a la base de datos (SQL) enriquecidas con el
lenguaje de programación PHP. De esta forma se puede calcular y extraer los valores
correspondientes a dicho indicador. Cuando se define la consulta para un indicador por
primera vez, se carga un código predefinido a manera de plantilla guía o template, la
cual incluye comentarios correspondientes a los campos definidos de Nombre, Ficha
Metodológica, Fórmula, Frecuencia y Unidad de medida, para que sirva de modo
orientativo al usuario del sistema para escribir el código necesario, tal como se detalla
en la Figura 31.
54/69
Figura 31 - Editor de código con plantilla base y opción de modificar la fuente de consultas
También es necesario definir en este momento la fuente de consultas, es decir a qué
grupo de bases de datos se conectará para efectuar la consulta correspondiente para
la obtención de los valores del indicador en cuestión. Esto se puede observar en la
Figura 32.
Figura 32 - Selección del grupo de consultas como fuente de datos
La plantilla incluye una función obligatoria denominada “get_valores” la cual debe estar
definida y debe retornar en todos los casos un arreglo con los campos fecha y valor 2
2 Arreglo o Array: zona de almacenamiento contiguo que contiene una serie de elementos del mismo tipo. Desde el punto de vista lógico un arreglo se puede ver como un conjunto de elementos ordenados en fila.
55/69
del indicador definido. De no ser así, el sistema emite un mensaje de error al querer
ejecutar dicho código. Además controla que el formato de la fecha sea el adecuado.
A continuación, en la Figura 33 se muestra el ejemplo para el indicador “Cantidad de
Aspirantes a la carrera de Ingeniería de Sistemas”. Esta consulta se realiza sobre un
grupo de bases de datos de ingreso, ya que cada año académico utiliza una nueva
base en blanco para gestionar a los nuevos aspirantes y su desempeño en el curso de
ingreso.
Figura 33 - Ejemplo de consulta para el cálculo de un indicador
Existe la posibilidad de guardar dicho código. El mismo se almacena en un archivo
plano dentro del sistema. Con lo cual se puede recuperar y modificar en el momento
que se desee, basta con ingresar nuevamente a la vista de detalle correspondiente a
dicho indicador. También existe la posibilidad de eliminarlo, luego de lo cual si se
desea volver a definir el código que calcula los valores para el indicador se vuelve a
cargar la plantilla original por defecto.
56/69
Este código es almacenado en un archivo con extensión .php, que se procesa
dinámicamente al presionar sobre el botón “Ejecutar”.
En este momento, cuando se desea ejecutar manualmente el cálculo de los valores
para el indicador, también existe la posibilidad de cambiar la fuente de datos a
consultar (Figura 32), esto es útil para cuando se desea calcular un mismo indicador,
pero sobre diferentes fuentes de datos.
Una vez que se presiona sobre el botón “Ejecutar” se calculan los valores para dicho
indicador desde la fuente de datos que se le haya establecido como origen, emitiendo
el resultado primero por pantalla, tal como se ve en la Figura 34.
Figura 34 - Resultado de la ejecución de una consulta
En este punto se indica por defecto la acción a realizar para cada par fecha-valor
calculado (como se observa en A), con las siguiente posibilidades:
● “Omitir”: El usuario a su criterio desea no almacenar este resultado en la BDI.
● “Insertar”: El valor será actualizado en la BDI.
● “Ya existe valor (omitir)”: El sistema detecta que en la BDI ya existe un valor
para esta fecha (ya sea el mismo o no), con lo cual advierte que lo más
oportuno sería omitir actualizarlo. El usuario a su criterio podría considerar
oportuno cambiarlo, con lo cual podría modificar la opción a “Insertar”.
Este valor puede ser cambiado por el usuario, bajo su responsabilidad. Por defecto,
todo valor anterior a la fecha de última actualización que tenga definida el indicador se
omite, así como también todas las fechas posteriores a las del día actual. Si existiera
57/69
una de esas fechas con valor para ese indicador, se indica que ya existe valor
(independientemente sea el mismo o no).
Cuando se presiona sobre el botón “Guardar en BDI” (mostrado en B) recién en este
momento se insertan datos en la BDI.
Si hubiera algún inconveniente por el cual el dato no se pudiera almacenar, como por
ejemplo que justo en ese momento estuviera caída la conexión a la BDI, se emite por
pantalla un mensaje detallado del error.
El prototipo cuenta con tablas de log dentro del sistema que registran cada acción
realizada sobre la BDI, de tal forma que se pueda utilizar para eventuales auditorías.
Esto será detallado al final del presente capítulo.
También se cuenta con la funcionalidad de poder ver los valores registrados en la BDI,
como se observa en la Figura 35. Esto es sólo a manera informativa. Se puede filtrar
tanto por el nombre del indicador como por su identificador.
Figura 35 - Consulta sobre los valores almacenados en BDI para un determinado indicador.
Como parte de los procesos de automatización, se contempló la funcionalidad de
poder definir tareas asociadas a un indicador, indicando frecuencia, fecha de inicio y
de fin y si está habilitada o no. En caso de ser necesario o requerirlo se puede definir
la hora a la que se desea se ejecute. El indicador sobre el cual se va a definir la tarea
se selecciona de una lista desplegable, basada en los indicadores de la BDI, tal como
se puede ver en la Figura 36.
58/69
Figura 36 - Alta de nueva Tarea
Se cuenta además con un listado detallado de las tareas definidas, en donde se puede
observar el estado, duración y fecha de la última ejecución, así como también la
duración promedio de todas las veces que se haya ejecutado (Figura 37). También
contempla la posibilidad de modificar las mismas, en caso de desear cambiar la
frecuencia o el período a estar habilitada. En caso de modificar una tarea definida con
anterioridad y que ya ha sido ejecutada, el sistema solo la reprograma a partir de la
fecha, conservando intacto el historial.
Figura 37 - ABM de Tareas
59/69
Para poder dar un seguimiento al procesamiento de las tareas automáticas, esta
versión del prototipo cuenta con un calendario que visualiza las tareas programadas y
el estado en que se encuentran.
Como se puede observar en la Figura 38, en verde indica que ha sido ejecutada
exitosamente. Presentando la variante del oscuro para la inserción de valores en el
prototipo para dar soporte a la gestión de indicadores y el claro para la ejecución
exitosa pero que no retornó resultados y no se insertaron nuevos valores. El rojo indica
ejecución con errores, y el usuario deberá analizar el inconveniente producido
registrado en el log de tareas. Mientras que el amarillo representa aquellas tareas
pendientes y que deberán ser ejecutadas a futuro en su momento oportuno.
Pasando el mouse sobre alguna tarea se despliega un tip indicando el resultado de la
ejecución.
Figura 38 - Calendario de tareas
60/69
Este calendario tiene las opciones de visualizarse en formato mensual, semanal o
diario, según sea la preferencia o comodidad del usuario, ya que al disminuir la
cantidad de días a visualizar se puede tener más detalle de la leyenda en la tarea.
Una mejora que se puede aplicar en este punto es permitir que el usuario desde el
mismo calendario pueda generar nuevas tareas, desplazar o modificar alguna en
particular, o hasta eliminarla si es que no ha sido ejecutada ya, en caso de desearlo.
Esto es tenido en cuenta en el capítulo 5, dentro de los trabajos futuros.
Por último, se cuenta con operaciones de auditoría, que son registros de todo lo que
se ha ejecutado en el prototipo, ya sea de manera manual o automática, tanto sobre la
tabla que registra la definición de los indicadores (Figura 39) como sobre la tabla que
almacena los valores para los mismos (Figura 40) en la BDI. En cada caso se asienta
un detalle del momento en que se realizó la ejecución, a través de qué usuario, sobre
qué base de consulta y cuál fue el resultado de la misma. La operación permite, si se
desea, filtrar por alguna fecha, indicador, usuario y/o base en particular.
Figura 39 - Log de auditoría para la definición de indicadores
61/69
Figura 40 - Log de auditoría para los valores de los indicadores
62/69
5. Conclusiones y trabajos futuros La idea central de este proyecto ha sido la de desarrollar un prototipo de fácil uso e
intuitivo que ayude a integrar diferentes fuentes de datos para la gestión por
indicadores.
Se logró construir una herramienta que permitiera la extracción de información y que
actuara de interfaz entre los sistemas transaccionales existentes en la institución y el
prototipo para dar soporte a la gestión de indicadores (BDI), sumado a un conjunto de
funcionalidades que permitió la implementación y seguimiento de la programación de
tareas automatizadas de actualización de los indicadores y registro de las operaciones
realizadas.
A continuación se presentan algunos trabajos futuros que pueden desarrollarse como
resultado de esta investigación o que, por exceder el alcance de esta tesis, no han
podido ser tratados con la suficiente profundidad.
● Permitir crear, modificar, desplazar y eliminar tareas desde el calendario
gráfico, de una manera intuitiva y amena.
● Extender la funcionalidad de conectarse a otras bases de datos además de
Informix, Postgres y MySQL.
● Notificación por mail en caso de falla en la ejecución de alguna tarea
automática.
● Emisión de reportes del estado de las tareas.
● Continuar con el desarrollo del software para mejorar la usabilidad y la
performance de la misma, ya que al tratarse de un prototipo sería el principal
trabajo a futuro.
● Acceso encriptado a web-service de tipo REST para las actualizaciones en la
BDI.
63/69
Anexo Dentro del proyecto integral PEFI, se calcularon los valores y actualización para los
siguientes indicadores:
1. Aspirantes
2. Aspirantes Sistemas
3. Aspirantes TUDAI
4. Duración promedio de la carrera Ingeniería en Sistemas
5. Egresados
6. Egresados por equivalencia
7. Egresados por equivalencia Sistemas
8. Egresados por equivalencia TUDAI
9. Egresados Sistemas
10. Egresados Sistemas cohorte 2004
11. Egresados Sistemas cohorte 2005
12. Egresados Sistemas cohorte 2006
13. Egresados Sistemas cohorte 2007
14. Egresados TUDAI
15. Estudiantes
16. Estudiantes extranjeros
17. Estudiantes extranjeros Sistemas
18. Estudiantes extranjeros TUDAI
19. Estudiantes internacionales
20. Estudiantes internacionales Sistemas
21. Estudiantes internacionales TUDAI
22. Estudiantes Sistemas
23. Estudiantes TUDAI
24. Nuevos Inscriptos
25. Nuevos inscriptos por equivalencia
26. Nuevos inscriptos por equivalencia Sistemas
27. Nuevos inscriptos por equivalencia TUDAI
28. Nuevos inscriptos por primera vez
29. Nuevos inscriptos por primera vez Sistemas
30. Nuevos inscriptos por primera vez TUDAI
64/69
31. Nuevos Inscriptos Sistemas
32. Nuevos Inscriptos TUDAI
33. Reinscriptos
34. Reinscriptos Sistemas
35. Reinscriptos TUDAI
36. Tasa graduación Sistemas cohorte 2004
37. Tasa graduación Sistemas cohorte 2005
38. Tasa graduación Sistemas cohorte 2006
39. Tasa graduación Sistemas cohorte 2007
65/69
Bibliografía AENOR (2003). “GUÍA PARA LA IMPLANTACIÓN DE INDICADORES”. Norma
Española UNE66175. Asociación Española de Normalización y Certificación. Sistemas
de gestión de calidad. Madrid, España.
BALLVÉ A. (2000): “TABLERO DE CONTROL”. Ed. Macchi. Buenos Aires.
BARONE D.; JIANG L.; AMYOT D.; MYLOPOULOS J. (2011) “COMPOSITE
INDICATORS FOR BUSINESS INTELLIGENCE”. Jeusfeld M., Delcambre L., and Ling
T.W. (Eds.) © Springer-Verlag Berlin Heidelberg.
DEL SORDOA C.; ORELLI R.; PADOVANI E.; GARDINI S. (2012) “ASSESSING
GLOBAL PERFORMANCE IN UNIVERSITIES: AN APPLICATION OF BALANCED
SCORECARD”. Elsevier Ltd.
[ILLE2014] ILLESCAS G.: Tesis Doctoral “APLICACIÓN DE MÉTODOS
MATEMÁTICOS EN EL CONTROL DE GESTIÓN POR INDICADORES”. Marzo 2014 ,
en repositorio digital de la biblioteca central UNICEN.
KAPLAN R.; NORTON D. (1992): “THE BALANCED SCORECARD-MEASURES THAT
DRIVE PREFORMANCE”. Harvard Business Review, enero-febrero.
KAPLAN R.; NORTON D. (1996): “USING THE BALANCED SCORECARD AS A
STRATEGIC MANAGEMENT SYSTEM”. Harvard Business Review, enero-febrero.
KAPLAN R.; NORTON D. (2000): “CUADRO DE MANDO INTEGRAL”. 2da edición.
Ediciones GESTION 2000.
MORA-SOTO J. (2011). “MARCO METODOLÓGICO Y TECNOLÓGICO PARA LA
GESTIÓN DEL CONOCIMIENTO ORGANIZATIVO QUE DE SOPORTE AL
DESPLIEGUE DE BUENAS PRÁCTICAS DE INGENIERÍA DE SOFTWARE”. Tesis
Doctoral. Escuela Politécnica Superior, Universidad Carlos III, Madrid. Dirección: Dra.
Sánchez-Segura M.
SINERGIA1. “GUÍA PARA ELABORACIÓN DE INDICADORES”. Departamento
Nacional de Planeación. Sistema Nacional de Evaluación de Resultados de la Gestión
Pública (SINERGIA). Colombia. Grupo Asesor de la Gestión de Programas y
66/69
Proyectos de Inversión Pública (GAPI). Disponible en:
https://www.dnp.gov.co/Portals/0/archivos/documentos/DIFP/Bpin/Guia_para_elaboraci
on_de_indicadores.pdf
[PEFI] PEFI http://pefi.siu.edu.ar/
Documentación referente al ambiente de desarrollo web SIU-Toba
https://toba.siu.edu.ar/trac/toba/wiki/Documentacion
Documentación referente a PostgreSQL.
https://www.postgresql.org/docs/9.3/static/index.html
Documentación referente a Informix
https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.welcome.
doc/welcome.htm
Documentación referente a MySQL
https://dev.mysql.com/doc/refman/5.7/en/
Documentación referente a PHP
http://php.net/manual/es/index.php
[ETL] Procesos ETL
https://www.datasciencecentral.com/profiles/blogs/10-open-source-etl-tools
[Websphere] IBM Websphere DataStage https://www.ibm.com/support/knowledgecenter/es/SSZJPZ_8.1.0/com.ibm.swg.im.iis.productization.iisinfsv.overview.doc/topics/cisodsoverview.html https://en.wikipedia.org/wiki/IBM_InfoSphere_DataStage [Pentaho] Pentaho Data Integration (Kettle ETL) http://www.pentaho.com/product/data-integration#data-integration- https://www.adictosaltrabajo.com/tutoriales/kettle/ https://es.wikipedia.org/wiki/Pentaho [SAS] SAS ETL Studio https://support.sas.com/documentation/onlinedoc/etls/ [OWB] Oracle Warehouse Builder https://docs.oracle.com/cd/B28359_01/owb.111/b31278/concept_overview.htm#BABJGDAF https://en.wikipedia.org/wiki/Oracle_Warehouse_Builder
67/69
[PowerCenter] Informatica PowerCenter https://www.informatica.com/#fbid=jNgY_-PEFHO https://www.etltools.net/informatica.html https://en.wikipedia.org/wiki/Informatica [Cognos] Cognos Decisionstream https://www.ibm.com/us-en/marketplace/process-automation https://es.wikipedia.org/wiki/Cognos [Ab] Ab Initio https://www.etltools.net/ab-initio.html https://en.wikipedia.org/wiki/Ab_Initio_Software [BODI] BusinessObjects Data Integrator (BODI) https://www.etltools.net/businessobjects-data-integrator.html https://en.wikipedia.org/wiki/BusinessObjects_Data_Integrator [SSIS] Microsoft SQL Server Integration Services (SSIS) https://docs.microsoft.com/en-us/sql/integration-services/sql-server-integration-services https://es.wikipedia.org/wiki/SQL_Server_Integration_Services [PT-Win] Programador de Tareas de Windows https://technet.microsoft.com/es-es/library/cc766428(v=ws.11).aspx [Cron] Manual básico de CRON - Linux https://www.linuxtotal.com.mx/?cont=info_admon_006
68/69
