unidad 2: tecnicas de revision

UNIDAD 2: TECNICAS DE REVISION ING. ALEJANDRA COLINA VARGAS MSC.

SEPTIEMBRE, 2015

UNIDAD 2: TECNICAS DE REVISION

◦ Efecto de los defectos del software en el costo

◦ Amplificación y eliminación del defecto

◦ Métricas de revisión y su empleo

◦ Revisiones: espectro de formalidad

◦ Revisiones informales

◦ Revisiones técnicas formales

Las revisiones del software son un “filtro” para el proceso del software.


Sirven para descubrir errores y defectos a fin de poder eliminarlos. “Purifican” los productos, modelos de requerimientos y diseño, código y datos de prueba.

Una REVISION es una forma de utilizar la diversidad de un grupo para lo siguiente: 1. Resaltar las mejoras necesarias en el producto que elaboró una sola persona o equipo; 2. Confirme aquellas partes de un producto en las que no se desea o no se necesita hacer una mejora; 3. Realice el trabajo técnico de calidad más uniforme, o al menos más predecible, que pueda lograrse sin hacer revisiones, a fin de que el trabajo técnico sea más manejable.


¿Qué es?

¿Quién lo

hace?

¿Por qué es

importante?

¿Cuáles son los pasos?

¿Cuál es el

producto final?

¿Cómo lo hice bien?

Mecanismo para detectar los errores en una etapa temprana del proceso de software.

Ingenieros de software

Errores al principio del proceso menos caro corregirlo

Seis pasos: planeación, preparación, estructurar la reunión, resaltar los errores, hacer las correcciones y verificaciones

Lista de errores

Seguir los lineamientos. Si conducen a un software de alta calidad, lo habrá hecho bien.

Revisiones del software

Utilice:

Métricas para determinar cuáles son las revisiones que funcionan y haga énfasis en ellas

Elimine del flujo las revisiones ineficaces, con objeto de acelerar el proceso.

IMPORTANTE.


DEFECTO = FALLA ???

Los dos implican un problema de calidad

Error denota un problema de calidad descubierto por ingenieros de software antes de entregar el software al usuario final.

Objetivo: encontrar errores durante el proceso a fin de que no se conviertan en defectos después de liberar el software.

Beneficio: el descubrimiento temprano de los errores, de modo que no se propaguen a la siguiente etapa del proceso del software.

UNIDAD 2: TECNICAS DE REVISION Efecto de los defectos del software en el costo

Modelo de amplificación del defecto.

UNIDAD 2: TECNICAS DE REVISION Amplificación y eliminación del defecto

Los errores surgen de manera inadvertida. La revisión puede fracasar en etapas anteriores, originando errores pasados por alto.


Ejemplo: Tenemos un software cuyos procesos no se hacen revisiones.

¿Qué pasa con los defectos o errores?

Escenario 1.

Se supone que en cada etapa de prueba se detecta y corrige 50 por ciento de todos los errores de entrada sin que se introduzcan nuevos errores (suposición optimista).

Diez defectos preliminares de diseño se amplifican a 94 errores antes de que comiencen las pruebas.

Se liberan al campo 12 errores latentes (defectos).


Escenario 2.

Se mantienen las mismas condiciones, excepto que se efectúan revisiones del diseño y código como parte de cada acción de la ingeniería de software.

En este caso, son 10 los errores, las condiciones iniciales de diseño preliminar (arquitectura) que se amplifican a 24 antes de comenzar las pruebas. Sólo existen tres errores latentes.



Pueden establecerse los costos relativos asociados con el descubrimiento y corrección de errores, así como el costo general (con y sin revisión para nuestro ejemplo hipotético).

Por ejemplo, como dicen los médicos es más fáciles de curar en sus inicios aunque difícil de reconocer, pero en el transcurso del tiempo, cuando no han sido reconocidos a primera vista y tratadas, se vuelven fáciles de reconocer pero difícil de curar.

“Debe dedicarse tiempo y esfuerzo a la realización de revisiones y su organización de desarrollo debe destinar el dinero para ello.”

UNIDAD 2: TECNICAS DE REVISION Métricas de revisión y su empleo

Las revisiones técnicas son una de las muchas acciones que se requieren como parte de las buenas prácticas de la ingeniería de software.

Cada acción requiere un esfuerzo humano dirigido.

Como el esfuerzo disponible para el proyecto es finito, es importante que una organización de software comprenda la eficacia de cada acción, definiendo un conjunto de métricas que puedan utilizarse para evaluar esa eficacia.


DIRECTAS INDIRECTAS INDICADORES

Métricas de revisión y su empleo

𝑬𝑷 Esfuerzo de preparación: Revisión de un producto del trabajo antes de la reunión de revisión real. Esfuerzo de evaluación: Se dedica a la revisión real. Esfuerzo de la repetición: Corrección de los errores descubiertos durante la revisión. Tamaño del producto del trabajo: medición del tamaño del producto del trabajo que se ha revisado Errores menores detectados: número de errores detectados que pueden clasificarse como menores Errores mayores detectados: número de errores encontrados que pueden clasificarse como mayores .

(en horas-hombre)

𝑬𝒂

𝑬𝒓

TPT

𝑬𝒓𝒓𝒎𝒆𝒏𝒐𝒓𝒆𝒔

𝑬𝒓𝒓𝒎𝒂𝒚𝒐𝒓𝒆𝒔



Análisis de las métricas

Antes de comenzar el análisis deben hacerse algunos cálculos sencillos. El esfuerzo total de revisión y el número total de errores descubiertos se definen como sigue:

Erevisión Ep Ea Er Errtot Errmenores Errmayores

La densidad del error representa los errores encontrados por unidad de producto del trabajo revisada.

Análisis de las métricas

𝑬𝑷 𝑬𝒂 𝑬𝒓

𝑬𝒓𝒓𝒕𝒐𝒕 𝑬𝒓𝒓𝒎𝒂𝒚𝒐𝒓𝒆𝒔

= 𝑬𝒓𝒆𝒗𝒊𝒔𝒊𝒐𝒏 + +

𝑬𝒓𝒓𝒎𝒆𝒏𝒐𝒓𝒆𝒔 = +

La densidad del error representa los errores encontrados por unidad de producto del trabajo revisada.

𝐃𝐞𝐧𝐬𝐢𝐝𝐚𝐝 𝐝𝐞𝐥 𝐞𝐫𝐫𝐨𝐫 =Errtot

TPT


Eficiencia del costo de las revisiones

Se puede evaluar la eficacia de las revisiones y su relación costo-beneficio sólo después de que éstas han terminado, de que las unidades de medida de la revisión se han recabado, de que los datos promedio han sido calculados y de que la calidad posterior del software ha sido medida (mediante pruebas)

Esfuerzo ahorrado por error = Epruebas − Erevisiones



Las revisiones técnicas deben aplicarse con un nivel de formalidad apropiado para el producto que se va a elaborar, para el plazo que tiene el proyecto y para el personal que realice el trabajo.

Hay suficiente cantidad de planeación y preparación

para la revisión

Se definen explícitamente roles distintos para los

revisores

Se define una estructura distinta para la revisión

(incluso tareas y productos internos del

trabajo)

El seguimiento por parte de los revisores tiene

lugar para cualesquiera correcciones que se

efectúen.

REVISIONES: ESPECTRO DE FORMALIDAD

Modelo de referencia para hacer revisiones técnicas


Espectro de formalidades



Evaluación estructurada: 1. Distribución 2. Estética, 3. Opciones de

navegación.

REVISIONES: ESPECTRO DE FORMALIDAD

ENFOQUE CASUAL

Examinen el prototipo de la interfaz


un rol específico: dirigir el equipo, registrar las reuniones, presentar el material, etc.

Cada revisor tendrá acceso al producto del trabajo (en este caso, el prototipo de la interfaz) antes de que la revisión tenga lugar y dedicará tiempo a la búsqueda de errores, inconsistencias y omisiones.

Se realizará un conjunto de tareas específicas con base en una agenda que se desarrollará antes de que ocurra la revisión.

Los resultados de ésta serán registrados de manera formal y el equipo decidirá sobre el estado del producto del trabajo con base en el resultado de la revisión. Los miembros del equipo también verificarán que las correcciones se hagan de manera adecuada.

Tareas especificas de la Revisión

Revisiones informales y Revisiones formales.

Revisiones Informales

Una verificación de escritorio simple o una reunión casual realizada con un colega constituye una revisión. Sin embargo, como no hay una planeación o preparación por adelantado, ni agenda o estructura de la reunión, y no se da seguimiento a los errores descubiertos, la eficacia de tales revisiones es mucho menor que la de los enfoques más formales.


Revisiones técnicas formales

Es una actividad del control de calidad del software realizada por ingenieros de software (y otras personas).

1) Descubrir los errores en funcionamiento, lógica o implementación

2) Verificar que el software que se revisa cumple sus requerimientos;

3) Garantizar que el software está representado de acuerdo con estándares predefinidos;

4) Obtener software desarrollado de manera uniforme

5) Hacer proyectos mas manejables


Revisiones Técnicas Formales

• Deben involucrarse de tres a cinco personas

• Preparación previa, pero no más de dos horas de trabajo

• Debe ser de al menos dos horas

• Centra en una parte específica (y pequeña) del software general.

Reunión de Revisión

• Se produce la lista de pendientes de la revisión

• Elabora un reporte técnico formal de la revisión

• El reporte de la revisión es una sola página (quizá con anexos)

• Identificar las áreas de problemas en el producto

Reporte y Registro de la revisión


REVISIONES TÉCNICAS FORMALES

• Revise el producto, no al productor

• Establezca una agenda y sígala.

• Limite el debate y las contestaciones.

• Enuncie áreas de problemas, pero no intente resolver cada uno.

• Tome notas por escrito

• Limite el número de participantes e insista en la preparación previa

• Desarrolle una lista de verificación para cada producto que sea probable que se revise

• Asigne recursos y programe tiempo para las RTF

• Dé una capacitación significativa a todos los revisores

• Revise las primeras revisiones

Lineamientos para la revisión


En Resumen

El objetivo de toda revisión técnica es detectar errores y descubrir aspectos que tendrían un efecto negativo en el software que se va a desarrollar.

Entre más pronto se descubra y corrija un error, menos probable es que se propague a otros productos del trabajo de la ingeniería de software y que se amplifique, lo que provocaría un mayor esfuerzo para corregirlo.


unidad 2: tecnicas de revision

Documents