Análisis en un Modelo de Procesos CSCW. Organización

Análisis en un Modelo de Procesos CSCW. Organización, Roles
e Interacción Persona-Ordenador-Persona
Victor M. R. Penichet, Maria D. Lozano, José A. Gallud, Ricardo Tesoriero
Departamento de Sistemas Informáticos
Universidad de Castilla-La Mancha
02071 Albacete, España
{ victor.penichet, maria.lozano, jose.gallud }@uclm.es; [email protected]
Resumen
Este artículo presenta una propuesta para llevar a
cabo el proceso de análisis para entornos CSCW,
una etapa del modelo de procesos esencial en este
tipo de sistemas. La metodología presentada para
abordar la etapa de análisis proporciona los
mecanismos suficientes para especificar la
organización de los participantes de un sistema,
los roles que desempeñan, la interacción de los
usuarios con el sistema y la interacción entre los
participantes a través del sistema, es decir, la
interacción persona-ordenador-persona.
1. Introducción
La etapa de análisis de cualquier sistema es una
etapa fundamental que posibilita el estudio en
profundidad de determinadas características del
dominio del problema. Se trata de descubrir el qué
describiendo los requisitos del sistema sin detallar
aspectos de implementación. Se estudian los
elementos del dominio del problema y sus
relaciones. Se trata de acercar la especificación
del sistema recogida en la elicitación de requisitos
en un “lenguaje más cercano a la persona” a una
especificación más cercana al desarrollador.
Sin duda, el lenguaje más utilizado para
modelar la realidad es UML, actualmente en su
versión 2.0 [9]. El modelado de sistemas
tradicionales se ha abordado por medio de
diagramas de clases, objetos y paquetes que
describen la parte estática, estructural del sistema.
Capturan la organización física de los elementos
en el sistema, cómo se relacionan [12].
Para abordar el modelado del comportamiento
de los elementos en el sistema, esto es, para
describir la parte dinámica, se suelen emplear
diagramas de actividades esencialmente. Estos
diagramas forman parte de la metodología de
algunos modelos de procesos muy conocidos
como RUP [6].
Sin embargo, estos mecanismos de
representación de la realidad no facilitan
especificar naturalmente la interacción personaordenador-persona que tiene lugar en los sistemas
CSCW [4][5][7][14], sistemas que, por otro lado,
son cada día más habituales debido a las
crecientes necesidades de los usuarios y al avance
de las tecnologías y las infraestructuras de red.
Algunas
otras
aproximaciones
como
AMENITIES o, más recientemente, CIAM
abordan esta problemática desde una perspectiva
diferente. AMENITIES (A MEthodology for
aNalysis and desIgn of cooperaTIve systEmS) [3]
es una metodología 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 metodológico basado en un conjunto de
modelos que permiten a los ingenieros guiar el
proceso de diseño y desarrollo de la interfaz de
usuario en aplicaciones interactivas para el trabajo
en grupo.
La metodología que se propone en este
artículo para el análisis de sistemas CSCW
posibilita un análisis de la estructura y del
comportamiento del sistema centrado en el
usuario y dirigido por las tareas que se
desempeñan. En el estudio de la estructura,
además de los objetos del sistema se tiene en
cuenta quiénes son y de qué manera participan,
cómo se organizan y qué roles desempeñan. El
estudio
del
comportamiento
se
aborda
describiendo la funcionalidad desde un punto de
vista CSCW, abordando sus características típicas
[15], así como sus características espaciotemporales, muy importante en estos sistemas [7].
La descripción del trabajo realizado por medio
de un sistema, es decir, lo que se hace en él, se
puede representar con flujogramas, máquinas de
estados finitos, modelos de workflow, diagramas
de flujo de datos, etc. Una de las técnicas más
utilizadas es el uso de modelos de tareas. También
estos modelos han tenido en cuenta las
colaboraciones que se dan en un sistema CSCW
pero sobre todo han permitido modelar la
interacción del usuario con el sistema
[10][13][16]. Una de las notaciones más utilizadas
para ello es CTT [10], notación que ha sido
adoptada como parte de la metodología que se
presenta. Sin embargo, se ha elaborado un
diagrama adicional que facilita el modelado de la
colaboración entre los participantes de un sistema
CSCW de un modo más natural.
El resto del artículo se organiza de la siguiente
manera. En el apartado 2 se enumeran los pasos
de la metodología que facilitaría el análisis 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 análisis 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 análisis de sistemas CSCW
La Figura 1 muestra un esquema de los pasos que
se siguen en la etapa de análisis del modelo de
procesos que se presenta en este artículo:
identificación
y
descripción
de
roles,
identificación y descripción de tareas, análisis de
la estructura del sistema y análisis del
comportamiento del sistema.
El análisis de un sistema colaborativo
comienza con una identificación previa de roles y
tareas a partir de la información recabada en la
elicitación de requisitos. Una vez identificados los
primeros roles y tareas, se puede comenzar la
descripción de los mismos y en paralelo los
primeros diagramas de tareas (TD), colaboración
(CD) y estructura organizativa (OSD). Estos
diagramas se describirán en sucesivos apartados.
Por un lado, la identificación 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 identificación de las primeras tareas
permite ordenarlas, creando un primer esbozo de
los diagramas de tareas y los diagramas de
colaboración, que modelan el comportamiento de
los actores del sistema.
Elicitación de Requisitos
Actores
Requisitos
Análisis
Identificación de Roles Tareas
Identificación y
Descripción de Roles
Identificación y
Descripción de Tareas
Estructura y Comportamiento
Estructura
Clases
Comportamiento
OSD
CD
TD
Diseño
Figura 1. Pasos de la etapa de análisis en entornos CSCW
Por otro lado, del análisis de las primeras
versiones de los diagramas surgen nuevos roles y
tareas. Tras esa primera identificación de roles y
tareas, un proceso iterativo de refinamiento
permitirá obtener un modelo de mayor calidad,
que permita obtener una especificación completa
del sistema.
Del mismo modo que la trazabilidad entre las
etapas de elicitación de requisitos y análisis
permiten obtener especificaciones coherentes y
completas, es necesario tener en cuenta una
trazabilidad intra-etapa entre sus pasos. Dicha
trazabilidad se detallará más adelante.
3. Caso de estudio
Con el objetivo de ilustrar los conceptos
novedosos introducidos en este artículo se
presenta este sencillo caso de estudio. Se trata de
una aplicación groupware que debe permitir la
elaboración de un documento entre varios autores
a través de Internet. Cuando los autores del
documento tienen un borrador, uno de ellos se
encarga de enviar, por medio de la misma
aplicación, el documento candidato a ser
publicado a unos revisores. Los revisores analizan
el documento y dan su opinión acerca de si ha de
ser publicado o no. Un documento público puede
ser leído por todos los usuarios del sistema,
aunque no sean autores o revisores.
A lo largo del artículo, los ejemplos
presentados se refieren ejemplo. Lógicamente no
se hace una especificación completa por falta de
espacio. Sólo se aclaran algunos puntos.
4. Identificación de roles y tareas
En una primera etapa de elicitación de requisitos
se identificarían, entre otras cosas, los actores del
sistema y la información relativa a los requisitos,
que darán lugar a los roles que los usuarios
pueden desempeñar y las tareas que tienen que
llevar a cabo en el sistema [11]. La relación entre
roles y tareas es tan estrecha que la identificación
y descripción 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 quién.
Se trata de algo determinante en la organización
del diseño de un sistema colaborativo.
Para describir los roles y las tareas
identificados, se emplearán unas plantillas
similares a las utilizadas en la elicitación de
requisitos por Durán [2]. Son plantillas más
sencillas en cuanto a número de metadatos que
describen el concepto en cuestión, pero necesarias
para ubicar rápidamente todos los roles y tareas
del sistema.
Además
se
emplearán
matrices
de
rastreabilidad [2] que ponen en relación actores
con roles y requisitos con tareas. Las matrices de
rastreabilidad simplemente muestran de forma
explícita información 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 evolución. Una
última matriz pone en relación las tareas asociadas
a cada rol.
La identificación de los roles y las tareas, su
descripción y el uso de las plantillas y las matrices
de rastreabilidad se describen en los siguientes
apartados.
4.1. Identificación y descripción de roles
El concepto de rol se ha definido como conjunto
de tareas que puede desempeñar un actor. Un
actor es lo que es debido al rol que desempeña en
cada momento en el sistema [11].
En [1] se dice que un rol (user role) es una
colección 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 términos 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 identificación y descripción de los roles en
este artículo, pasos que se describen a
continuación.
Para construir ese listado de roles, Constantine
[1] propone una serie de interrogantes previos:
• ¿Quiénes usarían o podrían usar el sistema?
• ¿Cuál es la clase general o el grupo al que
pertenecen?
• ¿Qué distingue el cómo puedan utilizar el
sistema?
• ¿Qué caracteriza su relación con la
aplicación?
• ¿Qué necesitan de la aplicación?
•
¿Cómo se comportan en relación a la
aplicación y cómo esperan que la aplicación
se comporte?
Identificación y Descripción de Roles
PASO 1
Interrogantes y generalización de tipos de
actores: Listado de Candidatos
PASO 2
Refinamiento: Listado de Roles del Sistema
PASO 3
Descripción de los Roles: modelo organizativo
PASO 4
Descripción de los Roles: modelo de contexto
Diagramado
Realización de los diagramas correspondientes
para realizar los modelos
Figura 2. Pasos en la identificación y descripción de
roles
Para identificar los roles se suele comenzar
pensando en usuarios (agentes o grupos)
particulares, reales, y después se va generalizando
y abstrayendo hasta llegar al rol. En [1] se
propone la técnica tormenta de ideas o
brainstorming para, partiendo de una lista de roles
candidatos, llegar al modelo de roles definitivo.
Del estudio de la información recogida y
elaborada en la elicitación de requisitos, se pueden
extraer los diferentes roles que se necesitan en el
Tabla 1.
sistema para que sean desempeñados por los
usuarios finales (actores en general) que harán uso
de la aplicación.
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 describirán empleando una
plantilla como la que se muestra en la Tabla 1, con
los metadatos utilizados en la descripción de los
roles identificados. Puesto que los roles se
describen en base a las tareas, hay una matriz que
pone en relación explícita estos conceptos (ver
apartado 6). Con estos metadatos se obtiene la
información necesaria sobre los roles del sistema
para el modelo de organización:
• Los tres primeros campos (Versión, Autores,
Fuentes) son comunes a las plantillas de
elicitación de requisitos y su significado es el
mismo [2].
• Los roles pueden ser desempeñados por los
actores si cumplen ciertas restricciones. Una
Capacidad
es
una
habilidad
o
responsabilidad asociada a un actor que le
permite desempeñar roles y llevar a cabo
tareas [3]. Por lo tanto, para que algún actor
pueda desempeñar un rol, éste debe tener unas
determinadas Habilidades, y se le pueden
exigir unas determinadas Responsabilidades,
necesarias para que lo pueda hacer.
Descripción del rol Writer a partir de la plantilla para la descripción de los Roles del sistema: modelo
organizativo
Rol- 1
Versión
Autores
Fuentes
Descripción
Responsabilidades
Habilidades
Permisos
Comentarios
Writer
v1.0 (22 marzo, 2007)
• Victor M. R. Penichet (LoUISE)
• Estudio interno (LoUISE)
Un usuario del sistema que desempeñe este rol puede elaborar documentos.
Las responsabilidades que se requieren de un actor para que pueda desempeñar
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 desempeñar este
rol son las siguientes:
• H1: Capacidad investigadora
• H2: Capacidad de expresión
Puede escribir en los documentos, crearlos, modificarlos y destruirlos.
No hay ningún comentario adicional.
Los actores que desempeñen un cierto rol,
normalmente tendrán una serie de Permisos o
privilegios para poder realizar ciertas acciones
en el sistema.
• La Descripción esboza cómo es ese rol,
mientras que los Comentarios dan algún tipo
de información adicional.
Para el ejemplo mostrado en el apartado 3,
tras su estudio se identificarían una serie de roles
que desempeñarían los actores del sistema. La
identificación de los roles se habría realizado en la
etapa de elicitación 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 decisión de enviar al proceso de revisión un
documento candidato.
• Reviewer, para los usuarios que pueden ser
revisores de documentos candidatos.
• Chair_reviewer, para revisores que además
puedan decidir si un documento puede ser
publicado.
• Notifier, para agentes que informarán
automáticamente a los autores del resultado
del proceso de revisión y a los lectores de si
hay un nuevo documento publicado.
• Reader, para los actores del sistema que
puedan leer documentos públicos.
La Tabla 1 muestra la descripción, 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
descomposición surgen en esta etapa de análisis.
El número de tareas identificadas se irá viendo
incrementado con el estudio y el análisis de las
mismas, principalmente por dos motivos: por
descomposición de tareas complejas en otras más
sencillas y por la identificación de nuevas tareas.
Se trata de describir el trabajo que se debe realizar
en el sistema.
Como se ha comentado con anterioridad, la
notación CTT para modelar tareas se ha utilizado
extensamente y es el diagrama seleccionado en
este artículo para representar las tareas.
Como se verá en los próximos apartados, CTT
permite modelar la interacción del usuario con el
sistema, sin embargo la interacción personaordenador-persona, es decir, la interacción entre
las personas a través de las máquinas no se
modela con facilidad. Para solventar esta situación
proponemos un nuevo diagrama que modela la
colaboración entre usuarios.
Así mismo, se describen las tareas por medio
de plantillas similares a la empleada para la
descripción de los roles.
Los metadatos que aparecen en la plantilla
para la descripción de las tareas son los siguientes:
• Los tres primeros campos (Versión, Autores,
Fuentes) son comunes a las plantillas de
elicitación de requisitos y su significado es el
mismo [2].
4.2. Identificación y descripción de tareas
1
R
El concepto de tarea se ha definido como una
porción de trabajo necesaria para lograr un
objetivo determinado [11]. Al iniciar el análisis
del sistema se podría decir que siempre hay una
tarea para resolver un requisito identificado en la
etapa de elicitación de requisitos. Existe una
relación 1:1 entre los conceptos requisito y tarea,
fruto de esa equivalencia semántica inicial.
Siempre hay una tarea, aunque sea abstracta, que
resuelve un requisito.
En la etapa de análisis, algunas tareas se
descomponen en otras y así sucesivamente hasta
llegar a otras que son atómicas y no se pueden
dividir más. Tal y como se expresa en la Figura 3,
en esta etapa es probable que la relación entre
requisitos y tareas ya no sea 1:1 sino más bien
1
1
T
R
*
T
T
- Al comenzar el análisis desde
la etapa de elicitación de
requisitos, siempre hay una
tarea, aunque sea abstracta,
que resuelve un requisito.
- En el análisis, la tarea se
descompone en otras, cada vez
más concretas y de menor
granularidad, hasta llegar a
tareas atómicas.
T
T
T
T
T
T
T
Figura 3. Relación entre requisitos y tareas en la etapa
de análisis
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 relación de esta tarea con
alguno de los requisitos identificados en la
etapa anterior.
• Descripción
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 están relacionadas o
afectan a algunos objetos del dominio del
sistema que deben mostrarse de manera que el
diseñador sea consciente de ello. Los objetos
del sistema y sus relaciones se representan,
como se verá posteriormente, por medio del
clásico diagrama de clases de UML.
• Modo de Ejecución representa una de las
caracterizaciones introducidas en el modelo.
Las tareas pueden ser de Usuario, de
Interacción, de Aplicación o Abstractas. Esta
clasificación está abierta, por lo que es posible
caracterizarla como otra. Sería el caso, por
ejemplo de las tareas compuestas.
• Composición indica si la tarea es compuesta o
atómica.
En caso de que la tarea sea compuesta existen dos
metadatos adicionales:
• Tareas Dependientes enumera aquellas tareas
que componen la que se describe.
• Descripción
como
Tarea
Compuesta
proporcionaría información adicional, en caso
de que fuera necesaria, relativa a su
composición.
Si además la tarea es de grupo, se deben
incorporar a la descripción de la tarea los
siguientes metadatos:
• CSCW permite caracterizar la tarea según las
características típicas del CSCW que han sido
comentadas en el modelo de tareas. Así, una
tarea podría caracterizarse como de
coordinación, comunicación, colaboración y/o
cooperación.
• Tiempo es el metadato que permite
caracterizar la tarea según su ejecución sea en
tiempo real o no.
• Lugar es el metadato que permite caracterizar
la tarea según se lleve a cabo en el mismo
•
lugar o los actores estén distribuidos
geográficamente.
• Descripción como Tarea de Grupo
proporcionaría información 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 envío/recepción del documento, etc.
En los apartados siguientes se muestran unos
diagramas que modelan la interacción donde se
pueden observar estas y otras tareas. En un
proceso de análisis normal, además, se deberían
haber identificado y descrito por medio del uso de
plantillas previamente.
5. Estructura y comportamiento
La división entre estructura y comportamiento se
ha utilizado tradicionalmente en Ingeniería del
Software para el modelado del sistema en todo el
ciclo de vida del software.
La etapa de análisis del modelo de procesos
presentado en este artículo contempla un conjunto
de diagramas estructurales y de comportamiento
que permiten llevar a cabo de forma completa el
análisis del sistema.
Los diagramas que se presentan se han
desarrollado con el objeto de aumentar la
expresividad de la especificación y conseguir que
sea más 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 notación. Del mismo
modo, la Tabla 3 resume las posibles relaciones
entre elementos organizativos.
5.1. Análisis de la estructura
Para representar la estructura del sistema se
emplean dos diagramas estructurales que reflejan
la parte estática 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
Descripción
Notación
Un Actor es una o varias personas,
u otro u otros sistemas externos,
que interactúan con el sistema.
ACTOR_1
Un Grupo es un conjunto de
Actores, individuos o colectivos,
que desempeñan roles para lograr
un Objetivo común.
Un elemento Individuo es un, y
sólo un, Actor que desempeña
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 desempeñar un Actor.
Tabla 3.
GROUP_1
Agent_1
ROLE_1
Relaciones entre elementos
Descripción
Notación
Una Relación de Desempeño es una
Relación Organizativa Estructural que
identifica el Rol que juega un Actor.
Una Relación de Agregación es una
Relación Organizativa Estructural que
identifica una asociación entre el
todo y las partes.
Una Relación de Jerarquía es una
Relación Organizativa Estructural que
identifica una dependencia de grado
entre dos Actores.
Task_role_1
Interacción Cooperativa
es
una
Relación
Cooperative_Interaction
Organizativa
Colaborativa entre dos
Actores que expresa
Task_role_2
una interacción entre
ellos, encaminada al logro de un Objetivo común
que no podría alcanzarse sin dicha interacción.
Esos objetos se representan mediante clases
(con los atributos y las operaciones que
comparten) que abstraen los conceptos y que están
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
organización y los roles que desempeñan.
Diagrama de la estructura organizativa
El diagrama para la estructura organizativa de los
actores de un sistema (Organizational Structure
Diagram, OSD) representa la distribución de los
diferentes elementos organizativos del mismo, es
decir, cómo se organizan los actores del sistema y
cómo se relacionan (en términos estructurales)
para constituir los grupos y jerarquías, qué roles
desempeñan, 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
podrían realizar diversos OSD complementarios,
representando, por ejemplo, subsistemas en los
que se dividiera el sistema principal.
En un OSD, podría aparecer cualquiera de los
elementos organizativos descritos, sin embargo,
en sucesivas iteraciones, elementos más abstractos
como actor o individuo se irán sustituyendo por
elementos más concretos como grupo, usuario o
agente. En cualquier caso se muestra también el
rol que juegan cada uno en el sistema.
En cuanto a las relaciones que se dan entre los
elementos organizativos de un OSD, podrían
aparecer relaciones de jerarquía, agregación o
desempeño.
La Figura 4 muestra un ejemplo de OSD para
el sistema descrito como caso de estudio en el
apartado 3.
5.2. Análisis del comportamiento
Para modelar el comportamiento de los elementos
en el sistema, se ha definido un nuevo diagrama,
el CD (Diagrama de Colaboración), 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 notación ConcurTaskTrees [10] por
ser ampliamente aceptada. Sin embargo, otras
notaciones para modelar tareas como las
presentadas en [13], [16], etc. podrían 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 interacción con el sistema.
Por falta de espacio, no se entrará en detalle
en la descripción de esta notación que, por otro
lado, se puede encontrar en [10].
Diagrama de colaboración
El diagrama de colaboración (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 través 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 intersección de todos los diagramas que
representan esos subsistemas daría lugar a la
representación de las colaboraciones que se dan en
el sistema en su totalidad.
Lo más adecuado, normalmente, es generar
varios CDs por OSD que modelan la interacción
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 colaboración 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 jerarquía, agregación o desempeño
por claridad, lo normal es que aparezcan
relaciones de interacción cooperativa que
describen la interacción entre dos participantes a
través 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 artículo se habla en todo
momento de análisis, se hará hincapié en la
trazabilidad intra-etapa, no describiendo la
trazabilidad que se da entre la etapa de análisis y
las etapas de elicitación de requisitos y diseño 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 también en los otros
diagramas.
En principio, el uso de elementos
unívocamente identificados en los distintos
diagramas debería mantener la coherencia y la
consistencia del modelo. Se debe tener especial
cuidado con las implicaciones que tendría la
modificación de un elemento en un modelo con
respecto a los otros, que probablemente se verían
afectados.
El rol se ha definido en base a un conjunto de
tareas, por lo que roles y tareas están íntimamente
relacionados. El número de roles y, sobre todo, de
tareas de un sistema puede ser muy elevado. Una
matriz que ponga en relación los roles con las
tareas asociadas, es decir, el rol identificado con la
funcionalidad que le proporcionaría al actor que lo
desempeñara, facilita la comprensión del sistema.
La matriz tareas-roles asocia el conjunto de
tareas que define cada rol. El rol es la selección de
un conjunto de tareas, por lo que éstas podrían
estar asociadas también 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. Conclusión
En el presente artículo se ha propuesto una
metodología para llevar a cabo el análisis de
sistemas CSCW haciendo especial hincapié en las
colaboraciones entre los participantes del sistema,
su organización y los roles que desempeñan. La
metodología también 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 sistemático del sistema.
Agradecimientos
Los autores agradecen la financiación 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] Durán, Amador: Un Entorno Metodológico de
Ingeniería de Requisitos para Sistemas de
Información. Tesis Doctoral. Universidad de
Sevilla. 2000
[3] Garrido Bullejos, José Luis; AMENITIES: Una
metodología 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
Metodológica 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:
Ontología para Estructuras Organizativas
Colaborativas. VII Congreso Internacional
Interacción 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, 326–337