Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Introduccin
2. Impacto de los defectos del software en el costo
3. Amplificacin y eliminacin de defectos
4. El proceso de inspeccin.
5. Mtricas en inspecciones
6. Conclusiones
7. Referencias bibliogrficas
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. La SQA (Software Quality Assurance) engloba:
software
software
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 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: los ingenieros de software, que realizan trabajo tcnico, y un
grupo SQA, que tiene la responsabilidad de la planificacin de garanta de calidad.
En ste 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 [Fre90] argumentan de la siguiente
forma la necesidad de revisiones:
El trabajo tcnico necesita ser revisado por la misma razn que los lpices necesitan gomas:
errar es humano. La segunda razn por la que necesitamos revisiones tcnicas es que,
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. 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 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
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
(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. Si embargo se ha demostrado que
las inspecciones de software son efectivas en un 75% a la hora de detectar errores [JON86].
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.
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 [IBM81]. Supongamos que un error descubierto durante el
diseo 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 despus de la entrega, entre 60 y 100 unidades.
3. Amplificacin y eliminacin de defectos
Se puede usar un modelo de ampliacin de defectos [IBM81] 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.
Figura A
(Para ver el grfico faltante haga click en el men superior "Bajar Trabajo")
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.
Figura B
(Para ver el grfico faltante haga click en el men superior "Bajar Trabajo")
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).
Figura C
(Para ver el grfico faltante haga click en el men superior "Bajar Trabajo")
Nmero
Costo unitario
Total
Durante el diseo
22
1.5 33
Antes de la prueba
36
6.5
234
Durante la prueba
15
15.0
315
67.0
201
Despus de la entrega
Total
783
Sin llevar a cabo Inspecciones
Errores encontrados
Nmero
Costo unitario
Total
Antes de la prueba
22
6.5
143
Durante la prueba
82
15.0
1230
Despus de la entrega
12
67.0
804
Total
2177
4. El proceso de inspeccin.
Podemos ver a las inspecciones de software como un repaso detallado y formal del trabajo
en proceso. Pequeos grupos de trabajadores (4 o 5) estudian el ""producto de trabajo""
independientemente y luego se renen para examinar el trabajo en detalle. El ""producto de
trabajo"" representa 200 a 250 lneas de cdigo, Requerimientos, diseo y otros productos
de trabajo son inspeccionados en un tamao similar. Los productos de trabajo son
considerados en progreso hasta que la inspeccin y las correcciones necesarias estn
completas.
El tiempo de la inspeccin vara segn cuan familiarizado est el inspector con el material.
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 reunen 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.
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.
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.
Utilizando una notacin UML (Lenguaje unificado de modelado, de Booch-RumbaughJacobson), describiremos grficamente con un diagrama de actividades, y casos de uso el
proceso de inspeccin.
Diagrama de actividades
(Para ver el grfico faltante haga click en el men superior "Bajar Trabajo")
Modelo de casos de uso
Infraestructura de soporte
Adems de los actores que identificamos en el diagrama anterior, debemos tener en cuenta
un nuevo actor ya que las inspecciones no ocurren espontneamente. 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:
5. Mtricas en inspecciones
El proceso de inspeccin puede ser medido para analizar distintos aspectos del proceso
(planificacin, monitoreo, control, mejora, etc.) y poder maximizar su eficacia as como
corregir posibles desvos que puedan producirse durante la inspeccin.
En nuestra opinin 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 mtricas propuestas por Jack Barnard (AT&T Bell
Laboratories) podemos utilizar los siguientes indicadores:
Total de lneas no comentadas del cdigo fuente inspeccionado
Cuando hablamos de lneas de cdigo a medir, siempre se tomarn en cuenta las lneas no
comentadas. Sin embargo ste indicador nos dar una primera idea de la comprensibilidad
del cdigo (contrastndola con la cantidad total), el cual se deber tener en cuenta para la
planificacin de posibles retrabajos y/o fase de mantenimiento.
Promedio de lneas de cdigo 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 cdigo
relacionado directamente con los requerimientos del software
Taza de preparacin promedio
Este ser un indicador claro de cuan complejo resulta la inspeccin del cdigo, y por
supuesto que si contramos con valores de sta mtrica en proyectos similares, ste sera
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 cdigo
para el proyecto en cuestin
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
Se complementa con el Promedio de fallas detectadas por KLOC, para ver cuan graves
fueron las fallas detectadas
Eficiencia en la remocin de defectos
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 bibliogrficas
[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 edicin,
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
Ingeniera de Software, un enfoque prctico 4 edicin Roger S.. Pressman Mc Graw
,Hill, 1998
Autor:
Juan Manuel Luzuriaga
Leer ms: http://www.monografias.com/trabajos6/isof/isof.shtml#ixzz3iNeTJMJe