Sistema de gestión de incidencias

De Departamento de Informatica
Saltar a: navegación, buscar

por José D. Marroquín T. de Casa Central

Un sistema de gestión de incidencias (issue tracking system en inglés) es una herramienta de software para la gestión de incidencias, issues, de proyectos. Una incidencia es una solicitud de modificación (MR, por sus siglas en inglés), corrección o mejora. En ese contexto, una corrección puede ser de tipo correctiva o preventiva; en cambio, una mejora, adaptativa o perfectiva[1]. Los cuatro tipos son categorías en el proceso mantención de software en ingeniería de software. Una mantención del tipo correctiva no es planificada, se ejecuta ante la detección de uno o más defectos; la preventiva se realiza para disminuir la probabilidad de que un sistema deje de estar disponible operacionalmente[2]; la adaptativa se hace para que la herramienta de software pueda ser usado en otras plataformas como cuando un desarrollador hace el porting de una aplicación móvil desde iOS, el sistema operativo (OS, por sus siglas en inglés) creado por Apple Inc., a Android, el OS por Google, por ejemplo; y la perfectiva se encarga de proporcionar mejoras a la experiencia de usuario y la documentación del producto de software.

Contenido

Implementación

Existen herramientas para gestión de incidencias integradas en repositorios en Internet. Por ejemplo, GitHub, un repositorio web basado en Git, integra un issue tracker a cada proyecto. En GitHub, si el repositorio es público, cualquier usuario de GitHub puede agregar una incidencia mediante un ticket, aunque no se trate de un colaborador, desde una interfaz que integra:

  1. Un cuadro de texto para el título.
  2. Un cuadro de texto para el comentario, el detalle del issue, con soporte para textos en Markdown en la pestaña Write y vista previa en Preview.
  3. Un botón Labels que despliega un cuadro de texto con opción de búsqueda para añadir o quitar etiquetas, e.g., bug, enhancement, question.
  4. Un botón Milestone que despliega un cuadro de texto con opción de búsqueda para añadir o quitar hitos.
  5. Un botón Assignees que despliega un cuadro de texto con opción de búsqueda para la asignación del ticket.
Vista para la adición de nuevos issues en GitHub desde un repositorio real.

Los elementos anteriores de la lista anterior también se integran en la vista en donde propietarios o colaboradores crean nuevos issues.

La visualización del detalle de un ticket en GitHub luce como una línea de tiempo con marcas por eventos tales como la apertura después de un cierre, la añadidura o sustracción de nuevas etiquetas e hitos personalizados, entre otros.

Es posible editar un issue y suscribirse para recibir notificaciones de sus cambios de estado.

Resultado de texto formateado en Markdown para comentario del ticket. Ejemplo de detalle de un issue en GitHub.

Flujo de trabajo

En este contexto, un flujo de trabajo es un conjunto de transiciones, decisiones, que modifica el estado de un issue.

Estados

La gestión de una incidencia se puede representar por dos o más estados y un flujo de acciones entre ellos. Por ejemplo, Attlasian, desarrollador del issue tracker Jira, indentifica tres estados para un ticket generado con esa herramienta[3]:

  1. TODO: hace referencia al inglés to do que puede traducirse literalmente al español como "a hacer" o "por hacer".
  2. In progress: "en progreso". Incidencia en tratamiento.
  3. Done: "hecha". El issue está resuelto y es posible reabrir la solicitud.

Un modelo simplificado publicado en el blog de Sifter el 14 de agosto de 2007[4] también identifica tres estados para su issue tracker:

  1. Open: la solicitud de incidencia fue aprobada y se encuentra revisión.
  2. Resolved: la incidencia fue resuelta y es posible reabrirla.
  3. Closed: el problema fue cerrado. Este pudo o no haber sido resuelto.
Workflow para issue tracking con Jira.

Transiciones

Las transiciones son las que determinan los estados de las solicitudes de mantenimientos, los issues tal y como se muestra en la tabla explicativa de la figura "Workflog para issue tracking".

Paso Descripción
1. Un usuario, A, detecta un problema.
2. A crea un ticket (TODO).
3. A lo asigna a un potencial reparador, B.
1. El problema es resuelto por un par antes que B haga el intento o
2. A lo resuelve.
1. A modifica el estado del ticket a done.
2. Ir a 5.
4. B aprueba la solicitud de incidencia (in progress).
1. B intenta resolver el problema.
1. B resuelve el problema,
1. B modifica el estado del ticket a done,
2. ir a 5;
2. si no,
1. Ir a 4.1.
2. B detiene el intento de solución.
1. Ir a 4.1.
5. B reabre el ticket,
1. ir a 2;
6. si no, ir a 2.

De lo anterior, por ejemplo, podría considerarse como curso normal: 1.→2.→3.→4.→4.1.→4.1.1.→4.1.1.1.→4.1.1.2.→5.→6, i.e., un usuario asigna un ticket a otro usuario como una solicitud de modificación, este último lo resuelve y lo cierra.

Ventajas y desventajas

Adoptar el uso de un sistema de gestión de incidencias en el desarrollo de un proyecto de software trae consigo ventajas como:

  • Único lugar para la creación y visualización de incidencias de un proyecto generadas por colaboradores o usuarios.
    • Sistemas de gestión de seguimientos como el de GitHub aparecen integrados al proyecto, pero estos pueden existir de forma independiente.
  • Categorización de incidencias.
  • Rápido acceso a historial completo de una incidencia.
    • La mayorías de los issue trackers incorporan cuadros para búsquedas con filtros. Pueden existir historiales largos.
  • Detalle transparente para usuarios generadores de solicitudes de modificación de un software.
    • En GitHub, por ejemplo, cuando se genera un ticket, este no puede ser eliminado[5]; sí, cerrado o reabierto.

Se identifica a lo menos una desventaja cuando se utiliza un framework como Scrum para la gestión de un proyecto[6]. Con Scrum, una incidencia se discutiría al finalizar una iteración de desarrollo y solo una personalidad, el Product Owner, está encargada de priorizarla y decidir cuándo se resuelve en base a las sugerencia de los Scrum Teams.

Referencias

  1. Cruz, P; y Visconti, M. (2016). Ingeniería de Software: Evolución & Mantención.
  2. Creus, A. (1991). Fiabilidad de seguridad de procesos industriales. Recuperado de https://books.google.cl/books?id=Lm0dih_S3fUC&pg=PA37&lpg=PA37&dq=fallo+nivel+operacional&source=bl&ots=FKYJ2j6sav&sig=uKobpama2uK0zSQal-1sVNpg8Qo&hl=en&sa=X&redir_esc=y#v=onepage&q=fallo%20nivel%20operacional&f=false
  3. Atlassian. (s.f.). Simple Issue Tracking Project. Recuperado de https://confluence.atlassian.com/jira064/simple-issue-tracking-project-720412430.html
  4. Sifter, LLC. (2007). Bugs & Issue Tracking. Recuperado de https://sifterapp.com/blog/2007/08/bug-issue-tracking/
  5. cirosantilli. (2014). Delete / Remove an issue completely. Recuperado de https://github.com/isaacs/github/issues/253
  6. Niebudek, M. (2009). Why a bug tracker is not a good tool for agile project management?. Recuperado de http://www.tinypm.com/blog/why-a-bugtracker-is-not-a-good-tool-for-agile-project-management/
Herramientas personales
Espacios de nombres
Variantes
Acciones
Navegación
Herramientas