Una revisión de software es "un proceso o reunión durante el cual un producto de software es examinado por el personal del proyecto, gerentes, usuarios, clientes, representantes de usuarios u otras partes interesadas para 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:
- Las revisiones por pares de software son realizadas por uno o más colegas del autor, para evaluar el contenido técnico y / o la calidad del trabajo. [2]
- Las revisiones de la gestión del software son realizadas por representantes de la dirección para evaluar el estado del trabajo realizado y tomar decisiones con respecto a las actividades posteriores.
- Las revisiones de auditoría de software son realizadas por personal externo al proyecto de software, para evaluar el cumplimiento de especificaciones, estándares, acuerdos contractuales u otros criterios.
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 la computadora.
- La programación en pareja es un tipo de revisión de código en la que dos personas desarrollan código juntas en la misma estación de trabajo.
- La inspección es un tipo de revisión por pares muy formal 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 dirige a los miembros del equipo de desarrollo y otras partes interesadas revisan un producto de software y los participantes hacen preguntas y 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 su uso previsto e identifica las discrepancias de las especificaciones y estándares.
Revisiones formales versus informales
"Formalidad" identifica el grado en que una actividad se rige por reglas acordadas (escritas). Los procesos de revisión de software existen en un espectro de formalidades, con actividades relativamente no estructuradas como "comprobación de amigos" hacia un extremo del espectro, y enfoques más formales como recorridos, revisiones técnicas e inspecciones de software, en el otro. IEEE Std. 1028-1997 define estructuras formales, roles y procesos para cada uno de los últimos tres ("revisiones formales por pares"), junto con auditorías de software . [1] IEEE 1028-1997 fue reemplazado por IEEE 1028-2008. [3]
Estudios de investigación [ ¿quién? ] tienden a respaldar la conclusión de que las revisiones formales superan en gran medida a las revisiones informales en cuanto a rentabilidad. Las revisiones informales a menudo pueden ser innecesariamente costosas (debido a la pérdida de tiempo debido a la falta de enfoque) y con frecuencia brindan una sensación de seguridad que está bastante injustificada por el número relativamente pequeño de defectos reales encontrados y reparados.
Proceso genérico IEEE 1028 para revisiones formales
IEEE Std 1028 define un conjunto común de actividades para revisiones "formales" (con algunas variaciones, especialmente para auditoría de software). La secuencia de actividades 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 diversos 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 gerencia: La gerencia responsable asegura que la revisión contará con los recursos adecuados con 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 realizar 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, asegura (en una reunión si es necesario) que todos los revisores comprenden los objetivos de la revisión, los procedimientos de revisión, los materiales disponibles para ellos y los procedimientos para realizar la revisión.
- 4. Preparación [individual]: Los revisores se preparan individualmente para el examen grupal del trabajo bajo revisión, examinándolo cuidadosamente en busca de "anomalías" (defectos potenciales), cuya naturaleza variará según el tipo de revisión y sus objetivos.
- 5. [Grupo] Examen: 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) realiza las acciones necesarias para reparar los defectos o satisfacer los requisitos acordados en la reunión de examen. El líder de revisión verifica que todos los elementos de acción estén cerrados.
- 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 pueden identificar problemas antes y de manera más económica de lo que se identificarían mediante pruebas o uso de 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 se encuentra el mismo defecto mediante la ejecución de una prueba o en el campo. [ cita requerida ]
Un segundo valor, pero en última instancia 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 muy pocos defectos, y también para identificar y eliminar las deficiencias del proceso que fomentan los defectos (el "proceso de prevención de defectos" ).
Este es particularmente el caso de las revisiones por pares si se llevan a cabo temprano y con frecuencia, sobre muestras de trabajo, en lugar de esperar hasta que el trabajo se haya completado. 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 error al usar el documento en procesos posteriores.
Como principio general, cuanto antes se produzca 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 tales como planes de marketing, contratos, planes de proyectos y cronogramas y especificaciones de requisitos. Los investigadores y profesionales han demostrado la eficacia del proceso de revisión para encontrar errores y problemas de seguridad. [5]
Ver también
- Calidad del software
- Lista de filosofías de desarrollo de software
Referencias
- ^ a b IEEE Std. 1028-1997, "Estándar IEEE para revisiones de software", cláusula 3.5
- ^ Wiegers, Karl E. (2001). Revisiones por pares en software: una guía práctica . Addison-Wesley. pag. 14. ISBN 0201734850.
- ^ "Estándar IEEE para revisiones y auditorías de software" . IEEE Std 1028-2008 : 1–53. 2008-08-15 [2008]. doi : 10.1109 / IEEESTD.2008.4601584 .
- ^ Fagan, Michael E: "Inspecciones de código y diseño 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 las inspecciones de software", IEEE Transactions on Software Engineering , vol. 12, No. 7, julio de 1986
- ^ Charles P. Pfleeger, Shari Lawrence Pfleeger. Seguridad en Computación . Cuarta edición. ISBN 0-13-239077-9
En 2020 se lanzó la primera plataforma de revisión de software honesta, https://Tekpon.com para convencer a más y más plataformas de generar revisiones reales de visitantes, no de pago. Si aceptamos reseñas falsas, compraremos productos que no queremos