ACTIVIDAD SEMANA 9 – MODELOS DE DESARROLLO DE SOFTWARE.

Ricardo jose Meneses Rueda

Realice un comparativo entre los siguientes 9 modelos de desarrollo de software:

El modelo de cascada, Modelo espiral, Modelo V, El proceso unificado racional (RUP),
Modelo incremental e iterativo, modelo prototipo, SCRUM, Kanban, Programación
extrema (XP)
Incluya en la comparación los siguientes aspectos:
- Fecha de creación.
- Descripción.
- Fases.
- Ventajas.
- Desventajas.
- Aplicabilidad del modelo.

1. MODELO DE CASCADA:

 Fecha de creación: Surgió en los años 1970.

 Descripción: Es un enfoque secuencial y lineal donde las fases del desarrollo de software
se realizan de manera secuencial, pasando de una fase a otra una vez que la anterior ha
sido completada. No hay retrocesos en las fases anteriores.
 Fases:
Fase de análisis: Planificación, análisis y especificación de los requisitos.
Fase de diseño: Diseño y especificación del sistema.
Fase de implementación: Programación y pruebas unitarias.
Fase de Verificación: Integración de sistemas, pruebas de sistema e integración.
Fase de implementación: Despliegue de Sistemas
Fase de mantenimiento: Entrega, mantenimiento y mejora.
 Ventajas: Es simple y fácil de entender. Cada fase se completa antes de avanzar a la
siguiente. Adecuado para proyectos con requisitos bien definidos y estables.
 Desventajas: No permite cambios una vez que se avanza a la siguiente fase. Puede haber
problemas de retroceso si se identifican errores en fases posteriores. No se adapta bien a
cambios en los requisitos.
 Aplicabilidad: Adecuado para proyectos con requisitos bien definidos y estables, donde los
cambios son mínimos.
2. MODELO ESPIRAL:

 Fecha de creación: Surgió en los años 80.

 Descripción: Es un enfoque iterativo y gradual que combina elementos del modelo de
cascada con la gestión de riesgos. Se centra en la identificación temprana y mitigación de
riesgos.
 Fases:
Fase de planificación: El paso inicial es identificar y establecer objetivos y metas a
alcanzar. Luego, como alternativas, presentan las mejores formas potenciales de satisfacer
los objetivos. Todo esto requiere una comunicación continua entre el cliente y el equipo
de gestión del proyecto.
Fase de análisis de riesgos: Al planificar y finalizar la estrategia de reducción de riesgos, se
identifican los posibles peligros. Cada peligro destacado se somete a un examen
exhaustivo. Se pueden crear prototipos para eliminar la posibilidad de requisitos
ambiguos. Los riesgos se minimizan tomando precauciones.
Fase de ingeniería: Implica la codificación, prueba e implementación del software. Tras
una evaluación de riesgos, se adopta el modelo de desarrollo. El modelo a utilizar está
determinado por el nivel de riesgo que se ha reconocido para esa fase.
Fase de evaluación: Valoración del cliente sobre el programa. Se decide si repetir o no el
ciclo. Aquí se está planificando la siguiente fase del proyecto.
 Ventajas: Permite la identificación y mitigación temprana de riesgos. Se puede realizar un
prototipo funcional en cada iteración. Permite cambios en los requisitos y en el diseño
durante el proceso.
 Desventajas: Es complejo y puede ser costoso de implementar. Requiere una gestión de
riesgos efectiva para tener éxito. Puede tener problemas de control si no se manejan
adecuadamente los riesgos.
 Aplicabilidad: Adecuado para proyectos con requisitos cambiantes y donde la mitigación
de riesgos es crucial.
 3. MODELO V:

 Fecha de creación: Surgió en los años 80.

 Descripción: Es una variante del modelo de cascada que incluye pruebas en cada fase del
proceso de desarrollo de software. Las pruebas se realizan en paralelo con las fases de
desarrollo.
 Fases:

Fase de Verificación:

Análisis de requisitos: El paso inicial de la fase de verificación es comprender las

expectativas de los clientes sobre nuestros productos mediante una amplia comunicación
con los clientes.
Diseño de sistemas: Después de la identificación de los requisitos de los clientes y las
expectativas de nuestros productos, se debe desarrollar el sistema de diseño detallado
para el desarrollo del producto.
Diseño arquitectónico: El diseño del sistema se segrega en diferentes módulos según sus
funcionalidades. Se reconoce la transferencia de datos entre los módulos internos y otros
sistemas.
Diseño del módulo: Los diseños se segregan aún más en módulos más pequeños y más
detallados.

Fases de Validación:

 Examen de la unidad: Las pruebas unitarias eliminan errores a nivel de código o de

unidad.
 Pruebas de integración: Las pruebas de integración validan la comunicación interna entre
módulos dentro del sistema.
 Pruebas del sistema: Las pruebas del sistema examinan los requisitos funcionales y no
funcionales de la aplicación desarrollada.
 Pruebas de aceptación del usuario (UAT): UAT valida la usabilidad del sistema
desarrollado en el mundo real.

 Ventajas: Permite una mayor detección temprana de errores y problemas. Ayuda a

garantizar la calidad del software. Facilita la identificación y corrección temprana de
errores.
 Desventajas: Puede tener una mayor complejidad en la planificación y gestión de las
pruebas en paralelo con el desarrollo. Los cambios en los requisitos pueden tener impacto
en las pruebas realizadas anteriormente.
 Aplicabilidad: Adecuado para proyectos donde la calidad y la detección temprana de
errores son prioritarios.

4. PROCESO UNIFICADO RACIONAL (RUP):

 Fecha de creación: Surgió en los años 90 como un marco de trabajo desarrollado por
Rational Software, que luego fue adquirido por IBM.

 Descripción: El RUP es un modelo de desarrollo de software basado en un enfoque

iterativo e incremental. Se centra en la colaboración entre equipos y la gestión de riesgos.
Proporciona un marco de trabajo detallado que define roles, actividades, artefactos y
flujos de trabajo.

 Fases:

Comienzo: Se visualiza la idea central.

Elaboración: Se diseñan los casos de uso y la arquitectura.

 Construcción: Actividades desde el diseño hasta el producto terminado.

Transición: Seguimiento de actividades para asegurar la satisfacción del cliente.

 Ventajas: Proporciona un enfoque estructurado y bien definido para el desarrollo de

software. Se centra en la gestión de riesgos y la calidad del software. Permite la
adaptación a cambios en los requisitos del proyecto. Facilita la colaboración entre equipos
y stakeholders.

 Desventajas: Puede ser complejo y requiere una planificación y gestión rigurosa. Puede
ser costoso de implementar. Requiere una buena comprensión de los roles y actividades
definidos en el marco de trabajo. Puede tener una curva de aprendizaje para los equipos
nuevos en el uso del RUP.

 Aplicabilidad: Adecuado para proyectos grandes y complejos, donde la gestión de riesgos

y la calidad son prioritarias. Puede ser utilizado en proyectos con requisitos cambiantes o
no bien definidos. Requiere un equipo experimentado y disciplinado para implementarlo
de manera efectiva.

5. MODELO INCREMENTAL E ITERATIVO:

 Fecha de creación: No tiene una fecha de creación específica, ya que es un enfoque que
ha evolucionado con el tiempo y se ha aplicado en diferentes contextos a lo largo de la
historia del desarrollo de software.
 Descripción: Es un enfoque de desarrollo de software que se basa en la entrega de
funcionalidades en incrementos sucesivos y la retroalimentación continua del cliente o del
usuario final. Se realiza en ciclos iterativos, donde cada iteración incluye actividades de
planificación, diseño, implementación, prueba y evaluación.
 Fases:
 Los siguientes pasos se pueden utilizar para clasificar el desarrollo iterativo e incremental:

Fase de Iniciación: La fase de iniciación de un proyecto se ocupa del alcance, las

necesidades y los peligros a un nivel superior.
Fase de Elaboración: Crea una arquitectura viable que mitiga los riesgos identificados en la
primera fase y cumple con los criterios no funcionales.
Fase de construcción: Gradualmente completa los componentes de la arquitectura con
código listo para la producción, que se desarrolla mediante el análisis, la implementación,
el diseño y las pruebas de los requisitos funcionales.
Fase de transición: Entregar el sistema al entorno operativo de producción durante la fase
de transición.
 Desventajas: Puede requerir una planificación y seguimiento cuidadosos para coordinar
las iteraciones y asegurar una entrega oportuna. Puede haber complejidad adicional en la
gestión de configuración y versiones del software en desarrollo. Requiere una
retroalimentación continua del cliente o usuario final.
 Aplicabilidad: Adecuado para proyectos con requisitos cambiantes o no bien definidos.
Adecuado para proyectos donde se busca una entrega rápida y temprana de
funcionalidades. Adecuado para proyectos donde se valora la retroalimentación continua
del cliente o usuario final. Adecuado para equipos de desarrollo con capacidad de
adaptación y colaboración.

6. MODELO PROTOTIPO:

 Fecha de creación: Desarrollado en la década de 1970.

 Descripción: Es un enfoque de desarrollo de software que se basa en la construcción de
prototipos rápidos para obtener retroalimentación temprana del cliente o usuario final.
Los prototipos son versiones simplificadas del software que permiten identificar y corregir
problemas antes de la implementación final.
 Fases:
Análisis de requisitos: El paso inicial del modelo trata de establecer los requisitos del
sistema deseable.
diseño: Después de la identificación de los requisitos del sistema deseado, se forma un
diseño conceptual básico.
Formación de prototipos: Con la ayuda del diseño conceptual básico, se construye un
prototipo de trabajo para el sistema deseado.
Evaluación inicial: El prototipo es probado por el cliente en este paso para evaluar
funcionalidades y limitaciones.
Prototipo de refinación: El prototipo se refina aún más, analizando la evaluación realizada
por el cliente.
Producción: Una vez que se ejecuta el proceso de refinación, se produce el sistema final
para su uso en tiempo real.

 Ventajas: Permite una retroalimentación temprana y precisa del cliente o usuario final.
Ayuda a identificar y corregir problemas antes de la implementación final. Facilita la
 comprensión de los requisitos del software. Mejora la comunicación y la colaboración
entre el equipo de desarrollo y los stakeholders.
 Desventajas: Puede requerir un esfuerzo adicional en la construcción y evaluación de
prototipo
 Aplicabilidad:
 Cuando el requisito del sistema deseado es inequívoco.
 Cuando aún no se han evaluado las funciones básicas del sistema deseado.
 Si es necesario cambiar los requisitos del sistema resultante.
 Mostrar las funcionalidades técnicas del producto deseado mediante la creación de un
prototipo.

7. SCRUM:

 Fecha de creación: Scrum fue creado en los años 80 por Jeff Sutherland y Ken Schwaber.
 Descripción: Scrum es un marco de trabajo ágil para el desarrollo de software que se basa
en la colaboración, transparencia y adaptación. Se centra en la entrega incremental y en
ciclos de trabajo llamados "sprints" de 1 a 4 semanas de duración, donde se desarrollan
funcionalidades en base a las prioridades del cliente o usuario final.
 Fases:
Pila de Producto: La fase de acumulación de productos es cuando se determinan las tareas
prioritarias y se recopila información concisa y completa sobre el proyecto que se creará.
Sprint: El sprint es el corazón palpitante del proceso scrum, un marco de tiempo de un
mes durante el cual tiene lugar la creación de un producto potencialmente entregable.
Quemar: El burn down es la fase en la que se mide el progreso de un proyecto Scrum.
Cuando se completa cada sprint, el scrum master será responsable de actualizar las
imágenes.
 Ventajas: Permite una entrega temprana y frecuente de funcionalidades. Facilita la
colaboración y comunicación entre los miembros del equipo y los stakeholders. Permite la
adaptación a cambios en los requisitos del software. Proporciona transparencia y
visibilidad en el progreso del proyecto. Fomenta la mejora continua a través de las
retrospectivas.
 Desventajas: Requiere una planificación y seguimiento cuidadosos para asegurar una
correcta ejecución. Puede tener una curva de aprendizaje para el equipo y los
stakeholders. Requiere una colaboración y participación activa de todos los miembros del
equipo. Puede haber riesgos de tener cambios frecuentes en los requisitos del software.
 Aplicabilidad: Adecuado para proyectos con requisitos cambiantes o no bien definidos.
Adecuado para equipos de desarrollo autoorganizados y multidisciplinarios. Adecuado
para proyectos donde se valora la adaptabilidad y entrega frecuente de funcionalidades.

8. KANBAN:

 Fecha de creación: Kanban es un enfoque que se originó en la industria manufacturera en

Japón en los años 40 y 50, pero se ha adaptado al desarrollo de software en años más
recientes.
 Descripción: Kanban es un enfoque visual y basado en tarjetas que se utiliza para
gestionar y optimizar el flujo de trabajo. Se centra en la limitación del trabajo en progreso
(WIP) y en la mejora continua del flujo de trabajo, identificando cuellos de botella y
mejorando la eficiencia del proceso.
 Fases: Kanban se compone de un tablero visual donde se registran las tareas o elementos
de trabajo en diferentes columnas que representan el flujo de trabajo, como "por hacer",
 "en progreso", "en revisión", y "completado". No sigue un conjunto de fases específicas,
sino que se enfocaen el flujo continuo de trabajo y en la optimización del proceso.
 Ventajas: Proporciona visibilidad y transparencia del flujo de trabajo. Permite una gestión
eficiente del trabajo en progreso (WIP). Identifica cuellos de botella y permite la mejora
continua del proceso. Facilita la colaboración y comunicación entre los miembros del
equipo. Permite una adaptación rápida a cambios en las prioridades.
 Desventajas: Puede haber una falta de estructura y definición de fases, lo que puede
dificultar la planificación y seguimiento del proyecto. Puede requerir una mayor
 Aplicabilidad:
 Identificar y explicar detalladamente todos y cada uno de los procesos que tienen lugar en
la fabricación.
 Visualiza los procesos antes mencionados: Asigna a cada uno de ellos una tarjeta y
colócala en el panel Kanban.
 Una vez que se han visualizado los procesos, es más importante identificar los problemas,
como los cuellos de botella, para que puedan ser revisados y simplificados si es necesario.
 Mantenga su trabajo en progreso al mínimo. Es decir, intente limitar la cantidad de
actividades completadas para que los empleados puedan concentrarse en lo que más
importa.
 Tome medidas y actúe en consecuencia. Debido a que Kanban es una técnica dinámica,
será importante examinar los resultados y tomar medidas para mejorar la situación.

Programación Extrema (XP)

 Fecha de creación: XP fue creado en la década de 1990 por Kent Beck, Ron Jeffries y otros,
como parte de la metodología ágil.
  Descripción: XP es una metodología de desarrollo de software ágil que se enfoca en la
colaboración, la simplicidad y la retroalimentación constante. Se basa en principios como
la comunicación cercana con el cliente, la entrega frecuente de software funcional, la
retroalimentación continua y la mejora constante.
 Fases:
 Planificación: Las historias de usuarios se priorizan y se dividen en miniversiones según su
identidad. Habrá una reevaluación de la planificación.
 Codificación: Trabajar con un código simple en esta fase, realizando solo el mínimo
absoluto para que funcione. Será posible conseguir el prototipo.
 Pruebas: La programación se realiza en parejas frente a la misma computadora, “a dos
manos”. Es común que los socios se cambien. Esto asegura que se crea un código más
general, que cualquier otro programador puede comprender y trabajar con él.
 Lanzamiento: Si hemos llegado a esta fase, indica que hemos probado con éxito todas las
historias de usuario o versiones mini considerando las necesidades del cliente.

Ventajas:

 Enfoque en la satisfacción del cliente: XP pone un fuerte énfasis en la comunicación

cercana con el cliente y en la entrega frecuente de software funcional, lo que permite una
mayor satisfacción del cliente al obtener resultados rápidos y ajustar los requerimientos
en tiempo real.
 Flexibilidad: XP permite una mayor flexibilidad en el desarrollo del software, ya que se
pueden realizar cambios y mejoras en el software durante todo el proceso de desarrollo.

 Mayor calidad: XP utiliza pruebas unitarias y de integración para asegurar la calidad del
software, lo que puede resultar en un producto final más robusto y confiable.

Desventajas:
 Requiere una comunicación efectiva: XP requiere una comunicación constante y cercana
con el cliente y el equipo de desarrollo, lo que puede ser un desafío si no se maneja
adecuadamente.

 Poca documentación: XP se enfoca en el desarrollo de software funcional en lugar de la

documentación exhaustiva, lo que puede dificultar el mantenimiento y la comprensión del
sistema en el futuro.

 Dependencia del equipo: XP requiere un equipo altamente colaborativo y autónomo para

funcionar eficazmente, lo que puede ser un desafío en entornos donde la colaboración y la
autonomía son limitadas.

Aplicabilidad del modelo: XP es adecuado para proyectos de desarrollo de software donde la

colaboración con el cliente es fundamental, y se requiere una mayor flexibilidad y adaptabilidad a
los cambios en los requerimientos del software. Es especialmente útil en proyectos de tamaño
pequeño a mediano, donde la comunicación y la colaboración cercana son factores clave para el
éxito del proyecto. También es apropiado para equipos de desarrollo altamente colaborativos y
autónomos que puedan seguir las prácticas de XP de manera rigurosa.