PDF de programación - Parte I: El computador y el proceso de programación - 4. Verificación de programas

Parte I: El computador y el proceso de
programación
• 1.Introducción a los computadores y su programación
• 2. Introducción al análisis y diseño de algoritmos
• 3. Introducción al análisis y diseño de programas
• 4. Verificación de programas

UNIVERSIDAD
DE CANTABRIA

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN
4

© Michael González Harbour

19/ma/09

1

Notas:

UNIVERSIDAD
DE CANTABRIA

1. Introducción a los computadores y su programación

• Arquitectura básica de un computador.El software del sistema. Lenguajes de Alto Nivel. El proceso de

compilación. El ciclo de vida del software.

2. Introducción al análisis y diseño de algoritmos.

• Diseño de un programa. Concepto de algoritmo. Descripción de algoritmos: el pseudolenguaje.

Tiempo de ejecución de algoritmos. La notación O(n). Ejemplos de análisis.

3. Introducción al análisis y diseño de programas

• Actividades del ciclo de vida del software. Paradigmas de desarrollo de programas. Análisis y

especificación. Diseño arquitectónico. Técnicas de diseño detallado.

4. Verificación de programas

• Importancia de la verificación. Estrategias de prueba. Depuración. Elección de datos para la prueba.

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

2

1. Importancia de la verificación
Aproximadamente la mitad del esfuerzo total del desarrollo se
emplea en las pruebas del programa.
La prueba de un programa depende mucho de su dimensión
• cuanto más grande es el programa más etapas son necesarias

UNIVERSIDAD
DE CANTABRIA

en el proceso de prueba.

Para las pruebas de un programa debe hacerse una planificación
rigurosa.
Para probar un programa incompleto o módulos de programa es
necesario escribir software de prueba
• en ocasiones, el software de prueba es más grande que el propio

programa.

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

3

Notas:

UNIVERSIDAD
DE CANTABRIA

Cuando tratamos el esfuerzo necesario para el desarrollo de un sistema software, vimos que
aproximadamente la mitad del esfuerzo total se empleaba en las pruebas del programa, lo cual pone de
manifiesto la gran importancia de esta etapa del desarrollo.

Según sea la dimensión del programa la problemática asociada a las pruebas de un programa pueden ser
completamente diferentes. En programas grandes normalmente la prueba necesita mayor número de
etapas que en programas pequeños.

Al igual que para el diseño de un programa, para su prueba es necesario hacer una planificación cuidadosa
de todos los elementos que se van a probar. Para ello, se suele elaborar un documento de pruebas, incluso
antes de escribir el programa. El rango de las técnicas empleadas para la prueba de programas es muy
amplio, y abarca desde el estudio de viabilidad de las especificaciones hasta los programas generadores
de las secuencias de pruebas.

Cuando se prueba un programa incompleto o un módulo de programa, es necesario crear software de
prueba, que permite introducir o recoger los datos y eventos necesarios. En programas grandes es habitual
que el software de pruebas sea más voluminoso que el propio programa.

El software de pruebas de un programa debe conservarse, para poder probar de nuevo el programa cuando
se hagan modificaciones.

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

4

Dependencia con el tamaño del
programa

UNIVERSIDAD
DE CANTABRIA

Categoría

Simple

Complejidad
intermedia

Complejo

Características

- < 1000 instrucciones
- 1 persona, < 6 meses
- Sin interacciones con otros programas

- < 10.000 instrucciones
- 1-5 personas, < 2 años
- Pocas interacciones con otros sistemas
- 10 a 100 módulos

- < 100.000 instrucciones
- 5-20 personas, < 3 años
- Frecuentemente interacciona con otros

sistemas.

- 100 a 1000 módulos.

Dependencia
Del programador

Del programador y
de la dirección

Técnicas modernas
de diseño y direc-
ción

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

5

Categoría
Muy complejo

Super com-
plejo

Notas:

Características

- < 106 instrucciones
- 20-100 programadores
- Requiere mantenimiento continuo y por

gente distinta.

- Fuertes interacciones con otros sistemas.
- 1000 a 10.000 módulos

- > 106 instrucciones
- > 100 programadores
- Requiere mantenimiento continuo y por

gente distinta.

- Casi siempre incluye procesado en tiempo

real, telecomunicaciones, etc.

- Corresponde, generalmente, a procesos

críticos (tráfico aéreo, defensa, etc.)

UNIVERSIDAD
DE CANTABRIA

Dependencia

Técnicas modernas
de diseño y dirección

Idem

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

6

UNIVERSIDAD
DE CANTABRIA

Definiciones básicas
Prueba o “Test”: ejecución para encontrar errores
Demostración: prueba matemática por inspección del código
Verificación: búsqueda de fallos en ambiente simulado
Validación: comprobación en el ambiente real
Certificación: se certifica la corrección cuando se han probado
exhaustivamente todas las posibilidades
Depuración o “Debugging”: localizar y corregir errores

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

7

Notas:

UNIVERSIDAD
DE CANTABRIA

Testing o Prueba: Es el proceso de ejecución de un programa (o parte de él) con la intención o meta de
encontrar errores.

Demostración: Es un intento de encontrar errores si tener en cuenta el ambiente del programa. Es decir, se
trata de obtener o probar teoremas matemáticos acerca de la corrección de un programa.

Verificación: Es un intento de encontrar errores en un ambiente de test o simulado.

Validación: Es un intento de encontrar errores ejecutando un programa en un ambiente real dado.

Certificación: Es un certificado de corrección. La prueba para certificación debe realizarse sobre algún tipo
de estándar predefinido.

Depuración: No es una forma de prueba y, aunque a veces las palabras depuración y prueba se usan de
forma intercambiable, son actividades distintas. La prueba es una actividad de encontrar errores, y la
depuración es la actividad de diagnosticar la naturaleza precisa de un error, conocerlo y corregirlo. Las dos
están relacionadas porque la salida de una actividad de prueba es la entrada de una actividad de
depuración.

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

8

Relación: prueba-diseño

UNIVERSIDAD
DE CANTABRIA

Diseño

Requerimientos

Prueba de instalación

Prueba

Especificación

Diseño arquitectura

Diseño detallado

Prueba de aceptación

Prueba de sistema

Pruebas Funcionales

Prueba de Integración

Codificación

Prueba de módulos

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

9

Notas:

UNIVERSIDAD
DE CANTABRIA

Prueba de módulo: Consiste en probar cada módulo de programa individualmente. Cuando tratamos un
programa pequeño, generalmente es desarrollado y probado como una utilidad única y por una sola
persona.

Prueba de integración: En la prueba de módulos normalmente no se encuentran los errores relacionados
con la interacción entre los diferentes módulos. El proceso de juntar los diferentes módulos individuales
para realizar subsecciones o funciones de un programa se denomina integración de sistemas. Cuando se
utilizan pruebas para averiguar la corrección de las interfaces entre los módulos se denomina a este
proceso de prueba, prueba de integración.

Pruebas de función y de sistema: En estas pruebas se analiza el funcionamiento de los módulos ya unidos
para comprobar su correcto funcionamiento conjunto en una función o subsistema del programa (prueba
de función), o del programa completo (prueba de sistema).

Prueba de aceptación: Es el proceso de prueba realizado sobre el programa completo, en ambiente
simulado o de prueba, para darlo por válido. Requiere la prueba bajo las condiciones más variadas.
Normalmente participa el usuario, que da su visto bueno.

Prueba de instalación: Es el proceso de prueba realizado con el programa funcionando en su sistema y
ambiente real, una vez instalado.

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

10

2.Comparación entre las distintas
técnicas de prueba
TOP-DOWN:

UNIVERSIDAD
DE CANTABRIA

Características

Ventajas

Desventajas

- El programa principal o de

- No necesita programas

“driver” de prueba

control se prueba en
primer lugar

- Los módulos se integran

uno por uno

- Se hace hincapié en las
pruebas de las interfaces

- Necesita módulos

simulados (“stubs”)

- El programa de control y

- Los errores en los módulos

unos pocos módulos
forman un prototipo básico

- Los errores de interfaces

se detectan pronto

- La característica modular

ayuda a la depuración

críticos se encuentran en
último lugar

DEPARTAMENTO DE MATEMÁTICAS,
ESTADÍSTICA Y COMPUTACIÓN

© Michael González Harbour

19/ma/09

11

Notas:

UNIVERSIDAD
DE CANTABRIA

Cuando se realiza un diseño top-down o bottom-up puro, lo más lógico es realizar también la prueba con la
misma técnica.

En el caso de una prueba top-down, ésta comienza analizando el funcionamiento del flujo de control del
programa principal examinando cómo pasa el control y los datos a los distintos módulos, cómo éstos los
devuelven y cómo el programa de control pasa los datos a los dispositivos de salida.

Para ello, se necesita incluir en esta fase del desarrollo un cierto conjunto de instrucciones en cada módulo,
aún cuando éstos aún no han sido diseñados. A estos módulos simplificados que permiten la prueba se les
denomina “stubs”.

Los “stubs” incluyen la implementación de las interfaces del módulo y un conjunto, normalmente sencillo,
de código para su utilización en el test. La complejidad de estos módulos simulados vendrá en función del
interés por profundizar en el funcionamiento del sistema.