4.4 Revisión de Diseño

El objetivo de toda revisión técnica es detectar errores y descubrir aspectos que tendrían un efecto negativo en el software que se va a desarrollar. Entre más pronto se descubra y corrija un error, menos probable es que se propague a otros productos del trabajo de la ingeniería de software y que se amplifique, lo que provocaría un mayor esfuerzo para corregirlo. A fin de determinar si las actividades de control de calidad funcionan, deben determinarse varias métricas. Éstas se centran en el esfuerzo requerido para realizar la revisión y los tipos y severidad de errores descubiertos durante la revisión. Una vez recabadas las métricas, se usan para evaluar la eficacia de las revisiones que se efectúen. Los datos de la industria indican que las revisiones tienen un rendimiento elevado sobre la inversión. Un modelo de referencia para la formalidad de la revisión identifica roles de las personas, planeación y preparación, estructura de la reunión, enfoque de corrección y verificación como las características que indican el grado de formalidad con el que se realiza una revisión. Las revisiones informales son de naturaleza casual, pero pueden usarse con eficacia para detectar errores. Las revisiones formales son más estructuradas y tienen una probabilidad mayor de dar como resultado un software de alta calidad. Las revisiones informales se caracterizan por tener una planeación y preparación mínimas y poco registro de su desarrollo. Las verificaciones de escritorio y la programación por parejas forman parte de esta categoría de revisión. Una revisión técnica formal es una reunión estilizada que ha demostrado ser extremadamente eficaz para detectar errores. Los walkthrougs y las inspecciones establecen roles definidos para cada revisor, estimulan la planeación y la preparación previa, requieren la aplicación de lineamientos de revisión definidos y ordenan llevar registros y hacer reportes. 

REVISIONES : 

ESPECTRO DE FORMALIDAD Las revisiones técnicas deben aplicarse con un nivel de formalidad apropiado para el producto que se va a elaborar, para el plazo que tiene el proyecto y para el personal que realice el trabajo. Cada una de las características del modelo de referencia ayuda a definir el nivel de formalidad de la revisión. La formalidad de una revisión se incrementa cuando:

1) se definen explícitamente roles distintos para los revisores

2) hay suficiente cantidad de planeación y preparación para la revisión

3) se define una estructura distinta para la revisión (incluso tareas y productos internos del trabajo) 

4) el seguimiento por parte de los revisores tiene lugar para cualesquiera correcciones que se efectúen.

REVISIONES INFORMALES  Las revisiones informales incluyen una simple verificación de escritorio de un trabajo de ingeniería de software, hecha con algún colega, o una reunión casual (con más de dos personas) con objeto de revisar un producto o aspectos orientados a la revisión de programación por pares. Una verificación de escritorio simple o una reunión casual realizada con un colega constituye una revisión. Sin embargo, como no hay una planeación o preparación por adelantado, ni agenda o estructura de la reunión, y no se da seguimiento a los errores descubiertos, la eficacia de tales revisiones es mucho menor que la de los enfoques más formales. Pero una verificación de escritorio sencilla descubre errores que de otro modo se propagarían en el proceso del software. Una forma de mejorar la eficacia de una verificación de escritorio es desarrollar un conjunto de listas de revisión para cada producto grande del trabajo generado por el equipo de software. Las preguntas que se plantean en la lista son generales, pero servirán para guiar a los revisores en la verificación del producto. 

REVISIONES TÉCNICAS FORMALES Una revisión técnica formal (RTF) es una actividad del control de calidad del software realizada por ingenieros de software (y otras personas). Los objetivos de una RTF son: 

1) descubrir los errores en funcionamiento, lógica o implementación de cualquier representación del software 

2) verificar que el software que se revisa cumple sus requerimientos

3) garantizar que el software está representado de acuerdo con estándares predefinidos

4) obtener software desarrollado de manera uniforme 

5) hacer proyectos más manejables. 

Además, la RTF sirve como método de capacitación, pues permite que los ingenieros principiantes observen distintos enfoques de análisis, diseño e implementación del software. La RTF también funciona para estimular el respaldo y la continuidad debido a que varias personas se familiarizan con software que de otra manera no hubieran visto. La RTF en realidad es una clase que incluye walkthroughs e inspecciones. Cada RTF se realiza como una reunión y tendrá éxito sólo si se planea, controla y ejecuta en forma apropiada. En las secciones que siguen se presentan lineamientos similares a aquellos usados para un walkthrough, como representativos de la revisión técnica formal.

Reporte y registro de la revisión 

Durante la RTF, un revisor (el secretario) registra activamente todos los asuntos que se planteen. Éstos se resumen al final de la reunión y se produce la lista de pendientes de la revisión. Además se elabora un reporte técnico formal de la revisión. Éste responde tres preguntas: 

 1. ¿Qué fue lo que se revisó? 

 2. ¿Quién lo revisó? 

 3. ¿Cuáles fueron los descubrimientos y las conclusiones?

Lineamientos para la revisión 

Los lineamientos para efectuar revisiones técnicas formales deben establecerse por adelantado, distribuirse a todos los revisores, llegar al consenso y, después, seguirse. Una revisión sin control con frecuencia es peor que si no se hiciera ninguna. Los siguientes representan un conjunto mínimo de lineamientos para hacer revisiones técnicas formales: 

1. Revise el producto, no al productor. Una RTF involucra personas y sus egos. Si se lleva a cabo en forma adecuada, la RTF debe dejar en todos los participantes una sensación de logro. Si se efectúa de modo inapropiado, adopta un aire inquisitorial. Los errores deben señalarse en forma amable; el tono de la reunión debe ser relajado y constructivo; el trabajo no debe apenar o menospreciar a nadie. El líder de la revisión debe conducir la reunión en tono y actitud apropiados y debe detenerla de inmediato si se sale de control. 

2. Establezca una agenda y sígala. Una de las fallas clave de las reuniones de todo tipo es la dispersión. Una RTF debe mantenerse encarrilada y dentro del programa. El líder de la revisión tiene la responsabilidad de que así sea y no debe sentir temor de llamar al orden a las personas cuando se dispersen. 

3. Limite el debate y las contestaciones. Cuando el revisor plantee un asunto, quizá no haya acuerdo universal acerca de su efecto. En vez de perder tiempo en debatir la cuestión, ésta debe registrarse para discutirla después. 

4. Enuncie áreas de problemas, pero no intente resolver cada uno. Una revisión no es una sesión para resolver problemas. Es frecuente que la solución de un problema la obtenga el productor, solo o con ayuda de otra persona. La solución de los problemas debe posponerse para después de la reunión de revisión. 

5. Tome notas por escrito. A veces es buena idea que el secretario tome notas en un pizarrón a fin de que la redacción y prioridades sean evaluadas por los demás revisores a medida que la información se registra. De manera alternativa, pueden tomarse notas directamente en una computadora. 

6. Limite el número de participantes e insista en la preparación previa. Dos cabezas piensan más que una, pero 14 no son necesariamente mejor que 4. Mantenga limitado el número de personas involucradas. Sin embargo, todos los miembros del equipo de revisión deben prepararse. El líder de la revisión tiene que solicitar comentarios por escrito (lo que proporciona un indicador de que el revisor ha inspeccionado el material). 

7. Desarrolle una lista de verificación para cada producto que sea probable que se revise. Una lista de verificación ayuda al líder del proyecto a estructurar la RTF y a cada revisor a centrarse en los aspectos importantes. Deben desarrollarse listas para los productos del análisis, el diseño, el código e incluso las pruebas. 

8. Asigne recursos y programe tiempo para las RTF. Para que las revisiones sean eficaces, deben programarse como tareas del proceso de software. Además, debe programarse tiempo para hacer las inevitables modificaciones que ocurrirán como resultado de la RTF.

9. Dé una capacitación significativa a todos los revisores. Para que una revisión sea eficaz, todos los revisores deben recibir cierta capacitación formal. Ésta debe hacer énfasis tanto en aspectos relacionados con el proceso como en el lado de la sicología humana de la revisión. Freedman y Weinberg estiman en un mes la curva de aprendizaje para que 20 personas participen de modo eficaz en una revisión. 

10. Revise las primeras revisiones. Volver a revisar puede ser benéfico para descubrir problemas con el proceso de revisión en sí mismo. El primer producto por revisar deben ser los lineamientos de la revisión. Debido a que son muchas las variables (número de participantes, tipo de productos del trabajo, tiempo y duración, enfoque específico de la revisión, etc.) que influyen en que una revisión sea exitosa, la organización de software debe experimentar para determinar el enfoque que mejor funcione en el contexto local.