You are on page 1of 12

PORTADA

Arreglar portada

















Tabla de contenido
Introduccin ........................................................................................................................................ 3
Definicin ........................................................................................................................................ 4
Diseo.......................................................................................................................................... 5
Tipos de Desarrollo Evolutivo ............................................................................................................ 6
Escribir el ttulo del captulo (nivel 2) .............................................................................................. 5
Escribir el ttulo del captulo (nivel 3).......................................................................................... 6
















Arreglar ndice















INTRODUCCION





Hacer introduccin en base a http://www.slideshare.net/jpbthames/modelos-evolutivos-
incremental-y-espiral





















Modelo de desarrollo evolutivo

1. Definicin


El desarrollo evolutivo es una metodologa de desarrollo de software muy
relacionada con, pero claramente distinta de, desarrollo por prototipos. El nfasis
esta puesto sobre la importancia de obtener un sistema de produccin flexible y
expandible. As, si los requerimientos cambian durante el desarrollo del sistema,
entonces con un mnimo de esfuerzo y tiempo se puede desarrollar un sistema de
trabajo flexible.
La diferencia fundamental entre desarrollo evolutivo y prototipos de software es
que el desarrollo evolutivo busca remplazar el viejo sistema con uno nuevo que
tendra la propiedad de satisfacer los nuevos requerimientos lo ms rpido posible.
En contraste, prototipos usa un enfoque iterativo solo para determinar los
requerimientos organizacionales. Por lo tanto el tiempo tomado entre cada
iteracin es mucho ms importante para el desarrollo evolutivo. En la figura 10 se
puede ver grficamente esta diferencia.
El desarrollo evolutivo asume que los requerimientos de un proyecto estn sujetos
a cambios continuos, por lo cual es necesario definir una estrategia de desarrollo
que refleje esta situacin. En cambio, el desarrollo orientado a prototipos, as
como los anteriores, asume que los requerimientos "reales" existen y se vale de
las iteraciones del prototipo para establecerlos y modelarlos.
La idea entonces de la metodologa de desarrollo evolutivo es estar liberando
constantemente una nueva versin del sistema que sea completamente funcional;
as, cada sistema producto de las iteraciones sucesivas del mtodo tendra
incorporado los nuevos requerimientos que ha sido posible identificar y que no
estaran considerados en la anterior versin.
As, las etapas del desarrollo evolutivo tienen por objetivo extender los
incrementos de un producto de software operacional, en las direcciones
determinadas por la evolucin de la experiencia operacional.










2. Diseo

Se construye una serie de grandes versiones sucesivas de un producto, asumiendo que los
requerimientos no son completamente conocidos al inicio del proyecto. Una vez creada la
primera versin del producto, los usuarios la usan y proveen retroalimentacin a los
desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es
actualizada y se desarrolla una nueva versin del producto. El proceso se repite
indefinidamente. Requiere de un cuidado especial en la manipulacin de documentos,
programas, datos de test, etc. Desarrollados para distintas versiones del software











3. Tipos de Desarrollo

Hay 2 tipos de desarrollo evolutivo:

1.- Desarrollo exploratorio: El objetivo de este enfoque es explorar con el usuario los requisitos
hasta llegar a un sistema final. El desarrollo comienza con las partes que se tiene ms claras.
El sistema evoluciona conforme se aaden nuevas caractersticas propuestas por el usuario


2.- Prototipos desechables: El objetivo es entender los requisitos del usuario y trabajar para
mejorar la calidad de los requisitos. A diferencia del desarrollo exploratorio, se comienza por
definir los requisitos que no estn claros para el usuario y se utiliza un prototipo para
experimentar con ellos. El prototipo ayuda a terminar de definir estos requisitos.





Colocar ejemplos de ambos

















3.1 Ventajas Y desventajas

Ventajas:- Es ms efectivo que el enfoque en cascada, pues satisface las necesidades
inmediatas delos clientes.-La especificacin se puede desarrollar deforma creciente.-
Conforme el usuario entienda mejor su problema, ste se puede reflejar en el sistema de
software.

Desventajas:- El proceso no es visible. Los administradores deben hacer entregas regulares
para medir el progreso- Genera sistemas con estructura deficiente. Los cambios continuos
tienden a corromper la estructura del software.

Recomendaciones pare el modelo evolutivo:* Para sistemas pequeos y medianos (hasta
500,000 lneas de cdigo).* Los problemas de desarrollo evolutivo se agravan en sistemas
grandes y complejos.* Se puede desarrollar un prototipo desechable para resolver
incertidumbres en la especificacin del sistema.























4. Aplicacin

El modelo de desarrollo evolutivo puede ser idealmente asociado a un lenguaje de aplicacin
de cuarta generacin y mejor an a situaciones en que el usuario dice, "yo no puedo hablarte
sobre lo que yo quiero, pero yo lo reconocera si lo viese". As, este mtodo entregara al
usuario rpidamente una capacidad operativa inicial y, adems, establecera una base real
operacin para determinar las mejoras subsecuentes en el producto.

Pero, existiran algunas dificultades tcnicas que no pueden dejar de ser mencionadas, por
ejemplo:

- No facilita la integracin de aplicaciones que han sido desarrolladas como sistemas
independientes.

- Facilita la posibilidad de que existan casos de "esclerosis de informacin", en el sentido que
trabajos temporales alrededor de algunas deficiencias del software se solidifican como
poderes inmodificables a la evolucin. Es decir, en la medida que se evoluciona, esta misma
facilidad a la evolucin llevara a que no sea posible seguir evolucionando.

- Pueden ocurrir que el software nuevo es un remplazo incremental de un subsistema dentro
de un gran sistema existente. Si el sistema existente est pobremente modula rizado,
entonces es obvia la dificultad en hacer que la nueva versin se acople con facilidad al resto.

El mtodo evolutivo tiene la gran ventaja de reconocer la existencia de una constante de
cambios en los requerimientos y, desde esta premisa, propone una solucin, la cual es vlida
para la solucin de ese problema pero que no resolvera la inquietud original, esto es que el
mtodo no facilita elementos que permitan reducir la distancia conceptual entre los dominios
del desarrollador y del usuario.

Con la existencia del mtodo evolutivo se configura una nueva problemtica en el desarrollo
de sistemas, es decir, la crisis se expande ahora en el sentido que no slo se requiere reflejar
lo ms fielmente posible las necesidades del usuario, sino que ahora los ambientes en que el
sistema est inserto estn sujetos a cambios y estos cambios inciden en la efectividad del
software desarrollado. Lo anterior fue articulado por Meir M. Lehman a principio de la dcada
de los ochenta, al definir las leyes de la evolucin del software, en que las dos primeras leyes
tienen directa relacin con lo que se describe. Veamos a Lehman citado por Ian Sommerville,
en el libro Ingeniera de Software:

Lehman propone que la evolucin de un sistema de software esta sujeta a varias leyes. Ha
determinado estas leyes a partir de observaciones experimentales de varios sistemas, como
los grandes sistemas operativos (...). Dice Lehman que hay cinco leyes de la evolucin de los
programas:
Cambio Continuo.
Un programa que se utiliza en un ambiente del mundo real debe cambiar o ser cada vez
menos til en ese ambiente.

Complejidad creciente.

A medida que un programa en evolucin cambia, su estructura se hace ms compleja, a
menos que se lleven a cabo esfuerzos activos para evitar este fenmeno.

Evolucin del programa.

La evolucin del programa es un proceso autor regulador, y una medicin de atributos del
sistema, como el tamao, el tiempo entre versiones, el nmero de errores advertidos, etc.,
revela las tendencias estadsticas significativas y las caractersticas invariantes.

Conservacin de la estabilidad organizativa.

Durante el tiempo de vida de un programa, su rapidez de desarrollo es casi constante e
independiente de los recursos dedicados al desarrollo del sistema.

Conservacin de la familiaridad.

Durante el tiempo de vida de un sistema, la evolucin del cambio del sistema en cada versin
es, aproximadamente, constante.

Sommerville considera las "leyes" de Lehman como elementos positivos en la configuracin
del mbito en que se desarrollan los sistemas, por ejemplo, dice que las dos primeras
hiptesis de Lehman son casi con certeza vlidas. Interpretando la primera como: ...El
razonamiento subyacente en la primera ley... es que cuando un sistema de software (sobre
todo uno grande) se construye para modelar algn ambiente y despus se introduce en l,
modificndose as el ambiente original con la presencia del sistema de software... No puede
ser ms interesante para los propsitos de esta revisin la caracterstica planteada por esta
hiptesis, es decir, si se desarrolla software no se podra pensar desde la perspectiva de
estabilidades, todo lo contrario, necesariamente es el cambio el motor y el configurador de los
sistemas de software. Aqu el punto es la introduccin de una nueva perspectiva al problema
del desarrollo de software, perspectiva que ser determinante en el planteamiento de un
modelo que permita reflejarla.

Lo expresado en la primera ley, configura un nuevo problema -como se haba anticipado- para
el desarrollo de software, adems de la distancia conceptual entre desarrollador y usuario,
existira el problema de la evolucin constante de la organizaciones o, ms claramente, la con
naturalidad de las organizaciones al cambio como elemento subyacente en su ser
organizacional. Situacin que se haba anticipado en el curso de "Ambientes..."
La segunda ley en el anlisis de Somerville corresponde al hecho de que la estructura del
programa original se estableci para aplicarlo a un conjunto de necesidades iniciales. A
medida que se produce el cambio evolutivo de esas necesidades, la estructura original se
degrada y con ello se va haciendo ms compleja ya que al ir incrementndose la distancia
conceptual entre el software y el medio que lo contiene, ste va estando cada vez ms
presente en el hacer cotidiano, formulando quiebres constantes sobre el sistema de trabajo lo
que imprime un sello de complejidad a la utilizacin del software.
Las siguientes leyes tienen relacin con las caractersticas de las organizaciones y de los
individuos que participan en el proceso de desarrollo de software. Lehman afirma que las
organizaciones se esfuerzan por lograr la estabilidad e intentan evitar cambios drsticos o
repentinos. Por tanto, a medida que se aaden ms recursos a un proyecto de software, el
efecto evolutivo de la adicin de nuevos recursos se va reduciendo, hasta que la adicin de
nuevos recursos no produce ningn efecto. Si bien, estas ltimas leyes no resultan tan obvias
como las primeras y podran ser cuestionadas, es posible que la ltima, que tiene que ver con
la conservacin de la familiaridad sea la ms til, como tambin la de reduccin de personal,
en el sentido que cuanta ms gente trabaje, menos productivo ser cada miembro del
proyecto.

Las proposiciones de Lehman se orientaron a la creacin de un mtodo de desarrollo que
considerase estas caractersticas.

Richard Fairley:
El desarrollo de productos mediante el mtodo de versiones sucesivas es una extensin del
mtodo de prototipos en el que se refina un esqueleto inicial del producto obteniendo as, cada
vez ms capacidades. En dicho me todo, cada versin es un sistema funcional y capaz de
realizar trabajo til. La figura 12a ilustra la fase de anlisis seguida por el diseo de
instrumentacin de versiones sucesivas en un proceso iterativo. Las lneas punteadas indican
que al conseguir la versin I puede necesitarse ms anlisis antes de disear la versin I+1.
En la figura 12b las versiones 1 a la N del producto se disean antes de cualquier actividad de
instrumentacin. En este caso, las caractersticas de cada diseo sucesivo sern planeadas
durante la fase de anlisis. Las lneas punteadas de la figura 12b indican que la
instrumentacin de la 1-esima versin puede demostrar la necesidad de mayor anlisis y
diseo antes de la puesta en marcha de la versin 1+1. El mtodo de versiones sucesivas es
similar, peto no idntico al de mejoras iterativas (BAS75).
En realidad, el ciclo de desarrollo de un producto de programacin es una combinacin de los
distintos modelos presentados. Las organizaciones y proyectos especiales pueden adoptar
alguno de estos modelos en particular; sin embargo, ciertos elementos de ellos se encuentran
en todo proyecto de programacin. Por ejemplo, para proyectos de desarrollo de
programacin no es extrao adoptar el modelo de fases como marco de referencia bsico, e
incluir prototipos y versiones sucesivas en el desarrollo.

Arreglar normas apa
CONCLUSION







COMENTARIOS

You might also like