Hispanopedia Wiki
Articulo de referencia

Proceso unificado racional

El Proceso Unificado de Rational ( RUP ) es un marco de proceso iterativo para el desarrollo de software creado por Rational Software Corporation, una división de IBM desde 2003...

Hispanopedia WikiContenido en espanolLectura gratuita

El Proceso Unificado de Rational ( RUP ) es un marco de proceso iterativo para el desarrollo de software creado por Rational Software Corporation, una división de IBM desde 2003. [ 1 ] RUP no es un proceso prescriptivo concreto único, sino más bien un marco de proceso adaptable , diseñado para ser personalizado 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 .

Historia

Rational Software desarrolló originalmente RUP como un producto de software para la gestión de procesos. Este producto incluye una base de conocimientos con hipervínculos, ejemplos de artefactos y descripciones detalladas para diversos tipos de actividades. RUP está integrado en Rational Method Composer (RMC), que permite personalizar el proceso.

Philippe Kruchten , un experimentado representante técnico de Rational, fue el encargado de dirigir el equipo original de RUP.

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 refería como el Enfoque Rational) con la guía de Objectory sobre prácticas como los casos de uso, e incorporaron un amplio contenido del enfoque de Tecnología de Modelado de Objetos (OMT) de Jim Rumbaugh para el modelado, el método Booch de Grady Booch y el recién 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 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 resultante "Proceso Unificado de Rational" (RUP) 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 complementó en versiones posteriores con conocimientos basados ​​en la experiencia de las empresas que Rational había adquirido.

En 1997, se añadió al enfoque una disciplina de requisitos y pruebas, gran parte del cual provino del método Requirements College desarrollado por Dean Leffingwell et al. en Requisite, Inc., y del método SQA Process desarrollado en SQA Inc., empresas que fueron adquiridas por Rational Software.

En 1998, Rational Software añadió dos nuevas disciplinas:

  1. modelado de negocios, gran parte de este contenido ya estaba en el proceso de Objectory
  2. una disciplina de Gestión de Configuración y Cambios, obtenida a través de la adquisición de Pure Atria Corporation.

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:

  1. Desarrollar de forma iterativa, con el riesgo como principal motor de la iteración [ 4 ].
  2. Gestionar los requisitos
  3. Emplee una arquitectura basada en componentes.
  4. Software de modelado visual
  5. Verificar continuamente la calidad
  6. Cambios de control

Estas buenas prácticas estaban estrechamente alineadas con la línea de productos de Rational, e impulsaban tanto el desarrollo continuo de los productos de Rational como su uso por parte de 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 como 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 apoyar 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 varios cambios que incorporaron directrices basadas en la experiencia práctica de Rational con el desarrollo iterativo, además de soporte de herramientas para la ejecución de instancias de RUP y para la personalización del marco de RUP. Estos cambios incluyeron:

  1. La introducción de conceptos y técnicas de enfoques como la Programación Extrema (XP), que más tarde se conocerían colectivamente como métodos ágiles. Esto incluía técnicas como la programación en parejas, el diseño basado en pruebas y artículos que explicaban cómo RUP permitía que XP se adaptara a proyectos de mayor envergadura.
  2. una revisión completa de la disciplina de pruebas para reflejar mejor cómo se realizaba el trabajo de pruebas en diferentes contextos de desarrollo iterativo.
  3. La introducción de guías de apoyo —conocidas como "mentores de herramientas"— para la implementación de las prácticas RUP en diversas herramientas. Estas guías proporcionaban, en esencia, apoyo metodológico paso a paso a los usuarios de las herramientas de Rational.
  4. Automatizar la personalización de RUP de forma que permita a los clientes seleccionar componentes del marco de procesos de 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 adaptado para la entrega de proyectos ágiles , publicado como un método de código abierto llamado OpenUP a través del sitio web de Eclipse . [ 5 ]

Temas del proceso unificado racional

bloques de construcción RUP

RUP se basa en un conjunto de bloques de construcción y elementos de contenido que describen qué se debe producir, las habilidades necesarias y la explicación paso a paso de cómo se deben alcanzar 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é son): Un producto de trabajo representa algo que resulta de una tarea, incluidos todos los documentos y modelos producidos durante el proceso.
  • Tareas (cómo): Una tarea describe una unidad de trabajo asignada a un rol que proporciona un resultado significativo.

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

Cuatro fases del ciclo de vida del proyecto

Fases y disciplinas del RUP.

El RUP ha definido un ciclo de vida del proyecto que consta de cuatro fases. Estas fases permiten presentar el proceso a un alto nivel, de forma similar a como se presentaría 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 indica que el objetivo se ha alcanzado. La visualización de las fases y disciplinas del RUP a lo largo del tiempo se denomina diagrama de joroba del RUP .

Fase inicial

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 de mercado, etc.) y la previsión financiera. Para complementar el caso de negocio, se generan un modelo básico de casos de uso, un plan de proyecto, una evaluación inicial de riesgos y una descripción del proyecto (los requisitos principales, las restricciones y las características clave). Una vez completados estos elementos, el proyecto se verifica según los siguientes criterios:

  • Consenso de las partes interesadas sobre la definición del alcance y las estimaciones de costes y plazos.
  • Comprensión de los requisitos, evidenciada por la fidelidad de los casos de uso principales.
  • Credibilidad de las estimaciones de costos/cronogramas, prioridades, riesgos y proceso de desarrollo.
  • Profundidad y amplitud de cualquier prototipo arquitectónico que se haya desarrollado.
  • Establecer una base de referencia para comparar los gastos reales con los gastos previstos.

Si el proyecto no supera este hito, denominado hito del objetivo del ciclo de vida, puede cancelarse o repetirse tras ser rediseñado para cumplir mejor con los criterios.

Fase de elaboración

El objetivo principal es mitigar los riesgos clave identificados en 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 se define la arquitectura básica del proyecto.

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 han desarrollado la mayoría de las descripciones de los casos de uso. El modelo de casos de uso debe estar completo en un 80 %.
  • Descripción de la arquitectura de software en un proceso de desarrollo de sistemas de software.
  • Una arquitectura ejecutable que materializa casos de uso arquitectónicamente significativos.
  • Estudio de viabilidad y lista de riesgos revisados.
  • Un plan de desarrollo para el proyecto en su conjunto.
  • Prototipos que mitigan de forma demostrable cada riesgo técnico identificado.
  • Manual de usuario preliminar (opcional)

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

  • ¿La visión del producto es estable?
  • ¿Es estable la arquitectura?
  • ¿Indica la demostración ejecutable que se han abordado y resuelto los principales elementos de riesgo?
  • ¿El plan de la fase de construcción es suficientemente detallado y preciso?
  • ¿Están de acuerdo todas las partes interesadas 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 en comparación con el planificado?

Si el proyecto no logra superar este hito, aún hay tiempo para cancelarlo o rediseñarlo. Sin embargo, una vez superada esta fase, el proyecto entra en una etapa de alto riesgo donde los cambios son mucho más difíciles y perjudiciales.

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 funcionalidades del sistema. Es en esta fase donde se realiza la mayor parte de la codificación. En proyectos de mayor envergadura, se pueden desarrollar varias iteraciones de construcción para dividir los casos de uso en segmentos manejables y así producir prototipos demostrables.

Fase de transición

El objetivo principal es llevar el sistema de la fase de desarrollo a la de producción, poniéndolo a disposición del usuario final para que lo comprenda. Las actividades de esta fase incluyen la capacitación de los usuarios finales y los responsables del mantenimiento, así como las pruebas beta del sistema para validarlo según las expectativas de los usuarios. El sistema también pasa por una fase de evaluación: cualquier desarrollador que no cumpla con los requisitos es reemplazado o eliminado. Además, el producto se verifica según el nivel de calidad establecido en la fase inicial.

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 el proyecto de marco de procesos de Eclipse (EPF) de código abierto para obtener más detalles.

Proceso de dar un título

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 denominada IBM Rational Certified Specialist - Rational Unified Process . [ 6 ] El nuevo examen no solo evaluará el conocimiento relacionado 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, es necesario realizar la prueba 839 de IBM: Rational Unified Process v7.0 . Se dispone de 75 minutos para completar las 52 preguntas del examen. La puntuación mínima para aprobar es del 62 %. [ 8 ]

Seis mejores prácticas

Se definen seis mejores prácticas de ingeniería de software para proyectos de software con el fin de minimizar fallos y aumentar la productividad. Estas son: [ 9 ] [ 10 ]

Desarrollar de forma iterativa
Lo ideal es conocer todos los requisitos con antelación; sin embargo, a menudo esto no es posible. Existen diversos procesos de desarrollo de software que ofrecen soluciones para minimizar los costos en las distintas fases de desarrollo.
Gestionar los requisitos
Ten siempre en cuenta los requisitos establecidos por los usuarios.
Utilizar componentes
Desglosar un proyecto avanzado no solo es recomendable, sino inevitable. Esto facilita la prueba de componentes individuales antes de integrarlos en un sistema mayor. Además, la reutilización de código es una gran ventaja y se logra con mayor facilidad mediante la programación orientada a objetos .
Modelado visual
Utilice diagramas para representar todos los componentes principales, los usuarios y su interacción. UML, siglas de Lenguaje Unificado de Modelado , es una herramienta que puede facilitar esta tarea.
Verificar la calidad
Las pruebas siempre deben ser una parte fundamental del proyecto. Si bien la carga de pruebas aumenta a medida que avanza el proyecto, deben ser un factor constante en la creación de cualquier producto de software.
Cambios de control
Muchos proyectos son creados por numerosos equipos, a veces ubicados en distintos lugares, utilizando diversas plataformas, etc. Por ello, es fundamental garantizar que los cambios realizados en un sistema se sincronicen y verifiquen constantemente. (Véase Integración continua ).

Véase también

Referencias

  1. ↑ IBM adquiere Rational
  2. ↑ Jacobson, Sten (19 de julio de 2002). "El proceso de Rational Objectory: un proceso de ingeniería de software basado en UML" . Rational Software Scandinavia AB . Archivado del original el 27 de mayo de 2019. Consultado el 17 de diciembre de 2014 .
  3. ↑ Kruchten, Philippe (1 de mayo de 2004). El Proceso Unificado Racional: Una Introducción . Addison-Wesley . pág. 33. ISBN  9780321197702. Consultado el 17 de diciembre de 2014 .
  4. ↑ Aked, Mark (25-11-2003). "RUP en breve" . IBM . Recuperado el 12-07-2011 .
  5. ↑ "OpenUP" . Archivado del original el 6 de enero de 2014. Consultado el 3 de agosto de 2013 .
  6. ↑ Krebs, Jochen (15 de enero de 2007). "El valor de la certificación RUP" . IBM . Recuperado el 5 de mayo de 2014 .
  7. ↑ "Spacer IBM Certified Solution Designer - IBM Rational Unified Process V7.0" . IBM . Archivado del original el 8 de enero de 2007. Consultado el 13 de mayo de 2008 .
  8. ↑ "Prueba 839: Rational Unified Process v7.0" . IBM . Consultado el 13 de mayo de 2008 .
  9. ↑ Stephen Schach (2004). Ingeniería de software clásica y orientada a objetos . 6.ª ed., WCB McGraw Hill, Nueva York, 2004.
  10. ↑ Documento técnico sobre el Proceso Unificado de Rational. Archivado el 1 de mayo de 2009 en Wayback Machine.

Lecturas adicionales

  • Ivar Jacobson , Grady Booch y James Rumbaugh (1999). El proceso unificado de desarrollo de software.
  • 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). El Proceso Unificado Racional Simplificado: Guía práctica para el RUP.
  • Per 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 referencia y certificación RUP
  • Walker Royce, Gestión de proyectos de software: un marco unificado
  • Paul Szymkowiak, Philippe Kruchten (2003). Pruebas: la filosofía RUP [ 1 ]
  • Sitio web de IBM Rational Unified Process
  1. ↑ Szymkowiak, Paul; Kruchten, Philippe (febrero de 2003). "Pruebas: La filosofía RUP" . Academia.Edu . Rational Software (revista electrónica Rational Edge). pág. 11. Consultado el 13 de octubre de 2022 .