Modelo en cascada

9,126 views

Published on

1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total views
9,126
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
151
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Modelo en cascada

  1. 1. Modelo en Cascada El modelo en cascada, algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimientos del cliente y que continúa con la planeación, el modelado, la construcción 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, también cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal, esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente. El modelo en cascada es el paradigma más antiguo para la ingeniería del software. Sin embargo, en las décadas pasadas, las criticas a este modelo de proceso han ocasionado que aun sus más fervientes practicantes hayan cuestionado su eficacia. Entre los problemas que algunas veces se encuentran al aplicar el modelo en cascada están: 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 manera indirecta. Como resultado, los cambios confunden mientras el equipo de proyecto actúa. 2. Con frecuencia es difícil para el cliente establecer todos los requisitos de manera explícita. 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 versión 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 revisión del programa.
  2. 2. En un análisis 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 más común 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 características, funciones y contenido de la información). 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 están fijos y donde el trabajo se realiza, hasta su conclusión, de una manera lineal. Las principales etapas de este modelo según Sommerville (2005) son: • Análisis y definición de requerimientos. Los servicios, restricciones y metas del sistema se definen a partir de las consultas con los usuarios. Se define una especificación del sistema. • Diseño del sistema y del software. El proceso de diseño del sistema divide los requerimientos en sistemas hardware o software. Establece una arquitectura completa del sistema. El diseño del software identifica y describe las abstracciones fundamentales del sistema software y sus relaciones. • Implementación y prueba de unidades. Durante esta etapa, el diseño del software se lleva a cabo como un conjunto o unidades de programas. • Integración 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 práctico. El mantenimiento implica corregir errores no descubiertos en las etapas anteriores del ciclo de vida.
  3. 3. Algunas veces llamado el ciclo de vida clásico, sugiere un enfoque sistemático, secuencial hacia el desarrollo del software, que se inicia con la especificación de requerimiento del cliente y que continúa con la planeación, el modelo, la construcción, 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 Incrementables El modelo incremental 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" del software. Por ejemplo, el software procesador de texto, desarrollado con el paradigma incremental en su primer incremento, podría realizar funciones básicas de administración de archivos, edición y producción de documentos; en el segundo incremento, ediciones más sofisticadas, y tendría funciones más complejas de producción de documentos; en el tercer incremento, funciones de corrección ortográfica y gramatical; y en el cuarto, capacidades avanzadas de configuración de página. Se debe tener en cuenta que el flujo del proceso de cualquier incremento puede incorporar el paradigma de construcción de prototipos que se expone más adelante. A menudo, al utilizar un modelo incremental el primer incremento es un producto esencial. Es decir, se incorporan los requisitos básicos, pero muchas características suplementarias (algunas conocidas, otras no) no se incorporan. El producto esencial queda en manos del cliente (o se somete a una evaluación detallada). Como resultado de la evaluación se desarrolla un plan para el incremento siguiente. El plan afronta la modificación del producto esencial con el fin de satisfacer de mejor manera las necesidades del cliente y la entrega de características y funcionalidades adicionales. Este proceso se repite después de la entrega de cada incremento mientras no se haya elaborado el producto completo.
  4. 4. El modelo de proceso incremental, al igual que la construcción de prototipos y otros enfoques evolutivos, es iterativo por naturaleza. Pero a diferencia de la construcción 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 implementación 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) más personal para implementar el incremento siguiente. Además, los incrementos se pueden planear para manejar los riesgos técnicos. Por ejemplo, un sistema grande podría requerir la disponibilidad de un hardware nuevo que está en desarrollo y cuya fecha de entrega es incierta. Sería posible planear los primeros incrementos de forma que se evite el uso de este hardware, lo que permitiría 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 pequeñas pero usables (incrementos). Cada parte se construye sobre partes ya entregadas. Modelo de desarrollo rápido de aplicaciones (DRA) El desarrollo rápido de aplicaciones (DRA) es un modelo de proceso de software incremental que resalta un ciclo de desarrollo corto. El modelo DRA es una adaptación a "alta velocidad" del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción 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 días).
  5. 5. Como otros modelos de proceso, el enfoque DRA cumple con las actividades genéricas del marco de trabajo que ya se han presentado. La comunicación trabaja para entender el problema de negocios y las características de información que debe incluir el software. La planeación 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 diseño que sirven como base para la actividad de construcción del modelo DRA. La construcción resalta el empleo de componentes de software existente y la aplicación de la generación automática de código. 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 aplicación de negocios se puede modular de forma que cada gran función pueda completarse en menos de tres meses (mediante la aplicación del enfoque ya descrito), ésta es una candidata para el DRA. Cada gran función se puede abordar mediante un equipo de DRA por separado, para después integrarlas y formar un todo. Como todos los modelos de procesos, el enfoque DRA tiene inconvenientes: 1) Para proyectos grandes, pero escalables, el DRA necesita suficientes recursos humanos para crear en número correcto de equipos DRA. 2) Si los desarrolladores y clientes no se comprometen con las actividades rápidas necesarias para completar el sistema en un marco de tiempo muy breve, los proyectos DRA fallarán. 3) Si un sistema no se puede modular en forma apropiada, la construcción de los componentes necesarios para el DRA será problemática. 4) Si el alto rendimiento es un aspecto importante, y se alcanzará al convertir interfaces en componentes del sistema, el enfoque DRA podría no funcionar. 5) El DRA sería inapropiado cuando los riesgos técnicos son altos (por ejemplo, cuando una aplicación nueva aplica muchas nuevas tecnologías).
  6. 6. Es un modelo de proceso del software incremental que resulta un ciclo de desarrollo corto. El modelo DRA es una adaptación a alta velocidad del modelo en cascada en el que se logra el desarrollo rápido mediante un enfoque de construcción 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 diseño, uso y reuso de los objetos de aprendizaje, como complemento al proceso de su descripción, de una manera iterativa o incremental, desde la concepción del objeto de aprendizaje hasta su reusabilidad a corto, mediano y largo plazo. Pero el éxito en la creación de cualquier objeto de aprendizaje dependerá de la adecuada aplicación del proceso de Ingeniería de Software, cuyas etapas facilitan el desarrollo de los objetos de aprendizaje. Modelos Evolutivos Se reconoce que el software al igual que todos los sistemas complejos evoluciona con el tiempo, los requisitos de gestión 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 versión 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 más completas del software. A continuación se presentan algunos de los modelos que se clasifican en esta categoría. • Construcción de prototipos • Modelos en espiral • Modelo de desarrollo concurrente En los modelos evolutivos se produce un sistema inicial que evoluciona según 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 especificación, desarrollo y validación. Construcción de Prototipos
  7. 7. En Ingeniería de software la construcción de prototipos pertenece 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 diseño rápido se basa en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final (por ejemplo, la configuración de la interfaz con el usuario y el formato de los despliegues de salida). El diseño rápido conduce a la construcción de un prototipo, el cual es evaluado por el cliente o el usuario para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La iteración 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 construcción de prototipos se puede utilizar como un modelo del proceso independiente. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. Etapas: • Plan rápido. • Modelado, diseño rápido. • Construcción del Prototipo. • Desarrollo, entrega y retroalimentación. • Comunicación. Ventajas:
  8. 8. • 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. • También 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 debería tomar la interacción humano-máquina. • 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 ingeniería. Desventajas: • El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, 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 función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. • El desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón 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 Espiral
  9. 9. El modelo en espiral representa en forma de espiral una secuencia de actividades. Este modelo fue originalmente propuesto por Boehm en 1988, y se diferencia de los demás modelos por considerar el riesgo. El modelo en espiral para la ingeniería de software es actualmente el enfoque más 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 riesgos en cada nivel evolutivo. El modelo en espiral se divide en un número de actividades estructurales, también llamadas regiones de tareas, según Sommerville (2005) el ciclo de vida del modelo en espiral se divide cuatro sectores: 1. Definición de objetivos. En esta fase se identifica las restricciones del proceso y le producto, y dependiendo los riesgos para trazar objetivos y respectivamente panes estratégicos. 2. Evaluación y reducción de riesgos. Se hace un análisis detallado para casa riesgo y se establece los pasos para reducirlos. 3. Desarrollo y validación. Después de evaluar los riesgos, se elige un modelo para el desarrollo del sistema. 4. Planificación. El proyecto se revisa y se toma la decisión de si debe continuar con un ciclo posterior de la espiral. Las características que se pueden indicar del modelo en espiral son: • El software se desarrolla en una serie de versiones increméntales. Durante las primeras iteraciones. • La versión incremental podría ser un modelo en papel o un prototipo. • A medida que se va incrementando el número de iteraciones, se producen versiones cada vez mas completas. Ventajas: • Puede adaptarse y aplicarse a lo largo de la vida del software.
  10. 10. • 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 construcción de prototipos en cualquier etapa de evolución del producto. • Demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto. Reduce los riesgos antes de que se conviertan en problemáticos. Desventajas: • Puede resultar difícil 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 surgirán 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 identificación de riesgos y refinamiento para su uso generalizado. Lo característico del modelo es espiral es que incluye un “análisis 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, también debemos buscar varias opciones de resolución de problemas para de allí escoger la opción más conveniente, y además analizar los riesgos que se pueda tener. Este modelo necesita de otro métodos para poder desarrollarse. Modelos de Desarrollo Ágiles
  11. 11. Las metodologías ágiles son un conjunto de métodos de ingeniería del software, que se basan en el desarrollo iterativo e incremental, teniendo presente los cambios y respondiendo a estos mediante la colaboración de un grupo de desarrolladores auto-organizados y multidisciplinares. En las metodologías ágiles, los procesos se desarrollan de manera solapada, donde el ciclo de vida del proyecto, es cíclico. La diferencia en el ciclo de vida de un proyecto ágil, en comparación con uno tradicional, se debe a la forma en la que el agilismo, solapa los procesos de manera iterativa. La tendencia del control de procesos para desarrollo de software ha traído como resultado que proyectos no resulten exitosos debido al cambiante contexto que existe, por lo cuál las metodologías ágiles pretende resolver este inconveniente, construyendo soluciones a la medida asegurando la calidad. Los métodos ágiles fueron pensados especialmente para equipos de desarrollo pequeños, con plazos reducidos, requisitos volátiles y nuevas tecnologías. La filosofía de las metodologías ágiles, pretenden dar mayor valor al individuo, a la colaboración 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 drásticamente los tiempos de desarrollo pero manteniendo una alta calidad. La dirección del enfoque de establecer una metodología que solventara los cambios drásticos del ambiente, dió origen en febrero de 2001, tras una reunión celebrada en Utah-EEUU, en esta reunión participan un grupo de 17 expertos de la industria del software, incluyendo algunos de los creadores o impulsores de metodologías de software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Se pretendía ofrecer una alternativa a los procesos de desarrollo de software tradicionales (metodologías pesadas), caracterizados por ser rígidos y dirigidos por la documentación que se genera en cada una de las actividades desarrolladas. Programación Extrema (XP)
  12. 12. La programación extrema (XP, extreme Programming) es un modelo de proceso de software el fue acuñado 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 pequeños, considera que la mejor manera de tratar la falta de requisitos estables en un sistemas, es mediante la agilidad de un grupo pequeño de desarrollo . Esta se basa en la simplicidad, la comunicación y el reciclado continuo de código. El modelo considera varios aspectos problemáticos del desarrollo de software como lo son los retrasos , proyectos cancelados, cambios en el negocio y la rotación del personal. Sus actividades básicas son : Codificar, hacer pruebas, escuchar y diseñar. Los objetivos de XP son muy simples: 1. La satisfacción del cliente: trata de dar al cliente el software que él necesita y cuando lo necesita. 2. Potenciar al máximo el trabajo en grupo: Tanto los jefes de proyecto, los clientes y desarrolladores, son parte del equipo y están involucrados en el desarrollo del software. XP define cuatro variables para proyectos de software: coste, tiempo, calidad y ámbito. Además de estas cuatro variables, Beck propone que sólo 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 función de las otras tres. Los valores originales de la programación extrema son: • Simplicidad: XP propone el principio de hacer la cosa más simple que pueda funcionar, en relación al proceso y la codificación. Esta es la base de la programación extrema. • Comunicación: Los programadores se comunican constantemente gracias a la programación por parejas y además la comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo • Retroalimentación: retroalimentación concreta y frecuente del cliente, del equipo y de los usuarios finales da una mayor oportunidad de dirigir el esfuerzo.
  13. 13. • Coraje o valentía : La valentía le permite a los desarrolladores que se sientan cómodos con reconstruir su código cuando sea necesario. Esto significa revisar el sistema existente y modificarlo si con ello los cambios futuros se implementaran mas fácilmente. Principios básicos en la Programación extrema: • Planificación Incremental: los requerimientos se registran en tarjetas de historias, estas incluyen el tiempo y la prioridad relativa. • Entregas pequeñas: estas entregas son frecuentes e incrementalmente añaden funcionalidad al primera entrega • Diseño sencillo: solo se lleva a cabo el diseño 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. • Refactorización: conserva el código sencillo y mantenible. • Programación 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. • Integración 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
  14. 14. La programación extrema es uno de los método ágiles más conocido y ampliamente utilizados, donde el usuario o cliente forma parte del equipo de trabajo, engloba en una serie de principios dentro de los más importantes se encuentra la programación en parejas y el desarrollo de pruebas, así como también reulitización de los códigos. Para el uso de XP los requerimientos deben de estar bien definidos, mediante las historias de usuario. Este modelo se basa en la retroalimentación 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 preocupándose por el aprendizaje de los desarrolladores y la satisfacción del cliente Desarrollo Adaptativo del Software (DAS) El desarrollo adaptativo de software (DAS) 1998 fue propuestos por Jim Highsmith como una metodología para desarrollar el software y sistemas muy complejos. Este se centra en la colaboración humana y la organización del equipo 2. 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. El ciclo de vida del DAS se conforma de tres fases: Especulación, colaboración y aprendizaje - Fase de especulación: Es la primera de las fases esta inicia en el desarrollo del proyecto. Se utiliza información como la visión del cliente, las restricciones del proyecto y los requisitos básicos para definir el conjunto de ciclos en el que se harán los incrementos del software. En esta fase es donde se lleva a cabo la planificación tentativa del proyecto en función de las entregas que se iran realizando
  15. 15. - Fase de colaboración: 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 críticas constructivas y ayudar si resentimientos, así como también 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 revisión de calidad que se realiza al final de cada ciclo, esto permite mejorar el entendimiento real sobre la tecnología, los procesos utilizados y el proyecto. El aprendizaje individual permite al equipo tener mayor posibilidad de éxito. Esta metodología no proporciona el tipo de prácticas detalladas como lo hace XP, pero proporciona la base fundamental de por qué el desarrollo adaptable es importante y las consecuencias a los más profundos niveles de la organización y la gerencia. Los apoyos filosóficos del DAS se enfocan en la colaboración humana y la organización propia del equipo, y es un modelo para la construcción de software y sistemas complejos, incluye tres fases que son: especulación, colaboración y aprendizaje, cada una de estas fases son fundamental para el desarrollo de la otra. Es adaptativo, se hace uso de la reutilización del código para adaptarlo a lo que se desea Modelo de Desarrollo de Sistemas Dinámicos (MDSD) Es 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 construcción de prototipos increméntales en un ambiente de proyecto controlado El MDSD comienza con un estudio de viabilidad y de negocio, son las primeras actividades que deben realizarse
  16. 16. • Estudio viabilidad: Se evalúa si la aplicación es viable, para el proceso teniendo en cuenta los requisitos básicos del negocio y sus restricciones asociadas. • Estudio de negocios: establece los requisitos funcionales y de información que permitirán que la aplicación proporcione un valor al negocio; también define la arquitectura básica de la aplicación. El resto del proceso forma tres ciclos iterativos que son: • Iteración de modelo funcional: produce una serie de prototipos increméntales que demuestran la funcionalidad para el cliente. Su propósito durante este ciclo es recopilar requisitos adicionales y producir documentación de análisis. • Iteración de construcción y diseño: revisa la construcción de prototipos durante la iteración del modelo funcional, en este se diseña el sistema para el uso operacional. En algunos casos, la iteración del modelo funcional y esta, suceden en forma concurrente. • Implementación: coloca el incremento de software más 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 dinámicos tiene como objetivo fundamental la entrega de sistemas software en tiempo y presupuesto , ajustándose a los cambios de requisitos que puedan surgir durante el proceso de desarrollo. Para su implementación 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 también basado por la retroalimentación del usuario, de esa manera logrando converger la solución del negocio mas efectiva. Ademas de lo mencionado anteriormente el MDSD incluyen enttregas frecuentes, equipos autorizados, y pruebas a lo largo de todo su ciclo Modelo Scrum
  17. 17. Scrum es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo, fue desarrollado por Jeff Sutherland y elaborado más formalmente por Ken Schwaber. 11. Se enfoca en el hecho de que procesos definidos y repetibles sólo 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 días. La literatura de Scrum se orienta principalmente en la planeación iterativa y el seguimiento del proceso 12 Caracteristicas: • Enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, prácticas de desarrollo, implementación y demás cuestiones técnicas. • Hace uso de Equipos auto-dirigidos y auto-organizados • Puede ser aplicado teóricamente a cualquier contexto en donde un grupo de gente necesita trabajar junta para lograr una meta común. • Desarrollo de software iterativos incrementales basados en prácticas agiles • Iteraciones de treinta días; aunque se pueden realizar con mas frecuencia, estas iteraciones, conocidas como Sprint • Dentro de cada Sprint se denomina el Scrum Master al Líder de Proyecto quien llevará a cabo la gestión de la iteración • Se convocan diariamente un “Scrum Daily Meeting” el cual representa una reunión de avance diaria de no más de 15 minutos con el propósito de tener realimentación sobre las tareas de los recursos y los obstáculos 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?

×