Sie sind auf Seite 1von 3

MODELO INCREMENTAL

MODELO INCREMENTAL (HISTORIA)


Propuesto por Mills en 1980. Sugiri el enfoque incremental de desarrollo como una forma de
reducir la repeticin 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. Surge porque en los
primeros desarrollos se poda esperar largo tiempo hasta que el software estuviese listo. Las reglas
del negocio de hoy no lo permiten.
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.
Diferencias:
Evolutivo: Se diferencia del modelo por prototipos en que en prototipos se da por hecho que
aunque se necesiten varias iteraciones para lograrlo al final se llegar a tener una serie de
requisitos completos y sin errores, que no vayan a cambiar ms.
En el modelo evolutivo se asume que los requisitos pueden cambiar en cualquier momento del
ciclo de vida y no solo en la etapa de anlisis.
Incremental: Es una aproximacin muy parecida a la evolutiva. En este modelo se desarrolla el
sistema para satisfacer un subconjunto de los requisitos especificados y en posteriores versiones
se incrementa el programa con nuevas funcionalidades que satisfagan mas requisitos.
En el caso del modelo evolutivo se desarrollara una nueva versin de todo el sistema, en el
incremental se parte de la versin anterior sin cambios y le aadimos las nuevas funciones.
Caractersticas:
Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta frecuencia.
El usuario se involucra mas.
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 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.
Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.
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.
Conclusin:
Un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del
producto Software denominados "incrementos" del sistema, que son escogidos en base a
prioridades predefinidas de algn modo.
El modelo permite una implementacin con refinamientos sucesivos (ampliacin y/o mejoras).
Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se
mejora la versin previamente implementada del producto software.

MODELO DE PROTOTIPOS
El Modelo de prototipos, en Ingeniera de software, pertenece a los modelos de desarrollo
evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no
se debe utilizar muchos recursos.
El diseo rpido se centra en una representacin de aquellos aspectos del software que sern
visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el
cual es evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos
del software que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer
las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo
que se debe hacer y el cliente vea resultados a corto plazo.
Etapas
Plan rpido.
Modelado, diseo rpido
Construccin del Prototipo
Desarrollo, entrega y retroalimentacin
Comunicacin
Entrega del desarrollo final

Ventajas
Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no
identifica los requisitos detallados de entrada, procesamiento o salida.
Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro
de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que
debera tomar la interaccin humano-mquina
Se puede reutilizar el cdigo
La construccin de prototipos se puede utilizar como un modelo del proceso independiente, se
emplea ms comnmente como una tcnica susceptible de implementarse dentro del contexto de
cualquiera de los modelos del proceso expuestos. Sin importar la forma en que ste se aplique, el
paradigma de construccin de prototipos ayuda al desarrollado de software y al cliente a entender
de mejor manera cul ser el resultado de la construccin cuando los requisitos estn satisfechos.
De esta manera, este ciclo de vida en particular, involucra al cliente ms profundamente para
adquirir el producto.
Inconvenientes
El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A
causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos
importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte
de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. Es frecuente que el
usuario se muestre reaccin a ello y pida que sobre ese prototipo se construya el sistema final, lo
que lo convertira en un prototipo evolutivo, pero partiendo de un estado poco recomendado.
En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones
de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto
porque proporcione un desarrollo ms rpido). Con el paso del tiempo, el desarrollador puede
olvidarse de la razn que le llev a tomar tales decisiones, con lo que se corre el riesgo de que
dichas elecciones pasen a formar parte del sistema final...
Conclusiones
A pesar de que tal vez surjan problemas, la construccin de prototipos puede ser un paradigma
efectivo para la ingeniera del software. La clave es definir las reglas del juego desde el principio;
es decir, el cliente y el desarrollador se deben poner de acuerdo en:
Que el prototipo se construya y sirva como un mecanismo para la definicin de requisitos.
Que el prototipo se descarte, al menos en parte.
Que despus se desarrolle el software real con un enfoque hacia la calidad.

Das könnte Ihnen auch gefallen