en el sistema WATERFALL es necesario determinar y discutir los alcances del sistema junto al Stakeholder con la finalidad de documentar en un contrato de diseño de software el cual debe ser seguido al pie de la letra, y se deben poner tambien precios fijos e incluso de llegar a ser modificado se puede incurrir en una falta y llegar a ser penalizado con multas.

a continuacion dejo un pequeño articulo para complementar la breve explicacion del parrafo anterior

https://blog.comparasoftware.com/metodologia-waterfall/

Cada proyecto responde a necesidades específicas y a partir de es punto se define el ciclo de vida del proyecto. El ciclo de vida predictivo o en "cascada" se usa generalmente en entornos estables en los que se puede definir el alcance del proyecto desde el inicio. Pese a que son utilizados principalmente en industrias como la construcción (En los que se ha demostrado sus beneficios), también es utilizado en proyectos de software en los que en el marco contractual se establecen restricciones de tiempo, alcance, recursos, costos y calidad, y en estos casos no es viable agregar cambios importantes durante la ejecución.

Por otro lado, los ciclos de vida adaptativos, presentan características de cambios permanentes, por lo que el alcance puede variar durante la ejecución del proyecto. En este ciclo se pueden encontrar variaciones: Incremental, iterativo, ágil (Combina las dos anteriores). Estos ciclos de vida son muy efectivos y generan grandes resultados en desarrollos internos de las empresas que hacen uso de capacidad instalada. En relación con cliente se debe incluir un alcance inicial y unos ajustes o enfocarlo desde la contratación de horas de desarrollo, por lo que la restricción no sería de alcance sino de costos, y el alcance sería variable.

Cabe mencionar que, algunos proyectos pueden tener un ciclo de vida con interrelación híbrida en los que se utilizan fases predictivas para los componentes que ya están definidos con claridad, y fases adaptativas para los aspectos que no están definidos y requieren cambios durante la ejecución.

Finalmente, el involucramiento de los stakeholders, es una buena practica de la gestión de proyectos sin importar el ciclo de vida ni el marco de trabajo que se emplee.

Muy buenas aportaciones.

Hola y muy buenas tardes a tod@s. Quisiera compartirles, mis apuntes acerca de la totalidad del video. (Método Cascada "Waterfall").

#

Modelo de Waterfall

(Profundizando en este concepto)

imaginando que se va a entregar un proyecto.

¿Qué es lo primero que se estará buscando?

• Puede haber un cliente, que esté pidiendo algún desarrollo, puede que se quiera llegar a un objetivo, a una meta específica.

La clave es dejar al cliente satisfecho.

Si se está, utilizando el modelo Waterfall, todos esos requisitos.

Tienen que estar:

• Documentados.

• Justificados.

*Y eso al final, solamente va a generar: *

• Un documento enorme:

  • Que nadie va a querer leer.

  • Que alguien, va a tener que validar .

  • Y que el cliente o cualquiera, de los stakeholders, va a tener que firmar.

Por lo tanto, el cliente tiene que tomar una decisión y no es una decisión simple.

(De hecho, hay muchísimas variables en juego en esta decisión).

No es solamente el costo, que se está pagando por hacer una entrega, sino, las ganancias que se pueden ver afectadas.

Hay un punto que es crucial y que es parte de este costo.

• La expectativa que hay al respecto de todo este proyecto.

¿Por qué?

• Porque, pueden empezar con una definición y una expectativa, pero esta, puede cambiar en todo este proceso, en donde se está desarrollando.

• Esto es uno de los mayores problemas, porque el documento, ya se encuentra, firmado y aprobado y por lo tanto, no se va a poder meter cambios.

Aquí se presenta una de las interrogantes, más importantes:

• ¿Qué pasa si ya se definió un requisito, pero el cliente, cambió de idea o sí uno mismo, se le ocurre una mejor idea, de cómo abordar el proyecto y realmente se necesita buscar una alternativa?

*Otro problema que presenta, el modelo de cascada es que: *

• No se tiene, retroalimentación inmediata.

¿Por qué pasa esto?

• El proceso para identificar, que el proyecto, realmente funcionó, va a tomar tiempo.

• Por ejemplo: La competencia, puede ganar la batalla, y entregar un producto más rápido, que cumple justamente con la necesidad, que el cliente necesita.

Si se lleva todo este proceso, a un entorno de tecnología:

• Allí, las cosas son incluso más difíciles:

  • Porque todo cambia muy rápido.

Otro problema, que posee el modelo de Waterfall es que:

• No está pensado para poder priorizar.

*De hecho: *

• Está pensado, para ejecutar siempre de forma secuencial.

*Hay que tomar en cuenta que: *

• En cada etapa o en cada fase que se va a entregar:

  • Se tiene, que hacer un análisis.

  • Se tiene que esperar a que, haya definiciones.

Esperar a que, haya una aprobación.

Y eso va a pasar de forma recurrente, hasta que acabe el proyecto.

La clave es realizar entregas más pequeñas.

Porque es ahí, donde se puede:

• Identificar, si realmente se está entregando valor.

*A diferencia, de una etapa enorme, que va a tomar por lo menos, un mes o varias semanas en poder implementarse. *

Y eso al final, es un costo muy alto. Entonces justamente, es por eso que:

• La clave es realizar entregas más pequeñas.

¡Saludos Cordiales!