INTRODUCCION.

Al igual que en otros sistemas de ingeniera, los sistemas de software requieren un tiempo y esfuerzo considerable para su desarrollo y deben permanecer en uso por un periodo mucho mayor. Durante este tiempo de desarrollo y uso, desde que se detecta la necesidad de construir un sistema de software hasta que este es retirado, se identifican varias estepas que en conjunto se denominan el ciclo de vida de software el cual describe el desarrollo del software, desde la fase inicial a la fase final. Y en cada caso, en funcin, se identifican varias estepas que en conjunto se denominan el ciclo de vida de forma diferente. Usualmente se consideran las etapas: especificacin y anlisis de requisitos, diseo de sistema, implementacin de software, aplicacin y pruebas, entrega y mantenimiento. Un aspecto esencial dentro de las tareas del desarrollo del software es la documentacin de todos los elementos y especificaciones en cada fase. Dado que esta tarea siempre estar influida por la fase del desarrollo en curso, se explicara de forma distribuida a lo largo de las diferentes fases como un apartado especial para recalcar su importancia en el conjunto del desarrollo del software.

44

OBJETIVOS.

Definir algunos de los distintos Ciclos de la Vida del Software as como las fases y o etapas intermedias que se requieren para validar el desarrollo de la aplicacin, Y garantizar que el software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de desarrollo y que los mtodos usados son los apropiados.

44

CICLO DE VIDA BASICO DE UN SOFTWARE.

Las etapas y fases constan de tareas. La documentacin es una tarea importante que se realiza en todas las etapas. Cada etapa tiene como entrada uno o varios documentos procedentes de las etapas anteriores y produce otros documentos de salida. Definicin de objetivos: Definir el resultado del proyecto y su papel en la estrategia global. Anlisis de los requerimientos y su viabilidad: Construye un modelo de los requisitos, recopilando, examinando, y formulando los requisitos del cliente y a su vez examinar cualquier restriccin que se pueda aplicar. Diseo: Diseo general: Requisitos generales de la arquitectura de la aplicacin. Diseo en detalle: Definicin precisa de cada subconjunto de la aplicacin. Codificacin o Programacin: Construye el sistema, es la implementacin de un lenguaje de programacin para crear las funciones definidas durante la etapa de diseo, la salida de esta fase es cdigo ejecutable. Pruebas: Prueba Unitaria: Se comprueba que se cumplen criterios de correccin y calidad. Mediante la prueba individual de cada subconjunto de la aplicacin para garantizar que se implementaron de acuerdo con las especificaciones. Integracin: Para garantizar que los diferentes mdulos se integren con la aplicacin. Este es el propsito de la prueba de integracin que deber estar cuidadosamente documentada. Prueba beta (validacin o prueba del sistema):

44

Para garantizar que el software cumple con las especificaciones originales. Documentacin: Sirve para documentar informacin necesaria, para los usuarios del software y para desarrollos futuros.

Mantenimiento: Tiene lugar despus de la entrega, se asegura qu el sistema siga funcionando y adaptndose a nuevos requisitos mediante actualizaciones secundarias del software.

En algunos casos la etapa de Diseo se divide en 2 partes: Diseo global o arquitectnico y Diseo detallado. En el primero se transforman los requisitos en una arquitectura de alto nivel, se definen las pruebas que debe satisfacer el sistema en su conjunto, se esboza la documentacin y se planifica la integracin. En el detallado para cada modulo se refina el diseo, se definen los requisitos del modulo y su documentacin. Las formas de organizar y estructurar la secuencia de ejecucin de las tareas en las diferentes fases de cada uno de los mtodos pueden dar lugar a un tipo

44

de ciclo de vida diferente. Los diferentes Ciclos de la Vida que a continuacin se presentaran realizan esta tarea.

44

PROCESOS DEL CICLO DE VIDA SOFTWARE

o o o o o o o o o o o o o o o o o o o o o o o o o o PROCESOS PRINCIPALES I Proceso de Adquisicin Proceso de Suministro Proceso de Desarrollo I Integracin del Software Prueba del Software Integracin del Sistema Prueba del Sistema Instalacin del Software Soporte del proceso de Aceptacin del Software Proceso de Desarrollo II Integracin del Software Prueba del Software Integracin del Sistema Prueba del Sistema Instalacin del Software Soporte del proceso de Aceptacin del Software PROCESOS PRINCIPALES IV Proceso de Explotacin Proceso de Mantenimiento PROCESOS DE SOPORTE I Proceso de Documentacin Proceso de Gestin de la Configuracin PROCESOS DE SOPORTE II Proceso de Aseguramiento de la Calidad Proceso de Verificacin Proceso de Validacin PROCESOS DE SOPORTE III Proceso de Revisin Conjunta Proceso de Auditora Proceso de Resolucin de Problemas PROCESOS GENERALES Proceso de Gestin Proceso de Infraestructura Proceso de Mejora Proceso de Formacin

44

TIPOS DE CICLOS DE LA VIDA. Las principales diferencias entre distintos modelos de cliclo de vida estandivididas en tres grandes visiones: El alcance del Ciclo de vida: que depende de hasta donde deseamos llegar con el proyecto: solo saber si es viable el desarrollo de un producto, el desarrollo completo o el desarrollo completo mas las actualizaciones y el mantenimiento. La cualidad y cantidad de las etapas: en que dividiremos el cliclo de vida, segn el ciclo de vida que adoptemos, y el proyecto para el cual lo adoptemos. La estructura y la sucesin de las etapas: si hay realimentacin entre ellas, y si tenemos libertad de repetirlas (iterar). Cascada.

1.1.

El ciclo de la vida inicial mente propuesto por Royce en 1970, comenz a disearse en 1966 y termina alrededor de 1970, aunque son ms conocidos los refinamientos realizados por Boehm [1981], Sommerville [1985] y Sigwart y col. [1990].Fue adaptado para el software a partir de ciclos de vida de otras ramas de ingeniera. Es el primero de los propuestos y el ms ampliamente seguido por las organizaciones en un 90%, se define como una secuencia de fases en etapa final en la que en cada una de ellas se rene la documentacin para garantizar que cumple con las especificaciones y los requisitos antes de pasar a la siguiente fase. [Anexo 1], Este modelo admite la posibilidad de hacer iteraciones, es decir, durante las modificaciones que se hacen en el mantenimiento se puede ver por ejemplo la necesidad de cambiar algo en el diseo, lo cual significa que se harn los cambios necesarios en la codificacin y se tendrn que realizar de nuevo etapas anteriores al mantenimiento hay que recorrer de nuevo el resto de las etapas. Este modelo es el ms antiguo y resulta especialmente sencillo de gestionar. Se basa en varios principios, como: Que una nueva fase no puede comenzar hasta que no se termine la anterior, Para poder pasar de una fase a otra se han de haber cubierto todos los objetivos de la predecesora o que al final de cada fase se pueda revisar el estado del proyecto por parte de los stakeholders1.

44

Al final de cada fase el personal tcnico y los usuarios tienen la oportunidad de revisar el progreso del proyecto.

Ventajas: La planificacin es sencilla.

1.- Stakeholders: quienes pueden afectar o son afectados por las actividades de una empresa. La calidad del producto resultante es alta.

Permite trabajar con personal poco calificado. Es til como control de fechas de entregas

Desventajas: La necesidad de tener todos los requisitos al principio. Y que el cliente no tenga perfectamente definidas las especificaciones del sistema, por lo que puede ser que surjan necesidades imprevistas. No refleja el proceso real del desarrollo del software, porque muy raramente un proyecto sigue un flujo secuencial, sino que siempre hay iteraciones. El paso por todo el ciclo es lento y pesado, porque requiere que se finalice una fase para pasar a la siguiente. Si se comete un error en la fase de anlisis no se descubre hasta la entrega al cliente, por lo que causa un gasto intil de recursos. Requiere de mucha paciencia por parte del cliente, porque no posee un prototipo de su sistema hasta los ltimos compases del proyecto y en algunos casos el cliente ya ha consumido casi la totalidad de los recursos. Otra limitacin que se argumenta es que el modelo supone que los requisitos pueden ser congelados antes de comenzar el diseo y esto significa un hardware asociado durante el tiempo que dure el proyecto.

ETAPAS: El nmero de etapas suele variar, pero en general suelen ser: Anlisis de requisitos del sistema:

44

Recopilar informacin en lenguaje natural y formular los requisitos del cliente y examinar cualquier descripcin que se pueda examinar. Anlisis de requisitos del software: El proceso de recopilacin de los requisitos se centra e intensifica especialmente en el software. El ingeniero de software debe comprender el mbito de la informacin del software, as como la funcin, el rendimiento y las interfaces requeridas Diseo preliminar: Su entrada son los Documentos de Requerimientos de Software, y en base a estos se crea y da forma a la interfaz general para la interaccin con la misma. Diseo detallado: Su entrada son los Documentos de Requerimientos de Software, y en base a estos se crea a detalle una por una las aplicaciones visuales con las cuales el usuario (cliente) tendr interaccin directa con el programa. Codificacin y pruebas: A partir del Documento de Diseo de Software produce mdulos. En esta fase se hacen tambin pruebas de unidad Explotacin (u operacin) y mantenimiento. Mantenimiento: Tiene lugar despus de la entrega, se asegura qu el sistema siga funcionando y adaptndose a nuevos requisitos mediante actualizaciones secundarias del software.

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Aquellos para los que se dispone de todas las especificaciones desde el principio, como los de reingeniera. Se est desarrolla un tipo de producto que no es novedoso. Proyectos complejos que se entienden bien desde el principio.

44

44

1.2

INCREMENTAL

Las etapas son las mismas que en el ciclo de vida en cascada y su realizacin sigue el mismo orden, pero corrige la problemtica de la linealidad del modelo en cascada. Este modelo incremental fue desarrollado por Lehman [1984]. En cada paso sucesivo se agregan al sistema nuevas funcionalidades o requisitos que permiten el refinado a partir de una versin previa. Este modelo satisface la necesidad de una secuencia no lineal de los pasos de desarrollo. En el modelo incremental se va creando el sistema software aadiendo componentes funcionales al sistema (llamados incrementos). En cada paso sucesivo, se actualiza el mismo con nuevas funcionalidades o requisitos, es decir, cada versin o refinamiento parte de una versin previa y le aade nuevas funciones. El sistema software ya no se ve como una nica entidad monoltica con una fecha fija de entrega, sino como una integracin de resultados sucesivos obtenidos despus de cada iteracin. [Anexo 2], Es una repeticin del ciclo de la vida en cascada, aplicndose este ciclo en cada funcionalidad del programa a construir, al final de cada ciclo le entregamos una versin al cliente que contiene una nueva funcionalidad. Este ciclo nos permite realizar una entrega al cliente antes de terminar el proyecto. Ventajas: No es necesario tener todos los requisitos en un principio. Se ajusta a entornos de alta incertidumbre, por no tener la necesidad de poseer un conjunto exhaustivo de requisitos, etc. Al comenzar el sistema. Permite el refinamiento, o sea se pueden ampliar los requisitos y las especificaciones derivadas de la etapa anterior. Una forma de reducir los riesgos es ir construyendo partes del sistema adoptando este modelo. Construir un sistema pequeo es menos riesgoso que construir un sistema grande. Si se detecta un error grave solo se deshace la ultima iteracin.

Desventajas:

44

La deteccin de requisitos tardamente, siendo su correccin tan costosa como en el caso de la cascada.

ETAPAS: Anlisis: Construye un modelo de los requisitos. Diseo: A partir de este modelo de anlisis se deducen las estructuras de datos, la estructura en la que descompone el sistema y la interfaz de usuario Codificacin: Construye el sistema. La salida de esta fase es cdigo ejecutable. Pruebas: Se comprueba que se cumplen criterios de correccin y calidad. Mantenimiento: Tiene lugar despus de la entrega, se asegura qu el sistema siga funcionando y adaptndose a nuevos requisitos mediante actualizaciones secundarias del software.

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Se puede utilizar en casi cualquier tipo de proyectos, pero ser verdaderamente til cuando el cliente necesite entregas rpidas, aun que sean parciales.

44

1.3

CICLO DE LA VIDA EN V

Este ciclo fue diseado por Alan Davis, y contiene las mismas etapas que el ciclo de la vida en cascada puro. A diferencia de aquel, a este se le agregaron dos subetapas de retroalimentacin entre las etapas de anlisis y mantenimiento, y entre las de diseo y debugging. El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicacin simple con las especificaciones ya que deben haberse creado en la fase de diseo. Asi mismo el modelo en V es una variacin del modelo en cascada que muestra cmo se relacionan las actividades de prueba con el anlisis y el diseo la codificacin forma el vrtice de la V, con el anlisis y el diseo a la izquierda y las pruebas y el mantenimiento a la derecha. La unin mediante lneas discontinuas entre las fases de la parte izquierda y las pruebas de la derecha representa una doble informacin. Por un lado sirve para indicar en qu fase de desarrollo se deben definir las pruebas correspondientes. Por otro sirve para saber a qu fase de desarrollo hay que volver si se encuentran fallos en las pruebas correspondientes.
[Anexo 3],

Ventajas: Este modelo ofrece mayor garanta de correccin al terminar el proyecto. Su planificacin es sencilla y de fcil aprendizaje. Provee un producto con un elevado grado de calidad sin necesidad de un personal altamente calificado. Hace explcito parte de la iteracin y trabajo que hay que revisar La relacin entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localizacin de fallos Involucra al usuario en las pruebas

Desventajas: Necesita contar con todos los requerimientos proyecto. al comienzo del

Es difcil que el cliente exponga explcitamente todos los requisitos.

44

El cliente debe tener paciencia pues obtendr el producto al final del ciclo de vida. Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas. El producto final obtenido puede que no refleje todos los requisitos del usuario. Los errores que no se detectan en la eta siguiente, generan costos que obligan a realizar la correccin posterior. No se reflejan los resultados hasta las etapas finales del ciclo.

ETAPAS: Anlisis de requisitos del sistema: Anlisis de requisitos del software: Diseo preliminar: Diseo detallado: Codificacin y pruebas: Mantenimiento:

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Se puede utilizar en aplicaciones como pequeas transacciones sobre bases de datos como una Facturacin.

44

1.4. CICLO DE LA VIDA TIPO SASHIMI. Este ciclo de vida es parecido al ciclo de vida en cascada, con la diferencia de que en el ciclo de vida en cascada no se puede solapar las etapas, y en este si. Esto suele, en muchos casos, aumentar su eficiencia ya que la retroalimentacin entre etapas se encuentra implcitamente en el modelo. [Anexo 4], El nombre Sashimi deriva del modo del estilo de presentacin de rodajas de pescado crudo en japon. Al utilizar este ciclo de vida se obtiene una ganancia de calidad en el producto final, adems de que no hace necesario una documentacin detallada para cada etapa, ya que por el mismo hecho de que estas se solapan, comparten partes de la documentacin. Entre los problemas que se presentan al utilizar este modelo existe la dificultad de identificar el inicio y el fin de cada etapa, adems de que en caso de presentarse problemas de comunicacin estos van a generar inconsistencias. La fase de ``concepto'' consiste en definir los objetivos del proyecto, beneficios, tipo de tecnologa y el tipo de ciclo de vida. El diseo arquitectnico es el de alto nivel, el detallado el de bajo nivel. Ventajas: Genera ganancia de calidad con respecto al producto final. Falta de necesidad de una documentacin detallada.

Desventajas: Difcil gestin de comienzo y fin de cada etapa. Problemas de comunicacin en el proyecto e integrantes.

ETAPAS: Anlisis o o Requisitos del sistema: Requisitos del software:

Diseo de arquitectura: Diseo detallado: Codificacin:

44

Pruebas:

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. En proyectos en los cuales se comparten los recursos como CPU, memoria o espacio de almacenamiento. Proyectos en modelos de 3 capas.

44

1.5. CICLO DE LA VIDA EN CASCADA CON SUBPROYECTOS. Cada una de las cascadas se dividen en subetapas independientes que se pueden desarrollar en paralelo, El principal riesgo de esta aproximacin son las interdependencias no detectadas. Para solucionar esto parcialmente al eliminar dependencias en la arquitectura se debe esperar hasta que el diseo detallado este terminado para dividir en subproyectos. [Anexo 5], Ventajas: Puede tener ms gente trabajando al mismo tiempo. Sigue dependencias entre las distintas subetapas. Gana velocidad Se puede realizar varias partes del proyecto al mismo tiempo por diferentes desarrolladores.

Desventajas: La planeacin tiene que ser mucho mas cuidadosa.

ETAPAS: Cuenta con tres etapas iniciales: concepto del software, anlisis de requerimientos y diseo global, las cuales se realizan linealmente, y luego propone separar el proyecto global en subproyectos ms pequeos de forma que las siguientes fases: el diseo detallado, la codificacin y depuracin, y las pruebas iniciales se realicen linealmente para cada subproyecto definido, logrando as que cada subproyecto se desarrolle llevando a cabo tareas y tcnicas particulares de acuerdo a sus respectivas necesidades. La etapa final de la metodologa consiste en llevar a cabo la integracin de los subproyectos y la realizacin de pruebas globales. Concepto del software: Anlisis o o Requisitos del sistema: Requisitos del software:

Diseo de arquitectura:

44

Diseo detallado: Codificacin: Pruebas:

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Es ideal en proyectos donde se cuenta con un plantel de programadores numerosos. Adecuada para el desarrollo de proyectos complejos de 1 a 3 aos de desarrollo.

44

1.6. CICLO DE LA VIDA ITERATIVO. Tambin derivado del ciclo de vida en cascada, este modelo busca reducir el riego que surge entre las necesidades del usuario y el producto final por malos entendidos durante la etapa de solicitud de requerimientos. Es la iteracin de varios ciclos de vida en cascada. Al final de cada iteracin se le entrega al cliente una versin mejorada o con mayores funcionalidades del producto. El cliente es quien luego de cada iteracin, evala el producto y lo corrige o propone mejoras. Estas iteraciones se repetirn hasta obtener un producto que satisfaga al cliente. [Anexo 6], Ventajas: Realizar entregas parciales del producto por partes en un mini proyecto, es ms fcil de gestionar con el usuario los requerimientos de las siguientes versiones. Los requerimientos de alta prioridad para los usuarios pueden ser probadas primero, como en el ejemplo del 80% de una versin de un programa y guardarlo cuando este funciona correctamente, para luego continuar con el resto.

Desventajas: . Se requiere de mucha planificacin para todo el proyecto y con las siguientes versiones a las que el usuario da los requerimientos.

ETAPAS: Anlisis o o Requisitos del sistema: Requisitos del software:

Diseo o o Diseo de Arquitectura: Diseo detallado:

Codificacin: Pruebas:

44

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Se suele utilizar en proyectos en los que los requerimientos no estn claros de parte del usuario, por lo que se hace necesaria la creacin de distintos prototipos para presentarlos y conseguir la conformidad del cliente. Tambin en aplicaciones medianas a grandes en las que el usuario o cliente final no necesita todas las funcionalidades de este principio de proyecto. (Migrar aplicaciones a otra arquitectura.)

44

1.7. CICLO DE LA VIDA POR PROTOTIPOS. El uso de programas prototipo no es exclusivo del ciclo de vida iterativo. En la prctica los prototipos se utilizan para validar los requerimientos de los usuarios en cualquier ciclo de vida. [Anexo 7], Si no se conoce exactamente como desarrollar un determinado producto o cules son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial y provisional. En este modelo, el objetivo es lograr un producto intermedio, antes de realizar el producto final, para conocer mediante el prototipo como respondern las funcionalidades previstas para el producto final. 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 iterativamente al ir aumentando la comprensin que del sistema tienen los usuarios y quien lo desarrolla. Antes de adoptar este modelo de ciclo de vida se debe evaluar si el esfuerzo por crear un prototipo vale realmente la pena adoptarlo. Ventajas: Permite suavizar la transaccin entre los requerimientos iniciales y finales que surgen en la creacin del proyecto con grandes innovaciones. 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. Es el nico apto para desarrollos en los que se conoce a priori sus especificaciones o la tecnologa a utilizar.

Desventajas: Es altamente costoso y difcil para la administracin temporal. Debe desarrollarse rpidamente, nfasis en la interfaz de usuario. Equipo de desarrollo reducido.

44

El desarrollador puede caer en la tentacin de ampliar el prototipo para construir el sistema final sin tener en cuenta los compromisos de calidad y de mantenimiento que tiene con el cliente.

ETAPAS: Concepto del software: Anlisis o o Requisitos del sistema: Requisitos del software:

Diseo o o Diseo de arquitectura: Diseo detallado:

Codificacin: Pruebas:

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Se utiliza en importantes. desarrollos de productos con innovaciones

En el uso de tecnologas nuevas o poco probadas, en las que la incertidumbre sobre los resultados o la ignorancia sobre el comportamiento, impiden iniciar un proyecto secuencia.

44

1.8. CICLO DE LA VIDA EVOLUTIVO. Este modelo acepta que los requerimientos del usuario pueden cambiar en cualquier momento. Es decir busca reemplazar el viejo sistema con uno nuevo que tendra la propiedad de satisfacer los nuevos requerimientos lo mas rpido posible. El desarrollo evolutivo asume que los requerimientos estn sujetos a cambios continuos y que la estrategia para enfrentar aquello pasa por un reflejo, tambin continuo, de aquellos cambios. [Anexo 8], Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximacin incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que

En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y slo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementacin parcial del sistema que recibe slo estos requerimientos La prctica demuestra que obtener todos los requerimientos al comienzo del proyecto es extremadamente difcil, no solo por la dificultad del usuario de transmitir su idea, sino porque estos requerimientos evolucionan durante el desarrollo y de esta manera, surgen nuevos requerimientos a cumplir. El modelado de ciclo de vida evolutivo afronta este problema mediante una iteracin de ciclos requerimientos, desarrollos, evaluacin. Construccin de una implementacin parcial que cubre los requisitos conocidos, para ir aprendiendo el resto y, paulatinamente, incorporarlos al sistema. Si bien el modelo de prototipos evolutivos, fcilmente modificables y ampliables es muy usado, en muchos casos pueden usarse prototipos descartables para esclarecer aquellos aspectos del sistema que no se comprenden bien. [J.Juzgado, 1996]. Ventajas: Reduce el riesgo y aumenta la probabilidad de xito. Fomenta el ensamblaje (reus) de componentes.

44

Desventajas: No se conocen niveles apropiados de calidad y documentacin. Problemas de gestin de configuracin.

ETAPAS: Concepto del software: Anlisis o o Requisitos del sistema: Requisitos del software:

Diseo o o Diseo de arquitectura: Diseo detallado:

Codificacin: Pruebas: Refinamiento iterativo del prototipo: Refinamiento de las especificaciones del prototipo: Diseo e implementacin del sistema final: Explotacin (u operacin) y mantenimiento:

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Este modelo es apropiado en proyectos donde se desea realizar mejoras para ampliar el alcance del mismo.

44

44

1.9. CICLO DE LA VIDA EN ESPIRAL. Propuesto inicialmente por Boehm en 1988. Consiste en una serie de ciclos que se repiten. Cada uno tiene las mismas fases y cuando termina da un producto ampliado con respecto al ciclo anterior. En este sentido es parecido al modelo incremental, la diferencia importante es que tiene en cuenta el concepto de riesgo. Un riesgo puede ser muchas cosas: requisitos no comprendidos, mal diseo, errores en la implementacin, etc. Una representacin tpica de esta estructura se muestra en el [Anexo
9]

Trata de mejorar los ciclos de vida clsicos y prototipos. Permite acomodar otros modelos, Incorpora objetivos de calidad y gestin de riesgos, Elimina errores y alternativas no atractivas al comienzo, Permite iteraciones, vuelta atrs y finalizaciones rpidas Cada ciclo empieza identificando: Los objetivos de la porcin correspondiente Las alternativas Restricciones Cada ciclo se completa con una revisin que incluye todo el ciclo anterior y el plan para el siguiente. En cada iteracin Boehm recomienda recopilar la siguiente lista de informaciones: Objetivos: Se hacen entrevistas a los clientes, se les hace rellenar cuestionarios, etc. Alternativas: Son las diferentes formas posibles de conseguir los objetivos. Se consideran desde dos puntos de vista o o o Caractersticas del producto. Formas de gestionar el proyecto. Restricciones: Desde el punto de vista del producto: Interfaces de tal o cual manera, rendimiento, etc. Desde el punto de vista organizativo: Coste, tiempo, personal, etc.

Riesgos: Lista de riesgos identificados.

44

Resolucin de riesgos: La tcnica ms usada es la construccin de prototipos. Resultados: Son lo que realmente ha ocurrido despus de la resolucin de riesgos. Planes: Lo que se va a hacer en la siguiente fase. Compromiso: Decisiones de gestin sobre como continuar.

Ventajas: No necesita una definicin completa de los requisitos para empezar a funcionar. Al entregar productos desde el final de la primera iteracin es ms fcil validar los requisitos. El riesgo en general es menor, porque si todo se hace mal, solo se ha perdido el tiempo y recursos invertidos en una iteracin (las anteriores iteraciones estn bien). El riesgo de sufrir retrasos es menor, ya que al identificar los problemas en etapas tempranas hay tiempo de subsanarlos.

Desventajas: Es difcil evaluar los riesgos. Necesita de la participacin continua por parte del cliente. Cuando se subcontrata hay que producir previamente una especificacin completa de lo que se necesita, y esto lleva tiempo.

ETAPAS: Concepto del software: Anlisis o o Requisitos del sistema: Requisitos del software:

Diseo o Diseo de arquitectura:

44

Diseo detallado:

Codificacin: Pruebas:

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Es apropiado en sistemas de gran tamao. Como tambin en proyectos donde sea importante el factor riesgo. As como cuando no sea posible definir al principio todos los requisitos.

44

1.10. CICLOS DE LA VIDA ORIENTADOS A OBJETOS. Los tipos de ciclos de vida que se han visto hasta ahora son relativos al anlisis y diseo estructurados, pero los objetos tienen una particularidad, y es que estn basados en componentes que se relacionan entre ellos a travs de interfaces, o lo que es lo mismo, son mas modulares y por lo tanto el trabajo se puede dividir en un conjunto de mini proyectos. Adems, hoy en da la tendencia es a reducir los riesgos, y en este sentido, el ciclo de vida en cascada no proporciona muchas facilidades. Debido a todo esto, el ciclo de vida tpico en una metodologa de diseo orientado a objetos es iterativo e incremental. La tecnologa de objetos permite acelerar el desarrollo de sistemas de manera iterativa e incremental, permitiendo la generalizacin de los componentes para que sean reutilizables. Piattini [1996] presenta algunos de los modelos propuestos desde esta perspectiva: El modelo de agrupamiento o de clster de Meyer [1990] El modelo fuente de Henderson-Sellers y Edwards [1990] El modelo de pinball de Amler [1994]

Los expertos en tecnologas de objetos, proponen un desarrollo interactivo e incremental, existiendo un ciclo evolutivo del sistema en el sentido anlisisdiseo-instrumentacin-anlisis, que se lleva a cabo en forma iterativa. Algunas metodologas hablan de diseos o metodologas recursivos pero como incrementales. [Piattini,1996] Goldberg [1993], dice que la idea de la integracin incremental es la diferencia clave de cmo debe ser gestionado un proyecto que utiliza tecnologa orientada al objeto. Existen otros modelos de ciclo de vida, que no se han detallado en esta seleccin ya que aunque presenten ciertas potencialidades, no estn muy extendidos. [J. Juzgado, 1996]. En el estndar IEEE 1074-1991 [IEEE, 1991] se detallan las etapas del proceso base de construccin de software. Este estndar determina el conjunto de actividades esenciales (no estn ordenadas en el tiempo),
[Anexo 12]

En este slo se describir un tipo de ciclo de vida orientado a objetos, que es adems el ms representativo, el cual es modelo fuente.

44

1.10.1 MODELO FUENTE.

Fue creado por Henderson-Sellers y Edwards en 1990. Es un tipo de ciclo de vida pensado para la orientacin a objetos y posiblemente el ms seguido. Un proyecto se divide en las fases: [Anexo 10], Planificacin del negocio Construccin: Es la ms importante y se divide a su vez en otras cinco actividades o Planificacin o Investigacin o Especificacin o Implementacin o Revisin Entrega

La primera y la tercera fase son independientes de la metodologa de desarrollo orientado a objetos. Adems de las tres fases, existen dos periodos: Crecimiento: Es el tiempo durante el cual se construye el sistema Madurez: Es el periodo de mantenimiento del producto. Cada mejora se planifica igual que el periodo anterior, es decir, con las fases de Planificacin del negocio, Construccin y Entrega.

Cada clase puede tener un ciclo de vida slo para ella debido a que cada una puede estar en una fase diferente en un momento cualquiera. La ventaja es que permite un desarrollo solapado e iterativo
Ventajas: Eliminan los lmites entre fases, tornndose cada vez ms difusos debido a la naturaleza interactiva del desarrollo orientado al objeto. Permiten una nueva forma de concebir los lenguajes de programacin y su uso e incorporan bibliotecas de clases u otros componentes reutilizables. La forma de trabajo es muy dinmica, debido al alto grado de iteracin solapamiento.

Desventajas: .

ETAPAS:

44

Concepto del software: Anlisis o o Requisitos del sistema: Requisitos del software:

Diseo o o Diseo de arquitectura: Diseo detallado:

Codificacin: Pruebas:

44

1.12. CICLO DE LA VIDA LINEAL. Es el ms sencillo de todos los modelos. Consiste en descomponer la actividad global del proyecto en etapas separadas que son realizadas de manera lineal, es decir, cada etapa se realiza una sola vez, a continuacin de la etapa anterior y antes de la etapa siguiente. Con un ciclo de vida lineal es muy fcil dividir las tareas, y prever los tiempos (sumando linealmente los de cada etapa). Las actividades de casa una de las etapas mencionadas deben ser independientes entre si, es decir, que es condicin primordial que no haya retroalimentacin entre ellas, aun que si pueden admitirse ciertos supuestos de realimentacin correctiva. Desde el punto de vista de la gestin, requiere tambin que se conozca desde el primer momento, con excesiva rigidez, lo que va a ocurrir en cada una de las distintas etapas antes de comenzarla. Esto ltimo minimiza, tambin, las posibilidades de errores durante la codificacin y reduce al mnimo la necesidad de requerir informacin de cliente o del usuario. [Anexo 11], Ventajas: La sencillez del ciclo de vida lineal es por la cual es el ms elegido en el desarrollo de programas pequeos.

Desventajas: No apto para desarrollos que superen mnimamente requerimientos de retroalimentacin entre etapas, es decir es muy costoso retomar una etapa anterior al detectar alguna falla.

ETAPAS: Anlisis: Se determinan los elementos que intervienen en el sistema a desarrollar, su estructura, relaciones, evolucin temporal, funcionalidades, tener una descripcin clara de que producto se va a construir, las funcionalidades que aportara y su comportamiento. Diseo: Determinar cmo se debe hacer (Cmo debe ser construido el sistema en cuestin?); definir en detalle entidades u relaciones de las bases de datos, seleccionar el lenguaje que se va a utilizar, el sistema gestor de bases de datos, etc.

44

Implementacin: Comenzar a codificar algoritmos y estructuras de datos, definidos en las etapas anteriores, en el correspondiente lenguaje de programacin o para un determinado sistema gestor de bases de datos.

Debugging: Garantizar que el programa no contiene errores de diseo o codificacin. En esta etapa no se desea saber si el programa realiza lo que solicito el usuario, esa tarea le corresponde a la etapa de implementacin. En esta etapa se desea encontrar la mayor cantidad de errores. Todos los programas contienen errores: encontrarlos es cuestin de tiempo.

Instalacin:

Aceptacin:

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. Se utiliza en proyectos internos de una empresa para programas muy pequeos como realizar altas, bajas y modificaciones sobre un conjunto de datos..

44

1.13 LA REUTULIZACION DEL CICLO DE LA VIDA. Principios de la reutilizacin:

Ventajas: Existen similitudes entre distintos sistemas de un mismo dominio de aplicacin El software puede representarse como una combinacin de mdulos Disear aplicaciones = especificar mdulos + interrelaciones Los sistemas nuevos se pueden caracterizar por diferencias respecto a los antiguos Reduce tiempos y costes de desarrollo Aumenta la fiabilidad

Desventajas: ETAPAS: Concepto del software: Anlisis o o Requisitos del sistema: Requisitos del software: Dificultad para reutilizables reconocer los componentes potencialmente

Dificultad de catalogacin y recuperacin Problemas de motivacin Problemas de gestin de configuracin

Diseo o Diseo de arquitectura:

44

Diseo detallado:

Codificacin: Pruebas:

TIPOS DE PROYECTOS PARA LOS QUE ES ADECUADO ESTE MODELO. En proyectos los cuales se requiere una modificacin para alargar el ciclo de vida y a su vez optimizar los recursos de las actividades y areas en las cuales participara.

44

2. ELEMENTOS PARA DISEAR Y CONSTRUIR UN SOFTWARE. Principalmente es obtener datos sobre la estructura de los mismos, arquitectura, internases, etc. Se utiliza por los ingenieros del software. Esta fase es importante ya que de aqu se extraen o establece la calidad del software y se pueden hacer las mejoras pertinentes si es necesario sin invocar a pruebas o al cliente. Proceso y calidad del diseo El diseo del software es un proceso iterativo mediante el cual los requerimientos se traducen en un plano para construir el software. Para lograr que un diseo sea presentable se deben seguir ciertas pautas. Caractersticas para la evaluacin o Implementar todos los requisitos explcitos contenidos en el modelo de anlisis, y ajustarse a todos lo requisitos del cliente. o Debe ser una gua legible y comprensible para quienes generan el cdigo y quienes realizan pruebas, es decir, dan soporte al software. o Debe proporcionar una imagen completa del software desde una perspectiva de implementacin.

Cmo alcanzar las metas del proceso? o Un diseo debe presentar una estructura arquitectnica que se halla creado mediante patrones de diseo reconocibles, la integren componentes que exhiban buenas caractersticas de diseo y que pueda implementarse de manera evolutiva para que de estar forma facilite la implementacin y las pruebas. o Un diseo debe ser modular. o Un diseo debe contener distintas representaciones de los datos, la arquitectura, las interfaces y los componentes. o Un diseo debe conducir a estructuras de datos que sean apropiadas para las clases que habrn de implementarse y que procedan de patrones de datos reconocibles. o Un diseo debe conducir a componentes que representan caractersticas funcionales independientes. o Un diseo debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los componentes y el ambiente externo. o Un diseo debe obtenerse por medio de un mtodo repetible que se base en la informacin obtenida durante el anlisis de requisitos del software.

44

Un diseo debe representarse por medio de una notacin que comunique de manera eficaz su significado. Caractersticas o La funcionalidad. o La facilidad. o La confiabilidad. o El desempeo. o La soportabilidad, la adaptabilidad y la servicialidad. Definiciones del diseo o La abstraccin es una de las formas fundamentales en las que los humanos se enfrentan a la complejidad. La arquitectura es la estructura u organizacin de los componentes del programa mdulos, la manera en que estos componentes interactan, y la estructura de datos que utilizan los componentes. o Los patrones describen una estructura de diseo que resuelve un problema de diseo particular dentro de un contexto especifico y en medio de fuerzas que pueden tener un impacto en la manera en la que se aplica y utiliza el patrn, de manera tal que el diseador pueda decidir si este es el necesario o el que puede usar para su trabajo actual. o La modularidad, el software se divide en componentes con nombres independientes y que es posible maniobrar de forma individual. Estos componentes llamados mdulos se integran para satisfacer los requisitos del problema. o La ocultacin de la informacin sugiere que los mdulos se caracterizan por las decisiones de diseo que oculta a los otros. En otras palabras el mdulo debe disearse de forma que la informacin sea inaccesible para otro mdulo que no necesite esta informacin. o La independencia funcional surge como resultado de la suma directa de la modularidad y de los conceptos de abstraccin y ocultacin de informacin pues cada mdulo del software debe ser capaz de funcionar por si solo. Refinamiento es un proceso de elaboracin. o Se inicia con el enunciado de una funcin o descripcin de los datos que se define como un alto grado de abstraccin. o Este describe los datos o funcin de manera conceptual pero no proporciona informacin acerca de los trabajos internos de la funcin o estructura interna de los datos.

44

El refinamiento hace que el diseador trabaje sobre el enunciado original y que proporcione ms y ms detalles conforme se realiza cada refinamiento sucesivo.

Re fabricacin tcnica de reorganizacin que simplifica el diseo (o cdigo) de un componente sin cambiar su funcin o comportamiento, dicho de otra manera, "es el proceso de cambiar un sistema de software de tal forma que no altere el comportamiento externo de su cdigo (diseo) y aun as se mejore su estructura interna". Tipos de patrones o Arquitectnicos definen la estructura general del software, relaciones entre los subsistemas y los componentes de software, y las reglas para especificar las relaciones entre los elementos de la arquitectura. o De diseo agregado de componentes que se aplica a un elemento especifico para resolver problemas de diseo, relaciones. o Idiomas (patrones de cdigo) patrones especficos de lenguajes por lo general implementan un algoritmo, un protocolo de interfaz entre los componentes. Clases de diseo o Las clases de interfaz con el usuario definen las abstracciones necesarias para la interaccin humano-computadora. o Las clases del dominio de negocios proceso de refinamiento de las clases anteriores, donde se identifican los atributos y servicios necesarios para implementar algn elemento del dominio de negocios. o Las clases del proceso implementan abstracciones del negocio en un nivel ms bajo, las cuales se requieren para el manejo de las clases del dominio de negocio. o Las clases persistentes representan almacenamientos de datos que persistirn ms all de la ejecucin el software. o Las clases de sistema implementan las funciones que permite que el sistema opere y se comunique dentro de su entorno de computacin y con el mundo exterior. Caractersticas de una clase de diseo o Completa y suficiente una clase de diseo debe ser la encapsulacin completa de todos los atributos y mtodos que se pueden esperar, en forma razonable, que existan para la

44

clase, es decir, que debe contener los mtodos aquellos que sean suficientes para lograr el objetivo ni ms ni menos. Primitivismo, los mtodos asociados a una clase de diseo deben enfocarse en el cumplimiento de un servicio para la clase. Una vez que el servicio ha sido implementado con un mtodo, la clase no debe proporcionar otra forma de complementar la misma. Cohesin alta, una clase de diseo cohesiva tiene un conjunto de responsabilidades pequeo y enfocado, y aplica atributos y mtodos de manera sencilla para implementar dichas responsabilidades. Acoplamiento bajo dentro del modelo de diseo es necesario que las clases de diseo colaboren con alguna otra. Sin embargo, la colaboracin se debe mantener en un mnimo aceptable. Si un modelo de diseo tiene un acoplamiento alto, el sistema es difcil de implementar, probar y mantener a travs del tiempo. En general las clases de diseo dentro de un subsistema deben tener solo un conocimiento limitado de las clases en otros subsistemas. Esta restriccin, llamada la Ley de Demter, sugiere que un mtodo solo debe enviar mensajes a mtodos de clases vecinas.

44

CONCLUSION

Finalmente puedo concluir que bajo la gran variedad de ciclos de vida que existen en la actualidad para el desarrollo o bien arquitectura, creacin e implementacin de un software, es muy importante el investigar bien cules son los objetivos del cliente, y a su vez saber y conocer bien cules son las herramientas con las que se cuenta ya que con el correcto anlisis de estos dos factores se puede muy bien definir el tipo de ciclo de vida de software se puede implementar, en realidad no hay un tipo de ciclo de vida de software que se pueda aplicar a cualquier proyecto, por lo cual es importante saber bien definir los componentes del proyecto mediante la documentacin como, requerimientos, entrevistas, minutas, las cuales deben ser plasmadas en papel y en lenguaje natural entendibles tanto para el cliente como para cualquier otra persona que en su momento llegue a tener la necesidad de leer esa informacin ya sea en el presente o en el futuro, de igual forma se tiene que tomar mucho en cuenta al momento de escoger el tipo de ciclo de vida, si realmente es necesario el mismo. En mi caso personal, detecte que uno de los tipos de Ciclo de Vida del Software que mas da la opcin de un control ms exacto y la implementacin dentro del mismo de otros ciclos, es el de espiral.

44

ANEXOS

44

44

44

44

44

44

44

44

En el estndar IEEE 1074-1991 (IEEE, 1991) se detallan las fases del proceso base de construccin de software, este estndar determina el conjunto de actividades esenciales que deben ser incorporadas dentro de un modelo de ciclo de vida del software y la documentacin involucrada, pero estas actividades no estn ordenadas en el tiempo. Para desarrollar un proyecto de software es necesario establecer un enfoque disciplinado y sistemtico. Las metodologas de desarrollo influyen directamente en el proceso de construccin y se elaboran a partir del marco definido por uno o ms ciclos de vida. (Plattini, 1996) http://www.docstoc.com/docs/26622026/IEEE-Std-1074-1991-(Recognized-byANSI)-IEEE-Standard-for

44