El Rational Unified Process o Proceso Unificado de Rational Inc es una implementación comercial del Proceso Unificado. Es un proceso de ingeniería de software que provee un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción 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 específica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguage, la misma visión y el mismo proceso acerca de cómo desarrollar software.
Fases de RUP
Sobre modelos
Las actividades de RUP se centran en crear y mantener modelos, utilizando UML, Lenguaje de Modelización 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 pequeños de desarrollo como a grandes organizaciones. Basándose en lo que se consideran best practices, las mejores prácticas de desarrollo de software, RUP resulta apropiado para un amplia gama de proyectos y organizaciones.
Las 6 mejores prácticas de desarrollo que aplica RUP
* Desarrollo de software en forma iterativa
* Gestión de requerimientos
* Uso de arquitecturas basadas en componentes
* Modelización visual del software
* Verificación 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, diseñarlo en su totalidad, construirlo y testearlo. El enfoque iterativo permite ir creciendo en el entendimiento del problema.a través de refinamientos sucesivos. Esto también permite introducir cambios tácticos en los requerimientos, características del sistema o en los tiempos.
2. Gestión 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 diseño, la implementación y el testeo de software; haciendo más 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 módulos no triviales, subsistemas que satisfacen una función definida. RUP proporciona un acercamiento sistemático definiendo una arquitectura usando componentes nuevos y existentes. Éstos están 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. Modelización visual del software
El proceso le demuestra cómo 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 código usando “bloques de construcción gráficos.” Las abstracciones visuales le ayudan a comunicar diversos aspectos del software, ayudan a mantener la consistencia entre un diseño y su puesta en marcha; y favorecen la comunicación inequívoca. El UML es la base de esta modelización visual.
5. Verificación de calidad del software
Una performance y una confiabilidad pobres son los factores comunes que inhiben dramáticamente la aceptabilidad de los usos del software hoy en día. Por lo tanto, la calidad se debe revisar con respecto a los requerimientos basados en la confiabilidad, funcionalidad, performance de la aplicación y del sistema. RUP le asiste en el planeamiento, el diseño, la puesta en marcha, la ejecución, y la evaluación 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 - asegurándose 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 cómo controlar, seguir y supervisar cambios para permitir el desarrollo iterativo acertado. También guía sobre cómo 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, código, documentos, etc.). Describiendo cómo automatizar la integración, hace que el equipo trabaje como una sola unidad.
RUP: Visión del proceso en 2 dimensiones
El proceso se puede describir en dos dimensiones:
* El eje horizontal representa tiempo y demuestra el aspecto dinámico del proceso, se expresa en términos de ciclos, de fases, de iteraciones, y de hitos o milestones.
* El eje vertical representa el aspecto estático del proceso: cómo se describe en términos 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 generación del producto. El RUP divide un ciclo de desarrollo en cuatro fases consecutivas.
* Fase de inicio
* Fase de elaboración
* Fase de construcción
* Fase de transición
Cada fase constituye un eslabón bien definido, un punto en el tiempo en el cual ciertas decisiones críticas 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 interactúe (los actores) y definir la naturaleza de esta interacción a un nivel alto. Esto implica identificar todos los casos de uso y describir sólo los más significativos. El caso de negocio incluye criterios de éxito, la evaluación de riesgos, y la estimación 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 visión: una visión general de los requerimientos básicos del proyecto, de las características 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 (proyección del rédito, reconocimiento del mercado, etcétera), y pronóstico financiero.
* Una estimación de riesgo inicial.
* Un plan de proyecto, demostrando fases e iteraciones.
* Un modelo de negocio, en caso de necesidad.
* Uno o más 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 evaluación para la fase del inicio son:
* Participación de los involucrados en la definición del alcance y estimaciones de costo y tiempos.
* Entendimiento de los requerimientos según la fidelidad de los casos de uso primarios.
* Estimaciones de costos/tiempos, de las prioridades, de los riesgos, y del proceso del desarrollo creíbles.
* Cobertura de cualquier prototipo arquitectónico 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 elaboración
El propósito de la fase de elaboración es analizar el dominio del problema, establecer una fundación arquitectónica sana, desarrollar el plan del proyecto, y eliminar los elementos del riesgo más alto del proyecto. Para lograr estos objetivos, usted debe tener una vision completa del sistema. Las decisiones arquitectónicas tienen que tomarse con una comprensión cabal del sistema: su alcance, funcionalidad importante y requerimientos no funcionales tales como requerimientos de performance.
Es fácil argumentar que la fase de elaboración es la más crítica de las cuatro fases. En el final de esta fase, la “ingeniería dura” se considera completa y el proyecto experimenta su día más importante: la decisión sobre si o no confiar en las fases de la construcción y de la transición. Para la mayoría de los proyectos, esto también corresponde a la transición de una fase de operatoria móvil, 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 elaboración aseguran que la arquitectura, los requerimientos y los planes sean bastante estables, y que los riesgos se atenúan lo suficiente, así usted puede determinar el costo y fecha de terminación del desarrollo en forma bastante certera.
Durante fase de elaboración, se construye un prototipo ejecutable de la arquitectura en unas o más iteraciones, dependiendo del alcance, del tamaño, del riesgo, y de la novedad del proyecto. Este prototipo debe tratar por lo menos los casos de uso mas críticos identificados en la fase del inicio, que exponen típicamente los mayores riesgos técnicos del proyecto. Mientras que un prototipo evolutivo de un componente de calidad es siempre la meta, no excluye el desarrollo de unos o más prototipos exploratorios, desechables, para atenuar riesgos específicos.
Resultado de la Fase de Elaboración
El resultado de la fase de elaboración 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 mayoría 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 específico.
* Una descripción de la arquitectura del software.
* Un prototipo arquitectónico 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 evaluación para cada iteración.
* 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 elaboración es el segundo hito importante del proyecto. En este punto, se examinan los objetivos y el alcance detallado del sistema, la opción de la arquitectura, y la resolución de los riesgos principales. Los criterios principales de la evaluación para la fase de elaboración implican las respuestas a estas preguntas:
* ¿Que tan estable es la visión del producto?
* ¿La arquitectura es estable?
* ¿La demostración ejecutable muestra que se han tratado y resuelto los rincipales elementos de riesgo?
* ¿El plan para la fase de la construcción esta suficientemente detallado?
* ¿Se cuenta con una base creíble de estimaciones?
* ¿Todos los involucrados en el proyecto están de acuerdo en que la visión 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 construcción
Durante la fase de la construcción, todos los componentes y características restantes se desarrollan , se integran en el producto, y se prueban a fondo. La fase de la construcción es, en cierto sentido, un proceso de fabricación 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 críticas de la arquitectura es su facilidad de la construcción. Ésta es una razón por la que durante la fase de elaboración.se pone el enfasis en el desarrollo equilibrado de la arquitectura y del plan.
El resultado de la fase de la construcción:
El resultado de esta fase es un producto listo para poner en las manos de los usuarios finales. Como mínimo, consta de:
* El producto de software integrado en las plataformas adecuadas.
* Los manuales del usuario.
* Una descripción del la versión o release actual.
3er. Hito: La capacidad operacional inicial
El final de la fase de construcción es el tercer hito principal del proyecto En este punto, se decide si el software, los sitios, y los usuarios están operativos, sin exponer el proyecto a demasiados riesgos. Este lanzamiento a menudo se llama un lanzamiento “beta”. Los criterios de la evaluación para la fase de la construcción implican el contestar de estas preguntas:
* ¿Esta versión es lo suficientemente estable y madura para entregar al usuario?
* ¿Todos los involucrados están listos para la transición del producto a producción ?
* ¿La diferencia entre los gastos reales versus los planeados es aún aceptable?
La transición puede tener que ser pospuesta si el proyecto no puede alcanzar este hito.
Fase de la transición
El propósito de la fase de la transición es justamente la transición del producto de software al ambiente de producción . 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 características que habían sido pospuestas.
Se ingresa a esta fase cuando el producto está lo suficientemente maduro para comenzar a pasar a producción . Esto requiere que un cierto subconjunto del sistema se encuentre en un nivel aceptable de la calidad y que la documentación del usuario está disponible de modo que la transición proporcione resultados positivos para todas las partes. Esto incluye:
* La “prueba beta” para validar el nuevo sistema contra las expectativas del usuario
* Operación en paralelo con un sistema anterior que el nuevo sistema esté sustituyendo
* La conversión de las bases de datos operacionales
* Entrenamientos y capacitación de los usuarios y la gente de mantenimiento
* Lanzar el producto a los equipos de marketing, distribución y ventas
La fase de transición se centra en las actividades requeridas para poner el software en manos de los usuarios. Típicamente, esta fase incluye varias iteraciones, incluyendo lanzamientos beta, lanzamientos de disponibilidad general, así como la reparación de errores y el lanzamiento de versiones mejoradas. Un esfuerzo considerable se realiza en la documentación 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 configuración , instalación, y a las cuestiones de usabilidad.
Esta fase puede variar -según el proyecto- de ser muy simple a muy compleja. Por ejemplo una nueva versión de un procesador de texto puede ser muy simple, mientras que substituir el sistema de control de tráfico aéreo de un país sería 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 evaluación para la fase de la transición 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 más iteraciones. Una iteración es un ciclo completo de desarrollo que resulta en una versión 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 iteración 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 más manejables
* Alto nivel de reusabilidad
* El equipo de desarrollo puede aprender durante el proceso
* Mejor calidad global
