Desarrollo en cascada

En Ingeniera de software el desarrollo en cascada, tambin llamado modelo en

cascada (denominado as por la posicin de las fases en el desarrollo de esta, que parecen
caer en cascada por gravedad hacia las siguientes fases), es el enfoque metodolgico que
ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma
que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior.
1
Al final de cada
etapa, el modelo est diseado para llevar a cabo una revisin final, que se encarga de
determinar si el proyecto est listo para avanzar a la siguiente fase. Este modelo fue el
primero en originarse y es la base de todos los dems modelos de ciclo de vida.

La versin original fue propuesta por Winston W. Royce en 1970 y posteriormente
revisada por Barry Boehm en 1980 e Ian Sommerville en 1985.
Un ejemplo de una metodologa de desarrollo en cascada es:
1. Anlisis de requisitos.
2. Diseo del Sistema.
3. Diseo del Programa.
4. Codificacin.
5. Pruebas.
6. Verificacin.
7. Mantenimiento.

De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce
necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los
costos del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la
gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un
proyecto.
Fases del modelo.

El "modelo cascada" sin modificar. El progreso fluye de arriba haca abajo, como una cascada.

Anlisis de requisitos

En esta fase se analizan las necesidades de los usuarios finales del software para
determinar qu objetivos debe cubrir. De esta fase surge una memoria llamada SRD
(documento de especificacin de requisitos), que contiene la especificacin completa de lo
que debe hacer el sistema sin entrar en detalles internos.
Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del
sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos
resultados a mitad del proceso de elaboracin del software de una manera.

Diseo del Sistema

Descompone y organiza el sistema en elementos que puedan elaborarse por separado,
aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD
(Documento de Diseo del Software), que contiene la descripcin de la estructura relacional
global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como
la manera en que se combinan unas con otras.
Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El
primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de
anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que
van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin
elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para
comenzar la implementacin..

Diseo del Programa

Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los
requerimientos del usuario as como tambin los anlisis necesarios para saber qu
herramientas usar en la etapa de Codificacin

Codificacin

Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como
de pruebas y ensayos para corregir errores.
Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y
componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un
proceso mucho ms rpido.

Pruebas

Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de ser
entregado al usuario final.

Verificacin

Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores
ya realizaron exhaustivas pruebas para comprobar que el sistema no falle.
En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y
pruebas del mismo.
Mantenimiento

Una de las etapas mas criticas, ya que se destina un 75% de los recursos, es el
mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla
con todas nuestras expectativas.

Desarrollo en espiral

El desarrollo en espiral es un modelo de ciclo de vida del software definido por primera vez
por Barry Boehm en 1986,1 utilizado generalmente en la Ingeniera de software. 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.
La Ingeniera de software, se vale y establece a partir de una serie de modelos que
establecen y muestran las distintas etapas y estados por los que pasa un producto software,
desde su concepcin inicial, pasando por su desarrollo, puesta en marcha y posterior
mantenimiento, hasta la retirada del producto. A estos modelos se les denomina modelos de
ciclo de vida del software. El primer modelo concebido fue el de Royce, ms comnmente
conocido como desarrollo en cascada o desarrollo lineal secuencial. Este modelo establece que
las diversas actividades que se van realizando al desarrollar un producto software se suceden
de forma lineal.
Boehm, autor de diversos artculos de ingeniera del software; modelos de estimacin de
esfuerzo y tiempo que se consume en hacer productos software; y Modelos de Ciclo de Vida;
ide y promulg un modelo desde un enfoque distinto al tradicional en Cascada: El Modelo
Evolutivo Espiral. Su Modelo de Ciclo de Vida en Espiral tiene en cuenta fuertemente
el riesgo que aparece a la hora de desarrollar software. Para ello, se comienza mirando las
posibles alternativas de desarrollo, se opta por la de riesgo ms asumible y se hace un ciclo
de la espiral. Si el cliente quiere seguir haciendo mejoras en el software, se vuelve a evaluar
las distintas nuevas alternativas y riesgos y se realiza otra vuelta de la espiral, as hasta que
llegue un momento en el que el producto software desarrollado sea aceptado y no necesite
seguir mejorndose con otro nuevo ciclo.
Este modelo fue propuesto por Boehm en 1986 en su artculo "A Spiral Model of Software
Development and Enhancement".1 En 1988, Boehm public un artculo similar2 destinado a
una audiencia ms ampla. Bsicamente consiste en una serie de ciclos que se repiten en
forma de espiral, comenzando desde el centro. Se suele interpretar como que dentro de cada
ciclo de la espiral se sigue un Modelo Cascada, pero no necesariamente debe ser as. El
Espiral puede verse como un modelo evolutivo que conjuga la naturaleza iterativa del
modelo MCP con los aspectos controlados y sistemticos del Modelo Cascada, con el agregado
de gestin de riesgo.

Ciclos o Iteracione]
En cada vuelta o iteracin hay que tener en cuenta:
Los Objetivos: qu necesidad debe cubrir el producto.
Alternativas: las diferentes formas de conseguir los objetivos de forma exitosa, desde
diferentes puntos de vista como pueden ser:
1. Caractersticas: experiencia del personal, requisitos a cumplir, etc.
2. Formas de gestin del sistema.
3. Riesgo asumido con cada alternativa.
Desarrollar y Verificar: Programar y probar el software.
Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades:

Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral
tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la
angular:
1. Angular: Indica el avance del proyecto del software dentro de un ciclo.
2. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteracin se
pasa ms tiempo desarrollando.

Este sistema es muy utilizado en proyectos grandes y complejos como puede ser, por
ejemplo, la creacin de un Sistema Operativo.
Al ser un modelo de Ciclo de Vida orientado a la gestin de riesgo se dice que uno de los
aspectos fundamentales de su xito radica en que el equipo que lo aplique tenga la necesaria
experiencia y habilidad para detectar y catalogar correctamente los riesgos.

Tareas
Para cada ciclo habr cuatro actividades:
1. Determinar Objetivos.
2. Anlisis del riesgo.
3. Desarrollar y probar.
4. 'Planificacin.



Determinar o fijar objetivos
Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de
usuario.
Fijar las restricciones.
Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos.
Hay una cosa que solo se hace una vez: planificacin inicial.

Desarrollar, verificar y validar(probar)
Tareas de la actividad propia y de prueba.
Anlisis de alternativas e identificacin resolucin de riesgos.
Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el
desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo,
cascada, etc. As si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un
modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si lo
riesgos de proteccin son la principal consideracin, un desarrollo basado en
transformaciones formales podra ser el ms apropiado.

Anlisis del riesgo
Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no
deseados y los daos y consecuencias que stas puedan producir. Se evalan
alternativas. Se debe tener un prototipo antes de comenzar a desarrollar y probar.
En resumen, es para tener en cuenta de los riesgos de cada uno de los ambitos

Mecanismos de control
La dimensin radial mide el coste.
La dimensin angular mide el grado de avance del proyecto.

Variaciones del Modelo En Espiral

Modelo en Espiral Tpico de seis regiones

El modelo en espiral puede adaptarse y aplicarse a lo largo de la vida del software de
computadora, a diferencia del modelo de proceso clsico que termina cuando se entrega el
software.
Las 6 regiones que componen este modelo son las siguientes:
Comunicacin con el cliente - Tareas necesarias para plantear la comunicacin entre el
desarrollador y el cliente.
Planificacin - Tareas inherentes a la definicin de recursos, el tiempo y otras
informaciones relacionadas con el proyecto. Son todos los requerimientos.
Anlisis de riesgos Tareas para evaluar riesgos tcnicos y otras informaciones
relacionadas con el proyecto.
Ingeniera - Tareas para construir una o ms representaciones de la aplicacin.
Construccin y adaptacin - Tareas requeridas para construir, probar, instalar y
proporcionar soporte a los usuarios.
Evaluacin del cliente - Tareas requeridas para obtener la reaccin del cliente segn la
evaluacin de las representaciones del software creadas durante la etapa de ingeniera e
implementacin durante la etapa de instalacin.

Modelo en espiral WIN WIN

El modelo Win-Win es una adaptacin del modelo espiral que se enfatiza en la
participacin del cliente en el proceso de desarrollo de un producto de software. En un caso
ideal, el desarrollador simplemente pregunta al cliente lo que se requiere y el cliente
proporciona suficiente informacin y detalles para proceder. Sin embargo esto no suele ocurrir
en la mayora de los casos y es necesario que se establezcan negociaciones significativas
entre ambas partes para equilibrar la funcionalidad y rendimiento con los costos y tiempo de
salida al mercado del producto. El modelo Win-Win deriva su nombre del objetivo de estas
negociaciones, es decir, "ganar-ganar". El cliente recibe el producto que satisface la mayora
de sus necesidades, y el desarrollador trabaja para alcanzar presupuestos y fechas de
entrega. Para lograr este objetivo, se realizan varias actividades de negociacin al principio de
cada paso alrededor de la espiral.

Ventajas
El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los
restantes modelos.
Reduce riesgos del proyecto
Incorpora objetivos de calidad
Integra el desarrollo con el mantenimiento, etc.
Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la
metodologa, ya que este ciclo de vida no es rgido ni esttico.
Desventajas
Genera mucho tiempo en el desarrollo del sistema
Modelo costoso
Requiere experiencia en la identificacin de riesgos
Proceso Unificado de Rational

El Proceso Unificado Rational (Rational Unified Process en ingls, habitualmente
resumido como RUP) es un proceso de desarrollo de software desarrollado por la empresa
Rational Software, actualmente propiedad de IBM. Junto con el Lenguaje Unificado de
Modelado UML, constituye la metodologa estndar ms utilizada para el anlisis, diseo,
implementacin y documentacin de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin.
Tambin se conoce por este nombre al software, tambin desarrollado por Rational, que
incluye informacin entrelazada de diversos artefactos y descripciones de las diversas
actividades. Est incluido en el Rational Method Composer (RMC), que permite la
personalizacin de acuerdo con las necesidades.
Originalmente se dise un proceso genrico y de dominio pblico, el Proceso Unificado, y
una especificacin ms detallada, el Rational Unified Process, que se vendiera como producto
independiente.

Principios de desarrollo
El RUP est basado en 6 principios clave que son los siguientes:

Adaptar el proceso
El proceso deber adaptarse a las necesidades del cliente ya que es muy importante
interactuar con l. Las caractersticas propias del proyecto. El tamao del mismo, as como su
tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se
deber tener en cuenta el alcance del proyecto en un rea subnormal.

Equilibrar prioridades
Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o
disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de
todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro.
Demostrar valor iterativamente

Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada
iteracin se analiza la opinin de los inversores, la estabilidad y calidad del producto, y se
refina la direccin del proyecto as como tambin los riesgos involucrados.

Colaboracin entre equipos

El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe
haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes,
resultados, etc.

Elevar el nivel de abstraccin

Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del
software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita
que los ingenieros de software vayan directamente de los requisitos a la codificacin de
software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor
manera los requisitos y sin comenzar desde un principio pensando en la reutilizacin del
cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y
soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de
la arquitectura, por ejemplo con el lenguaje UML.

Enfocarse en la calidad

El control de calidad no debe realizarse al final de cada iteracin, sino en todos los
aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso de
desarrollo y no de un grupo independiente.

Ciclo de vida

Esfuerzo en actividades segn fase del proyecto.

El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado
ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las
tareas en fases e iteraciones.
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. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas
segn la fase en la que se encuentre el proyecto RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la
comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la
eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la
arquitectura.
Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado
del negocio y de requisitos.
En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la
arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios
(refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de 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 seleccionan algunos Casos de Uso, se refinan su anlisis y diseo
y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada
ciclo. Se realizan iteraciones hasta que se termine la implementacin de la nueva versin del
producto.
En la fase de transicin se pretende garantizar que se tiene un producto preparado para
su entrega a la comunidad de usuarios.
Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo
de la fase el esfuerzo dedicado a una disciplina vara.

Principales caractersticas
Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y
cmo)
Pretende implementar las mejores prcticas en Ingeniera de Software
Desarrollo iterativo
Administracin de requisitos
Uso de arquitectura basada en componentes
Control de cambios
Modelado visual del software
Verificacin de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental,
estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los
productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el cdigo
fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una
persona puede desempear distintos roles a lo largo del proceso).

Fases
Establece oportunidad y alcance
Identifica las entidades externas o actores con las que se trata
Identifica los casos de uso.

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:
'Proceso': Las etapas de esta seccin son: (Revise nuevamente la grfica)
Modelado de negocio
Requisitos
Anlisis y Diseo
Implementacin
Pruebas
Despliegue
Soporte: En esta parte nos encontramos con las siguientes etapas:
Gestin del cambio y configuraciones
Gestin del proyecto
Entorno

La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo
fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas
anteriormente:
Inicio (tambin llamado Incepcin o Concepcin).
Elaboracin.
Desarrollo (tambin llamado Implementacin, Construccin).
Cierre (tambin llamado Transicin).

Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto
con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy
general de la arquitectura de software y producir el plan de las fases y el de iteraciones
posteriores.

Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que
permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificacin de los casos de uso seleccionados y el primer anlisis del dominio del
problema, se disea la solucin preliminar.

Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema,
para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a
las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto.

Fase de Transicin: El propsito de esta fase es asegurar que el software est disponible
para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar
que el producto cumpla con las especificaciones entregadas por las personas involucradas en
el proyecto.

Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura dinmica) realiza una serie
de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema
(entre otros). Estos artefactos (entre otros) son los siguientes:

Inicio:
Documento Visin
Diagramas de caso de uso
Especificacin de Requisitos
Diagrama de Requisitos

Elaboracin:
Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lgica
Diagrama de clases
Modelo E-R (Si el sistema as lo requiere)


Vista de Implementacin
Diagrama de Secuencia
Diagrama de estados
Diagrama de Colaboracin

Vista Conceptual
Modelo de dominio

Vista fsica
Mapa de comportamiento a nivel de hardware.
Diseo y desarrollo de casos de uso, o flujos de casos de uso arquitectnicos
Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura
documentada responde adecuadamente a requerimientos funcionales y no funcionales.

Construccin:
Especificacin de requisitos faltantes
Diseo y desarrollo de casos de uso y/o flujos de acuerdo con la planeacin iterativa
Pruebas de los casos de uso desarrollados, y pruebas de regresin segn sea el caso

Transicin:
Pruebas finales de aceptacin
Puesta en produccin
Estabilizacin