Anlisis en un Modelo de Procesos CSCW.

Organizacin, Roles
e Interaccin Persona-Ordenador-Persona
Victor M. R. Penichet, Maria D. Lozano, Jos A. Gallud, Ricardo Tesoriero
Departamento de Sistemas Informticos
Universidad de Castilla-La Mancha
02071 Albacete, Espaa
{ victor.penichet, maria.lozano, jose.gallud }@uclm.es; ricardo@dsi.uclm.es

Resumen
Este artculo presenta una propuesta para llevar a
cabo el proceso de anlisis para entornos CSCW,
una etapa del modelo de procesos esencial en este
tipo de sistemas. La metodologa presentada para
abordar la etapa de anlisis proporciona los
mecanismos suficientes para especificar la
organizacin de los participantes de un sistema,
los roles que desempean, la interaccin de los
usuarios con el sistema y la interaccin entre los
participantes a travs del sistema, es decir, la
interaccin persona-ordenador-persona.

1. Introduccin
La etapa de anlisis de cualquier sistema es una
etapa fundamental que posibilita el estudio en
profundidad de determinadas caractersticas del
dominio del problema. Se trata de descubrir el qu
describiendo los requisitos del sistema sin detallar
aspectos de implementacin. Se estudian los
elementos del dominio del problema y sus
relaciones. Se trata de acercar la especificacin
del sistema recogida en la elicitacin de requisitos
en un lenguaje ms cercano a la persona a una
especificacin ms cercana al desarrollador.
Sin duda, el lenguaje ms utilizado para
modelar la realidad es UML, actualmente en su
versin 2.0 [9]. El modelado de sistemas
tradicionales se ha abordado por medio de
diagramas de clases, objetos y paquetes que
describen la parte esttica, estructural del sistema.
Capturan la organizacin fsica de los elementos
en el sistema, cmo se relacionan [12].
Para abordar el modelado del comportamiento
de los elementos en el sistema, esto es, para
describir la parte dinmica, se suelen emplear
diagramas de actividades esencialmente. Estos
diagramas forman parte de la metodologa de

algunos modelos de procesos muy conocidos

como RUP [6].
Sin embargo, estos mecanismos de
representacin de la realidad no facilitan
especificar naturalmente la interaccin personaordenador-persona que tiene lugar en los sistemas
CSCW [4][5][7][14], sistemas que, por otro lado,
son cada da ms habituales debido a las
crecientes necesidades de los usuarios y al avance
de las tecnologas y las infraestructuras de red.
Algunas
otras
aproximaciones
como
AMENITIES o, ms recientemente, CIAM
abordan esta problemtica desde una perspectiva
diferente. AMENITIES (A MEthodology for
aNalysis and desIgn of cooperaTIve systEmS) [3]
es una metodologa que surge con el objeto de
abordar la complejidad de los entornos
colaborativos. Se centra en el concepto de grupo y
cubre aspectos relevantes de su comportamiento y
estructura.
Por otro lado, CIAM (Collaborative
Interactive Applications Methodology) [8] es un
marco metodolgico basado en un conjunto de
modelos que permiten a los ingenieros guiar el
proceso de diseo y desarrollo de la interfaz de
usuario en aplicaciones interactivas para el trabajo
en grupo.
La metodologa que se propone en este
artculo para el anlisis de sistemas CSCW
posibilita un anlisis de la estructura y del
comportamiento del sistema centrado en el
usuario y dirigido por las tareas que se
desempean. En el estudio de la estructura,
adems de los objetos del sistema se tiene en
cuenta quines son y de qu manera participan,
cmo se organizan y qu roles desempean. El
estudio
del
comportamiento
se
aborda
describiendo la funcionalidad desde un punto de
vista CSCW, abordando sus caractersticas tpicas
[15], as como sus caractersticas espaciotemporales, muy importante en estos sistemas [7].

La descripcin del trabajo realizado por medio

de un sistema, es decir, lo que se hace en l, se
puede representar con flujogramas, mquinas de
estados finitos, modelos de workflow, diagramas
de flujo de datos, etc. Una de las tcnicas ms
utilizadas es el uso de modelos de tareas. Tambin
estos modelos han tenido en cuenta las
colaboraciones que se dan en un sistema CSCW
pero sobre todo han permitido modelar la
interaccin del usuario con el sistema
[10][13][16]. Una de las notaciones ms utilizadas
para ello es CTT [10], notacin que ha sido
adoptada como parte de la metodologa que se
presenta. Sin embargo, se ha elaborado un
diagrama adicional que facilita el modelado de la
colaboracin entre los participantes de un sistema
CSCW de un modo ms natural.
El resto del artculo se organiza de la siguiente
manera. En el apartado 2 se enumeran los pasos
de la metodologa que facilitara el anlisis de
sistemas CSCW. En el apartado 3 se presenta un
sencillo caso de estudio para ilustrar el modelado.
Los apartados 4 y 5 describen los dos grandes
pasos en los que se divide el anlisis as como los
diagramas empleados para su modelado. El
apartado 6 describe la necesidad de la trazabilidad
entre etapas as como en el interior de la etapa
para mantener la coherencia del modelado.
Finalmente, el apartado 7 muestra algunas
conclusiones del trabajo.

2. Pasos en el anlisis de sistemas CSCW

La Figura 1 muestra un esquema de los pasos que
se siguen en la etapa de anlisis del modelo de
procesos que se presenta en este artculo:
identificacin
y
descripcin
de
roles,
identificacin y descripcin de tareas, anlisis de
la estructura del sistema y anlisis del
comportamiento del sistema.
El anlisis de un sistema colaborativo
comienza con una identificacin previa de roles y
tareas a partir de la informacin recabada en la
elicitacin de requisitos. Una vez identificados los
primeros roles y tareas, se puede comenzar la
descripcin de los mismos y en paralelo los
primeros diagramas de tareas (TD), colaboracin
(CD) y estructura organizativa (OSD). Estos
diagramas se describirn en sucesivos apartados.
Por un lado, la identificacin de los primeros
roles permite al analista realizar un primer esbozo
de la estructura organizativa de los actores del
sistema. Este diagrama, junto con el diagrama de
clases de UML modelan la estructura del sistema.
As mismo, la identificacin de las primeras tareas
permite ordenarlas, creando un primer esbozo de
los diagramas de tareas y los diagramas de
colaboracin, que modelan el comportamiento de
los actores del sistema.

Elicitacin de Requisitos
Actores

Requisitos

Anlisis
Identificacin de Roles Tareas
Identificacin y
Descripcin de Roles

Identificacin y
Descripcin de Tareas

Estructura y Comportamiento
Estructura
Clases

Comportamiento

OSD

CD

TD

Diseo

Figura 1. Pasos de la etapa de anlisis en entornos CSCW

Por otro lado, del anlisis de las primeras

versiones de los diagramas surgen nuevos roles y
tareas. Tras esa primera identificacin de roles y
tareas, un proceso iterativo de refinamiento
permitir obtener un modelo de mayor calidad,
que permita obtener una especificacin completa
del sistema.
Del mismo modo que la trazabilidad entre las
etapas de elicitacin de requisitos y anlisis
permiten obtener especificaciones coherentes y
completas, es necesario tener en cuenta una
trazabilidad intra-etapa entre sus pasos. Dicha
trazabilidad se detallar ms adelante.

3. Caso de estudio
Con el objetivo de ilustrar los conceptos
novedosos introducidos en este artculo se
presenta este sencillo caso de estudio. Se trata de
una aplicacin groupware que debe permitir la
elaboracin de un documento entre varios autores
a travs de Internet. Cuando los autores del
documento tienen un borrador, uno de ellos se
encarga de enviar, por medio de la misma
aplicacin, el documento candidato a ser
publicado a unos revisores. Los revisores analizan
el documento y dan su opinin acerca de si ha de
ser publicado o no. Un documento pblico puede
ser ledo por todos los usuarios del sistema,
aunque no sean autores o revisores.
A lo largo del artculo, los ejemplos
presentados se refieren ejemplo. Lgicamente no
se hace una especificacin completa por falta de
espacio. Slo se aclaran algunos puntos.

4. Identificacin de roles y tareas

En una primera etapa de elicitacin de requisitos
se identificaran, entre otras cosas, los actores del
sistema y la informacin relativa a los requisitos,
que darn lugar a los roles que los usuarios
pueden desempear y las tareas que tienen que
llevar a cabo en el sistema [11]. La relacin entre
roles y tareas es tan estrecha que la identificacin
y descripcin de roles y tareas ir muy ligada y en
paralelo.
Conocidos los requisitos del sistema y los
actores que intervienen en l, se pueden generar
una serie de roles que determinen qu hace quin.
Se trata de algo determinante en la organizacin
del diseo de un sistema colaborativo.
Para describir los roles y las tareas
identificados, se emplearn unas plantillas

similares a las utilizadas en la elicitacin de

requisitos por Durn [2]. Son plantillas ms
sencillas en cuanto a nmero de metadatos que
describen el concepto en cuestin, pero necesarias
para ubicar rpidamente todos los roles y tareas
del sistema.
Adems
se
emplearn
matrices
de
rastreabilidad [2] que ponen en relacin actores
con roles y requisitos con tareas. Las matrices de
rastreabilidad simplemente muestran de forma
explcita informacin que ya est recogida, con el
objetivo de facilitar al analista, desarrollador, etc.
el acceso a la misma y llevar a cabo posteriores
actividades de mantenimiento y evolucin. Una
ltima matriz pone en relacin las tareas asociadas
a cada rol.
La identificacin de los roles y las tareas, su
descripcin y el uso de las plantillas y las matrices
de rastreabilidad se describen en los siguientes
apartados.
4.1. Identificacin y descripcin de roles
El concepto de rol se ha definido como conjunto
de tareas que puede desempear un actor. Un
actor es lo que es debido al rol que desempea en
cada momento en el sistema [11].
En [1] se dice que un rol (user role) es una
coleccin abstracta de necesidades, intereses,
expectativas,
comportamientos
y
responsabilidades, y que conjuntos diferentes de
estos elementos, constituyen roles diferentes.
Un modelo de roles es una lista de los roles
que hay en el sistema, descritos en trminos de los
comportamientos, responsabilidades, necesidades,
intereses y expectativas que lo caracterizan. Cada
rol ha de tener un nombre asociado que capture su
naturaleza.
La Figura 2 muestra los pasos que se siguen
en la identificacin y descripcin de los roles en
este artculo, pasos que se describen a
continuacin.
Para construir ese listado de roles, Constantine
[1] propone una serie de interrogantes previos:
Quines usaran o podran usar el sistema?
Cul es la clase general o el grupo al que
pertenecen?
Qu distingue el cmo puedan utilizar el
sistema?
Qu caracteriza su relacin con la
aplicacin?
Qu necesitan de la aplicacin?

Cmo se comportan en relacin a la

aplicacin y cmo esperan que la aplicacin
se comporte?
Identificacin y Descripcin de Roles
PASO 1
Interrogantes y generalizacin de tipos de
actores: Listado de Candidatos
PASO 2
Refinamiento: Listado de Roles del Sistema
PASO 3
Descripcin de los Roles: modelo organizativo
PASO 4
Descripcin de los Roles: modelo de contexto
Diagramado
Realizacin de los diagramas correspondientes
para realizar los modelos

Figura 2. Pasos en la identificacin y descripcin de

roles

Para identificar los roles se suele comenzar

pensando en usuarios (agentes o grupos)
particulares, reales, y despus se va generalizando
y abstrayendo hasta llegar al rol. En [1] se
propone la tcnica tormenta de ideas o
brainstorming para, partiendo de una lista de roles
candidatos, llegar al modelo de roles definitivo.
Del estudio de la informacin recogida y
elaborada en la elicitacin de requisitos, se pueden
extraer los diferentes roles que se necesitan en el
Tabla 1.

sistema para que sean desempeados por los

usuarios finales (actores en general) que harn uso
de la aplicacin.
Los roles identificados se deben agrupar por
roles similares con los objetivos de evitar tener
roles demasiado parecidos que realmente pudieran
ser uno solo, evitar duplicados, simplificar y
generalizar el modelo, etc. [1]. Es un paso de
refinamiento.
Los roles se describirn empleando una
plantilla como la que se muestra en la Tabla 1, con
los metadatos utilizados en la descripcin de los
roles identificados. Puesto que los roles se
describen en base a las tareas, hay una matriz que
pone en relacin explcita estos conceptos (ver
apartado 6). Con estos metadatos se obtiene la
informacin necesaria sobre los roles del sistema
para el modelo de organizacin:
Los tres primeros campos (Versin, Autores,
Fuentes) son comunes a las plantillas de
elicitacin de requisitos y su significado es el
mismo [2].
Los roles pueden ser desempeados por los
actores si cumplen ciertas restricciones. Una
Capacidad
es
una
habilidad
o
responsabilidad asociada a un actor que le
permite desempear roles y llevar a cabo
tareas [3]. Por lo tanto, para que algn actor
pueda desempear un rol, ste debe tener unas
determinadas Habilidades, y se le pueden
exigir unas determinadas Responsabilidades,
necesarias para que lo pueda hacer.

Descripcin del rol Writer a partir de la plantilla para la descripcin de los Roles del sistema: modelo
organizativo

Rol- 1

Versin
Autores
Fuentes
Descripcin

Responsabilidades

Habilidades
Permisos
Comentarios

Writer
v1.0 (22 marzo, 2007)
Victor M. R. Penichet (LoUISE)
Estudio interno (LoUISE)
Un usuario del sistema que desempee este rol puede elaborar documentos.
Las responsabilidades que se requieren de un actor para que pueda desempear
este rol son las siguientes:
R1: Es el responsable directo de cuanto se escriba en el documento
R2: El contenido ha de ser original
R3: Debe introducir contenidos
Las habilidades que se requieren de un actor para que pueda desempear este
rol son las siguientes:
H1: Capacidad investigadora
H2: Capacidad de expresin
Puede escribir en los documentos, crearlos, modificarlos y destruirlos.
No hay ningn comentario adicional.

Los actores que desempeen un cierto rol,

normalmente tendrn una serie de Permisos o
privilegios para poder realizar ciertas acciones
en el sistema.
La Descripcin esboza cmo es ese rol,
mientras que los Comentarios dan algn tipo
de informacin adicional.
Para el ejemplo mostrado en el apartado 3,
tras su estudio se identificaran una serie de roles
que desempearan los actores del sistema. La
identificacin de los roles se habra realizado en la
etapa de elicitacin de requisitos, por lo que no se
mostrar en detalle.
Los roles identificados son los siguientes:
Writer, para aquellos usuarios autores que
puedan escribir un documento.
Chair_writer, para aquellos que puedan tomar
la decisin de enviar al proceso de revisin un
documento candidato.
Reviewer, para los usuarios que pueden ser
revisores de documentos candidatos.
Chair_reviewer, para revisores que adems
puedan decidir si un documento puede ser
publicado.
Notifier, para agentes que informarn
automticamente a los autores del resultado
del proceso de revisin y a los lectores de si
hay un nuevo documento publicado.
Reader, para los actores del sistema que
puedan leer documentos pblicos.
La Tabla 1 muestra la descripcin, a modo de
ejemplo, del rol Writer.

1:M. Si hay una tarea para resolver el requisito,

solo que esta tarea es en realidad una tarea
compuesta. Las tareas resultantes de esa
descomposicin surgen en esta etapa de anlisis.
El nmero de tareas identificadas se ir viendo
incrementado con el estudio y el anlisis de las
mismas, principalmente por dos motivos: por
descomposicin de tareas complejas en otras ms
sencillas y por la identificacin de nuevas tareas.
Se trata de describir el trabajo que se debe realizar
en el sistema.
Como se ha comentado con anterioridad, la
notacin CTT para modelar tareas se ha utilizado
extensamente y es el diagrama seleccionado en
este artculo para representar las tareas.
Como se ver en los prximos apartados, CTT
permite modelar la interaccin del usuario con el
sistema, sin embargo la interaccin personaordenador-persona, es decir, la interaccin entre
las personas a travs de las mquinas no se
modela con facilidad. Para solventar esta situacin
proponemos un nuevo diagrama que modela la
colaboracin entre usuarios.
As mismo, se describen las tareas por medio
de plantillas similares a la empleada para la
descripcin de los roles.
Los metadatos que aparecen en la plantilla
para la descripcin de las tareas son los siguientes:
Los tres primeros campos (Versin, Autores,
Fuentes) son comunes a las plantillas de
elicitacin de requisitos y su significado es el
mismo [2].

4.2. Identificacin y descripcin de tareas

1
R

El concepto de tarea se ha definido como una

porcin de trabajo necesaria para lograr un
objetivo determinado [11]. Al iniciar el anlisis
del sistema se podra decir que siempre hay una
tarea para resolver un requisito identificado en la
etapa de elicitacin de requisitos. Existe una
relacin 1:1 entre los conceptos requisito y tarea,
fruto de esa equivalencia semntica inicial.
Siempre hay una tarea, aunque sea abstracta, que
resuelve un requisito.
En la etapa de anlisis, algunas tareas se
descomponen en otras y as sucesivamente hasta
llegar a otras que son atmicas y no se pueden
dividir ms. Tal y como se expresa en la Figura 3,
en esta etapa es probable que la relacin entre
requisitos y tareas ya no sea 1:1 sino ms bien

1
T

*
T

T
- Al comenzar el anlisis desde
la etapa de elicitacin de
requisitos, siempre hay una
tarea, aunque sea abstracta,
que resuelve un requisito.
- En el anlisis, la tarea se
descompone en otras, cada vez
ms concretas y de menor
granularidad, hasta llegar a
tareas atmicas.

Figura 3. Relacin entre requisitos y tareas en la etapa

de anlisis

Objetivo representa el subproblema al que est

asociada la tarea. El conjunto de tareas
asociadas a l, resuelven este objetivo del
sistema, este subproblema.
Requisito muestra la relacin de esta tarea con
alguno de los requisitos identificados en la
etapa anterior.
Descripcin
permite
introducir
los
comentarios necesarios para saber qu hace la
tarea
Tarea a la que Pertenece en caso de que
forme parte de otra.
Objetos. Las tareas estn relacionadas o
afectan a algunos objetos del dominio del
sistema que deben mostrarse de manera que el
diseador sea consciente de ello. Los objetos
del sistema y sus relaciones se representan,
como se ver posteriormente, por medio del
clsico diagrama de clases de UML.
Modo de Ejecucin representa una de las
caracterizaciones introducidas en el modelo.
Las tareas pueden ser de Usuario, de
Interaccin, de Aplicacin o Abstractas. Esta
clasificacin est abierta, por lo que es posible
caracterizarla como otra. Sera el caso, por
ejemplo de las tareas compuestas.
Composicin indica si la tarea es compuesta o
atmica.
En caso de que la tarea sea compuesta existen dos
metadatos adicionales:
Tareas Dependientes enumera aquellas tareas
que componen la que se describe.
Descripcin
como
Tarea
Compuesta
proporcionara informacin adicional, en caso
de que fuera necesaria, relativa a su
composicin.
Si adems la tarea es de grupo, se deben
incorporar a la descripcin de la tarea los
siguientes metadatos:
CSCW permite caracterizar la tarea segn las
caractersticas tpicas del CSCW que han sido
comentadas en el modelo de tareas. As, una
tarea podra caracterizarse como de
coordinacin, comunicacin, colaboracin y/o
cooperacin.
Tiempo es el metadato que permite
caracterizar la tarea segn su ejecucin sea en
tiempo real o no.
Lugar es el metadato que permite caracterizar
la tarea segn se lleve a cabo en el mismo

lugar o los actores estn distribuidos

geogrficamente.
Descripcin como Tarea de Grupo
proporcionara informacin adicional, en caso
de que fuera necesaria, relativa al hecho de
que sea tarea de grupo.
Para el ejemplo del apartado 3 se identifican
multitud de tareas como escribir en el documento,
enviarlo, responder comentarios, etc.; as como
varias tareas de grupo como compartir el
documento que se elabora en conjunto, el proceso
de envo/recepcin del documento, etc.
En los apartados siguientes se muestran unos
diagramas que modelan la interaccin donde se
pueden observar estas y otras tareas. En un
proceso de anlisis normal, adems, se deberan
haber identificado y descrito por medio del uso de
plantillas previamente.

5. Estructura y comportamiento
La divisin entre estructura y comportamiento se
ha utilizado tradicionalmente en Ingeniera del
Software para el modelado del sistema en todo el
ciclo de vida del software.
La etapa de anlisis del modelo de procesos
presentado en este artculo contempla un conjunto
de diagramas estructurales y de comportamiento
que permiten llevar a cabo de forma completa el
anlisis del sistema.
Los diagramas que se presentan se han
desarrollado con el objeto de aumentar la
expresividad de la especificacin y conseguir que
sea ms completa, especialmente desde el punto
de vista del usuario como parte de un grupo y de
las interacciones que puedan darse entre ellos.
En la Tabla 2 se muestran de forma resumida
los elementos organizativos que se emplean en los
diagramas junto con su notacin. Del mismo
modo, la Tabla 3 resume las posibles relaciones
entre elementos organizativos.
5.1. Anlisis de la estructura
Para representar la estructura del sistema se
emplean dos diagramas estructurales que reflejan
la parte esttica del sistema. En primer lugar el
diagrama de clases correspondiente al paquete
Classes de UML 2.0 [9] muestra los objetos del
dominio que se utilizan en el sistema as como las
relaciones que existen entre ellos.

Tabla 2.

Elementos organizativos de los diagramas

Descripcin

Notacin

Un Actor es una o varias personas,

u otro u otros sistemas externos,
que interactan con el sistema.

ACTOR_1

Un Grupo es un conjunto de
Actores, individuos o colectivos,
que desempean roles para lograr
un Objetivo comn.
Un elemento Individuo es un, y
slo un, Actor que desempea
roles.
Un Usuario es
Individuo humano.

un

Un
Agente
es
un
Individuo no humano.

Individual_1

elemento
User_1

elemento

Un Rol es el conjunto de Tareas

que puede desempear un Actor.

Tabla 3.

GROUP_1

Agent_1

ROLE_1

Relaciones entre elementos

Descripcin

Notacin

Una Relacin de Desempeo es una

Relacin Organizativa Estructural que
identifica el Rol que juega un Actor.
Una Relacin de Agregacin es una
Relacin Organizativa Estructural que
identifica una asociacin entre el
todo y las partes.
Una Relacin de Jerarqua es una
Relacin Organizativa Estructural que
identifica una dependencia de grado
entre dos Actores.
Task_role_1
Interaccin Cooperativa
es
una
Relacin
Cooperative_Interaction
Organizativa
Colaborativa entre dos
Actores que expresa
Task_role_2
una interaccin entre
ellos, encaminada al logro de un Objetivo comn
que no podra alcanzarse sin dicha interaccin.

Esos objetos se representan mediante clases

(con los atributos y las operaciones que
comparten) que abstraen los conceptos y que estn
relacionadas entre s representando las

asociaciones que se dan entre los objetos del

dominio del problema.
Para describir la estructura organizativa de los
actores que participan en un sistema CSCW se ha
desarrollado un diagrama que la representa: OSD.
Especifica los participantes del sistema, su
organizacin y los roles que desempean.
Diagrama de la estructura organizativa

El diagrama para la estructura organizativa de los

actores de un sistema (Organizational Structure
Diagram, OSD) representa la distribucin de los
diferentes elementos organizativos del mismo, es
decir, cmo se organizan los actores del sistema y
cmo se relacionan (en trminos estructurales)
para constituir los grupos y jerarquas, qu roles
desempean, etc.
El OSD se emplea para representar la
estructura organizativa de todo el sistema. El
sistema se construye con una finalidad y para
llegar a alcanzar ese fin ltimo, los actores del
mismo han de organizarse de una determinada
manera.
Si el sistema fuera demasiado complejo, se
podran realizar diversos OSD complementarios,
representando, por ejemplo, subsistemas en los
que se dividiera el sistema principal.
En un OSD, podra aparecer cualquiera de los
elementos organizativos descritos, sin embargo,
en sucesivas iteraciones, elementos ms abstractos
como actor o individuo se irn sustituyendo por
elementos ms concretos como grupo, usuario o
agente. En cualquier caso se muestra tambin el
rol que juegan cada uno en el sistema.
En cuanto a las relaciones que se dan entre los
elementos organizativos de un OSD, podran
aparecer relaciones de jerarqua, agregacin o
desempeo.
La Figura 4 muestra un ejemplo de OSD para
el sistema descrito como caso de estudio en el
apartado 3.
5.2. Anlisis del comportamiento
Para modelar el comportamiento de los elementos
en el sistema, se ha definido un nuevo diagrama,
el CD (Diagrama de Colaboracin), que esboza
las colaboraciones que tienen lugar entre actores
del sistema.

WHOLE_SYSTEM

INTERNAL

Reader

EXTERNAL

Author_notifier

Reader_notifier

Writer

Reader
Notifier
AUTHORS

REVIEWERS

Reviewer

Author

Chair_author

Reviewer

Chair_writer

Chair_reviewer

Chair_reviewer

Figura 4. Diagrama de la Estructura Organizativa del sistema del caso de estudio

As mismo, el TD (Diagrama de Tareas) es un

diagrama que se considera fundamental para
representar lo que el usuario hace, las
interacciones con el sistema. Como TD se ha
adoptado la notacin ConcurTaskTrees [10] por
ser ampliamente aceptada. Sin embargo, otras
notaciones para modelar tareas como las
presentadas en [13], [16], etc. podran adaptarse
igualmente.
Diagrama de tareas

El diagrama de tareas permite modelar la parte de

la realidad, del dominio del problema, que tiene
que ver con el trabajo que realizan los actores en
un sistema. Concretamente tiene en cuenta las
tareas que realiza un actor del sistema de manera
individual, su interaccin con el sistema.
Por falta de espacio, no se entrar en detalle
en la descripcin de esta notacin que, por otro
lado, se puede encontrar en [10].

Diagrama de colaboracin

El diagrama de colaboracin (Collaborative

Diagram, CD) representa las colaboraciones
establecidas entre los diferentes elementos
organizativos de una estructura organizativa, es
decir, las interacciones que existen entre los
actores de un sistema a travs del mismo.
Estos diagramas se pueden emplear para
representar las colaboraciones de todo el sistema o
de parte de l. Si el sistema no es muy complejo,
el CD puede mostrar todas las colaboraciones que
se dan en l. De lo contrario, se pueden utilizar
varios para representar partes de l. En cualquier
caso, la interseccin de todos los diagramas que
representan esos subsistemas dara lugar a la
representacin de las colaboraciones que se dan en
el sistema en su totalidad.
Lo ms adecuado, normalmente, es generar
varios CDs por OSD que modelan la interaccin
persona-ordenador-persona entre los actores de
esa estructura representada por el OSD.

Sharing_draft

Send_comment

Receive_doc

Reader
Answer_comments

Send_doc

AUTHORS
Commenting_draft

Receive_opinion

Commenting

Receive_to_review
Send_opinion

Ask_for_comments
Sending_to_review

Receive_comment

REVIEWERS
Receive_approval

Receive_refusal

WHOLE_SYSTEM

Notifying_ko

INTERNAL

Notifying _ok
Send_approval

Send_to_review

Send_refusal

Chair_author

Reviewer

Chair_reviewer
Receive_reviewed_doc

Send_reviewed_doc
Sending_to_decide

Figura 5. Diagrama de colaboracin del sistema del caso de estudio

Los elementos empleados para formar un CD

son los mismos que los que se han utilizado para
representar la estructura organizativa por medio
de los OSD. Un CD representa las colaboraciones
que tienen lugar entre los participantes de un
sistema organizados como se muestra en el OSD.
En cuanto a las relaciones posibles entre los
elementos, aunque es factible mostrar algunas
relaciones de jerarqua, agregacin o desempeo
por claridad, lo normal es que aparezcan
relaciones de interaccin cooperativa que
describen la interaccin entre dos participantes a
travs del sistema.
La Figura 5 muestra un ejemplo de CD para el
sistema descrito como caso de estudio en el
apartado 3.

6. Trazabilidad inter e intra-etapa

Es fundamental mantener la coherencia y la
consistencia entre los elementos que aparecen
entre las distintas etapas, as como en el interior
de cada etapa.
Puesto que en el artculo se habla en todo
momento de anlisis, se har hincapi en la
trazabilidad intra-etapa, no describiendo la
trazabilidad que se da entre la etapa de anlisis y
las etapas de elicitacin de requisitos y diseo del
sistema.
La trazabilidad para mantener la coherencia y
la consistencia del modelo se ha de dar entre roles

y tareas puesto que son conceptos muy

relacionados pero que se identifican en un
principio separadamente.
As mismo, una vez identificados y descritos
tanto los roles como las tareas del sistema, los
diagramas comentados con anterioridad permiten
modelar la estructura organizativa de los actores
del sistema, las colaboraciones que existen entre
ellos y las interacciones de los usuarios con el
sistema. Muchos de los elementos que se emplean
en un diagrama se emplean tambin en los otros
diagramas.
En principio, el uso de elementos
unvocamente identificados en los distintos
diagramas debera mantener la coherencia y la
consistencia del modelo. Se debe tener especial
cuidado con las implicaciones que tendra la
modificacin de un elemento en un modelo con
respecto a los otros, que probablemente se veran
afectados.
El rol se ha definido en base a un conjunto de
tareas, por lo que roles y tareas estn ntimamente
relacionados. El nmero de roles y, sobre todo, de
tareas de un sistema puede ser muy elevado. Una
matriz que ponga en relacin los roles con las
tareas asociadas, es decir, el rol identificado con la
funcionalidad que le proporcionara al actor que lo
desempeara, facilita la comprensin del sistema.
La matriz tareas-roles asocia el conjunto de
tareas que define cada rol. El rol es la seleccin de
un conjunto de tareas, por lo que stas podran

estar asociadas tambin a varios roles. La Tabla 4

muestra un esquema de la matriz tareas-roles para
mantener esa trazabilidad.
Tabla 4.

Tarea-<id1>
Tarea -<id2>

Tarea -<idn>

Esquema de matriz tareas-roles

Rol<id1>

Rol<id2>

Rol<idm>

7. Conclusin
En el presente artculo se ha propuesto una
metodologa para llevar a cabo el anlisis de
sistemas CSCW haciendo especial hincapi en las
colaboraciones entre los participantes del sistema,
su organizacin y los roles que desempean. La
metodologa tambin permite modelar las
interacciones de los usuarios con el sistema as
como los objetos manipulados en el dominio del
problema y sus relaciones. Para llevar a cabo todo
esto, se proponen una serie de diagramas y el
modelo de procesos a seguir para el correcto
desarrollo sistemtico del sistema.

Agradecimientos
Los autores agradecen la financiacin de este
trabajo al proyecto CICYT TIN2004-08000-C0301, as como la ayuda de la JCCM PCC-05-005-1.

Referencias
[1] Constantine, L. L. and Lockwood, L. A. D.,
Software for use: a practical guide to the
models and methods of usage-centered design,
Addison Wesley, Reading, Mass, 1999.
[2] Durn, Amador: Un Entorno Metodolgico de
Ingeniera de Requisitos para Sistemas de
Informacin. Tesis Doctoral. Universidad de
Sevilla. 2000
[3] Garrido Bullejos, Jos Luis; AMENITIES: Una
metodologa para el desarrollo de sistemas
cooperativos basada en modelos de
comportamiento y tareas. Tesis Doctoral.
Granada 2003
[4] Greif, I.: Computer-Supported Cooperative
Work: A Book of Readings. Morgan
Kaufmann, San Mateo CA, 1988

[5] Grudin, J. 1994. Computer-Supported

Cooperative Work: History and Focus.
Computer 27, 5 (May. 1994), 19-26
[6] Jacobson, I., Booch, G., and Rumbaugh, J.
1999 The Unified Software Development
Process.
Addison-Wesley
Longman
Publishing Co., Inc.
[7] Johansen, R. (1988): Groupware: Computer
support for business teams. New York: The
Free Press
[8] Molina, Ana Isabel: Una Propuesta
Metodolgica para el Desarrollo de la
Interfaz de Usuario en Sistemas Groupware.
Tesis Doctoral. Universidad de Castilla-La
Mancha. 2006
[9] Object
Management
Group.
UML
Superstructure Specification, v2.0; 2005
[10] Paterno, F.; Model-based Design and
Evaluation of Interactive Applications.
F.Patern, Springer Verlag, November 1999,
ISBN 1-85233-155-0
[11] Penichet, Victor M. R.; Lozano, Maria D.;
Gallud, Jose A.; Montero, Francisco:
Ontologa para Estructuras Organizativas
Colaborativas. VII Congreso Internacional
Interaccin 2006. U. de Castilla-La Mancha,
Puertollano, Spain; 15 Nov 2006.
[12] Pilone, Dan; Pitman, Neil: UML 2.0 in a
Nutshell. O'Reilly Media; ISBN-13: 9780596007959 2nd edition. 2005
[13] Pinelle, D., Gutwin, C., Greenberg, S.: Task
analysis for groupware usability evaluation:
Modeling shared-workspace tasks with the
mechanics of collaboration. ACM (TOCHI)
Volume 10 , Issue 4, Pages: 281 - 311. (2003)
ISSN:1073-0516
[14] Poltrock, S. and Grudin, J. Computer
Supported Cooperative Work and Groupware.
Companion on Human Factors in Computing
Systems (Boston, Massachusetts, United
States, April 24 - 28, 1994). C. Plaisant, Ed.
CHI '94. ACM, 355-356`
[15] Poltrock, S. and Grudin, J. 1999. CSCW,
groupware and workflow: experiences, state
of art, and future trends. CHI '99 Human
Factors in Computing Systems (Pittsburgh,
Pennsylvania, May 15 - 20, 1999). CHI '99.
ACM Press, New York, NY, 120-121
[16] Van der Veer, G. C.; Van Welie, M. 2000.
Task based groupware design: Putting theory
into practice. Symposium on Designing
Interactive Systems. ACM, 326337