Los modelos evolutivos son iterativos y permiten desarrollar versiones cada vez más completas y complejas de un software hasta alcanzar el objetivo final. Existen dos tipos principales: el desarrollo exploratorio, que explora los requisitos con el usuario, y el enfoque con prototipos, que utiliza prototipos para definir requisitos no claros. Algunos modelos evolutivos conocidos son el iterativo incremental y el modelo en espiral.
Los modelos evolutivos son iterativos y permiten desarrollar versiones cada vez más completas y complejas de un software hasta alcanzar el objetivo final. Existen dos tipos principales: el desarrollo exploratorio, que explora los requisitos con el usuario, y el enfoque con prototipos, que utiliza prototipos para definir requisitos no claros. Algunos modelos evolutivos conocidos son el iterativo incremental y el modelo en espiral.
Descripción original:
modelos evolutivos y una breve descripción de ellos
Los modelos evolutivos son iterativos y permiten desarrollar versiones cada vez más completas y complejas de un software hasta alcanzar el objetivo final. Existen dos tipos principales: el desarrollo exploratorio, que explora los requisitos con el usuario, y el enfoque con prototipos, que utiliza prototipos para definir requisitos no claros. Algunos modelos evolutivos conocidos son el iterativo incremental y el modelo en espiral.
Los modelos evolutivos son iterativos y permiten desarrollar versiones cada vez más completas y complejas de un software hasta alcanzar el objetivo final. Existen dos tipos principales: el desarrollo exploratorio, que explora los requisitos con el usuario, y el enfoque con prototipos, que utiliza prototipos para definir requisitos no claros. Algunos modelos evolutivos conocidos son el iterativo incremental y el modelo en espiral.
Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
Descargar como docx, pdf o txt
Está en la página 1/ 14
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.
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.
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.
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
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.
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.
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
