Está en la página 1de 7

Modelo Incremental

El Modelo Incremental combina elementos del MLS con la filosofía interactiva de construcción
de prototipos.
En una visión genérica, el proceso se divide en 4 partes: Análisis, Diseño, Código y Prueba.
Sin embargo, para la producción del Software, se usa el principio de trabajo en cadena o
“Pipeline”, utilizado en muchas otras formas de programación. 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 métodos 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
dotación de personal suficiente. Los primeros pasos los pueden realizar un grupo
reducido de personas y en cada incremento se añadir• personal, de ser necesario.
Por otro lado los incrementos se pueden planear para gestionar riesgos técnicos.
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 más.
- Difícil de evaluar el coste total.
- Difícil 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

Desventajas: . reduciendo sus desventajas sólo al ámbito de cada incremento. Características . Interprete de comandos Parte fundamental de un sistema operativo que ordena la ejecución de mandatos obtenidos del usuario por medio de una interfaz alfanumérica. de alto nivel de seguridad. ya que equivale a la composición de funciones matemáticas. .El resultado puede ser muy positivo. . y/o de alto índice de riesgos.Requiere gestores experimentados. . Esta arquitectura es muy común en el desarrollo de programas para el intérprete de comandos. . Ventajas: .El modelo Incremental no es recomendable para casos de sistemas de tiempo real.El modelo proporciona todas las ventajas del modelo en cascada realimentado. .También provee un impacto ventajoso frente al cliente.La arquitectura en pipeline (basada en filtros) consiste en ir transformando un flujo de datos en un proceso comprendido por varias fases secuenciales.Se evitan proyectos largos y se entrega “algo de valor” a los usuarios con cierta frecuencia.Resulta más sencillo acomodar cambios al acotar el tamaño de los incrementos.Por su versatilidad requiere de una planeación cuidadosa tanto a nivel administrativo como técnico. . .Permite entregar al cliente un producto más rápido en comparación del modelo de cascada. que es la entrega temprana de partes operativas del Software. . ya que se pueden concatenar comandos fácilmente con tuberías (pipe). de procesamiento distribuido. tanto administrativa como técnica. .Con un paradigma incremental se reduce el tiempo de desarrollo inicial. .Difícil de evaluar el costo total. . También es una arquitectura muy natural en el paradigma de programación funcional.El usuario se involucre más.Requiere de mucha planeación. . .Los errores en los requisitos se detectan tarde. . siendo la entrada de cada una la salida de la anterior.Requiere de metas claras para conocer el estado del proyecto. ya que se implementa la funcionalidad parcial.Difícil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar como un todo.

Desarrollo iterativo e incremental En un desarrollo iterativo e incremental el proyecto se planifica en diversos bloques temporales (en el caso de Scrum de un mes natural o hasta de dos semanas. cada requisito se debe completar en una única iteración: el equipo debe realizar todas las tareas necesarias para completarlo (incluuyendo pruebas y documentación) y que esté preparado para ser entregado al cliente con el mínimo esfuerzo necesario. De esta manera no se deja para el final del proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos. En cada iteración el equipo evoluciona el producto (hace una entrega incremental) a partir de los resultados completados en las iteraciones anteriores. Un aspecto fundamental para guiar el desarrollo iterativo e incremental es la priorización de los objetivos/requisitos en función del valor que aportan al cliente. Las iteraciones se pueden entender como miniproyectos: en todas las iteraciones se repite un proceso de trabajo similar (de ahí el nombre “iterativo”) para proporcionar un resultado completo sobre producto final. . si así se necesita) llamados iteraciones. de manera que el cliente pueda obtener los beneficios del proyecto de forma incremental. añadiendo nuevos objetivos/requisitos o mejorando los que ya fueron completados. Para ello.

Esto es especialmente interesante cuando: o El cliente no sabe exactamente qué es lo que necesita. urgencias).Beneficios  Se puede gestionar las expectativas del cliente (requisitos desarrollados. calidad) de manera regular. lo va sabiendo conforme va viendo cuales son los resultados del proyecto.). por un nuevo producto que ha lanzado la competencia. que pueda incluso finalizar el proyecto manteniendo como mínimo los resultados alcanzados hasta ese momento.  La reacción y aceptación del mercado respecto al uso de los primeros resultados del proyecto. velocidad de desarrollo.  Cualquier cambio en el entorno (recursos. . etc. o El cliente necesita hacer cambios a corto plazo (nuevos requisitos o a cambios en los ya realizados) por:  Cambios en las condiciones del mercado (por un cambio de necesidades. puede tomar decisiones en cada iteración.

Con esta información ya es posible planificar los cambios necesarios para alinearse con las expectativas del cliente desde las primeras iteraciones. o En una iteración sólo se trabaja en los requisitos que aportan más valor en ese momento. no los de todo el proyecto. Sólo es necesario conocer con más detalle los requisitos de las primeras iteraciones. añadir nuevos equipos.  Permite conocer el progreso real del proyecto desde las primeras iteraciones y extrapolar si su finalización es viable en la fecha prevista. La finalización de cada iteración es el lugar natural donde el cliente puede proporcionar su feedback tras examinar el resultado obtenido (ver control empírico y demostración). Desde la primera iteración el equipo tiene que gestionar los problemas que pueden aparecer en una entrega del proyecto. los que más valor aportan. o Se puede dividir la complejidad para que cada parte sea resuelta en diferentes iteraciones.  El cliente puede obtener resultados importantes y usables ya desde las primeras iteraciones. etc. en función de la experiencia obtenida. de manera que al finalizar el proyecto el cliente obtenga los objetivos esperados.  La finalización de cada iteración es el lugar natural donde el equipo puede decidir cómo mejorar su proceso de trabajo. Al hacer patentes estos riesgos. No es necesario realizar una recolección completa y detallada de todos los requisitos antes de empezar el desarrollo del proyecto. Con esta información ya es posible planificar los cambios necesarios para aumentar la productividad y calidad desde las primeras iteraciones.  El cliente como máximo puede perder los recursos dedicados a una iteración. de manera que se vayan refinando en sucesivas iteraciones. es posible iniciar su mitigación de manera anticipada. Ver Retrospectiva.  Permite gestionar la complejidad del proyecto. cancelarlo. .  Se puede gestionar de manera natural los cambios que van apareciendo durante el proyecto.  El cliente puede comenzar el proyecto con requisitos de alto nivel.  Permite mitigar desde el inicio los riesgos del proyecto.o El equipo necesita saber si lo que ha entendido es lo que el cliente espera. El cliente puede decidir repriorizar los requisitos del proyecto. quizás no del todo completos.

el cliente ha de revisar los requisitos desarrollados. Recomendaciones  Utilizar iteraciones cortas de 2 a 4 semanas incrementa la productividad del proyecto. dado que el equipo trabaja de forma más eficiente cuando tiene objetivos a corto plazo. entregar unos resultados cerrados que sean susceptibles de ser utilizados por él. El tamaño depende de: o Los condicionantes del proyecto. o En la finalización de cada iteración.  Es necesario disponer de técnicas y herramientas que permitan hacer cambios fácilmente en el producto. el cliente ha de detallar (o haber detallado previamente) los requisitos que se van a desarrollar.  La relación con el cliente ha de estar basada en los principios de colaboración y ganar/ganar más que tratarse de una relación contractual en la cual cada parte únicamente defiende su beneficio a corto plazo. de manera que el resultado sea realmente útil para el cliente y no deje tareas pendientes para futuras iteraciones o para la finalización del proyecto. Asímismo. se minimiza el número de errores que se producen en el desarrollo y se aumentar la calidad. Restricciones  La disponibilidad del cliente debe ser alta durante todo el proyecto dado que participa de manera continua: o El inicio de una iteración. . o La necesidad de tener feedback más o menos rápido.  Cada iteración debe dar como resultado requisitos terminados. manteniendo su complejidad minimizada y su calidad. de manera que pueda crecer en cada iteración de manera incremental sin hacer un gran esfuerzo adicional. con iteraciones cortas la precisión de las estimaciones aumenta.  Cada iteración ha de aportar un valor al cliente. Dado que cada iteración debe dar como resultado requisitos terminados.

etc. o Permite gestionar y sincronizar de manera sencilla las necesidades del proyecto con respecto a las de otros proyectos (integración con el trabajo realizado por otros equipos. en función de la velocidad de desarrollo del equipo (el trabajo que pudo completar en iteraciones anteriores del mismo tamaño). y tomar decisiones al respecto. la organización puede tener medidas de resultados y objetivos a nivel trimestral o cuatrimestral). compartición de personas que son difíciles de asignar a un único equipo). de manera que todas sean un timebox de la misma duración. . la cantidad de trabajo que puede hacer en una iteración (sin tener que hacer extrapolaciones si las iteraciones no fuesen regulares).). o Las iteraciones coincidiendo con meses naturales permiten sincronizar el trabajo del equipo con el de otros departamentos y con el resto de la organización (por ejemplo. o El cliente puede proyectar cuantas iteraciones se necesitan para tener cada entrega. actividades necesarias que no producen valor directo.o Que no se degrade la relación trabajo útil / gestión operativa (por ejemplo reuniones. o El equipo aprende a calcular la velocidad de desarrollo.  Utilizar iteraciones regulares.