Embed Size (px)
Citation preview
TEMA: RESPONSABILIDAD DE ERRORES
NOMBRE DE LA ASIGNATURA: VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE
INTEGRANTES DEL EQUIPO:
RAFAEL VALLE CASTELÁN
JUAN DE DIOS RAMÍREZ VIVAR
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.
Responsabilidad de Errores
¿Qué se busca ?
La reducción de defectos, fallas, errores,
etc. en el sistema de software.
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.
El equipo
Moderador
Diseñador
Implementador/Codificador
Encargado de pruebas
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
