PONTIFICIA UNIVERSIDAD CATÓLICA DEL PERÚ FACULTAD DE CIENCIAS E INGENIERÍA HERRAMIENTA PARA GESTION DE PROYECTOS BASADA EN XPDL PARA EL PROYECTO COMPETISOFT Análisis y Diseño Tesis para optar por el Título de Ingeniero Informático, que presenta los bachilleres: Anita Yesenia Silva Lazo Sara Mirella Villegas Ortega ASESOR: Abraham Eliseo Dávila Ramón 2011 RESUMEN En el ambiente de negocios de hoy, más que nunca las organizaciones dependen del buen resultado de sus proyectos para estar en condiciones de alcanzar una multitud de objetivos; desde objetivos estratégicos hasta las mejoras operacionales diarias. El mundo en la actualidad está cambiando a velocidades inusitadas y las organizaciones deben reaccionar rápidamente abordando proyectos que las ayuden a alcanzar nuevos objetivos. La gestión de proyectos basada en una metodología ordenada, sistemática y rigurosa facilita el trabajo en los proyectos que enfrentan cada día las empresas y sus administradores. El adecuado conocimiento y aplicación de alguna metodología para la gestión de proyectos permite crear un ambiente de trabajo propicio y con menor variabilidad para obtener resultados efectivos. XPDL (XML Process Definition Language) es un lenguaje para la definición de un flujo de trabajo propuesto por la WfMC (Workflow Management Coalition). El objetivo de este lenguaje es proporcionar marco de referencia estándar que permita la importación y exportación de las definiciones de procesos. El presente trabajo de tesis presenta el desarrollo de una herramienta software basada en el lenguaje XPDL, la cual fue concebida con el propósito de realizar el seguimiento y control de cualquier tipo de proyecto de software, gestionando su avance, plazos, esfuerzos, recursos y ofreciendo la información necesaria sobre cada elemento para su administración oportuna, permite crear la instancia de una metodología a través de una interfaz grafica, así como apoyar con el manejo de otros elementos críticos en los proyectos informáticos como es la gestión de la configuración. Cabe resaltar que el presente proyecto es parte del componente de desarrollo de herramientas que viene realizando el Grupo de Investigación y Desarrollo en Ingeniería de Software y Sistemas de Información de la PUCP como parte del Proyecto COMPETISOFT (Mejora de Procesos para Fomentar la Competitividad de la Pequeña y Mediana Industria de Software de Ibero América). DEDICATORIA A Dios, que me dio la fuerza y salud para todo lo emprendido. A mis padres y hermana, Victoria, Agustín y Sofía quienes me enseñaron desde siempre a luchar para alcanzar mis metas, por el apoyo y los buenos consejos. A todos mis verdaderos amigos que están siempre conmigo y me fortalecen con su amistad. A Sara, Evelyn y Carlos por apoyarme en cada momento y por lograr juntos este objetivo. Anita Silva Lazo A Dios, por permitirme llegar a este momento tan especial en mi vida. A mis padres, Natalia y Luis por ser los pilares mas importantes de mi vida que día a día me demuestran su amor, cariño y apoyo para seguir adelante. A quien siempre me ha acompañado en cada uno de mis sueños, mi hermana Liliana. A todos mis amigos y en especial a Anita, Evelyn y Carlos por brindarme su apoyo y por lograr juntos el presente trabajo. Sara Villegas Ortega AGRADECIMIENTOS A la Pontifica Universidad Católica del Perú y en especial a la Facultad de Ciencias e Ingeniería que nos dieron la oportunidad de formar parte de ellas. Un agradecimiento muy especial al Ing. Abraham Dávila, nuestro asesor, por su amistad, apoyo, dedicación y orientación para el desarrollo del presente trabajo de tesis y llegar a la culminación del mismo. A toda las personas que de una forma o de otra nos brindaron su apoyo para la realización del presente trabajo. RECONOCIMIENTOS El presente trabajo está enmarcado dentro del proyecto 506AC0287 COMPETISOFT (Mejora de Procesos Para Fomentar la Competitividad de la Pequeña y Mediana Industria de Software de Ibero América) del programa CYTED (Ciencia y Tecnología para el Desarrollo), parcialmente financiado por PUCP- VRI - 2009-0008 PYMESOFT: Incremento de la productividad de pymes desarrolladoras de software: determinación de patrones de problemas y soluciones en un contexto de mejora de procesos (COMPETISOFT Perú 2da Fase) y con el apoyo del Departamento de Ingeniería de la Pontificia Universidad Católica del Perú. Índice General Introducción 1 Capitulo 1: Generalidades 3 1.1. Gestión de Proyectos. 3 1.1.1. Definición de proyectos 3 1.1.2. Definición de Gestión de proyectos. 5 1.1.3. Problemática de los proyectos. 6 1.1.4. Procesos según PMI. 9 1.2. Proyectos Informáticos 11 1.2.1. Procesos Principales. 11 1.2.2. Procesos de Apoyo. 13 1.2.3. Procesos Organizativos. 13 1.3. Gestión de la Configuración del Software (GCS) 14 1.3.1. Definición de la Gestión de la Configuración del Software. 14 1.3.2. Conceptos en Gestión de la Configuración del Software. 17 1.4. RUP 18 1.5. Lenguaje XPDL. 21 1.6. Proyecto COMPETISOFT 23 1.6.1. COMPETISOFT- CYTED. 24 1.6.1.1. Modelo de procesos (MoProSoft) 24 1.6.2. COMPETISOFT- PUCP. 28 1.6.3. COMPETISOFT- PUCP Tools. 29 1.7. Revisión de Productos. 34 1.7.1. Tecnológico 34 1.7.2. Descripción y Sustentación de la solución 40 1.7.3. Características principales de la herramienta propuesta 41 Capítulo 2: Análisis 44 2.1. Requerimientos Funcionales. 44 2.2. Requerimientos No Funcionales 48 2.3. Definición de la metodología utilizada para el Proyecto 48 2.4. Análisis de la Solución 50 2.4.1. Actores del sistema 50 2.4.2. Casos de Uso 51 2.5. Diagrama de Clases de Análisis 63 2.6. Restricciones del proyecto 66 2.6.1. Definición de Metodología de Desarrollo usada en la herramienta 66 2.6.2. Gestión de Configuración 68 2.7. Administración de proyectos 69 2.8. Administración de proyectos específicos 71 2.9. Gestión de la Configuración 72 Capitulo 3: Diseño 74 3.1. Arquitectura de la Solución 74 3.1.1. Patrón de Diseño Modelo Vista Controlador 77 3.1.2. Subsistemas del Software 78 3.1.3. Diagrama de Clases de Diseño 80 3.1.4. Diagrama de Secuencia 83 3.2. Diseño de Interfaz Gráfica 93 3.2.1. Criterios para el diseño de la interfaz gráfica 93 3.2.2. Estructura general del sitio 94 3.2.3. Diseño de prototipos del sistema 95 Capitulo 4: Observaciones, conclusiones y recomendaciones 115 4.1. Observaciones 115 4.2. Conclusiones 117 4.3. Recomendaciones 118 Bibliografía 119 ANEXOS A. Diagrama de Casos de Uso. B. Diagrama de Clases Análisis. C. Diccionario de Datos Clases Análisis. D. Diagrama de Clases Diseño. E: Diagrama de Secuencia. F. Plan de Pruebas del Sistema EACS Project Manager. G. Pruebas integrales del Sistema EACS Project Manager. Índice de Figuras Figura 1.1. Estadísticas de proyectos de software [Standish Group, 2009]. ........................... 8 Figura 1.2. Grupos de Procesos en la Gestión de Proyectos ................................................ 11 según PMI [Adaptado por EACS]. ......................................................................................... 11 Figura 1.3. Estructura de la norma técnica peruana [Francisco Ruiz, 2007]. ........................ 12 Figura 1.4. Grafo de evolución de versiones [SWEBOK, 2004]. ........................................... 18 Figura 1.5. Los flujos de trabajo en cada una de las fases e iteraciones del RUP [JACOBSON, 2000] ............................................................................................................... 20 Figura 1.6. Modelo de Referencia de Procesos [MOPROSOFT]. ......................................... 27 Figura 1.7. Relación entre las 3 herramientas del proyecto COMPETISOFT PUCP ............ 31 Figura 2.1. Diagrama de Casos de uso de la herramienta EACS Project Manager.............. 52 Figura 2.2. Diagrama de Clases de Análisis. ......................................................................... 64 Figura 2.3. Grafico con los conceptos principales usados en EACS Project Manager ......... 73 Figura 3.1. Diagrama de capas de la herramienta. ............................................................... 75 Figura 3.2. Esquema del patrón MVC. ................................................................................... 78 Figura 3.3. Diagrama de Componentes de la Aplicación. ..................................................... 79 Figura 3.4. Diagrama de Clases de Diseño – Proyectos. ...................................................... 81 Figura 3.5. Diagrama de Clases de Diseño – Actividades. ................................................... 82 Figura 3.6. Diagrama de Clases de Diseño – Artefactos. ...................................................... 83 Figura 3.7. Diagrama de Secuencia Carga Inicial. ................................................................ 84 Figura 3.8. Diagrama de Secuencia para Registrar Proyecto. .............................................. 86 Figura 3.9. Diagrama de Secuencia para Registrar Actividades. .......................................... 87 Figura 3.10. Diagrama de Secuencia para Ingresar Horas Trabajadas en las Actividades. . 89 Figura 3.11. Diagrama de Secuencia para Registrar Artefactos. .......................................... 91 Figura 3.12. Diagrama de Secuencia para Crear Versión Artefacto. .................................... 92 Figura 3.13. Cabecera para las páginas del sistema ............................................................ 94 Figura 3.14. Mapa de Navegación del sistema...................................................................... 95 Figura 3.15. Pantalla Ingreso al Sistema. .............................................................................. 96 Figura 3.16. Pantalla Proyectos. ............................................................................................ 96 Figura 3.17. Pantalla Nuevo Proyecto. .................................................................................. 97 Figura 3.18. Pantalla Mis Actividades. ................................................................................... 98 Figura 3.19. Pantalla Ver Horas Trabajo. .............................................................................. 99 Figura 3.20. Pantalla Usuarios. ............................................................................................ 100 Figura 3.21. Pantalla Nuevo Usuario. .................................................................................. 100 Figura 3.22. Pantalla Empresas. .......................................................................................... 101 Figura 3.23. Pantalla Nueva Empresa. ................................................................................ 102 Figura 3.24. Pantalla Reportes. ........................................................................................... 103 Figura 3.25. Pantalla Reporte Detallado del Proyecto. ........................................................ 103 Figura 3.26. Pantalla Reporte Esfuerzo. .............................................................................. 105 Figura 3.27. Pantalla Listado de Personal del Proyecto. ..................................................... 106 Figura 3.28. Pantalla Listado de Actividades. ...................................................................... 107 Figura 3.29. Pantalla Nueva Actividad. ................................................................................ 108 Figura 3.30. Pantalla Ver Artefactos por Actividad. ............................................................. 108 Figura 3.31. Pantalla Listado de Artefactos. ........................................................................ 109 Figura 3.32. Pantalla Nuevo Artefacto. ................................................................................ 110 Figura 3.33. Pantalla Descarga Artefacto. ........................................................................... 111 Figura 3.34. Pantalla Reservar Artefacto. ............................................................................ 111 Figura 3.35. Pantalla Subir Artefacto. .................................................................................. 112 Figura 3.36. Pantalla Versiones del Artefacto...................................................................... 113 Figura 3.37. Pantalla Diagrama de Gantt. ........................................................................... 114 Índice de Códigos Código 1.1. Estructura definición de procesos [MJS]. ........................................................... 32 Código 1.2. Estructura de las actividades definidas en una metodología [MJS]. .................. 33 Código 1.3. Estructura de los artefactos definidos en una metodología [MJS]. .................... 34 Código 2.1. XPDL de la Metodología - JAMESA. .................................................................. 67 Código 2.2. XPDL de las Actividades - JAMESA................................................................... 67 Código 2.3. XPDL de los Artefactos - JAMESA. .................................................................... 67 Código 2.4. XPDL para administrar los Artefactos. ............................................................... 68 Código 2.5. XPDL para administrar las Versiones de los Artefactos. ................................... 69 Índice de Tablas Tabla 1.1. Comparación de MoProSoft con otros modelos. .................................................. 24 Tabla 1.2. Características de las herramientas existentes en el mercado. ........................... 35 1 Introducción Un proyecto se define según el Instituto de Gestión de Proyectos (PMI de sus siglas en inglés de Project Management Institute), como un esfuerzo temporal y único que se realiza para lograr un objetivo, este objetivo puede ser un producto, servicio o resultado. En general se puede decir que la realización de uno o más proyectos puede cambiar el status-quo de una organización y que un producto puede ser el esfuerzo de una sola persona o bien de varios miles de individuos y durar unos pocos días o tomar varios años; los proyectos pueden involucrar a una sola unidad de una organización o bien pueden traspasar las fronteras organizacionales. Por tanto, en proyectos no triviales una mala planificación o ejecución puede ocasionar grandes pérdidas para las organizaciones involucradas. Las empresas relacionadas a las tecnologías de información (TI) realizan principalmente sus actividades basadas en proyectos informáticos de diversos tipos, que van desde proyectos de construcción de software a proyectos de implantación de grandes productos comerciales; pasando por una gama variada de posibilidades. Las empresas de TI, ejecutan los proyectos sea para clientes internos en su propia organización o clientes externos. 2 La realidad del sector de TI, en cuanto a la gestión de proyectos, es deficiente pero puede ser mejorado con la adopción de buenas prácticas y el soporte de herramientas adecuadas. La realidad del sector de TI también se puede mejorar con la adopción de modelos de procesos que han sido previamente probados y que ayude a la realización de la mejora continúa. Este último hecho es una tendencia hoy en el mundo informático con modelos como CMMI, ITIL, MoProSoft, ISO9000, etc. En el mercado existen diversas soluciones para el manejo de proyectos, sin embargo la mayoría están focalizadas en estos aspectos específicos de la gestión y no integradas a otros productos para el análisis y mejora de los procesos involucrados en los proyectos informáticos. El proyecto EACS Project Manager (las iniciales de los autores) es una iniciativa para la construcción de una herramienta que soporte en principio las tareas usuales de la gestión de un proyecto informático e integre la gestión de la Configuración para facilitar el trabajo de los equipos de desarrollo. El presente trabajo está enmarcado dentro del proyecto COMPETISOFT (mejora de procesos para fomentar la competitividad de la pequeña y mediana industria de software de Iberoamérica) del programa CYTED (Ciencia y Tecnología para el Desarrollo) y apoyado parcialmente por la Dirección de Gestión de Investigación (2009-0008 PYMESOFT) y el Departamento de Ingeniería de la Pontificia Universidad Católica del Perú. Este documento presenta el análisis y diseño de la herramienta EACS Project Manager, para Gestión de Proyectos basado en XPDL, dentro de la plataforma PS- PUCP y que se complementa con la tesis de Evelyn Ocampo Moreno y Carlos Gonzáles Cajahuanca que presentan la construcción, pruebas e integración. 3 Capitulo 1: Generalidades En este capítulo se presenta los aspectos básicos necesarios para entender el desarrollo del proyecto EACS Project Manager. Se cubren los temas de Gestión de Proyectos, Proyectos Informáticos, el Lenguaje XPDL, el proyecto COMPETISOFT- PUCP y la revisión de proyectos existentes. Este capítulo se ha desarrollado de manera conjunta con Evelyn Ocampo Moreno y Carlos Gonzáles Cajahuanca, quienes realizaron la tesis complementaria, el cual se presenta en ambos documentos para comprender el contexto en el que se desarrolla el Proyecto. 1.1. Gestión de Proyectos. En esta sección se presentan aspectos relacionados a la gestión de proyectos, definición de proyectos, problemática de los proyectos y procesos según el PMI. 1.1.1. Definición de proyectos Existen diversas definiciones de proyectos, a continuación citaremos algunas de ellas: 4 Proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio resultado único. Completar con éxito un proyecto significa cumplir con los objetivos dentro de las especificaciones técnicas, los costos y los plazos establecidos. Un proyecto tiene un propósito único, algo que no ha sido realizado de la misma manera anteriormente y es, por lo tanto, único y distinto [PMBOK, 2008]. Proyecto es un trabajo no repetitivo, que ha de planificarse y realizarse según unas especificaciones técnicas determinadas, y con objetivos de costos, inversiones y plazos prefijados. También se define un proyecto como un trabajo de volumen y complejidad considerables, que ha de realizarse con la participación de varios departamentos de la empresa y tal vez también con la colaboración de terceros [BOVERI, 1990]. Proyecto es una operación de envergadura y complejidad notables, de carácter no repetitivo, que se acomete para realizar una obra de importancia [PEREÑA, 1996]. Los proyectos tienen las siguientes características: Son temporales, definen un comienzo y un final, es decir una duración finita. Temporal no necesariamente significa de corta duración; muchos proyectos duran varios años. En cada caso, sin embargo, la duración de un proyecto es limitada. Los proyectos no son esfuerzos continuos. Además lo temporal no es aplicable generalmente al producto, servicio o resultado creado por el proyecto [PMBOK, 2008]. Crean productos entregables únicos. Productos entregables son productos, servicios o resultados [PMBOK, 2008]. Se elaboran gradualmente, ésta es una característica de los proyectos que acompaña a los conceptos de temporal y único. La elaboración gradual significa desarrollar en pasos e ir aumentando mediante incrementos [PMBOK, 2008]. Tienen como finalidad alcanzar su objetivo y luego concluirlo. El proyecto concluye cuando se alcanzan sus objetivos específicos o éste se cancela [PMBOK, 2008]. Son importantes y que suponen un esfuerzo notable para la entidad que lo acomete porque requiere inversiones cuantiosas [PEREÑA, 1996]. Pueden involucrar una sola persona o varios miles. Pueden involucrar a distintas áreas de una organización. 5 Se planifican, ejecutan y controlan. Cuentan con un patrocinador, quien es la persona o grupo que proporciona los recursos financieros, en efectivo o en especie, para el proyecto [PMBOK, 2008]. Todo proyecto está destinado a finalizar en un plazo predeterminado, consistiendo dicha finalización en la entrega de un producto [PEREÑA, 1996]. El proyecto está en continua evolución y se caracteriza por un notable dinamismo derivado de su carácter de operación inusual tendente a crear algo nuevo [PEREÑA, 1996]. Algunos proyectos suponen un fuerte riesgo, económico o de otra naturaleza, estando sometidos a contingencias difícilmente dominables e incluso azarosas [PEREÑA, 1996]. 1.1.2. Definición de Gestión de proyectos. Existen diversas definiciones de gestión de proyectos, a continuación citaremos algunas de ellas: La Gestión de Proyectos es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para cumplir con los requisitos del mismo. Se logra mediante la aplicación e integración adecuadas de los 42 procesos de la dirección de proyectos, agrupados lógicamente, que conforman los 5 grupos de procesos. Los grupos de procesos de la gestión de proyectos son: inicio, planificación, ejecución, seguimiento y control, y cierre. Dirigir un proyecto por lo general implica: - Identificar requisitos. - Abordar las diversas necesidades, inquietudes y expectativas de los interesados según se planifica y efectúa el proyecto. - Equilibrar las restricciones contrapuestas del proyecto que se relacionan, entre otros aspectos, con: el alcance, la calidad, el cronograma, el presupuesto, los recursos y el riesgo. El proyecto específico influirá sobre las restricciones en las que el director del proyecto necesita concentrarse. La relación entre estos factores es tal que si alguno de ellos cambia, es probable que al menos otro se vea afectado. Por ejemplo, un adelanto en el 6 cronograma a menudo implica aumentar el presupuesto, a fin de añadir recursos adicionales para completar la misma cantidad de trabajo en menos tiempo. Si no es posible aumentar el presupuesto, se puede reducir el alcance o la calidad, para entregar un producto en menos tiempo por el mismo presupuesto. Los interesados en el proyecto pueden tener opiniones diferentes sobre cuáles son los factores más importantes, lo que crea un desafío aún mayor. Cambiar los requisitos del proyecto puede generar riesgos adicionales. El equipo del proyecto debe ser capaz de evaluar la situación y equilibrar las demandas a fin de entregar un proyecto exitoso [PMBOK, 2008]. La Gestión de Proyectos es un conjunto de métodos y técnicas de gestión que, inspirados por el sentido común y el rigor profesional, están encaminadas a mejorar, definir, planificar, impulsar y controlar las operaciones. La gestión de proyectos representa un todo completo y coherente. No se trata de tomar una terminología vistosa ni de aplicar esporádicamente técnicas puntuales o instrumentos parciales. Si se quiere obtener un efecto perceptible y duradero en la calidad de la gestión, hay que adoptar una metodología en su conjunto, prestando especial atención a los aspectos culturales y de fondo pero sin descuidar los de naturaleza operativa e instrumental. Un pilar de la gestión profesional del proyecto es el empleo de técnicas de gestión conocidas a un terreno “sui generis”, pero variando sensiblemente la forma de aplicar dichas técnicas y poniendo el énfasis en ciertos puntos que son especialmente sensibles en las operaciones discontinuas. La correcta Gestión de los Proyectos será una inversión de máxima rentabilidad al evitar caer en todo ese conjunto de causas de fracaso o ineficacia. Como es lógico, no se puede considerar la metodología de gestión como un fin en sí misma, sino como una ayuda encaminada a facilitar la consecución de los resultados [PEREÑA, 1996]. 1.1.3. Problemática de los proyectos. En la actualidad un alto porcentaje de proyectos en tecnologías de información y comunicación tienen fracasos financieros, debido a la mala dirección de los mismos o a que los actores perdieron el horizonte al momento de poner en práctica sus planes de acción. 7 Información reciente sobre la gerencia de proyectos de TI muestra que [STANDISH GROUP, 2009]: El mundo gasta casi $10 trillones en proyectos de toda clase. Más de 16 millones de personas están involucradas en proyectos en el mundo. Tom Peters considerado por muchos el padre de la administración moderna y de la innovación aplicada en su obra 50 claves para la dirección de proyectos dice: “Para ganar hoy debemos dominar el arte del proyecto”. Un estudio realizado por Standish Group analizó el desarrollo de 8000 proyectos de software, realizados por 350 empresas diferentes y concluyó que solamente el 32% de los proyectos fueron exitosos y el 24% fueron cancelados antes de su terminación, costando billones de dólares. El estudio identificó como principales causas de los problemas: Especificaciones y requerimientos cambiantes o incompletos. Deficiencias en la aplicación de procesos y desconocimiento del ciclo de vida del proyecto. Falta de involucramiento de usuarios. Falta de recursos. Expectativas no realistas. Falta de soporte ejecutivo. Falta de planificación. Falta de gestión de las tecnologías de la información. Desconocimiento tecnológico. Los criterios para determinar el éxito de un proyecto son: Sin desviaciones en las fechas previstas. Sin desviaciones en los costos estimados. Que el producto final cubra las expectativas y necesidades del cliente. Que funcione correctamente. Los factores que afectan el éxito de los proyectos según Baker, Murphy y Fisher, citados por McManus [MCMANUS, 2003], quienes estudiaron 650 proyectos en los Estados Unidos son los siguientes: Compromiso con el proyecto en el establecimiento de cronogramas, presupuestos y objetivo de desempeño técnicos. 8 Frecuente retroalimentación de la organización patrocinadora. Compromiso del cliente y del patrocinador, comprometido en el establecimiento de cronogramas, presupuestos y objetivos de desempeño técnicos. Estructura de la organización adecuada al equipo del proyecto. Participación del equipo del proyecto en la determinación del cronograma y los presupuestos. Entusiasmo del patrocinador. Deseo del patrocinador de crear las capacidades internas. Cambios de personal durante el proyecto. Falta de una adecuada identificación de riesgos. Falta de seguimiento periódico del proyecto, control de la planificación y revisiones para corregir las desviaciones. La Figura 1.1 muestra las estadísticas de proyectos de software según estudios realizados por Standish Group. Figura 1.1. Estadísticas de proyectos de software [Standish Group, 2009]. Algunas de las deficiencias frecuentes en gestión de proyectos son: [PEREÑA, 1996] Ausencia total de planificación, lo que hace que las diversas tareas se vayan acometiendo desordenadamente y a medida que se presentan dificultades. 9 Pese a que cada responsable actúa con celeridad cuando se le encarga algo, el proyecto acumula retrasos por falta de planificación y por la dificultad existente de tomar decisiones. Las decisiones se toman en órganos colectivos, faltando una cabeza que de unidad e impulse el desarrollo del proyecto. Los plazos son enormemente dilatados. Las deficiencias de gestión no sólo desembocan en grandes problemas de plazo sino en defectos de calidad que obligan a cancelar el proyecto. 1.1.4. Procesos según PMI. El Project Management Institute (PMI) es una asociación sin fines de lucro, líder en la Industria de la Gerencia de Proyectos, dedicada al progreso y fomento de su aplicación efectiva a través de la práctica. Fundada en 1969 en Pensilvania, Estados Unidos de Norteamérica, actualmente está presente en 172 países, con más de 420,000 miembros y profesionales certificados, organizados en 250 Capítulos [PMI]. Entre sus principales objetivos se encuentran formular estándares profesionales, generar conocimiento a través de la investigación, y promover la Gestión de Proyectos como profesión a través de sus programas de certificación. La Guía del PMBOK es un estándar en la gestión de proyectos desarrollado por el Project Management Institute (PMI). PMI considera la norma como una referencia fundamental en el ámbito de la dirección de proyectos para sus certificaciones y programas de desarrollo profesional. El PMBOK es una colección de procesos y áreas de conocimiento generalmente aceptadas como las mejores prácticas dentro de la gestión de proyectos. El PMBOK en un estándar reconocido internacionalmente que provee los fundamentos de la gestión de proyectos que son aplicables a un amplio rango de proyectos, incluyendo construcción, software, ingeniería, etc. El PMBOK reconoce 5 grupos de procesos básicos y 9 áreas de conocimiento comunes a casi todos los proyectos. Los conceptos básicos son aplicables a proyectos, programas y operaciones. 10 Los cinco grupos de procesos básicos son: [PMBOK, 2008] Iniciación: aquellos procesos realizados para definir un nuevo proyecto o una nueva fase de un proyecto ya existente, mediante la obtención de la autorización para comenzar dicho proyecto o fase. Planificación: aquellos procesos requeridos para establecer el alcance del proyecto, refinar los objetivos y definir el curso de acción necesario para alcanzar los objetivos para cuyo logro se emprendió el proyecto. Ejecución: aquellos procesos realizados para completar el trabajo definido en el plan para la dirección del proyecto a fin de cumplir con las especificaciones del mismo. Seguimiento y Control: aquellos procesos requeridos para dar seguimiento, analizar y regular el progreso y el desempeño del proyecto, para identificar áreas en las que el plan requiera cambios y para iniciar los cambios correspondientes. Cierre: aquellos procesos realizados para finalizar todas las actividades a través de todos los grupos de procesos, a fin de cerrar formalmente el proyecto o una fase del mismo. En la Figura 1.2 se muestran los cinco grupos de procesos en la gestión de proyectos según PMI. Los procesos se traslapan e interactúan a través de un proyecto o fase. Los procesos son descritos en términos de: Entradas (documentos, planes, diseños, etc.), Herramientas y Técnicas (mecanismos aplicados a las entradas) y Salidas (documentos, productos, etc.). Las nueve áreas del conocimiento mencionadas en el PMBOK son: Gestión de la Integración del Proyecto. Gestión del Alcance del Proyecto. Gestión del Tiempo del Proyecto. Gestión de los Costos del Proyecto. Gestión de la Calidad del Proyecto. Gestión de los Recursos Humanos del Proyecto. Gestión de las Comunicaciones del Proyectos. Gestión de los Riesgos del Proyecto. Gestión de Adquisiciones del Proyecto. 11 Figura 1.2. Grupos de Procesos en la Gestión de Proyectos según PMI [Adaptado por EACS]. 1.2. Proyectos Informáticos Los proyectos informáticos de acuerdo al objetivo que se sigue se pueden clasificar principalmente en proyectos de desarrollo o proyectos de implantación. En particular en los proyectos de desarrollo de software se ejecutan diversos procesos, la Norma Técnica Peruana 12207 agrupa las actividades en procesos principales, procesos de apoyo y procesos organizativos [NTP-ISO/IEC 12207:2006] y los agrupa como se muestra en la Figura 1.3. 1.2.1. Procesos Principales. Son los procesos para iniciar o llevar a cabo el desarrollo, operación o mantenimiento del software. Los procesos principales son: [NTP-ISO/IEC 12207:2006] Proceso de adquisición. Proceso de suministro. Proceso de desarrollo. Proceso de operación. Proceso de mantenimiento. 12 Considerando estos grupos, se desarrolla el proceso de desarrollo, por ser de mayor interés para ésta tesis. El proceso de desarrollo contiene las actividades para el análisis de requisitos, diseño, codificación, integración, pruebas, e instalación y aceptación relativas al software. El desarrollador selecciona y realiza, o presta apoyo, a las siguientes actividades de acuerdo con un contrato. Figura 1.3. Estructura de la norma técnica peruana [Francisco Ruiz, 2007]. Este proceso consta de las siguientes actividades: Implementación del proceso. Análisis de los requerimientos del sistema. Diseño de la arquitectura del sistema. Análisis de los requerimientos software. Diseño de la arquitectura del software. Diseño detallado del software. 13 Codificación y pruebas del software. Integración del software. Pruebas de calificación del software. Instalación del sistema. Pruebas de calificación del sistema. Instalación del software. Soporte a la aceptación del software. 1.2.2. Procesos de Apoyo. Un proceso de apoyo es el que apoya a otro proceso como parte esencial del mismo, con un propósito bien definido y contribuye al éxito y calidad del proyecto de software. Un proceso de apoyo se emplea y ejecuta por otro proceso, según sus necesidades [NTP-ISO/IEC 12207:2006]. Los procesos de apoyo son: [NTP-ISO/IEC 12207:2006] Proceso de documentación. Proceso de gestión de la configuración. Proceso de aseguramiento de la calidad. Proceso de verificación. Proceso de validación. Proceso de revisión conjunta. Proceso de auditoría. Proceso de solución de problemas. 1.2.3. Procesos Organizativos. Se emplean por una organización para establecer e implementar una infraestructura constituida por procesos y personal asociado al ciclo de vida y para mejorar continuamente esta infraestructura. Se usan habitualmente fuera del ámbito de proyectos y contratos, contribuye a la mejora de la organización [NTP-ISO/IEC 12207:2006]. Los procesos organizativos son: [NTP-ISO/IEC 12207:2006] Proceso de gestión. Proceso de infraestructura. Proceso de mejora de proceso. Proceso de recursos humanos. 14 Proceso de gestión de activos. Proceso de gestión del programa de reutilización. Proceso de ingeniería del dominio. Considerando estos grupos, se desarrolla el proceso de gestión, por ser de mayor interés para ésta tesis. El proceso de gestión contiene las actividades genéricas y tareas que pueden ser empleadas por cualquier parte que tenga que gestionar sus respectivos procesos. El gerente es responsable de la gestión del producto, gestión del proyecto y gestión de las tareas de los procesos aplicables, tales como el de adquisición, suministro, desarrollo, operación, mantenimiento o soporte. Este proceso consta de las siguientes actividades: Inicio y definición del alcance. Planificación Ejecución y evaluación. Finalización. 1.3. Gestión de la Configuración del Software (GCS) A continuación se revisan diversas definiciones de GCS, sus aspectos funcionales, los beneficios de su aplicación y se definen los conceptos básicos de esta disciplina. 1.3.1. Definición de la Gestión de la Configuración del Software. Existen diversas definiciones de Gestión de Configuración del Software, citaremos algunas de las más importantes: El proceso de Gestión de Configuración es aplicar procedimientos técnicos y administrativos a lo largo del ciclo de vida del software para: identificar, definir y establecer la línea base de los elementos software en un sistema: controlar modificaciones y emisiones de los elementos: registrar e informar del estado de los elementos y peticiones de modificación: asegurar la completitud, 15 consistencia y corrección de los elementos: y controlar el almacenamiento, manipulación y entrega de los elementos [NTP-ISO/IEC 12207:2006]. Este proceso consta de las siguientes actividades: - Implementación del proceso. - Identificación de la configuración. - Control de la configuración. - Determinación del estado de la configuración. - Evaluación de la configuración. - Gestión de releases y entrega. La Gestión de la Configuración es el arte de identificar, organizar y controlar las modificaciones que sufre el software que construye un equipo de programación. La meta es maximizar la productividad minimizando los errores [BAB, 1986]. La Gestión de la Configuración es una disciplina de gestión que permite controlar formalmente la evolución del software, garantizando la viabilidad en el desarrollo y en el producto y la trazabilidad en el producto [BRYAN-SIEGEL, 1984]. La Gestión de Configuración del Software es una actividad de autoprotección que se aplica a lo largo del proceso de ingeniería de software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para (1) identificar el cambio, (2) controlar el cambio, (3) garantizar que el cambio se implementa adecuadamente y (4) informar del cambio a todos aquellos a los que le interese [PRESSMAN, 1998]. La Gestión de la Configuración, es la disciplina que permite identificar la configuración del sistema en diferentes puntos del tiempo. La implementación de esta disciplina parte de unos lineamientos administrativos para identificar los artefactos (ítems) que van a entrar al control de configuración y técnicos para seleccionar las herramientas de apoyo al control de versiones [SWEBOK, 2004]. 16 Gestión de la Configuración es el proceso de identificar y definir los elementos en el sistema, controlando el cambio de estos elementos a lo largo de su ciclo de vida, registrando y reportando el estado de los elementos y las soluciones de cambio, y verificando que los elementos sean correctos y completos [IEEE Std. 729-1983]. Gestión de la Configuración es una disciplina que aplica conceptos técnicos y administrativos para identificar y documentar características funcionales y físicas de un ítem de configuración, controlar cambios en características, registrar y reportar procesamiento de cambios y estado de la implementación, verificar adecuación con requerimientos especificados [IEEE Std. 828-1998]. El Instituto de Gestión de la Configuración (Institute of Configuration Management) [CMII] proporciona la siguiente definición: Gestión de la Configuración es el proceso de administrar los elementos físicos y los procesos gestionando la información sobre ellos, incluyendo cambios, y asegurando la conformidad en cada caso. El ámbito de la Gestión de Configuración incluye toda la información que puede impactar en la seguridad, la calidad, la planificación, el costo, el beneficio o el entorno. El énfasis de la Gestión de configuración esta en: (1) acomodar el cambio, (2) optimizar la reutilización de los estándares y mejores prácticas, (3) asegurar que todos los requerimientos se mantengan claros, concisos y válidos, (4) comunicar (1), (2) y (3) a cada usuario de manera exacta y precisamente y (5) verificar que los resultados sean conformes en cada caso. El Modelo de Capacidad y Madurez (CMMI, del inglés Capability Maturity Model Integration), promueve la mejora continua desde (1) hasta (5). El Cuerpo de Conocimiento de la Ingeniería de Software [SWEBOK 2004] define las siguientes actividades de la gestión de configuración: Administración del proceso de gestión de configuración de software - Contexto y restricciones - Planificación y Seguimiento Identificación de la configuración del software - Ítems a ser controlados 17 - Versiones del software - Línea base del software Control de la configuración - Proceso para cambio Contabilidad del estado de la configuración - Información y reportes Auditorias de la configuración - Control líneas base Gestión de liberación y entrega del software - Definición y pautas 1.3.2. Conceptos en Gestión de la Configuración del Software. A continuación definimos algunos de los conceptos más importantes en GCS. Elementos de Configuración de Software o Artefacto: Son todos los productos utilizados en el proyecto, documentos, código fuente, imágenes, manuales, etc, cuya evolución interna se desea controlar. Checkin: Acción acontecida cuando una copia local modificada de un artefacto es integrada al repositorio, esta actualización del artefacto produce generalmente una nueva versión del mismo. Checkout: Acción acontecida cuando se crea una copia local de un artefacto desde el repositorio, se puede utilizar una versión específica o por defecto la versión vigente del artefacto, esta copia local se realiza generalmente para realizar cambios o modificaciones sobre la copia. Bloqueo: La posibilidad de que varios usuarios necesiten realizar modificaciones sobre un mismo artefacto, produciría conflictos de versiones. El bloqueo sobre un artefacto se realiza para evitar estos conflictos, de esta forma es posible que un solo usuario realice modificaciones sobre un artefacto a la vez. Trazabilidad: La posibilidad de crear versiones de un mismo artefacto, hace necesario la posibilidad de seguir la traza en el histórico de las versiones para conocer la dependencia entre los artefactos. Soporte a equipos: Posibilidad de que el equipo de trabajo tenga acceso al repositorio y facilite la integración de los artefactos y sus cambios. Versión: es una instancia de un elemento de configuración. La creación y sucesivas modificaciones de los elementos de configuración pueden ser visualizadas en un grafo de evolución, como el que se muestra en la Figura 1.4. 18 Los elementos de software evolucionan conforme un proyecto de software progresa. Una versión es un elemento particular identificado y especificado. Puede ser tomado como un estado de la evolución del elemento [SWEBOK, 2004]. Revisión: es una nueva versión de un elemento que es propuesta para reemplazar a la versión anterior del elemento [SWEBOK, 2004]. Variante: es una nueva versión de un elemento que será añadida a la configuración sin reemplazar a la configuración anterior [SWEBOK, 2004]. Figura 1.4. Grafo de evolución de versiones [SWEBOK, 2004]. 1.4. RUP El Proceso Unificado de Rational (RUP, del inglés Rational Unified Process) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye una de las herramientas más utilizadas para el análisis, implementación y documentación de sistemas orientados a objetos [JACOBSON, 2000]. RUP es un proceso de desarrollo de software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (define quién está haciendo qué, cuándo lo hace y cómo alcanzar cierto objetivo, en este caso el desarrollo de software [KRUCHTEN]), cuyo objetivo es asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones). 19 RUP tiene 3 importantes características [MELOCHE, 2002]: Manejo de Casos de Uso: el proceso emplea casos de uso para manejar el proceso de desarrollo desde el inicio hasta el despliegue. Centrado en la arquitectura: el proceso busca entender el más significante aspecto estático y dinámico en términos de arquitectura de software. La arquitectura está en función de las necesidades del usuario y es capturada en el núcleo de los casos de uso. Iterativo e incremental: el proceso reconoce que es práctico dividir largos proyectos en medianos y pequeños proyectos. Cada pequeño proyecto comprende una iteración que resulta en un incremento. Una iteración podría abarcar todos los flujos en el proceso. Las iteraciones son planeadas usando los casos de uso. Fases de RUP El ciclo de vida de RUP, como se conoce al trazado de las actividades de desarrollo en el tiempo, está dividido en cuatro fases: inicial, elaboración, construcción y transición. A continuación se describen los objetivos de cada una de las fases [LARMAN, 2003]. Inicio: alcanzar un acuerdo entre todos los interesados respecto a los objetivos del ciclo de vida para el proyecto, generando el ámbito del proyecto, el caso de negocio, síntesis de arquitectura posible y el alcance del proyecto. Elaboración: establecimiento de la línea base para la arquitectura del sistema y proporcionar una base estable para el diseño y el esfuerzo de implementación de la siguiente fase, mitigando la mayoría de los riesgos tecnológicos. Construcción: completar el desarrollo del sistema basado en la línea base de la arquitectura. Transición: garantizar que el software está listo para entregarlo a los usuarios. Flujos de Trabajo En RUP se definen nueve flujos de trabajo distintos, separados en dos grupos. Flujo de Trabajo del Proceso, las etapas de esta sección son: Modelado de negocio. Requisitos. Análisis y Diseño. 20 Implementación. Pruebas. Despliegue. Flujo de Trabajo de Soporte: En esta parte nos encontramos con las siguientes etapas: Gestión del cambio y configuraciones. Gestión del proyecto. Entorno. Beneficios fuentes [LARMAN, 2003] Lograr gobernabilidad en tecnologías de información, mediante control y monitoreo en el ciclo de vida del desarrollo de software. Reducir la redundancia e incrementar la productividad. Promover el uso y re uso de activos en la organización. Mitigar riesgos en proyectos estratégicos de la organización. Unir al equipo de trabajo, simplificando su operación y monitoreo. Eliminar ambigüedades en la comunicación del equipo de trabajo. Generar calidad en los productos de trabajo. Automatizar de manera efectiva sus áreas de desarrollo. En la Figura 1.5 se muestra los flujos de trabajo y las fases de RUP. Figura 1.5. Los flujos de trabajo en cada una de las fases e iteraciones del RUP [JACOBSON, 2000] 21 En resumen, la meta de RUP es: [KRUCHTEN, 1999] Asegurar la producción de un software de alta calidad que reúna las necesidades de los usuarios finales dentro de un plan y un presupuesto predecible. Proveer un enfoque disciplinado para asignar tareas y responsabilidades dentro del desarrollo del sistema. Proveer un camino metódico, sistemático para desarrollar, diseñar y validar una arquitectura. Reducir en gran medida el riesgo que representa la construcción de sistemas complejos, porque evoluciona de forma incremental partiendo de sistemas más pequeños en los que ya se tiene confianza. 1.5. Lenguaje XPDL. XPDL es un lenguaje para la definición de un flujo de trabajo, posee un formato de archivo basado en XML que puede ser usado para intercambiar modelos de procesos de negocio entre distintas herramientas y que utiliza la notación grafica BPMN para la definición de un flujo de trabajo. Dicho lenguaje puede ser usado para almacenar o intercambiar modelos de procesos entre distintas herramientas [XPDL]. Los conceptos básicos que son la base de XPDL versión 1.0 fueron formulados por la WfMC (Workflow Management Coalition) y las compañías que desarrollaban herramientas de administración de procesos de negocio y del flujo de trabajo. Estos conceptos fueron incorporados en un meta-modelo y detallados en un glosario; los cuales fueron utilizados en la especificación de las diversas interfaces para los conceptos que formaban parte de un sistema del flujo de trabajo [BPMI]. La primera versión del lenguaje estándar de intercambio denominado WPDL (Workflow Process Definition Language) fue publicada por la WfMC en 1994 [BPMI], este lenguaje define la pieza esencial de la administración de procesos, el intercambio de las definiciones de procesos entre diversas herramientas y también distintos vendedores. En Octubre del 2002 fue lanzado oficialmente el XPDL 1.0, este se basó en la combinación del WPDL en el flujo de trabajo y herramientas de BPMN. XPDL 22 mantuvo la semántica utilizada en WPDL pero definió una nueva sintaxis usando el esquema XML. Sin embargo, ni WPDL ni XPDL 1.0 propusieron una representación gráfica específica para el modelado de procesos a pesar que el metamodelo subyacente para un proceso estaba conformado por actividades (nodos) y caminos conectores entre ellos (transacciones). XPDL, estándar que tiene por objetivo el archivo de los diagramas de procesos y el intercambio o portabilidad de estos entre distintas herramientas. Es un formato de archivo XML que representa el “dibujo” de la definición del proceso. Contiene el tamaño y las coordenadas X e Y del nodo. Tiene un concepto de líneas que señalan el camino a seguir. Los nodos y las líneas tienen atributos que pueden especificar información ejecutable tales como roles, descripción de actividades, temporizadores, llamadas a web services, etc. XPDL 2.0 contiene extensiones para ser capaz de representar todos los aspectos del BPMN (BP Modeling Notation) [XPDL_DOCS]. El objetivo de XPDL es proporcionar un lenguaje formal que permita la importación y exportación de las definiciones de procesos tanto a nivel gráfico y semántico entre una gran variedad de herramientas que hagan uso del mismo lenguaje. Esto ofrece una manera estándar para representar procesos de tal manera que puedan ser importados/exportados por cualquier aplicación que implemente el estándar [XPDL]. XPDL, especifica un formato de diseño de los procesos, permite una representación gráfica de los procesos incluyendo coordenadas X e Y para cada nodo implementado. Además, los nodos pueden especificar atributos tales como roles, descripción de actividades, temporizador, llamadas a servicios Web, etc. Suele ser preferido cuando se trata de implementar procesos o workflows con interacciones humanas [XPDL]. El 3 de octubre del 2005 fue lanzado XPDL versión 2.0, esta versión contempla los conceptos de diagramado propuestos por BPMN (Business Process Managment Notation) y ofrece un meta-modelo extendido que unifica XPDL Y BPMN. La Object Management Group, Inc. (OMG) junto con la Bussiness Process Modeling Initiative(BPMI), han desarrollado una notación, denominada BPMN [BPMN_DOCS], para el modelado de procesos de negocio, BPMN define una notación para la definición de procesos de negocio, lo que es una plataforma 23 independiente con respecto a definiciones específicas (por ejemplo XPDL) de procesos de negocio. Esta notación define una representación abstracta para la especificación de procesos de negocio que se ejecutan dentro de una empresa. Partiendo de un modelo BPMN se puede obtener, mediante la transformación, la definición de un proceso de negocio en un lenguaje específico. BPMN fue desarrollado por BPMI (Business Process Managment Intiative) con la finalidad de adoptar las técnicas empleadas en las herramientas de esquematización, así como unificar y extender los gráficos utilizados en ellas para expresar la semántica de los procesos. BPMN 1.0 fue lanzado en mayo del 2004, BPMN modela tanto la secuencia de actividades como los datos o mensajes intercambiados entre los distintos participantes [BPMN]. BPMN es un estándar de notación de proceso, es decir, define la forma gráfica de diseñar, modelar y construir un proceso, así como los diferentes objetos que se pueden utilizar para tal efecto. La característica principal y más destacable del estándar BPMN es que es un tipo de notación común entre las personas de negocio y los técnicos, construyendo un lenguaje común para intentar unir estos dos mundos [BPMN]. 1.6. Proyecto COMPETISOFT Es un esfuerzo iberoamericano que busca la competitividad de la industria desarrolladora de software a través del establecimiento de modelos de calidad en el proceso software. COMPETISOFT tiene como objetivo desarrollar un marco metodológico común ajustado a la realidad socio-económica de las organizaciones desarrolladoras de software iberoamericanas, orientado a la mejora continua de sus procesos. Este proyecto utiliza un modelo de procesos, un modelo de evaluación y un modelo de mejora siendo los modelos MoProSoft, EvalProsoft y Agile SPI los que han sido tomados como base respectivamente. En esta sección se presentará COMPETISOFT-CYTED el proyecto en la PUCP (COMPETISOFT-PUCP) y en particular COMPETISOFT-PUCP tools. 24 1.6.1. COMPETISOFT- CYTED. El Proyecto Competisoft se ha desarrollado sobre la base de los siguientes modelos: MoProSoft, EvalProsoft.y Agile SPI. 1.6.1.1. Modelo de procesos (MoProSoft) Es un modelo que fomenta la estandarización de su operación a través de la incorporación de buenas prácticas basadas en los modelos y estándares reconocidos internacionalmente, tales como ISO 9001:2000, CMM-SW, ISO/IEC 15504, PMBOK entre otros, la comparación con estos modelos y estándares se muestra en la Tabla 1.1 Características ISO 9000:2000 CMM-SW ISO 15540 MoProSoft 1. Para SW. NO SI SI SI 2. Comprensible. NO NO SI SI 3. Procesos. NO SI SI SI 4. Práctico. NO NO NO SI 5. Mejora de procesos orientada al objetivo de negocio. NO NO SI SI 6. Evaluación con vigencia. SI NO NO NO 7. Aplicable como norma. SI NO NO NO Modelos Tabla 1.1. Comparación de MoProSoft con otros modelos [MOPROSOFT, 2003]. La adopción del modelo permite elevar la capacidad de las organizaciones que desarrollan o mantienen software para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. MoProSoft es también aplicable en áreas internas de desarrollo de software de las empresas de diversos giros. Actualmente MoProSoft es una norma mexicana [MOPROSOFT, 2003] y norma técnica peruana. Las principales características de MoProSoft son: [MOPROSOFT, 2003] Pocos procesos que abarcan todos los niveles de una organización: directivo, gerencial y operativo. Procesos integrados como una red de comunicación. Definición explícita de roles responsables por las actividades de cada proceso y la capacitación requerida. Definición explícita del propósito, objetivos específicos, indicadores, metas cuantitativas y mediciones para cada proceso. Definición explícita de productos de entrada, salida e internos de cada proceso y sus características mínimas. 25 Definición de flujos de trabajo con las actividades, tareas, roles involucrados y productos generados. Existencia de una Base de Conocimiento de la organización en la cual se resguardan todos los productos generados, se administran y se consultan de acuerdo con los mecanismos definidos. Definición de las actividades para recaudar lecciones aprendidas y usarlas en proyectos futuros. Definición de un mecanismo específico para la reacción a las situaciones excepcionales durante el desarrollo de las actividades. Definición explícita de las actividades de verificación, validación y pruebas para fomentar la calidad de los productos. Definición explícita de guías de ajuste que sugieren la adaptación de los procesos a las necesidades de las organizaciones, sin perder de vista el cumplimiento de los objetivos de los procesos. Los objetivos y metas cuantitativas son las que guían a los demás procesos y proyectos y son los que se evalúan para conocer cuantitativamente la efectividad de los procesos de la organización. Las sugerencias de mejora a los procesos se identifican y se reportan a los responsables de gestión de procesos. Los procesos del modelo pueden ser ajustados con base al contexto de la organización. El propósito de contar con un modelo de estas características es apoyar a la industria de software a incrementar la productividad a un nivel donde la calidad de los productos de software será la consecuencia natural de la madurez en los procesos de las organizaciones. MoProSoft proporciona a las pequeñas y medianas empresas desarrolladoras de software, un modelo basado en las mejores prácticas internacionales con los siguientes beneficios: Mejora la calidad del software producido por la empresa que adopta el modelo. Eleva la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad. Integra todos los procesos de la organización y mantiene la alineación con los objetivos estratégicos. Inicia el camino a la adopción de los modelos ISO 9001 o CMMI. 26 Sirve para implantar un programa de mejora continua. Facilita la selección de proveedores. Permite obtener acceso a las prácticas de ingeniería de software de clase mundial. Estructura de MoProSoft El modelo pretende apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora continua. Sintetiza las mejores prácticas en un conjunto pequeño de procesos que abarcan las responsabilidades asociadas a la estructura de una organización que son: la Alta Dirección, Gestión y Operación [MOPROSOFT]. MoProSoft es un modelo integrado donde las salidas de un proceso están claramente dirigidas como entradas a otros; las prácticas de planeación, seguimiento y evaluación se incluyeron en todos los procesos de gestión y administración; por su parte los objetivos, los indicadores, las mediciones y las metas cuantitativas fueron incorporados de manera congruente y práctica en todos los procesos; las verificaciones, validaciones y pruebas están incluidas de manera explícita dentro de las actividades de los procesos; y existe una base de conocimientos que resguarda todos los documentos y productos generados. MoProSoft tiene tres categorías de procesos: Alta Dirección, Gestión y Operación que corresponden a la estructura organizacional de las empresas de software, como se muestra en la Figura 1.6 A continuación se describen las categorías de procesos: 1. Alta Dirección (DIR): Categoría de procesos que aborda las prácticas de Alta Dirección relacionadas con la gestión del negocio. Proporciona los lineamientos a los procesos de la Categoría de Gerencia y se retroalimenta con la información generada por ellos [MOPROSOFT]. Los elementos de entrada y salida de esta categoría son: Misión, Visión y Valores. Objetivos y la forma de medirlos, estrategias. Procesos con sus indicadores y metas. Cartera de proyectos. 27 Estructura organizacional y estrategia de recursos. Presupuesto. Plan de comunicación con el cliente. Proceso de mejora continúa. Figura 1.6. Modelo de Referencia de Procesos [MOPROSOFT]. 2. Gestión (GES): Categoría que aborda la práctica de gestión de procesos, proyectos y recursos en función de los lineamientos establecidos por la alta dirección. Proporciona los elementos para el funcionamiento de los procesos de la categoría de operación. Recibe y evalúa la información generada por estos y la comunica a la alta dirección [MOPROSOFT]. Esta categoría es compuesta por los siguientes elementos: Definir los elementos de los procesos, calendario y mediciones de procesos. Plan operativo de bienes, servicios e infraestructura, capacitación de recursos humanos y ambiente de trabajo. Plan de manejo de riesgos. Asignar responsables a proyectos. Implementación de procesos. Reporte de mediciones y sugerencias de mejoras. Plan de evaluación. 28 3. Operación (OPE): Categoría de procesos que aborda las prácticas de los proyectos de desarrollo y mantenimiento de software. Esta categoría realiza las actividades de acuerdo a los elementos proporcionados por la Categoría de Gerencia y entrega a ésta la información y productos generados [MOPROSOFT]. Esta categoría es compuesta por los siguientes elementos: Definir el protocolo de entrega y tiempo estimado para cada actividad. Calcular costo estimado del proyecto. Documentar y realizar las actividades del plan de proyecto, el plan de desarrollo y evaluar su cumplimiento. Cierre del contrato. Generar reporte de mediciones sugerencias de mejora. 1.6.2. COMPETISOFT- PUCP. Actualmente, el proyecto COMPETISOFT (Proyecto CYTED # 3789) involucra a 13 países (entre los cuales se encuentra el Perú) y más de 100 investigadores. En el Perú, las empresas vienen introduciendo distintos marcos de referencia para la mejora de sus procesos, sin embargo estos no calzan con las distintas realidades que se presentan en las empresas peruanas, por lo que el Perú se convierte en un escenario propicio para implantar un marco metodológico orientado a las pequeñas y medianas empresas como el que propone COMPETISOFT. COMPETISOFT- PUCP es un proyecto desarrollado por el Grupo de Investigación y Desarrollo en Ingeniería de Software de la Pontificia Universidad Católica del Perú (GIDIS-PUCP), el cual tiene como objetivo principal implantar un modelo de mejora de procesos de software en empresas dedicadas a este rubro en el Perú, planteándose las siguientes metas: Desarrollar herramientas de apoyo para la implantación del modelo de mejora. Desarrollar instrumentos de evaluación diagnóstica para COMPETISOFT. Evaluar el nivel de empresas peruanas según este modelo. Desarrollar mapeo de procesos entre modelos para apoyar a las empresas a elegir sus respectivos caminos de mejora. El conjunto de proyectos que forman parte de COMPETISOFT-PUCP se encuentran categorizados de la siguiente forma: 29 Plataforma para gestión de procesos: mejorar la gestión de procesos, metodologías y sus evoluciones en las empresas, utilizando un lenguaje de definición de procesos (XPDL y BPMN) a través de una plataforma en Internet que soporte la definición, administración, evolución, evaluación y auditoria de procesos. Procesos de mejora en empresas: mejorar la productividad de empresas desarrolladoras de software bajo el enfoque de adhesión a un modelo de referencia de procesos (MoProSoft). Este componente del proyecto se realiza a través de Action-Research, entre empresas y el equipo COMPETISOFT- PUCP. El esquema de trabajo implica que un estudiante entrenado en el modelo participe en una empresa como un practicante. Mapeo de modelos de procesos: determinar la correspondencia entre modelos de procesos referenciales más importantes respecto del nuevo modelo; para determinar el grado en que este nuevo modelo se alinea a los modelos existentes. El trabajo se realizará a través de un estudio comparado entre distintos modelos de referencia y evaluación a procesos. Dentro de la primera categoría se encuentra el proyecto PS-PUCP, proyecto que congrega un conjunto de herramientas que permiten reflejar y manejar los procesos de una organización, evaluar dichos procesos en base a marcos de referencia y proveer una auditoria a través del monitoreo y mediciones en todos los pasos de un proceso. 1.6.3. COMPETISOFT- PUCP Tools. El presente proyecto forma parte de una serie de herramientas desarrolladas por el Grupo de Investigación y Desarrollo en Ingeniería de Software (GIDIS) en el proyecto COMPETISOFT- PUCP Tools. Los proyectos que se ejecutan son: Proyecto para la definición de procesos (MJS Process Designer): Permite definir procesos de una organización para posteriormente construir metodologías en base a los procesos definidos, se ha tenido que realizar extensiones al lenguaje XPDL para realizar la definición de las metodologías. Esta herramienta será desarrollada por el grupo COMPETISOFT – JAMESA. 30 Proyecto para la gestión de proyectos (EACS Project Manager): Permite administrar proyectos y gestionar la configuración, los proyectos se basan en la metodología definida en XPDL por el Proyecto para la Definición de Procesos. Las actividades y artefactos que se generen en el proyecto también hacen referencia a las actividades y artefactos definidos en la metodología. Esta herramienta será desarrollada por el grupo COMPETISOFT – EVANCASA. Proyecto para la evaluación de procesos (LMB Process Audit)): Permite realizar una evaluación de los procesos definidos a través de los proyectos realizados y artefactos almacenados de dicho proyecto y usando la metodología definida por el tipo de proyecto. Es una herramienta basada en el lenguaje XPDL y será desarrollada por el grupo COMPETISOFT – LIMEBO. En la Figura 1.7 se muestra la relación entre las 3 herramientas del proyecto COMPETISOFT-PUCP Tools. La presente herramienta se integrará a las herramientas: MJS Process Designer y herramienta LMB Process Audit. La herramienta MJS Process Designer se encargará de generar una metodología en base a los procesos definidos en la organización evaluada en lenguaje XPDL. La herramienta EACS Project Manager utilizará las metodologías generadas para implementar los proyectos, además las actividades y artefactos del proyecto podrán estar relacionados con las actividades y artefactos provenientes de la metodología. La herramienta LMB Process Audit utilizará las metodologías y proyectos para realizar la evaluación y auditoría de las actividades y artefactos, de esta forma se realizará una comparación entre las actividades y artefactos de la metodología con los implementados en los proyectos. 31 Figura 1.7. Relación entre las 3 herramientas del proyecto COMPETISOFT PUCP 32 Los siguientes códigos corresponden a la tesis desarrollada por el grupo COMPETISOFT – JAMESA y la explicación de la estructura y los “tags” se encuentran en detalle en dicha la tesis [MJS]. En el Código 1.1 se muestra la estructura de definición de procesos en la cual se define la metodología a seguir en el desarrollo del proyecto. Una metodología se compone de un conjunto de actividades, estas al relacionarse de forma adecuada se transforman en un flujo de procesos. Código 1.1. Estructura definición de procesos [MJS]. 33 En el Código 1.2 se muestra el conjunto de actividades definidas en la metodología asignada al proyecto, sirven para determinar el flujo del proceso de desarrollo del proyecto, cada actividad define una serie de artefactos a utilizar. Código 1.2. Estructura de las actividades definidas en una metodología [MJS]. 34 En el Código 1.3 se muestra los artefactos definidos en la metodología asignada al proyecto, sirven para definir los artefactos reales dentro del proyecto, los cuales serán utilizados para la administración del repositorio. Código 1.3. Estructura de los artefactos definidos en una metodología [MJS]. 1.7. Revisión de Productos. En esta sección se presenta un breve resumen con las características más importantes de algunas de las herramientas de Gestión de proyectos que existen en el mercado así como las características más importantes de la herramienta propuesta. 1.7.1. Tecnológico En la Tabla 1.2 se muestra las características más importantes de algunas herramientas de gestión de proyectos existentes en el mercado. Características de las herramientas que existen en el mercado: Microsoft Project (o MSP) Es un software de administración de proyectos diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo [MSPROJECT]. Características: Almacena la información del proyecto incluyendo fechas, recursos, asignaciones, duraciones, relaciones entre tareas, secuencias de tareas, calendarios y más. 35 Características M S P ro je c t B -K IN P R O J E C T M O N IT O R B U G T R A C K K P L A T O d o tP ro je c t P R IM A V E R A Administración de Tareas       Retroalimentación de Tareas       Calendarios       Reportes Financieros       Plantillas de Proyectos       Administración de Recursos       Habilidades de los Recursos       Impresión de Reportes y Documentos       Administración de Artefactos       Notificaciones vía correo electrónico  *       Sistema en Línea  *       Tabla 1.2. Características de las herramientas existentes en el mercado. *: característica disponible en MS Project Server. Calcula la información incluyendo fechas, programaciones, costos, duraciones, rutas críticas, valor ganado, variaciones y más. Presenta las vistas de la información que se está recuperando. Se pueden especificar las vistas, las tablas, los filtros, los grupos, los campos o informes, dependiendo del aspecto que el modelo del proyecto necesite mostrar. Diagramas de Gantt e informes. Configuración de los recursos y asignaciones de los mismos a las tareas. Comparación de las variaciones entre la información de la tarea planeada y real. B-KIN PROJECT MONITOR Es una herramienta Web comercial que permite monitorizar proyectos, tareas, programas, personas, en general todos los aspectos y componentes de un proyecto 36 en forma distribuida. Permite también utilizar la herramienta de prueba gratuita por 30 días previa inscripción [B-KIN]. Características: En línea, permite la administración de proyectos bajo un entorno distribuido, la herramienta se encuentra alojada en el servidor de B-kin. La herramienta no se vende, simplemente se cobra una mensualidad por derecho de uso. Entorno web: aplicación 100% programada para ser utilizada vía Internet. Se trabaja siempre mediante un navegador (Internet Explorer o Firefox) desde cualquier lugar con acceso a Internet. Multiproyecto, permite realizar varios proyectos a la vez y formar grupos. Integración e-mail: Notificaciones a terceros vía mail de acciones y tareas. Recepción automática de mails Colaborativo, permite el flujo de información mediante foros y documentos compartidos dentro de cada proyecto. Permite generar una amplia gama de reportes para la revisión permanente y actualizada de los proyectos y tareas. Así mismo los reportes permiten ser exportados a formatos PDF, HTML, Microsoft Project y Microsoft Excel. Módulos complementarios: Mi BPM: Permite a todos los integrantes del equipo informar sobre la dedicación de horas de trabajo en los distintos proyectos que se encuentren asignados. B-kin Work Report: Permite asignar tareas desde el exterior de la organización (por ejemplo: tareas de soporte técnico por terceros). Aplicaciones complementarias: B-kin Content Manager: Permite administrar los documentos asociados al proyecto, noticias, foros y crear el portal Web del proyecto. B-kin Web Galleries: Permite alojar un espacio Web para compartir noticias, foros y documentación con clientes o personal externo a la organización. BUGTRACK Es una herramienta Web comercial que permite administrar proyectos bajo un entorno distribuido, la herramienta es alquilada mensualmente para su uso y existen 37 dos ediciones: Estándar y Profesional (permite realizar reportes y administrar repositorios de documentos). La herramienta permite el seguimiento de un proyecto de software y los posibles errores de código [BUGTRACK]. Características: En línea, permite el acceso Web a la herramienta las 24 horas y los 365 días del año, solo se necesita conexión a Internet. Permite reportar nuevos errores del proyecto, para la posterior revisión de estos. Notificaciones vía correo electrónico cuando se realicen cambios sobre el proyecto o nuevas notificaciones de errores. Permite el versionamiento del proyecto. Administración de roles y acceso por cada proyecto. Seguridad, todos los enlaces están encriptados bajo seguridad SSL (Secure Socket Layer). Exportación de registros para una revisión fuera de línea. Web-query, permite la ejecución de consultas y la exportación de datos hacia otras herramientas. Integración con CVS, Subversión y Microsoft Visual Source Safe. Permitiendo de esta forma que los miembros del proyecto tengan siempre la versión correcta del proyecto. Proyectos compartidos, permite compartir el proyecto con otras compañías que tengan suscripción con BUGtrack. KPLATO Es una herramienta gratuita de escritorio de gestión de proyectos perteneciente a KOffice (office suite de KDE) [KPLATO]. Características: Permite mostrar el costo planificado del proyecto a una fecha determinada. Permite la organización de las tareas mediante en una estructura de división del trabajo (WBS). Los recursos son organizados por medio en una estructura de desglose de recursos (RBS). 38 Los costos son organizados en una estructura de desglose de costos (CBS). Generación de Diagramas GANTT: tareas dependientes, nombre de la tarea, recursos asignados, tareas críticas. Cuadros de dialogo para crear y corregir el proyecto, diversos tipos de tareas, los calendarios, los recursos, los costos y el progreso del proyecto. Características no incluidas No permite restringir las tareas, si ya se había ingresado una tarea no puede validarse si esta existía. Revisión en línea. DotPROJECT Es una herramienta Web de código abierto para la administración de proyectos. No existe una empresa encargada de la herramienta debido a que es mantenido por un grupo de voluntarios y usuarios. El software es libre de descargarse desde la página Web de la herramienta, la empresa que desee utilizar la herramienta debe encargarse de hospedarlo en un servidor de aplicaciones [DOTPROJECT]. Características: Administración de usuarios, clientes y empresas. Jerarquía de lista de tareas Administración de repositorio de archivos. Permite generar un Calendario en base a los tiempos registrados en las tareas. Permite asignar recursos no humanos (oficinas, equipamiento, entre otros) a un proyecto. Permite la creación de foros de discusión dentro de cada proyecto para distribuir información y discutir temas relativos al proyecto del foro. Permite almacenar archivos dentro de un proyecto permitiendo un versionado básico de los mismos. Primavera Project Planner Es el producto más importante de Primavera System Inc, empresa líder de software de programación de proyectos desde 1982 y, los proyectos de mayor complejidad a 39 nivel mundial se realizan con este software. En octubre del 2008 Oracle adquirió Primavera System [PRIMAVERA]. Características: Incorpora todos los elementos necesarios para garantizar un adecuado control y seguimiento de los proyectos. Permite la gestión de múltiples proyectos de gran tamaño. Permite crear grupos de proyectos, dispone de herramientas para realizar planificaciones y de nivelaciones avanzadas que pueden realizarse de forma manual o automática. Todo ello dentro de un entorno multiusuario, donde cada participante puede tener acceso a todo el proyecto o sólo a las partes deseadas mediante las capas. La comunicación de los planes entre los diferentes usuarios se realiza mediante correo electrónico o a través de páginas Web. Esta herramienta dispone de todas las características de gestión de proyectos que se puedan necesitar, por complicado que sea el proyecto. Integra un módulo para gestión de contratos de proyectos, Expedition, y una herramienta de seguimiento y control de proyectos, Sure Track Project Manager. Además, esta suite permite la integración con los sistemas ERP más utilizados en las empresas, como SAP, Oracle, Baan y People Soft. La aplicación dispone de una opción en la que permite seleccionar el idioma en el que se desea trabajar, entre otros el castellano. Los informes, calendarios, etc. aparecerán en el idioma especificado. Sin embargo no puede decirse que exista realmente una versión en castellano de la aplicación, pues las barras de menús y los campos seguirán apareciendo en inglés. Tiene un poderoso acceso Web por todos los usuarios y a todos los proyectos simultáneamente. Manejo fácil de Gantt (herramienta gráfica cuyo objetivo es mostrar el tiempo de dedicación previsto para diferentes tareas o actividades a lo largo de un tiempo total determinado) Los principales módulos funcionales de este producto, en constante desarrollo, son: Cliente Windows orientado a los que ejecutan funciones de programación y/o control, elaboran cronogramas etc. 40 Cliente Web o My Primavera orientado a los administradores de proyectos o Project Managers, directivos, ingenieros y técnicos a pie de obra así como a la realización de análisis del portafolio. Módulo Contract Manager para controlar los aspectos administrativos y contractuales de los proyectos. 1.7.2. Descripción y Sustentación de la solución En esta sección se presenta la definición del producto en base a las necesidades detectadas en el mercado y definidos en el proyecto COMPETISOFT-PUCP. Como resultado del análisis de la situación actual, se diseñó la herramienta EACS Project Manager en busca de satisfacer las necesidades señaladas en capítulos anteriores. A pesar de existir una gran variedad de herramientas en el mercado, no se encontró ninguna que abarque el proceso de instanciar una metodología ya definida por algún proceso, manejo de sus actividades, artefactos de estas metodologías y gestión de la configuración haciendo uso de un lenguaje formal. La presente herramienta forma parte del proyecto PS-PUCP la cual se integrará a las herramientas: MJS Process Designer la que se encargará de generar una metodología en base a los procesos definidos en la organización evaluada, y herramienta LMB Process Audit que utilizará las metodologías definidas y los proyectos registrados para realizar la evaluación, de esta forma se realizará una comparación entre las actividades y artefactos de la metodología con los implementados en los proyectos. Otra de las bondades que la herramienta brinda al usuario es la posibilidad de crear un proyecto en base a una metodología ya definida en algún proceso. A este proceso se le denomina crear la instancia de una metodología que consiste en extraer de la metodología sus actividades y artefactos pertenecientes a un proceso o marco de referencia con la finalidad de asociarlas a una o más actividades o artefactos del proyecto creado. La gestión de la configuración de los artefactos creados en el proyecto tiene un papel fundamental en la correcta gestión y administración de los proyectos dentro de una organización. En el módulo de Gestión de la Configuración, el usuario podrá crear y administrar versiones de los artefactos definidos en el sistema a lo largo del tiempo. 41 La herramienta EACS Project Manager se desarrollará en plataforma Web para facilitar la distribución de la aplicación y el acceso de los usuarios desde cualquier ubicación. Para ello, se utilizará un repositorio de datos común, en el cual se registrarán versiones de los artefactos manejados por las empresas que tengan acceso a la aplicación. EACS Project Manager será desarrollada de tal forma que se pueda integrar a un conjunto de herramientas de administración de procesos que abarque a todos los miembros del proyecto PS-PUCP. La herramienta será desarrollada usando el lenguaje XPDL para el manejo de los procesos. Con ello, se logra contar con una herramienta que además de satisfacer las necesidades del usuario, también asegure su interoperabilidad con otras herramientas que manejen el mismo lenguaje. 1.7.3. Características principales de la herramienta propuesta Cuando se tiene un proyecto, es necesario tener un control de los recursos, tanto materiales, humanos y del tiempo. Siempre la necesidad de conocer el avance y estado de los proyectos que se desarrollan es importante, de otra forma se propician retrasos, desorganización y por ende pérdidas económicas en el proyecto. La herramienta propuesta ofrecerá el seguimiento y control de cualquier tipo de proyecto de software, gestionando su avance, plazos, esfuerzos, recursos y ofreciendo la información necesaria sobre cada elemento. Las principales características que la herramienta propuesta contiene, se mencionan a continuación: Definir y actualizar un proyecto, actividades, tiempos y recursos. Permite gestionar múltiples proyectos. Crear la instancia de una metodología, asociando un proyecto a una metodología ya definida por algún proceso. Clasificar los proyectos según una categorización definida por el usuario para agruparlos o sólo identificarlos. Permite registrar recursos que participan en determinado proyecto. Las actividades son las tareas que realizan las personas involucradas en cada proyecto y éstas tienen las siguientes características: 42 Permite registrar actividades y sus dependencias. Permite asociar una o más actividades de una metodología ya seleccionada con una actividad creada en el proyecto. Registrar el avance de las actividades conforme se desarrollan. Permite visualizar las actividades agrupadas por las actividades padre a la que fueron relacionadas. Mostrar el listado de las actividades del usuario, las cuales pueden ser filtradas por diferentes criterios de búsqueda. Permite registrar el esfuerzo realizado por cada usuario para las actividades seleccionadas. Permite visualizar las actividades asignadas a un miembro del equipo, mostrando que actividades son futuras, las que deberían haber empezado y actividades que les faltan para acabar en diferentes colores, con lo que permitirá al usuario detectarlas a tiempo. El color rojo indica las actividades cuyo tiempo transcurrido es mayor o igual al 80% del tiempo programado; si el tiempo transcurrido ha superado el tiempo programado, esta actividad se encuentra retrasada. El color anaranjado indica las actividades cuyo tiempo transcurrido es mayor o igual al 40% y menor o igual al 80% del tiempo programado. El color azul indica las actividades cuyo tiempo transcurrido es menor al 40% del tiempo programado. Los artefactos son todos los elementos producidos en un proyecto y tienen las siguientes características: Permite por cada proyecto crear un repositorio para gestionar los artefactos que se utilicen en el proyecto. Permite asociar uno o más artefactos de una metodología ya seleccionada con un artefacto creado en el proyecto. Permite asociar una o más actividades del proyecto con un artefacto creado en el proyecto. Permite gestionar las versiones de los archivos, las cuales son almacenadas en el repositorio, que controla la creación de nuevas versiones. El usuario podrá subir y descargar los archivos de acuerdo al acceso registrado manteniendo la integridad de los elementos. El usuario podrá reservar y liberar los artefactos de acuerdo al acceso registrado manteniendo la integridad de los elementos. Permite evaluar y ejecutar los cambios a estos elementos de forma controlada. 43 Entre otras características encontramos: Permite registrar empresas. Permite registrar usuarios al sistema. Permite validar accesos a los diferentes proyectos. Permite generar diferentes tipos de reportes. Permite generar un diagrama de Gantt, en el cual se podrá visualizar el tiempo programado, las fechas de iniciación y terminación para las diferentes actividades a lo largo de un tiempo total determinado. 44 Capítulo 2: Análisis El presente capítulo presenta los aspectos más relevantes de la etapa de análisis, partiendo de los requerimientos funcionales y no funcionales asociados al sistema, la definición de requisitos del software (casos de uso y especificaciones) y el diagrama de clases de análisis. 2.1. Requerimientos Funcionales. Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas, describen servicios o funciones. Proyectos 1. El sistema permite el registro, modificación y visualización de proyectos. 2. El sistema permite realizar la búsqueda de proyectos por diferentes filtros. 3. El sistema permite mostrar la relación de proyectos registrados, los cuales pueden ser ordenados por diferentes criterios. 45 4. El sistema permite crear la instancia de una metodología, asociándola a un proyecto. Las metodologías ya se encuentran definidas previamente en base a procesos definidos. 5. El sistema permite ingresar las fechas de inicio y fin referenciales para la planificación del proyecto, así como administrar los usuarios de un determinado proyecto. Actividades 1. El sistema permite el registro y modificación de las actividades. 2. El sistema permite la visualización de los artefactos correspondientes a las actividades de los proyectos registrados. 3. Las actividades pueden ser registradas de forma independiente o dependiente de otra actividad del mismo proyecto. 4. El sistema permite mostrar la relación de actividades registradas, las cuales pueden ser ordenadas por diferentes criterios y se muestran agrupadas por las actividades padre a la que están asociadas en forma de cascada. 5. El sistema permite asociar las actividades de un proyecto con una o varias actividades de la metodología elegida para el proyecto. 6. El sistema permite registrar al usuario responsable de la actividad, este usuario debe ser uno de los registrados para el proyecto, 7. El sistema permite el ingreso de las horas estimadas de las actividades. 8. El sistema permite ingresar el progreso de las actividades, que a su vez actualizan el avance del proyecto. 9. El sistema permite realizar la búsqueda de todas las actividades asignadas de un usuario por diferentes filtros. 10. El sistema permite mostrar la relación de actividades que está desarrollando un usuario asignado como parte del equipo en el proyecto. 11. El sistema permite visualizar la diferencia que existe entre las actividades de un usuario por colores según la fecha final de cada actividad, de esta manera las tareas más cercanas a vencerse o vencidas se mostrarán en color rojo, las que todavía faltan por vencerse (falta más del 20% pero menos de 60% del tiempo para terminar) se mostrarán en anaranjado y las que faltan por vencerse (más del 60% del tiempo para terminar) en azul. 12. El sistema permite registrar el número de horas de esfuerzo realizado por el usuario por cada actividad a la que se encuentra asignado. 13. Permite mostrar la relación de actividades asignadas a un usuario de un proyecto determinado, mostrando que actividades son futuras, las que deberían 46 haber empezado, las atrasadas y las que inician en el tiempo en diferente formato, con lo que permitirá al usuario detectarlas a tiempo. Artefactos 1. El sistema permite crear un repositorio por cada proyecto para gestionar sus propios artefactos. 2. El sistema permite mostrar la relación de artefactos registrados, los cuales pueden ser ordenados por los siguientes criterios: nombre y estado. 3. El sistema permite asociar el artefacto de un proyecto con uno o varios artefactos de la metodología elegida para el proyecto. 4. El sistema permite asociar el artefacto de un proyecto con una o varias actividades del proyecto. 5. El sistema permite a los usuarios cargar cualquier tipo de archivo que hayan estado trabajando en su estación local como artefacto del proyecto. Los archivos cargados generarán una versión inicial del artefacto. 6. El usuario que desee utilizar los artefactos del repositorio, deberá descargar la versión actual del repositorio (sincronización) a su estación de trabajo local previa validación de sus privilegios. 7. El sistema brindará acceso de modificación a un solo usuario. Si otro usuario desea modificar el artefacto, deberá esperar que el usuario que bloqueo el artefacto lo cargue (desbloqueo) al repositorio para visualizar los cambios que este ha realizado. 8. El sistema creará una nueva versión del artefacto en cada cambio y carga al repositorio. 9. El sistema permite mostrar la relación de versiones de artefactos registrados, los cuales pueden ser ordenados por diferentes criterios, lo que permite la trazabilidad en el histórico de las versiones para conocer la dependencia que existe entre los artefactos. 10. El sistema permite la descarga de cualquiera de las versiones del artefacto, por defecto se descarga la versión actual. 11. El sistema permite cambiar la versión vigente de los artefactos. Usuarios 1. El sistema permite el registro, modificación y eliminación de usuarios del sistema, así como, la asignación de roles y perfiles a los usuarios, cada usuario podrá ver información de gestión de proyectos y acceder a opciones según sus permisos. 47 2. El sistema permite realizar la búsqueda de usuarios por diferentes filtros. 3. El sistema permite mostrar la relación de usuarios registrados, los cuales pueden ser ordenados por diferentes criterios. Empresas 1. El sistema permite el registro, modificación y eliminación de empresas. 2. El sistema permite realizar la búsqueda de empresas por diferentes filtros. 3. El sistema permite mostrar la relación de empresas registradas, las cuales pueden ser ordenadas por diferentes criterios. Seguridad 1. El sistema permite validar el ingreso al sistema mediante un usuario y contraseña. Reportes 1. El sistema generará el diagrama Gantt de cada proyecto registrado. El cual permitirá mostrar las actividades según su distribución de acuerdo al calendario, de manera tal que se pueda visualizar el usuario responsable, el periodo de duración de cada actividad, sus fechas de iniciación y terminación e igualmente el tiempo total requerido para la ejecución de una actividad determinada. 2. El sistema permite generar reportes de proyectos específicos indicando sus datos principales, el personal involucrado, las actividades y artefactos de este. 3. El sistema permite mostrar reporte de horas de esfuerzo realizado por los usuarios. Cabe mencionar que la herramienta desarrollada tiene solo propósitos académicos con el fin de demostrar que es posible crear una herramienta que puede integrar el uso de archivos XPDL como definición de procesos para implementar proyectos y administrar la gestión de la configuración. La seguridad ha sido implementada solo a nivel de ingreso del usuario al sistema mediante un usuario y contraseña, además de la sección de gestión de la configuración donde se verifica el usuario que reserva un artefacto. No se ha considerado el registro de bitácora (logs) debido a que la herramienta no ha sido desarrollada con el fin de uso comercial, por lo que no es necesario almacenar los 48 eventos, excepciones y mensajes en archivos de logs para posteriores evaluaciones o revisiones. 2.2. Requerimientos No Funcionales Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. Estos requerimientos provienen del proyecto COMPETISOFT- PUCP Tools y definidos por el equipo JAMESA. 1. El sistema es multiempresarial, multiplataforma, compatible con el navegador de Internet Explorer 8 y Mozila Firefox 3.6. 2. El servidor Web utilizado es el Tomcat versión 5.5. 3. La arquitectura utilizada es de tres niveles, el patrón de diseño a utilizar es Modelo-Vista-Controlador, el marco de trabajo a utilizar es SPRING. 4. El lenguaje de programación es JAVA, con IDE NetBeans versión 6.1. 5. Metodología utilizada para el análisis, implementación y documentación de sistemas orientados a objetos RUP junto con lenguaje Unificado de Modelado UML. 6. Se utilizan archivos XML para el almacenamiento de datos de cada proyecto. 7. Se utiliza la metodología definida en la estructura de procesos generada por la herramienta MJS Process Designer. 2.3. Definición de la metodología utilizada para el Proyecto Para desarrollar el presente proyecto de fin de carrera se empleará el Lenguaje Unificado de Modelado UML. La elección de este lenguaje de modelado está basada principalmente por ser la más acorde y utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Asimismo, se tomó como base la metodología RUP (Rational Unified Process) para definir el proceso de desarrollo del proyecto y el modelo de procesos MoProSoft. 49 RUP pretende implementar las mejores prácticas actuales en ingeniería de software y tiene los siguientes beneficios: Desarrollo iterativo del software. Administración de requerimientos. Uso de arquitecturas basadas en componentes. Modelamiento visual del software. Verificación de la calidad del software. Control de cambios. Además, otro punto importante en cualquier desarrollo de software es el conocimiento adecuado y experiencia en la metodología elegida, siendo esta también una razón de la elección. A continuación se presenta la lista de artefactos RUP que formarán parte del presente proyecto y que se serán necesarios para la obtención del producto final: Catálogo de requerimientos: Son los requisitos funcionales y no funcionales del sistema. Es de suma importancia para establecer el alcance y las funcionalidades del proyecto. Ver sección 2.1 y 2.2. Diagramas de casos de uso: Son los casos de uso identificados a partir de los requisitos del sistema. Es de vital importancia para el proyecto ya que es la entrada principal para la especificación de requisitos, así como poder entender la lógica del negocio, sus procesos e identificar los actores del sistema. Ver figura 2.1 Diagrama de casos de uso de la herramienta EACS Project Manager. Especificación de requisitos de software - ERS: Son las especificaciones de cada uno de los casos de uso, permitiendo establecer la interacción entre el usuario y el sistema, así como los flujos básicos, alternativos y excepcionales que debe tener el sistema. Ver sección 2.4.2 Diagrama de clases de análisis: Presenta un primer diagrama general de las clases a utilizar en el sistema, es decir muestra un primer bosquejo para el diseño. Asimismo, se presenta el diccionario de clases. Ver figura 2.2 Diagrama de clases de análisis. Diagrama de clases de diseño: Presenta el diagrama de clase de diseño, donde se aprecia las clases que pertenecen a cada una de las capas del sistema, su 50 interrelación entre ellas y los métodos y atributos de cada una de ellas. Ver sección 3.1.3. Diagrama de componentes: Presenta la disposición de las partes integrantes de la aplicación y las dependencias entre los distintos módulos del sistema. Ver figura 3.3 Diagrama de componentes. Diagrama de secuencias: Presenta las secuencias del sistema, es decir el conjunto de pasos y la relación entre las diferentes clases del sistema, todo ello mediante la llamada a métodos e instancias de las clases. Resulta importante para llevar a cabo una correcta construcción del sistema. Todos los artefactos descritos se pueden revisar en los anexos del proyecto. Es importante mencionar que para el control de calidad del producto software será preciso utilizar el catálogo de pruebas basado en los casos de uso y pruebas integrales del sistema ver secciones F y G de anexos. El catálogo de pruebas esta enfocado a verificar la correcta implementación de los flujos básicos y alternativos presentados en la especificación de casos de uso. Asimismo, las pruebas integrales del sistema nos servirán para asegurar que todos los componentes operen correctamente cuando son combinados en la herramienta. 2.4. Análisis de la Solución Se trata de dar una visión global de la solución propuesta teniendo los siguientes objetivos en mente: identificar la necesidad que deseamos resolver, establecer la viabilidad del software propuesto, realizar el análisis técnico de los recursos disponibles, establecer restricciones técnicas y temporales, elaborar una definición del sistema que forme el fundamento de todo el trabajo de ingeniería subsiguiente. 2.4.1. Actores del sistema El software a desarrollar tiene los siguientes actores: jefe de proyectos, usuarios y administrador de sistemas. Se presenta una descripción de los mismos a continuación: 51 Jefe de Proyecto: es el encargado de la planificación, ejecución, control y término de los proyectos dentro del sistema, que estos acaben en el tiempo planeado, asegurando la correcta ejecución de estos. Usuario o miembros del equipo: son todas las personas que participan activamente en un proyecto, cada uno con responsabilidades específicas y están dirigidos de manera directa o indirecta por el jefe del proyecto. Administrador del Sistema: es el encargado de administrar los permisos a los usuarios en el Sistema, además se encarga del mantenimiento de proyectos, empresas y usuarios. 2.4.2. Casos de Uso Entre los procesos más importantes que serán soportados por la herramienta se encuentran la gestión de proyectos de software, crear la instancia de una metodología, administración de un proyecto específico y la gestión de configuración. Los casos de uso especifican la funcionalidad necesaria que permite a cada actor lograr estos propósitos. En la Figura 2.1 se presenta el diagrama de casos de uso de la herramienta EACS Project Manager. El caso de uso mantener proyecto tiene como finalidad la creación de un proyecto. Para cada proyecto se podrá registrar los datos principales así como asociarle una metodología definida en un proceso, además de los usuarios que participarán en la implementación de este a lo largo de su ciclo de vida. Los usuarios se asignarán al proyecto con un rol determinado asignado por el Jefe de proyecto. El sistema internamente realiza la creación de un espacio dentro del repositorio del sistema por cada proyecto creado. El caso de uso mantener actividades tiene como finalidad la producción de un elemento entregable. Estos entregables no sólo deben servir para medir el grado de éxito en el cumplimiento de la actividad, sino que deben ser útiles para el desarrollo del proyecto mismo. Algunos entregables sirven como productos intermedios y otros constituyen productos finales del proyecto. El registro de una actividad se realiza cuando el actor ya concluyó el registro de un proyecto pudiendo registrar múltiples actividades para un mismo proyecto. Por cada actividad creada se podrá registrar los datos principales, se podrá asociar una 52 actividad a una o más actividades de una metodología que se haya elegido cuando se creó el proyecto, así como asignar al responsable que participará en la implementación de esta a lo largo del proyecto. Figura 2.1. Diagrama de Casos de uso de la herramienta EACS Project Manager El caso de uso mantener artefacto tiene como finalidad evaluar y ejecutar los cambios a los elementos que conforman un proyecto de forma controlada, que ayuda a mantener el orden en el proyecto lo que contribuye a asegurar la integridad del software en la operación y consistencia de toda la documentación, lo que por lo general redundará en la eficiencia y la efectividad de la administración del proyecto. El registro de un artefacto se realiza cuando el actor ya concluyó el registro de un proyecto pudiendo registrar múltiples artefactos para un mismo proyecto, por cada artefacto creado se podrá registrar los datos principales así como asociar un 53 artefacto con una o más actividades del proyecto y con uno o más artefactos de la metodología que se haya elegido cuando se creó el proyecto. Se puede cargar y descargar artefactos desde y hacia el repositorio, el cual facilita el almacenar información de la evolución del sistema (historia) proporcionando acceso a esta información a todos los demás grupos de la organización, de acuerdo a los accesos que tenga definidos. Cuando un artefacto es descargado para ser modificado, no se permitirá que otro usuario lo descargue para el mismo fin, solo podrán consultarlo. El artefacto podrá ser descargado para ser modificado una vez que el usuario lo actualice como nueva versión o lo liberé. El sistema permite mostrar la relación de versiones de artefactos registrados, los cuales pueden ser ordenados por diferentes criterios, también permitirá la descarga de cualquiera de las versiones del artefacto, por defecto se descarga la versión actual. El sistema permite cambiar la versión vigente de los artefactos por otras ya registradas. El caso de uso mantener equipo proyecto tiene como finalidad la asignación de usuarios que participarán dentro del proyecto creado, cada uno tiene un rol definido dentro de éste, de manera que éstos se dediquen a cumplir los objetivos trazados. El caso de uso ingresar horas trabajadas en las actividades tiene como finalidad el registro de horas trabajadas dentro de la actividad a la que han sido designados los recursos en el proyecto. De esta manera se podrá gestionar las cargas de trabajo de los usuarios en los diferentes proyectos en los que se encuentran asignados. El caso de uso mantener usuario tiene como finalidad el registro de usuarios que participarán en los distintos proyectos según su cargo y perfil registrado en el sistema. El caso de uso mantener empresa tiene como finalidad el registro de las empresas que participarán en los distintos proyectos registrados en el sistema. A continuación se presentan las especificaciones de los casos de uso más importantes. 54 Mantener Proyecto. Caso de uso : Mantener Proyecto Actor : El Administrador del Sistema y el Jefe del Proyecto. Descripción : Este caso de uso permite el registro, actualización y visualización de los datos relacionados a un proyecto dentro del sistema. Pre-Condición : Haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El usuario selecciona la opción “Nuevo Proyecto”. 2. El sistema muestra un formulario donde se solicita los datos del nuevo proyecto, el usuario deberá ingresar los siguientes datos: Código. Nombre descriptivo. Empresa. Estado. Fecha inicio. Fecha fin. Descripción. Prioridad. Tipo. Jefe de Proyecto. Avance. Moneda. Presupuesto. Seleccionar una metodología ya definida por algún proceso que se adapte al proyecto que se creará. 3. El usuario ingresa la información solicitada. 4. El usuario selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra el proyecto asignándole un número consecutivo. 7. El sistema muestra un mensaje informando que se ha registrado un nuevo proyecto. Los pasos 1 al 7 son repetidos para cada proyecto nuevo que desee registrarse. Cuando el usuario termina de registrar proyectos, el caso de uso finaliza. Post-Condición : El sistema registra un nuevo proyecto. Flujo alternativo 1 : Se desea actualizar los datos del proyecto. 1. El sistema muestra el listado de proyectos encontrados en el sistema. 2. El usuario selecciona el proyecto a modificar y la opción “Editar”. 3. El sistema muestra la información del proyecto seleccionado. 4. El usuario modifica los atributos del proyecto, excepto el avance el cual es re calculado por las actividades y selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra los cambios realizados. Flujo alternativo 2 : Se desea visualizar los datos del proyecto. 1. El sistema muestra el listado de proyectos encontrados en el sistema. 2. El usuario selecciona el proyecto a visualizar y la opción “Ver”. 3. El sistema muestra un formulario con los datos principales del proyecto seleccionado. 55 Buscar Proyecto. Caso de uso : Buscar Proyecto. Actor : El Administrador del Sistema, el Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite la búsqueda de proyectos por diferentes criterios. Pre-Condición : Haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El usuario selecciona la opción “Proyectos”. 2. El sistema muestra un formulario donde se muestran los siguientes filtros de búsqueda: Responsable. Tipo Proyecto. Empresa. Estado. 3. El usuario deberá ingresar uno más criterios de búsqueda. 4. El usuario selecciona la opción “Buscar”. 5. El sistema muestra el listado con todos los proyectos que coincidan con los criterios de búsqueda ingresados. 6. El usuario selecciona el proyecto requerido. Los pasos 2 al 6 son repetidos para los diferentes criterios con los que se desee buscar. Cuando el proyecto buscado es encontrado, el caso de uso finaliza. Post-Condición : El sistema muestra uno o más proyectos encontrados. Mantener Actividades. Caso de uso : Mantener Actividades. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite el registro y actualización de los datos relacionados a una actividad de un proyecto específico, así como mostrar los artefactos registrados de la actividad. Pre-Condición : El usuario debe haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El usuario selecciona la opción “Nueva Actividad”. 2. El sistema muestra un formulario donde se solicita los datos de la nueva actividad, el usuario deberá ingresar los siguientes datos: Nombre actividad. Tipo. Estado. Prioridad. Responsable de la actividad. Actividad padre. Progreso. Horas estimadas. Fecha inicio. Fecha final. Descripción. Extender: Relacionar Actividad Metodología. 3. El usuario ingresa la información solicitada. 4. El usuario selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra la actividad asignándole un número consecutivo y la asocia al proyecto seleccionado. 7. El sistema muestra un mensaje informando que se ha registrado una nueva actividad. 56 Los pasos del 1 al 7 se repiten mientras el usuario desee registrar una nueva actividad. Cuando el usuario termina de registrar la actividad, el caso de uso finaliza. Post-Condición : El sistema registra satisfactoriamente la actividad asociándola al proyecto. Flujo alternativo 1 : Se desea actualizar los datos de la actividad. 1. El sistema muestra el listado de actividades encontradas según el proyecto seleccionado. 2. El usuario selecciona la actividad a modificar y la opción “Editar”. 3. El sistema muestra la información de la actividad seleccionada. 4. El usuario modifica los datos de la actividad y selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra los cambios realizados. Flujo alternativo 2 : Se desea mostrar los artefactos de la actividad registrada. 1. El sistema muestra el listado de actividades encontradas según el proyecto seleccionado. 2. El usuario selecciona la actividad para mostrar los artefactos registrados y la opción “Ver Artefactos”. 3. El sistema muestra un formulario con el listado de artefactos asociados a la actividad seleccionada. Buscar Mis Actividades. Caso de uso : Buscar Mis Actividades. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite la búsqueda de las actividades de un usuario por diferentes criterios. Pre-Condición : Haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El usuario selecciona la opción “Mis Actividades”. 2. El sistema muestra un formulario donde se muestran los siguientes filtros de búsqueda: Nombre del Proyecto. Estado Actividad. Semáforo. 3. El usuario deberá ingresar uno más criterios de búsqueda. 4. El usuario selecciona la opción “Buscar”. 5. El sistema muestra el listado de todas las actividades que coincidan con los criterios de búsqueda ingresados y se valida que dichas actividades tengan como responsable al usuario que realiza la búsqueda. 6. El usuario selecciona la actividad requerida. Los pasos 2 al 6 son repetidos para los diferentes criterios con los que se desee buscar. Cuando la actividad buscada es encontrada en el sistema, el caso de uso finaliza. Post-Condición : El sistema muestra una o más actividades encontradas. Relacionar Actividad Metodología. Caso de uso : Relacionar Actividad Metodología. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite asociar una actividad con una o más actividades ya definidas por la metodología instanciada en el proyecto. Pre-Condición : Haber ingresado a la creación o edición de alguna actividad. 57 Flujo de eventos : 1. El sistema realiza una búsqueda interna de las actividades que tiene la metodología seleccionada en el proyecto. 2. El sistema muestra el listado de actividades encontradas. 3. El usuario selecciona una o más actividades de la metodología que desee asociar a la actividad creada. 4. Si se eligieron actividades de la metodología instanciada, estas se registran asignándoles el número de la actividad creada y el identificador de la actividad de la metodología instanciada. Los pasos 1 al 4 se repiten para cada actividad de la metodología que se desee buscar. Mantener Artefacto. Caso de uso : Mantener Artefacto. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite el registro, carga y descarga de los artefactos, así como la visualización de versiones de estos. Pre-Condición : El usuario debe haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El usuario selecciona la opción “Nuevo Artefacto”. 2. El sistema muestra un formulario donde se solicita los datos del nuevo artefacto, el usuario deberá ingresar los siguientes datos: Código artefacto. Nombre del artefacto a cargar. Seleccionar el archivo a cargar. Descripción. Extender: Relacionar Actividad Artefactos. Extender: Relacionar Artefactos Metodología. 3. El usuario ingresa la información solicitada. 4. El usuario selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra el artefacto asignándole un número consecutivo y lo asocia al proyecto. 7. El sistema muestra un mensaje informando que se ha registrado un nuevo artefacto. Los pasos del 1 al 7 se repiten mientras el usuario desee registrar un nuevo artefacto. Cuando el usuario termina de registrar el artefacto, el caso de uso finaliza. Post-Condición : El sistema registra satisfactoriamente el artefacto relacionándolo a un proyecto específico. Flujo alternativo 1 : Se desea mostrar las versiones de los artefactos. 1. El sistema muestra el listado de artefactos encontrados según el proyecto. Por cada artefacto se muestra la relación de actividades en las que ha sido asociado. 2. El usuario selecciona el artefacto que desea mostrar las versiones y la opción “Versiones”. 3. El sistema muestra un formulario con el listado de las versiones de los artefactos encontrados. 4. El usuario puede seleccionar la versión del artefacto a descargar y seleccionar la opción “Descargar”. 5. El usuario puede modificar la versión vigente del artefacto y seleccionar la opción “Cambiar”. 6. El sistema registra los cambios realizados. 58 Flujo alternativo 2 : Se desea descargar el artefacto. 1. El sistema muestra el listado de artefactos encontrados según el proyecto. Por cada artefacto se muestra la relación de actividades en las que ha sido asociado. 2. El usuario selecciona el artefacto a descargar y la opción “Descargar”. 3. El sistema muestra la ventana de descarga del artefacto seleccionado. 4. El usuario ingresa la ruta en la cual desea realizar la descarga del artefacto. 5. El sistema valida los datos ingresados. 6. El sistema descarga el artefacto en la ruta ingresada. Relacionar Actividad Artefactos. Caso de uso : Relacionar Actividad Artefactos. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite asociar un artefacto con una o más actividades del proyecto. Pre-Condición : Haber ingresado a la creación o edición de algún artefacto. Flujo de eventos : 1. El sistema realiza una búsqueda interna de todas las actividades registradas que pertenecen al proyecto seleccionado. 2. El sistema muestra el listado de actividades encontradas. 3. El usuario selecciona una o más actividades del proyecto que desee asociar al artefacto creado. 4. Si se eligieron actividades del proyecto, estas se registran asignándoles el número del artefacto creado y el identificador de la actividad del proyecto seleccionada. Los pasos 1 al 4 se repiten mientras el usuario desee registrar un nuevo artefacto. Cuando el usuario termina de registrar el artefacto, el caso de uso finaliza. Post-Condición : El sistema muestra uno o más artefactos encontrados. Relacionar Artefacto Metodología. Caso de uso : Relacionar Artefacto Metodología. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite asociar un artefacto con uno o más artefactos ya definidos por la metodología instanciada en el proyecto. Pre-Condición : Haber ingresado a la creación o edición de algún artefacto. Flujo de eventos : 1. El sistema realiza una búsqueda interna de los artefactos que tiene la metodología seleccionada en el proyecto. 2. El sistema muestra un listado de los artefactos de la metodología encontrados. 3. El usuario selecciona uno o más artefactos de la metodología que desee asociar al artefacto creado. 4. Si se eligieron artefactos de la metodología instanciada, estos se registran asignándoles el número del artefacto creado y el identificador del artefacto de la metodología instanciada. Los pasos 1 al 4 se repiten mientras el usuario desee registrar un nuevo artefacto. Cuando el usuario termina de registrar el artefacto, el caso de uso finaliza. Post-Condición : El sistema muestra uno o más artefactos encontrados. Reservar Artefactos. Caso de uso : Reservar Artefactos. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite reservar un artefacto. Pre-Condición : Haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. 59 Flujo de eventos : 1. El sistema muestra el listado de artefactos encontrados según el proyecto. 2. El usuario selecciona el artefacto a reservar y la opción “Reservar”. 3. El sistema muestra los datos del artefacto a reservar. 4. El usuario selecciona la opción “Reservar”. 5. El sistema valida los datos ingresados. 6. El sistema protege el artefacto y cambia el estado del artefacto a “bloqueado”, así ningún otro usuario podrá modificarlo, solo consultarlo, registrando la fecha de reserva y el usuario que realizó dicha acción. Los pasos 1 al 6 se repiten mientras el usuario desee reservar un artefacto. Cuando el usuario termina de reservar el artefacto, el caso de uso finaliza. Post-Condición : El artefacto es reservado satisfactoriamente. Crear Versión Artefacto. Caso de uso : Crear Versión Artefacto. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite generar una nueva versión del artefacto. Pre-Condición : Haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El sistema muestra el listado de artefactos encontrados según el proyecto seleccionado. 2. El usuario selecciona el artefacto que ha reservado previamente y selecciona la opción “Subir”. 3. El sistema muestra un formulario donde se solicita los datos de la nueva versión del artefacto, el usuario deberá ingresar los siguientes datos: Seleccionar el archivo a cargar. Observaciones. 4. El usuario selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados y que el artefacto tenga el estado “bloqueado”. 6. El sistema registra la nueva versión del artefacto y cambia el estado del artefacto a “desbloqueado”, así los demás usuarios podrán reservarlo, registrando la fecha de generación de la nueva versión y el usuario que realizó dicha acción. Los pasos 1 al 6 se repiten mientras el usuario desee generar versiones de un artefacto. Cuando el usuario termina de generar versiones del artefacto, el caso de uso finaliza. Post-Condición : Se genera una nueva versión del artefacto. Flujo alternativo 1 : Se almacenan los artefactos y versiones creadas. 1. El sistema crea un espacio en el repositorio local del proyecto seleccionado por cada artefacto creado. 2. El sistema almacena por cada artefacto creado sus versiones generadas. 3. El sistema registra las rutas de los artefactos y versiones que son almacenados. Mantener Usuario. Caso de uso : Mantener Usuario. Actor : El Administrador del Sistema. Descripción : Este caso de uso permite el registro, actualización y eliminación de los datos relacionados a un usuario del sistema. Pre-Condición : El administrador debe haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. 60 Flujo de eventos : 1. El usuario administrador selecciona la opción “Nuevo Usuario”. 2. El sistema muestra un formulario donde se solicita los datos del nuevo usuario, el administrador deberá ingresar los siguientes datos: Apellido Paterno. Apellido Materno. Nombres. Perfil. Cargo. Estado. Usuario. Contraseña. 3. El usuario administrador ingresa la información solicitada. 4. El usuario administrador selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra el nuevo usuario asignándole un número consecutivo. 7. El sistema muestra un mensaje informando que se ha registrado un nuevo usuario. Los pasos del 1 al 7 se repiten mientras el usuario administrador desee registrar un nuevo usuario al sistema. Cuando el administrador termina de registrar al usuario ingresado, el caso de uso finaliza. Post-Condición : El sistema registra satisfactoriamente al nuevo usuario. Flujo alternativo 1 : Se desea actualizar los datos del usuario. 1. El sistema muestra el listado de usuarios encontrados en el sistema. 2. El usuario administrador selecciona el usuario a modificar y la opción “Editar”. 3. El sistema muestra la información del usuario seleccionado. 4. El usuario administrador modifica los datos del usuario seleccionado y selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra los cambios realizados. Flujo alternativo 2 : Se desea eliminar los datos del usuario. 1. El sistema muestra el listado de usuarios encontrados en el sistema. 2. El usuario administrador selecciona el usuario a eliminar. 3. El sistema cambia el estado del usuario. 4. El sistema registra el cambio realizado. Buscar Usuario. Caso de uso : Buscar Usuario. Actor : El Administrador del Sistema y el Jefe del Proyecto. Descripción : Este caso de uso permite la búsqueda de usuarios por diferentes criterios. Pre-Condición : Haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El usuario selecciona la opción “Usuarios”. 2. El sistema muestra un formulario donde se muestran los filtros de búsqueda: Apellidos y Nombres. Perfil. Cargo. Estado. 3. El usuario deberá ingresar uno más criterios de búsqueda, o aquellos que considere necesarios. 4. El usuario selecciona la opción “Buscar”. 61 5. El sistema muestra el listado con todos los usuarios que coincidan con los criterios de búsqueda ingresados. 6. El usuario administrador selecciona el usuario requerido. Los pasos 2 al 6 son repetidos para los diferentes criterios con los que se desee buscar. Cuando el usuario buscado es encontrado, el caso de uso finaliza. Post-Condición : El sistema muestra el o los usuarios encontrados. Mantener Empresa. Caso de uso : Mantener Empresa. Actor : El Administrador del Sistema. Descripción : Este caso de uso permite el registro, actualización y eliminación de los datos relacionados a una empresa del sistema. Pre-Condición : El administrador debe haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El usuario administrador selecciona la opción “Nueva Empresa”. 2. El sistema muestra un formulario donde se solicita los datos de la nueva empresa, el administrador deberá ingresar los siguientes datos: Nombre Empresa. Correo electrónico. Numero de teléfono 1. Numero de teléfono 2. Fax. Dirección 1. Dirección 2. País. Código postal. Dirección Web. Descripción. Tipo de empresa. 3. El usuario administrador ingresa la información solicitada. 4. El usuario administrador selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra la nueva empresa asignándole un número consecutivo. 7. El sistema muestra un mensaje informando que se ha registrado una nueva empresa. Los pasos del 1 al 7 se repiten mientras el usuario administrador desee registrar una nueva empresa al sistema. Cuando el administrador termina de registrar la empresa, el caso de uso finaliza. Post-Condición : El sistema registra satisfactoriamente la nueva empresa. Flujo alternativo 1 : Se desea actualizar los datos de la empresa. 1. El sistema muestra el listado de empresas encontradas en el sistema. 2. El usuario administrador selecciona la empresa a modificar y la opción “Editar”. 3. El sistema muestra la información de la empresa seleccionada. 4. El usuario administrador modifica los datos de la empresa y selecciona la opción “Grabar”. 5. El sistema valida los datos ingresados. 6. El sistema registra los cambios realizados. Flujo alternativo 2 : Se desea eliminar los datos de la empresa. 1. El sistema muestra el listado de empresas encontradas en el sistema. 2. El usuario administrador selecciona la empresa a eliminar. 3. El sistema cambia el estado de la empresa. 4. El sistema registra el cambio realizado. 62 Buscar Empresa. Caso de uso : Buscar Empresa. Actor : El Administrador del Sistema y el Jefe del Proyecto. Descripción : Este caso de uso permite la búsqueda de empresas por diferentes criterios. Pre-Condición : Haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. Flujo de eventos : 1. El usuario selecciona la opción “Empresas”. 2. El sistema muestra un formulario donde se muestran los filtros de búsqueda: Nombre Empresa. Tipo empresa. 3. El usuario deberá ingresar uno más criterios de búsqueda. 4. El usuario selecciona la opción “Buscar”. 5. El sistema muestra el listado con todas las empresas que coincidan con los criterios de búsqueda ingresados. 6. El usuario administrador selecciona la empresa requerida. Los pasos 2 al 6 son repetidos para los diferentes criterios con los que se desee buscar. Cuando la empresa buscada es encontrada, el caso de uso finaliza. Post-Condición : El sistema muestra la o las empresas encontradas. Ingresar Horas Trabajadas en las Actividades. Caso de uso : Ingresar Horas Trabajadas en las Actividades. Actor : El Jefe del Proyecto y usuarios. Descripción : Este caso de uso permite el ingreso de horas trabajadas en las actividades seleccionadas. Pre-Condición : El proyecto debe estar creado, así como las actividades que se realizarán. Flujo de eventos : 1. El sistema muestra el listado de actividades encontrados en el sistema las cuales tiene como responsable al usuario que ingreso al sistema. 2. El usuario selecciona la opción “Ver Horas Trabajo” para la actividad seleccionada. 3. El sistema muestra un formulario donde se solicita los siguientes datos: Fecha. Número de Horas. 4. El usuario ingresa la información solicitada. 5. El usuario selecciona la opción “Grabar”. 6. El sistema valida los datos ingresados. 7. El sistema muestra un mensaje informando que se ha registrado las horas trabajadas para la actividad seleccionada. Los pasos del 1 al 7 se repiten mientras el usuario administrador desee registrar las horas trabajadas por la actividad seleccionada. Cuando el administrador termina de registrar las horas trabajadas, el caso de uso finaliza. Post-Condición : El sistema registra satisfactoriamente el esfuerzo realizado para la actividad seleccionada. Mantener Equipo Proyecto. Caso de uso : Mantener Equipo Proyecto Actor : El Administrador del Sistema y el Jefe del Proyecto. Descripción : Este caso de uso permite el registro y eliminación de los usuarios que forman parte del proyecto. Pre-Condición : El Administrador o Jefe del Proyecto deben haber iniciado una sesión en el sistema con sus respectivos nombres de usuario y contraseña. 63 Flujo de eventos : 1. El usuario selecciona la opción “Personal”. 2. El sistema muestra un formulario donde se solicita los datos del nuevo usuario que formará parte del proyecto, se deberá seleccionar los siguientes datos: Nombre del usuario. Rol del usuario a desempeñar en el proyecto. 3. El usuario administrador o jefe de proyecto selecciona la información solicitada. 4. El usuario administrador o jefe de proyecto selecciona la opción “Agregar Personal”. 5. El sistema valida los datos ingresados. 6. El sistema registra el nuevo usuario que formará parte del equipo del proyecto seleccionado. Los pasos del 2 al 6 se repiten mientras se desee registrar un nuevo usuario que forme parte el proyecto. Cuando se termina de registrar el equipo del proyecto, el caso de uso finaliza. Post-Condición : El sistema registra satisfactoriamente el nuevo usuario que formará parte del equipo del proyecto. 2.5. Diagrama de Clases de Análisis A partir de la identificación de los requerimientos del sistema, el diagrama de casos de uso y el análisis del comportamiento de la herramienta, se ha elaborado el diagrama de clases de análisis que se considerará para el desarrollo de la herramienta. En la Figura 2.2 se presenta el diagrama de clases de análisis de la herramienta EACS Project Manager. En el anexo C: Diccionario de Datos Diagrama de Clases, se muestra la descripción detallada de todas las clases involucradas en el sistema a implementar. A continuación se detalla la descripción de las principales clases de la herramienta: BProyecto: clase que representa un proyecto en el sistema. Además de guardar toda la información del proyecto, se relaciona directamente con la clase BMetodologia la cual contiene la relación con la metodología definida en un proceso, BProyectoUsuario la cual contiene la relación del equipo de trabajo, BEmpresa la cual contiene la relación con la empresa a quien se realiza el proyecto, BActividad la cual contiene la relación de las actividades y BArtefacto la cual contiene la relación de los artefactos para el proyecto seleccionado. 64 Figura 2.2. Diagrama de Clases de Análisis. 65 BActividad: clase que representa a una actividad en el sistema. Además de guardar la información de las actividades asociadas a un proyecto, se relaciona directamente con la clase BMetodologiaActividad la cual contiene la relación de las actividades de la metodología que ha sido asociada al proyecto, BProyectoUsuario la cual contiene la relación con el usuario responsable, BArtefacto la cual contiene la relación de los artefactos asociados, además tiene una relación consigo misma BActividad, la cual contiene la relación entre las actividades padre e hijas. BArtefacto: clase que representa a un artefacto registrado en el sistema. Además de guardar la información de los artefactos asociados a un proyecto, se relaciona directamente con la clase BMetodologiaArtefacto la cual contiene la relación de los artefactos de la metodología que ha sido asociada al proyecto, BActividad la cual contiene la relación de actividades del proyecto a las que se le asocio el artefacto, BProyectoUsuario la cual contiene la relación con el usuario que registro y reservo el artefacto y BArtefactoVersion la cual contiene la relación de versiones del artefacto. BArtefactoVersion: clase que representa las versiones de un artefacto. Además de guardar la información de las versiones de los artefactos del proyecto, se relaciona directamente con la clase BProyectoUsuario la cual contiene la relación con el usuario que registro la versión del artefacto. BActividadHoras: clase que representa todo el tiempo en horas que se ha trabajado la actividad, se relaciona directamente con la clase BProyectoUsuario la cual contiene la relación con el usuario que ha trabajado la actividad y que ha ingresado sus horas trabajadas. BGenTipos: clase que representa de forma genérica algunos tipos y parámetros utilizados por las demás clases, las clases que heredan de esta son: TipoProyecto, EstadoProyecto, TipoActividad, EstadoActividad, TipoEmpresa, PerfilUsuario, EstadoUsuario, CargoUsuario, Moneda, Rol y Prioridad. 66 2.6. Restricciones del proyecto Como se indicó el proyecto la herramienta EACS Project Manager es parte del proyecto COMPETISOFT-PUCP y como tal tiene restricciones de los otros componentes como: Definición de la metodología de desarrollo. Usar XPDL para la definición de las metodologías. La herramienta LMB Process Audit para la evaluación y auditoria de los proyectos. Lenguaje de programación Java. Tomcat, contenedor de servlets. Servicio Web, conjunto de protocolos y estándares, para la gestión de configuración. Exclusiones del proyecto Entre las funcionalidades que no serán abordadas por el proyecto se encuentran: La herramienta no registra un calendario o agenda de eventos y tareas a realizar en el proyecto. La herramienta no realiza el cálculo de la ruta crítica, en el cual se calcula las fechas teóricas de inicio y finalización tempranas y tardías para todas las actividades La herramienta no permite establecer la línea base del proyecto. 2.6.1. Definición de Metodología de Desarrollo usada en la herramienta Para la definición de las plantillas de metodología de desarrollo se utiliza el componente XPDL del proyecto COMPETISOFT – JAMESA. Las plantillas de metodología definidas nos ayudan a relacionar las actividades y artefactos involucrados en esta, con las actividades y artefactos implementados en el proyecto desarrollado. En el Código 2.1 se muestra la estructura de la metodología y sus atributos, entre ellos el estado, la información de la versión así como los procesos involucrados. 67 Código 2.1. XPDL de la Metodología - JAMESA. En el Código 2.2 se define la estructura de las actividades de la metodología, el tipo de actividad, las actividades de referencia. Así mismo se define el flujo y orden de las actividades en la metodología. Código 2.2. XPDL de las Actividades - JAMESA. En el Código 2.3 se define la estructura de los artefactos de la metodología, el tipo de artefacto y el nombre del artefacto. Así como también el propietario del artefacto. … Código 2.3. XPDL de los Artefactos - JAMESA. 68 2.6.2. Gestión de Configuración En la presente sección se revisará las estructuras utilizadas para almacenar los datos de la gestión de configuración, esta incluye el gestor de los artefactos del repositorio, los artefactos en sí que son los entes que están compuestos por los documentos y código fuente generado en las diferentes actividades y las versiones de cada uno de estos. Esta información es almacenada en formato XPDL para que posteriormente el grupo COMPETISOFT – LIMEBO acceda a estos archivos para realizar la evaluación y auditoria de los proyectos. En el Código 2.4 se define la estructura de los artefactos para la gestión de la configuración del proyecto, entre los datos que contiene se encuentran el tipo de artefacto, la versión actual vigente, el permiso de acceso. También se incluye la asociación del artefacto con el artefacto de la metodología usada en el proyecto. Código 2.4. XPDL para administrar los Artefactos. En el Código 2.5 se define la estructura de las versiones de los artefactos para la gestión de la configuración del proyecto, entre los datos que contiene se encuentran 69 el número de versión, el estado en el que se encuentra, el usuario que generó la versión y fecha de creación. Código 2.5. XPDL para administrar las Versiones de los Artefactos. 2.7. Administración de proyectos La herramienta EACS Project Manager consta de un módulo de administración de proyectos, el cual tiene como propósito facilitar la planificación, la realización, la evaluación y control de todos los proyectos. Se ocupa de los proyectos internos y externos de la organización. La herramienta brinda las siguientes funcionalidades: Permite realizar la búsqueda de proyectos por diferentes filtros: nombre del responsable, tipo de proyecto, nombre de la empresa y estado del proyecto. Permite mostrar la relación de los proyectos registrados en el sistema. Se pueden visualizar y editar los datos del proyecto seleccionado. Permite realizar la búsqueda de todas las actividades asignadas de un usuario por diferentes filtros: nombre del proyecto, tipo y estado de la actividad. 70 Permite mostrar la relación de actividades que está desarrollando un usuario asignado como parte del equipo en el proyecto, prestando especial interés a aquellas actividades que están sufriendo algún retraso asignándoles un color diferente a las demás con lo que permitirá al usuario detectarlas a tiempo, de esta manera las actividades que les quedan menos del 20% del tiempo para que finalice o se encuentran retrazadas se muestran en color rojo, las actividades que faltan más del 20% pero menos de 60% del tiempo para terminar se muestran en color anaranjado y las actividades que faltan más del 60% del tiempo para terminar se muestran en color azul. Permite registrar las horas de trabajo realizado por el usuario, el cual puede ir añadiendo la fecha y el número de horas realizadas en la actividad seleccionada. Permite realizar la búsqueda de usuarios del sistema por diferentes filtros: apellidos y nombres, perfiles del sistema, estado del usuario y cargo en el proyecto. Permite mostrar la relación de los usuarios registrados en el sistema. Se pueden editar los datos del usuario seleccionado. Permite crear un nuevo usuario registrando sus datos principales, así como asociarle un nombre de usuario y contraseña para su ingreso en el sistema. Permite realizar la búsqueda de empresas por diferentes filtros: nombre y tipo de empresa. Permite mostrar la relación de las empresas registrados en el sistema. Se pueden editar los datos de la empresa seleccionada. Permite crear una nueva empresa registrando sus datos principales, así como asociarle un tipo de empresa. Permite exportar un documento de desarrollo del proyecto seleccionado en formato HTML, con los datos más importantes como: datos del proyecto, actividades, artefactos y recursos. Permite exportar un documento de esfuerzo en formato HTML mostrando todo el esfuerzo en número de horas que los miembros del equipo han ido imputando a lo largo del tiempo en cada actividad. Permite mostrar la relación de las actividades y sus grupos en forma de cascada, según la dependencia entras estas. 71 2.8. Administración de proyectos específicos La herramienta EACS Project Manager consta de un módulo de administración de proyectos específicos, el cual tiene como propósito establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costos esperados mediante la coordinación y el manejo de los recursos del mismo. La herramienta brinda las siguientes funcionalidades: Permite crear proyectos registrando sus datos principales, así como asociarle una metodología definida en un proceso, asignarle un jefe de proyecto, empresa, fecha de inicio y fin estimado y el presupuesto inicial programado. Permite crear un espacio para almacenar cada proyecto en el repositorio local del sistema. Permite mostrar la relación del equipo asignado al proyecto seleccionado. Se pueden editar los datos del equipo registrado en el proyecto. Permite asignar miembros al equipo del proyecto, necesarios para la ejecución del proyecto seleccionado, con sus correspondientes roles. Permite mostrar la relación de actividades en niveles de dependencia del proyecto seleccionado, las cuales pueden ser ordenadas por nombre, fecha inicial, fecha final y estado. Se pueden editar los datos de las actividades registradas en el proyecto. Permite crear actividades al proyecto seleccionado, registrando sus datos principales, así como asociarles las actividades definidas por la metodología elegida para el proyecto. Permite agrupar aquellas actividades que compartan características o que se van a completar en el mismo intervalo de tiempo bajo una actividad padre o resumen. Permite asignar un responsable a las actividades creadas. Permite mostrar la relación de artefactos de la actividad seleccionada, los cuales pueden ser ordenados por nombre del artefacto. Permite mostrar la relación de artefactos del proyecto seleccionado, los cuales pueden ser ordenados por nombre, Por cada artefacto se muestra la relación de actividades a las que fue asociado. Permite registrar en el proyecto seleccionado los datos principales de los artefactos que se desarrollarán, así como cargar al repositorio un artefacto para 72 asociarle las actividades correspondientes del proyecto y relacionar el artefacto con los artefactos definidos en la metodología que se definió en el proyecto seleccionado. Permite descargar, reservar y visualizar los artefactos registrados en el proyecto. Permite identificar la actividad en que se estará utilizando a cada uno de los usuarios y la duración de esa utilización mediante el diagrama de Gantt, de tal modo que puedan identificarse periodos ociosos innecesarios y se dé también al jefe de proyecto una visión completa de la utilización de los recursos que se encuentran bajo su supervisión. Permite mostrar en un diagrama de Gantt, el porcentaje de avance por cada actividad mostrando las actividades según su distribución de acuerdo al calendario, de manera tal que se pueda visualizar el periodo de duración de cada actividad, sus fechas de iniciación y terminación e igualmente el tiempo total requerido para la ejecución de una actividad determinada. 2.9. Gestión de la Configuración La herramienta EACS Project Manager consta de un módulo de gestión de la configuración, el cual tiene como propósito asegurar la validez y disponibilidad de las versiones de los artefactos en todas las etapas de vida del software, manteniendo la integridad de los elementos de trabajo identificando, controlando y auditando dichos elementos. En la Figura 2.3 se muestra el flujo de gestión de la configuración usado en la herramienta EACS Project Manager. La herramienta brinda las siguientes funcionalidades: Permite agregar artefactos y sus nuevas versiones al repositorio asignado al proyecto, creando un espacio por cada artefacto creado dentro del cual se almacenarán las versiones creadas. Permite recuperar archivos del repositorio en modo lectura (archivo que no será editado o modificado). Permite cambiar el número de versión vigente del artefacto seleccionado. 73 Permite recuperar archivos del repositorio con el propósito de modificarlos, llamamos a esta operación “check-out”. Dichos archivos serán marcados como archivos reservados o bloqueados, este archivo no podrá ser modificado por otro miembro del equipo, el repositorio mantendrá siempre un registro de nuestro intento de modificar los archivos. Esta copia local se realiza generalmente para realizar cambios o modificaciones sobre la copia mientras está bloqueada. El equipo podrá descargar el archivo sin permisos de modificarlo. Figura 2.3. Grafico con los conceptos principales usados en EACS Project Manager Permite subir los archivos modificados al repositorio, llamamos a esta operación “check-in”. Nuestros archivos de trabajo serán reincorporados o desbloqueados y la herramienta EACS Project Manager actualizará el repositorio con las nuevas versiones creadas de los archivos modificados y se liberarán para que el equipo pueda acceder a estos. Permite controlar las versiones de los artefactos, mostrando la relación de versiones creadas del artefacto indicando el número de versión creada, el nombre del miembro del equipo que realizó el cambio y la fecha de creación de la nueva versión. El número de versiones que se pueden crear es ilimitado. Permite descargar las versiones de los artefactos del repositorio al espacio local del usuario. 74 Capitulo 3: Diseño En el presente capítulo se describen los diferentes aspectos que se han tenido en cuenta para diseñar la aplicación. En dicho diseño se modela el sistema y se incluye la arquitectura, para que soporte todos los requisitos especificados en el capítulo anterior. 3.1. Arquitectura de la Solución La arquitectura constituye el diseño a alto nivel de una aplicación, esto implica subdividir la aplicación en componentes funcionales y particionar estos componentes en capas. El diseño de la arquitectura de alto nivel es neutral a las tecnologías utilizadas. Para la presente tesis se escogió una arquitectura Web basada en una arquitectura de aplicaciones de tres capas, en donde se separa la presentación, la lógica del negocio y el controlador, esto asegura una división clara de responsabilidades y hace que el sistema sea mantenible y extensible. 75 Las capas a considerar son las siguientes: La capa de presentación es la capa que contiene todo aquello con lo que el usuario puede interactuar. Además, contiene todos los elementos que constituyen la interfaz con el usuario, validación de datos de entrada y el formateo de los datos de salida. Además expone los servicios de la capa de lógica del negocio a los usuarios. Sabe cómo procesar una petición de cliente, cómo interactuar con la capa de lógica del negocio, y cómo seleccionar la siguiente vista a mostrar. La capa de lógica del negocio es la capa que contiene los objetos y servicios de negocio de la aplicación. Recibe peticiones de la capa de presentación y procesa la lógica de negocio basada en las peticiones. La capa de datos es la capa donde se manejan los mecanismos para manipular y persistir la información. Esta permite gestionar las consultas, actualizaciones e inserciones de las entidades del sistema. En la Figura 3.1 se ilustra la interacción de las capas de la arquitectura planteada. Figura 3.1. Diagrama de capas de la herramienta. Respuestas HTTP JAVA SERVLET - CONTROLADOR MODELO VISTA - JSF DATOS XML Objetos persistentes Pedidos SPRING 76 Para lograr este diseño se eligió el patrón MVC (Modelo-Vista-Controlador) que permite un diseño flexible, escalable y una separación eficiente entre las distintas capas de una aplicación. Para la capa de presentación (la vista) se buscaba un marco de referencia (Framework) que proporcionase una mayor facilidad en la elaboración de pantallas, mapeo entre los formularios y sus clases en el servidor, la validación, conversión, gestión de errores y de ser posible, que facilitase también el incluir componentes complejos (menús, árboles, tablas, pestañas, ajax, etc) de una forma sencilla y sobre todo fácil de mantener. Para esta capa se ha elegido Java Server Faces [JSF]. Se pueden utilizar EJB’s [EJB] (Enterprise JavaBeans) o POJO [POJO] (Plain Old Java Objects) para construir la capa de lógica del negocio. Se decidió desde el primer momento no emplear EJB’s por su elevado tiempo de desarrollo, además la herramienta EACS Project Manager es una aplicación Web que no será accedida remotamente desde otras aplicaciones, motivo por el cual se utilizará POJO. Los objetos y servicios de negocio existen en la capa de lógica del negocio. Un objeto de negocio no sólo contiene datos, también la lógica asociada con ese objeto específico. Los servicios de negocio interactúan con objetos de negocio y proporcionan una lógica de negocio de más alto nivel. POJO, con la ayuda del marco de trabajo Spring [SPRING], implementará la capa de lógica del negocio de la aplicación. Debido a que esta capa tiene acceso a los datos, realiza tareas de carga y descarga de datos hacia y desde un archivo plano en formato XML [XML]. El controlador es el objeto que proporciona significado a las órdenes del usuario, actuando sobre los datos representados por el modelo. Cuando se realiza algún cambio, entra en acción, bien sea por cambios en la información del modelo o por alteraciones de la vista. Beneficios de la arquitectura La principal ventaja de la arquitectura planteada se deriva en la modularidad del diseño. Cada una de las partes empleadas es intercambiable de forma sencilla y limpia por otras soluciones disponibles. Por ejemplo, para la vista se emplea Java Server Faces, pero nada impide emplear también una aplicación de escritorio mediante Swing o SWT sin tener que tocar ni 77 una sola línea de código de las restantes capas. Es más, nada impediría que se pudiese disponer de una aplicación con una parte de la capa de presentación en JSF y otra parte, para otro tipo de usuarios, en Swing, ambas funcionando a la vez y compartiendo todo el resto del código (lógica de negocio, persistencia, etc). De igual forma, si se desean cambiar elementos de la capa de datos empleando otro marco de trabajo para el mapeo diferente del utilizado o sencillamente no utilizar ninguno, tan sólo serían necesarios cambios en esa capa. La necesidad de integración con la herramienta de JAMESA, que nos proporcionaría un archivo XPDL con la definición de la metodología, y posteriormente con la de LIMEBO, el cual debe recibir la información del proyecto, sus actividades y artefactos; hace necesario un medio eficaz de intercambio de datos. Además debido a que se desea conservar la modularidad en todas las capas es que se ha diseñado la capa de datos para que utilice archivos XML para el almacenamiento de la información, ya que este tipo de archivos se utilizan como un estándar para el intercambio de datos entre aplicaciones. De la misma manera se podrían sustituir cualquiera de las otras capas. El diseño se ha hecho reduciendo al mínimo posible las dependencias entre ellas. 3.1.1. Patrón de Diseño Modelo Vista Controlador El patrón MVC es un patrón de diseño arquitectural recomendado para aplicaciones interactivas Java. Entre sus características se tiene que separa los conceptos de diseño, y por lo tanto disminuye la duplicación de código, la centralización del control y hace que la aplicación sea más extensible. [MVC] Los componentes en los que se separan los datos de una aplicación, la interfaz de usuario y la lógica de control son los siguientes: Modelo: encapsula los datos y las funcionalidades del negocio. El modelo incluye todas las funciones necesarias para acceder a los datos guardados en los archivos XML. 78 Vista: se encarga de mostrar la información recibida al usuario por medio de la interfaz gráfica de usuario. Así como también notifica al Controlador que se ha producido algún evento. Controlador: recibe los eventos de entrada y se encarga de realizar peticiones de actualización al modelo o a la vista según sea el caso. La principal ventaja de esta separación reside en la facilidad para realizar cambios en la aplicación puesto que cuando realizamos un cambio de bases de datos, programación o interfaz de usuario solo tocaremos uno de los componentes y podemos modificar alguno de los componentes sin conocer cómo funcionan los otros. En la Figura 3.2 se muestra el esquema de funcionamiento que define dicho patrón en base a las tres capas anteriormente mencionadas. Figura 3.2. Esquema del patrón MVC. 3.1.2. Subsistemas del Software A continuación se presentan los componentes principales que se encuentran en la herramienta EACS Project Manager (Figura 3.3). A continuación, se detalla la descripción de cada uno de ellos. Interfaz GUI: contiene los archivos de extensión .jsp que conforman la interfaz Web con la que interactúa el usuario. 79 Proyectos: contiene las clases que permiten el mantenimiento de proyectos, actividades, usuarios, empresas, asignar actividades y metodologías. Gestión de la Configuración: contiene las clases que permiten registrar, reservar, liberar, cargar y descargar los artefactos de los proyectos. Manejador de Versiones: contiene las clases que permiten registrar y controlar las versiones de los artefactos de los proyectos. Reportes: contiene las clases que permiten la creación y ejecución de los reportes de la aplicación. Manejador XML: contiene las clases que permiten la lectura y escritura de los archivos XML. Manejador XPDL (Metodologías): permite la creación de metodologías desde la aplicación MJS Process Designer. Figura 3.3. Diagrama de Componentes de la Aplicación. 80 3.1.3. Diagrama de Clases de Diseño A continuación se muestran los diagramas de clases de diseño, basados en las clases de análisis presentadas anteriormente, que ilustran la interacción entre las entidades y lógica de negocio. Las clases de diseño utilizadas en la herramienta EACS Project Manager se clasifican en: Tipo Controller: clases que sirven de intermediarias entre las peticiones del cliente y la lógica del negocio. Tipo Service: interfaces que contienen toda la funcionalidad referente a la lógica del negocio del sistema, contienen todos los servicios y sus correspondientes métodos para trabajar con las entidades. Esta capa contiene interfaces, por lo que solo se encuentran las definiciones de los métodos a utilizar. Estos servicios son implementados por clases de tipo ServiceImpl. Tipo Entity: clases que representan las entidades de negocio utilizadas por el sistema así como sus correspondientes gestores que los administran. El servicio llamado serviceLocator es el bean que permanecerá persistente en toda la aplicación y podrá ser utilizado en cualquier momento en el sistema. A partir de este único bean podremos incluir atributos que instancien a las clases que nos servirán para manejar los proyectos, actividades y artefactos. La implementación de este servicio llamado ServiceLocatorBean es el encargado de iniciar los servicios de todas las entidades con la que se trabaja en el sistema: usuarios, empresas, proyectos, actividades, artefactos. En esta sección se muestran los principales diagramas de clases de diseño del sistema. El modelo completo de clases de diseño se presenta en el Anexo D: Diagramas de Clases de Diseño. En la Figura 3.4 se muestran las clases de diseño implicadas en la búsqueda y consulta de proyectos, registro de los datos generales del proyecto y registro de usuarios al proyecto. En la Figura 3.5 se muestran las clases de diseño implicadas en la consulta de actividades, registro de los datos generales de las actividades y registro de usuarios a las actividades. 81 Figura 3.4. Diagrama de Clases de Diseño – Proyectos. 82 Figura 3.5. Diagrama de Clases de Diseño – Actividades. 83 En la Figura 3.6 se muestran las clases de diseño implicadas en la consulta de artefactos, registro de los datos generales de los artefactos y versiones de estos. Figura 3.6. Diagrama de Clases de Diseño – Artefactos. 3.1.4. Diagrama de Secuencia En el diagrama de secuencia se muestra la interacción y los mensajes que se intercambian entre los objetos que conforman la herramienta según su secuencia en el tiempo. Con estos diagramas se puede observar la interacción de estos objetos dentro de un escenario determinado. Se presentan a continuación la descripción de los principales diagramas de secuencia. En el anexo E: Diagramas de Secuencia, se presentan los diagramas de secuencia adicionales de la herramienta EACS Project Manager. 84 Diagrama de Secuencia – Carga inicial En la Figura 3.7 se muestra el diagrama de secuencia de carga inicial del sistema, en el cual podemos observar la interacción entre los diferentes componentes necesarios para realizar la carga inicial de información al sistema. El proceso de carga inicial comienza cuando se carga el sistema, la aplicación carga el constructor de la clase ApplicationBean la cual contiene un objeto de tipo ServiceLocator, en esta clase encontramos todos los servicios que tiene el sistema. Estos servicios son cargados en la clase ServiceLocatorBean, la cual llama al constructor de todos los servicios que tiene el sistema, los cuales a su vez llaman a la clase MotorXML, iniciándose un proceso de lectura de los datos iniciales de sus respectivos archivos XML obteniendo un gestor por cada tipo de servicio cargado. Figura 3.7. Diagrama de Secuencia Carga Inicial. 85 Diagrama de Secuencia – Registrar Proyecto En la Figura 3.8 se muestra el diagrama de secuencia Registrar Proyecto, en el cual podemos observar la interacción entre los diferentes componentes necesarios para realizar el registro de proyectos en el sistema. Este proceso comienza cuando se selecciona la opción “Grabar” del formRegistrarProyecto, la aplicación envía una petición para realizar el registro a la clase ApplicationBean la cual contiene un objeto de tipo ServiceLocator, en esta clase encontramos todos los servicios que tiene el sistema. Para el registro del proyecto se obtiene del servicio SGenTipos el número de identificador que tendrá el nuevo proyecto. El servicio SProyecto contiene los objetos y métodos respectivos para realizar el registro. Para registrar un nuevo proyecto el SProyecto llama al gestor de proyectos BGestorProyecto, mediante esta clase logramos que los objetos trabajen con sus correspondientes datos obteniendo de esta manera la relación de proyectos de tipo BProyecto a la que agregaremos el nuevo proyecto. Una vez que el objeto BProyecto esté cargado con los datos ingresados, se iniciará un proceso en el cual se escribirá la información correspondiente en el archivo XmListaProyecto a través de la clase MotorXML. Si el nuevo proyecto tiene relacionados usuarios que forman parte del equipo de trabajo, se realiza un proceso similar al anterior para su registro y la relación entre estos se guarda en el archivo XmListaProyectoUsuarios. Diagrama de Secuencia – Registrar Actividad En la Figura 3.9 se muestra el diagrama de secuencia Registrar Actividad, en el cual podemos observar la interacción entre los diferentes componentes necesarios para realizar el registro de actividades del proyecto y las actividades de una metodología seleccionada. Este proceso comienza cuando se selecciona la opción “Grabar” del formRegistrarActividad, la aplicación envía una petición para realizar el registro a la clase ApplicationBean la cual contiene un objeto de tipo ServiceLocator. 86 Figura 3.8. Diagrama de Secuencia para Registrar Proyecto. 87 Figura 3.9. Diagrama de Secuencia para Registrar Actividades. 88 Para el registro de las actividades se obtiene del servicio SGenTipos el número de identificador que tendrá la nueva actividad. Para registrar una nueva actividad el servicio SActividad llama al gestor de actividades BGestorActividades, obteniendo de esta manera la relación de actividades de tipo BActividad a la que agregamos la nueva actividad. Una vez que el objeto BActividad esté cargado con los datos ingresados, se iniciará un proceso en el cual se escribirá la información correspondiente en el archivo XmListaActividad a través de la clase MotorXML. Si la nueva actividad tiene asociadas actividades de la metodología seleccionada en el proyecto, se realiza un proceso similar al anterior para su registro y la relación entre estas se guarda en el archivo XmListaActividad. Si la nueva actividad tiene relacionados usuarios que forman parte del equipo de trabajo para esta actividad, se realiza un proceso similar al anterior para su registro y la relación entre estos se guarda en el archivo XmListaActividadUsuarios. Diagrama de Secuencia – Ingresar Horas Trabajadas en las Actividades En la Figura 3.10 se muestra el diagrama de secuencia Ingresar Horas Trabajadas en las Actividades, en el cual podemos observar la interacción entre los diferentes componentes necesarios para realizar el registro de horas trabajadas por el equipo de trabajo. Este proceso comienza cuando se selecciona la opción “Grabar” del formRegistrarMisActividades, la aplicación envía una petición para realizar el registro a la clase ApplicationBean la cual contiene un objeto de tipo ServiceLocator. Para el registro de horas trabajadas en las actividades se obtiene del servicio SGenTipos el número de identificador que tendrá el registro de horas. Para registrar las horas empleadas en una actividad el servicio SActividadesHoras llama al gestor de actividades BGestorActividadesHoras, obteniendo de esta manera la relación de actividades de tipo BActividadHoras a la que agregamos el nuevo registro de horas. 89 Figura 3.10. Diagrama de Secuencia para Ingresar Horas Trabajadas en las Actividades. 90 Una vez que el objeto BActividadHoras esté cargado con los datos ingresados, se iniciará un proceso en el cual se escribirá la información correspondiente en el archivo XmlListaActividadesHoras a través de la clase MotorXML. Diagrama de Secuencia – Registrar Artefacto En la Figura 3.11 se muestra el diagrama de secuencia Registrar Artefacto, en el cual podemos observar la interacción entre los diferentes componentes necesarios para realizar el registro de artefactos al proyecto así como asociarlos con las actividades del proyecto y los artefactos de la metodología seleccionada. Este proceso comienza cuando se selecciona la opción “Grabar” del formRegistrarArtefacto, la aplicación envía una petición para realizar el registro a la clase ApplicationBean la cual contiene un objeto de tipo ServiceLocator. Para el registro de los artefactos se obtiene del servicio SGenTipos el número de identificador que tendrá el nuevo artefacto y se le coloca como versión vigente generada. Para registrar un nuevo artefacto el servicio SArtefacto llama al gestor de artefactos BGestorArtefactos, obteniendo de esta manera la relación de artefactos de tipo BArtefacto a la que agregamos el nuevo artefacto. Una vez que el objeto BArtefacto esté cargado con los datos ingresados, se iniciará un proceso en el cual se escribirá la información correspondiente en el archivo XmListaArtefacto a través de la clase MotorXML. Si el nuevo artefacto está relacionado a una o más actividades del proyecto estas son registradas siguiendo un proceso similar al anterior y la relación entre estos se guarda en el archivo XmListaArtefactoActividades. Si el nuevo artefacto tiene asociados artefactos de la metodología seleccionada en el proyecto, se realiza un proceso similar al anterior para su registro y la relación entre estos se guarda en el archivo XmListaArtefactoMetodologia. Diagrama de Secuencia – Crear Versión Artefacto En la Figura 3.12 se muestra el diagrama de secuencia Crear Versión Artefacto, en el cual podemos observar la interacción entre los diferentes componentes necesarios para realizar el registro de la nueva versión del artefacto al proyecto. 91 Figura 3.11. Diagrama de Secuencia para Registrar Artefactos. 92 Figura 3.12. Diagrama de Secuencia para Crear Versión Artefacto. 93 Este proceso comienza cuando se selecciona la opción “Subir” del formRegistrarArtefacto, la aplicación envía una petición para realizar el registro a la clase ApplicationBean la cual contiene un objeto de tipo ServiceLocator. Para el registro de la nueva versión del artefacto se obtiene del servicio SGenTipos el número de versión que tendrá el nuevo artefacto y se le coloca como versión vigente generada. Para registrar la nueva versión del artefacto, agregamos a la relación de versiones del objeto BArtefacto seleccionado, el objeto BArtefactoVersion creado, el servicio SArtefacto llama al gestor de artefactos BGestorArtefactos, obteniendo de esta manera la relación de artefactos de tipo BArtefacto en la cual buscamos el objeto seleccionado para actualizar su relación de versiones. Una vez que el objeto BArtefacto esté cargado con los datos ingresados, se iniciará un proceso en el cual se escribirá la información correspondiente en el archivo XmListaArtefacto a través de la clase MotorXML. 3.2. Diseño de Interfaz Gráfica En esta sección se presentan detalles generales sobre el diseño de la interfaz del sistema para lo cual se detallan las consideraciones que se tendrá al diseñar el software. Así mismo se presentan los prototipos del sistema. 3.2.1. Criterios para el diseño de la interfaz gráfica A continuación se describen las consideraciones que se tendrá al diseñar el software con el objetivo de uniformizar la interfaz gráfica y hacerlo más sencillo y fácil de manejar. Todas las páginas elaboradas tendrán en la parte superior un logo y el nombre que representa al sistema, el nombre del usuario que ha ingresado y además íconos de enlaces a la página de inicio y a la opción de salir. Además mostrará el título de la opción a la cual se ha ingresado a través del menú del sistema, tal como se muestra en la Figura 3.13. Se manejará una sola ventana principal, que será el contenedor de las ventanas internas, es decir solo se levantará una ventana para el uso del sistema. 94 Figura 3.13. Cabecera para las páginas del sistema La ventana principal tendrá el menú con cada una de las funcionalidades principales del sistema. Cada funcionalidad principal a su vez contendrá uno o más accesos a las diferentes ventanas que conforman dichas funcionalidades. Se incluirá en todas las páginas internas enlaces hacia la página principal (menú) y opciones de retorno. En el caso de búsquedas o consultas, se muestra primero etiquetas y cajas de texto de ingreso de datos y los resultados se mostrarán enseguida, en un listado de varios ítems, los cuales pueden ser ordenados por diferentes criterios. El tipo de letra estándar a utilizar para la presentación de la información es Arial. El tamaño de las letras de los párrafos será de 10, el tamaño para los subtítulos será de 12, el tamaño para los títulos será de 14. Se hará uso de gráficos que reflejen acciones determinadas en los botones. Se colocarán nombres adecuados a todas las páginas para que el usuario pueda identificar donde se encuentra en todo momento. Se mostrarán enlaces de rápido acceso a otras operaciones para facilitar la navegación del usuario. Se mostraran pequeñas ventanas de diálogo para confirmar alguna acción o para informar sobre alguna advertencia, logrando una comunicación entre el usuario y la aplicación. 3.2.2. Estructura general del sitio El diseño del sitio Web contará con una jerarquía de menú eficiente para lograr que el usuario encuentre la información que requiere en el menor tiempo posible. En la Figura 3.14 se muestra el mapa de navegación que se utilizará en el sistema a desarrollar. 95 Mantenimiento Proyectos Modulo Proyectos Modulo Mis Actividades Modulo Usuarios Modulo Empresas Modulo Reportes Ver Horas Trabajo Mantenimiento Usuarios Mantenimiento Empresas Mantenimiento Personal Mantenimiento Actividades Mantenimiento Artefactos Diagrama Gantt Versiones Descargar Subir Reservar Liberar Cambio de contraseña Figura 3.14. Mapa de Navegación del sistema La estructura jerárquica del sitio Web será clara, de tal forma que permita al usuario en una próxima navegación encontrar fácilmente la información que busca. La profundidad de la estructura de navegación del sitio Web no será muy profunda ya que no contendrá demasiados niveles para llegar a la información requerida. 3.2.3. Diseño de prototipos del sistema A continuación se presenta los prototipos del sistema. Estos muestran las pantallas con las que interactuará el usuario para realizar de manera automatizada los procesos anteriormente descritos. Pantalla principal En la Figura 3.15 se muestra el diseño de la pantalla “Ingreso al Sistema”, la cual permite el ingreso a la herramienta EACS Project Manager. Los usuarios registrados deben autenticarse con un nombre de usuario y contraseña, que serán proporcionados por el administrador del sistema. 96 Figura 3.15. Pantalla Ingreso al Sistema. Proyectos En la Figura 3.16 se muestra el diseño de la pantalla “Proyectos”, la que contiene las opciones de “Nuevo Proyecto”, “Buscar” y “Salir”. Figura 3.16. Pantalla Proyectos. Al presionar el botón “Nuevo Proyecto” el sistema muestra la pantalla “Nuevo Proyecto” con los campos vacíos. Al presionar el botón “Buscar” se realiza la búsqueda de proyectos con los siguientes criterios de búsqueda: nombre del responsable, tipo proyecto, nombre de la empresa y estado del proyecto, como resultado de la búsqueda se muestra la 97 relación de proyectos registrados en el sistema. Al presionar el botón “Salir” salimos del sistema. Para cada proyecto encontrado se muestra la opción de “Editar”, al seleccionar esta opción el sistema muestra la pantalla “Editar Proyecto” con los datos del proyecto a modificar. También se muestra la opción de “Ver”. Proyectos - Nuevo Proyecto En la Figura 3.17 se muestra el diseño de la pantalla “Nuevo Proyecto”, ingresando en el formulario los datos relevantes del proyecto se podrá registrar en el sistema el nuevo proyecto. En el campo avance se almacena el porcentaje de avance del trabajo realizado del proyecto completo, este campo puede ser ingresado manualmente cuando se crea el proyecto, pero luego es recalculado automáticamente en función al promedio ponderado del progreso de sus actividades, cada vez que estas son actualizadas. De forma similar los campos fecha inicio y fecha fin pueden ser ingresados manualmente al crearse el proyecto pero son recalculados automáticamente obteniéndose la menor fecha de inicio y la mayor fecha de fin de las actividades del proyecto. Figura 3.17. Pantalla Nuevo Proyecto. 98 En esta pantalla se puede relacionar el proyecto creado con una metodología. Las metodologías ya se encuentran definidas previamente en base a procesos definidos. En la pantalla “Editar Proyecto” se actualizan los datos del proyecto que se deseen modificar. Excepto el campo avance, el cual no es editable. Al presionar el botón “Grabar” el sistema guarda los datos del proyecto, para regresar a la pantalla anterior se presiona el botón “Regresar”. Mis Actividades En la Figura 3.18 se muestra el diseño de la pantalla “Mis Actividades” la que contiene los siguientes criterios de búsqueda: nombre del proyecto, estado de la actividad y semáforo, como resultado de la búsqueda se muestra la relación de actividades diferenciadas con distintos colores. Figura 3.18. Pantalla Mis Actividades. A continuación se detalla el significado de los colores: Rojo: indica las actividades cuyo tiempo transcurrido es mayor o igual al 80% del tiempo programado; si el tiempo transcurrido ha superado el tiempo programado, esta actividad se encuentra retrasada. Anaranjado: indica las actividades cuyo tiempo transcurrido es mayor o igual al 40% y menor o igual al 80% del tiempo programado. 99 Azul: indica las actividades cuyo tiempo transcurrido es menor al 40% del tiempo programado. Para cada actividad se muestra la opción “Ver Horas Trabajo”. Mis Actividades – Ver Horas Trabajo En la Figura 3.19 se muestra el diseño de la pantalla “Ver Horas Trabajo” en la que el usuario puede registrar el esfuerzo realizado para la actividad seleccionada, añadiendo la fecha y el número de horas destinadas para su realización, solo los usuarios responsables de la actividad tienen acceso a ingresar las horas trabajadas de dicha actividad. Al presionar el botón “Grabar” el sistema guarda los datos ingresados, para regresar a la pantalla anterior se presiona el botón “Regresar”. Figura 3.19. Pantalla Ver Horas Trabajo. Usuarios En la Figura 3.20 se muestra el diseño de la pantalla “Usuarios" la que contiene las opciones de “Nuevo Usuario” y “Buscar”. Al presionar el botón “Nuevo Usuario” el sistema muestra la pantalla “Nuevo Usuario” con los campos vacíos. Al presionar el botón “Buscar” se realiza la búsqueda de usuarios con los siguientes criterios de búsqueda: apellidos y nombres, perfil, estado y cargo, como resultado 100 de la búsqueda se muestra la relación de usuarios con la siguiente información: apellidos y nombres, estado, perfil y cargo. Para cada usuario se muestra la opción de “Editar”, al seleccionar esta opción el sistema muestra la pantalla “Editar Usuario” con los datos del usuario a modificar. Figura 3.20. Pantalla Usuarios. Usuarios – Nuevo Usuario En la Figura 3.21 se muestra el diseño de la pantalla “Nuevo Usuario” en la cual se ingresan los siguientes datos del usuario para su registro: apellido paterno, apellido materno, nombres, perfil, cargo, estado, usuario y contraseña. Figura 3.21. Pantalla Nuevo Usuario. 101 En la pantalla “Editar Usuario” se actualizan los datos del usuario que se deseen modificar: apellido paterno, apellido materno, nombres, perfil, cargo, estado, usuario y/o contraseña. Al presionar el botón “Grabar” el sistema actualiza los datos del usuario, para regresar a la pantalla anterior se presiona el botón “Regresar”. Empresas En la Figura 3.22 se muestra el diseño de la pantalla “Empresas" la que contiene las opciones de “Nueva Empresa” y “Buscar”. Figura 3.22. Pantalla Empresas. Al presionar el botón “Nueva Empresa” el sistema muestra la pantalla “Nueva Empresa” con los campos vacíos. Al presionar el botón “Buscar” se realiza la búsqueda de empresas con los siguientes criterios de búsqueda: nombre y tipo de empresa, como resultado de la búsqueda se muestra la relación de empresas con la siguiente información: nombre, dirección, estado y tipo de empresa. Para cada empresa se muestra la opción de “Editar”, al seleccionar esta opción el sistema muestra la pantalla “Editar Empresa” con los datos de la empresa a modificar. 102 Empresas – Nueva Empresa En la Figura 3.23 se muestra el diseño de la pantalla “Nueva Empresa” en la cual se ingresan los siguientes datos de la empresa para su registro: nombre, email, teléfono 1, teléfono 2, fax, dirección 1, dirección 2, país, departamento, código postal, URL, tipo y descripción. En la pantalla “Editar Empresa” se actualizan los datos de la empresa que se deseen modificar: nombre, email, teléfono 1, teléfono 2, fax, dirección 1, dirección 2, país, departamento, código postal, URL, tipo y descripción. Al presionar el botón “Grabar” el sistema actualiza los datos de la empresa, para regresar a la pantalla anterior se presiona el botón “Regresar”. Figura 3.23. Pantalla Nueva Empresa. Reportes En la Figura 3.24 se muestra el diseño de la pantalla “Reportes”, en la que se refleja la información que va conformando la vida del proyecto y que nos permitirá trabajar el día a día y posteriormente comparar con las previsiones realizadas. Contiene las opciones de “Reporte Detallado del Proyecto” y “Reporte de Esfuerzo”. Al presionar la opción “Ver” se muestra el reporte del proyecto que ha sido seleccionado. 103 Figura 3.24. Pantalla Reportes. Reportes - Reporte Detallado del Proyecto En la Figura 3.25 “Reporte Detallado del Proyecto”, nos permite visualizar en formato HTML información importante del proyecto, este reporte presenta las siguientes secciones: Figura 3.25. Pantalla Reporte Detallado del Proyecto. 104 Datos de Proyecto: sección donde se muestra el código proyecto, nombre proyecto, fecha inicio, fecha fin, responsable del proyecto, empresa, estado proyecto, tipo proyecto, porcentaje de avance y descripción. Personal del proyecto: sección donde se muestra el nombre y rol del personal que forma parte del proyecto. También se visualiza las actividades y sub actividades que tiene el proyecto, así como el personal a cargo de cada una de las actividades, el porcentaje de avance, la fecha inicio y fecha fin de la actividad. El campo avance de las actividades padre o resumen se recalcula en función al avance de las hijas, para esto se realiza un promedio ponderado de los avances de las actividades hijas y sus tiempos de duración. El campo avance de las actividades padre o resumen servirán para calcular el avance del proyecto total, para esto se realiza un promedio ponderado de los avance de las actividades de primer nivel y sus tiempos de duración. Artefactos del Proyecto: sección donde se muestra todos los artefactos que tiene el proyecto, así como la versión vigente del artefacto. Reportes - Reporte Esfuerzo En la Figura 3.26 “Reporte Esfuerzo”, nos permite visualizar en formato HTML el esfuerzo realizado por los usuarios para cumplir con sus actividades designadas, este reporte presenta las siguientes secciones: Datos del proyecto: sección donde se muestra los datos básicos del proyecto seleccionado para el “Reporte de Esfuerzo del Proyecto”: código, nombre, fecha inicio, fecha fin, empresa, estado y porcentaje de avance. Listado de actividades del proyecto: sección donde se muestra el listado de actividades que tiene el proyecto elegido. Para cada actividad se muestran los datos principales de ésta como: fecha inicio, fecha fin, porcentaje de avance, responsable de la actividad, horas estimadas y horas reales, estas se calculan en base a las horas registradas por los mismos responsables del proyecto. 105 Figura 3.26. Pantalla Reporte Esfuerzo. También se listan a nivel de detalle los usuarios que participaron a lo largo de la vida de la actividad así como las horas que trabajaron en ésta, estas son en realidad un resumen y muestran el total de horas trabajadas por usuario, ya que en realidad los usuarios ingresan las horas trabajadas día a día. Proyecto – Listado de Personal del proyecto En la Figura 3.27 se muestra el diseño de la pantalla “Listado de Personal del proyecto” en la cual se agrega el personal que tendrá el proyecto, es decir, las personas involucradas en el ciclo de vida del proyecto. Contiene las opciones de “Agregar Persona” y “Editar”. Al presionar la opción “Agregar Persona” el sistema realiza la asignación del personal, se debe seleccionar a la persona y el rol que ocupará dentro del proyecto. En la pantalla “Editar Personal” se actualizan los datos de la persona asignada al proyecto. 106 Figura 3.27. Pantalla Listado de Personal del Proyecto. Proyecto – Listado de actividades En la Figura 3.28 se muestra el diseño de la pantalla “Listado de Actividades” en la que se muestra la relación de las actividades en las cuales es responsable un determinado miembro del equipo del proyecto, en esta pantalla se observa el nombre, fecha inicio, fecha fin, estado y progreso de cada actividad asignada a un miembro del equipo. En la parte superior se visualiza los datos principales del proyecto al cuál se le lista en la parte posterior las actividades que tiene registradas. Al presionar el botón “Nueva Actividad” el sistema muestra la pantalla “Nueva Actividad” con los campos vacíos. Para cada actividad se muestra la opción de “Editar”, al seleccionar esta opción el sistema muestra la pantalla “Editar Actividad” con los datos de la actividad a modificar. También se muestra la opción de “Crear Actividad” y “Ver Artefactos”. 107 Figura 3.28. Pantalla Listado de Actividades. Proyecto – Nueva actividad En la Figura 3.29 se muestra el diseño de la pantalla “Nueva Actividad” en la cual se ingresan los siguientes datos de la actividad para su registro: nombre, estado, tipo, prioridad, responsable, progreso, actividad padre, fecha inicio, fecha fin, descripción. Las actividades creadas pueden ser hijos de una actividad principal o padre. Las horas que esperamos tome la actividad se almacena en el campo horas estimadas, cabe resaltar que las horas reales de la actividad se calcularan sumando las horas de trabajo registradas desde la pantalla “Mis Actividades – Ver Horas Trabajo”. En el campo progreso se guarda el porcentaje de avance del trabajo realizado en la actividad, este campo es calculado para las actividades principales en función al promedio ponderado del progreso de sus actividades hijas. En esta pantalla se puede asociar la actividad a una o más actividades de una metodología que se haya elegido cuando se creó el proyecto. En la pantalla “Editar Actividad” se actualizan los datos de la actividad que se deseen modificar. 108 Al presionar el botón “Grabar” el sistema actualiza los datos de la actividad, para regresar a la pantalla anterior se presiona el botón “Regresar”. Figura 3.29. Pantalla Nueva Actividad. Proyecto – Ver Artefactos En la Figura 3.30 se muestra el diseño de la pantalla “Ver Artefactos por actividad” en la cual se muestra el listado de artefactos que tiene la actividad seleccionada. Para regresar a la pantalla anterior se presiona el botón “Regresar”. Figura 3.30. Pantalla Ver Artefactos por Actividad. 109 Proyecto – Listado de artefactos En la Figura 3.31 se muestra el diseño de la pantalla “Listado de Artefactos” en la cual se muestra el listado de artefactos que tiene un determinado proyecto. Por cada artefacto se muestran las actividades que están relacionadas así como su estado y versión actual. En la parte superior se visualiza los datos principales del proyecto al cuál se le lista en la parte posterior los artefactos que tiene registrados. Al presionar el botón “Nuevo Artefacto” el sistema muestra la pantalla “Nuevo Artefacto” con los campos vacíos. Para cada artefacto se muestra la opción de “Versiones”, “Descargar” y “Reservar”. Figura 3.31. Pantalla Listado de Artefactos. 110 Proyecto – Nuevo Artefacto En la Figura 3.32 se muestra el diseño de la pantalla “Nuevo Artefacto” en la cual se ingresan los datos correspondientes a un nuevo artefacto, donde se ingresa el código y nombre del artefacto, el archivo a cargar y su descripción. En esta pantalla se puede asociar el artefacto con una o más actividades del proyecto y con uno o más artefactos de la metodología que se haya elegido cuando se creó el proyecto. Al presionar el botón “Grabar” el sistema guarda los datos del artefacto, para regresar a la pantalla anterior se presiona el botón “Regresar”. Figura 3.32. Pantalla Nuevo Artefacto. Proyecto – Descargar Artefacto En la Figura 3.33 se muestra el diseño de la pantalla “Descargar Artefacto” en la cual se pueden descargar el artefacto seleccionado al espacio local del usuario. Proyecto – Reservar Artefacto En la Figura 3.34 se muestra el diseño de la pantalla “Reservar Artefacto” en la cual se realiza la reserva del artefacto seleccionado para que otros usuarios no puedan modificar la información, solo visualizarla. Cuando el artefacto es reservado se muestran las opciones de “Liberar” y “Subir”. 111 Figura 3.33. Pantalla Descarga Artefacto. Figura 3.34. Pantalla Reservar Artefacto. Proyecto – Subir Artefacto En la Figura 3.35 se muestra el diseño de la pantalla “Subir Artefacto” en la cual se genera una nueva versión del artefacto seleccionado. Se debe seleccionar el 112 artefacto que se desea subir de una ruta determinada, así como ingresar alguna observación. Al presionar el botón “Grabar” el sistema cambia de estado el artefacto así puede ser modificado por otros usuarios y se registran los datos del usuario que generó la versión y fecha correspondiente. Para regresar a la pantalla anterior se presiona el botón “Regresar”. Figura 3.35. Pantalla Subir Artefacto. Proyecto – Versiones del Artefacto En la Figura 3.36 se muestra el diseño de la pantalla “Versiones del Artefacto” en la cual se visualizan las distintas versiones que tiene el artefacto seleccionado. Para cada artefacto seleccionado se muestra la opción de “Descargar”, la que permite descargar la versión del artefacto a su espacio local. Se puede cambiar la versión vigente del artefacto con la opción “Cambiar”. Para regresar a la pantalla anterior se presiona el botón “Regresar”. 113 Figura 3.36. Pantalla Versiones del Artefacto. Proyecto – Diagrama de Gantt En la Figura 3.37 se muestra el diseño de la pantalla “Diagrama de Gantt” en la cual se visualizan todas las actividades ingresadas para el proyecto seleccionado. En el eje horizontal se muestra la escala de tiempo definido en términos de la unidad más adecuada al proyecto a ejecutar. En el eje vertical se muestran las tareas que constituyen el proyecto a ejecutar. A cada tarea se representa por una línea horizontal cuya longitud es proporcional a la duración en la escala de tiempo (eje horizontal). Para cada actividad se muestra el usuario responsable, el porcentaje de avance de la actividad, esta es actualizada por el usuario, por lo que representa el avance real de la actividad y las fechas de inicio y fin de la actividad. En el diagrama de Gantt se visualiza las barras de actividades según los colores para avisar sobre el fin de cada una de ellas, además se indica el porcentaje de avance. A medida que progresa una tarea, se completa proporcionalmente la barra que la representa hasta llegar al grado de finalización. Para cambiar la escala que se muestra en el diagrama, se selecciona las opciones que aparecen en la parte inferior en la etiqueta formato, podemos visualizar el diagrama en días, semanas, meses y trimestres. 114 Figura 3.37. Pantalla Diagrama de Gantt. 115 Capitulo 4: Observaciones, conclusiones y recomendaciones En este capítulo se resumirá las observaciones y 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. 4.1. Observaciones Las investigaciones y el análisis realizados previos al desarrollo de la herramienta han permitido identificar los conceptos y herramientas utilizadas en la actualidad para la administración de proyectos y gestión de la configuración. Esto permite centrar esfuerzos en las deficiencias o vacíos aun no cubiertos en esta área con el fin de evitar reinventar conceptos o herramientas previamente desarrollados. Las funcionalidades definidas en los requerimientos fueron contempladas durante la etapa de análisis y diseño del sistema. Esto se comprueba visualizando los distintos diagramas: de casos de uso, de clases de análisis, de clases de diseño y de secuencia. Para conseguirlo se ha utilizado el análisis y diseño orientado a objetos utilizando la metodología de desarrollo de software del Proceso Unificado apoyado con el lenguaje de modelado UML, que al 116 utilizar un lenguaje gráfico permite modelar sistemas de software de manera eficiente. La complejidad de los proyectos hacen imprescindibles que los sistemas de administración de proyectos puedan gestionar los artefactos involucrados en los proyectos. Para la elaboración de los diagramas correspondientes a la etapa de análisis y diseño de la herramienta se utilizó la librería del IDE Netbeans que integra la notación gráfica UML. Este último, facilitó la elaboración final de los diagramas de clases de diseño y secuencia debido a que los atributos y métodos asociados a las clases eran extraídos directamente del código fuente. Durante la etapa de análisis se ha estructurado los requerimientos del sistema de manera que nos facilite su comprensión, su preparación, su modificación y en general su mantenimiento y por tanto poder resolver aspectos internos del sistema, profundizar en la funcionalidad y características Durante la etapa de diseño se ha definido el sistema de tal forma que permitió dar soporte a todos los requerimientos definidos, incluyendo los no funcionales y restricciones relacionadas con el lenguaje de programación, componentes reutilizables y tecnología de interfaz de usuario. Durante la etapa de diseño se eligió una arquitectura Web basada en el patrón de diseño MVC. En base a la arquitectura y a los requerimientos funcionales se elaboraron los prototipos del sistema, los cuales facilitan su mantenimiento y su posible ampliación en el futuro. La utilización del marco de trabajo JSF (Java Server Faces) facilitó la creación de una moderna interfaz de usuario diferente a los clásicos formularios Web, lo que permitió diseñar una interfaz de usuario amigable. La utilización de librerías independientes de la tecnología y lenguaje de programación, facilitó la creación del diagrama de Gantt facilitando su integración. Esto además es favorecido gracias a que la carga de los datos que 117 se mostrarán en el Gantt se realiza desde un archivo XML estándar que puede ser generado con cualquier tecnología. 4.2. Conclusiones Como resultado del trabajo desarrollado a lo largo de todos los capítulos que componen esta tesis, se detallan a continuación las conclusiones obtenidas según el alcance establecido al inicio de este documento: Se logró diseñar una herramienta tecnológica que permite la administración de proyectos en especial de desarrollo de software, permitiendo establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto, llevar un mejor control del ciclo de vida del proyecto, permite la adecuada y optima asignación de actividades a los equipos de proyecto a partir de los reportes de carga de trabajo de los mismos. Se consiguió diseñar una herramienta que permite crear la instancia de una metodología a través de una interfaz gráfica amigable en entorno Web basada en el lenguaje XPDL. Las entidades que pueden ser asociadas a una metodología son: los proyectos, las actividades y los artefactos. Se puede afirmar que la herramienta EACS Project Manager permite un mecanismo de gestión del repositorio de los artefactos (gestión de la configuración) para cada proyecto, permitiendo a los usuarios administrar y modificar con seguridad los artefactos que se definirán por cada actividad, esta información ayudará a los administradores a controlar el avance de los proyectos siguiendo la metodología elegida. Se puede concluir que la herramienta EACS Project Manager cumple con los objetivos de acceso descentralizado por parte de los usuarios que hacen uso de ella. La plataforma Web sobre la cual ha sido construida permite que cualquier usuario registrado en el sistema pueda acceder a ella desde cualquier ubicación geográfica. 118 4.3. Recomendaciones Como resultado del trabajo realizado, se ha podido identificar algunas recomendaciones que contribuirán a la mejora del proceso para la etapa de análisis y diseño de la plataforma: Antes de comenzar con el análisis y diseño se debería contar con la comprensión precisa y detallada de los requerimientos del sistema. En el diseño se bosqueja procedimientos de captura de datos, accesos efectivos al sistema y archivos así como métodos adecuados de codificación y descodificación de archivos XML para que la implementación lo use. Según la definición de los requerimientos no funcionales realizados en la etapa de análisis, es recomendable contar con personas que tengan la experiencia necesaria en el manejo del lenguaje de programación requerido para que colaboren eficazmente en el proceso de implementación del sistema. En el diseño se identificaron aquellos componentes que serán de mayor utilización durante la implementación del sistema, los cuales fueron evaluados en partes críticas de la plataforma, lo que contribuyó a la construcción de una arquitectura estable y sólida. En el diseño se identificaron aquellos componentes que son parametrizables los cuales podemos adaptarlos dependiendo de las necesidades del sistema, el conseguir establecer parámetros que puedan modificarse nos ayuda a lograr adaptaciones de forma sencilla, en lugar de estar configurando constantemente las rutas de los archivos de configuración del sistema. Se recomienda investigar sobre diversas técnicas de estimación de tiempo, costos, esfuerzo, manejo del valor ganado y manejo de desviaciones. 119 Bibliografía [BAB, 1986] W. Babich, Software ConFiguration Management, Addison-Wesley, 1986. [BRYAN-SIEGEL, 1984] W. L. Bryan y S. G. Siegel, Software product assurance. Techniques for reducing software risks, Elsevier, 1984. [BOVERI, 1990] Boveri Brown . "Manual de Gestión de Proyectos". [PEREÑA, 1996] Pereña Brand, Jaime. "Dirección y Gestión de Proyectos". [PRESSMAN, 1998] Pressman, Roger S. "Ingeniería del software : un enfoque práctico". [CMII] Model for Configuration Management. Institute of Configuration Management. [SWEBOK, 2004] Guide to the Software Engineering Body of Knowledge. [JACOBSON, 2000] Ivar Jacobson, Grady Booch, James Rumbaugh. “El proceso unificado de desarrollo de software”. [KRUCHTEN] Philippe Kruchten. “The rational unified process made easy: a practitioner's guide to the RUP”. [LARMAN, 2003] Graig Larman. “UML y patrones: una introducción al análisis y diseño orientado a objetos y al proceso unificado”. [MELOCHE, 2002] Thomas Meloche. “The Rational Unified Process (RUP)”. En http://www.menloinnovations.com/freestuff/whitepapers/RationalUnifiedProcess.pdf [IEEE Std.729-1983] IEEE Standard Glossary of software Engineering Terminology. The Institute of Electrical and Electronics Engineers, Inc. New York, EEUU. [IEEE Std.828-1998] IEEE Standard for Software Configuration Management Plans. The Institute of Electrical and Electronics Engineers, Inc. New York, EEUU. [PMBOK, 2008] Guía de los Fundamentos para la Gestión de Proyectos (Guía del PMBOK) Cuarta edición. [PMI] Project Management Institute (PMI) www.pmi.org, [visitado en Noviembre del 2008] [MCMANUS, 2003] McManus, John y Wood-Harper, Trevor (2003) "Information Systems project management: The price of failure", Management Services; May; 47, 5; ABI/INFORM Global, pp. 16-19 [KRUCHTEN, 1999] P.B. Kruchten: The Rational Unified Process (An Introduction). [NTP-ISO/IEC 12207:2006] Norma Técnica Peruana NTP-ISO/IEC 12207. http://www.bvindecopi.gob.pe/normas/isoiec12207.pdf [visitado en Octubre del 2010] 120 [COMPETISOFT, 2006] COMPETISOFT: Proyecto de mejora de procesos para fomentar la competitividad de la pequeña y mediana industria del software de Iberoamérica, Versión 0.2. Diciembre 2006. [BPMI] Business Process Management Initiative. Business Process Modeling Language. BPMI.org. En http://www.bpmi.org/bpmn-spec.htm, [visitado en Marzo del 2011] [MOPROSOFT, 2003] Modelo de Procesos para la Industria de Software, MoProSoft V 1.1, mayo 2003, pp 121 [MOPROSOFT] Oktaba, H., Alquicira, C., Su, A., Martinez, A., Pérez, C., López, F.: Modelo de procesos para la industria del software. http://www.e-computacion.net/MoProSoft%20HannaOktaba.ppt#259,2,Contenido [visitado en Marzo del 2008] [B-KIN] En http://www.b-kin.com, [visitado en Marzo del 2008] [BUGTRACK] En http://www.bug-track.com, [visitado en Marzo del 2008] [KPLATO] En http://www.koffice.org/kplato, [visitado en Marzo del 2008] [DOTPROJECT] En http://www.dotproject.net, [visitado en Marzo del 2008] [MSPROJECT] http://www.microsoft.com/project, [visitado en Noviembre del 2010] [PRIMAVERA] http://www.oracle.com/us/corporate/Acquisitions/Primavera_Systems [visitado en Marzo del 2011] [XPDL] En http://www.xpdl.org, [visitado en Julio del 2008] [STANDISH GROUP, 2009]. En www.standishgroup.com, [visitado en Agosto del 2009] [MVC] Modelo, Vista y Controlador En http://es.wikipedia.org/wiki/Modelo_Vista_Controlador, [visitado en Marzo del 2009] [MJS] Herramienta para Modelado de Procesos: MJS Process Designer. Tesis para optar el Título de Ingeniero Informático presentada por: Camarena M., Pedreschi J. y Rondón S. [JSF] En www.java.sun.com/javaee/javaserverfaces, [visitado en Agosto del 2008] [SPRING] En http://es.wikipedia.org/wiki/Spring_Framework, [visitado en Agosto del 2008] [POJO] Richardson, Chris. “POJOs in Action”, 1ra edición. Manning Publications. 2006. [EJB] Monson-Haefel, Richard; Burke, Bill; Labourey, Sacha. “Enterprise JavaBeans”, 4ta edición. O’Reilly Media, Inc. 2004. [XML] En http://www.w3.org/standards/xml, [visitado en Octubre del 2008] [CASTOR] En http://www.castor.org, [visitado en Marzo del 2008] [EACS] Herramienta para Gestión de Proyectos basada en XPDL para el proyecto COMPETISOFT – Construcción, Pruebas e Integración. [BPMN_DOCS] Object Management Group “Business Process Modeling Notation(BPMN) Specification”. Final Adopted Specification dtc/06-02- 01,http://www.bpmn.org/Documents/OMG Final Adopted BPMN 1-0 Spec06-02-01.pdf, [visitado en Marzo del 2008] 121 [BPMN] En http://www.bpmn.org/, [visitado en Octubre del 2008] [XPDL_DOCS] En http://www.club-bpm.com/X.htm, [visitado en Mayo del 2011]