UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE COMPUTACIÓN

Transcripción

1 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE COMPUTACIÓN IMPLEMENTACIÓN E IMPLANTACIÓN DEL SISTEMA CONTROL DE GASTOS KAIZEN CGK Por: Maximiliano Alejandro González Pérez INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, Marzo de 2009

2 UNIVERSIDAD SIMÓN BOLÍVAR DECANATO DE ESTUDIOS PROFESIONALES COORDINACIÓN DE COMPUTACIÓN IMPLEMENTACIÓN E IMPLANTACIÓN DEL SISTEMA CONTROL DE GASTOS KAIZEN CGK Por: Maximiliano Alejandro González Pérez Realizado con la asesoría de: Tutor Académico: Kenyer Domínguez Tutor Industrial: Reyes Pinto INFORME DE PASANTÍA Presentado ante la Ilustre Universidad Simón Bolívar como requisito parcial para optar al título de Ingeniero en Computación Sartenejas, Marzo de 2009

3

4 iv IMPLEMENTACIÓN E IMPLANTACIÓN DEL SISTEMA CONTROL DE GASTOS KAIZEN CGK Por: Maximiliano Alejandro González Pérez RESUMEN El siguiente trabajo documenta el proceso y los resultados del diseño, implementación e implantación de un sistema que permite agilizar el proceso de solicitud y reembolso de gastos dentro de la empresa Kaizen Cone Norte C.A. Este sistema busca simplificar el proceso de ingreso, evaluación y reintegro de los gastos en los cuales hayan incurrido los colaboradores de la empresa, facilitando de esta manera los procesos administrativos, e involucrar a todos los niveles jerárquicos de la compañía, para lograr una distribución equitativa de las tareas correspondientes a dicho proceso, alcanzando una aceleración en el desarrollo del mismo. Para el desarrollo de este sistema se utilizó el framework Spring Web MVC 2.5, el cual administra la carga derivada de la creación de aplicaciones y la herramienta Hibernate 3.2.5, la cual permite un manejo eficiente de los objetos persistentes. La implementación se realizó sobre la plataforma Java Standard Edition 1.6, con Netbeans IDE 6.1 como herramienta de desarrollo, Microsoft SQL Server 2005 como manejador de base de datos y Java como lenguaje de programación.

5 v TABLA DE CONTENIDO INTRODUCCIÓN... 1 CAPÍTULO ENTORNO EMPRESARIAL Descripción general de la empresa Estructura organizacional Ubicación del pasante... 4 CAPÍTULO DESCRIPCIÓN DEL PROYECTO Antecedentes Planteamiento del Problema Solución Propuesta Objetivo General Objetivos Específicos... 8 CAPÍTULO MARCO TEÓRICO... 9

6 vi 3.1 Sistemas de Procesamiento de Transacciones Sistemas de Administración de Flujo de Trabajo Java Java SE Patrones de diseño Patrón Modelo Vista Controlador Spring MVC Hibernate CAPÍTULO MARCO METODOLÓGICO Metodología RUP Fase de inicio Fase de elaboración Fase de construcción Fase de transición Fases a cubrir dentro del marco de la pasantía CAPÍTULO

7 vii DESARROLLO Fase de inicio Creacion de plan de proyecto Levantamiento de información Requerimientos Objetivo del sistema Flujo de trabajo actual Flujo de trabajo propuesto Casos de uso Riesgos del Sistema Fase de elaboración Actualización del plan de proyecto Definición de la arquitectura Vista lógica Vista de procesos Vista de despliegue Vista de implementación... 41

8 viii Vista de casos de uso Definición de la base de datos Actualización de los riesgos del sistema Fase de construcción Cambios planteados Primera iteración Segunda iteración Fase de transición Pantallas de CGK CAPITULO LOGROS Y OBJETIVOS CUMPLIDOS Objetivos específicos Objetivo general Logros adicionales conclusiones y recomendaciones BIBLIOGRAFÍA APÉNDICES... 61

9 ix ÍNDICE DE TABLAS Tabla 1.- Planteamiento del problema de CGK Tabla 2.- Plan de proyecto para la fase de inicio Tabla 3.- Principales requerimientos del sistema CGK Tabla 4.- Usuarios y sus funciones dentro del Sistema CGK Tabla 5.- Matriz de Riesgo para la fase de inicio Tabla 6.- Plan de proyecto para la fase de elaboración Tabla 7.- Matriz de Riesgo para la fase de elaboración Tabla 8.- Casos de uso desarrollados durante la primera iteración Tabla 9.- Casos de uso desarrollados durante la segunda iteración

10 x ÍNDICE DE FIGURAS Figura 1.- Pirámide de SI [3] Figura 2.- Compilación en bytecode de Java [7] Figura 3.- Ciclo de vida de RUP [14] Figura 4.- Diagrama de Casos de Uso del Sistema CGK Figura 5.- Representación del modelo de 4+1 vistas [20] Figura 6.- Diagrama de paquetes del sistema CGK Figura 7.- Diagrama de despliegue del sistema CGK Figura 8.- Diagrama de clases del sistema CGK Figura 9.- Modelo ER-E del sistema CGK Figura 10.- Inicio de sesión del Sistema CGK Figura 11.- Ingreso de registro de gasto en el Sistema CGK Figura 12.- Listado de registros en el Sistema CGK

11 xi LISTA DE SÍMBOLOS Y ABREVIATURAS ASP CC CGK CMMi IDE IT JSF JSP JVM MVC RUP SE SI SQL TG TPS Active Server Pages Centro de Costo Control de Gastos Kaizen Capability Maturity Model Integration Integrated development Enviroment Information Technology Java Server Faces Java Server Pages Java Virtual Machine Modelo Vista Controlador Rational Unified Process Standard Edition Sistema de Información Structured Query Language Tipo de gasto Transaction Processing System

12 xii UR WFMS Unidades de referencia Workflow Management System

13 1 INTRODUCCIÓN El control de gastos dentro de una empresa es una de las actividades cruciales para el correcto funcionamiento de la misma. Dicha tarea debe ser realizada de una manera responsable y transparente, regida por las políticas y procesos establecidos por la compañía en la que participen todos los niveles de la empresa para así garantizar un cumplimiento cabal de dicha labor. La información derivada de esta tarea debe de estar clara y disponible en todo momento para los niveles administrativos de cualquier empresa, haciéndose necesaria la utilización de una solución automatizada que permita satisfacer estos requerimientos ya que los métodos manuales, a pesar de que son efectivos, producen retrasos en el procesamiento de dicha información además del omnipresente riesgo de la pérdida o alteración de la misma. Dentro de la empresa Kaizen Cone Norte C.A., el proceso de solicitud, evaluación y reembolso de gastos es realizado de manera no automatizada, no involucrando a niveles jerárquicos que deberían de estarlo y por lo tanto, colocando todo el peso de esta tarea en el departamento administrativo de la misma. Conscientes de los beneficios de los procesos automatizados y de las bondades de Internet, la compañía propuso la implementación e implantación de un sistema que resolviera dichos problemas, automatizara el proceso de reintegro de fondos a los colaboradores e involucrara a los niveles correspondientes dentro de dicho proceso. La tecnología utilizada para el desarrollo de dicho sistema es Java Enterprise Edition 5, utilizando el framework Spring Web MVC 2.5, la herramienta Hibernate 3.2.5, el manejador de base de datos Microsoft SQL Server El lenguaje de programación utilizado fue Java y el ambiente de desarrollo seleccionado fue Netbeans IDE 6.1.

14 2 El presente informe presenta los resultados obtenidos del análisis, diseño, implementación e implantación de dicho sistema, así como las conclusiones y recomendaciones derivadas del desarrollo del mismo.

15 3 CAPÍTULO 1 ENTORNO EMPRESARIAL En este capítulo se describe la empresa donde fue desarrollado el proyecto de pasantía con la finalidad de brindar un esbozo del ambiente de trabajo. 1.1 Descripción general de la empresa La Empresa Kaizen Cone Norte C.A. es una subsidiaria de su casa matriz Kaizen ubicada en la ciudad de Indaiatuba en Brasil. Esta rama surge de la necesidad y oportunidad de negocio que se presenta para la zona norte del continente Suramericano y parte del Centroamericano. Kaizen Cone Norte es una empresa especializada en el sector de tecnología de la información, enfocándose en la venta, instalación, entrenamiento y soporte post-venta de equipos de almacenamiento masivo y en la implantación de soluciones destinadas a la virtualización de servidores. Sus principales asociados son empresas de alto renombre a nivel internacional, entre ellas están Microsoft, EMC 2, VMWare, Dell, IBM, entre otros. Ha mantenido contratos con grandes empresas venezolanas como PDVSA, Banco Mercantil, Banesco, Banco Nacional de Crédito, Banco Provincial, CANTV y Seguros La Seguridad por nombrar algunos.

16 4 1.2 Estructura organizacional La Empresa se encuentra dividida en Centros de Costo (CC) los cuales son las divisiones que llevan a cabo las actividades de la empresa. Dichos CC son: Coordinación. Administración. Ventas. Instalación y soporte. Cada uno de estos CC están liderados por un Coordinador a excepción de la Coordinación, la cual es dirigida por el dueño de la Empresa. Al ser estos los líderes de los CC, su misión es transmitir las órdenes emanadas de la Coordinación, hacer planificaciones de los proyectos de la Empresa y controlar el ambiente dentro de los CC que dirigen. 1.3 Ubicación del pasante El pasante fue ubicado en el CC de Coordinación. Esta decisión fue tomada basada en el hecho de que la Empresa no posee un departamento encargado del desarrollo de software y a que toda la información referente al Sistema estaba siendo manejada en esta área de la misma. De igual manera, se designó a un grupo de miembros de la Coordinación ante los cuales el pasante debía exponer sus cuestionamientos y presentar sus logros para la aprobación.

17 5 CAPÍTULO 2 DESCRIPCIÓN DEL PROYECTO En este capítulo se dará una descripción del proyecto de pasantía. Se detallará el planteamiento del problema y la solución propuesta al mismo. También se establecerán los objetivos del proyecto así como delimitar su alcance. 2.1 Antecedentes La Empresa (Kaizen Cone Norte C.A.) por la naturaleza de su negocio, requiere que su personal se encuentre presente en las oficinas de sus clientes con la finalidad de satisfacer las necesidades de éstos. Frecuentemente durante estas visitas, los colaboradores incurren en gastos reintegrables por parte de la empresa tales como transporte, comidas, adquisición de materiales, hospedaje, entre otros. Dichos gastos eran ingresados en una hoja de cálculo de Microsoft Excel y enviadas al departamento administrativo junto con las facturas originales para realizar la evaluación, el cotejamiento entre los montos solicitados y los reflejados en las facturas, y su posterior reembolso. Como consecuencia de este modelo, todo el peso es puesto sobre el departamento administrativo, lo cual disminuye la eficiencia del mismo, y no mantiene informado al colaborador sobre el estado de sus solicitudes.

18 6 2.2 Planteamiento del Problema El problema se presenta en la siguiente tabla: El problema El proceso de ingreso, evaluación y reembolso de los gastos en los que incurren los Colaboradores que son reintegrables por parte de la Empresa es lento. Los estados de dichas solicitudes deben ser conocidos en todo momento por las partes interesadas a fin de mantenerlas informadas y actualmente esto no está ocurriendo. Toda la carga del proceso de evaluación y reembolso se encuentra en el departamento administrativo. Afecta a Todos los Colaboradores que ingresaran alguna solicitud. El departamento administrativo de la Empresa. El impacto es Los estados de las solicitudes son desconocidos por parte de los solicitantes, lo cual genera incertidumbre sobre las mismas. El departamento administrativo es el encargado de realizar la evaluación basándose únicamente en los comprobantes de consumo presentados por los Colaboradores, lo cual puede resultar en una evaluación errada. Sobrecarga de procesos en el CC Administración, lo cual disminuye la efectividad y rapidez de la finalización de las tareas. Una solución exitosa sería El desarrollo de un sistema que permita a los usuarios ingresar de manera rápida sus solicitudes de gasto, que les permita mantenerse al tanto de los diferentes estados de las mismas y que automatice las evaluaciones. Tabla 1.- Planteamiento del problema de CGK.

19 7 2.3 Solución Propuesta Se propuso crear un SI (Sistema de Información) de tipo TPS (Transaction Processing System) que agilizara el proceso de ingreso, evaluación y reembolso de consumos realizados por los colaboradores de la Empresa. Dicho sistema, denominado CGK (Control de Gastos Kaizen), debería permitir a los solicitantes, verificar el estado de sus solicitudes en cualquier instante e involucrar a los Líderes de CC en el proceso para lograr dos objetivos: una evaluación coherente, basada en las asignaciones realizadas por éstos, y simplificar el trabajo del departamento administrativo de la Empresa. 2.4 Objetivo General Diseñar, desarrollar e implantar un producto de calidad, hecho a la medida de los requerimientos y necesidades de la empresa, que facilite el proceso de solicitud, evaluación y reembolso de los gastos por parte de los Colaboradores de la Empresa. 2.5 Objetivos Específicos El sistema debe cumplir con los siguientes objetivos: Realizar de manera satisfactoria el proceso de ingreso, evaluación y reembolso de gastos. Facilitar la consulta de estado de solicitudes por parte de los Colaboradores. Incorporar a los Coordinadores en la fase de evaluación de las solicitudes. Aligerar la carga del departamento administrativo de la Empresa como consecuencia de los objetivos mencionados anteriormente.

20 8 2.6 Alcance El alcance del proyecto de pasantía es el diseño, desarrollo y puesta en producción de la solución. Se busca reducir los tiempos de respuesta para cada una de las solicitudes hechas por los Colaboradores, mantenerlos informados de los estados de las mismas a lo largo del proceso además de lograr mantener un registro actualizado y fiable que refleje el comportamiento de los entes de la Empresa. Uno de los objetivos específicos de la pasantía indica que se requiere que los Líderes de los CC se incorporen dentro del proceso, específicamente a la evaluación de las solicitudes realizadas por los Colaboradores. Para lograr dicho objetivo, fue necesario modificar la manera en la que el proceso de evaluación era realizado, de manera tal que se generó un nuevo flujo de trabajo y una nueva metodología para los procesos de negocio de la Empresa. Por razones ajenas a la voluntad del pasante, la implantación del sistema no pudo ser llevada a cabo. Dicha tarea fue dejada en manos de la Empresa para ser realizada una vez se dispusiera de la infraestructura adecuada. De igual manera, otros requerimientos fueron modificados por solicitud de la Empresa, no se emplearon los estándares de calidad CMMi (Capability Maturity Model Integration) y las tecnologías utilizadas cambiaron, inicialmente se solicitó realizar la implementación utilizando el framework.net, con C++ como lenguaje de implementación y ASP.NET como tecnología de desarrollo web y luego éstas cambiaron, se utilizó Java SE 6 con Java con lenguaje de implementación y JSP para el desarrollo de la interfaz. Todos estos cambios serán explicados con mayor detalle en los capítulos correspondientes de este libro.

21 9 CAPÍTULO 3 MARCO TEÓRICO En este capítulo se definirán conceptos importantes para el desarrollo del proyecto de pasantía, estos son Sistemas de Procesamiento de Transacciones, Sistemas de Administración de Flujo de Trabajo, Java, Java SE, patrones de diseño, Spring Web MVC e Hibernate. 3.1 Sistemas de Procesamiento de Transacciones Un SI puede ser definido como un conjunto de componentes interrelacionados que recopilan, procesan, almacenan y distribuyen información para apoyar la toma de decisiones y el control dentro de una organización [1]. Los principales usos que se le dan a los SI dentro de las organizaciones son en las áreas de ventas, fabricación, finanzas y recursos humanos. Las siguientes son las categorías en las cuales se clasifican los SI según la función a la que serán destinados: Sistemas de nivel operacional: son los encargados de monitorizar las actividades elementales de la organización. El propósito principal de los sistemas de éste nivel es el de responder preguntas rutinarias y seguir el flujo de operaciones dentro de la empresa [2].

22 10 Sistemas de nivel de conocimiento: son los encargados de descubrir, organizar e integrar conocimientos nuevos o ya existentes dentro del negocio. Mejoran los productos y la administración de una organización. Sistemas de nivel administrativo: diseñados para monitorizar, controlar, supervisar la toma de decisiones y las actividades administrativas de los niveles intermedios de la empresa [2]. Sistemas de nivel estratégico: atienden problemas de índole estratégica y tendencias a largo plazo, tanto dentro de la organización como en el ambiente externo [2]. Figura 1.- Pirámide de SI [3]. De estas categorías, se ahondará en la primera ya que es la de interés, sistemas de nivel operacional. La representación computarizada de éstos son los Sistemas de Procesamiento de Transacciones, o TPS por sus siglas en inglés. Estos Sistemas son básicos para la generación de la información ya que sus datos provienen de las transacciones y eventos rutinarios de la empresa. Los sistemas de niveles superiores toman estos datos y los analizan según sus finalidades.

23 11 Algunas de las características de los TPS son las siguientes: Deben ser confiables y precisos. Deben ser rápidos. Deben ser estructurados o programables. La información debe poder ser accedida en cualquier momento y ésta debe de estar actualizada. Unos buenos ejemplos de TPS pueden ser los sistemas de reserva de pasajes de líneas aéreas, donde la información sobre la disponibilidad de asientos tiene que estar actualizada siempre, los sistemas de puntos de ventas electrónicos, en los que los montos de las compras deben ser debitados de las cuentas del comprador y acreditados a las del vendedor de manera inmediata, y los sistemas de préstamo de libros en las bibliotecas, donde el acceso a la información sobre la existencia de un libro debe ser mantenida y actualizada de manera periódica. 3.2 Sistemas de Administración de Flujo de Trabajo Se define un Sistema de Administración de Flujo de Trabajo o WFMS por sus siglas en inglés, como un sistema que define, crea y administra la ejecución de flujos de trabajo a través del uso de software, ejecutándose en uno o más motores de flujo, el cual es capaz de interpretar la definición del proceso, interactuar con los participantes y, cuando sea requerido, invocar el uso de herramientas IT y sus aplicaciones [4]. Un WFMS consiste en componentes de software para almacenar e interpretar definiciones de procesos, crear y administrar instancias de flujo de trabajo de la manera en la que son ejecutados y controlar su interacción con los participantes y las aplicaciones del mismo [4]. Dichos sistemas adicionalmente proveen funciones administrativas y de supervisión, permitiendo por ejemplo la reubicación de actividades, además de información de auditoría y administración del sistema como tal o relacionada a procesos individuales [4].

24 Java Java es un lenguaje de programación concebido por un equipo de Sun Microsystems en Inicialmente surge por la necesidad de tener un lenguaje que fuera independiente de la plataforma, y que pudiera ser utilizado para crear software para diferentes tipos de dispositivos electrónicos, pero con el crecimiento del World Wide Web éste fue inclinado al desarrollo para Internet [5]. Una de las características principales de Java es que realza y mejora el modelo de orientación a objetos, utilizando los tres mecanismos que ayudan a implementarlo: encapsulamiento; permite unir el código junto con los datos que manipula, herencia; proceso mediante el cual un objeto adquiere propiedades de otro, y polimorfismo; permite que una interfaz sea utilizada por una clase general de acciones [5]. En Java la base del encapsulado son las clases, éstas definen la estructura y comportamiento que serán compartidos por un conjunto de objetos. La herencia es manejada a través de las subclases, en las que se tienen los atributos propios y los atributos que son heredados de las clases predecesoras. El polimorfismo es manejado por los métodos declarados dentro de las clases [5]. 3.4 Java SE Java Platform, Standard Edition o Java SE como es popularmente conocido, es una plataforma ampliamente conocida utilizada para programar en el lenguaje Java [6] el cual es muy parecido a C y C++, orientado a objetos pero con un manejo de los mismos de una manera mucho más simple [7]. Java SE es la plataforma utilizada para el despliegue de aplicaciones portátiles. Consiste de una máquina virtual, la cual es utilizada para ejecutar los programas escritos en Java, junto con

25 13 un conjunto de librerías necesarias para la utilización de sistemas de archivos, redes e interfaces gráficas [6]. Los programas escritos en Java, son compilados por la plataforma en un lenguaje intermedio llamado bytecode, para luego ser interpretados por la máquina virtual de Java o JVM por sus siglas en inglés. Una de las ventajas de esta modalidad, y algo que siempre se había buscado dentro de la programación, es la posibilidad de llevar los programas a este lenguaje intermedio para luego ser ejecutados en cualquier plataforma. Es decir, un programa puede ser compilado en una computadora cuyo sistema operativo es Windows, y llevar ese código en bytecode a otra máquina con una JVM instalada sin importar el sistema operativo, y el programa se ejecutará sin problema alguno. Como se dijo anteriormente, la plataforma Java SE posee dicha máquina virtual. Figura 2.- Compilación en bytecode de Java [8].

26 Patrones de diseño Los patrones de diseño son un conjunto de prácticas de óptimo diseño que se utilizan para abordar problemas recurrentes en la programación orientada a objetos [9]. Un patrón de diseño puede considerarse como un documento que define una estructura de clases que aborda una situación particular [9]. Los patrones de diseño se dividen en tres grupos principales: Patrones creacionales: Inicialización y configuración de objetos. Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes. Patrones de Comportamiento: describen la comunicación entre los objetos y las clases Patrón Modelo Vista Controlador El patrón Modelo Vista Controlador (MVC) es una arquitectura de diseño de software diseñada para reducir el esfuerzo de programación necesario en la implementación de sistemas múltiples y sincronizados de los mismos datos [9]. Su principal característica es la capacidad de tratar a sus tres componentes modelo, vista y controlador de manera independiente. A continuación, una descripción de cada una de sus partes: Modelo: representa las estructuras de datos. Típicamente el modelo de clases contendrá funciones para consultar, insertar y actualizar información de la base de datos [11]. Vista: es la información presentada al usuario. Una vista puede ser una página web o una parte de una página [11]. Controlador: actúa como intermediario entre el Modelo, la Vista y cualquier otro recurso necesario para generar una página [11].

27 Spring MVC El framework Spring es una herramienta utilizada para el desarrollo de aplicaciones en el lenguaje Java. Fue diseñado en módulos con funcionalidades específicas y consistentes. Entre sus principales ventajas tenemos la facilitación en la manipulación de objetos, eliminación de la utilización de varios ficheros de configuración, mejora en la práctica de la programación, entre otras. Uno de los módulos de esta herramienta es Spring MVC, el cual provee grandes funcionalidades al momento de desarrollar aplicaciones web robustas. Entre sus características tenemos: División clara entre los componentes del patrón MVC. Comunicación fácil con otros frameworks como Hibernate, Struts, Tapestry, ibatis, entre otros. No limita la utilización de un único lenguaje para el diseño de las páginas web. Implementación de toda la estructura a través de interfaces. Interfaz bien definida para la capa de negocio. 3.7 Hibernate Hibernate es un motor de persistencia encargado de hacer traducciones entre los registros almacenados en la base de datos y los objetos definidos por el lenguaje de programación seleccionado [12]. En otras palabras, facilita la carga y representación de objetos desde la base de datos hacia la capa de aplicación y el almacenamiento de objetos en registros en la dirección opuesta. Éste permite desarrollar clases de persistencia siguiendo la forma orientada a objetos, incluyendo las asociaciones, herencia, polimorfismo, composición y colecciones [13].

28 16 CAPÍTULO 4 MARCO METODOLÓGICO En este capítulo se describirá la metodología RUP (Rational Unified Process) utilizada para el desarrollo de la solución planteada a la Empresa. 4.1 Metodología RUP RUP es un proceso de desarrollo de software que podría ser considerado como el de más amplia aplicación a nivel mundial para la concepción, elaboración y documentación de SI orientados a objetos. Divide el proceso de desarrollo en cuatro fases que involucran el modelado del negocio, análisis y diseño, implementación, pruebas e implantación. Dichas fases son inicio, elaboración, construcción y transición. RUP intenta capturar muchas de las prácticas más utilizadas en el mundo del desarrollo de software y presentarlas de una manera que se adapte a una gran variedad de proyectos y organizaciones. Identifica que el proceso tradicional de desarrollo en cascada puede ser ineficiente pues mantiene alejados a miembros clave en el proceso por períodos largos de tiempo además del consenso de que el riesgo es muy alto ya que difiere las pruebas e integración para el final del ciclo de desarrollo del proyecto, los cuales a esas alturas son muy costosos de corregir [14].

29 17 RUP es una aproximación iterativa al proceso de desarrollo de software, superior por un número de razones, entre ellas [14]: Toma en cuenta los cambios de requerimientos. La integración se realiza progresivamente. Los riesgos son descubiertos o tratados durante la integración. El desarrollo iterativo provee a los directores de proyecto, la facilidad de realizar cambios tácticos al producto. Facilita la reutilización de componentes. La corrección de errores a lo largo de las iteraciones da como resultado una arquitectura robusta. El proceso de desarrollo puede ser mejorado y refinado durante la duración del mismo. Acompañando a las fases, se definen 6 disciplinas principales y 3 disciplinas complementarias, las cuales van a aplicarse con intensidad variable de acuerdo a la fase e iteración en la que se encuentre el proyecto. Las disciplinas principales son: Modelado del negocio. Requisitos. Análisis y diseño. Implementación. Pruebas. Despliegue. Las disciplinas complementarias son: Gestión del cambio y configuraciones. Gestión del proyecto. Entorno.

30 18 En la siguiente figura se pueden observar las diferentes fases de la metodología RUP así como el énfasis de las disciplinas a lo largo de la ejecución de las primeras: Figura 3.- Ciclo de vida de RUP [15] Fase de inicio En esta fase de RUP, el caso del negocio, el cual incluye el contexto del mismo, factores de éxito y panorama financiero, es establecido. Para completar el caso de negocio, un modelo de casos de uso básico, un plan de proyecto, un bosquejo de la evaluación de riesgos y la descripción del proyecto requerimientos básicos, niveles de calidad, limitaciones y características destacadas son generados [16]. demandas: Después de que estos puntos son completados, se enfrenta el proyecto a las siguientes Aprobación del stakeholder en cuanto al alcance del proyecto, costo y fechas de entrega del mismo.

31 19 Provisión a los desarrolladores de un claro entendimiento de los requerimientos del proyecto. Credibilidad de los costos, estimados de calendario, prioridades, riesgo y proceso de desarrollo. Definición del ámbito del proyecto. Presentación de cualquier prototipo arquitectural desarrollado. Comprensión de los requerimientos, evidenciado por la clara representación de los casos de uso modelados. Si el proyecto no satisface estos puntos, puede ser cancelado o se puede repetir esta fase hasta que cumpla de manera satisfactoria los objetivos esperados. Como resultado de esta fase, se deben de entregar los siguientes artefactos: Documento de Visión del Proyecto: proporciona a los desarrolladores y al cliente con un punto de vista común sobre el propósito de la ejecución del proyecto. Diccionario de términos. Modelo de casos de uso del negocio. Plan de proyecto para la fase de elaboración Fase de elaboración La meta de la fase de elaboración es el establecimiento de los lineamientos arquitecturales del sistema para proveer una base sólida a la tarea de la implementación llevada a cabo en la fase de construcción [17]. En esta fase se detallan a fondo los requerimientos y el diseño arquitectural orientado a objetos. Se sostienen entrevistas con los stakeholders y sus demandas son documentadas

32 20 detalladamente. Dichos requerimientos son identificados y definidos y son convertidos en casos de uso, obteniéndose como resultando el Modelo de Casos de Uso. También se desarrolla un prototipo funcional del sistema, en el cual se presentan los casos de uso identificados como básicos para demostrar la viabilidad de la arquitectura escogida [17]. Una vez realizados estas actividades, se decide pasar a la siguiente fase o repetir la actual basándose en los siguientes puntos [17]: La arquitectura es estable. Las estimaciones hechas para la fase de construcción son factibles. Se cree que las demandas serán satisfechas con la arquitectura propuesta. Los gastos en los que se ha incurrido están dentro de los límites establecidos durante la fase de inicio. Los principales elementos de riesgo se encuentran identificados y controlados. La visión del producto es estable. Los artefactos entregables de esta fase son los siguientes: Prototipo ejecutable del sistema. Documento de Modelo de Casos de Uso con todos los actores y casos identificados. Documento de Arquitectura. Plan de proyecto para la fase de construcción. Adicionalmente, se actualizan todos los artefactos generados en la fase de inicio.

33 Fase de construcción La finalidad de esta fase dentro de la metodología RUP es definir los requerimientos restantes y completar el proceso de desarrollo del sistema basado en la arquitectura definida en la fase de elaboración [17]. Vista desde un nivel de detalle alto, esta es una fase de fabricación, donde el énfasis se centra en la administración de recursos y el control de las operaciones para permanecer dentro de los límites de costo y tiempo, manteniendo los niveles de calidad deseados. Se entiende que el enfoque del trabajo pasa de ser intelectual a constructivo, reflejándose en la elaboración de productos desplegables durante las fases de construcción y transición [18]. Dicha fase puede abarcar una o más iteraciones, realizándose una serie de pruebas al final de cada una de las mismas para detectar y corregir a tiempo fallas o comportamientos inesperados. Una vez completadas estas actividades, se decide avanzar a la fase de transición o repetir esta etapa de acuerdo a los resultados de los siguientes puntos: Se tiene un producto estable y probado, capaz de ser puesto en producción. Los gastos en los que se han incurrido están dentro de los límites planteados inicialmente. Los artefactos entregables de esta fase son: Prototipo funcional. Plan de proyecto para la fase de transición. De igual manera que en la fase de elaboración, todos los artefactos generados en esa fase son actualizados.

34 Fase de transición El objetivo de la fase de transición en la metodología RUP es poner el sistema en funcionamiento y disponible a los usuarios finales [17]. Esta fase puede abarcar, al igual que la anterior, varias iteraciones. Se realizan pruebas a fondo al sistema antes de ponerlo en producción. Los ajustes deben ser menores ya que los detalles estructurales más complejos debieron ser atendidos en las fases anteriores del proyecto. Adicionalmente, se debe de tomar en cuenta los detalles de configuración, instalación y usabilidad [17]. También dentro de esta fase, se contempla el entrenamiento de los usuarios y administradores, creación de manuales uso del sistema, realización de pruebas para determinar se satisfacen las expectativas de los usuarios finales y se revisa que el producto cumpla las exigencias de calidad establecidas en la fase de inicio. Una vez finalizadas estas actividades, se decide si esta fase debe repetirse basándose en los siguientes criterios: El cliente y los usuarios finales se encuentran satisfechos con el producto. Los costos se encuentran dentro de los límites planificados. Al concluir esta etapa, los entregables deben ser los siguientes [19]: Prototipo puesto en producción. Documentación legal. De igual manera que en las fases anteriores, todos los artefactos generados en aquellas deben ser actualizados.

35 Fases a cubrir dentro del marco de la pasantía Inicialmente dentro del Plan de Pasantía presentado, se contemplaba la ejecución de las cuatro fases planteadas dentro de la metodología RUP. Sin embargo, por motivos de disponibilidad de infraestructura por parte de la Empresa, la etapa de transición no fue llevada a cabo. Las fases de inicio, elaboración y construcción fueron completadas en su totalidad. Todas produjeron sus artefactos entregables, los cuales fueron refinados por las fases sucesivas. Como se deriva del nivel de completitud del proyecto, el cliente aprobó el desarrollo realizado, el cual se mantuvo dentro de los límites establecidos de tiempo y costos. Inicialmente la fase de transición estaba contemplada en el plan de trabajo de la pasantía pero por razones ajenas a la voluntad del pasante no se pudo ejecutar.

36 24 CAPÍTULO 5 DESARROLLO En este capítulo describiremos las actividades llevadas a cabo durante las fases de inicio, elaboración y construcción del período de pasantía. 5.1 Fase de inicio Durante la fase de inicio, se levantó la información necesaria para obtener una visión general de la Empresa, el ambiente en el que se desenvuelve, la forma en la que atienden sus asuntos internos y los requerimientos y el alcance del sistema a desarrollar. Dicha fase involucró actividades como reuniones con los interesados, análisis de las necesidades, familiarización con la estructura empresarial y conocimiento del negocio de la Empresa. Derivado de estas actividades y como objetivo paralelo, se fue creando un primer boceto de las funcionalidades requeridas en el sistema a ser desarrollado. Cada una de estas actividades dejaba una gran cantidad de información valiosa para el equipo desarrollador, ya que en ella se encontraban representados los requerimientos, necesidades a satisfacer y expectativas que tenían los Colaboradores de la Empresa para con el producto final.

37 Creación de plan de proyecto Con la finalidad de tener un control sobre el progreso del proyecto, se fijó un cronograma donde se establecieron las actividades a ejecutar durante las diferentes fases del desarrollo, así como la duración de las mismas y los artefactos entregables en ellas. Este cronograma es de una importancia bastante alta, ya que permite identificar cualquier desvío del proceso de creación para tomar los correctivos necesarios y solventar dichas anomalías. Las actividades y entregables contemplados dentro de la fase actual aparecen señalados en la siguiente tabla: Iteraciones Duración Actividades Una. Dos semanas. Reuniones introductorias. Reuniones con stakeholders. Validación de los artefactos generados. Entregables Documento de Visión del Sistema CGK. Matriz de Riesgos. Documento de Especificación de Requerimientos de Software. Documento de Casos de Uso. Tabla 2.- Plan de proyecto para la fase de inicio.

38 Levantamiento de información Una de las tareas elementales en la primera fase de cualquier proyecto, cualquiera sea su índole, es el levantamiento de información. Con esta tarea se obtuvo una visión más concreta de los objetivos a cumplir con el desarrollo y un conocimiento en profundidad de la Empresa. Esta actividad fue llevada a cabo a través de reuniones con los stakeholders, quienes plantearon sus demandas e ideas, las cuales se centraron en accesibilidad, disponibilidad de la información en todo momento y facilidad de uso. Un punto que también fue integrado a dichas solicitudes, fue la inclusión de los CC al proceso de evaluación, tarea que anteriormente estaba delegada en su totalidad al departamento administrativo, lo cual ocasionaba atrasos y generaba desinformación generalizada hacia los demás componentes de la Empresa. Esta solicitud implicó un cambio dentro de las políticas establecidas, ya que se agregó un nuevo actor con responsabilidades importantes, las cuales fueron definidas por los entes correspondientes y transmitidas al equipo de desarrollo para lograr plasmarlas claramente en el sistema en cuestión. La tarea de levantamiento de información estuvo apoyada por la provisión de un bosquejo del Documento de Visión desarrollado por la casa matriz de la Empresa en Brasil (ver apéndice A) en base a las necesidades y los requerimientos de la misma. Uno de los puntos críticos de esta etapa fue adaptar el contenido de dicho documento a las necesidades de la filial local, ya que éste expresaba la idea central del sistema a desarrollar. Dicha adaptación fue realizada lográndose la depuración del mismo, ya que presentaba requerimientos no factibles de realización dentro del entorno, incluía procedimientos propios de una empresa con un alto número de empleados y de manera más importante, no incluía los requerimientos ni atendía las necesidades planteados por los responsables locales. Como resultado de las reuniones y el soporte brindado por el Documento de Visión brasilero, se genero el Documento de Visión del Sistema CGK (ver apéndice B).

39 Requerimientos Una vez sostenidas las reuniones con los stakeholders y entendido el entorno de la empresa, se procedió a la identificación de los requerimientos tanto funcionales como no funcionales del sistema. Dichos requerimientos fueron plasmados en el Documento de Especificación de Requerimientos de Software, el cual se encuentra en el apéndice C de éste libro. A continuación presentaremos de forma resumida los requerimientos más destacados del proyecto: Requerimientos funcionales Administración de reportes de gastos. Administración de lotes de gasto. Evaluación de lotes de gasto. Reembolso de lotes de gasto. Administración de CC. Administración de UR. Administración de Colaboradores. Requerimientos no funcionales Desarrollado bajo los estándares de calidad CMMi. Utilización del framework ASP.NET 2.0. Desarrollo bajo el lenguaje C#. Manejador de base de datos SQL Server Tabla 3.- Principales requerimientos del Sistema CGK.

40 Objetivo del Sistema El objetivo del Sistema CGK es proveer un sistema web que facilite el proceso de ingreso, evaluación y reembolso de los reportes de gasto de los Colaboradores de la Empresa. Una vez los Colaboradores son aceptados dentro del Sistema CGK, los mismos tienen la posibilidad de ingresar registros de gasto. Dichos registros, al momento de ser añadidos, deben ser identificados con alguno de los renglones de la clasificación de gastos denominados tipos de gasto (TG), los cuales poseen ciertas características como descripción de las expensas que abarcan así como los límites máximos que pueden ser aprobados de manera automática. Adicionalmente, pueden ser asociados con alguno de los Proyectos registrados por los Coordinadores. Ingresados los registros de gasto, estos son agrupados en lotes de registros de gastos, los cuales son enviados a los Coordinadores de sus respectivos CC para su evaluación. Al ser recibidos los lotes por los Coordinadores, éstos deben proceder a evaluarlos de acuerdo a las políticas de la Empresa y en situaciones excepcionales, a su criterio. De esto se desprende que un lote de gastos puede ser aprobado total o parcialmente o puede ser rechazado. Dicha evaluación puede ser hecha sin examinar su contenido, aprobando o rechazando en su totalidad los montos solicitados, o evaluando individualmente los registros de gastos contenidos en dicho lote, pudiendo ser aprobado el monto solicitado en estos registros de manera total, hasta el monto establecido en el límite del tipo de gasto o hasta un monto determinado por el Coordinador. De igual manera, el registro puede ser rechazado. Realizada la evaluación, el lote puede ser enviado al Administrador de la Empresa para su reembolso o devuelto al Colaborador solicitante para realizar la revisión correspondiente. En este último caso, el Colaborador puede volver a enviar una última vez el lote a evaluación. Al ser recibido un lote pendiente por reembolso por parte del Administrador, este procede a cotejar los montos de los registros aprobados con los comprobantes físicos facturas de consumo previamente entregados por parte del solicitante. En este punto, nuevamente un

41 29 lote puede ser aprobado y reembolsado o rechazado por inconsistencias entre los montos aprobados y los reflejados en los comprobantes. En caso de ser aprobado para reembolso, el Administrador notifica al Colaborador que su solicitud ha sido reembolsada una vez el pago ha sido realizado. De lo contrario, el lote es devuelto al solicitante quien debe reformular su solicitud y entregar los comprobantes correspondientes. Adicionalmente, se requiere de la presencia de un Líder, el cual determine la admisión o rechazo de usuarios dentro del Sistema, administre CC, UR, TG e impuestos. También se requiere que los Coordinadores de CC sean capaces de administrar Proyectos. Una especificación más detallada de la visión del Sistema se encuentra en el Documento de Visión del Sistema CGK en el apéndice B de este libro Flujo de trabajo actual Actualmente la Empresa realiza el proceso de ingreso, evaluación y reembolso de las solicitudes siguiendo una serie de pasos conocidos por todos los Colaboradores de la misma. Inicialmente los Colaboradores llenan una hoja de Microsoft Excel otorgada por la Empresa en la cual ingresan los detalles de sus gastos: tipo de gasto, concepto, fecha, y monto. Seguidamente, esta hoja de cálculo es enviada al CC de Administración junto con las facturas correspondientes a los registros contenidos en la misma. Una vez en manos del CC, el Administrador procede a realizar el cotejo de los montos solicitados con los montos indicados en las facturas. Al finalizar esta actividad, el mismo Administrador procede a realizar la evaluación de los registros, consistiendo en decidir si será reembolsado o no. En caso de ser aprobado, se procede a determinar el monto a reembolsar, el cual puede ser una parte o la totalidad del monto solicitado, tomando en cuenta el límite establecido para el tipo de gasto del registro. En caso de ser rechazado, se le notifica al Colaborador la decisión tomada por el Administrador.

42 30 Una vez concluida la evaluación, y totalizado el monto a reembolsar, el Administrador realiza a través de una transferencia bancaria el reembolso. Al haberse realizado el reintegro de los fondos, el Administrador le notifica al Colaborador la finalización de su solicitud de reembolso, indicándole el monto reembolsado, el número de operación, la cuenta bancaria a la cual se realizó la transferencia y la fecha de la misma. De igual manera, el Administrador incluye los mismos datos dentro de sus registros contables. El principal problema de este flujo de trabajo es que las evaluaciones son llevadas a cabo por el personal administrativo, el cual no está al tanto de las actividades realizadas por los solicitantes lo cual puede derivar en una evaluación errónea Flujo de trabajo propuesto Una de las intenciones del Sistema CGK es implementar un nuevo modelo del proceso de solicitud, evaluación y reembolso de gastos dentro de la Empresa. De la misma manera que en el flujo de trabajo actual, los Colaboradores deben introducir sus solicitudes indicando tipo de gasto, concepto, fecha y monto solicitado. Seguidamente, estas solicitudes son enviadas al Coordinador del CC al cual pertenece el Colaborador para su evaluación, constituyendo esto dos modificaciones sobre el flujo de trabajo actual, la evaluación es realizada antes que el cotejo de las facturas y es realizada por el Coordinador y no por el Administrador. La actividad de evaluación es llevada a cabo de la misma manera que en el flujo de trabajo actual, determinando si el registro debe ser reembolsado o no. En caso de ser aprobado para reembolso, es el Coordinador quien decide el monto aprobado, pudiendo ser la totalidad de la solicitud o un monto parcial, tomando en cuenta los limites establecido para dicho tipo de gasto. En caso de ser rechazado, la solicitud es enviada nuevamente al Colaborador afectado.

43 31 Una vez concluida la etapa de evaluación, las solicitudes son enviadas al CC de Administración donde se realiza el cotejo de las facturas con los montos solicitados. Una vez finalizada esta actividad, el flujo de trabajo continúa de la misma manera en la que es llevado a cabo en el flujo de trabajo actual, se realiza una transferencia bancaria, el Colaborador es notificado del resultado de su solicitud y se realizan asientos contables por parte de Administrador. Este flujo de trabajo permitirá la realización de evaluaciones acordes a las actividades llevadas a cabo por los solicitantes, ya que son los Coordinadores de los CC, los encargados de asignar tareas a los Colaboradores, los responsables de realizar la evaluación de las solicitudes, dejando sobre el CC de Administración únicamente las tareas relacionadas al cotejo, reembolso y notificación de las mismas Casos de uso Ya establecido el objetivo del Sistema, se definieron los usuarios del sistema. Dicha clasificación se muestra en la siguiente tabla:

44 32 Colaborador Coordinador Administrador Líder Personal de la Empresa que ingresará sus solicitudes de reembolso de gastos. Deben ser admitidos dentro del Sistema. Jefe de CC encargado de realizar las evaluaciones de los lotes de gasto. Administración de Proyectos. Encargado del departamento administrativo de la Empresa. Cotejará los montos aprobados con los reflejados en los comprobantes físicos y de ser requerido, notificará los reembolsos. Responsable de la admisión de usuarios, administración de CC, UR, TG e impuestos. Tabla 4.- Usuarios y sus funciones dentro del Sistema CGK. Con un alto nivel de detalle, los Casos de Uso y la jerarquía de usuarios se representan de la siguiente manera:

45 33 Figura 4.- Diagrama de Casos de Uso del Sistema CGK. Estos Casos de Uso se encuentran detallados a fondo en el apéndice D de este libro Riesgos del Sistema Durante el desarrollo de un proyecto de cualquier índole, se hace necesaria la identificación de los posibles problemas que se pueden presentar durante la ejecución del mismo. El Sistema CGK no escapa a esta necesidad y para poder controlar estas situaciones y tener definidas las medidas a tomar en caso de presentarse estas, se creó una Matriz de Riesgo donde se reflejaron los descriptores, consecuencias, nivel de importancia, probabilidad de ocurrencia y las medidas a tomar.

46 34 A continuación, la Matriz de Riesgo para la fase de inicio del Sistema CGK: Descriptor Consecuencia Importancia Probabilidad Medidas a tomar Dificultad para sostener reuniones con los stakeholders. Requerimientos poco claros. Demandas e ideas de los interesados no conocidas. Retraso en la toma de decisiones. Desarrollo basado en una idea no comprendida derivará en pérdida de tiempo e inconformismo por parte del cliente. 3 50% Establecimiento de las reuniones con suficiente tiempo de antelación. Realización de las reuniones de manera impersonal. 3 30% Revisión a fondo de los Casos de Uso planteados en el Documento de Casos de Uso. Replanteamiento del alcance del Sistema. Tabla 5.- Matriz de Riesgo para la fase de inicio. 5.2 Fase de elaboración El propósito principal de la fase de elaboración es el de colocar los cimientos para la implementación satisfactoria de los requerimientos obtenidos en la fase de inicio durante la fase de construcción. Durante la ejecución de la misma, se mantuvieron reuniones con las partes interesadas, se completaron los documentos de Casos de Uso y Requerimientos y se generaron nuevos artefactos como el Documento de Arquitectura del Software y el Documento de Base de

47 35 Datos. De igual manera, se actualizaron algunos de los artefactos generados en la fase anterior para que tuvieran coherencia con los nuevos objetivos planteados Actualización del plan de proyecto Como se indicó en la fase de inicio, se creó un cronograma donde se establecieron las actividades y entregables del proyecto. A continuación, la tabla de actividades y entregables de la fase de elaboración: Iteraciones Duración Actividades Dos. Dos semanas. Reuniones con stakeholders. Selección y estudio de las herramientas seleccionadas para el desarrollo. Definición de la arquitectura del Sistema. Actualización de los artefactos generados en la fase de inicio. Entregables Documento de Arquitectura. Documento de Base de Datos. Tabla 6.- Plan de proyecto para la fase de elaboración.

48 Definición de la arquitectura Como se dijo en la introducción a la fase de elaboración, el objetivo principal es el de determinar la arquitectura del sistema a desarrollar. En términos de desarrollo de software, la arquitectura de un sistema se refiere a las estructuras del mismo, lo cual abarca componentes programados, las propiedades externas visibles de estos y las relaciones entre ellos [20]. La arquitectura seleccionada seguirá el modelo implementado por Philippe Krutchen [21] llamado vistas, el cual describe la arquitectura mediante el uso de cinco vistas concurrentes. Cada una de estas vistas son: Vista lógica: permite visualizar el dominio del problema. Vista de procesos: describe los aspectos de sincronización y concurrencia dentro del diseño planteado. Vista de despliegue: describe la distribución del software en el hardware. Vista de implementación: describe la asignación de las tareas de la vista de procesos a los nodos físicos. Vista de casos de uso: es la guía para determinar la funcionalidad del sistema como es percibida desde el exterior. A continuación, una figura representativa de dicho modelo: Vista Lógica Vista de Implementación Casos de Uso Vista de Proceso Vista de Despliegue Figura 5.- Representación del modelo de 4+1 vistas [21].