2. INSPECCIONES DE SOFTWARE 2.1 Introduccin 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 cdigo. Error! La garanta de la calidad del software es una actividad de proteccin que se aplica a lo largo de todo el proceso de ingeniera de software. El SQA (Software Quality Assurance) engloba: Un enfoque de gestin de calidad Tecnologa de Ingeniera de Software efectiva (mtodos y herramientas) Revisiones tcnicas formales que se aplican durante el proceso del software Una estrategia de prueba multiescalada Un control de la documentacin del software y de los cambios realizados Un procedimiento que asegure un ajuste a los estndares de desarrollo de software Mecanismos de medicin y de generacin de informes El control de la calidad es una serie de revisiones, y pruebas utilizadas a lo largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados. La garanta de calidad o aseguramiento de la calidad consiste en la auditoria y las funciones de informacin de la gestin. El objetivo de la garanta de la calidad es proporcionar la gestin para informar de los datos necesarios sobre la calidad del producto, por lo que se va adquiriendo una visin ms profunda y segura de que la calidad del producto est cumpliendo sus objetivos. Es de esperar, que si los datos proporcionados mediante la garanta de la calidad identifican problemas, la gestin afronte los problemas y aplique los recursos necesarios para resolverlos. La garanta de calidad del software comprende una gran variedad de tareas, asociadas con dos constitutivos diferentes: 1. Los ingenieros de software, que realizan trabajo tcnico, 2. Un grupo SQA, que tiene la responsabilidad de la planificacin de garanta de calidad. En este marco podemos ver a las inspecciones como una implementacin de las revisiones formales del software las cuales representan un filtro para el proceso de ingeniera de software, stas se aplican en varios momentos del desarrollo y sirven para detectar defectos que pueden as ser eliminados. Freeman y Weinberg argumentan de la siguiente forma la necesidad de revisiones: 1. El trabajo tcnico necesita ser revisado por la misma razn que los lpices necesitan gomas: errar es humano. 2. Aunque la gente es buena descubriendo algunos de sus propios errores, algunas clases de errores se le pasan mas fcilmente al que los origina que a otras personas. 3. El proceso de revisin es, por lo tanto la respuesta a la plegaria de Robert Burns: Que gran regalo sera poder vernos como nos ven los dems! Una revisin es una forma de aprovechar la diversidad de un grupo de personas para: 1. Sealar 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 a cabo como parte de la ingeniera del software. Cada una tiene su lugar: Una reunin informal durante el almuerzo o en un caf es una forma de revisin, si se discuten problemas tcnicos. Una presentacin formal de un diseo de software a una audiencia de clientes, ejecutivos y personal tcnico es una forma de revisin. 2.2 Impacto de los defectos del software en el costo Dentro del contexto de desarrollo de software, los trminos defecto y fallo son sinnimos. Ambos implican un problema de calidad descubierto despus de entregar el software a los usuarios finales. El objetivo primario de las revisiones tcnicas formales (inspeccin) es encontrar errores durante el proceso para evitar que se conviertan en defectos despus 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. Una serie de estudios indican que las actividades del diseo introducen entre el 50% y 65% de todos los errores (y en ltimo lugar, todos los defectos) durante el proceso de software. Sin embargo se ha demostrado que las inspecciones de software son efectivas en un 75% a la hora de detectar errores.

Con la deteccin y la eliminacin de un gran porcentaje de errores, el proceso de inspeccin reduce substancialmente el costo de los pasos siguientes en las fases de desarrollo y mantenimiento. 2.3 Amplificacin y eliminacin de defectos Se puede usar un modelo de ampliacin de defectos para ilustrar la generacin y deteccin de errores durante los pasos de diseo preliminar, diseo detallado y codificacin del proceso de ingeniera del software. En la figura A se ilustra esquemticamente el modelo. Cada cuadro representa un paso en el desarrollo del software. Durante cada paso se pueden generar errores que pasan inadvertidos. La inspeccin puede fallar en descubrir nuevos errores y errores de pasos anteriores, produciendo un mayor nmero de errores que pasan inadvertidos. En algunos casos, los errores que pasan inadvertidos desde pasos anteriores se amplifican (factor de ampliacin x) con el trabajo actual. Las subdivisiones de los cuadros representan cada una de stas caractersticas y el porcentaje de eficiencia para la deteccin de errores, una funcin de la profundidad de la inspeccin.

Paso de desarrollo Defectos Errores de pasos anteriores

Errores inadvertidos Errores amplificados 1:x Errores nuevamente generados

Deteccin
Porcentaje de la eficiencia de la deteccin de errores

Errores pasados al siguiente paso

Figura A La Figura B ilustra un ejemplo hipottico de la amplificacin 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 ningn error nuevo (una suposicin muy optimista). Antes de que comience la prueba se han amplificado 10 errores del diseo preliminar a 94 errores. Al terminar quedan 12 errores latentes.
Diseo preliminar
0 0 10 0%

Diseo detallado 10 6 4
6 4 x 1,5 ; (x=1,5) 25 0%

Codificacin /prueba Uni. 37

10 27 x 3 ; (x=3) 25 20%

94
Prueba de integracin

94

0 0

50%

Prueba de validacin 47
0 0 50%

Para la integracin

Prueba del sistema. 24

0 0 50%

12

Errores latentes

Figura B La Figura C considera las mismas condiciones pero llevando a cabo inspecciones del diseo y de la codificacin dentro de cada paso del desarrollo. En este caso los 10 errores del diseo preliminar se amplifican a 24 antes del

comienzo de la prueba. Slo quedan 3 errores latentes. Recordando los costos asociados con el descubrimiento y la correccin de errores, se puede establecer el costo total (con y sin inspecciones para nuestro ejemplo hipottico).
Diseo preliminar
0 0 10 70%

Diseo detallado 3 2 1
2 1 1,5 25 50%

Codificacin /prueba Uni. 15 5 10

5 10 -3 25 60%

24
Prueba de integracin

24

0 0

50%

Prueba de validacin 12
0 0 50%

Para la integracin

Prueba del sistema. 6

0 0 50%

Errores latentes

Figura C Para ilustrar el impacto sobre el costo de la deteccin anticipada de errores, consideremos una serie de costos relativos que se basan en datos de costos realmente recogidos en grandes proyectos de software. Supongamos que un error descubierto durante el diseo cuesta corregirlo 1.5 unidades. 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 despus de la entrega, entre 60 y 100 unidades. De acuerdo a la siguiente tabla, 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 organizacin de desarrollo debe gastar dinero. Sin embargo, los resultados del ejemplo anterior no dejan duda de que hemos encontrado el sndrome de pague ahora o, pague despus mucho mas. Las inspecciones producen un beneficio en costo demostrable. Si se cuenta con los recursos, deben llevarse a cabo . Llevando a cabo inspecciones Nmero Costo unitario 22 1.5 36 6.5 15 15.0 3 67.0

Errores encontrados Durante el diseo Antes de la prueba Durante la prueba Despus de la entrega Total

Total 33 234 315 201 783

Errores encontrados Antes de la prueba Durante la prueba Despus de la entrega Total

Sin llevar a cabo Inspecciones Nmero Costo unitario 22 6.5 82 15.0 12 67.0

Total 143 1230 804 2177

A partir de lo expuesto, podramos resumir los beneficios comprobados al aplicar Inspecciones en :

Reduccin de los defectos en el uso del software Reduccin de los recursos de desarrollo, sobre todo en las etapas de codificacin y prueba Reduccin en los costos de mantenimiento correctivo

2.4 El proceso de inspeccin La inspeccin desarrollada por Fagan en 1972 consiste en seis pasos: 1. Planificacin: Cuando el desarrollador completa un producto de trabajo, se forma un grupo de inspeccin y se designa un moderador. El moderador asegura que el producto de trabajo satisfaga el criterio de inspeccin. Se le asignan diferentes roles a las personas que integran el grupo de inspeccin, as como la planificacin de tiempos y recursos necesarios. 2. Overview: Si los inspectores no estn familiarizados con el desarrollo del proyecto, una 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 inspeccin un background y el contexto a cubrir por las inspecciones. 3. Preparacin: Los inspectores se preparan individualmente para la evaluacin en la reunin, estudiando los productos de trabajo y el material relacionado. Aqu es aconsejable la utilizacin de listas de chequeos para ayudar a encontrar defectos comunes. 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 renen para analizar su trabajo individual en forma conjunta. El moderador deber asegurarse que todos los inspectores estn 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 atencin en busca de defectos va disminuyendo con el tiempo. Al terminar con la reunin, el grupo determina si el producto es aceptado o debe ser retrabajado para una posterior inspeccin. 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 inspeccin est formalmente completa, y el producto de trabajo es puesto bajo el control de configuracin. A partir de estos seis pasos surge la necesidad de la conformacin de: objetivos, participantes de la inspeccin y con que roles, productos de trabajo a inspeccionar y cual deber ser el resultado de las reuniones de inspeccin. Objetivos: El principal objetivo es encontrar defectos en el producto de trabajo, de esta manera debemos definir cuales sern las metas a alcanzar para el cumplimiento de ste objetivo. En nuestra opinin el establecimiento de estas metas estn en relacin directa con el tipo de proyecto, metodologas y herramientas utilizados Grupos de inspeccin: 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: Adems del autor se deber tener en cuenta al moderador quien dirige la inspeccin y deber contar con mayor experiencia que el resto, el lector quien presenta los productos de trabajo en las reuniones y quien documenta la descripcin y ubicacin de los defectos encontrados. Productos de trabajo: El proceso de inspeccin puede ser aplicado a diferentes tipos de productos de trabajo que pueden encontrarse en un desarrollo de software incluyendo requerimientos, diseo, cdigo, test, guas de usuario y otro tipo de documentacin. El estndar de la IEEE no especifica un tamao, pero los productos de trabajo tienen un tamao de 10 a 20 hojas para especificacin de requerimientos, 200 o 250 lneas de cdigo. En nuestra opinin tambin se debe tener en cuenta la divisin natural que pueda tener cada uno de stos documentos, ya que toda especificacin podremos dividirla en partes as como el diseo o el cdigo. Resultado de las reuniones de inspeccin: Los dos resultados principales deben ser: Una lista de defectos a corregir, y un reporte de inspeccin que describa que es lo que se inspeccion, quien inspeccion qu y el nmero de defectos encontrados. Las tareas del coordinador de inspecciones de software incluyen: Aprender sobre inspecciones y convencer al proyecto de utilizarlas Determinar en qu parte del proyecto deben ser utilizadas Crear y documentar especficamente para cada proyecto los procedimientos de inspeccin as como los manuales de inspeccin Organizar entrenamientos en el proceso de inspeccin manteniendo la documentacin y actualizacin 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.