Este documento presenta una guía sobre la gestión de incidentes en el desarrollo de software. Explica que los incidentes proporcionan información valiosa sobre los procesos y la organización que es esencial para la toma de decisiones. Detalla los requisitos de información necesarios para diferentes roles como desarrollo, testing y producción. Además, cubre temas como cómo gestionar incidentes de manera efectiva, minimizando el retrabajo a través de herramientas, procesos estandarizados, capacitación y trabajo en equipo.

1. Gestión de incidentes
Workshop
1
Ing. Mariana Travieso
Ing. María Elisa Presto

2. ¿Quién es quién?
2

3. 3
Mucho más que “bugs”
 Los incidentes aportan información
sobre
• Procesos
• Organización
 Esencial para la toma de decisiones

4. ¿Que información se
requiere?
Pasaje a
producción
Desarrollo
Testing
4

5. Pasaje a producción
 Cantidad y severidad de incidentes
detectados sin corrección
 Categorización de los incidentes
detectados aún no corregidos
 Cantidad, severidad y categorización de
los incidentes detectados por módulo
5

6. Grupo de testing
 Líder
• Cantidad de incidentes corregidos
• Cantidad de incidentes a aclarar
• Versión en que serán corregidos los
incidentes
 Tester
• Estado en que está cada incidente
reportado para poder hacerle seguimiento
6

7. ¿Cómo gestionar los
incidentes?
• Para que cada actor pueda obtener la
información que necesita
• Minimizando el re-trabajo
7

8. Incidentes
Conceptos
8

9. 9
James Bach – Reframing requirements analysis

10. Problemas e incongruencias
 Entre especificación, requerimientos y
producto:
• que la especificación no refleje los
requerimientos
• que el producto no refleje los
requerimientos
• que el producto no refleje la especificación
10

11. Minimizando el re-trabajo
11

12. Problemas de los reportes
• No se entienden, no se comprenden
• Demasiado complejos
• Con la información registrada no es posible
reproducir el incidente
• No se considera una falla
12

13. Problemas de gestión
 Los incidentes
• “se pierden”
• no se pueden monitorizar ni seguir
• no están centralizadas
• es difícil de contarlos
• se registran más de una vez
 Se generan malos entendidos
 Es complicado obtener información
13

14. Reportes de incidentes
14

15. Información de contexto
 Versión del producto en que fue
detectado el incidente
 Módulos con los cuales está vinculado el
incidente
 Referencias a especificación de
requerimientos o casos de uso
 Incidentes relacionados y soluciones
 Origen del incidente si se conoce o
sospecha
15

16. Clasificar los incidentes
 Prioridad: Cuándo tiene que ser resuelto
el incidente.
 Severidad: Impacto (técnico y en el
negocio) y visibilidad si el incidente
ocurre.
 Categoría: Etiqueta genérica para un
conjunto de incidentes que se relacionan
de cierta manera.
16

17. Consenso y alineación
 Entre todos los involucrados del
proyecto
 En cómo reportar
 Cómo responder
 Qué campos completar
 Qué información dar
 Qué roles habrán
17

18. Capacitar
 Es importante que quién reporta esté
capacitado
 Lo más adecuado
• Un curso teórico/práctico y experiencia!
 Conocer los problemas comunes y cómo
evitarlos
 Capacitar a los desarrolladores
también!!
18

19. Trabajo en equipo
 Reporta las diferencias
19

20. Gestión de los incidentes
20

21. Proceso de gestión de
incidentes
 Si no hay proceso, definirlo
• ¿Qué hace cada rol?
• ¿Cuáles son los estados?
 ¡Una herramienta nos facilitará la vida!
21

22. Ejemplo
22

23. Trabajo en equipo
23

24. Herramientas
 ¿Qué es una herramienta de gestión de
incidentes?
 ¿Qué herramientas conocen?
24

25. Taller de herramientas
25

26. Los esperamos mañana
26

27. 27
¡Gracias por participar!
 Sitio: http://www.ces.com.uy
 Twitter: @ces_com_uy
 Facebook: /CentroDeEnsayosDeSoftware
 Plataforma de capacitación: http://www.capacitacion.ces.com.uy
 Blog: http://blog.ces.com.uy
 Contacto: info@ces.com.uy
 Youtube: Centro de Ensayos de Software