HERRAMIENTA DE GESTIÓN DE CAMBIOS E INCIDENCIAS Anteproyecto de Tesis de Magíster en Ingeniería del Software Tesista: Ing. Verónica Farach Director: Prof. M.Ing. Paola V. Britos 1. Identificación del problema En el proceso de ingeniería del software, se presentan diferentes puntos en el ciclo de vida de un sistema en el que la detección correcta de desvíos, su reporte, evaluación, estimación y resolución son muchas veces el foco del proyecto y en otras ocasiones, una actividad necesaria para asegurar no sólo el correcto desarrollo del mismo sino también, la calidad del software. En este contexto, existen determinados factores que implican un mayor esfuerzo en la gestión de riesgos, con respecto al usuario: usuarios con perfiles funcionales parciales o con grados de conocimiento sensiblemente diferentes; usuarios con niveles de responsabilidad heterogéneos o con relación jerárquica dentro de la organización; políticas, cultura y procedimientos de comunicación interna pobres dentro de la organización; con respecto al equipo de desarrollo: programadores con diferentes niveles de experiencia en la tecnología rotación de equipos de programación con respecto a la gestión: más de un responsable en la coordinación del desarrollo, falta de métricas en la evaluación del producto, falta de procedimientos formales en la gestión de la comunicación interna, con respecto al software: defectos de código implementación incorrecta o pobre del alcance funcional errores en el análisis funcional y diseño entropía generada por la inclusión de cambios, mejoras y correcciones 1
La aplicación de una metodología no asegura, en sí misma, el éxito del proyecto. La aplicación de una metodología permite asegurar al menos que se ha realizado el suficiente esfuerzo para lograrlo, dentro de un marco teórico razonable. En este sentido, cuando se facilita además el uso de la metodología a través de una herramienta se obtienen las siguientes ventajas; 2. Situación Actual minimización de la curva de aprendizaje, registro progresivo de la aplicación del método a casos reales, mejora en las estimaciones, repetición del éxito. Son variados los procesos y técnicas de la ingeniería del software que convergen en la problemática del aseguramiento de la calidad y la gestión de la configuración del software. Diversas compañías y organizaciones dedicadas al desarrollo de sistemas informáticos, o que enfrentan proyectos de esta naturaleza, se encuentran en algún punto del camino con la necesidad de seguir y controlar el ciclo de vida del software en relación a su entorno. En la actualidad es posible encontrar una amplia gama de productos comerciales y de software libre (código abierto) que ofrecen solución al seguimiento de errores, defectos del software (Bug Tracking) y gestión de solicitudes de cambios (Change Management). En la tabla 1 se puede observar un conjunto de ellos [bug-tracking.info, 2005]. Bug Tracking Bug Tracking Change Management AceProject IssueView AccuRev AdminiTrack ITracker Aldon Affiniti for Enterprise SCM Alcea Fast BugTrack Kemma Software Aperture - Data Center CM Atlassian JIRA Legendsoft Spots eb CM Borderwave Software McCabe TRUEtrack IBM Rational ClearCase Bug Tracker Software Office Clip Intasoft AllChange Bug Tracking Online Ozibug Enterprise Edition McCabe TRUEchange Bugs Manager ProblemTracker MKS Integrity Manager Bug-Track.com QuickBugs Optrics Engineering BugAware 3.0 RMTrack OurayCM BugImpact Seapine TestTrack Pro Perforce bugvisor SWBTracker QualCode Inc. Bugzero TeamTrack Quartet SCM Labs, Inc. 2
Bug Tracking Bug Tracking Change Management Desertware Squash 'Em TechExcel Sablime - Lucent EBsuite.com ThinMind Seapine Surround SCM Elsinore's Visual Intercept Track+ Serena - TeamTrack Sesame Technology TrackStudio Enterprise SnapshotCM - True Blue Software IBM Rational ClearQuest Worksoft test progressive SpectrumSCM IssueTech.com ykap Telelogic Synergy CM IssueTrak VI Engineering, Inc. Tabla 1: Algunos productos de Bug Tracking y Change Management en la actualidad Existen además variadas aplicaciones de usuario y frameworks de desarrollo que contienen en alguna función embebida el registro de incidencias. Las mismas se encuentran orientadas, según la aplicación a la que vengan adosadas, a Customer Relationship Management (por ejemplo, Sugar CRM), a corrección de código fuente por y para el equipo de desarrollo (JBuilder) y detección de errores de código (FXCop de Microsoft). Estas aplicaciones no se consideran en el presente análisis dado que: no representan ni se encuadran dentro de las funciones específicas del software de seguimiento de incidencias y cambios de manera específica; sólo son de utilidad cuando el objetivo es el uso del software en el que vienen embebidas y son aprovechadas como un valor agregado; generalmente requieren el pago de licencias; generalmente no son código abierto, lo que hace que no sean adaptables según diferentes tipos de proyectos de software 3. Aporte original de la aplicación Es importante tener en consideración que el fin del desarrollo de una aplicación como esta es la de dar soporte metodológico a través de una herramienta informática a la actividad de ingeniería de software en las etapas de desarrollo y prueba unitaria. Sin embargo, ante tan diversa gama de productos, qué aporte original puede significar el desarrollo de otra herramienta? La propuesta de este trabajo es responder a esta pregunta abordando los siguientes lineamientos: Implementación de nociones, elementos de información y técnicas metodológicas en la resolución práctica de problemas. Captación de requerimientos considerando distintos niveles y tipos de usuarios en diferentes puntos de inflexión en el seguimiento de la calidad a lo largo de un proyecto de software. 3
Detección, selección y modelado de mejores prácticas. Concretamente, estas herramientas adolecen de ciertas características que aglutinen la gestión de incidencias y cambios con la gestión de la propia asignación de su eventual resolución y seguimiento. Este inconveniente se presenta cuando se asume que el usuario que tiene acceso a la herramienta, es un usuario habituado al uso de aplicaciones para la gestión de sus tareas. Este supuesto, en la mayor parte de los casos no es cierto. El usuario que participa activamente en la evaluación de aceptación del software es usuario experto sólo en el dominio de la aplicación y no en aspectos informáticos en general. Además, otra característica sobre-estimada de este tipo de aplicaciones es la integración con servicios de mail, que notifican on-line acerca de la creación y resolución de las incidencias. Generalmente, esta práctica resulta en la duplicación innecesaria de registros y muchas casillas de e-mail llenas. Con respecto a la flexibilidad en la tipología y definición de estados de las incidencias, es necesario encontrar un equilibrio entre la configuración totalmente por parámetros y la implementación según los requerimientos analizados que respondan a las necesidades específicas del equipo de desarrollo. Muy pocas aplicaciones poseen gestión de cambios e incidencias que deriven a la asignación y seguimiento de resolución de las mismas. Generalmente están orientadas a la gestión de cambios o a la gestión de incidencias en el ámbito del equipo de desarrollo. Finalmente, otro factor muy importante a considerar cuando se evalúan estas herramientas es la disponibilidad del recurso. La tabla siguiente muestra una comparación de las características funcionales mencionadas entre tres paquetes de gestión de incidencias de código abierto seleccionados entre los más populares junto a la propuesta de esta tesis (H.G de I&C). Característica Bugzilla Mantis Itracker H.G de I&C Enfoque a incidencias SI SI SI SI Enfoque a Cambios NO NO NO SI Reporte orientado al usuario NO NO NO SI Reporte orientado al equipo de desarrollo SI SI SI SI Reportes genéricos SI SI SI Según requerimiento Tipos y estatus de incidencias Parámetros Parámetros Parámetros Según requerimiento Catálogo Componentes flexible SI Algo Algo Según requerimiento Tabla 2: Comparación de algunos aplicativos y el sistema a desarrollar 4
Como resumen se muestra en la siguiente tabla los factores clave de aporte original de la aplicación: Naturaleza Metodológicas Aporte Implementación de nociones, elementos de información y técnicas metodológicas en la resolución práctica de problemas Orientación al usuario clave del dominio de negocios Detección, selección y modelado de mejores prácticas para el seguimiento de cambios e incidencias en procesos de ingeniería de software Funcionales Asociación entre pedidos de cambio y detección de incidencias con las tareas de resolución y desarrollo del equipo de programadores Elaboración de reportes específicos, orientados al cliente o usuario clave del dominio de negocios y NO orientado a un oyente técnico que no toma decisiones en este nivel Operativas Eliminación del concepto de alertas y envío de mails a usuarios de la aplicación, enfocando positivamente la aplicación a la gestión y resolución de problemas y no a la distribución de novedades Herramienta desarrollada en ámbito académico. Gratuita e independiente del framework de desarrollo, de otras aplicaciones satélite y de la base de datos disponible. Código Abierto 4. Objetivo del Trabajo de Tesis Tabla 3: Factores clave de aporte original de la aplicación El objetivo de este trabajo es el de desarrollar una herramienta que permita aplicar en forma práctica métodos, técnicas y elementos de información que sirvan a la gestión de cambios y el seguimiento de incidencias en el desarrollo de software en entornos complejos. Se entiende como entornos complejos aquellos que involucran diversos actores con responsabilidades compartidas y dónde la gestión del cambio es clave y figura como factor crítico en el desarrollo de software. 5. Modelo de Solución 5.1 Alcance Dentro del alcance de la presente Tesis, se considera la ejecución de las siguientes fases: Desarrollo de la aplicación Redacción y edición de la carpeta de Tesis Presentación y defensa 5
5.2. Modelo Funcional de la Aplicación Los bloques funcionales (figura 1) que contendrá la aplicación son los siguientes: Gestión de Cambios e Incidencias del Usuario: en este bloque se atienden las necesidades de registro unificado de cambios e incidencias detectadas en pruebas de usuario, tanto de sistema como de integración. En este caso, el foco reside en el reporting, la asignación de impacto, estimación de esfuerzo y la catalogación funcional. Este módulo tiene como usuario principal al gestor de pruebas. Asignaciones de Desarrollo: conjunto de actividades que permiten al gestor del equipo de desarrollo, asignar tareas de corrección y mejoras en base a las incidencias y cambios de usuario. Este bloque se enfoca a la catalogación técnica, asignación de prioridades, resolución y seguimiento de incidencias. Usuarios Clave Equipo de Gestión Equipo de QA Equipo de Desarrollo Incidencias y Cambios del Usuario Asignaciones de Desarrollo Metodología 5.3. Arquitectura Técnica de Aplicación Figura 1: Bloques Funcionales La arquitectura de aplicación seguirá los lineamientos dictados por las mejores prácticas asociadas a la tecnología de desarrollo. En términos generales, los requerimientos básicos que determinarán la arquitectura de aplicación a utilizar son los siguientes: La herramienta debe poder implementarse en un esquema de uso distribuido. Los usuarios de aplicación son usualmente estaciones de trabajo pesadas y medianamente potentes, con entornos de desarrollo y servidores de aplicación y otros que replican entornos productivos para las pruebas unitarias de código. El dominio de conceptos del sistema no es complejo ni voluminoso, no se necesitan conexiones elaboradas con la BBDD, pero si requiere una abstracción del origen físico de datos que permita cambiar de implementación a implementación. El look & feel de la aplicación debe ser fácilmente modificado para adaptarse las políticas internas de cada proyecto, debido a que es una herramienta con salidas a diferentes niveles de usuario, tanto del equipo de desarrollo como del cliente. La siguiente figura muestra la arquitectura en capas básica elegida, que en etapas posteriores de desarrollo de la aplicación justificará su diseño en base al análisis detallado de los requerimientos mencionados. 6
PRESENTACIÓN LÓGICA WEB REGLAS DE NEGOCIO DATOS Figura 2: Capas de Arquitectura Básica 6. Enfoque de Desarrollo 6.1. Metodología La metodología a aplicar para el desarrollo de la herramienta es Métrica versión 3 [MAP, 2001], la misma consiste en los siguientes procesos: Planificación de Sistemas de Información Estudio de Viabilidad del Sistema Análisis del Sistema de Información Diseño del sistema de Información Construcción del Sistema de Información Implantación y Aceptación del Sistema Mantenimiento de Sistemas de Información Para este trabajo, las fases de Planificación de Sistemas y Mantenimiento no aplican. 6.2. Cronograma Preliminar El cronograma completo cubre 20 semanas de trabajo (figura 2). Con una dedicación de 20 horas semanales, el total de horas asciende a 400. Figura 3: Cronograma Preliminar 7
7. Bibliografía [Blair Stephen, 2004] Blair Stephen, A Guide to Evaluating a Bug Tracking System White Pape, MetaQuest Software, Octubre 2004. [Bug-tracking.info, 2005] Sitio web www.bug-tracking.info Bug Tracking and Defect Tracking Resource, 2004-2005. [MAP, 2001] Ministerio de las Administraciones Públicas, Metodología Métrica v3, Madrid, 2001. [Piattini Mario y Otros, 1996] Piattini Mario y Otros, Análisis detallado de Aplicaciones Informáticas de Gestión, RA-MA 1996 8