A modelo de cascada , el modelo de seis fases es un modelo en cascada. En otras palabras, las etapas ocurren secuencialmente. Así como nadar contra la corriente contra una cascada es imposible, la técnica de la cascada pura impide volver a una fase una vez finalizada.
No es ideal decidir cambiar el diseño durante la fase de implementación, deteniendo así la implementación. El enfoque en cascada suele ser menos adecuado para proyectos de desarrollo de software por diversas razones.
- El desarrollo de software es un esfuerzo artístico; es prácticamente difícil anticipar todas las necesidades (funcionalidades).
- Calcular el tiempo necesario para desarrollar una función es muy complicado.
- A lo largo del ciclo de vida del proyecto, los usuarios deberían poder probar todos los resultados intermedios.
El desarrollo de software es un esfuerzo artístico #
Para los no iniciados, el desarrollo de software parece tener más que ver con la ingeniería que con la invención. Sin embargo, se relaciona de varias formas con la invención. En el proceso de creación, uno nunca sabe exactamente qué ocurrirá.
Los diseñadores y programadores responsables del desarrollo de nuevo software deben encontrar respuestas a los problemas que se les presentan. Independientemente de las muchas técnicas y prescripciones para el trabajo, la creación de códigos informáticos sigue siendo en su mayor parte desconocida y, por lo tanto, impredecible. Los programadores pueden seleccionar entre millones de soluciones escritas en docenas de lenguajes de programación y que operan en miles de diferentes combinaciones de hardware y plataformas de software. Si bien esta flexibilidad tiene muchos beneficios, también hace que el proyecto sea más desafiante de administrar que los más convencionales. gestión de proyectos (como proyectos de construcción o edificación).
Configuración de implementación #
El enfoque en cascada requiere que los requisitos se definan como consecuencia de la fase de definición del proyecto . Idealmente, debería producirse una mínima desviación adicional de estos criterios durante el resto del proyecto. El enfoque en cascada del desarrollo de software requiere un compromiso inicial de esfuerzo significativo en el análisis de la funcionalidad requerida (requisitos). Esto da como resultado un diseño funcional (consulte I para obtener información adicional sobre diseños funcionales). El arquitecto de software crea un diseño técnico durante todo el proceso de diseño, utilizando el diseño funcional como referencia. Además, el diseño técnico proporciona instrucciones sobre cómo ejecutar la funcionalidad requerida.
Si bien esto puede parecer un problema simple, considere el siguiente escenario. Se está desarrollando un nuevo vehículo como parte de un proyecto. Como conductor de automóvil activo, tiene la tarea de desarrollar las necesidades automotrices. Consulta con otros conductores y compila una lista exhaustiva:
- El coche debe tener capacidad para cuatro personas;
- El automóvil debe tener un volante en la parte delantera del lado izquierdo del conductor; • El automóvil debe tener un pedal de freno, un acelerador y un freno de mano.
- Los faros del automóvil deben ser blancos y las luces traseras deben ser rojas. (obviamente, la lista real sería enorme)
Diseño y modelado #
Los diseñadores crean un nuevo diseño usando su lista como guía, que luego se construye muchos meses después. A medida que avanza por la calle, ve que un vehículo se ha detenido. ¡Se da cuenta de que omitió las luces de freno de su lista! Se comunica rápidamente con el ingeniero del fabricante del automóvil, que casi estalla en respuesta a su llamada. Afirmas que es un ajuste menor. Sin embargo, es una catástrofe para los fabricantes de automóviles. Los automóviles ya fabricados deben desmantelarse por completo, los cables de los pedales de freno a la parte trasera deben extenderse, la parte trasera del vehículo debe ser totalmente rediseñada para adaptarse a las luces de freno y las escotillas de maletero ya fabricadas deben desecharse, y la lista continúa.
Si bien el escenario anterior parece ridículo, representa una ocurrencia casi diaria en el desarrollo de software. Los programadores suponen erróneamente que los clientes, clientes o usuarios del producto que se está creando entienden exactamente lo que quieren. Los clientes creen incorrectamente que los desarrolladores de software pueden crear (y modificar) cualquier cosa en el menor tiempo posible. Ésta es la principal causa de disputa entre consumidores y desarrolladores de software.
