6.6 Administración de defectos

Slides:



Advertisements
Presentaciones similares
6.6 Administración de defectos
Advertisements

HERRAMIENTAS ESTADÍSTICAS PARA LA SOLUCIÓN DE PROBLEMAS INGENIERIA INDUSTRIAL UNIVERSIDAD POLITECNICA DE EL SALVADOR.
Verificación y Validación de Software
-SON LOS ESTANDARES BASICOS DEL APRENDIZAJE MATRIZ DE REFERENCIA COMPETENCIA -SON LOS ESTANDARES BASICOS DEL APRENDIZAJE -LOS DBA COMPONENTE SON LAS.
Modelado de sistemas software: Introducción. Modelado de... Sistemas... Sistemas web Sistemas de control/tiempo real Familias de sistemas Variabilidad.
Diseño personal del Software. Una medida significativa en la mejora de calidad del software fue tomada con la esencia del proceso personal del software.
Método ZOPP Método ZOPP Proceso de Proceso de Planeación Participativa
UNIVERSIDAD TECNOLOGICA DE NEZAHUALCOYOTL División de Administración Ingeniería en Negocios Profesor: Ricardo Yebra Romero MERCADOTECNIA Alumno: I. Sharazan.
REDACCION DE INFORMES NORMAS ICONTEC. GUIA PARA LA ELABORACION DEL INFORME O PROYECTO FINAL DE PRACTICAS.
A NÁLISIS L ÉXICO Y ANÁLISIS SINTÁCTICO. COMPILADORES ANÁLISIS LÉXICO Y ANÁLISIS SINTÁCTICO ANGIE EVILLA LUQUEZ CORPORACIÓN UNIVERSITARIA REMINGTON INGENIERÍA.
MODELO ADDIE Módulo 2. 1.Fundamentos teóricos ADDIE Análisis Diseño Desarrollo Implementación Evaluación Prototipación rápida 2.Actividad de clase.
Programación INSTITUTO EVANGELICO LUZ Y VERDAD Nombre: Karoline Cañas Profesor: Moisés Bados Director: Armando Santos.
CONOCIMIENTO CIENTÍFICO INVESTIGACIÓN CIENTÍFICA El método científico es un procedimiento para descubrir las condiciones en que se presentan sucesos específicos,
TEMA: PSP (Personal Software Process) ANALISIS DE SISTEMAS I ING. EDGAR RAUL MOLINA INTEGRAMTES: HANNSEL E. CORDON AC JESSICA IDALMY KRESS FREDERIC HESTIB.
PROGRAMA ÚNICO DE CAPACITACIÓN DOCENTE
Mejores Prácticas en Proyectos de Desarrollo de Software
Tema 4: Ingeniería del Software
Programas de Auditoria Las NIA establecen: NAGUN establecen la obligatoriedad de llevar programas de Auditoria: NAGUN PROGRAMAS.
Unidad 2: LAS ETAPAS DE LA SIMULACION NUMERICA. Tema: 2
La planeación y la organización de los procesos técnicos.
2.Metodología de Solución de Problemas
Proyecto de Software. t07
ACCIONES CORRECTIVAS Y PREVENTIVAS
EJERCICIOS DE DIAGRAMA DE FLUJO
Fundamentos de negocios y comercio electrónico.
Los sistemas de información
Proyecto de Software. Clase 06
Introducción a los algoritmos
introducción Ingeniería de software
PROCESO DE DISEÑO Conceptos de Creatividad e Innovación
El resultado obtenido en esta etapa son las especificaciones de lo que se debe hacer para solucionar el problema.
Administración Basada en Actividades
5. Análisis y diseño de sistemas secuenciales (II)
Tema 6. Conceptos básicos de programación Clase 1
DESARROLLO ORGANIZACIONAL
Erika Castiblanco - umb virtual
PROYECTO TECNOLÓGICO.
ANALISIS DE PARETO Manuel Yáñez Arzola.
HABILIDADES COGNITIVAS
Maestría en Gestión Sustentable de Recursos Naturales
Las herramientas Case Julian madrigal.
Unidad 2.- Marcos de referencia en la gestión de servicios de TI
INTRODUCCION A LA ADMINISTRACION
Proceso Unificado de Desarrollo de Software
Marco Lógico.
Establecimiento de un Sistema de Documentación y Registros Paso Duodécimo / Principio 7 CAPÍTULO 3 Mod 12 El sistema de Análisis de Peligros y de Puntos.
Verificación y Validación de Software
«CUADROS SINOPTICOS DE LAS FASES DEL MODELO DEL CICLO DE VIDA.»
PROYECTO TECNOLÓGICO.
CC51A – Ingeniería de Software
MODELO ADDIE. MODELO ADDIE El modelo ADDIE es un proceso de diseño Instruccional interactivo, en donde los resultados de la evaluación formativa de.
ESCUELA DE MERCADOTECNIA
Método de casos (asociado a solución de problemas)
La planeación y la organización de los procesos técnicos.
SOFTWARE.
Calidad en la Prueba de Software
Fundamentos de la Programación I
Aplicación de PSP (Personal Software Process)
Tema 2 Sistemas de información y la organización
NO CONFORMIDAD ACCION CORRECTIVA
INTRODUCCION AL DISEÑO DEL SOTFWARE EDUCATIVO
Institución a la que pertenece
Inicia 5 de marzo y termina 1 de octubre 2007
¿Qué… cuándo… cómo… evaluar?
Gerencia de Seguimiento Normativo de los Programas de Apoyos
Carlos Manuel Ortega Avila
CICLO ESCOLAR
ANALISIS DE RIESGOS POR OFICIO
HOJA DE VERIFICACIÓN DE CALIDAD. Una hoja de verificación es una herramienta expresada en un formato que se utiliza para recolectar de manera estructurada.
Gestión de Proyectos Informáticos (GPI) ISW
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.