Inspección de Fagan
La inspección de Fagan se refiere al proceso estructurado de intentar encontrar defectos en documentos de desarrollo tales como código de programación, especificaciones, diseño, y otros, durante las fases del proceso de desarrollo del software. Es llamado así debido a Michael Fagan, quien es reconocido como el inventor de la inspección formal del software.
Método[editar]
La inspección de Fagan (Fagan inspection) es un método de revisiones agrupadas usado para evaluar la salida de un proceso dado.
La inspección de Fagan define un proceso como una cierta actividad con una entrada pre-especificada y criterios de salida. En cada actividad u operación para la cual se especificaron criterios de entrada y salida se puede usar la inspección de Fagan para validar si la salida cumple con el criterio especificado para el proceso. Ejemplos de actividades para las que se puede utilizar la Inspección Fagan son:
- Especificaciones de requerimientos
- Software / Arquitectura de Sistemas de Información (por ejemplo DYA)
- Programación (por ejemplo, para las iteraciones en XP o DSDM)
- Pruebas de software (por ejemplo, para la creación de scripts de prueba)
El proceso de desarrollo de software es una aplicación típica de la Inspección de Fagan. Dicho proceso involucra una serie de operaciones (definición de requisitos, diseño, codificación, pruebas y mantenimiento) que ofrecen un producto final determinado. Dado que los costos de remediar un defecto en las primeras instancias del proceso son hasta 10-100 veces menores que hacerlo en la fase de mantenimiento, es esencial encontrarlos lo antes posible y es aquí donde ayuda la inspección de la salida de cada operación y su comparación con los requisitos de salida previstos.
Los documentos de alto y bajo nivel deben cumplir con determinados criterios de ingreso (requisitos que deben cumplirse para entrar en un proceso específico) antes de que puedan ser utilizados por un proceso de inspección formal.[1] De manera similar, en las Inspecciones Fagan los documento de bajo nivel deben cumplir con los criterios específicos de salida (definidos en el documento de alto nivel). Las desviaciones del documento de salida de bajo nivel respecto de los requisitos especificados en el documento de alto nivel se consideran defectos, en palabras de M.E.Fagan, "una instancia en la que un requisito no se cumple".,[1] defectos que se pueden clasificar en principales o menores.
Los principales o mayores son aquellos defectos que implican errores en el funcionamiento de la aplicación o la pérdida de funcionalidad. En otras palabras, el software no funcionará correctamente mientras no se resuelvan. En cambio, los defectos menores no ponen en peligro el correcto funcionamiento del software y se reducen a errores de ortografía, colocación incorrecta de controles en una interfaz del programa, etc.
Un típico proceso de inspección involucra las siguientes operaciones::[1]
- Planificación:
- Preparación de materiales
- Determinar y convocar a los participantes
- Organizar la reunión
- Información general
- Poner al tanto a los participantes acerca de los materiales a ser examinados
- Asignación de roles
- Preparación
- Los participantes se preparan para la reunión revisando los items a ser analizados, estudiando el material de apoyo y preparando preguntas o señalando posibles defectos
- Los participantes ensayan su rol
- Reunión de inspección
- Comprobación efectiva de los defectos
- Rehacer
- Es el paso en el método de inspección de software en el que los defectos encontrados durante la reunión de inspección se resuelven por el autor, diseñador o programador. Partiendo de la lista de defectos del documento de bajo nivel, se corrige hasta que se cumplen los requisitos en el documento de alto nivel.
- Seguimiento
- En la fase de seguimiento, bajo la responsabilidad del moderador se inspecciona que todos los defectos encontrados en la reunión de la inspección efectivamente se hayan corregido y que no hayan aparecido nuevos.
Los "roles" (participantes del proceso) habituales son sólo miembros del equipo de desarrollo. The participants fulfill different roles within the inspection process:[2][3]
- Autor/Diseñador/Programador: responsable de la escritura del documento de bajo nivel
- Lector del documento
- Revisores: responsables de revisar el documento desde el punto de vista de las pruebas
- Moderador: responsable del manejo de la reunión de Inspección
Mediante el uso de las inspecciones el número de errores en el producto final puede disminuir significativamente creando un producto de mayor calidad. Adicionalmente, el equipo de diseño y desarrollo será capaz en lo futuro de evitar errores frecuentes detectados en las sesiones de inspección. A las mejoras de calidad, cabe agregar la citada disminución de costos derivada de la prevención y detección temprana de errores reduciendo la cantidad de recursos necesarios para la depuración en las fases posteriores del proyecto.
En la práctica, grandes corporaciones como IBM han señalado que se pueden encontrar entre el 80-90%de los defectos y ahorrar así hasta un 25% en los recursos necesarios.
Referencias[editar]
- ↑ a b c Fagan, M.E., Advances in Software Inspections, 1986, IEEE Transactions on Software Engineering, Vol. SE-12, No. 7, pp. 744-751
- ↑ Fagan M.E., Design and Code inspections to reduce errors in program development, 1976, IBM Systems Journal, Vol.15 N°3, pp. 182–211]
- ↑ Eickelmann, Nancy S, Ruffolo, Francesca, Baik, Jongmoon, Anant,An Empirical Study of Modifying the Fagan Inspection Process and the Resulting Main Effects and Interaction Effects Among Defects Found, Effort Required, Rate of Preparation and Inspection, Number of Team Members and Product 1st Pass Quality, Proceedings of the 27th Annual NASA Goddard/IEEE Software Engineering Workshop
| Control de autoridades |
|
|---|
Datos: Q4209964