Verificación y Validación del Software Unidad 2. Revisiones del Software (Parte 1)

Presentación del tema: "Verificación y Validación del Software Unidad 2. Revisiones del Software (Parte 1)"— Transcripción de la presentación:

1 Verificación y Validación del Software Unidad 2. Revisiones del Software (Parte 1)

2 Revisiones del Software2 Unidad 2: Revisiones del Software 1. Definición y características de las revisiones del software 2. Tipos de revisiones de software 3. Estándar IEEE-1028 "Standard for Software Reviews“ 4. El proceso de cada uno de los principales tipos de revisión: inspecciones, recorridos y revisiones personales 5. Revisión de los principales productos de trabajo: plan del proyecto, requerimientos, diseño, código 6. Formatos propuestos para la documentación de las revisiones de software

3 Revisiones del Software3 Revisiones de software, ¿qué son? ► Son parte del proceso de verificación del software. ► Las revisiones o inspecciones de software, son un proceso de V&V estático en el que un sistema software se revisa para encontrar errores, omisiones y anomalías.  Generalmente se centran en el código fuente, pero pueden aplicarse a cualquier producto del proceso de desarrollo. ► Son un filtro para el proceso de software.

4 Revisiones del Software4 Revisiones de software, ¿qué son? ► En los procesos de manufactura tradicional, las inspecciones por especialistas en aseguramiento de la calidad es una práctica aceptada, y común. ► Estas inspecciones toman lugar en puntos específicos de la línea de ensamblaje, y son usadas para asegurar que las partes y los ensamblajes están correctamente construidos acorde a las especificaciones. ► La forma más común de inspección sigue siendo una persona haciendo un juicio basado en su experiencia.

5 Revisiones del Software5 Revisiones de software, ¿qué son? ► Las inspecciones son usadas para asegurar la calidad durante el proceso de desarrollo, no sólo en la fase de implementación. ► Si una organización mantiene registros de los resultados de las inspecciones y de todos los otros métodos de identificación de defectos, podrá detectar el porcentaje promedio de errores localizados, y entonces indicar cuándo un producto está listo para pasar a la siguiente etapa del proceso de desarrollo.

6 Revisiones del Software6 Revisiones de software, ¿qué son? ► Las revisiones de software pueden ser muy variadas,  desde revisiones informales, como una reunión informal alrededor de una máquina de café donde se discuten aspectos técnicos de algún producto del proceso,  hasta revisiones formales, como una presentación formal del diseño del software ante un auditorio de clientes, gestores y personal técnico.

7 Revisiones del Software7 Revisiones de Software: Ventajas ► Ventaja 1  Durante las pruebas, los errores pueden ocultar otros errores. ► Cuando se descubre un error, nunca se puede estar seguro de si otras anomalías de salida son debidas a un nuevo error o son efectos secundarios del error original.  Debido a que la inspección es un proceso estático, no hay que preocuparse de las interacciones entre errores. ► Una única sesión de inspección puede descubrir muchos errores en un sistema

8 Revisiones del Software8 Revisiones de Software: Ventajas ► Ventaja 2  Pueden inspeccionarse versiones incompletas de un sistema sin costos adicionales. ► Si un programa está incompleto, entonces se necesita desarrollar software de soporte especializado para las pruebas a fin de probar aquellas partes que están disponibles.

9 Revisiones del Software9 Revisiones de Software: Ventajas ► Ventaja 3  Además de buscar los defectos en el programa, una inspección también puede considerar atributos de calidad más amplios de un programa, tales como grado de cumplimiento con los estándares, portabilidad y mantenibilidad. ► Puede buscarse ineficiencias, algoritmos no adecuados y estilos de programación que podrían hacer que el sistema fuese difícil de mantener y actualizar.

10 Revisiones del Software10 Algunos problemas ► Problema 1.  Uno de los mayores daños en las inspecciones, es la inhabilidad de los productores y los inspectores de diferenciar un producto de la persona que lo creo. ► Cuando un producto particular tiene muchos errores, los inspectores en ocasiones pueden ensañarse atacando al productor. ► Se debe mantener la inspección centrada en el producto, así como un tono profesional durante las reuniones de inspección.

11 Revisiones del Software11 Algunos problemas ► Problema 2.  Tratar de usar inspecciones sin programar el tiempo adecuado para su preparación y seguimiento. ► Una preparación insuficiente reduce el número de líneas o elementos que pueden ser inspeccionados en una reunión particular, dado que el tiempo se consume en tratar de entender el producto. ► Un seguimiento insuficiente puede causar que los defectos se mantengan. Defectos que podrían no ser encontrados en pruebas posteriores.

12 ¿Qué se busca? La reducción de defectos, fallas, errores, etc. en el sistema de software.

13 “Algunas enfermedades, dicen los médicos, son fáciles de curar en sus inicios aunque difíciles de reconocer… pero en el transcurso del tiempo, cuando no han sido reconocidas a primera vista y tratadas, se vuelven fáciles de reconocer pero difíciles de curar” Nicolás Maquiavelo

14 Revisiones del Software14 Problemas de calidad del software ► La meta del aseguramiento de la calidad, es eliminar los problemas en el software, los cuales pueden tener distintos nombres como bugs, fallas, errores, defectos, etc. ► Es importante definir a qué nos referimos con cada cosa, por ejemplo:  Error: ► es un problema descubierto antes de que el software sea liberado entre usuarios finales.  Defecto: ► es un problema detectado sólo después de que el software ha sido liberado entre los usuarios finales.  La diferencia también podría estar entre si el problema se detecta en la misma fase del proceso donde se generó, o en una fase posterior.

15 Revisiones del Software15 Impacto de los defectos ► El objetivo de las inspecciones es encontrar los errores antes de que se conviertan en defectos,  de modo que no se propaguen a través del proceso

16 Revisiones del Software16 Ampliación y eliminación de defectos ► Para ilustrar la generación y detección de errores, usaremos el siguiente modelo de ampliación de defectos. Errores pasados por alto Errores amplificados 1:x Nuevos errores generados Porcentaje de eficiencia para detección de errores Errores que pasan al siguiente paso Errores que vienen de pasos previos DefectosDetección

17 Revisiones del Software17 Modelo de ampliación de defectos ► Un recuadro representa un paso de desarrollo de software. ► Durante el paso, los errores se pueden generar de manera inadvertida. ► La revisión puede fallar en descubrir errores generados de manera reciente y errores de pasos anteriores, lo que resulta en cierto número de errores que se pasan por alto. ► En algunos casos, los errores que se pasan por alto de pasos anteriores, se amplifican con el trabajo actual.

18 Revisiones del Software18 Ampliación y eliminación de defectos 0 0 10 0% Diseño preliminar 6 4x1.5 25 0% Diseño Detallado 10 27x3 25 20% Prueba código/unidad 106 4 3710 27 X = 1.5 X = 3 0 0 50% Prueba de integración 0 0 50% Prueba de validación 0 0 50% Prueba de sistema 47 24 A integración 94 Errores latentes 12 SIN inspección “Es una suposición optimista”

19 Revisiones del Software19 Ampliación y eliminación de defectos 0 0 10 70% Diseño preliminar 2 1x1.5 25 50% Diseño Detallado 5 10x3 25 60% Prueba código/unidad 32 1 155 10 X = 1.5 X = 3 0 0 50% Prueba de integración 0 0 50% Prueba de validación 0 0 50% Prueba de sistema 12 6 A integración 24 Errores latentes 3 CON inspección

20 Revisiones del Software20 Ampliación y eliminación de defectos ► Primer caso:  10 errores de diseño se amplifican en 94 antes de empezar las pruebas.  12 defectos latentes se liberan al campo. ► Segundo caso:  10 errores iniciales de diseño se amplifican en 24 al comenzar las pruebas.  Sólo existen 3 defectos latentes.

21 Revisiones del Software21 Ampliación y eliminación de defectos ► Al considerar el costo relativo de la detección y eliminación de errores se puede establecer el costo global. ► El número de errores descubierto se multiplica por el costo de eliminar un error (1.5 unidades para el diseño, 6.5 antes de las pruebas, 15 durante las pruebas, y 67 después de la liberación) ► Usando los datos anteriores, los costos son:  Sin revisiones: 2177 unidades de costo  Con revisiones: 783 unidades de costo

22 Algunos casos ejemplo Tomados de reportes de investigación publicados

23 Revisiones del Software23 Caso ejemplo 1 ► Inspecciones de diseño y código (Fagan, 1976)

24 Revisiones del Software24 Caso ejemplo 1 ► Resultados del estudio (Fagan, 1976)

25 Revisiones del Software25 Caso ejemplo 1 ► Resumen  Se realizó un experimento usando inspecciones de software y recorridos (walkthroughs)  Las inspecciones consumieron alrededor del 15% del tiempo  Se obtuvo una reducción en los errores de alrededor del 40% ► Conclusiones:  Las inspecciones incrementan la productividad y la calidad del sistema. También ayudan a mejorar el control del proceso y la administración de los proyectos. ► Fagan indica que las inspecciones pueden ayudar a encontrar entre un 60 y 90% de los errores (Fagan, 1986) (Fagan, 1976)

26 Revisiones del Software26 Caso ejemplo 2 ► Datos extraídos de resultados en proyectos de Northern Telecom. (Rusell, 1991)

27 Revisiones del Software27 Caso ejemplo 2 ► Datos extraídos de un sistema con más de 10 millones de líneas de código ► Más de 2.5 millones de líneas de código fueron inspeccionadas ► La gráfica muestra el costo en esfuerzo de encontrar defectos con inspecciones (Rusell, 1991)

28 Revisiones del Software28 Caso ejemplo 2 ► El tiempo dedicado a inspecciones incluye preparación, presentación general del producto a inspeccionar y reuniones de inspección. ► El estudio muestra que “se puede encontrar un defecto por cada hora hombre dedicada a las inspecciones”.  Esto es de dos a cuatro veces más rápido que hacerlo durante las pruebas del código. ► En la empresa, cada defecto encontrado después de la liberación consume alrededor de 4.5 días hombre repararlo.  Por tanto, cada hora dedicada a la inspección reduce alrededor de 33 horas de mantenimiento asumiendo un día de trabajo de 7.5 horas. (Rusell, 1991)

29 Revisiones del Software29 Caso ejemplo 2 ► Defectos detectados por cada mil líneas de código en cada paso de inspección. ► Entre menos líneas se inspeccionen por hora, mayor la tasa de detección de errores. (Rusell, 1991)

30 Tipos de revisiones de software

31 Revisiones del Software31 Tipos de revisiones de software ► Las revisiones de software pueden variar en su tipo y nivel de formalidad (informales y formales) ► Algunas de las más comunes son:  Auditorias  Auto-inspección  Inspecciones técnicas formales (o inspecciones)  Revisiones  Recorridos (Walkthroughs)

32 Revisiones del Software32 Auditorias ► Es una técnica de verificación realizada durante el proceso de desarrollo de un nuevo producto o durante el mantenimiento. ► Consiste en que asegurar que tanto un producto se ajusta a los planes, políticas, procedimientos y estándares establecidos. ► Se realizan a través de reuniones, observaciones y examinando los productos y procedimientos.

33 Revisiones del Software33 Auto-inspección ► Es una revisión intensa de un producto del trabajo para asegurar que está correcto, completo, que es consistente y claro. ► Puede involucrar distintas tareas, tales como:  Revisión de sintaxis  Examinar referencias cruzadas  Violación de convenios  Comparación detallada con la especificación  Lectura de código  Análisis de diagramas de flujos de control  Sensibilización de caminos ► Es preferible que se realice por alguien no involucrado en el desarrollo del producto.

34 Revisiones del Software34 Inspecciones técnicas formales ► Se realizan por un equipo que examina un producto determinado, siguiendo roles y un proceso bien definido. ► El equipo normalmente se constituye de cuatro o cinco miembros: moderador, secretario, lector, el productor, el agente de V&V, y uno o más expertos. ► El proceso normalmente involucra los siguientes pasos: presentación general, preparación, inspección, retrabajo, y seguimiento.

35 Revisiones del Software35 Revisiones ► Se enfoca en evaluar un producto en base a guías, estándares y especificaciones de desarrollo y proveer a los administradores, evidencia de que el proceso se está realizando acorde con los objetivos establecidos. ► La revisión es similar a las inspecciones y recorridos, con excepción de que incluye a la administración. ► No se enfoca tanto en aspectos técnicos como las inspecciones.

36 Revisiones del Software36 Recorridos ► El objetivo principal es detectar y documentar fallas. ► Esto debe ser realizado por todos los involucrados. ► Un equipo típico para los recorridos es:  Coordinador,  Presentador,  Secretario,  Encargado de mantenimiento,  Encargado de estándares,  Agente de acreditación, que representa al usuario  Revisores adicionales

37 Revisiones del Software37 Inspecciones vs Recoridos vs Revisiones ► Las inspecciones son un proceso formal de cinco pasos. Se utiliza una lista de comprobación para descubrir errores. ► Un recorrido es menos formal, tiene menos pasos, y no usa una lista de comprobación, o documento para reportar el trabajo del equipo. ► Las inspecciones y recorridos se enfocan en asegurar la corrección. ► Las revisiones se enfocan más en deficiencias en el diseño, o desviaciones de los modelos conceptuales o los requerimientos, que en los intrincados detalles de cada línea de la implementación. ► El enfoque de las revisiones no es en fallas técnicas, sino en asegurar que el diseño y el desarrollo concuerdan con las necesidades de la aplicación.

38 Revisiones del Software38 Bibliografía ► Sommerville, capítulo: 22 ► Pressman, capítulo 26 ► Fagan, M.E., Design and Code inspections to reduce errors in program development, 1976, IBM Systems Journal, Vol. 15, No 3, Page 182-211 ► Fagan, M.E., Advances in Software Inspections, July 1986, IEEE Transactions on Software Engineering, Vol. SE-12, No. 7, Page 744-751 ► Rusell, G.W., Experience With Inspection in Ultralarge-Scale Development, January 1991, IEEE Software, 8(1): 25-31.