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

RUP building blocks

RUP is based on a set of building blocks and content elements, describing what is to be produced, the necessary skills required and the step-by-step explanation describing how specific development goals are to be achieved. The main building blocks, or content elements, are the following:

  • Roles (who) – A role defines a set of related skills, competencies and responsibilities.
  • Work products (what) – A work product represents something resulting from a task, including all the documents and models produced while working through the process.
  • Tasks (how) – A task describes a unit of work assigned to a Role that provides a meaningful result.

Within each iteration, the tasks are categorized into nine disciplines:

Four project life-cycle phases

RUP phases and disciplines.

The RUP has determined a project life-cycle consisting of four phases. These phases allow the process to be presented at a high level in a similar way to how a 'waterfall'-styled project might be presented, although in essence the key to the process lies in the iterations of development that lie within all of the phases. Also, each phase has one key objective and milestone at the end that denotes the objective being accomplished. The visualization of RUP phases and disciplines over time is referred to as the RUP hump chart.

Inception phase

The primary objective is to scope the system adequately as a basis for validating initial costing and budgets. In this phase the business case which includes business context, success factors (expected revenue, market recognition, etc.), and financial forecast is established. To complement the business case, a basic use case model, project plan, initial risk assessment and project description (the core project requirements, constraints and key features) are generated. After these are completed, the project is checked against the following criteria:

  • Stakeholder concurrence on scope definition and cost/schedule estimates.
  • Requirements understanding as evidenced by the fidelity of the primary use cases.
  • Credibility of the cost/schedule estimates, priorities, risks, and development process.
  • Depth and breadth of any architectural prototype that was developed.
  • Establishing a baseline by which to compare actual expenditures versus planned expenditures.

If the project does not pass this milestone, called the life cycle objective milestone, it either can be cancelled or repeated after being redesigned to better meet the criteria.

Elaboration phase

The primary objective is to mitigate the key risk items identified by analysis up to the end of this phase. The elaboration phase is where the project starts to take shape. In this phase the problem domain analysis is made and the architecture of the project gets its basic form.

The outcome of the elaboration phase is:

  • A use-case model in which the use-cases and the actors have been identified and most of the use-case descriptions are developed. The use-case model should be 80% complete.
  • A description of the software architecture in a software system development process.
  • An executable architecture that realizes architecturally significant use cases.
  • Business case and risk list which are revised.
  • A development plan for the overall project.
  • Prototypes that demonstrably mitigate each identified technical risk.
  • A preliminary user manual (optional)

This phase must pass the lifecycle architecture milestone criteria answering the following questions:

  • Is the vision of the product stable?
  • Is the architecture stable?
  • Does the executable demonstration indicate that major risk elements are addressed and resolved?
  • Is the construction phase plan sufficiently detailed and accurate?
  • Do all stakeholders agree that the current vision can be achieved using current plan in the context of the current architecture?
  • Is the actual vs. planned resource expenditure acceptable?

If the project cannot pass this milestone, there is still time for it to be canceled or redesigned. However, after leaving this phase, the project transitions into a high-risk operation where changes are much more difficult and detrimental when made.

The key domain analysis for the elaboration is the system architecture.

Construction phase

The primary objective is to build the software system. In this phase, the main focus is on the development of components and other features of the system. This is the phase when the bulk of the coding takes place. In larger projects, several construction iterations may be developed in an effort to divide the use cases into manageable segments to produce demonstrable prototypes.

Transition phase

The primary objective is to 'transit' the system from development into production, making it available to and understood by the end user. The activities of this phase include training the end users and maintainers and beta testing the system to validate it against the end users' expectations. The system also goes through an evaluation phase, any developer which is not producing the required work is replaced or removed. The product is also checked against the quality level set in the Inception phase.

If all objectives are met, the product release milestone is reached and the development cycle is finished.

The IBM Rational Method Composer product

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 .
Modelar visualmente
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 .