Metodologa de Desarrollo de Software

Metodologa de Desarrollo de Software

Mara Gonzlez Huerta 1212100507

GSI0943

6-sep-2013

Modelo en Cascadahttp://upload.wikimedia.org/wikipedia/commons/a/a1/Modelo_de_Cascadarw.JPGElmodelo en cascada, algunas veces llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimientos del cliente y que contina con la planeacin, el modelado, la construccin y el despliegue para culminar en el soporte del software terminado.Este modelo es aplicable en donde existen ocasiones en que los requisitos de un problema se entienden de una manera razonable y deben estar bien definidos, tambin cuando el trabajo fluye desde la comunicacin a travs del despliegue de una manera casi lineal, esta situacin se encuentra a veces cuando es necesario hacer adaptaciones o mejoras bien definidas a un sistema existente.El modelo en cascada es el paradigma ms antiguo para la ingeniera del software. Sin embargo, en las dcadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus ms fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada estn:1. Es muy raro que los proyectos reales sigan el flujo secuencial que propone el modelo. A pesar de que el modelo lineal incluye iteraciones, lo hace de maneraindirecta. Como resultado, los cambios confunden mientras el equipo de proyecto acta.2. Con frecuencia es difcil para el cliente establecer todos los requisitos de manera explcita. El modelo en cascada lo requiere y se enfrentan dificultades al incorporar la incertidumbre natural presente en el inicio de muchos proyectos.3. El cliente debe tener paciencia. Una versin que funcione de los programas estar disponible cuando el proyecto est muy avanzado. Un error grave ser desastroso si no se detecta antes de la revisin del programa.En un anlisis interesante de proyectos reales, Bradac(1994) concluy que la naturaleza lineal del modelo en cascada conduce a "estados de bloqueo" en los cuales algunos miembros del equipo del proyecto deben esperar a otros para terminar tareas dependientes. De hecho, el tiempo de espera puede superar el que se aplica en el trabajo productivo. El estado de bloqueo tiende a ser ms comn al principio y al final del proceso secuencial.En la actualidad, el trabajo del software est acelerado y sujeto a una cadena infinita de cambios (de caractersticas, funciones y contenido de la informacin). Con frecuencia, el modelo en cascada no es apropiado para dicho trabajo. Sin embargo, puede servir como un modelo de proceso til en situaciones donde los requerimientos estn fijos y donde el trabajo se realiza, hasta su conclusin, de una manera lineal.Las principales etapasAnlisis y definicin de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se define una especificacin del sistema.

Diseo del sistema y del software. El proceso de diseo del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseo del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones.

Implementacin y prueba de unidades. Durante esta etapa, el diseo del software se lleva a cabo como un conjunto o unidades de programas.

Integracin y prueba del sistema. Los programas o las unidades individuales de programas se integran y prueban como un sistema completo para asegurar que se cumplan los requerimientos del software.

Funcionamiento y mantenimiento. El sistema se instala y se pone en funcionamiento prctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida.

Algunas veces llamado el ciclo de vida clsico, sugiere un enfoque sistemtico, secuencial hacia el desarrollo del software, que se inicia con la especificacin de requerimiento del cliente y que contina con la planeacin, el modelo, la construccin, y el despliegue para culminar en el soporte del software. Es un enfoque pasado de moda pero til cuando los requisitos son fijos.

Modelo de Procesos IncrementablesModelo_Incrementalyeye.jpgElmodelo incrementalcombina elementos del modelo en cascada aplicado en forma iterativa.El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce "incrementos" del software. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podra realizar funciones bsicas de administracin de archivos, edicin y produccin de documentos; en el segundo incremento, ediciones ms sofisticadas, y tendra funciones ms complejas de produccin de documentos; en el tercer incremento, funciones de correccin ortogrfica y gramatical; y en el cuarto, capacidades avanzadas de configuracin de pgina. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construccin de prototipos que se expone ms adelante.A menudo, al utilizar un modelo incremental el primer incremento es unproducto esencial. Es decir, se incorporan los requisitos bsicos, pero muchas caractersticas suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluacin detallada). Como resultado de la evaluacin se desarrolla un plan para el incremento siguiente. El plan afronta la modificacin del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de caractersticas y funcionalidades adicionales. Este proceso se repite despus de la entrega de cada incremento mientras no se haya elaborado el producto completo.El modelo de proceso incremental, al igual que la construccin de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construccin de prototipos, el modelo incremental se enfoca en la entrega de un producto operacional con cada incremento. Los primeros incrementos son versiones incompletas del producto final, pero proporcionan al usuario la funcionalidad que necesita y una plataforma para evaluarlo.El desarrollo incremental es til sobre todo cuando el personal necesario para una implementacin completa no est disponible. Los primeros incrementos se pueden implementar con menos gente. Si el producto esencial es bien recibido se agrega (si se requiere) ms personal para implementar el incremento siguiente. Adems, los incrementos se pueden planear para manejar los riesgos tcnicos. Por ejemplo, un sistema grande podra requerir la disponibilidad de un hardware nuevo que est en desarrollo y cuya fecha de entrega es incierta. Sera posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitira la entrega de funcionalidad parcial a los usuarios finales sin retrasos desordenados.

Combina elementos del modelo en cascada aplicado en forma iterativa. El modelo incremental aplica secuencias lineales de manera escalonada conforme avanza el tiempo en el calendario. Cada secuencia lineal produce incrementos. Produce entregas de software pequeas pero usables (incrementos). Cada parte se construye sobre partes ya entregadas.Modelo de desarrollo rpido de aplicaciones (DRA)http://upload.wikimedia.org/wikipedia/commons/7/7b/Modelo_dra.jpgEldesarrollo rpido de aplicaciones(DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptacin a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rpido mediante un enfoque de construccin basado en componentes. Si se entienden bien los requisitos y se limita el mbito del proyecto, el proceso DRA permite que un equipo de desarrollo cree un "sistema completamente funcional" dentro de un periodo muy corto (por ejemplo, de 60 a 90 das).Como otros modelos de proceso, el enfoque DRA cumple con las actividades genricas del marco de trabajo que ya se han presentado. La comunicacin trabaja para entender el problema de negocios y las caractersticas de informacin que debe incluir el software. La planeacin es esencial porque varios equipos de software trabajan en paralelo sobre diferentes funciones del sistema. El modelado incluye tres grandes fases modelado de negocios, modelado de datos y modelado del proceso y establece representaciones del diseo que sirven como base para la actividad de construccin del modelo DRA. La construccin resalta el empleo de componentes de software existente y la aplicacin de la generacin automtica de cdigo. Por ltimo, el despliegue establece una base para las iteraciones subsecuentes, si stas son necesarias.El modelo de proceso DRA se ilustra en la siguiente figura. Es obvio que las restricciones de tiempo impuestas sobre un proyecto DRA exigen un "mbito de escalas". Si una aplicacin de negocios se puede modular de forma que cada gran funcin pueda completarse en menos de tres meses (mediante la aplicacin del enfoque ya descrito), sta es una candidata para el DRA. Cada gran funcin se puede abordar mediante un equipo de DRA por separado, para despus integrarlas y formar un todo.Como todos los modelos de procesos, el enfoque DRA tieneinconvenientes:1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear en nmero correcto de equipos DRA.2) Si los desarrolladores y clientes no se comprometen con las actividades rpidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos DRA fallarn.3) Si un sistema no se puede modular en forma apropiada, la construccin de los componentes necesarios para el DRA ser problemtica.
4) Si el alto rendimiento es un aspecto importante, y se alcanzar al convertir interfaces en componentes del sistema, el enfoque DRA podra no funcionar.5) El DRA sera inapropiado cuando los riesgos tcnicos son altos (por ejemplo, cuando una aplicacin nueva aplica muchas nuevas tecnologas).Es un modelo de proceso del software incremental que resulta un ciclo de desarrollo corto. El modelo DRA es una adaptacin a alta velocidad del modelo en cascada en el que se logra el desarrollo rpido mediante un enfoque de construccin basado en componentes. Hace un uso intensivo de componentes reusables de software con un ciclo de desarrollo extremadamente corto.Es importante destacar que los Modelo Prescriptivos proporcionan un conjunto de pautas para el diseo, uso y reuso de los objetos de aprendizaje, como complemento al proceso de su descripcin, de una manera iterativa o incremental, desde la concepcin del objeto de aprendizaje hasta su reusabilidad a corto, mediano y largo plazo. Pero el xito en la creacin de cualquier objeto de aprendizaje depender de la adecuada aplicacin del proceso de Ingeniera de Software, cuyas etapas facilitan el desarrollo de los objetos de aprendizaje.Modelos EvolutivosSe reconoce que el software al igual que todos los sistemas complejos evoluciona con el tiempo, los requisitos de gestin y de producto a menudo cambian conforme a que el desarrollo procede haciendo que el camino que lleva al producto final no sea real. El desarrollo evolutivo consta del desarrollo de una versin inicial que luego de exponerse se va refinando de acuerdo de los comentarios o nuevos requerimientos por parte del cliente o del usuario final. Los modelos evolutivos son iterativos, se caracteriza por la forma en que permiten a los ingenieros en software desarrollar versiones cada vez mscompletas del software. A continuacin se presentan algunos de los modelos que se clasifican en esta categora.Construccin de prototipos

Modelos en espiral

Modelo de desarrollo concurrente

En los modelos evolutivos se produce un sistema inicial que evoluciona segn las necesidades del cliente hasta cumplir con los requisitos de este, para luego producir un sistema que satisfaga sus necesidades. Este enfoque enlaza las actividades de especificacin, desarrollo y validacin.Construccin de PrototiposConstruccion_de_prototipos.JPGEn Ingeniera de software laconstruccin de prototipospertenece a los modelos de desarrollo evolutivo, El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar mucho dinero pues a partir de que este sea aprobado es que el desarrollador puede iniciar el verdadero desarrollo del software.El diseo rpido se basa en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final (por ejemplo, la configuracin de la interfaz con el usuario y el formato de los despliegues de salida). El diseo rpido conduce a la construccin de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La iteracin 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.La construccin de prototipos se puede utilizar como un modelo del proceso independiente. 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.Etapas:Plan rpido.

Modelado, diseo rpido.

Construccin del Prototipo.

Desarrollo, entrega y retroalimentacin.

Comunicacin.

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.

Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios.

Reduce costos y aumenta la probabilidad de xito.

Exige disponer de las herramientas adecuadas.

Una vez identificados todos los requisitos mediante el prototipo, se construye el producto de ingeniera.

Desventajas: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.

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.

Modelo en EspiralSIMEES.jpgElmodelo en espiralrepresenta en forma de espiral una secuencia de actividades. Este modelo fue originalmente propuesto por Boehm en 1988, y se diferencia de los dems modelos por considerar el riesgo. El 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, permitiendo al desarrollador y al cliente entender y reaccionar ante los riesgosen cada nivel evolutivo.actividades estructurales

El modelo en espiral se divide en un nmero de actividades estructurales, tambin llamadas regiones de tareas, segn Sommerville (2005) el ciclo de vida del modelo en espiral se divide cuatro sectores:1.Definicin de objetivos. En esta fase se identifica las restricciones del proceso y le producto, y dependiendo los riesgos para trazar objetivos y respectivamente panes estratgicos.2.Evaluacin y reduccin de riesgos. Se hace un anlisis detallado para casa riesgo y se establece los pasos para reducirlos.3.Desarrollo y validacin. Despus de evaluar los riesgos, se elige un modelo para el desarrollo del sistema.4.Planificacin. El proyecto se revisa y se toma la decisin de si debe continuar con un ciclo posterior de la espiral.Las caractersticas que se pueden indicar del modelo en espiral son:El software se desarrolla en una serie de versiones incremntales. Durante las primeras iteraciones.

La versin incremental podra ser un modelo en papel o un prototipo.

A medida que se va incrementando el nmero de iteraciones, se producen versiones cada vez mas completas.

Ventajas:Puede adaptarse y aplicarse a lo largo de la vida del software.

Como el software evoluciona, a medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de los niveles evolutivos.

Permite a quien lo desarrolla aplicar el enfoque de construccin de prototipos en cualquier etapa de evolucin del producto.

Demanda una consideracin directa de los riesgos tcnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan enproblemticos.

Desventajas:Puede resultar difcil convencer la grandes clientes de que el enfoque evolutivo es controlable (particularmente en situaciones de contrato).

Si un riesgo importante no es descubierto y gestionado, indudablemente surgirn problemas.

Como es un modelo relativamente nuevo no es muy utilizado.

Otros inconvenientes que pueden surgir es convencer al cliente que es un enfoque controlable,por lo que se requiere de experiencia en la identificacin de riesgos y refinamiento para su uso generalizado.

Lo caracterstico del modelo es espiral es que incluye un anlisis de riesgo es decir que podemos analizar si el proyecto puede continuar o mejor lo suspendemos. Este modelo se basa en que antes de hacer algo debemos analizarlo, tambin debemos buscar varias opciones de resolucin de problemas para de all escoger la opcin ms conveniente, y adems analizar los riesgos que se pueda tener. Este modelo necesita de otro mtodos para poder desarrollarse.Modelos de Desarrollo gilesLas metodologas gilesson un conjunto de mtodos de ingeniera del software, que se basan en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la colaboracin de un grupo de desarrolladores auto-organizados y multidisciplinares.En las metodologas giles, los procesos se desarrollan de manera solapada, donde el ciclo de vida del proyecto, es cclico. La diferencia en el ciclo de vida de un proyecto gil, en comparacin con uno tradicional, se debe a la forma en la queel agilismo, solapa los procesos de manera iterativa.Ciclo_de_vida_proyecto_metodologia_agiles.jpgLa tendencia del control de procesos para desarrollo de software ha trado como resultado que proyectos no resulten exitosos debido al cambiante contexto que existe, por lo cul las metodologas giles pretende resolver este inconveniente, construyendo soluciones a la medida asegurando la calidad. Los mtodos giles fueron pensados especialmente para equipos de desarrollo pequeos, con plazos reducidos, requisitos voltiles y nuevas tecnologas. La filosofa de las metodologas giles, pretenden dar mayor valor al individuo, a la colaboracin con el cliente y al desarrollo incremental del software con iteraciones muy cortas. Este enfoque est mostrando su efectividad en proyectos con requisitos muy cambiantes y cuando se exige reducir drsticamente los tiempos de desarrollo pero manteniendo una alta calidad.La direccin del enfoque de establecer una metodologa que solventara los cambios drsticos del ambiente, di origen en febrero de 2001, tras una reunin celebrada en Utah-EEUU, en esta reunin participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales (metodologas pesadas), caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las actividades desarrolladas.Programacin Extrema (XP)Programacion_extrema.JPEGLa programacin extrema (XP, extreme Programming) es un modelo de proceso de software el fue acuado por Beck el cual toma los principios y practicas aceptadas y las lleva a niveles extremos. Tiene como objetivo reducir el riesgo en el ciclo de vida del software mediante grupos de desarrollo pequeos, considera que la mejor manera de tratar la falta de requisitos estables en un sistemas, es mediante la agilidad de un grupo pequeo de desarrollo . Esta se basa en la simplicidad, la comunicacin y el reciclado continuo de cdigo. El modelo considera varios aspectos problemticos del desarrollo de software como lo son los retrasos , proyectos cancelados, cambios en el negocio y la rotacin del personal. Susactividades bsicasson: Codificar, hacer pruebas, escuchar y disear.Losobjetivosde XP son muy simples:1. La satisfaccin del cliente: trata de dar al cliente el software que l necesita y cuando lo necesita.2. Potenciar al mximo el trabajo en grupo: Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y estn involucrados en el desarrollo del software.XP define cuatro variables para proyectos de software: coste, tiempo, calidad y mbito. Adems de estas cuatro variables, Beck propone que slo tres puedan ser establecidas por las fuerzas externas (jefes de proyecto y clientes), mientras que el valor de la cuarta variable debe ser establecido por los programadores en funcin de las otras tres. Losvaloresoriginales de la programacin extrema son:Simplicidad: XP propone el principio de hacer la cosa ms simple que pueda funcionar, en relacin al proceso y la codificacin. Esta es la base de la programacin extrema.

Comunicacin: Los programadores se comunican constantemente gracias a la programacin por parejas y adems la comunicacin con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo

Retroalimentacin: retroalimentacin concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo.

Coraje o valenta: La valenta le permite a los desarrolladores que se sientan cmodos con reconstruir su cdigo cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fcilmente.

Principios bsicos en la Programacin extrema:Planificacin Incremental: los requerimientos se registran en tarjetas de historias, estas incluyen el tiempo y la prioridad relativa.

Entregas pequeas: estas entregas son frecuentes e incrementalmente aaden funcionalidad al primera entrega

Diseo sencillo: solo se lleva a cabo el diseo necesario para cumplir los requerimientos actuales

Desarrollo previamente probado; se utiliza un sistema de pruebas, para escribir pruebas de las nuevas funcionalidades antes de que estas se implementen.

Refactorizacin: conserva el cdigo sencillo y mantenible.

Programacin en parejas: esta es la mas importante de todos los principios, los desarrolladores trabajan en parejas, verificando cada uno el trabajo del otro, proporcionando la ayuda para hacer siempre un buen trabajo

Propiedad colectiva: las parejas trabajan en todas las reas del sistema.

Integracin continua: cuanto acaba el trabajo en una tarea, se integra en el sistema entero.

Ritmo sostenible: No se consideran aceptables grandes cantidades de horas extras, ya que a menudo, reduce la calidad del codigo y la productividad a medio plazo.

Cliente presente: Debe estar disponible al equipo de XP, un represente de los usuarios finales del sistema a tiempo completo. En un proceso XP el cliente es parte del equipo de desarrollo

La programacin extrema es uno de los mtodo giles ms conocido y ampliamente utilizados, donde el usuario o cliente forma parte del equipo de trabajo, engloba en una serie de principios dentro de los ms importantes seencuentra la programacin en parejas y el desarrollo de pruebas, as como tambin reulitizacin de los cdigos. Para el uso de XP los requerimientos deben de estar bien definidos, mediante las historias de usuario. Este modelo se basa en la retroalimentacin continua entre el cliente y el equipo de desarrollo, especialmente muy utilizada para proyectos con requisitos imprecisos y muy cambiantes, centrada en potenciar las relaciones interpersonales como clave para el xito en el desarrollo de software, promoviendo el trabajo en equipo y preocupndose por el aprendizaje de los desarrolladores y la satisfaccin del clienteDesarrollo Adaptativo del Software (DAS)DAS.JPEGEldesarrollo adaptativo de software (DAS)1998 fue propuestos por Jim Highsmith como una metodologa para desarrollar el software y sistemas muy complejos. Este se centra en la colaboracin humana y la organizacin del equipo2. El Desarrollo adaptativo del software proporciona un marco para el desarrollo iterativo de sistemas grandes y complejos, el mismo fomenta el desarrollo iterativo e incremental con el uso de prototipos.fasesEl ciclo de vida del DAS se conforma de tres fases: Especulacin, colaboracin y aprendizaje-Fase de especulacin:Es la primera de las fases esta inicia en el desarrollo del proyecto. Se utiliza informacin como la visin del cliente, las restricciones del proyecto y los requisitos bsicos para definir el conjunto de ciclos en el que se harn los incrementos del software. En esta fase es donde se lleva a cabo la planificacin tentativa del proyecto en funcin de las entregas que se iran realizando-Fase de colaboracin:Se busca que el equipo colabore inmensamente para lograr la funcionalidad planeada, se comunique o se encuentre completamente integrados, se desea que exista confianza, donde se puedan realizar crticas constructivas y ayudar si resentimientos, as como tambin comunicar de una forma oportuna los problemas que se presenten para tomar acciones efectivas y poseer un conjunto de actitudes que contribuyan al trabajo que se encuentran realizando.-Fase del aprendizaje:consiste en la revisin de calidad que se realiza al final de cada ciclo, esto permite mejorar el entendimiento real sobre la tecnologa,los procesos utilizados y el proyecto. El aprendizaje individual permite al equipo tener mayor posibilidad de xito.

Esta metodologa no proporciona el tipo de prcticas detalladas como lo hace XP, pero proporciona la base fundamental de por qu el desarrollo adaptable es importante y las consecuencias a los ms profundos niveles de la organizacin y la gerencia. Los apoyos filosficos del DAS se enfocan en la colaboracin humana y la organizacin propia del equipo, y es un modelo para la construccin de software y sistemas complejos, incluye tres fases que son: especulacin, colaboracin y aprendizaje, cada una de estas fases son fundamental para el desarrollo de la otra. Es adaptativo, se hace uso de la reutilizacin del cdigo para adaptarlo a lo que se deseaModelo de Desarrollo de Sistemas Dinmicos (MDSD)MDSD.jpgEs un metodo de desarrollo agil de software que apoyado por su continua implicacion del usuario en un desarrollo iterativo y creciente que sea sensible a los requerimientos cambiantes, para desarrollar un sistema que reuna las necesiadades de la empresa en tiempo y presuspuesto. Este se caracteriza por proporcionar un marco de trabajo el cual permita construir y mantener sistemas con restricciones de tiempo muy estrechas mediante el empleo de la construccin de prototipos incremntales en un ambiente de proyecto controlado ActividadesEl MDSD comienza con un estudio de viabilidad y de negocio, son las primeras actividades que deben realizarseEstudio viabilidad:Se evala si la aplicacin es viable, para el proceso teniendo en cuenta los requisitos bsicos del negocio y sus restricciones asociadas.

Estudio de negocios: establece los requisitos funcionales y de informacin que permitirn que la aplicacin proporcione un valor al negocio; tambin define la arquitectura bsica de la aplicacin.

El resto del proceso formatres ciclos iterativosque son:Iteracin de modelo funcional:produce una serie de prototiposincremntales que demuestran la funcionalidad para el cliente. Su propsito durante este ciclo es recopilar requisitos adicionales y producir documentacin de anlisis.

Iteracin de construccin y diseo:revisa la construccin de prototipos durante la iteracin del modelo funcional, en este se disea el sistema para el uso operacional. En algunos casos, la iteracin del modelo funcional y esta, suceden en forma concurrente.

Implementacin:coloca el incremento de software ms reciente en el ambiente operativo, se ocupa del despliegue al uso operacional. Puede destacarse que 1) el incremento puede no estar 100 por ciento completo o 2) se pueden requerir cambios cuando el incremento se coloca en el sitio.

El modelo de desarrollo de sistemas dinmicos tiene como objetivo fundamental la entrega de sistemas software en tiempo y presupuesto , ajustndose a los cambios de requisitos que puedan surgir durante el proceso de desarrollo. Para su implementacin se hacen dos estudios principalmente el de negocio y el de viabilidad, para posteriormente dar inicio a sus 3 ciclos de vida . Al igual que XP el desarrollo es iterativo e incremental as como tambin basado por la retroalimentacin del usuario, de esa manera logrando converger la solucin del negocio mas efectiva. Ademas de lo mencionado anteriormente el MDSD incluyen enttregas frecuentes, equipos autorizados, y pruebas a lo largo de todo su cicloModelo ScrumScrum.pngScrumes una metodologa gil de gestin de proyectos cuyo objetivo primordial es elevar al mximo la productividad de un equipo, fue desarrollado por Jeff Sutherland y elaborado ms formalmente por Ken Schwaber.11. Se enfoca en el hecho de que procesos definidos y repetibles slo funcionan para atacar problemas definidos y repetibles con gente definida y repetible en ambientes definidos y repetibles. Y se divide un proyecto en iteraciones (que ellos llaman carreras cortas) de 30 das. La literatura de Scrum se orienta principalmente en la planeacin iterativa y el seguimiento del proceso12Caracteristicas:Enfatiza valores y prcticas de gestin, sin pronunciarse sobrerequerimientos, prcticas de desarrollo, implementacin y dems cuestiones tcnicas.

Hace uso de Equipos auto-dirigidos y auto-organizados

Puede ser aplicado tericamente a cualquier contexto en donde un grupo de gente necesita trabajar junta para lograr una meta comn.

Desarrollo de software iterativos incrementales basados en prcticas agiles

Iteraciones de treinta das; aunque se pueden realizar con mas frecuencia, estas iteraciones, conocidas como Sprint

Dentro de cada Sprint se denomina el Scrum Master al Lder de Proyecto quien llevar a cabo la gestin de la iteracin

Se convocan diariamente un Scrum Daily Meeting el cual representa una reunin de avance diaria de no ms de 15 minutos con el propsito de tener realimentacin sobre las tareas de los recursos y los obstculos que se presentan. En la cual se responden preguntas como: Qu has hecho desde el ultimo encunetro? Qu obstaculos hay para cumplir la meta? Qu haras antes del proximo encuentro?

Conclusin

MODELOENFOQUEVENTAJAS/DESVENTAJASAPLICABILIDAD

MODELO CASCADAEl inicio de cada etapa debe esperar a la finalizacin de la inmediatamente anterior Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo.Los proyectos raras veces siguen una evolucin secuencial. No todos los requisitos son expuestos, al principio, de forma explcita como requiere este modelo. El cliente debe tener paciencia, ya que la aplicacin slo estar disponible en un estado muy avanzado del proyecto.

Ampliamente criticado desde el mbito acadmico y la industriaUtilizado cuando existen especificaciones amplias de los requerimientos del cliente.

MODELO BASADO EN PROTOTIPOSNo posee la funcionalidad total del sistema pero si condensa la idea principal del mismo, Paso a Paso crece su funcionalidad, alto grado de participacin del usuario.El cliente puede pensar que el prototipo es una versin acabada.Pueden llegar a pasarse por alto la calidad del software global o el mantenimiento a largo plazo.Las herramientas elegidas pueden ser inadecuadas. La clave del xito de este modelo consiste en definir bien, desde el principio, las reglas del juego. Alto grado de participacin del usuarioSe utiliza si en el mercado no se encuentra el producto pero el cliente desea resultados inmediatos.Conveniente en caso de ser necesario desarrollar mdulos.Para sistemas interactivos pequeos o de tamao pequeo.Para partes de sistemas grandes.Para sistemas con vida corta.

MODELO INCREMENTAL O EVOLUTIVOModelo Lineal-Secuencial con el Modelo Basado en Prototipos .El sistema no se entrega de una vez, sino que se divide y se entregan incrementos. Con cada incremento se entrega la parte de la funcionalidad que se ha establecido. Los requisitos son priorizados.Los requisitos con una ms alta prioridad se incluyen en los incrementos ms tempranos. Los requisitos de un incremento son inamovibles. Sin embargo estos puede verse modificados enincrementos posteriores.Este proceso se repite hasta la obtencin de un producto completo.Sin embargo el modelo incremental se centra en la entrega de un producto operativo en cada incremento.Los clientes no tienen que esperar hasta tener el sistema completo.

El primer incremento satisface los requisitos ms crticos.

Los primeros incrementos sirven como prototipo y ayudan en la tarea de detectar los posteriores requisitos.

Existe un riesgo bajo de fallar en el proyecto total.

Los servicios del sistema con la prioridad ms alta tienden a ser los ms probados.

Puede ser difcil ajustar los requisitos a los incrementos

Reemplazar el antiguo desarrollo con uno nuevo que satisfaga las nuevas necesidades segn las redefiniciones del problema Manejo de Versiones.

MODELO ESPIRALEs una mejora del Modelo Basado en prototipos Cada vuelta en la espiral representa una fase del proceso. No hay fases fijas, cada vuelta en la espiral determina las actividades a realizar. La dimensin radial representa el coste acumulado en la financiacin de las fases.La dimensin angular representa el progreso hecho en completar cada ciclo de la espiral. Un ciclo a travs de la espiral es simular un paso a travs de un modelo en cascadaRequiere comunicacin permanente con el cliente por lo tanto si se cambia el contacto con el cual se realiza desarrollo es necesario que est al tanto de lo realizado y lo pendiente, cliente debe ser gran conocedor del sistema.Utilizado para el desarrollo de aplicaciones complejas y/o especficas. (Ej. Investigacin Gentica)

MODELO BASADO EN COMPONENTES (ORIENTADO A OBJETOS)Es programacin orientada a Objetos. Se utilizan objetos, clases y se reutilizan en diferentes partes del sistema.Optimiza los tiempos de respuesta a los requerimientos del cliente y facilita la labor del programador pues hay un alto aprovechamiento del cdigo.Facilita mantenimiento del softwareSistemas robustos y de alta proyeccin.

CODE AND FIXNo requiere planeacin y se trata de codificar y corregir. Se trabaja mediante prueba y error. Especial para desarrollos rpidos y sencillos.Desarrollo Rpido.No garantiza calidad.Desarrollo muy pequeo con claridad de objetivos, requerimientos pequeos o de mantenimientos con bajo impacto.

CASCADA CON SUBPROYECTOSRequiere planeacin.Plantea Organizacin y planeacin de un gran proyecto Se pueden realizar varias partes del proyecto al mismo tiempo por diferentes desarrolladores.Adecuada para el desarrollo de proyectos complejos que estiman de 1 a 3 aos de desarrollo.

. ENTREGA POR ETAPASCascada con entregas grandes en diferentes etapas del desarrollo. Cascada con Evolutivo.Debe entregarse una etapa para continuar con la siguiente.Desarrollos robustos. Desarrollo depende del presupuesto directamente Ej. Ppto adjudicado anual/..

No existe una metodologa universal para hacer frente con xito a cualquier proyecto de desarrollo de software. Toda metodologa debe ser adaptada al contexto del proyecto (recursos tcnicos y humanos, tiempo de desarrollo, tipo de sistema, etc. Histricamente, las metodologas tradicionales han intentado abordar la mayor cantidad de situaciones de contexto del proyecto, exigiendo un esfuerzo considerable para ser adaptadas, sobre todo en proyectos pequeos y con requisitos muy cambiantes. Las metodologas giles ofrecen una solucin casi a medida para una gran cantidad de proyectos que tienen estas caractersticas. Una de las cualidades ms destacables en una metodologaes su sencillez, tanto en su aprendizaje como en su aplicacin, reducindose as los costos de implantacin en un equipo de desarrollo. Esto ha llevado hacia un inters creciente en las metodologas. Sin embargo, hay que tener presente una serie de inconvenientes y restricciones para su aplicacin, tales como: estn dirigidas a equipos pequeos o medianosentre otras cosas ms(Beck sugiere que el tamao de los equipos se limite de 3 a 20 como mximo, otros dicen no ms de 10 participantes), el entorno fsico debe ser un ambiente que permita la comunicacin y colaboracin entre todos los miembros del equipo durante todo el tiempo, cualquier resistencia del cliente o del equipo de desarrollo hacia las prcticas y principios puede llevar al proceso al fracaso (el clima de trabajo, la colaboracin y la relacin contractual son claves), el uso de tecnologas que no tengan un ciclo rpido de realimentacin o que no soporten fcilmente el cambio, etc.Falta an un cuerpo de conocimiento consensuado respecto de los aspectos tericos y prcticos de la utilizacin de metodologas,as como una mayor consolidacin de los resultados de aplicacin. La actividad de investigacin est orientada hacia lneas tales como: mtricas y evaluacin del proceso, herramientas especficas para apoyar prcticas giles, aspectos humanos y de trabajo en equipo.Aunque en la actualidad ya existen libros asociados a cada una de las metodologas giles existentes y tambin abundante informacin en Internet, es XP la metodologa que resalta por contar con la mayor cantidad de informacin disponible y es con diferencia la ms popular.

El desarrollo del software y laprogramacines uno de los pilares fundamentales de la informtica y al cual se dedican muchas horas de esfuerzos en empresas, colegios, academias y universidades.Conforme a la tecnologa va avanzando, van apareciendo nuevassoluciones, nuevas formas de programacin, nuevos lenguajes y un sin fin de herramientas que intentan realizarel trabajodel desarrollador un poco ms fcil.La programacin orientadas a objetos o loscompiladoresbasados en mquinas virtuales (en muchos casos, multiplataforma), tambin a sus puestos unas renovacin en la manera de programar.Microsoft como empresa desarrolladora de software, es consciente de lo importante que es hacer buenos desarrollos y lo complicado que es; por eso, intenta aportar las mejores soluciones almercado. En la actualidad la sociedad se encuentra en una poca de transicin, que se encamina hacia un nuevo estilo de programacin basada en estndares y para ello Microsoft propone la plataforma .NET.

BIBLIOGRAFIA

http://www.slideshare.net/guesta1695670/metodologias-de-desarrollo-de-software