El modelo de ciclo de vida de desarrollo de software

¿Qué es el ciclo de vida de desarrollo de software? El ciclo de vida se refiere a las etapas o fases que transforman las necesidades de los usuarios en un producto final de software. El ciclo de vida se representa con modelos que muestran de manera general las etapas o subprocesos (requisitos, diseño, construcción, prueba) y el orden en que se realizan. El modelo de ciclo de vida más conocido es el Ciclo de vida de cascada (waterfall) que se muestra en la figura.

¿Qué importancia tiene el ciclo de vida para el desarrollo de software? Vemos que, por ejemplo, el Capability Maturity Model del SEI establece como parte de los "activos" del proceso la descripción de los modelos de ciclo de vida aprobados para su uso y como parte de las subprácticas de Planeación del proyecto la definición del ciclo de vida para el proyecto (Subpráctica 1.3) lo cual, además, tiene un impacto en la forma de realizar las estimaciones. Por su parte, el Rational Unified Process establece como predeterminado un ciclo de vida iterativo. Pero, bueno ¿y qué importancia tiene? ¿no basta con tomar cualquier modelo de ciclo de vida y aplicarlo al proyecto? Resulta que no, que dependiendo de las características de nuestro proyecto en particular debemos analizar y seleccionar el modelo de ciclo de vida más adecuado y que de eso puede depender el éxito o fracaso de nuestro proyecto.

En las siguientes secciones analizaremos diferentes modelos de ciclos de vida y sus implicaciones para los proyectos de desarrollo de software.

¿Para qué construímos software?

Se está volviendo un cliché el decir que "el software está en todos lados", pero es cierto. El software nos rodea, nos envuelve, nos facilita la vida (aún no hablo de pantallas azules de error) y cada vez nos es más indispensable: celulares, PDAs, automóviles, satélites, Internet. Basta recordar que el fallo en los lentes del telescopio Hubble pudo corregirse vía software. El software nos permite comunicarnos lo mismo que facilita la administración y operación de una empresa o el llevar el expediente clínico de un paciente.

De manera que el software (cuando funciona bien) nos permite resolver problemas o buscar áreas de oportunidad en nuestra vida y en la sociedad en general.

Problemas en el desarrollo de software

Para poder entender claramente la necesidad de la Ingeniería de Software como disciplina, es necesario adentrarse en los problemas que se presentan en los proyectos de desarrollo de software y sus causas.

Es sabido que muchos proyectos de desarrollo de software no cumplen sus objetivos de tiempo, costo y calidad (ver por ejemplo Chaos Report de Standish Group) ¿cuáles son las razones?. Según Standish Group, las 3 razones más importantes de falla en los proyectos son:

1. Falta de información por parte de los usuarios
2. Requerimientos y especificaciones incompletas
3. Requerimientos y especificaciones cambiantes

Eso nos da una pista importante (ya lo había dicho Frederick Brooks en No Silver Bullet): "La parte más dificil de desarrollar un sistema es decidir qué desarrollar... ninguna otra parte hace fallar tanto el sistema resultante si se hace mal. Ninguna otra parte es más difícl de rectificar después". Brooks define las dificultades de desarrollar software en Esenciales (o inherentes al software) y Accidentales, siguiendo el pensamiento aristotélico y dice que el software es una construcción conceptual que toma múltiples representaciones muy detalladas, y que la dificultad esencial radica en la especificación, diseño y prueba de esta construcción conceptual ( dificultad semántica), y no tanto en la labor de representarla y probar esta representación (dificultad sintáctica).

Existen otros problemas relacionados con los requerimientos, como el hecho de que es difícil representar el conocimiento experto o que la mayoría de las personas pueden hacer bien su trabajo sin que necesariamente puedan explicar bien cómo o porqué lo hacen.

Por otro lado y refiriéndome a la causa No. 3 del reporte de Standish Group, Ed Bersoff estableció que "No importa donde te encuentres en el ciclo de vida, el Sistema cambiará y el deseo de cambiar persistirá durante todo el ciclo de vida".

¿Tiene la Ingeniería de Software una solución para estos problemas?

Es importante hacer notar que estamos aquí en la parte del Qué desarrollar y aun no entramos al Cómo desarrollarlo.

Definición de Ingeniería de Software

¿Qué es la Ingeniería de Software? Una frase con humor negro en la industria dice que "Ingeniería de Software es... un buen deseo". Podríamos decir que los grandes fracasos en los proyectos de desarrollo de software apoyan esta tesis (ver, por ejemplo, el "Salón de la vergüenza del software") y que en realidad estamos muy lejos de poder unir las palabras ingeniería y sofware en una misma oración.

Al parecer, el término Ingeniería de Software data de 1968 y se debe a Friedrich Ludwig Bauer, científico en computación alemán quien, entre otras cosas, también propició el que se estableciera por primera vez la carrera de ciencias de la computación en varias universidades alemanas y participó en el desarrollo del lenguaje Algol 60. En ese año (¡hace 38 años ya!) se habló ya también de la Crisis del software. De modo que el término no es nuevo (ni el problema que trata de resolver). Bueno, 38 años pareciera mucho tiempo para poder hablar ya de Ingeniería de Software, sin embargo, no hay que olvidar que otras áreas del conocimiento tienen hasta miles de años de antigüedad, como la arquitectura.

Aquí nos puede ser útil presentar ya alguna definición de Ingeniería de Software y tomaremos la de la Computer Society de la IEEE: "La aplicación de una aproximación sistemática, disciplinada y cuantificable al desarrollo, operación y mantenimiento de software, esto es la aplicación de la ingeniería al software". Pero ¿qué problemas trata de resolver entonces la Ingeniería de Software? ¿de qué nos sirve un enfoque sistemático? ¿qué aporta la disciplina aquí? ¿porqué querríamos cuantificar?