En este post vamos a hablar de los distintos ciclos de vida que se pueden aplicar en el desarrollo de un proyecto software. El ciclo de vida es el conjunto de fases o etapas, procesos y actividades requeridas para ofertar, desarrollar, probar, integrar, explotar y mantener un producto software, y que abarca desde su concepción hasta su retirada.
Para este artículo nos vamos a centrar en los cuatro que consideramos principales o más importantes: cascada, incremental, prototipado y en espiral.
Ciclo de vida en CASCADA ("Waterfall")
Este modelo es el más antiguo de cuantos vamos a comentar y resulta especialmente sencillo de gestionar. Se basa en varios principios, como que una nueva fase no puede comenzar hasta que no se termine la anterior, que para poder pasar de una fase a otra se han de haber cubierto todos los objetivos de la predecesora o que al final de cada fase se pueda revisar el estado del proyecto por parte de los stakeholders.
Por contra presenta, habida cuenta de su longevidad, algunos inconvenientes. Uno de ellos es que no refleja el proceso real del desarrollo del software, porque muy raramente un proyecto sigue un flujo secuencial, sino que siempre hay iteraciones. Otro es que el paso por todo el ciclo es lento y pesado, porque requiere que se finalice una fase para pasar a la siguiente, y por último, requiere de mucha paciencia por parte del cliente, porque no posee un prototipo de su sistema hasta los últimos compases del proyecto.
Ciclo de vida INCREMENTAL
Este modelo satisface la necesidad de una secuencia no lineal de los pasos de desarrollo. En el modelo incremental se va creando el sistema software añadiendo componentes funcionales al sistema (llamados incrementos). En cada paso sucesivo, se actualiza el mismo con nuevas funcionalidades o requisitos, es decir, cada versión o refinamiento parte de una versión previa y le añade nuevas funciones. El sistema software ya no se ve como una única entidad monolítica con una fecha fija de entrega, sino como una integración de resultados sucesivos obtenidos después de cada iteración.
Se ajusta a entornos de alta incertidumbre, por no tener la necesidad de poseer un conjunto exhaustivo de requisitos, especificaciones, diseños, etc., al comenzar el sistema, ya que cada refinamiento amplía los requisitos y las especificaciones derivadas de la fase anterior.
Así mismo, constituyó un avance sobre el modelo en cascada, pero también presenta problemas. Aunque permite el cambio continuo de requisitos, aún existe el problema de determinar si los requisitos propuestos son válidos. Los errores en los requisitos se detectan tarde y su corrección resulta tan costosa como en el modelo en cascada.
En el siguiente post os hablaremos de los otros dos que nos hemos dejado en el tintero...
martes, 25 de noviembre de 2008
Suscribirse a:
Enviar comentarios (Atom)
No hay comentarios:
Publicar un comentario