METODOLOGIA EVOLUTIVO

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)
1
, 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
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 de 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 riesgosas 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 y el Dynamic Systems Development Method. 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.
El proceso en s mismo consiste de:
Etapa de inicializacin
Etapa de iteracin
Lista de control de proyecto
Consideraciones sobre el momento de aplicacion
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 aplicarles tambin ms tarde, para refinar el
concepto, su principal esfuerzo de aplicacin esta en las tareas iniciales de desarrollo
.

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.

CARACTERISTICAS
Usando anlisis y mediciones como guas para el proceso de mejora es una diferencia mayor
entre las mejoras iterativas y el desarrollo rpido de aplicaciones, principalmente por dos
razones:
Provee de soporte para determinar la efectividad de los procesos y de la calidad del
producto.
Permite estudiar y despus mejorar y ajustar el proceso para el ambiente en particular.
Estas mediciones y actividades de anlisis pueden ser aadidas a los mtodos de desarrollo
rpido existentes.
De hecho, el contexto de iteraciones mltiples conlleva ventajas en el uso de mediciones. Las
medidas a veces son difciles de comprender en lo absoluto, aunque en los cambios relativos
en las medidas a travs de la evolucin del sistema puede ser muy informativo porque
proveen una base de comparacin. Por ejemplo, un vector de medidas m1, m2,..., mn puede
ser definido para caracterizar varios aspectos del producto en cierto punto, como pueden ser
el esfuerzo total realizado, los cambios, los defectos, los atributos lgico, fsico y dinmico,
consideraciones del entorno, etctera. As el observador puede decir como las caractersticas
del producto como el tamao, la complejidad, el acoplamiento y la cohesin incrementan o
disminuyen en el tiempo. Tambin puede monitorearse el cambio relativo de varios aspectos
de un producto o pueden proveer los lmites de las medidas para apuntar a problemas
potenciales y anomalas.

VENTAJAS
En este modelo los usuarios no tienen que esperar hasta que el sistema completo se
entregue para hacer uso de l. El primer incremento cumple los requerimientos ms
importantes de tal forma que pueden utilizar el software al instante.
Los usuarios pueden utilizar los incrementos iniciales como prototipos y obtener
experiencia sobre los requerimientos de los incrementos posteriores del sistema.
Existe muy pocas probabilidades de riesgo en el sistema. Aunque se pueden encontrar
problemas en algunos incrementos, lo normal es que el sistema se entregue sin
inconvenientes al usuario.
Ya que los sistemas de ms alta prioridad se entregan primero, y los incrementos
posteriores se integran entre ellos, es muy poco probable que los sistemas ms
importantes sean a los que se les hagan ms pruebas. Esto quiere decir que es menos
probable que los usuarios encuentren fallas de funcionamiento del software en las partes
ms importantes del sistema.
6


DEBILIDADES DEL MODELO
La entrega temprana de los proyectos produce la creacin de sistemas demasiados
simples que a veces se ven un poco montonos a los ojos del personal que lo recibe.
La mayora de los incrementos se harn en base de las necesidades de los usuarios. Los
incrementos en si ya son estipulados desde antes de la entrega del proyecto, sin embargo
hay que ver cmo se maneja el producto para ver si necesita otros cambios adems de
los estipulados antes de la entrega del proyecto. Este problema no se ve frecuentemente
ya que la mayora de las veces los incrementos estipulados suplen satisfactoriamente al
usuario.
Los incrementos no deben constar de muchas lneas de cdigo ya que la idea de los
incrementos es agregar accesorios al programa principal (o funcional), para que este
tenga una y mil formas de desenvolverse en su tarea; llenar los incrementos de muchas
lneas de cdigo provocara que se perdiera la objetividad o base de lo que se trata el
desarrollo incremental.
Requiere de un cliente involucrado durante todo el curso del proyecto. Hay clientes que
simplemente no estarn dispuestos a invertir el tiempo necesario.
El trato con el cliente debe basarse en principios ticos y colaboracin mutua, ms que
trabajar cada parte independientemente, defendiendo slo su propio beneficio.
La entrega de un programa que es parcial pero funcional puede hacer vulnerable al
programa debido a la falta de robustez en su sistema, provocando que agentes ajenos
puedan interferir con el correcto funcionamiento del programa en s.
Infunde responsabilidad en el equipo de desarrollo al trabajar directamente con el cliente,
requiriendo de profesionales sobre el promedio.
Sufre fuertes penalizaciones en proyectos en los cuales los requerimientos estn
previamente definidos, o para proyectos "todo/nada" en los cuales se requiere que se
completen en un 100% el producto para ser implementado (por ejemplo, licitaciones) otro
punto muy importante es asegurarnos de que el trabajo se pueda cumplir tomando en
cuenta los costos que podamos usar en nuestros propios recursos.

ESPIRAL
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.
Ciclos
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: requerimientos, 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 e cada uno de los ambitos

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

PUD
El Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es
un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso,
centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y
documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP.
El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que
puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso
Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces
resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso
Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un
mismo concepto.
El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos
elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite
evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas
por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el
tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de
Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady
Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML,
el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el
tema y que no estn afiliados a Rational utilizan el trmino Proceso Unificado, mientras que
los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational.


Fases
El Proceso Unificado de desarrollo puede ser dividido en cuatro fases para su mejor
desarrollo. Estas fases ayudando tanto a la elaboracin como a la resolucin de problemas.
Inicio
En la fase de inicio se define el negocio: facilidad de realizar el proyecto, se presenta un
modelo, visin, metas, deseos del usuario, plazos, costos y viabilidad.
Elaboracin
En esta fase se obtiene la visin refinada del proyecto a realizar, la implementacin iterativa
del ncleo del de la aplicacin, la resolucin de riesgos altos, nuevos requisitos y se ajustan
las estimaciones.
Construccin
Esta abarca la evolucin hasta convertirse en producto listo incluyendo requisitos mnimos.
Aqu se afinan los detalles menores como los diferentes tipos de casos o los riesgos menores.
Transicin
En esta fase final, el programa debe estar listo para ser probado, instalado y utilizado por el
cliente sin ningn problema. Una vez finalizada esta fase, se debe comenzar a pensar en
futuras novedades para la misma.
Desde el punto de vista Tcnico: el proyecto est formado por los flujos de trabajo
fundamentales: captura de requerimientos, anlisis, diseo, implementacin y pruebas.
Tantos el punto de vista Gerencial como el Tcnico concuerdan en: La iteracin .