El proceso unificado racional ( RUP ) es un marco de proceso iterativo de desarrollo de software creado por Rational Software Corporation, una división de IBM desde 2003. [1] RUP no es un único proceso prescriptivo concreto, sino más bien un marco de proceso adaptable , destinado a ser adaptado por las organizaciones de desarrollo y los equipos de proyectos de software que seleccionarán los elementos del proceso que sean apropiados para sus necesidades. RUP es una implementación específica del Proceso Unificado .
Rational Software desarrolló originalmente el proceso unificado racional como un producto de proceso de software. El producto incluye una base de conocimiento con hipervínculos con artefactos de muestra y descripciones detalladas para muchos tipos diferentes de actividades. RUP está incluido en el producto IBM Rational Method Composer (RMC), que permite la personalización del proceso.
Philippe Kruchten , un experimentado representante técnico de Rational, fue el encargado de dirigir el equipo RUP original.
Estas versiones iniciales combinaron la amplia experiencia de campo de la organización Rational Software en la creación de sistemas orientados a objetos (a la que el personal de campo de Rational se refiere como el Enfoque Racional) con la orientación de Objectory sobre prácticas tales como casos de uso, e incorporaron un amplio contenido del enfoque de modelado de la Tecnología de Modelado de Objetos (OMT) de Jim Rumbaugh, el método Booch de Grady Booch y el recientemente lanzado UML 0.8. [2] [3]
Para facilitar el acceso a esta creciente base de conocimientos, se encargó a Philippe Kruchten la creación de un marco de trabajo de procesos explícito para la ingeniería de software moderna. En este esfuerzo se empleó el mecanismo de entrega de procesos basado en HTML desarrollado por Objectory. El "Proceso Unificado Racional" (RUP) resultante completó un trípode estratégico para Rational:
Esta guía se complementó en versiones posteriores con conocimientos basados en la experiencia de las empresas que Rational había adquirido.
En 1997, se agregó al enfoque una disciplina de requisitos y pruebas; gran parte del material adicional provenía del método Requirements College desarrollado por Dean Leffingwell et al. en Requisite, Inc., y del método SQA Process desarrollado en SQA Inc., ambas compañías habían sido adquiridas por Rational Software.
En 1998 Rational Software añadió dos nuevas disciplinas:
Estas incorporaciones dan lugar a un conjunto general de principios que fueron definidos por Rational y articulados dentro de RUP como las seis mejores prácticas para la ingeniería de software moderna:
Estas mejores prácticas estaban estrechamente alineadas con la línea de productos de Rational, y ambas impulsaron el desarrollo continuo de los productos de Rational, además de ser utilizadas por los equipos de campo de Rational para ayudar a los clientes a mejorar la calidad y la previsibilidad de sus esfuerzos de desarrollo de software.
Se incluyeron técnicas adicionales que incluyen pruebas de rendimiento, diseño de UI, ingeniería de datos y una actualización para reflejar los cambios en UML 1.1.
En 1999 se introdujo una disciplina de gestión de proyectos, así como técnicas para respaldar el desarrollo de software en tiempo real y actualizaciones para reflejar UML 1.3. Además, el primer libro que describe el proceso, The Unified Software Development Process ( ISBN 0-201-57169-2 ) de Ivar Jacobson , Grady Booch y James Rumbaugh , se publicó ese mismo año.
Entre 2000 y 2003, se introdujeron una serie de cambios que aportaron orientación a partir de la experiencia de campo de Rational en desarrollo iterativo, además de soporte de herramientas para implementar instancias de RUP y personalizar el marco de trabajo de RUP. Estos cambios incluyeron:
IBM adquirió Rational Software en febrero de 2003.
En 2006, IBM creó un subconjunto de RUP diseñado para la entrega de proyectos Agile , publicado como un método de código abierto llamado OpenUP a través del sitio web Eclipse . [5]
El RUP se basa en un conjunto de bloques de construcción y elementos de contenido que describen lo que se debe producir, las habilidades necesarias requeridas y la explicación paso a paso de cómo se deben lograr los objetivos de desarrollo específicos. Los principales bloques de construcción o elementos de contenido son los siguientes:
Dentro de cada iteración, las tareas se clasifican en nueve disciplinas:
El RUP ha determinado un ciclo de vida del proyecto que consta de cuatro fases. Estas fases permiten presentar el proceso a un alto nivel de manera similar a cómo se podría presentar un proyecto en "cascada", aunque en esencia la clave del proceso reside en las iteraciones de desarrollo que se dan en todas las fases. Además, cada fase tiene un objetivo clave y un hito al final que denota el objetivo que se está cumpliendo. La visualización de las fases y disciplinas del RUP a lo largo del tiempo se conoce como el diagrama de joroba del RUP .
El objetivo principal es definir adecuadamente el alcance del sistema como base para validar los costos y presupuestos iniciales. En esta fase se establece el caso de negocio que incluye el contexto empresarial, los factores de éxito (ingresos esperados, reconocimiento en el mercado, etc.) y la previsión financiera. Para complementar el caso de negocio, se genera un modelo de caso de uso básico, un plan de proyecto, una evaluación inicial de riesgos y una descripción del proyecto (los requisitos básicos del proyecto, las limitaciones y las características clave). Una vez completados estos, el proyecto se verifica con los siguientes criterios:
Si el proyecto no supera este hito, llamado hito objetivo del ciclo de vida, puede cancelarse o repetirse después de rediseñarse para cumplir mejor con los criterios.
El objetivo principal es mitigar los elementos de riesgo clave identificados mediante el análisis hasta el final de esta fase. La fase de elaboración es donde el proyecto comienza a tomar forma. En esta fase se realiza el análisis del dominio del problema y la arquitectura del proyecto adquiere su forma básica.
El resultado de la fase de elaboración es:
Esta fase debe superar los criterios de hitos de arquitectura del ciclo de vida respondiendo las siguientes preguntas:
Si el proyecto no logra superar este hito, aún hay tiempo para cancelarlo o rediseñarlo. Sin embargo, después de salir de esta fase, el proyecto pasa a ser una operación de alto riesgo donde los cambios son mucho más difíciles y perjudiciales cuando se realizan.
El dominio clave de análisis para la elaboración es la arquitectura del sistema.
El objetivo principal es construir el sistema de software. En esta fase, el enfoque principal se centra en el desarrollo de componentes y otras características del sistema. Esta es la fase en la que se lleva a cabo la mayor parte de la codificación. En proyectos más grandes, se pueden desarrollar varias iteraciones de construcción en un esfuerzo por dividir los casos de uso en segmentos manejables para producir prototipos demostrables.
El objetivo principal es "transitar" el sistema desde el desarrollo a la producción, poniéndolo a disposición del usuario final y haciéndolo comprensible para él. Las actividades de esta fase incluyen la capacitación de los usuarios finales y los encargados del mantenimiento, y la realización de pruebas beta del sistema para validarlo frente a las expectativas de los usuarios finales. El sistema también pasa por una fase de evaluación, en la que se reemplaza o elimina a cualquier desarrollador que no esté produciendo el trabajo requerido. El producto también se verifica en relación con el nivel de calidad establecido en la fase de inicio.
Si se cumplen todos los objetivos, se alcanza el hito de lanzamiento del producto y se finaliza el ciclo de desarrollo.
El producto IBM Rational Method Composer es una herramienta para crear, configurar, visualizar y publicar procesos. Consulte IBM Rational Method Composer y un proyecto de marco de procesos Eclipse (EPF) de versión de código abierto para obtener más detalles.
En enero de 2007 se publicó el nuevo examen de certificación RUP para IBM Certified Solution Designer - Rational Unified Process 7.0 , que reemplaza la versión anterior del curso llamado IBM Rational Certified Specialist - Rational Unified Process . [6] El nuevo examen no solo evaluará los conocimientos relacionados con el contenido de RUP, sino también con los elementos de la estructura del proceso. [7]
Para aprobar el nuevo examen de certificación RUP, una persona debe realizar el examen IBM Test 839: Rational Unified Process v7.0 . Tiene 75 minutos para realizar el examen de 52 preguntas. La puntuación para aprobar es del 62 %. [8]
Se definen seis prácticas recomendadas de ingeniería de software para proyectos de software con el fin de minimizar fallas y aumentar la productividad. Estas son: [9] [10]