Unified Process: Difference between revisions
No edit summary |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
== Las cuatro fases del Unified Process == | == Las cuatro fases del Unified Process == | ||
Todos los marcos basados en UP comparten una estructura de cuatro fases: | Todos los marcos basados en UP comparten una estructura de cuatro fases: | ||
# '''Inicio:''' definición del alcance, identificación de los principales casos de uso y evaluación inicial de la viabilidad del proyecto. | |||
# '''Elaboración:''' confirmación de la arquitectura del sistema y mitigación de los riesgos técnicos más importantes antes de construir sobre ellos. | |||
# '''Construcción:''' desarrollo iterativo e incremental del sistema. Es la fase más larga y la que produce la mayor parte del software. | |||
# '''Transición:''' entrega del producto al entorno de producción, pruebas finales y formación de usuarios. | |||
A diferencia del desarrollo secuencial, estas fases no son etapas cerradas: las actividades de análisis, diseño, implementación y pruebas se realizan en todas las iteraciones, con diferente énfasis según la fase. | |||
== Principales variantes == | == Principales variantes == | ||
El patrón UP genérico ha dado lugar a varias especializaciones: | El patrón UP genérico ha dado lugar a varias especializaciones: | ||
* '''RUP''' (Rational Unified Process) — IBM / Rational. La variante más completa y documentada, también la más compleja. | |||
'''RUP''' (Rational Unified Process) — IBM / Rational. La variante más completa y documentada, también la más compleja. | * '''OpenUP''' (Open Unified Process) — Eclipse Foundation. Versión simplificada y de acceso abierto. | ||
'''OpenUP''' (Open Unified Process) — Eclipse Foundation. Versión simplificada y de acceso abierto. | * '''AUP''' ([[Agile Unified Process]]) — Scott W. Ambler. Adaptación ágil que reduce la documentación y enfatiza la entrega continua (véase [[Agile Unified Process]]). | ||
'''AUP''' ([[Agile Unified Process]]) — Scott W. Ambler. Adaptación ágil que reduce la documentación y enfatiza la entrega continua | * '''EssUP''' (Essential Unified Process) — Ivar Jacobson. Versión minimalista centrada en las prácticas esenciales. | ||
'''EssUP''' (Essential Unified Process) — Ivar Jacobson. Versión minimalista centrada en las prácticas esenciales. | * '''OUM''' (Oracle Unified Method) — Oracle. | ||
'''OUM''' (Oracle Unified Method) — Oracle. | |||
== Unified Process en perspectiva == | == Unified Process en perspectiva == | ||
UP y sus variantes han tenido una influencia significativa en la industria del software, especialmente en la década de 2000, antes de que Scrum se consolidara como estándar de facto. Su énfasis en la arquitectura, los casos de uso y el desarrollo iterativo sentó bases conceptuales que siguen siendo relevantes. | UP y sus variantes han tenido una influencia significativa en la industria del software, especialmente en la década de 2000, antes de que Scrum se consolidara como estándar de facto. Su énfasis en la arquitectura, los casos de uso y el desarrollo iterativo sentó bases conceptuales que siguen siendo relevantes. | ||
Hoy su adopción directa es limitada, sustituida en la mayor parte de los contextos por marcos más ligeros. Su valor actual es principalmente como referencia para entender la genealogía de los marcos ágiles y para organizaciones que trabajan en sistemas de alta complejidad arquitectónica donde la fase de elaboración de UP sigue siendo valiosa. | Hoy su adopción directa es limitada, sustituida en la mayor parte de los contextos por marcos más ligeros. Su valor actual es principalmente como referencia para entender la genealogía de los marcos ágiles y para organizaciones que trabajan en sistemas de alta complejidad arquitectónica donde la fase de elaboración de UP sigue siendo valiosa. | ||
== Error frecuente == | == Error frecuente == | ||
<div class="bok-aviso"> | <div class="bok-aviso"> | ||
Latest revision as of 17:07, 12 May 2026
El Unified Process (UP) es un marco de desarrollo de software iterativo e incremental, de ingeniería concurrente, en el que las tres fases principales de desarrollo —elaboración, construcción y transición— se solapan en iteraciones breves de tiempo cerrado. No describe una metodología cerrada con procedimientos concretos, sino un patrón genérico sobre el que varios autores y organizaciones han desarrollado variaciones y especializaciones.
Las cuatro fases del Unified Process
Todos los marcos basados en UP comparten una estructura de cuatro fases:
- Inicio: definición del alcance, identificación de los principales casos de uso y evaluación inicial de la viabilidad del proyecto.
- Elaboración: confirmación de la arquitectura del sistema y mitigación de los riesgos técnicos más importantes antes de construir sobre ellos.
- Construcción: desarrollo iterativo e incremental del sistema. Es la fase más larga y la que produce la mayor parte del software.
- Transición: entrega del producto al entorno de producción, pruebas finales y formación de usuarios.
A diferencia del desarrollo secuencial, estas fases no son etapas cerradas: las actividades de análisis, diseño, implementación y pruebas se realizan en todas las iteraciones, con diferente énfasis según la fase.
Principales variantes
El patrón UP genérico ha dado lugar a varias especializaciones:
- RUP (Rational Unified Process) — IBM / Rational. La variante más completa y documentada, también la más compleja.
- OpenUP (Open Unified Process) — Eclipse Foundation. Versión simplificada y de acceso abierto.
- AUP (Agile Unified Process) — Scott W. Ambler. Adaptación ágil que reduce la documentación y enfatiza la entrega continua (véase Agile Unified Process).
- EssUP (Essential Unified Process) — Ivar Jacobson. Versión minimalista centrada en las prácticas esenciales.
- OUM (Oracle Unified Method) — Oracle.
Unified Process en perspectiva
UP y sus variantes han tenido una influencia significativa en la industria del software, especialmente en la década de 2000, antes de que Scrum se consolidara como estándar de facto. Su énfasis en la arquitectura, los casos de uso y el desarrollo iterativo sentó bases conceptuales que siguen siendo relevantes.
Hoy su adopción directa es limitada, sustituida en la mayor parte de los contextos por marcos más ligeros. Su valor actual es principalmente como referencia para entender la genealogía de los marcos ágiles y para organizaciones que trabajan en sistemas de alta complejidad arquitectónica donde la fase de elaboración de UP sigue siendo valiosa.
Error frecuente
Confundir Unified Process con RUP. RUP es una implementación concreta y compleja del patrón UP genérico. Decir que UP es pesado o burocrático porque RUP lo es, es inexacto: AUP y OpenUP son ejemplos de que el mismo patrón puede implementarse de forma mucho más ligera.
Véase también
¿Quieres avanzar en agilidad? Puedes buscar convocatorias de cursos y exámenes o ir a tu ritmo haciéndote miembro del Club Agile. Esta membresía incluye recursos exclusivos, aulas e-learning y acceso a Skill Arena: un espacio para practicar y medir tus habilidades ágiles a tu ritmo.