Tipo de desarrollo de Proyectos

"Modelo en cascada".

El modelo en cascada es el ciclo de vida clásico, su principal característica es la naturaleza estrictamente secuencial de la ejecución de sus fases. Al aprobar cada una de ellas se genera la documentación adecuada que permite comenzar con la siguiente, ante defectos que se detectan en la ejecución de una fase determinada posiblemente haya necesidad de volver a la fase inmediatamente anterior y corregir o modificar algunos de sus contenidos, pero es algo que se debe evitar en la medida de lo posible. Esta naturaleza se explica con el carácter más homogéneo de las aplicaciones y la plataforma tecnológica mucho más simple de hace unas décadas (las aplicaciones eran prácticamente siempre aplicaciones de gestión sobre host con un nivel de complejidad relativamente simple frente a las actuales). Este modelo resulta adecuado cuando los requisitos están bien definidos, son estables desde el comienzo del proyecto y se dominan las metodologías y herramientas utilizadas en el proyecto, ya que minimiza el tiempo dedicado a cada una de las tareas.

Ventajas:

• Minimiza las tareas de desarrollo repetidas y por tanto el esfuerzo de desarrollo invertido en total.
• Minimiza la carga de planificación de los ciclos iterativos de otros ciclos de vida.
• Permite afrontar la complejidad de proyectos grandes de una manera muy ordenada y aumenta así las posibilidades de éxito.
• Ayuda a trabajar mejor con equipos de desarrollo de relativamente baja calificación por el alto control de cada actividad y sus resultados.

Inconvenientes

• Es muy inflexible, por tanto solamente resulta adecuado cuando hay requerimientos muy bien definidos y muy estables, algo que es difícil de encontrar.
• Retroceder en las fases para corregir errores que se han cometido en fases previas o adaptar el proyecto a cambios resulta muy difícil y costoso en esfuerzo.
• Aunque la documentación elaborada permite un seguimiento bueno del proyecto para una persona calificada, los resultados tangibles para el cliente aparecen prácticamente al final del proyecto, algo que muchas veces no aceptan los clientes.

"Modelo prototipo".

Fase A: El objetivo de la fase A es verificar la adecuación del sistema que se va a desarrollar a los requerimientos expresados por el usuario. Exige una evaluación por parte de éste: una vez el prototipo aceptado ya se tiene un modelo a escala del sistema completo que hay que construir.

Fase B: El punto de entrada en la fase B es el prototipo construido y aceptado en el que se han detallado los diseños de pantalla y listados, los encadenamientos de módulos y los flujos de datos. Con estas informaciones contrastadas ya se tiene la descomposición en programas, con lo que este modelo de ciclo de vida en la fase B se ocupa del desarrollo y prueba de los programas y de la integración de los mismos en la solución final.

Ventajas:

• El caso de requerimientos cambiantes e incapacidad de parte del cliente para definirlos con el suficiente detalle se da con frecuencia, abordar el proyecto de esta manera es una solución muy natural ante este problema y evita en gran medida los conflictos con el cliente.
• El cliente participa muy activamente en el desarrollo, por tanto, las posibilidades de alcanzar un producto que haga lo "que el quiere" son altas.
• Aporta resultados tangibles que permiten al cliente medir el progreso del proyecto.
• En muchas ocasiones el cliente gana tiempo en el sentido que ya le resultan útiles los primeros prototipos y amortiza la inversión desde un punto muy temprano mientras que se sigue mejorando el resultado final. Esta faceta frecuentemente hace que el cliente esté dispuesto a asumir una inversión global algo mayor a la que estaría dispuesto hacer si tuviera que esperar hasta la entrega final del producto, añade por tanto mucha flexibilidad a la negociación del proyecto

Inconvenientes:

• En proyectos de cierta envergadura es prácticamente imposible saber cuando se llegará al producto final, ni cuantos prototipos intermedios serán necesarios hasta entonces.
• No es fácil convencer al cliente de la necesidad de tirar determinados prototipos "a la basura", hay una gran tentación de no llegar al final con las iteraciones necesarias.
• Desde el punto de vista de los desarrolladores, este ciclo de vida puede ser una tentación a desarrollar de forma anárquica, es decir, dejar de lado la modificación de la especificación de requisitos, análisis, etc. que corresponde a cada iteración.

"Modelo Desarrollo en espiral".

El desarrollo en espiral es un ciclo de vida muy orientado a la eliminación progresiva de los riesgos, es un ciclo de vida iterativo en cuyas iteraciones se enfocan uno o más riesgos objetivos que han de superarse hasta que el nivel de riesgo sea suficientemente bajo para continuar con un ciclo menos complejo.

En cada iteración se realizan los siguientes pasos:

• Planificación: Determinar objetivos, alternativas y restricciones.
• Análisis de riesgo: Análisis de riesgos y evaluación de alternativas.
• Ingeniería: Desarrollo de los entregables o prototipos de la iteración.
• Evaluación del resultado: Evaluación y validación del resultado.

Ventajas:

• Puesto que se trata de un modelo orientado a los riesgos del proyecto da un nivel de seguridad muy elevado al proyecto, los riesgos se eliminan al principio que es cuando mejor se puede reaccionar a ellos y en el caso negativo extremo de detectar la inviabilidad del proyecto, minimiza la inversión realizada en él.
• Una mayor inversión en esfuerzo (y con ello tiempo y dinero) se traduce directamente en mayor seguridad del proyecto, ya que permite gestionar con mayor dedicación los riesgos.
• El cliente dispone mediante los prototipos de resultados tangibles en cada iteración y participa de una manera muy interactiva en la evolución del proyecto con lo cual se mejoran mucho las posibilidades de satisfacción del resultado. Inconvenientes:
• El único inconveniente es la complejidad y carga de gestión de este modelo.

El desarrollo orientado a prototipos que se evalúa progresivamente no se debe confundir con este modelo en espiral, aunque tienen bastante parecido en cuanto a su carácter iterativo, en el modelo en espiral se trata de enfocar los mayores riesgos desarrollando primero las facetas relacionadas con ellos y eliminarlos así cuanto antes, es decir, los riesgos determinan la evolución del proyecto. En el desarrollo evolutivo de prototipos se parte de un concepto inicial de la aplicación y es este concepto el que evoluciona. Es decir, en este modelo se desarrolla un primer prototipo relativamente completo, frecuentemente destinado a ser ya utilizado por cliente. El cliente aporta realimentación y con ella se desarrolla la siguiente versión, y así sucesivamente hasta que se alcance una versión que le satisface. Resulta útil cuando el cliente tiene prisa en desarrollar la aplicación, pero no es capaz de definirla con exactitud y el mismo tiene que aprender más de la problemática que debe resolver con la aplicación. También resulta adecuado cuando se prevé que los requerimientos van a tener una tasa de cambio alta durante el desarrollo del proyecto.

"Modelo Desarrollo orientado a Hitos"

Con frecuencia se da el caso que el factor limitante es el tiempo más que el presupuesto o el detalle de la funcionalidad. En estos casos puede ser muy oportuno aplicar este ciclo de vida que asume ciertas indefinición en la envergadura final de las funcionalidades implementadas, pero fija claramente un punto final en el tiempo. En un desarrollo grande puede ser además muy útil para gestionar el desarrollo de módulos individuales no críticos con el fin de que no retrasen el progreso global del proyecto.

En este ciclo de vida básicamente se trabaja secuencialmente en la base estable del producto que incluye llegar hasta el diseño de la arquitectura, pero a partir de ahí se trabaja en ciclos iterativos sobre el diseño detallado, codificación y pruebas. Los contenidos de estos ciclos se priorizan para optimizar según la relevancia de las funcionalidades implementadas.

Ventajas:

• Es una estrategia relativamente óptima ante una situación de fecha límite rígida.
• Permite reducir mucho el riesgo en proyectos grandes si se gestionan sus módulos de menor prioridad con esta técnica.

Inconvenientes:

• Si se consiguen implementar relativamente pocas funcionalidades de las previstas se habrá perdido mucho tiempo en la especificación y diseño de funcionalidades no implementadas al final, por tanto hay que medir bien la ambición del trabajo previo a los ciclos iterativos.

Nótese que se combina en cierta manera el enfoque clásico con el modelo en espiral dividiendo la parte más gruesa del desarrollo en fase priorizadas que permiten optimizar la relevancia del trabajo realizado dentro de unos límites de tiempo, obsérvese especialmente el matiz que la fase de diseño no iterativa se limita al diseño de la arquitectura ya que no varía con las iteraciones.

"Modelo de desarrollo en versiones sucesivas".

Este modelo de ciclo de vida pretende resolver uno de los problemas del modelo en cascada: La tardía aparición de un modelo funcional del sistema en desarrollo.

Para ello se realiza una serie de iteraciones sobre el propio modelo en cascada. En la primera se obtiene una primera versión del sistema. En cada una de las demás iteraciones el modelo se refina hasta alcanzar una versión definitiva que satisfaga plenamente los requerimientos de usuario.

En cada iteración, se reelaboran los requerimientos según se encuentren carencias o inexactitudes con la idea original del usuario. Los nuevos requerimientos se someten a análisis, se modifican los diseños, y se procede a las modificaciones pertinentes del código. Finalmente se procede a probar la nueva versión del modelo. Si el resultado obtenido se ajusta a los deseos del usuario, el proceso finaliza, en caso contrario se procede a una nueva iteración.

Las versiones obtenidas pueden obedecer también a un único plan inalterable. En este caso lo que se hace es realizar una implementación gradual de los requerimientos, en la que se pasa de un esbozo funcional a versiones cada vez más refinadas y cercanas a las especificaciones. En esta forma se denomina Modelo evolutivo.

Los principales inconvenientes de este paradigma están en las tareas de modificación de código, que resultan complejas y sujetas a errores salvo que se haga uso de herramientas automáticas o lenguajes de cuarta generación. Otro problema es que las posibles incorrecciones, o los "parches" incorporados a una versión, permanecen en ella y se convierten en la base para el código posterior. De esta forma, una mala estructuración, arquitectura defectuosa osoluciones parciales que sirven para hacer operativamente correcta una versión, degradan el trabajo invertido en la construcción de las siguientes.

"Modelo de transformación".

Este modelo trata de resolver los problemas asociados a la dificultad de modificar el código en paradigmas como el de versiones sucesivas. Para ello parte de la premisa de la existencia de un sistema que pueda convertir fácilmente los requerimientos en código.

Los pasos seguidos en este modelo son:

• Una especificación formal del sistema.
• Una transformación automática (o asistida) de las especificaciones a código.
• Una serie de iteraciones sobre el código obtenido con objeto de mejorarlo.
• Prueba general del resultado.
• Iteraciones para ajustar el resultado a las especificaciones. Si se realiza alguna modificación sobre éstas se repite el proceso hasta que requerimientos y código final sean válidos.

La principal dificultad para la aplicación de este modelo de desarrollo está en la falta de un sistema adecuado para transformar los requerimientos en código. Esta transformación puede ser llevada a cabo en pequeños proyectos dedicados a tareas específicas, pero no es posible generalizar su aplicación.

"Modelo Mixto"

Los modelos presentados solo son algunos de los existentes, ante un proyecto concreto cabe la posibilidad de combinar modelos diferentes si el perfil del proyecto lo hace aconsejable, es decir, los modelos presentados no se deben interpretar con un espíritu excesivamente purista, sino tomarlos comoestrategias de base ante una serie de características de un proyecto.

Lo importante es que se haga el ejercicio de plantear una estrategia de desarrollo que responda de una manera coherente a la situación previsible del proyecto al que se aplica. Los modelos aquí presentados pueden ser válidos para muchas ocasiones, y si no lo fueran constituirán una "inspiración" para diseñar un modelo a medida más adecuado.