IIE ­ Instituto de Ingeniería Eléctrica.

DesaSoft ­ Desarrollo de Software para Ingeniería Eléctrica.
Guías de clase.   Parte II: Ingeniería de Software.

El Proceso Unificado (UP).

Índice de contenido

El Proceso Unificado (UP).................................................................................................................1
Incrementos e iteraciones........................................................................................................1
Características del UP..............................................................................................................2
Disciplinas y artefactos............................................................................................................3
Fases del UP............................................................................................................................3
Marco de desarrollo del UP.....................................................................................................3
Plan, fases, artefactos, disciplinas............................................................................................3
Otras herramientas del UP.......................................................................................................5
Especificación Complementaria......................................................................................5
Visión y Análisis del Negocio..........................................................................................6
Glosario..........................................................................................................................6
UP: fase Inicio.........................................................................................................................6
UP: fase Elaboración................................................................................................................7
Referencias y lecturas recomendadas.......................................................................................8
Lecturas recomendadas..................................................................................................8
Referencias.....................................................................................................................8

El Proceso Unificado (UP, “Unified Process”) combina prácticas comúnmente aceptadas como 
"buenas prácticas", tales como el ciclo de vida iterativo y desarrollo dirigido por el riesgo, en una 
descripción consistente y bien documentada.
Un proceso es orientado por el riesgo cuando intenta identificar y definir estrategias para 
enfrentar los riesgos más graves del proyecto, resolviendo primero los puntos más difíciles, 
elaborando planes de contingencia y tratando de anticipar las dificultades.

Incrementos e iteraciones.

Los llamados ciclos por fases intentan poner en manos del usuario un sistema con prestaciones 
parciales, que se va completando con nuevas prestaciones en fases sucesivas. Así, el usuario tiene 
en producción algunas funcionalidades mientras se van desarrollando las otras. Existen entonces al 
menos dos sistemas funcionando en paralelo:
• el sistema operacional o sistema en producción, en uso por el cliente. Puede ser una 
implementación parcial, una implementación anterior con funcionalidades nuevas o 
sustituidas, una implementación nueva con partes de la anterior u otra variante coherente. 
• el sistema en desarrollo, la siguiente versión, que está siendo preparada para reemplazar 
la versión en producción, que puede aún conservar partes de implementaciones anteriores o 
faltarle funcionalidades.
El desarrollo incremental genera versiones comenzando con un subsistema funcional pequeño, al 
cual se le va agregando funcionalidad con cada versión. El desarrollo iterativo entrega un sistema 
completo desde el principio, y luego cambia la funcionalidad de algún subsistema en cada nueva 
versión. Ambos enfoques pueden combinarse en un desarrollo iterativo e incremental.

1 de 8
 Desarrollo incremental y desarrollo iterativo

Características del UP.

• desarrollo iterativo e incremental: el proyecto se organiza en una serie de mini­proyectos 
cortos de duración fija (2 a 6 semanas) llamadas iteraciones, que elige un conjunto 
reducido de requerimientos, los diseña, implementa y prueba. El resultado de cada iteración 
es un sistema que puede ser probado, integrado y ejecutado. La salida es un subconjunto 
con calidad de producción final. 
• rápida retroalimentación y asimilación de los cambios, posibilitada por el tamaño limitado 
de lo realizado en cada iteración. 
• se abordan, resuelven y prueban primeramente las decisiones de diseño críticas o de alto 
riesgo.
• si no se logra cumplir lo previsto dentro del plazo estipulado, se aconseja transferir tareas o 
requisitos para una iteración posterior, pero no modificar la fecha de entrega de la iteración 
actual.

Desarrollo iterativo e incremental en el UP

2 de 8
Disciplinas y artefactos.

El UP se organiza en disciplinas o flujos de trabajo. Un flujo de trabajo o disciplina (en el sentido del 
UP) es un conjunto de actividades realizadas en un área determinada. Las actividades producen 
artefactos. Un artefacto es un término general empleado para referirse a cualquier resultado del 
trabajo, ya sea un texto, un diagrama, una página web, código en lenguaje de programación u 
otros.

Fases del UP.

1. Inicio: visión aproximada, análisis del quehacer de la empresa cliente ("el negocio"), 
alcance del proyecto, estimaciones (imprecisas) de plazos y costos. Se define la viabilidad 
del proyecto.
2. Elaboración: visión refinada, implementación iterativa del núcleo central de la aplicación, 
resolución de los riesgos más altos, identificación de nuevos requisitos y nuevos alcances, 
estimaciones más ajustadas. 
3. Construcción: implementación iterativa del resto de los requisitos de menor riesgo y 
elementos más sencillos, preparación para el despliegue (entrega, instalación y 
configuración). 
4. Transición: pruebas beta, despliegue. 

Marco de desarrollo del UP.

El cuadro siguiente resume las disciplinas del UP y sus artefactos asociados, indicando también, 
para las siguientes fases, el grado aproximado de desarrollo de cada uno de estos artefactos.

c: comienzo de la construcción del artefacto.
r: refinamiento del artefacto (ampliación, corrección).
Componentes del UP Fases del UP
Artefacto Inicio Elaboración Construcción Transición
Disciplina
Iteraciones: I1 E1...En C1...Cn T1...Tn
Modelado del negocio Modelo del dominio c
Requerimientos Modelo de Casos de Uso c r
Visión y Análisis del Negocio c r
Especificación Complementaria c r
Glosario c r
Diseño Modelo de Diseño c r
Documento de Arquitectura c
Modelo de Datos c r
Implementación Modelo de implementación c r r
Gestión del proyecto Plan de desarrollo c r r r
Pruebas Modelo de Pruebas c r
Entorno Marco de desarrollo c r

No todos los proyectos requieren todos los artefactos, ni con igual grado de profundidad o 
detalle. Los artefactos son opcionales, y se recomienda usar pocos artefactos, eligiendo los de 
mayor valor práctico para cada proyecto.

3 de 8
Plan, fases, artefactos, disciplinas.

En el UP (“Unified Process”, proceso unificado) de desarrollo de software, se reconocen las fases 
de Inicio, Elaboración, Construcción y Transición, en cada una de las cuales se cumplen una o más 
iteraciones. El desarrollo es iterativo e incremental; en cada iteración se agrega algo más, y el 
sistema está en continuo crecimiento hasta su entrega. En cada iteración hay análisis de 
requerimientos, diseño, implementación y verificación, así como puesta a punto y coordinación de 
todos los artefactos.
La figura siguiente muestra la relación entre los distintos artefactos y su aplicación en las 
distintas disciplinas reconocidas en el UP. Las flechas indican algunos aportes significativos de unos 
artefactos hacia otros.

 
UP: Fases, Hitos, Planes de Fase y Planes de Iteración.

Iteraciones: períodos de trabajo con objetivos, tareas y entregables.
Fases: las etapas del proceso unificado.
Hitos: instantes donde se entrega algo o se controla el avance del proyecto.
Plan de Fase: objetivos, estimación de fechas, hitos, entregables.
Plan de Iteración: objetivos, tareas, entregables; en detalle para la presente iteración.

• El texto de los Casos de Uso sugiere términos, conceptos, atributos y asociaciones en el 
Modelo de Dominio. 
• El Modelo de Dominio sugiere nombres de las clases, asociaciones y atributos del Diagrama 
de Clases de Diseño. 
• Los Contratos de Operaciones describen los cambios de estado en el Modelo de Dominio; 
los cambio se producen en los objetos (creación, destrucción), sus atributos y sus 
asociaciones. Los Contratos de Operaciones se hacen, opcionalmente, para las operaciones 
descritas en el Diagrama de Secuencia del Sistema particularmente críticas o difíciles de 
entender. 
• Algunos de los términos del Modelo de Dominio se aclaran o elaboran en el Glosario. 
• Los Diagramas de Interacción (Colaboración o Secuencia) y los Diagramas de Clases de 
Diseño permiten a los programadores implementar los componentes de software y las 
Pruebas de verificación.

4 de 8
  
Artefactos en las diferentes disciplinas del UP

Otras herramientas del UP.

Especificación Complementaria.

La Especificación Complementaria reúne requerimientos, restricciones e información que resulta 
difícil reflejar en los Casos de Uso o en el Glosario. Si bien los requerimientos propios de un Caso 
de Uso deben figurar en él en la sección Requerimientos Especiales, algunos desarrolladores 
prefieren reunirlos además en este documento, como manera de tenerlos en cuenta globalmente.
La Especificación Complementaria comprende elementos tales como:
• requerimientos especiales de funcionalidad, confiabilidad, rendimiento, soporte. 
• informes. 
• restricciones de software y hardware (plataformas, sistema operativo, red, ...). 
• restricciones de desarrollo (herramientas a emplear, procedimientos). 

5 de 8
 • otras restricciones de diseño e implementación. 
• internacionalización (caracteres, moneda, unidades de medida, ...). 
• exigencias de documentación (usuario, administrador, instalación, ayuda, ...). 
• licencias, restricciones legales. 
• empaquetado (“packaging”), la forma física en que se entrega. 
• normas (técnicas, de seguridad, de calidad, ...). 
• ambiente físico (calor, humedad, luz, vibraciones, interferencia electromagnética, ...). 
• aspectos operacionales (respaldos, restauración, gestión de errores...). 
• reglas de la empresa, restricciones y comportamientos, el modo de trabajo del cliente. 
• información complementaria de interés (cómo se gestionan las compras a crédito, ...). 

Visión y Análisis del Negocio.

La Visión y Análisis del Negocio (o Visión) es un documento donde se describe la totalidad del 
sistema de manera general pero suficiente para servir como contrato formal o informal entre el 
cliente y el desarrollador. Muestra los problemas y objetivos a más alto nivel que los Casos de Uso, 
enfatiza la globalidad.
Algunas características propias del documento de Visión son:
• contiene una descripción del problema concisa, precisa, entendible por todos los 
involucrados. 
• muestra objetivos funcionales y no funcionales considerados importantes, que pueden 
corresponder a varios casos de uso. 
• se expresa como características del sistema, sentencias concisas, de alto nivel, que resumen 
las funciones y restricciones del sistema. 
• usa no más de 2 niveles descriptivos; no puede tener un nivel de detalle excesivo. 
El documento de Visión presenta el peligro de una duplicación inútil: no debe repetir los Casos 
de Uso, sino resumirlos en un documento único, con énfasis en el panorama global por 
contraposición a la visión más detallada de los casos de uso.

Glosario.

El Glosario es una lista de los términos relevantes y sus definiciones. Tiene como propósito evitar 
interpretaciones dispares o ambiguas de términos técnicos o propios del dominio del problema. No 
reúne todos los términos, sólo aquellos donde se entiende necesario dar una definición precisa. 
Puede incluir términos compuestos o expresiones de uso habitual, no sólo palabras aisladas 
(términos atómicos). Por ejemplo, "autorización de pago" puede contener varios elementos 
distintos.
El Glosario es un antecedente del Diccionario de Datos, un documento de elaboración posterior 
donde los términos no sólo de definen sino que se caracterizan con atributos tales como alias, 
formato (tipo, largo, unidad), relaciones con otro términos. El Diccionario de Datos se confecciona 
típicamente en la fase de Elaboración.

UP: fase Inicio.

En el Proceso Unificado (UP), el propósito de la fase Inicio es establecer una vista general de los 
objetivos del proyecto, determinar si es viable y decidir si se continuará el proyecto. Si es así, se 
realizarán investigaciones más profundas del problema en la fase de Elaboración. La fase Inicio 
podría ser muy breve si se trata de un problema conocido, o se ha decidido realizar el proyecto de 
todas formas.
La tabla siguiente muestra los artefactos típicos de la fase Inicio. Siguiendo los principios del 
desarrollo iterativo, estos artefactos se trabajan sólo parcialmente en esta etapa, apenas lo 
necesario para cumplir el objetivo de esta fase: entender lo suficiente el problema como para 
decidir su viabilidad. Recordemos una vez más que los artefactos son opcionales, su utilidad 
depende del problema, y también que es mejor restringirse a unos pocos artefactos útiles en la 

6 de 8
práctica.

UP: fase Inicio
Artefacto Descripción, propósito 
Visión y Análisis del  Describe objetivos, funcionalidades y restricciones en forma concisa (de 
Negocio alto nivel); es un resumen del proyecto apto para la toma de decisiones.
Modelado de Casos  Describe los requerimientos funcionales y no funcionales (restricciones) 
de Uso relacionados.
Especificación 
Describe otros requerimientos.
Complementaria
Glosario Define los términos más importantes del dominio del problema.
Lista de Riesgos Describe los riesgos técnicos, de recursos o del negocio implicados en el 
Plan de Gestión del  proyecto, y formula un plan con medidas preventivas y correctivas para 
Riesgo enfrentar cada uno.
Prototipos, prueba de  Código escrito para aclarar la visión del problema, probar soluciones 
conceptos técnicas, asegurar la viabilidad.
Describe qué se hará en la primera iteración de la fase de Elaboración 
Plan de Iteración
subsiguiente.
Estimación gruesa de la duración y esfuerzo requeridos para la fase de 
Plan de Fase Elaboración.
Plan de Desarrollo Propuesta o selección de herramientas de desarrollo, actividades de 
formación, recursos adicionales.
Descripción de los pasos del UP y los artefactos considerados más 
Marco de Desarrollo adecuados para este proyecto; es la adaptación del UP para este proyecto 
particular.

UP: fase Elaboración.

La Elaboración tiene por objeto construir el núcleo central de la arquitectura, resolver los 
elementos de alto riesgo, definir la mayor parte de los requerimientos y estimar los recursos 
necesarios. En esta fase,
• se descubren los restantes requerimientos y se estabiliza la mayoría de ellos. 
• se implementan y prueban los elementos básicos de la arquitectura.
• se reducen o eliminan los riesgos e incertidumbres más importantes del desarrollo (se ha 
implementado una solución básica, o se ha probado su viabilidad en código). 
Durante el estudio de los requerimientos se han puesto de manifiesto las capacidades que ha de 
tener el sistema. La arquitectura del sistema identifica las capacidades del sistema con las 
componentes de software que las implementarán, así como las relaciones entre estas componentes. 
En esta etapa se construye el núcleo central de la arquitectura del sistema, incluyendo:
• empleo de técnicas de diseño e implementación "amplias y superficiales", más bien 
abarcativas que de detalle: 
• identificación de procesos, capas de software, paquetes, subsistemas;
• establecimiento de sus responsabilidades;
• clarificación y prueba de las interfaces internas (entre componentes) y externas (con 
los actores).
• refinamiento de las interfaces locales incluyendo parámetros y valores de retorno.
• integración de componentes existentes.
• implementación de los flujos básicos y extensiones más significativas o de mayor incidencia 
en el diseño, la implementación, las pruebas o sobre otros componentes.
La tabla siguiente muestra los artefactos típicos de la fase Elaboración.

7 de 8
 UP: fase Elaboración
Artefacto Descripción, propósito 
Modelo del 
Visualización de los conceptos del dominio.
Dominio
Diagramas descriptivos del diseño lógico, sin referencias al modo de 
Modelo de 
implementación. Comprende diagramas de clases del software, diagramas de 
Diseño
interacción, diagrama de paquetes y otros.
Documento de  Describe la correlación entre los componentes de software y los requerimientos. 
Arquitectura Es un resumen de las ideas principales del diseño.
Comprende esquemas de bases de datos, estrategias de transformación entre 
Modelo de Datos objetos y no objetos (e.g. cómo guardar los objetos en archivos, o cómo 
reconstruirlos a partir de información guardada en archivos).
Modelo de  Descripción de lo qué se probará y cómo se probará; compara el resultado 
Pruebas obtenido contra el resultado esperado.
Modelo de 
Código fuente, ejecutables, bases de datos, otros.
Implementación
Prototipos UI Construcción de prototipos de la interfaz de usuario (UI, “User Interface”).
Guiones de Casos  Modelos de facilidad de uso, navegación dentro del sistema (e.g. entre menús, 
de Uso entre ventanas).

Referencias y lecturas recomendadas.

El contenido de este documento está basado en las fuentes citadas a continuación, cuya lectura o 
consulta no pretenden sustituir.

Lecturas recomendadas.

• [Larman2003] Larman, Craig. UML y patrones. Una introducción al análisis y diseño 
orientado a objetos y al Proceso Unificado, 2a. edición. Madrid, 2003.
ISBN 84­205­3438­2.
• [Fowler1997] Fowler, Martin y Scott, Kendall. UML distilled. Applying the Standard Object 
Modelling Language. Addison Wesley Longman, Inc., 1997. ISBN 0­201­32563­2.
• [Pfleeger2002] PFLEEGER, SHARI LAWRENCE. Ingeniería de software, teoría y práctica, 
1a. edición. Buenos Aires, Pearson educación, 2002. ISBN: 987­9460­71­5.

Referencias.

• [Jacobson2000] Jacobson, Ivar; Booch, Grady; Rumbaugh, James. El proceso unificado de 
desarrollo de software. Pearson Educación, Madrid, 2000. ISBN: 84­7829­036­2.
• [Booch1999] Booch, Grady; Jacobson, Ivar; Rumbaugh, James. El lenguaje unificado de 
modelado. Pearson Educación, Madrid, 2000. ISBN: 84­7829­028­1.

Errores, omisiones, comentarios: Víctor González Barbone, vagonbar en fing.edu.uy

Desarrollo de Software para Ingeniería Eléctrica ­ Rev. 2009­05­09
 Instituto de Ingeniería Eléctrica  ­ 
   Facultad de Ingeniería
    ­ Universidad de la República, Uruguay.
   

8 de 8