Modelo de cascada en SDLC

para entender el modelo de cascada en SDLC, es necesario sumergirse en la definición del modelo, las fases principales, qué documentos están asociados como resultado de cada etapa, ventajas y desventajas.

SDLC significa un ciclo de vida de desarrollo de software. Es un marco (una estructura de apoyo esencial)de un proceso de desarrollo, que puede diferir de una empresa a otra. Uno de los tipos más populares de SDLC es el modelo de Cascada. La cascada es, como se puede ver desde arriba, un modelo de proceso., En palabras simples, una descripción generalizada del proceso de desarrollo de software. El modelo de cascada es el más conocido, ya que fue el primero cronológicamente en aparecer y ser descrito, por el Dr. Winston W. Royce en 1970 en » Management the development of large software systems.»

hay una gama de tipos de modelos de ciclo de vida de desarrollo, sobre los cuales se escribe con más detalle, y son los que vienen más adelante:

• scrum model
• rapid application development
• prototyping
• spiral model
• kanban development model
• y otros.,

ciertamente, se les ocurrió que servían mejor donde el modelo de cascada era menos poderoso. Para entender los «lugares delgados», es necesario sumergirse en la definición del modelo de Cascada, las fases principales, qué documentos se asocian como resultado de cada etapa, ventajas y desventajas.

definición del modelo de Cascada

El modelo de Cascada es un modelo de ciclo de vida de desarrollo lineal (secuencial) que describe el desarrollo como una cadena de pasos sucesivos. Ninguna fase puede iniciarse antes o simultáneamente con la anterior o actual., Consideremos las fases principales del modelo de cascada a medida que avanzan.

fases principales del modelo de Cascada

Fase de requisitos del sistema

durante la primera fase, se establecen los requisitos para el sistema. El proceso comienza con la obtención de requisitos de negocio, analizándolos y priorizándolos, lo que termina con la creación del documento de alcance visión& (o 2 documentos separados dependiendo de cada caso particular). Los documentos de visión y alcance se crean antes de firmar el contrato., Vision is defined as a » long-term strategic concept of the ultimate purpose and form of a new system.»(Wiegers, 2012, p. 1) el alcance es lo que «dibuja el límite entre lo que está adentro y lo que está afuera para el proyecto.»(Wiegers, 2012, p. 1)

denotar el alcance es una parte esencial del proyecto para ambas partes. Hace al cliente transparente lo que se hará. Una buena estrategia para gestionar las expectativas es identificar lo que no se incluirá en un producto, para que las expectativas del cliente sean claras, es decir, para que se cree el documento de alcance del proyecto.,

alcance del proyecto

Se espera que el alcance del proyecto contenga la hoja de Ruta del proyecto, los presupuestos y la descripción, con las principales funciones definidas en relación con el documento de visión del problema. Lea detenidamente un artículo sobre la gestión del alcance del proyecto de un experto Vitaly Hornik.

la fase inicial es impensable sin la especificación de requisitos de Software (SRS) que es el núcleo de la fase.

Especificación de requisitos de Software

un SRS típico incluye un propósito, una descripción general, requisitos específicos (funcionales, no funcionales, atributos de calidad).,

A Veces, puede incluir prototipos que pueden ser de diferentes tipos: vertical / horizontal, estático/dinámico, de baja fidelidad/alta fidelidad. Las maquetas (o prototipos) se envían a los diseñadores de UI/UX que las transforman en diseños. Siéntase libre de estimar la plantilla de especificación de requisitos de Software (SRS) creada por XB Software.

Fase de diseño

la siguiente fase del modelo muestra la precisión con la que se implementarán técnicamente los requisitos del sistema. Esta fase cubre en gran medida componentes tales como un lenguaje de programación, capas de datos, servicios, etc.,

Fase de implementación (desarrollo)

el código fuente real finalmente se escribe en la tercera fase, implementando todos los modelos, lógica de negocio e integraciones de servicios que se especificaron en los pasos anteriores. El proceso de creación de código completo puede subdividirse en unidades pequeñas, y cada unidad se desarrolla y prueba para su funcionalidad (pruebas unitarias). Después, se construye un sistema completo a partir de unidades listas para usar, y comienza la cuarta fase.,

Fase de prueba

después de la fase de desarrollo, el producto debe experimentar una completa garantía de calidad y pruebas de software para descubrir defectos en un sistema. Los evaluadores participan en la búsqueda y notificación de problemas que deben resolverse. Para almacenar los problemas registrados, se puede utilizar un sistema de seguimiento de errores con el objetivo de que los problemas se puedan manejar durante la fase de ciclo de vida de mantenimiento.

el software se puede transmitir cuando se solucionan los problemas de código. El cliente está comprometido con las pruebas de aceptación para evaluarlo para su utilización.,

Fase de mantenimiento

tan pronto como el producto se coloca en un entorno en vivo, entra en la fase de mantenimiento listo del ciclo de vida de desarrollo. La fase de mantenimiento involucra no solo la implementación de la aplicación, sino también el soporte y mantenimiento que puede ser necesario para mantenerla funcional y actualizada.

lea también los criterios de outsourcing indoloro que enumeramos por prioridad en el artículo 7 Consejos para elegir una empresa de Desarrollo Web de Outsourcing.,

ventajas y desventajas del modelo de Cascada

el modelo de Cascada es fácil de seguir y entender, es común a grandes instituciones con muchos niveles de toma de decisiones y coordinación. Sin embargo, como cualquier otro modelo SDLC, tiene sus lados fuertes y débiles. El modelo de cascada no puede adaptarse a todo tipo de proyecto concebible., de flexibilidad

conclusión

el modelo de cascada es el mejor ajuste:

• para proyectos pequeños y cortos.,
• Cuando los requisitos son inmutables.
• Para clientes con una estructura corporativa compleja con muchos niveles de coordinación.

además, es aconsejable estimar una plantilla de especificación de requisitos de Software libre (SRS) creada por XB Software.