Vagner Luiz Gava*, Mauro de Mesquita Spinola**, José Manuel Cárdenas Medina*** y Carlos Antonio Tonini****
Recibido: 17-09-2010 - Aprobado: 10-11-2010
| RESUMEN: Los aspectos vinculados con el trabajo cooperativo, de los usuarios, no son normalmente considerados en el enfoque tradicional de la ingeniería de software, desde que el usuario es visto independientemente del medio o grupo del cual hace parte, teniendo el modelo individual generalizado para el estudio del comportamiento colectivo involucrando a todos los usuarios. El objetivo de este trabajo consiste en proponer un proceso para especificación de requisitos de software, por medio de la simulación del trabajo cooperativo de un sistema a ser informatizado. Para esto, la investigación hace uso de conceptos de ergonomía, cognición e ingeniería de software. Se utiliza investigación-acción como metodología de investigación, aplicada durante el desarrollo de un sistema de workflow corporativo en una empresa brasilera de investigación tecnológica, donde las contribuciones del grupo (sus acciones e inter-relaciones) son consideradas juntamente con las contribuciones individuales a través de la simulación de la solución propuesta. Los resultados de la investigación mostraron que, el proceso propuesto permite la recopilación de los requisitos más transaccionales del trabajo cooperativo (esto es, de los requisitos derivados de las acciones individuales y de los inter-relacionamientos entre usuarios) y parte de los requisitos de awareness. Palabras clave: Análisis Colectiva del Trabajo, Requisitos de Software. Modelos mentales. Trabajo cooperativo apoyado por computador. Awareness |
ABSTRACT: |
El avance tecnológico es consecuencia de las demandas sociales y de los sectores productivos. Los problemas y desafíos del mundo moderno presentan tales dimensiones y complejidad que sus soluciones involucran cada vez más trabajo en equipo, en razón del aumento de la competencia, la rápida evolución de la demanda, la presente innovación de los productos y de la transformación de las tecnologías.
De este modo, las empresas abdican de los modelos clásicos de organización, considerados más eficaces en contextos más estables y de producción en masa, pasando para un modelo focalizado en el contexto de la cooperación, cujas decisiones relativas a la concepción, fabricación y comercialización deben ser tomadas (SALERNO, 1999). Así, se apuesta en el trabajo cooperativo como medio de transformación conjunta de los individuos, de las colectividades y de las organizaciones, teniendo como objetivo el incremento de la eficacia organizacional (TAVARES, 2002).
La dimensión colectiva del trabajo es colocada, en el centro del cambio, por el discurso y práctica empresarial, con los cambios en la organización del trabajo, de procedimientos de fabricación, de prácticas profesionales y también, de los cambios en las competencias de los trabajadores.
Hoy, aunque la mayoría de las metodologías, utilizadas en desarrollo de software, prevén la participación y el envolvimiento de los usuarios en varias fases de su proceso de desarrollo, la cuestión del trabajo cooperativo necesario para ejecutar las actividades que serán informatizadas, no es considerada de modo explícito desde el inicio del proyecto.
Una de las explicaciones para esta situación es que en el abordaje tradicional de desarrollo de software (para sistemas de computadores tradicionales o sistemas comerciales, fuertemente orientados a datos), la hipótesis más frecuentemente utilizada es la de que los modelos son centrados en un único usuario (tenido como patrón e independiente del medio o grupo en el cual está se desenvuelve), siendo generalizados para el estudio del comportamiento cooperativo, involucrando a todos los usuarios.
Considerando la búsqueda de medios que conduzcan a la respuesta al problema presentado y del foco principal de la investigación, este trabajo busca responder las siguientes preguntas:
En función del problema y de la cuestión presentada, este artigo tiene como objetivo principal:
Admítase como premisa que los métodos convencionales, utilizados en desarrollo de software, no tratan adecuadamente la dimensión colectiva del trabajo en el uso de sistemas de información, tanto en su concepción, como en su corrección/mejoría.
Es propuesto un proceso que utiliza técnicas de ergonomía, prototipación de software, modelos mentales de cognición y de la ingeniería clásica para tratar las cuestiones colectivas y cooperativas del trabajo que deben ser consideradas en el proyecto de un sistema informatizado. Para tal, se utiliza la metodología de investigación-acción, aplicada durante el desarrollo de un sistema.
A metodología es aplicada en un proyecto de workflow corporativo en una grande empresa de investigación tecnológica en Brasil, mostrando como considerar las cuestiones colectivas del trabajo en un proyecto de desarrollo de software y los resultados obtenidos.
Este trabajo está organizado de la siguiente manera: primeramente son definidos los principales conceptos utilizados en esta investigación, en seguida es descrita la metodología utilizada y el proceso propuesto por medio del cual estos conceptos son lógicamente encadenados. Se presenta una investigación-acción realizada con base en la teoría propuesta y finalmente son discutidos los resultados.
Así, este trabajo pretende ofrecer una contribución de cuño empírico, asociada a una contribución teórica en el sentido de un refinamiento y/o extensión de la teoría.
En esta sección son definidos los principales aspectos teóricos del proceso propuesto, focalizándose el trabajo cooperativo en las interacciones cara a cara entre usuarios durante la simulación del futuro sistema a ser desarrollado.
La definición de cooperación utilizada en este trabajo es dada por Dejours (2005): “cooperación es una conducta coordinada, definida como a acción de participar de una obra común. La cooperación supone un lugar donde, al mismo tiempo, convergen las contribuciones singulares y se cristalizan las relaciones de dependencia entre los sujetos.”El autor enfatiza que la cooperación remite al colectivo de trabajo y es una conducta coordinada que posibilita desempeños superiores y suplementarios en relación a los desempeños individuales.El individuo integrado a un Sistema de Información (SI) en el cual hay distribución de competencias, de tareas, de roles, necesita de procesos integrantes (coordinación, comunicación, organización/cooperación). La dualidad entre el todo y las partes, entre unificación y distribución, entre homogeneidad y heterogeneidad raramente es considerada en los métodos de análisis y concepción de sistemas informatizados (ERCEAU et al, 1994).
El Análisis Colectivo del Trabajo (ACT) es un método de análisis en el cual trabajadores (usuarios, en el caso de la informática), en grupo, describen su propia actividad en situación de trabajo para otros trabajadores y para personas externas a la relación de trabajo (stakeholders, también, en el caso de la informática). Es el hablar de los trabajadores y el escuchar de los investigadores que se encuentra en el centro del proceso (FERREIRA, 1993).
Para la propuesta de trabajo en cuestión, algunos resultados y características generales sobre ACT deben ser destacados:
Con este método, se trabaja con grupos y no individualmente, y esta característica incide de varias maneras sobre los resultados. El colectivo funciona como un elemento que introduce una nueva dimensión a la comprensión y a las vivencias de cada uno, motivando a los trabajadores a expresarse. Como ellos son siempre mayoría, con relación a los investigadores,; este hecho disminuye el problema inicial de la situación propuesta, en el cual el saber de los trabajadores es el que predomina sobre el de los investigadores.
Otra característica es que la presencia de varias personas, hablando de su trabajo, facilita la comparación, y queda más claro aquello que es común en la actividad de cada uno de ellos y aquello que es diferente. Consecuentemente, los aspectos colectivos del trabajo son mejor abordados. Para explicar aquello que cada uno hace, en general, es necesario explicar lo que los otros hacen antes o después de él en el proceso productivo, encima, al lado o abajo en la escala jerárquica. En general, la conversa con los trabajadores es marcada entre el “nosotros” y ‘”ellos”, en el cual “nosotros” son todos los que tienen la misma actividad. “Ellos” son los otros, aquellos que controlan el trabajo, los que no conocen aquel trabajo.
Como resultado, las informaciones obtenidas en el ACT permiten dos tipos de abordajes: primeramente, una caracterización general de la actividad de trabajo, en la cual los principales puntos son destacados y, en un segundo momento, en la caracterización bien pormenorizada de determinados aspectos de la actividad, que normalmente pasan desapercibidos por observadores externos, como por ejemplo, la pericia necesaria para realizar una determinada operación, los artilugios empleados, etc. (FERREIRA, 1998, 1999).
Las personas formulan modelos mentales internos de sí mismas, de los objetos y de las personas con las cuales interactúan. Estos modelos ofrecen medios para la comprensión de las interacciones, siendo afectados fuertemente, tanto por la naturaleza de las interacciones como por las experiencias y conocimientos anteriores. Antes de no ser completos y precisos, son modelos útiles para orientar gran parte del comportamiento humano (NORMAN, 1986).
La propuesta de Norman (1986) y Norman (2002) prevé tres modelos mentales: de proyecto, del usuario e imagen del sistema:
De este modo, el modelo conceptual es un medio para criar el modelo mental y debe permitir al usuario interpretar lo que está ocurriendo por medio de la interfaz y documentación del sistema.
De acuerdo con Norman (1986), la mayor facilidad de aprendizaje y su utilización dependen de un correcto mapeo entre el modelo mental y el conceptual. El modelo mental no se forma con base no modelo del proyecto, y el mismo resulta del modo como el usuario interpreta a imagen de sistema.
Así, la tarea del proyectista es construir una imagen adecuada del sistema, entendiendo que todos los elementos con que el usuario interactúa ayudan a formar esta imagen, como por ejemplo: botones físicos, teclados, monitores de vídeo, documentación (manuales de instrucción, helps, etc.), mensajes de error, entrada y salida de datos, facilidades de ayuda y elementos de interfaz hombre-máquina.
Un proceso de software es un conjunto organizado de actividades y resultados asociados que transforman entradas en salidas y generan un producto de software. Un modelo de proceso de software es una descripción simplificada de un proceso de software, una abstracción útil para explicar los diferentes abordajes de desarrollo (KOTONYA; SOMMERVILLE, 1998; PRESSMAN, 2005).
En el abordaje del modelo de desarrollo iterativo evolucionario, un sistema es desarrollado por medio de sucesivas versiones. Se genera rápidamente un ejecutable, con base en las especificaciones iniciales. En seguida, debe ser refinado, apoyándose en los retornos obtenidos (feedback) del cliente visando a producir un sistema que satisfaga sus necesidades. El sistema es, entonces, entregado o, alternativamente, re-implementado, usando un abordaje más estructurado para producir un sistema más robusto y con mayor capacidad de manutención.
Existen dos estrategias, principales, de desarrollo evolucionario:
Según Sommerville (2007), para sistemas pequeños y medianos, la solución incremental es la mejor elección. Y para sistemas complejos, grandes, de larga duración y/o desarrollados por equipos diferentes, la mejor solución contempla el uso de prototipación (descartable o no) para la definición de requisitos que estén mal comprendidos, con una implementación por medio de un modelo mejor estructurado (modelo en cascada).
En este trabajo, el término prototipación incremental o evolucionaria es usado y, conforme Sommerville (2007) puede ser empleado como sinónimo de desarrollo incremental, en el cual el prototipo no es descartado, sino que evoluciona para atingir los requisitos de los stakehoders.
En desarrollo de software, un prototipo corresponde a una versión del sistema que está ya disponible en las primeras fases de un proceso de desarrollo. La prototipación funcional, de acuerdo con Boar (1984), implementa parte de los requisitos del sistema por medio de la construcción de un prototipo que ejecuta el comportamiento real de este sistema (con la implementación de algoritmos y banco de datos), pudiendo, inclusive, valer-se de herramientas, especialmente, construidas para la confección de ese tipo de prototipo.
En el caso de la prototipación no funcional se obtiene el comportamiento de los stakeholders y del sistema por interacciones e iteraciones con estos, por medio de un conjunto de interfaces gráficas simulando el comportamiento real del sistema (sin la implementación de algoritmos y banco de datos).
Conforme refiere Daniellou (2007), cuando se observa la actividad futura, la ergonomía de concepción debe fornecer un medio de prever el espacio de las formas posibles de esta actividad (márgenes de maniobra), evaluando en qué medida las opciones escogidas, en la concepción, permitirán la implementación de los modos operativos compatibles con los criterios escogidos (salud, eficacia productiva, desarrollo personal, trabajo colectivo, etc.)
Para agregar una reflexión sobre la actividad futura es preciso preparar las condiciones de su simulación, de modo que mismo que no se pueda observar la actividad futura, deben ser buscadas las situaciones existentes (situaciones de referencia) cuyo análisis permitirá esclarecer los objetivos y condiciones de la futura actividad (DANIELLOU, 2007).
En caso de una modernización, el análisis de las situaciones de referencia puede estar basado en aquellas encontradas al comienzo del proyecto, teniendo como objetivo la concepción de programas de computador iterativos, conocer los objetivos del trabajo, los procedimientos e identificar las informaciones y datos tratados por los usuarios, permitiendo, también, identificar su lenguaje y su terminología. No tratando de entender el trabajo para reproducirlo, de modo idéntico, sino transformarlo, informatizándolo, de forma que sea optimizado o, tornándose menos costoso para el usuario.
Después de la evaluación de las principales situaciones de referencia, se parte para determinar cuáles son las fuentes de variabilidad observadas; que en estas situaciones pueden aparecer en el futuro sistema, cuya formalizacción de análisis pasa por una lista de situaciones de acciones características futuras probables (DANIELLOU, 2007). En especial, en ergonomía de concepción informática, las herramientas de prototipaje permiten visualizar la apariencia y el funcionamiento de sistemas a un bajo costo, en ciclos de iteración rápida a lo largo del proceso, con la participación de los usuarios antes de las etapas finales de concepción. Estos prototipos sucesivos de software ofrecen una representación concreta para comunicarse con los usuarios y los proyectistas, constituyendo, también, una guía para la especificación de versiones sucesivas (BURKHARDT; SPERANDIO, 2007).
De acuerdo con Bastien y Scapin (2007), la concepción en general ocurre en tres etapas. Inicialmente, es elaborado el modelo conceptual del programa, tratándose de un modelo de alto nivel del sistema, envolviendo básicamente las funcionalidades y arquitectura de diálogo, pudiendo tomar la forma de un croquis, ilustrando las principales funcionalidades del sistema.
En la segunda etapa, el modelo conceptual es detallado y validado junto al usuario, tratándose de prototipos detallados, en los cuales son diseñadas las cajas de diálogo, sus encadenamientos y la organización de los menús.
En la tercera etapa, el sistema será desarrollado en detalles, con base en los desarrollos anteriores, cuyas interfaces con el usuario podrán seguir guías estilísticas.
Requisitos, para Sommerville et al. (1998), son descripciones de como el software debe comportar-se, informaciones del dominio de la aplicación, restricciones sobre operación de software o especificaciones de propiedad o atributo de un software. Los requisitos son definidos durante los estadios iniciales del desarrollo del software, como una especificación de lo que podrá ser implementado. Los requisitos contienen invariablemente una mistura de información del problema, declaraciones de comportamiento y propiedades del software, condiciones del proyecto y restricciones de construcción.
Los requisitos de software se clasifican en:
Las fuentes de los requisitos (stakeholders, dominio y sistema) pueden ser representadas por pontos de vista de sistema, pues cada punto de vista representa un subconjunto de los requisitos del sistema (NUSEIBEH et al., 2003; SABETZADEH et al., 2010);
En esta investigación, los conceptos de modelo 3C y awareness son utilizados sobre todo para mostrar como las interacciones cara a cara, de un ambiente de trabajo cooperativo, son especificadas de modo a ser mediadas por una solución informatizada que automatiza ese ambiente.
El modelo 3C de cooperación utilizado es derivado del artigo de ELLIS et al. (1991) y se apoya en la concepción de que para cooperar, los miembros de un grupo (C) se comunican, (C) se coordinan y (C) colaboran (3Cs).
Awareness es definido como la conciencia sobre a contextualización de las actividades individuales por medio de la comprensión de las actividades realizadas por otras personas (aun cuando no están comunicándose directamente) refiriéndose a tener conocimiento de las actividades del grupo, saber lo que sucedió, lo que está sucediendo y/o lo que podrá venir a suceder, más allá del propio conocimiento de lo que son este trabajo y el grupo.
Para posibilitar la coordinación y cooperación como un todo, son necesarias informaciones acerca de lo que está sucediendo y acerca de lo que las otras personas están haciendo. Por medio de estas informaciones, los participantes pueden construir un entendimiento compartido en torno de los objetos de cooperación, de los objetivos de las tareas o de todo el trabajo (FUKS, 2007).
* Instituto de Pesquisas Tecnológicas del Estado de São Paulo. Email:
** Escuela Politécnica de la Universidad de São Paulo. Email:
***Escuela Politécnica de la Universidad de São Paulo. Email:
****Escuela Politécnica de la Universidad de São Paulo. Email:
Vol. 32 (2) 2011
[Índice]