Parte de una serie sobre |
Desarrollo de software |
---|
Una revisión de software es "un proceso o reunión durante el cual un producto de software es examinado por personal de proyecto, gerentes, usuarios, clientes, representantes de usuarios u otras partes interesadas para recibir comentarios o aprobación". [1]
En este contexto, el término "producto de software" significa "cualquier documento técnico o documento parcial, producido como resultado de una actividad de desarrollo de software", y puede incluir documentos tales como contratos, planes y presupuestos de proyectos, documentos de requisitos, especificaciones, diseños, código fuente, documentación de usuario, documentación de soporte y mantenimiento, planes de prueba, especificaciones de prueba, estándares y cualquier otro tipo de producto de trabajo especializado.
Las revisiones de software se pueden dividir en tres categorías:
La "formalidad" identifica el grado en el que una actividad está regida por reglas acordadas (escritas). Los procesos de revisión de software existen en un espectro de formalidad, con actividades relativamente no estructuradas como la "verificación por pares" en un extremo del espectro, y enfoques más formales como los recorridos, las revisiones técnicas y las inspecciones de software, en el otro. La norma IEEE Std. 1028-1997 define estructuras formales, roles y procesos para cada una de las últimas tres ("revisiones formales por pares"), junto con las auditorías de software . [1] La norma IEEE 1028-1997 fue reemplazada por la IEEE 1028-2008. [3]
Los estudios de investigación [ ¿quién? ] tienden a apoyar la conclusión de que las revisiones formales superan ampliamente a las informales en cuanto a costo-efectividad. Las revisiones informales pueden ser a menudo innecesariamente costosas (debido a la pérdida de tiempo por falta de enfoque) y con frecuencia brindan una sensación de seguridad que no se justifica en absoluto por el número relativamente pequeño de defectos reales detectados y reparados.
La norma IEEE 1028 define un conjunto común de actividades para las revisiones "formales" (con algunas variaciones, especialmente para la auditoría de software). Esta norma aplica distinciones entre revisión de gestión , revisión técnica , inspección , inspección de campo , auditoría , etc.
La secuencia estipulada de actividades estándar se basa en gran medida en el proceso de inspección de software desarrollado originalmente en IBM por Michael Fagan . [4] Los diferentes tipos de revisión pueden aplicar esta estructura con distintos grados de rigor, pero todas las actividades son obligatorias para la inspección:
El valor más obvio de las revisiones de software (especialmente las revisiones formales) es que permiten identificar problemas antes y de manera más económica que si se detectaran mediante pruebas o en el campo (el "proceso de detección de defectos") [ cita requerida ] . El costo de encontrar y reparar un defecto mediante una revisión bien realizada puede ser uno o dos órdenes de magnitud menor que cuando el mismo defecto se encuentra mediante la ejecución de pruebas o en el campo. [ cita requerida ]
Un segundo valor, pero en última instancia más importante, de las revisiones de software es que pueden utilizarse para capacitar a los autores técnicos en el desarrollo de documentos con un nivel extremadamente bajo de defectos, y también para identificar y eliminar deficiencias del proceso que fomentan los defectos (el "proceso de prevención de defectos").
Esto es particularmente cierto en el caso de las revisiones por pares, si se realizan con frecuencia y de forma temprana, sobre muestras de trabajo, en lugar de esperar hasta que el trabajo esté terminado. Las revisiones tempranas y frecuentes de pequeñas muestras de trabajo pueden identificar errores sistemáticos en los procesos de trabajo del autor, que pueden corregirse antes de que se realicen más trabajos defectuosos. Esta mejora en las habilidades del autor puede reducir drásticamente el tiempo que lleva desarrollar un documento técnico de alta calidad y disminuir drásticamente la tasa de errores en el uso del documento en procesos posteriores.
Como principio general, cuanto antes se elabore un documento técnico, mayor será el impacto de sus defectos en las actividades posteriores y sus productos de trabajo. En consecuencia, el mayor valor se obtendrá de las revisiones tempranas de documentos como planes de marketing, contratos, planes y cronogramas de proyectos y especificaciones de requisitos. Los investigadores y los profesionales han demostrado la eficacia del proceso de revisión para detectar errores y problemas de seguridad. [5]