TESIS PUCP Esta obra ha sido publicada bajo la licencia Creative Commons Reconocimiento-No comercial-Compartir bajo la misma licencia 2.5 Perú. Para ver una copia de dicha licencia, visite http://creativecommons.org/licenses/by-nc-sa/2.5/pe/ PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA SISTEMA ADMINISTRADOR DE REQUERIMIENTOS Y PLANIFICADOR DE TAREAS Tesis para optar por el Titulo de Ingeniero Informático que presenta los bachilleres: Luzmila Grillo Oshiro Gina La Rosa Macedo ASESOR: Jorge Berrocal Lima, 29 de enero de 2009 1 Resumen Según un informe de Gartner Group, cerca del 46% del total de proyectos tienen grandes desfases en tiempo de finalización y adecuación funcional de las necesidades que se pretenden cubrir. Además el 28% del total de proyectos se abandonaban tras haber gastado un cierto tiempo y dinero y además sin ningún retorno de la inversión. [Gartner Symposium ItxPo 2004] El presente trabajo de tesis fue concebido con el propósito de ordenar y sistematizar el flujo de los requerimientos que los usuarios realizan, administrando la forma en que sus necesidades llegan al área de sistemas. Por ello, se ha realizado una investigación para estructurar una base sólida para la elaboración de un producto de software que colabore en la gestión de requerimientos de la empresa en donde se realizó el proyecto. El sistema implementado permite administrar y controlar la atención de requerimientos desde la recepción de la solicitud hasta la resolución del problema, buscando reducir sustancialmente los tiempos de espera en atención de requerimientos. A lo largo del presente documento se podrá apreciar la labor realizada para implementar una herramienta de administración de requerimientos y planificador de tareas que permita registrar, hacer seguimiento de las solicitudes y de su evolución a través de los distintos estados que pueden asumir; así como también definir las tareas necesarias para atender dichos requerimientos y registrar el trabajo real invertido por los recursos asignados para la culminación de las tareas. En el primer capítulo se presenta el marco teórico donde se detallan los conceptos relacionados a los requerimientos y a la ingeniería de requerimientos. En el segundo capítulo se presenta el análisis del problema en la administración de requerimientos y las principales necesidades de los usuarios, asimismo la evaluación de algunas herramientas existentes en el mercado para la gestión de requerimientos y planificación de tareas. 2 En el tercer capítulo se presenta el análisis realizado para la elaboración del sistema. En el cuarto capítulo se presenta el diseño y la implementación realizada. En el análisis y diseño se utilizó UML como estándar para la construcción de los artefactos del software. En el quinto capítulo se presenta las pruebas realizadas para la construcción de este sistema web. Finalmente en el sexto capítulo se presenta las conclusiones y el trabajo para las posibles ampliaciones. 3 Índice General Introducción .................................................................................................................................6 1. Marco Teórico ...................................................................................................................7 1.1 Requerimientos ................................................................................................................................ 7 1.2 Tipos de Requerimiento ................................................................................................................... 8 1.3 Características de los Requerimientos.............................................................................................. 8 1.4 Dificultad en la Definición de los Requerimientos .......................................................................... 9 1.5 Ingeniería de Requerimientos........................................................................................................... 9 1.6 Beneficios de la Ingeniería de Requerimientos .............................................................................. 10 1.7 Consideraciones durante la Ingeniería de Requerimientos............................................................. 11 1.8 Actividades de la Ingeniería de Requerimientos ............................................................................ 11 2. Definición del Problema.................................................................................................13 2.1 Definición del Problema................................................................................................................. 13 2.2 Requisitos....................................................................................................................................... 15 2.2.1 Módulo de Requerimiento ............................................................................................. 15 2.2.2 Módulo de Tarea............................................................................................................ 15 2.2.3 Módulo de Administración ............................................................................................ 16 2.3 Evaluación de Herramientas existentes .......................................................................................... 18 2.4 Características de las Herramientas Evaluadas .............................................................................. 18 3. Análisis ............................................................................................................................21 3.1 Flujo del Sistema............................................................................................................................ 21 3.2 Características de la Herramienta Propuesta .................................................................................. 25 3.3 Especificación de Actores .............................................................................................................. 25 3.4 Paquetes del Sistema ...................................................................................................................... 27 3.4.1 Paquete de Requerimiento ............................................................................................. 28 3.4.2 Paquete de Tarea............................................................................................................ 28 3.4.3 Paquete de Administración ............................................................................................ 29 3.5 Casos de Uso .................................................................................................................................. 29 3.5.1 Paquete Requerimiento.................................................................................................. 29 3.5.2 Paquete Tarea ................................................................................................................ 37 3.5.3 Paquete Administración................................................................................................. 40 3.6 Diagrama de Clases de Análisis ..................................................................................................... 44 3.6.1 Paquete Requerimiento.................................................................................................. 44 3.6.2 Paquete Tarea ................................................................................................................ 48 3.6.3 Paquete Administración................................................................................................. 50 3.7 Diagrama de Estados...................................................................................................................... 51 3.7.1 Requerimiento ............................................................................................................... 52 3.7.2 Tarea.............................................................................................................................. 54 3.7.3 Documento .................................................................................................................... 55 4. Diseño ..............................................................................................................................56 4.1 Arquitectura del Sistema ................................................................................................................ 56 4.2 Procesos.......................................................................................................................................... 59 4.2.1 Paquete de Requerimiento ............................................................................................. 59 4.2.2 Paquete de Tarea............................................................................................................ 71 4.2.3 Paquete de Administración ............................................................................................ 78 4.3 Diagrama Entidad Relación............................................................................................................ 82 5. Construcción...................................................................................................................84 5.1 Lenguaje de Programación............................................................................................................. 84 5.2 Herramientas Utilizadas ................................................................................................................. 84 5.3 Entorno de Ejecución ..................................................................................................................... 85 5.4 Plan de Pruebas .............................................................................................................................. 85 5.5 Capacitación................................................................................................................................... 86 5.6 Migración ....................................................................................................................................... 88 6. Conclusiones, Recomendaciones y Ampliaciones.....................................................91 6.1 Conclusiones .................................................................................................................................. 91 6.2 Recomendaciones........................................................................................................................... 92 6.3 Ampliaciones.................................................................................................................................. 92 7. Bibliografía ......................................................................................................................93 4 Índice de Ilustraciones Figura 1.1: Actividades de la Ingeniería de Requerimientos (Traducido de Sommerville) ................. 12 Figura 3.1: Flujo de actividades del sistema ........................................................................................ 24 Figura 3.2 : Diagrama de actores del sistema....................................................................................... 27 Figura 3.3 : Diagrama C.U – Sub Paquete Solicitud ............................................................................ 31 Figura 3.4 : Diagrama C.U – Sub Paquete Aprobación........................................................................ 33 Figura 3.5 : Diagrama C.U – Sub Paquete Documento y Pruebas ....................................................... 34 Figura 3.6 : Diagrama C.U – Sub Paquete Planificación .................................................................... 36 Figura 3.7 : Diagrama C.U –Paquete Tarea ......................................................................................... 38 Figura 3.8 : Diagrama C.U –Paquete Administración.......................................................................... 41 Figura 3.9 : Diagrama Clases – Sub Paquete Solicitud ........................................................................ 45 Figura 3.10 : Diagrama Clases – Sub Paquete Aprobación.................................................................. 46 Figura 3.11 : Diagrama Clases – Sub Paquete Documento y Pruebas ................................................. 47 Figura 3.12 : Diagrama Clases – Sub Paquete Planificación................................................................ 48 Figura 3.13 : Diagrama Clases –Paquete Tarea.................................................................................... 49 Figura 3.14 : Diagrama Clases –Paquete Administración.................................................................... 51 Figura 3.15 : Diagrama de Estado-Requerimiento ............................................................................... 53 Figura 3.16 : Diagrama de Estado-Tarea.............................................................................................. 54 Figura 3.17 : Diagrama de Estado-Documento .................................................................................... 55 Figura 4.1 : Arquitectura Web.............................................................................................................. 57 Figura 4.2 : Arquitectura MVC ............................................................................................................ 58 Figura 4.3 : Diagrama Secuencia – Registrar Requerimiento .............................................................. 61 Figura 4.4 : Interfaz Gráfica – Registrar Requerimiento...................................................................... 61 Figura 4.5 : Diagrama Secuencia – Aprobar Requerimiento................................................................ 63 Figura 4.6 : Interfaz Gráfica – Aprobar Requerimiento ....................................................................... 63 Figura 4.7 :Diagrama Secuencia – Aceptar Requerimiento ................................................................. 65 Figura 4.8 : Interfaz Gráfica – Aceptar Requerimiento........................................................................ 65 Figura 4.9 : Diagrama Secuencia – Asignar Recurso........................................................................... 67 Figura 4.10 : Interfaz Gráfica – Asignar Recurso ................................................................................ 68 Figura 4.11 : Diagrama de Secuencia - Mantener Prueba ................................................................... 69 Figura 4.12 : Interfaz Gráfica - Mantener Prueba ............................................................................... 70 Figura 4.13 : Diagrama de Secuencia - Mantener Solución ................................................................ 72 Figura 4.14 : Interfaz Gráfica - Mantener Solución ............................................................................ 73 Figura 4.15 : Diagrama Secuencia - Registrar Horas Reales Trabajadas ............................................ 75 Figura 4.16 : Interfaz Gráfica - Registrar Horas Reales Trabajadas.................................................... 75 Figura 4.17 : Diagrama de Secuencia - Consultar Disponibilidad ...................................................... 77 Figura 4.18 : Interfaz Gráfica - Consultar Disponibilidad................................................................... 77 Figura 4.19 : Diagrama Secuencia - Mantener Plantilla...................................................................... 79 Figura 4.20 : Interfaz Gráfica - Mantener Plantilla ............................................................................. 80 Figura 4.21 : Diagrama Secuencia - Mantener Flujo........................................................................... 81 Figura 4.22 : Interfaz Gráfica - Mantener Flujo .................................................................................. 82 Figura 5.1 : Flujo Capacitación ............................................................................................................ 86 5 Índice de Cuadros Cuadro 2.1 : Lista de Requisitos – Módulo de Requerimientos ........................................................... 16 Cuadro 2.2 : Lista de Requisitos : Módulo de Tarea............................................................................ 17 Cuadro 2.3 : Lista de Requisitos – Módulo de Administración ........................................................... 18 Cuadro 2.4 : Comparación características entre herramientas evaluadas ............................................. 20 Cuadro 3.1: Casos de Uso – Sub Paquete Solicitud ............................................................................. 30 Cuadro 3.2 : Casos de Uso vs. Requerimientos – Sub Paquete Solicitud............................................. 31 Cuadro 3.3 : Casos de Uso – Sub Paquete Aprobación........................................................................ 32 Cuadro 3.4 : Casos de Uso vs. Requerimientos – Sub Paquete Aprobación ........................................ 33 Cuadro 3.5 : Casos de Uso – Sub Paquete Documento y Pruebas ....................................................... 34 Cuadro 3.6 : Casos de Uso vs. Requerimientos – Sub Paquete Documento y Pruebas........................ 35 Cuadro 3.7 : Casos de Uso – Sub Paquete Planificación...................................................................... 35 Cuadro 3.8 : Casos de Uso vs. Requerimientos – Sub Paquete Planificación...................................... 36 Cuadro 3.9 : Casos de Uso -Paquete Tarea .......................................................................................... 37 Cuadro 3.10 : Casos de Uso vs. Requerimientos - Paquete Tarea........................................................ 39 Cuadro 3.11 : Casos de Uso - Paquete Administración........................................................................ 40 Cuadro 3.12 : Casos de Uso vs. Requerimiento-Paquete Administración............................................ 42 Cuadro 3.13 : Clases- Sub Paquete Solicitud ....................................................................................... 45 Cuadro 3.14 : Clases- Sub Paquete Aprobación................................................................................... 46 Cuadro 3.15 : Clases- Sub Paquete Documento y Pruebas .................................................................. 47 Cuadro 3.16 : Clases- Sub Paquete Planificación ................................................................................ 48 Cuadro 3.17 : Clases - Paquete Tarea................................................................................................... 48 Cuadro 3.18 : Clases - Paquete Administración................................................................................... 50 Cuadro 5.1 : Personal Acceso Lima ..................................................................................................... 87 Cuadro 5.2 : Personal Acceso Pisco.................................................................................................... 87 Cuadro 5.3 : Personal Acceso Arequipa............................................................................................... 87 Cuadro 5.4 : Datos para Migración ...................................................................................................... 89 6 Introducción Según Standish Group, varias de las causas de fracaso en el desarrollo de software se relacionan con los procesos de Modelamiento de Requerimientos; así cerca del 25.5% de las causas se debe a requerimientos incompletos y a la mala comunicación entre usuarios y desarrolladores. [Standish 1998]. Por ellos es necesario una herramienta que permita llevar el control de los requerimientos, es decir, una en que los usuarios puedan ingresar sus pedidos en base a plantillas y que éstos sean validados a través de un mecanismo de aprobación, asimismo, los usuarios puedan estar informados sobre la evolución de su solución. Además, se necesita llevar el control del tiempo empleado en la solución de los diversos requerimientos. El presente proyecto de tesis abarca el análisis, diseño e implementación de un producto de software que colabore con la gestión de requerimientos para el mantenimiento de sistemas y planificación de las tareas involucradas en la solución, realizadas en el área de sistemas de una empresa de gran envergadura. Este sistema tiene el propósito de ordenar, controlar y sistematizar el flujo de los pedidos que los usuarios solicitan, realizando un seguimiento de los mismos y administrando las tareas que surgen de dichos requerimientos de tal forma que el producto responda a las necesidades de los usuarios. 7 1. Marco Teórico En el presente capítulo se presentará el marco teórico de los Requerimientos e Ingeniería de Requerimientos. Se mostrarán los conceptos de requerimientos, tipos, características y dificultades presentes en la definición de los mismos; definición de ingeniería de requerimientos, beneficios, actividades y consideraciones a tener en cuenta durante la ingeniería de requerimiento. 1.1 Requerimientos Entre las principales definiciones de requerimientos tenemos: • Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. [IEEE-Std] • Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal. [IEEE-Std] • Una representación documentada de una condición o capacidad. [IEEE-Std] 8 • Un requerimiento es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste”. [Sommerville] 1.2 Tipos de Requerimiento Entre los tipos de requerimientos podemos destacar los siguientes [Sommerville]: • Los requerimientos asociados a la situación de demanda y atención de un producto. • Los requerimientos basados en función del usuario final, los cuales se fundamentan en los servicios que debe ofrecer el producto que necesita. • Los requerimientos del sistema de producción, los cuales están basados en la forma en que se vuelven una especificación viable, cumpliendo con las siguientes etapas: factibilidad, análisis y especificación. Otra clasificación esta basada en requerimientos funcionales y no funcionales. [Intersedes] • Los requerimientos funcionales definen las funciones del sistema, las cuales transforman las entradas en salidas. • Los requerimientos no funcionales son las características que de una u otra forma limitan el sistema, algunos de ellos son: el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad y estándares. 1.3 Características de los Requerimientos Las características están referidas a las propiedades principales del requerimiento [Intersedes]. Las principales características de los requerimientos se muestran a continuación: • Necesario: Un requerimiento es necesario si su omisión provoca una deficiencia en el sistema a construir y no pueden ser reemplazados por otras capacidades del producto o del proceso. • Conciso: Un requerimiento es conciso si es fácil de leer y entender. Su redacción es simple y clara. 9 • Completo: Un requerimiento está completo si no necesita ampliar detalles en su redacción, y si proporciona la información suficiente para su comprensión. • No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola interpretación. • Verificable: Un requerimiento es verificable cuando puede ser cuantificado a través de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas. 1.4 Dificultad en la Definición de los Requerimientos Algunas de las dificultades que presentan los requerimientos se pueden observar a continuación [Intersedes]: • Los requerimientos vienen de muchas fuentes. • Hay gran variedad en los tipos de requerimientos. • No son iguales. Algunos son más difíciles, más riesgosos, importantes o toman mas tiempo que otros. • Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso. • Un requerimiento puede cambiar a lo largo de su ciclo de vida. Debido a la ausencia de requerimiento se pueden presentar problemas durante el desarrollo de un sistema. Estos problemas son: • No se entienden los problemas del usuario. • No se documentan las necesidades del usuario. • Falta de acuerdos entre el desarrollador y el usuario. • No se controlan los cambios del requerimiento. • Falta definición y delimitación de responsabilidades de las partes involucradas. 1.5 Ingeniería de Requerimientos Existen muchas definiciones de Ingeniería de requerimiento, algunas de ellas son: • “Ingeniería de Requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes, ya sean hablados o escritos, a especificaciones precisas, no ambiguas, 10 consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones". [STARTS Guide 1987] • “Ingeniería de Requerimientos es la DISCIPLINA para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las FUNCIONES que realizará el sistema”. [B. Boehm. 1979] • "Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimientos". [Leite 1987] • "Ingeniería de requerimientos es un enfoque sistémico para recolectar, organizar y documentar los requerimientos del sistema; es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos, entre los clientes y el equipo del proyecto" [Rational Software] En resumen, la Ingeniería de Requerimientos cumple un papel primordial en el proceso de producción del software, debido a que enfoca un área fundamental: Definir lo que se desea producir. Por tal motivo, se puede definir la Ingeniería de Requerimiento como el proceso o los pasos a seguir para gestionar los requerimientos y expresarlos de una manera clara y consistente, los cuales se verán reflejados en el comportamiento del sistema [TIC]. 1.6 Beneficios de la Ingeniería de Requerimientos Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son: [UTFSM] • Ayuda al cliente a considerar sus requerimientos cuidadosamente, debido a que son parte del desarrollo durante el proyecto. • Gestiona las necesidades del proyecto: Cada actividad de la IR consiste en una serie de pasos organizados, definiendo controles que serán necesarios; tales como estimación de costos, tiempo y recursos necesarios. 11 • Hace cumplir las expectativas de funcionalidad, facilidad de uso, confiabilidad y desempeño. • Facilita el consenso entre clientes y desarrolladores. 1.7 Consideraciones durante la Ingeniería de Requerimientos Durante la Ingeniería de Requerimientos se debe tener en cuenta las siguientes consideraciones [Intersedes]: • Objetivos del negocio: Aunque los objetivos del negocio están definidos frecuentemente en términos generales, son usados para descomponer el trabajo en tareas específicas. • Punto de vista de los clientes: Los sistemas tienen diferentes tipos de clientes, siendo que cada grupo de clientes tiene diferentes necesidades, requerimientos y grados de importancia para ellos. Por otro lado, pocas veces tenemos que los clientes son los mismos usuarios; trayendo como consecuencia que soliciten procesos que causan conflictos con los solicitados por el usuario. • Evolución e Integración del sistema: En la práctica, los proyectos se derivan de sistemas ya existentes. Por lo tanto, los analistas de requerimientos deben comprender esos sistemas que son una integración de componentes de varios proveedores. • Documentación de Requerimientos: Los documentos de ingeniería de requerimientos son extensos, contienen detalles que pueden tener efectos en el sistema. 1.8 Actividades de la Ingeniería de Requerimientos La Ingeniería de requerimientos es un proceso que comprende todas las actividades para crear y mantener los requerimientos de un sistema. Comprende cuatro actividades de alto nivel, las que se muestra en la Figura 1.1. [Sommerville]. Dichas actividades son: • Estudio de Factibilidad: En que grado contribuye el sistema al cumplimiento de los objetivos de la organización. Si pueden satisfacerse las necesidades planteadas con la tecnología de hardware y software existente. Si desde el punto de vista comercial, 12 el desarrollo del sistema es rentable y si puede desarrollarse dentro del presupuesto previsto. • Obtención y análisis de requisitos: Se debe realizar un análisis previo de los requerimientos debido a que los solicitantes a menudo sólo conocen lo que desean de una manera muy general y los expresan en sus propios términos. El análisis de los requerimientos ayuda al analista a entender el sistema. • Especificación de Requisitos: Descripción detallada y precisa de los requerimientos del sistema. Debe servir de base para la elaboración de un contrato entre el cliente y el equipo de desarrollo. • Validación de Requisitos: Busca descubrir los errores en los requerimientos para evitar costos excesivos, antes del desarrollo o después de la implantación. Tiene como misión demostrar que la definición de requisitos define el sistema que quiere el usuario. El prototipado es una técnica muy útil para validar requisitos. Figura 1.1: Actividades de la Ingeniería de Requerimientos (Traducido de Sommerville) Usuario y Sistema de Requisitos Especificación de Requisitos Modelo de Sistemas Obtención y Análisis de Requisitos Informe de Factibilidad Estudio de Factibilidad Validación de Requisitos Documento de Requisitos 13 2. Definición del Problema En este capítulo se presenta la definición del problema, se explican las principales razones por las que es necesario contar con una Herramienta de Administración de Requerimientos y Planificador de Tareas en la empresa. Además se muestra algunas herramientas comerciales ofrecidas por proveedores de soluciones informáticas existentes en el mercado para la gestión de requerimientos; detallando las características comunes implementadas en las herramientas evaluadas y las características propias de cada una de éstas. 2.1 Definición del Problema El crecimiento económico de los últimos años ha generado la expansión de muchas empresas peruanas, en la actualidad están creciendo en el orden del 30% a 50% anual [Gerens]. Este crecimiento origina un incremento de sus 14 requerimientos informáticos, que soportan las mejoras realizadas en sus plantas y servicios administrativos. Por ello, en la actualidad, se vuelve fundamental poder gestionar de manera adecuada los requerimientos de software y hardware ya que la atención de estos pueden ser cruciales para ayudar a mejorar los procesos y servicios que brindan las áreas de la compañía a sus clientes externos e internos. El caso de estudio se realizó en una empresa del sector industrial, esta cuenta con tres sedes ubicadas en tres distintos departamentos del Perú. La sede principal cuenta con mayor número de empleados administrativos, los trabajadores de las otras dos sedes, en su mayoría, son obreros debido a que en ellas se encuentran las plantas de producción. La empresa presenta problemas en la atención y solución de los requerimientos debido a que la solicitud de estos se realiza a través de varios medios como: correo electrónico, llamada telefónica y personalmente. En el primer caso, cualquier empleado envía su pedido al área de sistemas, sin ningún consenso o aprobación previa en su área, con especificaciones incompletas; lo que ocasiona una lista larga de mensajes de requerimientos que no se van a atender porque va en contra de los objetivos de la empresa o simplemente porque su solución no compete al área de sistemas. En el caso de llamadas telefónicas, muchas veces al término de la solución el usuario que realizó el pedido no está conforme y manifiesta que no es lo que solicitó, invirtiéndose tiempo en realizar las modificaciones para que el producto sea acorde a “lo que el usuario solicitó”, eso evidencia la falta de documentación que le sirve al área de sistemas para sustentar que su producto cubre lo que inicialmente el usuario solicitó vía llamada telefónica. Según entrevistas realizadas al personal de la empresa se encontró que entre las causas que impiden la fluencia en la atención de los requerimientos de la empresa podemos destacar que estos son presentados de manera no formal, por lo que no se lleva un control adecuado de los recursos del área de sistemas destinado a desarrollar la solución de los requerimientos ni realizar el seguimiento de los mismos, lo que conlleva a la insatisfacción de los clientes internos; todo esto sumado a que no se cuenta con las estadísticas necesarias 15 de los requerimientos para sustentar la necesidad de incrementar los recursos de dicha área. A todo esto se debe añadir que las dificultades en la atención de requerimientos en la empresa consisten en implementar lo que realmente resuelve las necesidades del usuario y que los principales problemas para el desarrollo de las tareas son los requerimientos poco claros, que cambian a lo largo del desarrollo de la solución y la falta de participación del usuario. Por ello se ve la necesidad de desarrollar una herramienta que permita al personal de la empresa registrar detalladamente sus requerimientos, que estos puedan atravesar un flujo de aprobaciones antes de llegar al área de sistemas; un software que permita llevar un control de las tareas que se desarrollan para atender los requerimientos, pero principalmente que esta herramienta permita la interacción del personal del área de sistemas con los usuarios que solicitan los requerimientos. 2.2 Requisitos Para realizar bien el desarrollo de software es esencial realizar un buen trabajo en la especificación de requisitos. A continuación se presentará en tres módulos los requisitos capturados: 2.2.1 Módulo de Requerimiento Las necesidades que se buscan cubrir en el presente módulo son las referentes a los requerimientos, desde su registro hasta el cierre de los mismos, pasando por el flujo de aprobaciones necesarias hasta llegar al área de sistemas. En el cuadro 2.1 se aprecia la lista de requisitos de este módulo, asignándole un código de identificación. 2.2.2 Módulo de Tarea Las necesidades que se buscan cubrir en el presente módulo son las referentes a la ejecución de las tareas originadas por los requerimientos que se solicitan al 16 área de sistemas, contempla la etapa de desarrollo y todo lo relativo a las tareas realizadas para implementar la solución de los requerimientos registrados. En el cuadro 2.2 se aprecia la lista de requisitos del módulo de tarea asignándole un código de identificación. 2.2.3 Módulo de Administración En el presente módulo se presentan las necesidades de mantenimiento de las entidades del sistema. En el cuadro 2.3 se aprecia la lista de requisitos del módulo de administración, asignándole un código de identificación. Cuadro 2.1 : Lista de Requisitos – Módulo de Requerimientos MÓDULO DE REQUERIMIENTOS Cod. Requisitos R01 Registrar requerimientos. R02 Actualizar la información de un requerimiento. R03 Asignar recursos al requerimiento. R04 Mostrar reportes estadísticos de los requerimientos. R05 Contemplar flujo de aprobaciones. R06 Notificaciones vía correo electrónico. R07 Registrar lista de pruebas. R08 Registrar movimientos del requerimiento. R09 Reasignar el requerimiento a otro responsable de área para su futura aprobación o desaprobación. R10 Permitir al responsable de informática registrar el motivo de rechazo del requerimiento. R11 Asociar los requerimientos al centro de costo que lo solicite para poder calcular la cantidad de horas invertidas en la solución del requerimiento por centro de costo. R12 Permitir al usuario solicitante participar activamente en la etapa de pruebas. R13 Generar requerimientos automáticamente a partir del rechazo de alguna de las pruebas. R14 Asignar automáticamente el requerimiento (cuya categoría es "error o consulta") al responsable de sistemas según el sistema y subsistema registrado. R15 Conocer el grado de satisfacción del cliente mediante el registro de una encuesta. R16 Permitir al responsable del área retornar el requerimiento al usuario para su actualización antes de la aprobación. R17 Aprobar/Desaprobar un requerimiento por responsable de área. R18 Enviar el requerimiento al Área de sistemas. R19 Cerrar de requerimientos. R20 Cancelar un requerimiento. R21 Permitir al responsable de informática o responsable de solución modificar propiedades de requerimiento hijo. 17 Cuadro 2.1 : Lista de Requisitos – Módulo de Requerimientos (continuación) MÓDULO DE REQUERIMIENTOS Cod. Requisitos R22 Validar el motivo de rechazo de la solución. R23 Reasignar prioridad, fecha de inicio y recurso a los requerimientos antes de entrar a desarrollo. R24 Permitir al responsable de área dar conformidad de fecha de inicio de atención del requerimiento. R25 Permitir al gerente de área seleccionar requerimientos de su área que se están ejecutando para que puedan detenerse y atender el nuevo requerimiento(sólo cuando el responsable de área no acepte la fecha de inicio). R26 Adjuntar documento. R27 Actualizar documento del tipo Registro de Atención. R28 Registrar de observaciones a los documentos. R29 Aprobar documento. R30 Cargar plantillas de etapas y tareas definidas para la solución de requerimientos R31 R32 R33 Mostrar el diagrama de Gantt. Permitir al responsable de desarrollo enviar una fecha tentativa de inicio al responsable de área para su conformidad. Permitir al responsable de área rechazar la fecha de inicio y enviarla al gerente. Cuadro 2.2 : Lista de Requisitos : Módulo de Tarea MÓDULO DE TAREA Cod. Requisitos R34 Crear tareas. R35 Crear etapas. R36 Modificar datos de las tareas. R37 Eliminar tareas existentes. R38 Eliminar etapas. R39 Generar fechas estimadas de inicio y finalización de las tareas. R40 Registrar las horas reales invertidas en la solución. R41 Mostrar tareas asignadas a cada ejecutor. R42 Mostrar estado de las tareas. R43 Registrar las incidencias de las tareas (interrupciones). R44 Registrar los objetos con los cuales se estén trabajando. R45 Registrar tareas no asociadas al requerimiento. R46 Cerrar una tarea. R47 Registrar horas libres(vacaciones, permisos, feriados). R48 Consultar las actividades pendientes. R49 Cerrar una actividad pendiente. R50 Permitir al responsable de sistemas cerrar un periodo(ya no se podrán registrar horas). R51 Permitir al responsable de sistemas consultar las horas registradas por los recurso según sede, tipo requerimiento por semana o mes. 18 Cuadro 2.3 : Lista de Requisitos – Módulo de Administración MÓDULO DE ADMINISTRACION Cod. Requisitos R52 Registrar, modificar y eliminar un sistema. R53 Registrar, modificar y eliminar un subsistema asociado a un sistema. R54 Registrar, modificar y eliminar un tipo de requerimiento. R55 Registrar, modificar y eliminar una categoría asociada a un tipo de requerimiento. R56 Registrar, modificar y eliminar una clase. R57 Registrar, modificar y eliminar el estado de una tarea. R58 Registrar, modificar y eliminar el estado de un documento. R59 Registrar, modificar y eliminar el estado de un requerimiento. R60 Registrar, modificar y eliminar al responsable de informática según sede y tipo de requerimiento. R61 Registrar, modificar y eliminar al responsable de solución de un requerimientos según sistema y subsistema. R62 Definir y modificar el flujo que deberá seguir un requerimiento o tarea. R63 Registrar, modificar y eliminar un tipo de flujo. R64 Registrar, modificar y eliminar un tipo de documento. R65 Registrar, modificar y eliminar un tipo de movimiento. R66 Registrar, modificar y eliminar un tipo de tarea. R67 Registrar, modificar y eliminar una tarea para asociarla a una plantilla. R68 Registrar, modificar y eliminar una etapa para asociarla a una plantilla. R69 Registrar, modificar y eliminar plantillas solución según el tipo de requerimiento. R70 Registrar, modificar y eliminar las sedes. 2.3 Evaluación de Herramientas existentes Existen en el mercado herramientas encargadas de la gestión de requerimientos y otras que contemplan la planificación de tareas, pero no se han encontrado herramientas que cumplan con ambas funcionalidades. 2.4 Características de las Herramientas Evaluadas Se evaluaron las siguientes herramientas: Project KickStart [PKS], Project.net [PNET], Primavera P6 [Primavera], P2.net [P2NET], ProjectCompanion [PC], Hitos [Hitos], ProWorkflow [PWF] y se encontraron algunas características comunes a ellas. Con respecto a la gestión de requerimientos, entre las principales características encontradas tenemos: 19 • Permiten registrar los requerimientos. • Permite modificar y eliminar requerimientos. • Muestran el diagrama Gantt para realizar el seguimiento del requerimiento. • Permiten mostrar diversos reportes con datos estadísticos del requerimiento. Entre las características más resaltantes encontradas en las herramientas para la planificación de tareas destacan: • Permiten crear, modificar y eliminar tareas a desarrollar. • Permiten asignar recursos a las tareas. • Permiten mostrar el estado de las tareas. • Muestran el porcentaje de avance de las tareas. • Permiten mostrar todas las tareas del requerimiento y las asignadas a un recurso en particular. Durante la evaluación pudimos encontrar características que eran propias de algunas herramientas. Podemos mencionar las siguientes: • Notificaciones vía correo electrónico. • Permite el manejo de documentos. • Permiten la integración con otras herramientas ya que se puede importar/exportar datos desde y hacia otras fuentes. • Permite la creación de plantillas de tareas base para la solución de ciertos tipos de requerimientos. • Permiten registrar la cantidad de horas que se está invirtiendo en cada una de las tareas asignadas. • Permiten mostrar la sobrecarga de los recursos. • Permite registrar las incidencias presentadas durante el desarrollo de la solución del requerimiento. En el siguiente cuadro (2.4) se puede apreciar las características consideradas en la evaluación de cada una de las herramientas. La comparación se ha realizado según las especificaciones de las características de los productos y/o realizando pruebas de funcionalidad en cada una de dichas herramientas. Se puede observar que ninguna de las herramientas evaluadas poseen todas las características que la empresa necesita. 20 Cuadro 2.4 : Comparación características entre herramientas evaluadas Pr o jec t K ic kS ta rt Pr o jec t.n et Pr im av e ra P6 P2 . n et Pr o jec tC o m pa n io n H ito s Pr o W o rk flo w ¿Permite crear más de un proyecto? X X X ¿Permite asignar recursos al proyecto? X X X X ¿Permite establecer el costo de los recursos? X X ¿Permite crear tareas para el proyecto? X X X X ¿Permite modificar los datos de las tareas? X X X ¿Permite eliminar las tareas existentes? X X X ¿Permite establecer las fechas esperadas de inicio y finalización de las tareas? X X X ¿Permite cargar plantillas predefinidas? X X X ¿Permite crear plantillas de tareas para proyectos? X X ¿Permite modificar las plantillas existentes? X ¿Permite eliminar las plantillas existentes? X ¿Permite asignar recursos a las tareas? X X X X ¿Muestra las tareas asignadas a cada usuario? X X X ¿Permite el registro de las horas reales trabajadas? X X ¿Muestra la sobrecarga de recursos? X ¿Permite ver el porcentaje de avance de las tareas? X X X ¿Muestra el estado de las tareas? X X X ¿Muestra el diagrama de Gantt de seguimiento del proyecto? X X X X X ¿Permite registrar las incidencias del proyecto?(interrupciones) X ¿Muestra reportes estadísticos del proyecto? X X X X ¿Requiere usuario y contraseña para validar el ingreso al sistema/aplicación? X X X Manejo de documentos X X X X Contempla flujo de aprobaciones X X Registro de requerimientos X Actualización de información de requerimientos X Dependencia de requerimientos( padre - hijo) Notificaciones vía correo electrónico X X Creación automática de requerimientos hijos Registrar lista de pruebas X Registrar movimientos del requerimiento Registro de tareas no asociadas al requerimiento o proyecto Registro de observaciones a los documentos Registro de objetos modificados Medir grado de satisfacción del cliente – encuesta 21 3. Análisis El objetivo de este capítulo es mostrar una breve introducción al sistema, presentando las principales características que contendrá la herramienta propuesta, así como el análisis realizado para el presente trabajo de tesis. Se utilizará UML (de las siglas en inglés Unified Modeling Language) como lenguaje estándar para la construcción de los artefactos del software. Los artefactos de software elaborados para la etapa de análisis fueron: El diagrama de actores, el diagrama de casos de uso, el diagrama de clases de análisis y el diagrama de estados de las clases más importantes. 3.1 Flujo del Sistema Para un mayor entendimiento de la herramienta propuesta se define a continuación en un alto nivel las actividades realizadas en el sistema para la atención y solución de los requerimientos. 22 El flujo comienza cuando el usuario solicitante registra un requerimiento, dependiendo del tipo y categoría de solicitud registrada se sigue flujos diferentes. • Si es de tipo desarrollo y categoría error o consulta, el requerimiento se envía directamente al área de sistemas (al responsable del desarrollo de la solución). • Caso contrario, esté se dirige al responsable de área, quien podrá aprobar, desaprobar, reasignar o retornar la solicitud al usuario que lo registró para que brinde un mayor detalle. Si el requerimiento es aprobado por el responsable de área, se envía al responsable de informática (responsable de desarrollo o responsable de soporte según la información registrada en el requerimiento), quien podrá aceptar o rechazar la solicitud. En caso se acepte el requerimiento, el responsable de informática tendrá que verificar la disponibilidad de los recursos: • Si se cuenta con personal disponible se asignará un responsable de solución, el cual deberá analizar el requerimiento y registrar el plan de solución, asignando ejecutores y tiempo estimado a las tareas (inicialmente el sistema genera automáticamente una plantilla básica de etapas y tareas que se tendrán que desarrollar para atender el pedido, se podrá adicionar otras etapas y tareas según se requieran). Luego de terminar con el desarrollo de la solución, se podrá registrar los casos de prueba que deberán ser ejecutados por el usuario solicitante y/o responsable de área. Si todo es conforme, se solicita el cierre del requerimiento; en caso no esté conforme con alguna de la pruebas realizadas, el responsable de área deberá registrar el motivo de no conformidad y el sistema creará automáticamente un requerimiento nuevo dependiente del anterior al que se denominará en adelante “Requerimiento hijo”; el cual será asignado al ejecutor que registró las prueba. • Si no se cuenta con personal disponible, el responsable de informática envía al responsable de área la fecha tentativa en la cual se podría iniciar la atención del requerimiento, esta fecha es tomada en función a la disponibilidad de un responsable de solución. El responsable de área puede aceptar esa fecha, con lo cual el pedido ya estaría asignado al responsable de la solución. Asimismo, puede rechazar dicha fecha, en este caso se enviará al gerente del área que realizó la solicitud, la lista de requerimientos 23 de su área que se está atendiendo para que él pueda seleccionar alguno para su detención momentánea hasta que concluya la solución del requerimiento registrado. A manera de resumen se muestra en la Figura 3.1 las actividades realizadas en el sistema para la atención y solución de los requerimientos. El flujo establecido permitirá establecer mejoras en el proceso actual de atención de los requerimientos. El principal beneficio para el área de sistemas será tener un mayor control de los requerimientos y del tiempo invertido por los recursos de su área para dar solución a los pedidos registrados. Otra mejora que beneficia al área de sistemas, es que en el la herramienta propuesta se definirá un flujo previo de aprobación para los requerimientos, es decir, que los pedidos de los usuarios ya no llegarán directamente al área de sistemas, sino que contará con la aprobación previa del responsable de su área, permitiendo de esta manera disminuir la cantidad de solicitudes enviadas a sistemas y la duplicidad de pedidos porque el criterio del jefe de área actuaría como un filtro previo. Del mismo modo, contarán con la documentación necesaria que permita evidenciar que la solución brindada es de acuerdo a la necesidad manifestada por el usuario inicialmente, ya que muchas veces los usuarios no saben dar a entender sus necesidades y cuando se les proporciona una solución, manifiestan que no es lo que ellos solicitaron. El área de sistemas tendrá las estadísticas necesarias para llevar un control de los requerimientos y de la carga de trabajo de su personal, y de esta forma sustentar la necesidad de incrementar los recursos del área. Entre los principales reportes estadísticos se tiene la cantidad de requerimientos por centro de costo, tiempo invertido en la solución de cada tipo de requerimiento, tiempo invertido en la solución de los requerimientos por área, entre otros. Para las demás áreas de la empresa, el beneficio principal será la intervención directa de los usuarios. Serán ellos mismos los que registren sus pedidos en el sistema, se mantendrán informados en todo momento del avance de la solución y del estado en el que se encuentra su requerimiento vía correo electrónico o podrán entrar a consultar el requerimiento en el sistema. Además, serán actor activo porque se involucrarán en el desarrollo de la solución, ya que durante la etapa de pruebas deberán dar conformidad a la solución brindada. 24 Figura 3.1: Flujo de actividades del sistema 25 3.2 Características de la Herramienta Propuesta A continuación se menciona las características particulares de la herramienta propuesta: • Registro de requerimientos. • Creación de tareas • Asignación de recursos a las tareas. • Visualización del porcentaje de avance de las tareas. • Manejo de documentos, generación de reportes. • Registro de requerimientos relacionados a otros. • Aprobación o Desaprobación del requerimiento antes de ser enviado a sistemas. • Permitirá detener un requerimiento para dar atención a otro de mayor prioridad de la misma área solicitante. • Reasignación del requerimiento a otro responsable para su futura aprobación o desaprobación. • Permitirá al área de sistemas aceptar o rechazar el requerimiento registrando el motivo de rechazo. • Asociación de los requerimientos al centro de costo que lo solicite para poder calcular las horas invertidas en la solución del requerimiento. • Registro de encuesta para conocer el grado de satisfacción del cliente. • Permitirá al usuario solicitante participar activamente en la etapa de pruebas. • Generación automática de requerimientos a partir del rechazo de alguna de las pruebas. • Validar el control de cambios de las fuentes con las que se estén trabajando mediante el registro de los nombres de estas. • Asignación automática del requerimiento al responsable de sistemas según el sistema y subsistema registrado. • Permitirá interrumpir la ejecución de tareas. • Permitirá controlar los pases a producción. 3.3 Especificación de Actores Se denomina actor a un usuario del sistema, que necesita o usa alguno de los casos de uso. Un usuario puede jugar más de un rol. Un solo actor puede actuar 26 en muchos casos de uso, recíprocamente un caso de uso puede tener varios actores. Los actores no necesitan ser humanos, pueden ser sistemas externos que necesitan alguna información del sistema actual. El nombre del actor describe el papel desempeñado. [New Horizons]. Los actores para la herramienta propuesta son: usuario solicitante, responsable de área, responsable de desarrollo, responsable de soporte, asistente de soporte, encargado de soporte, responsable de solución, ejecutor, gerente y administrador del sistema. En la figura 3.2 se muestra el diagrama de actores del sistema. A continuación se describe cada uno de los actores: • Actor: Representa a cualquier usuario que tenga acceso al sistema. • Usuario Solicitante: Persona que registra un requerimiento. • Responsable de Área: Persona que analiza el requerimiento antes que pase al área de sistemas. • Responsable de Desarrollo: Persona que analiza los requerimientos de tipo software para ser asignados y atendidos. • Responsable de Soporte: Persona que analiza los requerimientos de tipo soporte para ser asignados y atendidos. • Encargado de Soporte: Persona responsable de los requerimientos de soporte relacionados con configuraciones de base de datos, accesos, permisos. • Asistente de Soporte: Persona que atiende los requerimientos de soporte relacionados con problemas de hardware y software base. • Responsable de Solución: Persona responsable de dar solución a los requerimientos tipo software • Ejecutor: Persona encargada de ejecutar las tareas relacionadas a los requerimientos tipo software. • Gerente: Persona que puede detener requerimientos. • Administrador del Sistema: Persona encargada de dar mantenimientos al sistema. • Personal Sistemas: Representa a los usuarios del área de sistemas. • Personal Otra Área: Representa a los usuarios que no pertenecen al área de sistema. 27 • Personal Desarrollo: Representa a los siguientes actores: Responsable de Desarrollo, Responsable de Solución y Ejecutor. • Personal Soporte: Representa a los siguientes actores: Responsable de Soporte, Asistente de Soporte y Encargado de Soporte. Figura 3.2 : Diagrama de actores del sistema 3.4 Paquetes del Sistema Los paquetes son mecanismos conceptuales que sirven para organizar elementos en grupos. Los paquetes pueden ser anidados dentro de otros paquetes [UML Bible]. Los paquetes definidos para este sistema son: paquete de requerimiento, paquete de tarea y paquete de administración. Para esta clasificación se ha tomado como base los módulos definidos en el punto 2.3. A continuación se describirá cada uno de estos paquetes. 28 3.4.1 Paquete de Requerimiento El presente paquete brindará al usuario las herramientas necesarias para que pueda realizar los siguientes procesos: registrar el requerimiento, mantener un documento, registrar movimiento, registrar una encuesta y mantener prueba. Tomando en cuenta el flujo establecido, es a través de este módulo que se podrá realizar los siguientes procesos: aprobar, desaprobar, retornar o reasignar el requerimiento, aceptar o rechazar el requerimiento, aceptar fecha de inicio estimado, rechazar fecha de inicio estimado, asignar recursos, detener requerimiento, aceptar o rechazar requerimiento hijo, cerrar, cancelar requerimiento y generar reportes. Todos los procesos mencionados anteriormente cubrirán las necesidades planteadas en el punto 2.3.1 del capítulo 2. Debido a la amplitud de este paquete se dividirá en sub paquetes para poder presentar los casos de uso con una mayor claridad. Estos sub paquetes son: a. Sub Paquete de Solicitud – Abarca los procesos de registro de requerimiento, de movimiento, de encuesta y la aceptación de requerimiento hijo. b. Sub Paquete de Documentos y Pruebas – Comprende los siguientes procesos: Mantener documento, aprobar documento, mantener observación documento, mantener prueba y aprobar prueba. c. Sub Paquete de Aprobaciones – Contempla los procesos de aprobación y asignación, tales como aprobar, reasignar, retornar y aceptar requerimiento. d. Sub Paquete de Planificación - Se encuentra los procesos concerniente a la estimación de la fecha de inicio de atención del requerimiento. En este sub paquete se encuentra el enviar fecha, aceptar y rechazar fecha, el detener requerimiento y el de asignar recurso. 3.4.2 Paquete de Tarea El presente paquete brindará al área de sistemas la posibilidad de llevar un control del recurso humano, de modo que se pueda conocer la disponibilidad de cada uno y saber las tareas que están desarrollando; para esto el personal de sistemas deberá planificar el tiempo de atención de cada una de las tareas asignadas, así como registrar el tiempo real invertido en dichas tareas. 29 Este paquete permitirá atender las necesidades planteadas en el punto 2.3.2, tales como creación y modificación de etapas y tareas, registrar horas invertidas en la atención de cada una de las tareas, registro de objetos creados o modificados, registro de interrupciones de las tareas, realizar consultas de disponibilidad de recursos, de actividades pendientes, de horas registradas. 3.4.3 Paquete de Administración El presente paquete permitirá al administrador del sistema realizar el mantenimiento de las principales tablas del sistema como tipo de requerimiento, categoría, prioridad, sistema, clase, estados del requerimiento, del documento, de la tarea, responsables de informática, responsables de solución; así como poder definir el flujo que seguirá cada tipo de requerimiento. Los mantenimientos mencionados atenderán los requerimientos planteados en el punto 2.3.3 3.5 Casos de Uso Es una técnica que captura los procesos del negocio desde la perspectiva del usuario. Direccionan el trabajo desde el análisis hasta las pruebas, establece los requisitos funcionales del sistema. [New Horizons]. Los casos de uso serán agrupados dentro de los paquetes definidos en el punto 3.3, los cuales son: paquete de requerimientos, paquete de tarea y paquete de administración. La especificación de los casos de uso por etapa se pueden observar en el Anexo A. El diagrama de casos de uso es un diagrama que muestra un conjunto de casos de uso, actores y sus relaciones dentro de un sistema; los diagramas de casos de uso muestran los casos de uso de un sistema desde el punto de vista estático. [Rumbaugh]. Los diagramas han sido elaborados utilizando la notación UML. 3.5.1 Paquete Requerimiento Se presentará los casos de usos contemplados dentro de los sub-paquetes: solicitud, aprobación, planificación y documentos/pruebas; además los requerimientos que abarca cada caso de uso. 30 a. Sub-Paquete Solicitud: Procesos directamente relacionado con el manejo del requerimiento, entre los cuales tenemos: registro de requerimiento, de movimiento, de encuesta, cerrar requerimiento, cancelar requerimiento, generar reportes y la aceptación de requerimiento hijo. En el Cuadro 3.1 se observa los casos de uso del presente sub paquete. Cuadro 3.1: Casos de Uso – Sub Paquete Solicitud Cod. Nombre Actor Descripción Req. A.1 Registrar Requerimiento Usuario Solicitante Permite registrar un requerimiento a cualquier usuario del sistema. R1, R11, R14 A.16 Aceptar Requerimiento Hijo Personal de Sistemas El actor tendrá la potestad de aceptar un requerimiento hijo originado por el rechazo de alguna prueba. R21, R22 A.17 Registrar Avance Actor El actor podrá registrar avances asociados al requerimiento y los involucrados serán notificados vía correo electrónico. R6, R8 A.18 Registrar Encuesta Usuario solicitante El actor deberá registrar una encuesta al finalizar la atención del requerimiento. R15 A.19 Cerrar Requerimiento Responsabl e de Desarrollo o Responsabl e de Soporte. Permite al actor cerrar el requerimiento cuando se hayan finalizado todas las tareas. R19 A.20 Cancelar Requerimiento Responsabl e de Desarrollo o Responsabl e de Soporte. Permite al actor cancelar el requerimiento en cualquier estado. R20 A.21 Generar Reportes Actor Permite generar diversos reportes R04, R31 En la Figura 3.3 se observa el diagrama de casos de usos que muestra los procesos que serán contemplados dentro del Sub-paquete Solicitud. En el cuadro 3.2 se muestra la relación entre requerimiento y caso de uso que lo cumplirá. 31 Figura 3.3 : Diagrama C.U – Sub Paquete Solicitud Cuadro 3.2 : Casos de Uso vs. Requerimientos – Sub Paquete Solicitud Casos de Uso Requerimientos A.1 A.16 A.17 A.18 A.19 A.20 A.21 R01 Permitir registrar requerimientos X R04 Mostrar reportes estadísticos de los requerimientos X R06 Notificaciones vía correo electrónico X R08 Registrar movimientos del requerimiento X R11 Permitir asociar los requerimientos al centro de costo que lo solicite para poder calcular la cantidad de horas invertidas en la solución del requerimiento por centro de costo X R14 Permitir asignar automáticamente el requerimiento (cuya categoría es "error o consulta") al responsable de sistemas según el sistema y subsistema registrado. X 32 Cuadro 3.2 : Casos de Uso vs. Requerimientos – Sub Paquete Solicitud (continuación) Casos de Uso Requerimientos A.1 A.16 A.17 A.18 A.19 A.20 A.21 R15 Permitir conocer el grado de satisfacción del cliente mediante el registro de una encuesta. X R19 Permitir el cierre de requerimientos. X R20 Permitir abortar(cancelar) un requerimiento X R21 Permitir al responsable de informática o responsable de solución modificar propiedades de requerimiento hijo X R22 Permitir validar el motivo de rechazo de la solución. X R31 Mostrar el diagrama de Gantt X b. Sub-Paquete Aprobación: Procesos relacionados a la etapa de aprobación del requerimientos antes del desarrollo de este; entre los cuales tenemos: aprobación y asignación, tales como aprobar, reasignar, retornar y aceptar requerimiento. En el Cuadro 3.3 se observa los casos de uso del sub paquete Aprobación. Cuadro 3.3 : Casos de Uso – Sub Paquete Aprobación Cod. Nombre Actor Descripción Req. A.2 Aprobar Requerimiento Responsable de Área Permite al actor aprobar un requerimiento registrado por un usuario de su área. R2, R17, R18 A.3 Reasignar Requerimiento Responsable de Área Permite al actor reasignar un requerimiento a un miembro de su área que tenga el permiso de aprobar, desaprobar o retornar el requerimiento. R2, R9 A.4 Retornar Requerimiento Responsable de Área Permite al actor retornar el requerimiento al usuario que lo registró para que brinde un mayor detalle o realice alguna corrección. R2, R16 A.5 Aceptar Requerimiento Responsable de Desarrollo o Responsable de Soporte Permite al actor aceptar un requerimiento que haya sido previamente aprobado. R2, R10, R23, R30 En el diagrama de casos de usos de la Figura 3.4 se muestra los procesos que serán contemplados dentro del Sub-paquete Aprobación. En el Cuadro 3.4 se muestra la relación entre requerimiento y caso de uso que lo cumplirá. 33 Figura 3.4 : Diagrama C.U – Sub Paquete Aprobación Cuadro 3.4 : Casos de Uso vs. Requerimientos – Sub Paquete Aprobación Casos de Uso Requerimientos A.2 A.3 A.4 A.5 R02 Permitir actualizar la información de un requerimiento X X X X R09 Permitir reasignar el requerimiento a otro responsable de área para su futura aprobación o desaprobación. X R10 Permitir al responsable de informática registrar el motivo de rechazo del requerimiento. X R16 Permitir al responsable del área retornar el requerimiento al usuario para su actualización antes de la aprobación. X R17 Permitir aprobar/rechazar un requerimiento por responsable de área. X R18 Permitir el envió del requerimiento al Área de sistemas X R23 Permitir reasignar prioridad, fecha de inicio y recurso a los requerimientos antes de entrar a desarrollo X R30 Cargar plantillas de etapas y tareas definidas para la solución de requerimientos. X c. Sub-Paquete Documento Pruebas: Procesos relacionados con el manejo de los documentos y las pruebas de un requerimiento; entre los cuales tenemos: Mantener documento, aprobar documento, mantener observación documento, mantener prueba y aprobar prueba. En el Cuadro 3.5 se observa los casos de uso del presente sub paquete. 34 Cuadro 3.5 : Casos de Uso – Sub Paquete Documento y Pruebas Cod. Nombre Actor Descripción Req. A.11 Mantener Documento Actor El actor podrá adjuntar documentos como formatos o actas de reunión. El usuario que registró el documento podrá eliminarlo. R26, R27 A.12 Aprobar Documento Actor El actor podrá aprobar las actas de reunión. R29 A.13 Mantener Observación Documento Actor Se puede registrar, modificar y eliminar observaciones de los documentos. R28 A.14 Mantener Prueba Personal de Sistemas El actor podrá registrar pruebas y asignárselas al usuario solicitante o responsable de área. R7 A.15 Aprobar Prueba Responsable de Área El actor podrá aprobar las pruebas asignadas. R12, R13 En la Figura 3.5 se muestra el diagrama de casos de usos que contiene los procesos que serán contemplados dentro del Sub-paquete Documento Pruebas. En el cuadro 3.6 se muestra la relación entre requerimiento y caso de uso que lo cumplirá. Figura 3.5 : Diagrama C.U – Sub Paquete Documento y Pruebas 35 Cuadro 3.6 : Casos de Uso vs. Requerimientos – Sub Paquete Documento y Pruebas Casos de Uso Requerimientos A.11 A.12 A.13 A.14 A.15 R07 Registrar lista de pruebas X R12 Permitir al usuario solicitante participar activamente en la etapa de pruebas. X R13 Permitir generar requerimientos automáticamente a partir del rechazo de alguna de las pruebas. X R26 Permitir adjuntar documento X R27 Permitir actualizar documento del tipo registro de Atención X R28 Permitir el registro de observaciones a los documentos X R29 Permitir aprobar documento X d. Sub-Paquete Planificación: Procesos que involucran al análisis y confirmación de la fecha de inicio de un requerimiento, entre los cuales tenemos: enviar fecha, aceptar y rechazar fecha, el detener requerimiento y el de asignar recurso. En el Cuadro 3.7 se observa los casos de uso del sub paquete Planificación. Cuadro 3.7 : Casos de Uso – Sub Paquete Planificación Cod. Nombre Actor Descripción Req. A.6 Asignar Recurso Personal de Sistemas Permite asignar un responsable al requerimiento. R3 A.7 Enviar Fecha Responsable de Desarrollo El actor enviará al responsable de área la fecha más próxima en la que se pueda atender el nuevo requerimiento, a fin que éste la acepte o se la envíe al gerente de su área. R31 A.8 Aceptar Fecha Responsable de Área El actor podrá aceptar la fecha de inicio enviada por el Responsable de Desarrollo en caso esté de acuerdo. R24 A.9 Rechazar Fecha Responsable de Área El actor podrá rechazar la fecha de inicio enviada por el Responsable de Desarrollo si considera que es muy lejana y enviará dicha fecha al Gerente de su Área para que tome las decisiones pertinentes. R32 A.10 Detener Requerimiento Gerente El actor podrá detener la ejecución de algún requerimiento de su área para que el personal de sistemas pueda atender un nuevo requerimiento. R25 36 En la Figura 3.6 se muestra el diagrama de casos de usos que contiene los procesos que serán contemplados dentro del Sub-paquete Planificación. En el cuadro 3.8 se muestra la relación entre requerimiento y caso de uso que lo cumplirá. Figura 3.6 : Diagrama C.U – Sub Paquete Planificación Cuadro 3.8 : Casos de Uso vs. Requerimientos – Sub Paquete Planificación Casos de Uso Requerimientos A.6 A.7 A.8 A.9 A.10 R03 Permitir asignar recursos al requerimiento X R24 Permitir al responsable de área dar conformidad de fecha de inicio de atención del requerimiento X R25 Permitir al gerente de área seleccionar requerimientos de su área que se están ejecutando para que puedan detenerse y atender el nuevo requerimiento(sólo cuando el responsable de área no acepte la fecha de inicio) X R32 Permitir al responsable de desarrollo enviar una fecha tentativa de inicio al responsable de área para su conformidad. X R33 Permitir al responsable de área rechazar la fecha de inicio y enviarla al gerente. X 37 3.5.2 Paquete Tarea En el Cuadro 3.9 se mostrará los casos de usos presentes en el paquete de tarea que definen los procesos de registro y consulta de disponibilidad, mantenimiento de solución y lo referente a las actividades pendientes. Cuadro 3.9 : Casos de Uso -Paquete Tarea Cod. Nombre Actor Descripción Req. B.1 Consultar Horas Responsable de Desarrollo o Responsable de Soporte El actor podrá consultar las horas registradas de su personal. R51 B.2 Cerrar Periodo Responsable de Desarrollo o Responsable de Soporte Semanalmente el actor podrá cerrar los periodos; el personal de sistemas ya no podrá regularizar las horas para dicho período. R50 B.3 Consultar Actividad Pendiente Actor El actor del sistema podrá consultar las actividades que tengan pendiente, en su bandeja de entrada del sistema. R48 B.4 Cerrar Actividad Pendiente Actor del Sistema El actor podrá cerrar la actividad una vez realizada. R49 B.5 Registrar Horas Trabajadas Personal de Sistemas El actor deberá registrar diariamente las horas invertidas en la atención de un requerimiento. R40 B.6 Registrar Horas Libres Personal de Sistemas El actor deberá registrar las horas correspondientes a permisos, vacaciones, feriados, descanso medico y viaje. R47 B.7 Registrar Tarea Indirecta Personal de Sistemas El actor deberá registrar las tareas indirectas que hayan realizado (todas aquellas tareas que no provengan de un requerimiento asignado) R45 B.8 Cerrar Tarea Personal de Sistemas El personal de sistemas deberá cerrar las tareas que hayan concluido. R46 B.9 Mantener Solución Personal de Sistemas El actor realizará el mantenimiento de la solución del requerimiento, podrá registrar una nueva etapa, una tarea o modificarlas. R34, R35, R36, R37, R38, R39, R42, R44 B.10 Mantener Interrupción Responsable de Desarrollo, Responsable de Soporte, Responsable de Solución, Encargado de Soporte El actor podrá interrumpir las tareas de otro requerimiento y registrar el tiempo estimado y real que demanda dicha interrupción. R43 B.11 Consultar disponibilidad Responsable de Soporte, Responsable de Desarrollo El actor podrá consultar la carga de trabajo que tiene el personal de sistemas. R41 38 El siguiente diagrama de casos de usos muestras los procesos que serán contemplados dentro del paquete de tarea. (Figura 3.7) Figura 3.7 : Diagrama C.U –Paquete Tarea En el cuadro 3.10 se muestra la relación entre requerimiento y caso de uso que lo cumplirá. 39 Cuadro 3.10 : Casos de Uso vs. Requerimientos - Paquete Tarea Casos de Uso Requerimientos B.1 B.2 B.3 B.4 B.5 B.6 B.7 B.8 B.9 B.10 B.11 R34 Permitir crear tareas X R35 Permitir crear etapas X R36 Permitir modificar datos de las tareas X R37 Permitir eliminar tareas existentes X R38 Permitir eliminar etapas X R39 Permitir generar fechas estimadas de inicio y finalización de las tareas. X R40 Permitir el registro de las horas reales invertidas en la solución. X R41 Mostrar tareas asignadas a cada ejecutor X R42 Mostrar estado de las tareas X R43 Permitir registrar las incidencias de las tareas (interrupciones) X R44 Permitir registrar los objetos con los cuales se estén trabajando. X R45 Registro de tareas no asociadas al requerimiento X R46 Permitir cerrar una tarea X R47 Permitir registrar horas libres(vacaciones, permisos, feriados) X R48 Permitir consultar las actividades pendientes X R49 Permitir cerrar una actividad pendiente X R50 Permitir al responsable de sistemas cerrar un periodo(ya no se podrán registrar horas) X R51 Permitir al responsable de sistemas consultar las horas registradas por los recurso según sede, tipo requerimiento por semana o mes. X 40 3.5.3 Paquete Administración. En el Cuadro 3.11 se presentará los casos de usos contemplados dentro del paquete de administración, asociados al requerimiento que cubre cada caso de uso. Cuadro 3.11 : Casos de Uso - Paquete Administración Cod. Nombre Actor Descripción Req. C.1 Mantener Tipo Administrador del Sistema Permite registrar, modificar y eliminar los tipos de requerimiento. R.54 C.2 Mantener Categoría Administrador del Sistema Permite registrar, modificar y eliminar las categorías de los requerimientos. R.55 C.3 Mantener Clase Administrador del Sistema Permite registrar, modificar y eliminar las clases registradas en el sistema, tales como: requerimiento, tarea, documento y prueba. R.57, R.58, R.59 C.4 Mantener Estado Clase Administrador del Sistema Permite registrar, modificar y eliminar los estados que contemplará cada clase considerada en el sistema. R.56 C.5 Mantener Sistema Administrador del Sistema Permite registrar, modificar y eliminar los sistemas existentes. R.52 C.6 Mantener Subsistema Administrador del Sistema Permite registrar, modificar y eliminar los subsistemas asociados a un sistema. R.53 C.7 Mantener Responsable Solución Administrador del Sistema Permite registrar, modificar y eliminar a los responsables de solución. R.61 C.8 Mantener Responsable Informática Administrador del Sistema Permite registrar, modificar y eliminar a los responsables de informática. R.60 C.9 Mantener Tipo Flujo Administrador del Sistema Permite registrar, modificar y eliminar los tipos de flujo considerados en el sistema. R.63 C.10 Mantener Flujo Administrador del Sistema Permite registrar, modificar y eliminar las rutas de cada flujo. R.62 C.11 Mantener Tipo Documento Administrador del Sistema Permite registrar, modificar y eliminar los diversos tipos de documentos considerados en el sistema. R.64 C.12 Mantener Tipo Movimiento Administrador del Sistema Permite registrar, modificar y eliminar los tipos de movimiento que contempla el sistema. R.65 C.13 Mantener Tipo Tarea Administrador del Sistema Permite registrar, modificar y eliminar los tipos de tareas considerados. R.66 C.14 Mantener Plantilla Administrador del Sistema Permite registrar, modificar y eliminar las plantillas que servirán de base para la solución de los requerimientos. R.69 41 Cuadro 3.11 : Casos de Uso – Paquete Administración (continuación) Cod. Nombre Actor Descripción Req. C.15 Mantener Etapa Plantilla Administrador del Sistema Permite registrar, modificar y eliminar las etapas asociadas a las plantillas existentes. R.68 C.16 Mantener Tarea Plantilla Administrador del Sistema Permite registrar, modificar y eliminar las tareas asociadas a las etapas de las plantillas. R.67 C.17 Mantener Sede Administrador del Sistema Permite registrar, modificar y eliminar las sedes consideradas. R.70 El diagrama de casos de uso que se contempla dentro del paquete de administración se puede observar en la Figura 3.8. Figura 3.8 : Diagrama C.U –Paquete Administración En el cuadro 3.12 se muestra la relación entre requerimiento y caso de uso que lo cumplirá. 42 Cuadro 3.12 : Casos de Uso vs. Requerimiento-Paquete Administración Casos de Uso Requerimientos C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9 C.10 C.11 C.12 C.13 C.14 C.15 C.16 C.17 R52 Permitir registrar, modificar y eliminar un sistema X R53 Permitir registrar, modificar y eliminar un subsistema asociado a un sistema X R54 Permitir registrar, modificar y eliminar un tipo de requerimiento X R55 Permitir registrar, modificar y eliminar una categoría asociada a un tipo de requerimiento X R56 Permitir registrar, modificar y eliminar una clase X R57 Permitir registrar, modificar y eliminar el estado de una tarea X R58 Permitir registrar ,modificar y eliminar el estado de un documento X R59 Permitir registrar, modificar y eliminar el estado de un requerimiento X R60 Permitir registrar, modificar y eliminar al responsable de informática según sede y tipo de requerimiento. X 43 Cuadro 3.12 : Casos de Uso vs. Requerimientos–Paquete Administración (continuación) Casos de Uso Requerimientos C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9 C.10 C.11 C.12 C.13 C.14 C.15 C.16 C.17 R61 Permitir registrar, modificar y eliminar al responsable de solución de un requerimiento según sistema y subsistema X R62 Permitir definir y modificar el flujo que deberá seguir un requerimiento o tarea. X R63 Permitir registrar, modificar y eliminar un tipo de flujo X R64 Permitir registrar, modificar y eliminar un tipo de documento X R65 Permitir registrar, modificar y eliminar un tipo de movimiento X R66 Permitir registrar, modificar y eliminar un tipo de tarea X R67 Permitir registrar, modificar y eliminar una tarea para asociarla a una plantilla X R68 Permitir registrar, modificar y eliminar una etapa para asociarla a una plantilla X R69 Permitir registrar, modificar y eliminar plantillas solución según el tipo de requerimiento X R70 Permitir registrar, modificar y eliminar las sedes X 44 3.6 Diagrama de Clases de Análisis Antes de presentar las clases definidas en el sistema y el diagrama de clases de análisis se presentará algunos conceptos básicos: Clases: Descripción de un grupo de objetos con propiedades, comportamiento, relaciones y semánticas comunes entre sí. Son las abstracciones en las cuales se fragmenta el sistema. [New Horizons] Clase de análisis: Representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema. [Rumbaugh]. Diagrama de Clases de Análisis: Es un diagrama que muestra un conjunto de clases y las relaciones entre estas; los diagramas de clases muestran el diseño de un sistema desde el punto de vista estático. [Rumbaugh]. Para definir las clases del sistema se utilizó el método de “Descubrimiento e Invención”: Con el descubrimiento se llega a reconocer las abstracciones utilizadas por los expertos. Si el experto del dominio habla de ella, entonces la abstracción suele ser importante. Mediante la invención, se crean nuevas clases y objetos que no son parte del dominio del problema, pero que son útiles en el diseño e implementación. [New Horizons]. 3.6.1 Paquete Requerimiento Se mostrará una breve descripción de cada clase considerada dentro del paquete de requerimiento agrupado en los sub-paquetes definidos en el punto 3.2.1. El Diccionario de las Clases de esta etapa se pueden observar en el Anexo B. • En el sub-paquete de solicitud se definen las clases correspondientes a los procesos de registro de requerimiento, de movimiento, de encuesta y la aceptación de requerimiento hijo. (Ver Cuadro 3.13) En la Figura 3.9 se observa el diagrama de clases correspondiente al presente sub-paquete. 45 Cuadro 3.13 : Clases- Sub Paquete Solicitud Clase Descripción Requerimiento Clase que representa los requerimientos registrados en el sistema. Movimiento Clase que representa los movimientos registrados en un requerimiento. Encuesta Clase que representa la encuesta que deberá llenar el usuario solicitante para que se cierre su requerimiento. Categoría Definido en el paquete de Administración. Tipo Definido en el paquete de Administración. Estado Clase Definido en el paquete de Administración. Sistema Definido en el paquete de Administración. Sub-Sistema Definido en el paquete de Administración. Prioridad Definido en el paquete de Administración. Área Definido en el paquete de Administración. Sede Definido en el paquete de Administración. Tipo Movimiento Definido en el paquete de Administración. Figura 3.9 : Diagrama Clases – Sub Paquete Solicitud 46 En la figura 3.9 se muestra la relación de asociación entre la clase requerimiento y sus principales atributos que lo caracterizan, entre los cuales encontramos a la clase tipo y categoría que definen el flujo a seguir del requerimiento. • En el sub-paquete de aprobación se mencionara las clases contempladas en los procesos de aprobación y asignación, tales como aprobar, reasignar, retornar y aceptar requerimiento. (Ver Cuadro 3.14) Cuadro 3.14 : Clases- Sub Paquete Aprobación Clase Descripción Estado Clase Clase definida en el paquete de Administración. Clase Clase definida en el paquete de Administración. Flujo Clase definida en el paquete de Administración. Tipo Flujo Clase definida en el paquete de Administración. Requerimiento Clase definida en el sub-paquete Requerimiento. En la Figura 3.10 se observa el diagrama de clases correspondiente al presente sub-paquete. Figura 3.10 : Diagrama Clases – Sub Paquete Aprobación En la Figura 3.10 se muestra la relación de asociación entre flujo y tipo de flujo; se observa que el flujo está asociado a un solo tipo de flujo. Cuando se aprueba, reasigna, retorna o se acepta el requerimiento, este cambia de estado por lo que en la Figura 3.10 se muestra la relación de asociación con la clase EstadoClase. 47 • En el sub-paquete de documento y pruebas se mencionará las clases referidas al mantenimiento de pruebas y documentos. (Ver Cuadro 3.15) En la Figura 3.11 se observa el diagrama de clases correspondiente al presente sub-paquete. Cuadro 3.15 : Clases- Sub Paquete Documento y Pruebas Clase Descripción Documento Clase que representa los documentos registrados para un requerimiento. Observación Documento Clase que contiene las observaciones ingresadas por documento por los usuarios. Prueba Clase que representa a las pruebas que deberá ejecutar el usuario solicitante, contiene información acerca de la fecha y ejecutor que la registró, fecha y usuario que la ejecutó. Tipo Documento Clase definida en el paquete de Administración. Figura 3.11 : Diagrama Clases – Sub Paquete Documento y Pruebas En el diagrama de la Figura 3.11 se muestra la relación de asociación entre el documento con el tipo de documento y las observaciones del documento. Además de la relación entre las clases prueba y documento, ya que una prueba podrá tener asociado un documento para brindar mayor información de esta. TipoDocumento (from Use Case View) ObservacionDocumento (from Use Case View) Documento (from Use Case View) 1 0..n 1 0..n Prueba (from Use Case View) 0..n 0..1 48 • En el sub-paquete de planificación se muestra las clases relacionadas a los procesos de enviar fecha, aceptar y rechazar fecha, detener requerimiento y asignar recurso. (Ver Cuadro 3.16) El diagrama de clases correspondiente al presente sub-paquete se observa en la Figura 3.12 Cuadro 3.16 : Clases- Sub Paquete Planificación Clase Descripción Requerimientos Detenidos Clase que representa los requerimientos que se han detenido para atender a otro de mayor prioridad. Requerimiento Clase definida en el sub-paquete requerimiento. Requerimiento (from Use Case View) RequerimientoDetenido (from Use Case View) 1 0..n Figura 3.12 : Diagrama Clases – Sub Paquete Planificación En la Figura 3.12 se muestra la relación de asociación entre la clase requerimiento y requerimientos detenidos; ya que un requerimiento puede detener a 0 ó muchos requerimientos pero a su vez los requerimientos solo podrán ser detenidos por un solo requerimiento. 3.6.2 Paquete Tarea Se mostrará una breve descripción de cada clase considerada dentro del paquete de Tarea. (Ver Cuadro 3.17). Cuadro 3.17 : Clases - Paquete Tarea Clase Descripción Hora Clase que representa las horas registradas reales diariamente. Actividad Pendiente Clase que representa las actividades pendientes de los usuarios. Solución Clase que representa la solución del requerimiento asociadas a una plantilla. Objeto Clase que representa los objetos que se van a utilizar en un requerimiento. Interrupción Clase que contiene el historial de incidencias ocurridas para cada requerimiento. 49 Cuadro 3.17 : Clases - Paquete Tarea (continuación) Clase Descripción Interrupción Clase que contiene el historial de incidencias ocurridas para cada requerimiento. Requerimiento Clase definida en el sub-paquete requerimiento. Estado Clase Clase definida en el paquete de Administración. Tipo Tarea Clase definida en el paquete de Administración. Información Usuario Clase definida en el paquete de Administración. Usuario Clase definida en el paquete de Administración. Plantilla Clase definida en el paquete de Administración. Etapa Clase definida en el paquete de Administración. Tarea Clase definida en el paquete de Administración. En la Figura 3.13 se observa el diagrama de clases correspondiente al presente paquete. En el diagrama de la Figura 3.13 se muestra las principales relaciones de asociación presentes en el paquete tales como: las clases solución y hora, ya que las horas registradas por el personal de sistemas podrá estar relacionada a la solución de un requerimiento. Etapa (from Use Case View) Tarea (from Use Case View) Interrupcion (from Use Case View) TipoTarea (from Use Case View) Objeto (from Use Case View) Hora (from Use Case View) Plantilla (from Use Case View) Requerimiento (from Use Case View) EstadoClase (from Use Case View) 1 1..n Solucion (from Use Case View) 1 0..n 0..n1..n 1..n 0..n 0..1 0..n 1 0..n 1 1 1 1..n InformacionUsuario (from Use Case View) 0..1 0..n Usuario (from Use Case View) 1 1..n ActividadPendiente (from Use Case View) 1 0..n Figura 3.13 : Diagrama Clases –Paquete Tarea 50 3.6.3 Paquete Administración A continuación se mostrará una breve descripción de las clases consideradas dentro del paquete de Administración. (Ver Cuadro 3.18) Cuadro 3.18 : Clases - Paquete Administración Clase Descripción Tipo Movimiento Clase que representa los tipos de movimientos asociados a un requerimiento. Tipo Documento Clase que representa los tipos de documentos que contempla el Sistema. Clase Representa a las clases empleadas en el sistema, tales como requerimiento, tarea. Estado Clase Clase que representa los estados de los requerimientos, tareas y documentos. Prioridad Clase que representa la prioridad que puede tomar un requerimiento. Flujo Clase que representa las acciones que se pueden tomar sobre un requerimiento dependiendo de los estados y los roles. Tipo Flujo Clase que representa al tipo de flujo al cual estará asociado una clase. Categoría Clase que representa las diferentes categorías presentes en el requerimiento. Tipo Requerimiento Clase que representa el tipo que puede tomar un requerimiento. Sistema Clase que representa los sistemas contemplados para el sistema. Sub-Sistema Clase que contiene todos los sub sistemas de la empresa asociados a un sistema. Tipo Tarea Clase que representa los diferentes tipos de tarea. Área Clase que representa las áreas de la empresa. Sede Clase que representa las sedes de la empresa. Plantilla Clase que representa a las plantillas de etapas y tareas predefinidas para los diversos tipos de requerimiento. Etapa Plantilla Clase que representa las etapas presentes en las plantillas. Tarea Plantilla Clase que representa las tareas de cada una de las etapas de una plantilla. Usuario Clase que representa a los usuarios que harán uso del sistema. Centro de Costo Clase que representa cada centro de costo existente en la empresa. Cargo Clase que representa a los roles que pueden cumplir los usuarios del sistema. Información Usuario Clase que contiene la información de los usuarios como el rol que posee, el área y sede a las que pertenece. Responsable Informática Clase que representa los responsables a los que le llegaría el requerimiento para ser aceptados dependiendo del tipo, sistema, subsistema y sede. Responsable Solución Clase que contiene al responsable de solución. 51 En la Figura 3.14 se observa el diagrama de clases correspondiente al presente paquete. Figura 3.14 : Diagrama Clases –Paquete Administración En el diagrama de la Figura 3.14 se muestra las principales relaciones de asociación que existen entre las clases presentes en el paquete de administración las cuales sirven para definir el sistema. 3.7 Diagrama de Estados Un estado es una condición o situación durante la vida de un objeto durante la cual éste satisface alguna condición, lleva a cabo alguna actividad o espera algún evento. [Rumbaugh]. Un estado del objeto es definido por sus atributos. [UML Bible] El Diagrama de estados especifica las secuencias por las que atraviesa un objeto en respuesta a distintos eventos durante su vida en una aplicación. Cada objeto está en un estado en cierto instante. [New Horizons]. 52 No se pretenderá diseñar diagramas de estados para todas las clases del sistema, sino sólo para aquellas que exhiban un comportamiento interesante de forma que la elaboración del diagrama de estados ayude a entender dicho comportamiento; estas clases son: Requerimiento, Tarea y Documento. Para cada una de ellas se describirá cada uno de los estados por los que pasa y se mostrará su respectivo diagrama de estados. Los estados de las diversas clases se encuentran especificados en el Anexo C. 3.7.1 Requerimiento Cuando el usuario solicitante ingresa su pedido en el sistema, el requerimiento se encuentra en estado Registrado. Una vez registrado el requerimiento en el sistema, el responsable de área puede aprobar, retornar, reasignar o desaprobar el pedido. Cuando lo apruebe el estado del requerimiento, se actualizará a Aprobado, si se retorna o reasigna, el estado permanece en registrado; en caso lo desapruebe el estado será Desaprobado. Luego de aprobarse el requerimiento, el responsable de informática analiza la solicitud y puede rechazar o aceptar la petición, actualizando el estado a Rechazado o Aceptado, respectivamente. Después de aceptar el requerimiento, deberá asignarle un responsable de solución o un encargado de soporte cambiando el estado del pedido a Asignado. Una vez registrada las primeras horas invertidas en su solución, el requerimiento cambia al estado En Desarrollo. El requerimiento permanece en este estado hasta que se finaliza la solución y se instala en producción, el responsable de solución o encargado de soporte deberá enviar una encuesta de satisfacción, es en este momento que el estado del requerimiento cambia a Por Calificar. El usuario solicitante o responsable de área deberán responder la encuesta del requerimiento y este pasa inmediatamente al estado Por Cerrar y permanece en este estado hasta que el responsable de informática cierre el pedido cambiando el estado a Cerrado; finalizando de esta manera el ciclo de vida del requerimiento. A partir del estado aprobado el responsable de informática podrá cancelar el requerimiento en cualquier momento cambiando el estado del pedido a Cancelado. 53 En la Figura 3.15 se muestra el diagrama de estados de la clase requerimiento: Figura 3.15 : Diagrama de Estado-Requerimiento 54 3.7.2 Tarea Cuando el responsable de informática acepta el requerimiento se crea la plantilla de solución con etapas y tareas; cada una de las tareas de la plantilla se registran en el sistema con estado Creada, lo mismo sucede cuando el responsable de solución, encargado de soporte, asistente de soporte o ejecutor añade una nueva tarea a la solución sin asignarle un ejecutor. En el instante en que se le asigna un ejecutor a la tarea, su estado cambia a Asignada. Cuando el ejecutor asignado registra las primeras horas invertidas en la ejecución de la tarea, esta pasa al estado En Desarrollo. La tarea permanece en este estado hasta que se finalice su ejecución; en ese momento el ejecutor deberá cerrarla actualizando el estado de la tarea a Cerrada finalizando su ciclo de vida. Cuando la tarea se encuentra en estado asignada o en desarrollo, el responsable de informática, solución o encargado de soporte podrá interrumpirla (se detiene su ejecución para atender otra tarea) cambiando su estado a Interrumpida. Al registrar nuevamente horas para dicha tarea, su estado se actualiza a En Desarrollo. En el diagrama de la Figura 3.16 se aprecia los estados por los que pasa un objeto de la clase tarea: Figura 3.16 : Diagrama de Estado-Tarea 55 3.7.3 Documento El ciclo de vida de un objeto de la clase Documento se inicia en estado Creado cuando un actor adjunta un documento en el sistema relacionándolo a un requerimiento. Estando en estado creado, el personal de sistemas podrá modificar el documento del tipo registro de atención, cambiando el estado a Actualizado. Si se trata de un documento tipo acta, luego de crearse, se deberá solicitar la aprobación de dicho documento, en ese momento el estado del documento se actualiza a Por Aprobar. Posteriormente, el actor al que se le haya solicitado su aprobación, podrá aprobar o desaprobar el documento, modificando el estado a Aprobado o Desaprobado respectivamente. Los estados por los que pasa un objeto de la clase documento se muestran en el diagrama de estados de la Figura 3.17: Figura 3.17 : Diagrama de Estado-Documento 56 4. Diseño El objetivo de este capítulo es mostrar a detalle el diseño del sistema. Se utilizará UML (de las siglas en inglés Unified Modeling Language) como lenguaje estándar para la construcción de los artefactos del software. Se mostrará la arquitectura del sistema, el diagrama de secuencias y el diseño de la interfaz gráfica de los procesos principales agrupados por paquetes. Así como el diagrama de entidad relación. 4.1 Arquitectura del Sistema Se necesita una arquitectura que describa los elementos del modelo que son más importantes. Estos elementos significativos, arquitectónicamente hablando, incluyen algunos de los subsistemas, dependencias, interfaces, colaboraciones, nodos y clases activas. Describen los cimientos del sistema, que son necesarios como base para comprenderlo, desarrollarlo y producirlo económicamente. La arquitectura del Sistema de Software abarca decisiones importantes sobre la 57 organización del sistema software y los elementos estructurales que compondrán el sistema y sus interfaces. [Rumbaugh] La idea de desarrollar el proyecto bajo la arquitectura Web, se sustenta en que los usuarios no requerirán instalar la aplicación en sus computadoras personales, debido a que se encuentra en una página Web accesible desde una computadora con acceso a Internet. Así mismo, las actualizaciones de la aplicación se harán sobre un solo lugar (servidor de aplicaciones) y no será necesario reinstalar la aplicación en cada una de las computadoras de los usuarios del sistema. A continuación se muestra el diagrama de arquitectura web (Figura 4.1) en la que figura el navegador, el servidor de aplicaciones que para el sistema será Apache Tomcat y la base de datos con la que contará el sistema (Oracle 10g). Figura 4.1 : Arquitectura Web El desarrollo del sistema se realizó tomando como base la arquitectura MVC de java. Esta arquitectura fue diseñada para reducir el esfuerzo de programación necesario en la implementación de sistemas múltiples y sincronizados de los mismos datos. Su principal característica es que el Modelo, las Vistas y los Controladores se tratan como entidades separadas; esto hace que cualquier cambio producido en el Modelo se refleje automáticamente en cada una de las Vistas. [Tecsup]. En la figura 4.2 se observa los componentes del modelo-vista- controlador. 58 Figura 4.2 : Arquitectura MVC Este modelo de arquitectura presenta varias ventajas: • Hay una clara separación entre los componentes de un programa; lo cual nos permite implementarlos por separado • Hay un API muy bien definido; cualquiera que use el API, podrá reemplazar el Modelo, la Vista o el Controlador, sin aparente dificultad. • La conexión entre el Modelo y sus Vistas es dinámica; se produce en tiempo de ejecución, no en tiempo de compilación. Al incorporar el modelo de arquitectura MVC a un diseño, las piezas de un programa se pueden construir por separado y luego unirlas en tiempo de ejecución. Si uno de los Componentes, posteriormente, se observa que funciona mal, puede reemplazarse sin que las otras piezas se vean afectadas. [Tecsup] El sistema se desarrollará haciendo uso del Framework Struts2. En la programación se ha empleado algunos patrones y clases como: Action, Logic, DAO, Bean y jsp. Los action son la unidad lógica que se encarga de realizar el proceso del negocio, y finalmente envían la ejecución al objeto definido en el forward. La clase Logic es la unidad lógica del negocio que sirve para controlar el flujo de la aplicación sirviendo de conexión entre el action y las clases de acceso a datos (DAO). Los DAO son las clases de acceso a datos, se encargan de acceder a la base de datos y obtener o insertar la data en las tablas. Los Bean almacenan datos de las entidades y proveen acceso a sus variables privadas con "getters" y "setters"; permiten asegurar la persistencia haciendo posible guardar un objeto de java en una tabla de base de datos. Los jsp (Java Server Page) son páginas dinámicas con la que interactúa el actor, contienen código html y que se encarga de mostrar la información necesaria en tiempo de ejecución. 59 4.2 Procesos En esta sección se presentará el diagrama de secuencia y el diseño de la interfaz gráfica de los principales procesos del sistema agrupados en paquetes. Los diagramas de secuencias muestra la interacción entre objetos dispuestos en secuencia temporal. En particular, muestra los objetos que participan en la interacción y la secuencia de mensajes intercambiados entre ellos. Un diagrama de secuencia incluye secuencias de tiempo, pero no incluye relaciones de objetos. [UML Bible]. Es útil para observar la vida de los objetos en el sistema, identificar llamadas a realizar o posibles errores del modelado estático, que imposibiliten el flujo de información o de llamadas entre los componentes del sistema. [New Horizons] El diseño de la interfaz gráfica muestra las principales pantallas del sistema para inducir al lector en un entendimiento visual sobre las bondades del mismo. El diseño de los principales procesos serán mostrados según los paquetes definidos en el punto 3.2 4.2.1 Paquete de Requerimiento En el presente paquete se mostrará el diagrama de secuencia y la interfaz gráfica de sus principales procesos, los demás procesos del paquete serán mostrados en el Anexo D. Los principales procesos de este paquete son: registrar requerimiento, aprobar requerimiento, aceptar requerimiento, asignar recurso y mantener prueba. a) Registrar Requerimiento Este proceso permite el registro de un requerimiento por cualquier usuario de un área, teniendo la posibilidad de adjuntar documentos. En la Figura 4.3 se puede observar el diagrama de secuencia del proceso registrar requerimiento. Este diagrama ilustra la interacción entre los objetos 60 involucrados para registrar un requerimiento, el cual será resumido a continuación: El actor del sistema elige la opción Requerimiento/Nuevo en el menú del sistema. A continuación se muestra la página dinámica “jpla_vNuevoDetalleRequerimiento” que contiene todos los campos necesarios para registrar un requerimiento. Cuando el actor selecciona un Tipo de Requerimiento, la página dinámica hace un llamado al action “NuevoDetalleRequerimientoAction” para que este cargue la lista de categorías existentes para el tipo seleccionado. El action llama al método cargarCategoriaTipo() del objeto “ComboLogic”, el cual invoca al método del mismo nombre del objeto “CategoriaDAO” quien se encarga de conectarse a la base de datos y obtener la lista de categorías correspondientes al tipo seleccionado. Cuando el actor selecciona un sistema ocurre un proceso similar al seleccionar el tipo, con la diferencia que los objetos involucrados en este caso son: el mismo action “NuevoDetalleRequerimientoAction”, también interviene el objeto “ComboLogic”, pero el método invocado es cargaSubSistema() y el objeto DAO involucrado es “SubSistemaDAO” quien devuelve la lista de subsistemas obtenidos de la base de datos. Luego de que el actor ha ingresado todos los campos requeridos, presiona el botón Guardar, en este momento el jsp llama al método insertarRequerimiento() del action el cual se encarga de realizar las validaciones necesarias; de encontrarse todo conforme invoca al método insertarRequerimiento() del objeto “RequerimientoLogic”, éste hace uso del objeto “RequerimientoDAO” para poder registrar el nuevo requerimiento en la base de datos. La interfaz gráfica del Proceso Nuevo Requerimiento, permite registrar un requerimiento. A esta pantalla se accede seleccionando la opción “Nuevo” del menú. Para registrar un nuevo requerimiento se deberá seleccionar los campos: tipo, categoría, sistema, subsistema, prioridad e ingresar: referencia y descripción; luego seleccionar la opción “Guardar” (se mostrará el campo del “IdRequerimiento”, y se habilitarán los botones “Nuevo” y “Eliminar”, estos permiten adjuntar documentos y eliminar documentos relacionados a este requerimiento). Para eliminar documentos, se selecciona el documento que se desea eliminar y luego el botón “Eliminar”. Este documento será eliminado de la lista de documentos. 61 Figura 4.3 : Diagrama Secuencia – Registrar Requerimiento En la Figura 4.4 se observa la pantalla de Registrar Requerimiento. Figura 4.4 : Interfaz Gráfica – Registrar Requerimiento 62 b) Aprobar Requerimiento El presente proceso permite al responsable de área aprobar un requerimiento para ser enviado al área de sistemas para su futura solución. En el diagrama de secuencia del proceso aprobar requerimiento que se mostrará en la Figura 4.5 ilustra la interacción entre los objetos involucrados para aprobar un requerimiento, la cual será resumida a continuación: El responsable de área elije la opción requerimientos por aprobar y selecciona un requerimiento para aprobarlo. A continuación se muestra la página dinámica jpla_modDetalleRequerimientoResponsableArea la cual mostrará la información necesaria al actor (Responsable de Área) para que este pueda actualizar el requerimiento y enviar el movimiento de aprobación del requerimiento además de aprobarlo. Cuando el responsable de área aprueba el requerimiento la página dinámica se comunicará con la unidad lógica ModificarDetalleRequerimientoAction para que este realice los procesos de actualizar requerimiento y enviar el movimiento. El action llama al método aprobarRequerimiento(datos) del objeto RequerimientoLogic, el cual invoca a los métodos actualizarRequerimiento(datos) e insertarMovimiento(datos) de los objetos RequerimientoDAO y MovimientoDAO, respectivamente, quienes se encargan de conectarse a la base de datos para actualizar los datos del requerimiento e insertar un nuevo movimiento relacionado al requerimiento que se esta aprobando. La interfaz gráfica de la Figura 4.6 permite al responsable de área aprobar el requerimiento para que sea enviado al área de sistema para su futura solución. El responsable de área podrá acceder a esta pantalla al seleccionar “Requerimientos por Aprobar” de su bandeja de entrada y seleccionar un requerimiento para ver su detalle. El responsable de área podrá actualizar el detalle registrado, además de: aprobar, rechazar, reasignar (enviarlo a otro responsable de área) o retornar el requerimiento. 63 Figura 4.5 : Diagrama Secuencia – Aprobar Requerimiento Figura 4.6 : Interfaz Gráfica – Aprobar Requerimiento 64 c) Aceptar Requerimiento El presente proceso permite al responsable de informática aceptar el requerimiento para a asignarle un responsable y dar la solución. En el diagrama de secuencia del proceso Aceptar requerimiento que se muestra en la Figura 4.7, se ilustra la interacción entre los objetos, la cual será resumida a continuación: El responsable de informática elige la opción requerimientos por aceptar y selecciona un requerimiento para aceptarlo. A continuación, se muestra la página dinámica jpla_modDetalleRequerimientoResponsableInformatica, la cual mostrará la información necesaria al actor (Responsable de Informática) para que este pueda actualizar el requerimiento y enviar el movimiento de aceptación además de aceptarlo. Cuando el responsable de Informática acepta el requerimiento, la página dinámica se comunica con la unidad lógica ModificarDetalleRequerimientoAction para que éste realice los procesos de actualizar requerimiento y enviar el movimiento. El action llama al método aceptarRequerimiento(datos) del objeto RequerimientoLogic, el cual invoca a los métodos actualizarRequerimiento(datos) e insertarMovimiento(datos) de los objetos RequerimientoDAO y MovimientoDAO, respectivamente, quienes se encargan de conectarse a la base de datos para actualizar los datos del requerimiento e insertar un nuevo movimiento relacionado al requerimiento que se esta aceptando. La presente interfaz gráfica de la Figura 4.8 permite al responsable de informática aceptar el requerimiento para que sea atendido por el área de sistemas y darle solución. El responsable de informática podrá acceder a esta pantalla al seleccionar “Requerimientos por Aceptar” de su bandeja de entrada y seleccionar un requerimiento para ver su detalle. El responsable de informática podrá actualizar el detalle registrado, además de: aceptar o rechazar el requerimiento. 65 Figura 4.7 :Diagrama Secuencia – Aceptar Requerimiento Figura 4.8 : Interfaz Gráfica – Aceptar Requerimiento 66 d) Asignar Recurso El presente proceso permite al responsable de informática consultar la carga de trabajo del personal de sistemas y asignar un responsable para dar solución al requerimiento. En el diagrama de secuencia del proceso Asignar recurso que se muestra en la Figura 4.9, se ilustra como interactúan los objetos del presente proceso: El responsable de informática elige la opción requerimientos por asignar y selecciona un requerimiento para asignar un responsable para dar solución. A continuación se muestra la página dinámica jpla_asignarResponsableInformatica, la cual muestra la información necesaria al actor (responsable de Informática) para que este pueda: asignar un responsable solución al requerimiento, enviar el movimiento de asignación y consultar la carga de trabajo del personal de sistemas. Cuando el actor consulta los recursos, la página dinámica hace un llamado al action UsuarioAction para que este obtenga la lista de usuarios del personal de sistemas y su disponibilidad. El action llama al método consultarDisponibilidad(datos) del objeto UsuarioLogic el cual invoca al método del mismo nombre del objeto UsuarioDAO quien se encarga de conectarse a la base de datos y obtener la lista de disponibilidad del personal de sistemas. La información obtenida se muestra a través de la página emergente jpla_pConsultaRecurso. Al seleccionar el actor un recurso, la página se cierra y envía los datos a la página dinámica jpla_asignarResponsableInformatica, es a través de esta página que el actor guarda los datos ingresados; la página hace un llamado al action cuando el actor asigna ModificaRequerimientoAction para que este realice los procesos de asignar el requerimiento y enviar el movimiento. El action llama al método asignarRequerimiento(datos) del objeto RequerimientoLogic el cual invoca a los métodos asignarRequerimiento(datos) e insertarMovimiento(datos) de los objetos RequerimientoDAO y MovimientoDAO, respectivamente, quienes se encargan de conectarse a la base de datos para asignar el requerimiento e insertar un nuevo movimiento relacionado al requerimiento que se esta asignando. 67 Figura 4.9 : Diagrama Secuencia – Asignar Recurso La interfaz gráfica de Asignar Recuso que se muestra en la Figura 4.10, permite consultar la carga de trabajo del personal del sistema y asignar un responsable para la solución del requerimiento. Para acceder a la esta pantalla, el responsable de informática deberá seleccionar “Requerimiento por Asignar” de su bandeja de entrada y seleccionar uno de los requerimiento. Para asignar un responsable se deberá ingresar el usuario, la fecha de inicio estimada y la fecha fin estimada; caso contrario se podrá seleccionar un responsable a través de una consulta, la cual muestra la carga de trabajo del personal de sistemas y se deberá ingresar la fecha fin estimada. 68 Figura 4.10 : Interfaz Gráfica – Asignar Recurso e) Mantener Prueba Este proceso permite realizar el mantenimiento de las pruebas; es decir registrar una prueba, modificarla o eliminarla. Se detallará el evento principal Registrar Prueba, los eventos secundarios se podrán encontrar en el Anexo D. En la Figura 4.11 se puede observar el diagrama de secuencia del proceso mantener prueba. En este diagrama se puede apreciar la interacción entre los objetos, la cual será resumida a continuación: Cuando el Responsable de Solución o Ejecutor selecciona la opción Nuevo en la pantalla de Pruebas, el sistema muestra la página dinámica “jpla_pNuevaPrueba”, la cual es una pantalla de tipo “popup” con la que interactúa el actor y que se encarga de solicitar los datos necesarios para registrar una prueba. Luego de ingresar los datos, el actor selecciona el botón Guardar y en la página dinámica se hace el llamado al action “PruebaAction”, que se encarga de hacer las validaciones necesarias, buscar el código de la etapa de pruebas y finalmente grabar la prueba ingresada. El action llama al método buscaEtapaPrueba() del objeto SoluciónLogic quien llama al objeto 69 SolucionDAO, es este objeto el que se encarga de conectarse a la base de datos y obtiene el código de la etapa de pruebas. Para insertar la prueba el action invoca al objeto “PruebaLogic”, el cual se encarga de llamar al método insertaPrueba() de “PruebaDAO” donde se accede a la base de datos y registra la nueva prueba en la tabla TAREAXETAPAXSOLUCION, la nueva tarea de la prueba para el usuario asignado y en la tabla PRUEBA la nueva prueba. Figura 4.11 : Diagrama de Secuencia - Mantener Prueba La interfaz gráfica de Nueva Prueba permite registrar una prueba y asignarla a un usuario. A esta pantalla se accede desde la pestaña de Pruebas, “Nueva”. Para registrar una prueba se deberá ingresar la descripción de la prueba y seleccionar al usuario al que se desea asignar la prueba; luego seleccionar la opción “Guardar” . También se podrá adjuntar un documento de caso de prueba seleccionando la opción Documentos. En la Figura 4.12 se observa la pantalla de Lista de Pruebas y la de Nueva Prueba. 70 Figura 4.12 : Interfaz Gráfica - Mantener Prueba 71 4.2.2 Paquete de Tarea Los principales procesos de este paquete son: mantener solución, consultar disponibilidad y registrar horas reales trabajadas. Los otros procesos de este paquete se podrán consultar en el Anexo D. f) Mantener Solución Este proceso permite realizar el mantenimiento de la solución; es decir registrar una etapa o tarea, modificarlas o eliminarlas de la solución. Se detallará el evento principal Registrar Etapa, los eventos secundarios se podrán encontrar en el Anexo D. En la Figura 4.13 se puede observar el diagrama de secuencia del proceso mantener solución. En este diagrama se puede apreciar la interacción entre los objetos, el cual será resumido a continuación: Cuando el Responsable de Solución o Ejecutor selecciona una etapa y el botón Nuevo en la pantalla de Solución, el sistema muestra la página dinámica “jpla_pNuevaEtapa” que es una pantalla de tipo “popup” que se encarga de solicitar los datos necesarios para registrar una etapa a la solución. Luego de ingresar los datos, el actor selecciona el botón Guardar y en el jsp se hace el llamado al action “SolucionAction” que se encarga de hacer las validaciones necesarias, calcular la fecha de inicio y fin estimada, grabar la etapa y finalmente grabar la tarea. El action llama al método calculaFechaInicioEstimada() del objeto SoluciónLogic. Para insertar la etapa el action invoca al método insertaEtapa() del objeto “SoluciónLogic”, el cual se encarga de llamar a “SolucionDAO” quien accede a la base de datos y registra la nueva etapa en la tabla ETAPAXSOLUCION y devuelve el código de la etapa registrada para que el action invoque al método insertaTarea() del objeto ya instanciado “SoluciónLogic”. La nueva tarea es registrada por “SolucionDAO” en la tabla TAREAXETAPAXSOLUCION. 72 Figura 4.13 : Diagrama de Secuencia - Mantener Solución La interfaz gráfica de Nueva Etapa permite registrar una etapa y su respectiva tarea. A esta pantalla se accede desde la pestaña de Solución, seleccionando una etapa y luego la opción “Nuevo”. Para registrar una nueva etapa se deberá ingresar el nombre de la etapa; para la tarea se tendrá que seleccionar el tipo de tarea, ingresar el nombre y descripción de la tarea, seleccionar el ejecutor e ingresar el tiempo estimado de duración de la tarea; luego seleccionar la opción “Guardar” (se mostrará el campo del “Cod. Tarea”). En la Figura 4.14 se observa la pantalla de Mantener Solución – Registrar Etapa. 73 Figura 4.14 : Interfaz Gráfica - Mantener Solución 74 g) Registrar Horas Reales Trabajadas Este proceso permite al personal de sistemas registrar las horas reales que le toma en desarrollar una tarea relacionada a un requerimiento, registrar horas indirectas (tiempo invertido en tareas que no están relacionadas a un requerimiento) y registrar horas libres (tiempo invertido en permiso, vacaciones, feriado y descanso medico). Se detallará el evento principal registrar horas relacionadas a un requerimiento. Los eventos secundarios se podrán encontrar en el Anexo D. En el diagrama secuencia del proceso registrar horas reales trabajadas que se muestra en la Figura 4.15, se ilustra la interacción entre los objetos, el cual será resumido a continuación: El personal del área de sistemas elige la opción Tarea del Menú del sistema. A continuación se muestra la página dinámica jpla_horas, el actor podrá visualizar las horas ingresadas por tarea por día para la presente semana. Cuando el actor registra sus horas la página dinámica se comunica con la unidad lógica HorasAction para que registre las horas. El action llama al método grabarHoras(datos) del objeto HorasLogic, el cual invoca al método grabarHoras(datos) del objeto HorasDAO quien se encarga de conectarse a la base de datos para insertar las horas relacionadas a un requerimiento. La interfaz gráfica de Registrar Horas Reales Trabajadas que se muestra en la Figura 4.16, permite al personal de sistemas registrar el tiempo real que invierte en desarrollar una tarea, ya sea relacionada a un requerimiento o no. A esta pantalla se accede seleccionando la opción “Tarea” del menú. Para registrar la disponibilidad deberá ingresar el tiempo real invertido en desarrollar una tarea por día según el listado de tareas que se muestra y guardar. 75 Figura 4.15 : Diagrama Secuencia - Registrar Horas Reales Trabajadas Figura 4.16 : Interfaz Gráfica - Registrar Horas Reales Trabajadas 76 h) Consultar Disponibilidad Este proceso permite consultar la disponibilidad de los recursos de sistemas y seleccionar uno de ellos para ser asignado. En la Figura 4.17 se puede observar el diagrama de secuencia del proceso consultar disponibilidad. En este diagrama se puede apreciar la interacción entre los objetos, el cual será resumido a continuación: Cuando el Responsable de Desarrollo, Responsable de Soporte, Encargado de Soporte o Responsable de Solución selecciona la opción de consultar recurso, el sistema muestra la página dinámica “jpla_pConsultarRecurso” que es una pantalla de tipo “popup” que se encarga de solicitar los filtros de búsqueda necesarios para mostrar la disponibilidad de los recursos. Luego de ingresar los filtros, el actor selecciona el botón Buscar y la página dinámica hace el llamado al action “UsuarioAction” quien hace la carga de usuarios según los filtros seleccionados y por cada usuario se busca su disponibilidad. El action llama al método ontieneUsuarioRol() del objeto UtilitarioLogic quien llama a UtilitarioDAO y devuelve la lista de usuarios. Por cada usuario el action realiza la consulta de disponibilidad invocando al objeto “UsuarioLogic”. “UsuarioDAO” es quien devuelve la lista de tareas asignadas al usuario. Finalmente el action obtiene la fecha de inicio estimada de cada tarea haciendo uso de los objetos SolucionLogic y SolucionDAO. En la pantalla de Consultar Disponibilidad (Figura 3.18), el personal de sistemas podrá ver la carga de trabajo con la que cuenta cada recurso. Se podrá hacer la búsqueda por nombre y apellidos del recurso, sede y/o nivel. En el resultado se mostrará el login del recurso, la tarea, el código del requerimiento al que pertenece la tarea, el área, estado y fechas reales y aproximadas. 77 Figura 4.17 : Diagrama de Secuencia - Consultar Disponibilidad Figura 4.18 : Interfaz Gráfica - Consultar Disponibilidad 78 4.2.3 Paquete de Administración A continuación se detalla el diseño de los siguientes procesos: mantener flujo y mantener plantilla. El resto de los procesos de este paquete serán diseñados en el Anexo D. i) Mantener Plantilla Este proceso permite generar la plantilla solución según tipo y categoría del requerimiento. En el diagrama de secuencia del proceso Mantener Plantilla que se muestra en la Figura 4.19, se ilustra la interacción entre los objetos, la cual será resumida a continuación: Cuando el Administrador del Sistema selecciona la opción Plantilla, el sistema muestra la página dinámica jpla_vAdminPlantilla, la cual permite generar la plantilla. Cuando el actor selecciona un Tipo de Requerimiento, el jsp hace un llamado al action “AdminPlantillaAction” para que este cargue la lista de categorías existentes para el tipo seleccionado. El action llama al método cargarCategoriaTipo() del objeto “ComboLogic”, el cual invoca al método del mismo nombre del objeto “CategoriaDAO” quien se encarga de conectarse a la base de datos y obtener la lista de categorías correspondientes al tipo seleccionado. Luego que el actor haya seleccionado el tipo y la categoría, cuando el actor selecciona +Etapa, la página dinámica hace un llamado al action EtapaPlantillaAction para que este muestre la página dinámica jpla_vNuevaEtapaPlantilla, cuando el actor realiza la búsqueda de la etapa, la página dinámica invoca al action EtapaPlantillaAction para que éste realice la búsqueda de la etapa. El action llama al método buscarEtapa(datos) del objeto AdminPlantillaLogic, el cual invoca al método buscarEtapa(datos) del objeto AdminPlantillaDAO quien se encarga de conectarse a la base de datos y realizar la búsqueda. Cuando el usuario selecciona la etapa, la página dinámica jpla_vNuevaEtapaPlantilla invoca al action TareaPlantillaAction para que muestre la página dinámica jpla_vNuevaTareaPlantilla; luego el usuario realiza la búsqueda de la tarea y la página dinámica jpla_vNuevaTareaPlantilla invoca al action TareaPlantillaAction para que realice la búsqueda de la tarea. El 79 action llama al método buscarTarea(datos) del objeto AdminPlantillaLogic, el cual invoca al método buscarTarea(datos) del objeto AdminPlantillaDAO quien se encarga de conectarse a la base de datos y realizar la búsqueda. Cuando el usuario selecciona la tarea en la página dinámica jpla_vNuevaTareaPlantilla, este se comunica con el action AdminPlantilla quien invoca al método guardarEtapaTareaPlantilla(datos) del objeto AdminPlantillaLogic, el cual invoca al método guardarEtapaTareaPlantilla(datos) del objeto AdminPlantillaDAO quien se encarga de conectarse a la base de datos para insertar la plantilla generada para el tipo y categoría seleccionado. Figura 4.19 : Diagrama Secuencia - Mantener Plantilla 80 La interfaz gráfica de Mantener Plantilla permite generar una plantilla solución según los tipos y categorías de los requerimientos. Para acceder a esta pantalla se accede seleccionando la opción “Plantilla” dentro del módulo de administración. Para registrar una nueva etapa deberá seleccionar “Etapa” de la Figura 4.20 y se mostrara una ventana “popup” en donde se deberá seleccionar la etapa o realizar una búsqueda de esta, una vez seleccionada la etapa se mostrara otra ventana “popup” en donde se deberá seleccionar la tarea o realizar una búsqueda de la tarea que estará presente en la etapa; se mostrara la etapa generada con su respectiva tarea. Figura 4.20 : Interfaz Gráfica - Mantener Plantilla j) Mantener Flujo Este proceso permite dar mantenimiento al flujo del proceso. Se detallará el evento principal Registrar Flujo, los eventos secundarios se podrán encontrar en el Anexo D. 81 En la Figura 4.21 se puede observar el diagrama de secuencia del proceso mantener flujo. En este diagrama se puede apreciar la interacción entre los objetos, el cual será resumido a continuación: Cuando el Administrador del Sistema selecciona la opción Flujo, el sistema muestra la página dinámica “jpla_vAdminFlujo”, la que permite realizar el mantenimiento del flujo que deberá seguir cada una de las clases definidas en el sistema. Cuando el administrador selecciona la opción Nuevo, los campos de la parte superior de la pantalla se limpian, luego de que el actor haya ingresado todos los campos y presionado el botón Guardar, el action “AdminFlujoAction” se encarga de realizar una serie de validaciones, de estar todo correcto realiza el registro de la nueva ruta del flujo definido. Para esto llama al método guardarFlujo() del objeto “FlujoLogic”, el cual se encarga de instanciar un objeto “FlujoBean” con todos los datos ingresados y luego invocar a “FlujoDAO” para que acceda a la base de datos e inserte una nueva ruta en la tabla Flujo. Figura 4.21 : Diagrama Secuencia - Mantener Flujo La interfaz gráfica de Administrar Flujo permite registrar, modificar y eliminar una nueva ruta de un flujo. Para acceder a esta pantalla se accede seleccionando la opción “Flujo” dentro del módulo de administración. Para registrar una nueva ruta de un flujo se deberá seleccionar la opción Nuevo, se blanqueará todos los campos de la sección Detalle Flujo; a continuación se deberá seleccionar todos los datos solicitados como son: Estado inicial y final, 82 rol inicial y final, la acción, el tipo de flujo, si se trata de un inicio o fin de ruta; luego seleccionar la opción “Guardar” (se mostrará el campo del “Codigo”). En la Figura 4.22 se observa la pantalla de Mantenimiento de Flujo. Figura 4.22 : Interfaz Gráfica - Mantener Flujo 4.3 Diagrama Entidad Relación El diagrama de entidad relación del sistema se puede apreciar en el Anexo E. Para la elaboración de las tablas, se ha considerado algunos estándares como que el nombre de las tablas deben empezar con los cuatro primeros caracteres del nombre del sistema, seguido de la letra T la cual hace referencia a una tabla, luego el carácter ’_’, seguido del nombre de la tabla. Por ejemplo, para la tabla usuario se tendrá el siguiente nombre: JPLAT_USUARIO. Los nombres de los atributos deben respetar la siguiente nomenclatura: las cuatro primeras letras representa el nombre de la tabla a la que pertenece, una letra que representa el tipo de dato, seguido del carácter ‘_’ y finalmente el nombre del campo, como por ejemplo el nombre del atributo apellido paterno de la tabla usuario será USUAV_APELLIDOPATERNO, donde USUA es por la tabla 83 JPLAT_USUARIO, la letra V especifica que es un tipo de dato varchar2 y APELLIDOPATERNO es el nombre del atributo. Un mayor detalle de los estándares considerados para la definición de los objetos de base de datos se encuentra en el Anexo E. 84 5. Construcción El objetivo de este capítulo es presentar algunas de las consideraciones que se tuvo en cuenta durante la etapa de implementación. 5.1 Lenguaje de Programación Para la programación se seleccionó el lenguaje Java por ser uno de los lenguajes de mayor difusión en el mundo, de uso libre y contar con gran cantidad de herramientas, componentes y librerías desarrolladas por diferentes organizaciones que facilitan la programación y que son necesarias para el desarrollo de la herramienta a utilizar. Además, porque en el lenguaje java se tiene más experiencia entre los lenguajes utilizados actualmente en el desarrollo orientado a objetos. 5.2 Herramientas Utilizadas Para el desarrollo se utilizaron las siguientes herramientas: • J2SDK (Java 2 Software Development Kit) - Implementación de las clases estándares y la máquina virtual del lenguaje Java proporcionado por Sun 85 Microsystems. Incluye herramientas en línea de comandos para compilar, ejecutar, depurar y documentar aplicaciones Java. [JAVA] • Eclipse - Entorno de desarrollo integrado de código abierto multiplataforma basada en java. Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios. [ECLIPSE] 5.3 Entorno de Ejecución Para ejecutar la aplicación y hacer pruebas durante el desarrollo se utilizaron: • Apache Jakarta Tomcat - Servidor de aplicaciones Web en Java desarrollado por la organización Apache. Es la implementación de referencia para los contenedores Web definidos en la especificación J2EE (Java 2 Enterprise Edition) y es actualmente el más utilizado en los desarrollos independientes de este tipo. [TOMCAT] • Oracle 10g – Oracle es uno de los motores de Base de Datos más potentes y utilizados del mercado. La base de datos Oracle es la base de datos más robusta y de mayor capacidad del mundo. Es por ese motivo, que todas las multinacionales la usan. [ORACLE] • SVN – Subversión es un sistema de control de versiones. Es un sistema cliente-servidor que se puede integrar fácilmente a Apache. En el servidor se guarda un historial completo de los cambios, cada estado particular se conoce como “Revisión”. Para usarlo desde Eclipse es necesario instalar el plugin de subeclipse. [SVN] 5.4 Plan de Pruebas Para probar el sistema se crearon los casos de prueba presentados en el Anexo F. Se consideró realizar pruebas funcionales basadas en los casos de uso, que verifiquen la correcta implementación de los flujos básicos y alternativos presentados en la especificación de casos de uso (Anexo A). Para definir los casos de prueba se les ordenó de forma que se pudiera probar toda la funcionalidad del sistema con el fin de detectar los defectos y poder corregirlos antes de realizar el pase a producción del sistema. 86 Inicio Identificación de necesidad de capacitación a usuarios Elaboración de material para capacitación. Actividad de coordinación para ejecutar la capacitación. Ejecución de la capacitación. Fin 5.5 Capacitación En este capítulo se detallará el proceso de capacitación de usuarios de la empresa en donde se ha realizado una primera instalación del producto. Dicha empresa cuenta con tres sedes: Lima, Pisco y Arequipa. Inicialmente se diseñó un plan de capacitación para el personal de la empresa. (Ver Figura 5.1) Figura 5.1 : Flujo Capacitación 1) Identificación de Necesidad de Capacitación a Usuarios Se ha identificado que la sede de Lima cuenta con mayor personal administrativo, el personal de Pisco es en su mayoría obreros, ya que en esta se encuentra la planta principal, en Arequipa se tiene el menor número de empleados. Se cuenta con 300, 600 y 100 empleados, respectivamente, en cada una de las sedes. Los jefes de sistemas de cada sede han identificado el personal por área que va a tener acceso a la herramienta propuesta. Se identificó lo siguiente: 87 Cuadro 5.1 : Personal Acceso Lima Sede : Lima 191 usuarios 1 Responsable de Desarrollo 1 Responsable de Soporte 10 Responsable Solución 10 Ejecutores 3 Asistente de Soporte 3 Encargado de Soporte 125 Usuarios Solicitantes 28 Responsable de Área 10 Gerente Cuadro 5.2 : Personal Acceso Pisco Sede : Pisco 185 usuarios 1 Responsable de Desarrollo 7 Responsable Solución 3 Ejecutores 3 Encargado de Soporte 146 Usuarios Solicitantes 24 Responsable de Área 1 Gerente Cuadro 5.3 : Personal Acceso Arequipa Sede : Arequipa 83 usuarios 1 Responsable de Desarrollo 2 Encargado de Soporte 69 Usuarios Solicitantes 10 Responsable de Área 1 Gerente 2) Elaboración de Material para Capacitación Se ha elaborado dos manuales de ayuda: Manual de ayuda para los usuarios del área de sistemas y manual de ayuda para los usuarios que no son de sistemas. 88 3) Actividad de Coordinación para ejecutar la Capacitación Se dispuso que dos personas del área de sistemas Lima, que participaron en el desarrollo de la nueva herramienta, sean las encargadas de realizar las capacitaciones en las tres sedes, contando con el apoyo del área de sistemas de cada una de las sedes para las presentaciones. Se coordinó que se brindará dos tipos de capacitaciones: presentaciones generales en cada sede con diferentes grupos de personas de diversas áreas en la que se mostrará la ruta de acceso al sistema y de forma general algunas funcionalidades de la herramienta propuesta; también se brindará las capacitaciones personalizadas donde se trata de reunir a usuarios solicitantes y el jefe del área. Las capacitaciones para los gerentes van a ser individuales. El orden para ejecutar las capacitaciones son: sede Lima, sede Pisco y por último sede Arequipa. 4) Ejecución de la Capacitación En las presentaciones generales se invirtió un total de 16 horas distribuidas de la siguiente manera: en la sede de Lima y Pisco se realizaron 4 presentaciones en cada una y en Arequipa se realizó 1 presentación. Cada presentación tuvo una duración de 2 horas. En las capacitaciones personalizadas se invirtió un total de 33 horas distribuidas de la siguiente manera: en la sede de Lima se invirtió 10 horas, en Pisco se efectuaron en 15 horas y en Arequipa por contar con menor número de personal se realizaron en 8 horas. 5.6 Migración La empresa mencionada en el capitulo 5.5 contaba con una herramienta simple para registrar requerimientos, asignar tareas y solo era utilizada por el personal de sistemas. Se ha considerado a dos personas para que estén a cargo de la migración y seguimiento proporcionándoles la lista de requerimientos que se encuentran registrados en la antigua herramienta, de los cuales solo se va a tomar en cuenta los requerimientos que se encuentren en estado de desarrollo, que son 150 registros. 89 A continuación en el cuadro 5.4 se mostrara los datos obtenidos del antiguo sistemas, los datos necesarios para la herramienta propuesta y el dato que fue ingresado. Cuadro 5.4 : Datos para Migración Nuevo Sistema Antiguo Sistema Dato ingresado IDREQUERIMIENTO Generado al migrar ID Adicionar en la descripción PLANEADO Generado al migrar FECHA_REGISTRO FECHA_REGISTRO Copiado IDESTADOREQ STATUS Copiado IDTIPO_REQ Adecuar a nuevo sistema IDCATEGORIA_REQ CATEGORÍA Adecuar a nuevo sistema IDPRIORIDAD PRIORIDAD Copiado DESCRIPCION DESCRIPCIÓN Copiado REFERENCIA REFERENCIA Copiado IDUSUARIO_REGISTRA REGISTRA Copiado IDSISTEMA SISTEMA Adecuar a nuevo sistema IDRESPONSABLE_SOLUCION RESPONSABLE Copiado Como se puede apreciar en el cuadro 5.4 se obtuvieron datos que fueron copiados idénticamente para ser ingresados, otros datos son generados al migrar y se encontraron datos para ser adecuados al sistema, siendo estos los más críticos para el desarrollo de la solución del requerimiento, por lo que se ha tenido que analizar cada requerimiento para poder registrar el dato más adecuado según las necesidades del nuevo sistema. El análisis de los requerimientos han sido realizados en 2 días útiles y la herramienta utilizada fue excel, ya que nos permite visualizar toda la información; al mismo tiempo esta herramienta será utilizada también para la carga de data. La carga de la información se realizo en 30 minutos, después de la hora de trabajo, para lo cual se utilizó un administrador de base de datos y el archivo excel con la lista de requerimientos que serán migrados. Se realizó seguimiento a los requerimientos que fueron migrados y se ha identificado problemas para el desarrollo de la solución, ya que la información 90 obtenida del antiguo sistema no era suficiente para adecuarla al nuevo sistema, por lo que se concluyo que los nuevos requerimientos serán administrados por la herramienta propuesta y las antiguas solicitudes serán manejados por el sistema antiguo hasta que concluyan. 91 6. Conclusiones, Recomendaciones y Ampliaciones En este capítulo se resumirá las conclusiones que se han podido obtener durante la ejecución del presente trabajo. También se brindará algunas recomendaciones para trabajos relacionados al mismo tema. Además se propondrá algunas mejoras aplicables al sistema implementado así como también nuevas funcionalidades que pueden ser añadidas a la herramienta desarrollada. 6.1 Conclusiones • La herramienta implementada cumple con la funcionalidad de registrar un requerimiento, ordenar y sistematizar el flujo de los requerimientos que los usuarios realizan; así como también, llevar un control del tiempo invertido en la solución. • El registro de las horas invertidas por tarea por el personal de sistemas ha permitido llevar un mejor control de los tiempos y ayudó a la gerencia de 92 sistemas a determinar y justificar la contratación de nuevo personal debido a la sobrecarga de trabajo de algunos de sus empleados. • Debido a que el requerimiento se asocia al área del usuario que lo registró y gracias al control del tiempo invertido en la atención de dicho pedido se puede determinar los costos incurridos por requerimiento y por área. 6.2 Recomendaciones • Luego de la obtención de los requisitos, se recomienda presentarlos al cliente y todos los responsables para que den su conformidad. • Es muy importante seguir una metodología para la planificación y desarrollo del proyecto. En este trabajo se usó como marco de referencia para el proceso de desarrollo de software a RUP. • Se debe desde un principio clasificar las tareas y asignarles un responsable a cada una de ellas. • Es muy importante realizar los casos de pruebas y de integración ya que se puede observar los defectos existentes, los cuales se pueden corregir antes de entregar el producto final. 6.3 Ampliaciones Para futuras ampliaciones en el sistema se recomienda lo siguiente: • Programar las tareas: Un requerimiento ya sea de software o hardware tiene tareas y cada una de ellas tienen una fecha de inicio estimada obtenida al seleccionar un ejecutor y una fecha fin estimada generada por la fecha de inicio y el tiempo estimado que se invertirá en el desarrollo de la tarea. Por tal razón, se hace necesaria que la herramienta permita ingresar manualmente la fecha de inicio estimada para poder estimar mejor las tareas de un requerimiento. • Asignar ejecutores: Las tareas que se desarrollan para dar solución a un requerimiento no siempre son realizadas por el personal del sistema, por tal motivo, es necesario que la herramienta propuesta permita ingresar como ejecutor a personal que no sea de sistemas y de esta forma tener el detalle de la solución del requerimiento de forma más completa y exacta. También es necesario que una tarea se pueda asignar a más de un ejecutor, haciendo de esta forma un sistema más dinámico. • Entregables por tarea: Un requerimiento tiene tareas y cada tarea puede incluir entregables. Por tal razón, se hace necesaria una herramienta que permita relacionar dichos entregables a una tarea. 93 7. Bibliografía 1. [IEEE-Std] IEEE Standard Glossary of Software Engineering Terminology. http://standards.ieee.org/reading/ieee/std_public/description/se/610.12- 1990_desc.html 2. [Sommerville] Sommerville, Ian. Ingeniería de Software. Pearson Educación. México, 2002 3. [Intersedes] Revista InterSedes © Universidad de Costa Rica -ISSN 1409- 4746 Volumen VI - Número 10  2005- Edición Digital: 26 / 07 / 2007. http://www.intersedes.ucr.ac.cr/pdfs_10/10-art_11.pdf 4. [STARTS Guide 1987] Requirements Definition and Design”, The STARTS Guide, Second Edition, Vol. 1, National Computing Center, 1987. 5. [B. Boehm. 1979] Boehm, B.W. Characteristics of Software Quality – Nueva York, North Holland, 1979. 6. [Leite 1987] Leite, J. C. S. P. "A Survey on Requirements Analysis", Advancing Software Engineering Project Technical Report RTP-071, University of California at Irvine, Department of Information and Computer Science, Jun. 1987. 7. [Rational Software] “Applying Requirements Management with Use Cases”, Rational Software Corporation, Technical Paper TP505, 1998. 8. [UTFSM] Universidad Técnica Federico de Santa María (alumnos) http://www.alumnos.inf.utfsm.cl/~rrossel/Papers/re.pdf 9. [TIC] 2007 Revista TIC. Centro de Soluciones APROVI Tijuana, B.C., México. http://www.aproviweb.gotdns.com/aprovi/boletines/ShowNoticia.aspx?Id_Not icia=3 10. [PKS] http://www.projectkickstart.com/ 11. [PNET] http://www.project.net 12. [Primavera] http://www.primavera.com/products/p6/project_man.asp 13. [P2NET] http://www.concertosupport.co.uk/brochure.pdf 14. [PC] http://www.inmotion.se/Products/ProjectCompanion/ 15. [Hitos] http://www.serbal.com.ar/ 16. [PWF] http://www.proworkflowEnterprise.com 17. [New Horizons] Curso de Análisis y Diseño Orientado a Objetos (UML), Abril 2007 18. [UML Bible] UML Bible / Tom Pender, Indianapolis, IN : Wiley, 2003 19. [Rumbaugh] The unified modeling language reference manual Rumbaugh, James. Reading, MA : Addison-Wesley, 1999. 20. [Tecsup] Curso Desarrollador de Aplicaciones Web con Java 21. [Gartner Symposium ItxPo 2004] Gartner Symposium ItxPo 2004 22. [Gerens] Escuela de Gestión y Economía. www.gerens.org 23. [Standish 1998] Standish Group. The Chaos Report. http://www.standishgroup.com/sample_research/PDFpages/chaos1998 24. [JAVA] http://www.java.sun.com 25. [ECLIPSE] http://www.eclipse.org 26. [TOMCAT] http://www,tomcat.apache.org 27. [ORACLE] http://www.oracle.com 28. [SVN] http://www.subversion.tigris.org