Diseño, Desarrollo y Pruebas de la Nueva Versión del Sistema Informático de Administración de Proyectos en TULEAP de la Universidad Distrital Francisco José de Caldas

Texto completo

(1)DISEÑO, DESARROLLO Y PRUEBAS DE LA NUEVA VERSIÓN DEL SISTEMA INFORMÁTICO DE ADMINISTRACIÓN DE PROYECTOS EN TULEAP DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS.. AUTOR: ANDRÉS FELIPE ESPINOSA MARTÍNEZ. PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS. DIRECTOR INTERNO: MEng. ALEJANDRO PAOLO DAZA CORREDOR. DIRECTOR EXTERNO: Ing. JHON GABRIEL CASTELLANOS JIMÉNEZ. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS Bogotá D.C, 2018.

(2) Contenido CAPÍTULO 1. INTRODUCCIÓN ................................................................................................. 1 CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA .................................................................... 2 CAPÍTULO 3. OBJETIVOS ......................................................................................................... 3 3.1. Objetivo general .......................................................................................................... 3 3.2. Objetivos específicos ................................................................................................... 3 CAPÍTULO 4. JUSTIFICACIÓN ................................................................................................... 4 CAPÍTULO 5. MARCO TEÓRICO ............................................................................................... 5 5.1. Proceso de Desarrollo Scrum/OAS .............................................................................. 5 5.2. Tuleap .......................................................................................................................... 6 5.2.1 Trackers ................................................................................................................. 6 5.2.2 Tuleap REST API ..................................................................................................... 7 5.3. Sistemas PQR ............................................................................................................... 7 5.4. SpagoBI ........................................................................................................................ 8 5.4.1 KPI .......................................................................................................................... 8 5.4.2 SpagoBi SDK ........................................................................................................... 9 5.5. Talend .......................................................................................................................... 9 5.5.1 Componentes ........................................................................................................ 9 5.6. Birt ............................................................................................................................. 10 5.7 Drupal ......................................................................................................................... 10 5.7.1 Hooks ................................................................................................................... 10 5.8 Bussines Inteligence ................................................................................................... 11 CAPÍTULO 6. ALCANCES Y LIMITACIONES ............................................................................. 12 6.1. Alcances ..................................................................................................................... 12 6.2. Limitaciones ............................................................................................................... 12 CAPÍTULO 7. METODOLOGÍA ................................................................................................ 13 7.1 Sprints ......................................................................................................................... 13 7.2 Epics ............................................................................................................................ 14 7.3 Historias de usuario .................................................................................................... 14 7.4 Kanban Task ................................................................................................................ 15.

(3) 7.5 Reuniones mensuales ................................................................................................. 15 CAPÍTULO 8. RECURSOS ........................................................................................................ 16 CAPÍTULO 9. PRESUPUESTO ................................................................................................. 17 CAPÍTULO 10. CRONOGRAMA .............................................................................................. 18 CAPÍTULO 11. FLUJO DE DATOS ........................................................................................... 19 CAPÍTULO 12. ARQUITECTURA ............................................................................................. 20 12.1 Obtención de datos .................................................................................................. 21 12.2 Proceso ETL ............................................................................................................... 23 12.2.3 Fase 1 del proceso ETL....................................................................................... 24 12.2.4 Fase 2 del proceso ETL....................................................................................... 28 12.3 Generación de reportes ............................................................................................ 33 12.3.1 Definición de fuente de datos y set de datos .................................................... 33 12.3.2 Definición del umbral ........................................................................................ 34 12.3.3 Definición del KPI ............................................................................................... 35 12.3.4 Definición del Modelo ....................................................................................... 35 12.3.5 Instancia del Modelo ......................................................................................... 36 12.3.6 Creación del documento ................................................................................... 38 12.4 Despliegue de reportes ............................................................................................ 38 CAPÍTULO 13. MODELO DE DATOS ....................................................................................... 41 CAPÍTULO 14. CONCLUSIONES ............................................................................................. 43 CAPÍTULO 15. TRABAJOS FUTUROS ...................................................................................... 44 CAPÍTULO 16. BIBLIOGRAFÍA ................................................................................................ 45. Índice de ilustraciones Ilustración 1 Vista general de un proyecto SCRUM. ............................................................... 5 Ilustración 2 Muestra de sprints del proyecto en tuleap ...................................................... 13 Ilustración 3 Muestra de Epics .............................................................................................. 14 Ilustración 4 Muestra de historias de usuario ...................................................................... 14 Ilustración 5 Muestra de Kanban Tasks ................................................................................ 15.

(4) Ilustración 6 Cronograma del proyecto ................................................................................ 18 Ilustración 7 Diagrama de flujo de datos de la integración ................................................. 19 Ilustración 8 Herramientas utilizadas en componentes de la arquitectura ......................... 20 Ilustración 9 Arquitectura de la integración ......................................................................... 21 Ilustración 10 Formulario de ingreso del Artifact ................................................................. 22 Ilustración 11 Muestra de Artifacts en un Tracker de Tuleap .............................................. 23 Ilustración 12 Proceso ETL. ................................................................................................... 24 Ilustración 13 Fase 1 ETL....................................................................................................... 24 Ilustración 14 Muestra de la respuesta XML fase 1 ETL ....................................................... 25 Ilustración 15 Icono tRESTClient, .......................................................................................... 26 Ilustración 16 Ícono tXMLMap.............................................................................................. 26 Ilustración 17 Ícono tPostgresqlOutput ................................................................................ 27 Ilustración 18 Resultante del proceso ETL fase 1.................................................................. 27 Ilustración 19 Fase 2 ETL....................................................................................................... 28 Ilustración 20 Ícono tPostgresqlInput ................................................................................... 28 Ilustración 21 Ícono tFlowToIterate ...................................................................................... 29 Ilustración 22 Ícono tRest ..................................................................................................... 30 Ilustración 23 Muestra de la respuesta XML fase 2 ETL ....................................................... 30 Ilustración 24 Ícono tConvetType ......................................................................................... 31 Ilustración 25 Ícono tExtractXMLField .................................................................................. 31 Ilustración 26 Ícono tMap ..................................................................................................... 31 Ilustración 27 Muestra de registros obtenidos del ETL ........................................................ 32 Ilustración 28 data set de la fase de diseño ......................................................................... 34 Ilustración 29 Definición del Umbral .................................................................................... 34 Ilustración 30 definición del KPI de modelo de datos. .......................................................... 35 Ilustración 31 Definición del modelo .................................................................................... 36 Ilustración 32 Instancia del modelo ...................................................................................... 37 Ilustración 33 KPIs del proyecto ............................................................................................ 38 Ilustración 34 Configuración de reportes ............................................................................. 39 Ilustración 35 Despliegue de reportes .................................................................................. 40 Ilustración 36 Tabla fase 1 .................................................................................................... 41 Ilustración 37 Tabla del proceso ETL .................................................................................... 42.

(5) Índice de tablas Tabla 1 Recursos del proyecto. ............................................................................................. 16 Tabla 2 Presupuesto del Proyecto. ....................................................................................... 17 Tabla 3 Descripción de la tabla fase 1 .................................................................................. 41 Tabla 4 Descripción de la tabla ETL ...................................................................................... 42.

(6) CAPÍTULO 1. INTRODUCCIÓN. Los sistemas PQR (Peticiones, quejas y reclamos) son necesarios ya que retroalimentan el sistema proporcionando información valiosa con la cual se puede mejorar un producto o servicio. El objetivo principal de un sistema PQR es mejorar un proceso, producto o servicio atendiendo todas las dudas, peticiones, preguntas y demás inquietudes o preocupaciones que se presenten por parte del usuario. La Oficina Asesora de Sistemas desea optimizar el desarrollo de proyectos propuestos implementando una integración para crear una nueva versión del sistema PQR. El fin de implementar dicho sistema es atender rápidamente los eventos que surjan de parte de las personas involucradas en el proyecto. Además, se desea tener una representación gráfica del progreso de cada proyecto. La implementación del sistema se llevará a cabo en la plataforma Tuleap, ya que es la plataforma actual de administración de proyectos en la Oficina Asesora de Sistemas, en conjunto con otras herramientas tecnológicas para realizar procesos de inteligencia de negocios. Con el fin de optimizar el sistema PQR que posee actualmente Tuleap, la Oficina Asesora de Sistemas decide crear una nueva solución de software mediante el proyecto llamado “Diseño, desarrollo y pruebas de la nueva versión del sistema informático de administración de proyectos en Tuleap de la Universidad Distrital Francisco José De Caldas”. Este proyecto tiene como objetivo Integrar nuevas funcionalidades al sistema de administración de proyectos en Tuleap aplicando inteligencia de negocios para mejorar el sistema PQR de la Oficina Asesora de Sistemas ya que actualmente el sistema no posee todas las características que se desean y este objetivo se trata de alcanzar utilizando la integración de varias herramientas tecnológicas como CMS, software analítico y software de soporte. En este documento se explicarán los conceptos y desarrollo de la integración mencionada. Primero se explicarán los conceptos concernientes a la metodología de desarrollo y las herramientas tecnológicas utilizadas. Luego se explicarán los conceptos y los pasos llevados a cabo en el desarrollo de la integración. Por último se hablará del desarrollo de proyectos futuros basados en este proyecto.. 1.

(7) CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA Al desarrollar un proyecto en la Oficina Asesora de Sistemas, como en cualquier otra empresa que desarrolle proyectos relacionados a los sistemas de información, surgirán dudas o inconvenientes y estos tienen que ser solucionados de la mejor manera lo más pronto posible. Para realizar el seguimiento de un proyecto de desarrollo existen diferentes metodologías de desarrollo por las cuales dirigir un proyecto de este tipo, además se han diseñado diferentes softwares con licencia privada y libre que facilitan el correcto seguimiento e implementación de estas metodologías. En la oficina Asesora de Sistemas se seleccionó un sistema de administración de proyectos llamado Tuleap, el cual cuenta con ciertas herramientas que proveen información detallada acerca del progreso de las tareas realizadas y por realizar, pero no se puede visualizar el progreso total del proyecto fácilmente, a no ser que se realice un conteo manual de tareas realizadas sobre el total de tareas asignadas en cada fase del proyecto. Por otra parte, los formularios que actualmente se manejan en Tuleap no están configurados para ceñirse totalmente al modelo de la metodología de desarrollo en la que trabaja la Oficina Asesora de Sistemas. Tuleap cuenta con varias herramientas que permiten gestionar proyectos, pero no cuenta realmente con las herramientas necesarias para permitir monitorear un proceso de PQR automatizado. Los trackers de Tuleap tan solo muestran un registro de datos sin análisis alguno. En los Agile Dashboards se puede ver en tableros las tareas que hay en diferentes etapas, pero si se requiere hacer un análisis de inteligencia de negocios con estos datos se torna un proceso engorroso que conllevaría demasiado tiempo, mucho más de lo deseado. Los problemas anteriormente mencionados ralentizan el proceso de desarrollo de un proyecto en sus diferentes fases. La toma de decisiones en cuanto al proyecto se ve afectada puesto que la vista general del estado del proyecto no se visualiza con las herramientas que proporciona Tuleap, así mismo el estado de cada fase no es visible. Al no tener una visualización rápida del progreso de un proyecto y sus no se pueden tomar decisiones de la manera más rápida posible. Para mejorar el manejo del sistema de administración de proyectos se pretende realizar la integración de herramientas CMS, software de administración de proyectos, software para ETL y software de inteligencia de negocios. La integración de estas herramientas pretende agilizar el proceso de respuesta del sistema PQR, además de ver gráficamente el progreso de los proyectos y facilitar la lectura de los datos que se vayan obteniendo al avanzar en los diferentes proyectos que se realicen. 2.

(8) CAPÍTULO 3. OBJETIVOS 3.1. Objetivo general Integrar nuevas funcionalidades al sistema de administración de proyectos en Tuleap aplicando inteligencia de negocios para mejorar el sistema PQR de la Oficina Asesora de Sistemas.. 3.2. Objetivos específicos ● Desarrollar formularios amigables en el sistema PQR para obtener información que permita ser analizada en el proceso de inteligencia de negocios. ● Desplegar visualmente las estadísticas generadas del análisis de la información recibida en el sistema PQR dirigido a mejorar y facilitar el entendimiento de dichas estadísticas. ● Efectuar procesos de inteligencia de negocios con la información registrada en el gestor de requerimientos TULEAP con el fin de dar respuesta eficientemente a las peticiones, quejas y reclamos. ● Realizar el proceso ETL con objeto de analizar, transformar, extraer y cargar la información proveniente de las diferentes fuentes manejadas en la oficina asesora de sistemas.. 3.

(9) CAPÍTULO 4. JUSTIFICACIÓN. La implementación de un sistema de administración de proyectos y un sistema de PQR pretende mejorar y facilitar la administración de los proyectos, del mismo modo todos los procesos relacionados al tratamiento de peticiones, quejas y reclamos. Al desarrollar un sistema PQR como módulo de un sistema de información se evita que se pierda información en el proceso, ya que no se cuenta con el factor humano al momento de recibir la información y se evitan errores (tal como la mala comunicación al momento de un reclamo por el estado de ánimo del reclamante o del personal de centro de servicios) los cuales podrían hacer perder la información o no garantizar la calidad de la misma. También se agiliza el proceso de recolección de información gracias a la alta disponibilidad que adquiere al no tener que esperar a que un empleado reciba dicha información. Igualmente se mejora el proceso de toma de decisiones en los diferentes aspectos que involucra el desarrollo de los proyectos dado que se tiene información detallada más rápidamente y con una comprensión más alta debido a su sencilla visualización. Teniendo en cuenta los aspectos anteriormente mencionados, la Oficina Asesora de Sistemas decidió poner en marcha el desarrollo de un módulo de software orientado en cumplir las especificaciones faltantes en el sistema de administración de proyectos con el que se cuenta actualmente. Para mejorar la toma de decisiones administrativas, además manejar eficientemente las peticiones, quejas y reclamos que se presenten dentro del desarrollo de un proyecto en la Oficina Asesora de Sistemas, es necesario implementar una nueva versión del sistema informático de administración de proyectos. La implementación de esta nueva versión del sistema mejorará el tiempo en desarrollo de los proyectos que se propongan, ya que se manejará un sistema más claro y conciso en las dudas e inconvenientes que se presenten dentro de los proyectos. También se identificará más fácilmente las falencias dentro del proyecto propuesto y se podrá ver el estado total y de cada fase dentro del proyecto, logrando así detectar si se necesita más personal dentro de una fase debido a su retraso o si por el contrario las fases están eficientemente planeadas.. 4.

(10) CAPÍTULO 5. MARCO TEÓRICO 5.1. Proceso de Desarrollo Scrum/OAS La metodología de desarrollo utilizada en la oficina asesora de sistemas es el proceso de desarrollo SCRUM/OAS [1]. Esta metodología se compone de elementos formales que determinan la manera en la que se realiza el proceso de desarrollo del producto de software requerido. Dichos elementos formales se denominan roles y elementos de Scrum.. Ilustración 1 Vista general de un proyecto SCRUM. Recuperado de: https:// tuleap.udistrital.edu.co. Los roles definidos en la metodología SCRUM son aquellos necesarios para poder producir el producto de software especificado. Los roles funcionales en SCRUM son: el Product Owner, el equipo de desarrollo y el Scrum Master. El Product Owner es la persona responsable del éxito del proyecto desde el punto de vista de los stakeholders. El equipo de de desarrollo está conformado por todos los individuos necesarios para el desarrollo del producto de software. El Scrum Master es quien lidera el proyecto y quien es responsable de lograr que la metodología se lleve a cabo de forma correcta.. 5.

(11) Los elementos de SCRUM están definidos para organizar las fases del proyecto y garantizar el desarrollo ágil de este..El principal elemento de SCRUM es el Product Backlog que es básicamente un listado de características priorizadas por el Product Owner. Al tener un enfoque ágil, SCRUM se constituye por fases llamadas Sprints, cada una con duración de 1 o 2 semanas, en las cuales el producto de software se construye incrementalmente, es decir, agregando o modificando funcionalidades del producto para obtener feedback. Al principio de cada Sprint se lleva a cabo la reunión de planificación, en donde se generarán los acuerdos entre el equipo de desarrollo y el Product Owner sobre el alcance del Sprint. Cada Sprint está constituido por reuniones diarias llamadas Daily Scrums, en la cual los miembros del equipo de desarrollo responden las siguientes preguntas: ¿Qué hice desde la última reunión diaria hasta ahora?, ¿En qué voy a estar trabajando desde ahora hasta la próxima reunión diaria? y ¿Qué problemas o impedimentos tengo?, esto con el fin de 1) incrementar la comunicación 2) explicitar los compromisos y 3) dar visibilidad a los impedimentos. Por último, al terminar cada Sprint se lleva a cabo una reunión de revisión, llamada Sprint Review, en donde se evalúan los potencialmente entregables construido por el equipo de desarrollo.. 5.2. Tuleap Tuleap [2] es un sistema gestor de proyectos por medio del cual se puede administrar los ciclos de vida de proyectos de software. Tuleap es la herramienta escogida por la Oficina Asesora de Sistemas para llevar el registro y realizar seguimiento a los proyectos que se están trabajando, utilizando la metodología SCRUM/OAS. En este software es posible llevar un control sobre el proyecto desde el punto de vista de la metodología SCRUM, llevando un registro de Sprints, Epics, historias de usuario, Backlog y demás elementos existentes en esta metodología.. 5.2.1 Trackers. Los Trackers de Tuleap tienen como objetivo realizar el seguimiento a los diferentes Artifacts presentes en un proyecto. Los artifacts son los ítems a los que se les está realizando un seguimiento a través de un tracker, es decir que pueden ser cualquiera entre bugs, tareas, peticiones de soporte, historias de usuario, etc. El seguimiento se 6.

(12) realiza por medio del envío de un nuevo artifact en el tracker que se seleccione. En un proyecto pueden existir varios trackers con diferentes objetivos, lo cual es definido por el administrador del sitio.. 5.2.2 Tuleap REST API. Tuleap cuenta con un REST API. El acceso a este puede hacerse anónimamente o realizar autenticación de credenciales. La respuesta del REST API de tuleap puede ser a través de JSON o de XML. Las consultas que permite son GET, POST, PUT, PATCH y DELETE. En este proyecto se trabaja con información privada de los proyectos dentro de Tuleap, por consiguiente es necesario realizar la autenticación para obtener los datos necesarios. La autenticación se realiza a través de la respectiva cabecera HTTP. Las credenciales se obtienen por medio del usuario y contraseña que se otorga desde la página de administración de Tuleap. Las consultas se hacen a través de rutas definidas en el REST API. A través de estas consultas se puede obtener información de diferentes elementos de Tuleap. Tuleap provee un explorador del API, con el cual podemos ver la respuesta respectiva de cada URL. Además se pueden realizar pruebas en línea sin tener que utilizar comandos CURL. Por medio de esta REST API se realizó la consulta de la información de los diferentes elementos en los proyectos y así alimentar la entrada de datos en el proceso ETL.. 5.3. Sistemas PQR Los sistemas PQR (Peticiones, quejas y reclamos) son necesarios en los sistemas de información, también son necesarios en otros tipos de sistemas, ya que retroalimenta el sistema proporcionando información valiosa con la cual se puede mejorar un producto o servicio. El objetivo principal de un sistema PQR es mejorar mejorar un proceso, producto o servicio atendiendo todas las dudas, peticiones, preguntas y demás inquietudes o preocupaciones que se presenten por parte del usuario. El desarrollo de un buen sistema PQR está especificado en la norma ISO 10002 [3], la cual orienta al diseño e implementación de un tratamiento de quejas para que este sea eficaz en actividades comerciales y no comerciales. Con la información que se obtiene del sistema PQR se. 7.

(13) deben adoptar estrategias, políticas o técnicas para mejorar el proceso involucrado a dicha información, contribuyendo así al mejoramiento de dicho producto o servicio. Un sistema automatizado de PQR debe mostrar todas las incidencias que se presentan, en este caso en algún proyecto, para dar respuesta oportunamente. Los módulos que integren un sistema PQR deben estar enfocados a mostrar los problemas que surjan categorizados para así saber en dónde se están presentando las fallas. La idea de un sistema automatizado de PQR es trabajar más rápidamente en la toma de decisiones dado que el proceso de recolección, categorización y despliegue de datos se hace de manera automática.. 5.4. SpagoBI Es un software libre de inteligencia de negocios, perteneciente a la iniciativa de código abierto SpagoWorld, el cual ofrece una alta variación de funciones analíticas clásicas de una suite de inteligencia de negocios convencionales, además de funciones propias que agregan funcionalidades de análisis de datos de manera dinámica y herramientas de visualización de datos. Las características de este software libre [4] abarcan diferentes herramientas de inteligencia de negocios que permiten analizar información, tales como: análisis multidimensional, KPIs, reportes ad-hoc, localización inteligente, minería de datos, ETL, entre otras. 5.4.1 KPI. KPI se refiere a Key perfomance indicator. Los KPIs son un conjunto de métricas que permiten visualizar gráficamente información, generalmente bastante relevante, de un negocio. Son usados para analizar rendimientos que son resaltados de un conjunto de información seleccionada. La creación de un modelo KPI en SpagoBI cuenta con tres fases. Primero, se define el modelo KPI para crear un documento analítico de este. Segundo, se crea la definición de la lógica por la cual el KPI será regido. Por último, se muestran los valores obtenidos por medio de reportes e interfaces de visualización. 8.

(14) 5.4.2 SpagoBi SDK. El SDK de SpagoBI contiene un API de JavaScript con la cual se pueden integrar ciertas partes de la suite de SpagoBI dentro de una página web, además también para obtener información acerca de conjuntos de datos y documentos existentes en SpagoBI. La política del mismo origen es una medida de seguridad para scripts que se encuentran en las páginas web no permite que dicha página obtenga datos de otra URL si no poseen el mismo origen. El origen es diferente cuando el esquema de la URI, el nombre del host o el puerto son diferentes. Esto significa que el SDK de SpagoBI no puede ser usado en una página web que no esté en los servidores de SpagoBI. Para solucionar el problema que surge de la política del mismo origen SpagoBI propone dos soluciones. La primera y más sencilla es utilizar un IFrame en la página que desea integrar a SpagoBI dado que así no afectaría esta política. La segunda es utilizar los servicios REST de SpagoBI, pero esto conlleva incompatibilidad con algunos navegadores (Internet Explorer anteriores a la versión 7) y problemas de seguridad con otros (versiones posteriores a Internet Explorer 7).. 5.5. Talend Es una herramienta de software libre para realizar procesos ETL (Extract, transform and load). TALEND [5] es un sistema de integración de datos que tiene como objetivo facilitar la migración de datos y para ello implementa más de 900 componentes con los que se puede crear un puente para conectar entre bases de datos, archivos del sistema, servicios web, mainframes, bodegas de datos, aplicaciones OLAP, aplicaciones en la nube, y más.. 5.5.1 Componentes. Los trabajos de Talend se caracterizan por estar basados en componentes. El objetivo del trabajo sobre componentes es minimizar lo que más se pueda la manipulación directa del código fuente realizado en Java. Para lograr la simplicidad que se desea, los componentes son representaciones gráficas de bloques de código orientados a manejar diferentes tecnologías. Los componentes manejan diferentes tecnologías, desde servicios web hasta. 9.

(15) manejo de bases de datos. Cada componente trae diversos parámetros que los permite ser ajustados a las necesidades de cada proyecto ETL que se pretenda realizar.. 5.6. Birt Es un proyecto de software libre que provee la plataforma de tecnología BIRT [6] para la creación de visualizaciones de datos, los cuales se pueden agregar a aplicaciones web. BIRT es un proyecto cumbre en la fundación Eclipse. BIRT tiene dos componentes principales, el componente de creación visual de reportes para crear diseños BIRT y el componente en tiempo de ejecución para generar los diseños creados anteriormente los cuales se pueden integrar a cualquier ambiente JAVA. También posee un motor gráfico que puede ser usado mediante su integración en el diseñador propio de BIRT o por cuenta propia en una aplicación desarrollada por el usuario. Las gráficas de los KPIs de SpagoBI son trabajadas desde Birt.. 5.7 Drupal Drupal [7] es un software libre para el manejo de contenido. Es utilizado para hacer sitios web y aplicaciones web. Es útil para integrarse con otros proyectos o frameworks. Esta herramienta posibilita la creación de páginas web versátiles, dinámicas y estructuradas. 5.7.1 Hooks. EL sistema de módulos en Drupal está basado en el concepto de Hooks. Un Hook, es un fragmento de código PHP, específicamente una función que se rige bajo la nomenclatura foo_bar() en donde foo es el nombre del módulo y bar es el nombre del Hook. En cada hook se precisan cierta cantidad de parámetros definidos los cuales son variables según el hook que se vaya a implementar. Cada Hook tiene un resultado diferente. La extensibilidad de Drupal se logra a través de la implementación de los Hooks, ya que estos son leídos por el núcleo de Drupal cuando son definidos correctamente al crear un nuevo módulo.. 10.

(16) Existen dos tipos de Hooks en drupal. . . Alter Hooks: Se utilizan comúnmente para editar el contenido de un objeto o variable en Drupal, mediante la obtención de las referencias de las variables en el Hook. Intercepting Hooks: Se utilizan para permitir que los módulos externos lleven a cabo acciones durante la ejecución de este.. 5.8 Bussines Inteligence La inteligencia de negocios [8] (BI por sus siglas en inglés) hace referencia al conjunto de técnicas y estrategias que abarcan diferentes tecnologías, aplicaciones, productos y arquitecturas para crear y administrar conocimiento acerca de un medio, a través del análisis de los datos de una organización con el fin de facilitar la toma de decisiones. EL objetivo de la inteligencia de negocios es extraer información de un negocio para obtener conocimiento útil que de partida a una toma de decisiones más eficiente. Fundamentado en los conocimientos adquiridos por un sistema de inteligencia de negocios, se pretende mejorar económicamente el proceso de producción del negocio mediante la mejor redistribución de recursos y talento humano. También se pretende mejorar el tiempo de producción basado en el conocimiento que genere el sistema de inteligencia de negocios. En este proyecto se referencia la inteligencia de negocios debido a la integración de diferentes componentes y el posterior uso de la información obtenida en la parte gerencial de los proyectos que se lleven a cabo. Para obtener datos relevantes se utiliza Tuleap como sistema de administración de proyectos. Con el objetivo de realizar los procesos ETL se utiliza Talend. Para creación gráfica de reportes se utiliza SpagoBI. Por último se despliegan los reportes por medio de Drupal. El anterior conjunto de herramientas tecnológicas y su posterior análisis por parte de las personas encargadas de los proyectos facilita el proceso de toma de decisiones frente a los proyectos que se llevan a cabo en la Oficina Asesora de Sistemas.. 11.

(17) CAPÍTULO 6. ALCANCES Y LIMITACIONES 6.1. Alcances    . . El proyecto lleva a cabo las fases de inicio, elaboración y construcción de la metodología ágil de desarrollo SCRUM/OAS. El proyecto estará estructurado en 16 iteraciones Cada iteración corresponde a una semana El equipo de trabajo se organizará por los roles definidos en el proceso de desarrollo SCRUM/OAS. El rol que se asumirán en la pasantía corresponde a desarrollador. Realizar y documentar los componentes de software de acuerdo a la arquitectura y diseño pertinentemente establecida en el proyecto, siguiendo los lineamientos del proceso de desarrollo SCRUM/OAS.. 6.2. Limitaciones    . La solución de software estará basada en los lineamientos del software libre dando respuesta a políticas distritales e institucionales. Los recursos de desarrollo del software, tiempo y dinero se limitan a los proveídos por el desarrollador. La solución de software estará basada en herramientas de software libre tales como Drupal, SpagoBI, Talend, Birt y TULEAP. El tiempo de desarrollo de la pasantía está definido a 640 horas.. 12.

(18) CAPÍTULO 7. METODOLOGÍA La metodología que se aplicó en este proyecto se encuentra bajo el proceso de desarrollo SCRUM/OAS. Se siguieron los lineamientos de la metodología SCRUM adoptada por la oficina asesora de sistemas. A continuación, se especificarán las tareas que se llevaron a cabo bajo el rol de desarrollador.. 7.1 Sprints Desde el inicio del proyecto se llevan reuniones periódicas, llamadas Sprints, en las cuales se asignan tareas al desarrollador, siendo este uno de los elementos más importantes de SCRUM. En los Sprints semanales se verán y discutirán los avances del proyecto según el Product Backlog definido por el Product Owner. Los Daily Scrums se llevarán a cabo dentro del Sprint correspondiente para resolver los inconvenientes o dudas que surjan en cuanto al desarrollo de software. En cada Sprint se le asignan tareas al desarrollador siguiendo los requerimientos definidos por el Product Backlog y también se revisa el progreso de las tareas asignadas en el Sprint anterior. Toda esta información que se obtiene de los Sprints semanales se registra en la herramienta TULEAP, ya que esta herramienta de seguimiento fue la escogida por la Oficina Asesora de Sistemas. En todas las reuniones semanales estará presente el Scrum Master siendo él quien observa y dirige el buen desempeño y seguimiento de la metodología además de resolver los inconvenientes que surjan en el desarrollo de esta. En la ilustración 2 se da una muestra de los sprints llevados a cabo en la realización del proyecto.. Ilustración 2 Espinosa, Andrés (2018) Muestra de sprints del proyecto en tuleap. 13.

(19) 7.2 Epics Para la asignación de tareas se deben generar epics. Las Epics están compuestas de historias de usuario las cuales están asociadas a una actividad de desarrollo particular que tiene duración desconocida. La duración de una actividad de desarrollo particular es determinada por las historias de usuario que componen a dicha actividad, ya que dichas historias son pequeñas partes las cuales tienen una duración determinada. En la ilustración 3 se da una muestra de los epics desarrollados en el proyecto.. Ilustración 3 Espinosa, Andrés (2018) Muestra de Epics. 7.3 Historias de usuario Las historias de Usuario son la representación de lo que el equipo de desarrollo debe construir en un tiempo determinado. A través de los Sprints se asignan historias de usuario a los Epics. Las historias de usuario se dividen en tareas para los desarrolladores que constituyen el equipo de desarrollo y se debe comentar diariamente, por medio de la herramienta TULEAP, las tareas para que el Scrum Master lleve un seguimiento de cada una de ellas. En la ilustración 4 seda una muestra de las historias de usuario realizadas en el proyecto.. Ilustración 4 Espinosa, Andrés (2018) Muestra de historias de usuario. 14.

(20) 7.4 Kanban Task El elemento Kanban Task permite realizar actividades referentes al proyecto que no hayan sido asignadas como tareas. Cada vez que se desarrolle una actividad pertinente al proyecto, pero no asignada como tarea, se debe generar un Kanban Task con objeto de validar la realización de dicha tarea. Los Kanban Task sirven como soporte de reuniones con integrantes del mismo u otro proyecto para tratar temas relacionados con las tareas asignadas, reuniones con Stakeholders para definir parámetros de tareas asignadas y solicitudes de herramientas, scripts o cambios del proyecto del desarrollador o externos. En la ilustración 5 se da una muestra de los Kanban Tasks que se llevarón a cabo en el proyecto.. Ilustración 5 Espinosa, Andrés (2018) Muestra de Kanban Tasks. 7.5 Reuniones mensuales Una vez al mes se lleva a cabo la socialización de avances en el proyecto a la cual acuden todos los equipos de trabajo de cada proyecto de la OAS. En las reuniones se lleva a cabo la socialización de avances, inconvenientes y soluciones que se hayan presentado en los proyectos que se desarrollen en la OAS. Estas reuniones sirven para resolver problemas que hayan surgido en algún proyecto, ya que muchas veces se encuentran los mismos problemas en diferentes proyectos.. 15.

(21) CAPÍTULO 8. RECURSOS En la tabla 1, se observan los recursos que fueron necesarios para el desarrollo de software mediante el rol de desarrollador.. Tipo de recurso. Recurso. Cantidad. Humano. Desarrollador. 1. Infraestructura. Computador. 1. Infraestructura. Control de versiones, entorno de desarrollo y avance del proyecto en TULEAP. 1. Infraestructura. Almacenamiento disponible en Google Drive para guardar documentación. 1 Gigabytes. Tiempo. Meses. 3. Tabla 1 Recursos del proyecto.. 16.

(22) CAPÍTULO 9. PRESUPUESTO En la tabla 2 se especifica el presupuesto requerido para el desarrollo del proyecto. Tipo de. Recurso. Cantidad. Dedicación. Tiempo. Recurso. Valor mensual. Valor total. unitario. Humano. Desarrollador. 1. Total. 3 meses. $ 2’000.000. $ 6’000.000. Humano. DBA. 1. Parcial. 3 meses. $ 1’000.000. $ 3’000.000. Humano. Scrum Master. 1. Parcial. 3 meses. $ 1’480.000. $ 4’440.000. Humano. Líder de proyecto. 1. Parcial. 3 meses. $ 1’550.000. $ 4’650.000. Humano. Líder de desarrollo. 1. Parcial. 3 meses. $ 1’445.000. $ 4’335.000. Infraestructura. Servicio de internet. 1. Total. 3 meses. $ 100.000. $ 300.000. Infraestructura. Alquiler de computadores. 1. Total. 3 meses. $ 250.000. $ 750.000. Infraestructura. Servicio de luz. 1. Total. 3 meses. $ 40.000. $ 120.000. Transporte. Transporte. 1. Total. 3 meses. $ 80.000. $ 240.000. Varios. Imprevistos. 1. Total. 3 meses. $ 1’402.059. $ 4’206.177. Total. $ 28’041.177. Tabla 2 Presupuesto del Proyecto.. 17.

(23) CAPÍTULO 10. CRONOGRAMA El proyecto se planeó para que se desarrolle en 16 Sprints, cada Sprint dura 1 semana, la duración del proyecto fue de cuatro meses. En la ilustración 2 se muestra el cronograma del proyecto dividido en las diferentes fases de la metodología SCRUM/OAS. La fecha de inicio del proyecto dependió de la aprobación del anteproyecto y la firma de contrato de pasantías.. Actividades / Sprints. 1. 2. 3. 4. 5. 6. 7. 8. 9 10 11 12 13. 14 15 16. Fase de inicio Análisis del problema Elaboración del documento del anteproyecto Fase de planeación y estimación Definición del Product Backlog Selección de herramientas tecnológicas Fase de implementación Capacitación de Tuleap Desarrollo de Formularios PQR Capacitación de Talend Desarrollo del ETL Capacitación de Drupal Desarrollo del módulo SpagoField Capacitación de SpagoBI Desarrollo de KPI Fase de revisión y feedback Revisión de los módulos de la integración Corrección de errores Fase de lanzamiento Puesta en marcha de proyecto Elaboración del documento del proyecto de grado. Ilustración 6 Espinosa, Andrés (2018) Cronograma del proyecto. 18.

(24) CAPÍTULO 11. FLUJO DE DATOS. Para comprender el funcionamiento de la nueva versión de PQR necesaria en la Oficina Asesora de sistemas se debe entender que dicha nueva versión comprende un conjunto de herramientas tecnológicas integradas para obtener información relevante en los proyectos que son llevados a cabo en esta extensión de la Universidad Distrital Francisco José de Caldas. Con el propósito de obtener información relevante se utilizó software de administración de proyectos, ETL, CMS y BI siendo estos Tuleap, Talend, Drupal y SpagoBI respectivamente. La información que es recolectada hace referencia a retroalimentación de los proyectos en desarrollo en la oficina asesora de sistemas, siendo provista por las personas involucradas en cada uno de los proyectos. El flujo de los datos obtenidos es representado en la ilustración 7.. Ilustración 7 Espinosa, Andrés (2018) Diagrama de flujo de datos de la integración. La integración de las tecnologías mencionadas anteriormente nos permite, en conjunto, realizar el proceso de inteligencia de negocios que se deseaba en la oficina asesora de sistemas. Por medio de Tuleap, se obtendrá la información de PQR que las personas involucradas en los diferentes proyectos suministren por medio de esta plataforma. Para tratar la información se utilizó Talend además de comunicar el api de Tuleap con el servidor de inteligencia institucional de la universidad, el cual posee el software SpagoBI, con el fin de crear reportes gráficos de la información. Finalmente, los reportes creados a partir de la información suministrada se mostrarán en la página de la oficina asesora de sistemas por medio de Drupal.. 19.

(25) CAPÍTULO 12. ARQUITECTURA La arquitectura adoptada por la Oficina Asesora de Sistemas es orientada a servicios, SOA (Service Oriented Architecture). Se trabajó bajo esta arquitectura, utilizando las herramientas mencionadas anteriormente y las cuales pueden verse en la ilustración 8 que representa la arquitectura orientada a servicios de la Oficina Asesora de Sistemas.. Ilustración 8 Oficina Asesora de Sistemas, Herramientas utilizadas en componentes de la arquitectura, recuperado de: https://tuleap.udistrital.edu.co. Las herramientas utilizadas corresponden a los componentes Servicios de datos, Servicios Analíticos y servicios de soporte además de utilizar el CMS Talend para desplegar los 20.

(26) reportes en la página web de la Oficina Asesora de Sistemas. En la ilustración 9, se modela la arquitectura de la integración, mostrando la relación entre cada uno de sus componentes. Seguido a esto se tratará cada uno de los componentes.. Ilustración 9 Espinosa, Andrés (2018) Arquitectura de la integración. 12.1 Obtención de datos Para obtener la información relevante de los proyectos se utilizó la herramienta Tuleap, la cual está siendo usada por la Oficina Asesora de Sistemas para servicios de soporte tal como la administración de proyectos. En Tuleap, existen diferentes elementos para realizar seguimiento a los proyectos que se tengan inscritos en la plataforma tales como Trackers, Agile Dashboards, Artifacts, etc. Para el PQR se utilizaron Trackers ya que estos permiten, mediante un formulario, ingresar información concerniente a cada proyecto. La información que se suministra corresponde a título de la tarea, fase, tipo, estado, detalles y archivos adjuntos, si es necesario. Cada registro de información suministrada es catalogado como un Artifact, esto se muestra en la ilustración 10.. 21.

(27) Ilustración 10 Espinosa, Andrés (2018) Formulario de ingreso del Artifact. Los formularios para el registro de la información se configuraron en un Tracker y este almacena cada registro como un Artifact. La información requerida se ingresa por diferentes campos en un formulario simple en el cual se asocia el Artifact a una tarea y a un usuario, quien es el que registra la información. Además del usuario y la tarea, información como el ID del Artifact, el tipo de tarea, el estado, la asignación de dicha tarea, los detalles y las fechas de registro y de última actualización del Artifact son almacenadas para ser tratadas posteriormente por el ETL. En la ilustración 11 se muestra un ejemplo de varios Artifacts en un Tracker de Tuleap.. 22.

(28) Ilustración 11 Espinosa, Andrés (2018) Muestra de Artifacts en un Tracker de Tuleap. 12.2 Proceso ETL La comunicación con el api de Tuleap se realiza mediante Talend. Ya que la información que se desea extraer se encuentra por medio de diferentes consultas al REST API de Tuleap, se necesitó realizar un proceso ETL. Primero se realiza una petición HTTPS por medio del api para obtener un documento XML con los IDs de los artifacts que se hayan generado hasta el momento y demás información referente al tracker, el resto de la información es filtrada. Los IDs obtenidos del documento XML son almacenados en la base de datos para luego realizar las iteraciones correspondientes a la cantidad de artifacts que se hayan obtenido. En cada iteración se genera una petición HTTPS con objeto de obtener el resto de datos de cada uno de los artifacts tal como el usuario, el título de la tarea, el tipo de tarea, el estado, la asignación de dicha tarea, los detalles, la fecha de registro y la fecha de última actualización. Al final, toda la información es almacenada en la base de datos, lista para generar los reportes en SpagoBI. En la ilustración 12 se muestra gráficamente el proceso ETL.. 23.

(29) Ilustración 12 Espinosa, Andrés (2018) Proceso ETL.. Debido a la naturaleza de Talend, se trabajó con varios componentes para lograr el proceso ETL deseado. A continuación se explican todos los componentes utilizados en las dos fases del proceso ETL.. 12.2.3 Fase 1 del proceso ETL. El objetivo de esta fase es guardar los IDs de los artefactos del proyecto en una tabla de la base de datos para posteriormente lograr extraer la información concerniente a cada uno de dichos artefactos. En la ilustración 13 se muestra una vista general de la fase 1 del proceso ETL.. Ilustración 13 Espinosa, Andrés (2018) Fase 1 ETL. 24.

(30) 12.2.3.1 tRESTClient. Este componente envía peticiones HTTP o peticiones HTTPS a un servicio web REST, en este caso el REST Api de Tuleap. Los parámetros que son necesarios configurar son la URL, el método HTTP, el tipo de acceso y el tipo de autenticación. La URL se selecciona según la respuesta que se necesite, para este componente se configuro la URL que preveía la información de un tracker específico ya que dentro de la respuesta se encuentran los IDs de los artifacts que se necesitan. El método HTTP seleccionado fue GET, ya que deseábamos obtener información del Api. El tipo de acceso escogido fue XML por simplicidad de manejo. El tipo de autenticación seleccionado fue HTTP Básico, en el cuál se enviaron las credenciales del usuario con permisos para consultar la información necesaria. En la ilustración 14 se muestra la primer respuesta XML para ser filtrada posteriormente.. Ilustración 14 Espinosa, Andrés (2018) Muestra de la respuesta XML fase 1 ETL. 25.

(31) En la ilustración 15 se muestra el ícono del componente tRESTClient.. Ilustración 15 Icono tRESTClient, recuperado de: https://help.talend.com/viewer/attachment/zX6_omT10WjDGqFsENEaLA. 12.2.3.2 tXMLMap. Con este componente se transforman y dirigen los datos provenientes de un documento XML desde una o varias fuentes hacia uno o varios destinos. Dentro de este componente se cuenta con un editor con el cual se filtran y transforman los datos. En el proyecto se necesitó utilizar este componente en dos ocasiones. El primer uso del componente se dio al consultar la primera URL, siendo el objetivo filtrar únicamente los IDs de los artefactos ya que el resto de información obtenida en esta primera petición no arrojaba todos los datos que estaban definidos como objetivo para poder realizar los KPIs. El segundo uso fue en la consulta de los datos faltantes de la anterior petición, pero esta segunda petición requirió el apoyo de otros componentes dado que se necesitaba realizar otros procesos en conjunto para lograr obtener la información. En la ilustración 16 se muestra el ícono del componente tXMLMap.. Ilustración 16 Ícono tXMLMap, recuperado de: https://help.talend.com/reader/ixBASPZJ7IvqUQVupZwWbg/Cu_~QbVV8_151c3BwGJxBg. Como resultado del uso de este componente se obtuvo los IDs asociados al proyecto, filtrando el resto de información innecesaria y realizando su inserción en base de datos con el siguiente componente.. 26.

(32) 12.2.3.3 tPostgresqlOutput. Este componente es usado para realizar comandos SQL de inserción y actualización en las bases de datos Postgresql. El componente realiza la acción especificada siguiendo los parámetros configurados en este. Los parámetros que se deben configurar para el funcionamiento de este componente son versión de base de datos, Host, puerto, nombre de la base de datos, esquema en el cual se encuentra, nombre de usuario y contraseña, nombre de la tabla, acción sobre la tabla y acción sobre los datos. La versión de la base de datos manejada es 9 o posterior, dado que en la Oficina Asesora de sistemas se trabaja con esta versión de sistema gestor de base de datos Postgresql. Los parámetros de host, puerto nombre de la base de datos, esquema, nombre de la tabla, nombre de usuario y contraseña se definen con los correspondientes a la información de la bodega de datos de la Oficina Asesora de Sistemas. La acción sobre la tabla se definió como “crear tabla si no existe” para evitar inconvenientes en la persistencia de los datos. La acción sobre los datos se definió como “insert o update” dado que en cada proceso de ETL se obtienen nuevos IDs de artifacts y se actualiza el estado de los artifacts existentes. En la ilustración 17 se muestra el ícono del componente tPostgresqlOutput.. Ilustración 17 Ícono tPostgresqlOutput, recuperado de: https://help.talend.com/viewer/attachment/5Lixaov~LcCVcgSIHJN0bg. En la ilustración 18 se muestra el resultado del proceso ETL de la fase 1 con los IDs listos para ser tratados por la fase 2.. Ilustración 18 Espinosa, Andrés (2018) Resultante del proceso ETL fase 1. 27.

(33) 12.2.4 Fase 2 del proceso ETL. El objetivo de esta fase es guardar la información concerniente a los artefactos del proyecto en la base de datos como resultado del proceso ETL para posteriormente realizar los KPIs en SpagoBI. En la ilustración 19 se muestra una vista general de la fase 2 del proceso ETL.. Ilustración 19 Espinosa, Andrés (2018) Fase 2 ETL. 12.2.4.1 tPostgresqlInput. Este componente es usado para realizar comandos SQL de consulta en las bases de datos Postgresql. El componente realiza la acción especificada siguiendo los parámetros configurados en este. Los parámetros que se deben configurar para el funcionamiento de este componente son versión de base de datos, Host, puerto, nombre de la base de datos, esquema en el cual se encuentra, nombre de usuario y contraseña, nombre de la tabla y consulta a realizar. La versión de la base de datos manejada es 9 o posterior, dado que en la Oficina Asesora de sistemas se trabaja con esta versión de sistema gestor de base de datos Postgresql. Los parámetros de host, puerto nombre de la base de datos, esquema, nombre de la tabla, nombre de usuario y contraseña se definen con los correspondientes a la información de la bodega de datos de la Oficina Asesora de Sistemas. La consulta corresponde a la extracción de los IDs obtenidos de la petición HTTP realizada anteriormente. En la ilustración 20 se muestra el ícono del componente tPostgresqlInput.. Ilustración 20 Ícono tPostgresqlInput, recuperado de: https://help.talend.com/viewer/attachment/qejbvzGrBDSOHeLCNNgKxg. 28.

(34) 12.2.4.2 tFlowToIterate. Este componente se usa para leer los datos entrantes línea por línea y guardarlos en las variables globales de Talend por cada iteración que se realice. Los datos de entrada de este componente provienen de la base de datos postgresql en la cual están los IDs de la petición. Se realiza una iteración por cada ID que se encuentre en la base de datos. En la ilustración 21 se muestra el ícono del componente tFlowToIterate.. Ilustración 21 Ícono tFlowToIterate, recuperado de: https://help.talend.com/viewer/attachment/MGtRNq5UFxCFVfjWFuZd6g. 12.2.4.3 tRest. Este componente envía peticiones HTTP a un servicio web REST, en este caso el REST Api de Tuleap. Los parámetros que son necesarios configurar son la URL, el método HTTP y las cabeceras HTTP. La URL se selecciona según la respuesta que se necesite, para este componente se configuro la URL que preveía la información de un artifact específico pero se trabajó en conjunto con el componente tFlowToIterate para poder usar una URL dinámica, ya que por cada ID obtenido en la petición anterior se debía trabajar con una URL diferente por cada uno para obtener los datos de cada uno de los artifacts. No se puedo utilizar el componente tRestClient, el cuál manejaba peticiones HTTPS con los parámetros configurables de las credenciales, ya que Talend no permite realizar iteraciones con este componente El método HTTP seleccionado fue GET, ya que deseábamos obtener información del Api. El tipo de acceso escogido fue XML por simplicidad de manejo, especificando este tipo de acceso en la cabecera HTTP correspondiente. Dado que este componente no maneja peticiones HTTPS, se presentó un problema en el desarrollo del ETL. La respuesta que se recibía era 401 Unauthorized. Para solucionarlo, se trabajó en conjunto con el componente tJava, el cual se explicara más adelante, para mandar la cabecera codificada de la autorización y lograr obtener la respuesta deseada con la información correspondiente. En la ilustración 22 se muestra el ícono del componente tREST. 29.

(35) Ilustración 22 Ícono tRest, recuperado de: https://help.talend.com/viewer/attachment/hkJNL1b8jakFJj_5g5fOKA. En la ilustración 23 se da una muestra de la respuesta XML de este componente en la fase 2 ETL de uno de los artifacts asociados al proyecto.. Ilustración 23 Espinosa, Andrés (2018) Muestra de la respuesta XML fase 2 ETL. 12.2.4.4 tConvertType. Este componente permite realizar conversiones de tipos específicos en tiempo de ejecución en un proyecto. Se utilizó este componente debido a que el cuerpo de respuesta del componente tRest es de tipo String y se necesita un documento XML para filtrar los datos con el componente tXMLMap. En la ilustración 24 se muestra el ícono del componente tConverType.. 30.

(36) Ilustración 24 Ícono tConvetType, recuperado de: https://help.talend.com/viewer/attachment/xOL65Yy6X8Q6VRfglpQ3jg. 12.2.4.5 tExtractXMLField. Con este componente se extraen los datos deseados de un archivo XML. El componente abre una entrada de un archivo estructurado XML el cual fue recibido como respuesta del REST API de Tuleap y convertido anteriormente a formato XML, ya que la respuesta se tomaba de tipo String. Luego se envía al siguiente componente, utilizando los XPath query correspondientes según correspondiera en la estructura del archivo, para que la información sea filtrada como es necesario para realizar su inserción en la base de datos. En la ilustración 25 se muestra el ícono del componente tMap.. Ilustración 25 Ícono tExtractXMLField, recuperado de: https://help.talend.com/viewer/attachment/37Rk1uvRgOc0b7Uzn~fdjA. 12.2.4.6 tMap. Con este componente se transforman y dirigen los datos provenientes de un archivo desde una o varias fuentes hacia uno o varios destinos. Dentro de este componente se cuenta con un editor con el cual se filtran y transforman los datos. A diferencia del componente tXMLMap, este componente es dedicado a todo tipo de archivos. En el proyecto se necesitó utilizar este componente para manejar principalmente las fechas que provenían del anterior componente para concordar con el formato usado en la base de datos postgresql y pasar los demás datos para su inserción. En la ilustración 26 se muestra el ícono del componente tMap.. Ilustración 26 Ícono tMap, recuperado de: https://help.talend.com/viewer/attachment/NWjnjzs8X7vigqFFG_1QYw. 31.

(37) 12.2.4.7 tpostgresqlInput. Este componente es usado para realizar comandos SQL de inserción y actualización en las bases de datos Postgresql. El componente realiza la acción especificada siguiendo los parámetros configurados en este. Los parámetros que se deben configurar para el funcionamiento de este componente son versión de base de datos, Host, puerto, nombre de la base de datos, esquema en el cual se encuentra, nombre de usuario y contraseña, nombre de la tabla, acción sobre la tabla y acción sobre los datos. La versión de la base de datos manejada es 9 o posterior, dado que en la Oficina Asesora de sistemas se trabaja con esta versión de sistema gestor de base de datos Postgresql. Los parámetros de host, puerto nombre de la base de datos, esquema, nombre de la tabla, nombre de usuario y contraseña se definen con los correspondientes a la información de la bodega de datos de la Oficina Asesora de Sistemas. La acción sobre la tabla se definió como “crear tabla si no existe” para evitar inconvenientes en la persistencia de los datos. La acción sobre los datos se definió como “insert o update” dado que en cada proceso de ETL se obtienen nuevos IDs de artifacts y se actualiza el estado de los artifacts existentes. Esta es la segunda vez que se utiliza este componente en el proyecto. La primera vez se utilizó para insertar los IDs de los artifacts para su posterior uso en la siguiente petición al REST Api de Tuleap. En la fase 2 del proceso ETL se utilizó para filtrar y completar la información de las tareas que se obtenían y así insertar los registros en la base de datos listos para ser consumidos por SpagoBI para realizar los Key Performance Indicators correspondientes al proyecto. En la ilustración 27 se presenta una muestra de los registros obtenidos como resultado del proceso ETL realizado a un proyecto inscrito en la plataforma de gestión de proyectos Tuleap.. Ilustración 27 Espinosa, Andrés (2018) Muestra de registros obtenidos del ETL. 32.

(38) 12.3 Generación de reportes Con SpagoBI se generarán los reportes gráficamente de la información extraída con Talend. Por medio de los medidores de desempeño KPI(Key Performance Indicator) se mostrará gráficamente el desempeño de cada proyecto, dependiendo del estado de las tareas de cada una de sus fases. Para la creación de los KPIs se precisa realizar una serie de pasos con el fin de mostrar gráficamente el progreso del proyecto, siguiendo una lógica temporal que fue regida por consultas sql con las cuales se logra finalmente mostrar el progreso del proyecto por fases. Primero se debe definir la fuente de datos y el set de datos con el cual se trabajará el KPI. Luego se debe definir el umbral por el cual será regido dicho set de datos, en otras palabras un límite o rango en el cuál se hará la medición de cada KPI. Después se debe crear la definición del KPI en el cual se asocian el set de datos y el umbral. Siguiente a esto se debe crear la definición del modelo el cual usará los KPIs creados. Por último se creara una instancia del modelo en el cual se asociará cada KPI a la fase y nodo del proyecto según corresponda para luego mostrar el resultado en un documento genérico en el servidor de SpagoBI de la Oficina Asesora de Sistemas.. 12.3.1 Definición de fuente de datos y set de datos. Como paso inicial para la creación de un KPI se debe definir la fuente de datos y el set de datos a utilizar. La fuente de datos que se utilizó en la creación de KPIs fue una base de datos existente en la bodega de datos de la Oficina Asesora de Sistemas a la cual se agregaron dos tablas llamadas tuleap_response y tuleap_data. Luego se definió el set de datos el cual consiste en un conjunto de datos que dan como respuesta un valor a desplegar en un KPI. Para lograr desplegar el valor correspondiente a cada KPI se debió realizar una consulta anidada en la cual se obtenía el porcentaje de tareas completas por fase, además el porcentaje desarrollado por fase y el total del proyecto. Se debió crear un set de datos por cada fase y cada nodo del modelo propuesto en la Oficina Asesora de Sistemas. En la ilustración 28 se muestra un ejemplo de cómo se procedió para la creación de un set de datos, en este caso el set de datos de la fase de diseño. Para cada una de las tareas y fases se llevó a cabo el mimo procedimiento, teniendo en cuenta el cambio necesario en cada consulta para que cada uno de estos elementos tuviera una relación lógica en el proyecto.. 33.

(39) Ilustración 28 Espinosa, Andrés (2018) data set de la fase de diseño. 12.3.2 Definición del umbral. Para poder mostrar por rangos los resultados del set de datos se debe crear la definición del umbral. En este caso los valores a mostrar corresponden al porcentaje del progreso de cada tarea, fase y del proyecto. En el umbral se definieron 5 rangos los cuales corresponden a: 1) 0%<=x<=20%, 2) 20%<x<=40% 3) 40%<x<=60% 4)60%<x<=80% 5) 80%<x<=100%. En la ilustración 29 se muestra la definición del umbral.. Ilustración 29 Espinosa, Andrés (2018) Definición del Umbral. 34.

(40) 12.3.3 Definición del KPI. En la definición del KPI se asocian el set de datos con el umbral. Cada KPI representa una tarea, fase o el proyecto. Con esta asociación se logra limitar el KPI con los respectivos porcentajes mencionados anteriormente para darle un orden jerárquico según el progreso de cada tarea, fase o del proyecto. En la ilustración 30 se muestra la definición del KPI asociando el set de datos y el umbral para el caso de la tarea del modelo de datos. Con cada elemento se debió realizar el mismo procedimiento de asociación entre umbral y set de datos.. Ilustración 30 Espinosa, Andrés (2018) definición del KPI de modelo de datos.. 12.3.4 Definición del Modelo. Para mostrar los KPIs también es necesario definir un modelo. En la definición del modelo se logra mostrar por tareas y fases el desarrollo de todo un proyecto en la Oficina Asesora de Sistemas. A cada tarea, fase y a la totalidad del proyecto se le asociará un KPI en los pasos siguientes para poder visualizar detalladamente y gráficamente el progreso del proyecto. En la ilustración 31 se muestra la definición del modelo por fases en SpagoBI. Especificar cada kpi en documento. 35.

(41) Ilustración 31 Espinosa, Andrés (2018) Definición del modelo. 12.3.5 Instancia del Modelo. Para utilizar el modelo anteriormente creado junto a los KPIs es necesario crear una instancia de ese modelo. Al crear esta instancia SpagoBI permite asociar los KPIs con cada tarea, fase y proyecto. En la ilustración 32 se muestra el resultado final de la asociación de los KPIs correspondientes a cada tarea, fase y proyecto.. 36.

(42) Ilustración 32 Espinosa, Andrés (2018) Instancia del modelo. Con cada uno de los elementos de debió realizar la asociación respectiva entre KPI y elemento, para que el resultado final fuera el deseado.. 37.

(43) 12.3.6 Creación del documento. Finalmente, para mostrar los KPIs del proyecto de integración se creó un documento genérico que desplegara la instancia del modelo junto a los KPIs. La información es cargada de la tabla generada en la Base de Datos y es graficada en perilla según se haya definido el umbral en SpagoBI. La ilustración 33 muestra el resultado final de la creación de los KPIs.. Ilustración 33 Espinosa, Andrés (2018) KPIs del proyecto. 12.4 Despliegue de reportes Los reportes se visualizan en el CMS Drupal. La página de la oficina asesora de sistemas tiene como gestor de contenido a Drupal, por lo tanto se realizó la integración con este CMS para desplegar los reportes gráficamente. En dicha página se visualizarán los reportes según lo desee el administrador de la página. Para realizar la integración de SpagoBI con Drupal, se desarrolló un módulo en el CMS. Drupal es una herramienta fácilmente extensible, este CMS está desarrollado en el lenguaje PHP y para lograr esta característica de extensibilidad, sus desarrolladores crearon el concepto de Hooks. Los Hooks son fragmentos de código basado en arreglos, presentes tanto en PHP como en otros lenguajes de programación, los cuales son leídos desde el núcleo de Drupal y con estos es posible desarrollar módulos, además de diferente 38.

(44) contenido en el CMS. Con el fin de la integración mencionada, se desarrolló un módulo el cual se denominó Spagofield en el que se gestiona la configuración de los reportes a desplegar de una manera sencilla. En la ilustración 34 se observa el formulario de administración de SpagoField. Los campos necesarios para el despliegue de los reportes son documentLabel, executionRole, User y Password, el campo Parameters es opcional y sólo es necesario en ciertos reportes.. Ilustración 34 Espinosa, Andrés (2018) Configuración de reportes. 39.

(45) En la ilustración 35 se muestra el reporte de KPIs del proyecto en el CMS.. Ilustración 35 Espinosa, Andrés (2018) Despliegue de reportes. 40.

(46) CAPÍTULO 13. MODELO DE DATOS La idea de la integración y los procesos ETL es mantener la simplicidad en cuanto al modelo de datos para facilitar el proceso de transformación y carga de la información. Teniendo en cuenta este principio, se modeló una tabla que contiene toda la información concerniente a los Artifacts. Antes de obtener los datos necesarios para la tabla resultante se necesitó crear una tabla la cual almacenarían los IDs provenientes de la fase 1 del proceso ETL. En la ilustración 36 se muestra la tabla resultante de la fase 1.. Ilustración 36 Espinosa, Andrés (2018) Tabla fase 1. En la tabla 3 se describe la tabla utilizada en la fase 1 del proceso ETL.. Atributo Descripción Tipo details IDs obtenidos del Varchar proyecto. Null. PK X. FK X. Tabla 3 Espinosa, Andrés (2018) Descripción de la tabla fase 1. 41.

(47) La información que se almacena en la tabla es usuario, tarea, ID del Artifact, el tipo de tarea, el estado, la asignación de dicha tarea, los detalles y las fechas de registro y de última actualización. En la ilustración 37 se muestra el modelo de la tabla del proceso ETL.. Ilustración 37 Espinosa, Andrés (2018) Tabla del proceso ETL. En la tabla 4 se describe la tabla resultante del proceso ETL. Atributo id title type Status assigned_to details submitted_by last_update_by. Descripción Id del Artifact Título del Artifact Tipo de tarea Estado del a Artifact Persona asignada a la tarea Detalles de la tarea Persona que registró el Artifact Persona que registró la actualización submitted_on Fecha de registro del Artifact last_update_on Fecha de última actualización. Tipo varchar varchar varchar varchar varchar varchar varchar última varchar. Null PK X. UK X. timestamp timestamp. Tabla 4 Espinosa, Andrés (2018) Descripción de la tabla ETL. 42.

(48) CAPÍTULO 14. CONCLUSIONES Con el proceso ETL llevado a cabo en este proyecto se logra obtener información estructurada desde Tuleap para así ser integrada por medio de otras herramientas tecnológicas como Drupal y SpagoBI con las cuales se realizó el despliegue de la información obtenida en el proceso ETL a fin de poder realizar el proceso de inteligencia de negocios concerniente. La creación de la nueva versión del sistema informático de administración de proyectos en Tuleap, por medio de la integración de diferentes herramientas, facilita la identificación visual que es lograda por medio de los KPIs y demás tecnologías utilizadas en este proyecto permitiendo realizar el proceso de inteligencia de negocios que es llevada a cabo por los profesionales de ingeniería y gerencia de proyectos en la Oficina Asesora de Sistemas. Los formularios que se crearon en el apartado de artifacts en los trackers permite la recolección automatizada de información de manera eficiente, sencilla y amigable para los usuarios de Tuleap. Los KPIs permiteron la identificación visual de falencias y fortalezas en un proyecto. Dado que los reportes se muestran de forma visual en forma de perilla logrando así un rápido entendimiento de lo que está sucediendo en las diferentes tareas y fases del proyecto además de hacerlo respectivamente con la totalidad del proyecto para que la gerencia de proyectos en la Oficina Asesora de Sistemas logre tomar decisiones de manera más eficiente. Con este proyecto se logró obtener la facilidad en la administración de proyectos que no permite Tuleap por cuenta propia. Gracias al uso de las diferentes herramientas tecnológicas utilizadas en el desarrollo del proyecto se logró claridad en cuanto al estado real de los proyectos en la Oficina Asesora de Sistemas. Las decisiones que se deben tomar según el estado de un proyecto se simplificaron debido a la naturaleza visual de los reportes creados. Este proyecto tiene un gran alcance debido a la posibilidad de extenderlo para nuevas funcionalidades que faciliten la labor administrativa de los proyectos en la Oficina Asesora de Sistemas tal como notificaciones a usuarios y demás soluciones que se puedan plantear en un futuro.. 43.