El Proceso de desarrollo de software unificado o Proceso unificado es un marco de proceso de desarrollo de software iterativo e incremental . El perfeccionamiento más conocido y ampliamente documentado del Proceso Unificado es el Proceso Unificado Racional (RUP). Otros ejemplos son OpenUP y Agile Unified Process .
Descripción general
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 oposición a Proceso unificado racional se utiliza generalmente para describir el proceso genérico, incluidos los elementos que son comunes a la mayoría de los refinamientos. El nombre de Unified Process también se utiliza para evitar posibles problemas de infracción de marcas comerciales, ya que Rational Unified Process y RUP son marcas comerciales 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 usando el nombre Unified Process , mientras que los autores afiliados a Rational Software han favorecido el nombre Rational Unified Process .
En 2012 se lanzó el marco Disciplined Agile Delivery , un marco híbrido que adopta y extiende estrategias de Unified Process, Scrum, XP y otros métodos.
Características del proceso unificado
Iterativo e incremental
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 cronometradas. (La fase de inicio también se puede dividir en iteraciones para un proyecto grande). Cada iteración da como resultado un incremento , que es una versión del sistema que contiene funciones agregadas 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 relativo y el énfasis cambiarán a lo largo del proyecto.
Centrado en la arquitectura
El Proceso Unificado insiste en que la arquitectura se encuentra en el corazón 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 arquitectónicos y vistas.
Uno de los entregables 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 restante.
Centrado en el riesgo
El Proceso Unificado requiere que el equipo del proyecto se concentre en abordar los riesgos más críticos en las primeras etapas del ciclo de vida del proyecto. Los entregables de cada iteración, especialmente en la fase de elaboración, deben seleccionarse para garantizar que se aborden primero los mayores riesgos.
Ciclo de vida del proyecto (fases del proceso unificado)
El Proceso Unificado divide el proyecto en cuatro fases:
- Comienzo
- Elaboración (hito)
- Construcción (lanzamiento)
- Transición (versión de producción final)
Fase de inicio
El inicio es la fase más pequeña del proyecto e, idealmente, debería ser bastante corta. Si la Fase Inicial es larga, puede ser una indicación de una especificación inicial excesiva, lo cual es contrario al espíritu del Proceso Unificado.
Los siguientes son objetivos típicos de la fase inicial:
- Establecer
- Prepare un cronograma preliminar del proyecto y una estimación de costos
- Factibilidad
- Cómpralo o desarrollalo
El hito del objetivo del ciclo de vida marca el final de la fase de inicio.
Desarrolle una visión aproximada del sistema, haga un caso de negocio, defina el alcance y produzca una estimación aproximada del costo y el cronograma.
Fase de elaboración
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 arquitectónicos).
La arquitectura se valida principalmente mediante la implementación de una línea de base de arquitectura ejecutable. Esta es una implementación parcial del sistema que incluye los componentes centrales más importantes desde el punto de vista arquitectónico. Está construido en una serie de pequeñas iteraciones encuadradas en el tiempo. Al final de la fase de elaboración, la arquitectura del sistema debe haberse estabilizado y la línea de base de la 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 producto final de la fase de Elaboración es un plan (que incluye estimaciones de costos y cronogramas) 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 dado que los factores de riesgo importantes deberían haberse abordado durante la fase de elaboración.
Fase de construcción
La construcción es la fase más grande del proyecto. En esta fase, el resto del sistema se construye sobre los cimientos establecidos en la Elaboración. Las características del sistema se implementan en una serie de iteraciones breves y encuadradas 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 del Lenguaje de modelado unificado común (UML) 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 producto final de la fase de construcción es un software listo para ser implementado en la fase de transición.
Fase de transición
La fase final del proyecto es Transición. En esta fase, el sistema se implementa en los usuarios de destino. Los comentarios recibidos de una versión inicial (o versiones iniciales) pueden resultar en 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 conversiones de sistemas y capacitación de usuarios.
Refinamientos y variaciones
Los refinamientos del proceso unificado varían entre sí en la forma en que categorizan las disciplinas del proyecto o los flujos de trabajo . El Proceso Unificado Rational define nueve disciplinas: Modelado de Negocios , Requisitos , Análisis y Diseño , Implementación , Prueba , Implementación , Configuración y Gestión de Cambios , Gestión de Proyectos y Medio Ambiente . El Proceso Unificado Empresarial extiende RUP mediante la adición de ocho disciplinas "empresariales". Los refinamientos ágiles de UP como OpenUP / Basic y Agile Unified Process simplifican RUP al reducir el número de disciplinas.
Los refinamientos también varían en el énfasis puesto en los diferentes artefactos del proyecto . Los refinamientos ágiles agilizan el RUP al simplificar los flujos de trabajo y reducir la cantidad de artefactos esperados.
Los refinamientos también varían en 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.
El número de mejoras y variaciones del proceso unificado es innumerable. Las organizaciones que utilizan el Proceso Unificado incorporan invariablemente sus propias modificaciones y extensiones. La siguiente es 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 precursora de OpenUP
- Enterprise Unified Process (EUP), una extensión del Rational Unified Process
- Proceso unificado esencial (EssUP), una variación ligera desarrollada por Ivar Jacobson
- Open Unified Process (OpenUP), el proceso de desarrollo de software de Eclipse Process Framework
- Rational Unified Process (RUP), el proceso de desarrollo de IBM / Rational Software
- Método Unificado de Oracle (OUM), el proceso de desarrollo e implementación de Oracle
- Rational Unified Process-System Engineering (RUP-SE), una versión de RUP adaptada por Rational Software para la ingeniería de sistemas
Referencias
- Kroll, Per; Kruchten, Philippe (2003). El proceso unificado racional simplificado: una guía para profesionales de RUP . ISBN 0-321-16609-4 .
- Kruchten, Philippe (2004). El proceso unificado racional: una introducción (3ª ed.). ISBN 0-321-19770-4 .
- Ambler, Scott (2002). Modelado ágil: prácticas efectivas para la programación EXTREMA y el proceso unificado . J. Wiley. ISBN 0-471-20282-7.
- Scott, Kendall (2002). Explicación del proceso unificado . ISBN 0-201-74204-7 .
- Bergstrom, Stefan; Raberg, Lotta (2004). Adopción del proceso unificado racional: éxito con RUP . ISBN 0-321-20294-5 .
- Ambler, Scott ; Constantine, Larry (2002). Las fases de producción y transición del proceso unificado . Libros CMP. ISBN 1-57820-092-X.
- Larman, Craig (2004). Desarrollo ágil e iterativo: una guía para el gerente . ISBN 0-13-111155-8 .
