TEMA: RESPONSABILIDAD DE ERRORES

Presentación del tema: "TEMA: RESPONSABILIDAD DE ERRORES"— Transcripción de la presentación:

1 TEMA: RESPONSABILIDAD DE ERRORES
NOMBRE DE LA ASIGNATURA: VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE INTEGRANTES DEL EQUIPO: JUAN DE DIOS RAMÍREZ VIVAR RAFAEL VALLE CASTELÁN NOMBRE DEL PROFESOR: L.C.C. MIGUEL FUENTES CORTES CARRERA: INGENIERÍA INFORMÁTICA SEMESTRE: 8º. GRUPO: “C” DEL DOCENTE: L.I. RAÚL GARCÍA HERRERA     ACATLÁN DE OSORIO PUE; A 24 DE MAYO DE 2014.

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

3 EL MÉTODO FAGAN PARA INSPECCIONES
El método de inspección más utilizado hasta el momento, es el de Fagan (1976). Fagan (1976) menciona que las inspecciones son un método formal, eficiente y económico para encontrar errores en el diseño y el código. Para su método, Fagan propone un conjunto de roles y un proceso a seguir durante las inspecciones.

4 El equipo Moderador Diseñador Implementador/Codificador Encargado de pruebas

5 El Moderador Es la persona clave en una inspección exitosa. Debe ser un programador competente, pero no necesita ser un técnico experto en el programa siendo inspeccionado. Es recomendable usar un moderador de un proyecto no relacionado, para preservar la objetividad, e incrementar la integridad de la inspección. Debe administrar al equipo de inspección y ofrecer un liderazgo. Sus tareas incluyen: Calendarizar reuniones y lugares de reunión Reportar los resultados de la inspección Dar seguimiento al retrabajo

6 EL DISEÑADOR Es el responsable de producir el diseño del programa. EL IMPLEMENTADOR/CODIFICADOR El responsable de transformar el diseño en código. EL ENCARGADO DE LAS PRUEBAS El responsable de escribir y/o ejecutar los casos de prueba o alguna otra forma de probar los productos del diseñador y el codificador.

7 El plan de pruebas Es un documento que describe el enfoque que será utilizado para las actividades de pruebas, e incluye: Los elementos a ser probados Los tipos de pruebas que serán realizadas El calendario de pruebas Los recursos humanos Procedimientos de reporte Criterios de evaluación, etc.

8 CALENDARIZACIÓN Fagan menciona que cuatro miembros es un buen tamaño para el equipo de inspección. Sin embargo, puede crecer si el programa tiene interfaces con otros, dado que los programadores de estas interfaces deberían también participar en las inspecciones. Fagan también menciona que con un grupo de cuatro, las inspecciones llevarán entre 90 y 100 horas hombre. Recomienda que las reuniones de inspección no sobrepasen las dos horas, y que dos reuniones de dos horas al día es aceptable. El tiempo para realizar las inspecciones y el retrabajo resultante, debe calendarizarse como cualquier otra actividad importante del proyecto.

9 EL PROCESO Fagan propone un proceso de inspección constituido por las siguientes actividades 1.Vista general 2.Preparación 3.Inspección 4.Retrabajo 5.Seguimiento

10 1.-VISTA GENERAL Participa todo el equipo. El diseñador describe el área general que será abordada, y entonces especifica el área que él ha diseñado en detalle (lógica, caminos, dependencias, etc.). La documentación del diseño se distribuye entre todos los participantes. En la inspección de código se requiere usar el listado del código y la especificación de diseño como material de la inspección. En la segunda inspección, el moderador debe tener un especial escrutinio de todas las partes que hayan sido modificadas después de la inspección de diseño, ya sea por retrabajo debido a errores, o por alguna otra causa.

11 2.-PREPARACIÓN Es una actividad individual. Los participantes tratan de entender el diseño, su intención y lógica. Algunos errores se pueden encontrar durante esta proceso, pero no suelen ser tantos como durante la reunión de inspección. Se debe estudiar la distribución de tipos de errores de inspecciones anteriores, para concentrarse en las áreas que con mayor probabilidad podrían tener errores. También se debe estudiar las listas de verificación de errores.

12 3.-INSPECCIÓN Se realiza por todo el equipo. Un lector, elegido por el moderador, describe cómo implementará el diseño. Parafrasea el diseño de la forma en que lo expresó el diseñador. Cada pieza de lógica es cubierta al menos una vez, y cada rama es tomada al menos una vez. Durante la inspección se debe contar con: Toda la documentación de alto nivel, especificación de diseño de alto nivel, especificación de lógica, etc.

13 3.-INSPECCIÓN Listado de bloques de control Una vez que se entendió el diseño, el objetivo es encontrar errores. Hasta que un error se descubre, se realizan preguntas. El moderador captura los errores, clasifica su tipo, e identifica su severidad (menor, mayor, etc.), y se continúa con la inspección. Si la solución del problema es obvia, se anota, pero no se espera definir soluciones durante la inspección. Al finalizar las conclusiones de las inspecciones del día, el moderador debe escribir un reporte de las inspecciones y sus resultados para asegurarse que se tomen en cuenta en las operaciones de retrabajo y seguimiento.

14

15

16 4.-RETRABAJO Todos los errores o problemas detectados en la inspección son resueltos por el diseñador o implementador/codificador 5.-SEGUIMIENTO Es responsabilidad del moderador asegurarse de que todos los aspectos, errores, problemas, etc. descubiertos en la inspección hayan sido resueltos por el diseñador o el implementador/codificador en su caso. Si más de un 5% del material ha sido retrabajado, se recomienda realizar una nueva inspección del 100%. En otro caso, el moderador puede usar su criterio para determinar la calidad del retrabajo por él mismo, o programar una reinspección de una parte o todo el trabajo.

17 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 por que las inspecciones pueden ayudar a encontrar entre un 60 y 90% de los errores.