Rational Unified Process

Mejores prcticas para el Software Equipos de desarrollo

Un libro blanco de Rational Software Corporation

Rational Unified Process

Mejores prcticas para los equipos de desarrollo de Software
CUL ES EL PROCESO UNIFICADO RACIONAL? ............................................................................ 1 DESPLIEGUE EFECTIVO DE 6 MEJORES PRCTICAS... 1 PROCESS OVERVIEW ........................................................................................................................ 3 TWODImensiones.............................................................................................................................. 3 FASES E ITERACIONES - LA DIMENSIN TEMPORAL. 3 YoNCEPTIONPHASE............................................................................................................................... 4 ELABORATIONPHASE........................................................................................................................ 4 CONSTRUCTIONPHASE...................................................................................................................... 5 TRANSITIONPHASE............................................................................................................................ 6 YoTERACIONES........................................................................................................................................ 7 ESTRUCTURA ESTTICA DEL PROCESO... 7 ACtividadesUnRTIFACTS, YWORKERS.......................................................................................... 8 WORKFLOWS...................................................................................................................................... 9 CORE WORKFLOWS............................................................................................................... ......... 10 BUSINESSMODELING....................................................................................................................... 10 REQUIREMENTS................................................................................................................................ 11 ANALYSISI+dESIGN........................................................................................................................ 11 YoAplicacin............................................................................................................................ 12 TEST.................................................................................................................................................. 12 DEPLOYMENT................................................................................................................................... 12 PROJECTMANAGEMENT.................................................................................................................. 13 CONFIGURATION& CAMBIARMANAGEMENT................................................................................. 13 ENVIRONMENT................................................................................................................................. 14 RACIONAL UNIFIED PROCESS - EL PRODUCTO... 14 INTEGRATION WITH TOOLS ......................................................................................................... 16 UNA BREVE HISTORIA DEL PROCESO UNIFICADO DE RATIONAL. 17 Resumen

Este papel presenta una visin general de la Rational Unified Process The Rational Unified Process es una proceso de ingeniera del software, entregado a travs de una base de datos investigable, habilitado para la web. El proceso aumenta la productividad del equipo y ofrece las mejores prcticas de software mediante directrices, plantillas y mentores de herramienta para todas las actividades de ciclo de vida del software crtico. La base de conocimiento permite el desarrollo equipos para obtener los beneficios de la industria estndar Unified Modeling Language (UML).

Qu es el Rational Unified Process?

El Rational Unified Process es un Proceso de ingeniera del Software. Proporciona un enfoque disciplinado para asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad que satisface las necesidades de sus usuarios finales, dentro de un horario predecible y presupuesto. El Rational Unified Process es un producto de proceso, desarrollado y mantenido por Rational Software . El equipo de desarrollo para el Rational Unified Process estn trabajando estrechamente con los clientes, socios, Rational grupos de productos, as como organizacin consultora de racionales, para asegurar que el proceso es

continuamente actualizado y mejorado a reflejar recientes experiencias y mejores prcticas en evolucin y comprobadas. El Rational Unified Process aumenta la productividad del equipo, proporcionando a cada miembro del equipo fcil el acceso a una base de conocimiento con las pautas, plantillas y herramientas mentores para todo el desarrollo crtico actividades. Al contar con todos los miembros del equipo acceso a la misma base de conocimientos, no importa si trabajas con requisitos, diseo, prueba, gestin de proyectos o administracin de la configuracin, nos aseguramos de que todo equipo los miembros comparten un lenguaje comn, proceso y visin de cmo desarrollar software. Las actividades de Rational Unified Process crean y mantienen modelos. En lugar de centrarse en la produccin gran cantidad de documentos en papel, el proceso unificado hace hincapi en el desarrollo y mantenimiento de modelos semnticamente ricas representaciones del sistema en desarrollo de software. [3, 7, 8] El Rational Unified Process es una gua para saber cmo utilizar eficazmente el Lenguaje unificado de modelado (UML). El UML es un lenguaje estndar de la industria que permite comunicar claramente los requisitos, arquitecturas y diseos. El UML fue creado originalmente por Rational Software y ahora es mantenido por la organizacin de estndares objeto Management Group (OMG). [4] El Rational Unified Process es apoyada por Herramientas, que automatiza gran parte del proceso. Son utilizado para crear y mantener los diferentes artefactos modelos en particular de la ingeniera de software proceso: modelado visual, programacin, pruebas, etc.. Son invaluables para apoyar toda la contabilidad asociados a la gestin del cambio, as como la gestin de la configuracin que acompaa a cada uno iteracin. El Rational Unified Process es un proceso configurables . No solo proceso es adecuado para todo el software desarrollo. El proceso unificado se adapta a los equipos de desarrollo pequeo as como el desarrollo de grande organizaciones. El proceso unificado se basa en una arquitectura de proceso simple y clara que proporciona comunes a toda una familia de procesos. Sin embargo, se puede variar para adaptarse a diferentes situaciones. Lo contiene un Kit de desarrollo, proporcionando soporte para configurar el proceso para adaptarse a las necesidades de un determinado organizacin. El Rational Unified Process captura muchas de las mejores prcticas en desarrollo de software moderno en un forma de que es conveniente para una amplia gama de proyectos y organizaciones. Implementar estas mejores prcticasusando El Rational Unified Process como su gua ofrece equipos de desarrollo de un nmero de ventajas. En la prxima seccin, describimos las seis mejores prcticas fundamentales de la Rational Unified Process.

Despliegue efectivo de 6 mejores prcticas

El Rational Unified Process describe cmo implementar efectivamente enfoques probados comercialmente a desarrollo de software para equipos de desarrollo de software. Estas son las llamadas "mejores prcticas" no tanto. Porque usted puede precisamente cuantificar su valor, sino porque se observan para ser utilizados en la industria por organizaciones exitosas. El Rational Unified Process proporciona a cada miembro del equipo con el directrices, plantillas y mentores herramienta necesaria para todo el equipo para aprovechar al mximo entre otros las siguientes prcticas recomendadas: 1. desarrollar iterativamente software 2. gestin de requisitos 3. Utilice las arquitecturas basadas en componentes 1 4. visualmente software de modelo 5. verificar la calidad del software 6. control de cambios al software Desarrollar Software de forma iterativa Dado los sistemas software sofisticado de hoy, no es posible a secuencialmente primero definir todo el problema, la solucin completa de diseo, construir el software y luego probar la producto al final. Se requiere un enfoque iterativo que permite una mayor comprensin del problema a travs de sucesivos refinamientos y de crecer incrementalmente una solucin eficaz en iteraciones mltiples. El Rational Unified Process apoya un enfoque iterativo de desarrollo que enfrenta el mayor riesgo artculos en cada etapa del ciclo de vida, reduciendo significativamente el perfil de riesgo de un proyecto. Este enfoque

iterativo le ayuda a atacar el riesgo a travs de progreso demostrableversiones frecuentes, ejecutables que permiten continua implicacin del usuario final y retroalimentacin. Porque cada iteracin termina con una versin ejecutable, el el equipo de desarrollo se mantiene enfocado en producir resultados y el estado frecuente controles ayudan a asegurar que el proyecto permanece en la agenda. Un enfoque iterativo tambin hace ms fcil acomodar cambios tcticos en requisitos, caractersticas o calendario. [1, 2, 10] Gestionar los requisitos El Rational Unified Process describe cmo obtener, organizar y documentar funcionalidad requerida y limitaciones; pista e intercambios de documentos y decisiones; y capturar fcilmente y comunicar los requerimientos del negocio. Las nociones de caso de uso y escenarios proscritas en el proceso ha demostrado para ser una excelente forma de capturar los requisitos funcionales y para asegurar que estos conducir el diseo, implementacin y pruebas de software, por lo que es ms probable que el sistema final cumple con el usuario final necesita. Proporcionan roscas coherentes y trazables a travs del desarrollo y la entrega sistema. [7] Arquitecturas basadas en componentes de uso El proceso se centra en el desarrollo temprano y la base de un slida arquitectura ejecutable, antes de comprometer recursos para el desarrollo a gran escala. Describe cmo diseo de una arquitectura flexible que es flexible, tiene capacidad para el cambio, es intuitivamente comprensible, y promueve la reutilizacin de software ms eficaz. El Rational Unified Process compatible con software basado en componentes desarrollo . Los componentes son mdulos no trivial, subsistemas que cumplen una funcin clara. Racional Proceso unificado proporciona un enfoque sistemtico para definir una arquitectura que utiliza nuevos y existentes componentes. Estos estn montados en una arquitectura bien definida, o ad hoc, o en un componente infraestructura como el Internet, CORBA y COM, para lo cual es una industria de componentes reutilizables emergentes. [5] Modelo visualmente Software El proceso muestra cmo modelar visualmente software para capturar el estructura y comportamiento de componentes y arquitecturas. Esto le permite ocultar los detalles y escribir cdigo uso de "bloques de construccin grficas." Abstracciones visuales ayudan a comunicarse diferentes aspectos de su software; ver cmo encajan los elementos del sistema; Asegrese de que los bloques de construccin son consistentes con el cdigo; mantener la coherencia entre un diseo y su aplicacin; y promover la inequvoca comunicacin. 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 Aplicacin pobre rendimiento y poca fiabilidad son comunes los factores que dramticamente inhibir la aceptabilidad de las aplicaciones de software de hoy. Por lo tanto, debe revisarse la calidad con respecto a los requisitos basados en fiabilidad, funcionalidad y rendimiento de la aplicacin sistema rendimiento. El Rational Unified Process le ayuda en la planificacin, diseo, implementacin, ejecucin, y evaluacin de estos tipos de prueba. Evaluacin de la calidad est incorporada en el proceso, en todas las actividades, involucrando a todos participantes, utilizando criterios y medidas objetivas y no tratada como una ocurrencia tarda o separado actividad realizada por un grupo independiente. Cambios en el control de Software La capacidad de gestionar el cambioasegurndose de que cada cambio es aceptable y ser capaces de rastrear 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 xito iterativo desarrollo. Tambin te gua en cmo establecer espacios de trabajo seguros para cada desarrollador proporcionando aislamiento de los cambios realizados en otras reas de trabajo y controlando los cambios de todos los artefactos de software (por ejemplo, modelos, cdigo, documentos, etc..). Y trae un equipo para trabajar como una sola unidad, describiendo cmo automatizar la integracin y gestin de construir. 2

Resumen de proceso
Dos dimensiones
El proceso puede ser descrito en dos dimensiones, o a lo largo de dos ejes: el eje horizontal representa el tiempo y muestra el aspecto dinmico del proceso como lo es promulgada y se expresa en trminos de ciclos, fases, iteraciones e hitos. el eje vertical representa el aspecto esttico del proceso: Cmo se describe en trminos de actividades, artefactos, los trabajadores y los flujos de trabajo.
Creacin elaboracin construccin transicin

Fases
Requisitos

Anlisis y diseo Implementacin Prueba Medio ambiente Despliegue

Ncleo proceso flujos de trabajo Ncleo de apoyo a los flujos de trabajo Iteraciones
preliminar iteration(s) ITER. #1 ITER. #2 ITER. #n ITER. #n + 1 ITER. #n + 2 ITER. #m ITER. #m + 1

Configuracin y administracin del cambio Modelado de negocios

Organizacin a lo largo del tiempo Organizacin a lo largo de contenido

El modelo iterativo grfico muestra cmo est estructurado el proceso 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 ciclos, cada ciclo trabajando en una nueva generacin del producto. El Rational Unified Process se divide un ciclo de desarrollo en cuatro consecutivas fases [10] Fase inicial Fase de elaboracin Fase de construccin Fase de transicin Cada fase se concluye con un bien definido hito un punto en el tiempo en que ciertas decisiones crticas debe hacerse y por lo tanto, los principales objetivos deben haber sido alcanzada [2].
tiempo

Principales hitos
Inception Elaboracin construccin transicin

Las fases y principales hitos en el proceso.

Cada fase tiene un propsito especfico. 3

Fase inicial
Durante la fase de inicio, puede establecer el caso de negocio para el sistema y delimitar el alcance del proyecto. Para lograr esto debe identificar todas las entidades externas con el cual el sistema interactuarn (actores) y definir la naturaleza de esta interaccin en un alto nivel. Esto implica identificar todos casos de uso y describiendo un pocos significativos. El caso de negocio incluye criterios de xito, evaluacin de riesgos y estimacin de la los recursos necesarios y un plan de fases muestra las fechas de los acontecimientos ms relevantes. [10, 14] Es el resultado de la fase inicial: Un documento de visin: una visin general de los requisitos del proyecto base, caractersticas clave y principal restricciones. Un modelo de caso de uso inicial (10% - 20% ms). Un glosario de proyecto inicial (puede opcionalmente ser parcialmente expresado como un modelo de dominio). Un caso de negocio inicial, que incluye el contexto empresarial, criterios de xito (proyeccin de ingresos, mercado reconocimiento y as sucesivamente) y proyecciones financieras. Una evaluacin inicial del riesgo. Un plan de proyecto, mostrando las fases e iteraciones. Un modelo de negocio, si es necesario. Uno o varios prototipos. Hito: Los objetivos del ciclo de vida
Creacin elaboracin construccin transicin Ciclo de vida Objetivo

Al final de la creacin fase es el primer hito importante proyecto: el hito de los objetivos del ciclo de vida.

Los criterios de evaluacin para la fase inicial son: Concurrencia de las partes interesadas en la definicin del alcance y costo/schedule estima. Casos de uso requisitos comprensin segn lo evidenciado por la fidelidad de las primarias. Credibilidad de las estimaciones de costo/schedule, prioridades, riesgos y proceso de desarrollo. Amplitud y profundidad de algn prototipo arquitectnico que se desarroll. Gastos reales versus los gastos previstos. El proyecto puede ser cancelado o considerablemente re pensado si falla pasar este hito.

Fase de elaboracin
InceptionElaboracinTransicin de construccin

El propsito de la fase de elaboracin es analizar el dominio del problema, establecer una arquitectura de sonido Fundacin, desarrollar el plan del proyecto y eliminar los elementos de riesgo ms altos del proyecto. Para llevar a cabo estos objetivos, debe tener la vista "milla de ancho y profundidad" del sistema. Decisiones arquitectnicas tienen que hacerse con una comprensin de todo el sistema: su alcance, mayor funcionalidad y requisitos no funcionales tales como los requisitos de rendimiento. Es fcil argumentar que la fase de elaboracin es el ms crtico de las cuatro fases. Al final de esta fase, la "ingeniera" dura es considerada completa y el proyecto somete a su da ms importante de Reckoning: la decisin sobre si desea o no comprometerse con las fases de construccin y transicin. Para la mayora proyectos, esto tambin corresponde a la transicin desde un mvil, ligero y gil, operacin de bajo riesgo para un operacin de alto costo, riesgo con gran inercia. Mientras que el proceso debe adaptarse siempre cambios, las actividades de la fase de elaboracin aseguran que la arquitectura, los requisitos y planes son estables suficiente, y los riesgos son mitigados suficientemente, para que pueda determinar el costo previsible y programar paran la terminacin del desarrollo. Conceptualmente, este nivel de fidelidad correspondera al nivel lo necesario para una organizacin que se comprometan a una fase de construccin de precio fijo. En la fase de elaboracin, se construye un prototipo de arquitectura ejecutable en una o ms repeticiones, dependiendo de en el mbito de aplicacin, tamao, riesgo y novedad del proyecto. Este esfuerzo debe abordar al menos los casos de uso crtico identificados en la fase inicial, que tpicamente se exponen los principales riesgos tcnicos del proyecto. Mientras que un prototipo evolutivo de un componente de la calidad de la produccin es siempre la meta, esto no excluye la desarrollo de prototipos uno o ms exploratorios, desechable para mitigar riesgos especficos tales como compensaciones/requisitos de diseo, estudio de factibilidad de componente o demostraciones a los inversionistas, clientes, y usuarios finales. Es el resultado de la fase de elaboracin: Un modelo de caso de uso (por lo menos un 80% completo) todos los casos de uso y actores han sido identificados y la mayora se han desarrollado las descripciones de casos de uso. Requisitos suplementarios capturando los requisitos no funcionales y los requisitos que son No asociado a un caso de uso especfico. Una descripcin de la arquitectura de Software. Un prototipo arquitectnico ejecutable. Una lista revisada de riesgo y un caso de negocios revisada. Un plan de desarrollo para el proyecto global, incluyendo el plan de proyecto de grano grueso, mostrando iteraciones"y criterios de evaluacin para cada iteracin. Un caso de desarrollo actualizado especificando el proceso que se utilizar. Un manual de usuario preliminar (opcional). Hito: La arquitectura del ciclo de vida
Creacin elaboracin construccin transicin Ciclo de vida Arquitectura

Al final de la elaboracin de fase es el segundo hito importante proyecto, la arquitectura del ciclo de vida Hito. En este punto, examinar los objetivos del sistema detallado y alcance, la eleccin de la arquitectura, y la resolucin de los grandes riesgos. Los criterios de evaluacin principal para la fase de elaboracin consiste en las respuestas a estas preguntas: Es la visin de la cuadra de producto? La arquitectura es estable? La demostracin ejecutable muestra que los elementos de mayor riesgo han sido abordados y creblemente resuelto?

Es el plan para la fase de construccin suficientemente detallada y precisa? Est respaldada con una creble base de estimaciones? Todas las partes interesadas de acuerdo que se logre la visin actual si se ejecuta el plan actual de desarrollar el sistema completo, en el contexto de la arquitectura actual? Es aceptable el gasto de recursos reales versus gasto planeado? El proyecto puede ser abortado o considerablemente re pensado si falla pasar este hito.

Fase de construccin
Durante la fase de construccin, se desarrollan todos los restantes componentes y funciones de la aplicacin y integrados en el producto, y todas las funciones son probadas a fondo. La fase de construccin es, en cierto sentido, un proceso donde se pone nfasis en el manejo de los recursos y controlar las operaciones de fabricacin optimizar los costos, horarios y calidad. En este sentido, la mentalidad de gestin sufre una transicin de el desarrollo de la propiedad intelectual durante la creacin y elaboracin, para el desarrollo de productos de despliegue durante la construccin y transicin. Muchos proyectos son lo suficientemente grandes como para que pueden ser generados incrementos de construccin paralela. Estos paralelos actividades pueden acelerar significativamente la disponibilidad de versiones desplegables; tambin pueden aumentar la complejidad de la sincronizacin de flujo de trabajo y gestin de recursos. Una arquitectura robusta y un comprensible plan estn altamente correlacionadas. En otras palabras, es una de las cualidades fundamentales de la arquitectura su facilidad de construccin. Esta es una razn por qu es el desarrollo equilibrado de la arquitectura y el plan destac 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, lo consta de: El producto de software integrado en las plataformas adecuadas. Los manuales de usuario. Una descripcin de la versin actual. Hito: La capacidad operativa inicial
Creacin elaboracin construccin transicin Operacional inicial Capacidad

Al final de la construccin fase es el tercer hito importante proyecto (capacidad operativa inicial Milestone). En este punto, usted decide si el software, los sitios y los usuarios estn listos para ir operacional, sin exponer el proyecto a altos riesgos. Esta versin se denomina una versin "beta". Los criterios de evaluacin para la fase de construccin implican responder a estas preguntas: Es esta versin del producto estable y lo suficientemente madura para ser desplegados en la comunidad de usuarios. Todas las partes interesadas estn listos para la transicin hacia la comunidad de usuarios. Son los gastos de recursos reales frente a los gastos previstos todava aceptable? Transicin puede tener que ser pospuesta por una liberacin si el proyecto no puede alcanzar este hito.

Fase de transicin
Creacin elaboracin construccinTransicin

El propsito de la fase de transicin es el producto de software a la comunidad de usuarios de la transicin. Una vez el producto se ha dado al usuario final, generalmente surgen problemas que requieren para desarrollar nuevos lanzamientos, correctos algunos problemas, o terminar las caractersticas que fueron pospuestas. La fase de transicin se introduce cuando una lnea de base es lo suficientemente madura para ser desplegada en el dominio del usuario final. Esto normalmente requiere que se haya completado un subconjunto utilizable del sistema a un nivel aceptable de calidad y la documentacin del usuario est disponible para que la transicin al usuario proporcionar positivo resultados para todas las partes. Esto incluye: "probando" para validar el nuevo sistema contra las expectativas del usuario funcionamiento en paralelo con un sistema heredado que reemplaza conversin de bases de datos operacionales formacin de usuarios y desarrolladores sale el producto a los equipos de ventas, marketing y distribucin La fase de transicin se centra en las actividades necesarias para poner el software en las manos de los usuarios.

Por lo general, esta fase incluye varias iteraciones, incluyendo versiones beta, comunicados de disponibilidad general, como as como correccin de fallos y realce libera. Un esfuerzo considerable es gastado en el desarrollo orientado hacia el usuario documentacin, formacin de usuarios, dando soporte a usuarios en el uso de su producto inicial y reaccionar a comentarios de los usuarios. En este punto del ciclo de vida, sin embargo, comentarios de los usuarios deberan limitarse principalmente a productos tuning, problemas de configuracin, instalacin y facilidad de uso. Los principales objetivos de la fase de transicin incluyen: Lograr la 5.Crews de usuario Lograr la concurrencia de las partes interesadas que las instantneas de despliegue son completa y es consistente con la Criterios de evaluacin de la visin 6 Logrando basal producto final lo ms rpidamente y eficazmente como sea posible costo Esta fase puede variar desde ser muy simples a extremadamente complejos, dependiendo del tipo de producto. Para ejemplo, una nueva versin de un producto de escritorio existente puede ser muy simple, considerando que la sustitucin de trfico areo de una nacin sistema de control sera muy complejo. Hito: Lanzamiento de producto Al final de la transicin fase es el cuarto proyecto importante hito, el hito de lanzamiento del producto. En este punto, usted decide si se cumplieron los objetivos, y si debe comenzar otro ciclo de desarrollo. En algunos casos, este hito puede coincidir con el final de la fase inicial para el siguiente ciclo. Los criterios de evaluacin primaria para la fase de transicin implican las respuestas a estas preguntas: Est satisfecha con el usuario? Son los gastos reales de los recursos frente a los gastos previstos todava aceptable?

Iteraciones
Cada fase en el proceso unificado de Rational se puede dividir ms a las iteraciones. Una iteracin es un bucle completo desarrollo resultando en un comunicado (interno o externo) de un producto ejecutable, un subconjunto de el producto final bajo desarrollo, que crece de forma incremental de iteracin de iteracin para convertirse en el sistema final [10]. Beneficios de un enfoque iterativo Comparado con el proceso tradicional de cascada, el proceso iterativo tiene las siguientes ventajas: Los riesgos son 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 quin est haciendo qu, Cmoy cuando. El Rational Unified Process se representa mediante cuatro elementos primarios de modelado: Los trabajadores, el 'quin' Las actividades, el "Cmo" Artefactos, el 'qu' Flujos de trabajo, el 'cuando' 7

Actividades, artefactos y trabajadores

Anlisis de caso de uso diseo diseo de casos de uso Realizacin de casos de uso

Actividades del trabajador Artefacto responsable

Los trabajadores, actividades y artefactos.

Trabajador Un trabajador define el comportamiento y las responsabilidades de un individuo o un grupo de individuos que trabajan juntos como un equipo. Un trabajador podra considera un "sombrero" un individuo puede usar en el proyecto. Uno individuo puede usar muchos sombreros diferentes. Esta es una distincin importante porque es natural pensar en una trabajador como individuo o equipo de s mismo, pero en el unificado

procesar el trabajador es ms el papel de definir cmo los individuos deben realizar el trabajo. Las responsabilidades que le asignamos a un trabajador incluye tanto a realizar un determinado conjunto de actividades, as como ser propietario de un conjunto de artefactos.
Actividades de los trabajadores de recursos Paul Mary Joe Sylvia Stefan Diseador Autor de casos de uso Diseador de casos de uso Revisor de diseo Arquitecto Diseo de objetos ... Detalle de un caso de uso ... Diseo de casos de uso ... Revisar el diseo ... Anlisis arquitectnico Diseo arquitectnico ...

La gente y los trabajadores s. Actividad Una actividad de un trabajador especfico es una unidad de trabajo que un individuo en ese papel se puede realizar. La actividad tiene un objetivo claro, normalmente expresado en trminos de crear o actualizar algunos artefactos, tales como un modelo, una clase, un plan. Cada actividad se asigna a un trabajador especfico. La granularidad de una actividad es generalmente unas horas o unos das, consiste en uno de los trabajadores y generalmente afecta a uno o slo un pequeo nmero de artefactos. Una actividad debe ser utilizable como elemento de planificacin y el progreso; Si es demasiado pequeo, ser descuidados, y si es demasiado grande, progreso tendra que ser expresado en trminos de partes de una actividad. Ejemplo de actividades: Planificar una iteracin , para el trabajador: Project Manager Encontrar actores y casos de uso , para el trabajador: Analista de sistemas Revisin del diseo , para el trabajador: revisor de diseo Prueba de rendimiento de ejecucin , para el trabajador: Performance Tester 8 Artefacto Un artefacto es una pieza de informacin que es producida, modificado o utilizado por un proceso. Los artefactos son el productos tangibles del proyecto, las cosas el proyecto produce o usa mientras se trabaja hacia la final producto. Artefactos se utilizan como entrada de los trabajadores para llevar a cabo una actividad y son el resultado o la salida de los mismos actividades. En trminos de diseo orientado a objetos, como las actividades son operaciones sobre un objeto activo (el trabajador), los artefactos son los parmetros de estas actividades. Artefactos pueden tomar diversas formas o formularios: Un modelo, como el modelo de caso 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, como el caso de negocio o documento de arquitectura de Software Cdigo fuente Archivos ejecutables

Flujos de trabajo
Una mera enumeracin de todos los trabajadores, actividades y artefactos no constituye todo un proceso. Necesitamos una forma de describir las secuencias significativas de las actividades que producen un resultado valioso y Mostrar interacciones entre los trabajadores. Un flujo de trabajo es una secuencia de actividades que produce un resultado de valor observable.

En trminos UML, un flujo de trabajo puede ser expresado como un diagrama de secuencia, un diagrama de colaboracin o una actividad diagrama. En este white paper, utilizamos una forma de diagramas de la actividad.
Arquitecto Caso de uso Diseador Diseador Diseo Revisor Anlisis arquitectnico Revisin del Diseo Revisin del Anlisis Revisin del Arquitectura Diseo de objeto de anlisis de objetos Anlisis de caso de uso caso de uso diseo Diseo arquitectnico describir concurrencia describir distribucin

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 implican el mismo trabajador o el mismo individuo. Las personas no son mquinas, y el flujo de trabajo no puede interpretarse literalmente como un programa para personas, que deben seguirse exactamente y mecnicamente. En la prxima seccin se discutir el tipo ms esencial de los flujos de trabajo en el proceso, llamado ncleo de flujos de trabajo. 9

Flujos de trabajo de ncleo

Hay nueve flujos de proceso de ncleo en el Rational Unified Process, que representan un particionamiento de todos los trabajadores y las actividades en grupos lgicos.
Creacin elaboracin construccin transicin

Fases
Requisitos Anlisis y diseo Implementacin Prueba Medio ambiente Despliegue

Ncleo proceso flujos de trabajo Ncleo de apoyo a los flujos de trabajo Iteraciones
preliminar iteration(s)

Configuracin y administracin del cambio Modelado de negocios

Los nueve principales flujos de proceso.

Los flujos de trabajo del proceso de base se dividen en flujos de trabajo "ingeniera" ncleo seis: 1. flujo de trabajo de modelado de negocios 2. flujo de trabajo requisitos 3. anlisis y diseo de flujo de trabajo 4. flujo de trabajo de aplicacin 5. prueba de flujo de trabajo 6. flujo de trabajo despliegue Y tres flujos de trabajo de "apoyo" de la base: 1. flujo de trabajo de gestin del proyecto 2. configuracin y gestin del cambio de flujo de trabajo 3. flujo de trabajo medio ambiente Aunque los nombres de los seis principales flujos de trabajo de ingeniera puede evocar las fases secuenciales en un tradicional proceso de cascada, debemos tener en mente que las fases de un proceso iterativo son diferentes y que estos los flujos de trabajo son revisitados una y otra vez a lo largo del ciclo de vida. El actual flujo de trabajo completo de un proyecto intercala estos flujos de trabajo de nueve centrales y les repite con diversos nfasis e intensidad en cada uno iteracin.

Modelado de negocios
Uno de los principales problemas con los negocios ms esfuerzos de la ingeniera, que es la ingeniera del software y la comunidad ingeniera empresarial no comunican adecuadamente. Esto conduce a que la salida desde la ingeniera de negocios no se utiliza correctamente como entrada al esfuerzo de desarrollo de software y viceversa. El Rational Unified Process aborda esta proporcionando un lenguaje comn y un proceso para ambos las comunidades, as como mostrando cmo crear y mantener la trazabilidad directa entre negocios y modelos de software. Modelado de negocios documentamos los procesos de negocio utilizando los llamados casos de uso comercial. Esto asegura una comn entendimiento entre todas las partes interesadas de qu proceso necesita ser apoyado en el organizacin. Se analizan los casos de uso empresarial para entender cmo las empresas deben apoyar los procesos de negocio. Esto est documentado en un modelo de objetos de negocio. Muchos proyectos pueden elegir no hacer negocio modelado.

Requisitos
El objetivo del flujo de trabajo de los requisitos es describir lo que el sistema debe hacer y permite a los desarrolladores y el cliente de acuerdo a esa descripcin. Para lograr esto, nos provocan, organizar y documento requerido funcionalidad y restricciones; rastrear y documentar las elecciones y decisiones. Se crea un documento de visin y necesidades de las partes interesadas se produce. Se identifican actores , que representan el los usuarios y cualquier otro sistema que puede interactuar con el sistema se desarrolla. Casos de uso son identificados, que representa el comportamiento del sistema. Porque se desarrollan casos de uso segn las necesidades del actor, la el sistema es ms probable que sea relevante para los usuarios. La siguiente figura muestra un ejemplo de un caso de uso modelo para un sistema de mquina de reciclaje.
Cliente reciclar elementos Imprimir informe diario Administrar depsito artculo Operador

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

Cada caso de uso se describe en detalle. La Descripcin de caso 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 el complementario Especificaciones. La funcin de los casos de uso como un hilo unificador en todo el desarrollo del sistema del ciclo. El mismo caso de uso modelo se utiliza durante la captura de requerimientos, anlisis y diseo y prueba.

Anlisis y diseo
El objetivo del anlisis y diseo de flujo de trabajo es mostrar Cmo el sistema ser realizado en el fase de implementacin. Quiere construir un sistema que: Realiza en un entorno de implementacin especfica las tareas y funciones que se especifican en el usecase descripciones. Satisface todas sus necesidades. Est estructurado para ser robusto (fcil de cambiar cuando cambian sus requerimientos funcionales). Diseo y anlisis de los resultados en un modelo de diseo y, opcionalmente, un 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 cmo es el cdigo fuente estructurado y escrito. El modelo de diseo consiste en clases de diseo estructuradas en paquetes de diseo y diseo de subsistemas con interfaces bien definidas, que representa lo que se convertirn en los componentes de la aplicacin. Tambin contiene descripciones de cmo los objetos de estas clases de diseo colaborarn para llevar a cabo casos de uso. La siguiente figura muestra parte de un modelo de diseo de muestra para el sistema de la mquina de reciclaje en el modelo de caso de uso se muestra en la figura anterior. 11
PrinterPackage y alarma paquete del cliente Impresora de recibos Depsito del artculo AlarmDevice Receptor CustomerPanel

Parte de un modelo de diseo con comunicacin clases de diseo y clases de diseo de grupo de paquete.

Las actividades de diseo estn centradas en la nocin de arquitectura.La produccin y la validacin de este

la arquitectura es el foco principal de las primeras iteraciones del diseo. La arquitectura est representada por un nmero de vistas arquitectnicas [9]. Estos puntos de vista capturan las decisiones importantes del diseo estructural. En esencia, arquitectnica las vistas son abstracciones o simplificaciones de todo el diseo, en el cual se realizan importantes caractersticas ms visible por dejar de lado los detalles. La arquitectura es un vehculo importante no slo para el desarrollo de un modelo de buen diseo, sino tambin para aumentar la calidad de cualquier modelo construido durante el desarrollo del sistema.

Implementacin
El propsito de la aplicacin son: Para definir la organizacin del cdigo, en cuanto a la implementacin de subsistemas organizados en capas. Implementar clases y objetos en trminos de componentes (fuente de archivos binarios, archivos ejecutables, y otros). Para probar los componentes desarrollados como unidades. Para integrar los resultados producidos por los implementadores individuales (o equipos), en un archivo ejecutable sistema. El sistema se realiza a travs de la implementacin de componentes. Describe el Rational Unified Process Cmo reutilizar los componentes existentes o implementar nuevos componentes con responsabilidades bien definidas, hacer el sistema ms fcil de mantener y aumentar las posibilidades de reutilizacin. Los componentes se estructuran en subsistemas de aplicacin. Subsistemas de adoptan la forma de directorios, con Informacin adicional de estructural o de gestin. Por ejemplo, puede crearse un subsistema como un directorio o una carpeta en un sistema de archivos, o un subsistema en Rational/Apex para C++, Ada o paquetes usando Java.

Prueba
Los propsitos de la prueba son: Para verificar la interaccin entre objetos. Para verificar la correcta integracin de todos los componentes del software. Para verificar que se han aplicado correctamente todos los requisitos. Identificar y asegurar defectos son tratadas antes de la implementacin del software. El Rational Unified Process propone un enfoque iterativo, que significa que pruebe a lo largo de la proyecto. Esto le permite encontrar defectos tan pronto como sea posible, que reduce radicalmente el costo de la fijacin de la el defecto. Prueba se llevan a cabo a lo largo de tres calidad dimensiones fiabilidad, funcionalidad, aplicacin desempeo y rendimiento del sistema. Para cada una de estas dimensiones de calidad, describe el proceso de cmo usted pasar por la prueba de ciclo de vida de planificacin, diseo, implementacin, ejecucin y evaluacin. Se describen las estrategias para cundo y cmo automatizar la prueba. Automatizacin de pruebas es especialmente importante usando un enfoque iterativo, para permitir nuevas pruebas de regresin y final de cada iteracin, as como para cada uno versin del producto.

Despliegue
El propsito del flujo de trabajo de implementacin es con xito producir lanzamientos de productos y entregar el software para sus usuarios finales. Cubre una amplia gama de actividades que incluyen: 12 Produciendo versiones externas del software. Embalaje del software. Distribuir el software. Instalacin del software. Proporcionando ayuda y asistencia a los usuarios. En muchos casos, esto tambin incluye actividades tales como: Planificacin y realizacin de pruebas beta. Migracin de datos o software existente. Aceptacin formal. Aunque despliegue actividades estn centradas sobre todo en la fase de transicin, muchas de las actividades es necesario para ser incluidos en las fases anteriores para prepararse para su despliegue en el final de la fase de construccin.

Los flujos de trabajo despliegue y medio ambiente de la Rational Unified Process contienen menos detalle que otro flujos de trabajo.

Gestin de proyectos
Gestin de proyectos es el arte de balancear objetivos contrapuestos, manejo de riesgo y la superacin de restricciones para entregar, con xito, un producto que satisfaga las necesidades de los clientes (los pagadores de facturas) y los usuarios. El hecho de que algunos proyectos son indiscutiblemente exitosos es suficiente comentar 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 facilitar la tarea al proporcionar: Un marco para la gestin de proyectos intensivos en software. Directrices prcticas para la planeacin, personal, ejecucin y seguimiento de proyectos. Un marco para la gestin del riesgo. No es una receta para el xito, pero presenta un enfoque para administrar el proyecto, que ser marcado mejorar las posibilidades de entrega de software exitoso. [14]

Configuracin y gestin del cambio

En este flujo de trabajo describimos cmo controlar los numerosos artefactos producidos por las muchas personas que trabajar en un proyecto comn. Control ayuda a evitar confusiones costosas y asegura que no son artefactos resultantes en conflicto debido a algunos de los siguientes tipos de problemas: Actualizacin simultneaCuando dos o ms trabajadores trabajan por separado en el mismo artefacto, el ltimo para realizar cambios destruye el trabajo del anterior. Notificacin limitadaCuando un problema es solucionado en artefactos compartidos por varios desarrolladores, y algunos de ellos no son notificados del cambio. Varias versionesMayora de los grandes programas se desarrollan en comunicados evolutivas. Una versin podra estar en uso del cliente, mientras otro est en prueba, y la tercera est an en desarrollo. Si problemas se encuentran en cualquiera de las versiones, necesidad de correcciones a propagar entre ellos. Confusin puede surgen lderes para volver a trabajar y costosas reparaciones a menos que los cambios son cuidadosamente controlados y supervisados. Este flujo de trabajo proporciona directrices para administrar mltiples variantes de sistemas de software, seguimiento de evolucin las versiones se utilizan en dado software construye, realizar compilaciones de programas individuales o entero versiones segn las especificaciones de la versin definida por el usuario y hacer cumplir las polticas de desarrollo especfico. Describimos cmo puede administrar desarrollo paralelo, hecho en mltiples sitios, el desarrollo y cmo automatizar el proceso de compilacin. Esto es especialmente importante en un proceso iterativo, donde quiz quieras ser capaz de hacer estructuras tan a menudo como todos los das, algo que sera imposible sin la automatizacin de gran alcance. Tambin describimos como puedes mantener una auditora trail en por qu, cundo y por quin fue cambiado cualquier artefacto. Este flujo de trabajo tambin cubre administracin de solicitudes de cambio, es decir, cmo reportar defectos, manejarlos a travs de su ciclo de vida y cmo utilizar defecto datos para rastrear el progreso y las tendencias. 13

Medio ambiente
El propsito del flujo de trabajo del medio ambiente es proporcionar la organizacin de desarrollo de software con la entorno de desarrollo de software, herramientas y procesos que son necesarios para apoyar el desarrollo equipo. Este flujo de trabajo se centra en las actividades para configurar el proceso en el contexto de un proyecto. Tambin centrar en actividades para desarrollar las directrices necesarias para apoyar un proyecto. Se proporciona un procedimiento paso a paso describe cmo implementar un proceso en una organizacin. El flujo de trabajo medio ambiente tambin contiene un Kit de desarrollo de proveerle con las directrices, plantillas y las herramientas necesarias para personalizar el proceso. El Kit de desarrollo se describe con ms detalle en el seccin "Desarrollo Kit para el proceso de personalizacin" encontr ms adelante en este documento.

Ciertos aspectos del flujo de trabajo del medio ambiente no estn cubiertos en el proceso como seleccionar, adquirir, y fabricacin de las herramientas de trabajo y mantener el entorno de desarrollo.

Rational Unified Process - el producto

El producto Rational Unified Process consiste en: Una base de conocimientos de bsqueda habilitado para la web proporciona directrices, todos los miembros del equipo plantillas y mentores de herramienta para todas las actividades de desarrollo crtico. La base de conocimientos puede Adems se rota hacia abajo para: Amplias directrices para todos los miembros del equipo y todas las porciones del software ciclo de vida. Se proporciona orientacin para ambos el alto proceso de pensamiento, as como en cuanto a las actividades diarias ms tediosas. La gua se publica en Formulario HTML para facilitar el acceso independiente de la plataforma en su escritorio. Mentores de herramienta proporcionar orientacin prctica para herramientas cubriendo el ciclo de vida completo. Los mentores de la herramienta se publican en forma de HTML para fcil independiente de la plataforma accede a tu escritorio. Consulte la seccin "Integracin con herramientas" para ms detalles. Rational Rose ejemplos y plantillas proporcionar orientacin para saber cmo estructurar la informacin en Rational Rose cuando siguiendo el Rational Unified Proceso (Rational Rose es la herramienta de Rational para el modelado visual) SoDA plantillas ms de 10 plantillas de SoDA que ayuda a automatizar documentacin del software (SoDA es documento herramienta del racional de automatizacin) Microsoft Plantillas de Word ms de 30 plantillas de Word asistir documentacin en todos los flujos de trabajo y todas las partes del ciclo de vida Los planes de Microsoft Project Muchos gestores resulta difcil crear planes de proyectos Eso refleja un enfoque de desarrollo iterativo. Nuestras plantillas arranca la creacin de planes de proyectos para el desarrollo iterativo, segn el Rational Unified Process. Kit de desarrollo de describe cmo personalizar y ampliar el Rational Unified Proceso a las necesidades especficas de la organizacin o proyecto, adoptando as como proporciona herramientas y plantillas para ayudar al esfuerzo. Este kit de desarrollo se describe en ms detalle ms adelante en esta seccin. Acceso al Centro de recursos que contiene los documentos ms recientes, actualizaciones, consejos, y tcnicas, as como referencias a servicios y productos complementarios. Un libro " Proceso unificado de rational una introduccin ", de Philippe Krutchen, publicado por Addison-Wesley. El libro est en 277 pginas y proporciona una buena introduccin y Resumen del proceso y el conocimiento base. 14 Navegando por la Base de conocimientos El conocimiento de Rational Unified Process le permite acceder a los contenidos con cualquiera de la popular web navegadores, como Microsoft Internet Explorer y Netscape Navigator. Con el Rational Unified Process, nunca ests ms de unos pocos clics de ratn de la informacin Quieres. La base de conocimientos contiene un montn de enlaces de hipertexto y descripciones del proceso varios los elementos se presentan a travs de imgenes interactivas, lo que facilita encontrar la informacin relevante en una manera intuitiva. El potente motor de bsqueda, el ndice y el browser del rbol "explorer buscando" hacerlo fcil de usar el proceso. Botones de navegacin le permiten mover a la pgina siguiente o anterior como si leyera un libro. La informacin se presenta en muchas opiniones diferentes, le permite buscar informacin relevante para su papel, para una actividad especfica o para un flujo de trabajo. Visitas guiadas para el fcil aprendizaje del proceso se proporcionan para clave funciones del proyecto.
Imgenes interactivas y botones de navegacin hacen fcil encontrar la informacin especfica que usted est buscando.

Kit de desarrollo para el proceso de personalizacin El Rational Unified Process es general y bastante completo para ser utilizado "como es" por algn software organizaciones de desarrollo. Sin embargo en muchas circunstancias, ser necesario este proceso de ingeniera del software modificarse, ajustado y adaptado para dar cabida a las caractersticas especficas, restricciones e historia de la organizacin adopta. En particular un proceso debe no seguir ciegamente, generando intil trabajo, produccin de artefactos que son de poco valor agregado. Debe hacerse tan magro como sea posible y poder para cumplir con su misin: producir software de forma rpida y fiable de alta calidad. El proceso contiene un Kit de desarrollo, que contiene directrices de cmo usted puede personalizar el proceso para adaptarse a las necesidades especficas de la organizacin o proyecto de adopcin. Tambin se incluyen plantillas para proceso de creacin de contenidos, as como herramientas para la generacin o manipulacin del buscador, ndice, mapa del sitio, rbol navegador, etc. El Kit de desarrollo permite la personalizacin organizacin mantener la apariencia de el proceso unificado de Rational. Ms el proceso es personalizado, ms difcil ser pasar sobre las personalizaciones a futuro comunicados del proceso. El Kit de desarrollo describe las estrategias, herramientas y tcnicas para minimizar el trabajo asociado con la mudanza personalizaciones para futuras versiones.

Integracin con herramientas de

Un proceso de ingeniera de software requiere herramientas para apoyar todas las actividades de ciclo de vida de un sistema, especialmente a apoyar el desarrollo, mantenimiento y contabilidad de varios artefactos modelos en particular. Un proceso de desarrollo iterativo pone requisitos especiales en el conjunto de herramientas que utiliza, tales como una mejor integracin entre las herramientas e ingeniera de ida y vuelta entre modelos y cdigo. Tambin se necesitan herramientas para hacer un seguimiento de cambios, para apoyar la trazabilidad de requisitos, para automatizar la documentacin, as como herramientas para automatizar las pruebas para facilitar la prueba de regresin. El Rational Unified Process puede usarse con una variedad de herramientas, ya sea desde Racional u otros proveedores. Sin embargo, Rational proporciona muchas herramientas bien integradas que soporte eficientementeel proceso unificado de Rational. A continuacin encontrar una lista de algunas de las herramientas de Rational que apoyan el proceso unificado de Rational. El Rational Unified Process contiene Herramienta mentores para casi la totalidad de estos productos. Un Mentor de la herramienta es un Gua paso a paso que describe en detalle cmo funciona una herramienta (es decir, qu mens para lanzar, qu informacin para entrar en los cuadros de dilogo y cmo navegar una herramienta) para llevar a cabo una actividad dentro del proceso. La herramienta Mentores nos permiten vincular el proceso independiente de la herramienta a la manipulacin real de las herramientas en su diario trabajo. Requisito racional Pro Mantiene el equipo completo de desarrollo actualizado y en camino a lo largo de la proceso de desarrollo de aplicaciones facilitando los requisitos escribir, comunicar y cambiar . Rational ClearQuest A Windows y producto de la gestin basada en Web-solicitud de cambio que los equipos de proyectos permite rastrear y administrar todo cambian las actividades que ocurren durante el desarrollo ciclo de vida. Rational Rose 98 Lder visual herramienta de modelado el mundo de procesos de negocio, Anlisis de requerimientos y diseo de la arquitectura de componentes. Rational SoDA Automatiza la produccin de documentacin para el desarrollo de software completo proceso, reduciendo drsticamente los costos y el tiempo de documentacin. Racional purificar Una herramienta comprobacin de error de tiempo de ejecucin para aplicaciones y componentes software desarrolladores de programacin en C/C++; ayuda a detecta errores de memoria. Visual racional cuantificar Una actuacin avanzada herramienta para aplicacin de perfiles y desarrolladores de software de componente de programacin en Visual Basic, C++ y Java; ayuda a eliminar cuellos de botella de rendimiento. de PureCoverage Visual racional Automticamente seala zonas de cdigo no se ejerce en las pruebas que

los desarrolladores pueden probar sus aplicaciones completamente, eficiencia y eficacia. TeamTest racional Crea, mantiene y ejecuta pruebas funcionales automatizadas, lo que le permite Fondo probar tu cdigo y determinar si su software cumple con los requisitos y se desempea como Espera. PerformanceStudio racional Una herramienta fcil de usar, precisa y escalable que mide y predice el desempeo de sistemas Web y cliente/servidor. Rational ClearCase Herramienta de gestin de configuracin software lder en el mercado, y dando proyecto los administradores el poder para seguir la evolucin de cada proyecto de desarrollo de software. 16

Una breve historia de la Rational Unified Process

El Rational Unified Process ha madurado durante muchos aos y refleja la experiencia colectiva de la muchas personas y empresas que conforman el rico patrimonio de hoy Rational Software. Tengamos una mirada rpida a la ascendencia del proceso, como se ilustra en la figura siguiente. Genealoga del proceso unificado de Rational Yendo hacia atrs en el tiempo, el Rational Unified Process es el sucesor directo de la Rational Objectory Proceso (versin 4). El Rational Unified Process incorpora ms material en las reas de datos Ingeniera, modelos de negocio, gestin de proyectos y gestin de la configuracin, el ltimo como resultado de la fusin con Pure-Atria. Tambin trae una integracin ms estrecha a la suite de herramientas de Rational Software. El Rational Objectory Process fue el resultado de la integracin de la "aproximacin racional" y la Proceso Objectory (versin 3), tras la fusin de Rational Software Corporation y Objectory AB en 1995. de su ascendencia Objectory, el proceso ha heredado su estructura de proceso y el concepto central de caso de uso . De su fondo racional, obtuvo la formulacin actual del desarrollo iterativo y arquitectura . Esta versin tambin incorpora material sobre gestin de requerimientos de requisito, Inc. y SQA, Inc. , las empresas que tambin se fusionaron con Rational Software heredado un proceso detallado de la prueba. Finalmente, este proceso fue el primero que se utilice el recin creado Unified Modeling Language (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 de su compaa, Objectory AB centrado en torno al concepto de caso de uso y un mtodo de diseo orientado a objetos, rpidamente gan reconocimiento en la industria del software y ha sido adoptado e integrada por muchas empresas en todo el mundo. Una versin simplificada de la Objectory proceso fue publicado como un libro de texto en 1992. El Rational Unified Process es una instancia concreta y detallada de un proceso ms genrica descrita por Ivar James Rumbaugh en el libro de texto, El desarrollo de Software unificado , Grady Booch y Jacobson Proceso. 17