Introducción al modelo de cascada
Originado de las industrias de construcción y fabricación, es un entorno físico altamente estructurado destinado a procesos de diseño y desarrollo. El modelo de cascada también se conoce como el modelo de ciclo de vida de desarrollo de software. Fue el primer modelo de proceso introducido como el modelo de ciclo de vida lineal-secuencial. El modelo de cascada simplemente le dice al fenómeno que complete una fase por completo antes de comenzar la nueva fase de desarrollo para que no haya superposición de fases. En el campo del desarrollo de software, el modelo en cascada se utilizó por primera vez como el enfoque SDLC. Para trabajar en el modelo de cascada necesitamos comprender su enfoque de aplicación basado en factores internos y externos que pueden ser los siguientes:
- No hay requisitos ambiguos en la aplicación.
- Estabilidad de la definición del producto.
- Es tecnología entendida
- No es dinamico
- Se dispone de grandes recursos con la experiencia adecuada para respaldar el producto.
- Vey proyecto de corta duración
- El buen documento, requisitos claros y fijos.
Para comenzar con la historia del modelo de cascada, me gustaría decir que la primera muestra del modelo de cascada fue presentada en el año 1970 por Winston w Royce en un artículo. Desde entonces, el modelo en cascada establece que uno debe cambiar a otra fase solo cuando las fases anteriores se prueban, revisan y verifican por completo. Se enfatiza en la progresión lógica de los pasos de fase. Su funcionalidad es similar a los flujos de agua sobre el borde del acantilado. Este enfoque de desarrollo de software ha recibido el nombre de cascada porque se desarrolla sistemáticamente de una fase a otra de manera descendente. Desde el momento en que Winston W. Royce lo publicó por primera vez en 1970, el modelo en cascada se ha utilizado ampliamente en el campo del desarrollo de software. En el ciclo del proceso de desarrollo de software, los modelos de programación se utilizan para planificar las distintas etapas del desarrollo de una aplicación. Uno de esos modelos es el modelo en cascada.
Modelo de Fases de Cascada
Ahora hablemos sobre las fases del modelo de cascada, que se pueden explicar claramente a través de esta infografía de demostración.
Con la infografía anterior, podemos entender que el modelo de cascada tiene un total de 7 fases de ciclo de diseño y desarrollo de software, que son las siguientes:
- Requisitos
- Análisis
- Diseño
- Codificación / implementación
- Pruebas
- Operación / despliegue
- Mantenimiento
Por lo tanto, podemos ver que el modelo de cascada funciona en la jerarquía de arriba a abajo con una fase completada con verificaciones completas y luego cambiando a otra fase que incluye procesos de fase como Concepción, Iniciación, Análisis, Diseño, Construcción, Pruebas, Producción / Implementación y Mantenimiento. Para obtener un conocimiento más breve sobre el modelo de cascada, necesitamos comprender todos sus procesos en profundidad con su modelo de trabajo. Hay una fase básica de prerrequisito que debe entenderse antes de comenzar las fases profundas del conocimiento. Se trata del estudio de viabilidad del producto de software. Se ocupa de los aspectos financieros y técnicos de los requisitos del proyecto. Esta fase se ocupa de la corrección de las medidas en función de los beneficios y los inconvenientes analizados. Por lo tanto, se elige la mejor solución.
- Requisitos: como palabras específicas, necesitamos saber y comprender lo que tenemos que diseñar, lo que tenemos que desarrollar, sus procesos, cuál será su funcionalidad, etc. Proporciona material de entrada para el producto que se está fabricando y, por lo tanto, para el próximo producto. es estudiado, finalizado y marcado. También nos brinda la extensión para decidir los requisitos de hardware o software del producto que se diseñarán, desarrollarán y capturarán en todas las fases.
- Análisis: resulta en el diseño de modelos, esquemas y reglas de negocio. No solo este requisito se divide en dos partes:
- Recopilación y análisis de requisitos: Primero, toda la información y los requisitos para el desarrollo del producto se recopilan del cliente y luego se procesan para su análisis. El papel principal de esta parte es erradicar la incompletitud e inconsistencias relacionadas con el desarrollo de productos de software.
- Especificación de requisitos: luego, los requisitos analizados anteriormente se documentan en un documento SRS (especificación de requisitos de software). Sirve como un camino entre el cliente y el equipo de desarrollo de SRS. Cualquier disputa en el futuro se gestiona y resuelve solo a través de esta documentación de SRS.
- Diseño: Una vez que se completa y verifica la primera fase, es la siguiente fase más importante que se debe estudiar, ya que se utiliza para el diseño del sistema. Ayuda a especificar los requisitos de software y hardware para el diseño del producto. También ayuda en la arquitectura general para el diseño del sistema. Por lo tanto, la especificación de requisitos se estudia y verifica principalmente en esta fase. También es útil para transformar el documento SRS en diseño funcional y desarrollo del producto de software. Entonces podemos decir que en la fase de diseño, uno está haciendo la arquitectura general para el proyecto de desarrollo de software.
- Implementación: con el diseño del sistema totalmente verificado, la fase de implementación viene en la fila. En esta fase, se toman las entradas del diseño del sistema, y primero se desarrolla en pequeños programas conocidos como unidades, que se prueban e implementan en la próxima fase. Cada unidad en la fase de implementación se somete a desarrollo y se prueba su funcionalidad completa, que también se conoce como prueba de unidad. Entonces, en esta fase, el diseño del sistema se convierte en código fuente con módulos de programas totalmente funcionales. Incluye desarrollo, prueba e integración del software.
- Integración y prueba: cada diseño de unidad y desarrollado en las fases anteriores se incorpora desde la fase de implementación que se integra en un módulo o sistema para una prueba diferente como prueba de carga, prueba de plomo, etc. después de probar cada unidad. El entorno de prueba se somete a una constante verificación de software para determinar si hay algún flujo o error en el diseño o el código. Las pruebas se realizan para mantener la estabilidad y la viabilidad del software para que el cliente no se enfrente a ningún problema o error durante su producción. Entonces, en esta fase después de la implementación, todo el sistema se prueba a fondo para detectar fallas y fallas. Las pruebas del sistema consisten en tres tipos diferentes de actividades que se pueden explicar a continuación:
- Prueba alfa (α): es la prueba realizada por el equipo de desarrollo.
- Prueba Beta (β): es la prueba realizada por el equipo amigable de clientes y usuarios.
- Prueba de aceptación: se realiza después de las pruebas alfa y beta. Básicamente, esta prueba se realiza después de la entrega por parte de los clientes. Después de las pruebas realizadas por el cliente, se toma la decisión de si este software es aceptable o rechazarlo. Entonces, en esta fase, básicamente se realiza la depuración de errores.
- Implementación del sistema / Operaciones: una vez que se realizan las pruebas no funcionales, funcionales, alfa y beta, el producto de software se implementa en el sistema del usuario o cliente o se lanza al mercado. La fase de implementación incluye instalación, migración y soporte del sistema completo para el entorno del usuario o cliente.
- Mantenimiento: es la última pero la fase más importante en el modelo de flujo de trabajo en cascada. Este paso viene justo después de la instalación e incluye la modificación adecuada del producto o sistema, o para mejorar, cambiar o modificar atributos relacionados con problemas de rendimiento relacionados con el sistema. su función principal es mejorar el rendimiento del sistema con el resultado de máxima precisión de la salida del software. Estos cambios generados durante la fase de mantenimiento están relacionados principalmente con los cambios iniciados por el cliente o los usuarios después de la fase de instalación y prueba, que incluye errores como defectos descubiertos durante los usos en vivo del sistema o la solicitud planteada por los clientes. Por lo tanto, el cliente recibe mantenimiento y soporte oportuno y programado para el producto desarrollado. Realmente se sorprenderá al saber que el esfuerzo realizado en la fase de diseño y desarrollo del producto de software es solo el 60% del esfuerzo en comparación con los esfuerzos realizados en la fase de mantenimiento. Básicamente, hay tres tipos de mantenimiento que se explican a continuación:
- Mantenimiento correctivo: durante la fase de diseño y desarrollo, algunos errores no se descubren, solo se tienen en cuenta cuando el cliente los usa. Esto es solo mantenimiento correctivo, lo que significa la corrección de problemas o errores que no se descubrieron en la fase de desarrollo.
- Mantenimiento perfecto: este tipo de mantenimiento se realiza a pedido del cliente para aumentar y mejorar las funcionalidades del sistema o software.
- Mantenimiento adaptativo: es el mantenimiento que se requiere para cambiar el entorno del sistema. Por lo general, se requiere para portar el sistema existente a un nuevo entorno o una nueva computadora o sistema o tal vez con un nuevo sistema operativo. Esta fase es demasiado importante ya que esto conduce a un mejor rendimiento del sistema.
Entonces, en la discusión anterior, llegamos a conocer cada fase del modelo de cascada profundamente con especificaciones completas. Entonces, podemos decir que el modelo en cascada es muy importante en el campo del software también en comparación con las industrias mecánicas, ya que cada fase tiene su propia importancia, ya que genera un software más productivo y estable.
Ventajas
No solo este modelo en cascada también tiene muchas más ventajas en el ciclo de vida de desarrollo de software que se pueden analizar a continuación:
- Permite la departamentalización y el control.
- Se puede establecer un cronograma con plazos para cada etapa de desarrollo y un producto puede pasar por las fases del modelo de proceso de desarrollo una por una.
- Como se somete a fases fácilmente comprensibles y explicables, supera muchos problemas, por lo que es muy fácil de usar.
- Debido a la rigidez del modelo de flujo de trabajo, es muy fácil de administrar ya que cada fase del modelo en cascada tiene procesos específicos de revisión y entregables.
- El modelo de cascada funciona bien para proyectos más pequeños donde los requisitos se entienden muy bien.
- El cronograma se puede establecer con plazos para cada etapa de desarrollo y un producto puede pasar por las fases del modelo de proceso de desarrollo una por una.
- Etapas claramente definidas.
- Hitos bien entendidos.
- Tareas fáciles de organizar.
- El proceso y los resultados están bien documentados.
- Refuerza los buenos hábitos: definir-antes-diseño,
- Diseño antes del código.
- El modelo funciona bien para proyectos más pequeños y proyectos donde los requisitos se entienden bien.
Desventaja
Como sabemos que cada moneda tiene dos caras, por lo que con el amplio acceso a las ventajas del modelo en cascada, el modelo en cascada también tiene algunos inconvenientes o puede decir desventajas que se analizan a continuación:
- No es un buen modelo para proyectos complejos y orientados a objetos.
- No es adecuado para proyectos donde los requisitos tienen un riesgo de cambio moderado a alto.
- Es difícil estimar el tiempo y el costo de cada fase del proceso de desarrollo.
- No es un buen modelo para proyectos complejos y orientados a objetos.
- No se produce ningún software que funcione hasta el final del ciclo de vida.
- No se pueden adaptar los requisitos cambiantes.
- Es difícil medir el progreso dentro de las etapas.
- Grandes cantidades de riesgo e incertidumbre.
- Modelo deficiente para proyectos largos y en curso.
- Ajustar el alcance durante el ciclo de vida puede finalizar un proyecto.
- Sin ruta de comentarios
- Sin superposición de fases
- Difícil de acomodar las solicitudes de cambio.
- El riesgo y la incertidumbre son altos con este modelo de proceso.
Dónde usar el modelo de cascada
Ahora, después de rodear todos los escenarios, llegamos a un punto en el que queremos saber dónde usar el modelo de cascada.
- Principalmente el modelo de cascada se usa en un proyecto de defensa, ya que el requisito es claro porque antes de pasar a la fase de desarrollo lo analizan bien.
- Esto también se puede usar en proyectos de migración donde los requisitos serán los mismos, solo la plataforma o los idiomas pueden variar / cambiar.
Conclusión
Entonces, en general, puedo decir que el modelo en cascada es el más adecuado para proyectos pequeños de desarrollo de software en comparación con los proyectos grandes porque el diseño, desarrollo e implementación es más fácil en el proyecto pequeño cuando se trabaja en el modelo en cascada porque en este modelo todas las fases anteriores necesitan para completar cuando se va a las próximas fases. Entonces, en el gran proyecto, los problemas y errores se presentan con frecuencia, ya que tiene un modelo grande, por lo que cada vez que la fase de prueba continuará si se implementa a través del modelo en cascada, lo que conducirá a una menor optimización y precisión del software.
Artículos recomendados
Esta ha sido una guía para el modelo de cascada. Aquí hemos discutido las fases, las ventajas y las desventajas del modelo de cascada. También puede consultar nuestros otros artículos sugeridos para obtener más información:
- ¿Qué es AWS?
- ¿Qué es Bootstrap?
- ¿Qué es una colmena?
- ¿Qué es unix?
- Scrum vs Cascada | Comparación