¿Cuáles son las alternativas al modelo Waterfall

Question

? ¿Puede por favor ofrecer una metodología que alivie las desventajas del modelo de cascada?

Answer 1

Éstos son algunos enlaces sobre el modelo cascada:

http://www.cs.odu.edu/~zeil/cs451/Lectures/01overview/process2/process2_htsu2.html

http://www.buzzle.com/editorials/3-13-2005-67039.asp

Answer 2

El problema de la cascada es que se compone de etapas monolíticos, cada edificio en la etapa anterior. Entonces, el código se desarrolla en un solo fragmento después de que se haya diseñado todo el sistema, que a su vez sucedió después de que todos los requisitos se hayan recopilado y firmado.

Esto es un problema porque cualquier cambio tiene que ser ratificado por un procedimiento complejo y ondulado a través de todas las etapas. Pero la lección de la historia es: el cambio sucede. Los requisitos están siempre incompletos, o mal especificados o simplemente desactualizados en el momento en que llegamos a la codificación. Con demasiada frecuencia, el diseño y la construcción se realizan sobre la base de supuestos que se anulan cuando el sistema llega a la UAT. Esto lleva a frenéticos reelaboraciones y desviaciones.

La verdad es que no muchos clientes son buenos en el tipo de pensamiento abstracto que se requiere para imaginar un sistema de software de software en funcionamiento. Y demasiados profesionales de TI carecen de la experiencia necesaria para comprender la lógica empresarial. Waterfall se niega a aceptar esta verdad.

La única especificación de requisito honesto es "Lo sabré cuando lo vea". Por lo tanto, es crucial obtener software de trabajo frente a usuarios reales tan pronto como sea posible. Cualquier metodología que se centre en entregar software de trabajo de forma incremental en iteraciones cortas "aliviará las desventajas del modelo de cascada".

Originalmente era RAD o DSDM. Luego, XP toque el banner. Ahora está Agile y cosas relacionadas como Scrum y Kanban.

¿Por qué la gente persiste con el método de Waterfall?

Hay una percepción común de que Agile es solo una tapadera para que los hackers vaqueros abandonen todo el proceso aburrido y continúen con lo que más les gusta: escribir código. La marca de la "Programación Extrema" definitivamente alienta este pensamiento, y, seamos honestos, no es una acusación infundada. Es decir, algunos codificadores pretenden ser ágiles como una excusa para no planificar, diseñar o documentar. Esto no refleja la práctica real de Agile, que requiere el mismo rigor que cualquier otra metodología.

También Agile requiere una mayor dedicación de tiempo del personal del cliente, que muchas organizaciones son reacias a aceptar. Además, las personas que pagan la factura pueden no estar dispuestas a capacitar a su personal subalterno para tomar decisiones. Hay una distinción importante entre Cliente y Usuario.

Cuando se trata de la subcontratación, el modelo de cascada proporciona un marco sencillo para el cumplimiento de los pagos por etapas. De hecho, el aspecto contractual puede ser más fuerte: en la UE, Waterfall tiene el mandato para todos los proyectos valorados en 100 millones de euros o más.

Finalmente, hay proyectos en los que Waterfall funciona bien. Estos proyectos tienen dominios de conocimiento que son estables y bien entendidos tanto por los clientes como por los desarrolladores.

última palabra

A pesar de sus defectos Cascada ha entregado muchos proyectos con éxito. Esto se debe a que el trabajo duro, la aptitud y la integridad son más importantes que la metodología.

Answer 3

El modelo de cascada fue documentado en 1970 por un Dr. Winston Royce en un documento titulado 'Administración del desarrollo de grandes sistemas de software'. Básicamente esbozando sus ideas sobre el desarrollo secuencial. Su idea era que el software podría producirse de forma similar a un automóvil, donde el vehículo se ensambla en fases secuenciales/lineales.

Este enfoque lineal realmente no permite cambios en una pieza de software una vez que comienza. No existe una relación estrecha con el usuario/cliente final por lo que es más difícil describir posibles áreas problemáticas.

Vale la pena señalar que algunas fases del modelo de cascada permiten 'salpicaduras' por lo que hay suficiente tiempo en el período de desarrollo para retroceder y realizar pequeños cambios. Las limitaciones de tiempo y la cantidad de trabajo involucrado y los presupuestos en realidad no permiten mucho cambio, si es que se hará con este modelo.

El modelo de cascada es antiguo, a medida que pasa el tiempo los paradigmas de software cambian. La programación orientada a objetos es popular, en ese entonces apenas estaba viva. Mediante el uso del modelo de cascada es obvio que los defectos han sido detectados y esto ha llevado a las metodologías de desarrollo alternativo.

Ok, entonces ahora para las alternativas. El modelo incremental es descrito por Alistair Cockburn (2008) como una estrategia de preparación y programación en la que varias partes se desarrollan en diferentes momentos o tasas, y se integran al completar esa parte específica.

Básicamente incrementales se parece mucho a esto:

Analysis->Design->Code->Test 
    Analysis->Design->Code->Test 
    Analysis->Design->Code->Test 

serie de beneficios incluye ciclo de vida del ser flexible y permitir el cambio desde el principio. El software de trabajo o más bien las piezas se generan rápidamente y al principio. El código producido es más temprano para probar y administrar debido a las pequeñas iteraciones de progreso. No todos los requisitos del sistema se recopilan por adelantado, solo un bosquejo. Esto permite un inicio rápido, sin embargo, podría ser una desventaja en algunos sistemas, ya que es posible que se pierdan cosas como la arquitectura del sistema.

Iterative, por otro lado, permite que las partes del sistema se vuelvan a trabajar y revisen para mejorar el sistema. El tiempo se aparta para permitir esto. Iterativo no comienza con una especificación completa de requisitos. El desarrollo se realiza al especificar e implementar solo una parte del software. El software se revisa para identificar otros requisitos. Este es más un enfoque de top down. Las desventajas con esta metodología son asegurarse de que todas las iteraciones sean compatibles. A medida que se aprueba cada nueva iteración, los desarrolladores pueden emplear una técnica conocida como ingeniería inversa, que es un procedimiento sistemático de revisión y verificación para asegurarse de que cada nueva iteración sea compatible con las anteriores. Un beneficio importante con las iteraciones constantes es que el cliente se mantiene en el ciclo y el producto final debe cumplir con los requisitos.

Iterative approach diagram.

Otras metodologías incluyen Prototipos. Evolutivo y desechable Estos también se consideran más como un enfoque de arriba hacia abajo. Ambos procesos se toman prestados de la ingeniería. En la ingeniería, es común construir modelos a escala de los objetos que se construirán.La construcción de modelos le permite al ingeniero probar ciertos aspectos del diseño. La metodología de desarrollo de prototipos de software proporciona la misma ideología. Los prototipos no se ven como una metodología de desarrollo independiente y completa, sino más bien como un enfoque para manejar porciones seleccionadas de una metodología de desarrollo más grande y tradicional.

Prototipado a la deriva - El prototipado a la deriva no preserva el prototipo que se ha desarrollado. En la creación de prototipos desechables, nunca hay ninguna intención de convertir el prototipo en un sistema funcional. En cambio, el prototipo se desarrolla rápidamente para demostrar algún aspecto del diseño de un sistema que no está claro. También se puede desarrollar para ayudar a los usuarios o clientes a decidir entre diferentes características o características de la interfaz. Una vez que se han abordado los problemas o la incertidumbre, el prototipo puede "desecharse" y los principios aprendidos se utilizan en el diseño y la documentación del producto real.

Prototipos evolutiva - En prototipado evolutivo que comienza modelando partes del sistema de destino y si el proceso de creación de prototipos es el éxito que evolucione el resto del sistema a partir de esas partes. Un aspecto clave de este enfoque es que el prototipo se convierte en el sistema de producción real. Este proceso permite que las partes difíciles del sistema se modelen con éxito en prototipos y se aborden desde el principio en un proyecto.

Otras áreas que investiguen incluirán Agile-> SCRUM, programación extrema, programación, etc. En combinación

intentado que sea corto, pero la gente escribe libros sobre este tipo de cosas y no hay mucho que discutir.

podría valer la pena echar un vistazo a: Incremental and Iterative

Answer 4

La alternativa al método de cascada está "haciendo de la manera correcta".

La cascada parece tener sentido si se encuentra en una línea de montaje en el piso de la fábrica. Pero nunca lo he visto funcionar como parte del proceso de diseño ... y el desarrollo de sofware es TODO un proceso de diseño. Y entonces el método de la cascada nunca funciona realmente en el sentido de que no ayuda a facilitar la creación de productos de alta calidad, sino que se centra en el proceso. El proceso puede ser excelente, pero ¿cuál es el punto si el producto que produce es de segunda?

Answer 5

Desde lo alto de la cabeza, puedo pensar en formas de paliar las deficiencias del modelo de cascada:

• Hacer que el concentrado de codificador en la automatización del proceso en sí. Automatice las transiciones entre un paso y otro, de modo que los cambios fluyan más o menos automáticamente.
• Haga que el proceso sea más bidireccional. Una característica principal en el modelo de cascada es que los cambios fluyen de arriba hacia abajo. Este es un proceso unidireccional, y eso es parte del problema.

Otra cosa que ayudaría es (como alguien mencionó en una respuesta anterior) es que el desarrollador comprenda mejor la lógica de negocio involucrada, y de lo que quiere el cliente, y para que el cliente gane conocimiento sobre las características del proceso de desarrollo.

Answer 6

Kanban y Scrum son dos de las alternativas más utilizadas a Waterfall. Traté de dar una buena visión general y una comparación de los diferentes SDLC approaches.

Waterfall depende en gran medida de las fases monolíticas masivas mencionadas por APC.Este es un gran punto débil porque tratar de determinar el producto final desde el principio es una tarea infructuosa.

Kanban es ligeramente vaquero, pero me parece que si lo combinas con plataformas, ciertamente todavía tiene su lugar.

Scrum es ideal para ejercer presión sobre el equipo y obtener la propiedad de los boletos. He descubierto que la mayoría de los lugares han estado yendo con este, pero la caída es que algunas personas se vuelcan por la borda con reuniones para todo. Reuniones de planificación de Sprint, reuniones de inicio de sprint, reuniones diarias stand up que duran 1 hora con más de 20 personas presentes, reuniones de demostración, y finalmente la autopsia.

Recuerda que ágil es tan bueno como lo haces y puedes derribar fácilmente cualquier metodología si te vuelves loco con reuniones desenfrenadas que no agregan valor. Manténgalo tan delgado como pueda sin que sea caótico.