Inspecciones de software

1. Introducción 2. Impacto de los defectos del software en el costo 3. Amplificación y eliminación de defectos 4. El proceso de inspección. 5. Métricas en inspecciones 6. Conclusiones 7. Referencias bibliográficas

1. Introducción

Las inspecciones de software surgen a partir de la necesidad de producir software de alta calidad. Algunos grupos de desarrollo creen que la calidad del software es algo en lo que deben preocuparse una vez que se ha generado el código. ¡ Error ¡ La garantía de la calidad del software es una actividad de protección que se aplica a lo largo de todo el proceso de ingeniería de software. La SQA (Software Quality Assurance) engloba:

• Un enfoque de gestión de calidad
• Tecnología de Ingeniería de Software efectiva (métodos y herramientas)
• Revisiones técnicas formales que se aplican durante el proceso del
• software
• Una estrategia de prueba multiescalada
• Un control de la documentación del software y de los cambios realizados
• Un procedimiento que asegure un ajuste a los estándares de desarrollo de
• software
• Mecanismos de medición y de generación de informes

El control de la calidad es una serie de revisiones, y pruebas utilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados.

La garantía de calidad o aseguramiento de la calidad consiste en la auditoria y las funciones de información de la gestión. El objetivo de la garantía de la calidad es proporcionar la gestión para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visión más profunda y segura de que la calidad del producto está cumpliendo sus objetivos. Es de esperar, que si los datos proporcionados mediante la garantía de la calidad identifican problemas, la gestión afronte los problemas y aplique los recursos necesarios para resolverlos.

La garantía de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes: los ingenieros de software, que realizan trabajo técnico, y un grupo SQA, que tiene la responsabilidad de la planificación de garantía de calidad.

En éste marco podemos ver a las inspecciones como una implementación de las revisiones formales del software las cuales representan un filtro para el proceso de ingeniería de software, éstas se aplican en varios momentos del desarrollo y sirven para detectar defectos que pueden así ser eliminados. Freeman y Weinberg [Fre90] argumentan de la siguiente forma la necesidad de revisiones:

El trabajo técnico necesita ser revisado por la misma razón que los lápices necesitan gomas: errar es humano. La segunda razón por la que necesitamos revisiones técnicas es que, aunque la gente es buena descubriendo algunos de sus propios errores, algunas clases de errores se le pasan mas fácilmente al que los origina que a otras personas. El proceso de revisión es, por lo tanto la respuesta a la plegaria de Robert Burns: ¡Que gran regalo sería poder vernos como nos ven los demás!

Una revisión es una forma de aprovechar la diversidad de un grupo de personas para:

1. Señalar la necesidad de mejoras en el producto de una sola persona o de un equipo
2. Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora.
3. Conseguir un trabajo de mayor calidad maximizando los criterios de Correctitud y Completitud principalmente .

Existen muchos tipos diferentes de revisiones que se pueden llevar adelante como parte de la ingeniería del software. Cada una tiene su lugar. Una reunión informal durante el almuerzo o en un café es una forma de revisión, si se discuten problemas técnicos. Una presentación formal de un diseño de software a una audiencia de clientes, ejecutivos y personal técnico es una forma de revisión. Sin embargo en éste trabajo nos concentraremos en una revisión técnica formal, que llamaremos Inspección de Software

2. Impacto de los defectos del software en el costo

Dentro del contexto de desarrollo de software, los términos "defecto" y "fallo" son sinónimos. Ambos implican un problema de calidad descubierto después de entregar el software a los usuarios finales.

El objetivo primario de las revisiones técnicas formales (inspección) es encontrar errores durante el proceso para evitar que se conviertan en defectos después de la entrega del software. El beneficio obvio de estas inspecciones es el descubrimiento de errores al principio para que no se propaguen al paso siguiente del proceso de desarrollo del software (catarata de errores de Mizuno).

Una serie de estudios (TRW, Nippon Electric y Mitre Corp., entre otros) indican que las actividades del diseño introducen entre el 50% y 65% de todos los errores(y en último lugar, todos los defectos) durante el proceso de software. Si embargo se ha demostrado que las inspecciones de software son efectivas en un 75% a la hora de detectar errores [JON86].

Con la detección y la eliminación de un gran porcentaje de errores, el proceso de inspección reduce substancialmente el costo de los pasos siguientes en las fases de desarrollo y mantenimiento.

Para ilustrar el impacto sobre el costo de la detección anticipada de errores, consideremos una serie de costos relativos que se basan en datos de costos realmente recogidos en grandes proyectos de software [IBM81]. Supongamos que un error descubierto durante el diseño cuesta corregirlo 1,0 unidad monetaria. De acuerdo a este costo , el mismo error descubierto justo antes de que comience la prueba costará 6,5 unidades; durante la prueba 15 unidades; y después de la entrega, entre 60 y 100 unidades.

3. Amplificación y eliminación de defectos

Se puede usar un modelo de ampliación de defectos [IBM81] para ilustrar la generación y detección de errores durante los pasos de diseño preliminar, diseño detallado y codificación del proceso de ingeniería del software. En la figura A se ilustra esquemáticamente el modelo. Cada cuadro representa un paso en el desarrollo del software. Durante cada paso se pueden generar errores que pasan inadvertidos. La inspección puede fallar en descubrir nuevos errores y errores de pasos anteriores, produciendo un mayor número de errores que pasan inadvertidos. En algunos casos, los errores que pasan inadvertidos desde pasos anteriores se amplifican (factor de ampliación x) con el trabajo actual. Las subdivisiones de los cuadros representan cada una de éstas características y el porcentaje de eficiencia para la detección de errores, una función de la profundidad de la inspección.

Figura A (Para ver el gráfico faltante haga click en el menú superior "Bajar Trabajo")  La Figura B ilustra un ejemplo hipotético de la amplificación de defectos en un proceso de desarrollo de software en el que no se lleva a cabo inspecciones. En la Figura se asume que cada paso descubre y corrige el 50% de los errores que le llegan, sin introducir ningún error nuevo (una suposición muy optimista). Antes de que comience la prueba se han amplificado 10 errores del diseño preliminar a 94 errores. Al terminar quedan 12 errores latentes.

Figura B(Para ver el gráfico faltante haga click en el menú superior "Bajar Trabajo") 

La Figura C considera las mismas condiciones pero llevando a cabo inspecciones del diseño y de la codificación dentro de cada paso del desarrollo. En este caso los 10 errores del diseño preliminar se amplifican a 24 antes del comienzo de la prueba. Sólo quedan 3 errores latentes. Recordando los costos asociados con el descubrimiento y la corrección de errores, se puede establecer el costo total (con y sin inspecciones para nuestro ejemplo hipotético).

Figura C (Para ver el gráfico faltante haga click en el menú superior "Bajar Trabajo") De acuerdo a la Tabla 1, se puede ver que el costo total para el desarrollo y el mantenimiento cuando se realizan inspecciones es de 783 unidades. Cuando no hay inspecciones, el costo total es de 2.177 unidades; casi 3 veces mas caro.

Para llevar a cabo inspecciones, el equipo de desarrollo debe dedicar tiempo y esfuerzo, y la organización de desarrollo debe gastar dinero. Sin embargo, los resultados del ejemplo anterior no dejan duda de que hemos encontrado el síndrome de "pague ahora o, pague después mucho mas". Las inspecciones producen un beneficio en costo demostrable. Si se cuenta con los recursos, deben llevarse a cabo .

Tabla 1

Llevando a cabo inspecciones

Sin llevar a cabo Inspecciones

A partir de lo expuesto , podríamos resumir los beneficios comprobados al aplicar Inspecciones en :

• Reducción de los defectos en el uso del software
• Reducción de los recursos de desarrollo, sobre todo en las etapas de codificación y prueba
• Reducción en los costos de mantenimiento correctivo

4. El proceso de inspección.

Podemos ver a las inspecciones de software como un repaso detallado y formal del trabajo en proceso. Pequeños grupos de trabajadores (4 o 5) estudian el ""producto de trabajo"" independientemente y luego se reúnen para examinar el trabajo en detalle. El ""producto de trabajo"" representa 200 a 250 líneas de código, Requerimientos, diseño y otros productos de trabajo son inspeccionados en un tamaño similar. Los productos de trabajo son considerados en progreso hasta que la inspección y las correcciones necesarias estén completas.

El tiempo de la inspección varía según cuan familiarizado esté el inspector con el material. La inspección consiste en seis pasos [Fagan 1986] :

1. Planificación: Cuando el desarrollador completa su un ""producto de trabajo"", se forma un grupo de inspección y se designa un moderador. El moderador asegura que el ""producto de trabajo"" satisfaga el criterio de inspección. Se le asignan diferentes roles a las personas que integran el grupo de inspección, así como la planificación de tiempos y recursos necesarios .
2. Overview: Si los inspectores no están familiarizados con el desarrollo de l proyecto, un vista general es necesaria en éste momento. Este es un paso opcional, pero no menos importante ya que en esta etapa se dará al grupo de inspección un "background" y el contexto a cubrir por las inspecciones.
3. Preparación: Los inspectores se preparan individualmente para la evaluación en la reunión, estudiando los productos de trabajo y el material relacionado. Aquí es aconsejable la utilización de listas de chequeos para ayudar a encontrar defectos comunes, y . El tiempo que pueda llevar esta etapa va a depender de cuan familiarizado esté el inspector con el trabajo que debe analizar.
4. Examen: En esta etapa, los inspectores se reunen para analizar su trabajo individual en forma conjunta. El moderador deberá asegurarse que todos los inspectores están suficientemente preparados. La persona designada como lector presenta el "producto de trabajo", interpretando o parafraseando el texto, mientras que cada participante observa en busca de defectos. Es recomendable que este examen no dure mas de 2 horas ya que la atención en busca de defectos va disminuyendo con el tiempo. Al terminar con la reunión, el grupo determina si el producto es aceptado o debe ser retrabajado para una posterior inspección.
5. Retrabajo: El autor corrige todos los defectos encontrados por los inspectores.
6. Seguimiento: El moderador chequea las correcciones del autor. Si el moderador está satisfecho, la inspección está formalmente completa, y el "producto de trabajo" es puesto bajo el control de configuración.

A partir de estos seis pasos surge la necesidad de la conformación de: objetivos, participantes de la inspección y con que roles, productos de trabajo a inspeccionar y cual deberá ser el resultado de las reuniones de inspección.

• Objetivos: El principal objetivo es encontrar defectos en el "producto de trabajo", de esta manera debemos definir cuales serán las metas a alcanzar para el cumplimiento de éste objetivo. En nuestra opinión el establecimiento de éstas metas están en relación directa con el tipo de proyecto, metodologías y herramientas utilizados
• Grupos de inspección: Se recomienda formar grupos entre 3 y 6 personas [IEEE STD 1028-1988]. Dentro de éste grupo debe incluirse al autor de los productos de trabajo.
• Roles: Además del autor se deberá tener en cuenta al moderador quien dirige la inspección y deberá contar con mayor experiencia que el resto, el lector quien presenta los productos de trabajo en las reuniones y el escriba quien documenta la descripción y ubicación de los defectos encontrados.
• Productos de trabajo: El proceso de inspección puede ser aplicado a diferentes tipos de productos de trabajo que pueden encontrarse en un desarrollo de software incluyendo requerimientos, diseño, código, test, guías de usuario y otro tipo de documentación. El estándar de la IEEE no especifica un tamaño , pero los productos de trabajo tienen un tamaño de 10 a 20 hojas para especificación de requerimientos, 200 o 250 líneas de código. En nuestra opinión también se debe tener en cuenta la división natural que pueda tener cada uno de éstos documentos, ya que toda especificación podremos dividirla en partes así como el diseño o el código.
• Resultado de las reuniones de inspección: Los dos resultados principales debe ser: Una lista de defectos a corregir , y un reporte de inspección que describa que es lo que se inspeccionó, quien inspeccionó qué y el número de defectos encontrados.

Utilizando una notación UML (Lenguaje unificado de modelado, de Booch-Rumbaugh-Jacobson), describiremos gráficamente con un diagrama de actividades, y casos de uso el proceso de inspección.

Diagrama de actividades (Para ver el gráfico faltante haga click en el menú superior "Bajar Trabajo")

Modelo de casos de uso

Infraestructura de soporte

Además de los actores que identificamos en el diagrama anterior, debemos tener en cuenta un nuevo actor ya que las inspecciones no ocurren espontáneamente. Deben ser planeadas y soportadas por alguien, que tenga la responsabilidad de llevarlas adelante. Este nuevo actor es el llamado "coordinador de inspecciones de software" [Ackerman-Buchwald-Lewski]. Cuyas tareas incluyen:

• Aprender sobre inspecciones y convencer al proyecto de utilizarlas
• Determinar en qué parte del proyecto deben ser utilizadas
• Crear y documentar específicamente para cada proyecto los procedimientos de inspección así como los manuales de inspección
• Organizar entrenamientos en el proceso de inspección manteniendo la documentación y actualización de dicho entrenamiento
• Recolectar datos de inspecciones en los proyectos para una base de datos de inspecciones
• Analizar datos de inspecciones de distintos proyectos para hacer recomendaciones de mejoras en los procesos.

5. Métricas en inspecciones

El proceso de inspección puede ser medido para analizar distintos aspectos del proceso (planificación, monitoreo, control, mejora, etc.) y poder maximizar su eficacia así como corregir posibles desvíos que puedan producirse durante la inspección.

En nuestra opinión las mediciones deben llevarse a cabo para poder formar una base de datos con los distintos proyectos con el fin de utilizarla a la hora de planificar nuevas inspecciones. Tomando como base las métricas propuestas por Jack Barnard (AT&T Bell Laboratories) podemos utilizar los siguientes indicadores:

Total de líneas no comentadas del código fuente inspeccionado

Cuando hablamos de líneas de código a medir, siempre se tomarán en cuenta las líneas no comentadas. Sin embargo éste indicador nos dará una primera idea de la comprensibilidad del código (contrastándola con la cantidad total), el cual se deberá tener en cuenta para la planificación de posibles retrabajos y/o fase de mantenimiento.

Promedio de líneas de código inspeccionado

Este es un claro indicador del porcentaje de trabajo que hemos inspeccionado, y deberá analizarse teniendo en cuenta si éste porcentaje supera o no el porcentaje de código relacionado directamente con los requerimientos del software

Taza de preparación promedio

Con este indicador observaremos cuanto nos cuesta, en planificación y cantidad de inspecciones, la inspección de todo el código

Taza de inspección promedio

Este será un indicador claro de cuan complejo resulta la inspección del código, y por supuesto que si contáramos con valores de ésta métrica en proyectos similares, éste sería sin duda un valor a tener en cuenta a la hora de planificar y estimar los recursos necesarios

Promedio de esfuerzo por KLOC

Este promedio nos dará una idea del esfuerzo necesario de inspeccionar el tipo de código para el proyecto en cuestión

Promedio de esfuerzo por falla detectada

Este promedio nos indicará el esfuerzo invertido por cada falla que se detecte. Este indicador resulta interesante cuando debamos decidir si aplicar o no inspecciones en proyectos similares al inspeccionado.

Promedio de fallas detectadas por KLOC

Este es un indicador claro de la calidad del código

Porcentaje de reinspecciones

Se complementa con el Promedio de fallas detectadas por KLOC, para ver cuan graves fueron las fallas detectadas

Eficiencia en la remoción de defectos

Este indicador nos da el porcentaje de defectos producidos en la codificación, y nos servirá para determinar el estado del proceso de inspección

A nuestro entender creemos que además sería útil medir, la cantidad promedio de productos de trabajo inspeccionados por cada inspector , así como catalogar la complejidad de los productos de trabajo a inspeccionar, ya que éstos dos valores nos darían una visión mas clara sobre la productividad de la inspección y un parámetro importante a tener en cuenta para la planificación de futuras inspecciones .

Recomendaciones con respecto al equipo de inspección

No debemos descuidar la comunicación que debe existir entre los inspectores y el team de desarrollo. Debemos tener en cuenta aspectos como la forma en que se comunican los defectos que existan en el software, ya que por una reacción normal el autor del "producto de trabajo" éste intentará justificarlo y muchas veces esa justificación se desvía de su objetivo principal si el autor se siente "atacado" por el inspector.

Deberemos seleccionar cuidadosamente al grupo de inspección, éste deberá ser "respetado" por el team de desarrollo en cuanto a sus conocimientos profesionales y del proyecto ya que de no ser así esto será sin dudas una fuente de conflicto permanente.

6. Conclusiones

Definimos el marco en el que se aplican las inspecciones de software partiendo de la base de un desarrollo profesional del mismo en el cual lo principal será la calidad de éste, estableciendo como criterios de calidad : Correctitud y Completitud [Fre90] como los principales e imprescindibles.

De éste modo podemos afirmar que un software en el que se controle la calidad no puede dejar de lado un proceso de revisión formal del mismo, como podemos observarlo en las normas ISO o CMM del SEI, quizás con otro nombre pero contemplando los mismos objetivos.

El proceso de inspección debe ser llevado a cabo por personas que conozcan tanto del dominio específico, comprendiendo la SRS [DAV93], así como la tecnología aplicada a las soluciones que serán objeto de la inspección. A partir de éste background en el equipo de inspección, deberán respetarse las etapas planteadas precedentemente, creando las condiciones necesarias para maximizar la sinergia que se produzca sobre todo en la etapa de "examen".

Por ultimo si se decide incorporar inspecciones como parte del ciclo de vida del software a construir, no debe dejar de medirse el proceso para controlarlo e incorporarlo como feedback de los sucesivos proyectos.

7. Referencias bibliográficas

[BAR92] Managing code inspection information, Jack Barnard, ART Price AT&T Bell Laboratories, 1992 [WHE96]Software Inspection. An industry Best Practice, Wheeler, DA, Brykezyski, B, Meeson, RN, IEEE Computer Society Press, 1996 [JON86] Jones, T.C., Programming Productivity, McGraw-Hill, 1986 [IBM81] "Implementating Software Inspections", Notas del curso, IBM Systems Sciences Institute, IBM Corporation, 1981 [FRE90] Handbook of walkthroughs, Inspections and Technical Reviews, 3° edición, Freeman, D.P., Weimberg, G.M., Dorset House,1990 [DAV93] Software Requirements, Alan M. Davis, Prentice Hall, 1993 El Lenguaje Unificado de Modelado, G. Booch, J.Rumbaugh, I.Jacobson – Addison Wesley, 1999 Ingeniería de Software, un enfoque práctico 4° edición – Roger S.. Pressman – Mc Graw ,Hill, 1998

Autor:

Juan Manuel Luzuriaga