Revisión 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.

Variedades de revisión de software

Las revisiones de software se pueden dividir en tres categorías:

Diferentes tipos de revisiones por pares

  • La revisión de código es un examen sistemático (a menudo como revisión por pares ) del código fuente de una computadora.
  • La programación en pares es un tipo de revisión de código en el que dos personas desarrollan código juntas en la misma estación de trabajo.
  • La inspección es un tipo muy formal de revisión por pares en la que los revisores siguen un proceso bien definido para encontrar defectos.
  • El tutorial es una forma de revisión por pares en la que el autor guía a los miembros del equipo de desarrollo y otras partes interesadas a revisar un producto de software y los participantes hacen preguntas y realizan comentarios sobre los defectos.
  • La revisión técnica es una forma de revisión por pares en la que un equipo de personal calificado examina la idoneidad del producto de software para el uso previsto e identifica discrepancias con las especificaciones y estándares.

Reseñas formales versus informales

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.

Proceso genérico IEEE 1028 para revisiones formales

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:

  • 0. [Evaluación de entrada]: El líder de la revisión utiliza una lista de verificación estándar de criterios de entrada para garantizar que existan condiciones óptimas para una revisión exitosa.
  • 1. Preparación de la gestión: La gestión responsable se asegura de que la revisión contará con los recursos adecuados de personal, tiempo, materiales y herramientas, y se llevará a cabo de acuerdo con políticas, estándares u otros criterios relevantes.
  • 2. Planificación de la revisión: El líder de la revisión identifica o confirma los objetivos de la revisión, organiza un equipo de revisores y se asegura de que el equipo esté equipado con todos los recursos necesarios para llevar a cabo la revisión.
  • 3. Descripción general de los procedimientos de revisión: El líder de la revisión, o alguna otra persona calificada, se asegura (en una reunión si es necesario) de que todos los revisores comprendan los objetivos de la revisión, los procedimientos de revisión, los materiales disponibles para ellos y los procedimientos para llevar a cabo la revisión.
  • 4. Preparación [individual]: Los revisores se preparan individualmente para el examen grupal del trabajo bajo revisión, examinándolo cuidadosamente para detectar "anomalías" (defectos potenciales), cuya naturaleza variará según el tipo de revisión y sus objetivos.
  • 5. Examen [grupal]: Los revisores se reúnen en un momento planificado para poner en común los resultados de su actividad de preparación y llegar a un consenso sobre el estado del documento (o actividad) que se está revisando.
  • 6. Reelaboración/seguimiento: El autor del producto de trabajo (u otra persona asignada) emprende las acciones necesarias para reparar los defectos o satisfacer de otro modo los requisitos acordados en la reunión de examen. El líder de la revisión verifica que se hayan cerrado todos los elementos de acción.
  • 7. [Evaluación de salida]: El líder de la revisión verifica que se hayan realizado todas las actividades necesarias para una revisión exitosa y que se hayan finalizado todos los resultados apropiados para el tipo de revisión.

Valor de las reseñas

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]

Véase también

Referencias

  1. ^ ab IEEE Std. 1028-1997, "Estándar IEEE para revisiones de software", cláusula 3.5
  2. ^ Wiegers, Karl E. (2001). Revisiones por pares en software: una guía práctica. Addison-Wesley. pág. 14. ISBN 0201734850.
  3. ^ "Estándar IEEE para revisiones y auditorías de software". IEEE STD 1028-2008 : 1–53. 15 de agosto de 2008 [2008]. doi :10.1109/IEEESTD.2008.4601584. ISBN 978-0-7381-5768-9.
  4. ^ Fagan, Michael E: "Inspecciones de diseño y código para reducir errores en el desarrollo de programas", IBM Systems Journal , vol. 15, n.º 3, 1976; "Inspección de diseños y códigos de software", Datamation , octubre de 1977; "Avances en inspecciones de software", IEEE Transactions on Software Engineering , vol. 12, n.º 7, julio de 1986
  5. ^ Charles P. Pfleeger, Shari Lawrence Pfleeger. Seguridad en la Computación . Cuarta edición. ISBN 0-13-239077-9 
Retrieved from "https://en.wikipedia.org/w/index.php?title=Software_review&oldid=1236227559#IEEE_1028_generic_process_for_formal_reviews"