MODELO EVOLUTIVO

Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas
y complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase
de operacin. Los modelos Iterativo Incremental y Espiral (entre otros) son dos de los ms
conocidos y utilizados del tipo evolutivo.
La idea detrs de este modelo es el desarrollo de una implantacin del sistema inicial,
exponerla a los comentarios del usuario, refinarla en N versiones hasta que se desarrolle el
sistema adecuado.Una ventaja de este modelo es que se obtiene una rpida realimentacin del
usuario, ya que las actividades de especificacin, desarrollo y pruebas se ejecutan en cada
iteracin.

Existen dos tipos de desarrollo evolutivo:

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.

Enfoque utilizando prototipos: 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.

Modelos Evolutivos
Los modelos evolutivos son iterativos. Se caracterizan por la forma en que
permiten a los ingenieros del software desarrollar versiones cada vez mas
completas del software.
El software evoluciona con el tiempo. Los requisitos del usuario y del producto
suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la
competencia hacen que no sea posible esperar a poner en el mercado un
producto absolutamente completo, por lo que se aconsejable introducir una
versin funcional limitada de alguna forma para aliviar las presiones
competitivas.

IMAGEN: http://2.bp.blogspot.com/-RVVORwIXkqc/T8PBiKveNtI/AAAAAAAAAAc/cW9B8YbLiGI/s1600/tncmdj.jpg

Modelo Espiral
Es un ciclo de vida de software definido por Barry Boehm en 1988, utilizado
mayormente en la ingeniera de software. Fue descrito por Boehm de la
siguiente manera: El modelo de desarrollo en espiral es un generador de
modelo de proceso guiado por el riesgo que se emplea para conducir sistemas
intensivos de ingeniera de software concurrente y a la vez con muchos
usuarios. Las actividades que conforman este modelo forman una espiral, en
la que cada bucle o interacciona representa un conjunto de actividades. Se
tiene en cuenta fuertemente el riesgo que aparece a la hora de desarrollar
software.

Grfico modelo Espiral

IMAGEN: http://scruz334.blogspot.es/img/espiral.jpg

Planificacin: determinacin

de

objetivos,

alternativas

restricciones.

Anlisis de riesgo : anlisis de alternativas e identificacin/resolucin de

riesgos.
Ingeniera

: desarrollo

del

producto

del

"siguiente

nivel",

Evaluacin del cliente : Valorizacin de los resultados de la ingeniera.

Durante la primera vuelta alrededor de la espiral se definen los objetivos, las
alternativas y las restricciones, y se analizan e identifican los riesgos. Si el
anlisis de riesgo indica que hay una incertidumbre en los requisitos, se puede
usar la creacin de prototipos en el cuadrante de ingeniera para dar asistencia
tanto
al
encargado
de
desarrollo
como
al
cliente.

El cliente evala el trabajo de ingeniera (cuadrante de evaluacin de cliente) y

sugiere modificaciones. Sobre la base de los comentarios del cliente se
produce la siguiente fase de planificacin y de anlisis de riesgo. En cada bucle
alrededor de la espiral, la culminacin del anlisis de riesgo resulta en una
decisin
de
"seguir
o
no
seguir".
Con cada iteracin alrededor de la espiral (comenzando en el centro y
siguiendo hacia el exterior), se construyen sucesivas versiones del software,
cada vez ms completa y, al final, al propio sistema operacional.
El paradigma del modelo en espiral para la ingeniera de software es
actualmente el enfoque ms realista para el desarrollo de software y de
sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniera de
software, permitiendo al desarrollador y al cliente entender y reaccionar a los
riesgos en cada nivel evolutivo. Utiliza la creacin de prototipos como un
mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a
quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier
etapa
de
la
evolucin
de
prototipos.

Caractersticas:
Tiene y esta conformado en un enfoque cclico para el crecimiento del
grado de definicin e implementacin de un sistema, mientras que disminuye
su grado de riesgo.
Utiliza un conjunto de puntos de fijacin para asegurar el compromiso
que asume el usuario con las soluciones de sistema que sean factibles y
totalmente satisfactorias.

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.
Citado de http://es.wikipedia.org/wiki/Desarrollo_en_espiral#Ventajas

Desventajas:
Genera mucho tiempo en el desarrollo del sistema

Modelo costoso

Requiere experiencia en la identificacin de riesgos

Citado de: http://es.wikipedia.org/wiki/Desarrollo_en_espiral#Desventajas

conclusiones
Bsicamente consiste en una serie de ciclos que comienzan desde el centro
que se repiten en forma de espiral, El Espiral puede verse como un modelo
evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos
controlados y sistemticos del Modelo Cascada, con el agregado de gestin de
riegos.
este modelo no es tan usado por lo que no se tiene clara la medida de
eficiencia de este modelo en un sistema de informacin, pero este modelo
podemos ver que apto para el desarollo de sistemas operativos complejos, este
modelo evolutivo tiene aspectos buenos ya que todo lo que hace este modelo
es controlar y sistematizar las actividades

Concurrente
La gran mayora de los modelos de desarrollo de software estn ligados al
tiempo, cuanto ms se dure sera mejor o peor para el modelo. Este modelo de
desarrollo de software concurrente est ligado y dirigido primordialmente por
las necesidades del usuario, las decisiones que se tomen acabo y las tareas
que realicen dichos usuarios.
Tambin define una serie de acontecimientos que se disparan a los estados de
cada
uno
de
las
actividades
realizadas.

IMAGEN: http://ekipo4.galeon.com/images/programando_3.gif

Fue creado por Davis Sitaram, se puede representar en forma de esquema de

una serie de actividades, tcnicas tareas y estados asociados a ellas como ya
lo habamos mencionado. Tiene la capacidad de describir las mltiples
actividades del software que estn ocurriendo simultneamente.

Caractersticas:
Se expresa de manera esquematizada y organizada.
Cada actividad lleva procesos concurrentes.

Se aplica a la mayora de tipos de desarrollo de software

Es un modulo aplicable para el cliente soador.

Esta dirigido bsicamente y esencialmente a las necesidades del

usuario.

Es aplicable al cliente servidor.

Grfico del modelo concurrente

IMAGEN:https://lh5.googleusercontent.com/5CYRpTGDtWq0SmgPjnUG07FxKyaso_iqzyWxKXr4wd36wEIkERyd7Ut3GjUSXtK
-FH0cgU1yvfal3_SrzOxM-p76CkT28jiEs1TfAB1vmUQz8LDXiw

Ventajas:

Es excelente para proyectos en los que se conforman grupos de

trabajo.

Proporciona una imagen exacta del estado actual de un proyecto

No restringe el proyecto a una secuencia de sucesos.
Desventajas:
Si no se dan las condiciones especficas no se puede aplicar.

Si no existe grupo de trabajo no se puede trabajar en este mtodo.

Todas las actividades de red existen simultneamente con otras.

Los sucesos generados dentro de una actividad, o en algn otro lado

de la red de
actividad, inician las transiciones entre los estados de otra
actividad.

conclusiones
El modelo de proceso concurrente se puede sentar en forma de esquema
como una serie de actividades tcnicas importantes, tareas y estados
asociados a ellas. Por ejemplo, la actividad de ingeniera definida para el
modelo en espiral, se lleva acabo invocando las tareas siguientes: modelado de
construccin de prototipos y/o anlisis, especificacin de requisitos y diseo.

Este modelo define una serie de acontecimientos que disparan transiciones de

estado a estado para cada una de las actividades del proyecto, utilizando para
ellos el paradigma de desarrollo de aplicaciones cliente/servidor.
Partes citadas de:
http://eclases.tripod.com/id12.html
http://modelosdrayevolutivos.blogspot.com/2008/10/modelo-de-desarrollo-concurrente.html

Incremental
Es un modelo basado en varios ciclos en Cascada retroalimentados aplicados
consecutivamente. Combina los elementos del MLS con la filosofa con la
filosofa interactiva de construccin de prototipos.
Fue propuesto por Mills en 1980. En una visin genrica, el proceso se divide
en 4 partes: Anlisis, Diseo, Cdigo y Prueba. Se usa el principio de trabajo
en cadena o Pipeline, utilizado en muchas otras formas de programacin.

IMAGEN: http://1.bp.blogspot.com/-ANKYNFg4M_U/T4VXjnkrCcI/AAAAAAAADqA/XCBpraJjcgI/s1600/incremental
%2Binnovation.jpg

Caractersticas:

Se evitan proyectos largos y se entrega algo de valor a los usuarios

con cierta
frecuencia.
El usuario se involucre ms.
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 muy positivo.

Grfico del modelo incremental

IMAGEN: http://ldc.usb.ve/~vtheok/cursos/ci3711/apuntes/99-01-14/Info/esquema5.gif

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.
Permite entregar al cliente un producto ms rpido en comparacin del
modelo de cascada.
Resulta ms sencillo acomodar cambios al acotar el tamao de los
incrementos.
Por su versatilidad requiere de una planeacin cuidadosa tanto a nivel
administrativo como tcnico.

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 de los proyectos.

conclusiones
El modelo incremental es una unin de las mejores funcionalidades del modelo de cascada y del
modelo de prototipos. A medida que se presenta un prototipo se produce un incremento, que
es una iteracin del proceso anterior pero aplicando las experiencias aprendidas del proceso

anterior. A diferencia del modelo de prototipos, los prototipos de este modelo estn orientados a
ser operacionales en cada incremento y no ser solo una previa de cmo sera el sistema en
su versin final.

Metodologas tradicionales.Al inicio el desarrollo de software era artesanal en su totalidad, la fuerte necesidad
de mejorar el proceso y llevar los proyectos a la meta deseada, tuvieron que
importarse la concepcin y fundamentos de metodologas existentes en otras reas
y adaptarlas al desarrollo de software. Esta nueva etapa de adaptacin contena el
desarrollo dividido en etapas de manera secuencial que de algo mejoraba la
necesidad latente en el campo del software.

Entre las principales metodologas tradicionales tenemos los ya tan conocidos RUP y
MSF entre otros, que centran su atencin en llevar una documentacin exhaustiva
de todo el proyecto y centran su atencin en cumplir con un plan de proyecto,
definido todo esto, en la fase inicial del desarrollo del proyecto.

Otra de las caractersticas importantes dentro de este enfoque tenemos los altos
costos al implementar un cambio y al no ofrecer una buena solucin para proyectos
donde el entorno es voltil.

Las metodologas tradicionales (formales) se focalizan en documentacin,

planificacin y procesos. (Plantillas, tcnicas de administracin, revisiones, etc.), a
continuacin se detalla RUP uno de los mtodos ms usados dentro de los mtodos
tradicionales
RATIONAL UNIFIED PROCESS (RUP)
PROCESO UNIFICADO RATIONAL

RUP es un proceso formal: Provee un acercamiento disciplinado para asignar tareas

y responsabilidades dentro de una organizacin de desarrollo.

Fases
Las cuatro fases del ciclo de vida son:
Concepcin
Elaboracin
Construccin
Transicin

Ventajas
Evaluacin en cada fase que permite cambios de objetivos
Funciona bien en proyectos de innovacin.
Es sencillo, ya que sigue los pasos intuitivos necesarios a la hora de desarrollar el
software.
Seguimiento detallado en cada una de las fases.

Desventajas
La evaluacin de riesgos es compleja
Excesiva flexibilidad para algunos proyectos
Estamos poniendo a nuestro cliente en una situacin que puede ser muy incmoda
para l.
Nuestro cliente deber ser capaz de describir y entender a un gran nivel de detalle
para poder acordar un alcance del proyecto con l.

MICROSOFT SOLUTION FRAMEWORK (MSF)

MSF es un compendio de las mejores prcticas en cuanto a administracin de
proyectos se refiere. Ms que una metodologa rgida de administracin de
proyectos, MSF es una serie de modelos que puede adaptarse a cualquier proyecto
de tecnologa de informacin.
Todo proyecto es separado en cinco principales fases:

Visin y Alcances.

Planificacin.

Desarrollo.

Estabilizacin.

Implantacin.
MODELO

DE

EQUIPO

DE

MSF

Microsoft Operation Framework.El modelo de proceso MOF est formado por cuadrantes, revisiones de la
administracin de las operaciones y revisiones de la administracin de los servicios.
En la figura 1 se muestra el funcionamiento del ciclo de MOF.

Ciclo de Microsoft Operations Framework

En la figura, se observa que el modelo de proceso MOF se desplaza en sentido de
las agujas del reloj y se divide en los cuatro cuadrantes integrados siguientes:
Cambios
Operaciones
Soporte tcnico
Optimizacin

3.

Metodologas Agiles.-

EXTREME PROGRAMMING (XP)

Los defensores de XP consideran que los cambios de requisitos sobre la marcha son
un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen
que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la
vida del proyecto es una aproximacin mejor y ms realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en
controlar los cambios en los requisitos.

SCRUM

4.

Diferencias:
DIFERENCIAS

ENTRE

METODOLOGA TRADICIONALES

Metodologas Tradicionales

GILES

Metodologas Agiles

Basadas en normas provenientes de

estndares seguidos por el entorno
de desarrollo

Basadas en heursticas provenientes

de prcticas de produccin de cdigo

Cierta resistencia a los cambios

Especialmente
preparados
cambios durante el proyecto

Impuestas externamente

Impuestas
equipo)

Proceso mucho ms controlado, con

numerosas polticas/normas

Proceso menos controlado, con pocos

principios.

El cliente interacta con el equipo de

desarrollo mediante reuniones

El cliente es parte del equipo de

desarrollo

Ms artefactos

Pocos artefactos

Ms roles

Pocos roles

Grupos grandes
distribuidos

La arquitectura
esencial y se

del

internamente

(por

para
el

posiblemente

Grupos pequeos (<10 integrantes) y

trabajando en el mismo sitio

software

Menos nfasis en la arquitectura del

software

es

expresa mediante modelos

Existe un contrato prefijado

5.

No existe contrato tradicional o al

menos es bastante flexible

Conclusin.-

El retrasar las decisiones en un proyecto de software permite potenciar el valor del

producto tanto para el cliente como al equipo o empresa que desarrolla
Para que un grupo de desarrollo adopte una metodologa gil debe poseer
experiencia trabajando con metodologas tradicionales, ya que la experiencia es la
que predomina en los mementos cruciales del proyecto, adems debe tener la
capacidad de ser equipos auto-gestionados, altamente motivados y con gran
innovacin
Las metodologas tradicionales son pesadas y que suponen obligatoriamente un
todo o nada.
Las metodologas giles son ms modernas y mejores que cualquiera de las
tradicionales.
Las actividades de calidad son intiles y slo funcionan en equipos grandes, no se
adaptan a nuestros proyectos. Cualquier cosa que nos quite tiempo de tareas
tcnicas (programar, etc.) es una prdida de tiempo.
El uso de metodologas tradicionales es esencial al inicio en un equipo de desarrollo
de software
Las metodologas giles se deberan aplicar en proyectos donde exista mucha
incertidumbre donde el entorno es voltil, donde los requisitos no se conocen con
exactitud, mientras que las metodologas tradicionales obligan al cliente a tomar las
decisiones al inicio del proyecto.

Publicado por Roger Humberto Uoja en 14:49

Enviar por correo electrnicoEscribe un blogCompartir con TwitterCompartir
con FacebookCompartir en Pinterest

No hay comentarios:
Publicar un comentario en la entrada
Entrada ms recienteEntrada antiguaPgina principal
Suscribirse a: Enviar comentarios (Atom)
ARCHIVO DEL BLOG

o
o

2012 (4)
mayo (2)
abril (2)
METODOLOGIAS DE DESARROLLO DE SOFTWARE
TRADICIONAL...
ANALISIS COMPARATIVO DE LAS NORMAS DE CALIDAD

PARA...
DATOS PERSONALES

Roger Humberto Uoja

Ver todo mi perfil