Garantía de Calidad del Software: Mejores Prácticas

Problemas Principales en el Desarrollo de Software

Problemas principales en el desarrollo de software:

• Especificaciones no probadas
• La mayoría del software no está pensado para soportar cambios futuros
• Dificultad para comprender el programa de alguien más
• Dificultad para rastrear la evolución del software en diferentes versiones
• Falta de experiencia en el tiempo de aplicación

Causas:

• Mal diseño
• Cambios al vapor (al momento) sin evaluar el impacto
• No siguen una metodología estándar
• Presiones de tiempo que provocan que el software sea liberado antes de probarlo

Garantía de Calidad del Software

1. Documentación - Planeación y Análisis de un Software

• Hojas numeradas # / total
• Fecha de elaboración
• Título
• Responsable
• Identificación de la empresa (logo)
• Versión
• Aprobó

2. Aplicación de Metodologías y Técnicas

Debe tener una metodología y un proceso que asegure su aplicación.

3. Realización de Revisiones Formales

• Revisión: personal interno
• Inspección: personal externo

Puntos de inspección:

• Inspeccionar el producto, no al productor
• Fijar una agenda y mantenerla
• Limitar el debate y las impugnaciones

4. Pruebas de Software

Clasificación ortogonal: una falla debe caer en una categoría de falla y no en varias.

a) Fallas de Programa

(Consiste en probar algoritmos, datos y sintaxis contra las especificaciones)

• Error de lógica: 32%
• Error de cálculo: 18%
• Documentación: 19%
• Código de terceros: 11%
• Manejo de datos: 6%
• Requerimientos: 5%
• Hardware: 4%

b) Fallas de Algoritmo

(Ocurre cuando un componente lógico no produce la salida adecuada para una entrada, porque algo está mal en los pasos de procesamiento)

• Mala sintaxis
• Derivaciones fuera de tiempo
• Condición equivocada
• Olvido de inicialización de ciclos
• Olvido de probar condiciones específicas

c) Fallas de Precisión

(Ocurre cuando la implementación de una fórmula está equivocada)

• Mezcla de tipos
• Orden de operaciones
• Truncamiento y redondeos

d) Fallas de Documentación

(Ocurre cuando la documentación no corresponde con lo que el programa hace)

• Deficiente actualización
• Mala interpretación del diseño

e) Fallas de Estrés

(Ocurre cuando las estructuras de datos sobrepasan su capacidad específica)

• Mala especificación de requerimientos

f) Fallo de Sincronización

(Ocurre cuando la coordinación de eventos simultáneos es equivocada)

• Problema de diseño en la anticipación de estados

g) Fallas de Actuación (Performance)

(Ocurre cuando el sistema no actúa a la velocidad necesaria)

• Mala especificación de requerimientos

h) Fallas de Recuperación

(Ocurre cuando un sistema no se recupera de una falla inesperada por sí mismo)

• Mala especificación
• Mal diseño
• Mala validación

i) Fallas de HW/SW Externo

(Ocurre cuando falla un componente de terceros)

• Fiabilidad de componentes reutilizables

Pruebas: Unitarias / Caja Negra / Caja Blanca

1) Definición de Pruebas Unitarias

Verifican el correcto funcionamiento de cada componente de código a partir del estudio del diseño de software. Estas pruebas sirven para asegurar que cada uno de los componentes funciona por separado.

Diseño Arquitectónico del Sistema (Diagrama)

Técnicas formales: consiste en que el programa es visto como un conjunto de axiomas y teoremas; si se prueba la validez del teorema, esto implica que el código es correcto.

Ventajas:

• Es una prueba muy precisa y rigurosa

Desventajas:

• Muy costosa, se lleva mucho tiempo y es difícil

PSL/PSA, RSL/REUS, Lenguaje Z.

2) Caja Negra

El programa es visto por un conjunto de estados donde se verifica que un estado de entrada produce el estado de salida correcto. Se llama caja negra porque el código no es revisado.

Ventajas:

• Lleva menos tiempo

Desventajas:

• Tiene que considerar todos los casos posibles