Parte

UML y el proceso
unificado
4 El workflow de los requisitos J
5 El workflow de los requisitos II
6 El >vorkflow del análisis orientado a objetos 1
7 El workftow del análisis orientado a objetos 11
8 El workflow del diseño orientado a objetos
9 Los workflows y las fases del proceso unificado
1O Más sobre el UML

Ja parte 2 de este libro consta de siete capítulos con un solo objetivo: enseñarle cómo
realizar el análisis y diseño orientado a objetos mediante el UML y el proceso unificado.
Para promover el aprendizaje, cada paso se enseña de tres maneras. Primero, se da una
explicación de lo que debe hacerse. Luego, se de111ucstra ol paso explicado mediante su
aplicación al caso práctico Osbert Og1esby y finalmente se aplica al caso práctico Funda-
ción MSG.
Los capítulos 4 y 5 se dedican a El worlifl.ow de los requisitos. Dicho con más preci-
sión, se explican Jos pasos y se aplican al caso práctico Osbert Oglcsby en el capítulo 4 y
al caso práctico Fundación MSG en el capítulo 5.
De manera similar, los capítulos 6 y 7 describen El wor/iflow del análisis orientado a
ohjetos. De nuevo, se explica cada paso y luego se aplica al caso práctico Osbert Oglesby
en el capitulo 6 y al caso práctico Fundación MSG en el capítulo 7.
El workjlow del diseiio orientado a objetos es el título del capítulo 8. Enseguida se
dcscdbe el tercer •vorlcftow y luego se aplica a ambos casos prácticos utilizando el mismo
método que en los capítulos 4 a 7.
A continuación todo se integra en el capítulo 9. los workfiows y las/ases del proceso
un(ficado. para asegurar que se ha comprendido a fondo el proceso unificado y cómo apli-
carlo.

61 .jpg

Stephen R. Shach
62 Parte dos UML y el proceso unificado

El lenguaje unificado de modelado (UML: Unified Modeling Language) es el lenguaje

gráfico universal para descr ibir un sistema de información. En los capítulos 3 a 9 se estu-
dia bastante UML de una manera informal con la :finalidad de que este libro se comprenda
mejor y se resuelvan los problemas, incluidos los proyectos de análisis y diseño de sistemas
y el proyecto de integración. Sin embargo, para ser un profesional de tecnología de la infor-
mación exitoso, se requiere un conocimiento más profundo del UML. Esta es la razón por la
cual en la parte 2 se incluye el capítulo 10, Más sobre el UML.

62.jpg

Stephen R. Shach
-~ ::>ítulo

El workflow
de los requisitos 1
Objetivos de aprendizaje
Después de estudiar este capítulo usted podrá:
• Realizar el workflow de los requisitos.
• Preparar el modelo de negocios inicial.
• Preparar los requisitos.

La únjca frase que ningún analista de sistemas querrá escuchar nunca de un cliente es: "Sé
que éste es el sistema de información que yo pedí, pero no es lo que quería". En otras pa-
labras, cuando se realiza·el workflow de los requisitos, la tarea principal de Jos analistas de
sistemas del equipo de requisitos es trabajar con el cliente y con los futuros usuarios del
sistema de información para determinar qué requieren, lo cual tal vez no sea lo que creen
necesitar. (Para comprender mejor este problema lea el Recuadro 4.1, Información de in-
terés.)

.1 Determinar cuáles son las necesidades del cliente

A primera vista, determinar qué necesita el cliente es sencillo, basta con preguntárselo. Sin
embargo, hay dos razones por las cuales este método directo por lo general no funciona
muy bien.
Primero, tal vez el cliente no aprecie lo que está ocurriendo en su empresa. Por ejemplo,
no tiene sentido para un cliente pedir un sistema de infonnación más rápido cuando la ra-
zón real por la cual el sistema de información actual tiene un tiempo de respuesta tan largo
es que la base de datos está mal diseñada. Lo que se necesita hacer es reorganizar y mejo-
rar la manera en que se alJnacenan los datos en el sistema de información. Un sistema de

63.jpg

Stephen R. Shach
 5.1. Hayakawa (1906-1992), senador de Estados Unidos por California, una vez le comentó
a un grupó de reporteros: "Sé que ustedes piensan que comprendieron lo que creen que di-
je, pero no estoy seguro de que se hayan dado cuenta que lo que escucharon no es lo que
quise decir". Esta excusa se aplica de igual manera al problema del análisis de los requisitos.
Los analistas de sistemas escuchan tas solicitwdes de sus clientes, pero lo que escuchan no
es lo que el clíente debería decir.
Esta cita se ha atribuido erróneamente al ex candidato a la presidencia de Estados Uni-
dos George Romney (1907-1995), quien una vez anunció en una conferencia de prensa:
"No dije que no lo dije. Dije que no dije que lo dije. Quiero dejar eso muy en claro." La
"aclaración" de Romney pone de relieve otro reto del análisis de sistemas, es fácil malinter-
pretar lo que dice et cliente.

información nuevo será igual de lento. O, si el cliente opera una cadena de tiendas al me-
nudeo que no produce, tal vez pida un sistema de información de administración financie-
ra que i-efieje elementos tales como ventas, salarios, cuentas por pagar y cuentas por cobrar.
Un sistema de información como éste tendrá poca utilidad si la razón de las pérdidas son
las fugas (robo por parte de los empleados y los clientes). Si ése es el caso, entonces se re-
quiere un sistema de control de existencias en vez de uno de información de administración
financiera.
Pero la razón principal por la cual un cliente pide con tanta frecuencia el sistema de in-
formación equivocado es que los sistemas de información son complejos. De por sí ya es
dificil para un analista de sistemas visualizar un sistema de información y su funcionali-
dad; el problema es mucho peor para el cliente, quien, por lo general, no es un experto en
tecnología de la información.
Sin la asistencia de un analista de sistemas experimentado, el cliente puede ser una fuen-
te mala de información respecto de lo que se necesita desarrollar. Por otra parte, a menos
que se comunique con el cliente, no hay otra manera de averiguar lo que realmente se ne-
cesita.
La solución es obtener esta información inicial como una entrada al proceso unificado.
Al seguir los pasos del proceso unificado, el analista de sistemas podrá determinar las ne-
cesidades reales del cliente.

4.2 Resumen del workflow de los requisitos

El proceso unificado es iterativo [Jacobson, Booch y Rumbaugh, 1999]. En el caso del
workftow de los requisitos, el primer paso es obtener una comprensión del dominio de apli-
caciones (o dominio, para abreviar); es decir, el entorno de negocios específico en el cual va
a operar el sistema de infom1ación. El dominio podría ser bancario, de fabricación de auto-
móviles o de ventas al por menor. Una vez que se comprende el dominio, se construye un
modelo de negocios; es decir, se usan los diagramas VML para describir los procesos de ne-
gocios del cliente. Se utiliza el modelo de negocios para determinar cuáles son los requisi-
tos del cliente. Luego se itera (recuerde de la sección 2.5 que "iterar" significa repetir).

64.jpg

Stephen R. Shach
 Capítulo 4 El workf/ow de los requisitos I 65

GURA 4.1
Diagrama del
rldlow de los
.nisitos.
Obtener una comprensión inicial del dominio

Construir un modelo inicial de negocios

Preparar un conjunto inicial de requisit os

¿Los
requisitos
>-S_í~,e

Obtener una comprensión más profunda del dominio

Refinar el modelo de negocios

Refinar el conjunto de requisitos

En otras palabras, se comienza con una comprensión inicial del dominio y se usa la in-
formación para construir el modelo de negocios inicial. Éste se utiliza después para prepa-
rar un conjunto inicial de los requisitos del cliente. Luego, a la luz de lo que se ha aprendi-
do sobre los requisitos del cliente, se obtiene una comprensión más profunda del dominio
y se usa este conocimiento para refinar el modelo de negocios y, por consiguiente, los re-
quisitos del cliente. La iteración continúa hasta que se está satisfecho con el conjunto de
requisitos que se ha obtenido. En este punto se detiene la iteración. Lo anterior se expresa
en el diagrama de flujo de la figura 4 .1.
El proceso de descubrir los requisitos del cliente se llama obtencüm de los requisitos (o
captura de los requisitos). Una vez que se ha redactado el conjunto inicial de requisitos, se
sigue con el proceso de refinarlos y extenderlos, al cual se le llama análisis de los requisi-
tos .

.3 Comprensión del dominio

La primera tarea de cada miembro del equipo de requisitos es familia1izarse con el domi-
nio de aplicaciones, a menos que él o ella ya tengan experiencia en esa área. Es particular-
mente importante utilizar la terminología correcta cuando se comunique con el cliente y
con los usuarios potenciales del sistema de información. Después de todo, es dificil ser to-

65.jpg

Stephen R. Shach
66 Parte dos UML y el proceso unificado

mado en serio por alguien que trabaja en un dominio específico a menos que el analista de
sistemas utilice el mismo vocabulario. Aún más importante, el uso de una palabra inapro-
piada puede conducir a una mala interpretación, provocando que al final se entregue un sis-
tema de información con fallas. El mismo problema puede surgir si los miembros del equi-
po de requisitos no comprenden las sutilezas de 1a terminología del dominio.
Por ejemplo, a una persona no especializada palabras como cheque, letra de cambio y
orden de pago puede parecerle que tienen el mismo significado, pero para un banquero son
términos distintos. Si un analista de sistemas no se da cuenta de que e l banquero utiliza los
tres términos de una manera precisa y si éste supone que aquél está familiarizado con las
diferencias entre los términos, el analista puede tratar los tres términos como equivalentes;
por to tanto, es posible que el sistema de información bancaria resultante contenga fallas
que provoquen violaciones a las regulaciones bancarias o pérdidas financieras serias para
et banco. Todos los profesionales de tecnología de la información desean que la salida de
todo sistema de información sea inspeccionada meticulosamente por una persona antes
de tomar decisiones basadas en dicho sistema, pero dada la fe cada vez mayor, que lapo-
blación tiene en las computadoras, es verdaderamente una imprudencia basarse en la pro-
babilidad de que se haga una revisión como ésta. Así que no es exagerado ni mucho menos
decir que una mala interpretación de la terminología podría provocar que los profesionales
de la tecnología de la información sean demandados por negligencia.
Una manera de abordar el problema de la terminología es construir un glosario, una lis-
ta u~ palabras técnicas utilizadas en el dominio, junto con su significado. Las entradas ini-
ciales se insertan en el glosario mientras los miembros del equipo están ocupados apren-
diendo tanto como pueden sobre el dominio de aplicaciones. Luego, el glosario se actualiza
siempre que los miembros del equipo encuentran nuevos términos. Un glosario no sólo re-
duce la confusión entre el cliente y los analistas de sistemas, sino que también es útil para
disminuir los malentendidos entre los miembros del equipo de análisis de sistemas.
La manera más fácil de construii- un glosario es usar una hoja de cálculo o un procesa-
dor de palabras. Se forman dos columnas y se introduce cada palabra técnica (en orden al-
fabético) en la columna izquierda y su s ignificado en la columna derecha. De vez en cuan-
do el glosario puede imprimirse y distribuirse entre los miembros del equipo o descargarse
a un PDA (por ejemplo, una Palm Pilot).
Se verá cómo se realiza este primer paso en el workflow de los requisitos al considerar el
caso práctico Osbert Oglesby, el primero de dos que se utilizarán a lo largo de este libro.

4.4 Comprensión inicial del dominio:

caso práctico Osbert Oglesby
Osbert Oglesby, el renombrado corredor de arte, necesita un sistema de información que le
ayude a comprar y vender cuadros. Osbert se especializa en comprar y vender cuadros im-
presionistas franceses. Sin embargo, comprará virtualmente cualquier cuadro si considera
que puede obtener una ganancia cuando lo venda en su galería, Les Objets d 'Orient.
Se entrevistará a Osbert con el fin de obtener información detallada sobre cada aspecto
de su negocio. Pero antes de hacerlo, es necesario adquirir conocimiento del medio; es de-
cir, información sobre cuadros y el negocio del arte en general. Esta información básica
"Qetmi.t\."tá C()ffi"Qtet\d.e"t cu.a\0¡_u.\e"1: \.é"t"ffii\'.\() \.éct\\C() u.~aü.<:::1 ~()\'. (J~\)e"t\ cu.at\Ü.() \\a"':fa u.!\a "l:eu.t\\()\'.\

66.jpg

Stephen R. Shach
 Capítulo 4 El workflow de los requisitos I 67

GURA 4.2 El glosario inicial del sistema de información de Osbert Oglesby.

a:.saj e Un cuadro de una escena de la naturaleza.

~.::::-amaestra Un cuadro de excelencia indudable .
.:}:"a representativa Una obra representativa hecha por un artista que ha pintado una obra maestra
anterior o posteriormente.
':'éc:"lica Un criterio de clasificación. El material con el cual se pinta una obra de arte. Véase
también óleo, acuarela.
Una técnica. Abreviatura de "cuadro al óleo".
t ipo Un cuadro que no es ni una obra maestra ni una obra representativa.
tema Un tema que no es un paisaje, un retrato o una naturaleza muerta.
Un cuadro de una o más personas.
Un criterio de clasificación. Un cuadro se clasifica como obra maestra, obra
representativa u otro tipo, dependiendo de su calidad.
a ::u r aleza muerta Un cuadro de objetos inanimados.
':'~!"la Un criterio de clasifi cación. Los temas incluyen paisaje, retrato y naturaleza muerta.
J.cuare l a Una técnica. Abreviatura de "pintura con base de agua".

coµ él. Además, si se sabe algo sobre el negocio del arte en general, antes de reunirse con
él se podrá marcar cualquier aspecto aparentemente inusual de la manera en que Osbert ha-
ce negocios. Luego se Je preguntará sobre esos puntos. En algunos casos podría sugerirle
que, al estar al tanto de lo que la mayoría de sus competidores está haciendo, tal vez pueda
aumentar la rentabilidad de su negocio. Poro en otros casos, aspectos únicos de las prácti-
cas empresariales de Osbert pueden darle una ventaja competitiva. Es vital incorporar es-
tos casos en el sistema de información computarizado que se está construyendo para él.
Con el fin de aprender sobre pintura y el negocio del arte en general se visitaron los si-
tios web de dos museos de arte importantes y de dos corredores de arte. Se descubrió que
hay muchas maneras distintas de clasificar los cuadros. Una es considerar la técnica; es de-
cir, el material con el cual se pintó la obra de arte. La técnica más popular es la pintura al
óleo, pero algunos cuadros más pequeños se pintan con acuarela. Otras técnicas utiliza-
das a veces incluyen lápiz, pastel y lápices de colores, pero con menos frecuencia. Se pone
esta información en el glosario, el cual aparece en la figura 4.2.
Una segunda manera de clasificar un cuadro es por tema. El tema más popular es el re-
trato de una persona. Otros temas comunes incluyen paisajes y un objeto inanimado co-
mo un florero , un frutero y así por el estilo, a los cuales se les llama naturaleza muerta.
Esta información se añade al glosario.
Una tercera clasificación es Ja calidad del cuadro. Un cuadro de excelencia indudable
recibe el nombre de obra maestra. También existe la obra representativa, la cual es un
cuadro inferior hecho por un artista que ha pintado una obra maestra. No obstante, la gran
mayoría de los cuadros no son de ninguno de estos dos tipos. Esta información también se
pone en el glosario, como se muestra en la figura 4.2.

4.5 Modelo de negocios

Una vez que los miembros del equipo de requisitos se han familiarizado con el lenguaje,
el siguiente paso es construir el modelo de negocios inicial , que es una descripción de los

67.jpg

Stephen R. Shach
68 Parte dos UML y el proceso unificado

procesos de una empresa. Por ejemplo, algunos de los procesos de negocios de un banco
incluyen aceptar depósitos de los clientes, conceder préstainos a los clientes y hacer inver-
siones.
La razón para consn·uir un modelo de negocios es, primero, que proporcione una com-
prensión de los negocios del cliente como un todo. Con este conocimiento es posible acon-
sejar al el iente respecto de qué porciones del sistema de información computarizai-. De ma-
nera opcional, si la tarea es ampliar un sistema de información computarizado existente, es
necesario entender el negocio como un todo para determinar cómo incorporar la extensión
y aprender qué partes del sistema de información existente necesitan modificarse para aña-
dir la nueva pieza.
Para construir un modelo de negocios un analista de sistemas debe comprender con to-
do detalle los diversos procesos de negocios. Por ejemplo, los procesos de negocios de
una empresa de servicios de banquetes incluyen comprar los ingredientes, preparar los
alimentos y servir la comida. Estos procesos ahora están refinados; es decir, analizados
con gran detalle. Por ejemplo, el proceso "comprar ingredientes" consta de cuatro subpro-
cesos:
• El encargado del servicio de banquetes ordena los ingredientes a un mayorista.
• El mayorista entrega los ingredientes al encargado del servicio de banquetes.
• El mayorista envía una factura a l encargado del servicio de banquetes.
• El encargado del servicio de banquetes paga la factura.

Pueden utilizarse una serie de técnicas diferentes para obtener la información necesaria
para construir el modelo de negocios, principalmente las entrevistas.

4.5. 1 Entrevistas
Los miembros del equipo de requisitos se reúnen con miembros de la empresa del cliente
hasta que están convencidos de que han obtenido toda la información relevante del c lien-
te y de los futuros usuarios del sistema de información objetivo.
Hay dos tipos básicos de preguntas. Una pregunta cerrada requiere una respuesta espe-
cífica. Por ejemplo, se podría preguntar al cliente cuántos vendedores emplea la compañía
o qué tan rápido se requiere un tiempo de respuesta. En cambio, las preguntas abiertas se
formulan para animar a hablar a la persona que se está entrevistando. Por ejemplo, al pre-
guntar al c liente: "¿por qué su sistema de información actual es deficiente?", podría expli-
car muchos aspectos de su método para hacer negocios. Algunos de estos hechos tal vez no
salgan a relucir si la pregunta fuera cerrada.
Asimismo, hay dos tipos básicos de entrevistas, a saber, estructuradas y no estructura-
das. En las primeras se plantean preguntas preplaneadas, con frecuencia cerradas. En las
segundas el entrevistador puede iniciar con una o dos preguntas cerradas preparadas, pe-
ro las preguntas subsiguientes se p\antean basándose en las respuestas que proporciona la
persona a quien se está entrevistando. Es probable que muchas de las preguntas subsi-
guientes sean de naturaleza abierta con el fin de proporcionar al entrevistador información
variada.
Al mismo tiempo, no es buena idea que la entrevista no tenga estructuración. Es poco
probable que invitar al cliente con un "cuénteme sobre su negocio" produzca mucho cono-
cimiento relevante. En otras palabras, las preguntas deben pJantearse de tal manera que se

68.jpg

Stephen R. Shach
 Capítul o 4 El workflow de los requisitos I 69

estimule a la persona a dar respuestas variadas, pero siempre dentro del contexto de la in-
formación específica requerida por el entrevistador.
Real izar una buena entrevista no siempre es fácil. Primero, el entrevistador debe estar
comp letamente fami liarizado con el terreno de las aplicaciones. Segundo, no tiene sentido
entrevistar a un miembro de la empresa del cl iente si el entrevistador ya ha tomado una de-
cisión con respecto a las necesidades del cliente. No importa qué se haya dicho previamen-
te al entrevistador o qué haya aprendido é l por otros medios, debe acercarse a cada entre-
vista con Ja intención de escuchar con atención lo que tiene que decir la persona a quien
entrevista, mientras que repdme las nociones preconcebidas con respecto a la compañía del
cliente o a las necesidades de los clientes y los usuarios potenciales del sistema de informa-
ción en desarrollo.
Una vez concluida la entrevista, el entrevistador debe preparar un informe por escrito
que resuma los resultados. Se recomienda amp li amente dar una copia del informe a la per-
sona que se entrevistó, tal vez quiera esclarecer ciertas afirmaciones o añadir puntos que se
pasaron por alto.

4.5.2 Otras técnicas

Las entrevistas son la técnica principal para obtener información para el modelo de nego-
cios. Es decir, las entrevistas siempre se realizan, no importa que otras técnicas puedan uti-
lizarse también. En esta sección se describen otras opciones que pueden usarse junto con
las entrevistas.
Una manera de obtener conocimiento sobre las actividades de la empresa del cliente es
enviar un cuestionario a los miembros importantes de dicha empresa. EsLa técnica es útil
cuando deben determinarse las opiniones de, por ejemplo, cientos de indiv iduos. Además,
una respuesta escrita muy bien pensada de un empleado quizá sea más precisa que una res-
puesta verbal inmediata a una pregunta planteada por un entrevistador. Sin embargo, una
entrevista sin estructura realizada por un entrevistador metódico que escucha con atención
y formula preguntas que amplían las respuestas iniciales, per mite obtener información mu-
cho más adecuada que un cuestionario redactado cuidadosamente. Debido a que los cues-
tionarios se planean con antelación, no hay manera de que una pregunta pueda plantearse a
partir de la respuesta a otra pregunta.
Una manera diferente de obtener los requisitos es examinar los diversosformuiarios uti-
lizados por el negocio. Por ejemplo, un formulario de una imprenta podría reflejar el núme-
ro de prensa, el tamaño del rol lo de papel, la h umedad, la temperatura de la tinta, la tensión
del papel y así por el estilo. Los distintos campos de este forrnula1io proporcionan datos so-
bre el flujo de los trabajos de impresión y la importancia relativa de los pasos en el proce-
so de impresión. Otros documentos, como los proced imi entos operativos y las descripcio-
nes del trabajo, también pueden ser herramientas poderosas para saber de una manera
exacta qué se está haciendo y cómo. Esta información global respecto de cómo se hacen los
negocios en la actualidad puede ser muy útil para determinar las necesidades del cliente.
Por lo tanto, un buen analista de sistemas estudiará con detalle la documentación del clien-
te, Lratándola como u n a fuente invaluable de información que puede conducir a una evalua-
ción precisa de sus necesidades.
Otra manera de obtener esta información es la observación directa de los usuarios; es
decir, los 1niembros del equipo de r equisitos que observan y anotan las acciones de los em-
picados mientras llevan a cabo sus tareas. Una versión moderna de esta técnica es instalar

69.jpg

Stephen R. Shach