6.6 Administración de defectos

Presentación del tema: "6.6 Administración de defectos"— Transcripción de la presentación:

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

2 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.

3 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.

4 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.

5 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.

6 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.

7 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:

8 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,

9

10 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.

11 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.