Universidad Privada San Juan Bautista

Facultad de Ingenieras
Escuela Profesional de Ingeniera de Computacin y Sistemas
CONTROL LECTURA N 2

Para empezar un gran proyecto,

hace falta valenta. Para terminar un gran proyecto,
hace falta perseverancia.

RATIONAL UNIFIED PROCESS - RUP

El Proceso Unificado de Rational es un proceso de ingeniera del software. Proporciona
un acercamiento disciplinado a la asignacin de tareas y responsabilidades en una
organizacin de desarrollo. Su propsito es asegurar la produccin de software de alta
calidad que se ajuste a las necesidades de sus usuarios finales con unos costos y
calendario predecibles.
En definitiva el RUP es una metodologa de desarrollo de software que intenta integrar
todos los aspectos a tener en cuenta durante todo el ciclo de vida del software, con el
objetivo de hacer abarcables tanto pequeos como grandes proyectos software. Adems
Rational proporciona herramientas para todos los pasos del desarrollo as como
documentacin en lnea para sus clientes
CARACTERISTICAS DEL RUP
Las caractersticas principales de RUP son:

Guiado/Manejado por casos de uso: La razn de ser de un sistema software es

servir a usuarios ya sean humanos u otros sistemas; un caso de uso es una facilidad que el
software debe proveer a sus usuarios. Los casos de uso remplazan la antigua
especificacin funcional tradicional y constituyen la gua fundamental establecida para las
actividades a realizar durante todo el proceso de desarrollo incluyendo el diseo, la
implementacin y las pruebas del sistema.
Centrado en arquitectura: La arquitectura involucra los elementos ms significativos

1. DEL SISTEMA Y EST INFLUENCIADA ENTRE OTROS POR

PLATAFORMAS
SOFTWARE,
SISTEMAS
OPERATIVOS,
MANEJADORES DE BASES DE DATOS, PROTOCOLOS,
CONSIDERACIONES DE DESARROLLO COMO SISTEMAS
HEREDADOS Y REQUERIMIENTOS NO FUNCIONALES. ES
COMO UNA RADIOGRAFA DEL SISTEMA QUE ESTAMOS
DESARROLLANDO, LO SUFICIENTEMENTE COMPLETA COMO
PARA QUE TODOS LOS IMPLICADOS EN EL DESARROLLO
TENGAN UNA IDEA CLARA DE QU ES LO QUE ESTN
CONSTRUYENDO, PERO LO SUFICIENTEMENTE SIMPLE COMO
PARA QUE SI QUITAMOS ALGO UNA PARTE IMPORTANTE DEL
SISTEMA QUEDE SIN ESPECIFICAR. SE REPRESENTA
MEDIANTE VARIAS VISTAS QUE SE CENTRAN EN ASPECTOS
CONCRETOS DEL SISTEMA, ABSTRAYNDOSE DE LO DEMS.
TODAS LAS VISTAS JUNTAS FORMAN EL LLAMADO MODELO
4+1 DE LA ARQUITECTURA, RECIBE ESTE NOMBRE PORQUE
LO FORMAN LAS VISTAS LGICA, DE IMPLEMENTACIN,
PROCESO Y DESPLIEGUE, MS LA DE CASOS DE USO QUE ES
LA QUE DA COHESIN A TODAS.

Iterativo e Incremental: Para hacer ms manejable un proyecto se recomienda

dividirlo en ciclos. Para cada ciclo se establecen fases de referencia, cada una de las
cuales debe ser considerada como un mini proyecto cuyo ncleo fundamental est
constituido por una o ms iteraciones de las actividades principales bsicas de cualquier
proceso de desarrollo. En concreto RUP divide el proceso en cuatro fases, dentro de las
cuales se realizan varias iteraciones en numero variable segn el proyecto y en las que se
hace un mayor o menor hincapi en los distintas actividades. En la Figura 1 tenemos un
ejemplo de la distribucin del trabajo.
Figura 1

Universidad Privada San Juan Bautista

Facultad de Ingenieras
Escuela Profesional de Ingeniera de Computacin y Sistemas

Desarrollo basado en componentes: La creacin de sistemas intensivos en software

requiere dividir el sistema en componentes con interfaces bien definidas, que

posteriormente sern ensamblados para generar el sistema. Esta caracterstica en un
proceso de desarrollo permite que el sistema se vaya creando a medida que se obtienen o
que se desarrollan y maduran sus componentes.

Utilizacin de un nico lenguaje de modelado: UML es adoptado como nico lenguaje

de modelado para el desarrollo de todos los modelos.
Proceso Integrado: Se establece una estructura que abarque los ciclos, fases, flujos de
trabajo, mitigacin de riesgos, control de calidad, gestin del proyecto y control de
configuracin; el proceso unificado establece una estructura que integra todas estas
facetas. Adems esta estructura cubre a los vendedores y desarrolladores de herramientas
para soportar la automatizacin del proceso, soportar flujos individuales de trabajo, para

construir los diferentes modelos e integrar el trabajo a travs del ciclo de vida y a travs de
todos los modelos. La estructura esttica del proceso unificado se define en base a cuatro
elementos, que son: los roles(antes workers), que responde a la pregunta quin?, las
actividades (activities), que responden a la pregunta cmo?, los productos (artifacts), que
responden a la pregunta qu?, y los flujos de trabajo (workflows), que responden a la
pregunta

Los trminos contenidos en la figura 2 son:

Roles: Un rol define el comportamiento y responsabilidades de un individuo, o de un

grupo de individuos trabajando juntos como un equipo. Una persona puede desempear
diversos roles, as como un mismo rol puede ser representado por varias personas. Las
responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el
ser el dueo de un conjunto de artefactos. En la Figura 2 se puede observar la relacin
entre los tres conceptos.

Actividades: Una actividad de un trabajador en concreto es una unidad de trabajo que

una persona que desempee ese rol puede ser solicitado a que realice. Las actividades
tienen un objetivo concreto, normalmente expresado en trminos de crear o actualizar

algn producto.
Productos: Un producto o artefacto es un trozo de informacin que es producido,
modificado o usado por un proceso. Los productos son los resultados tangibles del
proyecto, las cosas que va creando y usando hasta obtener el producto final.
FASES
Las fases describen hitos que debe cumplir el proyecto segn el avance desarrollado. Las
fases son :
Inicio
Esta fase se caracteriza por conceptualizar el proyecto, y sobre todo saber si es factible o
no.
Entre los entregables tenemos:

Visin del negocio: Describe los objetivos y restricciones a alto nivel.

Modelo de casos de uso.
Especificacin adicional: requisitos no funcionales.

Universidad Privada San Juan Bautista

Facultad de Ingenieras
Escuela Profesional de Ingeniera de Computacin y Sistemas

Glosario: Terminologa clave del dominio.

Lista de riesgos y planes de contingencia.
El caso de negocio (business case). Para ms detalles ver el flujo de
modelado del negocio.

Elaboracin
Se caracteriza por lo siguiente:

Definir, validar y cimentar la arquitectura.

Completar la visin.
Crear un plan fiable para la fase de construccin. Este plan puede evolucionar
en sucesivas iteraciones. Debe incluir los costes si procede.
Demostrar que la arquitectura propuesta soportar la visin con un coste razonable
y en un tiempo razonable.

Los productos resultantes de esta fase son:

Un modelo de casos de uso completa al menos hasta el 80%: todos los casos y

actores identificados, la mayora de los casos desarrollados.

Requisitos adicionales.
Descripcin de la arquitectura software.
Un prototipo ejecutable de la arquitectura.
Lista de riesgos y caso de negocio revisados.
Plan de desarrollo para el proyecto.
Un caso de desarrollo actualizado que especifica el proceso a seguir.
Posiblemente un manual de usuario preliminar.

Construccin
Los principales objetivos son de esta fase son :

Minimizar los costes de desarrollo mediante la optimizacin de recursos y evitando

el tener que rehacer un trabajo o incluso desecharlo.

Conseguir una calidad adecuada tan rpido como sea practico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rpido
como sea prctico.

Los artefactos o productos son:

Modelos Completos (Casos de Uso, Anlisis, Diseo, Despliegue e

Implementacin)
Arquitectura ntegra (mantenida y mnimamente actualizada)
Riesgos Presentados Mitigados
Plan del Proyecto para la fase de Transicin

Manual Inicial de Usuario (con suficiente detalle)

Prototipo Operacional beta

Transicin
Los objetivos de esta fase son:

Conseguir que el usuario se valga por si mismo.

Un producto final que cumpla los requisitos esperados, que funcione y satisfaga
suficientemente al usuario.

Los artefactos son :

Prototipo Operacional
Documentos Legales
Caso del Negocio Completo
Lnea de Base del Producto completa y corregida que incluye todos los modelos del

sistema.
Descripcin de la Arquitectura completa y corregida.

DISCIPLINAS
Las disciplinas de RUP son un conjunto de actividades orientadas desde el pun to de vista de un
modelo de cascada o secuencial. Se dividen en dos : Disciplinas de Proceso y Disciplinas de
Soporte.

DISCIPLINAS DE PROCESO
Modelado de Negocio
Esta disciplina explica cmo determinar los procesos de negocio que se van a sistematizar , el
objetivo es conocer el negocio y precisar la viabilidad del proyecto.

Anlisis y Diseo
Esta disciplina explica cmo transformar los productos de trabajo de los requisitos en los
productos de trabajo que especifiquen el diseo del software que el proyecto va a desarrollar.

Requisitos
Esta disciplina explica cmo obtener las solicitudes de los interesados y transformarlas en un
conjunto de productos de trabajo de los requisitos que cubran el mbito del sistema que va a
crearse y proporcionen requisitos detallados sobre lo que el sistema debe hacer.

Implementacin
Esta disciplina explica cmo desarrollar, organizar, realizar pruebas de unidad e integrar los
componentes implementados basndose en las especificaciones de diseo.
Prueba
Esta disciplina proporciona orientacin sobre cmo evaluar y valorar la calidad del producto.

Universidad Privada San Juan Bautista

Facultad de Ingenieras
Escuela Profesional de Ingeniera de Computacin y Sistemas

Despliegue
La disciplina de despliegue describe las actividades asociadas al garantizar que el producto de
software est disponible para los usuarios.

DISCIPLINAS DE SOPORTE
Configuracin y Gestin del Cambios
Esta disciplina explica cmo controlar y sincronizar la evolucin del conjunto de productos de
trabajo que componen un sistema de software.

Entorno
La categora de contenido de disciplina de entorno organiza esos elementos de mtodo que
proporcionan el entorno de desarrollo de software que da soporte al equipo de desarrollo,
incluidos los procesos y las herramientas.

Gestin de Proyecto
Esta disciplina se centra en la planificacin del proyecto, la gestin del riesgo, la supervisin del
progreso y la mtrica.

PORQUE UTILIZAR RUP

RUP proporciona a un profesional de desarrollo de software un entorno de proceso
configurable basado en estndares. Este entorno de proceso:

Permite la publicacin de un mtodo personalizado de Rational Method

Composer y que ste sea accesible a todo el equipo del proyecto.

Permite que ese mtodo se configure para satisfacer las necesidades

exclusivas de cada proyecto.

Proporciona a cada usuario filtrado personalizado.

RUP es una recopilacin de prcticas de ingeniera de software que se estn mejorando

continuamente de forma regular para reflejar los cambios en las prcticas de la industria.

Como interesado en un proyecto de desarrollo de software, RUP le proporciona

informacin sobre lo que puede esperarse de la tarea de desarrollo. Le ofrece un

glosario de terminologa y una enciclopedia de conocimiento que le ayuda a comunicar

sus necesidades de forma eficaz al equipo de desarrollo de software.
Para un profesional de desarrollo de software , este entorno de proceso proporciona una
definicin de proceso comn y central que todos los miembros del equipo de desarrollo
de software pueden compartir, garantizando siempre una comunicacin clara y sin
ambigedades entre los miembros del equipo. De esta manera, estableciendo cules
son sus responsabilidades, podr desempear el papel que el equipo del proyecto
espera de usted. Como consulta general de ingeniera de software, RUP proporciona
una gran cantidad de informacin sobre prcticas de desarrollo de software que tanto los
profesionales principiantes como los experimentados encontrarn de utilidad. Incluso si
es un programador "solitario", encontrar en RUP un mentor til para construir software
de gran calidad.
Como gestor o jefe de equipo, RUP le proporciona un proceso con el que comunicarse de
forma eficaz con el personal y gestionar la planificacin y el control de su trabajo.
Como ingeniero de proceso, RUP le proporciona una buena base de arquitectura y una
gran cantidad de material con las que construir una definicin de proceso, lo que le
permite configurar y ampliar dicha base como desee. Esto le ahorrar mucho tiempo y
esfuerzo que de otra manera tendra que aplicar para crear dicha definicin de proceso
desde cero.