Ciclo de vida del software

El trmino ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase final. El propsito de este programa es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicacin, es decir, para garantizar que el software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de desarrollo: se asegura de que los mtodos utilizados son apropiados. Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se detectan tarde dentro de la fase de implementacin. El ciclo de vida permite que los errores se detecten lo antes posible y por lo tanto, permite a los desarrolladores concentrarse en la calidad del software, en los plazos de implementacin y en los costos asociados.

El ciclo de vida bsico de un software consta de los siguientes procedimientos

Definicin de objetivos Anlisis de los requisitos y su viabilidad Diseo general Diseo en detalle Programacin Prueba de unidad Integracin Prueba beta (o validacin), Documentacin Mantenimiento Definir el resultado del proyecto y su papel en la estrategia global. Recopilar, examinar y formular los requisitos del cliente y examinar cualquier restriccin que se pueda aplicar. Requisitos generales de la arquitectura de la aplicacin. Definicin precisa de cada subconjunto de la aplicacin. (Programacin e implementacin): es la implementacin de un lenguaje de programacin para crear las funciones definidas durante la etapa de diseo. Prueba individual de cada subconjunto de la aplicacin para garantizar que se implementaron de acuerdo con las especificaciones. Para garantizar que los diferentes mdulos se integren con la aplicacin. ste es el propsito de la prueba de integracin que est cuidadosamente documentada. Para garantizar que el software cumple con las especificaciones originales. Sirve para documentar informacin necesaria para los usuarios del software y para desarrollos futuros. Para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicacin dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores.

OBJETIVOS DE CADA ETAPA Expresin de Necesidades Especificaciones Anlisis

Esta etapa tiene como objetivo el armado de un documento en el cual se reflejan los requerimientos y funcionalidades que ofrecer al usuario el sistema a implementar ( que, y no como se va implementar) Formalizamos los requerimientos, el documento obtenido en la etapa anterior se tomara como punto de partida para esta etapa. Determinamos los elementos que intervienen en el sistema a desarrollar, su estructura, relaciones, evolucin temporal, funcionalidades, tendremos una descripcin clara de que producto vamos a construir, que funcionalidades aportara y que comportamiento tendr. Ya sabemos que hacer, ahora tenemos que determinar cmo debemos hacerlo (Cmo debe ser construido el sistema en cuestin? Definimos en detalle entidades y relaciones de las bases de datos, seleccionamos el lenguaje que vamos a utilizar, el sistema Gestor de Base de Datos. Empezamos 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. En muchos proyectos se pasa directamente a esta etapa, son proyectos muy arriesgados que adoptan un modelo de ciclo de vida de Code & fix ( codificar y corregir) donde se eliminan las etapas de especificaciones, anlisis y diseo consiguiente prdida de control sobre la gestin del proyecto El objetivo de esta etapa es garantizar que nuestro programa no contiene errores de diseo o codificacin. En esta etapa no deseamos saber si nuestro programa realiza lo que solicito el usuario, esa tarea le corresponde a la etapa de implementacin. En esta deseamos encontrar la mayor cantidad Esta etapa tiene como objetivo la verificacin de que el sistema desarrollado cumple con los requerimientos expresados inicialmente por el cliente y que han dado lugar al proyecto. En muchos proyectos las etapas de validacin y debugging se realiza en paralelo por la estrecha relacin que llevan., sin embargo debemos evitar la confusin: podemos realizarlo en paralelo, pero no como nica etapa. En la mayora de los procesos se considera esta etapa se considera esta etapa como mantenimiento y evolucin y se le asigna, no solo el agregado de nuevas funcionalidades (evolucin), sino la correccin de errores que surgen (mantenimiento. En la prctica esta denominacin no es de todo errnea, ya que es posible que aun luego de una etapa.

Diseo

Implementacin

Debugging

Validacin

Evolucin

Modelos de Ciclo de Vida

Las principales diferencias entre distintos modelos de vida estn divididas entre 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 ms las actualizaciones y el mantenimiento. La cualidad y cantidad de las etapas: En que dividiremos el ciclo de vida: segn el ciclo de vida que adoptemos, y el proyecto para el cual adoptemos. La estructura y la sucesin de las etapas, si hay realimentacin entre ellas, si tenemos libertad de repetirlas.

Modelo Cascada Este es el ms bsico de todos los modelos, y sirve como bloque de construccin para los dems modelos de ciclo de vida. La visin del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a travs de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfaccin de metas de esa fase o quizs a una subsecuencia de metas de la fase. Las flechas muestran el flujo de informacin entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrs representan la retroalimentacin. El modelo de ciclo de vida cascada, captura algunos principios bsicos:

Planear un proyecto antes de embarcarse en l. Definir el comportamiento externo deseado del sistema antes de disear su arquitectura interna. Documentar los resultados de cada actividad. Disear un sistema antes de codificarlo. Testear un sistema despus de construirlo.

Modelo De Desarrollo Incremental Este modelo de ciclo de vida se basa en la filosofa de construir incrementando las funcionalidades del programa. Se realiza construyendo mdulos que cumplen las diferentes funciones del

sistema. Esto permite ir aumentando gradualmente las capacidades del software. 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, como se muestra en la figura. 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. Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo. 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.

Modelo De Desarrollo Evolutivo Este modelo acepta que los requerimientos del usuario pueden cambiar en cualquier momento. La practica nos muestra que obtener 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 del desarrollo y de esta manera surgen nuevos requerimientos a cumplir. 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 los requerimientos no son completamente conocidos al inicio del proyecto. 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. El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentacin a los desarrolladores. Basada en esta retroalimentacin, la especificacin de requerimientos es actualizada, y una segunda versin del producto es desarrollada y desplegada. El proceso se repite indefinidamente. Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma especfica de observar el desarrollo de algn incremento. As, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado tambin. Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado. El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulacin de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentacin debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.

Modelo de Prototipado de Requerimientos. El prototipado de requerimientos es la creacin de una implementacin parcial de un sistema, para el propsito explcito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rpida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentacin sobre lo que a ellos les gust y no les gust acerca del prototipo proporcionado, quienes capturan en la documentacin actual de la especificacin de requerimientos la informacin entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algn o todo el desarrollo incremental en modelos incremental o evolutivo. El Prototipado ha sido usado frecuentemente en los 90, porque la especificacin de requerimientos para sistemas complejos tienden a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho ms fcil proveer retroalimentacin convenientemente basada en la manipulacin, leer una especificacin de requerimientos potencialmente ambigua y extensa. Diferente del modelo evolutivo donde los requerimientos mejor entendidos estn incorporados, un prototipo generalmente se construye con los requerimientos entendidos ms pobremente. En caso que ustedes construyan requerimientos bien entendidos, el cliente podra responder con "s, as es", y nada podra ser aprendido de la experiencia.

Modelo Espiral El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Adems, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos: Determinar qu quieres lograr.

una, analizar los riesgos y resultados finales, y seleccionar la mejor.

ecer qu tienes terminado. La dimensin radial en la figura refleja costos acumulativos incurridos en el proyecto. Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situacin y determinamos que los mayores riesgos son la interfaz del usuario. Despus de un cuidadoso anlisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificacin de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de accin es construir un prototipo. Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentacin til. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer slo despus de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximacin es construir un incremento del sistema que satisfaga slo los requerimientos mejor entendidos. Hagmoslo ya. Despus del despliegue, el cliente nos provee de retroalimentacin que dir si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarn en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza. El modelo espiral captura algunos principios bsicos:

Decidir qu problema se quiere resolver antes de viajar a resolverlo. Examinar tus mltiples alternativas de accin y elegir una de las ms convenientes. Evaluar qu tienes hecho y qu tienes que haber aprendido despus de hacer algo.

No ser tan ingenuo para pensar que el sistema que ests construyendo ser "EL" sistema que el cliente necesita, y Conocer (comprender) los niveles de riesgo, que tendrs que tolerar. El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible.

Modelo Concurrente Como el modelo espiral, el modelo concurrente provee una meta-descripcin del proceso software. Mientras que la contribucin primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribucin del modelo concurrente es su capacidad de describir las mltiples actividades del software ocurriendo simultneamente. Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algn tiempo del proceso de desarrollo de software. Discutamos un poco tales casos: Los requerimientos son usualmente "lneas de base", cuando una mayora de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseo. Sin embargo, una vez que comienza el diseo, cambios a los requerimientos son comunes y frecuentes (despus de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados tambin). Es desaconsejado detener el diseo en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer lneas de base de los requerimientos mientras progresa el diseo. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseo puede no ser afectado, medianamente afectado o se requerir comenzar todo de nuevo. Durante el diseo de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseo detallado en esos componentes estables. Similarmente, durante el diseo detallado, puede ser posible proceder con la codificacin y quizs regular testeando en forma unitaria o realizando testeo de integracin previo a llevar a cabo el diseo detallado de todos los componentes. En algunos proyectos, mltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantencin de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantencin sobre un componente 2, mientras que se est haciendo codificacin sobre un componente 3, mientras se realiza diseo sobre una etapa 4, y especificacin de requisitos sobre un componente 5. En todos estos casos, diversas actividades estn ocurriendo simultneamente. Eligiendo seguir un proyecto usando tcnicas de modelacin concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto.

Modelo V

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos utilizados para probar si la aplicacin cumple las especificaciones ya deben haberse creado en la fase de diseo.