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 y desactivación de cada uno de los componentes y el intercambio de informaciónentre ellos (ahora con limitaciones de espacio).

Publicado por Juan en 18:18 Sin comentarios:

3. Implementación

Su objetivo es producir una solución eficiente en un lenguaje ejecutable que implemente las decisiones adoptadas en la fase de diseño. Suele incluir la codificación y la prueba del sistema hasta obtener un paquete ejecutable sobre la plataforma (hardware y S.O.) requerida por el usuario. Es interesante mencionar que todas las fases anteriores son conceptualmente independientes del lenguaje de programación seleccionado. Es ahora en la fase de implementación cuándo se selecciona y utiliza un lenguaje de programación determinado; lo que sí es evidente es que el conocimiento del lenguaje de implementación puede orientarla fase de diseño (como ocurre en el caso de los lenguajes de programaciónorientados a objetos) relacionando de forma más directa los objetos o módulos identificados con las construcciones del lenguaje. Como en el proceso de refinamiento se ha dividido el trabajo entre diversos componentes del equipo de trabajo, éstos han trabajado concurrentemente en el diseño detallado y en la subsiguienteimplementación de diversos módulos.

El problema es que ahora es necesario integrar los diversos módulos y construir el sistemas de software completo. Se denomina integración al proceso de construir un sistema de software combinando componentes individuales en una unidadejecutable. Este proceso de integración debe hacerse de formaordenada para que se integren los módulos en función del uso queunos hacen de otros. La gestión del proyecto deberá asegurar que laintegración se realiza adecuadamente. Una vez obtenida la implementación del sistema es necesarioprobar que satisface los requisitos definidos inicialmente. Posiblemente,cada uno de los diseñadores que ha estado construyendo cada uno delos módulos ha probado que su implementación está de acuerdo conlas decisiones tomadas en el diseño pero no puede asegurar que alintegrarlo con otros no existan problemas de incompatibilidades oaspectos no considerados individualmente en cada módulo. Esnecesario, por tanto, realizar pruebas a diferentes niveles hasta que elsistema en su conjunto sea aceptado por el usuario.

Al final de la fase, se genera el Manual de Usuario junto con elcódigo fuente del sistema y las pruebas asociadas.Aunque con la fase de implementación se dispone del «producto», no acaba con ella la actividad del equipo de desarrollo ni el ciclode vida del sistema de software construido. A estas fases se les suelenañadir otras dos que son cada vez más importantes: la fase de transferenciay la de evolución.

Publicado por Marisol en 18:10 Sin comentarios:

4. Transferencia del producto

La fase de transferencia del producto

...