Flujos de trabajo en el Rational Unified Process Al igual que con la primera nota en la serie de Ingeniera de Software, esta nota

basa en gran medida en la descripcin de la RUP en la propia racional whitepapor el RUP. El objetivo de estas notas es exponerle a un tpico proceso comercial. En las notas posteriores consideraremos la estructura de deprocesos rrollo con ms detalle y estudiar cmo alternativa enfoques para el enfoque adoptado peso pesado en el RUP. En conferencia Nota 1 se consideraron las mejores prcticas incorporadas en y pahases del RUP. En esta nota se considera el proceso y el principal trabajo flujos que componen el RUP. Este invloves un breve examen de cmo vamos a describiendo los procesos de desarrollo y, a continuacin se describe la estructura de la RUP. Describir los procesos de desarrollo Proceso de desarrollo de software implica la coordinacin de una compleja mezcla de recursos para entregar un producto de software completo. El RUP adopta un punto de vista particular sobre cmo describir tales procesos. Una descripcin del proceso consiste en la descripcin: Los trabajadores, que realizan diversas actividades. Las actividades, que describen cmo los trabajadores realizan su trabajo. Los artefactos, las cosas que los trabajadores trabajan. Flujos de trabajo, cuando las actividades se hacen a los artefactos por los rabajadores. Trabajador: Un trabajador define el comportamiento y responsabilidades de un individuo, o un grupo de individuos que trabajan juntos como un equipo. Se podra considerar que un trabajador un "sombrero" o "papel" que un individuo puede usar en el proyecto. Un individuo puede tener muchas funciones diferentes. Esta distincin es importante porque es natural pensar en un trabajo como el individuo o el propio equipo, pero en el Proceso Unificado del trabajador es el papel que define cmo las personas deben llevar a cabo el trabajo. La responsabilidades que le asignamos a un trabajador incluye tanto para realizar un determinado conjunto de actividades, adems de ser dueo de un conjunto de artefactos CS2 Software Engineering nota 2 CS2Ah 10/01/22 Actividad: Una 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, por lo general expresado en trminos de creacin o actualizacin de algunos artefactos, como un modelo, de una

clase, un plan. Cada actividad se asigna a un trabajador especfico. La granularidad de una actividad en general 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 deber ser utilizable como elemento de la planificacin y el progreso, y si es demasiado pequeo, se descuida, y si es demasiado grande, tendra el progreso que se expresa en trminos de una actividad de partes. Ejemplo de actividades, y el trabajador que se les asigna, son: Planifique una iteracin, llevada a cabo por el trabajador: Project Manager Bsqueda de casos de uso y actores, llevadas a cabo por el trabajador: Analista de Sistemas Revisar el diseo, realizado por el trabajador: Diseo Crtico Ejecutar pruebas de rendimiento, llevado a cabo por el trabajador: Performance Tester Artefacto: Un artefacto es un fragmento de informacin que se produce, modificado o utilizado por un proceso. Los artefactos son los productos tangibles del proyecto, las cosas el proyecto produce o usa en el trabajo hacia el producto final. 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 orientados a objetos, como las actividades son operaciones en un objeto activo (el trabajador), artefactos son los parmetros de estas actividades. Los artefactos son muy heterogneos, que a menudo son delivarables del desarrollo proceso. Por ejemplo: Un modelo, como el modelo de casos de uso o el modelo de diseo Un elemento de modelo, es decir, un elemento dentro de un modelo, como una clase, un uso caso o un subsistema Un documento, como caso de negocio o software Document Architecture Cdigo Fuente Cdigo ejecutable Flujos de trabajo: Una simple enumeracin de todos los trabajadores, actividades y artefactos no hace bastante constituir un proceso. Necesitamos una manera de describir secuencias significativas de 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 observables valor capaz. En trminos de UML, un flujo de trabajo se puede expresar como un diagrama de secuencia, una diagrama de colaboracin, o un diagrama de actividades. Utilizamos una forma de diagramas de Actividad en este documento. Tenga en cuenta que no siempre es posible o prctico para representar a la totalidad de la depen-dencias entre actividades. A menudo dos actividades estn ms estrechamente entrelazadas que muestran, sobre todo cuando se refieren a un mismo trabajador o de la misma persona. Las personas no son mquinas, y el flujo de trabajo no se pueden interpretar literalmente como programa para la gente, para seguir con exactitud y de forma mecnica. En la siguiente seccin vamos a discutir la forma ms esencial de los flujos de trabajo en el proceso, llamado Core Flujos de trabajo.

Flujos de trabajo bsicos Hay nueve flujos de trabajo de procesos bsicos en el Rational Unified Process, que representar una divisin de todos los trabajadores y actividades en grupos lgicos. La los flujos de trabajo de procesos centrales se dividen en seis flujos de trabajo de ingeniera de centrales: 1. Negocios flujo de trabajo de modelado 2. Requisitos de flujo de trabajo 3. Anlisis y diseo de flujo de trabajo 4. Flujo de trabajo de la aplicacin 5. Flujo de trabajo de prueba 6. Flujo de trabajo de implementacin Adems hay tres flujos de trabajo de soporte de ncleo. Los artefactos generados byt estos flujos de trabajo no son parte del producto que est siendo desarrollado, pero son essentail al smoot ejecucin de cualquier proyecto: 1. Proyecto de Gestin de flujo de trabajo 2. Configuracin y cambio de flujo de trabajo de gestin 3. Flujo de trabajo para el Medio Ambiente Aunque los nombres de los seis flujos de trabajo de ingeniera de ncleo evocan la secuencial fases de un proceso de cascada tradicional, debemos tener en cuenta que las fases de un proceso iterativo son diferentes y que estos flujos de trabajo son analizadas de nuevo y otra vez durante todo el ciclo de vida. El flujo de trabajo real de un proyecto entrelaza estos 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 de la mayora de empresas de ingeniera esfuerzos, es que la ingeniera de software y la comunidad de ingeniera de negocios no se comunican correctamente entre s. Esto conduce a que la salida desde ingeniera de negocios no se utiliza adecuadamente como insumo para el desarrollo de software esfuerzo, y vice-versa. El Rational Unified Process aborda esta proporcionando una lenguaje comn y un proceso para ambas comunidades, as como los que muestran cmo crear y mantener la trazabilidad directa entre los modelos de negocios y de software. En el negocio del modelaje nosotros los procesos de negocio de documentos mediante los llamados negocios casos de uso. Esto asegura un entendimiento comn entre todas las partes interesadas de qu procesos de negocio necesita ser apoyado en la organizacin. El negocio casos de uso son analizados para entender cmo la empresa debe apoyar la nego-procesos Ness. Esto est documentado en un negocio del modelo de objetos. Los proyectos pueden optar por no hacer modelado de negocio si el producto no est fuertemente arraigada en algunos procesos de negocio. Requisitos: El objetivo del flujo de trabajo Requisitos es describir lo que el sistema debe hacer, y permite a los desarrolladores y el cliente para acordar que Descripcin. Para lograr esto, provocar, organizar y documentar obligados funcin cionalidad y limitaciones; pista y compensaciones y decisiones de documentos. Una

Visin Se crea el documento y necesidades de los interesados se suscit. Se identifican los actores, representa a los usuarios, y cualquier otro sistema que puede interactuar con el sistema siendo desarrollado. Los casos de uso se identifican, que representa el comportamiento de los sistemas-tem. Debido a que los casos de uso se desarrollan de acuerdo a las necesidades del actor, el sistema de es ms probable que sea relevante para los usuarios.Un caso de uso describe un escenario representativo en el uso del sistema. Utilizar anlisis de casos intenta descubrir todos esos usos 1. Cada caso de uso se describe en detalle. La descripcin de casos de uso muestra cmo el sistema interacta paso a paso con los actores y lo que hace el sistema. Los requerimientos no funcionales son descrito en las Especificaciones Suplementarias. Los casos de uso funcionan como un unificador hilo durante todo el ciclo de desarrollo del sistema. El mismo modelo de casos de uso es utilizados durante la captura de requisitos, anlisis y diseo, y la prueba. Anlisis y diseo: El objetivo del flujo de trabajo de anlisis y diseo es mostrar cmo el sistema se llevar a cabo en la fase de implementacin. Usted quiere construir una sistema que: Lleva a cabo en un entorno de implementacin especfico de las tareas y funciones especificado en las descripciones de casos de uso. Cumple con todos sus requisitos. est estructurado para ser robusto (fcil de cambiar, siempre y cuando su funcionalidad re-requisitos cambio). Anlisis y diseo da como resultado un modelo de diseo y, opcionalmente, un modelo de anlisis. El modelo de diseo sirve como una abstraccin del cdigo fuente, es decir, el diseo modelo acta como un "modelo" de la forma en que el cdigo fuente est estructurado y escrito. El modelo de diseo consiste en clases de diseo estructurados en paquetes de diseo y Por lo general, es imposible identificar todos los casos de uso asociado a un sistema ya que para muchos el contexto de los sistemas de uso no es fijo sino que evoluciona con el tiempo y que el producto se utiliza en ms contextos subsistemas de diseo con interfaces bien definidas, en representacin de lo que ser componentes de la aplicacin. Tambin contiene una descripcin de cmo los objetos de estas clases de diseo de colaborar para llevar a cabo los casos de uso. Disear actividades se centran alrededor de la nocin de la arquitectura. El produccin y validacin de esta arquitectura es el foco principal del diseo temprano iteracin ciones. Arquitectura est representado por un nmero de puntos de vista arquitectnicos [1]. Estos vistas capturan las principales decisiones de diseo estructural. En esencia, la arquitectura vistas son abstracciones o simplificaciones de todo el diseo, en el que importantes caractersticas 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 por el aumento de la calidad de cualquier modelo construido durante el desarrollo del sistema.

Implementacin Los efectos de la aplicacin son: Definir la organizacin del cdigo, en trminos de implementacin subsistema tems organizados en capas. Implementar clases y objetos en trminos de los componentes (archivos de cdigo fuente, binarios, ejecutables y otros). Para probar los componentes desarrollados como unidades. Integrar los resultados producidos por los ejecutores individuales (o equipos), en un sistema ejecutable. El sistema se realiza mediante la aplicacin de los componentes. El Racional Proceso Unificado describe cmo reutilizar los componentes existentes, o establecer nuevos componentes con responsabilidad bien definida, haciendo el sistema ms fcil de principal-Tain, y el aumento de las posibilidades de reutilizar. Los componentes se estructuran en Subsistemas de implementacin. Subsistemas subestructura es introducido para facilitar la managemnet esfuerzo involucrado en la creacin de implementaciones. En Java, subsistemas corresponder a los paquetes. Pruebe el propsito de la evaluacin son: Para comprobar la interaccin entre los objetos. Para verificar la adecuada integracin de todos los componentes del software. Para verificar que todos los requisitos se han implementado correctamente. Identificar y garantizar 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 permite encontrar defectos tan pronto como sea ble, que reduce radicalmente el coste de la fijacin del defecto. Prueba se lleva a cabo a lo largo de tres dimensiones fiabilidad calidad, funcionalidad, rendimiento de la aplicacin y el rendimiento del sistema. Para cada una de estas dimensiones de la calidad, el proceso describe la forma en que avanza el ciclo de vida de la prueba de la planificacin, diseo, implementacin ejecucin y evaluacin. Estrategias para cundo y cmo automatizar las pruebas son descrito. Automatizacin de pruebas es especialmente importante el uso de un enfoque iterativo, para permitir las pruebas de regresin a continuacin, al final de cada iteracin, as como para cada nueva versin del producto. Implementacin: El objetivo del flujo de trabajo de despliegue es al xito producir lanzamientos de productos, y entregar el software a sus usuarios finales. Abarca una amplia gama de actividades que incluyen: Producir versiones externas del software. Empaquetamiento del software. Distribuir el software. Instalacin del software. Proporcionar ayuda y asistencia a los usuarios. En muchos casos, esto tambin incluye actividades tales como: Planificacin y realizacin de pruebas beta.

 Migracin de software o datos existentes. La aceptacin formal. Aunque las actividades de implementacin se centra fundamentalmente en la fase de transicin, muchas de las actividades que deben ser incluidas en las fases anteriores para preparar despliegue cin al final de la fase de construccin. El despliegue y Medio Ambiente los flujos de trabajo del Rational Unified Process contienen menos detalles que otros trabajos-flujos. Esto completa la descripcin de los flujos de trabajo orientado a la generacin de artihechos que estn relacionados directamente con el producto. Los flujos de trabajo restantes con-Tain las tareas de apoyo relacionadas con la gestin y el control del proyecto. Gestin de proyectos: Project Management Software es el arte del equilibrio objetivos contrapuestos, la gestin de riesgo, y la superacin de las limitaciones para ofrecer, suc-cessfully, un producto que satisface las necesidades tanto de los clientes (los que pagan las facturas) y los usuarios. El hecho de que algunos proyectos son indiscutiblemente exitosa es comcin suficiente sobre la dificultad de la tarea. Este flujo de trabajo se centra principalmente en la aspecto especfico de un proceso de desarrollo iterativo. El objetivo de este flujo de trabajo es para hacer la tarea ms fcil, proporcionando: Un marco para la gestin de proyectos intensivos en software. Orientaciones prcticas para la planificacin, dotacin de personal, ejecucin y seguimiento de los proyectos. Un marco para la gestin del riesgo. Thsi flujo de trabajo no puede dar una receta para el xito, sino que presenta un enfoque de la la gestin del proyecto que mejora notablemente las probabilidades de xito de la entrega de software. [2] Gestin de la Configuracin y Cambio en el flujo de trabajo se describe la forma de controlar los numerosos artefactos producidos por las muchas personas que trabajan en un proyecto comn. Control ayuda a evitar costosas confusin y asegura que resulartefactos tantes no estn en conflicto debido a algunos de los siguientes tipos de problemas: Actualizacin simultnea - Cuando dos o ms trabajadores trabajan por separado en el mismo artefacto, el ltimo en hacer cambios destruye el trabajo de los primeros. Notificacin Limited - Cuando un problema se resuelve en artefactos compartidos por varios desarrolladores, y algunos de ellos no son notificados del cambio. Mltiples Versiones - Ms grandes programas se desarrollan en la evolucin rearrendamientos. Una liberacin podra ser en el uso de los clientes, mientras que otro est en la prueba, y el tercero est todava en desarrollo. Si se encuentran problemas en uno cualquiera de los versiones, correcciones necesitan ser propagado entre ellos. La confusin puede surgir dando lugar a costosas reparaciones y la prdida de tiempo a menos que los cambios se controlan cuidadosamente y monitoreados.

Este flujo de trabajo proporciona directrices para la gestin de mltiples variantes de evolucin sistemas de software, seguimiento de las versiones que se utilizan en el software dado construye, realizar compilaciones de programas individuales o en lanzamientos completos de acuerdo con el usuario definido especificaciones de la versin y la aplicacin de polticas de desarrollo especficas del sitio. En l se describe la forma de gestionar el desarrollo en paralelo, el desarrollo hecho en mltiples sitios, y la forma de automatizar el proceso de construccin. Esto es especialmente importante en una proceso en el que es posible que desee ser capaz de hacer construye con la frecuencia diaria iterativo, algo que sera imposible sin la automatizacin de gran alcance. Tambin describe cmo mantener una pista de auditora sobre qu, cundo y por quin fue ningn artefacto cambiado. Este flujo de trabajo tambin incluye la gestin de solicitud de cambio, es decir, cmo defectos de informes, gestin de ellos a travs de su ciclo de vida, y la forma de utilizar los datos de defectos para seguir el progreso y las tendencias. Medio Ambiente: El objetivo del flujo de trabajo medio ambiente es proporcionar a la suave-organizacin de desarrollo de software con el entorno de desarrollo de software, tanto procesos y herramientas que se necesitan para apoyar al equipo de desarrollo. Este flujo de trabajo se centra en las actividades para configurar el proceso en el contexto de un proyecto. Tambin se centra en actividades para desarrollar las pautas necesarias para apoyar un proyecto. Con esto se completa este breve resumen de la RUP. Como se puede ver la descripcin del proceso y el nmero de actividades y la coordinacin necesaria hacer el RUP un enfoque bastante "pesado" para el proceso de desarrollo. En notas posteriores vamos a reflexionar sobre este proceso y considerar algn procedimiento alternativo de la corriente utilizar para el desarrollo orientado a objetos. Bibliografa [1] Philippe Kruchten, The 4 1 Ver Modelo de Arquitectura, IEEE Software, 12 (6), noviembre de 1995, IEEE, pp.42-50. [2] Walker Royce, Gestin de Proyectos de Software de un marco unificado, AddisonWesley, 1998.