Diseño Libre de Errores

Corrigiendo errores en la definición. 

Los errores más perniciosos y sutiles son los errores del sistema que surgen de suposiciones
incompatibles hechas por los autores de distintos componentes. La integridad conceptual del
producto no solo facilita su uso, también facilita su construcción y lo hace menos propenso a errores.

Para reducir el número de errores en el sistema se necesita una meticulosa revisión del problema
y una cuidadosa descomposición.

Prueba de la especificación

Esta prueba se trata de entregar el algoritmo creado a un grupo de prueba externo para el escrutinio
de su completitud y claridad mucho antes de pasar a formar el código.

Diseño descendente

 Las ideas de Niklaus Wirth establecidas para el diseño de programas, se aplican completamente al
diseño de sistemas complejos de programas. Brevemente, el procedimiento de Wirth es identificar el
diseño como una secuencia de pasos de refinamiento.

Se da un problema y un método de solución aproximado que consiga el resultado principal. Después

se examina el problema con mayor atención y se observa cómo difiere el resultado del que se
desea, y se descomponen los pasos grandes de la solución en pasos más pequeños. Cada
refinamiento del problema llega a ser un refinamiento en el algoritmo de la solución, y cada uno
puede ir acompañado por un refinamiento en la representación de los datos. A partir de este
proceso, se identifican módulos de solución o de datos cuyo refinamiento adicional puede proceder
independientemente de otro trabajo.

4Ventajas

Primero, la claridad de la estructura y su representación facilita el planteamiento preciso de los

requisitos y funciones de los módulos. Segundo, el particionamiento e independencia de los
módulos evita errores del sistema. Tercero, la supresión de detalles hace que los defectos en la
estructura sean más evidentes. Cuarto, el diseño se puede probar en cada uno de sus pasos de
refinamiento, así que las pruebas pueden empezar más pronto y concentrarse en el nivel de
detalle adecuado en cada paso.

Programación Estructurada

El enfoque de esta estructura teórica según Böhm y Jacopini es básicamente diseñar programas
cuyas estructuras de control consistan solo de lazos definidos por una declaración tal como DO
WHILE, y secciones condicionales delineadas en grupos de declaraciones marcadas con corchetes y
condicionadas por un IF ... THEN ... ELSE.

Se han hecho muchas críticas y se han elaborado estructuras de control adicionales, tales como una
bifurcación de caminos para distinguir entre muchas posibilidades, y una salida del desastre son muy
prácticas. El punto importante y vital para construir programas libres de errores, es que uno quiera
pensar acerca de las estructuras de control de un sistema como si fueran estructuras de control, no
como declaraciones individuales de bifurcación.

Depuración de Componentes

La depuración en la computadora. 
En primer lugar se usó la consola ya que la cinta de entrada-salida era muy lenta. De esta manera la
depuración se diseñó para permitir tantas pruebas como fuera posible por sesión de máquina. El
programador diseñaba meticulosamente su procedimiento de depuración planificando dónde
parar, qué localidades de memoria examinar, qué encontrar ahí y qué hacer si no lo encontraba. Esta
programación meticulosa de sí mismo como una máquina de depuración bien podía durar casi la
mitad del tiempo dedicado a la escritura del programa a ser depurado. El pecado cardinal era oprimir
START audazmente sin haber segmentado el programa en secciones de prueba con paradas
planificadas. La depuración en computadora fue muy eficaz. Se ejecutaba un programa hasta que
fallaba la verificación, y entonces se volcaba toda la memoria.

Volcado de memoria

En una sesión de dos horas, se podía obtener quizá una docena de ejecuciones. Pero las
computadoras eran muy escasas, y muy costosas.

Cuando se conectaron en línea las impresoras de alta velocidad, cambió la técnica. Se

ejecutaba un programa hasta que fallaba la verificación, y entonces se volcaba toda la
memoria. Luego empezaba la tarea de escritorio, verificando el contenido de cada localidad de
memoria. El tiempo de escritorio no era muy diferente al tiempo de la depuración en la
computadora; pero sucedía después de ejecutar la prueba, en el desciframiento, y no como
antes, en la planificación. Para cualquier usuario depurar tomaba mucho más tiempo, porque
las ejecuciones de prueba dependían del tiempo de respuesta de la ejecución por lotes. Sin
embargo, todo el procedimiento fue diseñado para minimizar el tiempo de uso de la
computadora, y servir a tantos programadores como fuera posible

Copias del Estado del Sistema. 

El volcado total de la memoria comenzó a ser impráctico ya que las capacidades de memorias
crecieron. Así que se desarrollaron técnicas de volcado de memoria selectivo, trazado selectivo y
para la inserción de copias del estado del sistema dentro de los programas. El OS/360 TESTRAN es
el último en esta dirección, permite insertar copias del estado del sistema dentro de un programa sin
necesidad de ensamblar o compilar nuevamente. Depuración interactiva.

Depuración interactiva

Se trata de una computadora que tendría múltiples programas en memoria listos para su
ejecución. Una terminal, controlada solo por programa, estaría asociada con cada programa en
proceso de depuración. La depuración estaría bajo control de un programa supervisor. Cuando el
programador a través de una terminal detenía su programa para examinar el avance o para hacer
cambios, el supervisor ejecutaría otro programa, manteniendo así ocupada la computadora.

La Depuración del Sistema

Depurar un sistema tomará más tiempo de lo esperado, y su dificultad justifica un enfoque

minuciosamente sistemático y planificado. Veamos ahora qué implica este enfoque.
Use componentes depurados

Esto dicta que se debe empezar a depurar el sistema solo después de que las piezas parecen
funcionar, que el algoritmo parece estar resuelto para así obtener un mejor resultado a la hora de
depurar y no perder el tiempo en errores visibles. 
Construir con abundante andamiaje. 

El andamiaje son todos los programas y datos construidos con fines de depuración que nunca
pretendieron formar parte del producto final. 

 Una forma de andamiaje es el componente ficticio, que consta solo de interfaces y quizás de

algunos datos falsos o algunos pequeños casos de prueba. Por ejemplo, un sistema puede incluir un
programa de clasificación que no esté todavía terminado.
Aún otra forma de andamiaje son los programas auxiliares. Generadores de datos de
prueba, impresiones de análisis especiales y analizadores de tablas de referencias cruzadas, todos
ellos son ejemplos de plantillas y accesorios de propósito especial que uno puede desear construir

Control de cambios.

La programación necesita marcar los errores encontrados y que fueron solucionados para tener un
sistema de respaldo. Le hace mucha falta un control riguroso

Añadir un componente a la vez

Este precepto, también, es obvio, aunque el optimismo y la pereza nos incitan a violarlo. Hacerlo

requiere componentes ficticios y otro andamiaje, y eso requiere trabajo. 

Cuantificar las actualizaciones

El reemplazo de un componente en operación por una versión nueva requiere el mismo

procedimiento sistemático de prueba que agregar un nuevo componente, aunque debería tomar
menos tiempo, ya que generalmente estarán disponibles casos de prueba más completos y
eficientes. Todo equipo que construye otro componente ha estado usando la versión más
recientemente probada del sistema integrado como banco de pruebas para depurar su pieza. Su
trabajo se retrasará por tener que cambiar el banco de pruebas subyacente. Luego, cada usuario tiene
un periodo de estabilidad productiva, interrumpido por ráfagas de cambio en el banco de pruebas.

Se mantiene el parche rápido hasta la siguiente liberación normal del componente, que debe
incorporar la reparación en forma probada y documentada.