Please enable JavaScript.
Coggle requires JavaScript to display documents.
Introduccion a Iterativo Incremental - Coggle Diagram
Introduccion a Iterativo Incremental
Introducción
Las causas principales de este problema son tres:
Los sistemas informáticos son más complejos que los sistemas físicos.
Muchos proyectos informáticos no cuentan con un metodología de análisis, diseño y programación bien establecida, sino que estos se ejecutan de manera desordenada.
La gestión de proyectos informáticos muchas veces carecen de un modelo de desarrollo o bien utilizan modelos obsoletos que son inadecuados para la tarea.
Es generalmente conocido que la tasa de éxito de los proyectos de desarrollo de software es notablemente más baja que la de cualquier otro proyecto de ingeniería
Proyectos sin modelo de desarrollo
Aunque la necesidad de un modelo de desarrollo hace décadas que está firmemente establecida, la desidia y falta de profesionalidad hacen que la mayoría de proyectos de software no apliquen ningún modelo absoluto.
La filosofía subyacente a dichos proyectos suele ser que el análisis y diseño del sistema, así como cualquier planificación de sus desarrollo, son una pérdida de tiempo y que lo importante es comenzar a programar cuanto antes para entregar el producto lo más pronto posible
El hecho de que esta entrega a tiempo pocas veces se consiga, no impide que esta forma equivocada y poco profesional de desarrollo siga repitiéndose una y otra vez
Proyectos con modelo de desarrollo en cascada.
En un modelo en cascada, primero se realiza el análisis. Cuando se tiene un análisis acabado se comienza a desarrollar el diseño. Cuando el diseño está acabado, se lleva a cabo la programación. Cuando la programación está acabada se realizan las pruebas.
Sin embargo, como hemos dicho, los programas informáticos son mucho más complejos y abstractos que un edificio o que cualquier producto resultante de otra ingeniería.
Es por esto que modelo no se adecua bien al desarrollo de sistemas.
Sus principales defectos son
los siguientes:
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.
Falta de retroalimentación.
El cliente comienza con una idea vaga de lo que necesita al principio del proyecto, pero este no sabrá su resultado hasta que se tenga el producto final.
Rigidez y poca adaptabilidad.
En un mundo perfecto, los clientes y los desarrollados tendrán claros los requerimientos desde un principio y estos requerimientos no cambiarían durante el proceso de desarrollo.
La realidad es que los requerimientos cambian constantemente por distintos motivos, ya sea por cambios del clientes que no se había percatado antes, el mercado o la tecnología que pueda afectar el proyecto.
Como consecuencia, el modelo de desarrollo en cascada es demasiado rígido para un proceso tan dinámico como es el desarrollo de software.
Proyectos con modelo de desarrollo iterativo.
Como se puede deducir de lo dicho hasta ahora, un proyecto de desarrollo requiere un cambio constante.
El modelo de desarrollo en cascada intenta evitar el cambio, fijando de forma temprana los requerimientos del sistema
Hay varios modelos de desarrollo iterativos. Entre ellos podemos destacar el " Unified Process" y su variante el "Rational Unified Process", que son estándares actuales a nivel internacional
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).
La idea central es que, en cada una de esa iteracciones, se construye una parte pequeña del sistema (esto se llama a veces "desarrollo incremental")
Para esa parte del sistema, se realiza todo el proceso; análisis, diseño, programación y pruebas.
Se acaba la iteración con un ejecutable que incluye todas las partes de! sistema construidas hasta el momento.
Las ventajas de este tipo de modelo son
las siguientes:
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.
Retroalimentación.
Como hay ejecutables desde el mismo comienzo del proyecto, el cliente puede examinarlos y proponer los
cambios que necesita para su negocio.
Los desarrolladores tienen una rápida retroalimentación de
lo que funciona y lo que no
Flexibilidad.
Se pueden realizar cambios de forma flexible puesto que el conocimiento que se adquiere en una iteración sirve para plantear de forma más realista los requerimientos de la siguiente
