Tecnologia Modelo Cascada

Modelo en cascada

El modelo en cascada, también denominado modelo convencional, responde a la secuencia de pasos de desarrollo de un producto empleada desde el comienzo del desarrollo de software para la mayor parte de los sistemas de software .Este modelo se caracteriza por la existencia de un conjunto defases secuenciadas en el tiempo.

A la finalización de una fase secomienza la siguiente tomando como datos de entrada los resultadosde la anterior. En cada una de las fases se introduce más detallehasta obtener un código ejecutable y eficiente que incorpore los requisitos necesarios. Tomaremos como referencia en la siguientedescripción el modelo de ciclo de vida propuesto por la AgenciaEspacial Europea (ESA) y que se corresponde con el modelo encascada.

Las fases principales consideradas son las siguientes:

1. • Definición de requisitos.

2. • Diseño.

3. • Implementación.

4. • Transferencia del producto.

5. • Evolución.

Aún hoy se considera que todos los demás modelos no son más que "modificaciones" de este modelo básico. Aunque es cierto que todos lo demás modelos han derivado de él para evitaralgunos de sus problemas, preferimos tratarlos de forma diferenciada.

1 • Definición de requisitos.

Empleada desde el comienzo del desarrollo de software para la mayor parte de los sistemas de software. Este modelo se caracteriza por la existencia de un conjunto de fases secuenciadas en el tiempo. Posiblemente con anterioridad a esta fase ha existido algún estudio de factibilidad que permite asegurar que el software a realizares "realizable", responde a un mercado potencial o real, etc.

La fase de definición de requisitos suele subdividirse en dos subfases:

Análisis de requisitos de usuario (1)

Análisis de requisitos de sísteme (2)

La subfase de (1) análisis de requisitos de usuario tiene como objetivo conocer las necesidades de los usuarios y cuáles deben serlos servicios que un sistema de software debe ofrecerles para satisfacerlas. La fase implica la creación del Documento de Requisitos de Usuario (DRU) que constituye el documento base para que, al final del desarrollo, el sistema sea aceptado por el usuario. Los requisitos de los usuarios pueden ser de muchos tipos diferentes. Por un lado, el usuario tiene requisitos que corresponden al servicio que el sistema de software que se pretende construir le debe proporcionar. En otros casos, se trata de limitaciones existentes en la operación del sistema.

Como ejemplo:

A) Un usuario puede requerir un sistema de control de un ascensor que, entre otros muchos requisitos, desde que el usuario pulsa un botón en la puerta hasta que ésta se cierre no deba transcurrir más de 3 segundos. Este requisito corresponde a un servicio que debe proporcionar al usuario.

B) Podría ser que el sistema de software tenga que utilizar un determinado sistema operativo (lo cual limita el tipo de soluciones posibles).

Esta subfase se aprovecha también para generar el plan de desarrollo con una estimación de costes y recursos .

La subfase de (2) análisis de requisitos del sistema consiste en la construcción de un modelo lógico del sistema de software describiendo las funciones que sean necesarias (sin tomar ninguna decisión sobre cómo implementarlas) y las relaciones entre ellas suponiendo que no existen limitaciones de recursos. Por modelo lógico se entiende la identificación de las funciones de software requeridas para satisfacer los requisitos del usuario. Esta identificación se suele realizar en varios niveles de detalle hasta llegara uno en el que las funciones identificadas estén suficientemente claras de tal forma que no exija un refinamiento posterior. El producto generado en esta fase es el Documento de Requisitos de Software (DRS). También se genera en esta sub-fase el plan de gestión del desarrollo con estimaciones de costes y recursos más ajustados que en la sub-fase anterior.

Es importante distinguir en esta subfase entre requisitos funcionales (aquellos ligados a la relación entre datos de entrada y resultados (datos de salida) que debe presentar el sistema, incluidos los derivados de restricciones temporales cuando éstas están cuantificadas) y requisitos no funcionales (que incluyen todos los aspectos de calidad del sistema: por ejemplo, mantenibilidad (facilidadpara que el sistema evolucione y se modifique una vez entregado alusuario), escalabilidad (posibilidad de incrementar sustancialmente elnúmero de usuarios u otros parámetros), facilidad de uso, etc., que nopueden ligarse a funciones concretas dentro del sistema.Los mecanismos de control (en estas etapas son las revisiones delos documentos generados) deben asegurar que los requisitos softwaresatisfacen completamente los requisitos de usuario. el requisito de usuario puede implicar un conjunto de funciones de software cuya relación debe establecerse en el modelo lógico. Concretamente, implicará una funciónde «cierre de puerta» cuyo tiempo de ejecución deberá ser inferior a 3 segundos (¡aunque en esta fase no podamos asegurarlo!; seráposteriormente cuando podamos estimar y luego comprobar que,efectivamente, ello es posible). En el caso de la limitación del usuario respecto del sistema operativo, implicará el uso de determinados servicios del mismo (llamadas al sistema).

2. Diseño

La fase de diseño tiene como objetivo determinar una solución a los requisitos del sistema definidos en la fase anterior. Obviamente,existen muchas maneras de satisfacer los requisitos y, por tanto, multitud de diseños posibles. Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado.

El primero de ellos (arquitectonico) tiene como objetivo definir la estructura de la solución (una vez que la fase deanálisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo (Detallado) define los algoritmos empleados y la organización del código para comenzar la implementación. En la subfase de diseño arquitectónico se parte del modelo lógico generado en la fase de definición de requisitos software y se transforma en una arquitectura agrupando las funciones identificadas en componentes software. Asi mismo, se define la activación

...