the tarpit

The Tar Pit (El pozo de alquitrán)
Ninguna escena es tan intensa como los esfuerzos de las bestias por mantenerse con vida en los posos de Alquitran. En el ojo de la mente podemos ver Dinosaurios, mamuts y dientes de sable, esforzándose por escapar del alquitran. Entre mas luchan por escapar, mas se unden en el alquitran, y ninguna bestia es tan fuerte ni habilidosa, que al final, terminasumergiéndose en el alquitran.
Los grandes proyectos de programación han sido durante la ultima década, un ejemplo de pozos de alquitran. Y muchas grandes y poderosas bestias se han sumergido en el. La mayoría ha logrado salir con sistemas ejecutables. Unos cuantos han conseguido sus metas, terminaron en la fecha establecida, el presupuesto establecido, grande y pequeño, complicado o sencillo, equipotras equipo se ha vuelto a manchar en el alquitrán. Ninguno parece provocar esta situación. Cualquier garra parece atraer por completo a la bestia. Pero el conjunto de factores simultaneos o interactivos, alentiza su hundimiento. Todos parecen sorpenderse con lo pegajoso que es el problema y es difícil darse cuenta de la naturaleza que hay en el, pero debemos intentar resolver si somos nosotroscapaces de resolverlos
Por lo tanto, dejenos iniciar identificando la artesanía del sistema de programación, y las ventajas y desventajas que existen en este.
La Programacion de sistemas.
Una vez leí en el diario la noticia de cómo 2 programadores e un garaje, construyeron un programa tan importante que superaba los esfuerzos de numerosos equipos de programación, y cada proramador esta preparadopara creer en tales cuentos. El sabia que podría construir cualquier programa mas rápido que equipos industriales, con 1000 declaraciones por año.
Entonces porque los equipos de programación industrial no han sido reemplazados por dúos de programadores de garage? Demos un viztaso a lo que se esta produciendo.
En la parte superior izquierda de la fig. 1.1 hay un programa independiente., listopara er ejecutado por el autor, en el sistema en el cual fue desarrollado, lo cual ocurre habitualmente en los garajes, y esa es la cuestión que un programador individual usa para estimar productividad.













Figura 1.1 Evolución en la programación de sistemas.
Hay 2 maneras en las que un programa se puede tranformar en un programa mas útil, pero mas costoso. Estas 2 maneras larepresentan los limites en el diagrama.
Recorriendo hacia el cuadro de abajo, el programa se transforma en producto, pude ser ejecutado, reparado, probado y extendido por cualquier persona. Es útil en muchos ambientes oprativos, para muchos conjuntos de datos. Para convertirlo en un producto generalmente funcional, debe escribirse en un estilo general. En particular el alcanze y forma de lasentradas deben generalizarse tanto como el algoritmo básico nos permita. Entonces el programa debe ser probado a fondo, de manera que podamos depender de el. Esto significa que un banco substancial de casos de prueba, explorando el rango de las entradas y sondeando los limites, debe estar preparado, ejecutarse y grabarse. Finalmente, la transición de un programa a un producto implica su documentaciónexplicita, para que cualquiera pueda usarlo, repararlo y expandirlo. Como una regla de oro, estimo que un producto cuesta almenos 3 veces mas que un programa sin errores con la misma función.
Recorriendo al figura hacia el cuadro derecho, un programa se vuelve un cmponente en un sistema de programación, esto es una colección de programas interactivos, coordinados en función, y disciplinados enformato, asi que el ensamblaje constituye una gran facilidad para grandes tareas. Para convertirse en un componente de sistemas de programas, debe escribirse de tal manera que cada entrada y salida, complementen en sintaxis y semantica, con interfaces muy precisamente definidas. El programa también debe estar prediseñado para que solamente use un presupuesto de recursos preescrito- espacio de...