REPBLICA BOLIVARIANA DE VENEZUELA

MINISTERIO DEL PODER POPULAR PARA LA DEFENSA

UNIVERSIDAD NACIONAL EXPERIMENTAL POLITCNICA
DE LA FUERZA ARMADA BOLIVARIANA UNEFA
NCLEO TCHIRA

Modelos de Ciclo de Vida del

Desarrollo del Software (MDS)

Ing. Jhon Duarte

 La ingeniera de software, con el fin de ordenar el caos que era anteriormente el desarrollo de software,
dispone de varios modelos, paradigmas y filosofas de desarrollo, estos los conocemos principalmente como
modelos o ciclos de vida del desarrollo de software, esto incluye el proceso que se sigue para construir, entregar
y hacer evolucionar el software, desde la concepcin de una idea hasta la entrega y el retiro del sistema y
representa todas las actividades y artefactos (productos intermedios) necesarios para desarrollar una aplicacin

1) Modelo en cascada o clsico En ingeniera de software el modelo en cascada tambin llamado

desarrollo en cascada o ciclo de vida clsico se basa en un enfoque metodolgico que ordena
rigurosamente las etapas del ciclo de vida del software, esto sugiere una aproximacin sistemtica
secuencial hacia el proceso de desarrollo del software, que se inicia con la especificacin de requisitos
del cliente y contina con la planificacin, el modelado, la construccin y el despliegue para culminar en
el soporte del software terminado
En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en cascada (denominado
as por la posicin de las fases en el desarrollo de esta, que parecen caer en cascada por gravedad hacia las
siguientes fases), es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo
de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.1 Al final
de cada etapa, el modelo est diseado para llevar a cabo una revisin final, que se encarga de determinar si el
proyecto est listo para avanzar a la siguiente fase. Este modelo fue el primero en originarse y es la base de todos
los dems modelos de ciclo de vida.

Un ejemplo de una metodologa de desarrollo en cascada es:

1. Anlisis de requisitos.
2. Diseo del Sistema.
3. Diseo del Programa.
4. Codificacin.
5. Pruebas.
6. Verificacin.
7. Mantenimiento.
De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y
nueva programacin del cdigo afectado, aumentando los costos del desarrollo. La palabra cascada sugiere,
mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases
ms avanzadas de un proyecto.

Anlisis de requisitos
En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos
debe cubrir. De esta fase surge una memoria llamada SRD (documento deespecificacin de requisitos),
que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos.

Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del sistema y ser
aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del
proceso de elaboracin del software de una manera.

Diseo del Sistema

Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las
ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software),
que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe
hacer cada una de sus partes, as como la manera en que se combinan unas con otras.
 Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de
ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el
problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus
relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos
empleados y la organizacin del cdigo para comenzar la implementacin...

Diseo del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del
usuario as como tambin los anlisis necesarios para saber qu herramientas usar en la etapa de
Codificacin

Codificacin
Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y
ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes
reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms
rpido.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se comprueba que funciona
correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

Verificacin
Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron
exhaustivas pruebas para comprobar que el sistema no falle.
En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y pruebas del mismo.

Mantenimiento
Una de las etapas ms crticas, ya que se destina un 75 % de los recursos, es el mantenimiento del
Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas.

Ventajas
Realiza un buen funcionamiento en equipos dbiles y productos maduros, por lo que se requiere de menos
capital y herramientas para hacerlo funcionar de manera ptima.
Es un modelo fcil de implementar y entender.
Est orientado a documentos.
Es un modelo conocido y utilizado con frecuencia.
Promueve una metodologa de trabajo efectiva: Definir antes que disear, disear antes que codificar.

Desventajas
En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del
modelo, lo cual hace que lo lleve al fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y
 hasta que el software no est completo no se opera. Esto es la base para que funcione bien.
Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva
programacin del cdigo afectado, aumentando los costos del desarrollo.
Una etapa determinada del proyecto no se puede llevar a cabo a menos de que se haya culminado la etapa
anterior.

2) Modelo de prototipos En ingeniera de software, el modelo de prototipos pertenece a los modelos de

desarrollo evolutivo. Este permite que todo el sistema, o algunos de sus partes, se construyan
rpidamente para comprender con facilidad y aclarar ciertos aspectos en los que se aseguren que el
desarrollador, el usuario, el cliente estn de acuerdo en lo que se necesita as como tambin la solucin
que se propone para dicha necesidad y de esta manera minimizar el riesgo y la incertidumbre en el
desarrollo, este modelo se encarga del desarrollo de diseos para que estos sean analizados y prescindir
de ellos a medida que se adhieran nuevas especificaciones, es ideal para medir el alcance del producto,
pero no se asegura su uso real. Este modelo principalmente se aplica cuando un cliente define un
conjunto de objetivos generales para el software a desarrollarse sin delimitar detalladamente los
requisitos de entrada procesamiento y salida, es decir cuando el responsable no est seguro de la eficacia
de un algoritmo, de la adaptabilidad del sistema o de la manera en que interacta el hombre y la
mquina. Este modelo se encarga principalmente de ayudar al ingeniero de sistemas y al cliente a
entender de mejor manera cul ser el resultado de la construccin cuando los requisitos estn
satisfechos. 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 codigo
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 desarrollador 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 reacio 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.

3) Modelo en espiral El modelo en espiral, que Barry Boehm propuso originalmente en 1986, es un
modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la construccin de
prototipos con los aspectos controlados y sistemticos del modelo en cascada, es decir, cuando se aplica
este modelo, el software se desarrolla en una serie de entregas evolutivas (ciclos o iteraciones), cada una
de estas entregando prototipos ms completas que el anterior, todo esto en funcin del anlisis de riesgo
y las necesidades del cliente. Aunque el modelo espiral representa ventajas por sobre el desarrollo lineal,
el clculo de los riesgos puede ser muy complicado y por lo cual su uso en el mbito real es muy escaso.
El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez por Barry
Boehm en 1986,1 utilizado generalmente en la Ingeniera de software. Las actividades de este modelo se
conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades
no estn fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo,
comenzando por el bucle interior.

La Ingeniera de software, se vale y establece a partir de una serie de modelos que establecen y muestran
las distintas etapas y estados por los que pasa un producto software, desde su concepcin inicial, pasando por su
desarrollo, puesta en marcha y posterior mantenimiento, hasta la retirada del producto. A estos modelos se les
denomina modelos de ciclo de vida del software. El primer modelo concebido fue el de Royce, ms
comnmente conocido como desarrollo en cascada o desarrollo lineal secuencial. Este modelo establece que las
diversas actividades que se van realizando al desarrollar un producto software se suceden de forma lineal.
Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de esfuerzo y tiempo que
se consume en hacer productos software; y Modelos de Ciclo de Vida; ide y promulg un modelo desde un
enfoque distinto al tradicional en Cascada: El Modelo Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral
tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza
mirando las posibles alternativas de desarrollo, se opta por la de riesgo ms asumible y se hace un ciclo de la
espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar las distintas nuevas
alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que llegue un momento en el que el producto
software desarrollado sea aceptado y no necesite seguir mejorndose con otro nuevo ciclo.
 Ciclos o Iteraciones
En cada vuelta o iteracin hay que tener en cuenta:
Los Objetivos: qu necesidad debe cubrir el producto.
Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos
de vista como pueden ser:
1. Caractersticas: experiencia del personal, requisitos a cumplir, etc.
2. Formas de gestin del sistema.
3. Riesgo asumido con cada alternativa.
Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:
Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una
forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular:
1. Angular: Indica el avance del proyecto del software dentro de un ciclo.
2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteracin se pasa ms tiempo
desarrollando.
Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por ejemplo, la creacin de un
Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno de los aspectos fundamentales
de su xito radica en que el equipo que lo aplique tenga la necesaria experiencia y habilidad para detectar y
catalogar correctamente los riesgos.

Tareas
Para cada ciclo habr cuatro actividades:
1. Determinar Objetivos.
2. Anlisis del riesgo.
3. Desarrollar y probar.
4. 'Planificacin.'
Determinar o fijar objetivos
Fijar tambin los productos definidos a obtener: requisitos, especificacin, manual de usuario.
Fijar las restricciones.
Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planificacin inicial.

Desarrollar, verificar y validar(probar)

Tareas de la actividad propia y de prueba.
Anlisis de alternativas e identificacin resolucin de riesgos.
Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el desarrollo, el que
puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As si por ejemplo si
los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la
construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal consideracin, un
desarrollo basado en transformaciones formales podra ser el ms apropiado.

Anlisis del riesgo

Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los
daos y consecuencias que stas puedan producir. Se evalan alternativas. Se debe tener un prototipo
 antes de comenzar a desarrollar y probar.
En resumen, es para tener en cuenta de los riesgos de cada uno de los ambitos

Mecanismos de control
La dimensin radial mide el coste.
La dimensin angular mide el grado de avance del proyecto.

Variaciones del Modelo En Espiral

Modelo en Espiral Tpico de seis regiones

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de computadora, a diferencia
del modelo de proceso clsico que termina cuando se entrega el software.
Las 6 regiones que componen este modelo son las siguientes:
Comunicacin con el cliente - Tareas necesarias para plantear la comunicacin entre el desarrollador y el
cliente.
Planificacin - Tareas inherentes a la definicin de recursos, el tiempo y otras informaciones
relacionadas con el proyecto. Son todos los requerimientos.
Anlisis de riesgos Tareas para evaluar riesgos tcnicos y otras informaciones relacionadas con el
proyecto.
Ingeniera - Tareas para construir una o ms representaciones de la aplicacin.
Construccin y adaptacin - Tareas requeridas para construir, probar, instalar y proporcionar soporte a
los usuarios.
Evaluacin del cliente - Tareas requeridas para obtener la reaccin del cliente segn la evaluacin de las
representaciones del software creadas durante la etapa de ingeniera e implementacin durante la etapa
de instalacin.3

Ventajas
El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos.
Reduce riesgos del proyecto
Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento, etc.
Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este
ciclo de vida no es rgido ni esttico.

Desventajas
Genera mucho tiempo en el desarrollo del sistema
Modelo costoso
Requiere experiencia en la identificacin de riesgos

Inconvenientes
Planificar un proyecto con esta metodologa es a menudo imposible, debido a la incertidumbre en el nmero de
iteraciones que sern necesarias. En este contexto la evaluacin de riesgos es de la mayor importancia y, para
grandes proyectos, dicha evaluacin requiere la intervencin de profesionales de gran experiencia.
 4) Modelo de desarrollo por etapas Es un modelo en el que el software se muestra al cliente en etapas
refinadas sucesivamente. Con esta metodologa se desarrollan las capacidades ms importantes
reduciendo el tiempo necesario para la construccin de un producto; el modelo de entrega por etapas es
til para el desarrollo de la herramienta debido a que su uso se recomienda para problemas que pueden
ser tratados descomponindolos en problemas ms pequeos y se caracteriza principalmente en que las
especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando
simultneamente con las diferentes versiones del cdigo.
En este modelo pueden distinguirse las siguientes fases:
Especificacin conceptual.
Anlisis de requisitos.
Diseo inicial.
Diseo detallado (codificacin, depuracin, prueba y liberacin).
Cuando es por etapas, en el diseo global estas fases pueden repetirse segn la cantidad de etapas que sean
requeridas.
Entre sus ventajas tenemos:
Deteccin de problemas antes y no hasta la nica entrega final del proyecto.
Eliminacin del tiempo en informes debido a que cada versin es un avance.
Estimacin de tiempo por versin, evitando errores en la estimacin del proyecto general.
Cumplimiento a la fecha por los desarrolladores.

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el
software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas
en detalle al inicio del proyecto y por tanto se van desarrollando simultneamente con las diferentes versiones
del cdigo.
Pueden distinguirse las siguientes fases:
Especificacin conceptual
Anlisis de requisitos
Diseo inicial
Diseo detallado, codificacin, depuracin y liberacin

Estas diferentes fases se van repitiendo en cada etapa del diseo.

Este modelo estipula que el software ser desarrollado en sucesivas etapas:

1. Plan operativo Etapa donde se define el problema a resolver, las metas del proyecto, las metas de calidad y se
identifica cualquier restriccin aplicable al proyecto.

2. Especificacin de requisitos Permite entregar una visin de alto nivel sobre el proyecto, poniendo nfasis en
la descripcin del problema desde el punto de vista de los clientes y desarrolladores. Tambin se considera la
posibilidad de una planificacin de los recursos sobre una escala de tiempos.
3. Especificacin funcional Especifica la informacin sobre la cual el software a desarrollar trabajar.
4. Diseo Permite describir como el sistema va a satisfacer los requisitos. Esta etapa a menudo tiene diferentes
niveles de detalle. Los niveles ms altos de detalle generalmente describen los componentes o mdulos que
formarn el software a ser producido. Los niveles ms bajos, describen, con mucho detalle, cada mdulo que
contendr el sistema.
5. Implementacin Aqu es donde el software a ser desarrollado se codifica. Dependiendo del tamao del
proyecto, la programacin puede ser distribuida entre distintos programadores o grupos de programadores. Cada
uno se concentrar en la construccin y prueba de una parte del software, a menudo un subsistema. Las pruebas,
en general, tiene por objetivo asegurar que todas las funciones estn correctamente implementadas dentro del
sistema.
6. Integracin Es la fase donde todos los subsistemas codificados independientemente se juntan. Cada seccin
es enlazada con otra y, entonces, probada. Este proceso se repite hasta que se han agregado todos los mdulos y
el sistema se prueba como un todo.
7. Validacin y verificacin Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es
probado para verificar que el sistema es consistente con la definicin de requisitos y la especificacin funcional.
Por otro lado, la verificacin consiste en una serie de actividades que aseguran que el software implementa
correctamente una funcin especfica. Al finalizar esta etapa, el sistema ya puede ser instalado en ambiente de
explotacin.
8. Mantenimiento El mantenimiento ocurre cuando existe algn problema dentro de un sistema existente, e
involucrara la correccin de errores que no fueron descubiertos en las fases de prueba, mejoras en la
implementacin de las unidades del sistema y cambios para que responda a los nuevos requisitos. Las
mantenciones se puede clasificar en: correctiva, adaptativa, perfectiva y preventiva.

5) Modelo Incremental o Iterativo Desarrollo iterativo y creciente (o incremental) es un proceso de

desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada, es decir,
este modelo aplica secuencias lineales como el modelo en cascada, pero de una manera iterativa o
escalada segn como avance el proceso de desarrollo y con cada una de estas secuencias lineales se
producen incrementos (mejoras) del software. Se debe tener en cuenta que el flujo del proceso de
cualquier incremento puede incorporar el paradigma de construccin de prototipos, ya que como se
mencion anteriormente, este tipo de modelo es iterativo por naturaleza, sin embargo se diferencia en
que este busca la entrega de un producto operacional con cada incremento que se le realice al software.
Este desarrollo incremental es til principalmente cuando el personal necesario para una implementacin
completa no est disponible.
Desarrollo iterativo y creciente (o incremental) es un proceso de desarrollo de software creado en respuesta a
las debilidades del modelo tradicional de cascada.
Bsicamente este modelo de desarrollo, que no es ms que un conjunto de tareas agrupadas en pequeas etapas
repetitivas (iteraciones), es uno de los ms utilizados en los ltimos tiempos ya que, como se relaciona con
novedosas estrategias de desarrollo de software y una programacin extrema, es empleado en metodologas
diversas.
El modelo consta de diversas etapas de desarrollo en cada incremento, las cuales inician con el anlisis y
finalizan con la instauracin y aprobacin del sistema.

Concepto de desarrollo iterativo y creciente

Se planifica un proyecto en distintos bloques temporales que se le denominan iteracin. En una iteracin se
repite un determinado proceso de trabajo que brinda un resultado ms completo para un producto final, de forma
que quien lo utilice reciba beneficios de este proyecto de manera creciente.
Para llegar a lograr esto, cada requerimiento debe tener un completo desarrollo en una nica iteracin que debe
de incluir pruebas y una documentacin para que el equipo pueda cumplir con todos los objetivos que sean
necesarios y est listo para ser dado al cliente. As se evita tener arriesgadas actividades en el proyecto
finalizado.
Lo que se busca es que en cada iteracin los componentes logren evolucionar el producto dependiendo de los
completados de las iteraciones antecesoras, agregando ms opciones de requisitos y logrando as un
mejoramiento mucho ms completo.
Una manera muy primordial para dirigir al proceso iterativo incremental es la de priorizar los objetivos y
requerimientos en funcin del valor que ofrece el cliente.3
Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks (entornos de
trabajo), de los cuales los dos ms famosos son el Rational Unified Process El desarrollo incremental e iterativo
es tambin una parte esencial de un tipo de programacin conocido como Extreme Programming y los dems
frameworks de desarrollo rpido de software.

Ciclo de vida
La idea principal detrs de mejoramiento iterativo es desarrollar un sistema de programas de manera
incremental, permitindole al desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo
anterior, incrementando, versiones entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo
del sistema, y su uso (mientras sea posible). Los pasos claves en el proceso son comenzar con una
implementacin simple de los requerimientos del sistema, e iterativamente mejorar la secuencia evolutiva de
versiones hasta que el sistema completo est implementado. En cada iteracin, se realizan cambios en el diseo y
se agregan nuevas funcionalidades y capacidades al sistema.
Bsicamente este modelo se basa en dos premisas:
Los usuarios nunca saben bien que es lo que necesitan para satisfacer sus necesidades.
En el desarrollo, los procesos tienden a cambiar.4
El proceso en s mismo consiste de:
Etapa de inicializacin
Etapa de iteracin
Lista de control de proyecto

Consideraciones sobre el momento de aplicacin

Para integrar la usabilidad en un proceso de desarrollo, no es suficiente con asignar tcnicas de usabilidad a
actividades de desarrollo, puesto que no todas las tcnicas de usabilidad son aplicables en cualquier momento de
un desarrollo iterativo. Por ejemplo, las tcnicas para desarrollar el concepto del producto estn concebidas para
su aplicacin en en los primeros esfuerzos del desarrollo, cuando las necesidades se identifican y el esquema
general del sistema se establece. Aunque es aconsejable aplicarlas tambin ms tarde, para refinar el concepto, su
principal esfuerzo de aplicacin esta en las tareas iniciales de desarrollo.5

Etapa de inicializacin
Se crea una versin del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda
interactuar, y por ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y
proveer una solucin lo suficientemente simple para ser comprendida e implementada fcilmente. Para guiar el
proceso de iteracin se crea una lista de control de proyecto, que contiene un historial de todas las tareas que
necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas, y areas de
rediseo de la solucin ya existente. Esta lista de control se revisa peridica y constantemente como resultado
de la fase de anlisis.

Etapa de iteracin
Esta etapa involucra el rediseo e implementacin de una tarea de la lista de control de proyecto, y el anlisis de
la versin ms reciente del sistema. La meta del diseo e implementacin de cualquier iteracin es ser simple,
directa y modular, para poder soportar el rediseo de la etapa o como una tarea aadida a la lista de control de
proyecto. El cdigo puede, en ciertos casos, representar la mayor fuente de documentacin del sistema. El
anlisis de una iteracin se basa en la retroalimentacin del usuario y en el anlisis de las funcionalidades
disponibles del programa. Involucra el anlisis de la estructura, modularidad, usabilidad, confiabilidad,
eficiencia y eficacia (alcanzar las metas). La lista de control del proyecto se modifica bajo la luz de los
resultados del anlisis.
Las guas primarias que guan la implementacin y el anlisis incluyen:
Cualquier dificultad en el diseo, codificacin y prueba de una modificacin debera apuntar a la
necesidad de redisear o recodificar.
Las modificaciones deben ajustarse fcilmente a los mdulos fciles de encontrar y a los aislados. Si no
es as, entonces se requiere algn grado de rediseo.
Las modificaciones a las tablas deben ser especialmente fciles de realizar. Si dicha modificacin no
ocurre rpidamente, se debe aplicar algo de rediseo.
Las modificaciones deben ser ms fciles de hacer conforme avanzan las iteraciones. Si no es as, hay un
problema primordial usualmente encontrado en un diseo dbil o en la proliferacin excesiva de parches
al sistema.
Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para
evitar el rediseo durante una fase de implementacin.
La implementacin existente debe ser analizada frecuentemente para determinar qu tal se ajusta a las
metas del proyecto.
Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el anlisis de
implementaciones parciales.
La opinin del usuario debe ser solicitada y analizada para indicar deficiencias en la implementacin
referida por l.

6) Modelo estructurado Este modelo como su nombre lo indica utiliza las tcnicas del diseo
estructurado o de la programacin estructurada para su desarrollo, tambin se utiliza en la creacin de
los algoritmos del programa. Este formato facilita la comprensin de la estructura de datos y su control.
Entre las principales caractersticas de este modelo se encuentan las siguientes:
Generalmente se puede diferenciar de una manera ms clara los procesos y las estructuras de datos.
Existen mtodos que se enfocan principalmente en ciertos datos.
La abstraccin del programa es de un nivel mucho mayor.
Los procesos y estructuras de datos son representados jerrquicamente.
Este modelo tambin presenta sus desventajas entre las cuales podemos mencionar algunas:
Se poda encontrar datos repetidos en diferentes partes del programa.
Cuando el cdigo se hace muy extenso o grande su manejo se complica demasiado.
En el modelo estructurado las tcnicas que comnmente se utilizan son:
El modelo entidad-relacin, esta tcnica se relaciona principalmente con los datos.
El diagrama de flujo de datos, esta es utilizada principalmente para los procesos.

7) Modelo orientado a objetos

Estos modelos tienen sus races en la programacin orientada a objetos y como consecuencia de ella gira entorno
al concepto de clase, tambin lo hacen el anlisis de requisitos y el diseo. Esto adems de introducir nuevas
tcnicas, tambin aprovecha las tcnicas y conceptos del desarrollo estructurado, como diagramas de estado y
transiciones. El modelo orientado a objetos tiene dos caractersticas principales, las cuales ha favorecido su
expansin:
Permite la reutilizacin de software en un grado significativo.
Su simplicidad facilita el desarrollo de herramientas informticas de ayuda al desarrollo, el cual es
fcilmente implementada en una notacin orientada a objetos llamado UML.