Articulo de referencia

Inspección de Fagan

Una inspección Fagan es un proceso que busca detectar defectos en documentos (como código fuente o especificaciones formales) durante las distintas fases del desarrollo de softw...

Una inspección Fagan es un proceso que busca detectar defectos en documentos (como código fuente o especificaciones formales) durante las distintas fases del desarrollo de software . Recibe su nombre de Michael Fagan, a quien se le atribuye la invención de las inspecciones formales de software .

La inspección Fagan define un proceso como una actividad determinada con criterios de entrada y salida predefinidos . En todo proceso con criterios de entrada y salida especificados, las inspecciones Fagan permiten validar si el resultado cumple con dichos criterios. La inspección Fagan utiliza un método de revisión grupal para evaluar el resultado de un proceso determinado.

Ejemplos

Algunos ejemplos de actividades para las que se puede utilizar la inspección Fagan son:

  • Especificación de requisitos
  • Arquitectura de software/sistemas de información (por ejemplo, DYA )
  • Programación (por ejemplo, para iteraciones en XP o DSDM )
  • Pruebas de software (por ejemplo, al crear scripts de prueba)

Uso

El proceso de desarrollo de software es una aplicación típica de la inspección de Fagan. Dado que los costos de corregir un defecto son entre 10 y 100 veces menores en las operaciones iniciales que en la fase de mantenimiento, [ 1 ] es fundamental encontrar los defectos lo más cerca posible del punto de inserción. Esto se logra inspeccionando el resultado de cada operación y comparándolo con los requisitos de salida, o criterios de finalización , de dicha operación.

Criterios

Los criterios de entrada son los requisitos que deben cumplirse para acceder a un proceso específico. [ 2 ] Por ejemplo, para las inspecciones Fagan, los documentos de alto y bajo nivel deben cumplir con criterios de entrada específicos antes de poder utilizarse en un proceso de inspección formal.

Los criterios de salida son los requisitos que deben cumplirse para completar un proceso específico. Por ejemplo, en las inspecciones de Fagan, el documento de nivel inferior debe cumplir con criterios de salida específicos (tal como se especifican en el documento de nivel superior) antes de que el proceso de desarrollo pueda pasar a la siguiente fase.

Los criterios de salida se especifican en un documento de alto nivel, que luego se utiliza como estándar con el que se compara el resultado de la operación (documento de bajo nivel) durante la inspección. Cualquier fallo del documento de bajo nivel para satisfacer los requisitos de alto nivel especificados en el documento de alto nivel se denomina defecto [ 2 ] (y puede clasificarse además como defectos mayores o menores ). Los defectos menores no amenazan el correcto funcionamiento del software, pero pueden ser pequeños errores como faltas de ortografía o una posición poco estética de los controles en una interfaz gráfica de usuario .

Operaciones típicas

Una inspección típica de Fagan consta de las siguientes operaciones: [ 2 ]

  • Planificación
    • Preparación de materiales
    • Organización de los participantes
    • Organización del lugar de encuentro
  • Descripción general
    • Formación grupal de los participantes sobre los materiales en revisión.
    • Asignación de roles
  • Preparación
    • Los participantes revisan el artículo que se va a inspeccionar y el material de apoyo para prepararse para la reunión, anotando cualquier pregunta o posible defecto.
    • Los participantes preparan sus papeles
  • Reunión de inspección
    • Hallazgo real del defecto
  • Rehacer
    • La reelaboración es la etapa de la inspección de software en la que el autor, diseñador o programador resuelve los defectos detectados durante la reunión de inspección. A partir de la lista de defectos, se corrige el documento de bajo nivel hasta que se cumplan los requisitos del documento de alto nivel.
  • Hacer un seguimiento
    • En la fase de seguimiento de las inspecciones de software, todos los defectos encontrados en la reunión de inspección deben corregirse (tal como se corrigieron en la fase de reelaboración). El moderador es responsable de verificar que esto se cumpla. Debe comprobar que todos los defectos se hayan corregido y que no se hayan introducido nuevos defectos al intentar corregir los iniciales. Es fundamental que se corrijan todos los defectos, ya que los costos de corregirlos en una fase posterior del proyecto pueden ser entre 10 y 100 veces superiores a los costos actuales. [ 1 ]
Modelo básico de inspección de Fagan

Hacer un seguimiento

En la fase de seguimiento de una inspección Fagan, se deben verificar los defectos corregidos durante la fase de retrabajo. El moderador suele ser el responsable de verificar el retrabajo. En ocasiones, el trabajo corregido puede aceptarse sin verificación, por ejemplo, cuando el defecto era trivial. En casos más complejos, el equipo de inspección (no solo el moderador) realiza una reinspección completa. En esta fase, todos los participantes coinciden en que los defectos se han solucionado adecuadamente.

Si la verificación falla, vuelva al proceso de reelaboración.

Roles

El proceso de inspección normalmente lo llevan a cabo miembros del mismo equipo que implementa el proyecto. Los participantes desempeñan diferentes roles dentro del proceso de inspección: [ 3 ] [ 4 ]

  • Autor/Diseñador/Programador: la persona que escribió el documento de bajo nivel.
  • Lector: parafrasea el documento de bajo nivel
  • Revisores: revisan el documento de bajo nivel desde el punto de vista de las pruebas.
  • Moderador: responsable de la sesión de inspección, actúa como entrenador.
  • Registrador: documenta los defectos

Beneficios y resultados

Mediante las inspecciones, el número de errores en el producto final puede disminuir significativamente, lo que resulta en un producto de mayor calidad. En el futuro, el equipo incluso podrá evitar errores, ya que las sesiones de inspección les brindan información sobre los errores más frecuentes tanto en el diseño como en la codificación, lo que permite prevenirlos desde su origen. Al mejorar continuamente el proceso de inspección, esta información puede aprovecharse aún más. [ 2 ]

Junto con los beneficios cualitativos mencionados anteriormente, se pueden lograr importantes "mejoras en los costos", ya que la prevención y la detección temprana de errores reducirán la cantidad de recursos necesarios para la depuración en fases posteriores del proyecto.

En la práctica, grandes corporaciones como IBM han reportado resultados muy positivos, indicando que se puede encontrar entre el 80% y el 90% de los defectos y lograr ahorros de recursos de hasta un 25%. [ 2 ]

mejoras

Aunque el método de inspección de Fagan ha demostrado ser muy eficaz, varios investigadores han sugerido mejoras. M. Genuchten [ 5 ], por ejemplo, ha investigado el uso de un Sistema Electrónico de Reuniones (EMS) para mejorar la productividad de las reuniones con resultados positivos [ 6 ].

Otros investigadores proponen el uso de software que mantiene una base de datos de errores detectados y escanea automáticamente el código del programa en busca de estos errores comunes. [ 7 ] Esto, a su vez, debería resultar en una mayor productividad.

Referencias

  1. 1 2 Fagan, ME (1976). "Diseño e inspecciones de código para reducir errores en el desarrollo de programas". IBM Systems Journal . 15 (3): 182– 211. doi : 10.1147/sj.153.0182 . ISSN 0018-8670 . 
  2. 1 2 3 4 5 Fagan, Michael E (2001) [1986]. "Avances en inspecciones de software". Pioneros y sus contribuciones a la ingeniería de software . págs. 335–360 . doi : 10.1007/978-3-642-48354-7_14 . ISBN  978-3-540-42290-7.
  3. ME, Fagan (1976). "Inspecciones de diseño y código para reducir errores en el desarrollo de programas" (PDF) . IBM Systems Journal . 15 (3): 182– 211. doi : 10.1147/sj.153.0182 .
  4. Eickelmann, NS; Ruffolo, F; Baik, J; Anant, A (2003). "Un estudio empírico de la modificación del proceso de inspección de Fagan y los efectos principales y de interacción resultantes entre los defectos encontrados, el esfuerzo requerido, la tasa de preparación e inspección, el número de miembros del equipo y la calidad del primer pase del producto". 27.º Taller Anual de Ingeniería de Software NASA Goddard/IEEE, 2002. Actas . pág. 58. doi : 10.1109/SEW.2002.1199450 . ISBN  978-0-7695-1855-8. S2CID 114935466 . 
  5. «Autor: Michiel van Genuchten» . Archivado desde el original el 2022-01-20.
  6. Genuchten, M; Cornelissen, W; Van Dijk, C (invierno de 1997-1998). "Apoyo a las Inspecciones con un Sistema de Reuniones Electrónicas". Revista de sistemas de información de gestión . 14 (3): 165– 179. doi : 10.1080/07421222.1997.11518179 .
  7. Doolan, EP (febrero de 1992). "Experiencia con el método de inspección de Fagan". Software: Practice and Experience . 22 (2): 173– 182. doi : 10.1002/spe.4380220205 . S2CID 942973 . 

Ron Radice, Inspecciones de software de alta calidad y bajo costo, Paradoxicon Publishing (21 de septiembre de 2001)

Obtenido de " https://en.wikipedia.org/w/index.php?title=Fagan_inspection&oldid=1360123315#Criteria "