Sie sind auf Seite 1von 53

Qu es RUP?

Requisitos del usuario

Proceso de desarrollo
de software

Sistema de software

RUP es un proceso de desarrollo de software:


Forma disciplinada de asignar tareas y responsabilidades en una empresa
de desarrollo (quin hace qu, cundo y cmo).

Objetivos:
Asegurar la produccin de software de calidad dentro de plazos
y presupuestos predecibles. Dirigido por casos de uso, centrado en la
arquitectura, iterativo (mini-proyectos) e incremental (versiones).

Es tambin un producto:
Desarrollado y mantenido por Rational.
Actualizado constantemente para tener en cuenta las mejores prcticas de
acuerdo con la experiencia.

Qu es RUP?
Aumenta la productividad de los desarrolladores mediante
acceso a:
Base de conocimiento, plantillas y herramientas.

Se centra en la produccin y mantenimiento de modelos del


sistema ms que en producir documentos.
RUP es una gua de cmo usar UML de la forma ms efectiva.
Existen herramientas de apoyo a todo el proceso:
Modelamiento visual, programacin, pruebas, etc.

Qu es RUP?
1998

Pruebas de rendimiento y carga


(Performance Awareness)
Ingeniera de Negocios
Administracin de
Configuracin y Cambios
(Pure-Atria)

1997

1996

1995
1987
1967

Escuela de
Requerimientos
(Requisite Inc.)

OMT
Booch

Rational Unified
Process 5.0

Diseo OO de IU
Ingeniera de Datos
(Vigortech)
UML 1.2

Rational Objectory
Process 4.1

Proceso SQA
(SQA Inc.)
UML 1.0

Rational Objectory
Process 4.0
Rational
Approach

Objectory
Process

UML 0.8

Ericsson
method

Las mejores prcticas


RUP pretende implementar las mejores prcticas
actuales en ingeniera de software:

Desarrollo iterativo del software


Administracin de requerimientos
Uso de arquitecturas basadas en componentes
Modelamiento visual del software
Verificacin de la calidad del software
Control de cambios

Desarrollo iterativo
El software moderno es complejo y novedoso. No es realista
usar un modelo lineal de desarrollo como el de cascada.
Un proceso iterativo permite una comprensin creciente de los
requerimientos a la vez que se va haciendo crecer el sistema.
RUP sigue un modelo iterativo que aborda las tareas ms
riesgosas primero.
Con esto se logra reducir los riesgos del proyecto y tener un
subsistema ejecutable tempranamente.

Administracin de requerimientos
RUP describe cmo:
Obtener los requerimientos
Organizarlos
Documentar requerimientos de funcionalidad y restricciones
Rastrear y documentar decisiones
Captar y comunicar requerimientos del negocio

Los casos de uso y los escenarios indicados por el proceso han


probado ser una buena forma de captar requerimientos y guiar
el diseo, la implementacin y las pruebas.

Arquitecturas basadas en componentes


El proceso se basa en disear tempranamente una
arquitectura base ejecutable.
La arquitectura debe ser:

Flexible
Fcil de modificar
Intuitivamente comprensible
Promueve la reutilizacin de componentes

RUP apoya el desarrollo basado en componentes, tanto


nuevos como preexistentes.

Modelamiento visual
Modelamiento visual de la estructura y el
comportamiento de la arquitectura y los componentes.
Bloques de construccin:
Ocultan detalles
Permiten la comunicacin en el equipo de desarrollo
Permiten analizar la consistencia:
entre las componentes
entre diseo e implementacin

UML es la base del modelamiento visual de RUP.

Verificacin de cualidades
No slo la funcionalidad es esencial, tambin el
rendimiento y la confiabilidad.
RUP ayuda a planificar, disear, implementar, ejecutar y
evaluar pruebas que verifiquen estas cualidades.
El aseguramiento de la calidad es parte del proceso de
desarrollo y no la responsabilidad de un grupo
independiente.

Control de cambios
Los cambios son inevitables, pero es necesario evaluar si
stos son necesarios y rastrear su impacto.
RUP indica como controlar, rastrear y monitorear los
cambios dentro del proceso iterativo de desarrollo.

Ciclos y fases
RUP divide el proceso de desarrollo en ciclos, teniendo
un producto al final de cada ciclo.
Cada ciclo se divide en cuatro Fases:

Inicio
Elaboracin
Construccin
Transicin

Cada fase concluye con un hito bien definido donde


deben tomarse ciertas decisiones.

Fases de RUP

Fases de RUP: Inicio


Se establece la oportunidad y alcance el proyecto.
Se identifican todas las entidades externas con las que se
trata (actores) y se define la interaccin a un alto nivel de
abstraccin:
Identificar todos los casos de uso
Describir algunos en detalle

La oportunidad del negocio incluye:

Criterios de xito
Identificacin de riesgos
Estimacin de recursos necesarios
Plan de las fases incluyendo hitos

Fases de RUP: Inicio


Productos:

Un documento de visin
general:
Requerimientos generales del
proyecto
Caractersticas principales
Restricciones

Modelo inicial de casos de uso


(10% a 20 % listos).
Glosario.

Caso de negocio:
Contexto
Criterios de xito
Pronstico financiero

Identificacin inicial de riesgos.


Plan de proyecto.
Uno o ms prototipos.

Fases de RUP: Inicio


Hito:
Objetivos del
Ciclo de Vida

Inicio

Elaboracin Construccin

Transicin

Las partes interesadas deben acordar el alcance y la


estimacin de tiempo y costo.
Comprensin de los requerimientos plasmados en casos
de uso.

Fases de RUP: Elaboracin


Objetivos:

Analizar el dominio del problema


Establecer una arquitectura base slida
Desarrollar un plan de proyecto
Eliminar los elementos de mayor riesgo para el desarrollo
exitoso del proyecto

Visin de una milla de amplitud y una pulgada de


profundidad porque las decisiones de arquitectura
requieren una visin global del sistema.

Fases de RUP: Elaboracin


Productos:

Es la parte ms crtica del


proceso:
Al final toda la ingeniera
dura est hecha
Se puede decidir si vale la
pena seguir adelante

A partir de aqu la arquitectura,


los requerimientos y los planes
de desarrollo son estables.

Ya hay menos riesgos y se


puede planificar el resto del
proyecto con menor
incertidumbre.
Se construye una arquitectura
ejecutable que contemple:
Los casos de uso crticos
Los riesgos identificados

Fases de RUP: Elaboracin


Productos:

Modelo de casos de uso (80%


completo) con descripciones
detalladas.
Otros requerimientos no funcionales o no asociados a casos de
uso.
Descripcin de la Arquitectura del
Software.

Un prototipo ejecutable de la
arquitectura.
Lista revisada de riesgos y del
caso de negocio.
Plan de desarrollo para el resto
del proyecto.
Un manual de usuario
preliminar.

Fases de RUP: Elaboracin


Hito:

Concepcin

Arquitectura de
Ciclo de Vida

Elaboracin Construccin

Transicin

Condiciones de xito de la elaboracin:


Es estable la visin del producto?
Es estable la arquitectura?
Las pruebas de ejecucin demuestran que los riesgos han sido
abordados y resueltos?
Es el plan del proyecto algo realista?
Estn de acuerdo con el plan todas las personas involucradas?

Fases de RUP: Construccin


En esta fase todas las componentes restantes se desarrollan
e incorporan al producto.
Todo es probado en profundidad.
El nfasis est en la produccin eficiente y no ya en la
creacin intelectual.
Puede hacerse construccin en paralelo, pero esto exige
una planificacin detallada y una arquitectura muy estable.

Fases de RUP: Construccin


Productos:

El producto de software integrado y corriendo en la plataforma


adecuada.

Manuales de usuario.

Una descripcin del release actual.

Fases de RUP: Construccin


Hito:

Concepcin

Capacidad
Operacional

Elaboracin Construccin

Transicin

Se obtiene un producto Beta que debe decidirse si puede


ponerse en ejecucin sin mayores riesgos.
Condiciones de xito:
El producto est maduro y estable para instalarlo en el ambiente
del cliente?
Estn los interesados listos para recibirlo?

Fases de RUP: Transicin


El objetivo es traspasar el software desarrollado a la
comunidad de usuarios.
Una vez instalado surgirn nuevos elementos que
implicarn nuevos desarrollos (ciclos).
Incluye:
Pruebas Beta para validar el producto con las expectativas del
cliente
Ejecucin paralela con sistemas antiguos
Conversin de datos
Entrenamiento de usuarios
Distribuir el producto

Fases de RUP: Transicin


Objetivos:
Obtener autosuficiencia de parte de los usuarios.
Concordancia en los logros del producto de parte de las
personas involucradas.
Lograr el concenso cuanto antes para liberar el producto al
mercado.
Concepcin

Elaboracin Construccin

Transicin

Producto

Definiciones
Trabajador
Un trabajador define el comportamiento y las
responsabilidades de un individuo.
Es como un sombrero que la persona usa durante el
proyecto:
Una persona puede tener varios sombreros
Es el rol que desempea en un momento dado

Responsabilidades:
Hacer una serie de actividades
Ser el responsable de una serie de artefactos

Definiciones
Actividades
Una actividad es una unidad de
trabajo que se asigna a un
trabajador. Ej.:

Crear o modificar un artefacto

Una actividad lleva entre un par


de horas y un par de das,
involucra un solo trabajador y
un nmero pequeo de
artefactos.

Las actividades se consideran en la


planificacin y evaluacin del progreso
del proyecto.
Ejemplos:
Planificar una iteracin - Administrador
de proyecto
Encontrar actores y casos de uso Analista
Revisar el diseo - Revisor de diseo
Ejecutar pruebas de performance - Ing.
de pruebas de performance

Asignacin de actividades
Recurso

Trabajador

Actividad

Pablo

Diseador

Diseo de Objetos

Mara

Autor de Casos de Uso

Detallar un Caso de Uso

J os

Diseador de Casos de Uso

Disear un Caso de Uso

Silvia

Revisor de Diseo

Revisar el Diseo

Arquitecto

Anlisis de Arquitectura
Diseo de Arquitectura

Eduardo

Artefactos

Elementos de informacin
producidos, modificados o
usados por el proceso.
Son los productos tangibles del
proyecto.
Son usados por los trabajadores
para realizar nuevas actividades y
son el resultado de esas
actividades.

Ejemplos:
Un modelo, como el modelo de
casos de uso o el modelo de
diseo.
Un elemento del modelo, como
una clase o un caso de uso.
Un documento tal como el Caso
del Negocio o la Arquitectura
del Software.
Cdigo fuente.
Cdigo ejecutable.

Flujos de trabajo

Una lista de actividades,


trabajadores y artefactos
constituye un proceso.

Anlisis de
Arquitectura

Diseo de
Arquitectura

No siempre es posible
representar flujos de trabajo.

Describir
Distribucin

Arquitecto
Anlisis de
Casos de Uso

Un flujo de trabajo es una


secuencia de actividades que
produce un resultado valioso.

Describir
Concurrencia

Diseo de
Casos de Uso

Diseador de
Casos de Uso
Anlisis de
Objetos

Diseo de
Objetos

Diseador

Revisor de
Diseo

Revisar el
Anlisis

Revisar el
Diseo

Revisar la
Arquitectura

Flujos de trabajo esenciales


Flujos de Trabajo
de Ingeniera

Flujos de Trabajo
de Apoyo

Flujos de trabajo
Existen habitualmente problemas de comunicacin entre
ingenieros de software e ingenieros de negocios.
RUP proporciona un lenguaje y proceso comn para estos
dos mbitos.
Para el modelamiento del negocio se usan business use
cases (casos de uso del negocio):
La forma en que el software dar apoyo al negocio.

Requerimientos
Los desarrolladores y
clientes deben acordar qu
es lo que el sistema debe
hacer:
Relevar requerimientos
Documentar funcionalidad
y restricciones
Documentar decisiones
Identificar actores
Identificar casos de uso

Imprimir Informe

Cliente

Operador

Reciclar
Administrar Depsito

Los casos de uso describen


la funcionalidad.
Los requerimientos no
funcionales se incluyen en
una especificacin
complementaria.

Anlisis y diseo

Descripcin de cmo se
implementar el sistema: un plano

Disear y validar la arquitectura


es una tarea esencial.

Debe:

El modelo de diseo consta de

Ejecutar las tareas y funciones


descritas en los casos de uso
Satisfacer todos los requerimientos
Flexible a cambios

El diseo se centra en la nocin de


arquitectura.

Clases estructuradas en paquetes


Diseos de subsistemas con
interfaces definidas
(componentes)
Forma de colaboracin entre las
clases.

Implementacin
Propsito:
Definir la organizacin del cdigo
Implementar clases y objetos en forma de componentes
(fuente, ejecutables, etc.)
Probar las componentes desarrolladas
Integrar las componentes en un sistema ejecutable

Pruebas

Propsito:
Verificar la interaccin entre los
objetos
Verificar la integracin apropiada
de componentes
Verificar que se satisfacen los
requerimientos
Identificar los defectos y
corregirlos antes de la instalacin

RUP describe como planear y


ejecutar estas pruebas.

RUP propone probar las componentes


desde el principio:
Confiabilidad, funcionalidad y
performance

Las pruebas de regresin son


importantes en desarrollos iterativos.

Rational tiene herramientas para


automatizar algunas pruebas.

Distribucin
Producir un producto y hacerlo
llegar a sus usuarios finales.

Realizar pruebas beta


Migracin de datos
Aceptacin formal

Incluye varias actividades:

Producir un release
Empaquetar el software
Distribuir el software
Instalar el software
Apoyar a los usuarios

A veces tambin incluye:

La mayor parte de la distribucin


ocurre durante la transicin.

Este es uno de los flujos de


trabajo menos documentados en
RUP.

Administracin de proyectos
Es el arte de balancear objetivos contrarios, manejar
riesgos y producir software que satisface a clientes y
usuarios.
Existen pocos proyectos realmente exitosos.
RUP incluye:
Un framework para manejo de proyectos de software
Guas para planificacin, provisin de personal, ejecucin y
monitoreo de planes
Un framework para manejar riesgos

Administracin de configuracin y cambios


Forma de controlar los artefactos producidos por las
personas que trabajan en el proyecto.
Algunos problemas habituales:
Actualizaciones simultneas
Mltiples versiones

RUP da guas para:


Desarrollos en paralelo
Automatizar la construccin
Administrar defectos

Ambiente
Ambiente y herramientas de desarrollo que harn
posible llevar a cabo el proyecto.
RUP gua en la configuracin de un ambiente de
proceso apropiado a cada proyecto.

UML
(Unifed Modeling Languaje) El lenguaje para modelamiento unificado (UML), es
un lenguaje para la especificacin, visualizacin, construccin y documentacin
de los artefactos de un proceso de sistema intensivo. Fue originalmente
concebido por la Corporacin Rational Software y tres de los ms prominentes
mtodologistas en la industria de la tecnologa y sistemas de informacin:
Grady Booch, James Rumbaugh, y Ivar Jacobson (The Three Amigos). El
lenguaje ha ganado un significante soporte de la industria de varias
organizaciones va el consorcio de socios de UML y ha sido presentado al
Object Management Group (OMG) y aprobado por ste como un estndar.

DIAGRNAS DE UML
Diagrama de casos de uso
Diagrama de clases
Diagramas de secuencia
Diagramas de colaboracin
Diagrama de estado
Diagrama de actividad
Elementos de ayuda
Diagramas de componentes
Diagramas de implementacin
Diagramas de relacin de entidad
Conceptos del diagrama de relaciones de entidades extendido (EER)

Modelado de casos de uso (I)


Un caso de uso es una tcnica de modelado usada para describir lo
que debera hacer un sistema nuevo o lo que hace un sistema que ya
existe.
Los casos de uso describen bajo la forma de acciones y reacciones
el comportamiento de un sistema desde el punto de vista de un
usuario, permiten definir los lmites del sistema y las relaciones entre
el sistema y el entorno.
Los componentes primarios de un modelo de casos de uso (caseuse model) son los casos de uso (use cases), los actores y el sistema
modelado.
Los casos de uso son descripciones funcionales del sistema;
describen cmo los actores pueden usar un sistema.

Suponga que va a comenzar a desarrollar un sistema Por dnde empieza?


Obviamente con el proceso de "levantado de requerimientos", el cual un proceso
muy parecido entre un exorcismo y un psicoanlisis, donde el talento del analita
debe aflorar. Sin embargo surge una pregunta: cmo documentar toda esa
informacin recabada?

Una forma es utilizando los Casos de Uso.

Qu es un Caso de Uso
Es una tcnica de la ingeniera del software utilizado para capturar una secuencia de
acciones realizadas por una entidad externa sobre el sistema, cuyo fin es lograr un
objetivo cuantificable.
Describe nicamente una caracterstica del sistema.
La mayora de los proyectos de software requieren muchos casos de uso para
describir su alcance total.

Actor: es una persona, organizacin o sistema externo que desempea un papel en


una o ms interacciones con el sistema con el fin de lograr un objetivo; dicho de
otra manera, es, bsicamente, un usuario del sistema. Tambin se consideran
actores todo aquello que inicia un caso de uso (por ejemplo una tarea agendada)
o responde a un caso de uso (un sistema externo de procesamiento en batch).
Caso de uso: es lo que pasa cuando el actor interacta con el sistema con el deseo
de lograr un objetivo. Se describe normalmente comenzando con un verbo que
representa la accin.
Asociacin: es la relacin entre un actor y un caso de uso, o entre dos casos de uso.
Este ltimo caso se da cuando un caso de uso incluye a otro, extiendo a otro o
generaliza a otro.
Escenarios: es un camino que puede tomar un caso de uso. Existen escenarios
exitosos, en los cuales el objetivo del caso de uso se logra, y los escenarios
fallidos, donde el objetivo no se logra. Un caso de uso puede tener varios
escenarios posible.

Existen dos formas principales de documentar un caso de uso:


1. Un diagrama en UML
2. Un documento detallado

El Lenguaje Unificado de Modelado (UML) provee de un grupo de elementos


grficos para representar un Caso de Uso, de manera explcita, sucinta y
esquemtica. Utiliza un monito para representar a los actores, una elipse con una
leyenda para representar un caso de uso y una lnea recta entre un actor y un
caso de uso para representar la asociacin entre ellos.

Documentar casos de usos no es una tarea fcil que se pueda dominar de


un da para otro, requiere de tiempo, disciplina y experiencia, sin embargo
podemos definir una serie de pasos identificables para escribir los casos
de uso.
1.
2.
3.
4.

Identifique a todos lo actores que intervienen.


Identifique todas las tareas que realizar cada actor.
Agrupe las tareas repetidas.
Genere el diagrama(s) UML que represente esquemticamente los Casos
de Uso.
5. De una prioridad a cada caso de uso.
6. Por cada caso de uso escriba un documento detallado siguiendo la
plantilla especificada anteriormente.

Actores (I)
Un actor es alguien o algo que interacta con el sistema, pero
que es externo al sistema.
El actor enva o recibe mensajes a y desde el sistema, o
intercambia informacin con el sistema.
Un caso de uso siempre es iniciado por un actor que le enva un
mensaje o estmulo (stimulus). Los actores llevan a cabo casos de
uso.
Cuando un caso de uso se realiza, el caso de uso podra enviar
mensajes a uno o ms actores. Estos mensajes tambin puede ir a
otros actores adems del que inici el caso de uso.