Tiempo atrás hablábamos del ciclo de vida del software. El ciclo de vida del software es, básicamente, el proceso que sigue un software, desde que es un simple proyecto hasta que deja de utilizarse, pasando por estudiar su origen, sus funcionalidades, sus restricciones, realizar su diseño, "fabricarlo", probarlo, instalarlo, utilizarlo, mantenerlo... y casi cualquier cosa que podamos hacer con un producto manufacturado como un paquete de software.

No obstante, no existe un proceso "industrial" estándar de fabricación de software. Cada caso es un mundo y puede resolverse de mil maneras, pero sin embargo, sí hay unas pautas generales para organizar el proceso, unas actividades que se repiten una y otra vez en la construcción de cualquier software. Esas actividades necesitan de una cierta organización en su realización... los criterios que nos sugieren esa organización son las metodologías de desarrollo de software. Buenas o malas, son mejor que nada. En este artículo discutimos sobre la organización del ciclo de vida y las actividades que pueden formar parte del desarrollo de un producto de software y asímismo, presentamos el concepto de "metodología" y de "técnica".

De vez en cuando, hace falta que una aplicación sea capaz de entender e interpretar -a veces, incluso traducir- expresiones escritas en algún lenguaje.

No estamos hablando, necesariamente, de construir compiladores o intérpretes complejos de lenguajes de programación. Las mismas técnicas, aunque a distinto nivel, se aplican tanto para construir un compilador de Pascal, una pequeña calculadora capaz de evaluar expresiones aritméticas o un cliente de IRC capaz de aceptar scripts sencillos.

En general, estamos hablando de que un programa sea capaz de reconocer una serie de sentencias escritas en algún lenguaje y bien traducirlas a otro lenguaje (compilar) o realizar acciones a medida que las va reconociendo (interpretar).

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.