Software y la teoría del caos, un enfoque despreocupado - La causa del problema

Claro que este escenario no es nada nuevo. Hace ya cerca de veinte añ os se crearon diferentes metodologías para disciplinar los proyectos de software utilizando prácticas estándares de ingeniería. A pesar de esto, la situac ión ha permanecido igual y los creadores de metodologías dicen que la culpa ha sido por la lenta adopci ón de sus propuestas. Después de todos estos a ños, uno se pregunta por qué el mercado ha sido tan reticente en adoptarlas, si en realidad estas metodologías pueden resolver problemas tan costosos.

---

De hecho, voceros respetados de la comunidad del desarrollo sugieren que las así llamadas metodologías monumentales pueden haber causado má s da ños que beneficios y que la situación parece que se ha tornado más grave desde el inicio del Internet y el increíble aumento de la velocidad en los cambios en los modelos de negocios. Estos voceros piensan que las metodologías monumentales surgieron de paradigmas mal concebidos, como por ejemplo, que la ingenierí a de software se asemeja a la eléctrica, química y especialmente a la civil. Según un aná lisis posterior (que se ha demorado quince añ os en llevar a cabo), existen algunas diferencias Fundamentales
1. En la ingeniería civil, usted hace un aná lisis detenido y un diseñ o del producto a fabricar y luego ejecuta un proceso de construcció n bastante caro, pero en términos generales rutinario y sin mayores cambios. Esto es posible solamente porque el producto fue comprendido muy bien, es relativamente simple y (especialmente) las necesidades y leyes físicas no cambiaban.

---

La mayoría de proyectos de software trata de capturar relaciones complejas y siempre cambiantes y flujos de trabajo, ademá s de una teorí a unificada de có mo funcionan las organizaciones humanas. No existe todaví a una teorí a que pueda convertir tales sistemas en algo tan predecible como, por ejemplo, la resistencia de los materiales.

---

2. Algunas investigaciones sugieren que la creación de software es un ejercicio continuo de diseñ o (es decir: hallar una solució n, construirla, ver si funciona, si funciona, ir al pró ximo reto, sino comenzar de nuevo.) Esto hace que el centro dte gravedad econó mico del proyecto se aleje de la construcció n repetitiva y se acerque al lado creativo. En este sentido, los proyectos de software se asemejan má s a los departamentos de investigació n y desarrollo que a las fá bricas.

---

3. El aná lisis y dise ño de la ingenierí a civil se llevan a cabo por gente muy inteligente y preparada, en cambio la fabricació n en sí puede ser realizada por gente menos preparada. En ingenierí a de software, profesionales igual de inteligentes y preparados se dedican a la construcció n. Si uno contrata programadores no muy listos que escriben có digo sin pensar mucho al respecto para cumplir especificaciones, es poco probable que se logre un proyecto exitoso. Una consecuencia muy importante es la siguiente: en la ingeniería civil, los mé todos de trabajo pueden ser impuestos por una autoridad, en cambio en ingeniería de software, el lí der debe convencer a sus compañ eros. Tenemos que darnos cuenta de que sí existen proyectos de software con especificaciones fijas y que se pueden comprender de manera razonable. En estos casos la mentalidad de la ingenierí a civil funcionar muy bien. Lamentablemente, tengo el presentimiento de que la mayoría de proyectos de software no cumple estos pará metros y en estos casos, la escuela de administració n basada en "aná lisis/diseñ o/definició n de tareas y costos/creació n de calendarios/construcció n siguiendo planes" no es adecuada.