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 e! que se "a generado el c#digo$ % Error % &a garant'a de la calidad del software es una acti idad de protecci#n que se aplica a lo largo de todo el proceso de ingenier'a de software &a S(A )Software (ualit* Assurance+ engloba, -.n enfoque de gesti#n de calidad -Tecnolog'a de Ingenier'a de Software efecti a )/0todos * "erra/ientas+ -Re isiones t0cnicas for/ales que se aplican durante el proceso del software -.na estrategia de prueba /ultiescalada -.n control de la docu/entaci#n del software * de los ca/bios reali!ados -.n procedi/iento que asegure un a1uste a los est2ndares de desarrollo de software -Mecanis/os de /edici#n * de generaci#n de infor/es El control de la calidad es una serie de re isiones3 * pruebas utili!ados a los largo del ciclo de desarrollo para asegurar que cada producto cu/ple con los requisitos que le "an sido asignados$

.na re isi#n es una for/a de apro ec"ar la di ersidad de un grupo de personas para, -Se4alar la necesidad de /e1oras en el producto de una sola persona o de un equipo -Confir/ar las partes del producto en las que no es necesaria o no es deseable una /e1ora$ -Conseguir un traba1o de /a*or calidad /a5i/i!ando los criterios de Correctitud * Co/pletitud principal/ente $ E5isten /uc"os tipos diferentes de re isiones que se pueden lle ar adelante co/o parte de la ingenier'a del software$ Cada una tiene su lugar$ .na reuni#n infor/al durante el al/uer!o o en un caf0 es una for/a de re isi#n3 si se discuten proble/as t0cnicos$ .na presentaci#n for/al de un dise4o de software a una audiencia de clientes3 e1ecuti os * personal t0cnico es una for/a de re isi#n$ Sin e/bargo en 0ste traba1o nos concentrare/os en una re isi#n t0cnica for/al3 que lla/are/os Inspecci#n de Software

Impacto de los defectos del software en el costo

Dentro del contexto de desarrollo de software, los t rminos "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 !ue se conviertan en defectos despus de la entrega del software. El beneficio obvio de estas inspecciones es el descubrimiento de errores al principio para !ue no se propaguen al paso siguiente del proceso de desarrollo del software (catarata de errores de "i#uno . $na serie de estudios (%&', (ippon Electric y "itre )orp., entre otros indican !ue las actividades del dise o introducen entre el *+, y -*, de todos los errores(y en ltimo lugar, todos los defectos durante el proceso de software. .in embargo se /a demostrado !ue las inspecciones de software son efectivas en un 0*, a la /ora de detectar errores 123(4-5.

La inspeccin consiste en seis pasos Fa!an "#$%& ' 678lanificacin9 )uando el desarrollador completa su un ""producto de trabajo"", se forma un grupo de inspecci n y se designa un moderador. El moderador asegura !ue el ""producto de trabajo"" satisfaga el criterio de inspecci n. .e le asignan diferentes roles a las personas !ue integran el grupo de inspeccin, as como la planificacin de tiempos y recursos necesarios . :73verview9 .i los inspectores no estn familiari#ados con el desarrollo de l proyecto, un vista general es necesaria en ste momento. Este es un paso opcional, pero no menos importante ya !ue en esta etapa se dar al grupo de inspeccin un "bac;ground" y el contexto a cubrir por las inspecciones. <78reparacin9 Los inspectores se preparan individualmente para la evaluacin en la reunin, estudiando los productos de trabajo y el material relacionado. A!u es aconsejable la utili#acin de listas de c/e!ueos para ayudar a encontrar defectos comunes, y . El tiempo !ue pueda llevar esta etapa va a depender de cuan familiari#ado est el inspector con el trabajo !ue debe anali#ar. =7Examen9 En esta etapa, los inspectores se reune para anali#ar su trabajo individual en forma conjunta. El moderador deber asegurarse !ue todos los inspectores estn suficientemente preparados. La persona designada como lector presenta el "producto de trabajo", interpretando o parafraseando el texto, mientras !ue cada participante observa en busca de defectos. Es recomendable !ue este examen no dure mas de : /oras ya !ue 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 inspecci n. *7&etrabajo9 El autor corrige todos los defectos encontrados por los inspectores. -7.eguimiento9 El moderador c/e!uea las correcciones del autor. .i el moderador est satisfec/o, la inspeccin 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 confor/aci n de, ob1eti os participantes de la inspeccin * con que roles3 productos de traba1o a inspeccionar * cual deber ser el resultado de las reuniones de inspecci n$ -Ob1eti os, El principal ob1eti o es encontrar defectos en el 6producto de traba1o63 de esta /anera debe/os definir cuales sern las /etas a alcan!ar para el cu/pli/iento de ste ob1eti o$ En nuestra opinin el estableci/iento de stas /etas estn en relacin directa con el tipo de pro*ecto3 /etodolog as * "erra/ientas utili!ados -7rupos de inspeccin, Se reco/ienda for/ar grupos entre 8 * 9 personas :IEEE STD ;<=>?;@>>A$ Dentro de ste grupo debe incluirse al autor de los productos de traba1o$ -Roles, Ade/s del autor se deber tener en cuenta al /oderador quien dirige la inspecci n * deber contar con /a*or e5periencia que el resto3 el lector quien presenta los productos de traba1o en las reuniones * el escriba quien docu/enta la descripcin * ubicacin de los defectos encontrados$ -Broductos de traba1o, El proceso de inspecci n puede ser aplicado a diferentes tipos de productos de traba1o que pueden encontrarse en un desarrollo de software inclu*endo requeri/ientos3 dise o3 cdigo3 test3 guas de usuario * otro tipo de docu/entacin$ El estndar de la IEEE no especifica un ta/ao 3 pero los productos de traba1o tienen un ta/ao de ;< a =< "o1as para especificacin de requeri/ientos3 =<< o =C< lneas de cdigo$ En nuestra opinin ta/bin se debe tener en cuenta la di isin natural que pueda tener cada uno de stos docu/entos *a que toda especificacin podre/os di idirla en partes as co/o el diseo o el cdigo$ -Resultado de las reuniones de inspecci n, &os dos resultados principales debe ser, .na lista de defectos a corregir 3 * un reporte de inspeccin que describa que es lo que se inspeccion 3 quien inspeccion qu * el n/ero de defectos encontrados$

(onclusiones
Definimos el marco en el !ue 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 9 )orrectitud y )ompletitud 1>re?+5 como los principales e imprescindibles. De ste modo podemos afirmar !ue un software en el !ue se controle la calidad no puede dejar de lado un proceso de revisin formal del mismo, como podemos observarlo en las normas @.3 o )"" del .E@, !ui#s con otro nombre pero contemplando los mismos objetivos. El proceso de inspeccin debe ser llevado a cabo por personas !ue cono#can tanto del dominio especfico, comprendiendo la .&. 1DAA?<5, as como la tecnologa aplicada a las soluciones !ue sern objeto de la inspeccin. A partir de ste bac;ground en el e!uipo de inspeccin, debern respetarse las etapas planteadas precedentemente, creando las condiciones necesarias para maximi#ar la sinergia !ue se produ#ca sobre todo en la etapa de "examen". 8or 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 feedbac; de los sucesivos proyectos.