Proceso racional unificado - Rational Unified Process

Desarrollo de software
Actividades centrales Actividades principales
Paradigmas y modelos
Metodologías y marcos
Disciplinas de apoyo
Practicas
Instrumentos
Estándares y cuerpos de conocimiento
Glosarios
Contornos

El Rational Unified Process ( 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 proceso prescriptivo concreto único, sino más bien un marco de proceso adaptable , destinado a ser adaptado por el organizaciones de desarrollo y 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 .

Historia

Rational Software desarrolló originalmente el proceso unificado racional como un producto de proceso de software. El producto incluye una base de conocimientos 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, tuvo la tarea de dirigir el equipo original de RUP.

Estas versiones iniciales combinaron la amplia experiencia de campo de la organización de Rational Software en la construcción de sistemas orientados a objetos (al que el personal de campo de Rational se refiere como el Enfoque racional) con la guía de Objectory sobre prácticas tales como casos de uso, e incorporaron un extenso contenido de la Tecnología de modelado de objetos de Jim Rumbaugh (OMT). ) enfoque al modelado, el método Booch de Grady Booch y el recientemente lanzado UML 0.8.

Para ayudar a que esta creciente base de conocimientos sea más accesible, a Philippe Kruchten se le encomendó la tarea de ensamblar un marco de proceso 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 "Rational Unified Process" (RUP) resultante completó un trípode estratégico para Rational:

  • un proceso adaptable que guió el desarrollo
  • herramientas que automatizaron la aplicación de ese proceso
  • servicios que aceleraron la adopción tanto del proceso como de las herramientas.

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

En 1997, se agregaron requisitos y una disciplina de prueba al enfoque, gran parte del material adicional procedente del método de Requirements College desarrollado por Dean Leffingwell et al. en Requisite, Inc., y el método de proceso SQA desarrollado en SQA Inc., ambas compañías han sido 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 de Objectory
  2. una disciplina de Gestión de la Configuración y el Cambio, obtenida a través 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. Desarrolle de forma iterativa, con el riesgo como principal impulsor de la iteración
  2. Gestionar requisitos
  3. Emplear una arquitectura basada en componentes
  4. Modele el software visualmente
  5. Verificar continuamente la calidad
  6. Control de cambios

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 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 y las actualizaciones de software en tiempo real para reflejar UML 1.3. Además, en 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 una guía de la experiencia de campo de Rational en curso con desarrollo iterativo, además del soporte de herramientas para promulgar instancias de RUP y para la personalización del marco de RUP. Estos cambios incluyeron:

  1. la introducción de conceptos y técnicas a partir de enfoques como eXtreme Programming (XP), que más tarde se conocerían colectivamente como métodos ágiles. Esto incluyó técnicas como la programación de pares, el diseño de prueba primero y artículos que explicaban cómo RUP permitió que XP escale para su uso en proyectos más grandes.
  2. una revisión completa de la disciplina de prueba para reflejar mejor cómo se realizó el trabajo de prueba en diferentes contextos de desarrollo iterativo.
  3. la introducción de guías de apoyo, conocidas como "mentores de herramientas", para implementar las prácticas de RUP en varias herramientas. Básicamente, estos proporcionaron soporte de método paso a paso a los usuarios de la herramienta Rational.
  4. automatizar la personalización de RUP de una manera que permita a los clientes seleccionar partes del marco del proceso de RUP, personalizar su selección con sus propias adiciones y aún incorporar mejoras en versiones posteriores de Rational.

IBM adquirió Rational Software en febrero de 2003.

En 2006, IBM creó un subconjunto de RUP adaptado para la entrega de proyectos ágiles , lanzado como un método de código abierto llamado OpenUP a través del sitio web de Eclipse .

Temas de procesos unificados racionales

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 va a 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:

  • Roles (quién): un rol define un conjunto de habilidades, competencias y responsabilidades relacionadas.
  • Productos de trabajo (qué): un producto de trabajo representa algo que resulta de una tarea, incluidos todos los documentos y modelos producidos mientras se trabaja en el proceso.
  • Tareas (cómo): una tarea describe una unidad de trabajo asignada a un rol que proporciona un resultado significativo.

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

Cuatro fases del ciclo de vida del proyecto

Fases y disciplinas de 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 una manera similar a cómo se podría presentar un proyecto con estilo de '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á cumpliendo. 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 comienzo

El objetivo principal es establecer el alcance del sistema de manera adecuada 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 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 de riesgo inicial y una descripción del proyecto (los requisitos básicos del proyecto, las limitaciones y las características clave). Una vez completados, el proyecto se verifica con los siguientes criterios:

  • Concordancia de las partes interesadas sobre la definición del alcance y las estimaciones de costos / cronogramas.
  • Comprensión de los requisitos como lo demuestra la fidelidad de los casos de uso primarios.
  • Credibilidad de las estimaciones de costos / cronogramas, prioridades, riesgos y proceso de desarrollo.
  • Profundidad y amplitud de cualquier prototipo arquitectónico desarrollado.
  • Establecer una línea de base para comparar los gastos reales con los gastos planificados.

Si el proyecto no supera este hito, llamado hito del objetivo del ciclo de vida, puede cancelarse o repetirse después de ser rediseñado 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:

  • Un modelo de casos de uso en el que se han identificado los casos de uso y los actores y se desarrollan la mayoría de las descripciones de los casos de uso. El modelo de caso de uso debe estar completo en un 80%.
  • Una descripción de la arquitectura del software en un proceso de desarrollo de un sistema de software.
  • Una arquitectura ejecutable que realiza casos de uso arquitectónicamente significativos.
  • Caso de negocio y lista de riesgos que se revisan.
  • Un plan de desarrollo para el proyecto general.
  • Prototipos que mitigan de forma demostrable cada riesgo técnico identificado.
  • Un manual de usuario preliminar (opcional)

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

  • ¿Es estable la visión del producto?
  • ¿Es estable la arquitectura?
  • ¿La demostración ejecutable indica que se abordan y resuelven los principales elementos de riesgo?
  • ¿El plan de la fase de construcción es lo suficientemente detallado y preciso?
  • ¿Están todas las partes interesadas 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 frente al planeado?

Si el proyecto no puede superar este hito, todavía hay tiempo para cancelarlo o rediseñarlo. Sin embargo, después de salir de esta fase, el proyecto pasa a una operación de alto riesgo donde 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 tiene lugar 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 comprendido por el usuario final. Las actividades de esta fase incluyen la formación de los usuarios finales y los encargados del mantenimiento y la prueba beta del sistema para validarlo frente a las expectativas de los usuarios finales. 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 verifica 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 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 denominado IBM Rational Certified Specialist - Rational Unified Process . El nuevo examen no solo evaluará los conocimientos relacionados con el contenido de RUP, sino también los elementos de la estructura del proceso.

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

Seis mejores prácticas

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

Desarrollar iterativamente
Es mejor conocer todos los requisitos de antemano; sin embargo, a menudo este no es el caso. Existen varios procesos de desarrollo de software que se ocupan de brindar soluciones para minimizar el costo en términos de fases de desarrollo.
Gestionar requisitos
Tenga siempre en cuenta los requisitos establecidos por los usuarios.
Utilizar componentes
Desglosar un proyecto avanzado no solo es una sugerencia sino que, de hecho, es inevitable. Esto promueve la capacidad de probar componentes individuales antes de que se integren en un sistema más grande. Además, la reutilización de código es una gran ventaja y se puede lograr más fácilmente mediante el uso de programación orientada a objetos .
Modelar visualmente
Utilice diagramas para representar todos los componentes principales, los usuarios y su interacción. "UML", abreviatura de Unified Modeling Language , es una herramienta que se puede utilizar para hacer más factible esta tarea.
Verificar la calidad
Haga siempre de las pruebas una parte importante del proyecto en cualquier momento. Las pruebas se vuelven más pesadas a medida que avanza el proyecto, pero deberían ser un factor constante en la creación de cualquier producto de software.
Control de cambios
Muchos proyectos son creados por muchos equipos, a veces en varias ubicaciones, se pueden usar diferentes plataformas, etc. Como resultado, es esencial asegurarse de que los cambios realizados en un sistema estén sincronizados y verificados constantemente. (Ver Integración continua ).

Ver también

Referencias

Otras lecturas

  • Ivar Jacobson , Grady Booch y James Rumbaugh (1999). El proceso de desarrollo de software unificado
  • Gary Pollice , Liz Augustine , Chris Lowe y Jas Madhur (2003). Desarrollo de software para equipos pequeños: un enfoque centrado en RUP
  • Per Kroll, Philippe Kruchten (2003). Rational Unified Process Made Easy, The: Una guía para profesionales de RUP
  • Por Kroll, Bruce Mac Isaac (2006). Agilidad y disciplina simplificadas: prácticas de OpenUP y RUP
  • Philippe Kruchten (1998). El proceso unificado racional: una introducción
  • Ahmad Shuja, Jochen Krebs (2007). Guía de certificación y referencia de RUP
  • Walker Royce, gestión de proyectos de software, un marco unificado

enlaces externos