Inspecciones de Software

Slides:



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

EL PROCESO DE DESARROLLO DEL SOFTWARE
Ciclo de vida de desarrollo de software
PLANIFICACIÓN DE TESTING
Ingeniería de Software II
Aclaraciones de la Realización del Producto
PROGRAMA DE AUDITORIA DE SISTEMAS
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de Metodologías ágiles.
10º2 Sergio Posso. Jonatán Agualimpia. Julia Blandón. Docente:
AUDITORIA INTERNA.
Administración de Procesos de Pruebas
Versión 2004 Enrique Bañuelos Gómez
Evaluación de Productos
ITERASOFT. OBJETIVOS DEL GRUPO Producir un sistema Manejador de Itinerarios de alta calidad y confiabilidad Realizar un proyecto bien administrado y productivo.
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.
TEAM SOFTWARE PROCESS CICLO 3.  Análisis del Proyecto  Producto  Resultados por Rol  Resultado del Proceso.
Planeación con Planning Tool y DotProject Grupo de Construcción de Software Facultad de Ingeniería Universidad de los Andes Rubby Casallas, Andrés Yie.
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.
Ingeniería del Software
Ximena Romano – Doris Correa
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.
Ingeniería de Software
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.
Pruebas y La Vida del Ciclo de Desarrollo del Software
35 años de investigación, innovando con energía 1 Mayo, 2012 P LAN DE ASEGURAMIENTO DE LA CALIDAD DEL DESARROLLO DE SOFTWARE E STÁNDAR IEEE 730 Y G UÍA.
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.
El rol de SQA en PIS.
Las Pruebas del Software y sus Fundamentos
ASIGNACIÓN DE ROLES.
INGENIERIA DE SOFTWARE
Verificación y Validación del Software
Factores y Métricas que determinan la Calidad de un producto
Método iterativo Integrantes : Paola Ramón Armando 19 octubre 2011.
Guía metodológica para la gestión de proyectos de software en PyMEs que no son fábricas de software por medio de metodologías ágiles Tatiana Alejandra.
Definición de sistema__________
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
TIPOS DE PRUEBAS DEL SOFTWARE
Introducción al proceso de verificación y validación.
Actividades en el Proceso de desarrollo de Software
NOMBRE DE LA ASIGNATURA: VERIFICACIÓN Y VALIDACIÓN DEL SOFTWARE
Simón Esneider Herrera Álvarez Media Técnica Casd 10-2
TEMA: RESPONSABILIDAD DE ERRORES
REVISION Y AUDITORIA.
“ NO HAY NADA MÁS DIFÍCIL DE CONSEGUIR, MÁS ARRIESGADO DE MANTENER NI MÁS INSEGURO DE TENER ÉXITO, QUE ESTAR A LA CABEZA EN LA INTRODUCCIÓN DE UN.
Ciclo de Vida del Software
CICLO 1 BEATRIZ BARREIRO GÓMEZ HENRY SUÁREZ SÁNCHEZ
Ingeniería en Informática F UNDAMENTOS DE C OMPUTACIÓN B ACHILLERATO EN I NGENIERÍA I NFORMÁTICA L IC. C ARLOS H. G UTIÉRREZ L EÓN.
Carolina Rangel Felipe Montaño Alexis García
INGENIERIA DE SOFTWARE
Verificación y Validación de Software
Proceso de desarrollo de Software
INTRODUCCIÓN A LA INGENIERIA DE SOFTWARE ALUMNO MILLER ANDRES GALINDO DUCUARA (412088)
República Bolivariana de Venezuela Universidad Nacional Experimental Politécnica de la Fuerza Armada (UNEFA) Carrera: Ingeniería de Sistemas Cátedra: Análisis.
6.6 Administración de defectos
EI, Profesor Ramón Castro Liceaga IV. AREAS DE EVALUACIÓN DE LA AUDITORIA EN INFORMÁTICA. UNIVERSIDAD LATINA (UNILA)
Fundamentos de Computación
Modelo de procesos de software
Planificación de Sistemas de Información
TEAM SOFTWARE PROCESS CICLO 1. El software propuesto por el equipo de Ingenium para cumplir con las necesidades planteadas, modela los un conjunto de.
Bachillerato Ingeniería en Informática Fundamentos de Computación.
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.
Plan de Pruebas de Aceptación
Verificación y Validación del Software Unidad 2. Revisiones del Software (Parte 1)
UNIDAD III. PSP Objetivo: El alumno identificará el Proceso Personal de Software, para medir su desempeño.
Verificación y Validación del Software
Sistemas de calidad en el desarrollo de software.
Transcripción de la presentación:

Inspecciones de Software R. Casallas Dpto. de Ingeniería de Sistemas y Computación Universidad de los Andes

Agenda Introducción Inspecciones

Introducción Costo de detectar errores tarde El factor que más contribuye en el incremento de los costos de software es el trabajo requerido para corregir errores detectados tarde en el proceso de desarrollo Entre más pronto se detecte un error más fácil y barato es corregirlo

Introducción (2) Costo de detectar errores tarde El número de errores detectados después de la instalación del software esta en correlación con el número de errores detectados en la fase de pruebas. Entre más errores se detecten en la fase de pruebas más alta es la probabilidad de que haya más

Introducción de Errores y Propagación Necesidades reales del usuario Definición y Análisis de Requerimientos Requerimientos de Software Correctos Requerimientos de Sw Incorrectos Diseño Arquitectónico Diseño Arquitectónico Correcto Diseño Arquitectónico basado en requerimientos erroneos Diseño Arquitectónico Erroneo Diseño Detallado Diseño Detallado Correcto D.D. basado en req. erroneos D.D. basado en D.A. erroneo Erroneo Programación Código Correcto Código Erroneo Código basado en DD erroneo Código basado en DA erroneo Código basado en Req. erroneos

Introducción (3) Cómo reducir costos y desfases en los cronogramas? Construir calidad a medida que se desarrolla el producto usando técnicas de detección de defectos e incrementando estrategias de desarrollo incremental e iterativo reducir el trabajo en las últimas etapas Construir casos de prueba al mismo tiempo que el producto hacer la fase de pruebas más productiva

Introducción (4) Cómo reducir costos y desfases en los cronogramas? Mejorar continuamente el proceso de desarrollo definiendo (usando) técnicas de prevención de defectos evitar cometer los mismos errores

Reducir el trabajo en las últimas etapas Especificaión de la Arquitectura del Sistema Especificación del Diseño Detallado Código Fuente Definición Requerimientos Análisis de Requerimientos Diseño de la Arquitectura Diseño Detallado Especificación de requerimientos preliminar Especificación Detallada de Requerimientos Programación Código Fuente listo para Pruebas Filtro de detección de defectos

Introducción (5) Técnicas de Detección de Defectos Tempranamente (sin ejecución) Revisiones personales Walk-throughs (verificación en grupo) Inspecciones Revisiones de colegas Modelaje y verificación formal

Introducción (6) Técnicas de Detección de Defectos Etapas Finales (con ejecución) Pruebas de caja blanca Pruebas de caja negra Pruebas basadas en escenarios o casos de uso

Inspecciones ( Historia) En un grupo de 11 programas desarrollado por el mismo equipo de personas: los primeros 5 programas fueron desarrollados sin revisiones y los 6 restantes usando éstas. El número de errores de los primeros 5 fue 4,5 errores por 100 líneas de código. Los seis restantes tuvieron un promedio de 0,82 errores por 100 líneas de código.

Inspecciones ( Historia) La compañía de seguros Aetna encontró el 82 por ciento de los errores en un producto usando inspecciones, lo cual le permitió reducir sus recursos de desarrollo en un 25%.

Inspecciones ( Historia) El proyecto Orbit de IBM con 500,000 líneas de código usaba 11 niveles de inspección. Fue entregado tempranamente y tenía tan solo un 1% de los defectos usuales en proyectos de su tamaño.

Inspecciones ( Historia) Introducido por Michael Fagan en 1976 Usado por IBM durante años antes de que éste publicara su trabajo. Una combinación de inspecciones en diseño y codificación remueve del 60 al 90% de los defectos de un producto, dichas inspecciones ocupan usualmente el 15% del tiempo total de un proyecto.

Desarrollo enfocado hacia la calidad Técnica prevención de defectos Definición Requerimientos Análisis de Requerimientos Diseño de la Arquitectura Diseño Detallado Especificación de requerimientos preliminar Filtro de detección de defectos Especificación Detallada de Requerimientos Programación Especificaión de la Arquitectura del Sistema Especificación del Diseño Detallado Código Fuente Código Fuente listo para Pruebas Técnica prevención de defectos Técnica prevención de defectos Técnica prevención de defectos Técnica prevención de defectos

Inspecciones Definición Revisión de Colegas en el que un equipo de personas sigue un procedimiento formal con el propósito de encontrar defectos en etapas tempranas en el producto que está siendo revisado.

Inspecciones Ventajas Aplicable en todas las etapas del ciclo de desarrollo, requerimientos, arquitectura, diseño, código, etc. No se requieren herramientas sofisticadas Más eficiente que buscar defectos en pruebas Se descubren errores en etapas tempranas.

Inspecciones Pruebas es una forma ineficiente de encontrar defectos: 1. Ud. detecta una falla o defecto 2. Ud. debe encontrar el defecto en el código depurar puede tomar una gran cantidad de tiempo, especialmente cuando el problema es intermitente o difícil de reproducir 3. Ud. debe planear la corrección del defecto 4. Finalmente, implementar la corrección y probarla

Inspecciones Las inspecciones son más eficientes 1. Ud. ve el defecto directamente en el código 2. Ud. debe planear la corrección del defecto 3. Finalmente, implementar la corrección e inspeccionarla

Métodos de inspección Listas de chequeo Puntos de vista Concentrarse en ciertas partes del producto

Inspecciones Roles en el proceso de inspección 1 Autor: desarrollador del producto que será inspeccionado 2 Revisores: colegas del autor, uno de otro proyecto 1 Moderador: miembro del grupo de aseguramiento de calidad

Fases de la Inspección

Preparación de la Inspección Proceso: 1. Autor prepara el producto que se va a revisar, la lista de chequeo y el material de soporte 2. Moderador asigna los revisores y elabora el cronograma 3. Autor distribuye el material 4. Autor realiza una presentación global del producto a los participantes en la inspección

Preparación de la Inspección (2) Guías: Autor debe realizar una revisión personal del trabajo y corregir los errores encontrados antes de preparar la inspección de colegas Para inspecciones de código, no debe cubrir más de 200 LOC por hora, y el código no debe ser probado antes de la inspección

Revisión Individual Proceso: 1. Los inspectores realizan una inspección individual del producto siguiendo la lista de chequeo suministrada 2. Los inspectores registran los defectos identificados en la forma de recolección de defectos suministrada 3. Los inspectores registran el tiempo invertido en la revisión

Revisión Individual (2) Guías: Los inspectores no deben trabajar más de dos horas seguidas en una revisión individual El Moderador también debe realizar la revisión individual Las listas de chequeo deben ser seguidas un ítem a la vez

Reunión de Inspección Proceso: 1. El moderador recolecta el tiempo invertido en cada revisión individual y las hojas de reporte de defectos 2. Por cada parte del producto: - El moderador va por cada parte del producto pidiendo a cada inspector presentar los errores potenciales encontrados - El Autor registra en el reporte resumen todos los defectos potenciales confirmados como defectos por el grupo de inspección

Reunión de Inspección (2) Guías: El objetivo de la reunión es identificar los defectos y no corregirlos Autor puede proveer aclaraciones pero no justificación en la identificación de un defecto potencial Evitar críticas contra el autor: el propósito es encontrar defectos en el producto no en el autor Evitar discusiones de estilo La reunión de Inspección no debe exceder 2 horas

Seguimiento Proceso: 1. Autor recolecta las formas de reporte de defectos 2. Autor desarrolla una respuesta para cada defecto 3. Autor hace las correcciones 4. Autor somete el producto reparado al moderador 5. Moderador verifica que todos los defectos fueron tenidos en cuenta apropiadamente y dependiendo de la cantidad de cambios realizados, convoca a una segunda revisión de colegas o hace una revisión individual. 6. Moderador aprueba la versión final del producto para que sea congelada

Recomendaciones Revise el producto no al que lo produce. El moderador debe fijar un tiempo para la reunión y debe tratar de mantenerlo. Es necesario limitar el debate. Enuncie el tipo de problemas, pero no trate de resolverlos en la reunión. Registre los datos obtenidos en la revisión.

Recomendaciones El número de participantes es limitado y siempre deben estar preparados previamente. Desarrolle o use una lista de chequeo para cada uno de los productos revisados. Usualmente dicha lista de chequeo debe tener en cuenta puntos problemáticos que se hayan dado en el pasado del proyecto