La #agilidad no es el único camino a la hora de desarrollar, y su motor, la metodología iterativa-incremetal, no es la panacea. Me di cuenta escribiendo el post de "Qué es la #agilidad?" aún no había escrito nada sobre ciclos de vida del software y es muy importante tenerlos claros antes de continuar con los post de #agilidad, ya que nos dará una perspectiva más íntima del concepto y lograremos interiorizarlos más fácilmente.
Por otra parte siempre hay que escoger muy bien como se va a desarrollar un proyecto, pues depende del ámbito, del cliente o del equipo, el tipo de modelo que se debe aplicar para que el proyecto tenga éxito.
Este Post pertenece a la Serie "Modelos de ciclo de vida del software". Aquí tenéis el listado de post que iremos viendo:
Modelo de Prototipos (II)
Modelo Iterativo (III)
Modelo Espiral (IV)
Modelo RDA (V)
1. Definiciones previas
¿Qué es el Ciclo de vida del Software?
Es una sucesión de etapas por las que pasa el sofware en su desarrollo, desde que se concibe la idea, hasta que deja de utilizarse.
Como apunte, hace tiempo hablé del Proceso de Retiro del software en ¿Es el software inmortal? donde reflexionaba sobre el concepto de muerte en el mundo del software.
¿Qué es el Modelo del Ciclo de Vida del Software?
Estrategias de desarrollo que ayudan a organizar las diferentes etapas y actividades del ciclo de vida del software. Éstas, ayudan al control y a la coordinación del proyecto y dependiendo del tipo del proyecto, escogeremos una u otra.
2. Modelo en Cascada
Características
· Se divide el desarrollo en un conjunto de etapas secuenciales.
· Una etapa no empieza hasta que no termina la anterior.
· Al finalizar cada etapa, los desarrolladores y los usuarios revisan el progreso del proyecto.
· En cada fase, se genera un conjunto de documentos. De hecho, se dice que es un modelo dirigido por documentos, donde son "los productos" principales de cada etapa. Por lo tanto se puede decir que es un modelo dirigido por documentos.
Desventajas
· Al ser predictivo se necesita especificar todo al máximo detalle desde el inicio, ya que realizar modificaciones resultará muy costoso.
· El cliente no verá el producto hasta el final de todas las etapas. Por lo tanto, la validación de los requisitos no se hará hasta finalizar todas las etapas.
· No permite flexibilidad ante los cambios.
Recomendado
· Proyectos muy complejos en los que está todo muy bien definido desde el comienzo.
· Cuando posees a miembros del equipo de desarrollo que aún son inexpertos o tienen carencias en algún aspecto técnico, ya que la estructura de trabajo es muy ordenada lo que facilita la curva de aprendizaje de nuevas habilidades (pero sin pasarse, que luego hay 15 becarios que no tienen ni idea y tampoco es eso lo que quiero decir, me refiero a tener un 30-40% del equipo que se pueda modelar durante el proyecto).
· Es buen modelo para la migración de software entre entornos tecnológicos.
Hasta el próximo!
Fuente:
Apuntes de Grado en Ingeniería del Software - Asignatura Procesos Software (2011-2012)
