Please enable JavaScript.
Coggle requires JavaScript to display documents.
Modelos de desarrollo iterativos - Coggle Diagram
Modelos de desarrollo iterativos
Proyectos con modelo de desarrollo iterativo
Un proyecto necesita un cambio constante, el modelo iterativo intenta adaptarse a este cambio. Hay varios tipos, de los cuales destacan el "Unified process" y el "Rational Unified Process"
El modelo se basa en dividir el proyecto en varias etapas, en cada una de estas etapas se construye una parte pequeña del sistema y con cada iteración se aumenta la complejidad de lo construido
Ventajas:
Mitigación de riesgos
Las pruebas se realizan desde el comienzo del proyecto, por lo que puede realizarse la eficiencia del diseño desde muy temprano
Los elementos con mas riesgo son solucionados en las primeras iteraciones
Retroalimentación
Los archivos ejecutables existen desde un principio del proyecto, por lo que es mas fácil que el cliente nos de su retroalimentación y proponer cambios
Los desarrolladores reciben una retroalimentación de manera mas rápida y eficaz de lo que funciona y de lo que no, ya que no hay que esperar hasta el final del proyecto para modificarlo
Flexibilidad
El conocimiento adquirido en una iteración puede ser utilizada para replantear los requisitos para la siguiente
Todos los documentos relacionados con el sistema pueden cambiarse en cualquier momento durante el desarrollo
Este modelo permite los cambios de manera flexible, por lo que no significan un costo mayor a la hora de realizarlos
Proyectos con modelo de desarrollo en cascada
Es el mas común a utilizar, primero se hace un análisis, luego un diseño, se realiza la programación y finalmente se hacen las pruebas pertinentes
Principales defectos:
Rigidez y poca adaptabilidad
No es realista pensar que los desarrolladores y los clientes tengan los requisitos claros desde un principio
La realidad es que los requerimientos sufren constantes cambios durante el desarrollo del producto, ya sea por una evolución de la tecnología o un cambio de opinión por parte del cliente
El modelo de cascada no permite acomodarse a estos cambios, ya que los requisitos son fijados desde el comienzo del proyecto
Falta de retroalimentación
En el modelo de cascada, el cliente no ve el avance del proyecto hasta las fases finales del mismo, por lo que si necesita algún cambio estos resultan caros o poco probables
Por lo general, el cliente empieza con una idea vaga de que es lo que quiere y cuando el proyecto ya tienen un avance en concreto es cuando se da cuenta de que es lo que realmente necesita
Baja mitigación de riesgos
Con este modelos, no podemos realizar las pruebas pertinentes hasta el final del proyecto
Por esto, los cambios para eliminar riesgos y errores resultan mas costosos, lo cual, por lo general supone una perdida de tiempo y esfuerzo
Proyectos sin modelo de desarrollo
Por lo general, se debe a que se considera una perdida de tiempo el análisis y el diseño del sistema
En ciertos casos, la falta de profesionalidad hace que la mayoría de proyectos no utilicen ningún modelo de desarrollo
Aunque es posible construir un proyecto sin utilizar un modelo de desarrollo, el resultado va a estar lejos de ser considerado aceptable
