Revisión de software

Una revisión de software es "un proceso o reunión durante el cual el personal del proyecto, los gerentes, los usuarios, los clientes, los representantes de los usuarios u otras partes interesadas examinan un producto de software para obtener comentarios o aprobación".

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:

• Los exámenes de los pares de software son realizados por uno o más colegas del autor, para evaluar el contenido técnico y/o la calidad del trabajo.
• Los representantes de la administración realizan exámenes de gestión de programas para evaluar la situación de los trabajos realizados y tomar decisiones sobre las actividades en curso.
• Los exámenes de auditoría de software son realizados por personal externo al proyecto de software, para evaluar el cumplimiento de las especificaciones, normas, acuerdos contractuales u otros criterios.

• La revisión del código es un examen sistemático (a menudo como revisión por pares) del código fuente de la computadora.
• La programación de pares es un tipo de revisión de código donde dos personas desarrollan código juntos en la misma estación de trabajo.
• La inspección es un tipo muy formal de revisión por pares donde los evaluadores están siguiendo un proceso bien definido para encontrar defectos.
• Walkthrough es una forma de revisión por pares donde el autor dirige a miembros del equipo de desarrollo y otras partes interesadas pasan por un producto de software y los participantes hacen preguntas y hacen comentarios sobre defectos.
• El examen técnico es una forma de examen entre pares en la que un equipo de personal calificado examina la idoneidad del producto del software para su uso previsto e identifica discrepancias de las especificaciones y normas.

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 1028-1997 define las estructuras, los roles y los procesos formales para cada una de las últimas tres ("revisiones formales por pares"), junto con las auditorías de software. La norma IEEE 1028-1997 fue reemplazada por la IEEE 1028-2008.

Los estudios de investigació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.

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 general, 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. Los distintos tipos de revisión pueden aplicar esta estructura con distintos grados de rigor, pero todas las actividades son obligatorias para la inspección:

• 0. [Evaluación de entrada]: El líder de revisión utiliza una lista estándar de criterios de entrada para asegurar que existan condiciones óptimas para una revisión exitosa.
• 1. Preparación de la gestión: La gestión responsable garantiza que el examen se dote de recursos suficientes al personal, el tiempo, los materiales y los instrumentos, y se llevará a cabo de conformidad con políticas, normas u otros criterios pertinentes.
• 2. Planificación del examen: El líder de revisión identifica o confirma los objetivos de la revisión, organiza un equipo de revisores y asegura que el equipo esté equipado con todos los recursos necesarios para realizar la revisión.
• 3. Panorama general de los procedimientos de examen: El líder del examen, o alguna otra persona cualificada, garantiza (en una reunión si es necesario) que todos los examinadores entiendan los objetivos de examen, los procedimientos de examen, los materiales a su disposición y los procedimientos para realizar el examen.
• 4. [Individual] Preparación: Los revisores se preparan individualmente para el examen de grupo de los trabajos objeto de examen, examinándolo cuidadosamente para "anomalies" (defectos potenciales), cuya naturaleza variará con el tipo de revisión y sus objetivos.
• 5. [Grupo] Examen: The reviewers meet at a planned time to pool the results of their preparation activity and arrive at a consensus regarding the status of the document (or activity) being reviewed.
• 6. Rework/follow-up: El autor del producto de trabajo (o de otra persona asignada) lleva a cabo las acciones necesarias para reparar defectos o satisfacer los requisitos acordados en la reunión de examen. The review leader verifies that all action items are closed.
• 7. [Exit evaluation]: The review leader verifies that all activities necessary for successful review have been achieved and that all outputs appropriate to the type of review have been finalized.

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"). 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.

Un segundo valor, pero en definitiva más importante, de las revisiones de software es que se pueden utilizar 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 las 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.

• Calidad del software
• Lista de filosofías de desarrollo de software