![](\"https:\/\/www.cybermedian.com\/es\/wp-content\/uploads\/sites\/8\/2022\/02\/0BL2OV4hEYw-jwg3u.png\")
1. Requisitos<\/strong><\/p>\n Si est\u00e1 involucrado en el desarrollo de software o en cualquier tipo de equipo de creaci\u00f3n de proyectos, le gustar\u00eda conocer el contexto comercial de lo que est\u00e1 tratando de crear: desea definir qu\u00e9 tipo de problemas est\u00e1 tratando de resolver y c\u00f3mo reaccionar\u00eda la gente a su producto terminado.\u00a0Despu\u00e9s de definir todos estos “requisitos”, tiene la entrada que necesita para pasar al siguiente paso.<\/p>\n 2. Dise\u00f1o<\/strong><\/p>\n Este paso se compone de todos los pasos que necesita para satisfacer todos los requisitos que ha determinado anteriormente.\u00a0En el desarrollo de software, esta es la parte en la que define toda la arquitectura de software y hardware, el lenguaje de programaci\u00f3n, el almacenamiento de datos, etc. Esta es tambi\u00e9n la parte en la que determina c\u00f3mo el proyecto ser\u00eda \u00fatil para su usuario final.<\/p>\n 3. Implementaci\u00f3n<\/strong><\/p>\n En este paso, comienza a construir lo que ha dise\u00f1ado en su plan.\u00a0Esta parte del m\u00e9todo Waterfall est\u00e1 dedicada a cumplir con los est\u00e1ndares que ha establecido en los pasos anteriores.\u00a0Esta es la parte donde la gente del equipo de desarrollo entra y hace que sucedan todas las cosas discutidas en los pasos anteriores.<\/p>\n 4. Verificaci\u00f3n<\/strong><\/p>\n Esta es la parte del m\u00e9todo donde la gente de control de calidad ingresa para asegurarse de que el equipo de desarrollo no cometi\u00f3 ning\u00fan error.\u00a0Esta tambi\u00e9n es probablemente la parte en la que las personas se dan cuenta de lo que est\u00e1 funcionando o no en su plan.<\/p>\n Tenga en cuenta que<\/strong><\/p>\n Cuando los desarrolladores del proyecto satisfacen todo, el cliente o el usuario final entra y toma la decisi\u00f3n final si el proyecto est\u00e1 listo para ser lanzado.<\/p>\n El m\u00e9todo Waterfall destaca que cuando algo sale mal en una etapa en particular, las personas pueden volver a la etapa anterior para ver qu\u00e9 sali\u00f3 mal.\u00a0Por ejemplo, si hay un problema en la implementaci\u00f3n del plan y las personas saben que simplemente siguieron el plan que se les entreg\u00f3, los gerentes revisan su plan y hacen sus revisiones a partir de ah\u00ed.<\/p>\n Es posible que los clientes no sepan exactamente cu\u00e1les son sus requisitos antes de ver el software en funcionamiento y, por lo tanto, cambien sus requisitos, lo que lleva al redise\u00f1o, nuevo desarrollo y nuevas pruebas, y mayores costos.<\/p>\n Es posible que los desarrolladores no sean conscientes de las dificultades futuras al dise\u00f1ar un nuevo producto o caracter\u00edstica de software, en cuyo caso es mejor revisar el dise\u00f1o que persistir en un dise\u00f1o que no tiene en cuenta las restricciones, los requisitos o los problemas reci\u00e9n descubiertos.<\/p>\n Por lo tanto, no hay garant\u00eda de que los requisitos que la organizaci\u00f3n ha pensado realmente funcionen.\u00a0A partir de aqu\u00ed, te dar\u00e1s cuenta de que el modelo Waterfall tiene los siguientes problemas:<\/p>\n 1.\u00a0\u00a0La gente sigue ciegamente los planes.<\/strong><\/p>\n En el m\u00e9todo tradicional, las personas prestan m\u00e1s atenci\u00f3n a c\u00f3mo suceder\u00e1n las cosas en el momento adecuado sin tener en cuenta si las cosas realmente est\u00e1n encajando.\u00a0Si bien la planificaci\u00f3n es importante, tambi\u00e9n es importante que los desarrolladores y los verificadores de calidad entiendan c\u00f3mo deben suceder las cosas, especialmente con el cliente o el usuario final.\u00a0Tambi\u00e9n es importante que todas las personas involucradas en el proyecto puedan decir de inmediato c\u00f3mo un paso en particular en el cumplimiento del proyecto puede fallar sin tener que esperar a la etapa de prueba.<\/p>\n 2.\u00a0\u00a0El proceso secuencial y los cambios se vuelven costosos<\/strong><\/p>\n Este enfoque no tiene en cuenta el cambio de los requisitos definidos a medida que avanza el proyecto.\u00a0Por lo tanto, existe un gran potencial de que el software no satisfaga completamente los requisitos del usuario, sea ineficiente y tenga una funcionalidad deficiente.<\/p>\n Es inadecuado ya que los desarrolladores no pueden simplemente regresar y cambiar algo en una fase anterior a medida que cambian los requisitos de los consumidores, sino que el desarrollador tiene que volver a donde el requisito debe cambiar y comenzar esa fase de nuevo.\u00a0Hasta que no se completa esa fase, no puede pasar a la siguiente fase.<\/p>\n 3.\u00a0\u00a0Los usuarios finales no saben lo que quieren.<\/strong><\/p>\n La mayor\u00eda de las veces, la mente de los usuarios finales cambia constantemente y la mayor\u00eda de las personas tienen una idea vaga de los requisitos de su software y es a medida que se desarrolla el software que especifican sus requisitos.<\/p>\n Cuando llega el momento de entregar el producto terminado a un cliente, es probable que no le guste c\u00f3mo qued\u00f3, a pesar de haber dicho deliberadamente lo contrario durante las etapas iniciales.\u00a0Es f\u00e1cil para los clientes y usuarios finales cambiar lo que quieren con el tiempo.\u00a0El sistema Waterfall a\u00fan no tiene una forma de resolver eso, sin tener que revisar los planes y rehacer todo el proyecto por completo.<\/p>\n 4.\u00a0\u00a0Las pruebas de calidad pueden sufrir.<\/strong><\/p>\n Es imposible predecir con precisi\u00f3n los resultados de un proyecto, y cuando todo el equipo tiene poco tiempo, es posible acortar la etapa de prueba para cumplir con la fecha l\u00edmite.<\/p>\n 5.\u00a0\u00a0Nunca sabr\u00e1s en qu\u00e9 escenario est\u00e1s realmente.<\/strong><\/p>\n Dado que el producto que est\u00e1 tratando de crear no se producir\u00e1 hasta el final, no est\u00e1 realmente seguro de si todav\u00eda est\u00e1 en la etapa de planificaci\u00f3n o si ya est\u00e1 en desarrollo.\u00a0Eso significa que tambi\u00e9n es probable que pase m\u00e1s tiempo en un escenario de lo que esperaba debido a esta poca visibilidad.<\/p>\n Al final, el m\u00e9todo Waterfall puede ser demasiado arriesgado ya que es demasiado r\u00edgido.\u00a0Para que pueda producir un producto que funcione y que sea lo suficientemente flexible como para ayudarlo a descubrir qu\u00e9 funciona o no.<\/p>\n En realidad, es posible que los clientes no sepan cu\u00e1les son sus necesidades hasta que vean el software en funcionamiento, por lo que cambiar sus requisitos conlleva un redise\u00f1o, un nuevo desarrollo y pruebas, y un aumento de los costes. Los desarrolladores pueden dise\u00f1ar un nuevo producto o funci\u00f3n de software sin darse cuenta de las dificultades que se avecinan, en cuyo caso es mejor modificar el dise\u00f1o que insistir en un dise\u00f1o que no tenga en cuenta las limitaciones, requisitos o problemas reci\u00e9n descubiertos. Como resultado, no hay garant\u00eda de que los requisitos que la organizaci\u00f3n tiene en mente funcionen realmente.<\/p>\n","protected":false},"author":3,"featured_media":6980,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_yoast_wpseo_title":"","_yoast_wpseo_metadesc":"","footnotes":""},"categories":[5],"tags":[],"class_list":["post-6977","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-software-engineering"],"yoast_head":"\n\u00bfCu\u00e1l es el problema de la cascada?<\/span><\/h3>\n
![](\"https:\/\/www.cybermedian.com\/es\/wp-content\/uploads\/sites\/8\/2022\/02\/05pAJlKyeehGiGDPP.png\")
Recursos Relacionados<\/span><\/h3>\n
\n