Proceso racional unificado

Las mejores prcticas para equipos de

desarrollo de software

Rational Software Libro Blanco

TP026B, Rev 11/01
 Tabla de contenido

QU ES EL RUP? .................................................. .............................. 1

Despliegue efectivo de 6 MEJORES PRCTICAS ............................................ ............................ 1

VISTA GENERAL DEL PROCESO ................................................ .................................................. ............................ 3

T WO D IMENSIONES ................................................. .................................................. ..................................... 3

FASES Y ITERACIONES - la dimensin del tiempo ........................................... ........................... 3

yo NCEPTION P ASE ................................................. .................................................. ..................................... 4 E cola- P ASE

................................................. .................................................. ............................... 4 C ONSTRUCTION P ASE
................................................. .................................................. ............................. 6 T RANSICIN P ASE
................................................. .................................................. .................................. 6 I TERATIONS .................................................
.................................................. .............................................. 7

ESTRUCTURA esttica del proceso ............................................. ................................................ 7

UN ACTIVIDADES, A RTIFACTS y W TRABAJADORES ................................................. .................................................. . 8 W ORKFLOWS

................................................. .................................................. ............................................ 9

FLUJOS DE TRABAJO ESENCIALES ................................................ .................................................. ........................... 10

segundo EGOCIOS M ODELING ................................................. .................................................. ............................. 10 R EQUERIMIENTOS

................................................. .................................................. ...................................... 11 A ANLISIS + D ESIGN
................................................. .................................................. .............................. 11 I MPLEMENTACIN .................................................
.................................................. ................................... 12 T EST ................................................. ..................................................
.................................................. ..... 12 D EPLOYMENT ................................................. ..................................................
......................................... 13 P PROYECTO M GESTIN ................................................. .................................................. .........................
13 C ONFIGURACIN & C AMBIO M GESTIN ................................................. ............................................ 13 E MBIENTE
................................................. .................................................. ....................................... 14

RACIONAL proceso unificado - PRODUCTO ............................................ ............................... 14

norte AVIGATING LA K ONOCIMIENTO B PLAZA BURSTIL NORTEAMERICANA................................................. .................................................. ..... 15 D ESARROLLO

K IT PARA P ROCESO C USTOMIZATION ................................................. ................................. 15

Integracin con herramientas ............................................... .................................................. .............. diecisis

BREVE HISTORIA DE LA Rational Unified Process .......................................... .............. diecisis

R EFERENCIAS ................................................. .................................................. ........................................... 18

Abstracto
Este artculo presenta una visin general del Rational Unified Process Rational Unified Process es un proceso de ingeniera de software, entregado a travs de
una base de conocimiento con conexin a Internet. El proceso de mejora la productividad del equipo y proporciona mejores prcticas de software a travs de
guas, plantillas y mentores de herramientas para todas las actividades crticas del ciclo de vida del software. La base de conocimientos permite a los equipos de
desarrollo para obtener los beneficios completos del Lenguaje de Modelado Unificado estndar de la industria (UML).
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Cul es el Rational Unified Process?

El Unified Process racional es una Ingeniera de Software Proces s. Proporciona un enfoque disciplinado 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, dentro de un
horario predecible y presupuesto. [11, 13]

RUP es una produc proceso t, desarrollado y mantenido por Rational Software. El equipo de desarrollo para el Proceso Unificado de Desarrollo estn trabajando

estrechamente con los clientes, socios, grupos de productos de Rational, as como organizacin consultora de racional, para asegurar que el proceso se actualiza

continuamente y mejorado para reflejar las experiencias recientes y en evolucin y las mejores prcticas comprobadas. El Rational Unified Process mejora productivit

equipo Y, proporcionando cada miembro del equipo, con fcil acceso a una base de conocimientos con las directrices, modelos y mentores de herramientas para todas
las actividades de desarrollo crticos. Al tener todos los miembros del equipo de acceso a la misma base de conocimiento, no importa si se trabaja con requerimientos,

diseo, pruebas, gestin de proyectos, o la gestin de configuracin, nos aseguramos de que todos los miembros del equipo comparten un lenguaje comn, el proceso

y la vista de la forma de desarrollar software.

Las actividades Rational Unified Process crear y mantener modelo s. En lugar de centrarse en la produccin de gran cantidad de documentos
en papel, el proceso unificado hace hincapi en el desarrollo y mantenimiento de
modelo s-semnticamente ricas representaciones del sistema de software en fase de desarrollo. [3, 7, 8] El Proceso Unificado Rational es una

gua para saber cmo utilizar efectivamente la Lenguaje de Modelado Unificado

(UML). El UML es un lenguaje estndar de la industria que nos permite comunicar claramente los requisitos, arquitecturas y diseos. El UML fue creado

originalmente por Rational Software, y ahora es mantenido por el Grupo de Gestin de organizacin de estndares de objetos (OMG). [4] El Proceso Unificado

Rational es apoyado por herramienta s, que automatizan grandes partes del proceso. Se utilizan para crear y mantener los diversos artefactos-modelos, en

particular, del proceso de ingeniera de software: modelado visual, programacin, pruebas, etc. que son de gran valor en el apoyo de toda la contabilidad

asociada a la gestin del cambio, as como la gestin de la configuracin que se acompaa cada iteracin. RUP es una configurable proceso. No solo proceso

es adecuado para todo el desarrollo de software. El Proceso Unificado se ajusta a los equipos de desarrollo pequeos, as como las organizaciones de

desarrollo de gran tamao. El Proceso Unificado se basa en una simple y clara arquitectura de procesos que proporciona comn a travs de una familia de

procesos. Sin embargo, se puede variar para adaptarse a diferentes situaciones. Contiene un kit de desarrollo, proporcionando soporte para configurar el

proceso para satisfacer las necesidades de una organizacin determinada. El Rational Unified Process captura muchas de las mejores prcticas en desarrollo

de software moderno en una forma que es adecuada para una amplia gama de proyectos y organizaciones. La implementacin de estas mejores prcticas

mediante el Rational Unified Process como su gua ofrece a los equipos de desarrollo de una serie de ventajas clave. En la siguiente seccin, se describen los

seis mejores prcticas fundamentales del Rational Unified Process.

Implementacin efectiva de 6 Mejores Prcticas

RUP describe cmo implementar efectivamente enfoques probados comercialmente para el desarrollo de software para equipos de desarrollo de
software. Son los llamados mejores prcticas no tanto porque se puede cuantificar con precisin su valor, sino ms bien, ya que se observan a ser
de uso comn en la industria de las organizaciones exitosas. El Rational Unified Process proporciona a cada miembro del equipo con las directrices,
modelos y mentores herramienta necesaria para todo el equipo para aprovechar al mximo entre otros, los siguientes mejores prcticas:

1. Desarrollar software de forma iterativa

2. Manejo de los requisitos

3. Utilice las arquitecturas basadas en componentes

1
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

4. Software modelo Visualmente

5. Verificar la calidad del software

6. Control de cambios en el software

Desarrollar software Iterativamente Teniendo en cuenta los sistemas de software sofisticados de hoy en da, no es posible secuencialmente primero definir todo el
problema, disear toda la solucin, construir el software y luego probar el producto al final. Se requiere un enfoque iterativo que permite una comprensin cada vez mayor del
problema a travs de sucesivos refinamientos, y crecer de forma incremental una solucin eficaz a travs de mltiples iteraciones. El Proceso Unificado de Desarrollo apoya
un enfoque iterativo para el desarrollo que se ocupa de los elementos de mayor riesgo en todas las etapas del ciclo de vida, lo que reduce significativamente el perfil de riesgo
de un proyecto. Este enfoque iterativo ayuda a atacar a los riesgos a travs de comunicados de progreso demostrable frecuentes, ejecutables que permiten la participacin del
usuario final y la retroalimentacin continua. Debido a que cada iteracin termina con una versin ejecutable, el equipo de desarrollo se mantiene enfocado en la produccin
de resultados, y comprobaciones de estado frecuentes ayudan a asegurar que el proyecto se mantiene en la fecha prevista. Un enfoque iterativo tambin hace que sea ms
fcil para adaptarse a los cambios tcticos en los requisitos, caractersticas o el horario. [1, 2, 10]

gestionar los requisitos de RUP describe cmo producir, organizar y documentar la funcionalidad y las restricciones requerido; pista y compensaciones de
documentos y decisiones; y fcilmente capturar y comunicar los requerimientos del negocio. Las nociones de casos de uso y escenarios prohibidos en el
proceso ha demostrado ser una excelente manera de capturar los requisitos funcionales y para asegurar que stos conducen el diseo, implementacin y
pruebas de software, por lo que es ms probable que el sistema final cumple con las necesidades de los usuarios finales . Proporcionan hilos coherentes y
trazables a travs de tanto el desarrollo como el sistema entregado. [7]

Las arquitecturas basadas en componentes Uso El proceso se centra en el desarrollo temprano y la 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 flexible que es flexible, se adapta
cambio, es intuitivamente comprensible, y promueve la reutilizacin de software ms eficaz. El Proceso Unificado Rational apoya basado en componentes de
desarrollo de software.
Los componentes son mdulos no triviales, subsistemas que cumplen una funcin clara. El Rational Unified Process ofrece un enfoque sistemtico para definir
una arquitectura utilizando componentes nuevos y existentes. Estos se ensamblan en una arquitectura bien definida, o bien ad hoc, o en una infraestructura de
componente, tal como la Internet, CORBA, COM y, para los que est surgiendo una industria de componentes reutilizables. [5]

Visualmente Software Modelo El proceso muestra cmo visualmente modelo de software para capturar la estructura y el comportamiento de
arquitecturas y componentes. Esto le permite ocultar los detalles y escribir cdigo usando abstracciones visuales ayudan a comunicar diferentes
aspectos de su software de bloques de construccin grficas.; ver cmo los elementos del sistema encajan entre s; asegurarse de que los
componentes son acordes con su cdigo; mantener la coherencia entre un diseo y su aplicacin; y promover la comunicacin inequvoca. El
estndar de la industria Unified Modeling Language (UML), creado por Rational Software, es la base para el modelado visual exitosa. [4, 12]

Verificar la calidad del software rendimiento de las aplicaciones pobre y escasa fiabilidad son factores comunes que inhiben de manera espectacular la aceptabilidad
de las aplicaciones de software de hoy en da. Por lo tanto, la calidad debe ser revisada con respecto a los requisitos basados 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. Evaluacin de la calidad est integrado en el proceso, en todas las actividades, la participacin de todos los participantes, utilizando medidas y criterios objetivos y
no tratado como un elemento secundario o como una actividad separada realizada por un grupo separado.

Los cambios de control a software La capacidad para gestionar el cambio est haciendo seguro de que cada cambio es aceptable, y ser capaz de seguir los cambios es
esencial en un entorno en el que el cambio es inevitable. El proceso describe cmo controlar, rastrear y monitorear los cambios para permitir el desarrollo iterativo xito.
Tambin le gua en la forma de establecer espacios de trabajo seguros para cada desarrollador proporcionando el aislamiento de los cambios realizados en otros espacios de
trabajo y mediante el control de los cambios de todos los artefactos de software (por ejemplo, modelos, cdigo, documentos, etc.). Y aporta un equipo para trabajar como una
sola unidad mediante la descripcin de cmo automatizar la integracin y la gestin de la construccin.

2
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Vista general del proceso

Dos dimensiones
El proceso puede describirse en dos dimensiones, o a lo largo de dos ejes:

el eje horizontal representa el tiempo y muestra el aspecto dinmico del proceso, ya que se promulg, y 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.

El grfico iterativo modelo muestra cmo el proceso se estructura a lo largo de dos dimensiones

Fases e iteraciones - La dimensin temporal

Esta es la organizacin dinmica del proceso a lo largo del tiempo. El ciclo de vida del software se divide en ciclo s, cada ciclo de trabajo

de una nueva generacin de producto. El Rational Unified Process divide un ciclo de desarrollo en cuatro consecutivos fases [ 10]

fase de inicio
fase de elaboracin
Fase de construccin
Fase de transicin

Cada fase se concluy con una bien definida Mileston e-un punto en el tiempo en el que deben realizarse ciertas decisiones crticas, y por lo tanto deben se
han logrado los objetivos clave [2].

Las fases y los hitos ms importantes en el proceso.

3
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Cada fase tiene un propsito especfico.

Fase de inicio

Durante la fase inicial, se establece el modelo de negocio para el sistema y delimitar el alcance del proyecto. Para lograr esto debe identificar todas
las entidades externas con las que el sistema va a interactuar (actores) y definir la naturaleza de esta interaccin a un alto nivel. Esto implica
identificar todos los casos de uso y la descripcin de unos pocos significativos. El modelo de negocio incluye criterios de xito, evaluacin de riesgos
y estimacin de los recursos necesarios, y un plan de fases que muestra las fechas de los hitos ms importantes. [10, 14] El resultado de la fase de
inicio es:

Un documento de visin: una visin general de los requisitos del proyecto bsico, las funciones principales y las limitaciones principales.

Un modelo de casos de uso inicial (10% -20%) completa).

Un glosario proyecto inicial (puede ser opcionalmente expresada en parte como un modelo de dominio).

Un caso de negocio inicial, que incluye contexto empresarial, criterios de xito (proyeccin de ingresos, el reconocimiento del mercado, y as sucesivamente),
y el pronstico financiero.

Una evaluacin inicial de riesgos.

Un plan de proyecto, que muestra fases e iteraciones.

Un modelo de negocio, si es necesario.

Uno o varios prototipos.

Objetivos del ciclo de vida: Milestone

Al final de la fase de inicio es el primer gran hito del proyecto: el ciclo de vida Objetivos Milestone. Los criterios de evaluacin para la fase
inicial son los siguientes:

concurrencia de las partes interesadas en la definicin del alcance y las estimaciones de costo / horario.

Requisitos para entender como lo demuestra la fidelidad de los casos de uso principales.
La credibilidad de las estimaciones de costo / horario, las prioridades, los 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 cancelada o considerablemente re-pens si no logra pasar 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 ms riesgo del proyecto. Para lograr estos objetivos, debe tener la milla de ancho y de pulgada de profundidad vista del sistema.
decisiones arquitectnicas tienen que hacerse con una comprensin de todo el sistema: su mbito de aplicacin, mayor funcionalidad y los requisitos no
funcionales tales como los requisitos de rendimiento.

Es fcil argumentar que la fase de elaboracin es la ms crtica de las cuatro fases. Al final de esta fase, el disco ingeniera se considera completa y el proyecto
sufre su ms importante da de la verdad: la decisin sobre si debe o no comprometerse con las fases de construccin y de transicin. Para la mayora de los
proyectos, esto tambin corresponde a la transicin desde un telfono mvil, ligero y gil, operacin de bajo riesgo con un alto costo, operacin de alto riesgo con
la inercia considerable. Si bien el proceso siempre debe adaptarse a los cambios, las actividades de la fase de elaboracin garantizan que la arquitectura, los
requisitos y los planes son lo suficientemente estables, y los riesgos son suficientemente mitigados, para que pueda determinar el costo predecible y calendario de
la finalizacin del desarrollo. Conceptualmente, este nivel de fidelidad se correspondera con el nivel necesario para una organizacin para comprometerse a una
fase de construccin de precio fijo.

4
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

En la fase de elaboracin, un prototipo de la arquitectura ejecutable se genera en una o ms iteraciones, dependiendo del alcance, el tamao, el riesgo y novedad
del proyecto. Este esfuerzo debera al menos hacer frente a los casos de uso crticos identificados en la fase inicial, que suele exponer los principales riesgos
tcnicos del proyecto. Mientras que un prototipo evolutivo de un componente de calidad de produccin es siempre el objetivo, esto no excluye el desarrollo de uno
o varios prototipos de exploracin, de usar y tirar para mitigar los riesgos especficos como diseo / requisitos compensaciones, estudio componente de viabilidad,
o demostraciones a los inversores , los clientes y usuarios finales.

El resultado de la fase de elaboracin es:

Un modelo de casos de uso (por lo menos 80% completa) - todos los casos de uso y actores han sido identificados, y las descripciones de casos ms uso- se
han desarrollado.

Los requisitos suplementarios captura de los requisitos no funcionales y los requisitos que no estn asociados con un caso de uso
especfico.
A Descripcin Arquitectura de Software.
Un prototipo de arquitectura ejecutable.
Una lista revisada de riesgos y un modelo de negocio revisado.

Un plan de desarrollo de todo el proyecto, incluyendo el plan de proyecto de grano grueso, mostrando iteracionesy criterios de evaluacin para
cada iteracin.
Un caso de desarrollo actualizado especificando el proceso que se utilizar.

Un manual de usuario preliminar (opcional).

Milestone: Ciclo de vida Arquitectura

Al final de la fase de elaboracin es el segundo hito importante proyecto, el ciclo de vida de Arquitectura Milestone. En este punto, se examina en
detalle los objetivos y el alcance del sistema, la eleccin de la arquitectura, y la resolucin de los principales riesgos.

Los principales criterios de evaluacin para la fase de elaboracin involucra las respuestas a estas preguntas:

Es la visin del producto estable?

Es estable la arquitectura?
Qu muestra la 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 respaldada con una base creble de las estimaciones?

Estn de acuerdo todas las partes interesadas que la visin actual se puede lograr si se ejecuta el plan actual para desarrollar el sistema completo,
en el contexto de la arquitectura actual?
Es el gasto de recursos reales en comparacin con el gasto previsto aceptable? El proyecto puede

ser abortado o considerablemente re-pens si no logra pasar este hito.

5
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Fase de construccin

Durante la fase de construccin, todos los componentes restantes y las caractersticas de aplicacin se desarrollan y se integran en el producto, y todas las
caractersticas se prueban a fondo. La fase de construccin es, en cierto sentido, un proceso de fabricacin, donde se hace hincapi en la gestin de los recursos y
el control de las operaciones para optimizar los costos, horarios y calidad. En este sentido, la mentalidad de gestin experimenta una transicin desde el desarrollo
de la propiedad intelectual durante el inicio y elaboracin, con el desarrollo de productos de despliegue durante la construccin y transicin. Muchos proyectos son lo
suficientemente grandes incrementos de construccin paralelas pueden ser generado. Estas actividades paralelas pueden acelerar significativamente la
disponibilidad de los comunicados de despliegue; tambin pueden aumentar la complejidad de la gestin de recursos y la sincronizacin de flujo de trabajo. Una
arquitectura robusta y un plan comprensible son altamente correlacionada. En otras palabras, una de las cualidades esenciales de la arquitectura es su facilidad de
construccin. Esta es una razn por qu se hizo hincapi en el desarrollo equilibrado de la arquitectura y el plan durante la fase de elaboracin. El resultado de la
fase de construccin es un producto listo para poner en manos de sus usuarios finales. Como mnimo, se compone de:

El producto de software integrado en las plataformas adecuadas.

Los manuales de usuario.

Una descripcin de la versin actual.

Milestone: capacidad operativa inicial

Al final de la fase de construccin es el tercer hito importante proyecto (inicial Milestone capacidad operativa). En este punto, se decide si el software, los

sitios y los usuarios estn listos para ir operativa, sin exponer el proyecto a altos riesgos. Este lanzamiento es a menudo llamado 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 madura lo suficiente como para ser desplegados en la comunidad de usuarios?

Son todas las partes interesadas listo para la transicin a la comunidad de usuarios?

Son los gastos de recursos reales frente a los gastos previstos todava aceptable? La transicin puede tener que

ser aplazado un comunicado de si el proyecto no llega a alcanzar este hito.

Fase de transicin

El propsito de la fase de transicin es la transicin del producto de software para la comunidad de usuarios. Una vez que el producto se ha dado al usuario final, los problemas
suelen surgir que hacen que deba desarrollar nuevos lanzamientos, corregir algunos problemas, o terminar las caractersticas que fueron pospuestas.

La fase de transicin se introduce cuando una lnea de base es lo suficientemente maduro para ser desplegado en el dominio del usuario final. Esto normalmente 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 para el

usuario proporcionar resultados positivos para todas las partes. Esto incluye:

Pruebas beta para validar el nuevo sistema frente a las expectativas de los usuarios

el funcionamiento en paralelo con un sistema heredado que est reemplazando

conversin de bases de datos operacionales

formacin de los usuarios y mantenedores

roll-out del producto para la comercializacin, la distribucin y los equipos de ventas

6
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

La fase de transicin se centra en las actividades necesarias para colocar el software en manos de los usuarios. Tpicamente, esta fase incluye varias iteraciones, incluyendo

versiones beta, comunicados de la disponibilidad generales, as como correccin de errores y comunicados de mejora. Un esfuerzo considerable se gasta en el desarrollo de la

documentacin orientada al usuario, la formacin de los usuarios, el apoyo a los usuarios en su uso inicial del producto, y reaccionando a comentarios de los usuarios. En este

punto en el ciclo de vida, sin embargo, la regeneracin de usuario debe limitarse principalmente a la sintonizacin del producto, configuracin, instalacin y problemas de

usabilidad. Los objetivos principales de la fase de transicin incluyen:

El logro de usuario auto-compatibilidad

El logro de los interesados concurrencia que las lneas de base de despliegue es completa y coherente con los criterios theevaluation
de la visin
El logro de la lnea de base producto final lo ms rpidamente y de manera rentable como sea prctico

Esta fase puede variar de ser muy simple a extremadamente compleja, dependiendo del tipo de producto. Por ejemplo, una nueva versin de un producto de escritorio
existente puede ser muy simple, mientras que la sustitucin de sistema de control de trfico areo de una nacin sera muy complejo.

Milestone: Lanzamiento Categoras

Al final de la fase de transicin es el cuarto hito importante proyecto, el producto de liberacin Milestone. En este punto, 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:

Se satisface al usuario?
Son los gastos de recursos reales frente a los gastos previstos todava aceptable?

iteraciones
Cada fase del proceso de Rational Unified puede subdividirse en iteraciones. Un iteracin es un bucle completo desarrollo que resulta en una liberacin
(interna o externa) de un producto ejecutable, un subconjunto del producto final en fase de desarrollo, que crece de forma incremental a partir de iteracin
a iteracin para convertirse en el sistema final [10].

Beneficios de un enfoque iterativo

En comparacin con el proceso tradicional cascada, el proceso iterativo tiene las siguientes ventajas:

Los riesgos se ven mitigados antes

El cambio es ms manejable
mayor nivel de reutilizacin

El equipo del proyecto puede aprender en el camino

Mejor calidad general

Estructura esttica del Proceso

Un proceso describe quien est haciendo wha t, Ho w, y cuando. RUP se representa mediante cuatro elementos de modelado
primarios:

Los trabajadores, el 'quin'

Actividades, el 'cmo'
Artefactos, el 'qu'
Flujos de trabajo, el 'cundo'

7
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Actividades, Artefactos, y Trabajadores

Los trabajadores, actividades y artefactos.

Obrero
UN obrero define el comportamiento y las responsabilidades de un individuo, o un grupo de individuos que trabajan juntos como un equipo. Se podra
considerar que un trabajador como un "sombrero" un individuo puede usar en el proyecto. Un individuo puede usar muchos sombreros diferentes. Esta es una
distincin importante porque es natural pensar en un trabajador como el individuo o el equipo en s, sino en el proceso unificado del trabajador es ms el papel
que define cmo las personas deben llevar a cabo el trabajo. Las responsabilidades que le asignan a un trabajador incluye tanto para llevar a cabo un cierto
conjunto de actividades, adems de ser propietario de un conjunto de artefactos.

La gente y los trabajadores

Actividad

Un actividad de un trabajador especfico es una unidad de trabajo que una persona en ese papel se le puede pedir para llevar a cabo. La actividad tiene un propsito claro,

generalmente expresada en trminos de creacin o actualizacin de algunos artefactos, como un modelo, una clase, un plan. Cada actividad se asigna a un determinado

trabajador. La granularidad de una actividad generalmente es de unas pocas horas a unos pocos das, por lo general implica un trabajador, y afecta a una o slo un pequeo

nmero de artefactos. Una actividad debe ser utilizable como elemento de la planificacin y el progreso; si es demasiado pequea, se descuida, y si es demasiado grande, el

progreso tendra que ser expresado en trminos de partes de una actividad. Ejemplo de actividades:

Planificar una iteracin, para el trabajador: Project Manager

Bsqueda de casos de uso y actores, para el trabajador: Analista de Sistemas

Revisar el diseo, para el trabajador: Diseo Crtico

Ejecutar prueba de rendimiento, para el trabajador: Performance Tester

8
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Artefacto

Un artefacto es una pieza de informacin que se produce, modificado o utilizado por un proceso. Los artefactos son los productos tangibles del proyecto, las cosas que el
proyecto produce o utiliza en el trabajo hacia el producto final. Los artefactos se utilizan como entrada por los trabajadores para realizar una actividad, y son el resultado o
salida de tales actividades. En trminos de diseo orientado a objetos, como actividades son operaciones en un objeto activo (el trabajador), los artefactos son los
parmetros de estas actividades.

Los artefactos pueden adoptar diversas formas o formas:

Un modelo, tales como el modelo de casos de uso o el Modelo de Diseo

Un elemento del modelo, es decir, un elemento dentro de un modelo, como una clase, un caso de uso o un subsistema

Un documento, tales como Business Case o software de arquitectura de documento

Cdigo fuente
ejecutables

Los flujos de trabajo

Una simple enumeracin de todos los trabajadores, actividades y artefactos no acaba de constituir un proceso. Necesitamos una manera de describir secuencias

significativas de las actividades que producen algn resultado valioso, y para mostrar las interacciones entre los trabajadores. 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, un diagrama de colaboracin, o un diagrama de actividad. Utilizamos una forma de diagramas

de actividad en este documento.

Ejemplo de flujo de trabajo

Tenga en cuenta que no siempre es posible o prctico para representar a todas las dependencias entre las actividades. A menudo dos actividades estn ms estrechamente
entrelazadas que se muestra, sobre todo cuando se refieren a un mismo trabajador o el mismo individuo. Las personas no son mquinas, y el flujo de trabajo no deben ser
interpretados literalmente, como un programa para las personas, para ser seguido exactamente como mecnicamente.

En la siguiente seccin vamos a discutir el tipo ms esencial de los flujos de trabajo en el proceso, denominado Core flujos de trabajo.

9
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

flujos de trabajo fundamentales

Hay nueve los flujos de trabajo fundamentales del proceso en el Rational Unified Process, que representan una particin de todos los trabajadores y
actividades en grupos lgicos.

Los flujos de trabajo de proceso de nueve centrales

Los flujos de trabajo de proceso central se dividen en flujos de trabajo de seis ncleos de ingeniera:

1. flujo de trabajo de modelado de negocio

2. requisitos de flujo de trabajo

3. Anlisis y Diseo de flujo de trabajo

4. flujo de trabajo de aplicacin

5. prueba de flujo de trabajo

6. flujo de trabajo de implementacin

Y tres ncleos apoyo flujos de trabajo:

1. flujo de trabajo de gestin de proyectos

2. Configuracin y flujo de trabajo de Gestin del Cambio

3. flujo de trabajo para el Medio Ambiente

Aunque los nombres de los seis principales flujos de trabajo de ingeniera pueden evocar las fases secuenciales en un proceso en cascada tradicional, debemos
tener en cuenta que las fases de un proceso iterativo son diferentes y que estos flujos de trabajo se revisan una y otra vez a lo largo del ciclo de vida. El flujo de
trabajo real completa de un proyecto intercala estas nueve flujos de trabajo fundamentales, y las repite con diferentes nfasis y la intensidad en cada iteracin.

Modelado de negocios
Uno de los principales problemas con la mayora de los esfuerzos de ingeniera de negocios, es que la ingeniera de software y la comunidad de ingeniera de

negocios no se comunican correctamente entre s. Esto conduce a la salida de la ingeniera empresa no est siendo utilizado adecuadamente como entrada para el

esfuerzo de desarrollo de software, y viceversa. El Proceso Unificado de Desarrollo se ocupa de esto proporcionando un lenguaje comn y un proceso para ambas

comunidades, as como mostrar cmo crear y mantener la trazabilidad directa entre los modelos de negocio y software. En el modelado de negocio documentamos

procesos de negocio utilizando los llamados casos de uso del negocio. Esto asegura un entendimiento comn entre todas las partes interesadas de lo que debe ser

apoyado en la organizacin de procesos de negocio. los

10
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

casos de uso del negocio son analizados para entender cmo la empresa debe apoyar los procesos de negocio. Esto est documentado en un objeto de modelo
de negocio. Muchos proyectos pueden optar por no hacer el modelado de negocios.

requisitos
El objetivo del flujo de trabajo es describir Requisitos qu El sistema debe hacer y permite a los desarrolladores y el cliente de acuerdo en esa descripcin. Para lograr esto,

producir, organizar y documentar la funcionalidad y las restricciones requerido; realizar un seguimiento y compensaciones de documentos y decisiones. Se crea un documento

de Visin y necesidades de los interesados son provocados. actores se identifican, en representacin de los usuarios, y cualquier otro sistema que puede interactuar con

siendo desarrollado el sistema. Los casos de uso son identificados, que representa el comportamiento del sistema. Debido a que los casos de uso se desarrollan de acuerdo a

las necesidades del actor, el sistema es ms probable que sea relevante para los usuarios. La siguiente figura muestra un ejemplo de un modelo de casos de uso para un

sistema de reciclaje de la mquina.

Un ejemplo de modelo de casos de uso con actores y casos de uso.

Cada caso de uso se describe en detalle. los Descripcin de casos de uso muestra cmo interacta el sistema paso a paso con los actores y lo que hace el

sistema. requisitos no funcionales se describen en Suplementario Presupuesto. Los casos de uso funcionan como un hilo conductor a lo largo del ciclo de

desarrollo del sistema. El mismo modelo de casos de uso se utiliza durante la captura de requisitos, anlisis y diseo, y de prueba.

Anlisis y Diseo
El objetivo del flujo de trabajo de anlisis y diseo es para mostrar cmo el sistema ser dio cuenta 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 las descripciones de casos de uso.

Cumple todos los requisitos.

Est estructurado para ser robusto (fcil de cambiar, siempre y cuando sus requisitos funcionales cambian). Anlisis y Diseo resulta en una modelo de diseo y

opcionalmente una modelo de anlisis. El modelo de diseo sirve como una abstraccin del cdigo fuente; es decir, el modelo de diseo acta como un 'modelo' de la forma

en que el cdigo fuente est estructurado y escrito.

El modelo de diseo consta de clases de diseo estructurados en paquetes de diseo y subsistemas de diseo de pozos con interfaces definidas, lo que representa lo que se
convertir 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. La
siguiente figura muestra parte de un modelo de diseo de la muestra para el sistema de reciclado de la mquina en el modelo de casos de uso se muestra en la figura anterior.

11
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Parte de un modelo de diseo con comunicantes clases de diseo, y las clases de diseo grupo de paquetes.

Las actividades de diseo se centran alrededor de la nocin de arquitectura. La produccin y validacin de esta arquitectura es el principal foco de iteraciones de diseo
inicial. Arquitectura est representado por un nmero de vistas arquitectnicas [9]. Estos puntos de vista de captura de las principales decisiones de diseo estructural. En
esencia, vistas arquitectnicas son abstracciones o simplificaciones de todo el diseo, en el que las caractersticas importantes se hacen ms visibles, dejando a un lado
los detalles. La arquitectura es un vehculo importante no slo para el desarrollo de un buen modelo de diseo, sino tambin para aumentar la calidad de cualquier modelo
construido durante el desarrollo del sistema.

Implementacin
El propsito de la aplicacin es:

Para definir la organizacin del cdigo, en trminos de subsistemas de implementacin organizados en capas.
Para llevar a cabo las clases y objetos en trminos de componentes (archivos de cdigo fuente, binarios, ejecutables y otros).

Para probar los componentes desarrollados como unidades.

Para integrar los resultados producidos por los implementadores individuales (o equipos), en un sistema ejecutable. El sistema se

realiza mediante la aplicacin de componentes. RUP describe cmo reutilizar componentes existentes o implementar nuevos componentes con

responsabilidad bien definida, haciendo que el sistema sea ms fcil de mantener, y aumentar las posibilidades de reutilizar.

Componentes estn estructurados en subsistemas de aplicacin. Subsistemas toman la forma de directorios, la informacin estructural o de gestin adicional.
Por ejemplo, un subsistema se puede crear como un directorio o una carpeta en un sistema de archivos, o un subsistema en Rational / Apex para C ++ o Ada,
o paquetes usando Java .

Prueba

Los propsitos de la prueba son:

Para verificar la interaccin entre los objetos.

Para verificar la correcta integracin de todos los componentes de software.
Para verificar que todos los requisitos se han aplicado correctamente.
Para identificar y asegurar los defectos se tratan antes de la implementacin del software. El Rational Unified Process propone un enfoque iterativo, lo

que significa que pruebe lo largo del proyecto. Esto le permite encontrar defectos tan pronto como sea posible, lo que reduce radicalmente el costo de reparar el

defecto. Las pruebas se llevaron a cabo a lo largo de tres dimensiones de calidad fiabilidad, funcionalidad, rendimiento de las aplicaciones y el rendimiento del

sistema. Para cada una de estas dimensiones de la calidad, el proceso se describe cmo vas a travs del ciclo de vida de la prueba de la planificacin, diseo,

implementacin, ejecucin y evaluacin.

12
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Se describen estrategias para cundo y cmo automatizar la prueba. La automatizacin de pruebas es especialmente importante el uso de un enfoque iterativo, para permitir
las pruebas de regresin a continuacin final de cada iteracin, as como para cada nueva versin del producto.

Despliegue
El propsito del flujo de trabajo de implementacin es para producir con xito lanzamientos de productos, y entregar el software para sus usuarios
finales. Cubre una amplia gama de actividades que incluyen:

La produccin de comunicados externos de software.

Empaquetar el software.
La distribucin de software.
La 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.

La migracin de software o datos existentes.

La aceptacin formal.

Aunque las actividades de despliegue se centran principalmente en torno a la fase de transicin, muchas de las actividades necesitan ser incluidos en las
fases anteriores a preparar para el despliegue en el extremo de la fase de construccin. Los flujos de trabajo de implementacin y entorno del proceso
Rational Unified contienen menos detalle que otros flujos de trabajo.

Gestin de proyectos
Software de gestin de proyectos es el arte de equilibrar los objetivos de la competencia, la gestin del riesgo, y la superacin de las limitaciones para entregar, con xito,

un producto en el que satisface las necesidades de los clientes (los pagadores de facturas) y los usuarios. El hecho de que tan pocos proyectos son indiscutiblemente xito

es lo suficientemente comentario sobre la dificultad de la tarea. Este flujo de trabajo se centra principalmente en el aspecto especfico de un proceso de desarrollo iterativo.

Nuestro objetivo con esta seccin es hacer la tarea ms fcil proporcionando:

Un marco para la gestin de proyectos de software intensivo.

directrices prcticas para proyectos de planificacin, dotacin de personal, ejecucin y seguimiento.

Un marco para la gestin de riesgos.

No es una receta para el xito, pero presenta una aproximacin a la gestin del proyecto que claramente va a mejorar las probabilidades de xito la
distribucin de software. [14]

Configuracin y Gestin del Cambio

En este flujo de trabajo se describe cmo controlar los numerosos artefactos producidos por las muchas personas que trabajan en un proyecto comn.
Control de ayuda a evitar la confusin costoso, y asegura que los artefactos resultantes no estn en conflicto debido a algunas de las siguientes tipos de
problemas:

actualizacin simultnea Cuando dos o ms trabajadores trabajan por separado en el mismo artefacto, el ltimo en hacer cambios destruye el
trabajo de los primeros.
Notificacin limitada Cuando un problema se resuelve en artefactos compartidos por varios desarrolladores, y algunos de ellos no son notificados
del cambio.
varias versiones La mayora de los programas grandes se desarrollan en las versiones evolutivas. Una liberacin podra estar en uso al cliente, mientras que otro
est en la prueba, y el tercero todava est en desarrollo. Si se encuentran problemas en cualquiera de las versiones, correcciones tienen que propagarse entre ellos.
La confusin puede surgir conduce a arreglos costosos y re-trabajo a menos que los cambios son cuidadosamente controlados y supervisados.

13
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Este flujo de trabajo proporciona directrices para la gestin de mltiples variantes de la evolucin de los sistemas de software, seguimiento de las versiones que se utilizan en el software dado

construye, construye la realizacin de los programas individuales o en lanzamientos enteras de acuerdo con especificaciones de la versin definidos por el usuario, y hacer cumplir las polticas

de desarrollo especficas del sitio.

Se describe cmo se puede gestionar un desarrollo paralelo, el desarrollo hecho en mltiples sitios, y la forma de automatizar el proceso de generacin. Esto es

especialmente importante en un proceso iterativo en el que puede querer ser capaz de hacer construye tan a menudo como todos los das, algo que sera imposible sin la

automatizacin de gran alcance. Tambin describe cmo puede mantener un registro de auditora sobre por qu, cundo y por quin fue cambiado ningn artefacto. Este flujo

de trabajo tambin cubre la gestin de solicitud de cambio, es decir, cmo informar de defectos, gestionarlos a travs de su ciclo de vida, y cmo utilizar datos de defectos

para seguir el progreso y las tendencias.

Ambiente
El propsito del flujo de trabajo de medio ambiente es proporcionar a la organizacin de desarrollo de software con el entorno de ambos procesos y herramientas de

desarrollo de software-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 centra en actividades para desarrollar las directrices necesarias para apoyar un proyecto. Un procedimiento paso a paso se proporciona la

descripcin de cmo se implementa un proceso en una organizacin.

El flujo de trabajo de medio ambiente tambin contiene un kit de desarrollo que le proporciona las directrices, plantillas y herramientas necesarias para
personalizar el proceso. El kit de desarrollo se describe con ms detalle en la seccin "Kit de desarrollo para Procesar" ms adelante en este documento.

Ciertos aspectos del flujo de trabajo de Medio Ambiente no estn cubiertos en el proceso tales como la seleccin, adquisicin, y haciendo las
herramientas de trabajo, y mantener el entorno de desarrollo.

Rational Unified Process - El Producto

El producto Rational Unified Process consta de:

UN base de conocimiento habilitado para la Web proporcionar a todos los miembros del equipo con guas, plantillas y mentores de herramientas para
todas las actividades de desarrollo crticos. La base de conocimientos ms se puede dividir a:

directrices amplias para todos los miembros del equipo, y todas las partes del ciclo de vida del software. Se proporciona una gua tanto para el
proceso de pensamiento de alto nivel, as como para las actividades ms tediosas del da a da. La gua se publica en formato HTML para
facilitar el acceso independiente de la plataforma en su escritorio.

mentores de herramientas proporcionar una gua prctica para disfrutar de herramientas que cubren el ciclo de vida completo. Los mentores de herramientas se

publican en forma HTML para facilitar el acceso independiente de la plataforma en su escritorio. Vea la seccin "Integracin con herramientas" para ms detalles.

Rational Rose ejemplos y plantillas que proporcionan una gua sobre cmo estructurar la informacin en Rational Rose cuando se sigue
el Proceso Unificado Racional (Rational Rose es una herramienta de modelado visual para Racional)

Soda plantillas ms de 10 plantillas de refresco que ayuda a automatizar la documentacin de software (soda es la herramienta de automatizacin
de documentos de Racional)

microsoft Las plantillas de Word ms de 30 plantillas de Word que asisten a la documentacin en todos los flujos de trabajo y todas las
partes del ciclo de vida

Planes de Microsoft Project Muchos directivos tienen dificultades para crear planes de proyecto que refleja un enfoque de desarrollo iterativo.
Nuestras plantillas saltar iniciar la creacin de planes de proyectos para el desarrollo iterativo, de acuerdo con el Rational Unified Process.

14
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Kit de desarrollo describe cmo personalizar y extender el proceso unificado racional a las necesidades especficas de la organizacin o proyecto
adoptar, as como proporciona herramientas y plantillas para ayudar al esfuerzo. Este kit de desarrollo se describe con ms detalle ms adelante
en esta seccin.
El acceso a los Centro de Recursos que contiene los ltimos documentos tcnicos, actualizaciones, consejos y tcnicas, as como las referencias a productos

complementarios y servicios.

Un libro "proceso unificado racional - An Introduction", de Philippe Kruchten, Addison-Wesley publicado por. El libro est en las pginas
277 y proporciona una buena introduccin y visin general del proceso y la base de conocimientos.

Navegando por la base de conocimientos

El conocimiento Rational Unified Process le permite acceder al contenido con cualquiera de los navegadores web ms populares, como Microsoft Internet
Explorer y Netscape Navigator.

Con el Rational Unified Process, nunca estar ms que unos pocos clics de ratn de la informacin que desea. La base de conocimientos contiene una gran cantidad de
enlaces de hipertexto, y una visin general de los diferentes elementos del proceso se presentan a travs de imgenes interactivas, por lo que es fcil encontrar
informacin relevante de una manera intuitiva. El potente motor de bsqueda, el ndice y el navegador del rbol explorador buscando hacen que sea fcil de usar el
proceso. botones de navegacin le permiten moverse a la pgina siguiente o anterior como si estuviera leyendo un libro.

La informacin se presenta en muchos puntos de vista diferentes, lo que le permite ver la informacin pertinente para su funcin, a una actividad especfica, o para un flujo de trabajo.

visitas guiadas para facilitar el aprendizaje del proceso se proporcionan para los papeles clave del proyecto.

imgenes interactivas y botones de navegacin hacen que sea ms fcil encontrar la informacin especfica que busca.

Kit de desarrollo para Procesar

los Proceso racional unificado es general y lo suficientemente completa como para ser utilizado como es por algunas organizaciones de desarrollo de software. Sin

embargo, en muchas circunstancias, tendr que ser modificado, ajustado, y adaptado para dar cabida a las caractersticas especficas, las restricciones y la historia de

la organizacin la adopcin de este proceso de ingeniera de software. En particular, un proceso no debe ser seguido a ciegas, la generacin de trabajo intil,

produciendo artefactos que son de poco valor aadido. Debe hacerse tan delgado como sea posible y an as ser capaz de cumplir su misin de producir software de

alta calidad rpida y predecible. El proceso contiene una Kit de desarrollo, que contiene directrices sobre cmo se puede personalizar el

15
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

proceso para adaptarse a las necesidades especficas de la organizacin o proyecto adopcin. Las plantillas tambin se incluyen para la creacin de procesos, as como
herramientas para la generacin o la manipulacin de motores de bsqueda, ndice, mapa del sitio, el navegador de rbol, etc. El kit de desarrollo permite a la organizacin de
personalizacin para mantener la apariencia del Rational Unified Process. Cuanto ms el proceso es personalizado, ms difcil ser para moverse sobre las personalizaciones
a futuras versiones del proceso. El kit de desarrollo se describen las estrategias, herramientas y tcnicas para reducir al mnimo el trabajo asociado con el movimiento de las
personalizaciones a futuras versiones.

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 artefactos-modelos 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. Tambin necesita herramientas para realizar un seguimiento de los cambios, para soportar

los requisitos de trazabilidad, para automatizar la documentacin, as como herramientas para automatizar las pruebas para facilitar la prueba de regresin. El Proceso Unificado Rational

se puede utilizar con una variedad de herramientas, ya sea desde los proveedores racional o de otro tipo. Sin embargo, Rational proporciona muchas herramientas bien integrados que

apoyan de manera eficiente el Rational Unified Process. A continuacin encontrar una lista de algunas de las herramientas de Rational que apoyan el Rational Unified Process. El

Rational Unified Process contiene Los mentores de herramientas para casi todos estos productos. A Mentor Tool es una gua paso a paso que describe en detalle la forma de operar una

herramienta, (es decir, lo mens para lanzamiento, qu informacin para entrar en cuadros de dilogo, y cmo navegar por una herramienta) para llevar a cabo una actividad dentro del

proceso . Los mentores de herramientas nos permiten vincular el proceso de herramienta independiente para la manipulacin real de las herramientas en su trabajo diario.

racional RequisitePro Mantiene todo el equipo de desarrollo actualiza, y en pista durante todo el proceso de desarrollo de
aplicaciones, haciendo requisitos fciles de escribir, comunicar y Chang mi.
Racional ClearQuest - Un producto de gestin de cambios-peticin basada en la Web de Windows y que permite a los equipos de proyecto para rastrear y
administrar todas las actividades de cambio que se producen a lo largo del ciclo de vida de desarrollo.

Rational Rose 98 - herramienta visual lder del mundo de la moda para el modelado de procesos de negocio, anlisis de requerimientos,
diseo y arquitectura de componentes.
Soda racional Automatiza la produccin de documentacin de todo el proceso de desarrollo de software, reduciendo drsticamente
el tiempo de documentacin y costes.
Purify racional Un error de tiempo de ejecucin de herramientas para desarrolladores de aplicaciones y software componente de programacin en C / C ++ comprobacin;

ayuda a detectar errores de memoria.

Cuantificar racional Visual - Una herramienta de perfiles de rendimiento avanzado para los desarrolladores de aplicaciones de software y componentes de
programacin en C ++, Visual Basic y Java; ayuda a eliminar los cuellos de botella de rendimiento.

Racional Visual PureCoverage - automticamente identifica reas de cdigo no ejercidos en las pruebas de que los desarrolladores puedan
fondo, con eficiencia y eficacia probar sus aplicaciones.
Racional TeamTest - Crea, mantiene y ejecuta pruebas funcionales automatizadas, lo que le permite probar a fondo su cdigo y
determinar si el software cumple con los requisitos y lleva a cabo como se esperaba.
Racional PerformanceStudio - Un medidas fciles de usar, precisos y escalables tambin que predice y el rendimiento de los
sistemas cliente / servidor y Web.
ClearCase racionales - Lder en el mercado de herramientas de gestin de configuracin de software, dando a los administradores de proyectos el poder para

realizar un seguimiento de la evolucin de cada proyecto de desarrollo de software.

Una breve historia del Rational Unified Process

El Rational Unified Process ha madurado durante muchos aos y refleja la experiencia colectiva de las muchas personas y empresas que conforman el
rico patrimonio de Rational Software hoy.

Vamos a echar un vistazo rpido a la ascendencia de proceso, como se ilustra en la figura siguiente, "Genealoga del Rational Unified Process".

diecisis
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

Genealoga del Rational Unified Process

Yendo hacia atrs en el tiempo, el Rational Unified Process es el sucesor directo del proceso Objectory Racional (versin 4). El Rational Unified
Process incorpora ms material en las reas de ingeniera de datos, modelado de negocios, gestin de proyectos y gestin de la configuracin, este
ltimo como resultado de la fusin con Pure-Atria. Tambin aporta una mayor integracin de la suite de Rational Software de herramientas.

El Proceso Racional Objectory fue el resultado de la integracin del enfoque racional y el proceso Objectory (versin 3), tras la fusin de
Rational Software Corporation y Objectory AB en 1995. Desde su ascendencia Objectory, el proceso ha heredado su estructura de procesos y el
concepto central de utilizar cas mi. De su fondo racional, gan la formulacin actual de desarrollo iterativo y Architectur mi. 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 fusion con Rational Software. Por ltimo, este proceso fue el primero en utilizar el Lenguaje de Modelado Unificado de nueva
creacin (UML 0.8).

El proceso Objectory fue creado en Suecia en 1987 por Ivar Jacobson como resultado de su experiencia con Ericsson. Este proceso se convirti en un producto en
su compaa, Objectory AB. Centrada alrededor del concepto de casos de uso y un mtodo de diseo orientado a objetos, rpidamente se gan el reconocimiento
en la industria del software y ha sido adoptado e integrado por muchas empresas en todo el mundo. Una versin simplificada del proceso Objectory fue publicado
como un libro de texto en 1992.

El Proceso Unificado Rational es una instancia especfica y detallada de un proceso ms genrico descrito por Ivar Jacobson, Grady Booch y
James Rumbaugh en el libro de texto, El desarrollo de software unificada Proceso.

17
Rational Unified Process: Las mejores prcticas para los equipos de desarrollo de software

referencias

1. Barry W. Boehm, un modelo espiral de desarrollo de software y de mejora, Computadora, mayo de 1988, IEEE, pp.61-72

2. Barry W. Boehm, Anclar el proces de software s, IEEE Software, 13, 4, julio de 1996, pp. 73-82.

3. Grady Booch, Soluciones de objetos, Addison-Wesley, 1995.

4. Grady Booch, Ivar Jacobson y James Rumbaugh, Unified Modeling Language 1. 3, Libro Blanco, Rational Software Corp.,
1998.

5. Alan W. Brown (ed.), INGENIERA software basado en componentes g, IEEE Computer Society, Los Alamitos, CA, 1996,
pp.140.

6. Michael T. Devlin, y Walker E. Royce, Mejora de Economa de software en la industria aeroespacial y

Industria de la defensa, documento tcnico TP-46, Santa Clara, CA, Rational Software Corp., 1995

7. Ivar Jacobson, Magnus Christerson, Patrik Jonsson, y Gunnar vergaar d, Ingeniera de Software-Un enfoque de casos de uso Driven
orientada a objetos, Wokingham, Inglaterra, Addison-Wesley, 1992, 582p.

8. Ivar Jacobson, M. Griss, y P. Jonsson, Software Reuse-Arquitectura, Procesos y Organizacin para el xito del negocio, Harlow, Inglaterra,
AWL, 1997.

9. Philippe Kruchten, El 4 + 1 Ver Modelo de Architectur e, IEEE Softwar mi, 12 (6), noviembre de 1995, IEEE, pp.42-
50.

10. Philippe Kruchten, Un desarrollo racional Proceso, diafona, 9 (7), la Subcomisin, Hill AFB, UT, pp.11-16.

11. Ivar Jacobson, Grady Booch, y Jim Rumbaugh, Proces unificado de desarrollo de software s, Addison-Wesley,
1999.

12. Grady Booch, Jim Rumbaugh, e Ivar Jacobson, Guid de Modelado Unificado de Lenguaje-usuario e, Addison-Wesley,
1999.

13. Philippe Kruchten, Racional Unified Process-Una introduccin, Addison-Wesley, 1999.

14. Walker Royce, Gestin de Proyectos de Software Un marco unificado, Addison-Wesley, 1998.

18
Sede dual: Rational Software
18880 Homestead Road
Cupertino, CA 95014 Tel: (408)
863-9900 Rational Software 20
Maguire carretera Lexington, MA
02421 Tel: (781) 676-2400 Lnea
gratuita: (800) 728-1212 E-mail :
info@rational.com web:
www.rational.com

Ubicaciones internacionales: www.rational.com/worldwide

Racional, el logotipo racional, Rational Unified Process, racional Apex, Rational Rose, RequisitePro, ClearQuest, ClearCase, Purificar, Visual Cuantificar,

PureCoverage Visuales, PerformanceStudio y SQA son marcas comerciales o marcas comerciales registradas de Rational Software Corporation en los Estados

Unidos y en otros pases. Microsoft y Microsoft Internet Explorer son marcas comerciales o marcas comerciales registradas de Microsoft Corporation. Java es

una marca registrada de Sun Microsystems. Todos los dems nombres se utilizan slo con fines de identificacin y son marcas comerciales o marcas

comerciales registradas de sus respectivas compaas. Copyright 1998 Rational Software Corporation. TODOS LOS DERECHOS RESERVADOS