Ciclo de Vida del Software

Un modelo de ciclo de vida define el estado de las fases a travs de las cuales se mueve un
proyecto de desarrollo de software.
El primer ciclo de vida del software, "Cascada", fue definido por Winston Royce a fines del 70.
Desde entonces muchos equipos de desarrollo han seguido este modelo. Sin embargo, ya
desde 10 a 15 aos atrs, el modelo cascada ha sido sujeto a numerosas crticas, debido a
que es restrictivo y rgido, lo cual dificulta el desarrollo de proyectos de software moderno. En
su lugar, muchos modelos nuevos de ciclo de vida han sido propuestos, incluyendo modelos
que pretenden desarrollar software ms rpidamente, o ms incrementalmente o de una forma
ms evolutiva, o precediendo el desarrollo a escala total con algn conjunto de prototipos
rpidos.
Definicin de un Modelo de Ciclo de Vida
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el
desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de
transicin asociadas entre estas etapas.
Un modelo de ciclo de vida del software:
Describe las fases principales de desarrollo de software.
Define las fases primarias esperadas de ser ejecutadas durante esas fases.
Ayuda a administrar el progreso del desarrollo, y
Provee un espacio de trabajo para la definicin de un detallado proceso de desarrollo de software.
As, los modelos por una parte suministran una gua para los ingenieros de software con el fin
de ordenar las diversas actividades tcnicas en el proyecto, por otra parte suministran un
marco para la administracin del desarrollo y el mantenimiento, en el sentido en que permiten
estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
Alternativas de Modelos de Ciclo de Vida
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 contribuye 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.
Una de las contribuciones ms importantes del modelo cascada es para los administradores,
posibilitndoles avanzar en el desarrollo, aunque en una escala muy bruta.
Modelo De Desarrollo 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, 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
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 basado en la manipulacin, desde un prototipo, en vez de 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.
Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los
riesgos y resultados finales, y seleccionar la mejor.
Seguir la alternativa seleccionada en el paso 2.
Establecer 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.

La solucin de problemas haciendo uso de herramientas computacionales requiere de una serie
de pasos que permitan una evolucin coherente y progresiva, para ir desde el problema
planteado, hasta hallar una solucin interpretable en el computador, la cual se denomina
programa.
Para realizar esta transicin, es necesario tomar algunos elementos de la Ingeniera del Software
que nos permitirn de una manera sistemtica comprender los diferentes aspectos necesarios
para producir una solucin de software y as llegar a la solucin.

INGENIERA DEL SOFTWARE
La ingeniera del software permite al diseador de programas, realizar su tarea de construccin
de software como un problema de ingeniera haciendo uso de guas, principios y normas que le
permitirn el correcto desarrollo de su labor. Adicionalmente, dispondr de un conjunto de
herramientas que le permitirn la evaluacin, validacin, depuracin y correccin del software
desarrollado.

CICLO DE VIDA DEL SOFTWARE
Es la forma mediante la cual se describen los diferentes pasos que se deben seguir para el
desarrollo de un software, partiendo desde una necesidad hasta llegar a la puesta en marcha de
una solucin y su apropiado mantenimiento. El ciclo de vidapara un softwarecomienza cuando se
tiene la necesidad de resolver un problema, y termina cuando el programa que se desarrollpara
cumplir con los requerimientos, deja de ser utilizado.
Existen varias versiones del ciclo de vida del software entre las cuales se destacan: el ciclo de
vida clsico o en cascada, el modelo en espiral, el desarrollo de prototipos, el modelo por
incrementos y el modelo extremo [6].

ETAPAS DEL CICLO DE VIDA DEL SOFTWARE
El ciclo de vida clsico del software siendo uno de los ms utilizados tal como lo plantean
diferentes autores, est conformado en su versin ampliada por siete etapas que se pueden
representar mediante un modelo en cascada as:

- INGENIERA DE SISTEMAS: En esta etapa el analista luego de unminucioso y detallado estudio
de los sistemas de una organizacin, detecta un problema o una necesidad que para su solucin
y/o satisfaccin es necesario realizar un desarrollo de software.
- ANLISIS: En esta etapa se debe entender y comprender de forma detallada cual es la
problemtica a resolver, verificando el entorno en el cual se encuentra dicho problema, de tal
manera que se obtenga la informacin necesaria y suficiente para afrontar su respectiva
solucin. Esta etapa es conocida como la del QU se va a solucionar.
- DISEO: Una vez que se tiene la suficiente informacin del problema a solucionar, es
importante determinar la estrategia que se va a utilizar para resolver el problema. Esta etapa es
conocida bajo el CMO se va a solucionar.
- IMPLEMENTACIN: partiendo del anlisis y diseo de la solucin, en esta etapa se procede a
desarrollar el correspondiente programa que solucione el problema mediante el uso de una
herramienta computacional determinada.
- PRUEBAS: Los errores humanos dentro de la programacin de los computadores son muchos y
aumentan considerablemente con la complejidad del problema. Cuando se termina de escribir un
programa de computador, es necesario realizar las debidas pruebas que garanticen el correcto
funcionamiento de dicho programa bajo el mayor nmero de situaciones posibles a las que se
pueda enfrentar.
- DOCUMENTACIN: Es la gua o comunicacin escrita en sus diferentes formas, ya sea en
enunciados, procedimientos, dibujos o diagramas que se hace sobre el desarrollo de un
programa. La importancia de la documentacin radica en que a menudo un programa escrito por
una persona, es modificado por otra. Por ello la documentacin sirve para ayudar a comprender
o usar un programa o para facilitar futuras modificaciones (mantenimiento).
La documentacin se compone de tres partes:
a. Documentacin Interna: Son los comentarios o mensajes que se aaden al cdigo fuente para
hacer ms claro el entendimiento de los procesos que lo conforman, incluyendo las
precondiciones y las poscondiciones de cada funcin.
b. Documentacin Externa: Se define en un documento escrito con los siguientes puntos:
Descripcin del Problema
Datos del Autor
Algoritmo (diagrama de flujo o Pseudocdigo)
Diccionario de Datos
Cdigo Fuente (programa)
c. Manual de Usuario: Describe paso a paso la manera como funciona el programa, con el fin de
que el usuario lo pueda manejar para que obtenga el resultado deseado.
- MANTENIMIENTO: una vez instalado un programa y puesto en marcha para realizar la solucin
del problema previamente planteado o satisfacer una determinada necesidad, es importante
mantener una estructura de actualizacin, verificacin y validacin que permitan a dicho
programa ser til y mantenerse actualizado segn las necesidades o requerimientos planteados
durante su vida til. Para realizar un adecuado mantenimiento, es necesario contar con una
buena documentacin del mismo.
Para terminar de entender la problemtica en la cual se desarrolla este libro es importante tener
unos conceptos claros y precisos de lo que es el Anlisis y el Diseo de Algoritmos.

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: definir el resultado del proyecto y su papel en la estrategia global.
Anlisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del
cliente y examinar cualquier restriccin que se pueda aplicar.
Diseo general: requisitos generales de la arquitectura de la aplicacin.
Diseo en detalle: definicin precisa de cada subconjunto de la aplicacin.
Programacin (programacin e implementacin): es la implementacin de un lenguaje de
programacin para crear las funciones definidas durante la etapa de diseo.
Prueba de unidad: 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. ste es
el propsito de la prueba de integracin que est cuidadosamente documentada.
Prueba beta (o validacin), 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.
Implementacin
Mantenimiento: 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.
Modelos de ciclo de vida
Para facilitar una metodologa comn entre el cliente y la compaa de software, los modelos de
ciclo de vida se han actualizado para reflejar las etapas de desarrollo involucradas y la
documentacin requerida, de manera que cada etapa se valide antes de continuar con la siguiente
etapa. Al final de cada etapa se arreglan las revisiones de manera que (texto faltante).
Modelo en cascada
El modelo de ciclo de vida en cascada comenz a disearse en 1966 y se termin alrededor de
1970. Se define como una secuencia de fases en la que al final de cada una de ellas se rene la
documentacin para garantizar que cumple las especificaciones y los requisitos antes de pasar a la
fase siguiente: