Desarrollo incremental

El modelo de desarrollo incremental es el ciclo de vida de desarrollo software en el cual

un proyecto es descompuesto en una serie de incrementos, cada uno de los cuales
suministra una porción de la funcionalidad respecto de la totalidad de los requisitos del
proyecto. Los requisitos tienen asignada una prioridad y son entregados según el orden
de prioridad en el incremento correspondiente. En algunas (pero no en todas) versiones
de este modelo de ciclo de vida, cada subproyecto sigue un “mini-modelo V” con sus
propias fases de diseño, codificación y pruebas.
¿Como nació?
El modelo incremental fue propuesto por Harlan Mills en el año 1980. Surgió el enfoque
incremental de desarrollo como una forma de reducir la repetición del trabajo en el
proceso de desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos
hasta adquirir experiencia con el sistema. Este modelo se conoce también bajo las
siguientes denominaciones:
Método de las comparaciones limitadas sucesivas.
Ciencia de salir del paso.
Método de atacar el problema por ramas.
Proceso
En una visión genérica, el proceso se divide en 4 partes
• Análisis
• Diseño
• Código
• Prueba

El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del

sistema, seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio
ciclo de vida y se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una
vez entregado un incremento, no se realizan cambios sobre el mismo, sino únicamente
corrección de errores. Dado que la arquitectura completa se desarrolla en la etapa inicial,
es necesario conocer los requerimientos completos al comienzo del desarrollo.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al final
terminará siendo la solución completa requerida por el cliente, pero éstas partes no se
pueden realizar en cualquier orden, sino que dependen de lo que el cliente este
necesitando con más urgencia, de los puntos más importantes del proyecto, los
requerimientos más básicos, difíciles y con mayor grado de riesgo, ya que estos se deben
hacer al comienzo, de manera que se disminuya la dificultad y el riesgo en cada versión.
Características
• 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 costo 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 positivo.
• Cada incremento agrega funcionalidad adicional o mejorada sobre el sistema.
• Cada etapa debe cumplir con los requisitos de las desarrolladas.
• La propuesta del modelo es diseñar sistemas que puedan entregarse por piezas.
• A partir de la evaluación se planea el siguiente incremento y así sucesivamente.
• Es interactivo por naturaleza.
• Es útil cuando el personal no es suficiente para la implementación completa.
• En lugar de entrega del sistema en una sola entrega, el desarrollo y la entrega están
fracturados bajo incrementos, con cada incremento que entrega parte de la
funcionalidad requerida.

Ventajas
• Los clientes no tienen que esperar hasta que el sistema se entregue completamente
para comenzar a hacer uso de él.
 • Los clientes pueden usar los incrementos iniciales como prototipo para precisarlos
requerimientos posteriores del sistema.
• Minimización del riesgo de falla en el proyecto porque los errores se van
corrigiendo progresivamente.
• El resultado puede ser muy positivo.
Desventajas
• Difícil de aplicar a sistemas transaccionales que tienden a ser integrados y a operar
como un todo.
• Riesgos largos y complejos.
• Pueden aumentar el coste debido a las pruebas.
• Los errores en los requisitos se detectan tarde
• 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 planeación, tanto administrativa como técnica.
• Requiere de metas claras para conocer el estado del proyecto.
 Desarrollo en espiral
El desarrollo en espiral es un modelo de ciclo de vida del software utilizado generalmente
en la ingeniería de software.
Las actividades de este modelo se conforman en una espiral, en la que cada bucle o
iteración representa un conjunto de actividades. Las actividades no están fijadas a ninguna
prioridad, sino que las siguientes se eligen en función del análisis de riesgo, comenzando
por el bucle interior.
¿Como nacio?
El desarrollo en espiral fue propuesto por Barry W. Boehm (1986) en su ensayo "A Spiral
Model of Software Development and Enhancement." En ese momento, el modelo de
desarrollo en cascada prevalecía, por lo que los inconvenientes asociados fueron
discutidos con frecuencia. A diferencia de otros modelos como "code and fix" o el
"modelo cascada", el desarrollo en espiral está basado en el riesgo. La identificación y
resolución de riesgos juega un papel importante en las diferentes espirales del proyecto
una vez definidos los objetivos y condiciones. El enfoque se centra en los posibles
factores que pueden causar incertidumbres para el software o para todo el proyecto. Según
el supuesto, si los riesgos pueden ser controlados de una manera rentable, no hay nada
que impida la finalización exitosa del proyecto. Los enfoques para minimizar estos
riesgos son, por ejemplo, prototipos, simulaciones, pruebas de referencia o entrevistas
con los usuarios. Para ciertos tipos de riesgos, todo el procedimiento puede incluso ser
revisado y estructurado de manera diferente. La intervención de la gerencia o
management es posible en cada fase del proyecto y pueden adaptarse otros enfoques de
desarrollo.
Proceso
El modelo de desarrollo en espiral se caracteriza por los siguientes ciclos (también
cuadrantes):
• Objetivo y determinación alternativa: Los objetivos se determinan
conjuntamente con el cliente. Al mismo tiempo, se discuten posibles alternativas
y se especifican las condiciones marco (por ejemplo, sistemas operativos,
entornos y lenguajes de programación).
• Análisis y evaluación de riesgos: Se identifican y evalúan los riesgos potenciales.
También se evalúan las alternativas existentes. Los riesgos son registrados,
evaluados y luego reducidos utilizando prototipos, simulaciones y softwares de
análisis. En este ciclo, existen varios prototipos como plantillas de diseño o
componentes funcionales
• Desarrollo y prueba: Los prototipos se amplían y se añaden funcionalidades. El
código real es escrito, probado y migrado a un entorno de prueba varias veces
hasta que el software pueda ser implementado en un entorno productivo.
• Planificación del siguiente ciclo: El siguiente ciclo se planifica al final de cada
etapa. Si se producen errores, se buscan soluciones, y si una alternativa es una
mejor solución, se prefiere en el siguiente ciclo.
La fuerza impulsora más importante del desarrollo en espiral es el análisis y la evaluación
de riesgos. Cualquier riesgo que amenace el proyecto debe ser identificado desde el
principio. El progreso del proyecto depende decisivamente de cómo se puedan eliminar
los riesgos. El proyecto se considera exitoso sólo cuando no hay riesgos. El objetivo del
ciclo es producir un producto en continua mejora. El software o la aplicación se
perfecciona constantemente. El modelo en espiral es incremental, pero no necesariamente
repetitivo. Las repeticiones ocurren sólo cuando los riesgos, errores o conflictos
amenazan el proyecto. Entonces el producto tiene que pasar por un ciclo de nuevo,
llamado una iteración o repetición.

Características
• Contiene una nueva etapa que es el análisis de riesgos, no incluida anteriormente.
• Este modelo es el indicado para desarrollar software con diferentes versiones
actualizadas como se hace con los programas modernos de PC´s.
• La ingeniería puede desarrollarse a través del ciclo de vida clásico o el de
construcción de prototipos.
• Este es el enfoque más realista actualmente.
Ventajas
• No requiere una definición completa de los requerimientos del software a
desarrollar para comenzar su funcionalidad.
• En la terminación de un producto desde el final de la primera iteración es muy
factible aprobar los requisitos.
• Sufrir retrasos corre un riesgo menor, porque se comprueban los conflictos
presentados tempranamente y existe la forma de poder corregirlos a tiempo.
• Reduce riesgos del proyecto
• Incorpora objetivos de calidad
• Integra el desarrollo con el mantenimiento, etc.
Desventajas
• Existe complicación cuando se evalúa los riesgos.
• Se requiere la participación continua por parte del cliente.
• Se pierde tiempo al volver producir inicialmente una especificación completa de
los requerimientos cuando se modifica o mejora el software.
• Genera mucho tiempo en el desarrollo del sistema
• Modelo costoso
• Requiere experiencia en la identificación de riesgos