Diseño de software Unidad 1

(/352&(6281,),&$'2583
El Proceso Unificado del Rational (RUP) también llamado UP (Proceso Unificado):
- Es un proceso de la Ingeniería del Software. Provee un enfoque disciplinado para asignar
tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la
producción de un software de alta calidad que satisfaga las necesidades de los usuarios finales,
con un presupuesto y un cronograma determinado.
- Incluye el modelado de negocio como una etapa dentro de cada fase, destinada a
comprender la empresa para la cual se construye el sistema.
- Es un proceso producido, desarrollado y mantenido por Rational Software.
- Apunta a la productividad en equipo, proveyendo a cada uno de sus miembros fácil acceso a
una base de conocimientos por medio de guías, plantillas y tutoriales para todas las actividades
críticas de desarrollo. Debido a que todos los miembros del equipo acceden a la misma base de
conocimientos -no importando si trabajan en requerimientos, en diseño, en testeo, en
administración del proyecto, o en administración de la configuración- comparten un lenguaje, un
proceso y una vista común de cómo desarrollar el software.
- Las actividades del RUP crean y mantienen modelos. Más que concentrarse en la
producción de grandes cantidades de documentos de papeles enfatiza el desarrollo y
mantenimiento de modelos.
- Es una guía de cómo usar efectivamente el Lenguaje de Modelado Unificado (UML).
- Captura muchas de las mejores prácticas en el desarrollo de software moderno, de forma tal
que sea adecuado para un amplio rango de proyectos y organizaciones.
&DUDFWHUtVWLFDVGHO583
(O3URFHVR8QLILFDGRHVWiGLULJLGRSRU&DVRVGH8VR
Sigue un hilo, avanza a través de una serie de flujos de trabajo que parten de los casos de Uso.
Los casos de uso se especifican, se diseñan y los casos de Uso finales son la fuente a partir de la
cual los ingenieros de prueba construyen sus casos de prueba. Los casos de uso se desarrollan a
la vez que la arquitectura del sistema.
(O3URFHVR8QLILFDGRHVWiFHQWUDGRHQODDUTXLWHFWXUD
La arquitectura en un sistema de software se describe mediante diferentes vistas del sistema en
construcción. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos
más significativos del sistema.
(VLWHUDWLYRHLQFUHPHQWDO
Iteraciones: pasos en el flujo de trabajo (mini-proyectos)
Incrementos: crecimientos del producto.
Para una efectividad máxima, las iteraciones deben estar controladas: es decir deben
seleccionarse y ejecutarse de una forma planeada.

/DVFXDWUR³3´HQHOGHVDUUROORGHVRIWZDUHSHUVRQDVSUR\HFWRSURGXFWR\
SURFHVR

1
Diseño de software Unidad 1

El resultado final de un proyecto software es un producto que toma forma durante el desarrollo
gracias a la intervención de muchos tipos distintos de personas. Un proceso de desarrollo de
software guía los esfuerzos de las personas implicadas en el proyecto, a modo de plantilla que
explica los pasos necesarios para terminar el proyecto. Típicamente el proceso está automatizado
por medio de una herramienta o un conjunto de ellas.
3HUVRQDVlos principales autores de un proyecto de software son los arquitectos, desarrolladores,
ingenieros de prueba el personal de gestión que les da soporte, además de los usuarios, clientes y
otros interesados. Las personas son realmente seres humanos, a diferencia del término abstracto
“trabajadores”(rol).
3UR\HFWR elemento organizado a través del cual se gestiona el desarrollo del software. El
resultado de un proyecto es una versión de un producto.
3URGXFWR artefactos que se crean durante la vida del proyecto Ej: modelos, código fuente,
ejecutables y documentación.
3URFHVR un proceso de ingeniería de software es una definición del conjunto completo de
actividades necesarias para transformar los requisitos de usuario en un producto. Un proceso es
una plantilla para crear proyectos.
+HUUDPLHQWDVsoftware que se utiliza para automatizar las actividades definidas en el proceso.
&RQYLUWLHQGR³UHFXUVRV´HQ³WUDEDMDGRUHV´SHUVRQDO
7UDEDMDGRU denominación de los puestos a los cuales se pueden asignar personas, y esas
personas aceptan.
Un tipo de trabajador es un papel que un individuo puede desempeñar en el desarrollo del
software: como puede ser un especificador de un caso de uso, un arquitecto, un ingeniero de
componentes, etc. No utilizar el término rol porque tiene un significado preciso y diferente en
UML, y el concepto de trabajador tiene que ser muy concreto; debemos pensar en términos de
trabajadores individuales como puestos que asumen las personas. También debemos emplear el
término rol para hablar de los papeles que cumple un trabajador.
Cada trabajador es responsable de un conjunto completo de actividades, como las actividades
necesarias para el diseño de subsistemas. Para trabajar eficazmente, los trabajadores necesitan la
información requerida para llevar a cabo sus actividades. Necesitan comprender cuáles son sus
roles en relación con los de otros trabajadores. Al mismo tiempo, si tienen que hacer su trabajo,
las herramientas que emplean deben ser las adecuadas. Las herramientas no solo deben ayudar a
los trabajadores a llevar a cabo sus propias actividades, sino que también deben aislarles de la
información que no les sea relevante. Para lograr estos objetivos, el Proceso Unificado describe
formalmente los puestos – es decir, los trabajadores- que las personas pueden asumir en el
proceso.
Una persona puede ser muchos trabajadores durante la vida de un proceso. Ej: Maria puede
comenzar como especificador de casos de uso y luego pasar a ser ingeniero de componentes.
Un trabajador también puede representar a un conjunto de personas que trabajan juntas. Por
ejemplo, un trabajador arquitecto puede ser un grupo de arquitectura.
Cada trabajador tiene un conjunto de responsabilidades y lleva a cabo un conjunto de actividades
en el desarrollo de software.
Al asignar los trabajadores a un proyecto, el jefe del proyecto debe identificar las aptitudes de las
personas y acoplarlas con las aptitudes requeridas de los trabajadores. Ésta no es una tarea fácil,
en especial si es la primera vez que se utiliza el Proceso Unificado. Se deben ensamblar las

2
Diseño de software Unidad 1

habilidades de los recursos (las personas reales) con las competencias especificadas por los
diferentes trabajadores que el proyecto necesita. Las aptitudes requeridas por algunos
trabajadores pueden conseguirse mediante formación, mientras que otros sólo pueden obtenerse
por medio de la experiencia.
Ej:

Sacar dinero: Cuenta: Ingeniero de Sacar dinero: Ingeniero

Especificador de Casos Componentes de Pruebas de
de uso Integración

Trabajadores

Recursos

)LJXUD3HUVRQDVFRPRUHFXUVRVHQ583

/RVSUR\HFWRVFRQVWUX\HQHOSURGXFWR
Un proyecto de desarrollo da como resultado una nueva versión de un producto.
El equipo de proyecto debe preocuparse por:
• Una secuencia de cambio
• Una serie de iteraciones: cada iteración implementa un conjunto de casos de uso relacionados
o atenúa algunos riesgos. Cada iteración: miniproyecto.
• Un patrón organizativo: organizar el equipo de personas.
(OSURGXFWRHVPiVTXHFyGLJR
• Sistema de software: consiste en todos los artefactos que necesitan para representarlo en una
forma comprensible por máquinas u hombres, para las máquinas, los trabajadores y los
interesados.
o Máquinas: herramientas, compiladores, ordenadores destinatarios.
o Trabajadores: directores, arquitectos, desarrolladores, ing. De prueba, personal de
marketing, administradores y otros.
o Interesados: inversores, usuarios, comerciales, jefes de proyecto, directores, línea de
productos, personal de producción, agencias de regulación.
o Artefactos: es un término general para cualquier tipo de información creada, producida,
cambiada o utilizada por trabajadores en el desarrollo del sistema. Ej: diagramas UML,
prototipos, componentes.
- Tipos:
⇒ de ingeniería: hardware y software
⇒ De gestión: análisis de negocio, plan de desarrollo, plan para asignación de personas
concretas o trabajadores, especificaciones de entornos de desarrollo

3
Diseño de software Unidad 1

• Un sistema de software posee una colección de modelos

El modelo es el artefacto más interesante de RUP.
¾ Cada trabajador necesita una perspectiva diferente del sistema.
¾ Cuando diseñamos el RUP, identificamos todos los trabajadores y cada una de las
perspectivas

Usuarios

Ingeniería de
Sistema prueba

Arquitecto

Diseñadores
Jefe de proyecto
Analistas

)LJXUD7UDEDMDGRUHVGH583

La construcción de un sistema es por lo tanto un proceso de construcción de modelos.

(OSURFHVRGLULJHORVSUR\HFWRV
En el contexto del Proceso Unificado, el término se refiere a los procesos de “negocio” claves en
una empresa de desarrollo de software, es decir una organización que desarrolla y da soporte al
software. Solo nos centramos en el Proceso de desarrollo.

El proceso: una plantilla Instancia de proceso: un proyecto

)LJXUD&RPSDUDFLyQHQWUHSURFHVRHLQVWDQFLD
Un proceso de desarrollo de software es una definición del conjunto completo de actividades
necesarias para convertir los requisitos de usuario en el conjunto de artefactos que conforman un
proceso de software, y para convertir los cambios sobre esos requisitos en un nuevo conjunto
consistente de artefactos.
La palabra requisito se utiliza con un sentido general refiriéndose a “necesidades”. Al principio,
estas necesidades no necesariamente se entienden en su totalidad. Para capturar estos requisitos o
necesidades, de una forma más completa, tenemos que comprender con mayor amplitud el
negocio de los clientes y el entorno en que trabajan los usuarios.

4
Diseño de software Unidad 1

El resultado de valor añadido del proceso es un conjunto consistente de artefactos, una línea base
que conforma una aplicación o una familia de ellas que forman un producto software. Un
proceso es una definición de un conjunto de actividades, no su ejecución.
Por último, un proceso no cubre solamente el primer ciclo de desarrollo (primera versión) sino
también los ciclos posteriores más comunes. En versiones posteriores, una instancia del proceso
toma cambios incrementales en los requisitos y produce cambios incrementales en el conjunto de
artefactos.
El modo en que describimos un proceso es en términos de flujos de trabajo descriptos en
diagramas de actividades. Primero identificamos los distintos tipos de trabajadores que
participan, después identificamos los artefactos que necesitamos crear durante el proceso para
cada tipo de trabajador, luego podemos describir cómo fluye el proceso a través de los diferentes
trabajadores y cómo ellos crean, producen y utilizan los artefactos de los demás.

Analista de Encontrar actores y

Estructurar el modelo de
sistemas casos de uso
casos de uso

Priorizar los casos

Arquitecto de uso

Detallar un caso de
Especificador de uso
casos de uso

Priorizar los casos

de uso
Diseñador de interfaces
de usuarios

)LJXUD,GHQWLILFDFLyQGHWUDEDMDGRUHVFRQDFWLYLGDGHV
A partir de aquí podemos identificar fácilmente las actividades que estos trabajadores deben
realizar cuando se activan. Estas actividades por trabajador son trabajos significativos para una
persona que actúe como trabajador. Además, podemos ver inmediatamente a partir de esas
descripciones si algún trabajador concreto necesita participar más de una vez en el flujo de
trabajo
La notación “ en forma de pez” es el estereotipo de flujo de trabajo o actividad.

Una colaboración de trabajadores y

Requisitos artefactos que se utiliza para describir el
flujo de requisitos del proceso

5
Diseño de software Unidad 1

)LJXUD(VWHUHRWLSRGHDFWLYLGDG
El proceso unificado puede especializarse para cumplir diferentes necesidades de aplicación o de
organización. Al mismo tiempo, es deseable que el proceso sea, al menos, completamente
consistente dentro de una organización. Esta consistencia permitirá el intercambio de
componentes, una transición eficaz de personas y directivos entre proyectos, y el logro de
conseguir que las métricas sean comparables.
Los factores principales que influyen en cómo se diferenciará el proceso son:
• Factores organizativos: la estructura organizativa, la cultura de la empresa, la
organización y la gestión del proyecto, las aptitudes y las habilidades disponibles,
experiencias previas y sistemas de software existentes
• Factores del dominio: el dominio de la aplicación, procesos de negocio que se deben
soportar, la comunidad de usuarios y las ofertas disponibles de la competencia.
• Factores del ciclo de vida: el tiempo de salida al mercado, el tiempo de vida esperando
del software, la tecnología y la experiencia de las personas en el desarrollo de software, y
las versiones planificadas y futuras.
• Factores técnicos: lenguaje de programación, herramientas de desarrollo, base de datos,
marcos de trabajo y arquitecturas estándar subyacentes, comunicaciones y distribución.


 
   "!#"! $

Modelo de casos de
%# &  '( !)*! $
uso

Modelo de Análisis +) -,-$ ."/ *!#! $

Modelo de Diseño





 0213& 1345,67!#! $


Modelo de    
89($ 6  !)! $

despliegue 
   
   

Modelo de O
implementación O
O

 Modelo de prueba

)LJXUD0RGHORGHO3URFHVR8QLILFDGR([LVWHQGHSHQGHQFLDVHQWUHPXFKRVGHORV
PRGHORVFRPRSRUHMHPSORODVGHSHQGHQFLDVGHORVFDVRVGHXVRGHORVRWURVPRGHORV

6
Diseño de software Unidad 1

9LVWD*HQHUDOGHO583

El RUP se puede describir en dos dimensiones, o a través de dos ejes:

 (O HMH KRUL]RQWDO representa el tiempo y muestra el aspecto dinámico del proceso. Se
expresa en términos de ciclos, fases, iteraciones e hitos.
 (O HMH YHUWLFDO representa el aspecto estático del proceso. Se describe en términos de
actividades, artefactos, trabajadores y workflows.

También, en el RUP, el ciclo de vida de desarrollo del software se presenta desde dos
perspectivas: la perspectiva de administración y la perspectiva de desarrollo.

Desde la perspectiva de administración, se camina a través de las cuatro fases del ciclo de vida
para desarrollar un sistema, o una nueva generación de un sistema.

Desde la perspectiva de desarrollo, se realizan versiones iterativamente, que se completan

incrementalmente. Las actividades que se desarrollan durante una iteración son agrupadas en un
conjunto de workflows centrales. Cada workflow central se focaliza en describir algún aspecto
del sistema, resultando en un modelo del sistema o en un conjunto de documentos.

Aspecto Dinámico

Fases
:RUNIORZV&HQWUDOHV
GH3URFHVRV Inicio Elabor. Construcción Transición

Modelado del Negocio

Requerimientos
Análisis & Diseño
Implementación
Testeo
Aspecto Estático

Despliegue

:RUNIORZV&HQWUDOHV
GH6RSRUWH

Adm. Conf. & Cambio

Adm. del Proyecto
Ambiente
Iterac. Iter Iter Iter Iter Iter Iter
Prelim. #1 #2 #n # n+ 1 # m # m+ 1

Iteraciones
)LJXUD9LVWD*HQHUDOGHO583(OPRGHORLWHUDWLYR


7
Diseño de software Unidad 1

Para entender el gráfico precedente es importante comprender los conceptos que se

presentan en las dos secciones siguientes.

$VSHFWRGLQiPLFRGHO583

&LFOR

El ciclo de vida del software esta dividido en ciclos, cada uno trabajando sobre una nueva
generación del producto. El RUP divide un ciclo de desarrollo en fases.

)DVHV

El RUP divide un ciclo de desarrollo en cuatro fases consecutivas. Cada fase tienen un
propósito específico y concluye con un hito bien definido. Las fases son las siguientes:

)DVHGH,QLFLR 

Durante la fase de inicio se deben identificar todas las entidades externas con las cuales
interactuará el negocio, es decir los actores. Esto involucra identificar todos los casos de uso y
describir el significado de algunos de ellos.

+LWR 2EMHWLYRVGHO&LFORGH9LGD

Es el primer hito importante del proyecto y se encuentra al finalizar la fase de inicio.

)DVHGH(ODERUDFLyQ

El propósito de esta fase es analizar el dominio del problema, establecer una base
arquitectónica, desarrollar el plan del proyecto y eliminar los elementos de alto riesgo del
proyecto. Las decisiones arquitectónicas tienen que ser hechas con un entendimiento del sistema
completo: su alcance, funcionalidad principal y los requerimientos no funcionales tales como los
requerimientos de rendimiento.

En general, ésta es la fase más crítica de las cuatro. Al final de esta fase es cuando el
proyecto sufre su mayor ajuste, es decir, la decisión de llevar o no a cabo las fases de
Construcción y de Transición.

En esta fase un prototipo de la arquitectura ejecutable esta integrado por una o más
iteraciones dependiendo del alcance, tamaño, riesgo y novedad del proyecto. Este esfuerzo debe
al menos manejar los casos de uso críticos identificados en la fase de inicio.

+LWR $UTXLWHFWXUDGHO&LFORGH9LGD

Es el hito que se encuentra al finalizar la fase de elaboración. En este punto se examina el

alcance y los objetivos del sistema detallado, la elección de la arquitectura y la resolución de los
principales riesgos.

8
Diseño de software Unidad 1

)DVHGH&RQVWUXFFLyQ

Durante la fase de Construcción se desarrollan todos los componentes y características

restantes y se integran al producto y, además, se testean completamente todas las características.

En la fase de construcción se pone énfasis en la administración de recursos y en el control

de operaciones para optimizar costos, cronogramas y calidad.

Si los proyectos son lo suficientemente grandes se puede incrementar la construcción en

paralelo. Estas actividades paralelas pueden acelerar significativamente la disponibilidad de
versiones; pero, ellas también pueden aumentar la complejidad de la administración de recursos
y la sincronización de los workflows.

Uno de los aspectos críticos de la arquitectura es su facilidad de construcción. Ésta es una

razón por la cuál se enfatiza el desarrollo balanceado de la arquitectura y el plan de
entendimiento durante la fase de elaboración.

+LWR &DSDFLGDG2SHUDFLRQDO,QLFLDO

Esta al finalizar la fase de construcción. A este punto, se decide si el software y los

usuarios están listos para operar, sin exponer el proyecto a altos riesgos. Esta versión se llama a
menudo “ versión beta” .

La transición puede tener que ser pospuesta si el proyecto no alcanza este hito.

)DVHGH7UDQVLFLyQ

El propósito de esta fase es la transición del producto de software a la comunidad de

usuarios. Una vez que el producto ha sido entregado al usuario final normalmente surgen
problemas que exigen que se desarrollen nuevas versiones para corregir o terminar las
características que se pospusieron.

Típicamente, esta fase incluye varias iteraciones, incluso las versiones beta, las versiones
de disponibilidad general, así como parches y versiones mejoradas.

Se debe desarrollar la documentación orientada al usuario para entrenarlos, para

apoyarlos en el uso inicial del producto y para reaccionar a su realimentación. A este punto del
ciclo de vida, sin embargo, la realimentación del usuario debe limitarse principalmente a
problemas de puesta a punto, de configuración, de instalación y de utilidad del producto.

+LWR: (QWUHJDGHO3URGXFWR

Se encuentra al finalizar la fase de transición. En este punto se decide si los objetivos se

cumplieron y si se debe empezar otro ciclo de desarrollo. En algunos casos este hito puede
coincidir con el final de la fase de inicio del próximo ciclo.

9
Diseño de software Unidad 1

+LWR

Es un punto en el tiempo en donde se deben tomar decisiones críticas certeras y, por

consiguiente, deben haberse logrados los objetivos claves.

Hitos Principales

Inicio Elaboración Construcción Transición

 Tiempo
)LJXUD/DVIDVHV\ORVSULQFLSDOHVKLWRVHQHO583

,WHUDFLRQHV

Cada fase puede dividirse en iteraciones. Una iteración es una vuelta de desarrollo completa que
produce una versión (interna o externa) de un producto ejecutable. La versión es un subconjunto
del producto final bajo desarrollo que crece incrementalmente de una iteración a otra hasta
convertirse en el sistema final.

$VSHFWRHVWiWLFRGHO583

Un proceso describe quién está haciendo qué, cómo y cuándo. El RUP utiliza cuatro elementos
de modelado básicos:

- Trabajadores, el “ quién”
- Actividades, el “ cómo”
- Artefactos, el “ qué”
- Workflows, el “ cuándo” .

&RQFHSWRVFODYHV

$FWLYLGDG

- Es algo que hace un trabajador que provee un resultado significativo para el contexto del
proyecto. Es una unidad de trabajo que debe ser realizada por un individuo que cumple el rol
descripto para ese trabajador.
- La actividad tiene un propósito clave usualmente expresado en términos de crear o
actualizar algún artefacto.
- Cada actividad es asignada a un trabajador específico.

$UWHIDFWRV

- Son los productos de trabajo intermedios o finales generados y usados durante un proyecto.
- Son usados para capturar y transmitir información del proyecto.
- Un documento, un modelo y un elemento de modelo son artefactos.

10
Diseño de software Unidad 1

- Su símbolo depende del tipo de artefacto del que se trate.

3DXWDVSDUDXQDUWHIDFWR

- Presentan información sobre como desarrollar, evaluar y usar un artefacto.

- Están asociadas a los artefactos.

3DXWDVGHWUDEDMR

- Presentan técnicas y consejos prácticos que son útiles para que el trabajador realice una
actividad.
- Están asociadas a actividades.

3ODQWLOODV

- Son “ modelos” o prototipos de los artefactos.

- Se usan para crear un artefacto.
- Pueden usarse plantillas ya predefinidas, como por ejemplo las de Microsoft Word, o
pueden definirse plantillas propias de la organización.

3XQWRVGHFRQWURO

- Los artefactos típicamente tienen asociados pautas y puntos de control los cuales presentan
información de cómo desarrollarlos, evaluarlos y usarlos.
- Los puntos de control proveen una rápida referencia que ayudan a asegurar la calidad del
artefacto.

5HSRUWH

- Extraen información de los modelos y de los elementos del modelo. Por ejemplo un
reporte presenta un artefacto o un conjunto de éstos para su revisión.

7UDEDMDGRU

- Es una definición de la abstracción de un rol, la cual especifica el conjunto de actividades

y artefactos de los cuales es responsable un trabajador.
- Generalmente se refiere a un individuo o a un conjunto de los mismos trabajando juntos
como equipo.
- Un miembro de un equipo puede cumplir distintos roles.
- Los trabajadores no son individuos, sino que describen como estos deberían comportarse
en el negocio y que responsabilidades deberían tener el mismo.
- Es importante aclarar que, mientras la mayoría de los trabajadores representan personas
dentro de la organización desarrolladora del proyecto, los stakeholders son trabajadores que
representan personas fuera de esta que se ven afectadas por el proyecto.

:RUNIORZV

- Un workflow es una secuencia de actividades que producen un resultado de valor

observable.

11
Diseño de software Unidad 1

- En términos de UML, un workflow puede expresarse como un diagrama de secuencia, un

diagrama de colaboración o un diagrama de actividades.
- En el RUP se usan los diagramas de actividades. Para cada workflow central se realiza un
diagrama de actividades, el cual muestra los workflows expresados en términos de detalles de
workflows.
- Para describir los procesos existen muchas formas de organizar el conjunto de actividades
dentro de un workflow. El RUP describe sus procesos utilizando los siguientes conceptos:
workflows centrales y detalles de workflows.

:RUNIORZVFHQWUDOHV

Un workflow central es una colección de actividades relacionadas, las cuales están asociadas a
una “ área de interés” principal dentro del proyecto. Separar las actividades en workflows
centrales facilita el entendimiento de las actividades pero dificulta su organización. Dentro de los
workflows centrales se encuentran:

à Modelado del negocio

à Requerimientos
à Análisis y Diseño
à Implementación
à Testeo
à Despliegue
à Administración de la Configuración y el Cambio
à Administración del Proyecto
à Ambiente

Cada workflow central tiene asociado uno o más modelos los cuales a su vez están compuestos
de artefactos.

Para cada workflow central, el RUP presenta una visión general de las actividades. Cada una de
estas actividades muestra, a la vez, todas sus actividades junto con los trabajadores que las
realizan.

'HWDOOHVGHOZRUNIORZ

El diagrama de detalles de un workflow muestra el agrupamiento de las actividades que

frecuentemente son realizadas conjuntamente. Este diagrama, también, muestra los trabajadores
involucrados, los artefactos de entrada y los de salida.

El diagrama de detalles de un workflow muestra como se trabajará frecuentemente en los talleres

o en las reuniones de equipo cuando se realiza un workflow. En general, se trabaja sobre más de
una actividad en forma paralela y se utiliza más de un artefacto cuando se está haciendo la
misma. Existen varios diagramas de detalles de workflow para un workflow central.

Los workflows centrales no son completamente independientes unos de otros. El diagrama de

detalles del workflow puede mostrar un grupo de actividades y artefactos en el workflow, junto
con aquellas actividades -de otro workflow- que están estrechamente relacionadas.

12
Diseño de software Unidad 1

Referencia a
Realiza
Actividad
 Trabajador ........
........
 Entrada de Salida de
........
...
Pautas de trabajo

Responsable de

 ........
........
 ........
...

 Artefactos

 ........ ........
........ ........
........ ........
 ... ...


Puntos de control Plantillas Pautas para un artefacto Reporte

)LJXUD'HWDOOHVGHZRUNIORZ

$OFDQFH

Como se muestra en la )LJXUD  9LVWD JHQHUDO GHO 583, el RUP abarca varios workflows
centrales, tanto de procesos como de soporte. Es importante aclarar que para el alcance del
presente trabajo sólo se ahondará en los conceptos relacionados con el workflow del modelado
del negocio pero no se debe olvidar que este workflow está relacionado con otros workflows
centrales. Esta relación se explica posteriormente.

:RUNIORZGH0RGHODGRGHO1HJRFLR
3URSyVLWRVGHOZRUNIORZGHPRGHODGRGHOQHJRFLR
Los propósitos son:
- Entender la estructura y la dinámica de la organización en la cual un sistema será
desarrollado (la organización objetivo).
- Entender los problemas actuales de la organización objetivo e identificar mejoras
potenciales.
- Asegurarse que los clientes, los usuarios finales y los desarrolladores tienen un
entendimiento común de la organización objetivo.
- Deducir cuales son los requerimientos necesarios para soportar la organización objetivo.

13
Diseño de software Unidad 1

Para lograr estas metas, el workflow de modelado del negocio describe cómo desarrollar
una visión de la nueva organización y, basándose en esta visión, define los procesos, los roles y
las responsabilidades de la organización en un modelo de casos de uso del negocio y en un
modelo de objetos del negocio.
5HODFLRQHVFRQRWURVZRUNIORZV
El workflow de modelado del negocio está relacionado con otros workflows:
- El )OXMR GH 5HTXHULPLHQWRV usa los modelos del negocio como entrada importante para
entender los requerimientos del sistema.
- El )OXMR GH$QiOLVLV\ 'LVHxR usa las entidades del negocio como entrada para identificar
clases de entidades en el modelo del diseño.
- El )OXMRGHO$PELHQWH desarrolla y mantiene los artefactos de soporte, tales como las Pautas
para el modelado del negocio.
'HFLVLRQHV,PSRUWDQWHVHQHOPRGHODGRGHOQHJRFLR
'HFLGLUFyPRUHDOL]DUHOZRUNIORZ
Se deben tomar las siguientes decisiones con respectos al workflow del modelado del negocio:
- Decidir como realizar el workflow mirando la )LJXUD  :RUNIORZ GHO PRGHODGR GHO
QHJRFLR. Existen distintos caminos para llevarlo a cabo, como se describe más abajo en la
sección 5.4: Alcance del modelado del negocio. Se debe decidir cual de los escenarios se seguirá.
- Decidir cuando, durante el ciclo de vida del proyecto, introducir cada parte del workflow.
Como regla general, el workflow del modelado del negocio debe introducirse al comienzo del
proyecto.
Observación. Frecuentemente, se necesitará hacer el workflow: Evaluar el estado del
negocio antes de poder tomar la decisión de que camino seguir en el workflow del modelado del
negocio.
'HFLGLUFyPRXVDUORVDUWHIDFWRV
Decidir que artefactos usar y cómo usar cada uno, depende completamente de cómo se
decidió hacer el modelado del negocio. La siguiente tabla describe aquellos artefactos que se
deben tener y aquellos que se usan en algunos casos.
Para cada artefacto, decidir cómo será usado: debería tenerlo, convendría tenerlo, podría
tenerlo o no tenerlo.

$UWHIDFWR %UHYHV&RPHQWDULRV

Actor del negocio 6HGHEH WHQHU si se hace reingeniería o mejoras al negocio.

6HSRGUtDWHQHU si sólo se quiere diagramar una organización existente.
1RWHQHUOR si se hace el modelado del dominio.

Documento de la arquitectura del 6HGHEHWHQHU si se hace reingeniería o mejoras al negocio.

negocio
1R WHQHUOR si se hace el modelado del dominio o se quiere diagramar una
organización existente.

Entidad del negocio 6HGHEHWHQHU si se decide hacer cualquier modelado del negocio.

14
Diseño de software Unidad 1

Glosario del negocio &RQYHQGUtDWHQHUOR.

Modelo de Objetos del negocio 6HGHEHWHQHU si se decide hacer cualquier modelado del negocio.

Reglas del negocio 6HSRGUtDWHQHU.

Caso de uso del negocio 6HGHEHWHQHU si se hace reingeniería o mejoras al negocio.

6HSRGUtDWHQHU si sólo se quiere diagramar una organización existente.
1RWHQHUOR si se hace el modelado del dominio.

Modelo de caso de uso del negocio Ver caso de uso del negocio

Realización del caso de uso del Ver caso de uso del negocio
negocio

Visión del negocio 6HGHEHWHQHU si se hace reingeniería o mejoras al negocio.

1R WHQHUOR si se hace el modelado del dominio o se quiere diagramar una
organización existente.

Trabajador del negocio 6H GHEH WHQHU si se hace reingeniería o mejoras al negocio y si se quiere
diagramar una organización existente.
1RWHQHUOR si se hace el modelado del dominio.

Unidad organizacional &RQYHQGUtDWHQHUOR

Especificaciones suplementarias &RQYHQGUtDWHQHUOR.

del negocio

Evaluación de la organización 6HGHEHWHQHU si se hace reingeniería o mejoras al negocio.

objetivo
1R WHQHUOR si se hace el modelado del dominio o se quiere diagramar una
organización existente.

'HFLGLUTXHUHSRUWHVXVDU
Reporte: Estudio del modelo de casos de uso del negocio
Este reporte describe el modelo de casos de uso del negocio. Entrega una vista general
completa de los resultados del modelado de los casos de uso e incluye breves descripciones para
cada caso de uso y actor del negocio.
Reporte: Estudio del modelo de objetos del negocio
Este reporte contiene un estudio del modelo de objetos del negocio. La estructura del
negocio se muestra jerárquicamente.
Reporte: Entidad del negocio
Este reporte contiene información respecto de una entidad del negocio particular
(<nombre de la entidad del negocio>) dentro del modelo de objetos del negocio.
Reporte: Trabajador del negocio
Este reporte contiene información respecto de un trabajador del negocio particular
(<nombre del trabajador del negocio>) dentro del modelo de objetos del negocio.

15
Diseño de software Unidad 1

3.4. Diagrama de actividades para el workflow central de procesos “ Modelado del

Negocio”

[Primera fase de Inicio]

Evaluar el
estado del negocio

[Modelado
del negocio]

[Modelado
del dominio
Identificar los solamente]
procesos del negocio

Describir el negocio
actual

Refinar los procesos

del negocio
Desarrollar un
modelo del dominio

Explorar la
automatización de
procesos
Diseñar las realizaciones de los
procesos del negocio

Refinar roles y
responsabilidades

)LJXUD:RUNIORZGHO0RGHODGRGHO1HJRFLR

16
Diseño de software Unidad 1

$OFDQFHGHOPRGHODGRGHOQHJRFLR
Los escenarios típicos que pueden presentarse, al finalizar el workflow: Evaluar la
organización objetivo, son:
- (VFHQDULR: Querer construir un mapa simple de la organización y de sus procesos para
obtener un mejor entendimiento de cuales son los requerimientos en la aplicación que se esta
construyendo. Si se presenta este escenario se debe seguir el camino del PRGHODGRGHQHJRFLR,
pero obviar “ Describir el negocio actual” . A este escenario se le llama 'LDJUDPD GH OD
2UJDQL]DFLyQ.
- (VFHQDULR  Querer construir aplicaciones con el propósito principal de administrar y
presentar información, es decir elegir construir un modelo de esa información a nivel de negocio
sin considerar los workflows de los negocios. Esto se conoce como 0RGHODGRGHO'RPLQLR. Hay
que seguir el camino del PRGHODGRGHOGRPLQLR.
- (VFHQDULR: Querer hacer un esfuerzo de modelado que sirva de entrada a varios proyectos
de ingeniería de software. Los modelos del negocio ayudan a encontrar los requerimientos
funcionales y además sirven como entrada para construir la arquitectura de la familia de
aplicaciones. El esfuerzo de modelado, en este caso, es frecuentemente tratado como un proyecto
en si mismo.
- (VFHQDULR : Querer construir una aplicación qué será usada por varias organizaciones
entonces, puede ser útil un esfuerzo de modelado para alinear las organizaciones con respecto a
como realizan sus negocios y evitar así requerimientos que son demasiado complejos para el
sistema. Si el alineamiento no es posible, el esfuerzo de modelado puede ayudar a entender y
manejar las diferencias.
- (VFHQDULR : Querer comenzar una nueva línea de negocios, en este caso se requiere un
esfuerzo de modelado de negocio cuyo propósito será no solo encontrar los requerimientos del
sistema, sino también determinar la viabilidad de la nueva línea de negocios. El esfuerzo de
modelado se trata como un proyecto en si mismo. Si se tiene este escenario se debe obviar
“ Describir el negocio actual” .
- (VFHQDULR: Querer renovar completamente la forma en que se hacen los negocios, en este
caso frecuentemente el esfuerzo de modelado del negocio es tratado por si mismo como uno o
varios proyectos.
'HVFULSFLyQGHOZRUNIORZGHOPRGHODGRGHOQHJRFLR
(YDOXDUHOHVWDGRGHOQHJRFLR)LJXUD
Este detalle de workflow debe llevarse a cabo si es la primera fase de inicio.
- Su propósito es:
à Evaluar el estado de la organización en la cual el sistema será desarrollado.
à Entender como categorizar el proyecto y a cuál escenario del negocio se ajusta mejor.
à Tomar decisiones de cómo continuar trabajando en la iteración actual y bosquejar cómo
trabajar en las iteraciones subsiguientes con los artefactos del modelado del negocio.
à Desarrollar un primer entendimiento de las metas y objetivos de la organización -una
visión del negocio- con el que estén de acuerdo tanto los stakeholders como el equipo de
modelado del negocio.
- Participantes:

17
Diseño de software Unidad 1

El equipo de modelado de negocios de la empresa desarrolladora -todos aquellos que actúen

como analistas de procesos de negocio- debe invitar a los representantes de los stakeholders para
entender el problema a resolver y el carácter del dominio del negocio de la organización
objetivo. Este equipo de modelado del negocio extendido necesitan tener un buen conocimiento
del dominio del negocio y también conocer como se usan los sistemas actuales para automatizar
el negocio. Si el modelado del negocio es hecho con la intención de reingenierizar una
organización existente, es importante involucrar a las personas que trabajarán en la nueva
organización. Estas personas son la mejor fuente de ideas para el mejoramiento y además se debe
lograr que sientan que son parte del trabajo. Existen al menos tres formas para lograr involucrar
a estas personas:
à Hacerlos miembros del equipo de modelado del negocio.
à Entrevistarlos para que expresen sus ideas y opiniones basadas en la experiencia.
à Solicitarles que revisen los resultados.
- Observación: generalmente, la primera iteración del proyecto -fase de inicio- se focaliza
sobre la producción del artefacto “ Evaluación de la organización objetivo” y en bosquejar
brevemente el artefacto “ Visión del negocio” . En la fase de elaboración se revisa la Visión del
negocio y durante la actividad “ establecer y ajustar las metas” ambos artefactos se completan.
'HVFULELUHOQHJRFLRDFWXDO)LJXUD
- El propósito de este workflow es:
à Entender la estructura y los procesos de la organización objetivo actual.
à Basándose en este entendimiento, refinar las metas del esfuerzo del modelado del
negocio.
- El propósito no es describir la organización objetivo actual en detalle sólo priorizar algunas
partes de la organización objetivo.
- Participantes:
El equipo de modelado de negocios de la empresa desarrolladora -todos aquellos que
actúan como analistas de procesos de negocio- debe invitar a los representantes de los
stakeholders para entender el problema a resolver y el carácter del dominio del negocio de la
organización objetivo. Este equipo de modelamiento del negocio extendido necesita tener un
buen conocimiento del dominio del negocio y, también, conocer como son usados los sistemas
actuales para automatizar el negocio. Para esta actividad se requiere tener habilidades como
facilitador.
,GHQWLILFDUORVSURFHVRVGHOQHJRFLR)LJXUD
- Los propósitos de este workflow son:
à Decidir sobre la terminología.
à Bosquejar el modelo del caso de uso del negocio.
à Priorizar los casos de uso del negocio para describir en detalle.
- Participantes:
El equipo de modelado del negocio - actuando como analistas de procesos del negocio -
deben invitar a representantes de los stakeholders del esfuerzo de modelado. Este equipo de
modelado del negocio extendido debe cubrir bien el conocimiento del dominio del negocio y
debe también saber como son usados los sistemas actuales para automatizar el negocio. El
equipo central necesita tener conocimiento detallado de las técnicas de modelado. Cuando se
hace reingeniería en un negocio, este workflow significa que se está decidiendo quien será el

18
Diseño de software Unidad 1

nuevo cliente. Por lo tanto los individuos que tienen poder para tomar tales decisiones deben
tomar parte en el esfuerzo, ya sea como un miembro activo del equipo de modelado o como
stakeholders.
5HILQDUODVGHILQLFLRQHVGHORVSURFHVRVGHOQHJRFLR)LJXUD
- Cada caso de uso del negocio debe ser asignado a un miembro del equipo el cual es
responsable de describirlo en detalle. Actuando como un diseñador del negocio, esta persona
completará la definición del caso de uso del negocio y conducirá una sesión de revisión para el
mismo. Se deben invitar a otros miembros del equipo de modelado del negocio a la sesión de
revisión para que actúen como revisores del modelo del negocio. El diseñador del negocio
también puede invitar a representantes de los stakeholders del proyecto.
- Los propósitos de este workflow son:
à Detallar la definición del caso de uso del negocio.
à Verificar que el caso de uso refleja correctamente como se lleva a cabo el negocio.
- Participantes:
Una persona que actúa como diseñador del negocio necesita tener una buena habilidad al
escribir. El conocimiento del dominio del negocio es útil, pero esto se puede cubrir involucrando
expertos del dominio como revisores.
'LVHxDUODVUHDOL]DFLRQHVGHORVSURFHVRVGHOQHJRFLR)LJXUD
- Los propósitos de este workflow son:
à Identificar todos los roles, productos, entregas y eventos del negocio.
à Describir las realizaciones del caso de uso del negocio que son llevadas a cabo por los
trabajadores y las entidades del negocio.
- Participantes:
Este workflow es, frecuentemente, llevado a cabo en una serie de talleres, a los que asisten el
equipo de desarrollo central –actuando como diseñadores del negocio- y algunos invitados
expertos. Debe haber, también, por lo menos una persona que previamente haya tenido la
responsabilidad de analista de procesos de negocio para asegurar que el modelo de casos de uso
sea entendible y para actualizar el glosario. Si los diseñadores del negocio carecen de
conocimiento en algún aspecto del dominio del mismo, se puede cubrir esto invitando a
stakeholders.
5HILQDUUROHV\UHVSRQVDELOLGDGHV)LJXUD
- Los propósitos de este workflow son:
à Detallar la definición de una entidad del negocio.
à Detallar la responsabilidad de un trabajador del negocio.
à Verificar formalmente que los resultados del modelado de objetos del negocio conforma
a los stakeholders del negocio.
- Participantes:
Una persona actuando como diseñador de negocio que necesita ser habilidoso para expresarse
por escrito. El conocimiento del dominio del negocio es bueno pero puede ser cubierto
involucrando expertos del dominio como revisores.

19
Diseño de software Unidad 1

([SORUDUODDXWRPDWL]DFLyQGHSURFHVRV)LJXUD
- Los propósitos de este workflow son:
à Explorar que porciones de los procesos del negocio pueden y deben ser automatizados.
à Entender como cualquiera de los sistemas existentes -frecuentemente referenciados como
sistemas legados- encajan en la organización.
à Derivar los requerimientos del sistema.
- Participantes:
Una persona actuando como diseñador de negocio necesita ser habilidoso para expresarse por
escrito. El conocimiento del dominio del negocio es bueno pero puede ser cubierto involucrando
expertos del dominio como revisores. Para conducir las tareas de este workflow, se necesitan
también personas que estén familiarizadas con el conjunto actual de sistemas usados en la
organización y personas conocedoras de las implicaciones de cualquier tecnología nueva a ser
considerada.
'HVDUUROODUXQPRGHORGHGRPLQLR)LJXUD
- Se puede elegir desarrollar un modelo de objetos “ incompleto” , que se focaliza en explicar
productos, entregas, o eventos que son importantes para el dominio del negocio. Tal modelo no
incluye las responsabilidades que las personas tienen y, frecuentemente, se llama modelo de
dominio.
- Propósitos:
à Identificar todos los productos, entregas y eventos importantes para el dominio del negocio.
à Detallar la definición de una entidad del negocio.
à Verificar formalmente que los resultados del modelado de objetos del negocio conforman a
las vistas de los stakeholders del negocio.
- Participantes:
Este workflow es frecuentemente llevado a cabo con una serie de talleres, atendidos por un
equipo desarrollador central – actuando como diseñadores del negocio- y algunos expertos en el
dominio invitados.

20
Diseño de software Unidad 1

___ ___
___ ___
___
Glosario del negocio Reglas del negocio
stakeholders

Usuario
final
Capturar un Mantener
vocabulario las reglas
común del del negocio
negocio
Analista
de
procesos
___
Cliente Evaluar la Establecer y ___
organización ajustar
objetivo metas Visión del
negocio

___
___

Evaluación de la
organización
objetivo ___
 ___

 Analista de
Desarrollar pautas Pautas para el
de modelado del modelado del

procesos del negocio negocio
'HO negocio
$PELHQWH

)LJXUD'HWDOOHGHOZRUNIORZGH(YDOXDUODRUJDQL]DFLyQREMHWLYR

21
Diseño de software Unidad 1

___
___
___
___
Evaluar la Evaluación de la
organización objetivo organización objetivo
(refinada)

Usuario final ___

Analista de
procesos del Encontrar actores ___
y casos de uso Establecer y ___
negocio
del negocio ajustar metas ___
Visión del
negocio
(refinada)
Cliente

___ ___
___ Caso de uso del ___
___ negocio ___
___ (bosquejado) ___
Evaluación de la ___
organización Modelo de casos
___
___ objetivo de uso del
___
___ negocio
___
___ ___ Pautas para el
___ ___ modelado del
Glosario del negocio
___
negocio ___
Reglas del
negocio
___
___ Encontrar entidades y
___ trabajadores del
___ negocio
Diseñador del
Visión del negocio
negocio

_____
_____
_____
Realización de caso _____
de uso del negocio Especificaciones
(bosquejada) suplementarias
del negocio
(refinada)

Modelo de objetos del

negocio

)LJXUD'HWDOOHGHOZRUNIORZGH'HVFULELUHOQHJRFLRDFWXDO

22
 Diseño de software Unidad 1

___ ___ ___

___ ___ ___
___ ___ ___
___ ___ ___
Reglas del Visión del Documento de la
negocio negocio arquitectura del
Client (actualizadas (actualizada) negocio (bosquejada)
Usuario final e )

Mantener las Establecer y Definir la

reglas del ajustar metas arquitectura
negocio del negocio
Analista de
procesos del
negocio

Capturar un Encontrar actores y

vocabulario común casos de uso del
del negocio negocio

Modelo de casos
de uso del
___ ___ ___ negocio
___ ___ ___
___ ___ ___ ___
___ ___ ___ ___
Glosario del Reglas del Evaluación de la ___
negocio negocio organización ___ Caso de uso del
objetivo Especificaciones negocio
___ suplementarias del (bosquejado)
___ negocio
___ ___
___ ___
Visión del ___
negocio ___
Pautas para el
modelado del
negocio

)LJXUD'HWDOOHGHOZRUNIORZGH,GHQWLILFDUORVSURFHVRVGHOQHJRFLR

23
Diseño de software Unidad 1

Estructurar el
Analista de modelo de casos
procesos del de uso del
negocio negocio Usuario final

___
___ ___
Revisor del modelo
___ ___
del negocio
___ ___
Reglas del ___
___ negocio Visión del
negocio Client
 ___
e
___ ___
 ___ ___ ___
___ ___
 Evaluar la ___
organización Revisar el modelo ___
 objetivo ___ ___ de casos de uso del Registro de
Pautas para el revisión
 modelado del
___ negocio
___
negocio
___
Glosario del Modelo de casos
negocio de uso del
negocio

___
___
___
___
Detallar un caso Caso de uso del Especificaciones
de uso del negocio suplementarias
Diseñador del negocio (detallado) del negocio
negocio

)LJXUD'HWDOOHGHOZRUNIORZGH5HILQDUODVGHILQLFLRQHVGHORVSURFHVRVGHOQHJRFLR

24
 Diseño de software Unidad 1

Realización del caso

Encontrar trabajadores de uso del negocio
y entidades del
Cliente Diseñador del
negocio
negocio

___
___
___
___ Evaluar la
Usuario final ___ organización
___ ___ objetivo Modelo de objetos del
Visión del ___ negocio
___
negocio ___ ___
Reglas del
___ ___
negocio
___ Glosario del
___
___ negocio
___
Pautas para el
modelado del ___
Especificaciones
negocio
suplementarias del
negocio

Modelo de casos
de uso del negocio

Capturar el Mantener las reglas del Definir la arquitectura

vocabulario común del negocio del negocio
Analista de procesos
negocio
del negocio

___ ___ ___

___ ___ ___
___ ___ ___
Glosario del negocio Reglas del negocio Documento de la
(refinado) (refinadas) arquitectura del
negocio

)LJXUD'HWDOOHGHOZRUNIORZGH5HDOL]DFLRQHVGHOSURFHVRGHOQHJRFLR

25
Diseño de software Unidad 1

____ ___ ___

____ ___ ___
____
___ ___
Documento de Reglas del Visión del
la arquitectura negocio negocio
del negocio

___ ___
___ ___
Caso de uso del Realización de
___ negocio
___ casos de uso del
Pautas para el Especificaciones
negocio
modelado del suplementarias del
negocio negocio

Detallar un
trabajador del Detallar una entidad
Diseñador del del negocio
negocio
negocio

Trabajador Unidad Entidad del

del negocio organizacional negocio
Usuario final

___
___
Revisor del modelo Revisar el modelo de ___
Cliente del negocio  objetos del negocio Registro de
revisión



)LJXUD'HWDOOHGHOZRUNIORZGH5HILQDUUROHV\UHVSRQVDELOLGDGHV

26
Diseño de software Unidad 1

____
____
____
Analista de procesos Establecer y ajustar Visión del negocio
del negocio metas (refinada)
____
____
____ ____ ____
Reglas del ____ ____
negocio ____ ____
____ Especificaciones Visión del negocio
____ suplementarias del
____ negocio
Documento de
la arquitectura Modelo de casos
del negocio de uso del negocio

Modelo de objetos del ____

negocio ____
____
Usuario final Especificaciones [sistema]
suplementarias
(bosquejo)
Diseñador del Definir requerimientos
negocio de automatización
Cliente

Modelo de casos de uso

[sistema] (bosquejo)

Modelo de análisis
(bosquejo)

)LJXUD'HWDOOHGHOZRUNIORZGH([SORUDUODDXWRPDWL]DFLyQGHORVSURFHVRV

27
Diseño de software Unidad 1

___
___ Usuario final
___
Mantener las reglas del Reglas del Revisor del modelo
negocio negocio del negocio

Analista de procesos ___ Cliente

del negocio ___
Capturar un vocabulario ___
común del negocio
Glosario del negocio
Revisar el modelo de
objetos del negocio

___
___ ___
___ ___
Evaluar la ___
organización
___
objetivo ___ Registro de revisión
___ Entidad del negocio
Pautas para el
modelado del
___ negocio
Modelo de objetos del negocio
___ (sólo las entidades del negocio)
___
Visión del negocio

Detallar una entidad del

Encontrar trabajadores y negocio
Diseñador del entidades del negocio
negocio

)LJXUD'HWDOOHGHOZRUNIORZ'HVDUUROODUXQPRGHORGHOGRPLQLR

28
Diseño de software Unidad 1

&XDGURVUHV~PHQHV


29
Diseño de software Unidad 1

30