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