Ciclo de vida

Esfuerzo en actividades según fase del proyecto.

El ciclo de vida RUP es una implementación 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 número variable
según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. En la Figura
muestra cómo varía el esfuerzo asociado a las disciplinas según la fase en la que se encuentre el proyecto
RUP.
Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema
y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al
establecimiento de una baseline (Línea 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 elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan
más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de
implementación orientado a la baseline de la arquitectura.
En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.
Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su
implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones
hasta que se termine la implementación de la nueva versión del producto.
En la fase de transición 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 que dependiendo de la fase el
esfuerzo dedicado a una disciplina varía.
[editar]Principales características

 Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
 Pretende implementar las mejores prácticas en Ingeniería de Software
 Desarrollo iterativo
 Administración de requisitos
 Uso de arquitectura basada en componentes
 Control de cambios
  Modelado visual del software
 Verificación 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 código fuente, etc.) y roles (papel que desempeña una
persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).
[editar]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 sección son: (Revise nuevamente la gráfica)

 Modelado de negocio
 Requisitos
 Análisis y Diseño
 Implementación
 Pruebas
 Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas:

 Gestión del cambio y configuraciones

 Gestión del proyecto
 Entorno

La estructura dinámica 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(También llamado Incepción o Concepción)

 Elaboración
 Desarrollo(También llamado Implementación, Construcción)
 Cierre (También llamado Transición)

Fase de Inicio: Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la
arquitectura de software y producir el plan de las fases y el de iteraciones posteriores.
Fase de elaboración: En la fase de elaboración se seleccionan los casos de uso que permiten definir la
arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificación de los casos de uso
seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar.
Fase de Desarrollo: El propósito 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 Cierre: El propósito de esta fase es asegurar que el software esté disponible para los usuarios finales,
ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el
soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por
las personas involucradas en el proyecto.
[editar]Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de artefactos que sirven
para comprender mejor tanto el análisis como el diseño del sistema (entre otros). Estos artefactos (entre otros)
son los siguientes:
Inicio:

 Documento Visión
 Especificación de Requisitos

Elaboración:

 Diagramas de caso de uso

Construcción:

 Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lógica

 Diagrama de clases
 Modelo E-R (Si el sistema así lo requiere)

Vista de Implementación

 Diagrama de Secuencia
 Diagrama de estados
 Diagrama de Colaboración

Vista Conceptual

 Modelo de dominio

Vista física

 Mapa de comportamiento a nivel de hardware.

MODELO DE DESARROLLO RAPIDO DE APLICACIONES

El desarrollo rápido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo

de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo
iterativo, la construcción de prototipos y el uso de utilidades CASE.

Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la

rapidez de ejecución.

El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de

proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente
corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque
de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del
proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro
de periodos cortos de tiempo. Cuando se utiliza principalmente para aplicaciones de sistemas de información,
el enfoque DRA comprende las siguientes fases:

 Modelado de gestión: el flujo de información entre las funciones de gestión se modela de forma que
responda a las siguientes preguntas:

¿Qué información conduce el proceso de gestión? ¿Qué información se genera? ¿Quién la genera? ¿A dónde
va la información? ¿Quién la proceso?

 Modelado de datos: el flujo de información definido como parte de la fase de modelado de gestión se
refina como un conjunto de objetos de datos necesarios para apoyar la empresa. Se definen las características
(llamadas atributos) de cada uno de los objetos y las relaciones entre estos objetos.

 Modelado de proceso: los objetos de datos definidos en la fase de modelado de datos quedan
transformados para lograr el flujo de información necesario para implementar una función de gestión. Las
descripciones del proceso se crean para añadir, modificar, suprimir, o recuperar un objeto de datos. Es la
comunicación entre los objetos.

 Generación de aplicaciones: El DRA asume la utilización de técnicas de cuarta generación. En lugar de

crear software con lenguajes de programación de tercera generación, el proceso DRA trabaja para volver a
utilizar componentes de programas ya existentes (cuando es posible) o a crear componentes reutilizables
(cuando sea necesario). En todos los casos se utilizan herramientas automáticas para facilitar la construcción
del software.

 Pruebas de entrega: Como el proceso DRA enfatiza la reutilización, ya se han comprobado muchos de los
componentes de los programas. Esto reduce tiempo de pruebas. Sin embargo, se deben probar todos los
componentes nuevos y se deben ejercitar todas las interfaces a fondo. Ingeniería de Software
Obviamente la limitación de tiempo impuesto en un proyecto DRA demanda "ámbito en escalas". Si una
aplicación de gestión puede modularse se forma que permita completarse cada una de las funciones
principales en menos de tres meses (utilizando el enfoque descrito anteriormente), es un candidato del

DRA. Cada una de las funciones puede ser afrontada por un equipo DRA diferente y ser integradas en un
solo conjunto.

Al igual que todos los modelos de proceso, el enfoque DRA tiene inconvenientes:

 Para proyectos grandes aunque por escalas, el DRA requiere recursos humanos suficientes como para crear
el numero correcto de equipos DRA.

 DRA requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para
completar un sistema en un marco de tiempo abreviado. Si no hay compromiso, por ninguna de las partes
constituyentes, los proyectos DRA fracasaran.

No todos los tipos de aplicaciones son apropiados para DRA. Si un sistema no se puede modulizar
adecuadamente. La construcción de los componentes necesarios para DRA será problemático. Si está en juego
el alto rendimiento, y se va a conseguir el rendimiento convirtiendo interfaces en componentes de sistema, el
enfoque DRA puede que no funcione. DRA no es adecuado cuando Ingeniería de Software los riesgos
técnicos son altos. Esto ocurre cuando una nueva aplicación hace uso de tecnologías nuevas, o cuando el
nuevo software requiere un alto grado de interoperabilidad con programas de computadora ya existentes.

DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización es la piedra angular

de las tecnologías de objetos, y se encuentra en el modelo de proceso de ensamblaje.

Características De Rad

Entre las principales características del RAD tenemos:

1. Equipos Híbridos

 Equipos compuestos por alrededor de seis personas, incluyendo desarrolladores y usuarios de tiempo
completo del sistema así como aquellas personas involucradas con los requisitos.

 Los desarrolladores de RAD deben ser "renacentistas": analistas, diseñadores y programadores en uno.

2. Herramientas Especializadas

 Desarrollo "visual"

 Creación de prototipos falsos (simulación pura)

 Creación de prototipos funcionales

 Múltiples lenguajes

 Calendario grupal

 Herramientas colaborativas y de trabajo en equipo

 Componentes reusables
 Interfaces estándares (API)

 Control de versiones

3. "Timeboxing"

 Las funciones secundarias son eliminadas como sea necesario para cumplir con el calendario.

4. Prototipos Iterativos y Evolucionarios

 Reunión JAD (Joint Application Development): o Se reúnen los usuarios finales y los desarrolladores.
o Lluvia de ideas para obtener un borrador inicial de los requisitos.

 Iterar hasta acabar: Ingeniería de Software

o Los desarrolladores construyen y depuran el prototipo basado en los requisitos actuales.

o Los diseñadores revisan el prototipo.

o Los clientes prueban el prototipo, depuran los requisitos.

o Los clientes y desarrolladores se reunen para revisar juntos el producto, refinar los requisitos y generar
solicitudes de cambios.

o Los cambios para los que no hay tiempo no se realizan. Los requisitos secundarios se eliminan si es
necesario para cumplir el calendario.

 Notas:

o Cada iteración dura entre un día y tres semanas.

o Reuniones de 2 horas con facilitador que mantiene enfocado al grupo.

RAD tiende a funcionar cuando:

 La aplicación funcionará de manera independiente.

 Se pueden usar mayormente bibliotecas existentes.

 Desempeño no crítico.

 Distribución limitada, interna o vertical.

 Alcance del proyecto limitado.

 Confiabilidad no crítica.

 El sistema puede dividirse en muchos módulos independientes.

 El producto está dirigido a un mercado altamente especializado.

 El proyecto cuenta con fuertes limitantes de tiempos parciales (timeboxes).

 La tecnología requerida tiene más de un año en el mercado.RAD tiende a fallar cuando:

 La aplicación debe interoperar con sistemas existentes.

 Existen pocos componentes reutilizables.

 Alto desempeño crítico.

 El desarrollo no puede aprovechar herramientas de alto nivel.

 Distribución amplia, horizontal o masiva.

 RAD se convierta en QADAD (Quick And Dirty Application Development).

 Métodos RAD para desarrollar sistemas operativos (confiabilidad demasiado alta) o juegos (desempeño
demasiado alto).

 Riesgos técnicos de tecnología de punta.

 El producto pone en riesgo la misión o la vida.

 El producto no puede ser modularizado.

Ventajas de RAD

 Comprar puede ahorrar dinero en comparación con construir.

 Los entregables pueden ser fácilmente trasladados a otra plataforma.

 El desarrollo se realiza a un nivel de abstracción mayor.

 Visibilidad temprana.Ingeniería de Software

 Mayor flexibilidad.

 Menor codificación manual.

 Mayor involucramiento de los usuarios.

 Posiblemente menos fallas.

 Posiblemente menor costo.

 Ciclos de desarrollo más pequeños.

 Interfaz gráfica estándar.

Desventajas de RAD
 Comprar puede ser más caro que construir.

 Costo de herramientas integradas y equipo necesario.

 Progreso más difícil de medir.

 Menos eficiente.

 Menor precisión científica.

 Riesgo de revertirse a las prácticas sin control de antaño.

 Más fallas (por síndrome de "codificar a lo bestia").

 Prototipos pueden no escalar, un problema mayúsculo.

 Funciones reducidas (por "timeboxing").

 Dependencia en componentes de terceros: funcionalidad de más o de menos, problemas legales.