Proceso racional unificado

El proceso unificado racional (RUP) es un marco de proceso de desarrollo de software iterativo creado por Rational Software Corporation, una división de IBM desde 2003. 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 proyecto 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.

Historia

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 representante técnico experimentado de Rational, recibió la tarea de encabezar el equipo RUP original.

Estas versiones iniciales combinaron la amplia experiencia de campo de la organización de Rational Software en la creación de sistemas orientados a objetos (referidos por el personal de campo de Rational como el Enfoque Racional) con la orientación de Objectory sobre prácticas tales como casos de uso y incorporó contenido extenso 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 UML 0.8 recientemente lanzado.

Para ayudar a que esta creciente base de conocimientos sea más accesible, Philippe Kruchten recibió la tarea de ensamblar un marco de procesos explícito para la ingeniería de software moderna. Este esfuerzo empleó el mecanismo de entrega de procesos basado en HTML desarrollado por Objectory. El "Proceso unificado racional" resultante (RUP) completó un trípode estratégico para Rational:

• a proceso adaptable que guiaron el desarrollo
• herramientas que automatiza la aplicación de ese proceso
• servicios que aceleró la adopción del proceso y de los instrumentos.

Esta guía se amplió en versiones posteriores con conocimientos basados en la experiencia de empresas que Rational había adquirido.

En 1997, se agregaron requisitos y disciplina de prueba al enfoque, gran parte del material adicional se obtuvo del método de la Universidad de requisitos desarrollado por Dean Leffingwell et al. en Requisite, Inc., y el método SQA Process desarrollado en SQA Inc., ambas compañías fueron adquiridas por Rational Software.

En 1998, Rational Software agregó dos nuevas disciplinas:

1. modelado de negocios, gran parte de este contenido ya había estado en el Proceso Objetivo
2. a Disciplina de configuración y gestión del cambio, fuente de la adquisición de Pure Atria Corporation.

Estas adiciones conducen 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:

1. Desarrollar iterativamente, con riesgo como el conductor primario de iteración
2. Necesidades de gestión
3. Emplear una arquitectura basada en componentes
4. Modelo de software visual
5. Verificación continua de calidad
6. Cambios de control

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 previsibilidad de sus esfuerzos de desarrollo de software.

Se incluyeron técnicas adicionales, incluidas pruebas de rendimiento, diseño de interfaz de usuario, 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 las actualizaciones para reflejar UML 1.3. Además, el mismo año se publicó el primer libro que describe el proceso, The Unified Software Development Process (ISBN 0-201-57169-2).

Entre 2000 y 2003, una serie de cambios introdujeron la guía de la experiencia de campo actual de Rational con el desarrollo iterativo, además del soporte de herramientas para promulgar instancias de RUP y para personalizar el marco de trabajo de RUP. Estos cambios incluyeron:

1. la introducción de conceptos y técnicas de enfoques tales como eXtreme Programming (XP), que más adelante serían conocidos colectivamente como métodos ágiles. Esto incluyó técnicas como la programación de pares, el diseño de prueba y papeles que explicaron cómo RUP permitió a XP escalar para su uso en proyectos más grandes.
2. a complete overhaul of the testing discipline to better reflect how testing work was conducted in different iterative development contexts.
3. la introducción de guías de apoyo - conocidos como " mentores de herramientas" - para promulgar las prácticas del RUP en varias herramientas. Estos esencialmente proporcionaron soporte de método paso a paso a los usuarios de herramientas Rational.
4. automatizar la personalización del RUP de una manera que permita a los clientes seleccionar partes del marco de proceso del RUP, personalizar su selección con sus propias adiciones, e incorporar mejoras en versiones posteriores de Rational.

IBM adquirió Rational Software en febrero de 2003.

En 2006, IBM creó un subconjunto de RUP diseñado para la entrega de proyectos Agile, lanzado como un método OpenSource llamado OpenUP a través del sitio web de Eclipse.

Temas de procesos unificados de Rational

Bloques de construcción RUP

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 que describe cómo se deben lograr los objetivos de desarrollo específicos. Los principales bloques de construcción, o elementos de contenido, son los siguientes:

• Funciones (quién) – Un papel define un conjunto de habilidades, competencias y responsabilidades relacionadas.
• Productos de trabajo (qué) – Un producto de trabajo representa algo resultante de una tarea, incluyendo todos los documentos y modelos producidos durante el proceso.
• Tareas (cómo) – Una tarea describe una unidad de trabajo asignada a un papel que proporciona un resultado significativo.

Dentro de cada iteración, las tareas se clasifican en nueve disciplinas:

• Seis "disciplinas de ingeniería"
  • Modelización de empresas
  • Necesidades
  • Análisis y diseño
  • Aplicación
  • Prueba
  • Despliegue
• Tres disciplinas de apoyo
  • Gestión de configuración y cambio
  • Gestión de proyectos
  • para el Medio Ambiente

Cuatro fases del ciclo de vida del proyecto

Fases y disciplinas del RUP.

El RUP ha determinado un ciclo de vida del proyecto que consta de cuatro fases. Estas fases permiten que el proceso se presente a un alto nivel de manera similar a cómo se podría presentar un proyecto de estilo 'cascada', aunque en esencia la clave del proceso radica en las iteraciones de desarrollo que se encuentran dentro de todas las fases. Además, cada fase tiene un objetivo clave y un hito al final que denota el objetivo que se está logrando. La visualización de las fases y disciplinas de RUP a lo largo del tiempo se denomina gráfico de joroba de RUP.

Fase de inicio

El objetivo principal es definir el alcance del sistema adecuadamente como base para validar los costos y presupuestos iniciales. En esta fase se establece el caso comercial que incluye el contexto comercial, los factores de éxito (ingresos esperados, reconocimiento del mercado, etc.) y el pronóstico financiero. Para complementar el caso de negocio, se generan 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 que se completan, el proyecto se verifica con los siguientes criterios:

• Stakeholder concurrence on scope definition and cost/schedule estimates.
• Requisitos entendidos como evidenciados por la fidelidad de los casos de uso primario.
• Credibilidad de las estimaciones de costos y horarios, prioridades, riesgos y proceso de desarrollo.
• Profundidad y amplitud de cualquier prototipo arquitectónico que se desarrolló.
• Establecer una base de referencia para comparar los gastos efectivos con los gastos previstos.

Si el proyecto no supera este hito, denominado hito del objetivo del ciclo de vida, puede cancelarse o repetirse después de rediseñarlo para cumplir mejor con los criterios.

Fase de elaboración

El objetivo principal es mitigar los elementos de riesgo clave identificados por 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:

• Se ha identificado un modelo de caso de uso en el que se han identificado los casos de utilización y los agentes y se han elaborado la mayoría de las descripciones de los casos de utilización. El modelo de caso de uso debe ser un 80% completo.
• Una descripción de la arquitectura del software en un proceso de desarrollo del sistema de software.
• Una arquitectura ejecutable que realiza casos de uso arquitectónicomente significativos.
• Casos comerciales y lista de riesgos que se revisan.
• Un plan de desarrollo para el proyecto general.
• Prototipos que mitiguen manifiestamente cada riesgo técnico identificado.
• Manual de usuario preliminar (opcional)

Esta fase debe pasar los criterios del hito de la arquitectura del ciclo de vida respondiendo a las siguientes preguntas:

• ¿La visión del producto es estable?
• ¿La arquitectura es estable?
• ¿La demostración ejecutable indica que se abordan y resuelven los principales elementos de riesgo?
• ¿El plan de fase de construcción es suficientemente detallado y preciso?
• ¿Todos los interesados están de acuerdo en que la visión actual se puede lograr utilizando el plan actual en el contexto de la arquitectura actual?
• ¿Es aceptable el gasto de recursos real vs. previsto?

Si el proyecto no puede pasar este hito, todavía 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 en la que los cambios son mucho más difíciles y perjudiciales cuando se realizan.

El análisis de dominio clave para la elaboración es la arquitectura del sistema.

Fase de construcción

El objetivo principal es construir el sistema de software. En esta fase, el enfoque principal está 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.

Fase de transición

El objetivo principal es 'transitar' el sistema desde el desarrollo hasta la producción, haciéndolo disponible y comprensible para el usuario final. Las actividades de esta fase incluyen la formación de los usuarios finales y mantenedores y la prueba beta del sistema para validarlo frente a los usuarios finales. Expectativas. El sistema también pasa por una fase de evaluación, cualquier desarrollador que no esté produciendo el trabajo requerido es reemplazado o eliminado. El producto también se compara 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 finaliza el ciclo de desarrollo.

El producto IBM Rational Method Composer

El producto IBM Rational Method Composer es una herramienta para crear, configurar, visualizar y publicar procesos. Consulte IBM Rational Method Composer y una versión de código abierto del proyecto Eclipse Process Framework (EPF) para obtener más detalles.

Certificación

En enero de 2007 se lanzó 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 . El nuevo examen no solo pondrá a prueba los conocimientos relacionados con el contenido de RUP, sino también con los elementos de la estructura del proceso.

Para aprobar el nuevo examen de certificación de RUP, una persona debe realizar el Test 839: Rational Unified Process v7.0 de IBM. Tiene 75 minutos para tomar el examen de 52 preguntas. El puntaje de aprobación es del 62%.

Seis mejores prácticas

Se definen seis mejores prácticas de ingeniería de software para proyectos de software a fin de minimizar fallas y aumentar la productividad. Estos son:

Desarrollar iterativamente

Es mejor conocer todos los requisitos por adelantado; sin embargo, a menudo este no es el caso. Existen varios procesos de desarrollo de software que tratan de ofrecer soluciones para reducir al mínimo el costo en las fases de desarrollo.

Necesidades de gestión

Tenga siempre en cuenta los requisitos establecidos por los usuarios.

Uso de componentes

Descomponer un proyecto avanzado no sólo es sugerido sino inevitable. Esto promueve la capacidad de probar componentes individuales antes de integrarse en un sistema más amplio. Además, la reutilización de código es un gran plus y se puede lograr más fácilmente mediante el uso de la programación orientada al objeto.

Modelo visual

Use diagramas para representar todos los componentes principales, usuarios y su interacción. "UML", corto para Unified Modeling Language, es una herramienta que se puede utilizar para hacer esta tarea más factible.

Verificar calidad

Siempre hacer pruebas una parte importante del proyecto en cualquier momento. La prueba se vuelve más pesada a medida que el proyecto progresa, pero debe ser un factor constante en cualquier creación de producto de software.

Cambios de control

Muchos proyectos son creados por muchos equipos, a veces en varios lugares, diferentes plataformas se pueden utilizar, etc. Como resultado, es esencial asegurarse de que los cambios realizados en un sistema se sincronizan y verifican constantemente. (Ver Integración continua).