CAPITULO 2.

CICLO DE VIDA EN
EL DESARROLLO DE SOFTWARE.
El anlisis, diseo y la implementacin de un sistema, significa estudiar y
disear sistemas para recolectar, almacenar, procesar y distribuir cuyo objetivo es
brindar informacin para que en una organizacin se planifique, se decida y se
sealice.
El profesional de sistemas tiene herramientas para trabajar, es decir, una
metodologa de trabajo, que se conoce como metodologa para el anlisis y diseo
de sistemas de informacin. Esta metodologa bsicamente tiene:
Fases o etapas (Ciclo de vida).
Tcnicas para:
o Obtener informacin
o Documentar informacin
La metodologa es un conjunto de actividades a realizar y esas actividades
son llevadas adelante con un conjunto de tcnicas. Las actividades se agrupan en
fases. Las fases y etapas son llamadas ciclos de vida o metodologa.
Ciclo de vida del desarrollo de sistemas.
El desarrollo de sistemas es un proceso que consiste en dos etapas
principales de anlisis y diseo de sistemas; comienza cuando la gerencia, o en
algunas ocasiones el personal de desarrollo de sistemas, se da cuenta de que
cierto sistema del negocio necesita mejorarse. El ciclo de vida del desarrollo de
sistemas es el conjunto de actividades de los analistas, diseadores y usuarios,
que necesitan llevarse a cabo para desarrollar y poner en marcha un sistema de
informacin.
Es esencial definir previamente los requisitos de todos los elementos del
sistema, as como un modelo de vida para cada uno de los proyectos de
programacin, puesto que permite clasificar y controlar las diferentes actividades
necesarias para el desarrollo y mantenimiento del producto.
Etapas del ciclo de vida de un sistema.
El ciclo de vida del producto de programacin se divide en una serie de
actividades sucesivas; cada fase requiere informacin de entrada, procesos y
resultados, bien definidos. El ciclo de vida del desarrollo de sistemas consiste en
las siguientes actividades:
1. Definicin y Planificacin del Proyecto.
2. Anlisis del Sistema (Determinacin de requerimientos).
3. Diseo del sistema.
4. Codificacin, Programacin, Implementacin o Desarrollo del
software.
5. Prueba o Testeo del Sistema.
6. Implantacin.
7. Mantencin.
Mtodos de desarrollo de Software.
Los mtodos de desarrollo de software pueden dividirse en dos grupos:
funcin/dato y orientados a objetos.
Orientado a Funcin/Dato.
Aquellos mtodos en los cuales las funciones y/o los datos son tratados
como entidades independientes. Estos sistemas resultan difciles de mantener.
El mayor problema es que las funciones generalmente dependen de la
estructura de los datos. A menudo diferentes tipos de datos tienen distintos
formatos y se necesita verificar el tipo del dato (con sentencias If-Then o CASE),
produciendo programas difciles de leer y modificar. Si se desea hacer alguna
modificacin en la estructura de los datos se debe modificar en todos los lugares
donde es utilizado.
Otro problema es que una persona no piensa naturalmente en trminos de
una estructura. La especificacin de requerimientos se hace en lenguaje comn,
se especifica la funcionalidad que debe tener el sistema y no en cmo se deben
estructurar los datos.
Orientado a Objetos.
Son aquellos mtodos en los cuales datos y funciones estn altamente
relacionados. El nfasis est centrado en la abstraccin de datos. Se piensa en
forma natural, los objetos son mapeados a entidades del mundo real. Los
programas son fcilmente mantenibles y extensibles por medio de la construccin
de subclases.
1) Modelo de fases del ciclo de vida (Cascada).
En ocasiones se denomina de cascada porque los productos pasan de un
nivel a otro con suavidad. Este es el ciclo de vida clsico y ms antiguo, usado en
el desarrollo de productos de software. Sin embargo, con el paso de unos cuantos
aos, se han producido crticas, incluso por seguidores activos, que cuestionan su
aplicabilidad a todas las situaciones.

Modelo de ciclo de vida en Cascada.
El desarrollo de productos de software bajo ste ciclo de vida tiene los
siguientes problemas:
1. Los proyectos reales raramente siguen el flujo secuencial que
propone el modelo.
2. Normalmente, es difcil para el cliente establecer explcitamente al
principio todos los requisitos. Este ciclo lo requiere y tiene
dificultades en entender posibles problemas que pudieran existir.
3. El cliente debe tener paciencia. Hasta llegar a las etapas finales del
desarrollo del proyecto.
A pesar de sus inconvenientes, este ciclo de vida sigue siendo el modelo
clsico ms ampliamente usado por los ingenieros del software.
En un principio fue de gran utilidad pero el problema es que para pasar de
una etapa a la otra haba que terminar la primera, produciendo un gran problema
si algn cambio era requerido. La etapa de Mantenimiento consuma el 80% del
costo de produccin.
Debido a los nuevos requerimientos en el desarrollo de software, surgieron
muchos otros modelos que trataban de solucionar los problemas existentes, que
se basaron en el modelo en Cascada. Por ejemplo, el Modelo en Espiral, en el
cual el sistema se desarrolla incrementalmente.
Los modelos propuestos poseen bsicamente las mismas etapas, pero
varan en:
los mtodos y herramientas utilizadas en cada actividad
los controles requeridos, paralelismo en las actividades
las salidas de cada etapa
No es aconsejable elegir un modelo y seguirlo al detalle sino que se debe
adaptar a las caractersticas del proyecto que est siendo desarrollado.
2) 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, define cuatro actividades
principales:
1. Anlisis
2. Diseo
3. Implementacin
4. Test
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.

Figura 1 modelo en espiral
Modelo de ciclo de vida en Espiral
3) Modelo de prototipo para el ciclo de vida.
Un prototipo es una representacin o modelo del producto de programacin
que, a diferencia de un modelo de simulacin, incorpora componentes del
producto real. Por lo regular, un prototipo tiene un funcionamiento limitado en
cuanto a capacidades, confiabilidad o eficiencia. Hay varias razones para
desarrollar un prototipo; una de ellas es ilustrar los formatos de datos de entrada,
mensajes, informes y dilogos al cliente, este es un mecanismo adecuado para
explicar opciones de procesamiento y tener un mejor entendimiento de las
necesidades de l.
Una vez realizado el sistema prototipo, la pregunta que surgira sera la
siguiente: Qu debemos hacer con el prototipo cuando ya ha servido para el
propsito establecido? Brooks nos da una respuesta: "En la mayora de los
proyectos, el primer sistema construido apenas es utilizable". Puede ser
demasiado lento, demasiado grande, difcil de usar o las tres cosas. No hay ms
alternativa que comenzar de nuevo y construir una versin rediseada que
resuelva los problemas que se presenten... Cuando se utiliza un nuevo concepto
de sistema o de tecnologa, hay que construir un sistema para desecharlo, porque
incluso la mejor planificacin no puede asegurar que vaya a ser bueno la primera
vez. Por tanto, la cuestin no es si hay que construir un sistema piloto y tirarlo. Se
tirar. La nica cuestin es si planificar de antemano la construccin de algo que
se va a desechar, o prometer entregar el desecho a los clientes. Al igual que el
ciclo de vida clsico, la construccin de prototipos puede ser problemtica por las
siguientes razones:
El cliente ve funcionando lo que parece ser una primera versin del
software, ignorando que, por las prisas en hacer que funcione, no hemos
considerado los aspectos de calidad o de mantenimiento del software a
largo plazo. Cuando se le informa de que el producto debe ser reconstruido,
el cliente se vuelve loco y solicita que se apliquen "cuantas mejoras" sean
necesarias para hacer del prototipo un producto final que funcione. Y el
desarrollador del producto cede demasiado a menudo.
El tcnico de desarrollo, frecuentemente, impone ciertos compromisos de
implementacin con el fin de obtener un prototipo que funciones
rpidamente. Puede que utilice un sistema operativo inapropiado, o un
lenguaje de programacin equvoco o simplemente porque ya est
disponible y es conocido, puede que implemente ineficientemente un
algoritmo, sencillamente para demostrar su capacidad.
La clave est en definir al comienzo las reglas del juego; esto, es, el cliente y el
tcnico deben estar de acuerdo en que el prototipo se construya para servir slo
como un mecanismo de definicin de los requisitos.
Una ventaja fundamental que presenta la construccin de prototipos desde el
punto de vista de la validacin radica en que estos modelos, una vez construidos,
pueden ser evaluados directamente por los usuarios o expertos en el dominio del
sistema para validar sobre ellos el anlisis.