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.
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.
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.
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.
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.
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.
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.
• 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.
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.
• 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.
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.
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.
• 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.
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.
- 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.
• 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.
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?