Desarrollo del Modelo Cascada

La mentalidad tradicional del desarrollo de un software es usualmente

llamada el Modelo de Cascada. Utilizando el modelo de cascada un
producto no debe moverse de una fase a la siguiente hasta que la
fase predecesora haya sido completada a la perfección. No es posible
regresar a etapas previamente concluidas. Este modelo de desarrollo
se muestra en la imagen más abajo. Un problema con este enfoque
es que el riesgo se empuja al proceso de desarrollo y puede, si el
software tiene un tamaño significativo causar problemas más
adelante en el proceso. Esto puede llevar a un incremento en el costo
del proyecto y puede resultar en la terminación del mismo. (Kruchten,
2003).

Para cualquier Proyecto no trivial es difícil tener una fase del ciclo de
vida de un producto de software perfeccionada antes de moverse a
las siguientes fases y aprender de ellas. Por ejemplo, los clientes
pueden no estar conscientes de exactamente qué requisitos quieren
hasta que ven un prototipo funcional y pueden realizar sus
comentarios. Puede que cambien sus requisitos constantemente y los
diseñadores del programa e implementadores deben tener algo de
control sobre esto. Si el cliente cambia sus requisitos luego de que el
diseño haya sido finalizado, ese diseño debe ser modificado para
adaptarse a los nuevos requisitos, lo que a menudo invalida una parte
del esfuerzo y las horas invertidas. La siguiente imagen da un modelo
típico de un desarrollo en Cascada.
Modelo de Cascada o metodología del ciclo de vida

Los diseñadores pueden no estar al tanto de las futuras dificultades

de implementación al escribir un diseño para un producto de software
no implementado. Puede volverse claro en la fase de implementación
que un área en particular de la funcionalidad el programa es
extraordinariamente difícil de implementar. En este caso, es mejor
revisar el diseño que persistir utilizando un diseño hecho basado en
predicciones erradas y que no tiene en cuenta las áreas
problemáticas recién descubiertas.

A menos que aquellos que especifican los requisitos y aquellos que

diseñan el sistema de software en cuestión tengan un gran
conocimiento del problema a resolver, es difícil saber exactamente lo
que se necesita en cada fase del proceso antes de pasar algo de
tiempo en la fase siguiente.

Si no ataca activamente los riesgos en su proyecto, estos lo atacarán

activamente a usted (Tom Gilb, 1988).

La retroalimentación de las fases siguientes es usualmente necesaria

para completar las fases precedentes. Puede ser difícil estimar el
tiempo y costo de cada fase del proceso de desarrollo sin hacer una
especie de “prueba de concepto” en esa fase, a menos que aquellos
estimando el tiempo y los costos tengan una amplia experiencia en el
tipo de producto de software en cuestión. Vale la pena mencionar
que, sin embargo, con la experiencia y aprendizaje de proyectos
anteriores, ¡Se puede hacer con gran precisión!

Cuando se piensa en la metodología de Cascada, usualmente esta se

ve como un enfoque de peso pesado a la gestión de proyectos con un
Diseño Detallado por Adelantado (“Big Design Up Front” BDUF) que
no tiene ningún punto de control en el camino, llevado a cabo sin
tener en cuenta las condiciones cambiantes. Esto no es
necesariamente cómo se debe trabajar y no significa que usted no
puede evaluar su progreso y cambiar el curso a lo largo del camino.
No significa que usted no puede medir dónde usted se encuentra o
comparar eso contra las expectativas que se realizaron por
adelantado.

La Cascada puede ser muy superior cuando el cliente sabe

exactamente lo que quiere y nada cambia sustancialmente más allá
de los arreglos de errores. La metodología en Cascada es muy
desacreditada porque la mayoría de los clientes no saben lo que
quieren (lo que es perfectamente normal, siempre y cuando haya
alguien que los guíe).
El modelo de desarrollo Agile

La idea básica detrás de cualquier proceso de desarrollo Agile es que es de naturaleza

interactiva o cíclica, lo que significa que la implementación del software ocurre de
forma incremental. Hay una gran cantidad de enfoques interactivos existentes en la
actualidad. Por ejemplo: Scrum, Kanban, RUP, Programación Extrema, Desarrollo
Rápido de Aplicaciones etc. Como se mencionó anteriormente, me enfocaré en Scrum
ya que es la metodología con mayor popularidad en la actualidad.

Scrum es una forma para que los equipos trabajen juntos para desarrollar un producto.
El desarrollo de productos, utilizando Scrum ocurre en pequeñas piezas, cada pieza se
construye de piezas creadas previamente. Crear productos pieza por pieza alienta la
creatividad y permite que los equipos respondan a los comentarios y cambios, para crear
exactamente y solo lo que es necesario.

La siguiente imagen muestra un ejemplo del enfoque Scrum hacia el desarrollo de

software.

Ejemplo de scrum

En vez de crear todas las tareas y los horarios por adelantado, todo el tiempo es
encajonado en fases llamadas sprints. Cada sprint tiene una duración definida, la que
usualmente es de algunas semanas, con una lista de ejecución con entregables, y con
cada sprint planificado por adelantado. Los entregables son priorizados por su valor
empresarial el cual es determinado por el cliente. Si todo el trabajo planificado para un
sprint no puede ser completado, se le vuelve a dar prioridad al trabajo y la información
se utiliza para la planificación de los sprints futuros.

En la imagen se ve que el trabajo se toma de una lista ordenada por prioridades, la cual
se divide en sprints y luego se desarrolla. Los objetos en la parte superior de la lista
están más refinados que los de la parte inferior. Para no perder tiempo y dinero, los
objetos de la lista solo deben ser expandidos lo suficiente para realizar las decisiones
apropiadas. Para cada objeto en la lista de prioridades, se realiza en el sprint un historial
de usuario, una implementación y una prueba.

A medida que el trabajo sea completado durante cada sprint, se revisa y evalúa
continuamente por el cliente. Todo el trabajo que ha sido completado debe ser definido
como entregable, lo que significa que debe funcionar como se debe y debe haber pasado
a través de pruebas. Como resultado, Agile se basa en un alto nivel de participación del
cliente durante todo el proyecto ya que este es el que necesita validar la funcionalidad y
aceptar que funciona como se debe. El ciclo continúa hasta que el producto haya sido
completado y esté listo para ser desplegado o sea considerado como aceptable por la
empresa.

Comparando este enfoque con el modelo de desarrollo en Cascada, el valor de la

empresa se entrega constantemente en intervalos regulares, mientras que el modelo en
Cascada entrega todo el valor empresarial al final del proyecto. Seleccionar el enfoque
Scrum puede facilitar el control del proyecto con respecto al costo, retorno de inversión
y valor empresarial general. Hace que el proyecto sea mucho más transparente. En un
enfoque de Cascada, puede ser extremadamente complejo ver el beneficio total del
proyecto, hasta que el desarrollo esté muy cerca de ser completado. ¡Pero esto no es
algo necesariamente malo acerca del modelo en Cascada!
Costo, funcionalidad y tiempo
Como cualquier otra operación humana, los proyectos necesitan se realizados y
entregados bajo ciertas restricciones. Tradicionalmente, estas restricciones han sido
listadas como costo, funcionalidad y tiempo. Estas también son referidas como el
Triángulo de Administración de Proyectos (PMT), donde cada lado representa una
restricción. Un lado del triángulo no puede ser cambiado sin afectar los demás. Esta
relación se ilustra a continuación.

‍El Triángulo PMT

La restricción de tiempo/horario se refiere a la cantidad de tiempo disponible para

completar un proyecto. La restricción de costo se refiere al presupuesto disponible para
el proyecto. La restricción de funcionalidad/alcance se refiere a lo que debe hacerse para
llegar al resultado final del proyecto. Estas tres restricciones suelen ser restricciones
competitivas: aumentar la funcionalidad típicamente significa costos y tiempos
incrementados, y un presupuesto ajustado podría significar mayor tiempo y un alcance
reducido.

Dependiendo en el tipo de empresa/proyecto en el que está trabajando, dos de estas

restricciones serán las más importantes. Si es un precio fijo, entonces el costo del
proyecto es una restricción que no podrá ser cambiada. En ese caso, la funcionalidad o
el tiempo serán las que sufrirán.

En otras palabras, usted tiene 3 opciones:

 Desarrollar un producto rápidamente y con gran calidad o muchas

funcionalidades, pero a un alto precio.
 Desarrollar un producto rápidamente y a bajo costo, pero sin muchas
funcionalidades o calidad.
 Desarrollar un producto de alta calidad y muchas funcionalidades y a bajo costo,
pero con un tiempo relativamente más largo.

La calidad no es una parte del PMT, pero es el objetivo final de cada entrega. Por lo
tanto, el PMT implica calidad.

Muchos gestores de proyectos están bajo la noción de que una alta calidad implica altos
costos, lo que de cierta manera es verdad, a menos que la cantidad de funcionalidades
sea el parámetro que sufre. En todos los casos, usar recursos de baja calidad para
cumplir los tiempos de un proyecto no lleva al éxito general del proyecto.

Al igual que con el alcance, la calidad también debe ser una parte importante para el
proyecto.

En Agile, la funcionalidad o costo son los que usualmente sufren. El tiempo es

usualmente un factor menor debido a que las iteraciones continúan hasta que el
equipo/proyecto/cliente cree que el producto está listo para ir al mercado. Es más acerca
de continuamente sacar funcionalidades para que el proyecto pueda detenerse en
cualquier momento y aun así se pueda tener un producto terminado.
Los Aspectos Positivos de la Cascada
La planificación, diseño y arquitectura son más directos ya que el cliente y el
desarrollador están de acuerdo en lo que debe ser entregado en el ciclo de vida
temprano. Debido a que el alcance completo del trabajo es conocido, el proceso puede
medirse fácilmente.

Dependiendo en la fase del proyecto, todos los trabajadores no necesitan estar atrapados
en el mismo. Como ejemplo, los analistas de negocios (BAs) pueden continuar
trabajando en otras partes u otros proyectos completamente, luego de que los requisitos
hayan sido escritos y viceversa, los desarrolladores no necesitan estar involucrados
antes que los Bas sepan lo que necesita entregarse. En base a los requisitos de los BAs,
los probadores pueden preparar scripts de prueba mientras los desarrolladores están
codificando, etc.

Luego de la fase de requisitos ya no hay una fuerte necesidad para el cliente de estar
presente y, por lo tanto, puede enfocarse en cosas más pertinentes. El cliente
básicamente solo necesita involucrarse para revisiones, aprobaciones, etc.

Si se necesita integrar y ejecutar al mismo tiempo múltiples

sistemas/componentes/paquetes de software, un diseño temprano es usualmente
requerido. Esto se adapta perfectamente al enfoque escalonado de la Cascada.

Arquitectura, un intercambio usualmente olvidado o descuidado en el desarrollo

moderno de softwares, puede también ser diseñara mejor para escalabilidad, coherencia
general e integridad ya que hay un entendimiento más completo de todas las partes de
todo el sistema. El código no necesita ser reescrito una y otra vez, lo que algunas veces
sucede en el caso del Scrum, lo que a veces resulta en un sistema fragmentado.

Los recursos de los proyectos no son tan críticos, ya que la planificación y la

documentación ya ha sido realizada, por lo tanto, si un desarrollador abandona, es fácil
que otro tome su posición y continúe rápidamente con el plan.

Debido a que el método en Cascada requiere una planificación inicial, el software puede
ser lanzado rápidamente luego del desarrollo. Las estimaciones de horarios y
presupuestos pueden hacerse con mayor precisión, lo que definitivamente tiende a
complacer a los clientes.

Los Aspectos Negativos de la Cascada

Reunir y documentar los requisitos para que el cliente entienda lo que significan es muy
difícil. A menudo, los clientes se sienten intimidados por los detalles y los detalles
específicos deben ser proporcionados temprano en el proyecto antes de que se realice
algún proyecto. Los clientes usualmente no pueden visualizar una aplicación de un
documento de requisitos. Los esquemas y las maquetas ayudan, pero la mayoría de los
usuarios finales tienen dificultad de entender estos elementos con suficiente detalle para
visualizar claramente el producto final.
Este problema significa que un cliente puede no estar satisfecho con su producto
entregado una vez se haya finalizado. Dado que todas las entregas se basan en requisitos
documentados, es posible que el cliente no vea lo que se entregará hasta que se hayan
terminado grandes partes del proyecto. En ese momento, los cambios son complicados y
costosos.

La retroalimentación y las pruebas se diferirán hasta que se completen las partes más
importantes del proyecto. Esto significa que los problemas y las deficiencias pueden ser
más difíciles de cambiarse sin cantidades considerables de tiempo y esfuerzo.

Los Aspectos Positivos de Scrum

Dado que el cliente tiene oportunidades frecuentes y tempranas para ver el trabajo que
se está presentando, y pueden hacer decisiones y cambios a través del proyecto, el
cliente gana un sentido de propiedad. El cliente trabaja extensivamente y directamente
con el equipo del proyecto a través del mismo.

Scrum producirá una versión base simple más rápido que la Cascada, lo que algunas
veces es adecuado para la creación de prototipos.

El desarrollo está enfocado en el usuario y los cambios debido a problemas o

insuficiencias pueden ser remediados más rápido y a un menor costo. Debido a que el
diseño es flexible, el proyecto tendrá una vida más evolutiva y menos estricta. Esto tiene
un número de ventajas, especialmente en los ambientes del proyecto, donde las
necesidades de desarrollo deben poder responder a los cambios en los requisitos de
forma rápida y efectiva.

Scrum puede ser especialmente beneficioso en situaciones donde las metas finales de
los proyectos no estén claramente definidas. SI no es posible que el cliente proporcione
una meta clara en la parte temprana del proyecto, Scrum trabajará bien ya que esto
puede ser aclarado a medida que el proyecto avanza

Usualmente con Scrum hay más interacción y comunicación, lo que usualmente toma
prioridad en el diseño. Dado que las partes están más involucradas, es especialmente
propicio para entornos de trabajo en equipo. Diferentes desarrolladores trabajan en
diferentes módulos a través del proceso de desarrollo y luego trabajan para integrar
todos estos módulos en una pieza cohesiva de software al final del proyecto.

Los Aspectos Negativos de Scrum

No todos los clientes tienen ya sea el deseo o el tiempo de estar muy involucrados en el
proyecto. Scrum funciona mejor cuando todos los miembros del equipo están
completamente dedicados al proyecto. Por lo tanto, no es una buena idea tener menos
del 100% de los recursos dedicados para este tipo de proyecto.

Scrum se enfoca en entregas en tiempo real y cambios frecuentes en las prioridades, por
lo que algunos puntos pueden no ser completados dentro del marco de tiempo
determinado para el proyecto. Puede que se necesiten sprints adicionales para completar
las características, lo que por supuesto se añade al costo total. Además, el alto grado de
participación del cliente usualmente lleva a peticiones adicionales de características a
través del proyecto, extendiendo el tiempo necesario para completarlo.

Los clientes usualmente tienen dificultades para mantenerse al día con la rápida
iteración y ciclos de pruebas del Scrum. Esto puede poner el proyecto en riesgo ya que,
mientras más tiempo pasen los desarrolladores sin una retroalimentación, más difícil
será recuperar si no están desarrollando exactamente lo que el cliente espera.

Debido a que Scrum es altamente flexible y no tiene la estructura del método en

Cascada, los proyectos de Scrum tienden a ser más difíciles de predecir, desde tiempos
de entrega hasta presupuestos. Sin un plan concreto y un conjunto completo de
requisitos, todo se mantiene un poco vago.

El trabajo en equipo en Scrum es más fácil de manejar cuando todos los miembros del
equipo se encuentran localizados en el mismo espacio físico. Además, la colaboración
intensa y los requisitos menos complejos resultan en problemas catastróficos si algún
miembro del equipo deja el proyecto.

Scrum tiene menos énfasis en entender el sistema finalizado como un todo en la parte
temprana del proyecto, lo que puede llevar a una reducción de la calidad y desempeño
general del sistema. Esto es especialmente cierto para implementaciones a gran escala o
con sistemas que incluyen un gran nivel de puntos de integración.

Este método de desarrollo puede ser bastante lento, mucho más que el desarrollo en
Cascada. Hay muchos códigos que se deben reescribir debido a cambios de requisitos y
problemas en la funcionalidad. A menudo, los requisitos no son claros al principio, lo
que puede resultar en una arquitectura poco óptima que no es lo suficientemente flexible
para alcanzar los requisitos finales. A menudo, se pasa mucho tiempo puliendo detalles
para los usuarios antes de que comience la programación.

Como el proyecto final no tiene un plan definitivo, el producto terminado puede ser
muy diferente a lo que se pretendía inicialmente. Esto además se relaciona con la
incapacidad de dar una fecha máxima al momento que se firma un contrato.

Cuando Seleccionar la Cascada Sobre Scrum

Algunas cosas para considerar:

 Si el tamaño del proyecto y la complejidad son grandes, ejemplo, una gran

migración de sistemas involucrando sistemas diferentes.

 El cliente no se puede comprometer a una extensa participación.

 Las integraciones de sistemas externos son numerosas, con muchos puntos

(incluyendo los sistemas heredados).

 El presupuesto y el calendario son fijos o difíciles de modificar.

 Se requiere el proyecto completo antes del lanzamiento.

  Los desarrolladores necesitan orientación, gestión y supervisión.

 El cliente no espera cambios mayores en el ámbito del proyecto

 EL cliente sabe exactamente lo que quiere.

Cuando Seleccionar Scrum Sobre la Cascada

Algunas cosas que considerar:

 El tamaño y la complejidad del proyecto son pequeños (puede utilizarse en

proyectos grandes en ciertas circunstancias). Ejemplo, tiendas online pequeñas,
sitios web, desarrollo de apps.

 El cliente está disponible frecuentemente durante la duración del proyecto.

 Las integraciones con sistemas externos son simples o no necesarias.

 El presupuesto y el horario son flexibles a los cambios y son bienvenidos por los
clientes.

 Se requiere un prototipado y despliegue rápido. El proyecto/producto puede ser

lanzado sin tener todas las características.

 No hay una imagen clara de cómo debe ser el producto final.

 Los desarrolladores son habilidosos y se adaptan fácilmente sin la necesidad de

ser supervisados

 Cuando el producto está destinado para una industria con estándares en

constante cambio.
¿Cuál método es mejor?
A medida que agile ha aumentado su popularidad y las organizaciones de todo el mundo
están luchando para adoptar este paradigma, principalmente en la forma de Scrum,
también se ha demostrado que hay momentos en los que los proyectos toman más
tiempo son más costosos y tienen menos características al seleccionar Agile sobre el
modelo en Cascada.

Al llegar a este punto, podemos decir que ni Agile con Scrum ni el método de Cascada
son inherentemente uno mejor que el otro. Dicho eso, cada método tiene sus méritos. La
cascada tiende a ser mejor para proyectos que no tengan muchos cambios durante el
proceso de desarrollo y que no aceptan errores. Scrum tiende a ser una opción mejor
para proyectos más pequeños donde los cambios son ya sea rápidos o fáciles de
implementar durante el proceso o con proyectos que puedan ser modularizados.

En scrum, la expansión del alcance no es un problema, porque se trata de obtener

funcionalidades, en el orden correcto y en base a las necesidades del negocio, Pero, en
práctica, Scrum puede llegar a ser desarticulado y sin dirección, una excusa para la
ausencia de procesos internos y caos organizacional. A menudo se asume que Scrum no
necesita una visión estratégica, lo que es un error fatal.

Si los equipos del proyecto están localizados en diferentes lugares y zonas horarias, la
coordinación del trabajo necesita ser relativamente detallada para evitar confusiones y
pérdidas de tiempo. En este caso, el método de Cascada es el más apropiado, ofreciendo
entregables, hitos y dependencias claras. Cuando los proyectos requieren conocimientos
especializados únicos y estos recursos no están disponibles inmediatamente, una buena
planificación es requerida. Si esto es costoso o difícil de organizar, es importante
asegurarse que el recurso se utilice plenamente durante su uso programado. Para esto, la
cascada es un mejor enfoque, ya que la planificación es mucho más confiable para
asegurar una máxima eficiencia de uso.

Mientras que cada modelo tiene sus fortalezas y defectos, los conceptos erróneos reinan
sobre ambos. Es una desorganización debido a la falta de disciplina o una complejidad
innecesaria arraigada en una creencia irracional de que uno puede eliminar el riesgo.
Las empresas eficientes y maduras entienden cuándo aplicar cualquiera de estos
métodos. En práctica, las organizaciones con ciclos de desarrollo exitosos usualmente
emplean un enfoque híbrido, tomando un poco de cada metodología.

Lo mejor de ambos mundos

El enfoque híbrido puede ser concebido con un diseño tomado de la metodología de
Cascada, inicialmente, pero luego cambiando a Scrum como método de producción.
Esto le dará una vista general del proyecto completo, pero permitirá el desarrollo con
retroalimentaciones constantes basadas en los requisitos de los usuarios. Esto permite
que un equipo gane conocimientos sobre el panorama general con un análisis y diseño
preliminar, al tiempo que permite cambios incrementales durante las fases de desarrollo
e implementación. El equipo puede ofrecer una funcionalidad completa, pero enfocada
que comprende una pequeña parte del conjunto. Esto mantendrá al negocio ocupado y
responsivo, mientras que, al mismo tiempo, asegura que el BA y los equipos de prueba
tengan una mejor conexión con el progreso del proyecto. Esto asegura que una
planificación apropiada puede hacerse y se pueden establecer estimaciones realistas para
todo el proyecto.

Se requiere la adopción de un enfoque general de arquitectura para minimizar las

brechas de los requisitos. Los talleres de soluciones deben ser llevados a cabo con todas
las partes interesadas, como Negocios, marketing, IT, para asegurar la congruencia en
los requisitos actuales y la solución final. Los controles de cambios y riesgos deben
estar estrictamente aplicados, con el fin de controlar y manejar la influencia del alcance.
Los cambios mayores deben ser tomados a una junta de revisión con los interesados
principales, especialmente para proyectos grandes o de transformación.

Y, finalmente, ¡el patrocinio ejecutivo debe ser fuerte para que todos, hasta los
proyectos tengan éxito!

Realmente, cuando se trata de escoger un método, no hay opción correcta o equivocada.

Usted solo necesita entender cuál método es el más adecuado para su proyecto y sus
necesidades, ya sea el de Cascada, el Scrum o un enfoque híbrido.

Diferentes situaciones obviamente requerirán diferentes enfoques. Pero, una cosa que es
cierta y es que el uso de cualquiera de las metodologías aumentará enormemente el
éxito a comparación de no seguir ningún proceso o simplemente ir a ad hoc.