REVISIONES DEL SOFTWARE

SISTEMAS DE INFORMACION

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 La 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 utilizados a los largo del ciclo de desarrollo para asegurar que cada producto cumple con los requisitos que le han sido asignados.

Una revisin es una forma de aprovechar la diversidad de un grupo de personas para: Sealar la necesidad de mejoras en el producto de una sola persona o de un equipo Confirmar las partes del producto en las que no es necesaria o no es deseable una mejora. 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 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. Sin embargo en ste trabajo nos concentraremos en una revisin tcnica formal, que llamaremos Inspeccin de Software

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 (catarata de errores de Mizuno). Una serie de estudios (TRW, Nippon Electric y Mitre Corp., entre otros) 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 [JON86].

La inspeccin consiste en seis pasos [Fagan 1986] : 1-Planificacin: Cuando el desarrollador completa su 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 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 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, 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 reune 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 stas 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 el escriba 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 debe 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.

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 revisin formal del mismo, como podemos observarlo en las normas ISO o CMM del SEI, quizs con otro nombre pero contemplando los mismos objetivos. El proceso de inspeccin debe ser llevado a cabo por personas que conozcan tanto del dominio especfico, comprendiendo la SRS [DAV93], as como la tecnologa aplicada a las soluciones que sern objeto de la inspeccin. A partir de ste background en el equipo de inspeccin, debern 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.