Ciclo de Vida

Todo proyecto de desarrollo de software tiene como fin la obtencin de un

producto o servicio que es necesario generar a travs de diversas actividades.
Dichas actividades deben estar bien fundamentadas y descritas en cada una
de las diferentes secciones del mismo.
La naturaleza del proyecto definir las tareas a realizar como tambin las
caractersticas del entorno en el que se vaya a desarrollar e implementar, es
as como se deben elegir los mtodos y herramientas ms adecuados en cada
momento para satisfacer las necesidades especficas del proyecto y establecer
las medidas oportunas que permitan controlar su evolucin.
Algunas de estas actividades pueden agruparse en fases, pues contribuyen a
obtener un producto intermedio necesario para continuar hacia el producto final
facilitando la gestin del proyecto. Al conjunto de estas fases empleadas se le
denomina ciclo de vida.
Es necesario que las actividades satisfagan el tiempo de entrega pactado con
el cliente sin comprometer la calidad del producto final; para facilitar una
metodologa comn entre el cliente y la compaa de software, los modelos de
ciclo de vida se han ido actualizando para reflejar las etapas de desarrollo
involucradas y la documentacin requerida. Al final de cada etapa se arreglan
las revisiones de manera que los involucrados evalen si se cumple con los
objetivos.
Existen distintas formas de organizar el orden concreto en el que se
acometern las distintas etapas del ciclo de vida y es deber de quien desarrolla
el software elegir la ms adecuado conforme a las caractersticas del proyecto.
Modelo en cascada

Ciclo de vida clsico, tambin denominado "modelo en cascada", su
caracterstica primordial es que no se comienza con un paso hasta que no se
ha terminado el anterior. Conduce en orden, de una etapa a la siguiente slo
tras finalizar con xito las tareas de verificacin y validacin propias; si resulta
necesario, nicamente se da marcha atrs hasta la fase inmediatamente
anterior.
Este modelo tradicional de ciclo de vida exige una aproximacin secuencial al
proceso de desarrollo del software, el principal problema de esta aproximacin
es el que no podemos esperar el que las especificaciones inciales sean
correctas, completas y que el usuario mantenga su opinin sobre una u otra
caracterstica; normalmente, es difcil para el cliente establecer explcitamente
todos los requerimientos al comienzo del proyecto (hasta que no vea
evolucionar el proyecto no tendr una idea clara de qu es lo que realmente
quiere).
Lo que puede resultar contraproducente es que cualquier cambio o decisin
tomada errneamente en las etapas iniciales del proyecto supondr un coste
adicional significativo, tanto econmico como temporal (retraso en la fecha de
entrega).
Como es evidente esto es solo un modelo terico, si el usuario cambia de
opinin en algn aspecto tendremos que volver hacia atrs en el ciclo de vida.



Modelo de Prototipado

Anteriormente manifestamos lo perjudicial que puede ser que el cliente no
establezca los requerimientos del proyecto de una forma precisa, sin embargo,
normalmente define un conjunto general de objetivos para el sistema a
construir, a pesar de no ser detallados.
Puede surgir que, aun teniendo las caractersticas del entorno en el que se
vaya a desarrollar, exista incertidumbre con respecto a la eficiencia del
algoritmo, la capacidad o la forma en que debe disearse la interfaz. En
cualquiera de estas situaciones, resulta adecuado construir un prototipo.

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; esto es dado a que los usuarios o clientes experimentan con el
prototipo y proveen la retroalimentacin sobre lo que a ellos les gust y no les
gust acerca del prototipo, capturando la especificacin de requerimientos para
el desarrollo del sistema real.
Puede ser usado como parte de la fase de requerimientos (determinar
requerimientos) o justo antes de la fase de requerimientos (como predecesor
de requerimientos).
As como desarrollo de prototipos reduce el riesgo de que nuestro proyecto
fracase y facilita la especificacin de requerimientos tambin tiene sus
inconvenientes: el cliente puede pensar que el prototipo es el sistema definitivo,
ignorando que un prototipo no es un sistema acabado aunque tenga el mismo
aspecto externo; esto puede conducir a la consolidacin de aspectos de baja
calidad de un prototipo en el sistema final que se entrega si el prototipo no se
desecha a tiempo.
A veces, los prototipos desechables no se llegan a desechar. Pero los
prototipos no siempre son desechables. En tal caso, estaremos utilizando un
modelo iterativo de refinamiento de prototipos en el que, tras varias iteraciones,
seremos capaces de construir un sistema que se adapte mejor a las
necesidades de nuestro cliente.



Modelos iterativos

Los modelos iterativos consisten en descomponer un proyecto de desarrollo de
software en una serie de subproyectos de menor extension. Tales diseos de
estos subproyectos deben aportar funcionalidad nueva para el sistema desde el
punto de vista del usuario final.
Usualmente, se establecen prioridades entre los requerimientos iniciales del
sistema para decidir qu parte del mismo se construir primero.
Los modelos iterativos de desarrollo de software permiten adelantar el
momento en el que se determina si un proyecto es tcnicamente viable o no
(con lo que se eliminan costes innecesarios si, finalmente, el proyecto hubiese
de cancelarse).
Fomenta una mejor comunicacin con el usuario/cliente, ya que se dispondr
antes de una versin operativa del sistema, aunque sea de funcionalidad
reducida. Estas versiones intermedias del producto ayudan a la eliminacin de
malentendidos que pueden surgir en la etapa de adquisicin de requerimientos.
Adems, ayudan a que el usuario se forme una idea ms clara de lo que
realmente necesita.




Modelo espiral

El modelo en espiral de Barry Boehm hace especial hincapi en la prevencin
de riesgos.
Las actividades de este modelo se conforman en una espiral, en la que cada
bucle o iteracin representa un conjunto de actividades. Las actividades no
estn fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin
del anlisis de riesgo, comenzando por el bucle interior.
Este modelo define cuatro actividades principales: planificacin (determinar los
objetivos y restricciones del proyecto), anlisis de riesgos (anlisis de
alternativas e identificacin de riesgos), ingeniera (desarrollo del producto) y
evaluacin (revisin por parte del cliente y valoracin de los resultados
obtenidos). En cada iteracin alrededor de la espiral se construyen versiones
cada vez ms completas del software.



Secuencial o iterativo?

El modelo de desarrollo ms adecuado para un proyecto depender del tipo de
sistema que se ha de construir:
Se elegira un modelo secuencial cuando los requerimientos se conocen
bastante bien y son estables, cuando el diseo ser similar al de otros sistemas
con los que tenemos experiencia, y exista familiarizacin con el entorno de
desarrollo, o cuando el coste de tener que cambiar algo en las etapas finales
del proyecto resultara prohibitivo.
En la prctica, los modelos iterativos se adaptan mejor a la realidad del
desarrollo de software. Nos inclinaremos por un modelo iterativo cuando los
requerimientos no se conocen con exactitud o se prev que puedan cambiar en
el futuro, cuando el diseo del sistema es complejo o no tiene precedentes para
nosotros, cuando el proyecto en s es arriesgado econmicamente y cuando
podamos controlar el coste de futuros cambios en el sistema.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en nmero variable segn el proyecto y en las que se hace un
mayor o menor hincapi en las distintas actividades.
Las primeras iteraciones (en las fases de Formulacion y Elaboracin) se
plantea la comprensin del problema, la delimitacin del mbito del proyecto y
eliminacin de los riesgos crticos. Durante la Formulacion las iteraciones
hacen mayor nfasis en actividades de modelado del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se sitan al desarrollo de la lnea
base de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo
de negocios, anlisis, diseo y una parte de implementacin orientado a la
arquitectura.
En la fase de construccin, se lleva a cabo la construccin del producto por
medio de una serie de iteraciones. Para cada iteracin se refinan su anlisis y
diseo y se procede a su implementacin y pruebas. Se realiza una pequea
cascada para cada ciclo, las iteraciones ocurren hasta que se termine la
implementacin de la nueva versin del producto.
En la fase de transicin se busca garantizar que se tiene un producto
preparado para su entrega a la comunidad de usuarios.