TEMA: RESPONSABILIDAD DE ERRORES

Slides:



Advertisements
Presentaciones similares
INTRODUCCIÓN A LA VERIFICACION Y VALIDACION
Advertisements

Fundamentos de Diseño de Software INFT.1
Pruebas de Diseño Diplomado en Calidad en el Software NOTAS
Gestión de Recursos Informáticos Unidad Nº 3: Gestión de calidad y eficiencia.
Tecnologías.
ASEGURANDO LA CALIDAD DEL CODIGO
Actividad 16. Estrategias para prueba del software
METODOLOGÍAS ÁGILES “PROCESO UNIFICADO ÁGIL (AUP)
Unidad I: Transición del Análisis hacia el Diseño
Administración de Procesos de Pruebas
Controles internos en Sistemas de Información Universidad de Buenos Aires Facultad de Ciencias Económicas Materia: Sistemas Administrativos.
TEAM SOFTWARE PROCESS CICLO 2.  Producto  Reporte del ciclo  Plan  Inspección  Plan de calidad  Valor ganado  Objetivos  Proceso TSP  Equipo.
Verificación y validación. Objetivos Introducir la verificación y validación del software y discutir la diferencia entre ellos (V & V) Describir el proceso.
© Asesores en Control de Calidad, S. C. Av. Observatorio # 280 Col. Observatorio, México, D. F. C. P Tels
TEAM SOFTWARE PROCESS CICLO 3.  Análisis del Proyecto  Producto  Resultados por Rol  Resultado del Proceso.
Diseño de métodos de trabajo
Inspecciones de Software
Papeles de trabajo para la auditoria de sistemas computacionales
Métricas de calidad de software
Administración Proyectos Jorge Baracaldo Robin Ochoa.
Modelos de desarrollo de Software
PREPARACIÓN DE PRUEBAS EQUIPO DE TRABAJO: ISABEL MARTÍNEZ MARTÍNEZ Y ERIKA HERRERA HERRERA.
9.4 ACTIVIDADES DE LAS PRUEBAS Describe las actividades de las pruebas dentro de las que están: Inspección de componentes Pruebas unitarias Pruebas de.
Introducción a la investigación de mercados Naresh malhotra
Instituto Tecnológico superior de Acatlán de Osorio. Nombre del Docente: L.C.C. Miguel Fuentes cortes. Equipo de trabajo: Isabel Martínez Martínez y Erika.
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
VISIÓN GENERAL DE LA IS Con independencia del modelo de proceso hay tres fases genéricas: Fase de definición Fase de desarrollo Fase de mantenimiento Cada.
Unidad ll Equipo 2 Juan Carlos Martínez Ramos
Ing. Noretsys Rodríguez. Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de.
SGSI: Sistemas de Gestión de la Seguridad de la Información
Universidad de Aconcagua SISTEMA DE GESTION DE CALIDAD
Las Pruebas del Software y sus Fundamentos
La Calidad y los Costos.  Conjunto de cualidades y características que constituyen la escencia de un producto y respaldan el grado de beneficio proporcionado.
PROYECTO TECNOLÓGICO Mateo Guerra Alzate Cristian Herrera 9-D I
ASIGNACIÓN DE ROLES.
INGENIERIA DE SOFTWARE
Ciclo de vida de un sistema
El proceso de verificación y validación.
 Sara Isabel Osorio Alcaraz Ana Isabel Vallejo Grisales 10 Informática 1.
Métricas de calidad de software
Roles de Open UP.
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
TIPOS DE PRUEBAS DEL SOFTWARE
Introducción al proceso de verificación y validación.
NOMBRE DE LA ASIGNATURA: VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE
Simón Esneider Herrera Álvarez Media Técnica Casd 10-2
REVISION Y AUDITORIA.
Ciclo de Vida del Software
Carolina Rangel Felipe Montaño Alexis García
TEMA: Tipos de Errores Integrantes del equipo : Chávez Cholula Gisela Ramírez Valerio Ángeles Docente: L.I. Fuentes Cortes Miguel INSTITUTO TECNOLÓGICO.
SEGURIDAD INFORMATICA II VIII. DEFINICIÓN DE POLÍTICAS DE SEGURIDAD .
Verificación y Validación de Software
Asesoría Relacionada a la Seguridad. Balance de Seguridad.
Proceso de desarrollo de Software
ANALISIS SEGURO DE TRABAJO (AST)
Capas de ingeniería del Software. Rosendo Antonio Manuel Ingeniería en Sistemas Computacionales.
Administración de Calidad de Software
6.6 Administración de defectos
Las fases del ciclo de la vida de desarrollo de sistemas
Ingeniería del Software
Bachillerato Ingeniería en Informática Fundamentos de Computación.
Productos de Pruebas Hace hambre!! . Las bases. La verificación consiste en corroborar que el programa respeta su especificación, mientras que validación.
CICLO DE VIDA DE UN SOFTWARE. Es el conjunto de los programas de cómputo, procedimientos, reglas, documentación y datos asociados, que forman parte de.
Objetivos de la prueba Los objetivos principales de realizar una prueba son: Detectar un error. Tener un buen caso de prueba, es decir que tenga más probabilidad.
Aseguramiento de la Calidad. (Software Quality Assurance, SQA) Por. Ing. Ernesto Soto Roca.
Verificación y Validación del Software Unidad 2. Revisiones del Software (Parte 1)
Verificación y Validación del Software
VERIFICACIÓN Y VALIDACIÓN DE SISTEMAS 3.10 Fase de manejo de requerimientos 4.1 Modelado de pruebas en UML Ponente: ing. Alejandro tapia vazquez.
Sistemas de calidad en el desarrollo de software.
Entregables del Proyecto
Transcripción de la presentación:

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.

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.