Modelo de fuente para la orientación a objetos o ciclo de vida iterativo e incremental

En lo que concierne al ciclo de vida de un proyecto concreto, el modelo de fuente de Henderson-Sellers es, probablemente, el que refleja mejor la ingeniería del software orientado a objetos.

De este modelo hay que remarcar, en primer lugar, que está fuertemente arraigado en el modelado de los sistemas del mundo real. Tiene un alto nivel de iteración y una significativa fusión de las etapas del modelo clásico. Es decir, el desarrollo es incremental o, como dice Gilb "un poco de análisis, un poco de diseño, un poco de programación y ¡repitámoslo!".

	De las muchas variaciones de este modelo, la más frecuente se basa en una primera iteración que puede durar, según el tipo de aplicación, unos tres o cuatro meses y las siguientes, un mes aproximadamente. En la primera iteración se analiza la aplicación y se elige lo que se conoce como núcleo significativo de negocio. Es decir, lo que representa la actividad básica de la empresa y los objetos que se representen tendrán relación con la mayor parte de la aplicación. Una vez se ha desarrollado este núcleo, se entrega al cliente y se forma a éste en su utilización. Mientras el usuario empieza a utilizar esta primera versión de la aplicación, se inicia el desarrollo de otra parte de la aplicación -es decir, un incremento de la aplicación-, y esto se realiza repetidamente hasta que se ha acabado totalmente la aplicación. De aquí viene la expresión desarrollo incremental e iterativo.

A menudo, durante este segundo diseño se ve la necesidad de introducir cambios en lo que se había entregado anteriormente, pero esto no suele ser un problema, ya que la herencia nos permite introducir cambios sin "desmontar", circunstancia que ya resulta operativa. También sucede a menudo que, cuando todavía no hemos acabado la segunda iteración o una posterior, el usuario nos comenta que hay aspectos de los que ya está utilizando que no le son adecuados. Esto no es un problema, sino justamente todo lo contrario: todo lo que nos critique el usuario debe servirnos para tenerlo en cuenta en la parte de software que estamos pendientes de desarrollar, y de esta manera, cada nueva iteración será mejor.

De hecho, esta forma de desarrollar nos garantiza (dentro de ciertos límites) algo que hasta ahora era un sueño: que cuando se acabe el desarrollo esté todo bien y ya no sea necesaria una puesta en funcinamiento en pruebas ni una formación del usuario, porque las dos tareas se habrán realizado gradualmente a lo largo del desarrollo.