Parece mentira, pero el mundo del software, y en general de las tecnologías de la información, esta lleno de grandes fracasos. Algunos de ellos, realmente estrepitosos. Muchos de los sistemas de información que causan y han causado problemas lo han hecho por no prever factores externos ("No mandé mis naves a luchar contra los elementos", que dicen que dijo Felipe II como excusa barata), y otras muchas, simplemente porque fueron realizadas sin un cuidadoso estudio previo.

En otras ramas de la industria, o en general, de la producción de bienes o servicios distintas a la del sofware, mucho antes de que empiece la producción se realizan tareas de análisis, planificación, estudio de riesgos, costes, plazos... y cuando todo está atado y bien atado es cuando empieza la producción. ¿Te imaginas que para construir un edificio se empiecen a poner ladrillos y cemento directamente sin unos planos, un estudio de materiales, del terreno...? ¿Te imaginas a los empleados de algún gran fabricante de automóviles cogiendo cuatro ruedas, un motor, etc... a su aire y uniendo las piezas como pueden? ¿Te imaginas a algún@ modist@ de alta costura tijera en ristre delante de la máquina de coser haciendo los trajes directamente sin diseño previo, patrones, pruebas....? No ¿verdad?... pues en el desarrollo de software y sistemas de información pasa muy a menudo... en cuanto se tienen cuatro cosas claras... ¡A programar!

No... ese no es el camino. Poner ladrillos sin hacer planos puede funcionar para construir una jardinera, pero no una casa. Juntar cuatro ruedas con un motor y un volante puede funcionar para construir un pequeño vehículo de juguete, pero no un automóvil funcional y seguro. Ponerse a cortar tela y coserla sin más puede funcionar para hacer una funda de cojín, pero no para un vestido o un traje. Del mismo modo, ponerse a programar sin un concienzudo estudio previo puede valer para pequeñas utilidades o aplicaciones muy sencillas "de andar por casa", pero para aplicaciones de cierto tamaño (no demasiado) es absolutamente imprescindible, y recomendable en todos los casos.

A todo el proceso que sigue el desarrollo de un producto de software se le denomina genéricamente ciclo de vida del sofware. Este ciclo de vida cubre en el tiempo desde que el software es meramente una idea, pasando por su análisis, diseño, producción, utilización, mantenimiento... hasta que finalmente deja de utilizarse.

Aunque ponga los pelos de punta, muchos profesionales del sector de la informática desconocen gran parte de las técnicas y métodologías necesarias para la producción del software -algunos ni siquiera saben que existen-. Y muchos de los que sí las conocen a menudo no pueden utilizarlas por falta de presupuesto, tiempo, o cualquier otro factor. Si analizando, diseñando y planificando bien las cosas a menudo salen mal, imagínate como salen aquellas en las que apenas se ha dedicado esfuerzo a esas labores.

Pues parece que buena parte de los profesionales de la industria de la informática aún no han aprendido la lección. Y es que ésto ya es viejo... en los anales de la informática se habla por doquier de la Crisis del software , que azotó el sector de la informática sobre todo en la década de los 70 y parte de los 80. En aquella época, en la que los ordenadores eran ya máquinas muy prometedoras, grandes sistemas se fueron abajo con terribles consecuencias económicas, e incluso, en algunos casos con pérdidas de vidas. Seguramente fue una situación angustiosa, o cuanto menos preocupante para mucha gente. Quizá pudiera excusarse en la inmadurez de un sector recién surgido. La programación de ordenadores no había existido previamente como disciplina (muy recomendable el artículo The Humble Programmer , de Edsger Dijkstra. Fíjate en el tipo de problemas sobre los que reflexiona en 1972) y los profesionales de la emergente informática venían desde otras disciplinas (física, matemáticas, electrónica...) con otras técnicas y otras metodologías. La calidad del software era un concepto inexistente. Era la época del "¡Hala! ¡Ya funciona!".

No es la primera vez que lo digo... la frase "¡Pero si funciona!" es una de las más pronunciadas en nuestro sector, pero que algo funcione es lo mínimo que se le debe exigir.

¿Qué más hace le hace falta a una aplicación o sistema de información con vocación de durabilidad, seguridad y calidad? ¡Muchísimas cosas! Por ejemplo:

• Que sea lo más eficaz posible: es decir, que haga lo que se espera de él en todas las ocasiones.
• Que sea lo más eficiente posible: es decir, que lo que hace lo haga con un consumo mínimo de recursos, en especial de tiempo, espacio y esfuerzo.
• Que sea robusto: es decir, que resista a gran parte los condicionantes externos que pudieran afectarle.
• Que sea usable: es decir, que los humanos u otros sistemas que interactúan con él lo hagan de forma sencilla y racional.
• Que sea modular y no monolítico: es decir, que esté formado por pequeñas piezas sólidas, robustas, eficaces y eficientes que interactúan entre ellas para lograr el objetivo global. Estas piezas deben ser lo más independientes que sea posible (desacopladas) para lograr el máximo en facilidad de mantenimiento y mejora, así como de cara a una posible reutilización. A la vez, esas piezas deben estar perfectamente coordinadas entre ellas, y en la medida de lo posible, que sigan trabajando aún si alguna de ellas falla.
• Que se entienda fácilmente por cualquier profesional: es decir, que el sistema esté construido con un proceso racional de abstracción, organización y construcción y en la medida de lo posible, uniforme y no arbitrario o caótico, a la vez que perfectamente documentado. Cualquier profesional debe ser capaz de entenderlo al nivel que le sea preciso: desde una visión muy general y abstracta hasta cualquier detalle concreto.
• Que esté lo suficientemente especializado en su trabajo como para hacerlo perfectamente, pero que sea lo suficientemente flexible para ser adaptado fácilmente a nuevas situaciones.
• Que soporte holgadamente la carga de trabajo para la que fue diseñado y un poco más.
• etc

Quizá pienses que todo esto sería carísimo, y para muchos casos, innecesario.... Pues sí y no.

Todas esas características y muchas más son criterios de calidad. Evidentemente, la calidad absoluta no existe en ningún producto, porque sería teóricamente inalcanzable... pero desde luego, es necesario fijar siempre unos objetivos de calidad a cumplir, y que por supuesto, superen un cierto mínimo. Como siempre, es cuestión de equilibrio: es necesario hacer una elección entre el nivel de calidad que se desea y el coste en tiempo, espacio y esfuerzo.

De lo que podemos estar absolutamente seguros es de que si ni tan siquiera nos planteamos cuál es el mínimo de calidad que vamos a exigir a nuestro sistema y no adoptamos un análisis, diseño, planificación y desarrollo acordes, es posible que lleguemos a un sistema de los de "¡Pero si funciona!"... si... y funcionará durante algún tiempo, probablemente de manera ineficaz e ineficiente, y mientras que no haya ni un solo factor adverso. Quizá cause alguna incomodidad algún día... quizá otro día no funcione del todo bien, pero algún usuario hábil encuentre la forma de evitar algún factor adverso... pero existen muchas probabilidades de que un buen día los problemas superen el umbral de lo aceptable o que surja "el problema clave" que haga tambalear al sistema desde los cimientos -si es que los tiene-. La falta de previsión y organización hará que el sistema no sea facilmente mantenible, con lo cual, la solución temporal será, en el mejor de los casos, meter una ñapa... y luego otra... y otra... hasta que el conjunto sea un gran montón de parches.

En fin... que antes de ponerse "manos a la obra" a programar un sistema es necesario tenerlo todo atado y bien atado. Que el ciclo de vida de ese software siga una serie de pasos seguros y bien documentados, hasta que el producto sea de la calidad deseada y tenga una exitosa vida celebrada por sus usuarios. Para ello, es imprescindible aplicar con el mejor rigor que se pueda una metodología, es decir, una manera de hacer las cosas por pasos racionales y conocidos por todos en el proceso de producción del software.

Para la construcción de un software de calidad se conocen montones de metodologías (que si estructurada, que si orientada a aspectos, que si extreme programming, que si el proceso racional unificado, que si métrica...): algunas funcionan bien en unos casos y no tan bien en otros. Además, también existen distintas técnicas aplicables en cada paso de una metodología de construcción de software (que si UML, que si PERT, que si entidad/relación...) También podemos decir que algunas funcionan bien en unos casos y no tan bien en otros.

Lo que podemos tener claro es que un sistema de información debe tener una vida larga y próspera, y que facilite la vida lo más posible a aquellos para los que fué diseñado. Para ello, es necesario que el software tenga un ciclo de vida sensatamente planificado, se siga una metodología que lo permita y se utilicen las técnicas necesarias en cada paso. A veces acertaremos y lo haremos bastante bien... otras no acertaremos tanto y lo haremos menos bien (pero podremos corregir fácilmente en la mayoría de los casos)... pero sin utilizar una metodología para realizar un análisis, diseño, planificación y posterior construcción de un sistema podemos estar prácticamente seguros de que el fracaso a corto o largo plazo está garantizado en cuanto el sistema sea de cierta envergadura.

Todas estas consideraciones forman parte de la Ingeniería del Software, nombre genérico con el que se denomina al estudio del ciclo de vida del software, o dicho de otro modo, de la producción de aplicaciones o sistemas de información, mucho más allá de la mera programación (dicen que esa denominación se popularizó a partir de una conferencia del comité de ciencia de la OTAN  en 1968). Y no es que la programación no sea importante, es que en el proceso de producción del software -de cualquier software- necesariamente hay mucho más que programación. A pesar del nombre, no hace falta ser ingeniero ni nada parecido para acercarse a ésta disciplina. Todos los profesionales del sector debemos ser conscientes de los aspectos involucrados en la producción del software.

En la ingeniería del software, como en cualquier otra disciplina, hay modas, tendencias, técnicas maravillosas, chorradas impresionantes y cosas absolutamente desfasadas (hay mucha gente del pasado , aunque no necesariamente todo lo pasado fue peor). Todo eso no es malo. En general, todo lo que se elucubra acerca del ciclo de vida del software es, en cierta medida, bienintencionado. ¿Cómo se distingue entonces lo bueno de lo no-tan-bueno?.... Ahhhh... eso, mi querido amigo, es cosa tuya: déjate guiar por tu propio sentido crítico. No tomes nada como dogma o verdad absoluta (y mucho menos éste artículo). Tú y tus experiencias podréis descubrir qué es lo bueno y qué no lo es... a veces te irá bien y a veces menos bien... pero seguro que mucho mejor que no teniendo en cuenta ninguna consideración más allá de la mera programación. Si no sabes por dónde empezar, fíate de aquellos en los que confíes: si confías en ellos es porque en general, estás de acuerdo con su criterio. Quizá sea acertado también en este terreno. También en bueno fijarse en aquellos que normalmente toman decisiones que tú no tomarías y llegan a situaciones que tú no desearías. Es probable que en este tema también lo hagan: seguramente sus decisiones no serán acertadas de acuerdo con tu visión.

Seguiremos hablando de estos temas.