UNIVERSIDAD NACIONAL

DEL SANTA
FACULTAD DE INGENIERIA
E.A.P. SISTEMAS E
INFORMATICA
RESUMEN DEL Proceso
racional unificado
CURSO:
Ingeniera de Software

PROFESOR:
Ing. Noe Silva

INTEGRANTES:
Corales Rivera Diego
Rodrguez Esquivel Luis
Torrealva Mendoza Neyda
Vega Flores Fredy
Alvarado Romn Luis
Palacios Zamudio Brandon

PROCESO RACIONAL UNIFICADO

QU ES PROCESO RACIONAL UNIFICADO ?
Proceso de ingeniera de software que proporciona un enfoque para la
asignacin de tareas y responsabilidades dentro de una organizacin de
desarrollo.
Su objetivo es asegurar la produccin de software de alta calidad que
satisfaga las necesidades de sus usuarios finales.
Las actividades del proceso racional unificado es crear y mantener modelos.
En lugar de centrarse en la produccin de gran cantidad de documentos en
papel, el Proceso Unificado enfatiza el desarrollo y mantenimiento de
modelos-semnticamente ricas en representaciones del sistema de software
en fase de desarrollo.
El proceso racional unificado es una gua para saber cmo utilizar el
Lenguaje Unificado de Modelado(UML). El UML fue creado por Rational
Software, y ahora es mantenido por el Grupo de Gestin organizacin de
estndares de objetos (OMG).
El proceso racional unificado, es un proceso configurable.El Proceso Unificado
se basa en una arquitectura de proceso simple y claro, que puede variar para
adaptarse a diferentes situaciones.

IMPLEMENTACIN
PRCTICAS

EFECTIVA

DE

LAS

MEJORES

El proceso racional unificado, describe cmo implementar enfoques

demostrando el desarrollo de software. stos se llaman las "mejores
prcticas" no tanto porque se puede cuantificar con precisin su valor,
sino ms bien, porque se observan a ser de uso comn.
El proceso racional unificado proporciona a cada miembro del equipo:
Directrices, plantillas y mentores de herramientas necesarias para todo
el equipo para aprovechar al mximo entre otros las siguientes
prcticas:
1. Desarrollar software iterativo
2. Administrar requisitos
3. Utilice las arquitecturas basadas en componentes
4. Software de modelo Visual
5. Verificacion de la calidad del software

6. Control de cambios en el software

1 Desarrollar software Iterativo

Dado los sistemas de software de hoy en da, no es posible
definir todo el problema. Se requiere un enfoque iterativo que
permita una comprensin
del problema a travs de
refinamientos
sucesivos.
El proceso racional unificado apoya con un enfoque iterativo. Este
enfoque iterativo le ayuda a atacar el riesgo a travs de un
progreso demostrable, ejecutable que permiten poner fin a la
participacin
del
usuario
y
la
retroalimentacin.
Un enfoque iterativo tambin hace que sea fcil adaptarse a los
cambios
tcticos
en
requisitos, caractersticas o el horario.
2 Administrar Requisitos
El proceso racional unificado describe cmo obtener, organizar y
documentar la funcionalidad y limitaciones necesarias;
decisiones;
capturar
y comunicar los requerimientos del
negocio. Proporcionan hilos coherentes y trazables, tanto el
desarrollo como el sistema entregado.
3 Utilice las arquitecturas basadas en componentes
El proceso se centra en el desarrollo temprano y lnea de base
de una arquitectura ejecutable robusta, antes de comprometer
recursos para el desarrollo a gran escala. En l se describe cmo
disear una arquitectura que es flexible, comprensible, y
promueve la reutilizacin del software. El Rational Unified Process
ofrece un enfoque sistemtico para la definicin de una
arquitectura utilizando componentes nuevos y existentes. Estos
se ensamblan en una arquitectura bien definida, ya sea ad hoc, o
en un componente de la infraestructura, tal como Internet,
CORBA, COM .
4 Software de modelo visual
El proceso muestra cmo el software de modelo visual captura la
estructura y el comportamiento de arquitecturas y componentes.
Esto le permite ocultar los detalles y escribir cdigos usando
abstracciones visuales que ayudan a comunicar los diferentes
aspectos de su software de "bloques grficos de construccin
El estndar de la industria Unified Modeling Language (UML),
creado por Rational Software, es la base para el modelado visual
exitosa.
5 Verificacin de la Calidad del Software

Pobre rendimiento de las aplicaciones y la escasa fiabilidad son

factores
comunes
que
inhiben la aceptabilidad de las aplicaciones de software. Por lo
tanto, la calidad debe ser revisada basada en la fiabilidad,
funcionalidad, rendimiento de las aplicaciones y el rendimiento
del sistema. El Rational Unified Process le ayuda en la
planificacin, diseo, implementacin, ejecucin y evaluacin de
este tipo de prueba.

6 Control de cambios para software

El proceso describe cmo controlar, rastrear y monitorear los
cambios para permitir el desarrollo iterativo con xito. Tambin le
gua en la forma de establecer espacios de trabajo seguros para
cada desarrollador, proporcionando el aislamiento de los cambios
realizados en otras reas de trabajo y mediante el control de los
cambios de todos los artefactos de software (modelos, cdigos,
documentos, etc.).

VISTA GENERAL DEL PROCESO

El proceso puede describirse en dos dimensiones, o en dos ejes:
El eje horizontal. Representa el tiempo y muestra el aspecto dinmico
del proceso, se expresa en trminos de ciclos, fases, iteraciones e
hitos.
El eje vertical. Representa el aspecto esttico del proceso: La forma
en que se describe en trminos de actividades, artefactos, los
trabajadores y los flujos de trabajo.

FASES E ITERACIONES - LA DIMENSIN DEL TIEMPO

Esta es la organizacin dinmica del proceso a lo largo del tiempo.
El ciclo de vida del software se divide en fases. El Rational Unified Process
divide un ciclo de desarrollo en cuatro fases consecutivas
Fase de Inicio
Fase de Elaboracin
Fase de construccin
Fase de transicin
Cada fase se concluye con un hito, un punto bien definido en el tiempo en el
que deben hacerse ciertas decisiones crticas.

FASE DE INICIO
Durante la fase inicial, se establece el modelo de negocio para el
sistema y se delimita el alcance del proyecto. Para esto es necesario
identificar todas las entidades externas con las que el sistema
interacta y definir la naturaleza de esta interaccin. El resultado de
la fase de inicio es:
Un documento de visin: una visin general de los requisitos del
proyecto bsico, caractersticas clave y las limitaciones principales.
Un modelo de casos de uso inicial (10% -20% de avance).
Un glosario proyecto inicial (se puede expresar en parte como un
modelo
de
dominio).
Un caso de negocio inicial, que incluye el contexto empresarial,
criterios
de,
y
las
previsiones
financieras.

Una
evaluacin
inicial
de
riesgos.
Un plan de proyecto, mostrando fases e iteraciones.

Un
modelo
de
negocio,
si
es
necesario.
Uno o varios prototipos.
OBJETIVOS DEL CICLO DE VIDA: HITO
Los criterios de evaluacin para la fase inicial son:

 Concurrencia de las partes interesadas en la definicin del alcance y

de
las
estimaciones
de
costo
/
horario.
La credibilidad de las estimaciones de costo / horario, prioridades,
riesgos
y
proceso
de
desarrollo.
Profundidad y amplitud de cualquier prototipo arquitectnico que se
desarroll.
Los gastos reales frente a los gastos previstos.
El proyecto puede ser cancelado o reformulado si no logra pasar a
este hito.

FASE DE ELABORACIN
El propsito de la fase de elaboracin es analizar el dominio del
problema, establecer una base arquitectnica de sonido, desarrollar el
plan del proyecto, y eliminar los elementos de mayor riesgo del
proyecto. Para lograr estos objetivos, debe tener la "milla de ancho y
pulgada de profundidad" vista del sistema.
En la fase de elaboracin, un prototipo de la arquitectura ejecutable
est construido en ms iteraciones, en funcin del alcance, tamao,
riesgo y novedad del proyecto.
El resultado de la fase de elaboracin es:
Un modelo de casos de uso (al menos un 80% de avance) - casos de
uso
y
actores
han
sido
identificados.

Una
Arquitectura
Descripcin
del
software.

Un
prototipo
de
arquitectura
ejecutable.
Una lista de riesgos revisados y un caso de negocio revisado.
Un plan de desarrollo para el proyecto en general mostrando
repeticiones y criterios de evaluacin para cada iteracin.
Un caso de desarrollo actualizado especificando el proceso que se
utilizar.
Un manual preliminar (opcional).
HITO:
CICLO
DE
VIDA
ARQUITECTURA
Los principales criterios de evaluacin de la fase de elaboracin implica
las respuestas a estas preguntas:

Es
la
visin
del
producto
estable?

Es
la
arquitectura
estable?
El programa de demostracin ejecutable que los principales
elementos de riesgo se han abordado y resuelto de manera creble?
Es el plan para la fase de construccin suficientemente detallada y
precisa? Es una copia de seguridad con una base creble de las
estimaciones?
Todas las partes interesadas estn de acuerdo en que la visin actual
se puede lograr si el plan actual se ejecuta para desarrollar el sistema
completo,
en
el
contexto
de
la
arquitectura
actual?
Es el gasto de recursos reales en comparacin con los gastos
previstos aceptable?
El proyecto puede ser abortado si no logra pasar a este hito.

FASE DE CONSTRUCCIN
La fase de construccin es un proceso de fabricacin, donde se hace
hincapi en la gestin de los recursos y control de las operaciones para
optimizar
costos,
horarios
y
calidad.
El resultado de la fase de construccin es un producto listo para poner
en manos de sus usuarios finales. Como mnimo, se compone de:
Este producto de software integrado en las plataformas adecuadas.

Los
manuales
de
usuario.
Una descripcin de la versin actual.
HITO: CAPACIDAD OPERATIVA INICIAL
Al final de la fase de construccin( tercer hito importante) .En este
punto, usted decide si el software, los sitios y los usuarios estn
dispuestos a ir operativa, sin exponer el proyecto a altos riesgos. Estp
es llamado comnmente un comunicado de "beta".
Los criterios de evaluacin para la fase de construccin implican
responder a estas preguntas:
Es esta versin del producto estable y lo suficientemente maduro
para
ser
desplegados
en
la
comunidad
de
usuarios?
Son todas las partes interesadas prepararse para la transicin a la
comunidad
de
usuarios?
Son los gastos de recursos reales frente a los gastos previstos
todava aceptable?
La transicin puede ser aplazado por un lanzamiento si el proyecto no
llega a este hito.

FASE DE TRANSICIN
El propsito es la transicin de producto de software para la comunidad
de
usuarios.
La fase de transicin se introduce cuando una lnea de base es lo
suficientemente maduro para ser desplegados en el dominio del
usuario
final.
Esto requiere que algn subconjunto utilizable del sistema ha sido
completado a un nivel aceptable de calidad y que la documentacin de
usuario est disponible para que la transicin al usuario de positivo
resultados para todas las partes. Esto incluye:
"Pruebas beta" para validar el nuevo sistema frente a las expectativas
de
los
usuarios
Funcionamiento en paralelo con un sistema heredado que est
reemplazando

Conversin
de
bases
de
datos
operacionales

Formacin
de
los
usuarios
y
mantenedores
Puesta en marcha del producto para la comercializacin, distribucin
y equipos de ventas
Los objetivos principales de la fase de transicin incluyen:


Lograr
usuario
auto-compatibilidad
Lograr la concurrencia de las partes interesadas de que las lneas de
base de despliegue son completos y coherentes con los criterios de
evaluacin.
HITO: PRODUCTO DE ESTRENO
Al final de la fase de transicin, es el cuarto hito importante
proyecto.Aqui, usted decide si se cumplieron los objetivos, y si debe
iniciar otro ciclo de desarrollo. En algunos casos, este hito puede
coincidir con el final de la fase de inicio para el siguiente ciclo.
Los criterios de evaluacin principales para la fase de transicin
implican las respuestas a estas preguntas:

Est
satisfecho
el
usuario?
Son los gastos de recursos reales frente a los gastos previstos
todava aceptable?

ESTRUCTURA ESTTICA DEL PROCESO

Un proceso describe quin est haciendo qu, cmo y cundo. El
Rational Unified Process se representa usando cuatro elementos:

Trabajadores,
el
'quin'

Actividades,
el
"cmo"

Los
artefactos,
el
"qu"
Flujos de trabajo, el "cundo"
TRABAJADOR:
Define el comportamiento y las responsabilidades de un individuo, o
un grupo de individuos que trabajan juntos como un equipo.
ACTIVIDAD
La actividad de un trabajador especfico es una unidad de trabajo que
se
le
puede
pedir
para
llevar
a
cabo.
Una actividad debe ser utilizable como elemento de la planificacin y
progreso
Ejemplo
de
actividades:
Planificar una iteracin, para el trabajador: Project Manager
Encuentra casos de uso y actores, para el trabajador: Analista de
Sistemas

Revisar
el
diseo,
para
el
trabajador:
Diseo
Crtico

ARTEFACTO
Los artefactos son los productos tangibles del proyecto, las cosas que
el proyecto produce o utiliza mientras se trabaja hacia el producto
final. Los artefactos pueden adoptar diversas formas:


Un
modelo.

Un
elemento
del
modelo.
Un documento (caso de negocio o Arquitectura de Software de
documentos)
Cdigo fuente

FLUJOS DE TRABAJO
Un flujo de trabajo es una secuencia de actividades que produce un
resultado de valor observable.
En trminos de UML, un flujo de trabajo se puede expresar como un
diagrama de secuencia, de colaboracin, o de actividad.

FLUJOS DE TRABAJO FUNDAMENTALES

MODELADO DE NEGOCIOS
El Rational Unified Process aborda esto proporcionando un lenguaje y un
proceso comn para la ingeniera de negocios e ingeniera de software, as
como los que muestra cmo crear y mantener la trazabilidad directa entre las
empresas y modelos de software.
Los casos de uso del negocio son analizados para entender cmo la empresa
debe apoyar los procesos de negocio

REQUERIMIENTOS
Es describir lo que el sistema debe hacer y permite a los desarrolladores

Se crea un documento de Visin.

Los actores se identifican, en representacin de los usuarios, y
cualquier otro sistema que pueden interactuar con el sistema que se
est desarrollando.
Los casos de uso se identifican, representa el comportamiento del
sistema. Debido a que los casos de uso se desarrollan de acuerdo a las
necesidades de los actores.
Cada caso de uso se describe en detalle.

ESPECIFICACIONES.

Los casos de uso funcionan como un hilo conductor a lo largo del ciclo de
desarrollo del sistema. El mismo caso de uso
modelo se utiliza durante la captura de requisitos, anlisis y diseo, y la
prueba.
Anlisis y Diseo El objetivo del flujo de trabajo de Anlisis y Diseo es
mostrar cmo se realizar el sistema en la fase de implementacin. Usted
quiere construir un sistema que:

Realiza en una implementacin especfica con el medio ambiente de

las tareas y funciones especificadas en el caso de uso
Cumple con todos sus requisitos.
Est estructurado para ser robusto (fcil cambiar si y cuando sus
requisitos funcionales cambian).

Los resultados del anlisis y diseo de un modelo de diseo

opcionalmente, un modelo de anlisis. El modelo de diseo sirve como

y,

El modelo de diseo consiste en clases de diseo estructurados en paquetes

de diseo y subsistemas de diseo con interfaces bien definidas, lo que
representa lo que se convertir en componentes de la aplicacin. Tambin
contiene descripciones de cmo los objetos de estas clases de diseo
colaboran para llevar a cabo los casos de uso.

IMPLEMENTACIN
El propsito de la aplicacin son:
Para definir la organizacin del cdigo, en trminos de subsistemas de
implementacin organizados en capas.
Implementar clases y objetos en trminos de componentes (archivos de
cdigo fuente, binarios, ejecutables, y
otros).
Para probar los componentes desarrollados como unidades.
Integrar los resultados producidos por los ejecutores individuales (o
equipos), en un archivo ejecutable

PRUEBA:
Los propsitos de la prueba son:
- Para comprobar la interaccin entre los objetos.
- Para verificar la adecuada integracin de todos los componentes del
software.
- Para verificar
correctamente.

que

todos

los

requisitos

se

han

aplicado

- Identificar y asegurar defectos se tratan antes de la implementacin

del software.

La prueba se lleva a cabo a lo largo de tres dimensiones: fiabilidad de

calidad, funcionalidad, rendimiento de las aplicaciones y el rendimiento del
sistema

DESPLIEGUE:
El propsito del flujo de trabajo de despliegue es para producir con xito
versiones de productos, y entregar el software a sus usuarios finales.
Incluyendo las actividades:
- Produccin de comunicados externas del software.
- Empaquetado software.
- La distribucin de software.
- Instalacin del software.
- Proporcionar ayuda y asistencia a los usuarios.
En muchos casos, esto tambin incluye actividades tales como:
- Planificacin y realizacin de pruebas beta.
- Migracin de software o datos existentes.
- La aceptacin formal.
Muchas de las actividades necesitan ser incluidos en fases anteriores para
preparar para el despliegue en el final de la fase de construccin.

GESTIN DE PROYECTOS:
Es el arte de equilibrar los objetivos de la competencia, la gestin del riesgo,
y la superacin de las limitaciones para ofrecer, con xito, un producto que
satisfaga las necesidades de los clientes (los pagadores de facturas) y los
usuarios.
Nuestro objetivo con esta seccin es hacer la tarea ms fcil al proporcionar:
- Un marco para la gestin de proyectos intensivos en software.
- Directrices prcticas para la planificacin, dotacin de personal,
ejecucin y seguimiento de proyectos.
- Un marco para la gestin del riesgo.

GESTIN DE CONFIGURACIN Y CAMBIO

En este flujo de trabajo se describe la forma de controlar los numerosos
artefactos producidos. Control ayuda a evitar la confusin costosa, y se
asegura de que los artefactos resultantes no estn en conflicto debido a
algunos de los siguientes tipos de problemas:
- Actualizacin simultnea Cuando dos o ms trabajadores trabajan
por separado en el mismo artefacto.
- Notificacin Limitado Cuando un problema se resuelve en
artefactos compartidos por varios desarrolladores.
- Varias versiones se desarrollan programas ms grandes en las
versiones evolutivas. Una liberacin podra estar en uso de los
clientes, mientras que otro es en la prueba, y el tercero an est en
desarrollo.
Este flujo de trabajo proporciona directrices para la gestin de mltiples
variantes de la evolucin de los sistemas de software, seguimiento de las que
se utilizan en las versiones de software dada construye, construye la

realizacin de los programas individuales o en lanzamientos completos de

acuerdo con especificaciones de la versin definidos por el usuario, y hacer
cumplir las polticas de desarrollo especficas del sitio.

AMBIENTE
El propsito del flujo de trabajo del ambiente es proporcionar a la
organizacin de desarrollo de software junto al entorno de desarrollo de
software, los procesos y las herramientas que se necesitan para apoyar al
equipo de desarrollo.
Este flujo de trabajo se centra en las actividades para configurar el proceso
en el contexto de un proyecto. Tambin se centran en actividades para
desarrollar las pautas necesarias para apoyar un proyecto. Un procedimiento
paso a paso se proporciona describiendo cmo se implementa un proceso en
una organizacin.
Ciertos aspectos del flujo de trabajo del Ambiente no estn cubiertos en el
proceso, como la seleccin, adquisicin, y fabricacin de las herramientas de
trabajo, y mantenimiento del entorno de desarrollo.

PROCESO RACIONAL UNIFICADO- EL PRODUCTO

El producto Proceso racional unificado consiste en:
Una base de conocimientos de bsqueda habilitado para la web que
proporciona todos los miembros del equipo con guas, plantillas y mentores
de herramientas para todas las actividades crticas de desarrollo. La base de
conocimientos se puede dividir a:

Directrices amplias para todos los miembros del equipo, y todas las
partes del ciclo de vida del software. Se proporciona orientacin tanto
para el proceso de pensamiento de alto nivel, as como para las
actividades ms tediosas del da a da.
Mentores de herramientas que proporciona una gua prctica para
disfrutar de herramientas que cubren el ciclo de vida completo. Los
mentores de la herramienta se publican en forma de HTML para la
plataforma fcil.
Rose racionales Ejemplos y plantillas que proporcionan orientacin
para saber cmo estructurar la informacin en Rational Rose cuando se
sigue el Rational Unified Proceso (Rational Rose es la herramienta de
Rational para el modelado visual).
Planes de Proyecto Microsoft, Muchos gerentes tienen dificultades para
crear planes de proyecto que refleja un enfoque de desarrollo iterativo.
Nuestras plantillas inician la creacin de planes de proyectos para el
desarrollo iterativo, segn el Rational Unified Process.
Kit de Desarrollo, se describe cmo personalizar y ampliar el Rational
Unified Process a las necesidades especficas de la organizacin o
proyecto, as como proporciona herramientas y plantillas para ayudar
el esfuerzo.

El acceso a centro de recursos que contiene las ltimas blanco

papeles, actualizaciones, consejos y tcnicas, as como las referencias
a aadir productos y servicios.

INTEGRACIN CON HERRAMIENTAS

Un proceso de ingeniera de software requiere de herramientas para apoyar
todas las actividades en el ciclo de vida del sistema, especialmente para
apoyar el desarrollo, el mantenimiento y la contabilidad de varios artefactosmodelos en particular.
Un proceso de desarrollo iterativo pone requisitos especiales en el conjunto
de herramientas que utiliza, como una mejor integracin entre las
herramientas y la ingeniera de ida y vuelta entre los modelos y el cdigo.
A continuacin encontrar una lista de algunas de las herramientas de
Rational que apoyan el Proceso Racional Unificado. Una herramienta Mentor
es una gua paso a paso que describe en detalle la forma de operar una
herramienta.

Rational RequisitePro

Rational
Rational
Rational
Rational
Rational

ClearQuest
Rose 98
SoDA
Purify
Visual Quantify

Rational
PureCoverage
Rational TeamTest
Rational
PerformanceStudio
Rational ClearCase

Visual

UNA BREVE
UNIFICADO

HISTORIA

DEL

PROCESO

RACIONAL

El Proceso Racional Unificado ha madurado a lo largo de muchos aos y

refleja la experiencia colectiva de las muchas personas y empresas que
conforman el rico patrimonio actual de Software Rational.
Vamos a echar un vistazo rpido a la ascendencia de este proceso, como se
ilustra en la figura siguiente:

El Proceso Racional Unificado es el sucesor directo del Proceso Objectory

Racional (versin 4). El Proceso Racional Unificado incorpora ms material
en las reas de ingeniera de datos, modelado de negocios, gestin de
proyectos y gestin de la configuracin.
El Proceso Objectory racional fue el resultado de la integracin del "Enfoque
racional" y el proceso Objectory (versin 3).
Esta versin tambin incorpora material sobre la gestin de requisitos de
Requisitos, Inc. y un proceso de prueba detallado heredado de SQA, Inc. ,
las empresas que tambin se fusionaron con Software Rational.
Por ltimo, este proceso fue el primero en utilizar el recin creado Lenguaje
de Modelamiento Unificado (UML 0.8). El proceso Objectory se cre en
Suecia en 1987 por Ivar Jacobson como resultado de su experiencia con
Ericsson. Centrado en el concepto de caso de uso y un mtodo de diseo
orientado a objetos, que rpidamente gan reconocimiento en la industria
del software y ha sido adoptado e integrado por muchas empresas en todo
el mundo.