Una revisión de software es "un proceso o reunión durante la cual un producto de software es examinado por 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 reseñas 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 gestión de 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 auditorías de software son realizadas por personal ajeno al proyecto de software para evaluar el cumplimiento de las especificaciones, los estándares, los acuerdos contractuales u otros criterios.
Diferentes tipos de revisiones por pares
- La revisión de código es un examen sistemático (a menudo mediante revisión por pares ) del código fuente de una computadora.
- La programación en parejas 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 proceso de revisión por pares es una forma de revisión en la que el autor guía a los miembros del equipo de desarrollo y a otras partes interesadas a través de 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 cualificado examina la idoneidad del producto de software para el uso previsto e identifica discrepancias con respecto a las especificaciones y los estándares.
revisiones formales versus informales
La "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 formalidad, con actividades relativamente no estructuradas como la "revisión entre 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, roles y procesos formales para cada una de las tres últimas ("revisiones formales por pares"), junto con las auditorías de software . [ 1 ] La norma IEEE 1028-1997 fue sucedida por la norma IEEE 1028-2008. [ 3 ]
Los estudios de investigación suelen respaldar la conclusión de que las revisiones formales superan con creces a las informales en términos de rentabilidad. Las revisiones informales a menudo resultan innecesariamente costosas (debido a la pérdida de tiempo por falta de enfoque) y con frecuencia generan una falsa sensación de seguridad que no se justifica 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 revisiones "formales" (con algunas variaciones, especialmente para auditorías de software). Esta norma establece distinciones entre revisión de gestión , revisión técnica , inspección , recorrido , 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 ] 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 las condiciones óptimas para una revisión exitosa.
- 1. Preparación de la dirección: La dirección responsable garantiza que la revisión contará con los recursos adecuados en cuanto a personal, tiempo, materiales y herramientas, y que se llevará a cabo de acuerdo con las políticas, normas u otros criterios pertinentes.
- 2. Planificación de la revisión: El responsable de la revisión identifica o confirma los objetivos de la misma, organiza un equipo de revisores y se asegura de que el equipo cuente con todos los recursos necesarios para llevar a cabo la revisión.
- 3. Descripción general de los procedimientos de revisión: El responsable de la revisión, u otra persona cualificada, 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 a su disposición 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 que se está revisando, examinándolo cuidadosamente en busca de "anomalías" (defectos potenciales), cuya naturaleza variará según el tipo de revisión y sus objetivos.
- 5. Examen [de grupo]: Los revisores se reúnen en un momento planificado para compartir 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. Revisión/seguimiento: El autor del producto (u otra persona designada) realiza las acciones necesarias para corregir los defectos o cumplir con los requisitos acordados en la reunión de revisión. El responsable de la revisión verifica que se hayan completado todas las acciones pendientes.
- 7. [Evaluación final]: 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 productos apropiados para el tipo de revisión.
Valor de las reseñas
El valor más evidente de las revisiones de software (especialmente las revisiones formales) es que pueden identificar problemas antes y a un costo menor que si se detectaran mediante pruebas o uso en campo (el "proceso de detección de defectos"). [ 5 ] El costo de encontrar y corregir 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 campo.
Un segundo valor, pero en última instancia más importante, de las revisiones de software es que pueden utilizarse para capacitar a los redactores técnicos en el desarrollo de documentos con muy pocos defectos, y también para identificar y eliminar las deficiencias de los procesos que fomentan los defectos (el "proceso de prevención de defectos").
Esto es especialmente cierto en el caso de las revisiones por pares, siempre que se realicen de forma temprana y frecuente, sobre muestras de trabajo, en lugar de esperar a que el trabajo esté terminado. Las revisiones tempranas y frecuentes de pequeñas muestras de trabajo permiten identificar errores sistemáticos en los procesos de trabajo del autor, que pueden corregirse antes de que se produzcan más errores. Esta mejora en las habilidades del autor puede reducir drásticamente el tiempo necesario para desarrollar un documento técnico de alta calidad y disminuir considerablemente la tasa de errores al utilizar dicho 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. Por consiguiente, se obtendrá el mayor valor de las revisiones tempranas de documentos como planes de marketing, contratos, planes y cronogramas de proyectos y especificaciones de requisitos. Investigadores y profesionales han demostrado la eficacia del proceso de revisión para detectar errores y problemas de seguridad. [ 6 ]
Véase también
- Calidad del software
- Lista de filosofías de desarrollo de software
Referencias
- 1 2 Norma IEEE 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. pág. 14. ISBN 0201734850.
- ↑ "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.
- ↑ 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ódigo de software", Datamation , octubre de 1977; "Avances en inspecciones de software", IEEE Transactions on Software Engineering , vol. 12, n.° 7, julio de 1986
- ↑ "Proceso de detección de defectos" . unsworks.unsw.edu.au .
- ^ Charles P. Pfleeger, Shari Lawrence Pfleeger. Seguridad en la Computación . Cuarta edición. ISBN 0-13-239077-9
- Análisis de software