1

Politécnico Gran Colombiano

Entrega 1 semana 3

Natalia Martínez Rojas

Ingeniería de software 1

Oliver Aguilar Bahamon

Subgrupo 2

2023
 2

Proyecto

1. ¿Qué modelo fue escogido?

Para el desarrollo de este proyecto con respecto a las características dadas por el cliente se
escogió el modelo Scrum la cual hace parte de las metodologías agiles las cuales son una
forma de trabajo que se sujeta al cambio el cual ayuda a reaccionar rápidamente sobre el
cambio, ser muy flexible con el cambio, pero sin sacrificar o afectar la estabilidad del
proyecto. Pero scrum es un framework del trabajo, el cual consiste de un marco de trabajo que
nos da algunas pautas a seguir para realizar el proyecto, pero no son obligatorias para seguir,
con scrum podemos gracias a su flexibilidad tomar algunas partes de scrum y adaptarlas a los
proyectos, además de que este se adapta a cualquier otro proyecto, pero con diferentes pautas,
pero siguiendo la misma metodología.

Dentro de scrum también existen ciertos roles que ayudan a tener un mayor orden y control
sobre el proyecto, algunos de los roles que podemos encontrar dentro de este modelo son:

 Product Owner (PO): Este es el encargado de contactar el equipo que desarrolla el

proyecto y el cliente interno. Este rol es el encargado de filtrar la información debe
tener la capacidad de decir que no se puede y que se pude hacer dentro del proyecto.

 Scrum master: Este rol debe ser un experto en scrum a diferencia del Product Owner,
su función es encargarse de guiar, indicar, ayudar al equipo de trabajo a cumplir con
los requerimientos planteados por el modelo Scrum y facilitar el trabajo. Hay que dejar
en claro que este rol no ordena debido a que el equipo debe ser autosuficiente.

 Development Team: Este ya viene siendo el equipo de trabajo que se encargan de

crear el producto, gente con capacidad técnica y con todo conocimiento sobre
programación para entregar el producto según las indicaciones dadas por el cliente y
comunicada por el Product Owner, siguiendo las pautas planteadas por el Scrum
master.

Dentro de las metodologías se encuentra otros roles que no forma parte del equipo de Scrum,
pero si hace parte de todo el desarrollo del proyecto los cuales son:

 Customers: Estos son aquellas personas que se encargan de la toma de decisiones

dentro de la organización, son los encargados de definir que debería tener la
organización.

 User: El sor de user hace referencia al cliente en los términos generales, la persona a
la que va destinada el producto.

 Backlog: Este mas que un rol es el conjunto de todos los requerimientos o todas las
funcionalidades que deben tener este producto desarrollado.

 Sprint: Este al igual que el backlog no es un rol este viene siendo el corazón de Scrum,
un intervalo de tiempo de máximo un mes, que comienza con el sprint Planning y
finaliza con el sprint Retrospective. Al final de cada sprint se debe entregar algo
funcional.

2. Ventajas, desventajas, riesgos y mitigación.
Ventajas
 Flexibilidad: El modelo Scrum es
muy flexible y permite adaptarse a
los cambios que surjan durante el
desarrollo del proyecto. Esto se
debe a su enfoque iterativo e
incremental.
 Entrega temprana de resultados:
Scrum se enfoca en entregar
pequeñas partes del proyecto en
cortos períodos de tiempo, lo que
permite obtener resultados tangibles
en un corto plazo.
 Mayor compromiso del equipo:
Scrum fomenta el trabajo en equipo
y la colaboración, lo que puede
llevar a una mayor motivación y
compromiso del equipo.
 Mayor transparencia: El modelo
Scrum es muy transparente, ya que
todas las partes interesadas tienen
acceso a la información del
proyecto.
Riesgos
 Falta de comunicación: Si no hay
una buena comunicación entre los
miembros del equipo o entre el
equipo y los interesados en el
proyecto, el proyecto puede
fracasar.
 Falta de compromiso: Si el equipo
no está comprometido con el
proyecto, puede haber una falta de
motivación y de esfuerzo.
 Cambios constantes: Si hay
demasiados cambios durante el
proceso, puede ser difícil mantener
el enfoque y el objetivo del
proyecto.
3
Desventajas
 Falta de estructura: Scrum puede ser
demasiado flexible en algunas
situaciones, lo que puede llevar a la
falta de estructura y a la
imposibilidad de cumplir con los
plazos del proyecto.
 Dependencia del equipo: Scrum
depende mucho del equipo y su
capacidad para trabajar en conjunto.
Si el equipo no está motivado o no
funciona bien, el proyecto puede
fracasar.
 Dificultad para la planificación: El
modelo Scrum es difícil de
planificar debido a la naturaleza
flexible del proceso.
Mitigación
 Comunicación: La comunicación
regular y abierta es fundamental
para el éxito de un proyecto Scrum.
 Compromiso: Es importante que
todo el equipo esté comprometido
con el proyecto y tenga una clara
comprensión de su papel en el
mismo.
 Gestión del cambio: Es importante
tener un proceso de gestión de
cambios establecido para minimizar
los cambios innecesarios y mantener
el enfoque del proyecto.
 4

3. ¿Por qué se escogió la metodología Scrum?

Se decidió el uso de la metodología Scrum debido a su gran flexibilidad y adaptabilidad al

cabio también por que este es muy útil para proyectos complejos esto debido a las siguientes
razones:

 Mayor flexibilidad: Scrum es un modelo de gestión de proyectos ágil que se adapta

fácilmente a los cambios durante el desarrollo del proyecto. Esto permite a los equipos
responder rápidamente a las necesidades y cambios del proyecto.

 Mayor eficiencia: Al dividir el proyecto en pequeñas partes y trabajar en ellas de

forma incremental, los equipos pueden entregar resultados de forma más eficiente y
temprana. Esto también permite detectar problemas y solucionarlos rápidamente.

 Mejora de la colaboración y comunicación: Scrum fomenta la colaboración y la

comunicación constante entre el equipo y los interesados en el proyecto. Esto ayuda a
garantizar que todos los miembros del equipo estén alineados en cuanto a los objetivos
y prioridades del proyecto.

 Mayor transparencia: Scrum es un modelo transparente que permite a todos los

interesados en el proyecto tener acceso a la información actualizada del mismo. Esto
incluye información sobre el progreso del proyecto, los obstáculos y los resultados
alcanzados.

 Mayor satisfacción del cliente: Scrum se centra en entregar un producto o servicio

que cumpla con las necesidades y expectativas del cliente. Al involucrar al cliente en el
proceso de desarrollo y mostrar resultados tangibles de forma temprana, se puede
lograr una mayor satisfacción del cliente.

En resumen, Scrum es recomendable porque permite una gestión más eficiente, adaptable y
transparente de proyectos complejos, fomenta la colaboración y la comunicación constante, y
ayuda a garantizar la satisfacción del cliente.

4. ¿Por qué se descargaron las demás metodologías?

 Modelo en cascada (Waterfall):

El modelo en cascada o Waterfall fue uno de los primeros modelos de desarrollo de

software, y aunque todavía se utiliza en algunos proyectos, no es recomendable en muchos
casos por las siguientes razones:

- Poca flexibilidad: El modelo en cascada se basa en una estructura lineal y secuencial

de fases que deben completarse antes de avanzar a la siguiente. Esto hace que sea
difícil adaptarse a los cambios que puedan surgir durante el desarrollo del proyecto, lo
que puede resultar en retrasos y costos adicionales.
- Poca retroalimentación: El modelo en cascada no incluye una retroalimentación
constante del cliente o del usuario final, lo que puede llevar a desarrollar un producto
que no cumple con las necesidades o expectativas del cliente.
- Mayor riesgo de errores: El modelo en cascada implica una planificación exhaustiva
y una fase de prueba al final del proyecto. Esto significa que los errores pueden pasar
 5

desapercibidos hasta el final del proyecto, lo que resulta en costos adicionales y

retrasos en la entrega.
- Mayor costo y tiempo: Debido a la naturaleza secuencial del modelo en cascada, es
posible que se necesite más tiempo y recursos para completar cada fase antes de
avanzar a la siguiente, lo que puede resultar en un costo total y un tiempo de entrega
mayor.
- Mayor complejidad: Los proyectos de software pueden ser complejos y pueden
incluir cambios significativos en las fases de desarrollo. El modelo en cascada no es
adecuado para proyectos complejos, ya que puede hacer que el proceso de desarrollo
sea más complicado y difícil de gestionar.

En resumen, el modelo en cascada puede no ser adecuado para proyectos de desarrollo de

software complejos debido a su rigidez, falta de retroalimentación, mayor riesgo de errores,
mayor costo y tiempo, y mayor complejidad. En su lugar, se recomienda utilizar metodologías
más ágiles y flexibles, como Scrum o Kanban, que permiten una mayor adaptabilidad a los
cambios y una retroalimentación constante del cliente.

 Modelo en espiral (Spiral)

El modelo en espiral es una metodología de desarrollo de software que combina los

enfoques iterativos e incrementales del desarrollo de software con el proceso sistemático y
estructurado del modelo en cascada. Aunque esta metodología es más flexible que el modelo
en cascada, todavía puede no ser recomendable en algunos casos por las siguientes razones:

- Mayor costo: El modelo en espiral implica un mayor costo debido a la necesidad de

evaluar los riesgos y planificar cada iteración. Además, la retroalimentación constante
y la adaptación a los cambios pueden resultar en más trabajo y costos adicionales.
- Mayor complejidad: El modelo en espiral puede ser más complicado que otras
metodologías debido a su naturaleza iterativa y a la necesidad de planificar y evaluar
los riesgos en cada iteración. Esto puede hacer que sea difícil de manejar y de entender
para algunos equipos de desarrollo.
- Requiere de personal altamente capacitado: El modelo en espiral requiere de
personal altamente capacitado y experimentado, ya que los miembros del equipo de
desarrollo deben tener una sólida comprensión de la evaluación de riesgos y la gestión
de proyectos.
- Mayor tiempo de desarrollo: Debido a la naturaleza iterativa del modelo en espiral,
puede tomar más tiempo completar cada iteración y el proyecto en general.
- Falta de enfoque en la entrega de valor: Aunque el modelo en espiral tiene en cuenta
la evaluación de riesgos y la retroalimentación constante, puede faltar un enfoque en la
entrega de valor al cliente. Esto puede resultar en un producto que no cumple con las
necesidades o expectativas del cliente

En resumen, el modelo en espiral puede no ser recomendable para algunos proyectos

debido a su mayor costo, complejidad, necesidad de personal altamente capacitado, mayor
tiempo de desarrollo y falta de enfoque en la entrega de valor al cliente. En su lugar, se
recomienda utilizar metodologías más ágiles y centradas en el cliente, como Scrum o Kanban,
que permiten una mayor adaptabilidad a los cambios y una entrega constante de valor al
cliente.
 6

 Desarrollo rápido de aplicaciones (RAD)

El modelo de Desarrollo Rápido de Aplicaciones (DRA o RAD, por sus siglas en inglés) es
una metodología de desarrollo de software que se enfoca en acelerar el proceso de desarrollo
de software mediante el uso de herramientas y técnicas específicas. Aunque esta metodología
puede ser adecuada para algunos proyectos, puede no ser recomendable en otros casos por las
siguientes razones:

- Menor calidad: Debido a la velocidad y el enfoque en la entrega rápida, el DRA puede

comprometer la calidad del software producido. Esto se debe a que a menudo se salta la
fase de pruebas y validaciones necesarias para garantizar la calidad del software.
- Mayor riesgo: El DRA es una metodología de alto riesgo, ya que se enfoca en la
entrega rápida y no siempre se tiene en cuenta la evaluación adecuada de riesgos y la
planificación necesaria para evitar problemas futuros.
- Falta de documentación: El DRA se enfoca en la entrega rápida de software y puede
descuidar la documentación necesaria para el mantenimiento y la comprensión futura
del software.
- Dependencia de herramientas y tecnologías específicas: El DRA depende en gran
medida de herramientas y tecnologías específicas, lo que puede hacer que sea difícil de
implementar en entornos que no tienen acceso a estas herramientas.
- No adecuado para proyectos complejos: El DRA puede no ser adecuado para
proyectos complejos debido a la naturaleza acelerada de la metodología y la necesidad
de una planificación adecuada.

En resumen, aunque el DRA puede ser útil en algunos casos, puede no ser recomendable
en otros debido a la menor calidad del software, el mayor riesgo, la falta de documentación, la
dependencia de herramientas y tecnologías específicas, y su inadecuación para proyectos
complejos. En su lugar, se recomienda utilizar metodologías más ágiles y centradas en el
cliente, como Scrum o Kanban, que permiten una mayor adaptabilidad a los cambios y una
entrega constante de valor al cliente sin comprometer la calidad del software.

 Desarrollo de software orientada a objetos (OOAD)

En realidad, el modelo de Desarrollo de Software Orientado a Objetos (DSOO) es una

metodología de desarrollo de software muy popular y efectiva que se utiliza ampliamente en
la industria. La DSOO se enfoca en el diseño, desarrollo y mantenimiento de software
utilizando principios de programación orientada a objetos, lo que permite una mayor
reutilización del código y una mayor eficiencia en el desarrollo.

Sin embargo, como con cualquier metodología de desarrollo de software, hay situaciones
en las que la DSOO puede no ser recomendable. Algunas de las razones por las cuales la
DSOO podría no ser adecuada incluyen:

- Requiere de habilidades y conocimientos específicos: La DSOO requiere que los

miembros del equipo tengan habilidades y conocimientos específicos en programación
orientada a objetos, lo que puede no ser fácil de adquirir o puede requerir tiempo y
recursos adicionales.
- Mayor costo: El desarrollo de software orientado a objetos puede ser más costoso que
otras metodologías debido a la necesidad de adquirir herramientas y tecnologías
específicas, así como a la capacitación requerida para el equipo.
 7

- No adecuada para proyectos pequeños: La DSOO puede no ser adecuada para

proyectos pequeños que no requieren un diseño complejo y un alto nivel de
reutilización de código.
- Puede ser demasiado compleja para algunos proyectos: La DSOO puede ser
demasiado compleja para algunos proyectos y puede requerir más tiempo y recursos de
lo que se necesita para desarrollar el software.
- Dificultad en la gestión del proyecto: La DSOO puede ser más difícil de gestionar en
comparación con otras metodologías, especialmente si el equipo de desarrollo es nuevo
en el enfoque de la programación orientada a objetos.

En resumen, aunque la DSOO es una metodología de desarrollo de software efectiva y

ampliamente utilizada, puede no ser adecuada para todos los proyectos. Se recomienda
evaluar cuidadosamente las necesidades del proyecto y la capacidad del equipo antes de
adoptar la DSOO o cualquier otra metodología de desarrollo de software.

 El proceso unificado racional (RUP)

El proceso unificado racional (Rational Unified Process o RUP) es un modelo de

desarrollo de software que se centra en la planificación, el control y la gestión del proyecto de
software. Aunque este modelo puede ser adecuado en algunos casos, hay algunas razones por
las que podría no ser recomendable en todos los casos:

- Requiere una gran cantidad de recursos: El RUP es un modelo muy completo que
requiere una gran cantidad de recursos, incluyendo tiempo, dinero y personal altamente
capacitado. Esto puede no ser factible para todas las organizaciones o proyectos.
- Enfoque demasiado estructurado: El RUP es un modelo muy estructurado y rígido
que puede ser difícil de adaptar a proyectos que requieren una mayor flexibilidad y
adaptabilidad.
- Exceso de documentación: El RUP puede requerir una gran cantidad de
documentación, lo que puede aumentar el tiempo y el costo del proyecto. Además, la
documentación puede ser redundante o innecesaria en algunos casos.
- No enfocado en la entrega de valor al cliente: El RUP se centra en la planificación y
la gestión del proyecto, pero no necesariamente en la entrega de valor al cliente. Esto
puede resultar en un producto final que no cumple con las necesidades y expectativas
del cliente.

En resumen, aunque el RUP puede ser adecuado para proyectos grandes y complejos que
requieren una planificación y gestión rigurosas, puede no ser recomendable para proyectos
más pequeños o para organizaciones que buscan una mayor flexibilidad y adaptabilidad. En
su lugar, se recomienda utilizar metodologías más ágiles y centradas en el cliente, como
Scrum o Kanban, que permiten una mayor adaptabilidad a los cambios y una entrega
constante de valor al cliente sin comprometer la calidad del software.

 Desarrollo de software dirigido por modelos (MDSD)

El modelo de Desarrollo de Software Dirigido por Modelos (DSDM, por sus siglas en
inglés) es una metodología de desarrollo de software que se enfoca en la entrega rápida y
continua de software de alta calidad mediante el uso de modelos y prototipos. Aunque puede
ser una metodología adecuada para algunos proyectos, existen algunas razones por las cuales
el DSDM podría no ser recomendable en todos los casos:
 8

- Dependencia de herramientas y tecnologías específicas: El DSDM depende en gran

medida de herramientas y tecnologías específicas, lo que puede hacer que sea difícil de
implementar en entornos que no tienen acceso a estas herramientas.
- No adecuado para proyectos complejos: El DSDM puede no ser adecuado para
proyectos complejos que requieren una planificación y gestión cuidadosas debido a la
naturaleza acelerada de la metodología.
- Falta de documentación: El DSDM se enfoca en la entrega rápida de software y
puede descuidar la documentación necesaria para el mantenimiento y la comprensión
futura del software.
- Puede comprometer la calidad del software: Debido a la velocidad y el enfoque en
la entrega rápida, el DSDM puede comprometer la calidad del software producido. Esto
se debe a que a menudo se salta la fase de pruebas y validaciones necesarias para
garantizar la calidad del software.
- Mayor riesgo: El DSDM es una metodología de alto riesgo, ya que se enfoca en la
entrega rápida y no siempre se tiene en cuenta la evaluación adecuada de riesgos y la
planificación necesaria para evitar problemas futuros.

En resumen, aunque el DSDM puede ser adecuado para algunos proyectos, puede no ser
recomendable en otros debido a la dependencia de herramientas y tecnologías específicas, su
inadecuación para proyectos complejos, la falta de documentación, la posible comprometida
calidad del software y el mayor riesgo. En su lugar, se recomienda utilizar metodologías más
ágiles y centradas en el cliente, como Scrum o Kanban, que permiten una mayor adaptabilidad
a los cambios y una entrega constante de valor al cliente sin comprometer la calidad del
software.

 Lean Software Development

El modelo Lean Software Development (LSD) es una metodología de desarrollo de

software que se basa en los principios de la producción Lean y busca minimizar el
desperdicio, mejorar la eficiencia y aumentar el valor entregado al cliente. Aunque puede ser
una metodología adecuada para algunos proyectos, existen algunas razones por las cuales el
LSD podría no ser recomendable en todos los casos:

- Requiere un alto nivel de experiencia: La implementación exitosa del LSD requiere

un alto nivel de experiencia en la metodología Lean y en la industria del software. Esto
puede ser un desafío para los equipos de desarrollo menos experimentados.
- Puede llevar a la falta de documentación: El enfoque de LSD en la entrega rápida y
la eliminación del desperdicio puede llevar a una falta de documentación, lo que puede
dificultar el mantenimiento y la comprensión futura del software.
- No adecuado para proyectos de gran escala: El LSD puede no ser adecuado para
proyectos de gran escala que requieren una planificación y gestión cuidadosas debido a
la naturaleza acelerada de la metodología.
- Puede ser difícil de implementar en entornos no ágiles: El LSD se basa en una
cultura ágil y puede ser difícil de implementar en entornos no ágiles o en equipos que
no están acostumbrados a trabajar de manera ágil.
- No siempre es fácil de adaptar: La naturaleza inflexible del LSD puede hacer que sea
difícil adaptar la metodología a las necesidades cambiantes del proyecto o del cliente.
 9

En resumen, aunque el LSD puede ser adecuado para algunos proyectos, puede no ser
recomendable en otros debido al alto nivel de experiencia requerido, la posible falta de
documentación, su inadecuación para proyectos de gran escala, la dificultad de
implementación en entornos no ágiles y la inflexibilidad de la metodología. En su lugar, se
recomienda utilizar metodologías más ágiles y centradas en el cliente, como Scrum o Kanban,
que permiten una mayor adaptabilidad a los cambios y una entrega constante de valor al
cliente sin comprometer la calidad del software.

 Modelo Prototipo

El modelo de desarrollo de software basado en prototipos se centra en la construcción de

prototipos rápidos para ayudar a comprender los requisitos del cliente y refinar el diseño del
sistema. Aunque este modelo puede ser útil en algunos casos, hay algunas razones por las que
podría no ser recomendable en todos los casos:

- Enfoque limitado: El modelo de prototipo se centra en la construcción de prototipos

en lugar de en la construcción del producto final. Esto puede resultar en un producto
final que no cumple con las expectativas del cliente.
- No es adecuado para proyectos grandes y complejos: El modelo de prototipo puede
no ser adecuado para proyectos grandes y complejos que requieren una planificación
rigurosa y una gestión de proyectos cuidadosa.
- Requiere habilidades de desarrollo y diseño: La construcción de prototipos requiere
habilidades avanzadas de desarrollo y diseño, lo que puede no estar disponible en todos
los equipos de desarrollo de software.
- Puede ser costoso y consumir tiempo: La construcción de prototipos puede ser
costosa y consumir tiempo, especialmente si se necesitan múltiples prototipos para
refinar el diseño del sistema.

En resumen, aunque el modelo de prototipo puede ser útil en algunos casos, puede no ser
recomendable para proyectos grandes y complejos que requieren una planificación rigurosa y
una gestión cuidadosa del proyecto. En su lugar, se recomienda utilizar metodologías más
ágiles y centradas en el cliente, como Scrum o Kanban, que permiten una mayor adaptabilidad
a los cambios y una entrega constante de valor al cliente sin comprometer la calidad del
software.

 Modelo V

El modelo V es un modelo de desarrollo de software que se basa en la idea de que la

verificación y validación son esenciales para la calidad del software. Aunque este modelo
puede ser útil en algunos casos, hay algunas razones por las que podría no ser recomendable
en todos los casos:

- Requiere una planificación detallada: El modelo V requiere una planificación

detallada y rigurosa desde el principio del proyecto. Esto puede ser difícil de lograr si
el alcance del proyecto cambia a medida que avanza.
- No es adecuado para proyectos complejos y cambiantes: El modelo V no es
adecuado para proyectos complejos y cambiantes que requieren adaptabilidad y
flexibilidad en la planificación y el desarrollo.
- Enfocado en la verificación y validación tardía: El modelo V se centra en la
verificación y validación tardía, lo que significa que los errores pueden ser detectados
 10

en etapas avanzadas del proceso de desarrollo. Esto puede aumentar el costo y el

tiempo necesario para corregir los errores.
- No promueve la colaboración: El modelo V no promueve la colaboración entre los
miembros del equipo y puede dificultar la comunicación y el intercambio de ideas.

En resumen, aunque el modelo V puede ser adecuado para proyectos que requieren una
planificación detallada y rigurosa desde el principio, no es recomendable para proyectos
complejos y cambiantes que requieren flexibilidad y adaptabilidad en la planificación y el
desarrollo. En su lugar, se recomienda utilizar metodologías más ágiles y centradas en el
cliente, como Scrum o Kanban, que permiten una mayor adaptabilidad a los cambios y una
entrega constante de valor al cliente sin comprometer la calidad del software.

 Metodología Kanban

En general, la metodología Kanban es muy útil y efectiva en muchos casos, pero hay
algunas situaciones en las que puede no ser la mejor opción. Algunas de las razones por las
que puede que no se recomiende el uso de Kanban son:

- Requiere una alta madurez en gestión de proyectos: El éxito de Kanban depende en

gran medida de la madurez en la gestión de proyectos del equipo. Si el equipo no tiene
experiencia en la gestión de proyectos o no está acostumbrado a trabajar de manera
autónoma, es posible que la implementación de Kanban no sea tan efectiva.
- No es adecuada para proyectos altamente inciertos: Kanban es una metodología de
flujo continuo que requiere una planificación detallada y una comprensión clara de los
requisitos del proyecto. Si el proyecto es altamente incierto o los requisitos cambian
constantemente, Kanban puede no ser la mejor opción.
- Puede no ser efectiva para proyectos de gran escala: Kanban es una metodología
que se enfoca en la entrega continua de pequeñas unidades de trabajo. Si se trata de
proyectos de gran escala, puede ser más difícil de aplicar ya que se requiere una mayor
coordinación y planificación para el equipo.
- No enfatiza en la mejora continua: Aunque Kanban puede ser efectiva para la gestión
del flujo de trabajo, no se enfoca en la mejora continua como lo hace Scrum. Por lo
tanto, puede ser menos adecuada para proyectos que requieren un alto nivel de
innovación o mejora continua.

En resumen, aunque la metodología Kanban es muy útil y efectiva en muchos casos, puede
no ser la mejor opción en situaciones en las que se requiere una alta madurez en la gestión de
proyectos, el proyecto es altamente incierto, se trata de proyectos de gran escala o se enfoca
en la mejora continua. En estos casos, puede ser más efectiva la implementación de otras
metodologías, como Scrum o el enfoque de desarrollo Lean.

 Metodología XP o Extreme Programming

La metodología Extreme Programming (XP) es una metodología de desarrollo de software

ágil que se centra en la entrega constante y rápida de software de alta calidad. Aunque puede
ser una metodología adecuada para algunos proyectos, hay algunas razones por las que podría
no ser recomendable en todos los casos:

- Requiere un alto nivel de colaboración: XP se basa en una alta colaboración entre los
miembros del equipo y los clientes. Si los miembros del equipo no tienen una buena
 11

relación con el cliente, o si el cliente no está disponible para colaborar de manera

constante, puede ser difícil implementar XP.
- Puede ser difícil para equipos grandes: XP puede ser difícil de implementar para
equipos grandes debido a la naturaleza intensiva de la colaboración y la coordinación
que se requiere.
- Puede llevar a la falta de documentación: XP se centra en la entrega rápida y
frecuente de software, lo que puede llevar a una falta de documentación y dificultar el
mantenimiento y la comprensión futura del software.
- No adecuado para proyectos de larga duración: XP puede no ser adecuado para
proyectos de larga duración que requieren una planificación y gestión cuidadosas
debido a la naturaleza intensiva de la colaboración y la falta de planificación.
- Puede ser difícil de implementar en entornos no ágiles: XP se basa en una cultura
ágil y puede ser difícil de implementar en entornos no ágiles o en equipos que no están
acostumbrados a trabajar de manera ágil.

En resumen, aunque XP puede ser adecuado para algunos proyectos, puede no ser
recomendable en otros debido al alto nivel de colaboración requerido, la dificultad para
implementarlo en equipos grandes, la posible falta de documentación, su inadecuación para
proyectos de larga duración y la dificultad de implementación en entornos no ágiles. En su
lugar, se recomienda utilizar metodologías más flexibles y centradas en el cliente, como
Scrum o Kanban, que permiten una mayor adaptabilidad a los cambios y una entrega
constante de valor al cliente sin comprometer la calidad del software.
 12

Bibliografía

 Descripción Scrum: https://www.youtube.com/watch?v=sLexw-

z13Fo&t=174s&ab_channel=EDteam
 Ventajas, desventajas, riesgos y mitigación: https://blog.lemontech.com/metodologia-
scrum-ventajas-desventajas/
 Modelos y sus características: https://cynoteck.com/es/blog-post/top-software-
development-models-to-choose-from/
 Modelo en cascada: https://www.crehana.com/blog/transformacion-digital/modelo-en-
cascada/
 Modelo en espiral: https://www.ionos.es/startupguide/productividad/modelo-en-espiral/
 Desarrollo rápido de aplicaciones: https://www.youtube.com/watch?
v=GlCZmrBuzx8&ab_channel=LUISJAIROROBLES
 Desarrollo de software orientada a objetos:
https://www.techtitute.com/co/informatica/cursos-software/blog/desarrollo-software-
orientado-objetos
 El proceso unificado racional: https://www.programaenlinea.net/proceso-unificado-
rational-rup/
 Desarrollo de software dirigido por modelos: https://www.youtube.com/watch?
v=41j4oSS1X9Y&ab_channel=FacultaddeInform%C3%A1ticaUNLP
 Lean Software Development: https://techlib.net/techedu/lean-software-development/
 Modelo prototipo: https://www.ecured.cu/Modelo_de_prototipos
 Modelo V: https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/modelo-v/
 Modelo Kanban: https://asana.com/es/resources/what-is-kanban
 Metodología XP: https://www.sydle.com/es/blog/extreme-programming-
602ee205da4d096809438c9c#:~:text=El%20Extreme%20Programming%20(XP)
%20es,y%20ciclos%20de%20desarrollo%20cortos.