6.6 Administración de defectos

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
Ciclo de Vida de Desarrollo de los Sistemas de Información
Ingeniería de Software II
Gestión de Recursos Informáticos Unidad Nº 3: Gestión de calidad y eficiencia.
ANÁLISIS DE REQUERIMIENTOS
Evaluaciones de Sistemas de Administración de la Seguridad SMSA
EL DIRECTIVO FRENTE A LOS PROBLEMAS
Resolución de Problemas Algoritmos y Programación
Temas Operaciones básicas Instalando el compilador
Ciclo de desarrollo del software
Modelos de confiabilidad
Administración de Procesos de Pruebas
Teoría de lenguajes y compiladores
Programas Son una serie o secuencia de instrucciones entendibles por los ordenadores que permiten la realización de las acciones o tareas para las que.
Modelo de Desarrollo XP
Inspecciones de Software
Fundamentos de Ingeniería de Software Facultad de Ingenieria Universidad Distrital Francisco José de Caldas ESPECIFICACIÓN Y MANEJO DE LOS REQUERIMIENTOS.
LENGUAJE DE PROGRAMACIÓN
PROGRAMACIÓN PROCEDIMENTAL
Modelos de desarrollo de Software
Metodología para solución de problemas
Ingeniería del Software
Programación 1 (01y 05) Prof. Flor Narciso
FUNDAMENTOS DE PROGRAMACION
Análisis y diseño detallado de aplicaciones informáticas de gestión
Tema 1: Introducción a la Ingeniería de Software
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.
Tecnologías para el Aprendizaje
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.
En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto.
Diseño de Sistemas Herramientas para el Diseño de Sistemas.
Metodología de la programación
Las Pruebas del Software y sus Fundamentos
ASIGNACIÓN DE ROLES.
INGENIERIA DE SOFTWARE
Alexander Aristizabal Ángelo flores herrera
Verificación y Validación del Software
Ciclo de vida de un sistema
 Sara Isabel Osorio Alcaraz Ana Isabel Vallejo Grisales 10 Informática 1.
TIPOS DE AUDITORÍAS EN SISTEMAS DE INFORMACIÓN
Elaborado por: Mayoral Cruz Matilde Morales Espinoza Anllhins
Introducción al proceso de verificación y validación.
Actividades en el Proceso de desarrollo de Software
Desarrollo de lógica algorítmica.
Simón Esneider Herrera Álvarez Media Técnica Casd 10-2
Ford 8DS es una herramienta de fabricación magra. Originalmente desarrollado por Ford Motor Company, Ocho D se introdujo en 1987 en un manual titulado.
G ESTIÓN DE LA C ONFIGURACIÓN DEL S OFTWARE G ESTIÓN DE LA C ONFIGURACIÓN DEL S OFTWARE Daniel Eduardo Almeciga Angie Katterine Cruz O. Diego Fernando.
TEMA: RESPONSABILIDAD DE ERRORES
REVISION Y AUDITORIA.
Ciclo de Vida del Software
Omar de Jesús Rosales hernández
Preocupaciones del Analista Programador & Usuarios
Carolina Rangel Felipe Montaño Alexis García
 es el conjunto de conocimientos y técnicas científicas aplicadas al desarrollo, implementación, mantenimiento y perfeccionamiento de estructuras (tanto.
DESARROLLO DE SOFTWARE Cuando se va desarrollar un software intervienen muchas personas como lo es el cliente quien es el que tiene el problema en su.
Verificación y Validación de Software
Proceso de desarrollo de Software
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
Ingeniería del Software
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.
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.
6.6 Administración de defectos
Transcripción de la presentación:

6.6 Administración de defectos ELABORADO POR: MAYORAL CRUZ MATILDE MORALES ESPINOZA ANLLHINS

Los pasos para encontrar defectos Hay varias formas para encontrar defectos en un programa, pero en esencia tienen lo s siguientes pasos: 1. Identificación de los síntomas del defecto. 2. Deducir de esos síntomas la localización del defecto. 3. Entender lo que es erróneo en el programa. 4. Decidir cómo corregir el defecto. 5. Hacer la corrección. 6. Verificar que se ha resuelto el problema.

Formas de encontrar y corregir defectos El compilador es una de las herramientas que ayudan a detectar errores aunque no de forma completa, pueden evitar un  90% de errores sintácticos y algunos lógicos. Otra herramienta es por medio de las pruebas, estas dependen de los casos  planteados y de sus condiciones. Además las p ruebas siguen obligando a moverse desde los síntomas al  problema, y sólo verifican  las condiciones probadas. Un tercer método  es la entrega del programa al usuario  y que éste informe de los errores  que identifique. La forma más efectiva de encontr ar y corregir defectos  es la revisión personal del código fuente del programa.

Revisión del código Para hacer la revisión de código se estudia el código fuente a partir de un listado, antes de compilarlo o probarlo. Tras  hacer el diseño o la codificación  es más fácil   recordar la intención que se tiene, simplificando la corrección del problema. La revisión de código consume tiempo, pero su eficiencia es mayor que las  pruebas, ya que  se  detectan  los problemas y  no los síntomas.  En el  momento  de  revisión del código se  piensa sobre lo que el programa debe hacer. Las desventajas  principales  de  las  revisiones  son que consumen tiempo y la dificultad de  hacerlas  correctamente, sin  embargo la capacidad de revisión  mejora con la práctica. La razón más importante para revisar los programas antes de compilarlos y probarlos es la dificultad de convertir en un  producto de calidad un programa que ha sido  varias veces parcheado.

El coste de encontrar y corregir defectos En los proyectos software, el producto es dividido en programas elementales o  módulos. Tras el diseño, implementación  y compilación del mismo, se realizan  las pruebas de unidad. Tras la combinación de módulos pasamos a las pruebas   de integración. Se realizan varios niveles de pruebas de componentes antes de  combinarlos en productos y realizar las correspondientes pruebas. Finalmente  se ensamblan los productos y se realizan las pruebas del sistema. El coste medio de encontrar y corregir un defecto crece unas 10 veces en cada  paso del proceso de desarrollo. Además  del coste, una razón importante para  encontrar los defectos al principio, es que la compilación, depuración y pruebas  tienen  una efectividad reducida.

El uso de las revisiones para encontrar defectos La razón principal de reunir los datos de defectos es para poder entender la clase de defectos que se pueden introducir. Los defectos de un programa nuevo serán parecidos a los encontrados en programas anteriores. Esto supone que la estrategia de revisión se debe basar en el perfil personal. El objetivo de la revisión de códigos es encontrar el mayor numero de defectos lo mas pronto posible en el proceso software.

Listas de comprobación para la revisión de código ¿Por qué ayudan las listas de comprobación? Una lista de comprobación una serie de pasos de procedimientos que se siguen de forma precisa. Cuando es esencial encontrar y corregir cada defecto en un programa se debe seguir un procedimiento preciso. Una lista de comprobación tiene el siguiente formato:

La lista de comprobación para la revisión de código Se deben leer y hacer sucesivamente las acciones prescritas tal y como están establecidas en la lista de comprobación , cada acción completada se marca en la lista. Al final se comprueba que todas comprobaciones hayan sido realizadas, y si no es el caso se vuelve atrás para realizar las acciones omitidas. Al utilizar una lista de comprobación, pueden ser útiles las siguientes practicas: 1. Revisar todo el programa para cada apartado de la lista de comprobación. 2. Cuando se encuentra un defecto, se anota con una marca en la primera columna libre (#). Cada columna # se usa para cada revisión completa 3. Después de completar cada comprobación, si no se han encontrado defectos, se escribe X en la primera casilla no utilizada de la columna # 4. Hacer un examen final global de todo el programa para buscar lo inesperado,

Elaboración de una lista de comprobación personal La lista de comprobación debe estar personalizada para el lenguaje usado y para  los defectos que cada ingeniero  en particular encuentra y/o omite. Recomendaciones: 1. Hacer una lista clasificada con los defectos en cada fase del proceso software. 2. Clasificar los tipos de defectos en orden descendente del numero de defectos encontrados en las fases de compilación y pruebas. 3. Para los tipos con el mas defectos, examinar el Cuaderno de Registro de defectos y averiguar los errores específicos que causan estos tipos 4. Para los defectos que resultan de los problemas mas importantes, idear las pasos necesarios en la revisión de código para encontrarlos. 5. Registrar las comprobaciones ideadas en la lista de comprobación. 6. Agrupar las pruebas parecidas en la lista de comprobación. 7. Después de desarrollar cada programa, examinar los datos de defectos y la lista de comprobación para identificar los cambios o adiciones útiles.

La previsión de defectos Utilización de los datos de defectos. La disciplina personal, asociada con la revisión de defectos y su análisis, es mucho mas efectiva que los años de experiencia para la reducción del numero de defectos introducidos. Reunir los datos de defectos permiten comprender los defectos introducidos, diseñar una lista de comprobación personal para la revisión de código y también para estimar el numero de defectos que se introducirán en un nuevo programa. Las estimaciones exactas del grado de defectos son importantes ya que pueden fundamentar la necesidad de una nueva del código.