Please enable JavaScript.
Coggle requires JavaScript to display documents.
MODELOS DE DESARROLLO ITERATIVOS - Coggle Diagram
MODELOS DE DESARROLLO ITERATIVOS
Proyectos con modelos de desarrollo iterativos
Los modelos iterativos se basan en dividir el proyecto de desarrollo en varias etapas, llamadas iteraciones. Las iteraciones son cortas (unas cuantas semanas, excepto en proyectos enormes) y en educación es fija (no puede alargarse si hay retrasos, éstos se incluyen en otra iteración).
Beneficios
Flexibilidad
Todos los documentos del sistema (requerimientos, diseño y código) no son rígidos sino que pueden cambiarse durante todo el proceso de desarrollo. (Típicamente suelen ser modificados en mayor medida en las primeras iteraciones y en menor medida en las últimas) .
Mitigación de riesgos
Como las pruebas se hacen desde el principio del proyecto, puede determinarse la viabilidad o eficiencia de las decisiones de diseño. Además, los elementos con más riesgo se tratan en las primeras iteraciones, con lo cual se puede implementar una mitigación de riesgos más temprana y exitosa.
Retroalimentación
Como hay ejecutables desde el mismo comienzo del proyecto, el cliente puede examinarlos y proponer los cambios que necesita para su negocio. También los desarrolladores tienen una rápida retroalimentación de lo que funciona y lo que no, ya que las pruebas se realizan desde el comienzo mismo del proyecto y no se debe esperar al final para hacer modificaciones necesarias
Proyectos sin modelo de desarrollo iterativo
Se obtienen sistemas llenos de errores, difíciles de mantener, inestables y costosos, que rápidamente pasan a ser inmanejables, siendo desechados después
de pocos años
Modelo de desarrollo en cascada
Analisis
Es una descripción de lo que debe hacer el sistema,
Programación
Proceso donde se fabrica el sistema, previamente diseñado
Diseño
Se diseña el proyecto, se crean modelos, clases relaciones entidades, funcionalidades, interfaces, etc.
Pruebas
se prueba el programa para detectar posibles errores y corregibles
Problemas del modelo
Rigidides y poca adaptabilidad
El modelo en cascada no permite acomodar cambios, ya que los requerimientos quedan fijados desde el comienzo, no pudiendo ser modificados con posterioridad.
Baja mitigación de riesgos
Con el modelo en cascada no es hasta el final del proyecto cuando se pueden hacer pruebas y determinar la viabilidad o eficiencia de nuestra arquitectura. Así, los elementos más riesgosos (como la viabilidad de la arquitectura del sistema) se determinan al término del proceso de desarrollo, cuando es más difícil y costoso modificarlos, además de que se ha perdido valioso tiempo y recursos diseñando una arquitectura que al final se revela como no viable
Falta de retroalimentación
Sólo se tiene un ejecutable del sistema hasta el final del proyecto. En este punto, los cambios son caros o poco posibles ya que la estructura del sistema está firmemente establecida, como consecuencia, el modelo de desarrollo en cascada es demasiado rígido para un proceso tan dinámico como es el desarrollo de software.
