CICLOS DE VIDA DE UN DESARROLLO DE SISTEMAS.

1. Clsico o cascada. 2. Estructurado. 3. Espiral. 4. Prototipos. 5. Incremental. 6. Combinacin de Paradigmas 7. Criterios en la seleccin.

Tambin denominado o conocido como, Modelo Cascada, o 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. Se caracteriza por la existencia de un conjunto de fases secuenciales en el tiempo. A la finalizacin de una fase se comienza con la siguiente tomando como datos de entrad los resultados de la anterior. Las fases principales consideradas son las siguientes: 1. 2. 3. 4. 5. Definicin de requisitos. Diseo. Implementacin. Transferencia del producto. Evolucin.

Definicin de requisitos. El objetivo de la fase de definicin de requisitos es obtener una clara comprensin del problema a resolver, extraer las necesidades del usuario y derivar de ellas las funciones que debe realizar el sistema. Esta se subdivide en anlisis de requisitos de usuario y anlisis de requisitos de sistema. Por modelo lgico se entiende la identificacin de las funciones de software requeridas para satisfacer los requisitos del usuario. Esta identificacin se suele realizar en varios niveles de detalle hasta llegar a uno en el que las funciones identificadas estn suficientemente claras de tal forma que no exija un refinamiento posterior.

Diseo
La fase de diseo tiene como objetivo determinar una solucin a los requisitos del sistema definidos en la fase anterior. En la subfase de diseo arquitectnico se parte del modelo lgico generado en la fase de definicin de requisitos software y se transforma en una arquitectura agrupando las funciones identificadas en componentes software. Asimismo, se define la activacin y desactivacin de cada uno de los componentes y el intercambio de informacin entre ellos (ahora con limitaciones de espacio). El resultado de esta fase es el Documento de Diseo Arquitectnico (DDA). Definir una buena arquitectura del sistema constituye un elemento bsico para asegurar que el sistema sea luego mantenible e integrable con otros.

En los ltimos aos se ha dedicado atencin a la ltima subfase del diseo se conoce como diseo detallado. Al final de la fase, se genera el Documento de Diseo Detallado (DDD). El proceso de diseo detallado suele requerir diversos pasos de refinamiento en los que mltiples decisiones de diseo permiten incorporar restricciones de implementacin derivadas del uso de recursos limitados: la ejecucin de las funciones identificadas requiere tiempo y espacio de memoria o bfferes as como recursos de CPU que no son ilimitados.

Implementacin Su objetivo es producir una solucin eficiente en un lenguaje ejecutable que implemente las decisiones adoptadas en la fase de diseo. Suele incluir la codificacin y la prueba del sistema hasta obtener un paquete ejecutable sobre la plataforma (hardware y S.O.) requerida por el usuario. Es ahora en la fase de implementacin cundo se selecciona y utiliza un lenguaje de programacin determinado; lo que s es evidente es que el conocimiento del lenguaje de implementacin puede orientar la fase de diseo (como ocurre en el caso de los lenguajes de programacin orientados a objetos) relacionando de forma ms directa los objetos o mdulos identificados con las construcciones del lenguaje. Al final de la fase, se genera el Manual de Usuario junto con el cdigo fuente del sistema y las pruebas asociadas.

Transferencia del producto La fase de transferencia del producto tiene como objetivo instalar el sistema de software desarrollado en el entorno del cliente y realizar las pruebas de aceptacin necesarias. En muchas ocasiones el proceso de transferencia implica un perodo largo en el que se incluye la formacin del usuario en el producto y la realizacin de las pruebas de aceptacin junto con el usuario. Debemos tener presente que el usuario deber aceptar el sistema que se le entrega en funcin de los requisitos de usuario que dieron origen a todo el proceso. Por ello, es importante que durante el desarrollo sea posible conocer las decisiones asociadas con los requisitos de usuario (trazabilidad de requisitos).

Evolucin Suele incluirse dentro de una fase denominada de mantenimiento aunque su implicacin es mucho ms amplia de lo que el trmino significa en otras ingenieras. Se suele hablar de tres tipos diferentes de mantenimiento: 1) Mantenimiento correctivo. Pretende eliminar problemas surgidos durante la fase de operacin del sistema y que no han sido detectados anteriormente. 2) Mantenimiento perfectivo. Pretende mejorar la funcionalidad del sistema ya sea en relacin con la eficiencia en ejecucin del mismo (menor tiempo de respuesta, optimizacin del uso de la memoria) 3) Mantenimiento evolutivo. Pretende modificar (ampliar, eliminar o sustituir) la funcionalidad del sistema para adaptarla a las nuevas necesidades del usuario o con el objetivo de adaptarlo a nuevas interfaces hardware o software.

Ventajas Fases conocidas por todos los desarrolladores y ligadas a los perfiles tcnicos clsicamente establecidos. Existe gran experiencia documentada sobre el uso del modelo que coincide con la formacin tpica del ingeniero de software. Es el ms eficiente cuando el sistema es conocido y los requisitos estables ya que se puede avanzar rpidamente hacia la fase de diseo arquitectnico sin que exista el peligro de una continua interaccin entre las primeras fases. Permite una gestin del proceso de desarrollo basada en revisiones de los documentos generados en cada fase facilitando la ejecucin de los procedimientos de gestin.

Desventajas Nada esta hecho hasta que todo est terminado. No permite manejar fcilmente cambios de requisitos una vez iniciado el desarrollo Las fallas ms triviales se encuentran al comienzo del perodo de prueba y las ms graves al final. La visibilidad del proceso es muy limitada siendo el cdigo generado el nico producto con el que el usuario puede validar sus requisitos. Las entradas y salidas intermedias son documentos internos al equipo de desarrollo no pensadas para su validacin por los usuarios. La eliminacin de fallas suele ser extremadamente difcil durante las ltimas etapas de prueba del sistema. La necesidad de prueba con la computadora aumenta exponencialmente durante las etapas finales de prueba. La segunda debilidad ms importante del ciclo de vida de un proyecto clsico es su insistencia en que las fases se sucedan secuencialmente.

CLASICO, ESTRUCTURADO o CASCADA

ESTUDIO DE FACTIBILIDAD Opcional

ANLISIS DE REQUISITOS

Documento de Especificaciones Usuario Sistema Arquitectura de Sistema

DISEO ARQUITECTNICO Fases de Desarrollo DISEO DETALLADO

Diagrama de Diseo

IMPLEMENTACIN

Cdigo probado Manual de Usuario

TRANSFERENCIA DEL PRODUCTO

Entrega al Cliente y Evolucin

Modelo espiral El modelo espiral para la ingeniera de software ha sido desarrollado para cubrir las mejores caractersticas tanto del ciclo de vida clsico, como de la creacin de prototipos, aadiendo al mismo tiempo un nuevo elemento: el anlisis de riesgo. El modelo representado mediante la espiral de la figura 2.4, define cuatro actividades principales: de objetivos, de alternativas alternativas y e

Planificacin: determinacin restricciones.

Anlisis de riesgo: anlisis identificacin/resolucin de riesgos.

Ingeniera: desarrollo del producto del "siguiente nivel", Evaluacin del cliente: Valorizacin de los resultados de la ingeniera.

Modelo espiral Durante la primera vuelta alrededor de la espiral se definen los objetivos, las alternativas y las restricciones, y se analizan e identifican los riesgos. Si el anlisis de riesgo indica que hay una incertidumbre en los requisitos, se puede usar la creacin de prototipos en el cuadrante de ingeniera para dar asistencia tanto al encargado de desarrollo como al cliente. El cliente evala el trabajo de ingeniera (cuadrante de evaluacin de cliente) y sugiere modificaciones. Sobre la base de los comentarios del cliente se produce la siguiente fase de planificacin y de anlisis de riesgo. En cada bucle alrededor de la espiral, la culminacin del anlisis de riesgo resulta en una decisin de "seguir o no seguir".

Modelo espiral Con cada iteracin alrededor de la espiral (comenzando en el centro y siguiendo hacia el exterior), se construyen sucesivas versiones del software, cada vez ms completa y, al final, al propio sistema operacional. El paradigma del modelo en espiral para la ingeniera de software es actualmente el enfoque ms realista para el desarrollo de software y de sistemas a gran escala. Utiliza un enfoque evolutivo para la ingeniera de software, permitiendo al desarrollador y al cliente entender y reaccionar a los riesgos en cada nivel evolutivo. Utiliza la creacin de prototipos como un mecanismo de reduccin de riesgo, pero, lo que es ms importante permite a quien lo desarrolla aplicar el enfoque de creacin de prototipos en cualquier etapa de la evolucin de prototipos.

PROTOTIPO

Prototipos Una alternativa de enfoque para la definicin de los requerimientos consiste en capturar un conjunto inicial de necesidades e implementarlas rpidamente con la intencin declarada de expandirlas y refinarlas en forma iterativa al ir aumentando la compresin que del sistema tienen los usuarios y quien lo desarrolla. Tambin se le conoce como modelamiento del sistema o desarrollo heurstico. Ofrece una alternativa atractiva y practicable a los mtodos de especificacin para tratar mejor la incertidumbre, la ambigedad y la volubilidad de los proyectos reales. Dentro del enfoque de prototipos se pretende que el modelo sea operante, es decir, una coleccin de programas que simulan algunas o todas las funciones que el usuario desea. Para lograr lo anterior se utilizan las siguientes herramientas de software:

Un diccionario de datos integrado. Un generador de pantallas. Un generador de reportes no guiado por procedimientos Un lenguaje de programacin. Medios poderosos de administracin de base de datos.

Caractersticas de esta metodologa. No modifica el flujo del ciclo de vida. Reduce el riesgo de construir productos que no satisfagan las necesidades de los usuarios. Reduce costos y aumenta la probabilidad de xito. Exige disponer de las herramientas adecuadas. No presenta calidad ni robustez. Debe ser un sistema con el que se pueda experimentar. Debe desarrollarse rpidamente. El nfasis predomina en la interfaz de usuario. Se Utiliza un equipo de desarrollo reducido. Se deben emplear herramientas y lenguajes adecuados. El Cliente ve los resultados de manera rpida.

Prototipos

Modelo Incremental Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir slo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construccin siempre incrementando subconjuntos de requerimientos del sistema. Tpicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo. Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma especfica de observar el desarrollo de algn otro incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo.

El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos: Construir un sistema pequeo es siempre menos riesgoso que construir un sistema grande. Al ir desarrollando parte de las funcionalidades, es ms fcil determinar si los requerimientos planeados para los niveles subsiguientes son correctos. Si un error importante es realizado, slo la ltima iteracin necesita ser descartada. Permiten Incrementar la visibilidad del proceso de desarrollo mediante la experimentacin con prototipos ejecutables intermedios. La documentacin de las fases de anlisis y diseo queda reforzada por los resultados del proceso de animacin de modelos facilitando las pruebas de aceptacin.

Si un error importante es realizado, el incremento previo puede ser usado. Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del prximo incremento. Como desventajas se pueden mencionar: Requieren el empleo de mtodos formales para ejecutar la descripcin de la especificacin y el diseo con sofisticadas herramientas grficas. Siguen existiendo dificultades para la evaluacin de requisitos temporales. Se mantienen dificultades en la evaluacin de requisitos no funcionales igual que en los prototipos desechables. En ese sentido no es fcil definir y mantener una arquitectura del sistema a lo largo de los diferentes pasos incrementales.

INCREMENTAL

Ingeniera de siste as

Incre ento 1

DISEO

Incre ento 2

Incre ento3

ANLISIS

DISEO

CDIGO

PRUEBA

Entrega del tercer Incre ento

Incre ento 4

Tie po de Calendario

ANLISIS

DISEO

CDIGO

PRUEBA

Entrega del c arto Incre ento

ANLISIS

DISEO

CDIGO

PRUEBA

Entrega del seg ndo Incre ento

ANLISIS

CDIGO

PRUEBA

Entrega del pri er Incre ento

Combinacin de Paradigmas En muchos casos, los paradigmas pueden y deben combinarse de forma que puedan utilizarse las ventajas de cada uno en un nico proyecto. El paradigma del modelo en espiral lo hace directamente, combinando la creacin de prototipos y algunos elementos del ciclo de vida clsico, en un enfoque evolutivo para la ingeniera de software.

No hay necesidad por tanto de ser dogmtico en la eleccin de los paradigmas para la ingeniera de software: la naturaleza de la aplicacin debe dictar el mtodo a elegir. 1. Prototipo Desechable / Prototipo Incremental. 2. Modelo Espiral Prototipos. 3. Ciclo Clsico o Cascada Prototipos.

Seleccin de un Modelo de Ciclo de Vida. Criterios a considerar: 1. Madurez de la aplicacin (relacionado a la probabilidad que muchos requerimientos comenzarn a conocerse slo despus del uso del sistema). 2. Complejidad del problema y de la solucin. 3. Frecuencias y magnitudes esperadas de los cambios de requerimientos. 4. Financiamiento disponible, y su perfil como una funcin del tiempo. 5. Acceso de los desarrolladores a los usuarios. 6. Certeza de requerimientos conocidos.

Otros que pueden incluirse: 1. Tolerancia al riesgo. 2. Planes y presupuestos crticos 3. Grado de lentitud de construccin dentro de los planes y presupuestos. Considerando la importancia de la planificacin se recomienda realizar el desarrollo de un proyecto de software bajo el modelo espiral insertando en l, cualquier otro modelo que se requiera dependiendo de las necesidades que se presenten. Este modelo permite realizar una planificacin del proceso de desarrollo del software considerando los riesgos asociados en cada etapa identificada. El identificar los riesgos en proyectos, evaluar su impacto, monitorear y controlar el avance del desarrollo del proyecto, permite al administrador aumentar las posibilidades de xito de un proyecto o, minimizar las posibilidades de fracaso de ste.

Uno de los factores que ms influyen en el proceso de desarrollo de software y que prcticamente acompaa a toda aplicacin es el hecho de que en su mayora, no hay forma de tener todos los requerimientos corregidos antes del desarrollo del software. Muchas veces los requerimientos emergen a medida que la aplicacin o partes de ella estn disponibles para experimentacin prctica. En todos los casos, el trabajo comienza con la determinacin de objetivos, alternativas y restricciones, paso que a veces se llama recoleccin preliminar de requisitos. El empleo de Prototipos es ampliamente recomendado para realizar la especificacin de requerimientos. Se debe notar que la idea del prototipado es capturar por retroalimentacin los objetivos, necesidades y expectativas del cliente

Por lo cual no se debe caer en una utilizacin de estos prototipos como partes finales del sistema, ya que en su desarrollo generalmente no se consideran aspectos de calidad, ni otros asociados con facilitar la etapa de mantencin del sistema. El prototipo trata de minimizar los cambios en los requerimientos, mientras que el diseo modular (incremental, en funcionalidades) trata de minimizar el impacto de los cambios en los requerimientos.