Sistemas Multimedia Analisis, Diseño y Evaluacion

55521UD01A01

55521UD01A01

55521UD01A01

Ignacio Aedo Cuevas es doctor en Informática por la Universidad Politécnica de Madrid lleva trabajando en el campo de la hipermedia desde 1990, participando en numerosos proyectos internacionales, nacionales y regionales tanto con financiación pública como privada en el área de sistemas interactivos. Es autor de más de cien artículos y congresos tanto nacionales como internacionales, siendo además miembro del consejo editor de la revista IFETS&IEEE LTTF Journal of Educational Technology and Society. En la actualidad es catedrático de Universidad del Departamento de Informática de la Universidad Carlos III de Madrid.

Cada vez son más y mejores las herramientas de edición multimedia disponibles en el mercado a precios razonables. Sin embargo, el mayor problema está en la formación adecuada de los autores potenciales de trabajos multimedia. Se pretende con este libro presentar, de forma clara y sistemática, las líneas de acción principales de análisis, diseño y evaluación de una aplicación multimedia. La obra Sistemas Multimedia: análisis, diseño y evaluación va permitir al lector interesado: • Analizar los requisitos de los sistemas multimedia, y su integración en los sistemas de información actuales. • Identificar los distintos componentes de éstos, así como las distintas plataformas de distribución existentes: CDROM, Intranet, Internet, etc. • Promover la capacidad de diseño de sistemas, su interrelación con la interfaz de usuario y los requisitos del mismo. • Evaluar los diferentes sistemas multimedia utilizados en los actuales sistemas de información. Para ello se incluyen los siguientes contenidos temáticos: • Medios tradicionales y medios digitales de la información (textos, sonidos, imagen, animación, vídeo, 3D, etc.). • Análisis, diseño, evaluación y dirección de proyectos de sistemas multimedia y de la interfaz de usuario. • Plataformas de difusión (CD-ROM, Intranet, Internet, etc.). Integración de sistemas multimedia en la www. La obra incluye además, como valor añadido, un tema específico de dirección y metodología de proyectos multimedia. ¡Esperamos que el lector vea cumplidas sus expectativas…!

ISBN 84-362-4996-8

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

Unidad Didáctica

Unidades Didácticas Cuadernos de la UNED Aula Abierta Estudios de la UNED Actas y Congresos Estudios de Educación a Distancia Educación Permanente

Ingeniería en Informática (2º ciclo)

SISTEMAS MULTIMEDIA: ANÁLISIS, DISEÑO Y EVALUACIÓN

Colecciones de la UNED

I. Aedo Cuevas A. Vara de Llano F. Mur Pérez P. Díaz Pérez A. Colmenar Santos M. A. Castro Gil M. A. Sicilia Urbán P. Losada de Dios J. Peire Arroba

U.D.

Paloma Díaz Pérez es licenciada y doctora en Informática por la Universidad Politécnica de Madrid, siendo en la actualidad catedrática de Universidad del Departamento de Informática de la Universidad Carlos III de Madrid. Sus intereses se centran en el proceso de desarrollo de sistemas interactivos así como en la incorporación de las tecnologías de la información y de las comunicaciones en el proceso de aprendizaje, habiendo participado en numerosos proyectos relacionados con estos temas. Además, es autora de numerosos artículos internacionales en las revistas más prestigiosas en los ámbitos de su interés (IEEE Transactions on Software Engineering, IEEE Transaction on Education, Information Systems, etc.) y es autora de tres libros relacionados con el proceso de desarrollo de sistemas informáticos y con la hipermedia. Es miembro del comité ejecutivo de IEEE Learning Technology Task Force. Miguel Ángel Sicilia Urbán es doctor Ingeniero en Informática por la Universidad Carlos III de Madrid e Ingeniero en Informática por la Universidad Pontificia de Salamanca. Ha desarrollado su labor docente e investigadora en ambas Universidades, estando actualmente en la Universidad de Alcalá de Henares. Ha trabajado como consultor, tutor y arquitecto software en diferentes empresas, y actualmente desarrolla su labor investigadora en el área de hipermedia adaptativa y los sistemas educativos, con especial énfasis en el tratamiento de la imprecisión y la incertidumbre. Alfonso Vara de Llano es Ingeniero Industrial por la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid, en la especialidad Electricidad, intensificación Electrotecnia. Actualmente es gerente de Proyectos en la División de Servicios Profesionales de Compaq, recientemente fusionada con Hewlett Packard. Anteriormente ha trabajado como Jefe de Proyectos en UITESA (actualmente integrada en IBERINCO perteneciente a al grupo IBERDROLA) y como ingeniero en el Laboratorio de Ensayos Dinámicos de Vehículos Ferroviarios de RENFE. Es profesor asociado de la E.T.S. de Ingenieros Industriales de la UNED y sido durante 1 año profesor asociado en la E.T.S. de Ingenieros Industriales de la Universidad Politécnica de Madrid y durante 4 años profesor asociado en la Escuela Politécnica Superior de la Universidad Carlos III de Madrid.

SISTEMAS MULTIMEDIA: ANÁLISIS, DISEÑO Y EVALUACIÓN Ignacio Aedo Cuevas Paloma Díaz Pérez Miguel Ángel Sicilia Urbán Alfonso Vara de Llano Antonio Colmenar Santos Pablo Losada de Dios Francisco Mur Pérez Manuel Alonso Castro Gil Juan Peire Arroba


Antonio Colmenar Santos es doctor Ingeniero Industrial e Ingeniero Industrial, especialidad Electrónica y Automática por la ETSII de la UNED e Ingeniero Técnico Industrial por la Escuela Universitaria de Ingeniería Técnica Industrial de la Universidad de Valladolid, especialidad Electricidad, intensificación Electrónica, Regulación y Automatismos. Actualmente es Profesor titular en el área de Ingeniería Eléctrica del Departamento de Ingeniería Eléctrica Electrónica y de Control DIEEC de la UNED. Ha sido profesor asociado en el Departamento de Tecnología Electrónica en la Universidad Politécnica de Alcalá de Henares y en el DIEEC de la UNED. Es profesor titular en excedencia del cuerpo de Profesores de Educación Secundaria y de Profesores Técnicos de Formación Profesional en las especialidades de Sistemas Electrónicos y Equipos Eléctricos, respectivamente. Ha trabajado para la AECI-ICI como experto asesor en el proyecto INTECNA (Nicaragua). Es miembro de la sección española de la International Solar Energy Society (ISES) y ha trabajado en diferentes proyectos relacionados con las energías renovables. Ha pertenecido a la Association for the Advancement of Computing in Education. Es experto en aplicaciones de Sistemas Multimedia y posee diferentes publicaciones prácticas apoyándose en estas técnicas. Actualmente, es Coordinador de Virtualización en la ETSII de la UNED. Pablo Losada de Dios es Ingeniero Técnico de Telecomunicaciones por la Escuela Universitaria de Ingenieros Técnicos de Telecomunicación de la Universidad Politécnica de Madrid, en la especialidad de Imagen y Sonido. Ha obtenido el Premio a los mejores Materiales Didácticos en Ciencias Experimentales del Consejo Social de la UNED en 1998. Posee los títulos de Postgrado de Especialista Universitario en “Comunicaciones: Redes, Servicios e InfoVía”, “Desarrollo de Aplicaciones Multimedia: Aplicaciones para InfoVía” y Sistemas de Gestión de Bases de Datos, todos otorgados por la UNED. Ha realizado los cursos oficiales de Microsoft de administración y gestión de Redes NT. En la actualidad trabaja en la UNED como Técnico Especialista para el apoyo informático del profesorado del Departamento de Ingeniería Eléctrica, Electrónica y de Control de dicha Escuela, colaborando en proyectos del departamento, impartiendo cursos de formación y realizando la gestión y el soporte de los servidores del Departamento. Francisco Mur Pérez es doctor Ingeniero Industrial por la Escuela Técnica Superior de Ingenieros Industriales de la UNED e Ingeniero Industrial, especialidad Electricidad, intensificación Electrónica y Automática por la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid. Ha obtenido el Premio Extraordinario de Doctorado de la UNED. Ha obtenido el Premio a los mejores Materiales Didácticos en Ciencias Experimentales del Consejo Social de la UNED en el año 1999. Actualmente es profesor titular en el Departamento de Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED. Manuel-Alonso Castro Gil es doctor Ingeniero Industrial por la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid (UPM) e Ingeniero Industrial, especialidad Electricidad, intensificación Electrónica y Automática, por la misma Escuela. Ha obtenido el Premio Extraordinario de Doctorado de la UPM así como el Premio Viesgo 1988 a la Tesis Doctoral por la aportación a la Investigación Científica sobre Aplicaciones de la Electricidad en los Procesos Industriales. Ha obtenido el Premio a los mejores Materiales Didácticos en Ciencias Experimentales del Consejo Social de la UNED en los años 1997 y 1999. Ha recibido el premio a la "Innovative Excellence in Teaching, Learning & Technology" del "Center for the Advancement of Teaching and Learning" del año 2001. Actualmente es Catedrático de Universidad del área de Tecnología Electrónica en el Departamento de Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED, a la vez que es Vicerrector de Nuevas Tecnologías de la UNED. Ha sido Director del Centro de Servicios Informáticos de la UNED y Subdirector de Investigación y Doctorado, y de Gestión Académica de la ETSII. Ha participado en numerosos proyectos de investigación como investigador, coordinador y director y ha publicado en revistas y congresos, tanto nacionales e internacionales. Ha publicado igualmente diversos libros y material multimedia dentro de sus líneas de investigación y docencia. Ha trabajado cinco años como Ingeniero de Sistemas en Digital Equipment Corporation. Pertenece al comité organizador de los congresos internacionales IEEE FIE, ISES y TAEE, así como es revisor y presidente de mesa. Es miembro Senior del IEEE y del consejo de dirección de ISES España. Juan Peire Arroba es doctor Ingeniero Industrial por la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid e Ingeniero Industrial, especialidad Electricidad por la misma Escuela. Licenciado en Derecho por la Universidad Complutense de Madrid. Actualmente es Catedrático de Universidad del área de Tecnología Electrónica en el Departamento de Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED. Ha sido Director del Departamento. Ha obtenido el Premio a los mejores Materiales Didácticos en Ciencias Experimentales del Consejo Social de la UNED en los años 1997 y 1999. Ha recibido el premio a la "Innovative Excellence in Teaching, Learning & Technology" del "Center for the Advancement of Teaching and Learning" del año 1999. Ha trabajado varios años como Consultor especializado en la creación de Empresas Tecnológicas, así como ha dirigido y dirige diversos proyectos de investigación, tanto nacionales como internacionales. Es miembro del IEEE.

Capítulo 4 FASES DEL DESARROLLO DE SISTEMAS MULTIMEDIA

ESQUEMA 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7.

Ingeniería del software y multimedia. Características del desarrollo multimedia. Las fases del ciclo de vida del desarrollo multimedia. Modelos de proceso para el desarrollo multimedia. Resumen. Ejercicios de autoevaluación. Referencias bibliográficas.

El desarrollo de cualquier producto software es un proceso de ingeniería en el que se siguen una serie de fases de manera sistemática para conseguir un producto de la mayor calidad posible. La ausencia de aplicación este tipo de métodos bien definidos para el desarrollo de aplicaciones informáticas dio lugar en la década de los 70 a lo que comúnmente se ha venido denominando desde entonces crisis del software, convertida ya en «aflicción crónica» para Roger Pressman, y que originó la aparición de la ingeniería del software como la disciplina que propone la utilización de un «enfoque sistemático, disciplinado y cuantificable para el desarrollo, operación y mantenimiento del software» (IEEE, 1990). Los sistemas interactivos, y por ende los sistemas multimedia, no son distintos en este sentido de cualquier otra aplicación software. Sin embargo, la mayor parte de los desarrolladores tienden a trabajar de manera completamente artesanal, bajo el supuesto de que no existe una sólida teoría ni métodos formales que puedan aplicarse debido a las características especiales de este tipo de sistemas. Más en concreto, suele argumentarse que debido al carácter pluridisciplinar del equipo de desarrollo y la premura con la que se suele trabajar, es imposible aplicar un método de ingeniería. El objetivo de este capítulo es, precisamente, mostrar que lo que realmente ocurre es que no se puede pretender seguir el mismo modelo de proceso que para otro tipo de sistemas pero que sí existen métodos de ingeniería del software que son aplicables al desarrollo de sistemas interactivos y en los que de algún modo se recoge la experiencia adquirida por otros diseñadores. Con este fin el capítulo se inicia haciendo una introducción al por qué de la utilización de ingeniería del software en el desarrollo de aplicaciones multimedia como introducción a la sección 4.2 en que se lleva a cabo un análisis de esas características de los sistemas interactivos que hacen que no sea plausible la aplicación de métodos tradiciones, entendiendo como tradicionales aquellos propios del desarrollo de sistemas de información. A continuación se estudiarán, en la sección 4.3, de forma escueta las fases típicas del proceso de desarrollo, puesto que algunas de ellas se abordan de forma completa en otros capítulos, así como posibles modelos de proceso en la sección 4.4.

110

4.1.


INGENIERÍA DEL SOFTWARE Y MULTIMEDIA

Antes de pasar a estudiar en detalle las peculiaridades del proceso de desarrollo de las aplicaciones multimedia, resulta conveniente repasar algunos conceptos propios de la ingeniería del software con el fin de establecer un vocabulario mínimo que se utilizará a lo largo de este capítulo. Con este objeto se ha recurrido al «IEEE Standard Glossary of Software Engineering Terminology» (IEEE, 1990). En primer lugar es preciso distinguir entre el ciclo de vida del desarrollo software y el modelo de proceso del ciclo de vida, usualmente denominado modelo de proceso. El ciclo de vida en sí incluye, de manera genérica, una serie de fases entre las que se encuentran el análisis, el diseño, la implementación y las pruebas o la instalación, pero en ningún caso implica que estas fases tengan que realizarse siguiendo una determinada secuencia. El modelo de proceso es el que establece una forma de trabajo concreta en función del paradigma adoptado (por ejemplo, en cascada, iterativo, en espiral o incremental). DEFINICIÓN: Ciclo de vida del desarrollo de software. • Es el periodo de tiempo que se inicia con la decisión de desarrollar un producto software y que finaliza cuando éste se entrega DEFINICIÓN: Modelo de proceso del ciclo de vida del desarrollo de software. • Paradigma que establece de forma racional cómo llegar desde las necesidades del usuario a un producto software concreto a través de una serie de fases.

El modelo de proceso, a su vez, tampoco es un método de desarrollo. Mientras el modelo establece una secuenciación en las fases del desarrollo, el método propone de forma detallada qué actividades deben llevarse a cabo durante cada una de las fases, qué productos o entidades de diseño deben generarse y también ofrece principios básicos, guías o consejos para producir un software de mayor calidad. Así, existen distintos modelos de proceso que determinan cómo llevar a cabo las distintas fases del desarrollo y, a su vez, para cada modelo de proceso existirán diversos métodos que indicarán qué hacer en cada fase así como las interacciones entre las distintas fases. La adopción de métodos de ingeniería durante el proceso de desarrollo de los productos software, independientemente del tipo de producto del que se trate, hace posible una aplicación sistemática de conocimiento científico con objeto de construir soluciones efectivas y eficientes a un problema dado (Berry, 1992). Así, la utilización de dicho enfoque en el ámbito de las aplicaciones interactivas estará orientado a (Lowe y Hall, 1999):

FASES DEL DESARROLLO DE SISTEMAS MULTIMEDIA

111

■

entender los objetivos y requisitos del producto a desarrollar,

■

diseñar interfaces adecuadas y estructurar la información de acuerdo con las necesidades del usuario,

■

incorporar mecanismos que posibiliten un uso efectivo del producto por parte del usuario final,

■

gestionar el proceso de desarrollo de manera eficiente,

■

emplear métricas que recojan aspectos del desarrollo con los que se pueda controlar su progreso,

■

documentar aspectos relevantes del desarrollo y

■

llevar a cabo un desarrollo que asegure que la aplicación va a a ser fácil de mantener.

El objetivo fundamental será pues obtener productos de calidad y llevar a cabo un proceso de desarrollo de calidad. Por un lado, un producto multimedia de calidad será relevante, completo, correcto, usable y útil. Un proceso de desarrollo multimedia de calidad garantizará la productividad, la reutilización, la facilidad de mantenimiento, la gestión del proceso y las medidas tanto del producto como del propio proceso.

4.2.

CARACTERÍSTICAS DEL DESARROLLO MULTIMEDIA

Los sistemas interactivos y multimedia tienen características intrínsecas que requieren de enfoques distintos a los que se aplican en otras disciplinas. Así, la primera característica singular que hay que destacar es que en el ciclo de vida es preciso introducir una nueva fase: la evaluación. El objetivo de esta fase, que no debe confundirse con las típicas pruebas del software puesto que no tienen ninguna relación, es analizar la utilidad de la aplicación. Esta fase es tan importante en el desarrollo de sistemas interactivos que el presente libro le dedica un capítulo completo, el septimo. Además, existen otros aspectos a tener en cuenta en el proceso de desarrollo de sistemas interactivos que afectan a la selección del modelo de proceso y que hacen que se precisen métodos específicos que tengan en cuenta las peculiaridades de este tipo de productos software, entre las que cabe destacar las que se describen a continuación: • el desarrollo debe estar centrado en el usuario y en sus necesidades, • el equipo de trabajo es pluridisciplinar y • existen algunos requisitos de modelado muy específicos.

112

4.2.1.


Desarrollo centrado en el usuario

Las aplicaciones multimedia, como aplicaciones interactivas que son, tienen como objeto conseguir que el usuario pueda llevar a cabo alguna tarea, ya sea aprender algo, comprar un producto, comunicarse con alguien o simplemente divertirse, de una manera eficiente y efectiva. Dicha tarea se realiza a través de un diálogo que se establece entre el usuario y la máquina, diálogo que se materializa a través de la interfaz de usuario. La interfaz de usuario puede representarse por medio de un modelo general en el que se establecen las relaciones entre los principales agentes involucrados, los entornos y los procesos realizados por ambos. La figura 1 es una simplificación del modelo propuesto por Roy Rada en (Rada, 1995).

FIGURA 4.1. Modelo simplificado de la interacción entre el usuario y la máquina (basado en el propuesto en Rada, 1995).

Los agentes que participan en la interacción son dos: la persona y el ordenador, y el canal a través del cual se materializa el diálogo entre ambos es la interfaz. El conocimiento sobre la tarea a realizar lo tiene la persona, que es realmente quien sabe qué quiere hacer y cuál es la secuencia de pasos a seguir para conseguir su objetivo. Cuando una persona se pone delante de una máquina para completar una tarea, analiza las funciones que le ofrece el producto software y realiza una acción orientada a conseguir su objetivo. A su vez, en el entorno de la máquina el soporte a dicha tarea está implementado de una determinada forma y cada interacción del usuario da lugar a un


113

procesamiento que va a generar una salida específica que el usuario interpretará para decidir si el sistema funciona como él había presupuesto. En la Tabla 4.1 se muestra un ejemplo del proceso cognitivo que se produce cuando un usuario que nunca ha utilizado un procesador de textos intenta emplearlo para escribir una carta. TABLA 4.1. Ejemplo de proceso de cognitivo del usuario durante la interacción Tarea: Poner la fecha a una carta en un procesador de textos Atención

Observa los botones de la barra de herramientas del procesador de textos tratando de encontrar alguno que inserte la fecha de hoy.

Cognición

Identifica un botón que podría justificar la fecha a la izquierda de la página pero no encuentra uno que inserte la fecha fi tendrá que escribir la fecha y luego justificarla.

Intención

Escribe la fecha, selecciona el texto y pulsa el botón.

Codificación

Observa la respuesta que se produce por parte de la aplicación: la fecha ha sido justificada a la izquierda.

Evaluación

El objetivo ha sido conseguido satisfactoriamente, luego se ha seguido el proceso adecuado.

Como se refleja en la tabla, el usuario realiza una serie de actividades cognitivas (en la columna sombreada de la izquierda) que le hacen llevar a cabo una acción sobre la interfaz (la intención) y, tras recibir la respuesta de la aplicación, realiza otras actividades cognitivas que le hacen llegar a una conclusión sobre el funcionamiento de la aplicación y la consecución de sus objetivos. Dichas conclusiones pueden ser acertadas o no, incluso si el resultado recibido es el esperado, puede que el proceso seguido no sea el óptimo. De hecho en el ejemplo mostrado, el usuario no se ha dado cuenta de que podría existir una opción para insertar la fecha directamente sin tenerla que escribir él, de forma que se eviten errores innecesarios. El hecho de que el conocimiento de la tarea resida en el usuario y que la máquina deba responder de la manera que éste espera, lleva a la necesidad de contar con dicho usuario durante el proceso de desarrollo. El enfoque de desarrollo que hace que el usuario y sus necesidades reales se conviertan en las directrices del proceso de desarrollo de un producto software se conoce como diseño centrado en el usuario. DEFINICIÓN: Diseño centrado en el usuario. • Enfoque de desarrollo en el que juegan un papel central tanto el usuario como sus necesidades.

El diseño centrado en el usuario, término acuñado por Gould y Lewis en 1985, tiene como objetivo maximizar la usabilidad del producto para lo cual se asumen cuatro principios básicos (Gould y otros, 1997):

114


■

Focalización temprana y continua en el usuario: es preciso estudiar las características cognitivas, antropológicas, de actitud y los patrones de comportamiento de los usuarios. Para ello es preciso entender la naturaleza de la tarea que se va a realizar con el producto y los requisitos que ésta impone, por lo que es necesario involucrar al usuario en el desarrollo.

■

Medidas empíricas: los usuarios reales, o representantes de grupos de usuarios reales, deben enfrentarse a prototipos o maquetas del producto para llevar a cabo tareas, de tal forma que se puedan recoger y analizar datos válidos sobre la utilidad del sistema.

■

Diseño iterativo: el modelo de proceso debe permitir iteraciones en las que se tengan en cuenta los datos empíricos recibidos de la interacción del usuario con el producto para mejorarlo.

■

Diseño integrado: todos los aspectos del diseño de la usabilidad, ya sea la interfaz, la documentación o el plan de implantación, deben evolucionar a la par y no de forma secuencial.

De acuerdo con la norma ISO 13407 («Human-centred design process for interactive systems»), las actividades involucradas en el ciclo de vida del desarrollo de sistemas interactivos son (figura 4.2): • analizar y especificar los contextos de uso o escenarios, • especificar los requisitos organizativos así como los de los usuarios, • producir soluciones de diseño, y, • evaluar esas soluciones frente a los requisitos. El modelo de proceso elegido, que determina cómo secuenciar estas actividades dependerá de múltiples factores, pero siempre se deberían emplear métodos que den soporte a las cuatro actividades fundamentales que permiten contar la participación activa del usuario durante todo el proceso de desarrollo para construir un producto de mayor calidad. Algunos aspectos a tener en cuenta durante la planificación de la participación del usuario incluyen: • es preciso especificar desde el comienzo del desarrollo cuándo y cómo van a participar los usuarios, ya sean éstos expertos en el dominio de la aplicación o usuarios reales, • hay que tener en cuenta que es conveniente tratar con el usuario en su entorno de trabajo, y, • la terminología y la notación a emplear deben ser familiares para el usuario o fáciles de entender y de aprender, de tal manera que éste siempre comprenda lo que se le está mostrando y pueda contrastarlo frente a su conocimiento del entorno de la tarea.


115

FIGURA 4.2. Actividades del diseño centrado en el humano y sus relaciones (ISO, 1999).

Toda la información proporcionada por los usuarios, ya sea en discusiones sobre el análisis y el diseño o en evaluaciones de prototipos, debe emplearse para mejorar el proceso de interacción convirtiéndose en una valiosa entrada para los procesos de análisis, diseño y construcción.

4.2.2.

Equipo de desarrollo pluridisciplinar

El desarrollo de un sistema interactivo es un proceso que tiene múltiples facetas y, además, no todas ellas son de carácter tecnológico. Así, de acuerdo con (Perece y otros, 1994) se puede ver un sistema interactivo formado por una serie de niveles, cada uno de los cuales se puede subdividir en otros niveles, tal y como se muestra en la figura 4.3. En primer lugar el sistema está formado por el sistema informático y por sus usuarios. Para comprender las necesidades del usuario se pueden requerir conocimientos de psicología, sociología, antropología e incluso fisiología, especialmente si el desarrollo en cuestión no sólo incluye software sino también hardware. Por otra parte el sistema informático puede dividirse en el software de la aplicación, que será desarrollado por personal fundamentalmente técnico, y la interfaz de usuario, que requerirá de la intervención de especialistas en diseño, ingeniería, lingüística o arte (Faulkner, 1998).

116


FIGURA 4.3. Visión modular de un sistema interactivo.

Si bien no siempre es preciso ni factible involucrar a tantos tipos de profesionales, si es recomendable que el equipo sea míninamente pluridisciplinar, contando al menos con: • técnicos capaces de realizar el análisis, diseño e implementación del software de la aplicación, • especialistas en las necesidades de los usuarios que puedan tomar decisiones sobre las opciones de diseño (psicólogos, sociólogos o, por ejemplo, pedagogos en un sistema destinado a la enseñanza), y, • diseñadores gráficos y otros especialistas en el tratamiento de información multimedia. En la tabla 4.2 se muestra las habilidades que deberían cubrirse para el desarrollo de sistemas Web, como ejemplo de desarrollo de sistema multimedia interactivo. En la tabla se indican el tipo de miembro del equipo de desarrollo, las labores que éste debe realizar y, finalmente, las habilidades y conocimientos requeridos. TABLA 4.2. Habilidades requeridas para el desarrollo de aplicaciones Web ampliadas de Hansen y otros, 2001 Miembro del equipo

Labor

Habilidades/Conocimientos

Usuarios

Aportar opiniones y experiencia de uso del producto.

Conocimiento de la tarea a realizar y del dominio en que se lleva a cabo la misma.

Proveedores de contenidos

Producir contenidos multimedia.

Principios de usabilidad, creatividad, diseño gráfico y multimedia, etc. (Continua)

117


TABLA 4.2. (Continuación) Miembro del equipo

Labor

Habilidades/Conocimientos

Ingenieros del Web de nivel 1 (publicadores)

Publicar el material en Web.

Encargados del mantenimiento del Web

Actualizar y mantener los contenidos de información.

Administrador del Web

Gestionar el servidor Web, responsabilizándose de su eficiencia, integridad, seguridad, etc.

Arquitecturas cliente/servidor, comunicaciones, protocolos, mecanismos de seguridad, etc.

Ingenieros del Web de nivel 2

Analizar los requisitos, producir la documentación del análisis y del diseño, establecer los procedimientos de operación y de mantenimiento, definir la política de seguridad.

Plataformas hardware/software existentes (características, limitaciones, etc.), técnicas de especificación y modelado, publicación de páginas Web, etc.

Ingenieros del Web de nivel 3 (gestores de proyectos)

Gestionar los recursos, humanos y técnicos del proyecto para conseguir que las metas se obtengan en el menor tiempo posible.

Planificación y gestión de proyectos, análisis de riesgos, gestión de calidad, etc.

Bases de datos, cgis, html y lenguajes de programación y marcado para Web (HTML, XML, XSL, SMIL, etc), etc. Uso de las bases de datos y/o de lenguajes de marcado.

El hecho de que el equipo de desarrollo sea pluridisciplinar no sólo tiene implicaciones durante los procesos de planificación y gestión del proyecto multimedia, sino también en el modelo de proceso y el método de desarrollo elegidos, puesto que éstos deberán contar con actividades y productos capaces de fomentar la necesaria cooperación y sinergia entre personas de características, conocimientos y habilidades de diversa índole.

4.2.3.

Requisitos de modelado

A la hora de desarrollar un producto multimedia es necesario elegir un método cuyas etapas y productos hagan posible analizar y diseñar cada una de las características del sistema. Las aplicaciones multimedia imponen algunos requisitos en lo referente a las capacidades expresivas del modelo a utilizar que debe aunar ciertos aspectos cognitivos y estéticos, tema que se abordará de manera detallada en el siguiente capítulo. El método de desarrollo debe ofrecer productos que permitan modelar todas las características de las apli-

118


caciones multimedia, ya estén éstas relacionadas con la forma en que debe presentarse la información, con la estructura lógica de la aplicación, con las posibilidades de interacción ofrecidas al usuario, con los mecanismos de seguridad implementados, con los procesos a los que se da soporte o con los caminos y herramientas de navegación incluidos en el producto multimedia.

4.3.

LAS FASES DEL CICLO DE VIDA DEL DESARROLLO MULTIMEDIA

El proceso de desarrollo de aplicaciones multimedia conlleva la realización de una serie de actividades, independientemente de la secuencia que se siga en las mismas (sección 4.4), entre las que se cuentan el estudio de la factibilidad, el análisis, el diseño, la producción, la evaluación y el mantenimiento. En las siguientes subsecciones se comentan brevemente dichas fases como introducción a los modelos de proceso presentados en la sección 4.4. Se proporcionará más información sobre cada fase, las actividades a realizar o los métodos aplicables en los capítulos dedicados a ellas.

4.3.1.

Estudio de factibilidad

El objeto de esta fase es determinar si un determinado producto software es factible, tanto desde un punto de vista técnico como práctico. En el caso de un sistema interactivo, es importante analizar la aceptación que éste podría tener antes de embarcarse en un complejo y costoso desarrollo. Aspectos como la adecuación social del sistema o su utilidad práctica pueden tenerse en cuenta a este efecto (Nielsen, 1993). Durante el estudio de factibilidad se deben considerar todos aquellos factores que podrían afectar al desarrollo y al éxito del producto final, entre los que se cuentan las limitaciones económicas, técnicas, de recursos, funcionales o cognitivas (Lowe y Hall, 1999). Al final de esta fase, el equipo de desarrollo debe tener claro: ■

qué tipo de aplicación se quiere realizar,

■

cuál es su potencial utilidad,

■

qué tipo de usuarios la van a emplear y cómo,

■

cuándo estará disponible,

■

qué limitaciones tendrá asociadas (v.g. restricciones legales) o

■

cuál es su relación con otros productos.


4.3.2.

119

Análisis

El análisis es una actividad orientada a estudiar las características o requisitos de un producto software. Teniendo en cuenta que los productos multimedia son sistemas interactivos orientados a dar soporte a unas determinadas tareas, de las que tiene conocimiento el usuario, una de las actividades básicas de la etapa de análisis es, precisamente, el análisis de las tareas. Así, se deberá saber qué actividades se van a poder llevar a cabo, en qué secuencia, con qué limitaciones, qué opciones existen para cada tarea, etc. Además, es preciso conocer las características de los usuarios que pueden afectar al diseño. Por ejemplo, hay que tener en cuenta las capacidades o discapacidades físicas o cognitivas, la diversidad cultural, la edad, el sexo o cualquier otro parámetro que pueda influir en la forma de presentar la información o en la manera en que se va a producir la interacción. También habrá que analizar el entorno de operación, en el cual se va a hacer uso del producto a desarrollar. Así habrá que establecer si existen limitaciones o estándares a cumplir, si se va a dar soporte al uso de diferentes plataformas de acceso o incluso las características físicas del entorno. Por ejemplo, si se va a instalar un punto urbano de información, será necesario tener en cuenta características ambientales, como la luminosidad o el ruido, a la hora de diseñar la interfaz de usuario. El objetivo último de esta fase es entender qué debe hacer el producto y generar una especificación o pliego de requisitos en la que se recojan todas las características funcionales, no funcionales y de usabilidad de la aplicación. Como se verá en el capítulo 5 existen diversos métodos para llevar a cabo este estudio, entre las que se encuentran la realización de entrevistas, el uso de prototipos, casos de uso y escenarios o el análisis jerárquico de tareas (Preece y otros, 2002). DEFINICIÓN: Especificación de requisitos. • Documentación sobre las características de un producto que recoge qué debería hacer sin entrar en cómo se va a desarrollar.

En general suele organizarse los requisitos de un sistema interactivo en tres categorías: ■

Los requisitos de usabilidad determinan qué se va a entender por un nivel aceptable de utilización y de aceptación del producto final por parte del usuario (Preece y otros, 1994).

■

Los requisitos funcionales establecen funciones que el sistema o producto debe realizar (IEEE, 1990).

120


■

Los requisitos no funcionales que imponen restricciones a los requisitos funcionales relacionadas con la eficiencia, consistencia, reusabilidad, flexibilidad, adecuación a estándares, etc. (IEEE, 1990).

A modo de resumen, la tabla 4.3 muestra ejemplos de requisitos para un curso interactivo multimedia. TABLA 4.3. Ejemplos de requisitos para un curso multimedia Tipo

Requisito

Usabilidad

El curso podrá ser utilizado por alumnos sin conocimientos previos en la materia así como por alumnos que desean especializarse.

Funcional

Se incluirá un buscador que permita localizar información sobre los contenidos del curso de forma eficiente.

No funcional

El curso será accedido masivamente de forma remota y utilizando una conexión vía módem.

4.3.3.

Diseño

El proceso de diseño consiste en convertir una especificación de lo qué el producto debe hacer en una propuesta, más o menos formal, de cómo debe hacerlo. Durante el diseño se va a especificar, en consecuencia, aspectos tales como: ■

cómo se va a estructurar la información,

■

cómo se va a presentar la información al usuario,

■

cómo funciona la aplicación,

■

cómo va a poder interactuar el usuario con el producto en cada momento, o

■

cómo se va a poder acceder al producto aplicando ciertas reglas de accesibilidad y de seguridad.

Con este fin es preciso hacer uso de un modelo de diseño que permita traducir las necesidades en productos más o menos formales que puedan ser discutidos por parte de los diversos miembros del equipo de desarrollo. DEFINICIÓN: Modelo de diseño (Díaz y otros, 1996). • Especificación de las características y funciones de un producto software que permite expresar la solución a los requisitos de una forma abstracta y con una determinada notación.

Por ejemplo, la tabla 4.4 muestra cómo un requisito sobre los tipos de usuarios que va a haber en un curso multimedia son interpretados utilizan-


121

do un diagrama propio de la metodología para aplicaciones hipermedia Ariadne (Díaz y otros, 2001). En dicho diagrama se muestra gráficamente que hay cuatro tipos de usuarios (Docente, Alumno, Administrador y Proveedor de Contenidos) y que uno de esos tipos puede especializarse utilizando tres subtipos (Profesor, Tutor y Coordinador). Esta especificación, que podrá ampliarse incluyendo características y capacidades de acceso para cada tipo de usuario, permite representar de forma no ambigua y clara un requisito. Además, se utiliza una notación sencilla de aprender que permite que el diagrama sea discutido en el seno de un equipo de desarrollo pluridisciplinar así como con los propios usuarios, para comprobar si se ha comprendido bien el requisito antes de invertir recursos en implementar un prototipo. TABLA 4.4. Ejemplos de requisitos y su especificación informal durante el diseño para un curso multimedia Análisis Se va a dar acceso a distintos tipos de usuarios, incluyendo profesores, tutores, alumnos, responsables docentes, desarrolladores de contenidos y administradores.

Diseño Los usuarios se organizarán tal y como se muestra en el siguiente diagrama que utiliza notación UML para representar relaciones estructurales entre tipos de usuarios.

El diseño es un proceso típicamente creativo y abstracto que se ve restringido por limitaciones técnicas, cognitivas y no técnicas (Lowe y Hall, 1999) que deberían haberse recogido durante el análisis y que deben tenerse en cuenta durante el diseño de determinadas partes del producto: ■

Restricciones técnicas. Si bien se suele decir que el diseño debe centrarse sólo en el cómo hacer las cosas, no se puede hacer un buen diseño si se ignoran ciertas restricciones de la plataforma técnica, como por ejemplo la forma en que se va a distribuir el producto o las características típicas de la plataforma de uso. Así, si la mayor parte de los usuarios acceden a un curso virtual haciendo uso de un módem, no es lógico plantear un diseño en el que se incluya la videoconferencia como principal medio de comunicación.

122


■

Restricciones cognitivas. Los usuarios tienen una características físicas (agudeza visual, capacidad auditiva, etc.) y cognitivas (memoria a corto y largo plazo, capacidad de razonamiento y de resolución de problemas) que deben ser respetadas si se pretende construir un sistema utilizable (Dix y otros, 1998). Por ejemplo, si se muestran varias animaciones simultáneamente, no se puede esperar que el usuario atienda a su contenido.

■

Restricciones no técnicas. Existen otras restricciones a considerar como son aspectos legales, de seguridad o de autenticidad. Así, no se puede permitir por ejemplo que un curso virtual permite a sus usuarios acceder a información que viola la legalidad vigente (v.g. datos personales de otros usuarios).

El diseño es, por lo tanto, una compleja actividad en la que se tienen que amalgamar distintos requisitos bajo una misma perspectiva. A la hora de realizar el diseño pueden emplearse diferentes niveles de abstracción y producir diagramas o especificaciones conceptuales o incluso prototipos que ayuden a establecer la solución más adecuada para cada problema. El capítulo 5 profundizará en métodos y técnicas de diseño para productos multimedia.

4.3.4.

Producción

A la hora de producir o generar una aplicación multimedia existen diversas actividades a tener en cuenta, como se muestra en la figura 4.4. En primer lugar es preciso establecer la organización de la aplicación, es decir identificar de qué conceptos se va a hablar o qué pantallas se van a incluir. Una aplicación multimedia está formada por una serie de nodos o unidades indivisibles de presentación en las que se incluyen varios contenidos. Así, cada ventana o cada marco puede considerarse un nodo. Durante la etapa de definición de la estructura se identificarían los nodos y la forma en que éstos se secuencian. Además, se determinarán los contenidos que se van a incluir en cada una de esos nodos, ya sean textos, gráficos, dibujos, animaciones, simulaciones, mundos virtuales, música, sonido o cualquier otro tipo de contenido que se considere de utilidad para conseguir los objetivos del producto. El siguiente paso consiste en producir esos contenidos en un formato procesable por el ordenador. Es posible que se cuente con un guión que describa cómo debe ser el contenido y que haya que generar éste, pero también es posible que se quieran utilizar contenidos que existen pero que no están disponibles en formato no digital. Así, es muy frecuente que se cuente con vídeos o sonidos analógicos y con textos e imágenes en papel que se desean incluir. En este caso el paso previo es la digitalización utilizando el hardware y software adecuado. Una vez obtenido un archivo en formato digital se pasa-


123

rá a retocar el contenido multimedia editándolo con herramientas software al efecto. Este proceso, ya sea de creación o de digitalización y edición, no sólo requiere software y hardware específico, sobre el que se puede consultar en los temas específicos de este libro, sino también de la participación de especialistas en diseño multimedia capaces de editar y generar contenidos de calidad.

FIGURA 4.4. Proceso de producción de aplicaciones multimedia, ampliación de la propuesta de (Lowe y Hall, 1999).

124


Una vez que se tiene la estructura y el contenido, basta con integrar los contenidos en esa estructura y programar aquellos procesos que sean necesarios. Como resultado de esta fase se habrá construido un sistema o un prototipo, dependiendo del modelo de proceso elegido y del estado en que se encuentre el desarrollo.

4.3.5.

Evaluación

La evaluación tiene como misión primordial asegurar que las aplicaciones se han diseñado teniendo en cuenta las necesidades de sus usuarios finales, y no sólo las de los desarrolladores. Este proceso va a proporcionar información que permita comprobar si los mecanismos de interacción se han diseñado correctamente, detectando aquellas deficiencias que haya que solventar o proponiendo mejoras. Es muy importante tener presente que en ningún caso la evaluación es una parte de la etapa de pruebas y depuración, ya que los errores que se buscan con la evaluación están relacionados con la forma de interactuar con el producto desarrollado y tienen su origen en una mala comprensión o interpretación de la forma en que el usuario se comunica con el sistema, y no con posibles fallos o errores en el código. La evaluación es una fase tan importante en el desarrollo de sistemas interactivos que en este libro se le dedica todo un capítulo, el septimo.

4.3.6.

Mantenimiento

El mantenimiento del software consiste en modificar el producto o un componente del mismo una vez que ya se ha entregado, ya sea para corregir errores, mejorar el funcionamiento o alguna otra característica o para adaptarlo a cambios en el entorno (IEEE, 1990). Se estima que en sistemas de información una gran parte del esfuerzo del desarrollo se invierte en mantenimiento, cosa que en el caso de los sistemas multimedia puede variar, especialmente cuando se trata de productos cerrados. En algunas ocasiones la aplicación multimedia se concibe como un CD que una vez generado no va a evolucionar. Pero salvo en esos casos específicos, las aplicaciones multimedia deben mantenerse como cualquier otro tipo de producto software, un mantenimiento especialmente acusado en el caso de los sitios Web. El mantenimiento puede ser de tres tipos: ■

Adaptativo: es aquel que se produce para hacer frente a un entorno cambiante. En los productos multimedia el mantenimiento adaptativo es crucial ya que las necesidades del usuario, incluidas las característi-


125

cas de la plataforma de acceso, están en permanente evolución, por lo que habrá que tener en cuenta nuevos requisitos. ■

Correctivo: es aquel que está destinado a solventar problemas que se hayan detectado durante el uso del producto. Si se ha seguido un proceso iterativo, no debería ser preciso llevar a cabo un mantenimiento correctivo pues todos los fallos de software o de interacción deberían haberse detectado en las fases de producción y evaluación, respectivamente. No obstante, es cierto que en muchas ocasiones es preciso entregar el producto antes de que se hayan llevado a cabo todas las verificaciones y evaluaciones que serían necesarias, por lo que sigue siendo necesario este proceso que corrija los errores que se vayan encontrando.

■

Perfeccionador: es aquel que se lleva a cabo para mejorar el funcionamiento, el mantenimiento u otros atributos del sistema. Por ejemplo, se podría dedicar a optimizar código o a hacer más flexible y modular el sistema para hacer más eficiente su modificación. Este tipo de mantenimiento es también bastante habitual en las aplicaciones multimedia.

4.4.

MODELOS DE PROCESO PARA EL DESARROLLO MULTIMEDIA

Algunos de los paradigmas clásicos de modelo de proceso son (Amescua y otros, 1995): • El modelo en cascada, que exige finalizar una fase antes de poder pasar a la siguiente. • El modelo incremental, en la que se van construyendo versiones del sistema, cada una de las cuales hace frente a un subconjunto de los requisitos. • El modelo evolutivo, que está orientado a conseguir una versión rápida y flexible del producto, susceptible de ser modificada ante una variación en los requisitos. • El modelo en espiral, en el que se hace un desarrollo iterativo basado en el análisis de riesgos. • El modelo basado en transformaciones, que hace uso de herramientas CASE (Computer Aided Software Engineering) capaces de transformar automá- ticamente la salida de cada fase en entrada de la siguiente. • El modelo basado en el uso de prototipos que ofrece una aproximación iterativa en la que se emplean prototipos para involucrar al usuario.

126


El uso de prototipos y su evaluación por parte del usuario o de evaluadores expertos es básico en los sistemas interactivos, como los sistemas multimedia. Por ello, de los modelos de proceso descritos anteriormente el único que sería aplicable es el diseño iterativo. Además, existe otro modelo de proceso más flexible que resulta especialmente adecuado para sistemas interactivos el modelo en estrella (Preece y otros, 1994). Las dos siguientes subsecciones profundizan en estos dos tipos de ciclo de vida y su aplicación al desarrollo de sistemas multimedia.

4.4.1. Diseño iterativo o modelo de proceso basado en el uso de prototipos El diseño iterativo es una aproximación muy utilizada en el proceso de desarrollo de aplicaciones interactivas puesto que permite incorporar al usuario y tener en cuenta sus necesidades desde el pricipio del proyecto. Por su propia naturaleza, el diseño iterativo conlleva el compromiso de desarrollar algo rápido, el prototipo, que permita probar si las decisiones de diseño son o no apropiadas (Preece y otros, 2002). Con este compromiso, el diseño iterativo supone realizar cortos ciclos de análisis y diseño para producir un prototipo que pueda ser evaluado de forma que se obtengan datos fiables sobre su utilidad. Los resultados de la evaluación pueden hacer replantearse cualquiera de las fases previas como se muestra en la figura 4.5, ya que un problema de usabilidad puede deberse a una mala comprensión de los requisitos del producto (reinicio en la etapa de análisis), a un mal diseño de un requisito (reinicio en la etapa de diseño) o a un aspecto de implementación (reinicio en la etapa de implementación de prototipos).

FIGURA 4.5. Modelo de proceso basado en prototipos.


127

A la hora de desarrollar los prototipos hay tres enfoques básicos (Dix y otros, 1998): ■

Prototipos de usar y tirar: los prototipos se utilizan para adquirir conocimiento sobre las tareas a las que el producto debe dar soporte y sobre las necesidades de los usuarios, pero una vez evaluados no se utilizan para construir el sistema final. Por ejemplo, antes de iniciar el desarrollo de un complejo sitio Web (v.g. un banco electrónico) es habitual hacer unas primeras maquetas con alguna herramienta de autor que genere HTML y sin que se acceda a ninguna base de datos ni se programen complejas funciones. Una vez que se hayan decidido gran parte de las características de la aplicación, se establecerá el entorno técnico de desarrollo y se iniciará la verdadera implementación en la que poco, o nada, del código generado para los prototipos se podrá reutilizar.

■

Desarrollo incremental: el producto final se construye como una serie de módulos o componentes, de forma que en cada ciclo de la iteración se incluye un nuevo módulo al producto anterior. Por ejemplo, cuando una empresa se plantea generar su sitio Web y está bajo la presión de salir a la palestra cuanto antes, este tipo de modelo de proceso le permite publicar un producto aún no completo (por ejemplo, sólo páginas informativas) e ir añadiendo nuevos módulos según estos se vayan produciendo (por ejemplo, venta on-line, personalización, comunicación con proveedores, etc.).

■

Desarrollo evolutivo: el prototipo va evolucionando en cada iteración hasta conseguir el producto final. Esta sería la situación idónea siempre que los recursos lo permitan.

4.4.2.

Modelo en estrella

Otro modelo de proceso bastante adecuado para el desarrollo de sistemas interactivos es el ciclo de vida en estrella (figura 4.6) (Preece y otros, 1994). Este modelo de proceso se caracteriza por su gran flexibilidad, ya que no impone ninguna secuencia concreta a la hora de organizar las distintas fases, y por hacer de la evaluación el eje sobre el que debe orbitar todo el proceso de desarrollo. Así, cada proyecto de desarrollo puede iniciarse en la etapa que se desee (análisis, diseño, implementación o desarrollo de prototipos) o en la que se pueda, de acuerdo con las características del equipo de desarrollo, las habilidades y conocimientos de sus integrantes, la disponibilidad de los usuarios para participar en evaluaciones empíricas o cualquier otro factor, pero

128


FIGURA 4.6. Modelo de proceso en estrella.

siempre se pueden y se deben evaluar los resultados de cualquier fase, ya sean éstos un prototipo, un sistema o una simple especificación formal, con el fin de confirmar si realmente se están teniendo en cuenta las necesidades y características de los usuarios. En el capítulo 7 se presentan diversas técnicas de evaluación que pueden aplicarse en las distintas fases del ciclo de vida.

4.4.3.

Selección del modelo de proceso

A la hora de abordar el desarrollo de un producto multimedia concreto es preciso adoptar un modelo de proceso, ya sea diseño iterativo, ciclo de vida en estrella o cualquier otro que se considere adecuado. Existen múltiples factores que influyen de manera decisiva en esta decisión, entre los que se cuentan los siguientes: ■

Tiempo de desarrollo: la mayor parte de los productos multimedia, y en especial aquellos que se desarrollan como sitios Web, deben generarse en un tiempo récord, por lo que el ciclo de vida debe permitir crear un producto o un prototipo en un tiempo mínimo (Lowe y Hall, 1999).

■

Tamaño de la aplicación: no es lo mismo desarrollar una pequeña aplicación, por ejemplo un CD sobre la Antigua Roma que se va a entregar con una revista, que una aplicación de gran envergadura, como por ejemplo el sitio Web de un banco electrónico. Cada tipo de aplicación requiere de un tipo de ciclo de vida. Así, mientras que para productos pequeños un enfoque muy formal puede ser engorroso e


129

inútil, para productos a gran escala es imprescindible aplicar un proceso completamente sistematizado (Lowe y Hall, 1999). ■

Características del equipo de desarrollo: dependiendo de los conocimientos del equipo de desarrollo se podrá adoptar un modelo de proceso u otro. Así, si la mayor parte de los integrantes tienen un perfil técnico será mejor aplicar un modelo iterativo en el que la participación de otro tipo de personas (diseñadores gráficos o usuarios) pueda postponerse hasta que se pueda contar con ellos.

En líneas generales, el ciclo de vida en estrella proporciona mayor flexibilidad ya que permite adaptar el proceso de desarrollo a las necesidades de cada momento. Por otro lado, el desarrollo iterativo marca unas pautas a seguir que pueden resultar de utilidad cuando requiere disciplinar a los miembros del equipo de desarrollo.

4.5.

RESUMEN

Este capítulo ha abordado algunas cuestiones genéricas sobre el desarrollo de productos multimedia, enfocando éste como un proceso sistemático en el que es preciso aplicar métodos propios de la ingeniería del software. Se han puesto de manifiesto algunas características y requisitos propios de los productos multimedia que hacen precisa la adopción de modelos de proceso y métodos de desarrollo especialmente propuestos para este tipo de aplicaciones, entre las que se cuentan el hecho de que el equipo de desarrollo sea pluridisciplinar, que el proceso tenga que estar centrado en el usuario y que haya que especificar características de presentación, navegación, estructurales, de comportamiento, de seguridad o de interacción. Se han presentado brevemente las fases del desarrollo, que incluirían el estudio de la factibilidad, el análisis, el diseño, la producción, la evaluación y el mantimiento, viendo brevemente en qué consiste cada una de ellas. Y, finalemente, se han estudiado posibles modelos de proceso que establezcan cómo secuenciar estas fases y se han presentado algunos factores que influyen en la selección del modelo de proceso, como son la disponibilidad de usuarios y de recursos o las características del equipo de desarrollo.

4.6.

EJERCICIOS DE AUTEVALUACIÓN

4.1. El desarrollo de productos multimedia: a) No difiere en nada del de otro producto informático. b) Requiere involucrar al usuario para verificar la validez de los mecanismos de interacción.

130


c) Consta de menos fases que el desarrollo de cualquier otro producto informático. d) No puede llevarse a cabo utilizando métodos propios de la ingeniería del software.

4.2. El diseño centrado en el usuario: a) No permite aplicar un método sistemático. b) Sólo se aplica a productos multimedia. c) Plantea la necesidad de obtener medidas empíricas sobre la validez de las decisiones del diseño. d) Es una alternativa frente al diseño iterativo.

4.3. Durante la etapa de análisis de los productos multimedia: a) b) c) d)

Siempre hay que utilizar prototipos para recoger requisitos. No hace falta involucrar al usuario. Hay que identificar requisitos de distintos tipos. Los requisitos sólo están relacionados con el usuario o con la plataforma de uso.

4.4. De los miembros de equipo de desarrollo de un sitio Web: a) El ingeniero del Web de nivel 1 tiene conocimientos técnicos más profundos que el proveedor de contenidos. b) El encargado del mantenimiento hace las mismas labores que el proveedor de contenidos. c) Ningún miembro podría asumir varias funciones en un mismo desarrollo. d) El ingeniero del Web de nivel 3 se encarga de realizar el análisis y el diseño de la aplicación.

4.5. En un desarrollo de un producto multimedia: a) El modelo de proceso en cascada es inviable. b) El modelo de proceso en estrella es más flexible que el basado en prototipos, pero, en contrapartida, es menos sistemático. c) La evaluación incluye las fases tradicionales de pruebas del software y verificación de requisitos. d) Nunca se lleva a cabo la fase de mantenimiento.


4.7.

131

REFERENCIAS BIBLIOGRÁFICAS

AMESCUA y otros (1995): A. Amescua, L. García, P. Martínez y P. Díaz. Ingeniería del Software de Gestión: Análisis y diseño de aplicaciones. Ed. Paraninfo, Madrid, 1995. BERRY (1992): D. M. Berry. Academic Legitimacy of the Software Engineering Discipline, Technical Report CMU/SEI-92-TR-34, Software Engineering Institute, Carnegie Mellon University, Pittsburgh (Pennsylvania, EE.UU.), Noviembre 1992. DÍAZ y otros (1996): P. Díaz, N. Catenazzi e I. Aedo. De la multimedia a la hipermedia. Ed. Rama, Madrid, 1996. DÍAZ y otros (2001): P. Díaz, I. Aedo y S. Montero. Ariadne, a development method for hypermedia. Dexa 2001. LNCS 2113, pp. 764-774. DIX y otros (1998): A. Dix, J. Finlay, Gregory Abowd y Russell Beale. Human-Computer Interaction, 2nd Ed. Prentice Hall, 1998, FAULKNER (1998): C. Faulkner. The essence of human-computer interaction. Prentice Hall, 1998. GOULD y otros (1997): J. D. Gould, S. J. Boies y J. P. Ukelson. How to design usable systems. En Handbook of Human Computer Interaction, pp. 231-254. Elsevier Science, 1997. HANSEN y otros (2001): S. Hansen, Y. Deshpande y S. Murugesan, A Skills Hierarchy for Web Information System Development. Web Engineering: Managing Diversity and Complexity of Web Application Development, Eds. San Murugesan y YogeshDeshpande, LNCS, 2016, Springer Verlag, 2001, pp 223 -236. IEEE (1990): IEEE Standard Glossary of Software Enginnering Terminology. IEEE Std. 610.12-1990. ISO (1999): ISO 13407: Human-centred design processes for interactive systems LOWE y HALL (1999): D. Lowe y W. Hall. Hypermedia & the Web: an engineering approach. Jon Wiley & Sons, 1999. NIELSEN (1993): J. Nielsen. Usability Engineering. Academic Press. EE.UU, 1993. PREECE y otros (1994): J. Preece, Y. Rogers, H. Sharp, D. Benyon, S. Holland y T. Carey. Human Computer Interaction. Addison-Wesley, 1994. PREECE y otros (2002) J. Preece, Y. Rogers y H. Sharp: Interaction Design: beyond human computer interaction. John Wiley &Sons, 2002 RADA (1995): R. Rada. Interactive Media. Springer-Verlag, 1995.

Capítulo 5 ANÁLISIS Y DISEÑO DE SISTEMAS MULTIMEDIA

ESQUEMA 5.1. 5.2. 5.3. 5.4. 5.5. 5.6.

La etapa de análisis de requisitos en el desarrollo multimedia. La especificación de requisitos en el desarrollo multimedia. La etapa de diseño en el desarrollo multimedia. Resumen. Ejercicios de autevaluación. Referencias bibliográficas.

Diferentes estudios demuestran que el fracaso en los proyectos software se debe, en muchas ocasiones, a un mal análisis de requisitos (Preece y otros, 2002), que deriva en un producto que ni satisface las necesidades de sus usuarios ni las expectativas del propio equipo de desarrollo, que si bien ha invertido un esfuerzo no siempre lo ha hecho de la forma más productiva. Entender para qué debe servir un producto y a quién debe ser de alguna utilidad tiene que ser una prioridad en cualquier desarrollo de software, puesto que este conocimiento es el que ha de guiar el resto del proceso. Este es precisamente el objetivo de la etapa de Análisis de Requisitos. En los productos multimedia, esencialmente concebidos como sistemas interactivos, esta necesidad es aún más acuciante si cabe. Es imprescindible que antes de comenzar a implementar el producto se tengan claras sus principales características, a quién va destinado, qué tipo de actividades se van a llevar a cabo con él, de qué manera se va a utilizar y dónde, de tal forma que se pueda organizar el subsiguiente desarrollo de la forma más eficiente y productiva. Sin embargo, también hay que tener en cuenta que el análisis de requisitos va a ser un proceso iterativo y evolutivo, en la medida en que según se vaya avanzando en el proceso de desarrollo se van a ir identificando nuevas necesidades o se van a conocer más detalladamente las que ya se habían identificado. Asimismo la etapa de diseño juega un papel fundamental en el ciclo de desarrollo de sistemas interactivos ya que permite abordar la resolución de los requisitos aplicando un nivel de abstracción que hace posible llegar a una solución conceptual de los mismos. Durante el diseño se debe dar lugar a una completa especificación del sistema en la que se tenga en cuenta su estructura, la información que contiene, el modo en que se presenta ésta al usuario final, la forma de interacción con el sistema, los mecanismos de acceso a la información o las reglas que se encargan de preservar la seguridad. El objetivo de este capítulo es profundizar en el análisis de requisitos para sistemas multimedia así como en la etapa de diseño. Con este fin, se inicia el capítulo introduciendo en la sección 5.1 el objetivo del análisis, para pasar a continuación en la sección 5.2 a profundizar en los tipos de requisi-

136


tos que se pueden encontrar en un sistema multimedia, las técnicas que pueden emplearse para recolectar información sobre esos requisitos y la manera de plasmar esos requisitos en un documento que pueda utilizarse en el resto de las fases del proceso de desarrollo. El capítulo se cierra con la sección 5.3 en las que se estudian las necesidades de modelado que presentan los productos multimedia, enfocándolas en seis perspectivas: presentación, estructura, comportamiento, seguridad, funciones y navegación.

5.1.

LA ETAPA DE ANÁLISIS DE REQUISITOS EN EL DESARROLLO MULTIMEDIA

Tal y como se había comentado en el capítulo 4, el análisis es una fase del proceso de desarrollo de un producto software que tiene como objetivo estudiar y documentar las características o requisitos que dicho producto debe tener, dando lugar a una Especificación de Requisitos. En un sistema multimedia, como sistema interactivo, habrá que estudiar las características de sus usuarios, de las tareas que se espera realizar con el sistema a desarrollar y del propio entorno de operación. Antes de pasar a estudiar en más detalle cómo realizar el análisis es preciso ampliar el concepto que se tiene de usuario, ya que no sólo los usuarios finales de un producto son los que tienen que decir algo con respecto al mismo. Por ello, en los sistemas interactivos suele hablarse de destinatarios o «stakeholders» incluyendo dentro de este término a todas aquellas personas, comunidades o grupos cuyas necesidades deben ser tenidas en cuenta (Elsom-Cook, 2001). Así por ejemplo al desarrollar una Universidad Virtual no sólo habría que analizar las características de sus potenciales usuarios (ya sean académicos, administrativos o estudiantes) y del cliente que contrata el desarrollo, sino que también habría que considerar las necesidades y opiniones de instituciones involucradas en el proceso educativo (por ejemplo, organismos internacionales, nacionales, regionales o locales) o que se pueden ver afectadas por el funcionamiento de la misma (por ejemplo, empresas del sector), siempre que se consiga mantener un ritmo de desarrollo adecuado. DEFINICIÓN: El objetivo del análisis de requisitos en un sistema interactivo es (Preece y otros, 2002): • Estudiar a los usuarios, las tareas que éstos realizan y el entorno de operación para identificar necesidades. • Producir un conjunto de requisitos estables que sirvan de guía durante el proceso de diseño.

Al tratar de abordar la especificación de requisitos en los desarrollos multimedia, hay que tener en cuenta que esta especificación se va a hacer de

ANÁLISIS Y DISEÑO DE SISTEMAS MULTIMEDIA

137

forma incremental y flexible, puesto que no se suelen, ni en muchas ocasiones se pueden, identificar a priori todas las características que el producto deberá tener. Esto no significa que la fase de análisis deba evitarse, sino simplemente que debe contemplarse de una forma más flexible (Preece y otros, 2002), una flexibilidad que ya debería provenir del modelo de proceso que se haya adoptado. Así, es muy probable que gran parte de los requisitos se vayan identificando en etapas tales como el diseño conceptual o incluso durante la implementación y evaluación de prototipos. Durante esta importante fase del proceso de desarrollo se van a recoger datos, a interpretarlos y a convertirlos en requisitos estables, que puedan emplearse para verificar la usabilidad y utilidad del sistema final.

5.2.

LA ESPECIFICACIÓN DE REQUISITOS EN EL DESARROLLO MULTIMEDIA

Un requisito es una propiedad o característica que un sistema debe cumplir para que sus destinatarios lo consideren válido. Para conseguir esa aceptación por parte de los usuarios es preciso que el producto final sea útil y utilizable, unas características que no suelen ser fácilmente definibles. El análisis de requisitos en un sistema multimedia es una actividad esencial que trata de extraer del entorno y del usuario todas aquellas características relevantes para el diseño y la producción, unas características que varían en su naturaleza con respecto a otros tipos de aplicaciones software. De hecho, la disciplina denominada ingeniería de los requisitos hace hincapié en la importancia de llevar a cabo una buena recogida de requisitos, entendida ésta como un proceso de ingeniería iterativo y evolutivo (Preece y otros, 2002). En este apartado se describirán los tipos de requisitos que se pueden identificar en sistemas multimedia, algunas técnicas para recoger datos sobre las necesidades de sus destinatarios y en formatos para producir una especificación de requisitos útil durante todo el proceso de desarrollo.

5.2.1.

Tipos de requisitos

Los requisitos pueden hacer referencia a distintas facetas del producto e incluso del propio proceso de desarrollo y tener un nivel de concreción muy dispar. En la tabla 5.1 se muestran algunos ejemplos de requisitos organizados en dos ejes: en el horizontal se distingue entre requisitos sobre el producto o sobre el proceso de desarrollo del mismo, y en el vertical sobre el grado de concreción de los mismos.

138


TABLA 5.1. Ejemplos de requisitos de distinto nivel de abstracción Concreto

Vago

Proceso

R1. El producto se entregará en un R2. Se utilizará un método que inplazo de doce meses a la firma de volucre al usuario. esta especificación.

Producto

R3. El producto se distribuirá como un R4. El producto tendrá una estética único CD autocontenido, que incluirá adecuada para niños. toda la información y los programas necesarios para su utilización.

Cuanto más concreto sea un requisito más sencillo será verificar su cumplimiento, por lo que el análisis de requisitos debería tender a producir requisitos claros, concretos y que puedan medirse. Así, cuando un requisito se exprese de una forma vaga (como R2 y R4 en la tabla 5.1), tal vez sea necesario estudiarlo más en detalle para tratar de formularlo de una manera más precisa. Así, en el requisito R2 de la tabla 1 habrá que indicar qué grado de participación se quiere conseguir por parte del usuario (por ejemplo, en qué etapas, con qué tipo de compromiso, qué tipo de usuario, etc.) y en R4 será preciso detallar qué se entiende por «estética adecuada para niños» (v.g, la que un grupo de niños en representación de los usuarios finales considere adecuada, la que siga algún tipo de recomendación al uso, la que aprueben expertos en interfaz de usuario, etc.). Además, los requisitos pueden clasificarse de acuerdo con su objetivo. Así, en ingeniería del software se ha trabajado tradicionalmente con dos tipos de requisitos: los funcionales y los no funcionales (IEEE, 1990). DEFINICIÓN: Un requisito funcional: • establece las funciones que el sistema o producto debe permitir realizar.

Los requisitos funcionales estarán relacionados pues con las tareas que el usuario puede llevar a cabo con la aplicación, incluyendo aquellas relacionadas con: el acceso a la información (por ejemplo uso de buscadores, índices o mapas, mecanismos históricos, controles de reproducción de contenidos con una duración implícita, etc.); la modificación de la información o de la estructura (por ejemplo, capacidades de anotación, personalización, uso de marcadores, inclusión de nuevos contenidos, etc.); o la capacidad de comunicarse o colaborar con otros usuarios (por ejemplo, mecanismos de comunicación sincrónica o asincrónica, notificación de eventos, creación de grupos de interés, etc.). DEFINICIÓN: Un requisito no funcional: • impone una serie de restricciones a los requisitos funcionales relacionadas con la eficiencia, consistencia, reusabilidad, flexibilidad, mantenimiento, adecuación a estándares, reglas de seguridad, aspectos legales o corporativos, etc.


139

Los requisitos no funcionales no son funciones sino características que deben verificarse en el funcionamiento o en la estructura de la aplicación. Sin embargo esta distinción no es siempre evidente y, además, los requisitos no funcionales pueden afectar a los funcionales y viceversa. Así por ejemplo, limitar el tamaño de la ventana de visualización ¿es un requisito funcional o no funcional? Por ello, a estos dos tipos de requisitos se añaden otras cuatro categorías que permiten recoger aspectos importantes de cualquier sistema interactivo y clasificar las propiedades de una forma más apropiada: los requisitos de usuario, del entorno, de usabilidad y de datos (Preece y otros, 2002). DEFINICIÓN: Un requisito de usuario: • hace relación a características relevantes del grupo de usuarios a los que va destinada la aplicación.

Existen muchas características de los usuarios que pueden tenerse en cuenta a la hora de diseñar el producto, ya sea sobre aspectos personales (por ejemplo, edad, sexo, capacidades físicas y mentales), cognitivos (conocimientos previos, formación, habilidades) o sociales (por ejemplo, rasgos culturales, función social, etc.). A la hora de estudiar al usuario se puede recurrir a estudios psico-sociológicos y antropométricos, si bien hay que tener en cuenta que sólo hay que registrar aquella información que sea realmente relevante y tenga algún tipo de influencia en el desarrollo del producto multimedia (Elsom-Cook, 2001). Además, se puede estudiar al usuario como: ■

un único grupo, del que se extraerán aquellos aspectos comunes que puedan influir en la utilidad del sistema,

■

una serie de grupos distintos con necesidades de interacción diferentes, o

■

como un individuo con características propias que deben ser tenidas en cuenta.

En el primer caso, los requisitos se emplean para mejorar un diseño que es único, mientras que en los otros dos los diseños deben adaptarse, de forma automática o no, a las características de los usuarios. En el segundo caso pueden considerarse distintos tipos de usuarios en función de diversos parámetros (por ejemplo grupos de edad o de experiencia) de forma que se satisfagan las necesidades de todos ellos. Así por ejemplo, en Montero y otros, 2002, se define la estructura de usuarios como un grafo en el que se usan roles y equipos para representar las relaciones existentes entre ellos, de manera que no sólo se conozca mejor como éstos se relacionan como entidades sociales sino que también pueda emplearse este conocimiento para proporcionar un acceso personalizado a la información.

140


El tercer caso presenta sistemas adaptativos en los que es imprescindible mantener un modelo de usuario que recoja sus características y comportamiento mediante alguna técnica de representación del conocimiento así como algún tipo de mecanismo de inferencia que pueda deducir qué hacer en función de esas características. DEFINICIÓN: Un requisito del entorno: • refleja las circunstancias que rodean al uso del producto.

Dentro del grupo de requisitos del entorno se pueden estudiar aquellas restricciones que impone el entorno técnico, físico, organizativo y social. Así, en el entorno técnico habrá que tener en cuenta si se va a emplear un determinado hardware o software que pueda afectar al desarrollo. También puede resultar interesante analizar in situ el entorno físico en que se va a utilizar para detectar si existen parámetros (por ejemplo, nivel de ruidos o iluminación) que puedan a afectar a la utilidad del diseño. Con respecto al entorno organizativo se trata de ver aspectos tales como el tipo de soporte con que van a contar los usuarios para aprender a utilizar el producto o si existen relaciones organizativas que puedan influir en su uso. Finalmente, con el entorno social se pretende hacer hincapié en los aspectos propios del producto como sistema de interacción social. DEFINICIÓN: Un requisito de usabilidad: • analiza la capacidad de ser usado de un producto.

La usabilidad, de la que se hablará más detalladamente en el capítulo 7 dedicado al proceso de evaluación, suele medirse en términos de efectividad, eficiencia, seguridad, utilidad y facilidad de aprendizaje. Desde la ingeniería de la usabilidad se insiste en que la usabilidad es una característica más del producto software y que puede medirse siguiendo métodos rigurosos, de manera que la especificación de requisitos relacionados con esta propiedad debe hacerse cuidadosamente. Así, será preciso que las metas de usabilidad se expresen acompañadas de una serie de métricas (Good y otros, 1986) que permitan valorar la aceptación que tendrá el producto final. Normalmente suelen emplearse criterios tales como: el tiempo requerido para completar una tarea; el porcentaje de tareas completadas; el porcentaje de tareas completadas por unidad de tiempo; el número de errores cometidos por los usuarios; el tiempo empleado para resolver los errores; la frecuencia de uso de la ayuda y de la documentación; el tiempo empleado en la ayuda y en la documentación; el porcentaje de comentarios favorables y desfavorables; el número de comandos erróneos o de repeticiones; y el número de comandos que no han sido utilizados (Faulkner, 1998).

141


Para documentar un requisito de usabilidad puede utilizarse una plantilla como la que se muestra en la tabla 5.2, en la que se muestra el ejemplo de un requisito de usabilidad cuyo objetivo es medir la eficiencia de una determinada tarea en un curso electrónico: la inclusión de una página que ya está creada dentro de un curso electrónico. Para ello los usuarios deberán localizar dónde ubicar la página y añadirla. Como características generales del atributo se tienen (Faulkner, 1998): la métrica que se va a emplear, los tipos de usuarios involucrados y las precondiciones que deben satisfacerse. Además, tal y como propone en (Whiteside y otros, 1998) se añaden una serie de valores que proporcionan una escala bastante útil a la hora de analizar los resultados obtenidos: el valor que se obtendrá en el peor caso, en el mejor, el nivel mínimo aceptable, el esperado y el que actualmente se tiene (éste último a rellenar una vez que se haya llevado a cabo al menos una evaluación del sistema).

DEFINICIÓN: Un requisito de datos: • es aquel que recoge características de los datos que van a incluirse en el producto.

Finalmente, un requisito de datos hará referencia a aspectos tales como los tipos de datos que van a incluirse en el sistema, su volatilidad, el tamaño, la persistencia, la precisión o el valor (Preece y otros, 2002). A este respecto, sería interesante incluir la integridad de los datos como un punto básico a tener en cuenta, particularmente importante en el caso de que se lleve a cabo una gestión descentralizada de los mismos (Ammann y Jajodia, 2000), en la que hay que tener en cuenta los múltiples factores que pueden hacer que los datos no sean consistentes, fiables, actuales, válidos o accesibles. TABLA 5.2. Ejemplo de requisito de usabilidad Atributo

Eficiencia de «Añadir una página a un curso concreto»

Métrica

Tiempo requerido para completar la tarea.

Usuarios

Profesores.

Precondiciones

■

Haber utilizado el curso durante al menos 3 sesiones.

■

Haber creado la página.

Criterios de funcionamiento

Peor caso

No poder incluir la página

Mínimo nivel aceptable

3 minutos

Nivel esperado

1 minuto

Mejor caso

0,5 segundos

Nivel actual

--------------------

142


5.2.2. Técnicas de recolección de datos Como se ha podido ver en la subsección anterior, los requisitos de un sistema multimedia son de naturaleza muy variada, tanto por el tipo de información a que hacen referencia como por la forma en que se expresan y se miden. Para tener un conocimiento apropiado de los mismos será preciso utilizar diferentes técnicas que permitan extraer información tanto del usuario como del entorno. La recolección de datos tiene como objetivo fundamental obtener datos suficientes, relevantes y apropiados para definir un conjunto estable de requisitos o para expandir, clarificar y confirmar ese conjunto en caso de que ya existiese. Durante esta actividad se debe llegar a conocer la forma en que el usuario realiza las tareas a las que el producto a desarrollar dará soporte, así como las metas asociadas a dicha tarea, el contexto en el que se realizan y las razones de por qué las cosas son como son. Existen varias técnicas para recoger información, entre las que se cuentan los cuestionarios, entrevistas, grupos de trabajo o talleres, observación, estudio de documentación o software de registro (Preece y otros, 2002). Estas técnicas son similares a las que se utilizan durante el proceso de evaluación (capítulo 7) pues de hecho tanto el análisis de requisitos como la evaluación comparten un objetivo común: la recolección de datos. La principal diferencia radica en que mientras durante el análisis los datos a recopilar hacen referencia a las características que un producto debería tener, en la evaluación se trata de contrastar con esos datos que se van a recoger si el producto que se está desarrollando está realmente satisfaciendo las necesidades de sus usuarios. En los siguientes apartados se comentan brevemente estas técnicas, algunas de las cuáles se abordan con más detalle en el capítulo 7. Una característica básica de estas técnicas es que son complementarias y que, habitualmente, se suelen utilizar varias para recolectar información sobre el mismo requisito. ■

Cuestionarios. Los cuestionarios son una forma eficaz y barata de recopilar información cualitativa y cuantitativa sobre cuestiones que tienen una respuesta muy específica (Preece y otros, 2002). El mayor problema es diseñarlos de manera que se pueda recoger información relevante, puesto que las respuestas a las preguntas pueden diseñarse de distintas formas y conseguir motivar a los participantes para que rellenen la encuesta.

■

Entrevistas. Las entrevistas ofrecen más flexibilidad que los cuestionarios, en tanto en cuanto la respuesta no está tan limitada o dirigida. Son muy adecuadas para explorar temas (Preece y otros, 2002) y suelen arrojar más datos cualitativos que cuantitativos, si bien se requiere un entrevistador con capacidad para incitar a los participantes a involucrarse en el análisis e incluso para suscitar temas de discusión. Además, la presencia de un entrevistador puede cohibir al usuario.


143

■

Grupos de trabajo. Se pueden organizar grupos o talleres en los que participen varios usuarios o destinatarios junto con miembros del equipo de desarrolla, de forma que se fomente la discusión en grupo sobre temas relevantes del producto y se obtengan distintos puntos de vista del mismo problema. De esta manera, y a diferencia de las entrevistas individuales, se pueden identificar puntos de consenso y de conflicto y, además, se da lugar a una relación más estrecha y directa entre destinatarios del producto y desarrolladores.

■

Observación. El objetivo de esta técnica es tener información del usuario y del entorno de la tarea de primera mano, puesto que lo que se hace es que un miembro del equipo de desarrollo observe al usuario durante su labor y recoja datos de forma directa e indirecta. Los estudios etnográficos se enmarcan dentro de estas técnicas de observación empleadas en las etapas iniciales del proceso de desarrollo. En estos estudios «el etnógrafo participa, de forma patente o infiltrado, en la vida diaria de la gente durante un periodo de tiempo extenso, mirando qué ocurre, escuchando lo que se dice, haciendo preguntas» (Hammersley y Atkinson, 1983). Así pues un etnógrafo dedica una temporada a convivir en el mismo ambiente que el usuario y no sólo observa a estos sino también las interfaces y productos software que éstos utilizan en su rutina, con el fin de detectar requisitos o entenderlos mejor (Shneiderman, 1998).

■

Estudio de documentación. En esta técnica se estudia documentación o estándares que puedan informar sobre las actividades de las tareas a realizar, puesto que en muchas ocasiones algunos procedimientos ya están sujetos a algún tipo de regulación que es preciso tener en cuenta (Preece y otros, 2002).

■

Estudio de la literatura. Otra valiosa fuente de información, especialmente adecuada si el equipo de desarrollo no tiene mucha experiencia en el dominio de aplicación del producto, es buscar en la literatura ejemplos de productos similares (Lowe y Hall, 1999).

■

Prototipos. Los prototipos son una técnica que se usa con mucha frecuencia para recoger requisitos (IEEE, 1998; Lowe y Hall, 1999) puesto que hacen posible enfrentar a los usuarios con productos más o menos interactivos y observar sus reacciones reales.

A modo de resumen, la tabla 5.3 recopila las situaciones en las que es útil cada técnica si bien hay que volver a hacer hincapié en que normalmente se utilizan varias incluso para analizar el mismo requisito. Así, se optará por una u otras dependiendo de diversos factores, entre los que se cuentan el momento del desarrollo actual1, del tipo de usuarios y de su disponibilidad y predisposición

1 Recuérdese que el modelo de proceso para un sistema multimedia tiene que ser cíclico, por lo que el análisis no sólo se realiza al principio del desarrollo (capítulo 7).

144


para participar en el análisis, de los recursos y del tiempo con que se cuenta o de la experiencia del equipo de desarrollo en este tipo de labores. TABLA 5.3. Ejemplos técnicas de recogida de datos en el proceso de análisis Técnica

Objetivo básico

Ejemplo

Cuestionario

Responder a preguntas muy con- ¿Qué navegador para web utilizan los usuarios con más frecretas. cuencia?

Entrevista

Explorar aspectos.

Grupos de trabajo

Confrontar perspectivas distintas. ¿Cómo hay que estructurar la información?

Observación

Conocer el entorno.

Estudio de documentación

Conocer estándares o normativas. ¿Cómo es el proceso de matriculación en el centro de enseñanza?

Estudio de la literatura

Aprender de desarrollos similares. ¿Qué estilos de aprendizaje se están ofreciendo en cursos similares?

Prototipos

Confirmar aspectos.

5.2.3.

¿Qué contenidos debería tener el curso?

¿Cómo son las sesiones de los alumnos de un curso virtual?

¿Tienen los usuarios problemas al responder a los tests de nivel?

La especificación de requisitos

Los requisitos deben plasmarse de manera más o menos detallada en un documento, de tal manera que este documento pueda convertirse en una útil guía durante todo el proceso de desarrollo, ya sea para diseñar, para construir o para evaluar. Una buena Especificación o Pliego de Requisitos tiene las siguientes ventajas (IEEE, 1998): ■

se establece una base sólida para alcanzar un acuerdo sobre lo que el producto debe hacer entre los desarrolladores y los clientes o usuarios;

■

se reduce el tiempo de desarrollo, puesto que al conocer las necesidades del usuario se evita implementar funcionalidades innecesarias y se reduce el número de iteraciones en los procesos de diseño y de producción;

■

se proporciona una base sobre la que llevar a cabo estimaciones de costes y planificaciones, así como validaciones y verificaciones;

■

se facilita la transferencia del producto, y

■

se ofrece una base sobre la que mejorar el producto a través de continuas evaluaciones.


145

Para ello es preciso elaborar un documento que sea correcto, completo, no ambiguo, consistente, verificable, modificable, con referencias cruzadas fácilmente seguibles y en el que los requisitos se ordenen por importancia o por su nivel de estabilidad. En el campo de la ingeniería del software se ha venido utilizando como formato para la documentación de los requisitos el estándar de ANSI/IEEE sobre especificación de requisitos software (IEEE, 1998) cuyo formato se refleja en la figura 5.1.

FIGURA 5.1. Formato de una Especificación de Requisitos, según IEEE, 1998.

Para especificar cada uno de los requisitos (apartado 3 de la Figura 5.1) se puede emplear un formato similar al mostrado en la tabla 5.2 o bien el que se plantea en la figura 5.2 procedente del proceso Volere (Preece y otros, 2002).

5.3.

LA ETAPA DE DISEÑO EN EL DESARROLLO MULTIMEDIA

El diseño tiene como objetivo primordial pasar de la especificación de requisitos, en la que se indica para qué debe servir un producto y a quién, a una propuesta de solución que indica cómo va a ser dicho producto. Esa solución abordará, entre otras, cuestiones tales como:

146


FIGURA 5.2. Especificación de un requisito con el formato Volere (Preece y otros, 2002).

■

la manera en la que se va a estructurar la información (por ejemplo, secuencialmente, en un grafo, jerárquicamente, etc.);

■

la forma en la que se va a presentar la información al usuario (por ejemplo, tipos de contenidos multimedia que se van a utilizar, ritmo de presentación, sincronizaciones, estilos de interacción, etc.);

■

el funcionamiento de aplicación (por ejemplo, cómo se van a poder realizar las distintas tareas, etc.);

■

cómo va a poder interactuar el usuario con el producto en cada momento (por ejemplo qué eventos de usuario se van a gestionar y cómo, qué resultados producen los eventos, etc.), o,

■

la aplicación de ciertas reglas de accesibilidad y de seguridad (por ejemplo, qué mecanismos se van a incluir para hacer que la información sea accesible a todos los usuarios, quién va a poder modificar la información o la estructura, quién va a poder hacer anotaciones personales, etc.).


147

Con este fin es preciso hacer uso de un modelo de diseño que permita traducir las necesidades en productos más o menos formales que puedan ser discutidos por parte de los diversos miembros del equipo de desarrollo. En los sistemas multimedia se pueden considerar las seis perspectivas de diseño que se muestran en la figura 5.3 (Díaz y otros, 2001b).

FIGURA 5.3. Perspectivas de modelado para productos multimedia.

5.3.1.

Modelado de la Presentación

La forma en que se presenta la información es sin duda un aspecto básico en un producto multimedia, y no sólo por razones estéticas, puesto que la manera y el ritmo de presentación de los contenidos pueden determinar en gran medida el éxito de un producto multimedia. Por un lado hay que tener en cuenta que en una composición multimedia en la que los objetos van apareciendo y desapareciendo del espacio de representación, es preciso establecer una coreografía de los contenidos armónica y eficiente, de manera que se consiga no sólo una presentación estéticamente adecuada sino también cogni-tivamente eficiente. Los contenidos van a poder ubicarse en diferentes dimensiones o espacios finitos de coordenadas, que serán como mínimo dos: el de la ventana bidimensional (o tridimensional) y el del tiempo. Además, estos contenidos pueden colocarse en un punto concreto de ese espacio (por ejemplo, «el vídeo demostración se inicia en el segundo 5»), o bien hacer que su presentación

148


dependa de la presentación de otro y otros elementos (por ejemplo, «en cuanto acaba el vídeo demostración se muestra un botón para continuar»). Con este fin, es preciso que el método elegido permita establecer relaciones o restricciones espacio-temporales entre contenidos. DEFINICIÓN: Relación espacio-temporal. • Es aquella que refleja ciertas características que tienen las posiciones de dos o más contenidos en un determinado espacio de representación.

Una relación espacial puede representarse por medio de la topología, la distancia y la dirección a que se encuentran los objetos involucrados como se muestra en la tabla 5.4 utilizando la notación propuesta en (Díaz y otros, 2001a). TABLA 5.4. Ejemplo de notación para relaciones espaciales Parámetro

Significado

Valores

Topología

Relación existente entre las superficies internas y los bordes de los objetos.

Disjuntos (A,B) Juntos (A,B) Solapados (A,B) Cubre (A,B) Contiene (A,B) Iguales (A,B)

Dirección

Orientación relativa entre las esquinas superiores izquierdas de dos contenidos.

Arriba (A,B) Debajo (A,B) Izquierda (A,B) Derecha (A,B) Arribaizquierda (A,B) Debajoizquierda (A,B) Arribaderecha (A,B) Debajoderechaa (A,B)

Distancia

Distancia entre las esquinas superiores izquierdas de dos contenidos.

(distanciaX, distanciaY)

Una relación temporal puede indicarse por medio de un desplazamiento entre el momento de inicio de la presentación y el de finalización entre dos contenidos. Por ejemplo, si un vídeo que dura 3 segundos se inicia un segundo después de abrir un nodo, la relación temporal entre este contenido y el resto de los que se incluyan desde el principio se indicará de la forma (3, -). DEFINICIÓN: Restricción espacio-temporal. • Una restricción espacio-temporal es una especificación dada por el diseñador que obliga a que se verifiquen ciertas características que tienen las posiciones de dos o más contenidos en un determinado espacio de representación.


149

Para poder modelarlas es preciso que el método ofrezca mecanismos para indicar las posiciones de los contenidos haciendo uso no de posiciones absolutas sino de relaciones espacio-temporales con respecto a otros contenidos. La figura 5.4 muestra un ejemplo de alineación por el borde superior entre dos contenidos utilizando la notación presentada en la tabla 4.

FIGURA 5.4. El ítem de contenido B está alineado por el borde superior con respecto al ítem A, de forma que si A se mueve, B se moverá para mantener esta restricción.

A modo de resumen, la tabla 5.5 muestra algunos ejemplos de relaciones y restricciones que podrían incluirse en sistemas multimedia. TABLA 5.5. Ejemplos de relaciones y restricciones espacio-temporales Relación espacial

En el escritorio, cuando un fichero es soltado dentro de la papelera, el icono del fichero desaparece.

Restricción espacial

Todos los campos del formulario tienen que estar justificados a la izquierda.

Relación temporal

Si un vídeo que dura 3 segundos se inicia al mismo tiempo que un sonido que dura 2 segundos, existe un intervalo de 1 segundo durante el cual sólo se presenta el vídeo.

Restricción temporal

El vídeo y su correspondiente subtítulo deben estar sincronizados.

Existen algunos modelos de referencia para hipermedia que incluyen las restricciones temporales y espaciales para ubicar contenidos, y que luego pueden trasladarse a etiquetas de SMIL para su visualización a través de una plataforma Web (capítulo 14, «Lenguajes de marcado y de presentación»). Otro aspecto relevante de cara a la presentación es la posibilidad de separar las características de presentación del contenido en sí, de manera que se potencie la reutilización y la accesibilidad. Cada contenido puede ir acompañado de unas especificaciones de presentación (por ejemplo tamaño de letra, color, tipografía o incluso estilo retórico para un texto). En esa especificación se puede considerar la posibilidad de recoger: la proyección y modificación de objetos tal y como se definen en HyTime (DeRose y Durand, 1994): ■

Proyección de eventos: se trata de poder transformar la posición y la extensión de un evento desde un espacio de coordenadas a otro. A cada

150


evento se le pueden aplicar una o más proyecciones (projectr) que determinarán su posición y extensión en el nuevo espacio de coordenadas. Cada proyección se realiza dentro de un alcance (proscope) que determina un rango dentro del espacio de coordenadas origen en el que aplicar la proyección. Los alcances de proyección en un espacio de coordenadas forman una lista que se denomina baton, que debe estar alineada con las listas de eventos a las que afecte, de tal manera que se pueda llevar a cabo la proyección de los eventos. ■

En la figura 5.5 se muestran dos proyección sobre el mismo objeto (un vídeo): la primera es una transformación de 1 a 3 que se aplica a unos determinados frames, es decir, se ralentiza el vídeo durante esos frames a un tercio de su velocidad; la segunda proyección es de 1 a 0, es decir, una serie de frames del vídeo no se van a mostrar.

FIGURA 5.5. Funcionamiento del módulo de proyección de eventos en HyTime. ■

Modificación de eventos: permite especificar modificadores de objetos así como sus combinaciones. Cada modificador de objeto (object modifier) tendrá efecto únicamente en la extensión determinada por el alcance de la modificación (modscope) al que pertenece. A su vez, los alcances estarán incluidos dentro de una lista de modificaciones (wand). Como ejemplo se muestra en la figura 5.6 una doble modificación sobre las imágenes un vídeo: en la primera de ellas se superponen unas líneas oblicuas y en la segunda unas líneas horizontales.

Además, puede haber varias especificaciones para el mismo objeto, de manera que se seleccione la más adecuada para cada usuario o para el


151

FIGURA 5.6. Funcionamiento del módulo de modificación de eventos en HyTime.

entorno en el que este trabaja. En el primer caso se dará soporte a sistemas que se puedan personalizar o adaptar, y en el segundo se maximizará la accesibilidad. Modelado de la estructura. La información contenida en un producto multimedia tiene una estructura que está compuesta por una serie de nodos y de relaciones estructurales definidas entre dichos nodos. Un nodo es un contenedor abstracto de información (Díaz y otros, 1996) en el que se puede insertar distintos elementos de contenido. Se puede identificar un nodo con una ventana, un marco o una página de un libro electrónico, por ejemplo; mientras que sus contenidos serán los diversos textos, imágenes, fotos, gráficos, vídeos, animaciones, sonidos, etc., que se presenten en los distintos nodos que conforman la aplicación. La separación, lógica y física, de los contenedores (nodos) y de los contenidos en sí (cada ítem multimedia que se incluye en el producto) es útil no sólo porque son elementos conceptualmente distintos, sino porque, además, facilita: ■

compartir información por referencia (como se hace en HTML con imágenes y otros elementos multimedia), de manera que se mejore la consistencia, y

■

reutilizar las mismas estructuras con distintos contenidos (por ejemplo, un producto multimedia presentado en distintos idiomas tiene la misma estructura pero distintos contenidos).

152


Además nodos y contenidos pueden ser simples o compuestos: ■

Un nodo simple es aquel que tiene una serie de contenidos pero no está formado por otros nodos. Por ejemplo, en un libro multimedia una página concreta es un nodo simple.

■

Un nodo compuesto es aquel que está compuesto por otros nodos con los que materializando algún tipo de relación (por ejemplo, generalización/especia-lización, composición o agregación). Por ejemplo, en el libro multimedia el capítulo es una agregación de páginas, y la novela es una generalización de una serie de libros.

■

Un contenido simple es un ítem multimedia que puede aparecer en distintos nodos. Por ejemplo, un texto o una imagen del libro son contenidos simples. Los contenidos se ubican en los nodos mediante una función de localización pero no se embeben en ellos, de forma que se facilita el mantenimiento y la reutilización de contenidos (Díaz y otros, 1996).

■

Un contenido compuesto es aquel que está compuesto por otros contenidos con los que materializando algún tipo de relación (por ejemplo, genera-lización/especialización, composición o agregación). Por ejemplo, una barra de botones es una agregación de varios contenidos.

El hecho de que el método empleado permita representar la estructura a través de estos objetos compuestos y de relaciones estructurales va a hacer posible reflejar una situación que se produce en la mayor parte de los productos multimedia: la existencia de una estructura jerárquica que es preciso mantener. La figura 5.7 muestra un ejemplo de estructura bastante simplificada del Web de una biblioteca en la que puede verse que éste se compone de varias secciones (el catálogo, la información de los usuarios y los documentos que, a su vez, se especializan en tres tipos). Como puede verse, este diagrama sólo incluye información estructural que refleja cómo se organiza la información. Modelado del comportamiento. Las aplicaciones multimedia, como se ha mencionado repetidas veces, son aplicaciones interactivas, lo cual supone que el sistema debe reaccionar ante determinados eventos. Dichos eventos pueden ser activados tanto por ocurrencias no persistentes (por ejemplo, «cuando el usuario selecciona el botón «Parar» se detiene la ejecución del vídeo») como por estados del sistema o de sus objetos (por ejemplo, «siempre que el icono del fichero esté dentro del contorno de la papelera debe desaparecer»). Además, dichos eventos pueden ser provocados por acciones realizadas por el usuario (por ejemplo, «seleccionar un botón») o por el estado sistema (por ejemplo, «tres segundos después de acceder al nodo principal se salta al índice»). Así pues, el método de desarrollo debe tener en cuenta la necesidad de especificar estas reacciones como parte esencial del modelado de la aplicación interactiva.


153

FIGURA 5.7. Diagrama estructural de una biblioteca electrónica basado en la metodología Ariadne (Díaz y otros, 2001),

Otro aspecto a tener en cuenta sobre el comportamiento de las aplicaciones interactivas es la necesidad de incluir elementos (nodos, contenidos, enlaces, etc.) que no se indican de manera declarativa sino mediante una especificación procedimental. Es habitual que muchos objetos que se incluyen en el sistema no existan como tales en la base de información del mismo y que no se pueda hacer referencia a ellos por medio de algún tipo de identificador (por ejemplo un nombre de fichero o un identificador de objeto). Por ejemplo, los resultados de consultas a bases de datos o los enlaces adaptativos cuyo destino depende de lo que haya hecho el usuario previamente (por ejemplo, enlace «Siguiente ejercicio» en un curso adaptativo en el que el siguiente ejercicio propuesto depende de lo que se haya aprendido) necesitan para definirse de algún tipo de procedimiento o de regla que los genere en tiempo de ejecución. En consecuencia, durante el desarrollo también debe tenerse en cuenta este tipo de objetos, normalmente denominados virtuales. Modelado de la seguridad. Cuando un producto multimedia va a ser utilizado por múltiples usuarios es posible que no todos ellos tengan las mismas atribuciones y responsabilidades. Así por ejemplo, en el sitio Web de una universidad no tendrán las mismas posibilidades de acceso los alumnos y los profesores o en una agencia de viajes on-line los clientes individuales y las agencias de viajes. El modelado de la seguridad se refiere exclusivamente a la especificación de una política de seguridad de alto nivel (Fernández y otros, 1996) en la que

154


se describe quién puede hacer qué en qué contexto y no a los mecanismos físicos que se implementarán para proporcionar acceso seguro (por ejemplo, firma digital, cifrado, etc.). Desde esa perspectiva más conceptual que física, la seguridad puede analizarse de acuerdo con tres propiedades: ■

Confidencialidad: está relacionada con la prevención del acceso no autorizado a la información. El objetivo básico es salvaguardar los datos ante operaciones de lectura por parte de usuarios, ya sean personas o programas, no habilitados para ello. Por ejemplo «¿quién puede ver las notas de un alumno?» sería una regla de confidencialidad.

■

Integridad: supone garantizar que la información no se ha falseado o dañado, esto es, que no se han realizado modificaciones inadecuadas, de forma que cuando el usuario acceda a ella sea completa y exacta. Por ejemplo «¿quién pone las notas de un alumno y en qué plazos?» sería una regla de integridad.

■

Disponibilidad: establece que los usuarios habilitados para ello podrán acceder a la información cuando lo requieran. El sistema deberá además responder dentro de unos márgenes de tiempo adecuados. Por ejemplo «cualquier alumno puede acceder a sus notas a través de Internet y desde cualquier dispositivo» sería una regla de disponibilidad.

Confidencialidad e integridad pueden establecerse de acuerdo con una serie de reglas que son computacionalmente tratables, mientras que la disponibilidad involucra parámetros y situaciones que van más allá de los límites del sistema informático (por ejemplo, capacidad de acceso físico a un terminal), por lo que habitualmente no se incluyen como parte del modelado de la seguridad. El método de desarrollo debe permitir integrar la especificación de la política de seguridad, que determine la confidencialidad y la integridad, de tal manera que ésta se exprese en los mismos términos que el resto de las características de la aplicación. Así, si la presentación o la estructura se indican utilizando nodos y contenidos, las reglas de seguridad también deben escribirse haciendo uso de esas mismas abstracciones y no de elementos físicos como puedan ser ficheros, directorios o tuplas de una base de datos. La integración de la seguridad como una parte más del desarrollo hace de éste un proceso integrador y más completo. Métodos como Ariadne (Díaz y otros, 2001), que incluye un modelo de seguridad para especificar las reglas que determinan un acceso seguro a un sistema hipermedia, pueden aplicarse con este fin. En la tabla 6 se muestran ejemplos de qué tipos de reglas de confidencialidad o integridad pueden establecerse para una aplicación multimedia interactiva.


155

TABLA 5.6. Ejemplos de reglas de seguridad en un sistema multimedia Confidencialidad

Quién puede/no puede acceder a un determinado nodo. Quién puede/no puede acceder a un determinado contenido de un nodo.

Integridad

Quién puede/no puede modificar un determinado nodo o contenido. Quién puede/no puede crear nodos o contenidos. Quién puede/no puede borrar nodos o contenidos. Quién puede/no puede personalizar nodos o contenidos.

Como puede verse en la tabla 6, esta especificación tiene dos características fundamentales: ■

Es conceptual, pues las reglas se expresan en función de nodos o contenidos y no se tiene en cuenta si éstos son ficheros, directorios o están almacenados en algún tipo de base de datos.

■

Es multi-nivel, pues las reglas permiten restringir el acceso a un nivel más detallado que el del contenedor de la información (nodo), de manera que se puede conseguir que dos usuarios distintos tengan distintas vistas y distintas capacidades de manipulación para el mismo nodo o para sus contenidos.

Modelado de funciones. El funcionamiento de la aplicación debe también especificarse como en cualquier otro tipo de producto software. Esta no es una característica especial de los sistemas multimedia y por tanto no se profundizará en este tema. Modelado de la navegación. Gran parte de los productos multimedia son en realidad hipermedia, puesto que incluyen enlaces o relaciones navegables entre conceptos (Díaz y otros, 1996). En este caso, es preciso poder especificar esa estructura de navegación, que no hay que confundir con la estructura lógica que se mencionaba en el epígrafe «Modelado de la estructura». DEFINICIÓN: Enlace. • Un enlace es una conexión entre dos nodos que proporciona una forma de seguir referencias entre conceptos relacionados.

Al activar un enlace se puede dar lugar a una gran variedad de resultados, como son: trasladarse a un nuevo tema; mostrar una referencia, una anotación o una definición; presentar una ilustración o esquema; ver un índice, etc. Además, de acuerdo con la forma en que se definan el origen y el destino existen muchos tipos de enlaces, entre los que se cuentan (Díaz y otros, 1996): ■

Enlaces entre posiciones de nodos. El origen y el destino pueden considerarse bien como nodos (enlaces entre nodos), o bien como puntos

156


específicos dentro de los nodos (enlaces entre posiciones). Los primeros expresan una relación semántica entre todo el contenido de un nodo y otro concepto, y suelen representarse en el origen mediante un icono, de forma que esta conexión global se localiza físicamente en una zona de la pantalla. En los enlaces entre posiciones se conecta un elemento de información incluido dentro de un nodo con otro contenido o nodo relacionado. En este caso, se suele emplear el término ancla para designar el punto de enganche del enlace dentro del nodo. La forma de presentar este tipo de enlaces en la pantalla depende de las implementaciones, siendo lo más usual remarcar de algún modo la zona afectada en el origen y situarse o resaltar el punto de destino. ■

Enlaces embebidos. Son aquellos en los que el origen y el destino del enlace se definen en el mismo nodo, permitiendo el desplazamiento a través de los contenidos del mismo. Estas conexiones resultan muy útiles en el caso de las anotaciones incluidas en un mismo nodo, especialmente si éste está basado en ventanas.

■

Enlaces bidireccionales. Cuando los puntos entre los que se define un enlace pueden actuar indistintamente como origen o destino se dice que el enlace es bidireccional. Un enlace bidireccional es más fácil de mantener que dos unidireccionales puesto que en el caso de que uno de los nodos cambie de nombre, sólo hay que cambiar una referencia (figura 5.8).

FIGURA 5.8. Los enlaces bidireccionales frente a los unidireccionales.

■

Enlaces n-arios. Son aquellos cuyo origen o destino está compuesto por un conjunto de elementos. Los enlaces con varios orígenes y un único destino se emplean normalmente para representar conexiones genéricas que afectan a muchos elementos del hipertexto (por ejemplo, enlaces a un nodo de ayuda), de manera que si se cambia el destino sólo haya que modificar un enlace y no varios, con lo que se simplifica


157

la labor de mantenimiento. El enlace con un origen y varios destinos puede utilizarse para representar la llegada a un destino diferente, dependiendo de alguna condición. Por ejemplo, en un sistema de aprendizaje, la selección de un enlace Ejercicios llevará a cada alumno al problema que le corresponde resolver. También es posible emplear este último tipo de enlace para recuperar varios nodos a la vez. ■

Enlaces virtuales. En algunos casos no se puede indicar de forma declarativa el origen o el destino de un enlace porque no existe en la base de información como tal sino que se crea en tiempo de utilización del hiperdocumento. Este tipo de enlace, definido por medio de alguna especificación funcional se denomina virtual. Un sencillo ejemplo consiste en relacionar cada nodo con el visitado anteriormente, mediante la definición de un enlace Nodo Anterior cuyo destino no puede declararse salvo mediante un procedimiento que lo calcule. Este tipo de enlaces permite que las asociaciones entre contenidos puedan determinarse de forma dinámica, dependiendo de algún tipo de condición presente en el momento de su activación, dotando así de una cierta capacidad de inferencia a los sistemas hipertextuales.

■

Enlaces con tipo. Se puede aumentar la definición del enlace añadiéndole ciertas propiedades, ya sea en forma de tipo o de atributos. Así por ejemplo, Conklin propuso la primera distinción entre enlaces estructurales, que responden a relaciones jerárquicas (por ejemplo, entre capítulos de un libro), y los enlaces referenciales, que reflejan una conexión semántica entre dos elementos sin ningún tipo de connotación estructural.

■

Enlaces con atributos. Otra posibilidad es la asignación de atributos, en número no definido, que incrementen la semántica de los enlaces, permitiendo su utilización en el planteamiento de consultas directas en un lenguaje de interrogación. Así, por ejemplo, en un hipertexto al que accediesen múltiples lectores, podría existir la opción de realizar una rápida visita por las últimas novedades incluidas, de manera que se mostraría un subhipertexto formado por aquellos nodos y enlaces cuyo atributo Fecha de creación no superase un determinado valor.

Además de a través de una estructura de enlaces, la navegación suele realizarse por medio de herramientas avanzadas como son los mapas, índices, huellas, mecanismos históricos o buscadores (Díaz y otros, 1996) que facilitan la orientación en grandes espacios de información.

5.4.

RESUMEN

El análisis es una actividad básica en el desarrollo de cualquier sistema interactivo pues va a permitir extraer criterios de aceptación del producto

158


final. Los tipos de requisitos que suelen identificarse se clasifican en requisitos funcionales, no funcionales, de usuario, del entorno, de usabilidad y de datos. Cada requisito es de naturaleza diversa y requiere de una métrica para poder verificarlo. Para recoger información sobre estos requisitos pueden emplearse técnicas tales como los cuestionarios, las entrevistas, los grupos de trabajo, la observación, el estudio de documentación asociada y de la literatura o los prototipos, dependiendo del tipo de requisito, la etapa del desarrollo y otros factores. Los requisitos deben plasmarse en algún documento que sea completo, correcto, no ambiguo, modificable, verificable, con referencias cruzadas y con una clasificación de requisitos según su estabilidad o importancia. El diseño es la fase en la que se aportan soluciones a los requisitos identificados en el análisis para lo cual se hace uso de algún método de especificación o modelo. En el caso de los sistemas multimedia habrá que tener en cuenta que es preciso diseñar la forma en que se muestra la información (presentación), la manera en que ésta se organiza (estructura); la reacción del sistema ante determinados eventos y situaciones (comportamiento); las reglas que aseguran un uso seguro del producto (seguridad), y finalmente, la forma en que se accede a la información (navegación).

5.5.

EJERCICIOS DE AUTOEVALUACIÓN

5.1. Un enlace: a) b) c) d) e)

Siempre hay que utilizar prototipos para recoger requisitos. Puede tener más de un destino. Puede tener más de un destino pero nunca más de un origen. Se define siempre entre un único origen y un único destino. Siempre conlleva un cambio de nodo o página.

5.2. El análisis de requisitos: a) b) c) d)

Retarda el proceso de desarrollo. Se hace al inicio y da lugar a un conjunto invariante de requisitos. Permite detectar requisitos de distinto tipo. Nunca puede hacerse antes de la implementación.

5.3. Al modelar la presentación de un producto multimedia: a) Sólo se consideran aspectos estéticos. b) Se pueden emplear relaciones temporales para crear presentaciones más dinámicas.


159

c) Cada elemento de contenido sólo puede tener una única especificación de las características de presentación. d) Se define la forma en que se accede a los nodos.

5.4. De acuerdo con la notación explicada en este capítulo, para decir que dos contenidos están alineados por la izquierda: a) b) c) d)

La topología tiene que asumir el valor «disjunto». Hay que indicar la distancia en los dos ejes de coordenadas. La dirección es irrelevante. La distancia en el eje de la Y es 0.

5.5. El diseño conceptual de la estructura de un producto multimedia: a) Depende de la plataforma de implementación. b) Sólo se pueden utilizar relaciones de generalización/especialización y agregación. c) Se describe cómo navegar por la información. d) Refleja qué entidades de información hay, cuáles son simples y cuáles son compuestas, y cómo se estructuran las entidades compuestas.

5.6.


AMMANN y JAJODIA (2000): P. Ammann y S. Jajodia, `The integrity challenge. Integrity and Internal Controls in Information Systems: Strategic View on the Need for the Control. Eds. Margaret E. van Biene-Hershey y Leon Strous. Kluwer, Boston, págs. 59-69. DE ROSE y DURAND (1994): S. DeRose y D. Durand, Making Hypermedia Work: A User’s Guide to HyTime Kluwer Academic Publishers, Dordrecht 1994 DÍAZ y otros (1996): P. Díaz, N. Catenazzi e I. Aedo. De la multimedia a la hipermedia. Ed. Rama, Madrid, 1996. DÍAZ y otros (2001a): P. Díaz, I. Aedo y F. Panetsos. Modeling the dynamic behavior of hypermedia applications. IEEE Transactions on Software Engineering, vol 27 (6), Junio 2001, págs. 550-572. DÍAZ y otros (2001b): P. Díaz, I. Aedo y S. Montero. Ariadne, a development method for hypermedia. Dexa 2001. LNCS 2113, págs. 764-774. FAULKNER (1998): C. Faulkner. The essence of human-computer interaction. Prentice Hall, 1998. GOOD y otros (1986): M. Good, T. M. Spine, J. Whiteside y P. George. User-Derived Impact Analysis as a Tool for Usability Engineering. CHI’86 Proceedings, págs. 241-246.

160


HAMMERSLEY y ATKINSON (1983): M. Hammersley y P. Atkinson. Etnography principles and practice. Routledge, Londres. IEEE (1990): IEEE Standard Glossary of Software Enginnering Terminology. IEEE Std. 610.12-1990. IEEE (1998): IEEE Recommended Practice for Software Requirements Specifications. IEEE Std 830-1998. LOWE y Hall (1999): D. Lowe y W. Hall. Hypermedia & the web: an engineering approach. Jon Wiley & Sons, 1999. PREECE y otros (2002): J. Preece, Y. Rogers and H. Sharp: Interaction Design: beyond human computer interaction. John Wiley &Sons, 2002 RADA (1995): R. Rada. Interactive Media. Springer-Verlag, 1995. SHNEIDERMAN (1998): B. Shneiderman. Designing the User Interface: Strategies for effective Human-Computer Interaction. 3.a ed. Addison Wesley, 1998.

Capítulo 6 DISEÑO DE UNA INTERFAZ DE USUARIO

ESQUEMA 6.1. 6.2. 6.3. 6.4. 6.5. 6.6. 6.7. 6.8. 6.9.

La interfaz de usuario. Paradigmas de interacción. Estilos de la interacción. Principios de diseño. Ejemplo de recomendaciones de interacción para un sitio Web de comercio electrónico. Uso de la metáfora. Resumen. Ejercicios de autoevaluación. Referencias bibliográficas.

La interfaz es el canal de comunicación a través del cual se realiza la transferencia de información entre el usuario y la máquina, y si esta comunicación no es fructífera es bastante probable que el producto software seguramente no goce de gran aceptación. Como medio de comunicación, la interfaz es física. Así por ejemplo, el usuario utilizará un teclado, una pantalla, un ratón o cualquier otro dispositivo de entrada o salida cuyas características afectarán de algún modo a la consecución de sus objetivos. Pero la interfaz también es simbólica, en la medida en que cada uno de los elementos que se presentan al usuario tiene un significado y un propósito específico (por ejemplo, el uso de iconos). En consecuencia, la interfaz no sólo ofrece una forma de control sino también un entorno de trabajo, que, de cara al usuario, puede ser explícito (por ejemplo, un escritorio) o no (por ejemplo, un lenguaje de comandos) (Dillon, 1991). Desde los años ochenta, el diseño de la interfaz de usuario ha ido adquiriendo una importancia cada vez mayor en el desarrollo de productos software de calidad. En este capítulo se presentarán, en primer lugar, distintos tipos de interfaces de usuario, así como varios paradigmas de interacción, para pasar a continuación a presentar los estilos básicos de interacción. Al final del capítulo se mostrarán las ocho reglas de oro para la construcción de una interfaz y algunas recomendaciones para el desarrollo de sitios Web de comercio electrónico, para finalizar introduciendo el concepto de metáfora.

6.1.

LA INTERFAZ DE USUARIO

Un sistema multimedia es un sistema interactivo en el que la interacción debe concebirse como un diálogo entre el usuario y el producto software con objeto de completar una tarea, ya sea ésta seguir un curso, leer un libro electrónico, visitar un museo virtual o comprar unas entradas para el cine. La interfaz es el medio a través del cual ese diálogo se materializa, de ahí la importancia de llevar a cabo un diseño cuidadoso que maximice la efectividad y eficiencia de esta comunicación.

164


DEFINICIÓN: Interfaz de usuario. • Comprende aquellos aspectos del sistema con los que el usuario entra en contacto (Moran, 1981)

Puesto que un sistema informático está formado por un hardware y un software, la interfaz afectaría a todas aquellas partes del hardware y del software que el usuario final utiliza para realizar sus tareas. Así por ejemplo, y en cuanto a hardware se refiere, el teclado, el ratón o la pantalla son dispositivos de interacción bastante habituales. En este texto no se analiza el diseño de dispositivos hardware por estar poco relacionado con el objeto del libro. En relación con el software, el usuario tiene a su disposición una serie de objetos (por ejemplo, ventanas, iconos, menús, etc.) con los que interactúa para conseguir sus objetivos. Este capítulo se centra en la forma de diseñar esos componentes del software que conforman la interfaz de usuario con el fin de mejorar la comunicación entre el usuario y la máquina. El primer aspecto a considerar a la hora de diseñar la interfaz de usuario es si el usuario va a interaccionar con ella o no (Díaz y otros, 1996). En el primer caso, tiene lugar un intercambio de información bidireccional entre el usuario y la máquina, como, por ejemplo, sucede cuando se escribe con un procesador de textos. En cambio, en las interfaces no interactivas el comportamiento de la máquina siempre es el mismo, independientemente del usuario o de su entorno, como suele ocurrir cuando se ve televisión. En este texto se supone que las aplicaciones multimedia son básicamente interactivas y no simples presentaciones con las que el usuario no puede interactuar. Centrándose meramente en el intercambio de información, éste puede producirse de diversas formas. Atendiendo a este criterio se pueden distinguir los siguientes tipos de interfaces interactivas: ■

Textual: es aquella interfaz en la que sólo se emplea texto para la comunicación en ambos sentidos (desde la máquina a la persona y viceversa), como por ejemplo ocurre en algunos sistemas operativos como Linux o en las ventanas de comandos de herramientas como Hypercard o ToolBook.

■

Gráfica: es aquella interfaz en la que se puede utilizar texto e imagen en la comunicación desde la máquina a la persona. Este tipo de interfaz era la que ofrecían, por ejemplo, los sistemas hipertexto (Díaz y otros, 1996).

■

Multimedia: es aquella interfaz en la que se emplean medios de naturaleza diversa, como son el texto, la imagen, el sonido o el vídeo en la comunicación desde la máquina a la persona. Este es sin

DISEÑO DE UNA INTERFAZ DE USUARIO

165

duda el estilo predominante en las aplicaciones multimedia en las que se emplean diversos recursos para transmitir información al usuario. ■

Multimodal: es aquella interfaz en la que no sólo la presentación de la información es multimedia sino que la entrada al sistema también es de naturaleza diversa. Se trata de interfaces capaces de responder a sonidos del usuario, a sus gestos o a movimientos de su cuerpo (Preece y otros, 1994). El primer ejemplo de interfaz multimodal es «Put that there» (Bolt, 1980), un sistema que mostraba objetos en la pantalla al usuario y éste para desplazarlos hacía uso de gestos y sonido. En primer lugar señalaba con el dedo el objeto que quería mover, luego decía «put that», de nuevo señalaba con el dedo dónde había que ponerlo y decía «there» para finalizar.

■

Conversacional: es aquella en la que el usuario se comunica con la máquina conversando. Es un tipo especial de interfaz multimodal en el que se establece un diálogo al estilo tradicional. Este tipo de interfaces conllevan técnicas de procesamiento de lenguaje natural que no siempre son necesarias en las interfaces multimodales (véase el caso de «Put that there»). El grupo Media Lab del MIT ha desarrollado varias interfaces conversacionales1 como por ejemplo, Rea o MACK (Stocky y Cassell, 2002).

6.2.

PARADIGMAS DE INTERACCIÓN

Antes de desarrollar cualquier tipo de sistema interactivo, uno de los puntos clave que ayudarán a realizar un diseño efectivo del sistema es la adopción de un determinado paradigma de interacción. DEFINICIÓN: Paradigma de interacción. • Se entiende por paradigma una filosofía o forma de pensar sobre el diseño de la interacción, siendo parte de su historia, sirviendo como puntos clave en la mejora de este proceso (Preece y otros, 2002).

Algunos de estos paradigmas que a los largo de la historia de la informática han cambiado el tipo de diseño son: tiempo compartido, las unidades de vídeo, las herramientas de programación, la informática personal, los sistemas de ventanas y la metáfora. En la actualidad el paradigma más utilizado es la manipulación directa pero los avances que se están produciendo en la sociedad de la información (por ejemplo, miniaturización, acceso en red,

1

http://gn.www.media.mit.edu/groups/gn/projects/humanoid/.

166


telefonía, etc.) hacen que surjan nuevas formas de interacción como la informática ubicua, la informática «pervasiva», la informática que se lleva puesta («wearable computing»), las interfaces tangibles, la realidad aumentada y los entornos atentos («attentive environments»). A continuación se describen estos paradigmas.

6.2.1.

Manipulación directa

El paradigma de manipulación directa se basa en el desarrollo de una representación visual del mundo con el que se va a interactuar, bajo la premisa de que se simplifican las tareas que tiene que realizar el usuario puesto que éste trabaja con objetos que le son familiares. Algunos ejemplos de utilización de este tipo de interacción son el escritorio de algunos sistemas operativos, videojuegos, sistemas de control aéreo, etc. Aunque este tipo de paradigmas se asocian habitualmente con entornos WIMP (Windows, Icons, Mouse and Pull-down menus) pueden ser implementados también, por ejemplo, como entornos virtuales en los que el usuario interactúa con objetos recreados por ordenador. Este es el caso de la figura 6.1 en la que se

FIGURA 6.1. Un ejemplo de manipulación directa en entornos virtuales (Universdidad de Stanford)2.

2

http://www-graphics.stanford.edu/.


167

puede apreciar un usuario que interactúa de forma virtual con un cuerpo humano virtual.

6.2.2.

Informática ubicua

La informática ubicua tiene como objetivo fundamental que los ordenadores desaparezcan del entorno, integrándose en él. Como indica Mark Weiser, un visionario de la computación ubicua, «La computación ubicua no producirá nada nuevo, sino que lo hará más rápido y fácil, con menos esfuerzo y una menor gimnasia mental, transformará lo que es aparentemente posible». Esto no quiere decir que los ordenadores se hagan más pequeños y portátiles sino que éstos se integren en el entorno de manera que extiendan las capacidades de la persona. Por ejemplo, que en una oficina los post-it, los papeles y las pizarras estuvieran intercomunicados compartiendo información. En la figura 6.2 se puede ver tres dispositivos integrados en una oficina (CommChair®, DynaWall® e InteracTable®).

FIGURA 6.2. Tres ejemplos de informática ubicua (Fraunhofer Institut für Integrierte Publikations und Informationssysteme).

6.2.3.

Informática pervasiva

La informática pervasiva es un paso hacia delante en la informática ubicua, teniendo como idea subyacente el poder interactuar con la información desde cualquier lugar y en cualquier momento. Ejemplos de este paradigma son los frigoríficos que incorporan una conexión a Internet para poder realizar la compra, las agendas electrónicas que a través de tecnología Bluetooh permiten la conexión inalámbrica con la oficina central, etc. En la figura 6.3 se puede ver una representación gráfica de una solución de la compañía IBM para poder realizar este tipo de informática.

168


FIGURA 6.3. Una representación de informática pervasiva (IBM)3.

6.2.4.

Computación que se lleva puesta

La informática que se lleva puesta se inspira en muchas de las ideas subyacentes a la informática ubicua. La idea fundamental de este paradigma es que las tecnologías multimedia y de comunicaciones pueden integrarse en las ropas que portan las personas. Esto quiere decir que las gafas, jerséis, joyas, etc. proporcionan un medio con el cual el usuario puede interactuar con la información mientras se mueve por el entorno. En la imagen de la figura 6.4 se puede ver un reloj que en realidad es un ordenador con sistema operativo Linux.

3

http://www-3.ibm.com/software/pervasive/.


169

FIGURA 6.4. Un ordenador incluido en un reloj (IBM)4.

6.2.5.

Interfaces tangibles

Las interfaces tangibles (tangible bits o tangible interfaces) se basan en el aumento computacional del entorno físico, encontrando formas de combinar la información con objetos y superficies facilitando las actividades que lleve a cabo el usuario. De esta forma, y como se puede ver en la figura 6.5, un usuario puede interactuar con una maqueta de una zona e interactuando con ella tener distintas perspectivas de un área.

FIGURA 6.5. Un ejemplo de interfaces tangibles (MIT Tangible labs)5.

4 5

http://www.research.ibm.com/WearableComputing/. http://tangible.media.mit.edu/.

170


6.2.6.

Realidad aumentada

El paradigma de la realidad aumentada es otro tipo de interfaces tangibles, en el que representaciones virtuales se sobreponen a los objetos reales, acercando el mundo físico y el virtual. En la figura 6.6 se puede ver un ejemplo de realidad aumentada en el que sobre un papel físico se integra una representación virtual de una torre con reloj, de manera que cuando el papel se mueva también lo hará la torre.

FIGURA 6.6. Un ejemplo de realidad aumentada (Jim Vallino de Rochester Institute of Technology)6.

6.2.7.

Entornos atentos

Los entornos atentos (attentive environments) tienen como objetivo que el ordenador se anticipe a las necesidades del usuario de manera que sepa que quiere hacer. En este caso el control deja de tenerlo el usuario pasando a ser el ordenador quien controla el entorno, por lo que la forma de interacción con el usuario se basa en respuestas mediante expresiones, gestos y/o comportamientos. En la figura 6.7 se puede ver el robot ERS-7 AIBO de Sony que tiene diversos comportamientos autónomos de acuerdo a la voz y la cara del dueño.

6

http://www.se.rit.edu/~jrv/.


171

FIGURA 6.7. Un ejemplo de un entorno atento (Sony)7.

6.3.

ESTILOS DE LA INTERACCIÓN

Excepto en el caso del paradigma de los entornos atentos, en el que como ya se ha dicho la iniciativa la tiene el ordenador, en el resto de los casos el usuario interactúa con el sistema de maneras muy diversas. Al definir la interfaz en cualquiera de estos paradigmas el diseñador puede utilizar cualquiera de los siguientes estilos de interacción básicos (Shneiderman, 1998): selección por menú, rellenado de espacios, lenguajes de comandos, lenguaje natural y manipulación directa.

6.3.1.

Selección por menú

En la selección por menú, los usuarios leen una lista de elementos y eligen el más apropiado para la tarea que tienen que realizar, aplican una determinada sintaxis para indicar su selección (por ejemplo, sitúan el cursor encima de la opción), la confirman (por ejemplo, pulsan con el cursor la opción), se inicia la acción y observan sus efectos. En la figura 6.8, el usuario ha desplegado el menú

FIGURA 6.8. Ejemplo de interfaz de selección por menú. 7

http://www.aibo.com/.

172


Archivo y ha situado el cursor sobre la opción Guardar como. A continuación, deberá pulsar el ratón sobre la opción y esperar la respuesta del sistema. Algunas de las ventajas de este estilo de interacción son: un aprendizaje rápido, utilización de estructuras de decisión y una fácil gestión de errores. Algunas desventajas son: el peligro de utilizar muchos menús, la lentitud para los usuarios que son expertos en el uso del sistema y que necesita mucho espacio de pantalla.

6.3.2.

Rellenado de espacios

En el rellenado de espacios, el usuario ve una serie de campos en los que, situándose con el cursor, podrá introducir los datos solicitados. Esto obliga a que los usuarios tengan que comprender y conocer las etiquetas y sus posibles valores, así como, el método de introducción de datos y los errores que se puedan producir. La figura 6.9 muestra un formulario en la que aparecen diversos huecos que se tienen que rellenar con una serie de valores para la facturación de una venta.

FIGURA 6.9. Ejemplo de interfaz de espacios en blanco.


173

Algunas de las ventajas de este estilo de interacción son: se simplifica la entrada de información, permite utilizar herramientas para la gestión de formularios y es sencillo ofrecer ayuda al usuario. La mayor desventaja es que necesita mucho espacio en la pantalla.

6.3.3.

Lenguajes de comandos

Los lenguajes de comandos ofrecen al usuario una serie de expresiones con las que realizar sus peticiones. Cuando el usuario aprende los comandos y su sintaxis, lo cual no es inmediato, construye complejos mandatos que le producen una sensación de control e iniciativa, hasta llegar a creerse el dominador del sistema. En la figura 6.10, aparece un comando del sistema operativo MS-DOS que hace que el resultado de ejecutar la instrucción DIR/W se almacene en el fichero FICHERO.TXT.

C: \ > DIR/W > FICHERO.TXT FIGURA 6.10. Ejemplo de interfaz de lenguaje de comandos

Algunas de las ventajas de este estilo de interacción son: es flexible, da la iniciativa al usuario y permite la creación de macros al usuario. Algunas desventajas son: habitualmente se gestionan mal los errores y se requiere mucho entrenamiento para aprender a utilizarlo de forma eficiente.

6.3.4.

Lenguaje natural

Las interfaces de lenguaje natural proporcionan una forma cómoda de interacción hombre-máquina, puesto que emplean frases para expresar las peticiones del usuario. El problema que surge con este tipo de interfaces es que, al no ser los comandos independientes del contexto en que se producen, es decir, de lo que ha sucedido hasta llegar a la situación actual, son impredecibles, y muchas veces se requieren diálogos de clarificación. La principal ventaja de este estilo es que no hace falta aprender la sintaxis del idioma. Algunas desventajas son: requiere muchos diálogos de clarificación, es algunas veces impredecible y puede requerir un esfuerzo añadido.

6.3.5.

Interfaces de manipulación directa

En los interfaces de manipulación directa, el diseñador crea una representación visual del entorno en el que se mueve el usuario. Las tareas que se le proporcionan pueden simplificarse manejando directamente los objetos

174


que le interesen. En la figura 6.11 puede verse el escritorio del sistema operativo Windows, en el que borrar la carpeta «sobre ed» supondría seleccionarlo con el cursor y arrastrarlo hasta la papelera.

FIGURA 6.11. Ejemplo de interfaz de manipulación directa.

Estos tipos de interfaz pueden emplearse de forma aislada o bien se pueden combinar. La selección del más apropiado va a depender de parámetros tales como el tipo de información a presentar, la clase de opciones a realizar, el usuario, etc. En resumen, puede decirse que el uso de estos interfaces debe estar de acuerdo con los objetivos generales del desarrollo que se está realizando. Algunas de las ventajas de este estilo de interacción son: se representa visualmente el concepto de la tarea, se puede aprender fácilmente y se evitan muchos errores de manera natural. Algunas desventajas son: suelen ser difíciles de desarrollar (aunque en la actualidad existen muchas herramientas que hacen mucho más fácil esta labor), requieren dispositivos externos y, en muchos casos, la realidad no se ha reflejado de manera fiel.

6.4.

PRINCIPIOS DE DISEÑO

Se puede decir que no existen panaceas en la creación de la interfaz, pero sí una serie de líneas generales que se deben cumplir y que habrá que interpretar, refinar y extender, utilizando un proceso iterativo que permita obtener el mejor resultado. Estas líneas pueden ser: • principios de diseño, que dan cuerpo a las teorías de diseño de la información en forma de recomendaciones;


175

• reglas, que dan un camino más detallado sobre aspectos específicos de la interfaz; • guías de estilo, que son una colección de reglas de diseño y principios que aseguran una apariencia similar en un conjunto de aplicaciones (por ejemplo, las guías de las aplicaciones Windows de Microsoft), y, • estándares, que son colecciones internacionalmente reconocidas de reglas y principios que proporcionan al diseñador con un marco de trabajo basado en la experiencia (por ejemplo, ISO 13407 es un estándar dedicado a la definición de los procesos de diseño centrado en el usuario en sistemas interactivos). Ben Shneiderman ha definido unos principios de diseño, denominadas las ocho reglas de oro, que se han de tener en cuenta en el diseño de cualquier interfaz (Shneiderman, 1998) y que ayudan al diseñador a la hora de analizar la usabilidad de su sistema. • La interfaz debe ser consistente, es decir, que en situaciones similares se debe emplear la misma secuencia de acciones. Se debe utilizar una terminología idéntica en los mensajes, menús y pantallas de ayuda. Un ejemplo de consistencia sería usar siempre el comando Nuevo para crear cualquier elemento, en vez de tener comandos alternativos dependiendo de la situación. • La interfaz debe permitir accesos rápidos, de tal manera que los usuarios que utilicen frecuentemente el sistema puedan reducir el número de interacciones. Algunos ejemplos de este tipo de técnica son el empleo de teclas de función y de macros o programas que realizan un conjunto de acciones individuales. • La interfaz debe ofrecer al usuario una respuesta que le indique lo que ha sucedido en cada una de las operaciones realizadas. Por ejemplo, cuando solicita cambiar el tamaño de un objeto, el sistema lo presentará modificando sus dimensiones. • Las secuencias de acciones incluidas en la interfaz deben tener un principio y un fin. Por ejemplo, la búsqueda de una palabra en un editor de texto se inicia con la aparición de la ventana que solicita la palabra a buscar y el final se alcanza bien cuando se ha encontrado o bien cuando se cumpla otra condición (por ejemplo, se ha recorrido todo el texto seleccionado). • El sistema debe minimizar la posibilidad de que el usuario pueda cometer errores, de manera que, por ejemplo, no pueda realizar una determinada acción si no dispone de toda la información necesaria. Pero como es inevitable que el usuario se equivoque, el sistema debería proporcionar mecanismos de vuelta atrás después de realizar una tarea compleja.

176


• La interfaz debe permitir deshacer acciones. Las unidades reversibles pueden ser una acción simple, una entrada de un dato o un grupo de acciones completo. Por ejemplo, cuando se borra un elemento por confusión se debe poder anular la acción, recuperando el elemento eliminado. • La interfaz se debe diseñar de manera que el control de la interacción lo tenga el usuario, ya que así se sentirá más cómodo con el sistema. • La interfaz debe permitir el empleo de fórmulas con una sintaxis ya construida, abreviaciones, códigos y otros tipos de información, de forma que el usuario pueda recordarlas más fácilmente. Un claro ejemplo de esta recomendación es el uso de la palabra DIR en vez de DIRECTORIO.

6.5.

EJEMPLO DE RECOMENDACIONES DE INTERACCIÓN PARA UN SITIO WEB DE COMERCIO ELECTRÓNICO

Estos principios básicos pueden utilizarse en cualquier tipo de desarrollo para asegurar la usabilidad del producto. A su vez se pueden definir un conjunto de recomendaciones que ayuden al diseñador a poder asegurar que su sistema es útil y utilizable. En este sentido en esta sección se presentan algunas pistas y recomendaciones a tener en cuenta aplicadas en el terreno del comercio electrónico, aunque válidas para cualquier entorno, y en concreto al caso de las tiendas electrónicas, a través de preguntas que se podría plantear el diseñador a la hora de abordar el desarrollo del producto. Las respuestas a estas preguntas están basadas en el trabajo de uno de los gurús en el campo de la interacción como es Jackob Nielsen. (Nielsen, 1999). P.1. ¿Cómo conseguir que el usuario realice rápidamente la tarea, tenga un porcentaje bajo de errores y una alta satisfacción? Para que el usuario realice rápidamente una determinada tarea debe estar familiarizado con la misma, de manera que comprenda su significado y alcance. Además, la descomposición de la tarea en acciones, así como su secuenciación, tiene que ser la adecuada de acuerdo al conocimiento del usuario. Además, no tienen que producirse retrasos innecesarios debido a un mal dimensionamiento de la página, de manera que el tiempo de respuesta estándar no debería superar un segundo. Otra forma de que se realice rápidamente la tarea, es evitar incluir distracciones en la información, evitando que se produzca sobrecarga tanto desde el punto de vista de «peso» de la página como de cantidad de información. El usuario estará más satisfecho si en todo momento sabe qué parte de la tarea ha realizado y cuanto le queda por realizar. Así por ejemplo, en una tienda electrónica es importante indicarle qué pasos ha realizado y cuáles le falta por hacer antes de realizar la compra (figura 6.12).


177

FIGURA 6.12. Indicación al usuario de que tarea está realizando y cuáles le quedan por hacer (BOL)8.

P2. ¿Cuál es la velocidad esperada en la interacción? La velocidad de interacción depende de muchos factores tales como la edad, el conocimiento del medio, la familiaridad con la tarea, la disposición del dispositivo y del usuario, etc., por lo que es muy difícil diseñar un sitio Web que se adapte perfectamente a todo tipo de usuarios. Habrá que tener en cuenta que el usuario novel prefiere velocidades más lentas que los expertos, por lo que la selección por menús es un buen mecanismo para ellos, el cual debería combinarse con acceso mediante teclas rápidas para que los expertos no se aburran utilizando el sistema. Además, si el usuario ha tenido experiencias previas, intentará obtener resultados que sean, al menos, igual de satisfactorios que los que obtuvo en anteriores ocasiones. P3. El usuario se pregunta ¿Qué puedo hacer aquí? Uno de los grandes problemas al visitar un sitio Web se produce cuando el usuario ha llegado a una determinada página y se pregunta ¿y ahora qué? Para responder a esta pregunta, la interfaz debe proporcionar toda la información necesaria para que el usuario pueda tomar una decisión correcta sin tener que pulsar el botón de vuelta atrás. Además, todos los caminos para realizar las acciones que permite el sistema tienen que estar accesibles, por lo que no se deben crear caminos específicos para las opciones generales. Para ello, el diseñador deberá considerar la posibilidad de incluir un directorio que ofrezca todas las alternativas, así como un motor de búsqueda que facilite el acceso a informaciones específicas. P4. ¿Qué consideraciones tiene que tener en cuenta el diseñador si se quiere incluir información multimedia? La primera consideración que hay que tener en cuenta es la capacidad de almacenamiento necesario para poder contener toda la información del sitio. En segundo lugar, habrá que considerar que este tipo de contenidos requiere un ancho de banda para su transmisión muy superior al de la información textual pudiendo producirse retardos inadmisibles en la recuperación de las páginas, lo que generará incertidumbre y aburri-

8

http://www.bol.com/.

178


miento en el usuario. Por ello, y en la actualidad, es recomendable no incluir el material multimedia en la página sino hacerlo descargable o incluir los denominados m-iconos, representaciones parciales del contenido multimedia (por ejemplo, un icono que represente varios fotogramas con baja calidad de una película).

Figura 6.13. Ejemplo de m-icon (TC-Helicon)9.

P.5. ¿Qué hacer si se requiere una aplicación externa (distinta del navegador)? Es muy habitual proporcionar al usuario información que no puede visualizarse directamente a través del navegador que está utilizando. Cuando ocurre esto, la interfaz debe advertirlo avisando al usuario de este hecho y proporcionándole los mecanismos necesarios para poder recuperar ese contenido (por ejemplo, mediante un enlace a la página desde la que puede descargar ese software o mediante la ejecución de un proceso que inicie la fase de instalación del mismo). P.6. ¿Cuál es el periodo de funcionamiento del sistema? Una de las características más importantes de un sitio Web es que debe estar operativo veinticuatro horas ya que no se sabe en que momento un cliente potencial va a acceder. Aunque aparentemente este aspecto parece que no está dentro de lo que serían los aspectos de interacción, no es así ya que este es un parámetro muy importante para que el usuario este satisfecho con el sitio Web. P.7. ¿Cómo orientar el diseño del sitio Web? El diseño del sitio Web debe estar orientado al producto que se quiere vender y al usuario que potencialmente puede comprar. Por ello el sitio tiene que atraer al cliente de manera que cuando visita la página le enganche, también tiene que ser utilizable por parte del cliente comprendiendo cuáles son las opciones disponibles y como utilizarlas, y, por último, tiene que ser fiable de manera que el aspecto que

9

http://www.tc-helicon.tc.


179

proporcione inspire confianza al usuario (por ejemplo, ¿alguien compraría en un sitio que se llame www.estonofunciona.com?). Además, se tiene que considerar las características y necesidades del público al cual se quiere atraer, teniendo en cuenta características como la edad, los objetivos, el nivel cultural, la nacionalidad, etc. En la figura 6.14 se puede ver una pantalla del sitio Web Egallery en el que se distintos mecanismos de búsqueda al usuario, así como la facilidad de comprar cualquier obra.

FIGURA 6.14. Un buen ejemplo de diseño orientado al producto y a sus usuarios (Egallery)10.

10

http:// www.artbrokerage.com/mall/mall.htm.

180


P.8. ¿Es más importante la legibilidad o la vistosidad del sitio? Por supuesto, es más importante la legibilidad que la vistosidad del sitio Web. La legibilidad no se refiere únicamente al tipo de letra utilizado sino también a como el usuario puede «leer» los contenidos multimedia que incluye el sitio. Por ello es muy importante combinar los elementos multimedia de tal modo que se favorezca la comprensión sin crear distracciones innecesarias al lector (por ejemplo, un icono en movimiento que cambia el foco de atención o simultanear elementos que requieran la atención). Si se utilizan animaciones o gráficos muy complejos, se reduce de manera significativa la eficiencia del sistema y, por lo tanto, se crea insatisfacción en el usuario. Además la velocidad de captación de información de cada usuario es distinta por lo que hay que realizar una composición armónica de los contenidos que permita una comprensión completa del mensaje que se quiera transmitir. En cualquier caso, habitualmente se desarrolla una plantilla sobre la que los contenidos multimedia se van presentando, lo que facilita en gran medida al usuario la lectura. Respecto las locuciones, se debe primar la claridad (buena vocalización, entonación, etc.) de manera que el oyente interprete correctamente el mensaje. Para todos los contenidos multimedia, habrá que analizar si la calidad y comprensión de la información puede verse afectada por retardos debidos a la congestión en la red y al ancho de banda del servidor/cliente. Cuando se utiliza información textual, se debe utilizar una tipografía que sea nítida (por ejemplo, se suele recomendar una tipografía de tipo serif para los títulos y una sans serif para el texto) y con un tamaño adecuado y proporcionado en distintas resoluciones. Ya que cuando se lee no se leen palabras, sino que las identificamos por su forma, especialmente por la parte inferior de la letra más que por la superior, es importante elegir una tipografía que no dé lugar a ambigüedades. También por esta razón, es mejor utilizar letras minúsculas que mayúsculas ya que en este segundo caso se ralentiza la lectura. La calidad de la imagen y la cantidad de espacio requerido para su almacenamiento son directamente proporcionales e inversamente proporcionales a la eficiencia, por esta razón hay que adoptar una solución de compromiso que dependerá de la importancia que tenga la imagen para el objetivo del sistema. Por ejemplo, en la figura 6.15 se presenta una tienda de arte para la cual es muy importante la calidad de la imagen, aunque ofrezca la posibilidad de visualizarla en distintas resoluciones dependiendo del interés del cliente. A la hora de definir el tamaño en pixels de la imagen hay que tener en cuenta que la imagen debería poder verse completa en configuraciones estándar (por ejemplo, podría tener una tamaño de 350 x 600 pixels para una resolución de 480 x 640), pero además habría que tener en cuenta que si se va a querer imprimir se va a hacer habitualmente en un tamaño de papel estándar (por ejemplo, 670 x 535 pixels para papel US letter).


181

FIGURA 6.15. El sitio Web de una galería de arte en el que la calidad de la imagen es muy importante.

P.9.

¿Por qué es importante mantener la consistencia? La consistencia permite hacer un uso semántico del color y de otros recursos audiovisuales (tipografía, sonidos, etc.) lo que facilita el aprendizaje y comprensión del sistema que se esté utilizando. Además, la consistencia también se basa en utilizar los mismos nombres para referirse a las mismas cosas, además de que las mismas funcionalidades deben activarse siempre del mismo modo y producir el mismo tipo de resultados.

P.10. ¿Cómo tiene que ser la información que muestre el sistema? Las funciones y los datos que proporciona, el sistema tienen que ser tangibles, lo que significa que tiene que ser explícito como se utiliza el sistema y para qué sirve la información. El sistema tienen que transmitir al usuario su intencionalidad, así como la de la información incluida en él. Además, todos los controles tienen que ser visibles y dar pistas de cómo se utilizan, ya que en algunas ocasiones y debido a un mal diseño el usuario puede que no sepa como hacer una determinada tarea o acción, o como se utiliza el mecanismo para poder llegar a realizarla. La principal recomendación que se puede dar es que todas las unidades de información (nodo o páginas) sean autocontenidas, evitando en la medida de lo posible hiperenlazarlas de manera que se le proporcionen al usuario los caminos «razonables», y se utilice los contenidos

182


multimedia para realzar el contenido del nodo y hacerlo más fácilmente identificable. Otra recomendación es el uso de herramientas de navegación que ayuden al usuario a moverse por el espacio de información, proporcionándole pistas sobre dónde está, cómo ha llegado allí y qué puede hacer. Algunas de estas herramientas de navegación son: visitas guiadas, que son caminos más o menos lineales a través del espacio de información establecido por el diseñador (figura 6.16); mapas, representación gráfica del contenido del sistema (figura 6.17); mecanismos de vuelta atrás, posibilidad de volver al nodo anteriormente visitado; facilidades de ayuda, proporcionan una guía general para utilizar el sistema e información específica sobre elementos y situaciones en las que los usuarios podrían encontrarse; y los mecanismos de búsqueda, complementan la navegación útil para acceso rápido a información de la que se tiene algún conocimiento.

FIGURA 6.16. Una visita guiada por una galería de arte (Egallery).


183

FIGURA 6.17. Un ejemplo de mapa (Disney)11.

6.6.

USO DE LA METÁFORA

Cuando una persona está leyendo crea representaciones mentales que se asemejan a la estructura de un documento de papel, en términos de localización espacial y de organización global (Dillon, 1992). Estas representaciones, o modelos, se derivan de años de lectura de distintos tipos de documentos. La misma conclusión se puede extrapolar para otros contextos, deduciéndose que cuando un usuario se encuentra en una situación conocida aplica patrones de comportamiento adquiridos a través de la experiencia. La utilización de metáforas (Barker y Manji, 1991) en la interfaz de usuario explota modelos ya asimilados, situando al usuario en un entorno de trabajo que se asemeja a una situación real. DEFINICIÓN: Metáfora. • La metáfora es la utilización de una realidad conocida por el usuario para dirigir el comportamiento e interacción de un sistema.

11

http://www.disney.com/.

184


El empleo de metáforas en el diseño del interfaz ayuda a clarificar la naturaleza de los elementos de información que contiene el sistema, y consigue que el usuario capte la manera en la que éstos están relacionados. Además, al usuario se le facilitará el acceso a las herramientas que ya le son conocidas, lo cual le permitirán situarse rápidamente en el entorno de trabajo. Hammond y Allison (1987) subrayan la importancia de la integración de la metáfora en el diseño del sistema, ya que puede servir para el doble propósito de disciplinar al diseñador y ayudar al usuario a aprender. Esta integración permitirá, además, acercar el modelo conceptual del sistema al modelo mental del usuario. Estos autores argumentan también que en las metáforas existen dos dimensiones relevantes para la comprensión de la información: el ámbito y el nivel de descripción. El ámbito se puede equiparar al número de conceptos dirigidos a la comprensión del usuario del sistema. Las metáforas que tienen un ámbito muy amplio intentan abarcar todas, o muchas, de las funciones del sistema y de las tareas que éste proporciona. Algunos ejemplos son: el pupitre (por ejemplo, desktop en el sistema operativo Windows) y el libro (por ejemplo, libros electrónicos publicados por GlassBook12). Una metáfora de ámbito más pequeño es la metáfora hidráulica, que utiliza tuberías para el transporte de la información en los sistemas operativos Unix y MS-DOS (comando pipe). El nivel de descripción de la metáfora equivale al tipo de información que se intenta transmitir. Este tipo puede ser de muy alto nivel, tal como pensar sobre las tareas y su ejecución, o de muy bajo, reflejando una sintaxis de comandos que permita recordarlos fácilmente. Las metáforas no necesitan estar destinadas a todos los niveles de descripción, ya que no tienen que explicar todos los aspectos del sistema. Tampoco todas las características de la metáfora tienen que regir la aplicación, así que, si parece ser inapropiada en algún nivel de la descripción, es mejor no forzarla. Una regla importante es evitar relaciones erróneas entre la metáfora y el dominio del sistema, puesto que el usuario puede sentirse engañado. Se pueden cubrir varios aspectos de un sistema multimedia utilizando metáforas (Väänänen, 1995): • la presentación, es decir, cómo aparecen, suenan e incluso se sienten los objetos y los espacios de información; • la estructura, es decir, cuáles son las relaciones entre los distintos espacios, y, • la interactividad, es decir, cómo interactúa el usuario con la información. Es importante que no se produzcan inconsistencias entre estos aspectos (Eberts, 1994).

12

http.//www.glassbook.com/.


185

La metáfora necesita generalmente, y en particular en un sistema multimedia, ser concreta y familiar, altamente estructurada y explícita, visual y multimedia, y, además, espacial (Väänänen, 1995). Si un usuario está familiarizado con la metáfora que emplea, el sistema multimedia, podrá comprender de manera rápida e intuitiva su funcionamiento y si, además, se le hace explícita la estructura de la información, se podrá reducir considerablemente el problema de la pérdida en el espacio de navegación del sistema. La multimedia ayudará a mejorar la calidad de la metáfora utilizando todos los canales sensoriales como base de adquisición de la información. Las metáforas espaciales proporcionan al usuario un sólido modelo cognitivo para la navegación, ya que existe una relación directa entre el espacio de información y el de la metáfora. Algunos ejemplos de las metáforas más empleadas en los sistemas multimedia son: la historia, el viaje, el museo y el libro. a) Las historias representan un mecanismo duradero y atrayente para la comunicación de información, especialmente en un contexto educativo, por eso McLellan (1992) ha aconsejado su uso en los sistemas multimedia. Según esta autora hay tres razones fundamentales para emplear historias: • proporcionan una estructura de la información familiar y conocida; • pueden reducir la carga cognitiva de la navegación, gracias a la riqueza de la información, y, • pueden ayudar a convertir la interactividad inherente al sistema en una participación activa y creativa mediante el uso de los elementos involucrados en la historia. b) La metáfora del viaje consiste en la inclusión en el sistema de visitas guiadas, de manera que el usuario piensa que está viajando por ella. El éxito de este tipo de metáfora depende de la habilidad del diseñador para crear distintos caminos, así como de las opciones de selección que proporcione al usuario. c) En la metáfora del museo, el conocimiento está expuesto del mismo modo en que se podría encontrar en un museo real. El usuario es libre de navegar por las distintas estancias, ya sea en una forma preestablecida o una libre. d) El libro de papel es el modelo que toma la metáfora del libro para representar los contenidos, la estructura y los servicios. El corpus del conocimiento está incluido en sus páginas de información electrónica, que se muestran sobre una pantalla (Reynolds y Derose, 1992). La interpretación de la metáfora empleada, así como de las recomendaciones que se han ido exponiendo para la creación del interfaz, hace que cada

186


diseñador, partiendo de los mismos requisitos, realice un desarrollo multimedia distinto. Además, el cumplimiento de estas normas no significa que el sistema resuelva satisfactoriamente las expectativas de los usuarios. Por todo ello, en el capítulo 7 se verá cómo se puede evaluar la interfaz creada, con la finalidad de concluir no sólo si el producto es bueno, sino cuáles son las deficiencias a solventar para mejorarlo.

6.7.

RESUMEN

En este capítulo se ha presentado el diseño de la interacción como uno de los elementos fundamentales en el desarrollo de cualquier aplicación multimedia, y a la interfaz como elemento que sirve de comunicación entre el usuario y el sistema. Se han presentado, también, distintos tipos de interfaces y varios paradigmas de interacción que en la actualidad se está desarrollando y que hacen el campo de la interacción persona-ordenador un campo fascinante. En las dos secciones siguientes se proporcionan un conjunto de principios que hay que tener en cuenta a la hora de desarrollar un sistema interactivo, y se resuelven algunas de las preguntas que cualquier diseñador de este tipo de sistemas puede hacerse cuando afronta un desarrollo. Por último, se han introducido el concepto de metáfora como una forma de aprovechamiento del conocimiento previo del usuario con objetos o situaciones (por ejemplo, un libro o un viaje) a la hora de utilizar un sistema interactivo.

6.8.


6.1. ¿Cómo se denomina la interfaz en la que las entradas de información son de naturaleza diversa? a) b) c) d)

Multimedia. Multimodal. Conversacional. Textual.

6.2. ¿Qué paradigma tiene como objetivo acercar el mundo físico y al virtual sobreponiendo elementos virtuales a la realidad? a) b) c) d)

Ubicuo. «Pervasivo». Entorno atentos. Realidad aumentada.


187

6.3. La mayor ventaja del «Rellenado de espacios». a) b) c) d)

Aprendizaje rápido. Facilidad en la gestión de errores. Simplifica la entrada de información. No hace falta aprender la sintaxis del idioma.

6.4. ¿Quién da un camino más detallado sobre aspectos específicos de la interfaz? a) b) c) d)

Principios de diseño. Reglas de diseño. Estándares. Guías de estilo.

6.5. ¿Qué herramienta de navegación complementa la navegación mediante un acceso rápido a información de la que se tiene algún conocimiento? a) b) c) d)

6.9.

Mapas. Visitas guiadas. Mecanismos de vuelta atrás. Mecanismos de búsqueda.


BARKER y MANJI (1991): P. Barker. y K. Manji. Designing Electronic Books. Educational and Learning Technology International (ETTI). 28 (4), págs. 273-280. BOLT (1980): R. A. Bolt. Put that there: Voice and gesture at the graphics interface. Computer Graphics, 14(3), págs. 262-270. DÍAZ y otros (1996): P. Díaz, N. Catenazzi e I. Aedo. De la multimedia a la hipermedia. Ed. Rama, Madrid, 1996. DILLON (1992): A. Dillon. Human Factors issues in the design of hypermedia interfaces. Ed. Brown, H. «Hypermedia/Hypertext and Object-Oriented Databases». Chapman &Hall (Londres), págs. 93-105. EBERTS, R.E. (1994): R.E. Eberts. User Interface Design. Prentice Hall. Londres. HAMMOND y ALLISON (1987): N. Hammond y L. Allison. The travel metaphor as a Design Principle and Training Aid for Navigating around Complex Systems. Eds. Diaper, D. y Winder, R. «People and Computers III». Cambridge University Press (Gran Bretaña), págs. 75-90. MCLELLAN, (1992): H. McLellan. HyperStories: some guidelines for instructional designers. Journal of research on computing in education. 25 (1), págs. 28-49.

188


MORAN (1981): T. P. Moran. The command language grammar: a representation for the user interface of interactive systems. International Journal of Man-Machine Studies, 15(1), págs. 3-50. NIELSEN (1999): J. Nielsen. Designing Web usability. New Riders Pub. (versión española publicada por Prentice Hall. PREECE y otros (1994): J. Preece, Y. Rogers, H. Sharp, D. Benyon, S. Holland y T. Carey. Human Computer Interaction. Addison-Wesley. PREECE y otros (2002): J. Preece, Yvonne Rogers and Helen Sharp. Interaction Design: beyond human computer interaction. John Wiley & Sons. REYNOLDS y DEROSE (1992): L.R. Reynolds y S.J. Derose. Electronic books. Byte. 17 (6) (Junio), págs. 263-268. STOCKY y CASSELL (2002): T. Stocky y J. Cassell. Shared Reality: Spatial Intelligence in Intuitive User Interfaces. Proceedings of Intelligent User Interfaces. Enero 13-16, San Francisco, CA, pp. págs. 224-225. SHNEIDERMAN (1998): B. Shneiderman. Designing user interfaces. Pearson educación. VÄÄNÄNEN (1995): K. Väänänen. Metaphor-based User Interfaces for Hyperspaces. Eds. Schuler, W., Hannemann, J. y Streiz, N. «Designing User Interface for Hypermedia». Springer Verlag (Alemania), págs. 68-78.

Capítulo 7 EVALUACIÓN DE SISTEMAS INTERACTIVOS

ESQUEMA 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7.

El concepto de usabilidad. Métodos de evaluación. El proceso de evaluación. Parámetros para la evaluación de sistemas multimedia. Resumen. Ejercicios de autoevaluación. Referencias bibliográficas.

Los sistemas multimedia son aplicaciones interactivas con las que el usuario establece un diálogo para llevar a cabo una serie de tareas de índole diversa. Uno de los objetivos primordiales de cualquier desarrollador de sistema multimedia debe ser conseguir que dicho diálogo sea fructífero, es decir, lograr que el usuario sea capaz de utilizar la aplicación para satisfacer sus objetivos en el mínimo tiempo posible y cometiendo el mínimo número de errores. La interfaz, ya sea física o simbólica, es el canal a través del cual se establece dicha comunicación entre la persona y el ordenador. Si bien existen reglas o guías de diseño que pueden ayudar al desarrollador a incrementar la calidad de la interfaz, como se ha visto en el capítulo 6, éstas sólo pueden tomarse como meros consejos ya que sólo se podrá afirmar que los usuarios son capaces de utilizar con éxito un sistema si se ha realizado una evaluación que corrobore este hecho. La evaluación, que como se verá en este capítulo puede llevarse a cabo en todas las fases del proceso de desarrollo, va a proporcionar información que permita comprobar si los mecanismos de interacción se han diseñado correctamente, detectando aquellas deficiencias que haya que solventar o proponiendo mejoras. Es muy importante tener presente que en ningún caso la evaluación es una parte de la etapa de pruebas y depuración, ya que los errores que se buscan con la evaluación están relacionados con la forma de interactuar con el producto desarrollado y tienen su origen en una mala comprensión o interpretación de la forma en que el usuario se comunica con el sistema, y no con posibles fallos o errores en el código. La evaluación tiene como misión primordial asegurar que las aplicaciones se han diseñado teniendo en cuenta las necesidades de sus usuarios finales, y no sólo las de los desarrolladores. El objetivo de este capítulo es profundizar en qué consiste la evaluación de sistemas multimedia, qué técnicas existen para evaluar y cuándo debe o puede utilizarse cada una de ellas, cómo puede realizarse el proceso de evaluación y qué aspectos se puede analizar en él para obtener información valiosa de cara a mejorar la interacción con el sistema. Para ello se va a comenzar analizando en la sección 7.1 en el concepto de usabilidad. A con-

192


tinuación, la sección 7.2 intentará dar una visión de qué se entiende por evaluación, viendo brevemente qué se puede evaluar, por qué, cuándo y cómo. Finalmente, se profundiza en la forma de llevar a cabo la evaluación presentando algunos métodos de evaluación (sección 7.3), un proceso genérico para proceder con la evaluación (sección 7.4) y algunos aspectos que se pueden medir durante el proceso de evaluación de un producto multimedia (sección 7.5)

7.1.

EL CONCEPTO DE USABILIDAD

La aceptación de un producto software depende en general de un conjunto de parámetros (reflejados en la figura 7.1) que según (Nielsen, 1993) tiene dos vertientes: una social y otra práctica.

FIGURA 7.1. Parámetros relacionados con la aceptación de un producto software.

La aceptación social depende de aspectos estrechamente relacionados con el tipo de sociedad en el que se va a utilizar el sistema, es decir, con las costumbres, hábitos y normas del lugar en el que se va a implantar el producto software. Los factores incluidos en la segunda vertiente, la práctica, están relacionados con parámetros como el coste de la aplicación, la compatibilidad, la fiabilidad o la utilidad. Éste ultimo aspecto es probablemente el más difícil de medir. Para que un sistema sea realmente útil tiene que ser funcionalmente correcto y, además, debe ser posible que el usuario lo emplee de manera eficiente para conseguir el fin para el cual se ha diseñado. En este sentido, se puede considerar que un usuario es capaz de usar con éxito un sistema, o lo que es lo mismo:

EVALUACIÓN DE SISTEMAS INTERACTIVOS

193

DEFINICIÓN: Un producto es USABLE, si (Rubin, 1994): • Ayuda al usuario a conseguir sus metas. • Es fácil de emplear: se cometen pocos errores y su uso es eficiente. • El producto es fácil de aprender y recordar. • La actitud del usuario ante el producto es positiva.

La principal dificultad a la hora de evaluar la utilidad de un producto software radica en tratar de cuantificar de algún modo su usabilidad1. En demasiadas ocasiones, los diseñadores tienden a calificar sus aplicaciones como «sencillas», «amigables», «intuitivas» o «fáciles de utilizar» simplemente por el hecho de haber empleado interfaces WIMP (Windows Icons Menus Pointers) o de manipulación directa y basándose en su experiencia o la de sus colegas al utilizar la aplicación (Preece y otros., 2002). Sin embargo, para poder afirmar con una cierta rigurosidad que un producto software es usable, es preciso estudiar de forma objetiva si realmente satisface las necesidades de sus usuarios, aplicando lo que se conoce en la literatura como un proceso de ingeniería de la usabilidad (Mayhew, 1999). A lo largo de este capítulo se intentará dar una visión de cómo llevar a cabo la evaluación para conseguir datos fiables y útiles sobre la usabilidad de los sistemas multimedia.

7.1.1.

Qué es la evaluación

El hecho de aplicar guías o recomendaciones de diseño sobre la interfaz de usuario no asegura que la aplicación resultante sea utilizable, puesto que siempre habrá que tener en cuenta las reacciones del usuario ante el sistema final. Puesto que la aplicación interactiva se desarrolla con objeto de facilitar unas tareas realizadas por un determinado tipo de usuarios, sólo ellos pueden proporcionar información fiable sobre la usabilidad del producto resultante. De hecho, sólo se podrá afirmar que los usuarios son capaces de utilizar con éxito un sistema si se ha realizado una evaluación que corrobore este hecho, ya que, según palabras de Benyon (1990), la evaluación va a permitir valorar y mejorar la interfaz para adaptarla a las características y necesidades de los usuarios. DEFINICIÓN: La EVALUACIÓN permite: • establecer si un sistema cumple las necesidades del usuario y si éste está satisfecho con el sistema

Antes de pasar a estudiar más en detalle la evaluación, se intentará responder a algunas preguntas típicas que aclaran el sentido de este proceso de ingeniería de la usabilidad, como son qué evaluar, para qué, cuándo y cómo.

194


7.1.2. ¿Qué hay que evaluar? En una aplicación interactiva hay infinidad de aspectos y elementos susceptibles de ser evaluados, tales como la apariencia de los contenidos, la utilidad de los menús o formularios, e incluso la forma en que los usuarios utilizan los productos en su entorno puede ofrecer valiosa información para diseñar la aplicación (Preece y otros., 2002). Un sistema multimedia es una aplicación software intrínsecamente interactiva, pues el usuario está constantemente dialogando con el sistema para obtener información. Desde el punto de vista de la usabilidad, estos sistemas pueden analizarse desde diversas perspectivas. En concreto, se pueden considerar los siguientes aspectos de la aplicación: • Estructura. Desde esta perspectiva se evalúan las relaciones existentes entre los distintos contenidos. La aplicación multimedia está formada por una serie de nodos o unidades indivisibles de presentación en las que se incluyen varios contenidos. Así, cada ventana o cada marco puede considerarse un nodo. A su vez, los nodos pueden estar agrupados de acuerdo con ciertos criterios. Por ejemplo, al pasar este libro a formato multimedia éste se organizaría en capítulos que, a su vez, se estructurarían en secciones que, finalmente, se compondrían de una serie de páginas cada una de las cuales contendrá uno o más elementos de contenido. Estas relaciones puramente estructurales, así como cualquier otra de carácter semántico que se establezcan entre contenidos, deben ser analizadas para comprobar si reflejan el conocimiento del dominio que tiene el usuario. • Navegación. En la navegación se analizan las diversas formas en las que el usuario puede moverse por la información. Por ejemplo, es muy habitual que en los sistemas multimedia se incluyan enlaces como en el hipertexto u otras opciones de acceso a los contenidos tales como mapas o índices, cuya utilidad también hay que analizar. • Contenidos. Esta perspectiva hace referencia a cada uno de los elementos de información que se utilizan en un producto multimedia. Por ejemplo, una definición de un término, una imagen o un vídeo que lo ilustran serían tres contenidos distintos. Los contenidos de un sistema multimedia pueden ser o no los adecuados, una adecuación que en muchas ocasiones depende más del objetivo del sistema y de las características de sus usuarios que de la calidad de cada contenido individual. • Presentación. Desde esta perspectiva se estudia la apariencia con que se muestran los contenidos y las opciones disponibles al usuario. Así, se 1 Si bien el término usabilidad no aparece en el Diccionario de la Real Academia Española, se empleará en este capítulo por considerarse aceptado en el ámbito de los sistemas interactivos.


195

analizaría lo que comúnmente se llama interfaz de usuario, teniendo en cuenta si la manera en la que los elementos de información y las distintas funciones que el usuario pueden realizar se presentan de la forma más apropiada y utilizable. • Interacción. La interacción hace referencia a la manera en que los usuarios dialogan con el sistema para realizar una tarea (por ejemplo, rellenando un cuestionario o resolviendo un ejercicio interactivo). Dentro de esta categoría se incluyen los comandos ofrecidos para controlar la presentación multimedia, la utilización de menús, formularios y cualquier otro tipo de mecanismo de interacción cuya usabilidad debe ser contrastada. Así pues, la usabilidad del sistema podría analizarse de acuerdo a estos cinco grandes bloques. Como ejemplo, la tabla 7.1 recopila algunas cuestiones sobre usabilidad que podrían plantearse, como primera aproximación, para cada uno de estos aspectos con objeto de ayudar a entender el significado y la extensión del término usabilidad. Se ofrecerá una descripción más elaborada sobre posibles criterios a evaluar en una aplicación multimedia en el apartado 7.5. TABLA 7.1. Algunas cuestiones relacionadas con la usabilidad de sistemas multimedia Estructura

¿Está el sistema bien estructurado? ¿Es comprensible la estructura del sistema? ¿La información está bien estructurada, de manera que cada nodo se identifica con un único concepto u objetivo?

Navegación

¿Se pueden utilizar las opciones de navegación disponibles para conseguir los objetivos del usuario? ¿Se puede localizar rápidamente un concepto? ¿Se le facilitan mecanismos de orientación? ¿Puede el usuario regresar a cualquier punto por el que ha pasado? ¿Está de acuerdo el usuario con los enlaces existentes?

Contenidos

¿Son los contenidos adecuados y atrayentes? ¿Se pueden utilizar los contenidos para conseguir los objetivos? ¿Hay contenidos que proporcionen pistas sobre la utilidad del producto? Presentación ¿Se presentan los contenidos de forma armónica y se usan para potenciar la comprensión del tema tratado? ¿Se utilizan características de presentación para resaltar la información clave? ¿Se satura al usuario con la información presentada? ¿Son evidentes las opciones disponibles? ¿Se hace explícita la estructura del sistema mediante pistas?

Interacción

¿Se pueden utilizar las opciones de interacción disponibles para conseguir los objetivos del usuario? ¿Se restringe a los usuarios la utilización de la información? ¿Puede el usuario controlar el comportamiento de los elementos que participan en el sistema?

196


7.1.3.

¿Por qué hay qué evaluar?

La respuesta más evidente e inmediata es que la evaluación tiene como misión obtener datos objetivos y fiables sobre la usabilidad de un sistema y conseguir que el producto se adapte a las necesidades y requerimientos de sus usuarios. Ésta debería ser una razón suficientemente importante para justificar la evaluación de productos multimedia. Sin embargo, en los desarrollos comerciales se tiende a evitar la evaluación porque se considera un proceso costoso, tanto en tiempo como en recursos, no siempre disponibles, problema especialmente acusado en el caso de las aplicaciones Web en las que se suele trabajar con unos plazos acuciantes (Lowe y Hall, 1999). En este sentido, se puede considerar que la evaluación es una inversión de esfuerzos que hace posible (Preece y otros., 2002): • Detectar y solventar problemas de usabilidad antes de que el producto salga a la calle. De esta forma, se conseguirá crear una actitud más positiva en los usuarios que suelen ver en los productos multimedia una sobrecarga de aprendizaje que puede evitar la utilización del mismo. • Concentrar los esfuerzos en solucionar problemas reales y no imaginarios. En muchas ocasiones los integrantes del equipo de desarrollo se enfrascan en discusiones interminables sobre la utilidad de alguna función, debates que se zanjarían llevando a cabo una evaluación. • Llevar a cabo un proceso de ingeniería de usabilidad en vez de debates. Del mismo modo que el resto de los requisitos de una aplicación son analizados, diseñados y verificados siguiendo un proceso más o menos formal, los requisitos de usabilidad deben ser tenidos en cuenta a lo largo del proceso de desarrollo de una forma rigurosa y no basándose en buenas prácticas o «reglas de oro». • Reducir el tiempo que tarda en salir al mercado el producto. En la medida en que la evaluación ayuda a detectar y solventar problemas desde el inicio del desarrollo, el producto puede estar listo en menos tiempo y cumpliendo requisitos básicos de usabilidad. • Facilitar el trabajo del departamento de ventas. Esto es debido a que dicho equipo que no se las tiene que ingeniar para vender un producto deficiente, puesto que cuenta con un trabajo sólido que puede considerarse como una versión 1.1 ó 2.0.

7.1.4.

¿Cuándo hay que evaluar?

La evaluación es un procedimiento formal imbricado en el ciclo de desarrollo de un sistema interactivo con el fin de mejorar la usabilidad del pro-


197

ducto final. La evaluación se puede realizar durante distintas fases dentro del ciclo de vida, utilizando en cada una de ellas la técnica más apropiada. Como puede verse en la figura 7.2, la evaluación se puede considerar como una tarea central que proporciona información para validar las decisiones tomadas en cada una de las restantes fases.

FIGURA 7.2. El papel de la evaluación en el ciclo de desarrollo de aplicaciones software, basado en el ciclo de vida en estrella descrito en (Preece y otros., 1994).

Durante el análisis, se podrán emplear técnicas para la extracción de requisitos de usabilidad que darán lugar a diseños conceptuales que hay que contrastar antes de llevar a la práctica, ya sea en forma de maquetas o de implementaciones más completas. Además, y de acuerdo con los resultados de la evaluación, se debería modificar el sistema que está en desarrollo. Este proceso de modificación del diseño del sistema se debe repetir frecuentemente, teniendo en cuenta los resultados de la evaluación, de manera que se dé lugar a un diseño iterativo (Preece y otros., 2002). De forma muy general, se distingue entre dos tipos de evaluaciones: DEFINICIÓN: Tipos de evaluaciones. • EVALUACIONES FORMATIVAS: que sirven para comprobar que las necesidades de los usuarios se están teniendo en cuenta durante el proceso de diseño y desarrollo del producto. • EVALUACIONES FINALES: que son aquellas que se hacen para asegurar el éxito o la posible aceptación de un producto ya acabado.

198


7.1.5.

¿Cómo hay que evaluar?

La forma de evaluar depende básicamente de qué y cuándo se va evaluar. Además, cualquier tipo de evaluación, se siga la técnica que se siga, se guía por un conjunto de creencias, explícitas o implícitas, que pueden ser también secundadas por la teoría y que se conocen como paradigmas de evaluación (Preece y otros., 2002). DEFINICIÓN: Paradigma de evaluación. • Conjunto de asunciones sobre el objetivo de la evaluación y la forma en que ésta debe llevarse a cabo.

Algunos paradigmas de evaluación son: • Evaluaciones rápidas (Quick and dirty): se trata de conseguir de forma muy rápida algún tipo de información sobre si las ideas de los diseñadores están de acuerdo con las necesidades de los usuarios. Los estudios no son muy detallados o profundos y pueden hacerse en todas las fases del desarrollo. • Análisis de usabilidad: se estudia qué harán los potenciales usuarios al tratar de llevar a cabo tareas típicas con el producto, midiendo el tiempo requerido para completar las tareas y el número de errores cometidos. Son experimentos que suelen realizarse en laboratorios de usabilidad y en los que el evaluador juega un papel fundamental. • Estudios de campo: que se realizan en condiciones reales, con el objetivo de incrementar la comprensión que se tiene sobre lo que los usuarios hacen habitualmente y cómo les afecta la tecnología. • Evaluaciones predictivas: en las que una serie de expertos aplican su conocimiento sobre usuarios típicos de la aplicación, a menudo guiados por heurísticas, para predecir problemas de usabilidad Para cada paradigma se podrán utilizar una o varias técnicas. DEFINICIÓN: Técnica de evaluación. • Proceso que puede aplicarse para realizar algún tipo de evaluación o una parte de la misma.

Ejemplos de técnicas son: observar a los usuarios mientras emplean el producto, preguntarles su opinión, preguntar a expertos, analizar el rendimiento de los usuarios o modelar ese rendimiento para predecir la eficiencia. En la siguiente sección se profundiza en la forma de llevar a cabo la evaluación, presentado distintos métodos aplicables.


7.2.

199

MÉTODOS DE EVALUACIÓN

Es posible identificar diferentes métodos para realizar la evaluación de un sistema en los que, de algún modo, subyace un paradigma de evaluación que pueden llevarse a cabo utilizando algún tipo de técnica de las anteriormente mencionadas. DEFINICIÓN: Método de evaluación. • Descripción más o menos detallada de una forma de llevar a cabo la evaluación.

Así por ejemplo, reinterprendo la clasificación propuesta por Benyon en (Benyon y otros., 1990) se pueden considerar cuatro métodos de evaluación: • Evaluación analítica. • Evaluación experta. • Evaluación empírica. • Evaluación experimental.

7.2.1.

La evaluación analítica

Este tipo de evaluación hace uso de una descripción formal o semiformal del sistema (por ejemplo, un guión o storyboard) con el fin de predecir el comportamiento del usuario, tanto en términos físicos como de las operaciones cognitivas que se deberían realizar. Entra pues dentro del grupo de evaluaciones predictivas, ya que al no ser necesario que exista el sistema sino tan sólo una especificación del mismo, cualquier dato sobre la usabilidad se basa en conjeturas sobre la forma en que el usuario interactuará. Además, en muchas ocasiones, se asume también el paradigma de la evaluación rápida. Los datos obtenidos en una evaluación analítica serán muy genéricos y no directamente extrapolables a conclusiones sobre utilidad real, en tanto en cuanto lo que se evalúa es una especificación y no un producto en sí. Permitirán comprobar si se está yendo en una dirección adecuada, si bien no hacen posible validar la usabilidad del sistema. Las evaluaciones analíticas suelen utilizarse en las fases de análisis o diseño, ya que requiere pocos recursos, no necesita prototipos costosos ni pruebas de usuario. Además, pueden emplearse para analizar la factibilidad y la aceptación social de un producto. Un ejemplo de método de evaluación analítica es la evaluación heurística propuesta por Jakob Nielsen en (Nielsen, 1994), en el que los autores proponen una serie de heurísticas para ayudar a los evaluadores a criticar el sistema que se recogen en la tabla 7.2.

200


TABLA 7.2. Ejemplos de utilización de heurísticas para la evaluación analítica (ampliados de Preece y otros, 2002) Heurística Visibilidad del estado del sistema.

Equivalencia entre el mundo real y el sistema.

Ejemplos de cuestiones ¿Se informa a los usuarios de lo que está ocurriendo en cada momento? ¿Se responde en un plazo razonable? ¿Es el lenguaje utilizado en la interfz simple? ¿Es ese lenguaje familiar para el usuario? ¿Está relacionado con la tarea a realizar?

Control del usuario y libertad.

¿Qué grado de libertad tiene el usuario? ¿Puede elegir la forma de moverse por el producto? ¿Puede tomar la iniciativa en otros tipos de acciones?

Consistencia y estándares.

¿La presentación de la información se hace siguiendo unas normas de estilo? ¿Producen funciones similares resultados similares? ¿Se ajusta el producto a algún estándar o norma?

Ayuda al usuario a reconocer, diagnosticar y solventar errores.

¿Son los mensajes de error útiles? ¿Utilizan un lenguaje sencillo para describir el problema? ¿Proporcionan guías sobre la forma de solucionar el problema?

Prevención de errores.

¿Es fácil cometer errores? ¿Dónde y cómo?

Reconocimiento frente a recuerdo.

¿Están siempre visibles los objetos, acciones y opciones disponibles?

Flexibilidad y eficiencia.

¿Se adapta a las características del usuario o de la plataforma? ¿Existen atajos para usuarios expertos?

Diseño estético y minimalista.

¿Hay información innecesaria? ¿Hay funciones innecesarias?

Ayuda y documentación.

¿La ayuda es contextual? ¿Es fácil de utilizar? ¿Se puede buscar de forma eficiente?

7.2.2.

La evaluación experta

Este método de evaluación, que se enmarcaría dentro del paradigma de la evaluación predictiva, consiste en elegir una serie de personas altamente cualificadas en el diseño de interfaces de usuario o en el tipo de aplicación bajo examen e invitarlas a juzgar el sistema e identificar los problemas de interacción que encontrarán los usuarios. Es un método que no requiere grandes recursos y es eficaz, puesto que sin necesidad de involucrar usuarios reales se pueden detectar problemas signi-


201

ficativos. Sin embargo, los expertos tienen que elegirse con cautela de manera que se eviten prejuicios y evaluaciones demasiado sesgadas, ya que el objetivo es conseguir reproducir la conducta real del usuario. Por sus características, es un método idóneo para utilizarse en las fases de análisis, diseño y prototipado. Un ejemplo de técnica de evaluación experta es el Walktrough que se verá en detalle en el capítulo 9, «Ejemplos de desarrollo».

7.2.3.

La evaluación empírica

Este método abarcaría los paradigmas de estudios de usabilidad y estudios de campo, pues tiene como objetivo enfrentar a usuarios reales con la aplicación para detectar los problemas de usabilidad. Existen dos técnicas ampliamente utilizadas para este fin: la evaluación por observación y la evaluación por examen. En ambos casos se requiere que el sistema esté en una fase de desarrollo muy avanzada. En la evaluación por observación se obtienen datos sobre la conducta del usuario mientras éste está empleando el sistema. Para ello pueden aplicarse las siguientes técnicas: • observación directa: un evaluador toma notas sobre las acciones del usuario; • grabación en vídeo: la actividad del usuario se graba y se visualiza con o sin su participación; • uso de software de registro: la interacción del usuario con el sistema se graba automáticamente en ficheros (log) que, posteriormente pueden estudiarse para reconstruir de algún modo las acciones del usuario; • protocolos verbales: se invita al usuario a expresar en voz alta sus observaciones y pensamientos mientras usa el sistema. Todas estas técnicas, con la excepción del software de registro, se dice que son métodos intrusos puesto que afectan a la actividad del usuario en la medida en que éste se siente observado. Sin embargo, el software de registro puede incumplir el derecho a la privacidad, puesto que habitualmente se graba sin consentimiento ni conocimiento del usuario las acciones que éste realiza. En cualquier caso, la evaluación por observación es un método costoso puesto que habrá que analizar muchos datos pero, como contrapartida, suele suministrar datos cualitativos muy interesantes y fiables sobre la forma en que se utiliza el sistema, dónde se encuentran las principales dificultades, medidas de ejecución o la frecuencia de errores de usuario.

202


La evaluación por examen hace uso de entrevistas o cuestionarios con el propósito de recoger opiniones subjetivas de los usuarios. Las entrevistas consumen muchos recursos y requieren un entrevistador capaz de extraer información del usuario, pero se pueden obtener resultados interesantes. Las entrevistas pueden ser: • flexibles, si se define un conjunto de temas generales sobre los que hablar pero no hay una secuencia precisa de preguntas; • estructuradas, si existe un conjunto de cuestiones predefinidas, o • semi-estructuradas si de adopta un enfoque mixto como el que se refleja en la figura 7.3.

FIGURA 7.3. Ejemplo de entrevista semi-estructurada.

Los cuestionarios son menos costosos pero hay que diseñarlos cuidadosamente de manera que los evaluadores entiendan cada pregunta y las posibles respuestas. Suelen incluirse dos clases de preguntas: cerradas, cuando el evaluador tiene que elegir dentro de un conjunto de alternativas; y abiertas, en las que se permite dar cualquier respuesta. Las cuestiones abiertas pueden ser más difíciles de analizar, pero proporcionan una fuente de información mayor ya que dan la opción de expresar opiniones, posibles mejoras, etc. Las cuestiones cerradas pueden diseñarse de distintas formas, algunas de las cuales se muestran en la figura 7.4.


203

FIGURA 7.4. Ejemplos de diseño de cuestionarios.

7.2.4.

La evaluación experimental

Por último, en una evaluación experimental, el evaluador puede manipular diferentes factores asociados con el diseño de la interfaz y estudiar sus efectos en varios aspectos del rendimiento del usuario. Esto requiere un buen conocimiento de métodos experimentales y un gran consumo de tiempo y recursos. Normalmente este método se aplica cuando se ha desarrollado por completo el prototipo. Una técnica utilizada en esta fase es el Estudio en el terreno, que consiste en una revisión del producto cuando ya ha sido implantado en el lugar donde va a ser empleado (Rubin, 1994). Esta técnica se complementa en una etapa posterior con la realización de un Estudio de seguimiento, que consiste en recoger datos de empleo de una versión para mejorar la siguiente, usando exámenes, entrevistas y observaciones (Rubin, 1994).

7.3.

EL PROCESO DE EVALUACIÓN

Los métodos y técnicas que se pueden usar durante los diversos estados por los que pasa el desarrollo de un sistema multimedia son muy variados y es muy importante la selección que se haga de los mismos. No obstante, e independientemente del método o técnica que se aplique, la evaluación debe prepararse bien si se quieren obtener resultados útiles. Por ello, y aunque pueda parecer una labor muy sencilla, es importante seguir un proceso bien

204


definido que permita examinar y ahondar en las bondades y las deficiencias del sistema. La figura 7.5 resume un proceso de evaluación que se comenta en las siguientes subsecciones.

FIGURA 7.5. El proceso de evaluación (según Díaz y otros, 1996).

7.3.1.

Definición del objetivo de la evaluación

En primer lugar hay que establecer de manera clara y precisa los objetivos perseguidos en la evaluación que no tienen por qué coincidir con los objetivos del sistema. A este respecto, resulta esencial formular objetivos muy concretos y mensurables. Así, el primer objetivo que parece surgir es el de medir la usabilidad de una aplicación. Sin embargo, proponerse medir la usabilidad, sin más descripción de qué se entiende por usabilidad, no se puede considerar como un objetivo alcanzable. Por ello, habrá qué analizar que significa que un producto software sea usable, teniendo en cuenta los usuarios que lo van a utilizar, las tareas para las que se va a emplear y el entorno en que se va a implantar. Entre los objetivos a considerar también se encuentran: • comparar el producto con otro u otros similares; • analizar si mejora algún proceso que se hacía a través de un mecanismo no automatizado, o • verificar si se ajusta a algún tipo de estándar, recomendación o norma.


205

TABLA 7.3. Ejemplo de objetivos de la evaluación para un curso virtual Evaluación de un curso virtual

Comprobar si el curso ayuda a los estudiantes a aprender. Comprobar si el curso puede ser seguido por todo tipo de estudiantes. Comprobar si el curso provoca una actitud positiva en los estudiantes. Comprobar si el curso motiva al estudiante a seguir aprendiendo sobre el tema. Comprobar si el curso es considerado más útil que otro curso similar. Comprobar si el curso es preferido frente a otro de formato presencial, etcétera.

En cualquier caso, es preferible huir de objetivos grandiosos difícilmente verificables como, por ejemplo, comprobar si un curso virtual mejora de forma genérica el proceso de aprendizaje.

7.3.2.

Selección de la técnica de evaluación

Como se ha comentado anteriormente, existen diversos paradigmas, métodos y técnicas de evaluación. La selección de uno u otro depende de múltiples criterios, entre los que se encuentran la fase de desarrollo en que se encuentra el sistema, los recursos disponibles (fundamentalmente, tiempo y recursos humanos que pueden dedicarse a esta tarea), la experiencia previa del equipo de desarrollo, la disponibilidad de evaluadores, etc.

7.3.3.

Preparación de la evaluación

La evaluación hay que prepararla cuidadosamente para no perder la oportunidad de recoger datos interesantes y relevantes. Para ello es preciso: • seleccionar a los evaluadores, • elegir los datos que se van a recoger • definir las tareas a realizar, y • preparar los mecanismos de registro. Selección de los evaluadores. Es preciso decidir quién va a proporcionar información durante el proceso de evaluación, para lo cual habrá que tener en cuenta los objetivos de la evaluación, la técnica elegida y los recursos disponibles. Si se ha optado por una evaluación empírica o experimental será preciso contar con usuarios reales o potenciales, mientras que con técnicas analíticas o expertas bastará contar con expertos. Si se invita a evaluadores expertos, éstos deben proceder de diversos campos, conocer las tareas para las que se utiliza el producto software y poder asumir el papel de los usuarios.

206


Si se incluyen usuarios potenciales, debería formarse un grupo que represente a los distintos tipos de usuarios finales. Además, hay que conseguir que las condiciones bajo las cuales se realiza la evaluación recreen un entorno de uso verídico, para no alterar la fiabilidad de los datos. En la tabla 7.4 se muestran algunos ejemplos de evaluadores para un curso virtual. La selección de unos u otros dependerían, entre otros aspectos, del objetivo del curso. En cualquiera de las situaciones, la participación siempre debe ser voluntaria y los evaluadores deben ser conscientes de que se está juzgando al sistema y no a ellos. TABLA 7.4. Ejemplos de evaluadores para un curso virtual Usuarios reales

• Usuarios con distintos niveles de dominio del producto (noveles, usuarios con experiencia, expertos, etc.). • Usuarios con distintos perfiles (estudiantes, docentes, administradores, etc.). • Usuarios con diferentes necesidades (estudiantes avanzados, estudiantes con discapacidades, etc.). • Etcétera.

Expertos

• • • • •

Diseñadores de interfaces interactivas. Diseñadores instructivos. Pedagogos, sociólogos, psicólogos, etc. Expertos en usabilidad. Etcétera.

Selección de los datos a recoger. Es necesario determinar qué dato, tantos cuantitativos como cualitativos, se recopilarán y elaborarán para extraer las conclusiones de acuerdo a los objetivos iniciales. Los datos cuantitativos serán medidas de calidad que proporcionen un valor de la capacidad del usuario para utilizar el sistema, por ejemplo, el tiempo invertido en llevar a cabo una tarea o el número de errores cometidos. En cambio, los cualitativos se recogerán con protocolos verbales y cuestionarios o entrevistas, incluyendo preguntas con respuestas abiertas que proporcionen información que pueda ser posteriormente analizada, por ejemplo, ¿Cómo se podría mejorar el producto para llevar a cabo la tarea X? Como ayuda se pueden emplear criterios como los presentados en la siguiente sección. Definición de las tareas a realizar. Si se quieren estudiar todos los mecanismos de interacción de la aplicación, es conveniente que la interacción del evaluador sea guiada, de manera que no sólo se asegure que se utilizan todas las opciones disponibles sino que también se puedan detectar errores. Además, hay que asegurarse de que las tareas permiten recopilar todos los datos que se quieren recoger.


207

De forma general se puede decir que hay dos tipos de tareas: • Tareas dependientes del dominio: son aquellas que ayudan al usuario a conseguir un objetivo y que no pueden generalizarse porque dependen de la aplicación concreta que se haya desarrollado. Por ejemplo, en un curso virtual tareas específicas serían realizar un determinado ejercicio o hacer un resumen de una lección. • Tareas genéricas: que son aquellas consideradas como propias de cualquier producto multimedia. La tabla 7.5 resume algunos ejemplos de tareas genéricas.

TABLA 7.5. Ejemplos de tareas para un curso virtual Navegación

• Exploración secuencial del producto. • Exploración asociativa del producto.

Búsqueda

• Localización de un nodo por importancia. • Localización de un nodo por contenido.

Personalización

• Inclusión de anotaciones. • Inclusión de elementos personales (contenidos, enlaces, etc.).

Edición

• Actualización de contenidos. • Actualización de la estructura.

Preparación de los mecanismos de registro. Finalmente es preciso preparar los artefactos a través de los cuales se va a recopilar información, ya sean cuestionarios, entrevistas, grabaciones o software de registro.

7.3.4.

Realización de la evaluación

Al realizar la evaluación hay que recrear un entorno real. Además, los evaluadores deben ser conscientes de qué se está evaluando y por qué. Las evaluaciones pueden hacerse de forma individual o en grupo. En el primer caso, es conveniente que alguien del equipo de desarrollo asista al usuario para resolver malentendidos y dudas. En el segundo caso, se suele aprovechar para fomentar discusiones y puestas en común de opiniones para obtener resultados más significativos. Si se prevé una evaluación larga, se dividirá en varias sesiones para no cansar a los evaluadores, ya que la fatiga puede dar lugar a una falta de interés que falsee los resultados de la evaluación. En algunas ocasiones llevar a cabo una sesión de prueba dentro del propio equipo de desarrollo para depurar el proceso de evaluación puede ser adecuado, sobre todo si no se cuenta con una gran disponibilidad por parte de los evaluadores reales.

208


7.3.5.

Elaboración de los resultados

Los resultados deben servir para extraer una serie de conclusiones en términos de deficiencias detectadas y mejoras propuestas que permitan revisar el producto para incrementar su utilidad. Para elaborar los datos cuantitativos suelen emplearse métodos estadísticos, como por ejemplo la presencia, moda, rango, valor mínimo, medio, máximo, desviación típica, frecuencia, etc. Los datos cualitativos requieren normalmente de mayor interpretación para extraer información de utilidad.

7.4.

PARÁMETROS PARA LA EVALUACIÓN DE SISTEMAS MULTIMEDIA

Para decidir qué evaluar en un sistema multimedia se puede hacer uso de una serie de criterios que proporcionen un marco de trabajo más riguroso que la experiencia o intuición de los desarrolladores. DEFINICIÓN: Criterio de evaluación. • Atributo o propiedad de un componente o de varios componentes de un producto que tiene relevancia de cara a medir la usabilidad final del producto.

En la tabla 7.6 se resumen algunos criterios que podrían tenerse en cuenta al establecer los datos a recopilar (sección 7.4) y que están basados en los trabajos presentados en (Garzotto y otros., 1995; Ficarra, 1997; Aedo y Díaz, 2001).

7.5.

RESUMEN

En conclusión, la evaluación se debe realizar durante todo el ciclo de desarrollo, de manera que el producto final haya pasado por el mayor número de filtros posibles, acercándolo y adaptándolo a las necesidades de la empresa y del usuario. La evaluación puede realizarse siguiendo distintos métodos (evaluación analítica, experta, empírica y experimental) cada uno de los cuales responde a uno o más paradigmas de evaluación (evaluaciones rápidas, estudios de usabilidad, estudios de campo y evaluaciones predictivas). En general, la selección de un enfoque u otro depende de diversos factores, entre los que se encuentran los recursos disponibles, el objetivo de la evaluación, el estado del producto a evaluar y factores externos (disponibilidad de evaluadores, restricciones temporales, etc.).


209

En cualquier caso, es importante evaluar y hacerlo de forma rigurosa, es decir, aplicando un proceso bien definido y una serie de parámetros o criterios que hagan posible recopilar información relevante sobre la potencial usabilidad de un producto multimedia. TABLA 7.6. Criterios para la evaluación de productos multimedia Riqueza

Mide la cantidad de elementos de información incluidos, la expresividad de cada uno de ellos y la variedad de formas de acceso e interacción.

Capacidad de predicción

Expresa la medida en que los usuarios se anticipan al resultado de una operación.

Naturaleza de la metáfora

Representa la calidad del proceso de comunicación entre el usuario y el ordenador. Se pretende acercar, en la medida de lo posible, el modelo mental del usuario al modelo utilizado para desarrollar el sistema.

Autonomía Consistencia

Refleja el grado de libertad concedido al usuario. Mide la coherencia de la aplicación. Se comprueba si elementos conceptualmente similares se tratan de la misma forma.

Estética

Mide cómo la incorporación de información multimedia aumenta la comprensión de los conceptos

Transparencia del significado

Se utiliza para medir cómo los términos utilizados en los contenidos no causan ambigüedades. La terminología utilizada, tanto para los contenidos como para el control del sistema, tienen un único sentido, de manera que el usuario entiende de forma inequívoca cada uno de los significados particulares.

Competencia

Representa la capacidad del usuario para utilizar el sistema.

Autoevidencia

Expresa la medida en que los usuarios adivinan el propósito de cualquier elemento que se está presentando.

Soporte a la autoría

Permite recoger la medida en que el usuario puede modificar el sistema hipermedia.

Soporte a la colaboración

Refleja la capacidad del usuario de colaborar y comunicarse con otros usuarios.

Soporte a la personalización

Mide la capacidad del usuario de personalizar el producto.

210

7.6.



7.1. Al evaluar un producto multimedia: a) Sólo se debe analizar la calidad de los contenidos. b) Hay que tener en cuenta los mecanismos de acceso a la información. c) Sólo se pueden recolectar datos subjetivos que recojan las opiniones de los usuarios. d) No se puede recurrir a técnicas de evaluación analítica, puesto que éstas se basan en conjeturas no siempre trasladables al mundo real.

7.2. La evaluación: a) Retarda el tiempo de entrega pero permite obtener un producto de mayor calidad. b) Evita elucubrar sobre la bondad de un diseño, convirtiendo el diseño de la usabilidad en un proceso de ingeniería. c) Es una alternativa frente al diseño iterativo. d) Sólo puede realizarse si existe un prototipo del sistema.

7.3. La usabilidad: a) Mide la utilidad de un producto. b) No puede considerarse como un criterio de calidad del software. c) Depende de la compatibilidad, de la flexibilidad y del coste del producto final. d) Recoge, entre otros aspectos, la eficiencia que se logra al usar un determinado producto software.

7.4. Con respecto a los paradigmas de evaluación: a) Implican el uso de una única técnica muy concreta. b) Las evaluaciones rápidas, los análisis de usabilidad o los estudios de campo son algunos de los paradigmas más habituales. c) Determinan el ciclo de vida del producto software. d) Si se hace una evaluación predictiva puede emplearse una técnica de evaluación empírica.

7.5. Con respecto a la evaluación analítica: a) Hace uso de prototipos analizados por expertos y usuarios para llevar a cabo una evaluación formativa. b) Se podría enmarcar dentro del paradigma de estudios de campo.


211

c) La evaluación por examen es una técnica analítica que hace uso de entrevistas y cuestionarios para recoger opiniones de los evaluadores. d) La evaluación heurística es una técnica analítica que ofrece algunas guías para detectar problemas de usabilidad.

7.7.


AEDO y DÍAZ (2001): I. Aedo y P. Díaz. Evaluation criteria for hypermedia educational systems. In Computers and Education: Towards an Interconnected Society. Eds. Ortega, M. and Bravo, J. Kluwer Academic Pub., Holanda, 45-60. BENYON y otros (1990): D. Benyon, G. Davies, Laurie Keller e Yvonne Rogers. A Guide to Usability- Usability Now!». Milton Keynes: The Open University. Gran Bretaña. DÍAZ y otros (1996): P. Díaz, N. Catenazzi e I. Aedo. De la multimedia a la hipermedia. Ed. Rama. FICARRA (1997): F.V.C Ficarra, Evaluation of multimedia components. Proceedings of the International Conference on Multimedia Computing and Systems, Ottawa, 557-564 GARZOTTO y otros (1995): F. Garzotto, L. Mainetti y P. Paolini. Hypermedia Design, Analysis and Evaluation Issues. Comm. of the ACM, 38(8), 74-86. LOWE y Hall (1999): D. Lowe y W. Hall: Hypermedia and the web: an engineering approach. John Wiley & Sons. MAYHEW (1999): D.J. Mayhew. The usability engineeering lifecycle : a practitioner’s handbook for user interface design. Morgan Kaufmann. NIELSEN (1993): J. Nielsen: Usability engineering. AP Professional. NIELSEN (1994): J. Nielsen. Usability Inspection Methods. John Wiley & Sons, Nueva York. PREECE y otros (1994): J. Preece, Y. Rogers, H. Sharp, D. Benyon, Simon Holland and Tom Carey: Human Computer Interaction. Addison Wesley. PREECE y otros (2002): J. Preece, Y. Rogers y H. Sharp: Interaction Design: beyond human computer interaction. John Wiley &Sons. RUBIN (1994): J. Rubin: Handbook of usability testing, how to plan, design and conduct effective tests. John Wiley & Sons.

Capítulo 9 EJEMPLOS DE DESARROLLO

ESQUEMA 9.1. 9.2. 9.3. 9.4. 9.5.

Now-Graduado: ejemplo de análisis y diseño. Ejemplo de evaluación de la usabilidad. Resumen. Ejercicios de autoevaluación. Referencias bibliográficas.

En los capítulos precedentes se han abordado las fases de que consta el proceso de desarrollo de sistemas multimedia (Capítulo 4), así como los procesos de análisis, diseño y evaluación (Capítulos 5, 6 y 7). Con objeto de ilustrar los conceptos previamente estudiados, este capítulo se va a centrar en mostrar ejemplos concretos de análisis, diseño y evaluación. Este capítulo muestra, en primer, lugar, la experiencia del desarrollo de Now-Graduado, un CD multimedia educativo implementado con MacroMedia Director, haciendo hincapié en las fases de análisis, diseño e implementación. Este ejemplo se ha considerado adecuado porque tanto por las características del producto (tales como la inclusión de muy diverso material multimedia y de diferentes actividades interactivas) como por las del propio proceso de desarrollo (en el marco de un proyecto concreto y con un equipo multidisciplinar), permite mostrar las ventajas de seguir un enfoque sistemático en el que, independientemente de las restricciones de recursos, se haga algún tipo de análisis y de diseño conceptual antes de pasar a la implementación. A continuación, se presentará como ejemplo de evaluación el caso de CESAR, un sistema hipermedia educativo, cuya evaluación permitió extraer útiles conclusiones no sólo para mejorar el propio producto sino también para el proceso de evaluación.

9.1.

NOW-GRADUADO: EJEMPLO DE ANÁLISIS Y DISEÑO

Now-Graduado es una aplicación hipermedia, es decir una combinación de multimedia e hipertexto, que se desarrolló en el año 1997 con el fin de ayudar a adultos a adquirir los conocimientos fundamentales del Graduado Escolar (Aedo y otros, 1997). El Graduado Escolar es una cualificación básica y esencial para optar a gran número de trabajos y, de hecho, hay exámenes que permiten que aquellos adultos que en su momento abandonaron los estudios puedan ahora obtener este título. Puesto que la mayor parte de los adultos tienen dificultades para seguir cursos presenciales, ya sea por cargas laborales o familiares, y, además no suelen tener un hábito de estudio, se

262


consideró que un sistema interactivo que cubriera los temas más difíciles resultaría de gran utilidad. Además, se optó por una organización hipermedia fundamentalmente por cuatro razones: • La estructura asociativa del hipertexto constituye un buen modelo para representar el conocimiento, como se ha puesto de manifiesto en múltiples experiencias. • Los sistemas hipermedia son intrínsecamente interactivos (Rada y otros, 1995) y la interactividad es básica en cualquier proceso educativo. • La incorporación de contenidos multimedia no sólo resulta de gran utilidad para mejorar la comprensión de ciertos conceptos y procesos sino que, además, hace el producto más grato y ameno favoreciendo así una actitud positiva por parte del usuario final. • La hipermedia ofrece la posibilidad de gestionar grandes volúmenes de información de una manera consistente y, al mismo tiempo, manteniendo relaciones entre distintos conceptos. En las siguientes secciones se describen los procesos de análisis, diseño y construcción que se llevaron a cabo durante la elaboración de este producto, con objeto de ilustrar los conceptos presentados en los capítulos precedentes.

9.1.1.

Requisitos del desarrollo

Dentro de los requisitos que se detectaron, algunos afectaban al proceso de desarrollo en sí y otros al propio producto a desarrollar. Los primeros se engloban dentro la categoría de requisitos no funcionales, mientras que los segundos hacen referencia a múltiples características del sistema, ya sean concernientes a los usuarios, a la información a ofrecer, a las funcionalidades a soportar o a las características del entorno. En los siguientes epígrafes se describen algunos de los requisitos más relevantes organizados en las categorías introducidas en el capítulo 5 («Análisis y diseño de sistemas multimedia»): requisitos no funcionales, funcionales, de usuario, de datos, del entorno y de usabilidad.

9.1.2.

Requisitos no funcionales

El desarrollo de esta aplicación tenía que ser llevado a cabo formando un equipo multidisciplinar, en el que participasen tanto personal técnico, incluyendo programadores, analistas o diseñadores gráficos, como representantes de los usuarios. Así pues, desde el principio se evidenció la necesidad de llevar a cabo un proceso iterativo. Además, al tratarse de un proyecto concreto se contaba con unos plazos de entrega firmes, por lo que la participación de los representantes de los usuarios tampoco podía retrasar el proceso de desarrollo.

EJEMPLOS DE DESARROLLO

263

Otro aspecto destacable dentro de esta categoría de requerimientos es que se partía de un curso en formato tradicional, cuya estructura y contenidos se querían respetar.

9.1.3.

Requisitos funcionales

Dentro de esta categoría se incluyen todas las características relacionadas con la forma en que deberá funcionar el sistema, independientemente de las restricciones técnicas o de cualquier otro tipo. En este sentido, la primera característica que debía tener el producto era posibilitar el estudio de los diferentes temas tratados en el curso, ya fueran aspectos teóricos o prácticos. Además, también se quería que las alumnas pudieran revisar los temas ya estudiados. El temario se estructuraba en tres módulos temáticos: matemáticas, socionaturales y lengua, de forma que las alumnas podrían elegir qué querían estudiar. Además, estas materias no eran completamente independientes, puesto que entre ellas existirían enlaces que facilitarían el estudio de un mismo concepto desde distintas perspectivas, con el fin de enriquecer el aprendizaje de las alumnas. Otro aspecto fundamental era la necesidad de incluir ejercicios interactivos de diverso tipo así como de actividades complementarias, no necesariamente realizadas con el ordenador, como podría ser visitar un museo. Con ello se pretendía reforzar el proceso de aprendizaje y prolongarlo más allá de los límites de la sesión de trabajo con el producto multimedia. Además se quería que se pudieran incluir recursos didácticos, tales como un glosario o un diccionario, que fuera accesible tanto de forma independiente como a través de los contenidos del curso.

9.1.4.

Requisitos del usuario

Los usuarios del producto eran mujeres adultas, puesto que el proyecto se enmarcaba dentro del programa NOW («New Opportunities for Women») financiado por la Comunidad Europea. Este requisito era muy relevante puesto que dada la temática del producto, los contenidos propios del Graduado Escolar, podía caerse en la utilización de una interfaz infantil, que desmotivaría a sus usuarios que podrían sentirse infravalorados. Además, el hecho de que el producto estuviera orientado a mujeres en exclusiva influyó en algunas de las decisiones relacionadas con las características de la presentación, como por ejemplo la estética o el lenguaje empleado.

264


9.1.5.

Requisitos de datos

Con respecto a los datos se determinó que estos serían de naturaleza diversa, siendo preciso incluir textos, imágenes, dibujos, animaciones, locuciones y vídeos. Si bien se requería la mayor calidad posible, el producto debía distribuirse como un único CD, por lo que la cantidad de material multimedia a incluir debía restringirse. Además, el curso debía poder utilizarse en sistemas operativos Windows y sin necesidad de tener que instalar ningún software adicional, por lo que los formatos multimedia debían ser aquellos que pudieran presentarse en dicha plataforma (por ejemplo, vídeos en formato AVI).

9.1.6.

Requisitos del entorno

Dentro de este apartado se impusieron restricciones tales como considerar que el curso se utilizaría tanto en casa como en un centro con el apoyo de tutores. Además, se estableció que habría un curso de iniciación en los centros para ayudar a los usuarios a aprender a utilizar el curso.

9.1.7.

Requisitos de usabilidad

Este tipo de requisitos se consideró de gran importancia, como puede apreciarse en (Aedo y otros, 1997), puesto que con ellos se pretende mejorar la utilidad funcional y práctica del producto final. Los requisitos de usabilidad de Now-Graduado pueden resumirse en tres metas básicas: • Debe ser útil. Se pretende que el sistema ayude a sus usuarios a aprender aquellos conceptos que éstos requieren y que se consiga, al mismo tiempo, que la desorientación del usuario sea mínima. Este último es un aspecto muy importante, puesto que uno de los problemas fundamentales del hipertexto es que la libertad de navegación puede no favorecer el aprendizaje en algunos casos, especialmente en aquellos en los que por las características de los estudiantes o del tema o por condicionantes externos se requiera un acceso más guiado. • Debe ser fácil de usar y aprender. Los usuarios deben comprender el objetivo del producto y cómo pueden emplearlo para alcanzar sus metas. Además, se debe reducir la sobrecarga cognitiva que supone aprender a utilizar el Now-Graduado, pues el tiempo que los usuarios inviertan debe estar básicamente orientado a estudiar con él, no a estudiarlo a él. No hay que olvidar que el esfuerzo del usuario debe centrarse en conseguir sus metas y no en dominar el producto. • Debe provocar una actitud positiva del usuario, de tal manera que el sistema invite e incite al usuario a trabajar con él.

265


A partir de estos objetivos de usabilidad se establecieron una serie de principios de diseño orientados a cumplir estos requisitos. Dichos principios se encuentran recogidos en la tabla 9.1. TABLA 9.1. Requisitos de usabilidad Requisito Debe ser útil

Debe ser fácil de usar y aprender

Debe provocar una actitud positiva del usuario

9.1.8.

Principios de diseño • • • • • • • • • • •

Estructurar el material didáctico. Restringir la navegación. Fomentar la participación del usuario. Considerar las necesidades y preferencias del usuario. Hacer un uso de creativo de la multimedia. Evitar enlaces y servicios innecesarios. Crear una interfaz de usuario homogénea y consistente Incluir pistas visuales. Considerar el uso de metáforas. Incluir actividades interactivas. Aplicar una estética adecuada y atrayente.

Diseño conceptual

Una vez analizadas las características del producto, es preciso plantear soluciones que tengan en cuenta dichos requisitos. Para ello se puede realizar un diseño conceptual de la aplicación que sea independiente de la plataforma de implementación, de tal manera que esas soluciones se expresan haciendo uso de abstracciones que son fácilmente comprensibles por parte de todos los miembros del equipo de desarrollo, independientemente de su formación previa. Con este fin, en el proceso de elaboración de Now-Graduado se recurrió al modelo de referencia para hipermedia denominado Labyrinth (Díaz y otros, 1997), que había sido empleado en otras experiencias similares como puede consultarse en (López-Rey y otros, 1999). Por medio de este modelo fue posible representar la estructura lógica del producto, las facilidades de navegación que se iban a ofrecer al usuario así como las características de presentación, las posibilidades de interacción o la creación dinámica de objetos (Díaz y otros, 2001a). A modo de ejemplo, la figura 1 recoge la estructura lógica de Now-Graduado a través de un Diagrama Estructural, propio de la metodología de desarrollo Ariadne (Díaz y otros, 2001b) que, a su vez, se basa en el modelo de representación Labyrinth. Como puede apreciarse en dicha figura, el sistema se organiza como una jerarquía de nodos, que pueden ser: • contenedores de información (nodos simples, representados en la figura por medio de las cajas con borde sencillo), o,

266


• composiciones de otros nodos (nodos compuestos, representados en la figura por medio de las cajas con borde doble e icono en forma de jerarquía). Existen dos relaciones de composición, de acuerdo con el modelo adoptado: la generalización (representada por medio de una flecha desde el hijo al padre) y la agregación (representada por medio de un rombo con origen en el padre). Así, según se muestra en la figura 9.1, Now-Graduado se compone de cuatro elementos: la Presentación, la Ayuda, el Glosario y el Curso en sí. El nodo Presentación es un nodo simple en el que se mostrará, a modo de introducción, una animación sobre los objetivos del curso y su estructura. La Ayuda es un nodo compuesto, pues está formada por una serie de temas (nodo simple Tema) sobre los que se ofrece información, ya sea sobre el uso del producto o sobre el uso del propio ordenador. De forma similar, el Glosario es un nodo compuesto por un conjunto definiciones (nodo simple Definición). El Curso es un nodo más complejo puesto que, por una parte, se indica su estructura y, por otra, sus variantes. El Curso se organiza como una agregación de módulos (nodo compuesto Módulo), cada uno de los cuáles se compone de lecciones (nodo compuesto Lección), que a su vez constan de páginas (nodo compuesto Página) que pueden ser de tres tipos diferentes: páginas de teoría (nodo compuesto Teoría, formado por nodos simples del tipo Concepto), de ejercicios teoría (nodo compuesto Ejercicios, formado por nodos simples del tipo Ejercicio) o una página para ampliar conocimientos sobre el tema tratado (nodo Saber más). Por otra parte, el Curso se especializa en tres materias, representadas respectivamente por los nodos compuestos Socionaturales, Lengua y Matemáticas, cuya estructura es la misma y coincide con la que se ha definido para el nodo Curso. Para definir la forma en que se va poder mover el usuario por la aplicación se hace uso de un Diagrama de Navegación (Díaz y otros, 2001), en el que se indican caminos de navegación entre los nodos. Para ello se pueden establecer enlaces unidireccionales, bidireccionales, n-arios o binarios entre distintos nodos (Díaz y otros, 1996). La figura 9.2 muestra cómo puede acceder el usuario a Now-Graduado. Desde la Presentación, que es el nodo de inicio, el siguiente paso puede ser ir a la Ayuda o al Curso, dependiendo de si es la primera vez que se usa el sistema o no. Por ello se hace uso de un enlace n-ario, definido entre un origen (el nodo Presentación) y dos destinos (los nodos Ayuda y Curso). La selección del destino se hace en tiempo de utilización, comprobando si es o no la primera vez que ese usuario utiliza el producto. Una vez en el Curso, se puede estudiar, con lo que se accede a la última página en que se estuvo (véase enlace Estudiar) o bien repasar lo que se ha hecho hasta el momento, con lo que se accede a un índice creado dinámicamente y en el que sólo se incluyen los conceptos y ejercicios ya estudiados (véanse los enlaces Repasar y Selección). En cada Página se incluyen enlaces a la Ayuda y al Glosario y, además, existe una secuencia entre las páginas de una misma lección, de manera que se proporciona una herramienta de lectura lineal (véase el enlace reflexivo Anterior/Siguiente). Para promover una actitud activa por


267

FIGURA 9.1. Estructura lógica de Now-Graduado.

parte del estudiante, en cada Página se le proponen también enlaces asociativos a otras páginas sobre temas relacionados (véase el enlace reflexivo Asociación), ejercicios relacionados con ese tema (véase el enlace Ejercicicios) así como enlaces directos entre términos presentados en esa página y su definición en el Glosario (véase el enlace Mención). Éstos últimos suponen abrir

268


una ventana modal en la que se presenta ese concepto. Éste y otros aspectos de presentación se indican también con el mismo modelo, si bien no se incluye aquí la especificación por no aportar nada al objeto de este capítulo. Más información sobre el modelo Labyrinth y el método Ariadne puede encontrarse en (Díaz y otros, 1997; Díaz y otros, 2001a; Díaz y otros, 2001b). Esta representación, que es independiente de la plataforma, puede ser discutida con los representantes de los usuarios para identificar la estructura lógica del sistema o las características de navegación e interacción del producto. La principal ventaja que ofrece frente al uso de prototipos o maquetas es que el usuario no se distrae con aspectos de presentación, como los colo-

FIGURA 9.2. La navegación a través de los nodos de Now-Graduado.


269

res o tamaños, que son más llamativos y fáciles de cambiar y, en cambio, se centra en las características conceptuales del sistema. Una buena práctica consiste en acompañar estos diagramas conceptuales con prototipos de usar y tirar (Preece y otros, 2002), de manera que también pueda visualizarse la interfaz y se puedan discutir en el equipo de desarrollo todo tipo de aspectos.

9.1.9.

Implementación

Como se comentó al inicio de este capítulo, Now-Graduado se implementó utilizando Marcomedia Director. La aplicación final era un sistema híbrido, en el que el componente principal era un CD con los contenidos del curso que hacía uso de unos archivos almacenados en el ordenador del usuario en los que se registraba la actividad de éste, con el fin de saber qué había hecho en las sesiones precedentes para poder actuar en consecuencia. Las siguientes figuras muestran algunas de las pantallas de la aplicación que se corresponden con algunos de los nodos conceptuales descritos en la sección anterior. Al describirlos, se hará hincapié en aquellos aspectos de diseño de la interfaz que fueron considerados para mejorar la usabilidad del producto final.

FIGURA 9.3. El nodo Curso en Now-Graduado.

270


El nodo Curso, herramienta de acceso a los cursos de Now-Graduado para estudiar o repasar era el que se muestra en la figura 9.3. Como puede verse, pese a tratarse de un sistema que trataba temas habitualmente enseñados a niños, se optó por una estética apropiada para adultos. Además se hizo un uso semántico del color, de manera que cada temática (matemáticas, lengua o socionaturales) se asoció con un color específico que dominaría su interfaz (azul, rojo y verde, respectivamente). Aquellas zonas comunes, como esta pantalla del Curso, tienen un fondo formado por una combinación de los tres iconos, mientras que las zonas específicas de cada bloque temático están dominadas por su correspondiente color (figuras 9.4 y 9.5). Las páginas, del tipo que fueran, tenían una estructura similar que se definía en el nodo Página y era heredado por los tres nodos que lo especializan (figura 9.1). En la parte superior hay una barra que incluye una herramienta de localización, que indica dónde se encuentra el usuario, y unas herramientas de generales, como son el acceso a la ayuda, a la presentación o la finalización de la sesión de trabajo (representados, respectivamente por los tres iconos de la derecha). Puesto que esta parte es genérica y no depende

FIGURA 9.4. Una página de Teoría de Lengua en Now-Graduado.


271

del tema estudiado, su fondo es una combinación de los iconos de los tres temas del curso. Sin embargo, como el resto de la pantalla se destina al tema específico se utiliza el fondo y el color que representa ese tema. En el caso de la pantalla de la figura 9.4, al tratarse de lengua el color es el rojo frente al verde de la figura 9.5 que es un ejercicio de socionaturales. Las palabras resaltadas, en color rojo en la aplicación original (figura 9.4) invitan al usuario a seleccionarlas y en cada caso se podrá producir uno de tres posibles resultados: se inicia una animación (en el caso del título «El español en el mundo»), se abre una ventana modal con la definición de un término (véase la palabra resaltada «mensajes» y la ventana modal abierta) o se traslada al usuario a una nueva página si se trata de un enlace asociativo. Las figuras 9.5 y 9.6 muestran dos ejemplos de ejercicios de Now-Graduado, destinadas a la clasificación de conceptos y a la identificación, respectivamente. Mientras en el primer caso el usuario puede arrastrar alimentos para incluirlos en la categoría adecuada, en el segundo deben arrastrar letras para construir palabras. Como se puede apreciar son ejercicios muy interactivos, en los que es preciso hacer uso de programación basada en eventos.

FIGURA 9.5. Un ejercicio de clasificación en Now-Graduado

272


FIGURA 9.6. Un ejercicio de identificación en Now-Graduado

9.2.

EJEMPLO DE EVALUACIÓN DE LA USABILIDAD

Otra fase básica del desarrollo de sistemas multimedia o hipermedia es la evaluación, pues permite mejorar la utilidad del producto final. En esta sección, se muestra cómo se llevó a cabo la evaluación de CESAR (Aedo y otros, 1995), un entorno de aprendizaje hipermedia destinado a ayudar a niños con deficiencias auditivas a conseguir la competencia necesaria en los lenguajes gestual y escrito. Este sistema inicia al niño sordo en la estructura del relato y le proporciona la experiencia necesaria mediante el uso de libros e historias. El modelo de sistema educativo adoptado se refleja en la figura 9.7 (Díaz y otros, 1996) en la que se pueden ver tres componentes básicos: una biblioteca de libros, un conjunto de elementos periféricos y los estilos de aprendizaje del usuario. El eje central son los libros que se encuentran en una biblioteca (o librería) y que están compuestos por un relato y un conjunto de entrenamientos como se muestra en la figura 9.7. Los entrenamientos se organizan como ejercicios que pertenecen a una determinada categoría y que se resuelven siguiendo una estrategia que se adapta a las necesidades marcadas por el


273

FIGURA 9.7. El entorno de aprendizaje de CESAR y sus elementos.

estilo de aprendizaje del alumno. Como herramientas externas se incluyen un diccionario y un cuaderno personal, en el que cada niño puede pegar aquellas cosas que desee o crear otras nuevas haciendo uso de un estuche. Para finalizar esta breve descripción del sistema, la figura 9.8 muestra una página del cuento en la que, como puede verse, se adopta la metáfora del libro tradicional aumentada con ciertas posibilidades del entorno electrónico. La aplicación se desarrolló con Hypercard y desde el principio se consideró básico realizar una evaluación con expertos cuyos comentarios pudieran enriquecer la interfaz y el funcionamiento de CESAR. Con este fin, se aplicó el proceso descrito en el apartado 4 y reflejado en la figura 5, como se describe a continuación.

9.2.1. Definición del objetivo de la evaluación Los objetivos de esta evaluación, que se encuentra documentada en (Aedo y otros, 1996), pueden resumirse en dos: • Analizar si los niños pueden beneficiarse de los cuentos electrónicos, el hipertexto y la multimedia durante el aprendizaje.

274


FIGURA 9.8. Una página de un cuento de CESAR.

• Examinar si el sistema ayuda a los niños sordos a adquirir la necesaria competencia en los lenguajes signado y escrito.

9.2.2.

Selección de la técnica de evaluación

Se aplicó la técnica de evaluación denominada Jogthrough, variante del Walkthrough, que permite estudiar la utilidad de un sistema en proceso de diseño, como era el caso de CESAR. De acuerdo con esta técnica, se establece un conjunto de tareas que se pueden realizar con el sistema y que permiten conseguir algún objetivo de los que se quieren evaluar. Cada tarea se descompone en una o más acciones. Varios expertos evalúan dichas tareas con un cuestionario y se utiliza también software de registro y grabación en vídeo. Durante la evaluación participan cuatro tipo de actores, recogidos en la tabla 9.2.

275


TABLA 9.2. Actores involucrados en la técnica de evaluación Jogthrough Actor

Responsabilidades

Presentador Evaluador Moderador Notario

• Describe la tarea a evaluar. • Ejecuta las acciones que conlleva esa tarea e identifica caminos alternativos. • Enfoca la descripción del presentador. • Responde a las cuestiones que se le hacen. • Conduce la reunión, manteniendo el foco de atención. • Resuelve dudas. • Provoca discusiones y comentarios. • Registra cada paso realizado (automatizado en este caso).

El proceso que se aplica es el siguiente: • Cada tarea se evalúa con el cuestionario. • El Presentador introduce el objetivo de la tarea. • El Presentador indica la primera acción a realizar. • Los evaluadores identifican problemas de la interfaz en función del porcentaje de usuarios que tendrán problemas. • Se pasa a la siguiente acción hasta terminar la tarea. • Una vez terminada la tarea, el Moderador propone mejoras. • Se comienza el proceso con una nueva tarea. Se trata por tanto un método sugestivo y eficiente para evaluar un sistema no terminado como era el caso de CESAR.

9.2.3.

Preparación de la evaluación

Durante la preparación de la evaluación, se realizó una experiencia piloto que permitió mejorar el proceso originalmente propuesto, que puede verse en (Rowley y Rhoades, 1992), en dos sentidos: se amplió el rango de respuestas a las preguntas y se incluyeron acciones complementarias, modificando tanto el cuestionario como el modo de utilizarlo. La figura 9.9 muestra el cuestionario final y los ciclos que se realizaban por tarea y actividad. Además, este ensayo permitió refinar el número y tipo de evaluadores que deberían participar en la prueba final. Se optó por un equipo multidisciplinar y reducido, ya que en la experiencia piloto el exceso de evaluadores hizo que algunas discusiones fueran interminables. Al establecer las tareas, se clasificaron éstas en dos tipos tal y como se recoge en la figura 9.10. Cada una de estas tareas se descompuso en una serie de acciones (figura 9.11).

276


FIGURA 9.9. Cuestionario de evaluación de CESAR.

9.2.4.

Realización de la evaluación

Al iniciarse la sesión de evaluación de CESAR, el presentador describió tanto la técnica que se iba a usar, es decir, Jogthrough, como el sistema en sí, es decir, CESAR. Participaron cuatro evaluadores, un pedagogo, un logopeda, un experto en interfaces de usuario y un desarrollador de software. El cuestionario se empleó de la siguiente forma: • El Presentador introducía la tarea o la acción a realizar. • El Moderador hacía las preguntas oportunas. • Se invitaba a los evaluadores a entablar un coloquio y a dar una puntuación entre 0 y 3 en las preguntas cerradas. • Se empleó software de registro y una cámara de vídeo.


FIGURA 9.10. Tareas realizadas durante la evaluación de CESAR.

FIGURA 9.11. Ejemplo de descomposición de tareas en actividades

277

278

9.2.5.


Elaboración de los resultados

Una vez finalizada la sesión de evaluación era preciso analizar los resultados para extraer conclusiones sobre la medida en que los objetivos planteados se habían satisfecho. En las preguntas cerradas se calculó la media por tarea de la agregación de las respuestas de todos los evaluadores (véase como ejemplo la parte superior de la figura 9.12). También se estudió la media por evaluador, dado que su distinta formación y experiencia podía hacer más o menos relevante su juicio. Por ejemplo, las opiniones del logopeda y del pedagogo en las cuestiones relacionadas con actividades de aprendizaje podrían ser más fundadas que las del desarrollador del software, si bien las de este último tampoco son desdeñables. En la parte inferior de la figura 9.12 se muestran las repuestas dadas por el evaluador pedagogo en las tareas relacionadas con el aprendizaje.

FIGURA 9.12. Resultados de las respuestas cerradas del cuestionario.


279

Con respecto a las preguntas abiertas, las respuestas eran opiniones sobre el sistema. Se analizaron y se extrajeron conclusiones tanto sobre el potencial de CESAR como herramienta de apoyo al aprendizaje como sobre las mejoras que podrían realizarse. En conclusión, puede decirse que se trató de una experiencia muy positiva en la que se recogieron opiniones de personas que no pertenecían al grupo de desarrollo y que, además, tenían una perspectiva del producto muy distinta, lo cual permitió mejorar la interfaz del sistema y contar con una cierta evidencia empírica sobre la posible utilidad de CESAR.

9.3.

RESUMEN

En este capítulo se han ilustrado las fases del desarrollo de un producto multimedia a través de dos ejemplos. En el primero, Now-Graduado, se ha presentado cómo realizar el análisis de requisitos y el diseño, tanto el conceptual y como el de la interfaz de usuario, haciéndose hincapié en el hecho de que siempre puede aplicarse un enfoque sistemático. En el segundo se ha ejemplificado el proceso de evaluación de un producto, describiendo las distintas actividades a realizar a través de la evaluación de CESAR.

9.4.

EJERCICIOS DE AUTEVALUACIÓN

9.1. En el análisis de requisitos: a) Se especifican enlaces n-arios. b) Se identifican necesidades de los usuarios como parte de los requisitos del producto a desarrollar. c) Sólo se estudian las características de los usuarios, porque el funcionamiento de la aplicación se analiza durante la fase de diseño. d) Se puede realizar utilizando la técnica denominada Jogthrough.

9.2. Señale las afirmaciones que considere ciertas con respecto al proceso de desarrollo de un sistema multimedia: a) No se puede realizar el análisis ni el diseño si hay un plazo de entrega establecido. b) El diseño conceptual no debe ser independiente de la plataforma de implementación.

280


c) No se pueden usar prototipos de usar y tirar si se sigue un enfoque sistemático. d) El diseño conceptual puede simultanearse con el uso de prototipos. 9.3. En la evaluación de CESAR: a) b) c) d)

Se utilizó Jogthrough porque es una técnica de evaluación analítica. Se utilizó Jogthrough porque es una técnica de evaluación empírica. Se utilizó Jogthrough porque estaba en fase de diseño. No se utilizó Jogthrough si no Walkthrough.

9.4. En el desarrollo de Now-Graduado: a) El diagrama estructural se empleó para representar la forma en que se accedía al sistema. b) Se empleó un modelo de referencia de hipermedia para realizar un diseño conceptual del producto. c) El diagrama estructural incluía enlaces y nodos. d) El análisis no se llevó a cabo por no considerarse de utilidad. 9.5. En la técnica utilizada para evaluar CESAR: a) b) c) d)

9.5.

Los evaluadores son usuarios reales. Se ejecutan acciones que se descomponen en tareas. Se analizan sólo las características de la interfaz de usuario. Se usa software de registro y cuestionarios.


AEDO y otros (1995): I. Aedo, N. Catenazzi y R. Calzada. Electronic Stories for Deaf Children in a Hypermedia Environment (CESAR). Actas de ED-MEDIA 95. Graz (Austria). Junio. Págs. 63-68. AEDO y otros (1996): I. Aedo, N. Catenazzi y P. Díaz. The evaluation of a Hypermedia Learning Environment: The CESAR experience. Journal of Educational Multimedia and Hypermedia, 5 (1). Págs. 49-72. DÍAZ y otros (1996): P. Díaz, N. Catenazzi e I. Aedo. De la multimedia a la hipermedia. Ed. Rama, Madrid. DÍAZ y otros (2001a): P. Díaz, I. Aedo y Fivos Panetsos. Modeling the dynamic behavior of hypermedia applications. IEEE Transactions on Software Engineering, vol 27 (6), Junio. Págs. 550-572. DÍAZ y otros (2001b): P. Díaz, I. Aedo y S. Montero. Ariadne, a development method for hypermedia. Dexa 2001. LNCS 2113. Págs. 764-774.


281

LÓPEZ-REY y otros (1999): A. López-Rey, F. Panetsos, M. Castro y J. Peire. Utilización del modelo Labyrinth en el diseño de la aplicación Now-meta. Congreso Nacional de Informática Educativa (CONIED’99)». Puertollano, España, Noviembre. PREECE y otros (2002): J. Preece, Y. Rogers y H. Sharp: Interaction Design: beyond human computer interaction. John Wiley &Sons. RADA (1995): R. Rada. Interactive Media. Springer-Verlag. ROWLEY y RHOADES (1992): D. E. Rowley, y D. G. Rhoades. The Cognitive Jogthrough: A Fast-Paced User Interface Evaluation Procedure. Proceedings of Computer Human Interaction. ACM. (Mayo). Págs. 389-395.

Capítulo 15 EJEMPLOS DE DESARROLLO DE SISTEMAS MULTIMEDIA

ESQUEMA 15.1. Tipos de aplicaciones multimedia. 15.2. Presentaciones multimedia y patrimonio cultural: Voces de la Meseta del Colorado. 15.3. Telediagnóstico y otros servicios multimedia en medicina: proyecto EMERALD 15.4. VIDEOSERVER: Experiencia en la Universidad de Ko˘sice. 15.5. Sistemas de telepesentación y emisión remota de vídeo. 15.6. Resumen. 15.7. Ejercicios de autoevaluación. 15.8. Referencias bibliográficas.

Como se ha visto a lo largo del libro, las aplicaciones multimedia se caracterizan esencialmente por la combinación de datos independientes de diferentes tipos, entre los cuales se encuentran medios continuos, como el vídeo o el audio, y medios discretos, como el texto o los gráficos. Ahora bien, esa sencilla caracterización incluye a aplicaciones que pueden pertenecer a dominios muy diversos, como la medicina, la educación, el entretenimiento e incluso el arte, y esas aplicaciones pueden tener además características muy diferentes: pueden ser aplicaciones hipermedia en la Web, simples presentaciones, aplicaciones de trabajo cooperativo, etc. Por otro lado, el dominio de aplicación y la funcionalidad que deben proporcionar hacen que el desarrollo de las mismas presente una gran heterogeneidad, de forma que resulta especialmente útil el estudio de informes sobre casos de desarrollo previos de aplicaciones de características similares. Así, el desarrollador de sistemas multimedia puede beneficiarse de las «lecciones aprendidas» de proyectos precedentes, y reutilizar datos de experiencias anteriores. Por ejemplo, en Georganas, 1997, se puede encontrar la descripción de varios sistemas multimedia de índole diversa, y entre las conclusiones de los autores se tiene que, en todos los casos, siempre es necesario tener en cuenta a los usuarios futuros de la aplicación como el aspecto más importante del sistema. En este capítulo, se describen ejemplos de desarrollo de sistemas multimedia concretos, con el objetivo de ofrecer una panorámica de los métodos, técnicas y herramientas de desarrollo que pueden utilizarse.

15.1.

TIPOS DE APLICACIONES MULTIMEDIA

La descripción y comprensión de aplicaciones multimedia concretas se realiza más fácilmente si se posee una visión global de qué tipos de aplicaciones multimedia se pueden encontrar. Obviamente, no existe una única y definitiva clasificación de aplicaciones multimedia, sino que atendiendo a distintos criterios pueden existir distintas taxonomías, todas ellas válidas. Por ejemplo, se pueden clasificar las aplicaciones de acuerdo a qué actores interactúan mediante el uso de la aplicación, ya sean personas o sistemas, o

408


de acuerdo al dominio de la aplicación, ya sea educativo, lúdico, dedicado a la presentación, etc. En esta sección se describirán algunas de estas posibles taxonomías para poder clasificar las aplicaciones que se describen en el resto del capítulo en función de las mismas. Como ya se ha descrito, las aplicaciones multimedia se pueden clasificar de acuerdo a qué actores interactúan gracias al uso de la aplicación, tal y como puede encontrarse en (Fluckiger, 1995). Fluckiger divide este tipo de aplicaciones en dos grandes grupos: — Las aplicaciones multimedia persona-a-persona, donde los actores implicados en el uso de la aplicación son al menos dos humanos, y por lo tanto el objetivo principal de la aplicación suele ser facilitar la comunicación entre ambos con cualquier fin, ya sea en ambientes de trabajo o de otro tipo. — Las aplicaciones multimedia persona-a-sistema, que son aquellas donde individuos o grupos de individuos se comunican con un sistema remoto con objeto de acceder, recibir o interactuar con información multimedia. Como se puede deducir de las características de esta primera división a alto nivel, esta taxonomía está especialmente indicada para clasificar aplicaciones multimedia de red. A su vez estos dos grandes grupos se subdividen en varios más (no excluyentes), tal y como puede observarse en la figura 15.1. Si bien hay otras formas de subdividir las aplicaciones persona-a-persona, la división más representativa que se puede realizar del tipo es de acuerdo al carácter síncrono o asíncrono de las aplicaciones. Las aplicaciones síncronas son aquellas en las que tanto el/los usuarios emisores de la comunicación como el/los usuarios receptores deben estar presentes en el mismo instante de tiempo, para poder llevar a cabo una comunicación en tiempo real. Este tipo de aplicaciones se divide en tres tipos de a aplicaciones: aplicaciones interpersonales, donde hay un único emisor y un único receptor de la comunicación multimedia, aplicaciones persona-grupo, donde el flujo de medios se transmite de un emisor único a un grupo de usuarios y sin posibilidad de que el grupo emita contenidos al emisor, y aplicaciones de teleconferencia en grupo (o grupo-grupo), donde existe una comunicación multimedia bidireccional entre dos o más grupos de personas. En las aplicaciones asíncronas las personas no tienen por qué estar conectadas simultáneamente para poder comunicarse información multimedia. Ejemplos de este tipos de aplicaciones son las aplicaciones de correo electrónico con soporte multimedia o las listas de distribución con soporte para contenidos multimedia.

409

EJEMPLOS DE DESARROLLO DE SISTEMAS MULTIMEDIA

Aplicaciones para la comunicación entre personas

Aplicaciones síncronas

Aplicaciones asíncronas

Aplicaciones Multimedia

Aplicaciones para la comunicación entre personas y sistemas

Aplicaciones interactivas

Aplicaciones de distribución

Aplicaciones de comunicación interpersonal

Aplicaciones de distribución

Aplicaciones de teleconferencia en grupo

Aplicaciones de respuesta simple

Aplicaciones de interacción múltiple

Aplicaciones de distribución a grupos cerrados

Aplicaciones de distribución a grupos abiertos

FIGURA 15.1. Taxonomía de aplicaciones, de acuerdo a actores que se comunican mediante ella.

Las aplicaciones multimedia para la comunicación entre personas y sistemas se pueden dividir según el tipo de acceso que se haga al sistema multimedia en aplicaciones interactivas o aplicaciones de distribución. En las aplicaciones interactivas el usuario es siempre el que inicia la interacción con el sistema, que no tiene porqué realizarse en tiempo real. Así, un usuario puede pedir información en un momento dado —como ocurre, por ejemplo, en aplicaciones de video bajo demanda—, sin necesidad de que el sistema haya iniciado la comunicación y sin restricción en cuanto a cuándo debe responder el usuario a cualquier indicación del sistema. Una vez que el usuario ha iniciado la interacción con el sistema, este tipo de

410


aplicaciones se pueden clasificar a su vez en aplicaciones de respuesta simple, que son aquellas en las que la interacción finaliza cuando el sistema produce una respuesta a la petición inicial del usuario, como ocurre en los sistemas de recuperación de información multimedia, o aplicaciones de interacción múltiple, que son aquellas donde la interacción continua a lo largo de la sesión, que es el caso habitual en aplicaciones multimedia educativas, por poner un ejemplo. Cuando se habla de aplicaciones de distribución se hace referencia a aplicaciones multimedia donde la interacción la inicia el sistema multimedia, y bien puede tratarse de aplicaciones de distribución a grupos cerrados o grupos abiertos. En las aplicaciones de distribución a grupos cerrados el sistema inicia la interacción sólo si el usuario pertenece a un determinado grupo, como ocurre, por ejemplo, en aplicaciones que sirven contenidos multimedia (periódicos o no) a sus suscriptores —véase algunos servidores de noticias o listas de distribución— o en aplicaciones que sirven contenidos a usuarios de un determinado perfil dentro de un grupo. En las aplicaciones de distribución a grupos abiertos no se requieren que el destinatario de la información pertenezca a ninguna categoría en especial. Otra forma típica de clasificar las aplicaciones multimedia es respondiendo al dominio de la aplicación. Un clasificación que responde a este criterio es la que puede consultarse en (Gibbs y Tsichritzis, 1995). Según esta clasificación, existen diversas categorías de aplicaciones multimedia: juegos electrónicos, sistemas de presentación multimedia, herramientas de autor para contenidos multimedia, sistemas de mensajería multimedia, sistemas de conferencia multimedia o aplicaciones de servicios multimedia, que a su vez pueden dividirse en aplicaciones de servicios médicos, de servicios bancarios, aplicaciones educativas o aplicaciones de comercio interactivo, por citar algunas. Cabe destacar que los tipos establecidos en la clasificación que hacen Gibbs y Tsichritzis no pueden considerarse excluyentes, puesto que una aplicación pueden pertenecer a más de uno; por ejemplo, se puede considerar una aplicación multimedia educativa compleja que incluya juegos y un sistema de presentación de contenidos, por poner un caso. En la actualidad se están ultimando otro tipo de taxonomías, como ETNA (siglas en inglés de Taxonomía para la Evaluación de Aplicaciones Multimedia en Red, Evaluation Taxonomy for Networked Multimedia Applications) (Mullin y otros, 2001) para clasificar aplicaciones multimedia en tiempo real. El objetivo de esta taxonomía es disponer de un método para determinar el nivel de calidad de video y audio que requieren las distintas aplicaciones multimedia. Para conseguir tal fin, la clasificación se realiza de acuerdo a criterios que tienen impacto en dicha calidad, como la actividad o tarea para la que está diseñada la aplicación, el contexto en el que se utiliza la misma o el grupo de usuarios al que está destinada.


15.2.

411

PRESENTACIONES MULTIMEDIA Y PATRIMONIO CULTURAL: VOCES DE LA MESETA DEL COLORADO

Los museos, bibliotecas y organizaciones que gestionan el patrimonio cultural de los distintos países han visto en la Web un potencial medio de difusión cultural para sus recursos, que permite llegar a una audiencia más amplia. Por ello, muchas de estas instituciones han habilitado el acceso a sus catálogos o colecciones a través de Internet. Actualmente, se considera que la simple publicación de elementos en catálogos no explota todo el potencial de la interacción con el navegador, y carece de elementos narrativos que faciliten aún más la difusión a audiencias de índoles diversas (Vergo y otros, 2002). Así, han comenzado a aparecer «muestras» o «exposiciones guiadas» virtuales temáticas que mejoran la experiencia de los usuarios mediante un flujo narrativo continuo combinado con información contextual. En esta redacción se describe un ejemplo de ese tipo de exposiciones guiadas denominado «Voces de la Meseta del Colorado» (http://archive.li.suu. edu/voices/), creado bajo los auspicios del Institute for Museum and Library Services, una agencia estatal estadounidense destinada a la difusión cultural. El objetivo del proyecto (Nickerson, 2002) es dar a conocer la historia de la región de la meseta del Colorado a través de grabaciones e imágenes históricas presentadas en un flujo narrativo organizado en tres secciones principales: «Personas», «Lugares» y «Temas», como se muestra en la figura 15.2.

FIGURA 15.2. Menú principal de la presentación guiada «Voces de la Meseta del Colorado».

Cada una de las secciones da acceso a otras subsecciones que dan acceso a varias secuencias guiadas. Algunas de estas secuencias son sólo de audio,

412


pero otras, como la que se muestra en la figura 15.3 combinan audio con subtítulos, músicas de fondo y la sucesión de las imágenes en movimiento de la zona que ilustran el discurso en primera persona.

FIGURA 15.3. Narración histórica sincronizada en primera persona.

Por tanto, la aplicación permite el acceso por tres criterios (correspondientes a las tres secciones principales) a una colección de presentaciones multimedia en primera persona que utilizan diferentes combinaciones de tipos multimedia. Es importante resaltar que la tecnología subyacente a esta presentación es un servidor Web estándar, habiendo sido desarrolladas las presentaciones con la herramienta Flash 5 de Macromedia, y utilizando compresión MPEG para combinar varios canales de sonido. El equipo de desarrollo estaba formado por estudiantes con conocimientos de publicación en Web y multimedia, y los expertos de las diferentes instituciones participantes trabajaron colaborativamente utilizando técnicas tan simples como el correo electrónico o el protocolo de transferencia de ficheros FTP.

15.3.

TELEDIAGNÓSTICO Y OTROS SERVICIOS MULTIMEDIA EN MEDICINA: PROYECTO EMERALD

La multimedia está teniendo un amplio campo de aplicación en los servicios médicos. Concretamente se construyen sistemas de información médica


413

integrados para cubrir áreas como la captura de imágenes o videos digitales de gran calidad y su posterior retransmisión entre servicios hospitalarios o incluso entre hospitales con objeto de facilitar el telediagnóstico en función de datos de distinta naturaleza (radiografías, tomografías, resonancias magnéticas, etc.). Uno de los proyectos más recientes en esta línea es el proyecto europeo EMERALD (Servicios Multimedia Europeos para imágenes médicas, European Multimedia Services for Medical Imaging) (Rahms y otros, 1997). El principal objetivo de dicho proyecto es la creación de un servicio médico multimedia avanzado que facilite el trabajo cooperativo y la coordinación entre grupos de especialistas con objeto de ofrecer una mayor calidad de servicio en las redes hospitalarias europeas. El sistema está desarrollado en diferentes escenarios diferenciados entre los que se incluye la radiología, la cardiología, la mamografía y la radiocirugía. En la figura 15.4 se puede observar una videoconferencia desarrollada en el escenario de radiología, llevada a cabo con EMERALD.

FIGURA 15.4. Sesión de videoconferencia con visualización de radiografías.

414


Para todos los escenarios actuales de uso la aplicación dispone de un conjunto de servicios comunes como videoconferencias, soporte para trabajo en grupo, transmisión de ficheros de datos, digitalización de audio y video, almacenamiento, recuperación mediante consultas, visualización y procesamiento de información multimedia de acuerdo al estándar DICOM (Figura 15.5) y mensajería multimedia.

FIGURA 15.5. Aplicación del proyecto EMERALD, procesamiento y visualización de imágenes digitales.

En cuanto al tipo de aplicación, y teniendo en cuenta que se trata de un sistema integrado, EMERALD se puede considerar de distinto tipo según el uso que se haga de ella. Dentro de las aplicaciones de servicios multimedia médicos, la aplicación contiene servicios síncronos, como la videoconferencia, asíncronos, como la mensajería electrónica multimedia, e interactivos, como la recuperación y procesamiento de imágenes e historias clínicas. EMERALD hace uso del protocolo IP sobre ATM, y soporta codificación de video a 15 fps, siguiendo el estándar JPEG con un ratio de transmisión de 2 a 5 Mbits/s. Como ya se ha indicado, la transmisión de imágenes médicas se realiza bajo el estándar DICOM 3.0, que define cómo se deben comunicar los equipos de tomas de imágenes médicas, así como especifica qué datos que se necesitan del paciente y de la imagen médica y que formato deben tener.


15.4.

415

VIDEOSERVER: EXPERIENCIA EN LA UNIVERSIDAD DE KOSˇICE

Otro tipo de aplicación multimedia muy común es la implementación de servidores de video. Se va a presentar a continuación una implementación concreta llevado a cabo en la Universidad de Kosˇ ice (Eslovaquia) diseñada para almacenar presentaciones de video con otro soporte de presentación multimedia, como es la visualización de transparencias creadas con PowerPoint. La aplicación está disponible en la URL http://videoserver.atm.tuke.sk/ Videoserver (Jakab, 2002) es una herramienta Web que permite a los usuarios registrados tanto conectarse a aulas virtuales donde se están llevando a cabo sesiones como acceder a contenidos multimedia de grabaciones en video correspondientes a una clase o sesión informativa. Para asistir virtualmente a un aula se puede consultar la planificación de reservas de dichas aulas así como consultar los datos de la sesión que tendrá lugar (figura 15.6). Teniendo en cuenta este servicio de la aplicación, ésta se puede considerar una aplicación educativa de tipo síncrono, más concretamente se trata de una aplicación persona-grupo, puesto que la comunicación es síncrona y unidireccional, del profesor o ponente al grupo que conforma su audiencia virtual, permitiendo igualmente la asincronía ya que almacena las sesiones de manera que se pueden visualizar posterioremente.

FIGURA 15.6. Aulas virtuales en Videoserver y la planificación de su ocupación.

416


La segunda funcionalidad que permite la aplicación es la de visualizar sesiones de eventos anteriores. El usuario puede seleccionar la sesión que desee dentro de una colección organizada por eventos y, mientras se muestra el video de la sesión también se puede visualizar la presentación multimedia que el profesor o ponente utilizara en su momento (figura 15.7). Desde el punto de vista de este servicio, la aplicación Videoserver se puede catalogar como una aplicación interactiva de respuesta simple.

FIGURA 15.7. Visualización de una sesión almacenada con Videoserver. En la parte izquierda de la pantalla aparece la reproducción de video y en la parte derecha se muestran las transparencias utilizadas en la sesión.

La aplicación está construida sobre tecnologías Microsoft Media. Se ha utilizado Windows Media Tools para la creación de contenidos, Windows Media Player como cliente para visualizar los flujos de medios y Windows Media Services para implementar el servidor que proporciona contenidos a los usuarios. Este último se seleccionó frente a un simple servidor Web puesto que posibilita visualizar contenidos multimedia sin necesidad de descargarlos previamente por completo, permite administrar opciones de seguridad y proporciona tecnologías que permiten el flujo inteligente (intelligent data streaming), es decir, que la transmisión del flujo de medias se ajusta al ancho de


417

banda de la conexión que establece el usuario, permitiendo que incluso para una conexión realizada con módem, la calidad de la reproducción en el cliente sea adecuada.

15.5.

SISTEMAS DE TELEPRESENTACIÓN Y EMISIÓN REMOTA DE VÍDEO

Uno de las utilidades más recientes de la multimedia es la retransmisión de video en tiempo real. Aplicaciones que permitan llevar a cabo estas funciones son de sumo interés tanto en las clases, dentro del ámbito educativo, como en organizaciones a la hora de realizar reuniones y otro tipo de encuentros, puesto que permiten que los participantes en las mismas no se encuentren en el mismo lugar. Uno de los principales problemas de este tipo de aplicaciones es el coste tan elevado que pueden llegar a alcanzar las retrasmisiones, ya que para obtener una buena calidad en la grabación hacen falta profesionales que graben en cada momento de la conferencia lo más adecuado, ya sea el conferenciante, la proyección que está realizando el conferenciante o bien la audiencia en general o la persona que formula la pregunta. Recientes sistemas como el descrito en (Rui, Gupta y Grudin, 2003) permiten automatizar la grabación en una sala de conferencias teniendo en cuenta todos estos factores. La arquitectura del sistema, como la de cualquier aplicación multimedia (Capítulo 10), está formada por una capa hardware y una capa software. La capa hardware está formada por diferentes cámaras, micrófonos y los ordenadores que lo controlan, mientras que la capa software (además de los sistemas operativos y controladores necesarios para la transmisión en red) contiene módulos que permiten la correcta grabación de los que acontece en la sala. Más concretamente, el sistema que se describe consta de cuatro cámaras (figura 15.8): una orientada al conferenciante, otra a la audiencia, otra al área donde el conferenciante proyecta transparencias y una última que recoge perspectivas generales de la sala. Cada cámara tiene asociado un ordenador que la controla y que gracias a módulos software juega el papel del hombre-cámara. Cada uno de estos ordenadores está conectado con otro que hace las veces de director. Entre los «hombrescámara» y el «director» se produce el intercambio de órdenes necesario para obtener una grabación lo más correcta y profesional posible. Las órdenes están programadas en función de los estados de cada «hombre-cámara» y sobre la base de una serie de reglas obtenidas de profesionales humanos. El «director», una vez obtenidas las secuencias de los «hombres-cámara» las mezcla y codifica para su transmisión y posterior visualización tanto en multidifusión como bajo demanda.

418


FIGURA 15.8. Arquitectura en bloques de la aplicación de grabación automática de Rui y otros.

La aplicación que se está describiendo ha sido evaluada tanto por cámaras profesionales como por posibles usuarios —puede verse un resumen del informe en (Rui, Gupta y Grudin, 2003)— permitiendo así a sus creadores perfeccionar el sistema de posicionamiento de las cámaras e incorporar nuevas reglas y estados al sistema. La evaluación se llevó a cabo permitiendo la grabación simultánea tanto por el sistema como por los profesionales humanos, de manera que los posibles usuarios podían observar en su interfaz (figura 9) ambas opciones (A y B en la figura 15.9) para emitir un juicio final.

FIGURA 15.9. Interfaz de usuario para la audiencia remota de la aplicación de teletrasmisión de Rui.


15.6.

419

RESUMEN

En este capítulo se realiza una descripción general de algunas aplicaciones multimedia concretas con objeto de que el lector tenga un espectro amplio de cómo se han desarrollado y para qué fin. Para ello se hace necesario partir de algún tipo de taxonomía que permita clasificar la aplicación descrita de acuerdo a un determinado criterio. En el primer apartado se han esbozado algunas de estas taxonomías. Con mayor detalle se describió cómo se pueden clasificar aplicaciones de acuerdo al tipo de actores entre los que media la aplicación, ya sean personas o sistemas. También se ha mencionado más someramente la existencia de otras clasificaciones que responden a criterios como el dominio de la aplicación o a cómo se lleva a cabo la tarea para la que se diseñó la aplicación, el tipo usuario que la realiza y las condiciones ambientales en las que se desarrolla. La primera aplicación que se describe es un ejemplo de aplicación multimedia para la exhibición de patrimonio cultural. Se trata de una aplicación desarrollada en Flash 5.0 y con compresión MPEG para dar a conocer la región e historia de las mesetas de Colorado (EEUU). El segundo caso que se describe muestra cómo una aplicación multimedia se puede utilizar en el ámbito médico. Se trata del proyecto EMERALD, que proporciona un sistema multimedia integrado entre varios hospitales europeos con el fin de soportar el intercambio de datos y diagnósticos en cuatro servicios hospitalarios distintos utilizando redes ATM y servicios de videoconferencia, transmisión, almacenamiento y procesamiento de video e imágenes digitales entre otros. A continuación se muestró una aplicación que permite almacenar y recuperar videos a través de Internet así como conectarse a aulas virtuales para poder visualizar lo que ocurre en su interior. La arquitectura de esta aplicación está íntegramente diseñada utilizando tecnología Windows Media, tanto para la generación de contenidos como para el suministro de servicios y acceso en el cliente. Por último se describió una sistema multimedia para la difusión de video. En este ejemplo se muestra una arquitectura multimedia cubriendo tanto sus capas hardware como las software. El sistema automatiza la grabación de lo que ocurre en un lugar de reunión mediante un sistema controlado por reglas obtenidas de profesionales humanos. La grabación puede ser visualizada en tiempo real o bajo demanda.

420

15.7.



15.1. ¿De que tipo es la aplicación de telepresentación descrita en la sección 4? a) Aplicación de comunicación entre personas síncrona de comunicación interpersonal. b) Aplicación de comunicación entre personas asíncrona. c) Aplicación para la comunicación entre personas y sistemas. d) Aplicación para FNS.

15.2. ¿Cuál de las siguientes afirmaciones es cierta respecto a las aplicaciones multimedia? a) Todas las aplicaciones multimedia son interactivas. b) Algunas aplicaciones multimedia pueden facilitar el trabajo en grupo. c) Las aplicaciones de comunicación interpersonal no son aplicaciones interactivas. d) Las aplicaciones no tienen que ser interactivas.

15.3. ¿Cuál de las siguientes aplicaciones es cierta respecto a la aplicación descrita en la sección 2? a) La aplicación utiliza un servidor Web especializado con streamming de vídeo. b) La aplicación está basada en el formato Flash de presentaciones multimedia. c) El desarrollo de la aplicación se realizó utilizando herramientas de autor colaborativas. d) El sistema WGF es el más completo.

15.4. ¿Cuáles de estas afirmaciones son ciertas respecto a la aplicación descrita en la sección 3? a) La aplicación está basada en el estándar DICOM que define cómo se deben comunicar los equipos de captura de imágenes médicas. b) La aplicación está basada en el estándar DICOM que especifica el protocolo TCP/IP sobre redes ethernet como requisito de comunicación. c) Es una aplicación que no permite ningún tipo de comunicación síncrona. d) El sistema VRF no es operativo en WWW.

15.5. ¿Cuál de las siguientes afirmaciones es falsa respecto a la aplicación descrita en la sección 15.4?


421

a) La aplicación VIDEOSERVER es una aplicación de comunicación entre personas que permite la comunicación síncrona. b) La aplicación VIDEOSERVER es una aplicación de comunicación entre personas que permite la comunicación asíncrona. c) La aplicaciones está construida con tecnologías especializadas de streamming de vídeo. d) La aplicación permite tener dos presentaciones simultáneas dentro de la misma sala virtual.

15.8.


FLUCKIGER (1995): Fluckiger, F. Understanding Networked Multimedia: Applications and Technology. Prentice-Hall Europe, 1995. GEORGANAS, (1997): Georganas, N.: Multimedia Applications Development: Experiences. Multimedia Tools and Applications, 4(3), Kluwer Academic Publishers (1997), págs. 313-332. GIBBS y TSICHRITZIS (1995): Gibbs, S.J. y Tsichritzis, D.C.: Multimedia Programming: Objects, Environments and Framenworks. Addison-Wesley + ACM Press (1995). JAKAB, GENCˇ I y CˇECH, 2002) Jakab, F., Gencˇ i, J y Cˇech, A.: Experimental Videoserver implementation at Technical University of Ko_ice. International Conf. On Informtaion Technology Based Higher Education and Training ITHET’02, 2002. págs. 247-251. MULLIN y otros (2001): Mullin, J., Smallwood, L., Watson, A. y Wilson, G.: New Techniques For Assessing Audio And Video Quality In Real-Time Interactive Communications. Tutorial realizado en Human Computer Interaction 2001 IHM-HCI 2001, Lille, Francia, 2001. Disponible en: http://www-mice.cs.ucl.ac.uk/multimedia/projects/etna/tutorial.pdf , consultado en abril de 2003. NICKERSON (2002): Nickerson. M.: «Voices: Bringing Multimedia Museum Exhibits to the World Wide Web», First Monday 7(5) (May 2002). Disponible en http://firstmonday.org/issues/issue7_5/nickerson/index.html, consultado en abril de 2003. RAHMS y otros. (1997): Rahms, H., Desco, M., Martínez, F., Fraile, E., García-Barreno, P., del Pozo, F.: European Multimedia Services for Medical Imaging (EMERALD Project). Computer Assisted Radiology and Surgery. H.U. Lemke, M.W. Vannier, K. Inamura (eds). Elsevier Science, 1997. RUI, GUPTA y GRUDIN (2003): Y. Rui, A. Gupta y J. Grudin: Videography for Telepresentations, Actas de ACM CHI’2003. VERGO y otros (2002): John Vergo, Clare-Marie Karat, John Karat, Claudio Pinhanez, Renee Arora, Thomas Cofino, Doug Riecken y Mark Podlaseck,: «Less Clicking, More Watching: Results from the User-Centered Design of a Multi-Institutional Web Site for Art and Culture,» Papers from Museums and the Web 2002, Seattle, Wash. Disponible en http://www.archimuse.com/mw2001/papers/vergo/vergo. html.

55521UD01A01

55521UD01A01

55521UD01A01

Ignacio Aedo Cuevas es doctor en Informática por la Universidad Politécnica de Madrid lleva trabajando en el campo de la hipermedia desde 1990, participando en numerosos proyectos internacionales, nacionales y regionales tanto con financiación pública como privada en el área de sistemas interactivos. Es autor de más de cien artículos y congresos tanto nacionales como internacionales, siendo además miembro del consejo editor de la revista IFETS&IEEE LTTF Journal of Educational Technology and Society. En la actualidad es catedrático de Universidad del Departamento de Informática de la Universidad Carlos III de Madrid.

Cada vez son más y mejores las herramientas de edición multimedia disponibles en el mercado a precios razonables. Sin embargo, el mayor problema está en la formación adecuada de los autores potenciales de trabajos multimedia. Se pretende con este libro presentar, de forma clara y sistemática, las líneas de acción principales de análisis, diseño y evaluación de una aplicación multimedia. La obra Sistemas Multimedia: análisis, diseño y evaluación va permitir al lector interesado: • Analizar los requisitos de los sistemas multimedia, y su integración en los sistemas de información actuales. • Identificar los distintos componentes de éstos, así como las distintas plataformas de distribución existentes: CDROM, Intranet, Internet, etc. • Promover la capacidad de diseño de sistemas, su interrelación con la interfaz de usuario y los requisitos del mismo. • Evaluar los diferentes sistemas multimedia utilizados en los actuales sistemas de información. Para ello se incluyen los siguientes contenidos temáticos: • Medios tradicionales y medios digitales de la información (textos, sonidos, imagen, animación, vídeo, 3D, etc.). • Análisis, diseño, evaluación y dirección de proyectos de sistemas multimedia y de la interfaz de usuario. • Plataformas de difusión (CD-ROM, Intranet, Internet, etc.). Integración de sistemas multimedia en la www. La obra incluye además, como valor añadido, un tema específico de dirección y metodología de proyectos multimedia. ¡Esperamos que el lector vea cumplidas sus expectativas…!

ISBN 84-362-4996-8


Unidad Didáctica

Unidades Didácticas Cuadernos de la UNED Aula Abierta Estudios de la UNED Actas y Congresos Estudios de Educación a Distancia Educación Permanente

Ingeniería en Informática (2º ciclo)


Colecciones de la UNED

I. Aedo Cuevas A. Vara de Llano F. Mur Pérez P. Díaz Pérez A. Colmenar Santos M. A. Castro Gil M. A. Sicilia Urbán P. Losada de Dios J. Peire Arroba

U.D.

Paloma Díaz Pérez es licenciada y doctora en Informática por la Universidad Politécnica de Madrid, siendo en la actualidad catedrática de Universidad del Departamento de Informática de la Universidad Carlos III de Madrid. Sus intereses se centran en el proceso de desarrollo de sistemas interactivos así como en la incorporación de las tecnologías de la información y de las comunicaciones en el proceso de aprendizaje, habiendo participado en numerosos proyectos relacionados con estos temas. Además, es autora de numerosos artículos internacionales en las revistas más prestigiosas en los ámbitos de su interés (IEEE Transactions on Software Engineering, IEEE Transaction on Education, Information Systems, etc.) y es autora de tres libros relacionados con el proceso de desarrollo de sistemas informáticos y con la hipermedia. Es miembro del comité ejecutivo de IEEE Learning Technology Task Force. Miguel Ángel Sicilia Urbán es doctor Ingeniero en Informática por la Universidad Carlos III de Madrid e Ingeniero en Informática por la Universidad Pontificia de Salamanca. Ha desarrollado su labor docente e investigadora en ambas Universidades, estando actualmente en la Universidad de Alcalá de Henares. Ha trabajado como consultor, tutor y arquitecto software en diferentes empresas, y actualmente desarrolla su labor investigadora en el área de hipermedia adaptativa y los sistemas educativos, con especial énfasis en el tratamiento de la imprecisión y la incertidumbre. Alfonso Vara de Llano es Ingeniero Industrial por la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid, en la especialidad Electricidad, intensificación Electrotecnia. Actualmente es gerente de Proyectos en la División de Servicios Profesionales de Compaq, recientemente fusionada con Hewlett Packard. Anteriormente ha trabajado como Jefe de Proyectos en UITESA (actualmente integrada en IBERINCO perteneciente a al grupo IBERDROLA) y como ingeniero en el Laboratorio de Ensayos Dinámicos de Vehículos Ferroviarios de RENFE. Es profesor asociado de la E.T.S. de Ingenieros Industriales de la UNED y sido durante 1 año profesor asociado en la E.T.S. de Ingenieros Industriales de la Universidad Politécnica de Madrid y durante 4 años profesor asociado en la Escuela Politécnica Superior de la Universidad Carlos III de Madrid.

SISTEMAS MULTIMEDIA: ANÁLISIS, DISEÑO Y EVALUACIÓN Ignacio Aedo Cuevas Paloma Díaz Pérez Miguel Ángel Sicilia Urbán Alfonso Vara de Llano Antonio Colmenar Santos Pablo Losada de Dios Francisco Mur Pérez Manuel Alonso Castro Gil Juan Peire Arroba


Antonio Colmenar Santos es doctor Ingeniero Industrial e Ingeniero Industrial, especialidad Electrónica y Automática por la ETSII de la UNED e Ingeniero Técnico Industrial por la Escuela Universitaria de Ingeniería Técnica Industrial de la Universidad de Valladolid, especialidad Electricidad, intensificación Electrónica, Regulación y Automatismos. Actualmente es Profesor titular en el área de Ingeniería Eléctrica del Departamento de Ingeniería Eléctrica Electrónica y de Control DIEEC de la UNED. Ha sido profesor asociado en el Departamento de Tecnología Electrónica en la Universidad Politécnica de Alcalá de Henares y en el DIEEC de la UNED. Es profesor titular en excedencia del cuerpo de Profesores de Educación Secundaria y de Profesores Técnicos de Formación Profesional en las especialidades de Sistemas Electrónicos y Equipos Eléctricos, respectivamente. Ha trabajado para la AECI-ICI como experto asesor en el proyecto INTECNA (Nicaragua). Es miembro de la sección española de la International Solar Energy Society (ISES) y ha trabajado en diferentes proyectos relacionados con las energías renovables. Ha pertenecido a la Association for the Advancement of Computing in Education. Es experto en aplicaciones de Sistemas Multimedia y posee diferentes publicaciones prácticas apoyándose en estas técnicas. Actualmente, es Coordinador de Virtualización en la ETSII de la UNED. Pablo Losada de Dios es Ingeniero Técnico de Telecomunicaciones por la Escuela Universitaria de Ingenieros Técnicos de Telecomunicación de la Universidad Politécnica de Madrid, en la especialidad de Imagen y Sonido. Ha obtenido el Premio a los mejores Materiales Didácticos en Ciencias Experimentales del Consejo Social de la UNED en 1998. Posee los títulos de Postgrado de Especialista Universitario en “Comunicaciones: Redes, Servicios e InfoVía”, “Desarrollo de Aplicaciones Multimedia: Aplicaciones para InfoVía” y Sistemas de Gestión de Bases de Datos, todos otorgados por la UNED. Ha realizado los cursos oficiales de Microsoft de administración y gestión de Redes NT. En la actualidad trabaja en la UNED como Técnico Especialista para el apoyo informático del profesorado del Departamento de Ingeniería Eléctrica, Electrónica y de Control de dicha Escuela, colaborando en proyectos del departamento, impartiendo cursos de formación y realizando la gestión y el soporte de los servidores del Departamento. Francisco Mur Pérez es doctor Ingeniero Industrial por la Escuela Técnica Superior de Ingenieros Industriales de la UNED e Ingeniero Industrial, especialidad Electricidad, intensificación Electrónica y Automática por la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid. Ha obtenido el Premio Extraordinario de Doctorado de la UNED. Ha obtenido el Premio a los mejores Materiales Didácticos en Ciencias Experimentales del Consejo Social de la UNED en el año 1999. Actualmente es profesor titular en el Departamento de Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED. Manuel-Alonso Castro Gil es doctor Ingeniero Industrial por la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid (UPM) e Ingeniero Industrial, especialidad Electricidad, intensificación Electrónica y Automática, por la misma Escuela. Ha obtenido el Premio Extraordinario de Doctorado de la UPM así como el Premio Viesgo 1988 a la Tesis Doctoral por la aportación a la Investigación Científica sobre Aplicaciones de la Electricidad en los Procesos Industriales. Ha obtenido el Premio a los mejores Materiales Didácticos en Ciencias Experimentales del Consejo Social de la UNED en los años 1997 y 1999. Ha recibido el premio a la "Innovative Excellence in Teaching, Learning & Technology" del "Center for the Advancement of Teaching and Learning" del año 2001. Actualmente es Catedrático de Universidad del área de Tecnología Electrónica en el Departamento de Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED, a la vez que es Vicerrector de Nuevas Tecnologías de la UNED. Ha sido Director del Centro de Servicios Informáticos de la UNED y Subdirector de Investigación y Doctorado, y de Gestión Académica de la ETSII. Ha participado en numerosos proyectos de investigación como investigador, coordinador y director y ha publicado en revistas y congresos, tanto nacionales e internacionales. Ha publicado igualmente diversos libros y material multimedia dentro de sus líneas de investigación y docencia. Ha trabajado cinco años como Ingeniero de Sistemas en Digital Equipment Corporation. Pertenece al comité organizador de los congresos internacionales IEEE FIE, ISES y TAEE, así como es revisor y presidente de mesa. Es miembro Senior del IEEE y del consejo de dirección de ISES España. Juan Peire Arroba es doctor Ingeniero Industrial por la Escuela Técnica Superior de Ingenieros Industriales de la Universidad Politécnica de Madrid e Ingeniero Industrial, especialidad Electricidad por la misma Escuela. Licenciado en Derecho por la Universidad Complutense de Madrid. Actualmente es Catedrático de Universidad del área de Tecnología Electrónica en el Departamento de Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED. Ha sido Director del Departamento. Ha obtenido el Premio a los mejores Materiales Didácticos en Ciencias Experimentales del Consejo Social de la UNED en los años 1997 y 1999. Ha recibido el premio a la "Innovative Excellence in Teaching, Learning & Technology" del "Center for the Advancement of Teaching and Learning" del año 1999. Ha trabajado varios años como Consultor especializado en la creación de Empresas Tecnológicas, así como ha dirigido y dirige diversos proyectos de investigación, tanto nacionales como internacionales. Es miembro del IEEE.

Sistemas Multimedia Analisis, Diseño y Evaluacion

Recommend Documents