Iturribizia, S.L.

Ingeniería estructural

Criterios seguidos para el desarrollo del programa

De la experiencia adquirida en las labores de desarrollo realizadas con anterioridad se obtuvieron las siguientes conclusiones:

  1. Probar, comprobar y recomprobar. Para cada funcionalidad del programa se deberá escribir un test de verificación que permita comprobar la corrección del código. Además para cada modificación del código que se haga se deberá verificar que se completa correctamente toda la batería de test escrita hasta el momento. De este modo se hace más difícil introducir errores en el código inadvertidamente (alguien dijo que un ordenador es una máquina que permite cometer miles de errores en muy poco tiempo). A pesar de esto se detectarán errores para los que también se deberá escribir un test de comprobación que permita verificar que no vuelven a repetirse.
  2. No reinventar la rueda. Emplear tanto como sea posible las bibliotecas de fuente abierta a las que puede accederse fácilmente a través de Internet. Siempre que, para alguna de las funciones del programa, es posible delegar la escritura del código (solución de sistemas de ecuaciones, procesamiento paralelo (MPI), teoría de grafos, etc.) debe hacerse así.
  3. No perder el tiempo en el desarrollo de un elegante GUI (Graphics User Interface). Esto probablemente resulte bastante impopular porque las interfaces gráficas de usuario crean en él la ilusión de que sabe manejar el programa {dice José Calavera que los programas se hacen para que los que saben calcular lo hagan más rápido no para que calculen los que no saben hacerlo}. Permiten adoptar un rocedimiento de prueba y error que, a nuestro juicio, quizá pueda ser adecuado para manejar un procesador de textos en el que el resultado queda a la vista, pero no lo es tanto para un programa de cálculo cuyo manejo requiere una concienzuda revisión de los datos e hipótesis de partida. Por otra parte el empleo de un lenguaje de macros dota al programa de una flexibilidad mucho mayor. Basta pensar que para definir un segmento de recta se podrá hacer mediante dos puntos, un punto y un vector, un punto, una longitud y un ángulo, la intersección de dos planos, etc. Esta flexibilidad es prácticamente imposible de conseguir con una interfaz gráfica de usuario y ello a un coste exorbitante en tiempo de desarrollo.
  4. La normas cambian, las leyes físicas permanecen. Mientras que, en lo que se refiere a la solución del problema mecánico seguimos manejando las leyes de la mecánica newtoniana, los avances en el conocimiento del comportamiento de los materiales y los cambios en el nivel de exigencia de la sociedad respecto al nivel de calidad exigible a sus infraestructuras, hacen que periódicamente se renueve el contenido de las normas de diseño (EHE,EAE,\ldots). En consecuencia, y dado que no existe la necesidad de ocultar el código al usuario, se procurará escribir los algoritmos relativos a la normativa (comprobaciones,...) en forma de macros del intérprete de comandos que pueden modificarse con facilidad, reservando la escritura de código en C++ para aquellos algoritmos que expresan leyes más estables (equilibrio de fuerzas, inercia, modelos constitutivos de los materiales, etc.).