MODELO INCREMENTAL El Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos.

En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento.

Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos. El Modelo Incremental se puede ver aqu en forma grafica: - Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucra ms. - Difcil de evaluar el coste total. - Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. - Requiere gestores experimentados. - Los errores en los requisitos se detectan tarde. - El resultado puede ser muy positivo. Pipeline La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales, siendo la entrada de cada una la salida de la anterior. Esta arquitectura es muy comn en el desarrollo de programas para el intrprete de comandos, ya que se pueden concatenar comandos fcilmente con tuberas (pipe). Tambin es una arquitectura muy natural en el paradigma de programacin funcional, ya que equivale a la composicin de funciones matemticas. Interprete de comandos Parte fundamental de un sistema operativo que ordena la ejecucin de mandatos obtenidos del usuario por medio de una interfaz alfanumrica. Caractersticas

- Se evitan proyectos largos y se entrega algo de valor a los usuarios con cierta frecuencia. - El usuario se involucre ms. - Difcil de evaluar el costo total. - Difcil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo. - Requiere gestores experimentados. - Los errores en los requisitos se detectan tarde. - El resultado puede ser muy positivo. Ventajas: - Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa la funcionalidad parcial. - Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del Software. - El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. - Permite entregar al cliente un producto ms rpido en comparacin del modelo de cascada. - Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos. - Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel administrativo como tcnico. Desventajas: - El modelo Incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto ndice de riesgos. - Requiere de mucha planeacin, tanto administrativa como tcnica. - Requiere de metas claras para conocer el estado del proyecto.
perteneciente a la familia de los procesos evolutivos. el Modelo Incremental combina elementos del MLS con la filosofa interactiva de construccin de prototipos. En una visin genrica, el proceso se divide en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o Pipeline, utilizado en muchas otras formas de programacin. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se repite hasta que se elabore el producto completo. De esta forma el tiempo de entrega se reduce considerablemente. Al igual que los otros mtodos de modelado, el Modelo Incremental es de naturaleza interactiva pero se diferencia de aquellos en que al final de cada incremento se entrega un producto completamente operacional. El Modelo Incremental es particularmente til cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden realizar un grupo reducido

de personas y en cada incremento se aadir personal, de ser necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos.

Modelo De Desarrollo Incremental

La propuesta del modelo es disear sistemas que puedan entregarse por piezas.

A partir de la evaluacin se planea el siguiente incremento y as sucesivamente Es interactivo por naturaleza Es til cuando el personal no es suficiente para la implementacin completa En lugar de entrega del sistema en una sola entrega, el desarrollo y la entrega estn fracturados bajo incrementos, con cada incremento que entrega parte de la funcionalidad requerida. Los requerimientos del usuario se priorizan y los requerimientos de prioridad ms altos son incluidos en los incrementos tempranos. Hechos de incrementos tempranos como un prototipo, ayudan a obtener requisitos para los incrementos ms tardos. Los usuarios no tiene que esperar. Pueden aumentar el coste debido a las pruebas. El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. El modelo incremental presupone que el conjunto completo de requerimientos es conocido al comenzar Se evitan proyectos largos y se entrega Algo de valor a los usuarios con cierta frecuencia El usuario se involucra ms Riesgos largos y complejos. Difcil de aplicar a sistemas transaccionales que tienden a serintegrados y a operar como un todo Requiere gestores experimentados Los errores en los requisitos se detectan tarde.

Bajo este modelo se entrega software por partes funcionales ms pequeas , pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregado. Beneficios:

Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, slo la ltima iteracin necesita ser descartada. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo incremento El resultado puede ser muy positivo

http://modelos-phpnoche.blogspot.com/ http://www.slideshare.net/boreasH/ingenieria-de-softwaremodelo-incremental-victor-mamanicatachura-boreash http://ingenieraupoliana.blogspot.com/2010/10/modelo-incremental.html