Verified answer

Ha decir verdad no se si hay otro que sea "específicamente" para OO.

Yo creo que un desarrollo en OO puede ser llevado incluso en cualquier tipo de ciclo de vida.

Y que además, si bien el USDP (unificado) fue pensado INICIALMENTE para seguir un modelo OO, creo y considero que no debe haber muchas complicaciones para aplicar el ciclo de vida hacia otros paradigmas de programación.

El ciclo de vida lo que impone es una estructrura de trabajo, no un paradigma de desarrollo. Nació con la idea de aportar mejores soluciones y enfoques para dirigir sistemas desarrollados en lenguaje OO. Pero estas prácticas pueden escalarse hacia otros tipos de A/D.

Son dos cosas distintas: ciclo de vida y paradigma de programación.

El enfoque que aporta USDP es un trabajo evolutivo, incremental. Diseñado para combatir proyectos con fechas límites estrictas, con riesgos técnicos elevados y otros factores más. En fin, para proyectos grandes....

Por ejemplo: pongamos que trabajas con lenguaje OO. ¿Aplicarías un enfoque unificado si sabes que el proyecto es chico, si los requisitos son fijos, no hay demasiada limitaciones técnicas-operativas y cuentas con mucha experiencia ya que se trata de un sistema parecido o similares a otros realizados?

Quiero hacerte ver que la imposición de un ciclo de vida, ya no obedece a un paradigma de lenguaje. Sino al marco de trabajo.

Hay muchos paradigmas de trabajo: secuencial (o Cascada), Prototipado, Espiral, Incremental.

Como dije: fueron concebidos inicialmente para un enfoque de programación, pero lo que en realidad imponen es un programa de trabajo. Una estructura de como deben realizarse las actividades desde la concepción del sistema hasta la entrega del mismo.

Si usas POO, POA (Programación orientado a aspectos), un lenguaje orientados a eventos, o estructurado es a tu gusto.

Claro, está, también dependerá de la facilidad y continuidad del sistema. Por lo general: si se sabe que el sistema obedecerá a muchos cambios, mantenimiento y mejoras... lo mejor es usar un lenguaje que ofrezca facilidades.... Un LOO es útil en estos casos, pero igualmente puede conseguirse con cualquier otro. Es una cuestión subjetiva.

Como lo expresa Craig Larman: "El UP se utiliza como ejemplo de proceso con el que explorar el análisis de requisitos y el A/DOO, puesto que es necesario introducir el tema en el contexto de algún proceso, y el uso de UP (o el refinamiento del RUP) está relativamente bastante extendido. Además, el UP presenta actividades comunes y buenas prácticas. No obstante, las ideas centrales de este libro -como casos de uso y patrones de diseño- SON INDEPENDIENTES DE CUALQUIER PROCESO PARTICULAR, Y PUEDEN APLICARSE A MUCHOS".(1)

Por favor, pon mayor atención a lo que resalté en mayusculas. El mismo sostiene que el enfoque de OO puede ser dirigido por otros modelos.

Todo dependerá de las circunstancias de cada proyecto y de la experiencia con que se cuente.