RUP El Rational Unified Process o Proceso Unificado de Rational Inc es una implementacin comercial del Proceso Unificado.

Es un proceso de ingeniera de software que provee un enfoque para asignar tareas y responsabilidades dentro de una organizacin de desarrollo. Su objetivo es asegurar la produccin de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad especfica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguage, la misma visin y el mismo proceso acerca de cmo desarrollar software.

Fases de RUP Sobre modelos Las actividades de RUP se centran en crear y mantener modelos, utilizando UML, Lenguaje de Modelizacin Unificado, en forma efectiva. Como no existe un nico proceso que sea apropiado para todos los desarrollos, RUP es un proceso configurable. Se adapta tanto a grupos pequeos de desarrollo como a grandes organizaciones. Basndose en lo que se consideran best practices, las mejores prcticas de desarrollo de software, RUP resulta apropiado para un amplia gama de proyectos y organizaciones. Las 6 mejores prcticas de desarrollo que aplica RUP * Desarrollo de software en forma iterativa * Gestin de requerimientos * Uso de arquitecturas basadas en componentes * Modelizacin visual del software * Verificacin de calidad del software * Control de cambios 1. Desarrollo de software en forma iterativa

Dada la complejidad de los sistemas de software modernos no es posible definir el problema entero en forma secuencial, disearlo en su totalidad, construirlo y testearlo. El enfoque iterativo permite ir creciendo en el entendimiento del problema.a travs de refinamientos sucesivos. Esto tambin permite introducir cambios tcticos en los requerimientos, caractersticas del sistema o en los tiempos. 2. Gestin de requerimientos Las nociones de casos de uso y escenarios resultaron ser una forma excelente de capturar requerimientos funcionales y de asegurar que estos rijan el diseo, la implementacin y el testeo de software; haciendo ms probable que el sistema final cumpla exactamente con lo que pidi el cliente. 3. Uso de arquitecturas basadas en componentes RUP apoya el desarrollo de software basado en componentes. Los componentes son mdulos no triviales, subsistemas que satisfacen una funcin definida. RUP proporciona un acercamiento sistemtico definiendo una arquitectura usando componentes nuevos y existentes. stos estn montados en una arquitectura bien definida, o bien ad hoc, o en una infraestructura de componentes reutilizables tal como el Internet, el CORBA, y J2EE 4. Modelizacin visual del software El proceso le demuestra cmo modelar visualmente software para capturar la estructura y el comportamiento de arquitecturas y de componentes. Esto permite que usted oculte los detalles y que escriba cdigo usando bloques de construccin grficos. Las abstracciones visuales le ayudan a comunicar diversos aspectos del software, ayudan a mantener la consistencia entre un diseo y su puesta en marcha; y favorecen la comunicacin inequvoca. El UML es la base de esta modelizacin visual. 5. Verificacin de calidad del software Una performance y una confiabilidad pobres son los factores comunes que inhiben dramticamente la aceptabilidad de los usos del software hoy en da. Por lo tanto, la calidad se debe revisar con respecto a los requerimientos basados en la confiabilidad, funcionalidad, performance de la aplicacin y del sistema. RUP le asiste en el planeamiento, el diseo, la puesta en marcha, la ejecucin, y la evaluacin de estos tipos de pruebas. El estudio de la calidad est incorporado como parte del proceso, en todas las actividades, implicando a todos los participantes, usando medidas y criterios objetivos, y no se trata de una actividad separada realizada por otro grupo. 6. Control de cambios La capacidad de manejar los cambios - asegurndose que cada cambio sea aceptable, y pudiendo continuar con los mismos- es esencial en un ambiente en el cual el cambio es inevitable. El proceso describe cmo controlar, seguir y supervisar cambios para permitir el

desarrollo iterativo acertado. Tambin gua sobre cmo establecer los espacios de trabajo seguros para cada desarrollador proporcionando el aislamiento de los cambios realizados en otros espacios de trabajo y controlando los cambios de todos los dispositivos de software (modelos, cdigo, documentos, etc.). Describiendo cmo automatizar la integracin, hace que el equipo trabaje como una sola unidad. RUP: Visin del proceso en 2 dimensiones El proceso se puede describir en dos dimensiones: * El eje horizontal representa tiempo y demuestra el aspecto dinmico del proceso, se expresa en trminos de ciclos, de fases, de iteraciones, y de hitos o milestones. * El eje vertical representa el aspecto esttico del proceso: cmo se describe en trminos de actividades, de dispositivos, de trabajadores y de workflows. . El ciclo de vida del software est particionado en ciclos, cada ciclo trabaja en una nueva generacin del producto. El RUP divide un ciclo de desarrollo en cuatro fases consecutivas. * Fase de inicio * Fase de elaboracin * Fase de construccin * Fase de transicin Cada fase constituye un eslabn bien definido, un punto en el tiempo en el cual ciertas decisiones crticas deben tomarse, y por lo tanto afinar metas debe haber sido alcanzadas. Fase de inicio Durante la fase del inicio, se establece el caso de negocio para el sistema y delimita el alcance del proyecto. Para lograr esto debe identificar todas las entidades externas con las cuales el sistema interacte (los actores) y definir la naturaleza de esta interaccin a un nivel alto. Esto implica identificar todos los casos de uso y describir slo los ms significativos. El caso de negocio incluye criterios de xito, la evaluacin de riesgos, y la estimacin de los recursos necesarios, y un plan de la fase que muestre las fechas previstas e hitos importantes. Resultado de la Fase de inicio El resultado de la fase del inicio es: * Un documento de la visin: una visin general de los requerimientos bsicos del proyecto, de las caractersticas dominantes, y de las restricciones principales. * Un modelo inicial de casos de uso (10%-20% completo). * Un glosario inicial del proyecto (opcionalmente puede ser expresado como modelo de dominio). * Un caso inicial de negocio, que incluye contexto del negocio, los criterios del xito

(proyeccin del rdito, reconocimiento del mercado, etctera), y pronstico financiero. * Una estimacin de riesgo inicial. * Un plan de proyecto, demostrando fases e iteraciones. * Un modelo de negocio, en caso de necesidad. * Uno o ms prototipos. 1er. Hito: Objetivos del Ciclo de vida Los objetivos del ciclo de vida en el final de la fase del inicio son el primer hito principal del proyecto: el hito de los objetivos del ciclo de vida. Los criterios de la evaluacin para la fase del inicio son: * Participacin de los involucrados en la definicin del alcance y estimaciones de costo y tiempos. * Entendimiento de los requerimientos segn la fidelidad de los casos de uso primarios. * Estimaciones de costos/tiempos, de las prioridades, de los riesgos, y del proceso del desarrollo crebles. * Cobertura de cualquier prototipo arquitectnico que se desarroll. * Gastos reales contra gastos planeados. El proyecto puede ser cancelado o ser repensado considerablemente si no puede pasar este hito. Fase de elaboracin El propsito de la fase de elaboracin es analizar el dominio del problema, establecer una fundacin arquitectnica sana, desarrollar el plan del proyecto, y eliminar los elementos del riesgo ms alto del proyecto. Para lograr estos objetivos, usted debe tener una vision completa del sistema. Las decisiones arquitectnicas tienen que tomarse con una comprensin cabal del sistema: su alcance, funcionalidad importante y requerimientos no funcionales tales como requerimientos de performance. Es fcil argumentar que la fase de elaboracin es la ms crtica de las cuatro fases. En el final de esta fase, la ingeniera dura se considera completa y el proyecto experimenta su da ms importante: la decisin sobre si o no confiar en las fases de la construccin y de la transicin. Para la mayora de los proyectos, esto tambin corresponde a la transicin de una fase de operatoria mvil, ligera y gil, poco arriesgada, a una de alto-costo, riesgo elevado con una inercia substancial. Mientras que el proceso siempre debe acomodarse a los cambios, las actividades de la fase de elaboracin aseguran que la arquitectura, los requerimientos y los planes sean bastante estables, y que los riesgos se atenan lo suficiente, as usted puede determinar el costo y fecha de terminacin del desarrollo en forma bastante certera. Durante fase de elaboracin, se construye un prototipo ejecutable de la arquitectura en unas o ms iteraciones, dependiendo del alcance, del tamao, del riesgo, y de la novedad del proyecto. Este prototipo debe tratar por lo menos los casos de uso mas crticos identificados en la fase del inicio, que exponen tpicamente los mayores riesgos tcnicos del proyecto.

Mientras que un prototipo evolutivo de un componente de calidad es siempre la meta, no excluye el desarrollo de unos o ms prototipos exploratorios, desechables, para atenuar riesgos especficos. Resultado de la Fase de Elaboracin El resultado de la fase de elaboracin es: * Un modelo de caso de uso (por lo menos 80% completo) - todos los casos de uso y actores deben haber sido identificados-, y se han desarrollado la mayora de las descripciones de casos de uso. * Requerimientos suplementarios que capturan los requerimientos no funcionales o cualquier requerimiento que no se asocie a un caso de uso especfico. * Una descripcin de la arquitectura del software. * Un prototipo arquitectnico ejecutable. * Una lista revisada del riesgo y un caso de negocio revisado. * Un plan de desarrollo para el proyecto total, incluyendo el plan de grano grueso del proyecto, demostrando iteraciones y los criterios de la evaluacin para cada iteracin. * Un caso actualizado del desarrollo que especifica el proceso que se utilizar. * Un manual preliminar del usuario (opcional). 2do. Hito: La arquitectura del ciclo de vida La arquitectura del ciclo de vida en el final de la fase de elaboracin es el segundo hito importante del proyecto. En este punto, se examinan los objetivos y el alcance detallado del sistema, la opcin de la arquitectura, y la resolucin de los riesgos principales. Los criterios principales de la evaluacin para la fase de elaboracin implican las respuestas a estas preguntas: * Que tan estable es la visin del producto? * La arquitectura es estable? * La demostracin ejecutable muestra que se han tratado y resuelto los rincipales elementos de riesgo? * El plan para la fase de la construccin esta suficientemente detallado? * Se cuenta con una base creble de estimaciones? * Todos los involucrados en el proyecto estn de acuerdo en que la visin actual se puede alcanzar si el plan actual se ejecuta para desarrollar el sistema completo, en el contexto de la arquitectura actual? * La diferencia entre los gastos reales y previstos es aceptable? El proyecto puede ser abortado o ser repensado considerablemente si no puede pasar este hito. La fase de la construccin

Durante la fase de la construccin, todos los componentes y caractersticas restantes se desarrollan , se integran en el producto, y se prueban a fondo. La fase de la construccin es, en cierto sentido, un proceso de fabricacin donde el nfasis se pone en manejar los recursos y controlar las operaciones para optimizar costos, tiempos y calidad. Una arquitectura robusta y un plan comprensible estan ntimamente relacionados. Es decir, una de las cualidades crticas de la arquitectura es su facilidad de la construccin. sta es una razn por la que durante la fase de elaboracin.se pone el enfasis en el desarrollo equilibrado de la arquitectura y del plan. El resultado de la fase de la construccin: El resultado de esta fase es un producto listo para poner en las manos de los usuarios finales. Como mnimo, consta de: * El producto de software integrado en las plataformas adecuadas. * Los manuales del usuario. * Una descripcin del la versin o release actual. 3er. Hito: La capacidad operacional inicial El final de la fase de construccin es el tercer hito principal del proyecto En este punto, se decide si el software, los sitios, y los usuarios estn operativos, sin exponer el proyecto a demasiados riesgos. Este lanzamiento a menudo se llama un lanzamiento beta. Los criterios de la evaluacin para la fase de la construccin implican el contestar de estas preguntas: * Esta versin es lo suficientemente estable y madura para entregar al usuario? * Todos los involucrados estn listos para la transicin del producto a produccin ? * La diferencia entre los gastos reales versus los planeados es an aceptable? La transicin puede tener que ser pospuesta si el proyecto no puede alcanzar este hito. Fase de la transicin El propsito de la fase de la transicin es justamente la transicin del producto de software al ambiente de produccin . Una vez que el producto se haya entregado al usuario final, surgen algunos temas que llevan al desarrollo de nuevas versiones, a corregir errores, o a terminar algunas caractersticas que haban sido pospuestas. Se ingresa a esta fase cuando el producto est lo suficientemente maduro para comenzar a pasar a produccin . Esto requiere que un cierto subconjunto del sistema se encuentre en un nivel aceptable de la calidad y que la documentacin del usuario est disponible de modo que la transicin proporcione resultados positivos para todas las partes. Esto incluye: * La prueba beta para validar el nuevo sistema contra las expectativas del usuario * Operacin en paralelo con un sistema anterior que el nuevo sistema est sustituyendo

* La conversin de las bases de datos operacionales * Entrenamientos y capacitacin de los usuarios y la gente de mantenimiento * Lanzar el producto a los equipos de marketing, distribucin y ventas La fase de transicin se centra en las actividades requeridas para poner el software en manos de los usuarios. Tpicamente, esta fase incluye varias iteraciones, incluyendo lanzamientos beta, lanzamientos de disponibilidad general, as como la reparacin de errores y el lanzamiento de versiones mejoradas. Un esfuerzo considerable se realiza en la documentacin orientada al usuario final, en entrenar a los mismos, en brindar apoyo en las primeras etapas del uso, y en reaccionar al feedback que generen los mismos usuarios. En este punto del ciclo de vida, sin embargo, el feedback del usuario se debe centrar sobre todo en el ajuste fino del producto, la configuracin , instalacin, y a las cuestiones de usabilidad. Esta fase puede variar -segn el proyecto- de ser muy simple a muy compleja. Por ejemplo una nueva versin de un procesador de texto puede ser muy simple, mientras que substituir el sistema de control de trfico areo de un pas sera muy complejo. 4to. Hito: Lanzamiento del Producto En este, se decide si los objetivos fueron alcanzados, y si se comienza otro ciclo de desarrollo. En algunos casos, este hito puede coincidir con el final de la fase del inicio para el ciclo siguiente. Los criterios primarios de la evaluacin para la fase de la transicin implica las respuestas a estas preguntas: * El usuario est satisfecho? * Los gastos reales versus los planeados son aun aceptables? Iteraciones Cada fase de RUP puede descomponerse en una o ms iteraciones. Una iteracin es un ciclo completo de desarrollo que resulta en una versin o release (interno o externo) de un producto ejecutable, un subconjunto del producto final que se encuentra bajo desarrollo y que crece incrementalmente en cada iteracin hasta llegar al producto final. Beneficios del enfoque iterativo El proceso iterativo tienen las ventajas siguientes: * Los riesgos son mitigados en forma temprana * Los cambios son ms manejables * Alto nivel de reusabilidad * El equipo de desarrollo puede aprender durante el proceso * Mejor calidad global