Proceso unificado

El proceso unificado de desarrollo de software o proceso unificado es un marco de trabajo iterativo e incremental para el proceso de desarrollo de software. La versión más conocida y ampliamente documentada del proceso unificado es el proceso unificado racional (RUP). Otros ejemplos son OpenUP y el proceso unificado ágil.

El proceso unificado no es simplemente un proceso, sino más bien un marco extensible que debe personalizarse para organizaciones o proyectos específicos. El proceso unificado racional es, de manera similar, un marco personalizable. Como resultado, a menudo es imposible decir si un refinamiento del proceso se derivó de UP o de RUP, por lo que los nombres tienden a usarse indistintamente.

El nombre proceso unificado, en contraposición a proceso unificado racional, se utiliza generalmente para describir el proceso genérico, incluidos aquellos elementos que son comunes a la mayoría de los refinamientos. El nombre proceso unificado también se utiliza para evitar posibles problemas de infracción de marca registrada, ya que Rational Unified Process y RUP son marcas registradas de IBM. El primer libro que describió el proceso se tituló The Unified Software Development Process (ISBN 0-201-57169-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh. Desde entonces, varios autores no afiliados a Rational Software han publicado libros y artículos utilizando el nombre Unified Process, mientras que los autores afiliados a Rational Software han preferido el nombre Rational Unified Process.

En 2012 se lanzó el marco de trabajo Disciplined Agile Delivery, un marco híbrido que adopta y amplía estrategias de procesos unificados, Scrum, programación extrema y otros métodos.

El proceso unificado es un proceso de desarrollo iterativo e incremental. Las fases de elaboración, construcción y transición se dividen en una serie de iteraciones con límites de tiempo. (La fase de inicio también puede dividirse en iteraciones para un proyecto de gran envergadura). Cada iteración da como resultado un incremento, que es una versión del sistema que contiene funcionalidades añadidas o mejoradas en comparación con la versión anterior.

Aunque la mayoría de las iteraciones incluirán trabajo en la mayoría de las disciplinas del proceso (por ejemplo, requisitos, diseño, implementación, pruebas), el esfuerzo y el énfasis relativos cambiarán a lo largo del proyecto.

El proceso unificado insiste en que la arquitectura se encuentra en el centro de los esfuerzos del equipo del proyecto para dar forma al sistema. Dado que ningún modelo es suficiente para cubrir todos los aspectos de un sistema, el proceso unificado admite múltiples modelos y vistas arquitectónicas.

Uno de los resultados más importantes del proceso es la línea base de la arquitectura ejecutable que se crea durante la fase de elaboración. Esta implementación parcial del sistema sirve para validar la arquitectura y actuar como base para el desarrollo posterior.

El proceso unificado requiere que el equipo del proyecto se concentre en abordar los riesgos más críticos al comienzo del ciclo de vida del proyecto. Los resultados de cada iteración, especialmente en la fase de elaboración, deben seleccionarse para garantizar que los mayores riesgos se aborden primero.

Los casos de uso son las principales herramientas de modelado para definir las funcionalidades del sistema. También actúan como un medio de comunicación directo para los miembros del equipo, tanto técnicos como no técnicos.

El proceso unificado divide el proyecto en cuatro fases:

• Inception
• Elaboration (milestone)
• Construcción (liberación)
• Transición (libertad de producción final)

Cada fase generalmente contendrá múltiples iteraciones (denominadas I1, E1, E2, C1, etc. en la ilustración de la fase UP). El número exacto de iteraciones en cada fase depende de la escala y la naturaleza del proyecto. La ilustración de la fase UP que se muestra aquí contiene exactamente 1, 2, 4 y 2 iteraciones en las cuatro fases, pero esto es simplemente un ejemplo de cómo podría ser un proyecto específico.

La fase inicial es la más pequeña del proyecto y, idealmente, debería ser bastante corta. Si la fase inicial es larga, puede ser un indicio de una especificación inicial excesiva, lo que es contrario al espíritu del proceso unificado.

Desarrollar una visión aproximada del sistema, elaborar el caso de negocio, definir el alcance y elaborar una estimación aproximada de los costos y un cronograma del proyecto.

Durante la fase de elaboración, se espera que el equipo del proyecto capture una gran mayoría de los requisitos del sistema. Sin embargo, los objetivos principales de la elaboración son abordar los factores de riesgo conocidos y establecer y validar la arquitectura del sistema. Los procesos comunes que se llevan a cabo en esta fase incluyen la creación de diagramas de casos de uso, diagramas conceptuales (diagramas de clases con solo notación básica) y diagramas de paquetes (diagramas de arquitectura).

La arquitectura se valida principalmente mediante la implementación de una línea base de arquitectura ejecutable. Se trata de una implementación parcial del sistema que incluye los componentes arquitectónicos más importantes. Se construye en una serie de pequeñas iteraciones con límites de tiempo. Al final de la fase de elaboración, la arquitectura del sistema debe haberse estabilizado y la línea base de arquitectura ejecutable debe demostrar que la arquitectura admitirá la funcionalidad clave del sistema y exhibirá el comportamiento correcto en términos de rendimiento, escalabilidad y costo.

El resultado final de la fase de elaboración es un plan (que incluye estimaciones de costos y plazos) para la fase de construcción. En este punto, el plan debe ser preciso y creíble, ya que debe basarse en la experiencia de la fase de elaboración y, durante la fase de elaboración, se deben haber abordado factores de riesgo importantes.

La construcción es la fase más grande del proyecto. En esta fase, el resto del sistema se construye sobre la base establecida en la elaboración. Las características del sistema se implementan en una serie de iteraciones cortas y limitadas en el tiempo. Cada iteración da como resultado una versión ejecutable del software. Es habitual escribir casos de uso de texto completo durante la fase de construcción y cada uno se convierte en el inicio de una nueva iteración. Los diagramas de lenguaje de modelado unificado (UML) comunes utilizados durante esta fase incluyen diagramas de actividad, diagramas de secuencia, diagramas de colaboración, diagramas de transición de estado y diagramas de descripción general de interacción. Se realiza la implementación iterativa para los riesgos más bajos y los elementos más fáciles. El resultado final de la fase de construcción es un software listo para implementarse en la fase de transición.

La fase final del proyecto es la de transición. En esta fase, el sistema se implementa para los usuarios de destino. Los comentarios recibidos de una versión inicial (o versiones iniciales) pueden dar lugar a mejoras adicionales que se incorporarán en el transcurso de varias iteraciones de la fase de transición. La fase de transición también incluye las conversiones del sistema y la capacitación de los usuarios.

Los refinamientos del proceso unificado varían entre sí en la forma en que categorizan las disciplinas o los flujos de trabajo del proyecto. El proceso unificado racional define nueve disciplinas: modelado de negocios, requisitos, análisis y diseño, implementación, prueba, despliegue, configuración y gestión de cambios, gestión de proyectos y entorno. El proceso unificado empresarial extiende RUP mediante la incorporación de ocho disciplinas "empresariales". Los refinamientos ágiles de UP, como OpenUP/Basic y el proceso unificado ágil, simplifican RUP al reducir la cantidad de disciplinas.

Los refinamientos también varían en el énfasis que se pone en los distintos artefactos del proyecto. Los refinamientos ágiles optimizan el RUP al simplificar los flujos de trabajo y reducir la cantidad de artefactos esperados.

Los refinamientos también varían en cuanto a la especificación de lo que sucede después de la fase de transición. En el proceso unificado racional, la fase de transición suele ir seguida de una nueva fase de inicio. En el proceso unificado empresarial, la fase de transición va seguida de una fase de producción.

La cantidad de mejoras y variaciones del proceso unificado es incontable. Las organizaciones que utilizan el proceso unificado incorporan invariablemente sus propias modificaciones y extensiones. A continuación, se incluye una lista de algunas de las mejoras y variaciones más conocidas.

• Proceso unificado ágil (AUP), una variación ligera desarrollada por Scott W. Ambler
• Proceso unificado básico (BUP), una variación ligera desarrollada por IBM y un precursor de OpenUP
• Proceso unificado de la empresa (EUP), una extensión del proceso unificado racional
• Proceso unificado esencial (EssUP), una variación ligera desarrollada por Ivar Jacobson
• Proceso unificado abierto (OpenUP), proceso de desarrollo de software Eclipse Process Framework
• Proceso unificado racional (RUP), proceso de desarrollo IBM / Software Racional
• Método unificado de Oracle (OUM), el proceso de desarrollo y ejecución de Oracle
• Rational Unified Process-System Engineering (RUP-SE), versión de RUP adaptada por el Software Racional para la Ingeniería de Sistemas

• Kroll, Per; Kruchten, Philippe (2003). El proceso unificado racional hizo fácil: Guía del practicante del RUP. ISBN 0-321-16609-4.
• Kruchten, Philippe (2004). El proceso unificado racional: una introducción (3rd Ed.). ISBN 0-321-19770-4.
• Ambler, Scott (2002). Modelado ágil: Prácticas eficaces para la programación de EXtreme y el proceso unificado. J. Wiley. ISBN 0-471-20282-7.
• Scott, Kendall (2002). El proceso unificado explicado. ISBN 0-201-74204-7.
• Bergstrom, Stefan; Raberg, Lotta (2004). Adopting the Rational Unified Process: Success with the RUP. ISBN 0-321-20294-5.
• Ambler, Scott; Constantine, Larry (2002). Las fases de transición y producción de procesos unificados. CP/RP Libros. ISBN 1-57820-092-X.
• Larman, Craig (2004). Desarrollo ágil e iterativo: Guía de un administrador. ISBN 0-13-111155-8.