Ciclo de vida de la ingeniería de software en cascada

El modelo en cascada es un enfoque clásico, popular y lineal del ciclo de vida de la ingeniería de software. Define una secuencia de fases, cada una con objetivos claros. Como el agua que baja por una pendiente, el modelo estricto avanza sin volver atrás.

El enfoque en cascada es estricto y ofrece poco margen para revisar lo anterior. Las pruebas se tratan como una fase separada, en lugar de llevarse a cabo de manera continua junto al desarrollo. Como resultado, el modelo no permite detectar defectos temprano en el desarrollo.

Abrir el diagrama a tamaño completo ↗

Ciclo de vida de la ingeniería de software en cascada

Las fases siguen este orden.

1. Recopilación de requisitos. Documenta los requisitos del cliente y prepara la documentación necesaria.
2. Diseño del sistema. Usa los requisitos para definir la arquitectura y las necesidades de hardware y software del sistema.
3. Implementación. Empieza a programar a partir del diseño. Divide el programa en unidades pequeñas e independientes, prueba cada unidad frente a sus especificaciones e intégralas en el sistema completo.
4. Pruebas de integración. Combina las unidades probadas y comprueba si el sistema completo presenta defectos.
5. Despliegue. Corrige los defectos encontrados en la integración y repite las pruebas para comprobar que se han resuelto. El sistema queda listo para salir al mercado e instalarse en el entorno del cliente.
6. Mantenimiento. Publica parches o versiones nuevas para resolver los defectos y problemas que se detecten después de la entrega.

Las fases avanzan en cascada. Cada fase empieza solo cuando la anterior ha terminado satisfactoriamente.

Usa el modelo en cascada si los requisitos están claros, el producto es estable y cada fase cuenta con recursos suficientes. En la práctica, se debe usar únicamente en proyectos pequeños y manejables. Evítalo cuando los requisitos impliquen un riesgo moderado o alto.

Especificación y análisis de requisitos

El desarrollo de software depende de un único factor, la calidad con la que se recopilan y documentan los requisitos. El proceso de identificarlos y documentarlos se denomina especificación y análisis de requisitos.

El cliente, el equipo directivo y el equipo de soporte técnico analizan los requisitos en detalle. Los estudian, revisan y documentan hasta que estén claros y completos.

Abrir el diagrama a tamaño completo ↗

Especificación de requisitos del usuario

Usa el formato que exija la empresa, como documentos de Word, diagramas de flujo o dibujos. El resultado es un registro detallado de lo que el cliente quiere, que ayuda al equipo a entender bien sus necesidades. Todo lo que no cumple los requisitos del cliente es un defecto. Si se recopilan requisitos incorrectos, el proyecto empieza con una base equivocada.

Especificación de requisitos del usuario

Este documento no técnico describe las expectativas de los usuarios y las necesidades de la empresa. Lo redactan los usuarios finales, y los requisitos se comprueban durante las pruebas de aceptación de usuario. Sirve de base para las siguientes actividades de requisitos y para el diseño del sistema.

Especificación de requisitos de software

La especificación de requisitos de software (SRS, por sus siglas en inglés) define cómo quiere el usuario que funcione el software. Cumple las siguientes funciones.

• Registrar el acuerdo entre el cliente y el proveedor sobre las funciones detalladas del software.
• Servir de base para el diseño del software.
• Simplificar el desarrollo y las pruebas mediante requisitos claros.
• Ayudar a programar las actividades y estimar los costos.
• Servir de base para la verificación y la validación.

Abrir el diagrama a tamaño completo ↗

Especificación de requisitos de software

Diseño de software

El diseño de software tiene dos niveles.

• Diseño de software de alto nivel
• Diseño detallado de software

Abrir el diagrama a tamaño completo ↗

Diseño de software

Diseño de software de alto nivel

El diseño de alto nivel (HLD, por sus siglas en inglés) describe el diseño de la base de datos y la arquitectura funcional. Orienta al equipo de desarrollo y responde preguntas sobre el flujo del diseño. Para prepararlo, se necesita una SRS clara.

Diseño detallado de software

El diseño detallado o de bajo nivel (LLD, por sus siglas en inglés) divide el HLD en partes más pequeñas y registra la lógica que define la especificación del programa. Proporciona información detallada del sistema y depende de que el HLD esté listo.

Procesos de diseño de software

Los procesos de diseño pueden seguir cualquiera de estos enfoques.

• Diseño descendente
• Diseño ascendente

Enfoque de diseño descendente

El diseño descendente parte de un esquema del sistema y deja los detalles de los subsistemas para más adelante. Recorre cada subsistema con un nivel de detalle cada vez mayor hasta llegar a sus elementos básicos.

Enfoque de diseño ascendente

El diseño ascendente parte de elementos básicos ya definidos en detalle. Únelos en subsistemas y combina los subsistemas hasta formar todo el sistema. Imagínate que plantas una semilla y poco a poco crece un árbol.