Sistemas Multimedia PDF

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
U.D. 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.
Unidad Didáctica
Paloma Díaz Pérez es licenciada y doctora en Informática por la Universidad Politécnica
A. Colmenar Santos M. A. Castro Gil

de Madrid, siendo en la actualidad catedrática de Universidad del Departamento de Informática
J. Peire Arroba
de la Universidad Carlos III de Madrid. Sus intereses se centran en el proceso de desarrollo de
F. Mur Pérez
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
Colecciones de la UNED 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
Cada vez son más y mejores las herramientas de edición comité ejecutivo de IEEE Learning Technology Task Force.
Unidades Didácticas multimedia disponibles en el mercado a precios razonables. 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
Cuadernos de la UNED Sin embargo, el mayor problema está en la formación adecuada
M. A. Sicilia Urbán P. Losada de Dios

desarrollado su labor docente e investigadora en ambas Universidades, estando actualmente en
A. Vara de Llano
la Universidad de Alcalá de Henares. Ha trabajado como consultor, tutor y arquitecto software
Aula Abierta de los autores potenciales de trabajos multimedia. Se pretende 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
con este libro presentar, de forma clara y sistemática, las líneas la incertidumbre.
Estudios de la UNED de acción principales de análisis, diseño y evaluación de una 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
Actas y Congresos aplicación multimedia. 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
Estudios de Educación a Distancia La obra Sistemas Multimedia: análisis, diseño y evaluación 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
va permitir al lector interesado: Ferroviarios de RENFE. Es profesor asociado de la E.T.S. de Ingenieros Industriales de la UNED
Educación Permanente • Analizar los requisitos de los sistemas multimedia, y su
y sido durante 1 año profesor asociado en la E.T.S. de Ingenieros Industriales de la Universidad
I. Aedo Cuevas
Politécnica de Madrid y durante 4 años profesor asociado en la Escuela Politécnica Superior de
la Universidad Carlos III de Madrid.
P. Díaz Pérez
integración en los sistemas de información actuales. Antonio Colmenar Santos es doctor Ingeniero Industrial e Ingeniero Industrial, especialidad
• Identificar los distintos componentes de éstos, así como 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
las distintas plataformas de distribución existentes: CD- 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
ROM, Intranet, Internet, etc. y de Control DIEEC de la UNED. Ha sido profesor asociado en el Departamento de Tecnología
• Promover la capacidad de diseño de sistemas, su

interrelación con la interfaz de usuario y los requisitos
SISTEMAS MULTIMEDIA: 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
del mismo.
• Evaluar los diferentes sistemas multimedia utilizados en
Ingeniería
en Informática
ANÁLISIS, DISEÑO 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.
los actuales sistemas de información.
Para ello se incluyen los siguientes contenidos temáticos: (2º ciclo) Y EVALUACIÓN 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
• Medios tradicionales y medios digitales de la información 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
(textos, sonidos, imagen, animación, vídeo, 3D, etc.). 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
• Análisis, diseño, evaluación y dirección de proyectos de 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,
sistemas multimedia y de la interfaz de usuario. impartiendo cursos de formación y realizando la gestión y el soporte de los servidores del
Departamento.
• Plataformas de difusión (CD-ROM, Intranet, Internet,
etc.). Integración de sistemas multimedia en la www.
Ignacio Aedo Cuevas 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
La obra incluye además, como valor añadido, un tema Paloma Díaz Pérez 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
específico de dirección y metodología de proyectos multimedia. Miguel Ángel Sicilia Urbán 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
ANÁLISIS, DISEÑO Y EVALUACIÓN

de Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED.
¡Esperamos que el lector vea cumplidas sus expectativas…!
Alfonso Vara de Llano 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,
Antonio Colmenar Santos 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
Pablo Losada de Dios 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
Francisco Mur Pérez
SISTEMAS MULTIMEDIA:
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
ISBN 84-362-4996-8
Manuel Alonso Castro Gil 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
Juan Peire Arroba 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
UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA proyectos de investigación, tanto nacionales como internacionales. Es miembro del IEEE.
SISTEMAS MULTIMEDIA: ANÁLISIS, DISEÑO
Y EVALUACIÓN
UNIDADES DIDÁCTICAS
Ignacio Aedo Cuevas Pablo Losada de Dios
Paloma Díaz Pérez Francisco Mur Pérez
Miguel Ángel Sicilia Urbán Manuel Alonso Castro Gil
Alfonso Vara de Llano Juan Peire Arroba
Antonio Colmenar Santos
ANÁLISIS, DISEÑO
Y EVALUACIÓN
UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

UNIDADES DIDÁCTICAS (55521UD01A01)
SISTEMAS MULTIMEDIA: ANÁLISIS, DISEÑO Y EVALUACIÓN
Quedan rigurosamente prohibidas, sin la autorización escrita

de los titulares del «Copyright», bajo las sanciones establecidas en las leyes,
la reproducción total o parcial de esta obra por cualquier medio o procedimiento,
comprendidos la reprografía y el tratamiento informático, y la distribución
de ejemplares de ella mediante alquiler o préstamo públicos.
© UNIVERSIDAD NACIONAL
DE EDUCACIÓN A DISTANCIA - Madrid, 2004
Librería UNED: Bravo Murillo, 38; 28015 Madrid

Tels.: 91 298 75 60/73 73, e-mail: libreria@adm.uned.es
© Ignacio Aedo, Paloma Díaz, Miguel Ángel Sicilia, Alfonso Vara, Antonio Colmenar,
Pablo Losada de Dios, Francisco Mur, Manuel Alonso Castro y Juan Peire
ISBN: 84-362-4996-8
Depósito legal: M. 5383-2004
Primera edición: febrero de 2004
Impreso en España - Printed in Spain
Imprime: LERKO PRINT, S.A.
Paseo de la Castellana, 121. 28046 Madrid

ÍNDICE
Presentación.............................................................................................. 13
CAPÍTULO 1
MULTIMEDIA Y COMUNICACIÓN. SISTEMAS MULTIMEDIA
1.1. La comunicación a distancia .......................................................... 21

1.2. La revolución de las comunicaciones. Internet ............................. 26
1.3. Sistemas y procesado de la información: Informática.................. 27
1.4. El concepto de multimedia ............................................................. 28
1.5. Sistemas multimedia tradicionales................................................. 30
1.6. Sistemas multimedia actuales......................................................... 34
1.7. Ventajas e inconvenientes de los multimedia ................................ 36
1.8. Recomendaciones a tener en cuenta en el diseño de un proyecto
multimedia ....................................................................................... 37
1.9. Resumen ........................................................................................... 40
1.10. Ejercicios de autoevaluación........................................................... 41
1.11. Referencias bibliográficas ............................................................... 42
CAPÍTULO 2
MEDIOS: TEXTO, IMAGEN Y SONIDO
2.1. Hipertexto......................................................................................... 45
2.2. Hipermedia....................................................................................... 49
2.3. OCR. Reconocimiento Óptico de Caracteres ................................. 49
2.4. Captura de imágenes digitales ........................................................ 51
2.5. Formatos de archivos ...................................................................... 54
2.6. El sonido digital. Conceptos previos .............................................. 55
2.7. CD-AUDIO ........................................................................................ 56
8 SISTEMAS MULTIMEDIA: ANÁLISIS, DISEÑO Y EVALUACIÓN
2.8. Formatos de sonido ......................................................................... 57

2.9 Extracción-Compresión-Reproducción .......................................... 60
2.10. Resumen .......................................................................................... 62
CAPÍTULO 3
MEDIOS: ANIMACIÓN Y VÍDEO
3.1. Las animaciones. Principios, herramientas y técnicas de animación . 70

3.2. Imágenes en 3 dimensiones. Creación y animación........................ 78
3.3. Elementos básicos para comenzar a digitalizar vídeo .................... 88
3.4. Edición y efectos del vídeo digital .................................................... 95
3.5. Resumen ............................................................................................. 102
3.6. Ejercicios de autoevaluación............................................................. 103
3.7. Referencias bibliográficas ................................................................. 104
CAPÍTULO 4
FASES DEL DESARROLLO DE SISTEMAS MULTIMEDIA
4.1. Ingeniería del software y multimedia............................................... 110

4.2. Características del desarrollo multimedia........................................ 111
4.3. Las fases del ciclo de vida del desarrollo multimedia ..................... 118
4.4. Modelos de proceso para el desarrollo multimedia......................... 125
4.5. Resumen ............................................................................................. 129
4.6. Ejercicios de autevaluación............................................................... 129
CAPÍTULO 5
ANÁLISIS Y DISEÑO DE SISTEMAS MULTIMEDIA
5.1. La etapa de análisis de requisitos en el desarrollo multimedia...... 136

5.2. La especificación de requisitos en el desarrollo multimedia .......... 137
5.3. La etapa de diseño en el desarrollo multimedia .............................. 145
5.4. Resumen ............................................................................................. 157
CAPÍTULO 6
DISEÑO DE UNA INTERFAZ DE USUARIO
6.1. La interfaz de usuario........................................................................ 163

6.2. Paradigmas de interacción ................................................................ 165
ÍNDICE 9
6.3. Estilos de la interacción .................................................................... 171

6.4. Principios de diseño........................................................................... 174
6.5. Ejemplo de recomendaciones de interacción para un sitio Web de
comercio electrónico.......................................................................... 176
6.6. Uso de la metáfora ............................................................................. 183
6.7. Resumen ............................................................................................. 186
CAPÍTULO 7
EVALUACIÓN DE SISTEMAS INTERACTIVOS
7.1. El concepto de usabilidad ................................................................. 192

7.2. Métodos de evaluación ...................................................................... 199
7.3. El proceso de evaluación ................................................................... 203
7.4. Parámetros para la evaluación de sistemas multimedia ................. 208
7.5. Resumen ............................................................................................. 208
CAPÍTULO 8
DIRECCIÓN Y METODOLOGÍA DE PROYECTOS MULTIMEDIA
8.1. Proyectos .......................................................................................... 216

8.2. Dirección de proyectos .................................................................... 218
8.3. Ciclo de vida ..................................................................................... 226
8.4. Establecimeinto del ámbito ............................................................ 231
8.5. Desarrollo del plan de proyecto ...................................................... 235
8.6. Ejecución del plan de proyecto....................................................... 245
8.7. Monitorización y control del proyecto ........................................... 250
8.8. Cierre del proyecto........................................................................... 253
8.9. Resumen ........................................................................................... 256
CAPÍTULO 9
EJEMPLOS DE DESARROLLO
9.1. Now-Graduado: ejemplo de análisis y diseño .................................. 261

9.2. Ejemplo de evaluación de la usabilidad ........................................... 272
9.3. Resumen ............................................................................................. 279
9.4. Ejercicios de autevaluación............................................................... 279
CAPÍTULO 10
ARQUITECTURA Y CONFIGURACIÓN DE LOS SISTEMAS
MULTIMEDIA
10.1. Arquitectura general de los sistemas multimedia.......................... 286

10.2. Dispositivos y elementos hardware para aplicaciones multimedia .. 288
10.3. Soporte multimedia en los sistemas operativos............................. 293
10.4. Bases de datos multimedia.............................................................. 296
10.5. Redes con soporte específico para aplicaciones multimedia........ 299
10.6. Diseño arquitectónico para sistemas multimedia.......................... 300
10.7. Resumen ........................................................................................... 302
CAPÍTULO 11
INTEGRACIÓN DE LOS SISTEMAS MULTIMEDIA EN WEB
11.1. La arquitectura Web y los sistemas multimedia............................ 310

11.2. Lenguajes Web para los sistemas multimedia ............................... 318
11.3. Algunos tipos de aplicaciones multimedia en la Web ................... 322
11.4. Resumen ........................................................................................... 327
CAPÍTULO 12
LENGUAJES DE PROGRAMACIÓN PARA SISTEMAS MULTIMEDIA
12.1. Herramientas para la programación multimedia .......................... 333

12.2. Uso de lenguajes de propósito específico ....................................... 335
12.3. Uso de lenguajes de propósito general ........................................... 340
12.4. Criterios de selección ....................................................................... 353
12.5. Resumen ........................................................................................... 354
CAPÍTULO 13
HERRAMIENTAS DE AUTOR
13.1. ¿Qué es una herramienta de autor?................................................ 360

13.2. ToolBook II ....................................................................................... 362
13.3. Dreamweaver.................................................................................... 367
13.4. Authorware ....................................................................................... 371
ÍNDICE 11
13.5. La tecnología Flash .......................................................................... 373

13.6. Director ............................................................................................. 377
13.7. Resumen ........................................................................................... 378
13.9. Referencias biblográficas................................................................. 380
CAPÍTULO 14
LENGUAJES DE MARCADO Y DE PRESENTACIÓN
14.1. Lenguajes de marcado genéricos .................................................... 384

14.2. Lenguajes de presentación .............................................................. 397
14.3. Modelado de mundos virtuales utilizando VRML ......................... 399
14.4. Resumen ........................................................................................... 402
CAPÍTULO 15
EJEMPLOS DE DESARROLLO DE SISTEMAS MULTIMEDIA
15.1. Tipos de aplicaciones multimedia................................................... 407

15.2. Presentaciones multimedia y patrimonio cultural: Voces de la
Meseta del Colorado......................................................................... 411
15.3. Telediagnóstico y otros servicios multimedia en medicina: proyecto
EMERALD ........................................................................................ 412
15.4. VIDEOSERVER: Experiencia en la Universidad de Košice.......... 415
15.5. Sistemas de telepresentación y emisión remota de vídeo ............. 417
15.6. Resumen ........................................................................................... 419
ANEXO
SOLUCIONES A LOS EJERCICIOS DE AUTOCOMPROBACIÓN .... 425

PRESENTACIÓN
El término que aparece con mayor frecuencia en los medios de comuni-

cación es «Multimedia». Una de las definiciones tecnológicas para el con-
cepto de multimedia es «la integración de dos o más medios distintos y el
ordenador personal». Los sistemas multimedia constituyen una nueva for-
ma de comunicación que hace uso de diferentes medios como la imagen, el
diseño, el texto, gráficos, voz, música, animación o vídeo en un mismo
entorno. La presentación multimedia facilita utilizar la combinación óptima
de medios para presentar la información en forma atractiva adecuada a
situaciones especificas, manteniendo la atención del usuario y contribuyen-
do significativamente a facilitar y mejorar los procesos de Enseñanza/Apren-
dizaje (E/A). Además, permiten al usuario controlar cómo y cuándo ha de
obtener acceso a esa información. En el multimedia se concentran las diver-
sas aportaciones de cada medio para un único fin: la transmisión de un con-
cepto al usuario.
A través del multimedia se posibilita la realización de un aprendizaje más
interactivo, facilita un entorno hecho a la medida de los usuarios, logrando
que las interfaces sean menos frías, más intuitivas y amigables. Mediante
estos sistemas se obliga al usuario a intervenir en el proceso de transferencia
de información, participando activamente en el mismo.
La interactividad es el nivel de relación y de respuesta mutua entre usua-
rio y medio, es la característica más definitoria de los sistemas multimedia
educativos. Por desgracia, «interactividad» también es uno de los términos de
los que más han abusado los vendedores de equipos informáticos, lo que ha
contribuido a crear cierta confusión de su significado. No pocas veces se han
presentado a bombo y platillo como «interactivos» programas informáticos
que tan sólo posibilitan un nivel mínimo de relación entre el usuario y la
máquina. No se incrementa significativamente la interactividad y la partici-
pación del alumno en la construcción de su aprendizaje porque tenga que
apretar un botón de vez en cuando. Es la característica que les distingue, por

ejemplo, de la imagen en movimiento que combina gráficos, sonido y texto, y
que encontramos en muchos programas de televisión, pero que no invitan al
usuario a tomar decisiones, a responder a preguntas, o a buscar información.
No es posible mantener con ellos una relación recíproca.
Este concepto de multimedia, tal y como hoy se entiende, constituye un
fenómeno relativamente nuevo en la actual sociedad de la información; esto
no debe ser excusa para seguir improvisando diseños o ir saliendo al paso
como cada uno puede de situaciones mas o menos apuradas a la hora de
implementar una aplicación multimedia.
La obra «Sistemas Multimedia: análisis, diseño y evaluación», que tiene
en sus manos, pretende afrontar del reto de formalizar y sistematizar las líne-
as de acción principales de análisis, diseño y evaluación implicadas en toda
aplicación multimedia. Este libro incluye además, como valor añadido, un
tema específico de Dirección y metodología de proyectos multimedia.
Las aplicaciones multimedia serán cada vez mejores si somos capaces de
dar la formación adecuada a los potenciales autores de trabajos multimedia.
Para ello se ha escrito este libro, con la intención de preparar a todas aquellas
personas que de una u otra forman vayan a formar parte de un equipo de cre-
ación de productos multimedia.
Para ello el capítulo 1 comienza pasando revista a la historia de la apari-
ción de las diferentes formas de comunicación, se podrá observar la acelera-
ción vertiginosa que lleva la implantación de estas nuevas tecnologías de la
información. Se pretende dejar bien claro el concepto de multimedia y las
posibilidades que esta ofrece, teniendo siempre en cuenta que el diseño y la
construcción de un proyecto multimedia van de la mano, y que con frecuen-
cia, los mejores resultados son producto de una retroalimentación continua,
así como de modificaciones a lo largo del proceso de producción.
Cuando el flujo de la información, que aparece en la pantalla del ordena-
dor, es controlable por el usuario, se empieza a hablar de hipertexto. En el
capítulo 2 se muestran las bases para la confección de unos buenos sistemas
hipertextuales e hipermediales, se abordan los fundamentos del texto digital.
Se dan los conceptos fundamentales sobre el mundo de la imagen digital y se
presentan los diferentes modos de obtención de imágenes digitales, así como
los principales formatos en los que estas pueden archivarse. A continuación
se muestran los conceptos que proporcionan los fundamentos para poder
comprender el funcionamiento del sonido digital.
Con el estado actual de la tecnología, cualquier usuario con un PC y una
videocámara puede realizar su aportación al mundo de la edición de vídeo.
En el capítulo 3, se presentan los conceptos básicos a tener en cuenta antes
de adentrarse en el mundo de la edición del vídeo digital. También se mues-
tra una ligera iniciación al mundo de la animación 3D. Se trata el proceso de
PRESENTACIÓN 15
modelado, animación, render y composición, y proporcionan algunos conse-

jos sobre la creación de gráficos y animación 3D para el Web.
En el capítulo 4, «Fases de desarrollo de sistemas multimedia», se mues-
tra que no se puede pretender seguir el mismo modelo de proceso que para
todo 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
se ve, entre otros temas, por qué de la utilización de ingeniería del software
en el desarrollo de aplicaciones multimedia.
En el capítulo 5 se profundiza en el análisis de requisitos para sistemas
multimedia así como en la etapa de diseño. Con este fin, se inicia este tema
con el objetivo del análisis, para pasar a continuación a profundizar en los
tipos de requisitos que se pueden encontrar en un sistema multimedia, las
técnicas que pueden emplearse para recolectar información sobre esos requi-
sitos y la manera de plasmar esos requisitos en un documento que pueda uti-
lizarse en el resto de las fases del proceso de desarrollo. El capítulo se cierra
con el estudio de las necesidades de modelado que presentan los productos
multimedia, enfocándolas en seis perspectivas: presentación, estructura,
comportamiento, seguridad, funciones y navegación.
Desde los años ochenta, el diseño de la interfaz de usuario ha ido adqui-
riendo una importancia cada vez mayor en el desarrollo de productos soft-
ware de calidad. En el capítulo 6 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. Tam-
bién 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 elec-
trónico, para finalizar introduciendo el concepto de metáfora.
El objetivo del capítulo 7 será 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 eva-
luació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 el concepto de usabilidad. A continuación, se 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 for-
ma de llevar a cabo la evaluación presentando algunos métodos de evalua-
ción, un proceso genérico para proceder con la evaluación y algunos aspectos
que se pueden medir durante el proceso de evaluación de un producto multi-
media.
Como valor añadido a este libro, en el capítulo 8, se desgranan los con-
ceptos generales de Dirección y Administración de Proyectos de uso total-
mente adaptado al desarrollo de un Sistema Multimedia. Este tipo de desa-
rrollo goza de todas las características que definen un proyecto en su sentido

más amplio y son, por tanto, susceptibles de aplicarse todas las ideas que
aquí se exponen.
En el capítulo 9 se muestran dos experiencias o casos prácticos, en pri-
mer, lugar, el 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 restric-
ciones 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.
En el capítulo 10, se introducirán los elementos arquitectónicos más
importantes desde el punto de vista de las aplicaciones multimedia. Se debe
tener en cuenta que la caracterización de estos sistemas no reside meramen-
te en el soporte de más de un tipo de medio —ya que, desde ese punto de vis-
ta una aplicación con texto e imágenes sería multimedia—, sino en determi-
nadas propiedades relacionadas con la combinación de varios de esos
medios. Se expondrán primero los aspectos generales de las diferentes partes
que configuran la arquitectura de este tipo de sistemas, para terminar con
algunas nociones básicas sobre cuándo y de qué modo debe integrarse el
«diseño arquitectónico» dentro del ciclo de desarrollo de aplicaciones inte-
ractivas.
El capítulo 11 ofrece una visión general de la multimedia en la Web,
comenzando por una revisión de la arquitectura general de la Web, y su ade-
cuación para la multimedia, pasando después a detallar cómo se integra la
multimedia en las aplicaciones Web. Se termina con una revisión de algunos
de los tipos de aplicaciones multimedia más relevantes en este entorno.
En el capítulo 12 se describen los rasgos generales de las opciones exis-
tentes y algunos criterios de selección, y se profundiza en el concepto de len-
guaje de programación específico para la multimedia, tomando como caso
concreto el del lenguaje ActionScript. También se ilustra el uso de lenguajes
de programación de propósito general con una visión panorámica de las
bibliotecas que el lenguaje Java proporciona para el desarrollo de funcionali-
dades multimedia.
El capítulo 13 analiza las herramientas de autor para productos multi-
media. Obviamente, dado el ingente número de herramientas existentes en el
PRESENTACIÓN 17
mercado, no se pretende elaborar un catálogo de la mismas, sino que se ha

optado por presentar algunas que se han considerado bastante representati-
vas y difundidas. El capítulo se inicia con una breve introducción al concep-
to de herramienta de autor, en el que se comentan clasificaciones de las mis-
mas, ya sea atendiendo al modelo de información o metáfora que asumen, ya
sea atendiendo al paradigma de creación de aplicaciones que ofrecen. A con-
tinuación se describirán algunas herramientas de autor como son ToolBook,
Dreamweaver, Authorware, herramientas que soportan la tecnología Flash o
Director.
En el capítulo 14 se presentan un conjunto de lenguajes de marcado que
se utilizan habitualmente en los entornos Web y algunos lenguajes de pre-
sentación que permiten adaptar la presentación de la información contenida
en esos documentos. Además, y para finalizar, se presenta VRML como len-
guaje de modelado que permite la definición de mundos virtuales que permi-
ten al usuario navegar por la información en tres dimensiones.
Y finalmente, en el capítulo 15 se describen ejemplos de desarrollo de sis-
temas multimedia concretos, con el objetivo de ofrecer una panorámica de
los métodos, técnicas y herramientas de desarrollo que pueden utilizarse.

Capítulo 1
MULTIMEDIA Y COMUNICACIÓN.
SISTEMAS MULTIMEDIA
ESQUEMA
1.1. La comunicación a distancia.

1.2. La revolución de las comunicaciones. Internet.
1.3. Sistemas y procesado de la información: Informática.
1.4. El concepto de multimedia.
1.5. Sistemas multimedia tradicionales.
1.6. Sistemas multimedia actuales.
1.7. Ventajas e inconvenientes de los multimedia.
1.8. Recomendaciones a tener en cuenta en el diseño de un proyecto mul-
timedia.
1.9. Resumen.
1.10. Ejercicios de autoevaluación.
1.11. Referencias bibliográficas.
El interés que hoy en día despierta en la sociedad todo lo relativo a las
nuevas tecnologías de la comunicación, los sistemas multimedia e Internet,
así como el inmenso abanico de oportunidades que ahora se abre, es conse-
cuencia del rápido progreso de las tecnologías de las telecomunicaciones y de
la informática, así como, del masivo uso y abaratamiento de los ordenadores
personales.
Hoy en día a nadie sorprende la posibilidad de encender el ordenador y a
través del mismo, utilizando las superautopistas de la información, realizar
las tutorías de los alumnos de la UNED viendo en tiempo real la cara del pro-
fesor, escuchando su voz, y al mismo tiempo permitir el intercambio de pro-
blemas y ejercicios o la resolución de la última prueba presencial, del último
examen, para los que no estén habituados a la terminología específica que se
utiliza en la UNED.
En el primer capítulo de este libro, antes de abordar las posibilidades y limi-
taciones que estas tecnologías ofrecen, se va a hacer un poco de historia y mos-
trar como se ha llegado a este punto, secciones 1.1 a 1.3. Se podrá observar la
aceleración vertiginosa que lleva la implantación de estas nuevas tecnologías.
Así mismo, en las secciones 1.4 a 1.8 se pretende dejar bien claro el con-
cepto de multimedia y las posibilidades que esta ofrece, teniendo siempre en
cuenta que el diseño y la construcción de un proyecto multimedia van de
la mano. Aunque un proyecto multimedia no es más que la combinación de
texto, gráficos, sonido y elementos de vídeo. Con frecuencia, los mejores
resultados son producto de una realimentación continua, así como de modi-
ficaciones a lo largo del proceso de producción.
1.1. LA COMUNICACIÓN A DISTANCIA
1.1.1. Las primeras telecomunicaciones
La necesidad de las comunicaciones a distancia es tan antigua como la

historia del hombre, un rápido viaje por la historia permitirá comprender
como los cambios tecnológicos provocan modificaciones sociales, y vicever-

sa. Cuando la sociedad se decide a introducir un cambio, se necesita desa-
rrollar una nueva aplicación tecnológica. Y a veces una nueva aplicación tec-
nológica, produce un cambio social.
La primera forma de comunicación a distancia que se conoce, después
del habla, o hablando con más precisión, del grito, ha sido la utilización del
fuego en la noche o el humo en el día, o, en zonas donde la visibilidad era
muy reducida, la utilización de señales acústicas, como el célebre «tam-tam»
africano.
De esta manera existen multitud de ejemplos que ilustran estas prácticas,
así, ya Homero en la Ilíada habla del fuego para señalar la llegada de una flo-
ta venida a socorrer a los sitiados de Troya. O en épocas más recientes y con
una significación muy especial para los españoles, están las señales de fuego
que utilizaron los ingleses para avisar de la llegada de la mal llamada Arma-
da Invencible en 1588.
Otras veces, la información, o la velocidad de su transmisión dependía de
la velocidad del mensajero, así el envío de palomas mensajeras, o la célebre
transmisión de la victoria griega en Maratón en el 490 a. C.
De esta forma, surgirá otra forma de comunicación, la del envío de men-
sajeros, correos, desde los reales de la Edad Media, hasta los envíos que habi-
tualmente realiza la UNED a sus miles de estudiantes.
Sin embargo, el envío de correos, sea sobre papel, papiro o de palabra, ya
sea a caballo, en tren, coche o en avión, poco va a avanzar en el curso de la
historia, si no es por el avance de los medios de comunicación. En definitiva,
en donde se van a producir los avances más espectaculares y que van a cam-
biar el mundo, es con los modernos medios de comunicación a distancia o
telecomunicación (Peire, 2001).
1.1.2. El telégrafo óptico
Así, después de las señales luminosas, se produce ya entrado el siglo XVIII

el primer telégrafo, que, pese a lo que la gente puede pensar, no es el de Mor-
se, sino el sistema óptico de Claude Chappe. Éste, se componía de una torre
con tres brazos articulados, y por combinaciones de las posiciones de los mis-
mos, reproducía letra a letra un mensaje. Algo muy similar a las indicaciones
que se utilizan en los códigos de banderas en los barcos.
Este sistema inevitablemente debía disponer de torres situadas en las
zonas más altas de la orografía de la zona. En cada torre debía existir un emi-
sor (el que realizaba las señales) y de un receptor (otra persona provista de su
correspondiente catalejo que debía interpretar las señales). De esta manera, y
de torre en torre se lograba transmitir un mensaje. Como es lógico y puede
MULTIMEDIA Y COMUNICACIÓN. SISTEMAS MULTIMEDIA 23
suponerse, para transmitir un mensaje, que necesariamente debía ser corto,

se requería tal cantidad de medios materiales y humanos que solo podían
estar al alcance de los Gobiernos, y para noticias relacionadas con la guerra,
así el primer despacho que se realizó el 15 de agosto de 1794, cubriendo una
distancia de 230 km entre París y Lille anunciando 1a reconquista de Quesno
por las tropas de la República (Peire, 2001).
1.1.3. El telégrafo de señales eléctricas
Después del desarrollo de estos sistemas ópticos, que desde luego no fun-
cionaba muy bien, en los países más septentrionales de Europa como Ingla-
terra y Suecia, se comprendió la necesidad de buscar un método de comuni-
cación a distancia que no dependiera de las condiciones de visibilidad de la
zona, y para ello se recurrió a la electricidad, con lo cual, se acercan a las tec-
nologías que actualmente imparte el Departamento de Ingeniería Eléctrica,
Electrónica y de Control de la UNED.
Uno de los primeros experimentos que se realizaron fue en Aranjuez. El

sistema consistía en transmitir señales eléctricas al operador, el cual en fun-
ción de la intensidad y del sitio donde se le aplicaban las descargas eléctricas
identificaba las letras. Afortunadamente, y sobre todo para el gremio de los
telegrafistas este sistema no llegó a popularizarse, aunque sí funcionó con
éxito entre Madrid y Aranjuez.
Cuesta imaginar, lo que sería hoy día transmitir la información a distan-

cia, en una experiencia como las que habitualmente se realiza en la UNED,
realizando descargas eléctricas sobre nuestros alumnos para poderles trans-
mitir «nuestras enseñanzas a distancia».
Pero será en el año 1837 cuando se va a producir un avance significativo

en la transmisión de la información. En estas fechas aparece Morse, el cual
propone un telégrafo distinto al óptico. Utiliza en vez de señales ópticas,
señales eléctricas, pero no aplicadas sobre el operador, sino sobre un disposi-
tivo que marca o perfora una cinta de papel. La forma de transmitir la infor-
mación es muy sencilla: un código digital que posteriormente se hará suma-
mente popular, consiste en transmitir únicamente dos tipos de caracteres,
puntos y rayas. Este sistema rápidamente goza de una amplia aceptación. Sin
embargo, la dependencia de un soporte físico para su transmisión hacia nece-
sario buscar otros medios, sobre todo después de que tras la inauguración de
lo que se puede considerar la primera línea marítima entre Gris-Nez en Fran-
cia y Southerland en Inglaterra, y tras grandes esfuerzos para tender un cable
que uniera Francia e Inglaterra, el servicio tuvo que ser suspendido a los
pocos días, porque un pescador se enganchó con el cable y cortó un trozo
para enviarlo como prueba de haber encontrado una nueva especie de alga
que contenía oro en su interior (Peire, 2001).
1.1.4. La radio y el teléfono
El siguiente paso estaba cantado, lo que la sociedad demandaba era

poder transmitir información sin necesidad de un soporte físico, es decir,
conseguir la telegrafía sin hilos, sería Guillermo Marconi quien lo haría posi-
ble, por lo que obtuvo el premio Nobel de Física en el año 1989, a la edad de
45 años.
Una vez explicado cómo nacieron el correo y el telégrafo, el siguiente
paso que la Sociedad ya demandaba era el transmitir el habla a distancia.
Paradójicamente, lo que se buscaba en aquella época no era tanto la
transmisión del habla, sino la posibilidad de enviar más de una comunica-
ción sobre un mismo cable utilizando el código Morse.
Fue el 14 de febrero de 1876, cuando Alejandro Graham Bell patentó su
invento del teléfono. Lo que no todos los historiadores cuentan es que E.
Gray realizó una patente del teléfono sólo dos horas después, y lo que aún
menos cuentan los historiadores es que el dispositivo que utilizó Bell al reali-
zar su famosa conexión de «Dr. Watson venga aquí, le necesito», la realizó
según un dispositivo similar a las patentes de Gray y distintas a las descritas
por él en sus patentes.
En 1886 funcionaban en España tres redes exclusivamente urbanas per-
tenecientes a tres compañías privadas que operaban en Barcelona con 602
abonados, en Madrid con 364 y en Valencia con 64. Los precios prohibitivos,
rondaban los 3 euros anuales. En 1924 se constituye la CTNE con capital y
tecnología de la ITT. Bajaron las tarifas y en diez años se multiplicó el núme-
ro de abonados llegándose a los 343.092. Para poner de manifiesto la «lenti-
tud» con la que se desarrolla el teléfono basta decir que se necesitará casi un
cuarto de siglo para que en 1947 se instaurare el primer servicio telefónico
entre Madrid y Nueva York (Peire, 2001).
1.1.5. La televisión
Falta la TV. Lo que poca gente sabe hoy, es que los primeros televisores
que existieron fueron mecánicos, y funcionaban con un principio de funcio-
namiento que se puede considerar idéntico al de las actuales TV. Estaban for-
madas por un disco con pequeños taladros dispuestos sobre una trayectoria
espiral. De esta manera por cada revolución del disco se trazaban por toda la
imagen tantas líneas de barrido como agujeros tuviera el disco. Este princi-
pio de barrido, con muy pocas diferencias, se sigue realizando hoy, eso sí, con
procedimientos totalmente electrónicos. Estas patentes datan de 1884.
La primera demostración pública de una TV fue en 1925 en Londres. Cua-
tro años más tarde comenzaba a emitir la célebre BBC. Incluso en 1928 se
transmitió con la TV en color, por supuesto ¡también mecánica! En 1937 la

BBC normalizó la utilización del sistema electrónico.
En España las emisiones televisivas se inician en 1948 con la transmisión
desde el Stand de Phillips Ibérica en la Feria de Muestras de Barcelona, sin
embargo todavía transcurrirán ocho años para el primer servicio de TVE.
Concretamente fue el 28 de octubre de 1956, hace algo mas de cuarenta años
desde esa primera transmisión televisiva.
A los tres meses había 3.000 madrileños con TV. Tres horas de emisión
diaria de 9 a 12 de la noche. Un alcance de 70 km, y más de 50 empleados.
En 1957, después de las vacaciones de agosto, vacaciones que por supues-
to se tomaba la TV española, aparece un compañero inseparable hasta nues-
tros días, el Telediario. En 1971 se televisa en España el primer programa de
televisión en color que como no podía ser menos, era una corrida de toros.
Cuatro años más tarde el 20% de las emisiones era en color. A finales de los
70 se calcula que el 93% de los españoles tenía TV, y la media de televisores
por familia es, hoy día, superior a la de teléfonos fijos (Peire, 2001).
1.1.6. La electrónica al servicio de la comunicación
Queda por explicar la parte electrónica, cómo y cuándo nace la electró-

nica y el ordenador, que cambiaron decisivamente la tecnología de las comu-
nicaciones, siendo hoy día impensable la existencia de una radio, una televi-
sión o telecomunicaciones sin electrónica, aunque y como se ha visto
nacieron sin necesidad de la electrónica, y con un funcionamiento, que
como la TV mecánica son totalmente similares, por no decir idénticas a las
actuales de la TV.
A comienzos del siglo XX hicieron su aparición las válvulas de vacío, que
hicieron posible la amplificación electrónica y las radios de «nuestras abue-
las», los partes de guerra, los radares, etc. Sin embargo esta electrónica de
válvulas no hubiera podido realizar lo que se puede considerar la mayor revo-
lución industrial y sociológica desde los tiempos de la máquina de vapor.
En diciembre de 1947 aparece el transistor. Cuando se publican apenas
unas líneas en la última página del New York Times del 1 de julio de 1948,
haciendo referencia a él, nadie le dió importancia. Al fin y al cabo, Yury Gaga-
rin catorce años después volaría al espacio guiado por una electrónica en
base a las válvulas.
Sin embargo, el nacimiento de lo que se denomina electrónica de estado
sólido, y el boom que iba a propiciar, no había hecho más que empezar.
En 1964 aparece el primer circuito integrado, en 1971 el primer micro-
procesador (el corazón de un ordenador) y en la década de los 80 empiezan a
popularizarse los PCs (ordenadores personales). Sin embargo, socialmente

todavía no se vislumbran los grandes cambios que se avecinan.
Nuevamente, la gente del siglo XX está acostumbrada a los cambios tec-
nológicos y no se vislumbra el tremendo impacto social que se viene encima.
¿Dónde está el cambio del microprocesador, si en 1969 se pudo llegar a la
Luna sin él? Donde se podría englobar la famosa frase de Neil Alden Arms-
trong cuando alunizó y pronunció lo que hoy día son palabras que han pasa-
do a la historia «Un pequeño paso para el hombre y un paso gigante para la
Humanidad». Con este hito se cumplía uno de los más viejos sueños de la
Humanidad.
Sin embargo, no es hasta finales de la década de los 80 cuando el boom de
los ordenadores personales hace presagiar un nuevo conjunto de aplicacio-
nes que van a implicar un profundo cambio en las relaciones sociales.
En este epígrafe se ha analizado sucintamente la historia, corta en el
tiempo pero vertiginosa en cuanto a transformaciones tecnológicas y sociales
provocadas por las nuevas posibilidades que ofrecen las telecomunicaciones,
unidas a la auténtica locomotora del cambio que es la industria microelec-
trónica (Peire, 2001).
1.2. LA REVOLUCIÓN DE LAS COMUNICACIONES. INTERNET
Si se analizan hoy día los periódicos aparecen casi a diario referencias a

una nueva palabra mágica, «Internet». EL PAIS en su editorial dominical del 13
de octubre de 1998, publicaba «Internet y la Ley», el dominical del ABC (la
revista Blanco y Negro), también en ese mismo día publica «Los robots han
muerto, llegan los knowbots», seres cibernéticos virtuales que tienen como
misión imposible navegar por la red Internet en busca la información que nece-
sita su amo. En otras palabras los modernos YAHOO, OLÉ, GOOGLE, etc.
La historia de Internet como casi todas las descritas hasta estos momen-
tos se inicia con las aplicaciones que se derivan de desarrollos estratégicos de
las guerras. La idea de Internet la lanza el Departamento de Defensa Ameri-
cano. Su objetivo, es garantizar la comunicación de los principales centros
operativos americanos en caso de que ocurriera una catástrofe nuclear. A
mediados de los 60, en plena guerra fría, había que garantizar que si una
cabeza nuclear destrozaba gran parte de las instalaciones militares de un
Estado, el resto de las comunicaciones entre centros operativos pudieran
mantenerse en pie.
En 1969 comienza su operación ARPANET (Advance Research Projects
Agency-Net del Departamento de Defensa Americano). Los nodos principales
estaban ubicados en cuatro universidades americanas, las universidades cali-
fornianas de UCLA, Stanford, Santa Bárbara y la Universidad de Utah.
A partir de esta fecha se suceden los cambios de denominación y los usos

de esta red siendo ya «historia» el comienzo del funcionamiento en 1979 de
USENET (User Network), en 1981 de CSNET (Computer Science Network) y
de BIT NET. En 1983 se separa MILNET de ARPANET buscando trabajos y
aplicaciones más científicas. En 1987 se inician los servicios comerciales de
UUNET (Unix to Unix Copy Program protocol). El siguiente hito y ya muy
reciente, es la práctica absorción en 1990 de ARPANET por parte de NSF-
NET (National Science Foundation).
El establecimiento de esta red, que ha vuelto a propiedad privada en
1995, ha propiciado, el predominio a nivel mundial de la red de Internet: la
red de redes nacida y desarrollada en el ámbito de las universidades ameri-
canas y con fines inicialmente militares.
Si se recurre a aplicaciones o programas para optimizar y sacar recursos de
la red Internet, los años en los que aparecen estas aplicaciones son aún más
impresionantes. El correo electrónico eclosiona a mediados de los 70 (en USA), a
comienzos de los 90 los programas conocidos como Archie, Wais, Goopher (estos
productos ya salen prácticamente de una manera simultánea en todo el mundo).
En 1992 la WWW (World Wide Web), en 1993 Mosaic, en 1994 Netscape.
En 1995 VRML y Java y a partir de 1996 las conocidas y cada vez más utili-
zadas Intranet.
Hasta aquí se ha puesto de manifiesto la vertiginosa velocidad de cambio
de estas nuevas tecnologías, que sin duda alguna están influyendo de manera
decisiva en los cambios sociales y políticos en el ámbito mundial, y que el
concepto inicialmente quimérico para muchos de la «Aldea global» empiece
a hacerse día a día una realidad tangible (Colmenar, 1999a).
1.3. SISTEMAS Y PROCESADO DE LA INFORMACIÓN:

INFORMÁTICA
Hace sólo 20 años no existía el miniordenador ni las actuales redes de comu-
nicación. El cambio es tan rápido que se puede aventurar que en dos años los
equipos se vuelven obsoletos, y si se pierde el carro de estos avances, se está en
riesgo de obsolescencia. La situación es de una auténtica tiranía tecnológica.
El reto de los sistemas informáticos está en que pueden llegar a ser una
herramienta de apoyo a las empresas y a la mejora de las condiciones de tra-
bajo y de las condiciones de vida.
Las barreras existentes, como una presa ante una riada, serán superadas.
Quizá la postura de abrir compuertas sea la que más facilite el discurrir del río.
Sin embargo, la penetración de las nuevas tecnologías de comunicación,
presenta una característica muy importante. Los tiempos en que se empiezan a
utilizar socialmente los nuevos avances, cada vez son más cortos. Si no, y como
muestra piénsese que desde que se patentó el teléfono en 1876 hasta que se rea-
lizó la primera conexión entre Madrid y Nueva York, 1947, pasaron 69 años.
Desde la primera demostración pública de la TV en Inglaterra en 1925,
pasaron 23 años hasta la primera demostración en España.
Desde que NSFNET absorbe a ARPANET, iniciando tímidamente lo que
puede denominarse el «boom» de Internet hasta hoy día que ya es una reali-
dad consolidada en España, han transcurrido menos de diez años. Es más, la
mayoría de las aplicaciones, programas, etc., se suelen lanzar, comercial-
mente hablando, de manera simultánea en todas las partes del mundo.
Es por ello por lo que se puede estar seguro del futuro y el auge que a tra-
vés de esta nueva tecnología, la unión de los PCs y las super-autopistas de la
información van a revolucionar, ya lo están haciendo, aspectos estructurales
de nuestra sociedad y sobre todo serán un fundamental elemento de cambio
en la manera de entender en un futuro muy cercano la tele-enseñanza y todo
esto, aunque paradójicamente, en un mundo donde la mitad de la población
todavía no ha realizado su primera llamada telefónica.
Llegados a este punto parece obligado encontrar un nexo de unión en
todas las tecnologías de la comunicación. ¿Qué tienen en común los trabajos
de Gutemberg con la invención del teléfono o del transistor? Pues bien en
época reciente todas estas tecnologías están basadas en el procesado masivo
de la información, información en el sentido que todo el mundo entiende:
libros, artículos periodísticos, leyes, cartas, escritos hablados o en vídeo, etc.,
engloban las llamadas ciencias de la información.
Las Ciencias de la Información se encuentran relacionadas con los proce-
sos de almacenamiento, transferencia, recuperación, y tratamiento de la
información. Intentan conjuntar disciplinas tan variadas como las ciencias
de la computación, la lingüística, la cibernética, y otras ciencias que ayuden
a los procesos de recuperación, gestión, almacenamiento y control de la
información (Peire, 2001).
Las raíces de las ciencias de la información yacen en tres desarrollos fun-
damentales acaecidos durante la segunda guerra mundial: los desarrollos de
Shanon-Weaver, las teorías de Norbert Wiener y el rápido desarrollo de los
ordenadores de silicio (principalmente los ordenadores personales) ocurri-
dos a partir de los años 70 .
1.4. EL CONCEPTO DE MULTIMEDIA

El concepto de multimedia ha evolucionado en los últimos años. Hoy se
puede afirmar que ha adquirido un nuevo significado más preciso y menos
ambiguo y general. A continuación, se analiza la delimitación conceptual del
vocablo multimedia y su evolución desde varias múltiples perspectivas:

empresarial, etimológica, mediática, informática e integradora de lenguajes.
1.4.1. Perspectiva empresarial
Para autores centrados en la temática de los Medios de Comunicación de

Masas (prensa, radio, cine y televisión), hablar de multimedia, desde una
perspectiva empresarial, significa referirse a una actividad en la que partici-
pan o se integran varios de estos medios. Por eso hablan de «empresas o gru-
pos multimedia» que se mueven en el ámbito de varios medios (Colmenar,
1999b).
1.4.2. Perspectiva de la pluralidad mediática
La pluralidad mediática al hablar de multimedia, destaca la literalidad

del significado etimológico. Cada vez que se utiliza más de un medio, lo deno-
minan «Multimedia» o suma de medios, pues etimológicamente su significa-
do es claro y parecería lejos de originar ningún debate: Multi-Media =
Muchos Medios.
1.4.3. Perspectiva informática
En muchos catálogos de productos informáticos se encuentra el vocablo

Multimedia referido al hardware que permite intercambiar datos entre dis-
tintos ordenadores. Productores de software describen también con ese tér-
mino paquetes en los que combinan textos y gráficos con animación en una
misma pantalla. La palabra multimedia se ha convertido para las empresas
de hardware y software en un elemento imprescindible en el márketing
actual de sus productos.
1.4.4. Perspectiva contemporánea
En las últimas reuniones nacionales e internacionales, así como en Con-

gresos de expertos sobre el tema, se define en un sentido estricto el concepto
de multimedia afirmando que
«multimedia es un sistema que facilita todo el material de equipo y de pasos

necesarios con el fin de combinar imágenes fijas y en movimiento —inclu-
yendo vídeo, imágenes fotográficas, gráficos y animación— con sonido, tex-
tos y datos generados por ordenador y programas de ordenador. Toda la
información de un programa multimedia —sonido, imágenes, textos y
datos— puede grabarse en un solo soporte, generalmente un disco óptico».
1.4.5. Sistemas multimedia como integración de lenguajes

Uno de los aspectos que se encuentan en cualquier sistema multimedia
correctamente diseñado es la integración de lenguajes. No se trata de una sim-
ple superposición o adición de imagen, sonido, etc., sino de un cuidado proceso
en el que se crea un producto audiovisual donde se hallan las potencialidades
expresivas y artísticas de varios lenguajes. La integración supone que el diseña-
dor y productor tienen un concepto definido de la imagen icónica y de la ima-
gen sonora, unidas por un ritmo interno y externo. En el multimedia, el mensa-
je se hace más complejo en su diseño y realización, para que pueda ser mejor
entendido. Es el sonido, con frecuencia, el que da las pautas de comprensión
tanto de las imágenes individuales como de las secuencias. Y cuando se habla de
sonido se incluyen las cuatro facetas fundamentales de todo mensaje audio:
palabra, música, efectos y silencios. Son también importantes la variedad de
voces y los matices expresivos que se consiguen con una locución adecuada.
Sería deseable la definición (acordada por parte de quienes trabajan e
investigan en este campo) de un modelo para el diseño de hiperdocumentos
que sea general, abstracto, consistente y seguro, y que ofrezca soluciones al
acceso, creación y modificación de la información.
DEFINICIÓN: Diferentes individuos y grupos están usando los términos que describen
una idea de una forma clara para su propio pensamiento. Pero entre los grupos, la idea
y los significados asociados con ese término, varían considerablemente. Por ello es nece-
sario dejar claros aquí los conceptos de estos términos.
• Multimedia es la integración de todas las formas de comunicación y de presentar la
información (se puede presentar en forma de textos, imágenes, sonido y vídeo).
• Hipermedia es el conjunto de componentes lógicos que se emplean en multimedia.
En esencia, los logicales o programas que se emplean para la multimedia.
• Hipertexto es un texto en el que partes del mismo están conectadas con una base
de datos o/y imágenes.
• Navegar es acceder por los distintos nodos a las partes del programa. Se presen-
ta la información de una forma aleatoria, en lugar de secuencial.
1.5. SISTEMAS MULTIMEDIA TRADICIONALES

Bajo esta denominación se agrupan una serie de sistemas como son: el
diaporama, como primer multimedia, la multivisión, los paquetes instructi-
vos y los laboratorios de idiomas.
1.5.1. El diaporama como primer multimedia

Cuando se habla de diaporama se hace referencia a algo más que un «mon-
taje de diapositivas sonorizadas», o un «montaje sonoro ilustrado con diaposi-
tivas», ambas posibilidades también interesantes y con numerosas aplicacio-

nes didácticas. Algunos autores definen el diaporama como:
«un medio de comunicación grupal, abierto, que une diferentes medios de
expresión: imágenes, palabras, música, ruidos, diálogos, silencios, poesía,
narración y ritmo, con una unidad estética y significativa. La clave del dia-
porama reside en la conexión de los lenguajes que no deben estorbarse, ni
ser redundantes».
Hace años recibían nombres inapropiados como son: «Fotomontaje» (el

vocablo se refiere a la manipulación de fotografías, propia de las publica-
ciones escritas). En algunos países latinoamericanos lo llaman «Diapofilm»
o «Sonoviso». También se le denomina «Montaje audiovisual», «Audiovi-
sual» o «Diapocinta». La carencia de un nombre claro estable ha sido tal
vez, una de las causas del desconocimiento del diaporama. En el diaporama
se integran varios medios: el sonido (es la creación física del ambiente, del
movimiento y del ritmo), la palabra (da fuerza y claridad conceptual, rigor
formal y concreción) y la imagen (concretiza visualmente, evoca y sugiere).
La elaboración de un diaporama con los alumnos es una actividad senci-
lla y de grandes resultados formativos para el grupo de alumnos que la reali-
za. Puede realizarse con alumnos con un mínimo de 10 años, incluso menos.
La calidad técnica, aunque es importante, es menos decisiva que el «proceso»
de creación-realización. Si el resultado va a ser visionado sólo por la clase del
grupo realizador, como es lo habitual, las carencias técnicas, incluso los erro-
res y los fallos, son «comprendidos» por todos. A continuación, se distinguen
algunas fases de su realización:
1. Planificación o idea inicial (se escoge el tema o idea central).
2. Redacción del guión (se parte de una sinopsis, resumen del contenido
del diaporama).
3. Selección de las diapositivas. Se elegirán fotos simbólicas o foto-repor-
tajes.
4. Preparación del sonido (voces adecuadas, elección de la música, rui-
dos y efectos necesarios, etc.).
5. Grabación del sonido.
6. Comprobación de la grabación y del ritmo imagen/sonido.
7. Evaluación y correcciones, si es preciso.
Es importante que el docente sepa utilizar adecuadamente el diaporama,
para conseguir todos sus efectos pedagógicos. En este sentido son aconseja-
bles las siguientes recomendaciones:
a) Antes de la proyección: Preparar los elementos técnicos de proyec-
ción y sonido, pantalla, oscurecimiento de la sala, etc. Ambientar al
grupo y situar el contexto.
b) Proyectar el diaporama sin cortes ni interrupciones.

c) Después de la proyección: Facilitar la expresión e intercomunica-
ción del grupo, facilitar el descubrimiento del mensaje expresado, rea-
lización de distintas actividades: dibujo, expresión corporal, cartel,
etc.
Hoy la filosofía del medio tiende cada vez más a apearse de la pantalla y
alojarse en soportes tridimensionales, ambientes y recintos imaginarios pro-
gramados a base de luces, colores, rayos láser, vídeos, autómatas, etc. La tec-
nología ha hecho que la multivisión crezca en extensión y evolucione rápida-
mente.
1.5.2. Multivisión
En la Feria Mundial de Bruselas de 1958 se presentaron por primera vez

dos espectáculos de multivisión en los pabellones holandés y checo, basados
en la proyección simultánea y sincronizada de películas de cine. Años des-
pués, en la Exposición Universal de Sevilla, en casi todos los pabellones podí-
an encontrarse presentaciones de multivisión. Uno de los espectáculos de
más éxito en la Expo 92 fue el programa Audiovisual del Lago, donde se
incorporaron algunos de los últimos adelantos técnicos de la multivisión.
Hoy en día, no se concibe una exposición, una feria, una convención impor-
tante, etc., sin un programa de multivisión, que también se denomina Multi-
pantalla, Multi-imagen, y Multiproyección.
La característica principal de la multivisión es la espectacularidad de
su presentación, que proporciona abundante información junto con un
impacto expresivo. El espectáculo multivisión está más próximo a las leyes
de la música, donde sólo cuenta la perfección interna, como la variación,
el contraste o la repetición. La aportación técnica de la multivisión reside
en la utilización de grandes pantallas en las que se proyectan imágenes
(casi siempre fijas) procedentes de varios proyectores coordinados por un
ordenador, mientras se incorpora a la comunicación un mensaje sonoro,
generalmente estéreo. La sensación de movimiento se consigue intercam-
biando imágenes estáticas con rapidez y ritmo, jugando con el impacto del
mosaico icónico.
Las presentaciones multivisión son controladas mediante un microorde-
nador. Un codificador transforma las órdenes del software a su propio códi-
go de datos. Las unidades de control de programación y proyección, desgra-
ciadamente no están estandarizadas y son entre sí incompatibles, excepto el
sistema sueco Dataton que lee AVL, Electrosonic y Arion. Este hecho ha difi-
cultado la popularización de este medio. El inconveniente de la multivisión
ha sido siempre lo laborioso de su ejecución y lo aparatoso de la maquinaria.
La entrada de los sistemas informáticos ha simplificado la infraestructura y
ha aumentado las prestaciones, pero la multivisión está más cerca del espec-
táculo que de la didáctica.
1.5.3. Paquetes instructivos
Los «paquetes instructivos», también denominados «paquetes autodidác-

ticos», «paquetes multimedia» y «documentos integrados», tienen su origen
en los primeros trabajos de enseñanza programada, donde se perseguía faci-
litar al alumno y al profesor materiales de autoaprendizaje que sirvieran para
potenciar el aprendizaje independiente del alumno. Combinan recursos
variados y complementarios como, diapositivas, grabaciones de audio y
vídeo, programas informáticos, textos, etc.
Actualmente los paquetes instructivos han alcanzando progresivos niveles de
desarrollo. La documentación de la Reforma Educativa, referente a cualquier
nivel, insiste en la importancia de los recursos didácticos y en facilitar elementos
de aprendizaje personal a los discentes. Siguiendo a la pedagogía constructivis-
ta, promueve un aprendizaje por descubrimiento, para el que es preciso contar
con elementos y apoyos materiales. Contar en un aula con estas ayudas, facilita
el aprendizaje y la actividad personalizada de los alumnos. Tanto el Ministerio de
Educación, Cultura y Deporte (MECD) como distintos grupos editoriales traba-
jan para que se disponga de materiales de aprendizaje multimedia. Son, pues,
paquetes instructivos pensados y diseñados para reforzar el proceso de enseñan-
za/aprendizaje (E/A) a base de recursos didácticos multimedia.
El creciente desarrollo de la enseñanza a distancia ha potenciado los
paquetes instructivos. En el Tratado de Maastricht se ha insistido en que una de
las prioridades europeas de enseñanza es la enseñanza a distancia. Se prevé un
aumento notable en todos los países de esta metodología de aprendizaje en la
que están presentes tanto entidades públicas como privadas. Los paquetes ins-
tructivos facilitan que el estudio personal sea variado y se potencie su eficacia.
Los mensajes se transmiten utilizando varios canales y con distintos niveles de
redundancia verboicónica. El alumno recibe estos paquetes de aprendizaje con
recursos plurales a los que puede acceder desde diferentes equipos técnicos y
en distintas condiciones ambientales. Entre las ventajas de utilización de los
paquetes didácticos multimedia, se destacan (Castro y otros, 1996):
a) Facilitan la enseñanza individualizada y el aprendizaje activo.
b) Proporcionan una enseñanza modular adaptable.
c) Ahorran tiempo a profesores y alumnos.
d) Facilitan la evaluación.
En la tabla 1 se refleja de forma esquemática, las líneas de acción princi-
pales de diseño de un paquete instructivo multimedia.
TABLA 1.1. Líneas de acción principales de diseño de un paquete instructivo multimedia
1. Aprendizaje de las posibilidades técnicas y didácticas de los medios a usar.

2. Elección del tema y su aplicación.
3. Preparación del proyecto.
4. Análisis (objetivos, tareas de aprendizaje, etc.).
5. Diseño de lo que hay que enseñar, su secuencia, medios empleados y líneas de
evaluación.
6. Comprobación del diseño del paquete instructivo.
7. Desarrollo de guiones de textos, audio, imagen, vídeo.
8. Evaluación formativa de la preproducción.
9. Producción del material: textos, audio, imagen, vídeo.
10. Comprobación con grupo el piloto y evaluación.
11. Producción definitiva.
12. Implantación.
13. Revisiones periódicas y puesta al día.
1.6. SISTEMAS MULTIMEDIA ACTUALES

El concepto de multimedia ha evolucionado hasta llegar, en la actualidad, a
un sistema que facilita la combinación interactiva de imágenes fijas y en movi-
miento, sonido, textos, gráficos, animación, etc., coordinados por un ordenador,
generalmente con soporte de disco óptico. Uno de los primeros multimedia, den-
tro de esta línea conceptual, ha sido el Videodisco Interactivo, que une la capaci-
dad de memoria del ordenador y la imagen en movimiento con sonido del vídeo,
combinando textos, gráficos, etc. Hoy existen numerosas plataformas multime-
dia, que se diferencian entre sí por cuatro características (Castro y otros, 1999):
a) Capacidad de memoria.
b) Capacidad de audio, vídeo y gráficos.
c) Sistemas de presentación.
d) Estándares técnicos predominantes.
Éstas trabajan con distintos formatos, entre los que destacan:
a) CD-DA (Compact Disk-Digital Audio) o Disco Compacto-Audio Digital.
b) CD+G (Compact Disk Plus Graphics) o Disco Compacto más gráficos.
c) CD-ROM (Compact Disk-Read Only Memory) o Disco Compacto-
Memoria de sólo lectura.
d) CD-V (Compact Disk-Video) o Disco Compacto Video.

e) IV (Interactive Video) o Vídeo Interactivo.
f) CD-I (Compact-Disk Interactive) o Disco Compacto Interactivo.
g) DVD (Disco Vídeo Digital).
El Compact Disk Interactive (CD-I), iniciado por Philips y desarrollado
con Sony y Matushita, parecía ser una de las plataformas con más posibili-
dades. Integra en un solo soporte de gran capacidad todos los datos, textos,
gráficos, imágenes y sonidos. El Videodisco Interactivo (VD-I) presenta gran
calidad en información para los procesos de aprendizaje/formación indivi-
dualizados. Actualmente el futuro apunta hacia el DVD, entre otras razones
por ser capaz de almacenar una mayor cantidad de información.
En los programas multimedia actuales se pueden destacar las caracterís-
ticas siguientes:
a) Interactividad
Se denomina interacción a la comunicación recíproca, a la acción y
reacción. Una máquina que permite al usuario hacerle una pregun-
ta o pedir un servicio es una «máquina interactiva». La interacción
es una de las características educativas básicas potenciada con los
sistemas multimedia y permite al usuario buscar información,
tomar decisiones y responder a las distintas propuestas que ofrece el
sistema.
b) Ramificación
Es la capacidad del sistema para responder a las preguntas del usuario
encontrando los datos precisos entre una multiplicidad de datos dis-
ponibles. Gracias a la ramificación cada alumno puede acceder a lo
que le interesa y necesita prescindiendo del resto de datos.
c) Transparencia
En cualquier presentación la audiencia debe fijarse en el mensaje
más que en el medio empleado. El usuario, el alumno, etc., debe
poder llegar al mensaje sin estar obstaculizado por la complejidad de
la máquina. La tecnología de interacción hombre-máquina (ratón,
pantalla tactosensible, teclados, lápiz óptico, etc.) debe ser tan trans-
parente como sea posible, permitiendo la utilización de los sistemas
de manera sencilla y rápida, sin que haga falta conocer cómo funcio-
na el sistema.
d) Navegación
El concepto de «navegación» se ha convertido en una síntesis de los
nuevos sistemas interactivos de información. Los sistemas multime-
dia permiten «navegar», por todos esos mares de la información con-

temporánea, haciendo que la «jornada» sea grata y eficaz al mismo
tiempo.
1.7. VENTAJAS E INCONVENIENTES DE LOS MULTIMEDIA
Entre las ventajas de un multimedia se pueden destacar (García, 1983):

a) Presenta las ventajas comunes a todas las tecnologías, permitiendo
además una mayor interacción.
b) Ofrece la posibilidad de controlar el flujo de información.
c) Gracias a la información almacenada en un disco óptico, ofrece gran
rapidez de acceso y durabilidad.
d) Une todas las posibilidades de la Informática y de los medios audiovi-
suales.
e) Un programa multimedia bien diseñado permite actualizar con facili-
dad los contenidos, con pequeños cambios en el software.
f) Mejora el aprendizaje, pues el alumno avanza por el sistema según su
ritmo individual de aprendizaje, pedirá información, se adentrará en
temas nuevos cuando tenga dominados los anteriores, etc.
g) Incrementa la retención. La memorización de núcleos de información
importantes aumentará significativamente gracias a la interacción y a
la combinación de imágenes, gráficos, textos, etc., junto a las simula-
ciones con representaciones de la vida real.
h) Aumenta la motivación y el gusto por aprender. El aprendizaje se con-
vierte de este modo en un proceso lúdico.
i) Reduce el tiempo de aprendizaje
j) Presenta consistencia pedagógica. La información contenida es la
misma en distintos momentos y para diferentes alumnos.
k) La metodología, dentro de su variedad, es homogénea.
l) La evaluación de procesos y no sólo de resultados, ofrece ecuanimi-
dad.
m) Es hoy en día uno de los medios de instrucción con mayor calidad.
n) Mejoran las condiciones del aprendizaje no sólo recibiendo más y
mejor información, sino, sobre todo, mejorando los procesos cogni-
tivos, favoreciendo la interacción, y aumentando la experiencia
social.
Entre los inconvenientes de los sistemas multimedia, se pueden destacar:

a) Alto costo del material de equipo y de la producción del material de paso.
b) Falta de estandarización. Hay una multiplicidad de marcas y estánda-
res excesiva que tiende a reducirse a dos: MPC (Multimedia PC para
compatibles) y, por otro lado, Macintosh de Apple.
c) Falta de programas en cantidad y calidad en lengua castellana.
d) Problemas de personal: los docentes, en general, no están preparados
para el uso de esta tecnología y, además, con frecuencia tienen cierto
«miedo» que revierte en tecnofobia.
e) Los multimedia mediocres o malos confunden a los alumnos inun-
dándoles con elementos complejos y distractivos.
1.8. RECOMENDACIONES A TENER EN CUENTA

EN EL DISEÑO DE UN PROYECTO MULTIMEDIA
Multimedia proporciona el gran poder para saltar con facilidad dentro

del contenido del proyecto. No obstante, demasiada libertad desconcierta al
usuario e incluso le desorienta. Hay que tratar de mantener los mensajes y
contenidos organizados a través de un flujo constante de los temas principa-
les, dejando así que los usuarios hagan bifurcaciones para explorar más deta-
lles. Hay que dar siempre un ancla segura con botones que lleven al usuario
a lugares esperados y construir un escenario familiar para que puedan regre-
sar en cualquier momento. Los productos de software realmente buenos han
de ser sencillos, emocionantes y profundos. Las personas deben meterse en el
programa en 30 segundos, tener una retroalimentación positiva inmediata y
sentirse recompensada. Si esto es así, enseguida sonríen, se divierten y quie-
ren seguir profundizando. Emocionante significa que ha de sacarle provecho
a su procesador y todas sus capacidades, gráficas y de sonido, para vehicular
algo dinámico y excitante que compita con lo que la gente está acostumbra-
da a ver en cine o televisión.
El diseño y la construcción de un proyecto multimedia van de la mano.
Con frecuencia, los mejores resultados son producto de una retroalimenta-
ción continua, así como de modificaciones a lo largo del proceso de produc-
ción. Un proyecto multimedia no es más que un arreglo de texto, gráficos,
sonido y elementos de vídeo. Pero el modo en que se componen estos ele-
mentos hace que cada proyecto sea diferente, tomando la forma que le dan el
propósito del proyecto y los mensajes que contiene. Muchos mapas de nave-
gación son esencialmente no lineales. En estos sistemas de navegación los
espectadores tienen la libertad de saltar a un índice, un glosario, diferentes
menús, el módulo de Ayuda o Acerca de, etc., (figuras 1.1 y 1.2).
FIGURA 1.1. Módulo de Ayuda
El guión para un proyecto se organiza secuencialmente, pantalla por pan-

talla, y cada pantalla se aboceta con notas de diseño y especificaciones. Los
guiones son piezas cortas que describen con gran detalle cada imagen, ani-
mación, segmento de película, sonido, texto y señales de navegación. Los
guiones son la pareja de los mapas de navegación durante el proceso de dise-
ño (Castro y otros, 2002).
FIGURA 1.2. Módulo de Glosario.

La mayoría de los sistemas de desarrollo de multimedia permiten hacer

que una parte de la pantalla, o cualquier objeto, se convierta en un botón o
«área sensible». Cuando se hace clic en un botón sobre esa localización, algo
sucede, y esto hace que multimedia no sea sólo interactiva sino emocionante.
El diseño de navegación proporciona botones lógicos, de modo que sus accio-
nes se comprendan intuitivamente por medio de la representación gráfica, de
sus iconos o por señalamientos de texto. No se debe forzar a los usuarios a
aprender muchos iconos nuevos o especiales; se mantendrá la curva de
aprendizaje al mínimo. También es importante incluir botones que ejecuten
tareas básicas de mantenimiento, tales como terminar el proyecto en un pun-
to dado, o cancelar una actividad.
El diseño de pantallas de ordenador excelentes requiere un conjunto
especial de habilidades artísticas que no todos los programadores tienen. Un
artista gráfico de multimedia siempre se pone en el papel del usuario final
durante el proceso de diseño y generación, seleccionando colores que se ven
bien, especificando las fuentes de texto y diseñando los botones que repre-
sentan claramente lo que hacen.
El multimedia en todos estos aspectos debe ser un producto que atraiga,
que anime a profesores y a alumnos a utilizarlo cuando sea menester (tabla
1.2). La calidad técnica, por tanto, no es una categoría absoluta, sino que
estará mediatizada mientras que la misma sea efectiva para la creación de un
cierto clima positivo. La posibilidad del alumnado y el profesorado jueguen
un papel protagonista en su relación con el medio no es un asunto baladí des-
de una perspectiva técnica. Indicadores para evaluar los medios podrían ser:
los lenguajes en cada medio, integración de los medios, calidad de trata-
mientos textos, audios, vídeos, etc., potencialidad informativo-comunicativa-
educativa, presentación de la producción, interactividad y navegabilidad,
pertinencia de la interfaz, las articulaciones de los medios, las instrucciones
de instalación y uso.
TABLA 1.2. Recomendaciones para las presentaciones multimedia
El artista sabe que lo que funciona bien es lo que sigue:

Contrastes claros: grande / pequeño, pesado / ligero, brillante / oscuro, delgado/ancho.
Pantallas sencillas y limpias con mucho espacio en blanco.
El artista sabe que lo que funciona bien es lo que sigue:
Elementos atractivos a la vista, como letras mayúsculas iniciales, o un solo objeto de
color brillante sobre una pantalla en escalas de grises.
Sombreados en varios tonos. Gradientes.
Gráficos invertidos para remarcar los textos e imágenes importantes.
Objetos en varios tonos y texto en dos y tres dimensiones.
(Continúa)
TABLA 1.2. Recomendaciones para las presentaciones multimedia (Continuación)
Lo que el artista evita es:

Mezcla de colores.
Pantallas recargadas.
Humor trillado, sobrerrepetido en animaciones.
Campanas o rechinidos cuando se hace clic en un botón.
Patrones de bordes con demasiados adornos.
La necesidad de hacer más de dos clics para terminar.
Incluir demasiados números.
Demasiadas palabras (separe la información en frases pequeñas).
Demasiados elementos importantes presentados rápidamente.
1.9. RESUMEN
La necesidad de las comunicaciones a distancia es tan antigua como la
historia del hombre. Actualmente se está ante una auténtica tiranía tecnoló-
gica. Hace sólo 20 años no existía el ordenador personal ni las actuales redes
de comunicación. El cambio es tan rápido que se puede aventurar que en dos
años los equipos se vuelven obsoletos, y si se pierde el carro de estos avances,
se está en riesgo de obsolescencia.
El concepto de multimedia ha evolucionado en los últimos años. Hoy, se
puede decir, que ha adquirido un nuevo significado más preciso y menos
ambiguo y general. En este capítulo se ha analizado la delimitación concep-
tual del vocablo multimedia y su evolución desde una serie de perspectivas:
empresarial, etimológica, mediática, informática e integradora de lenguajes.
El primer multimedia fue el Diaporama, que combinaba la palabra, la
imagen, y el sonido. En 1958 se presentó la Multivisión, con grandes aportes
tecnológicos, pero basados en la técnica del diaporama, sólo que está más
cerca del espectáculo que de la didáctica. Luego aparecieron los Paquetes
Instructivos, diseñados para reforzar el proceso de enseñanza aprendizaje.
Los actuales sistemas Multimedia permiten no sólo usar la información,
sino también modificarla desde el ordenador.
1.10. EJERCICIOS DE AUTOEVALUACIÓN
1.1. El nacimiento de lo que se denomina electrónica de estado sólido fue

debido a la aparición de:
a) Las válvulas de vacío.
b) El transistor.
c) El primer circuito integrado.
d) El primer microprocesador.
1.2. La historia de Internet se inicia en aplicaciones que se derivan de desarro-

llos para:
a) Eliminar la lepra.
b) Estrategia de guerras.
c) Favorecer las comunicaciones.
d) La conquista espacial.
1.3. Cuál de las siguientes aplicaciones es la mas reciente:

a) WWW (World Wide Web).
b) Mosaic.
c) Netscape.
d) Intranet.
1.4. Las Ciencias de la Información se encuentran relacionadas con los pro-

cesos de:
a) Almacenamiento, transferencia, recuperación, y tratamiento de la
información.
b) Recuperación, manipulación, almacenamiento y control de la situación.
c) Almacenamiento, transferencia y tratamiento de la información.
d) Manipulación, almacenamiento y control de la situación.
1.5. Al referirse a una actividad en la que participan o se integran varios

medios: prensa, radio, cine y televisión, se está hablando de multimedia
desde una perspectiva:
a) Etimológica.
b) Empresarial.
c) Mediática.
d) Informática.
1.11. REFERENCIAS BIBLIOGRÁFICAS

CASTRO y otros (1996): M. Castro. Comparación de Técnicas y Herramientas de Autor
para la Generación de Aplicaciones Educativas. II Congreso de Tecnologías Apli-
cadas a la Enseñanza de la Electrónica, Sevilla.
CASTRO y otros (1999): M. Castro. Herramientas Hipermedia y/o Multimedia en Los
Procesos de Enseñanza/Aprendizaje en la Educación Superior a Distancia. 8º
Encuentro Iberoamericano de Educación Superior a Distancia. Quito-Ecuador
del 22 al 24 de julio de 1999.
CASTRO y otros (2002): M. Castro. Diseño y desarrollo multimedia: Sistema, imagen,
sonido y vídeo. RA-MA, 2002.
CASTRO y otros (1999): M. Castro. Sistemas básicos de comunicaciones. RA-MA, 1999.
COLMENAR (1999a): A. Colmenar. M. Castro, y J. Peire. Aplicaciones Didácticas de los
Sistemas Multimedia en la Enseñanza a Distancia. 8.° Encuentro Iberoamericano
de Educación Superior a Distancia. Quito-Ecuador del 22 al 24 de julio de 1999.
COLMENAR (1999b): A. Colmenar. Propuesta de Diseño Curricular en un Marco Cons-
tructivista para los Diferentes Niveles del Nuevo Sistema Educativo: Aplicación a
las Energías Renovables. Tesis Doctoral. UNED, 1999.
GARCÍA (1983): L. García. Los Medios Audiovisuales al Servicio de la Enseñanza.
Madrid: Servicio de Publicaciones del ICE de la Universidad Politécnica de
Madrid, 1983.
PEIRE (2001): J. Peire. Sesión de Apertura del 9.° Encuentro Iberoamericano de Edu-
cación Superior a Distancia. Cartagena de Indias, julio de 2001.
Capítulo 2
MEDIOS: TEXTO, IMAGEN Y SONIDO
ESQUEMA
2.1. Hipertexto.
2.2. Hipermedia
2.3. OCR. Reconocimiento Óptico de Caracteres.
2.4. Captura de imágenes digitales.
2.5. Formatos de archivos.
2.6. El sonido digital. Conceptos previos.
2.7. CD-AUDIO.
2.8. Formatos de sonido.
2.9. Extracción-compresión-reproducción.
2.10. Resumen.
El hipertexto se ha utilizado desde un principio en Informática para
almacenar información y presentar ésta en forma de texto entendible, los
avances en hardware y programación han permitido añadir gráficos y mejo-
rar la presentación de la información. Cuando el flujo de la información, que
aparece en la pantalla del ordenador, es controlable por el usuario, se empie-
za a hablar de hipertexto. Si bien hace tiempo que fueron acuñados, los sis-
temas hipertexto han alcanzado auge en la actualidad, con el abaratamiento
y popularización de los periféricos de almacenamiento masivo de datos y la
llegada de Internet. En este capitulo se muestran las bases para la confección
de unos buenos sistemas hipertetuales e hipermediales. En las secciones 2.1
a 2.3 se abordan los fundamentos del texto digital.
Antes de comenzar a digitalizar y editar imágenes es necesario familiari-
zarse con un par de conceptos fundamentales sobre el mundo de la imagen
digital. En este tema se van a presentar los diferentes modos de obtención de
imágenes digitales, 2.4, así como los principales formatos en los que estas
pueden archivarse, 2.5.
A continuación se muestran los conceptos que proporcionan los funda-
mentos para poder comprender el funcionamiento del sonido digital así
como sentar las bases para un conocimiento que le ayudará a seleccionar los
formatos de archivo más adecuados para su documento. WAV, MP3, MIDI,
son algunos de los múltiples formatos de sonido. En este tema se pretende,
desde un punto de vista práctico, descifrar qué se esconde tras este laberinto
de nombres de archivos de sonido digital. Después de su lectura sabrá cuál es
el mejor formato y qué herramientas se deben emplear para editar, visualizar,
reproducir y convertir diferentes archivos de audio. Todos estos aspectos se
abordan en las secciones 2.6 a 2.9 de este tema.
2.1. HIPERTEXTO
La versión estrictamente teórica del Hipertexto responde exactamente a
las formas básicas del estructuralismo y propone que cada pieza del texto,
cada palabra, será tratada como un elemento relacionable en un sistema de
información. De esta manera, se puede acceder a enormes cantidades de

datos relacionados a través de palabras claves y búsquedas (Castro y otros,
1996).
A diferencia de lo que son las llamadas a pie de página o notas de un tex-
to, los distintos cuerpos o espacios textuales del hipertexto poseen autono-
mía. Crecen y se modifican de forma independiente y sólo se ven cuando son
activados a través de las palabras claves o puntos de conexión, a los que se lla-
ma nodos.
Es obvio que cuando se planifica un viaje o se narra un hecho, se hace de
manera hipertextual, yéndose por las ramas como se suele decir y haciendo
mención a definiciones o narraciones anexas que ayudan a completar la idea
del discurso. Esto demuestra que el hipertexto no es un invento del ordena-
dor, sino un descubrimiento del pensamiento humano que encontró en la
máquina una herramienta para su propio crecimiento; los primeros hiper-
textos creados en papel, jamás gozaron de versiones electrónicas y entre otros
se pueden contar el libro de Julio Cortázar Rayuela, considerado como un
hipertexto, ya que puede leerse de manera lineal hasta el capítulo 56 o tomar
el camino que sugiere el autor. Algunos poemas de Cortázar también están
construidos en forma hipertextual. El Jardín de los senderos que se bifurcan o
El Aleph, de Jorge Luis Borges, son libros que también hablan en clave de
hipertextualidad. En la colección de libros «Elige tu propia aventura», el lec-
tor toma parte activa seleccionando los espacios que desea leer (Colmenar,
1999a).
Lo primero que el ordenador le añadió, fue la posibilidad de presentar los
distintos cuerpos en forma casi inmediata permitiendo, a través de opciones
de fácil acceso, avanzar o retroceder para navegar por los mares de la infor-
mación (Boom, 1987).
«Por lo tanto, la diferencia básica entre un hipertexto y un texto tradicio-
nal es la naturaleza exclusivamente secuencial de la información que presen-
ta este último. El hipertexto por el contrario, representa una red o sistema de
información en el que no se sigue un único orden de lectura. Las sucesivas
unidades de información están entrelazadas mediante vínculos o punteros
que permiten desplazarse en el documento». Se entiende por hipertexto un
texto interactivo que incorpora otros elementos que no son propiamente tex-
to. Es por tanto, un sistema que vincula elementos de información mediante
enlaces activables.
Algunas formas de enlazar entre sí los diferentes nodos del hipertexto se
logran mediante un conjunto de botones que permiten la navegación hacia la
próxima página o a la página anterior, abandonar la sesión de trabajo o el libro,
solicitar orientaciones generales sobre cómo utilizar el hipertexto, consultar el
índice temático, buscar directamente contenidos especificados mediante pala-
bras claves, realizar evaluaciones del aprendizaje o ejecutar comprobaciones
MEDIOS: TEXTO, IMAGEN Y SONIDO 47
prácticas de los contenidos estudiados. Otra forma de enlace utilizada son las
denominadas palabras calientes, que se distinguen por su color diferente al
resto del texto y por el cambio en la forma del cursor del ratón cuando el mis-
mo se ubica encima de una de estas palabras. Los enlaces se realizan, en gene-
ral, mediante elementos designables en pantalla usando el ratón (letras de
color, palabras activas, frases o imágenes) y su objetivo (texto plano, otro hiper-
texto, una imagen, una secuencia de vídeo o un sonido) (Colmenar, 1999b).
Un hipertexto debe estructurarse jerárquicamente, pues así se facilita la
entrada a éste por múltiples puntos del documento final, flexibilizando su
uso para posteriores aplicaciones (figura 2.1). Generar hipertexto es tan sen-
cillo como escribir un documento en un procesador de texto cualquiera, e ir
insertando marcas (elementos activables y referencias de documentos) que
definen las relaciones entre los distintos textos que lo definen. El hipertexto
puede ser desarrollado mediante múltiples formas, desde aplicaciones infor-
máticas personalizadas como Visual Basic, Borland C, Delphi, Toolbook, etc.,
hasta pequeñas herramientas que generan hipertexto en formato .HLP (como
es el caso del procesador de texto Word), es decir, documentos que son leídos
por la ayuda de Windows, programa que acompaña al entorno por lo que la
visualización de estos ficheros está garantizada desde la instalación de Win-
dows. Pueden encontrarse otras herramientas para generar hipertexto a pre-
cios asequibles (incluso versiones shareware): Help Builder, compilador HC31
de Borland o Microsoft, etc.
Uno de los programas que más fielmente se adaptan a la definición de
hipertexto es el programa Simply Help. Éste nació, tal como reconoce su
Entrada
Cap. 1 Cap. 2 Cap. N Glosario
Entrada
FIGURA 2.1. Estructura jerárquica de un hipertexto.

autor, como un entorno de creación de ayudas que son integradas en otros

programas que funcionan bajo el sistema operativo DOS. Los sistemas crea-
dos con él son pantallas de texto independientes que se vinculan entre sí de
diferentes formas. La sucesiva presentación de las mismas se puede realizar
por su orden natural o en cualquier orden que se diseñe mediante enlaces
hipertexto. Con el fin de moverse a través de las distintas pantallas, se pulsa
cualquier palabra de enlace con el ratón, o bien la tecla Intro cuando se
encuentre resaltada. Las últimas versiones permiten la posibilidad de enlazar
con programas externos de modo que, utilizando visores adecuados, es posi-
ble dar a la publicación hipertexto un carácter multimedia más amplio (Cas-
tro y otros, 1999).
Un sistema hipertextual completo debe proporcionar herramientas de
creación y edición de nodos y enlaces para formar hiperdocumentos, permi-
tiendo que un nodo esté conectado a otro en una compleja red. Estas herra-
mientas deben estar incluidas en un entorno que tenga una interfaz de usua-
rio que sea sencilla y flexible, y que dé un amplio rango de facilidades en la
construcción, modificación y actualización de documentos.
En la figura 2.2 se muestra un modelo general de arquitectura de sistemas
hipertextuales. Como primer nivel están dos tipos de usuarios: uno que acce-
de en forma de consulta (denominado usuario en la figura) y el otro que es el
FIGURA 2.2. Arquitectura de un hipertexto.

creador del hiperdocumento (denominado autor). El primero puede consul-

tar y navegar por la base de información, mientras que el autor puede, ade-
más, actualizar el sistema con las herramientas de mantenimiento. La infor-
mación con la que trabajan los dos está contenida en una base de datos
hipertextual.
Como se desprende de la figura 2 en los sistemas hipertextuales existen
dos formas básicas de acceso a la información, mediante navegación y por
interrogación. La experiencia en hipertextos ha demostrado que los mecanis-
mos de acceso por navegación no son suficientes. En algunas aplicaciones
normalmente caracterizadas por grandes redes estructuradas y heterogéne-
as, los usuarios tienden a perderse mientras están buscando la información
de partida. En consecuencia para reforzar los mecanismos de acceso (nave-
gadores gráficos, visualizador de la red, etc.), muchos sistemas hipertextua-
les soportan otros tipos de búsqueda por contenidos, que permite a los usua-
rios examinar el hiperdocumento con una pregunta (Castro y otros, 2002).
2.2. HIPERMEDIA
Como extensión del término hipertexto (escritura no secuencial), aparece

el término hipermedia, que implica enlaces y navegación en un material
almacenado en cualquier medio: texto, vídeo, sonido, música, gráficos, etc.
Hipermedia es el término que define el almacenamiento y recuperación de
información mediante un ordenador de una manera no secuencial. La habi-
lidad para moverse en la información textual y las imágenes es sólo la mitad
del sistema: un entorno que se denomina con propiedad como hipermedia
incluye herramientas que permiten al lector reelaborar el material que se le
presenta con un control total del usuario. Muchos autores consideran sinóni-
mos los términos hipertexto e hipermedia.
2.3. OCR. RECONOCIMIENTO ÓPTICO DE CARACTERES
El reconocimiento óptico de caracteres (OCR), es decir, que el ordena-

dor entienda las letras escritas sobre el papel y sea capaz de trabajar con ellas,
es uno de los grandes logros de los escáneres o sistemas de digitalización.
Para su correcto funcionamiento hace falta un software especial, que suele
incluirse con el aparato. La combinación software-hardware servirá para aho-
rrar trabajo (teclear el texto) y para ahorrar espacio en disco (un documento
editable ocupa mucho menos que una imagen digital).
El reconocimiento óptico de caracteres es el proceso mediante el que, a
partir de la imagen de un documento, se reconocen los caracteres en él con-
tenidos. El proceso de OCR no siempre es capaz de leer la totalidad del con-
tenido de los documentos, algunas palabras pueden estar mal interpretadas o

algunos caracteres pueden ser erróneos. La tasa de errores dependerá de la
calidad y el tipo de original que se maneje. No obstante, el OCR puede aho-
rrar mucho trabajo de introducción de datos. Al hacer OCR, el escáner (o el
ordenador) se limita a convertir la página de texto física a una imagen digita-
lizada; posteriormente, el software OCR se encarga de traducir sus líneas a
caracteres editables. De hecho, cualquier imagen digitalizada que contenga
texto, es susceptible de ser convertida en un documento editable. Se puede
grabar la imagen digitalizada como un bitmap en formato TIF, por ejemplo,
para, más tarde, arrancar el programa de OCR, leer desde el disco el mapa de
bits y convertirlo en una página perfectamente editable por el procesador de
textos habitual (Castro y otros, 2002).
El reconocimiento de caracteres ópticos (OCR) es una tecnología utili-
zada en aplicaciones comerciales desde 1950. Fue diseñada inicialmente
para leer lo que se conoce como tipologías «estilizadas». Estas tipologías,
como OCR-A, incluyen conjuntos completos de caracteres alfanuméricos
junto con caracteres especiales que son digitalizados o leídos mecánica-
mente proporcionando, de esa manera, un método de alta velocidad de
entrada de datos libre del teclado. Hay dos formas principales de abordar el
reconocimiento de caracteres ópticos: la comparación contra un juego de
caracteres existente o la extracción de rasgos. La comparación «ve» el
carácter impreso y compara esa imagen con una base de datos de posibles
opciones. La extracción de rasgos mira los elementos estructurales y su
combinación para reconocer el carácter (figura 2.3). En los últimos años, la
tecnología ha mejorado significativamente, en parte debido a la disponibi-
lidad de ordenadores personales de bajo costo y alta potencia. Esto ha per-
mitido el desarrollo de software de reconocimiento más poderosos. Por
ejemplo, la mayoría de los equipos actuales de OCR son capaces de leer
tipologías comunes de oficina, como la Courier y también tipologías estili-
zadas y tipologías proporcionales que se encuentran en los periódicos y
revistas. De hecho, muchos utilizan el término «reconocimiento de caracte-
res inteligentes» (ICR) ya que,este término, describe mejor el hardware y
software actuales para OCR. Sin duda, aunque el OCR tiene mucho tiempo
de existencia, no ha sido hasta hace algunos años, cuando bajaron los pre-
cios de los escáneres y llegaron al pequeño usuario, cuando han empezado
a mejorarse hasta los límites que se conocen hoy.
FIGURA 2.3. Reconocimiento por extracción de rasgos.

2.4. CAPTURA DE IMÁGENES DIGITALES
Por todos es conocido que «una imagen vale más que mil palabras», la
imagen juega un papel fundamental en el campo del multimedia; a continua-
ción, se verá cómo es posible introducir en el ordenador una imagen no digi-
tal, cómo obtener directamente imágenes digitales, así como qué son y don-
de encontrar álbumes de imágenes digitales.
2.4.1. El escáner
El dispositivo óptico que puede leer documentos y convertirlos en «unos

y ceros» para posteriormente ser tratados por un programa informático, reci-
be el nombre de escáner. Éstos pueden interpretar fotos, dibujos y textos, y
almacenarlos en un archivo gráfico en el ordenador. Si el aparato es bueno, y
se reconoce el original a una resolución elevada, la diferencia entre el origi-
nal y la exploración será muy pequeña. Con el escáner, una fotografía puede
ser explorada, incorporada en un documento después de retocarla ligera-
mente y ser impresa en muy pocos minutos.
E1 avance tecnológico de la mayoría de los escáneres permite que puedan
ser utilizados para todo tipo de trabajos. El tamaño se ha reducido casi hasta
alcanzar la superficie de una hoja A4, y su espesor es de apenas unos centí-
metros, por lo que consumen poco espacio sobre la mesa. Además, si no se
dispone de impresora y escasea el espacio, existen escáneres multifunción,
que en una sola máquina permiten escanear e imprimir.
Casi todos los fabricantes incluyen con sus productos algún software con
el que empezar a trabajar desde el primer momento. Los programas de OCR
(reconocimiento óptico de caracteres) suelen formar parte de todos los
paquetes de software.
La característica más importante de un escáner es su resolución, la canti-
dad de información que es capaz de procesar el escáner, indicando el nivel de
detalles en la imagen que el escáner puede capturar. Se mide en puntos por
pulgada y la cifra se suele dar en ppp (puntos por pulgada), dpi (dots per
inch), e incluso en ppi (pixels per inch), aunque todo significa lo mismo.
Cuando se dice que un escáner tiene una resolución de 300x600, significa que
tiene una resolución horizontal de 300 ppp y una resolución vertical de 600
ppp. Y cuando se dice que un escáner tiene una resolución de 600 ppp es que
tanto la resolución horizontal como la vertical es de 600 ppp. La resolución
de un escáner se facilita, habitualmente, de dos maneras/formas: resolución
óptica y resolución interpolada.
Las imágenes digitalizadas se guardan en unos archivos de formato gráfico
denominados, según la forma de almacenamiento, gráficos vectoriales o mapas
de bits (bitmaps). Un mapa de bits consiste en un mosaico rectangular de pun-
tos, denominados píxeles. Por lo tanto, un píxel es el elemento más pequeño

del que está compuesta una imagen. Cada píxel lleva asignado un valor, desde
un bit de información, que indica si es blanco o negro, hasta 64 bits utilizado
por algunos formatos de uso reducido. A este valor se le llama profundidad de
color. La profundidad de color más utilizada actualmente es la de 24 bits. Los
bitmaps de 24 bits están formados por tres canales de color, rojo, verde y azul
(RGB, de Red, Green, Blue), de 8 bits cada uno. Al combinar los tres canales
RGB se pueden obtener hasta 16,7 millones de colores. Esta profundidad de
color se la suele llamar Color Verdadero o True Color. Utilizar más de esta pro-
fundidad de color para visualizar en pantalla, imprimir o hacer algo que no
sean procesos internos de cálculo de los programas o sensibilidades ópticas de
los escáneres, no tiene demasiado sentido, porque el ojo humano no es capaz
de distinguir tantos tonos y matices (Castro y otros, 2002).
2.4.2. Cámaras fotográficas digitales

En pleno siglo XXI el hecho de que las cámaras digitales estén predestina-
das a sustituir a las convencionales es algo que no parece razonable discutir.
La actual tendencia de bajada de precios y el incremento más que notable de
la resolución óptica y de la calidad general de las cámaras disponibles en el
mercado en el mercado parecen confirmarlo. Las ventajas de una cámara
digital son muy variadas: permiten crear fotografías rápidamente para su
inclusión en una página Web, realizar trabajos escolares, tener fotografías de
excursiones o eventos familiares en pocos minutos, o eliminar los tiempos de
espera de revelado y procesado en los trabajos donde el tiempo es vital (y en
comunicación como es el caso de periodismo). Y todo ello pudiendo obtener
copias infinitas y realizar el proceso en el ordenador de casa (figura 2.4).
FIGURA 2.4. Cámara fotográfica digital.

2.4.3. Clip-Arts
Existen álbumes de imágenes profesionales (llamados ClipArt), figura 2.5,
y de fotografías que son muy fáciles de conseguir. Las imágenes y las fotos
son los elementos que más habitualmente se incorporan a los programas
multimedia. Muchos paquetes incluyen muestras de diferentes compañías
creadoras de imágenes y fotos. Por ejemplo, CorelDRAW 96 incorpora 22.000
imágenes y símbolos, así como 100 fotografías de alta resolución. Si eso no
fuera suficiente (y para muchos profesionales no lo es), Corel vende bibliote-
cas de imágenes y fotos adicionales, con otras 200.000 imágenes. Sin embar-
go, hay que tener en cuenta que la calidad de las imágenes y las fotos puede
variar enormemente. Sólo porque se trate de un producto comercializado no
significa que tenga una categoría verdaderamente profesional. Image Club es
una compañía que siempre se ha considerado líder en la categoría de las imá-
genes profesionales de alta calidad. Este Club también ofrece fotografías pro-
fesionales. Adobe adquirió Image Club en 1995. Se puede visitar la página de
presentación de Image Club en: http://www.adobe.com/imageclub. Otras dos
compañías que disponen de imágenes digitales impresionantes son Photo-
Disk y CMCD. CMCD es una compañía de la firma de diseño Clemont Mok, y
sus fotos las distribuye PhotoDisk. Una tendencia en las imágenes fotográfi-
cas es la utilización de objetos de uso cotidiano y metáforas al respecto. Se
pueden visitar las últimas novedades de los objetos de uso cotidiano de
CMCD en la dirección:
http://www.cmdesigns.com
Tenga en cuenta que no existe un formato estándar para las fotografías y

las imágenes de los clip-art. Image Club utiliza los formatos EPS y TIFF. Pho-
toDisk utiliza los formatos JPEG y TIFF, mientras que CMCD utiliza el for-
mato PhotoCD de Kodak.
Comentar aquí la conveniencia, por no decir necesidad o condición de los
autores de referenciar siempre su trabajo haciendo una referencia a su uso
(no su compra), como un reconocimiento a sus derechos de autor.
FIGURA 2.5. Colección de Clip-Arts.

2.5. FORMATOS DE ARCHIVOS
Los datos contenidos en los archivos gráficos no siempre se refieren a

parámetros de pixeles o puntos, tales como posiciones y colores. Esto es sólo
cierto en el caso de los archivos raster o de tipo bitmap (mapa de bits), muy
empleados para almacenar fotografías. Los archivos con datos vectoriales
contienen ecuaciones matemáticas que evitan la degradación de los conteni-
dos ante las operaciones de edición. Son empleados de forma masiva por los
programas de CAD, ilustración y diseño gráfico. Los metafiles son un tipo
especial de archivos que pueden contener información bitmap o vectorial. Un
claro ejemplo es el Windows Metafile o WMF, un peculiar formato que inclu-
ye llamadas a funciones de la interfaz gráfica de Windows. Las animaciones
son almacenadas en formatos especiales de datos raster con estructuras pre-
paradas para la reproducción secuencial. Por último, existen formatos de
objetos multidimensionales que incluyen los datos y el código para su inter-
pretación y archivos multimedia que pueden almacenar todos estos tipos de
datos junto con información audiovisual. La idoneidad y conveniencia de
uno u otro formato depende de la finalidad que vayan a tener los trabajos que
contienen. Los formatos más utilizados son las que se citan a continuación
(Castro y otros, 2002):
2.5.1. BMP (Windows Bitmap Format)
Es el formato nativo de Windows, puede tener una profundidad de color

desde 2 hasta 24 bits, sin compresión. Sus principales ventajas son que no tie-
ne ninguna pérdida de color y lo suelen utilizar todos los programas que se
ejecutan en Windows, aunque tiene el inconveniente de su gran tamaño.
Existe también una derivación con compresión, empleando un algoritmo

de compresión RLE (Run Lenght Encoding) de 4 u 8 bits. El método RLE es
idóneo ante imágenes que incluyen patrones repetitivos y bloques de puntos
similares, funciona comprimiendo cadenas secuenciales iguales, cambiándo-
las por el símbolo repetido y el número de veces que se repite.
2.5.2. GIF (Graphics Interchange Group, Grupo de Intercambio

de Gráficos)
Hasta hace poco ha sido el más utilizado, sobre todo en el mundo de las
comunicaciones. Hoy ha cedido el paso al JPG, ya que éste soporta 24 bits
(16,7 millones de colores), mientras que el GIF sólo permite 8 bits (256 colo-
res). Todavía se sigue utilizando en Internet, ya que goza de un alto nivel de
compresión, puede crear gráficos animados y puede establecer fondos
transparentes.
Los archivos GIF se almacenan en un formato comprimido, de tal mane-

ra que el tiempo que se emplea para cargar estos archivos gráficos es mínimo.
Los archivos GIF soportan tipos de imágenes de color indexado, así como
imágenes en escala de grises y de líneas.
2.5.3. JPEG
Fue diseñado por el grupo Joint Photographics Experts Group (la Unión
del Grupo de Expertos Fotográficos). Es el formato más utilizado actualmente
en Internet y es muy válido para crear fotografías de alta calidad, color ver-
dadero y un tamaño reducido. Ideal para el almacenamiento masivo de
imágenes. Hay que tener presente que, aunque admite unos grados de com-
presión muy elevados (a mayor compresión, mayor pérdida de detalle en la
imagen final) no es conveniente superar un nivel de compresión de 15:1.
JPEG es el estándar a elegir, debido a su alta resolución y a su elevada
compresión. Muchos editores gráficos, tal como Adobe Photoshop, permiten
elegir una configuración de alta calidad para efectuar la compresión. La ele-
vada calidad se comprime, con una relación comprendida entre 5:1 y 15:1.
Reduce los archivos de imagen aproximadamente a un 10% de su tamaño ori-
ginal (o aún menos). El algoritmo JPEG pierde algunos de los datos, ya que
identifica e ignora los píxeles que no son esenciales para la calidad general de
la imagen; por ejemplo, una gran área de un color continuo.
2.5.4. TIFF
Suele ser el formato utilizado por el escáner durante la digitalización de

los documentos. Debido a su escasa compresión, su mayor defecto es el
tamaño de la imagen resultante. Sin embargo, juega a su favor el que es
soportado por todos los programas de tratamiento de imágenes e incluye
todos los tipos de color (puede almacenar imágenes de 1, 8, 12 y 24 bits de
color por píxel o imágenes de 32 bits separadas en componentes CMYK con
un canal alpha para transparencias y otros efectos). Es el formato indicado
para utilizar la separación de colores CMYK, utilizada en impresión. Este for-
mato ofrece libertad para elegir el tipo de compresión empleado para tratar
sus datos y que puede ser de tipo LZW (Lempel-Ziv-Welch), RLE, PackBits,
grupos III y IV de fax y CCITT/Huffman. Es el formato ideal para transferir
trabajos entre ordenadores PC y Apple Macintosh.
2.6. EL SONIDO DIGITAL. CONCEPTOS PREVIOS
Debido a que el sonido se transmite como una onda continua o analógica y

que los ordenadores emplean sonido digital, deberá realizarse una transforma-
ción. Para realizar esta conversión se toman unas muestras de ondas a unos
intervalos de tiempo concretos. Se denomina frecuencia de muestreo al número
de muestras tomadas por segundo, cuanto mayor sea este número mayor será la
calidad del sonido y mayor será la cantidad de datos a almacenar. Las frecuen-
cias más habituales son 22.050 Hz y 44.100 Hz. Al tomar una muestra de soni-
do se almacena un valor que representa su amplitud. Este sonido se podrá gra-
bar en 8 ó 16 bits. Cuanto mayor sea el número de bits utilizado mayor será la
calidad de dicho sonido, es decir la reproducción de dicho sonido se realizará
con mayor precisión, si bien también hay que tener en cuenta que un mismo
archivo grabado a 16 bits ocupa el doble de espacio que uno de 8 bits. El núme-
ro de canales de audio muestreados determinará si el sonido es monofónico (un
solo canal) o estereofónico (dos canales) (Castro y otros, 2002).
Antes de comenzar a digitalizar sus propias piezas de sonido es necesario
que se familiarice con un par de conceptos fundamentales sobre el sonido
digital. Estos conceptos le proporcionarán los fundamentos para poder com-
prender el funcionamiento del sonido digital y un conocimiento que le ayuda-
rá a seleccionar los formatos de archivo más adecuados para su documento.
El sonido en el CD almacenado ha sido muestreado a 44 kHz y una reso-
lución de 16 bits en estéreo. Una canción o tema corresponde exactamente a
una pista. Mediante un láser se leen los datos del CD y son traducidos por un
circuito conversor digital-analogico (DAC) a señales electromagnéticas que
serán transmitidas a través de un cable, que estará conectado a un amplifica-
dor o auriculares. El paso contrario, es decir, la grabación de una señal ana-
lógica a un CD en formato digital se hace mediante un convertidor analógico-
digital (ADC), (figura 2.6) (De Furia, 1986).
También hay que destacar el auge del MiniDisc, que permite la grabación
de 74 minutos de música con un tamaño parecido a un disquete de 3 1/2 y que
ofrece la ventaja de poder grabar en un mismo soporte hasta un millón de
veces, sin perder calidad.
Cuando se preparan archivos de sonido para utilizarlos en el Web hay que
tener en cuenta que no siempre hay que utilizar la mayor profundidad de
muestreo ni la mayor frecuencia de muestreo posibles. Cuanto mayores sean
estos dos parámetros más espacio se requerirá para almacenar ese sonido. Por
ello, será necesario decidir si se desea sacrificar espacio de disco y ancho de
banda para aumentar la calidad de los archivos de sonido. Además, esa fre-
cuencia sólo debe utilizarse en las muestras de alta calidad. Si un archivo de
sonido sólo contiene voz, será suficiente utilizar 8 bits y 8 kHz (De Furia, 1987).
2.7. CD-AUDIO
La aparición de los primeros estándares multimedia se remonta a princi-
pios de la década de los años ochenta. El primero de los formatos fue el CD-
FIGURA 2.6. Conversión analógico digital y viceversa de una señal.
Audio, desarrollado por Sony, y cuyas especificaciones se recogen en el deno-

minado «Libro rojo», el primero de una serie de manuales técnicos sobre for-
matos multimedia. En el CD-Audio se basó el desarrollo de los discos com-
pactos o compact disc (CD), muy extendidos como soportes para música.
2.8. FORMATOS DE SONIDO

Las muestras de sonido, al igual que sucede con los formatos destinados a
gráficos, pueden ser transportadas en varios tipos de archivos. Su variedad no
es tan grande como sucede con los formatos gráficos, pero todos ellos contie-
nen una serie de parámetros comunes que informan de la frecuencia de mues-
treo empleada en la grabación, del número de canales de la muestra, de los bits
de cuantificación digital y de otros datos importantes sobre bucles de repeti-
ción (loops) e información adicional por citar tan sólo dos ejemplos.
Los editores gráficos de audio (EGA) son unas sofisticadas aplicaciones
que facilitan la grabación, reproducción y edición de audio digital. Sound
Forge (programa que se comentará un poco más adelante) es un soberbio
software shareware que incluye funciones típicas de los editores comerciales y
alguna que otra para trabajar con varias muestras de sonido al mismo tiempo
y la edición se lleva a cabo con el ratón tal y como si fuera un lápiz que per-
mitiera «pintar» el sonido. Aplica varios efectos de sonido tales como ecos,
reverberaciones, distorsiones y panoramas. Todas sus operaciones de edición
son inteligentes, de tal forma que la frecuencia de muestreo, resolución y

número de canales son convertidos de forma automática al realizar operacio-
nes entre varias muestras abiertas en el área de trabajo. La longitud de las
muestras no está determinada por la cantidad de memoria RAM, ya que a la
hora de trabajar con grandes archivos de audio, Sound Forge emplea el disco
duro. Puede leer y grabar diversos formatos de archivos RIFF Wave o .WAV,
VOC, IFF y AU entre otros y realizar conversiones con cualquier combinación
de los atributos soportados por un formato particular (De Furia, 1987).
Uno de los elementos que rodea cualquier tecnología emergente es la apa-

rición de diferentes formatos. Casi todos los fabricantes de hardware han
desarrollado su propio formato para grabar y reproducir los archivos de soni-
do, y cada uno de ellos necesita su propio programa de software para enviar
el sonido al altavoz. Afortunadamente, no se necesita ser un maestro de los
formatos para colocar archivos de sonido en los documentos. El laberinto de
las normas se ha visto relativamente limitado en Internet. Los apartados
siguientes explican la mayoría de los formatos habituales de los archivos de
sonido utilizados en el Web, incluyendo AU (Audio), utilizado por las esta-
ciones de trabajo de Sun; AIFF, utilizado por los Macintosh; y WAV (Wave-
form) de Microsoft, empleado por los PCs.
Ocasionalmente se pueden encontrar archivos en otros formatos. Por

ejemplo, se pueden ver archivos con extensiones .VOC o .IFF. La extensión
.VOC se refiere a la voz (voice en inglés), y es el formato que utilizan por
defecto las tarjetas de sonido SoundBlaster. La extensión .IFF suele referirse
a un archivo de sonido de la plataforma Amiga. Éstos son formatos no están-
dar en Internet, por lo que deben evitarse.
2.8.1. WAV
Waveform (que significa forma de onda) es un formato de Microsoft e

IBM creado inicialmente para Windows 3.1. Este formato es actualmente un
subconjunto del formato RIFF (Resource Interchange File Format, es decir,
formato de Recurso de Archivo de Intercambio) de Microsoft. Esto se debe a
que el formato .WAV (Waveform Audio Format, es decir, Formato de Sonido
de Forma de Onda) se encuentra agrupado con la opción de formato de archi-
vo RIFF en varios editores de sonido. Los archivos waveform se pueden guar-
dar como archivos de sonido estéreo o mono, con 8 o 16 bits. Los archivos
donde se almacenan estos sonidos digitalizados tienen, en sistemas PC, la
extensión «. WAV».
En estos ficheros WAV suelen estar grabados los ruidos, voces y efectos
especiales de las bandas sonoras de videojuegos y programas multimedia. Al
principio de cada fichero WAV está almacenada la información que lo va a
caracterizar, y viene representada por 4 parámetros: duración temporal, fre-
cuencia de muestreo, resolución y grabación mono o stereo. El registro digi-

tal de una forma de onda se lleva a cabo mediante aproximaciones numéricas
que reproducen la estructura de dicha forma en determinados puntos de la
misma.
2.8.2. MP3
El MP3 se aprovecha de todas las deficiencias del oído humano, de forma

que elimina toda la información que no se necesita. Para ello utiliza un siste-
ma denominado Codificación de SubBandas, proceso por el cual la señal se
descompone en subbandas a través de un banco de filtros o cualquier otro
método semejante. Las subbandas obtenidas, se comparan a continuación
con el original mediante un modelo psicoacústico que determina cuáles son
las bandas importantes y cuáles se pueden eliminar. Dependiendo de la cali-
dad que se desee obtener, se eliminarán más o menos bandas. Para finalizar
el proceso, se cuantifican y codifican las subbandas que han pasado la criba,
y el resultado final se comprime utilizando un algoritmo estándar tipo Huff-
man o LZW. El proceso de codificación es mucho más complicado que el de
decodificación, por ello se tarda mucho más en codificar un archivo MP3 que
en reproducirlo.
El escaso tamaño de los ficheros de sonido en este formato de compre-
sión sin apenas perder calidad, lo hace ideal para grabar grandes cantidades
de música con calidad CD (toda la discografía de grandes bandas como los
Rolling o Queen entran en un solo CD y más si se utiliza DVD) y, sobre todo,
ofrece la posibilidad de intercambiar canciones e incluso discos completos a
través de Internet en un tiempo de conexión más o menos razonable (Castro
y otros, 2002).
2.8.3. MIDI
Los archivos MIDI File o MID permiten el transvase de partituras entre

diferentes plataformas informáticas con sistemas de archivos compatibles.
Estos archivos son un buen recurso para la inclusión de temas musicales en
aplicaciones multimedia, pues al contener únicamente los datos referentes a
las notas musicales y su interpretación, ocupan muy poco espacio físico en
las unidades de almacenamiento. Por ejemplo, los archivos que contienen
audio muestreado de alta calidad (44,1 kHz estéreo con 16 bits de resolución)
requieren 10 MB por minuto de sonido, mientras que una secuencia MIDI en
formato MIDI File con una duración igual, tan sólo requiere 10 kB. Por otro
lado, la reproducción de estos archivos no exige los mismos recursos que
necesita la reproducción de audio digital, aspecto decisivo para la sobrecarga
del sistema. El nivel de edición inherente a un archivo MIDI es mayor que el
que se posee por el momento sobre los archivos muestreados, facilitándose
los cambios de tempo o velocidad de reproducción y los cambios del tono y

las notas de los instrumentos del tema musical. La Asociación Internacional
de fabricantes MIDI o IMA publicó una normativa de estandarización para
los archivos MIDI File o SMF que define tres formatos diferentes: el formato
O almacena todos los datos MIDI en una única pista; el formato 1 —el más
empleado— posee pistas diferentes para cada instrumento; y el formato res-
tante, el tipo 3, permite disponer de pistas con datos independientes.
2.8.4. RealAudio
La aparición de los sistemas de compresión de audio en Internet datan de

la década de los años noventa. Vistas las amplias capacidades de transmisión
de información, muchos ingenieros comenzaron a darle vueltas a la cabeza
en busca de un sistema de compresión que permitiera reducir el tamaño de
los archivos de audio (los que más capacidad ocupan, junto con los de vídeo),
de tal manera que fuera posible transmitir esa información a través de la Red.
Con esto, la radio y la televisión podrían hacerse un hueco en Internet, al
tiempo que favorecería la aparición de emisoras y productoras de contenidos
diversos ampliando el elenco de información existente. Aunque los inicios
fueron más bien parcos, compañías como RealNetworks, Microsoft y Vxtre-
me, comenzaron a investigar en este campo ofreciendo soluciones y sistemas
diferentes.
Uno de los más populares es el conocido RealAudio o RealVideo, depen-
diendo de la fuente de información que se vaya a emitir. Su versión permite
convertir al ordenador conectado a la Red en un auténtico sintonizador de
canales de radio y televisión a través de Internet (Castro y otros, 2002).
El sistema de RealNetworks se basa en la tecnología streaming, que con-
siste en dividir en paquetes muy pequeños un archivo para enviarlo inmedia-
tamente a su destino y que pueda ejecutarse mientras otros paquetes van lle-
gando. Gracias a esa tecnología, es capaz de reproducir audio, vídeo,
imágenes estáticas, texto y animaciones en tiempo real con casi cualquier
tipo de conexión.
2.9. EXTRACCIÓN - COMPRESIÓN - REPRODUCCIÓN
Para pasar un disco de formato CD-Audio a ficheros MP3 son necesarios

dos pasos principalmente: la extracción digital de audio y la compresión. En
el primero se obtiene un fichero WAV por pista del disco, para lo cual es
imprescindible que nuestro lector de CD sea capaz de extraer audio, lo que no
solían cumplir las unidades más antiguas. Si nuestra unidad es capaz de
hacerlo, se buscará un programa que realice esta función, entre los sharewa-
re destaca el Windac, que permite la extracción a velocidad variable de una
forma bastante eficaz, aunque hay otros muchos (los programas de graba-
ción de CD, que suelen utilizar las grabadoras, también tienen extracción de
audio, aunque generalmente sólo pueden leer a velocidad simple). Esto tam-
bién se puede hacer directamente de forma integrada en RealAudio o Win-
dows Media.
Cada fichero WAV, por ejemplo, ocupará unos 50 MB y puesto que un CD
de audio suele tener unas 12 canciones será necesario disponer de 600 MB
libres de disco. Tras la compresión se pasará de tener un WAV de 50 MB a
tener un MP3 de 3 a 5 MB e incluso menos, y ello sin apenas pérdida de cali-
dad, y por tanto un disco que ocupaba 600 MB pasará a ocupar 50 MB. Para
ello será necesario un programa de compresión, también share o freeware
como MusicMatch Jukebox, AudioCatalyst, Fraunhofer MP3 Encoder,
XingMP3 Encoder o BladeEncoder o RealAudio o Windows Media, en los
que se podrá elegir una serie de parámetros para modificar la calidad (lo ide-
al es comprimir en estéreo a 44,1 kHz, 16 bits y 128 kbps). Además, en la
compresión se pueden incluir datos como el nombre de la canción, autor,
álbum, e incluso la letra de las canciones (Castro y otros, 2002).
Para la escucha de estos ficheros será necesario un programa descompresor/
reproductor, y aquí es donde se encontrará mayor variedad, entre los que desta-
can Winamp, Sonique, MusicMatch Jukebox o WPlay, RealAudio o Windows
Media, para los que existen plugins y carátulas personalizadas a fin de hacer
más completa y atractiva la reproducción de este tipo de ficheros (figura 2.7).
Winamp, nacido casi al mismo tiempo que el propio formato (por no
mentir, algunos meses después), ha evolucionado como ninguno, siendo la
punta de lanza en cuanto a reproducción de ficheros MP3. En sus últimas
versiones, soporta muchos más formatos de audio, siendo una buena herra-
mienta para la «reproducción por defecto» de nuestros ficheros de sonido en
general. Asimismo, las posibilidades de personalización mediante skins o las
de ampliación utilizando plug-ins hacen de este software uno de los más ver-
sátiles. Además, ahora vuelve a ser de tipo freeware, después de haber estado
disponible como share durante algún tiempo, sin duda el reproductor más
utilizado.
FIGURA 2.7. Winamp.

2.10. RESUMEN
La diferencia básica entre un hipertexto y un texto tradicional es la natu-
raleza exclusivamente secuencial de la información que presenta este último.
El hipertexto por el contrario, representa una red o sistema de información
en el que no se sigue un único orden de lectura. Las sucesivas unidades de
información están entrelazadas mediante vínculos o punteros que permiten
desplazarse en el documento.
Un sistema hipertextual completo debe proporcionar herramientas de
creación y edición de nodos y enlaces para formar hiperdocumentos, permi-
tiendo que un nodo esté conectado a otro en una red compleja. Estas herra-
mientas deben estar incluidas en un entorno que tenga una interfaz de usua-
rio que sea sencilla y flexible, y que dé un amplio rango de facilidades en la
construcción, modificación y actualización de documentos.
La imagen juega un papel fundamental en el campo de la multimedia, en
este capítulo se ha visto como es posible introducir en el ordenador una ima-
gen no digital, como obtener directamente imágenes digitales así como qué
son y donde encontrar álbumes de imágenes digitales.
Cuando se tiene que archivar una imagen digitalizada, se puede elegir
entre más de un par de docenas de formatos gráficos diferentes. A todos ellos
se les identifica por las tres letras de su extensión. La mayoría de los progra-
mas actuales para retoque de fotografías, dibujo, ilustración cuentan con
diferentes filtros de importación y exportación para trabajar con diferentes
formatos.
Cuando se preparan archivos de sonido para utilizarlos en el Web hay que
tener en cuenta que no siempre hay que utilizar la mayor profundidad de
muestreo ni la mayor frecuencia de muestreo posibles. Cuanto mayores sean
estos dos parámetros más espacio se requerirá para almacenar ese sonido.
Por ello, será necesario decidir si se desea sacrificar espacio de disco y anchu-
ra de banda para aumentar la calidad de los archivos de sonido. Además, esa
frecuencia sólo debe utilizarse en las muestras de alta calidad. Si un archivo
de sonido sólo contiene voz, será suficiente utilizar 8 bits y 8 kHz.
Las muestras de sonido, al igual que sucede con los formatos destinados
a gráficos, pueden ser transportadas en varios tipos de archivos. Su varie-
dad no es tan grande como sucede con los formatos gráficos, pero todos
ellos contienen una serie de parámetros comunes que informan de la fre-
cuencia de muestreo empleada en la grabación, del número de canales de la
muestra, de los bits de cuantificación digital y de otros datos importantes
sobre bucles de repetición (loops) e información adicional por citar tan sólo
dos ejemplos.
Finalmente, se recomienda al lector que quiera profundizar en los con-
tenidos de este capítulo la referencia (Castro y otros, 2002).

2.1. Indicar cuál de las siguientes afirmaciones no es correcta:
a) La diferencia básica entre un hipertexto y un texto tradicional es la natura-
leza exclusivamente secuencial de la información que presenta este último.
b) Se entiende por hipertexto un texto interactivo que incorpora otros
elementos que no son propiamente texto.
c) Las denominadas «palabras calientes» juegan un papel clave en el
hipertexto.
d) Un hipertexto no debe estructurarse jerárquicamente, pues así se
facilita la entrada a éste por múltiples puntos del documento final,
flexibilizando su uso para posteriores aplicaciones.
2.2. Cuando se desea volcar al ordenador una imagen contenida en un papel

debe recurrirse a:
a) Los Clip-Arts.
b) El escáner.
c) Las Cámaras digitales fotográficas.
d) La tarjeta de imagen XWZ.
2.3. El formato más utilizado actualmente en Internet y es muy válido para

crear fotografías de alta calidad, color verdadero y un tamaño reducido.
Ideal para el almacenamiento masivo de imágenes. Que admite unos
grados de compresión muy elevados es:
a) BMP
b) TIFF
c) JPEG
d) GIF
2.4. Los archivos donde se almacenan digitalizados el formato de Microsoft

e IBM que puede guardar sonido estéreo o mono, con 8 o 16 bits, estos
sonidos tienen, en sistemas PC, la extensión:
a) WAV.
b) MIDI.
c) MP3.
d) RealAudio.
2.5. Al principio de cada fichero WAV está almacenada la información que lo

va a caracterizar, y viene representada por 4 parámetros:
a) Duración temporal, frecuencia de muestreo, resolución y grabación

mono o estéreo.
b) Extensión del fichero, frecuencia de muestreo, resolución y graba-
ción mono o estéreo.
c) Duración temporal, frecuencia de muestreo, propiedades y grabación
mono o estéreo.
d) Fecha de creación, frecuencia de muestreo, resolución y grabación
mono o estéreo.

BOOM (1987): M. Boom. Música con Midi. Microsoft Press.
CASTRO y otros (1996): M. Castro. Comparación de Técnicas y Herramientas de Autor
para la Generación de Aplicaciones Educativas. II Congreso de Tecnologías Apli-
cadas a la Enseñanza de la Electrónica, Sevilla.
CASTRO y otros (1999): M. Castro. Herramientas Hipermedia y/o Multimedia en Los
Procesos de Enseñanza/Aprendizaje en la Educación Superior a Distancia. 8º
Encuentro Iberoamericano de Educación Superior a Distancia. Quito-Ecuador
del 22 al 24 de julio de 1999.
CASTRO y otros (2002): M. Castro. Diseño y desarrollo multimedia: Sistema, imagen,
COLMENAR (1999): A. Colmenar. M. Castro, y J. Peire. Aplicaciones Didácticas de los
Sistemas Multimedia en la Enseñanza a Distancia. 8º Encuentro Iberoamerica-
no de Educación Superior a Distancia. Quito-Ecuador del 22 al 24 de julio de
1999.
COLMENAR (1999): A. Colmenar. Propuesta de Diseño Curricular en un Marco Cons-
las Energías Renovables. Tesis Doctoral. UNED, 1999.
DE FURIA (1987): S. De Furia, y J. Scaciaferro. El Sistema Exclusivo MIDI. Third Earth
Publishing Inc, 1987
DE FURIA (1986): S. De Furia, y J. Scaciaferro. Implementación Midi. Third Earth
Publishing Inc, 1986.
DE FURIA (1987): S. De Furia, y J. Scaciaferro. The Midi Resource Book. Third Earth
Publishing Inc, 1987.
EICHE (1990): J. F. Eiche. Qué es MIDI. Hal Leonard Publishing Co. 1990.
FARALL (1993): J. Farall . Midi, Sintes, Samplers... y algo más. Ricordi, 1993.
GARCÍA (1983): L. García. Los Medios Audiovisuales al Servicio de la Enseñanza.
Madrid: Servicio de Publicaciones del ICE de la Universidad Politécnica de
Madrid, 1983.
HAUS (1993): G. Haus. Procesamiento de música. A-R Editions, Inc., 1993.
HECQUET (1990): A. Hecquet. Entorno Midi. Ra-Ma, 1990.

IGLESIAS (2002): P. Iglesias. Postproducción digital de sonido por ordenador. RA-MA,
2002.
MORATA (1998): R. Morata y D. Insa, Multimedia e Internet. Ed. Paraninfo, 1998.
PENFOLD (1992): R.A. Penfold. Midi Avanzado, guía del usuario. RA-MA, 1992.
YAVELOW (1992): C. Yavelow. La Biblia de la música y el sonido. IDG Books, 1992.

Capítulo 3
MEDIOS: ANIMACIÓN Y VÍDEO
ESQUEMA
3.1. Las animaciones. Principios, herramientas y técnicas de animación.

3.2. Imágenes en 3 dimensiones. Creación y animación.
3.3. Elementos básicos para comenzar a digitalizar vídeo.
3.4. Edición y efectos del vídeo digital.
3.5. Resumen.
Actualmente es posible disponer de buenos paquetes de software infor-
mático de animación que realizan en cuestión de segundos muchas de las
pesadas tareas que en épocas no muy lejanas tenían que realizar varias per-
sonas durante semanas o meses. Además, el software de animación por
ordenador proporciona todas las ventajas de la edición digital. Dentro del
primer apartado de este capítulo, se describen algunos principios y termi-
nología básica de animación, incluidos aspectos específicos de animación
informática.
Uno de los medios digitales que más tarde se ha incorporado al mundo
multimedia, principalmente motivado por su complejidad de creación y la
gran cantidad de recursos que consume del ordenador, son las imágenes en
tres dimensiones. Cuando se combinan imágenes 3D con animaciones, se
pueden conseguir interfaces más intuitivas y fáciles de usar, a la vez que se
consigue mejorar las posibilidades de transmisión de información al usuario.
Una imagen o animación 3D puede proporcionar vistas alternativas de una
estructura compleja, como por ejemplo una escultura, una pieza mecánica,
un corazón, etc., además de añadir atractivo visual a las páginas. En el apar-
tado Imágenes en tres dimensiones. Creación y animación se van a desarrollar
las formas de crear tridimensionalidad, así como una ligera iniciación al
mundo de la animación 3D. En sus apartados se trata el proceso de modela-
do, animación, render y composición, y proporcionan algunos consejos sobre
la creación de gráficos y animación 3D para la Web. Todos estos aspectos son
tratados en la sección 3.2.
Con el estado actual de la tecnología, cualquier usuario con un PC y una
vídeocámara puede realizar su aportación al mundo de la edición de vídeo.
En el tercer apartado, Elementos básicos para comenzar a digitalizar vídeo, se
presentan los conceptos básicos a tener en cuenta antes de adentrarse en el
mundo de la edición del vídeo digital, y ya en el cuarto apartado de este tema
Edición y efectos del vídeo digital se expone una visión del mundo de la edi-
ción de vídeo digital de forma que le permita decidir si quiere adentrarse o no
en su aprendizaje.
3.1. LAS ANIMACIONES. PRINCIPIOS, HERRAMIENTAS

Y TÉCNICAS DE ANIMACIÓN
3.1.1. Animación en celuloide

El término celuloide hace referencia a la película transparente que se uti-
lizaba en la animación tradicional dibujada a mano. En la actualidad, esta
película transparente es de acetato (figura 3.1).
La animación se dibuja en diferentes acetatos o celuloides que, por lo
general, se superponen para producir un solo cuadro de animación. Existe un
celuloide para la capa de fondo y otro para cada objeto que se mueve de for-
ma independiente sobre el fondo.
Esta superposición de capas le permite al animador aislar y volver a dibu-
jar las partes de la imagen que cambian entre cuadros sucesivos. Un cuadro
consta del celuloide de fondo y de los superpuestos. El hecho de dibujar sobre
acetato, permite al animador disponer sucesivos cuadros, uno encima de
otro, y ver al instante cómo progresa la animación en el tiempo. Muchos de
los procesos y la terminología de la animación tradicional basada en celuloi-
de se han llevado a la animación por ordenador.
FIGURA 3.1. Ejemplo de técnica de animación por superposición de acetatos.

MEDIOS: ANIMACIÓN Y VÍDEO 71
3.1.2. Animación en cuadros

Es la forma más sencilla de visualizar animación, significa mostrar una
secuencia de archivos gráficos para producir la ilusión de movimiento. Las
imágenes gráficas se muestran en una rápida sucesión, cada imagen es lige-
ramente diferente de la anterior. Las imágenes gráficas se muestran tan rápi-
damente que la persona que las visualiza piensa que percibe una imagen en
movimiento. En las películas, son 24 imágenes o cuadros por segundo, pero
en una aplicación multimedia se puede reducir a 16. Para reproducirlo en un
ordenador, cada archivo gráfico tiene que estar «pintado» en la pantalla para
cada cuadro de animación (figura 3.2).
Tanto Shockwave de Macromedia como QuickTime de Apple Computer,
así como la mayor parte del software de animación actualmente en el merca-
do utilizan varios algoritmos para comprimir archivos, de modo que en lugar
de tener que actualizar toda la pantalla para cada cuadro, como tendría que
hacerse en este tipo de animación basada en cuadros, sólo tienen que actua-
lizar las partes de la pantalla que hayan cambiado entre cuadros. Esta com-
presión lleva a tamaños más pequeños de archivos y a una reproducción más
rápida.
3.1.3. Animación de sprites, trayectorias y vectores

La animación basada en sprites es muy similar a la técnica tradicional de
animación donde un objeto se superpone y anima sobre un gráfico de fondo
estático, es muy común en programas de animación por ordenador. Un spri-
te es cualquier parte de la animación que se mueve de forma independiente,
FIGURA 3.2. Animación de un objeto 3D con la técnica de cuadros.

FIGURA 3.3. Animación a base de sprites en la herramienta de creación Director.
como por ejemplo un niño corriendo o un planeta en rotación. Cada sprite se

mueve como un objeto independiente y se puede animar en un lugar fijo,
como en el caso del planeta en rotación, o moverse a lo largo de una trayec-
toria, como en el caso de un niño corriendo.
Los requisitos de tamaño de archivos y ancho de banda para animación
basada en sprite son, por lo general, menores que para la animación basada
en cuadros, ya que se diferencian en que no tiene que actualizar toda la pan-
talla para cada cuadro, como sucede con la animación basada en cuadros, en
la animación sprite sólo se actualiza la parte de la pantalla que lo contiene.
En ocasiones la animación sprite se denomina animación basada en tra-
yectorias ya que agrega un sprite a una trayectoria en movimiento, consiste
en una curva dibujada entre las posiciones del sprite en cuadros sucesivos. El
sprite u objeto animado se mueve por esta trayectoria durante el proceso de la
animación. El objeto animado puede ser un sencillo bitmap que no cambia o
puede ser una serie de bitmaps que forman un bucle o ciclo de animación.
Por ejemplo, se podría crear un bucle de animación que contenga tres o
cuatro cuadros de un niño caminando. La trayectoria del niño caminando es
su trayectoria de movimiento; cuando se anime, se podrá ver al niño movien-

do sus piernas a medida que se desplaza por la pantalla. La mayor parte del
software de animación por ordenador le permite crear bucles de animación
de este tipo.
Cuando los objetos se mueven, por lo general, no siguen una línea recta;
como tal, las trayectorias de movimiento son más creíbles si son curvas. Los
programas de animación por ordenador normalmente le permiten crear tra-
yectorias de movimiento curvas basadas en splines. Los splines son repre-
sentaciones matemáticas de una curva. Para definir curvas basadas en spline,
primero tiene que situar una serie de puntos ancla. La curva pasa por esos
puntos, que definen el principio y fin de las diferentes partes de la curva. Cada
punto ancla posee unas manillas de control que le permiten cambiar la forma
de la curva entre dos puntos. La figura 3.4 muestra una trayectoria en movi-
miento basada en spline para una animación de un avión de caza a reacción.
FIGURA 3.4. Animaciones basadas en trayectorias curvas o splines.
Hoy son muchos los programas de animación que permiten cambiar el

índice de movimiento a lo largo de la trayectoria. Si una trayectoria en movi-
miento tiene una curva muy cerrada, por ejemplo, un objeto disminuye la
velocidad a medida que se acerca a la curva y acelera cuando sale de ella.
Algunos programas proporcionan un sofisticado control de la velocidad en
las trayectorias.
Similar a la animación sprite basada en bitmap resulta la animación
basada en vectores. En lugar de utilizar bitmaps para los sprites, los pro-
gramas basados en vectores utilizan fórmulas matemáticas para describirlos.
Estas fórmulas son similares a las fórmulas que describen curvas spline.
Puesto que los objetos son fórmulas matemáticas, no bitmaps, el tamaño de
los archivos es mucho menor. Otra ventaja de la animación basada en vecto-

res es que los gráficos se pueden presentar a escala; es decir, se pueden agran-
dar sin que presenten distorsiones.
3.1.4. Índice de Cuadro

El número de cuadros por segundo de animación se expresa con el deno-
minado índice del cuadro. Estos índices para películas son de 24 cuadros por
segundo, para vídeo de 30 y se puede reducir hasta 12 cuadros por segundo
para aplicaciones multimedia. El índice mínimo de cuadro depende de la ani-
mación. Índices de cuadro de 10 a 15 cuadros por segundo presentan, por lo
general, resultados aceptables.
3.1.5. Puntos clave de trayectoria o extrusión

Al proceso de crear cuadros intermedios entre puntos clave se le conoce
como extrusión. En la animación tradicional, los animadores más experi-
mentados dibujaban los cuadros más importantes o los puntos clave de la
trayectoria. Estos cuadros establecen los puntos principales, definen el flujo
de acción y crean el estilo gráfico de la animación.
FIGURA 3.5. Técnica de animación por extrusión o por creación de puntos clave
de la trayectoria.
Actualmente, el ordenador generará la mayor parte de los cuadros inter-

medios, lo único que el usuario debe hacer es crear los puntos clave. En el
ordenador, el usuario sitúa los puntos clave a lo largo de una línea de tiempo.
La distancia entre los puntos clave en esa línea determina la cantidad de
tiempo entre ellos, y a su vez, el tiempo entre los puntos clave determina el
número de cuadros intermedios que se generan. Si el índice de cuadro es de
diez cuadros por segundo, por ejemplo, y se tiene un punto clave a 1 y el
segundo a 3, el ordenador genera 20 cuadros intermedios.
3.1.6. Animación de personajes
Este tipo de animación es la que se puede ver, por lo general, en los dibu-
jos animados, es un tipo especial de animación. Se diferencia del resto de
tipos de animación, como por ejemplo gráficos en movimiento o logos ani-
mados, en el hecho de que implica formas orgánicas complejas con múltiples
movimientos secundarios y jerárquicos. En el simple movimiento de un per-
sonaje animado que hable, además de la boca, se mueven los ojos, la cara y
las manos al mismo tiempo. Aunque es relativamente sencillo animar un solo
bitmap en el tiempo, animar un personaje es casi un arte y conlleva una con-
siderable cantidad de trabajo. Muchas de estas técnicas se presentan más
adelante en este mismo apartado.
3.1.7. Pistas y secuenciadores de animación
Un buen programa de animación por ordenador proporciona múltiples

capas que se pueden utilizar para crear una animación. Cada objeto ani-
mado se sitúa en su propia capa. La figura 3.6 ilustra las capas y el inter-
faz de usuario de la base de datos de Macromedia Director. Los objetos
animados de ésta se sitúan en la escena. La mayor parte del software de
animación por ordenador utiliza una línea de tiempo basada en pistas o un
secuenciador para la coreografía de la animación. Esta línea de tiempo
basada en pistas y secuenciador proporciona una visión preliminar de la
animación.
Cada pista representa una propiedad que se anima con el tiempo. La pis-
ta contiene el punto clave e información de la animación para esa propiedad.
Cada objeto individual puede tener asociadas varias pistas de animación; un
solo objeto puede tener una pista separada para cada uno de los parámetros
que varían con el paso del tiempo, como por ejemplo la posición, tamaño,
forma, velocidad o propiedades de la superficie. Se puede crear un punto cla-
ve al elegir un punto en la línea de tiempo y luego elegir un valor para un
parámetro que varíe con el tiempo, como por ejemplo la posición o color. El
ordenador genera cuadros intermedios entre los puntos clave interpolando
los valores para los parámetros especificados.
FIGURA 3.6. Técnica de animación de personaje en Director.
3.1.8. Técnicas de animación

Se analizan a continuación algunas de las técnicas más utilizadas en ani-
mación:
• Piel de cebolla.
• Recortes.
• Deceleración/aceleración y curvas de velocidad.
• Acción secundaria y acción sobrepuesta.
• Línea de acción.
• Exageración.
No existen reglas mejores ni peores; la técnica que funcione mejor depen-
derá de la animación concreta y de los objetivos del diseño. Estas técnicas
incluyen formas de dibujar animaciones y formas de realizar su coreografía.
a) Piel de cebolla
Muchos programas de animación en dos dimensiones tales como Macro-

media Director, Fractal Design Painter y CelAnimator de FutureWave soportan
la piel de cebolla. Incluso se pueden utilizar las características de capas y trans-
parencia en programas de proceso de imágenes como Photoshop para simular-
lo. Es una técnica de dibujo tramada prestada de la animación tradicional de
celuloide que ayuda al animador a crear la ilusión de movimiento. En la anima-
ción tradicional, cada cuadro se dibuja en capas de acetato o celuloide transpa-
rente. En lugar de trabajar en cada cuadro por separado, los animadores sitúan
estos celuloides transparentes uno encima del otro. Este hecho les permite ver
los cuadros anteriores y posteriores a medida que dibujan el cuadro actual.
b) Recortes
Los recortes de animación son otra técnica tomada prestada de la anima-

ción tradicional de celuloide. Cuando el movimiento de un personaje está limi-
tado, por ejemplo, a decir hola con la mano, es más sencillo volver a dibujar la
mano y el brazo que dibujar de nuevo todo el personaje para cada cuadro.
El personaje se puede dibujar una vez y utilizarlo como fondo. Los gráfi-
cos independientes de la mano por separado o recortes se componen en la
figura del fondo para simular movimiento. Un ejemplo de recortes para dife-
rentes posiciones del brazo y la mano se muestran en la figura 3.7. Esta téc-
nica es de utilidad a la hora de animar movimiento limitado como, por ejem-
plo, los movimientos de la boca durante los diálogos.
c) Deceleración/Aceleración y curvas de velocidad
En el mundo real, los objetos, por lo general, no se mueven a una veloci-

dad constante, sino que se ven afectados por la gravedad. Una moto de carre-
ras disminuye la velocidad al acercarse a una curva y acelera cuando sale de
ella. Una transición entre un estado de movimiento y otro, como por ejemplo,
ponerse en marcha, detenerse o girar, se presenta, por lo general, como un
punto clave. Esta reducción y aceleración a medida que los objetos se acercan
y alejan de los puntos clave se denomina disminuir y acelerar.
Estos cambios de velocidad se pueden establecer a mano. Los movimien-
tos lentos poseen cambios pequeños entre cuadros, mientras que los movi-
mientos rápidos tienen mayores cambios. Las transiciones entre un estado de
FIGURA 3.7. Animación de recortes. En este ejemplo se muestran y se esconden diversas

posiciones de la mano del tenista para simular el movimiento.
movimiento y otro son difíciles de establecer de forma suavizada aunque,

afortunadamente, los ordenadores pueden ayudar en parte.
d) Aplastar y estirar
Es otra técnica muy utilizada que se basa en aplastar el objeto y estirarlo

en la dirección del movimiento, como si fuera de goma. Es una forma de dar
la sensación de peso.
FIGURA 3.8. Ejemplo de técnica de animación por estirado y aplastamiento del objeto.
3.2. IMÁGENES EN 3 DIMENSIONES. CREACIÓN

Y ANIMACIÓN
3.2.1. Programas de 2D para crear 3D

La forma más sencilla de crear imágenes 3D es a partir de una imagen
plana o 2D y añadirle dimensionalidad. Hoy casi todos los programas de dise-
ño 2D incluyen herramientas para agregar sombras, texturas, efectos de ilu-
minación y superficies de relieve, que producen un efecto de tridimensionali-
dad a objetos planos. Los objetos 3D más sencillos que pueden crearse son
dar relieve a texto plano y crear botones de acción en 3D jugando con mapas
de relieve e iluminación del objeto plano.
Existen otros métodos sencillos para dar tridimensionalidad como son la
posibilidad de dar perspectiva a figuras planas, añadir contornos concéntri-
cos, técnicas de golpeo y apretamiento, etc.
FIGURA 3.9. Creación de un elemento de tres dimensiones a partir de uno de dos.
3.2.2. Programas para crear gráficos 3D

Son diferentes las tareas de un proceso de creación de gráficos 3D:
• En la tarea de modelado, se crea la estructura básica de sus objetos y
se sitúa en un mundo 3D.
• En la de animación, por lo general, se asignan diferentes posiciones de
puntos claves de trayectoria a los objetos en una línea de tiempo. El
ordenador genera cuadros intermedios entre esos puntos clave (extru-
sión) para simular movimiento en su mundo 3D, y realiza todo el tra-
bajo de crear perspectiva, iluminación, sombras y efectos ambientales.
Esta tarea es similar a la animación de puntos clave en programas de
animación 2D, pero más potente.
• En el render, el ordenador pinta su mundo 3D en función de la ilumi-
nación, propiedades del material y vistas de la cámara que ha creado.
Las propiedades del material definen el color, textura y propiedades de
superficie de un objeto. Las luces y los efectos atmosféricos definen el
entorno de su mundo.
• La tarea final es unir o componer gráficos 3D con otros elementos grá-
ficos utilizando programas como Photoshop, Debabeiizer, Director,
AfterEffects o Premiere.
Diseñar un mundo 3D no es un proceso sencillo, lineal, paso a paso, sino que,
por lo general, implica alternar entre el modelado y la animación, realizando ren-
ders de prueba en diferentes puntos para comprobar varios aspectos de su mun-
do, y luego realizar una presentación final de alta calidad que puede llevar
muchos minutos, horas o incluso días. Los procesos de modelado, animación,
render y composición se tratan con detalle más adelante en este mismo apartado.
Los siguientes apartados proporcionan más detalles sobre lo que necesi-
ta, en términos de requisitos de sistema y software, para crear gráficos 3D.
3.2.3. Requisitos de sistema para 3D

Los programas gráficos en tres dimensiones requieren mucha memoria
RAM y disco duro. Cuanto más complejos sean los modelos y animaciones, y
cuantos más mapas de textura se utilicen, más memoria se necesitará. Además
se puede tener abiertos otros programas, como Photoshop, mientras se trabaja
en el programa 3D, lo que supone más memoria. Es decir, se tendrá que dispo-
ner de tanta memoria como pueda. Igualmente sucede con la capacidad de
cálculo del ordenador, deberá ser tan rápida como sea posible. También se nece-
sita mucho espacio en disco ya que, por regla general, una animación 3D de 1
MB puede generar fácilmente 10 MB de archivos intermedios.
3.2.4. Software 3D
Como se ha mencionado anteriormente, el proceso de diseño en 3D impli-
ca varias tareas. Estas tareas son el modelado, animación, render y composi-
ción. Los programas de software en tres dimensiones gestionan una o más de
estas tareas.
FIGURA 3.10. Pantalla de trabajo de la aplicación 3D.

Macromedia Extreme 3D, Specular Inflni-D, VIDI Presenter Pro, Lightwa-

ve 3D, Ray Dream, Designer Studio y Caligari Truespace son programas inte-
grados que proporcionan una mezcla de modelado, animación y render. Virtus
Walkthrough Pro, Gryphon Morph, el Valls Group PixclPutty y Metaflo pro-
porcionan características especializadas de modelado, animación o render.
Specular Logomotion, CorelMotion3D, Crystal Flying Fonts y Strata Stra-
taType son programas asequibles para crear y animar elementos 3D. Fractal
Design Poser es una herramienta para el modelado y render de formas huma-
nas. Incluso si se está utilizando un programa 3D integrado como Extreme
3D o Studio Pro, se puede intercambiar archivos entre diferentes programas
3D y 2D durante el proceso de producción.
El programa 3D que se elija debería ser capaz de exportar animaciones
como películas QuickTime, una secuencia de archivos PICT numerados,
archivos BMP o archivos TARGA. PICs es un formato común para exportar
animación. También se debería soportar importar/exportar el formato DXF
de AutoCAD, utilizado para intercambiar modelos 3D entre diferentes pro-
gramas EPS o EPSF que permite importar curvas Bézier 2D y gráficos de pro-
gramas como FrceHand e Illustrator.
FIGURA 3.11. Pantalla de trabajo de la aplicación de modelo 3D, 3D Studio MAX.

3.2.5. Cómo funciona el mundo 3D

En programas 3D, se agrega una tercera dimensión respecto a los progra-
mas 2D (en los que la pantalla está dividida en X e Y) por medio de un tercer
eje Z. Muchos programas permiten posicionar y alinear objetos con una pre-
cisión CAD dentro de este sistema de coordenadas 3D.
Se puede visualizar un mundo 3D por medio de una ventana en la panta-
lla del ordenador. Esta vista tiene parámetros que se pueden editar como la
perspectiva y la orientación. En un principio, es muy fácil desorientarse a
medida que se construye un mundo 3D, por lo tanto es aconsejable ajustarse
al conjunto de vistas por defecto.
3.2.6. Modelado
Muchos programas 3D proporcionan un conjunto de formas básicas, como
por ejemplo el cubo, la esfera y el cono, que se pueden utilizar para crear mode-
los más complejos. La mayor parte de los programas 3D proporcionan un con-
junto de herramientas para construir modelos 3D a partir de perfiles 2D. Mode-
lar es el proceso que se utiliza para construir los objetos 3D o modelos y crear
la estructura básica de un mundo 3D (también denominado un modelo). Los
modelos se construyen a partir de curvas Bézier. Se puede posicionar objetos
en su mundo 3D por medio del ratón o al introducir coordenadas 3D. Muchos
programas permiten situar un objeto en unos puntos precisos en el mundo 3D.
Puesto que algunas veces, puede ser difícil decir dónde se encuentra un objeto
dentro del sistema de coordenadas 3D, cuando se cree un objeto, quizá sea más
sencillo alinearlo a los puntos (0,0,0) en su mundo y luego moverlo a lo largo de
los ejes (X, Y y Z) para saber cómo se orienta el objeto en el espacio 3D.
3.2.7. Animación
La animación se crea a partir de una secuencia de imágenes fijas o cua-
dros que se reproducen rápidamente en sucesión, de modo que el ojo lo per-
cibe como un movimiento continuo.
FIGURA 3.12. Dos perspectivas de un modelo 3D básico.

Los programas de tres dimensiones con posibilidades de animación, nor-

malmente utilizan una línea de tiempo basada en puntos claves de trayecto-
ria. El ordenador calcula todos los cuadros intermedios entre los puntos cla-
ves. Existen programas en los que se pueden animar casi todas las
propiedades editables, incluidos los mapas de texturas y vértices individua-
les, o controlar puntos. Las trayectorias de movimiento son curvas editables.
Los formatos de salida más habituales para las animaciones 3D son las
secuencias de Bitmaps o como películas de formato QuickTime.
3.2.8. Sombras y luces

Para conseguir que un mundo 3D parezca real, hay que asignar diferen-
tes propiedades de material a los objetos, y crear luces y efectos atmosféricos.
Iluminar un mundo 3D es similar a iluminar una escena o una parte de una
película, con la excepción de que se pueden situar las luces en cualquier lugar
en el espacio 3D y se pueden cambiar fácilmente las propiedades de cada luz.
Las fuentes de luz en programas 3D incluyen luces distantes, focos de luz y
luces de ambiente.
Las luces distantes simulan el sol y arrojan rayos de luz paralelos; los
focos de luz son, por lo general, luces en forma de cono que enfocan puntos
específicos, y la luz de ambiente es la luz global que inunda la escena desde
todas las direcciones. Las luces en el mundo 3D no tienen que seguir las leyes
de la física. Pueden tener luces que no arrojen sombras, y pueden incluso
tener una intensidad negativa.
FIGURA 3.13. Posicionamiento de un foco para iluminar una pieza.

3.2.9. Texturas procedurales y mapas de textura

Las propiedades de superficie de sus objetos 3D reflejan los materiales
con los que están hechos y la iluminación y el ambiente de su mundo 3D. Los
mapas de texturas y las texturas procedurales son dos formas comunes utili-
zadas para simular materiales para sus objetos.
El mapeado de texturas es un proceso que consiste en aplicar una imagen
bitmap, como un archivo PICT, a una superficie 3D. También se pueden animar,
proyectar y situar texturas con orientaciones diferentes, y se puede simular efec-
tos de iluminación y parámetros de transparencia con mapas de texturas. Algu-
nos programas soportan incluso películas QuickTime como mapas de textura.
Las texturas procedurales utilizan ecuaciones matemáticas para gene-
rar propiedades de superficie. Puesto que las texturas procedurales son cálcu-
los matemáticos, no requieren tanto espacio en disco o memoria como los
mapas de textura. Bryce es un programa 3D que utiliza texturas procedurales
para recrear formas y texturas naturales.
3.2.10. Crear texturas

La mayor parte de los programas 3D vienen con librerías de texturas. Se
pueden utilizar programas de creación de texturas dedicados a crear mapas
FIGURA 3.14. Editor de trabajo con texturas para objetos 3D.

de texturas originales para sus modelos 3D. Cualquier bitmap se puede con-
vertir a un mapa de textura.
En lugar de crear detalles complejos en un modelo 3D, hay que dibujar el
aspecto detallado que se desea en un programa 2D y luego importarlo como
un mapa de textura a su programa 3D. Escanear y capturar vídeo son otras
formas de crear texturas del mundo real.
3.2.11. Diseño del interfaz 3D

Los botones y los cuadros de diálogo se han convertido en algo común en
los interfaces de usuario. Los gráficos en tres dimensiones se inclinan por el
sentido táctil, lo que aumenta la sensación de encontrarse directamente
manipulando objetos en la pantalla del ordenador.
Un interfaz de usuario 3D bien diseñado ofrece una impresión visual más
clara de sus funciones. El diseño de un interfaz de usuario en tres dimensio-
nes utiliza los mismos principios que el diseño del interfaz de usuario 2D.
Aquí tiene algunos consejos para su diseño:
FIGURA 3.15. Ejemplo de un Interfaz con inclusión de elementos y sistema de navegación 3D.
• Cuando cree interfaces 3D, no sobrecargue el contenido con texturas

suntuosas.
• No compita con las dimensiones de otros elementos 3D en la pan-

talla.
• Reduzca la altura de los objetos del interfaz 3D a dos o tres capas.
• Evite los botones demasiado juntos.
• Suavice el rango tonal de sombras y luces en el interfaz. Simplemente

una diferencia de un diez por ciento en los valores de grises de sombras
e iluminación es suficiente para proporcionar la impresión de una ter-
cera dimensión.
• Utilice luces paralelas (luces distantes en Extreme 3D) especialmente si

necesita reducir su interfaz a varios colores.
• Utilice posiciones numéricas de objetos.
3.2.12. Render
El render es el proceso que utiliza el ordenador para generar una imagen,

basado en todas las propiedades, posiciones, luces y modelos del material
que tiene en su mundo 3D. Los métodos de mayor calidad llevan mayor can-
tidad de tiempo. Existen diferentes métodos de render:
• Bounding box.
• Wireframe.
• Flat-shading.
• Gourand shading. Ray-tracing y sombreado Phong.
• El render interactivo es el render utilizado para mostrar su mundo 3D

en pantalla mientras trabaja en él.
3.2.13. Composición
La composición es el proceso de unir diferentes elementos gráficos en

una sola imagen o animación. Algunas veces es mejor realizar el render de
objetos y animaciones 3D por separado.
La composición le permite agregar diferentes fondos, cambiar las trayec-
torias de movimiento o agregar y eliminar elementos individuales sin tener
que volver a realizar el render de toda la escena.
3.2.14. Fondos 3D
Una forma sencilla de agregar dimensionalidad a una aplicación es utili-

zar un fondo 3D. Si crea su fondo como un modelo en un programa 3D, resul-
ta sencillo cambiar la perspectiva, iluminación y efectos atmosféricos o reali-
zar un render de diferentes partes de la escena por separado.
Establezca una perspectiva interesante para su fondo al utilizar los pará-
metros de la cámara y las vistas en el programa 3D. Evite superficies planas
paralelas a la pantalla del ordenador. La iluminación en un ángulo bajo y las
sombras también pueden agregar un sentido de profundidad. Una técnica
sencilla, como agregar un desenfoque gaussiano a la capa de fondo, crea una
sensación de profundidad en la escena. Asegúrese que el fondo no compite
visualmente con el contenido del interfaz y que tiene un estilo gráfico similar
al resto del proyecto.
3.2.15. Objetos 3D
Cuando componga elementos 3D que se han generado por separado, es

importante que posean una consistencia de estilo para que los elementos no
parezcan estar fuera de lugar. Siga estas directrices:
• Todos los elementos deberían estar iluminados desde la misma direc-
ción.
• Las luces deberían ser de una intensidad y color similar.
• Los parámetros de entorno global, como la luz ambiental y la niebla,
deberían ser los mismos en los gráficos 3D generados, a menos que esté
diseñando para conseguir un determinado efecto.
• Utilizar colores y propiedades de superficie similares para asignar a sus
gráficos una unidad de estilo.
• Antes de iniciar el render, determine el orden de las capas de sus gráfi-
cos 3D y planifique la composición de acuerdo a ello.
• Decida, en un principio, cómo desea componer las sombras: ¿Desea
generar las sombras con el objeto 3D, agregarlas más tarde como una
capa aparte, o dibujarlas directamente en el fondo con alguna herra-
mienta?
Es una buena idea generar sus imágenes 3D con unas dimensiones más
grandes que lo que vaya a necesitar, y luego cambiar el tamaño de la imagen
a las dimensiones que desea para su proyecto. La calidad de los gráficos que
se cambian de tamaño es mejor si empieza con un gráfico grande y luego
reduce el tamaño, en lugar de empezar con uno pequeño.
FIGURA 3.16. Detalle del cuadro de opciones de renderización de la aplicación

3D Studio MAX.
3.3. ELEMENTOS BÁSICOS PARA COMENZAR

A DIGITALIZAR VÍDEO
3.3.1. Conceptos técnicos

La Cinta: Para grabar las señales de vídeo se emplea la denominada cin-
ta magnética, consiste en un soporte de poliéster recubierto por partículas de
compuestos férricos dispersos en un adhesivo. Las de óxido de cobalto de alta
energía son las de mayor nivel de calidad.
El Vídeo: El vídeo es un sistema dedicado al almacenamiento de imáge-
nes en movimiento y sonidos sincronizados para su posterior reproducción
tantas veces como se desee. La edición de vídeo digital no es otra cosa que el
paso de las señales de vídeo analógicas a señales de vídeo digitales. A conti-
nuación, se detallan ambos tipos de señales:
— Vídeo analógico: Cada fotograma se representa por una señal fluc-
tuante de voltaje, lo que se conoce como una señal de forma de onda
analógica. En el vídeo compuesto todos los componentes de brillo,
color e información de sincronización se combinan en una sola señal.
Como consecuencia de esto la calidad es menor y las pérdidas genera-
cionales mayores.
El vídeo por componentes reduce este problema. En este formato se
toman los distintos componentes de la señal de vídeo y se emiten
como señales separadas. Gracias a estas mejoras surgió el nacimiento

de formatos como S-Vídeo y RGB.
— Vídeo digital: Es una representación digital de la señal analógica (la
información va en forma de bits). Adicionalmente el vídeo digital pue-
de exportarse a cinta analógica para su uso en los reproductores tra-
dicionales. La señal, a diferencia del vídeo analógico, no se degrada en
calidad de una generación a otra. Utilizar el ordenador para el vídeo
digital aporta muchas ventajas, ya que se puede acceder aleatoria-
mente a las películas almacenadas y se pueden comprimir (con el aho-
rro de espacio de almacenamiento que esto conlleva).
Diferentes tipos de ediciones de vídeo: En general, la edición de vídeo
analógico conlleva una «destrucción» del original, es decir, que cualquier
modificación que se realice durante la edición sobre el original hace que éste
cambie y, por tanto, se destruya su estado inicial. En la edición de vídeo digi-
tal no se destruye el original. Los efectos, alteraciones, recortes y cambios
que se apliquen a un corte de vídeo para utilizarlo en un proyecto determina-
do no afectan al vídeo a partir del cual se está trabajando. Los términos des-
tructivo/no destructivo definen el tipo de procedimiento que se utiliza para
editar el vídeo.
Fotogramas o Frames: Estos términos (en español y en inglés) se van a
manejar continuamente a la hora de editar vídeo. Hacen referencia a las imá-
genes fijas que se muestran a lo largo de un segundo de película (ya sea vídeo o
televisión). Existen varios estándares de televisión y cada uno de ellos se basa
en una cantidad de frames o fotogramas emitidos por segundo (figura 3.17).
El ordenador y la televisión no manejan el vídeo de igual manera. A con-
tinuación, se establece la diferencia entre vídeo no entrelazado y entrelazado:
— Vídeo no entrelazado: El monitor del ordenador suele utilizar un pro-
ceso denominado «escaneado progresivo» para actualizar la informa-
ción que muestra la pantalla. De forma que en el fotograma se mues-
tran todas las líneas de la imagen.
— Vídeo entrelazado: Cada uno de los fotogramas o frames queda divi-
dido en dos campos, uno de ellos contiene las líneas pares y el otro las
impares de la imagen. En televisión, primero se muestra el primer
campo (es decir, las líneas pares) y después el segundo, percibiendo el
ojo la imagen completa.
La Secuencia: Se denomina secuencia a la sucesión ininterrumpida de
escenas o planos que integran una etapa descriptiva, una etapa de la acción o
un tramo coherente y concreto del argumento (figura 3.18).
La Película: Se puede decir que una película es la sucesión de múltiples
secuencias. Cuando se trabaja con archivos de vídeo en el ordenador, se guar-
darán en formato de película, los más comunes son QuickTime, AVI y MPEG.
FIGURA 3.17. Ejemplo de un solo fotograma.
FIGURA 3.18. Ejemplo de una secuencia de fotogramas.
Calidad: Se determina por la relación que existe entre la señal «útil» y

los «ruidos» inherentes al sistema. La calidad en la edición digital depen-
derá de la cantidad de bits que utilice la tarjeta de digitalización para reali-
zar el muestreo de la información analógica. También dependerá la calidad
de las ediciones de vídeo, del sistema de conexión utilizado para unir el dis-
positivo fuente con la tarjeta de digitalización. El tipo de conexión que se
puede encontrar en las tarjetas de digitalización domésticas es RCA y S-
Vídeo.
Resolución: Se refiere a la definición que proporciona en líneas y es un
parámetro fundamental al hablar del vídeo. El grado de definición de una
imagen depende del ancho de banda que pueda manejar el sistema. En Euro-
pa el factor de resolución horizontal es de 80 líneas por cada MHz de señal
tratada. La resolución vertical consiste en la cantidad de líneas de escaneado
horizontales. Debe tener en cuenta que en la industria del vídeo se habla de
resolución horizontal como si la pantalla tuviera la misma anchura que altu-
ra, cuando en realidad suele ofrecer una relación de cuatro tercios, y en el
futuro se apunta este dato hacia la relación 16:9.
Resolución espacial o tamaño de ventana: La resolución espacial, es
decir, el espacio que debe ocupar una imagen en función de su resolución
para que se visualice con la calidad adecuada es el motivo de que existan dife-
rentes tamaños de ventana en el vídeo por ordenador.
En Estados Unidos, NTSC 640 x 480 píxeles, por lo que se ha asumido que
el estándar para el vídeo por ordenador es justo la mitad de esas medidas 320
x 240. Aunque en buena parte de Europa se utiliza el formato PAL, es decir,
de 768 x 576 píxeles de resolución.
Estándares: No se pueden olvidar los diferentes estándares de televisión
que existen: PAL, NTSC y SECAM principalmente. Cada uno trabaja con una
resolución y velocidad distintos y, en el caso de que se quiera volcar de nuevo
a cinta un vídeo una vez editado, se deben conocer dichos parámetros para
que la película pueda ser reproducida en un aparato de vídeo. En España, al
igual que en la mayor parte de Europa Occidental (a excepción de Francia) se
utiliza el denominado PAL (Phase Alternation Line) que consta de 625 líneas
horizontales a una velocidad de 25 fotogramas por segundo.
Luminancia y crominancia: Se trata de las señales referentes a la luz y
el color en la señal de vídeo. Se las denomina también Luma y Croma. La
señal de luminancia suele representarse por una Y, y la de crominancia por
una C (se representa por una V en el caso de utilizar dos canales). Estos dos
parámetros, la luzluminancia y el colorcrominancia, son los principales dife-
renciadores de los distintos tipos de vídeo:
— Vídeo compuesto (Composite vídeo): Toma su nombre del hecho de
que emite el factor luminancia (Y) de una imagen de vídeo y el factor
crominancia (C) como un «compuesto» de ambos. Generalmente la
salida de un reproductor VHS es una señal compuesta (YC).
— Super-vídeo (S-Vídeo): Emite el vídeo separando la luminancia de la
crominancia, lo que permite obtener una mayor resolución.
— RGB (Red, Green, Blue o rojo, verde y azul): Tiene la mejor calidad.
Emite el vídeo en función de una mezcla de las porciones de rojo, ver-
de y azul del espectro visible de luz, en lugar de en función de la lumi-
nancia y la crominancia. Aunque no hay una correlación directa entre
RGB y YUV (uno de los formatos más comunes del color en el vídeo
analógico) ambos tienen varios niveles de profundidad de color (can-
tidad máxima de colores que se pueden mostrar).
Compresión: Se trata del proceso de reducción del tamaño de la infor-
mación digital. La compresión permite almacenar razonablemente grandes
cantidades de vídeo en el disco duro. Existen dos tipos de compresión: con
pérdidas y sin pérdidas. La compresión con pérdidas descarta datos durante
el proceso, por lo que el archivo resultará ser ligeramente diferente cuando
vuelva a abrirse. Esto se logra calculando y desechando la información
redundante, eliminando la información que el ojo humano no es capaz de
detectar.
3.3.2. Los requerimientos del hardware y software

para la digitalización
Lo primero es conectar el aparato reproductor de vídeo o la videocámara
a la tarjeta. Todas las tarjetas deben venir provistas de cables con conectores
para entrada/salida de audio y vídeo, a las que deberá conectar un cable
cuyos contactos sean adecuados a las tomas de la tarjeta.
Seguidamente, debe introducirse la cinta de vídeo que contiene la película
que se desea digitalizar en el aparato de vídeo o videocámara. Conviene posicio-
nar la cinta de vídeo unos segundos antes del punto en el que se quiera comen-
zar a digitalizar para dejar que alcance la velocidad adecuada. De este modo, se
evitará que las cabezas lectoras registren las tensiones que se producen al iniciar
su movimiento, lo cual se suele traducir en ciertas vibraciones en la imagen.
Abrir el Software de edición, en el caso de trabajar con Adobe Premiere, el
programa presentará un cuadro de diálogo de Configuraciones de proyecto
nuevo (figura 3.19). En este cuadro se deberá elegir QuickTime o AVI para el
Modo de edición. Elegir 25 para la Base de tiempo (puesto que se ha elegido
el formato PAL), este menú Base de tiempo especifica los fotogramas por
segundo para la edición. Si se estuviera produciendo la versión final de un
programa de vídeo en formato NTSC, se debería seleccionar 29,97. Hacer clic
en Siguiente para abrir la sección Configuraciones de vídeo del cuadro Con-
figuraciones de proyecto nuevo (figura 3.20).
En tamaño, se debe escribir 240 en el cuadro izquierdo para definir la
anchura del previo. Puesto que la opción Aspecto 4:3 está activada, aparece-
rá automáticamente 180 para la altura de los fotogramas del previo. Esta con-
figuración controla la forma en que se previsualiza el proyecto en el monitor.
En FPS, hay que especificar 15 y hacer clic en Aceptar.
FIGURA 3.19. Cuadro de diálogo de Configuraciones de proyecto nuevo de Premiere.

FIGURA 3.20. Sección Configuraciones de vídeo del cuadro Configuraciones de proyecto nuevo.
Muchas de las configuraciones de proyecto que se acaban de definir

determinan cómo se construirá y se exportará el programa de vídeo. Ahora
Premiere está configurado para trabajar con clips importados.
En el menú Archivo, hay que seleccionar Capturar. Esta opción muestra
un menú desplegable en el que se deberá elegir Captura de clips. Se abrirá
una ventana (con el tamaño que se haya seleccionado) con un único botón en
su parte superior para grabar (figura 3.21).
FIGURA 3.21. Ventana Captura de clips.

3.3.3. Sugerencias para la captura de vídeo

La grabación digital de vídeo de fotograma completo con movimiento
normal requiere un ordenador rápido con mucho espacio en disco. El tama-
ño de los fotogramas, el número de colores y la velocidad de los fotogramas
afectan a la cantidad de datos que deben capturarse y, por lo tanto, la rapidez
y la calidad con la que se puede grabar el vídeo.
A medida que se aumenta de calidad, se aumenta la cantidad de datos
requeridos para representar el vídeo. Los avances recientes en el poder de los
procesadores y en memoria han permitido que los sistemas informáticos de
sobremesa procesen datos con suficiente eficacia para capturar, almacenar y
proyectar vídeo digital.
La posibilidad de capturar el vídeo de la más alta calidad depende del
vídeo de origen y del hardware. Ya que la calidad del vídeo capturado no
superará nunca la calidad del vídeo de origen, debería usar el vídeo de origen
de la más alta calidad posible.
Son varios los factores hardware que afectan a la velocidad máxima de los
fotogramas y al tamaño de imagen que se puede conseguir durante la captu-
ra y la proyección. Seguidamente se abordan para una mayor información
los siguientes temas:
— La velocidad de la tarjeta de captura: A mayor velocidad de la tar-
jeta de vídeo, más velozmente se dibujarán los fotogramas de vídeo en
pantalla. Para capturar vídeo de fotograma completo a 30 fps, la
mayoría de las tarjetas capturan sólo uno de dos campos (la mitad de
las líneas de pantalla) en cada fotograma y replican los datos para
completar el fotograma. La calidad de imagen resulta comprometida.
Para capturar imágenes de tamaño de un cuarto de la pantalla o
menos, este compromiso normalmente no hace falta.
— La velocidad del disco duro: A mayor velocidad del disco duro, más
velozmente podrán leerse y escribir los datos en el ordenador. Para la
captura a 30 fps, se recomienda tener un disco duro con un tiempo de
acceso medio de 10 milisegundos (ms) o menos y una velocidad de
transferencia de datos de 3 MB por segundo o más. Esta velocidad de
transferencia de datos está disponible actualmente con los discos de
5.400 rpm. Como norma general, la velocidad de transferencia de
datos de vídeo será la mitad de la velocidad de transferencia de datos.
Puede conseguir velocidades de transferencia más altas mediante
conexiones especiales SCSI, como las matrices de disco, SCSI II o
SCSI rápido (fast).
— La velocidad de la CPU: Cuanto más rápida sea la CPU, más rápida-
mente podrá el ordenador procesar los datos necesarios para capturar
y proyectar el vídeo digital.
— La capacidad de procesamiento de los datos de la CPU: Durante la

captura, debe asegurarse de que tiene la mayor parte de la CPU dedi-
cada al procesamiento. Esto significa desactivar todas las otras apli-
caciones no necesarias y minimizar todas las ventanas abiertas menos
la de Capturar película. Debería también reducir el tamaño del cache
de disco y asegurarse de que la asignación de memoria virtual no es
más grande que dos veces la cantidad de RAM instalada.
— La velocidad del bus de datos: El bus de datos del ordenador con-
trola la velocidad de transferencia de datos desde el dispositivo de
captura hasta la CPU. Actualmente, los estándares más rápidos de bus
son el VESA Local Bus, o VL-Bus, y el nuevo estándar PCI, que está
disponible en muchos ordenadores Pentium con una placa madre de
Intel. El VESA Local Bus es un bus de 32 bits. El Capturar directa-
mente en memoria.
En muchos ordenadores, el método mejor para la captura de vídeo es
directamente en memoria, RAM. Capturar en memoria RAM es más rápi-
do que capturar en un disco duro, y se recomienda cuando tiene sufi-
ciente memoria libre para almacenar la película capturada. Sin embargo,
el tamaño de la película se limita a la cantidad de memoria libre. La can-
tidad de memoria que necesita depende del tamaño de imagen, velocidad
de fotograma, método de compresión y duración del vídeo capturado.
Experimente con un corte para averiguar si tiene suficiente memoria.
3.4. EDICIÓN Y EFECTOS DEL VÍDEO DIGITAL

Una vez digitalizada la película es posible que los primeros o últimos foto-
gramas no gusten o tal vez se desea conservar únicamente algunas porciones
de todos los segundos grabados. Es posible que los segundos de que dispone
no permitan muchas selecciones, pero en una grabación de algunos minutos
tomada en vacaciones puede que su inicio, medio y final no interesen. Enton-
ces es posible determinar qué partes se quiere mantener, en qué orden se
quiere que vayan y repetir una y otra vez la misma imagen para lograr un
efecto distinto.
Será posible seleccionar un corte para ello se deberá colocar el manejador
en la barra de controles en el fotograma desde el que se quiera comenzar a
seleccionar y después se pulsará el botón Inicio situado a la derecha del área
de estado.
Será preciso después posicionar el manejador en el fotograma en que se
quiera que termine la selección y pulsar Fin. Se podrá observar que las cifras
inferiores del área de estado muestran los segundos y fotogramas seleccionados.
En la parte superior de cada ventana se puede observar una pestaña que indica
que el inicio del corte original no se corresponde con el del seleccionado.
Es preciso arrastrar la ventana de corte a la ventana de Proyecto, esto se

hará una vez seleccionada la porción que se desea añadir al proyecto en primer
lugar. Un cuadro de alerta le preguntará si se quiere guardar el archivo antes de
añadirlo al proyecto. Como se comentó anteriormente, ésta es una de las venta-
jas de algunas aplicaciones: permiten realizar videoedición no destructiva, lo
que significa que el corte originalmente digitalizado quedará intacto a pesar de
todos los cambios que quiera realizar. Hay que pulsar Aceptar y dar al archivo el
nombre y la ubicación que se quiera en el disco duro. A partir de ahora se podrá
ir seleccionando los cortes que se quiera y arrastrarlos a la ventana de Proyecto.
Quedarán automáticamente numerados para poder trabajar con ellos.
Cada uno de los cortes que se hayan arrastrado a la ventana de Proyecto
se irán almacenando en ella. Además quedarán identificados por el número
de corte de que se trate, y se podrá ver una pequeña ventana con la primera
imagen de ese corte e información sobre su duración y resolución.
Seguidamente hay que elegir del menú Ventana la selección Ventana de
construcción y, aparecerá la Ventana de construcción del proyecto. Ésta
cuenta con varias pistas de vídeo, audio y transiciones. Por el momento se
utilizará la primera pista de vídeo que está en la parte superior de la ventana
marcada con la letra A en su borde derecho.
Es necesario arrastrar el corte con el que desee comenzar la película a esta
pista y colocarlo al principio de la misma (a la izquierda). Después debe repa-
tirse con los restantes cortes. Se puede observar en la ventana de Construcción
que, según se coloca un corte sobre ella, distribuye los fotogramas a lo largo
de la pista de vídeo. Si sobrepasan el ancho de la ventana, es conveniente
seleccionar, en su parte inferior, otra medida de nuestra escala en el maneja-
dor hasta que pueda abarcar todo el vídeo en el espacio visual disponible.
Para previsualizar lo que se acaba de construir hay que pulsar Enter o
hacer clic en el botón de la parte superior derecha de la ventana de construc-
ción, marcado con el símbolo de reproducir. Aparecerá la ventana de Visuali-
zación monitor (figura 3.22). Es preciso reproducir la grabación para com-
probar la forma en que quedará finalmente. Una vez que se tenga más
confianza con el proceso de digitalización se podrán realizar más acciones en
la película, hacer cortes, eliminar o duplicar fotogramas, insertar transicio-
nes entre unas secuencias y otras o incluir títulos sobre el vídeo.
3.4.1. El Volcado a cinta de vídeo
Una vez construido el vídeo, podrá ser convertido en una película en una
cinta. Para ello, en el menú Archivo, hay que seleccionar Exportar y se abrirá
un menú desplegable donde se deberá escoger Película (o utilizar la combi-
nación de teclas Ctrl+M) y aparecerá el cuadro de diálogo Exportar película y
hacer clic en Configuraciones.
FIGURA 3.22. Ventana de Visualización monitor.
El cuadro de diálogo Exportar película pedirá que se dé un nombre y una

ubicación al archivo. Además, informará en su parte inferior de la resolución
de la película, fotogramas por segundo, codec de compresión y configuración
de audio.
En el cuadro de diálogo de Configuraciones para exportar película
podrán definirse diversas opciones, como se ve en la figura 3.23:
— Tipo de archivo: Elegir el tipo de archivo que se desee exportar de tra-
bajo. Si está disponible, se puede hacer clic en Configuraciones avan-
zadas para determinar las opciones que varían según el tipo de archi-
vo que se elija.
— Rango: Se deberá seleccionar Microsoft AVI, aunque también cuenta
con diversas opciones adicionales.
— Exportar Vídeo: Deberá seleccionarse esta casilla de verificación para
exportar las pistas vídeo o también, no es nuestro caso, deseleccionar-
se para evitar la exportación de las mismas.
— Exportar Audio: Al no preocuparse todavía del sonido se puede dese-
leccionar la casilla de verificación.
— Abrir al acabar: Es conveniente seleccionar esta opción. Marque esta
casilla de verificación si quiere que el programa abra automáticamen-
te la película una vez terminada.
Si la tarjeta de digitalización no ofrece la posibilidad de mostrar un panel
desde el que se pueda controlar los parámetros relativos a la salida de vídeo,
se podrá emplear las opciones que Adobe Premiere ofrece para ello, se deben
seguir los pasos siguientes:
FIGURA 3.23. Configuraciones para exportar película.
1. Generar la película utilizando el codec de la tarjeta.

2. Cuando finalice el proceso, elegir la función para ello, en el menú Archivo,
hay que seleccionar Exportar y se abrirá un menú desplegable donde se
deberá escoger Imprimir en vídeo. Aparecerá la ventana de la figura 24.
3. En la ventana de Imprimir en vídeo, se deberán ajustar la duración de
barras de color y de pantalla negra.
4. En este mismo cuadro de diálogo se podrán realizar otro tipo de ajus-
tes que permitirán alterar el tamaño de la película. En el caso de que
incremente el tamaño de cuadro mediante estos ajustes, la aplicación
interpolará la información para obtener las nuevas dimensiones. Esto
significa que se estará perdiendo resolución en la película.
4. Pulsar el botón de grabar en el dispositivo analógico y, a continuación,
hacer clic en el botón Aceptar de Imprimir en vídeo.
Esperar a que finalice el proceso y detener la grabación en el aparato de
vídeo. Comprobar que el resultado es adecuado reproduciendo la película desde
la cinta analógica y visualizándola en un monitor o en la pantalla del ordenador.
3.4.2. Formatos de vídeo

En el vídeo digital, además de todo lo abordado en puntos anteriores, es
necesario pensar en la tecnología multimedia con un sistema operativo capaz
de controlar el hardware de producción.
Windows hace posible la instalación de diferentes tecnologías: Vídeo for
Windows (ya obsoleta) DirectX y QuickTime. A estas tecnologías se les debe
añadir las específicas para la reproducción de vídeo y audio en Internet.
FIGURA 3.24. Vetana de Imprimir vídeo.
Estas tecnologías se encuentran a nivel de sistema operativo, y son las

únicas que permiten la comunicación con la tarjeta de captura de vídeo y las
que precisan las aplicaciones de edición de vídeo para su correcto funciona-
miento. Las tecnologías como DirectX o QuickTime también son las respon-
sables de limitar el tipo de información que se va a poder manejar durante el
proceso de edición. Esto será así siempre que se grabe el archivo resultante
en un formato compatible con la propia tecnología.
• AVI (Audio Video Interleave)
Hoy DirectX, es el formato de vídeo utilizado por el software de repro-

ducción Video for Windows, y está soportado por la mayoría de herramientas
de creación en entorno Windows.
Su característica principal es el entrelazado de los datos de vídeo con los
de audio dentro del archivo que contiene la secuencia, y así se produce la sin-
cronización entre audio y vídeo.
Otras características podrían ser:
— Reproducción desde disco duro o CD-ROM.
— Reproducción en ordenadores con memoria limitada al trabajar con
un rango medio de índices de transferencia de información.
— Rápida carga y reproducción al usar sólo algunos cuadros de vídeo a
la vez, y una porción de vídeo.
El gran auge de este formato ha sido debido a la extensión de las plata-
formas Windows que integran por defecto este formato de almacenamiento y
reproducción.
• QuickTime
Se podría decir que QuickTime es algo más que un formato de vídeo, es

un formato multimedia que proporciona entornos de vídeo (almacenamiento
y reproducción), audio digital, realidad virtual, etc.
QuickTime proporciona un interfaz estándar, reproducción y característi-

cas para comprimir/descomprimir en múltiples plataformas.
Está soportado por plataformas Windows y Macintosh, y se encuentra
altamente integrado con las actuales tarjetas de captura de vídeo MPEG A y B.
QuickTime engloba cuatro elementos:
— Un sistema de software.
— Un conjunto de algoritmos de compresión.
— Un formato estándar de ficheros de vídeo.
— Un interfaz para definir la captura de vídeo, compresión y caracterís-
ticas de reproducción.
Usa codecs más adecuados para Macintosh, como son Animation,
Video, Photo-Jpeg; codecs para plataformas Windows como es Intel
Indeo en sus diversas versiones.
Una película QuickTime es un conjunto de pistas en las que se contie-
nen distintos tipos de datos multimedia, todos ellos coordinados con
un sistema común de tiempos para lograr su sincronismo.
En resumen, es un formato de características similares a AVI, pero que
incluye una serie de opciones y herramientas de valor añadido que lo
convierten en un sistema multiplataforma.
La tecnología que se decida instalar en el equipo tendrá una gran
importancia a la hora de determinar la calidad de los proyectos, la
integración con múltiples medios de volcado y la calidad de reproduc-
ción desde ordenador.
3.4.3. Codecs
Se va a ver a continuación una buena cantidad de esquemas de compre-
sión y descompresión. En cualquier caso, tanto la tecnología QuickTime
como Vídeo para Windows y DirectX soportan un mayor número de codecs
que los que aquí se recogen.
— MPEG (Moving Pictures Experts Group)
Su aplicación está muy extendida entre diversas tecnologías de vídeo y
multimedia. Se ha convertido en un formato internacionalmente aceptado.
Su principal virtud como compresor es la de generar archivos suficientemen-
te pequeños; por tanto, se podrá trabajar con más minutos de vídeo al ocupar
éste menos espacio en el disco duro. Como descompresor, su principal carac-
terística es reproducir vídeo a pantalla completa a una velocidad de 25 imá-
genes por segundo en formato PAL, si bien para ello se deberá tener instala-
da en el ordenador una tarjeta de descompresión MPEG. Existen varias ver-

siones de compresión MPEG, ya que algunas de las evoluciones de este for-
mato se han centrado en el tratamiento del sonido o del vídeo digital en for-
mato DVD (Digital Versatile Disk).
MPEG ha ido evolucionando hacia una serie de subformatos capaces de
ofrecer un rendimiento específico según la calidad que se desee obtener. Por
ejemplo, el MPEG original realiza los procesos de descompresión por soft-
ware, mientras que los algoritmos MPEG-2 y 3 realizan la descompresión
mediante tarjeta hardware para lograr la reproducción a pantalla completa.
Existen algunas utilidades software que permiten la compresión y reproduc-
ción de archivos en formato MPEG sin necesidad de tarjeta. No obstante, la
calidad que se obtiene en estos casos es menor.
— JPEG
Se utiliza en las tarjetas de digitalización de vídeo para permitir la captu-
ra en formato PAL. Cuando se va reproducir una película con compresión
JPEG, es necesario que el ordenador tenga instalada la misma tarjeta que se
utilizó para su captura. Para disminuir esta limitación, lo más recomendable
es grabar la película final utilizando otro compresor que soporte la compre-
sión espacial o de menor pérdida.
Es un sistema sucesor de las aplicaciones de retoque fotográfico. El siste-
ma JPEG a diferencia de los anteriores esquemas de compresión/descompre-
sión, comprime la información fotograma a fotograma; es decir, que no tiene
en cuenta la información de las imágenes posteriores ni de las anteriores.
Este compresor es de tipo destructivo por lo que desde el punto de vista
de la calidad, la compresión JPEG implica pérdida de información: elimina
para la correcta visualización de los fotogramas comprimidos aquella infor-
mación que considera redundante o innecesaria.
— MJPEG
En este caso, a diferencia del codec MPEG, la compresión se realiza
teniendo en cuenta, tanto la información de la imagen a comprimir, como la
de las anteriores y posteriores. Las películas comprimidas con formato
MJPEG sí podrán editarse posteriormente. El resultado generado por este
codec es un menor tamaño de archivo y mayor calidad de la película digitali-
zada. QuickTime ofrece dos variantes del codec MJPEG: A y B. Ambas varian-
tes del codec ofrecen los mismos ajustes de personalización al usuario, el
resultado obtenido variará considerablemente en la tasa de transferencia. La
variante MJPEG-A suele generar archivos muy pequeños, además de mante-
ner una tasa de transferencia apta para su inclusión en títulos CD-ROM. Por
el contrario, la variante MJPEG-B genera archivos de mayor tamaño (inclu-
so, en ciertas condiciones, el tamaño es mayor que el del archivo original), y
la tasa de transferencia suele estar entre 1 MB y 3 MB por segundo. La cali-
dad de imagen en éste es mucho mayor y es aconsejable para aquellas pelí-

culas en las que exista mucho movimiento o diferencia entre cada uno de los
fotogramas que componen la película.
— Intel Indeo
Un archivo de vídeo comprimido con el codec Indeo Video puede ejecutar-
se en cualquier sistema que soporte QuickTime para Windows. Es el codec de
Intel para sistemas basados en procesador Pentium. Los cortes de vídeo com-
primidos con Indeo en formato .AVI pueden ejecutarse en Vídeo para Windows
(Windows 3.x,.Windows 95 y superiores), y los clips de vídeo comprimidos con
el codec Indeo en formato .MOV pueden ejecutarse en QuickTime.
Su tecnología está basada en un compresor/descompresor (codec) en for-
ma de controlador de software que comprime los datos de vídeo digital para
almacenarlos y los descomprime para su reproducción en un PC multimedia.
Para que un ordenador pueda ejecutar archivos comprimidos con Indeo debe
instalarse el codec de vídeo de Indeo, utilizando el programa de instalación
de Intel. En definitiva, Indeo es el software de captura de vídeo digital, com-
presión y descompresión de Intel.
— Cinepak
En este codec la calidad de la compresión está supeditada al valor que el
usuario fije como máximo para la transmisión de datos; por tanto, la imagen
se ve bastante mermada por la pérdida de la información requerida durante
el proceso de compresión que, por otra parte, es algo lento.
Cuando se reproduce la película desde CD-ROM, se obtienen muy buenos
resultados trabajando a 320x240 píxeles de tamaño de cuadro y con una velo-
cidad de reproducción de 15 a 25 imágenes por segundo. Para Internet, pue-
den utilizarse los mismos valores, si bien debe bajarse a 90 kB por segundo el
valor correspondiente al máximo para la tasa de transferencia. De esta forma
se ajusta más al ancho de banda proporcionado por los módems, aunque
también se reduce en igual medida la calidad de la imagen que ha sido com-
primida. No obstante, no funciona bien con tasas de transferencia inferiores
a 30 kbps. El compresor Cinepak es uno de los que adapta la calidad en fun-
ción de los ajustes que se hayan realizado para la compresión.
Permite también que se pueda incrementar el flujo de los datos de peque-
ño tamaño seleccionando la casilla de verificación Aumentar flujo de datos
bajos, configurando así el mantenimiento del flujo de datos deseado.
3.5. RESUMEN
La forma más sencilla de crear imágenes 3D es a partir de una imagen
plana o 2D y añadirle dimensionalidad. Hoy casi todos los programas de dise-
ño 2D incluyen herramientas para agregar sombras, texturas, efectos de ilu-
minación y superficies de relieve, que producen un efecto de tridimensionali-

dad a objetos planos. Los objetos 3D más sencillos que pueden crearse son
dar relieve a texto plano y crear botones de acción en 3D jugando con mapas
de relieve e iluminación del objeto plano.
Existen otros métodos sencillos para dar tridimensionalidad como son la
posibilidad de dar perspectiva a figuras planas, añadir contornos concéntri-
cos, técnicas de golpeo y apretamiento, etc.
Actualmente es posible disponer de buenos paquetes de software infor-
mático de animación que realizan en cuestión de segundos muchas de las
pesadas tareas que en épocas no muy lejanas tenían que realizar varias per-
sonas durante semanas o meses. Además, el software de animación por orde-
nador proporciona todas las ventajas de la edición digital.
El vídeo es un sistema dedicado al almacenamiento de imágenes en movi-
miento y sonidos sincronizados para su posterior reproducción tantas veces
como se desee. En la actualidad cabe hablar de dos tipos de vídeo, el vídeo
analógico y el vídeo digital. La edición de vídeo digital no es otra cosa que el
paso de las señales de vídeo analógicas a señales de vídeo digitales.
A medida que se aumenta de calidad, se aumenta la cantidad de datos
requeridos para representar el vídeo. Los avances recientes en el poder de los
procesadores y en memoria han permitido que los sistemas informáticos de
sobremesa procesen datos con suficiente eficacia para capturar, almacenar y
proyectar vídeo digital.
Finalmente, al igual que en el capítulo anterior, se recomienda al lector
que quiera profundizar en los contenidos de este capítulo, la referencia (Cas-
tro y otros, 2002).

3.1. La película transparente que se utilizaba en la animación tradicional
dibujada a mano responde al termino:
a) Animación en celuloide.
b) Animación en cuadros.
c) Animación de sprites.
d) Animación de trayectorias.
3.2. A continuación se citan algunas de las técnicas más utilizadas en ani-

mación, una de ellas no es correcta:
a) Piel de cebolla.
b) Recortes.
c) Deceleración/aceleración y curvas de velocidad.

d) Hiteresis.
3.3. Son diferentes las tareas de un proceso de creación de gráficos 3D. La

encargada de crear la estructura básica de sus objetos y situar en un
mundo 3D se conoce como:
a) Animación.
b) Modelado.
c) Render.
d) Componer.
3.4. En la de animación, por lo general, se asignan diferentes posiciones de

puntos claves de trayectoria a los objetos en una línea de tiempo. El
ordenador genera cuadros intermedios entre esos puntos clave para
simular movimiento en su mundo 3D. Estos puntos clave reciben el
nombre de:
a) Extrusión.
b) PixclPutty.
c) EPSF.
d) Modelo.
3.5. A la sucesión ininterrumpida de escenas o planos que integran una eta-

pa descriptiva, una etapa de la acción o un tramo coherente y concreto
del argumento de un vídeo, se denomina:
a) Resolución.
b) Luminancia.
c) Secuencia.
d) Compresión.

ADOBE PREMIERE, 2002. «Manual de usuario de Adobe Premiere».
CASTRO y otros, 1996. M. Castro. «Comparación de Técnicas y Herramientas de Autor
para la Generación de Aplicaciones Educativas». II Congreso de Tecnologías Apli-
cadas a la Enseñanza de la Electrónica, Sevilla,.
CASTRO y otros, 2002. M. Castro. Diseño y desarrollo multimedia: Sistema, imagen,
COLMENAR, 1999. A. Colmenar. M. Castro, y J. Peire. «Aplicaciones Didácticas de
los Sistemas Multimedia en la Enseñanza a Distancia». 8º Encuentro Ibero-
americano de Educación Superior a Distancia. Quito-Ecuador, del 22 al 24 de

julio de 1999.
COLMENAR, 1999. A. Colmenar. «Propuesta de Diseño Curricular en un Marco Cons-
las Energías Renovables». Tesis Doctoral. UNED, 1999.
GARCÍA, 1983. L. García. Los Medios Audiovisuales al Servicio de la Enseñanza. Madrid:
Servicio de Publicaciones del ICE de la Universidad Politécnica de Madrid, 1983.
MORATA, 1998. R. Morata y D. Insa. Multimedia e Internet. Ed. Paraninfo, 1998.
RODRÍGUEZ, 1998. F. J. Rodríguez y A. García. Videoedición Digital. Ed. Paraninfo. 1998.

Capítulo 4
FASES DEL DESARROLLO
DE SISTEMAS MULTIMEDIA
ESQUEMA
4.1. Ingeniería del software y multimedia.

4.2. Características del desarrollo multimedia.
4.3. Las fases del ciclo de vida del desarrollo multimedia.
4.4. Modelos de proceso para el desarrollo multimedia.
4.5. Resumen.
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 dis-
tintos en este sentido de cualquier otra aplicación software. Sin embargo, la
mayor parte de los desarrolladores tienden a trabajar de manera completa-
mente artesanal, bajo el supuesto de que no existe una sólida teoría ni méto-
dos 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 real-

mente ocurre es que no se puede pretender seguir el mismo modelo de pro-
ceso que para otro tipo de sistemas pero que sí existen métodos de ingenie-
rí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 aplica-
ciones 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 informa-
ció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 abor-
dan de forma completa en otros capítulos, así como posibles modelos de
proceso en la sección 4.4.
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 algu-
nos 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 obje-
to se ha recurrido al «IEEE Standard Glossary of Software Engineering Termi-
nology» (IEEE, 1990).
En primer lugar es preciso distinguir entre el ciclo de vida del desarro-
llo software y el modelo de proceso del ciclo de vida, usualmente denomi-
nado 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 imple-
mentació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 fun-
ció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 soft-
ware 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 desarro-
llo 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 dis-
tintas 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 aplica-
ciones 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 multi-
media de calidad será relevante, completo, correcto, usable y útil. Un pro-
ceso 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 pues-
to 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 desa-

rrollo de sistemas interactivos que afectan a la selección del modelo de pro-
ceso 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 des-
tacar 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.

4.2.1. Desarrollo centrado en el usuario

Las aplicaciones multimedia, como aplicaciones interactivas que son, tie-
nen como objeto conseguir que el usuario pueda llevar a cabo alguna tarea,
ya sea aprender algo, comprar un producto, comunicarse con alguien o sim-
plemente divertirse, de una manera eficiente y efectiva. Dicha tarea se reali-
za 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 gene-
ral en el que se establecen las relaciones entre los principales agentes involu-
crados, 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 orde-

nador, 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á implementa-
do de una determinada forma y cada interacción del usuario da lugar a un
procesamiento que va a generar una salida específica que el usuario inter-

pretará 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 cuan-
do un usuario que nunca ha utilizado un procesador de textos intenta emple-
arlo 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 tex-
tos 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 cog-

nitivas (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 con-
clusión sobre el funcionamiento de la aplicación y la consecución de sus obje-
tivos. 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):
■ 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 requisi-
tos 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 pro-
ducto 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 interac-
ció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 evo-
lucionar 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 desa-
rrollo 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 acti-
vidades dependerá de múltiples factores, pero siempre se deberían emplear
métodos que den soporte a las cuatro actividades fundamentales que permi-
ten contar la participación activa del usuario durante todo el proceso de desa-
rrollo 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.
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 discusio-

nes sobre el análisis y el diseño o en evaluaciones de prototipos, debe em-
plearse 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 nive-
les, 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 softwa-
re sino también hardware. Por otra parte el sistema informático puede divi-
dirse en el software de la aplicación, que será desarrollado por personal fun-
damentalmente 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).
FIGURA 4.3. Visión modular de un sistema interactivo.
Si bien no siempre es preciso ni factible involucrar a tantos tipos de pro-

fesionales, si es recomendable que el equipo sea míninamente pluridiscipli-
nar, 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 deci-
siones sobre las opciones de diseño (psicólogos, sociólogos o, por ejem-
plo, pedagogos en un sistema destinado a la enseñanza), y,
• diseñadores gráficos y otros especialistas en el tratamiento de informa-
ció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 multime-
dia interactivo. En la tabla se indican el tipo de miembro del equipo de desa-
rrollo, las labores que éste debe realizar y, finalmente, las habilidades y cono-
cimientos requeridos.
TABLA 4.2. Habilidades requeridas para el desarrollo de aplicaciones Web

ampliadas de Hansen y otros, 2001
Miembro del Labor Habilidades/Conocimientos

equipo
Usuarios Aportar opiniones Conocimiento de la tarea a
y experiencia de uso del realizar y del dominio en que
producto. se lleva a cabo la misma.
Proveedores de Producir contenidos Principios de usabilidad,
contenidos multimedia. creatividad, diseño gráfico y
multimedia, etc.
(Continua)
TABLA 4.2. (Continuación)
Miembro del Labor Habilidades/Conocimientos

equipo
Ingenieros del Publicar el material en Web. Bases de datos, cgis, html y
Web de nivel 1 lenguajes de programación y
(publicadores) marcado para Web (HTML,
XML, XSL, SMIL, etc), etc.
Encargados del Actualizar y mantener los
mantenimiento del contenidos de información. Uso de las bases de datos y/o
Web de lenguajes de marcado.
Administrador del Gestionar el servidor Web, Arquitecturas
Web responsabilizándose de su cliente/servidor,
eficiencia, integridad, comunicaciones, protocolos,
seguridad, etc. mecanismos de seguridad,
etc.
Ingenieros del Analizar los requisitos, Plataformas
Web de nivel 2 producir la documentación hardware/software existentes
del análisis y del diseño, (características, limitaciones,
establecer los procedimientos etc.), técnicas de
de operación y de especificación y modelado,
mantenimiento, definir la publicación de páginas Web,
política de seguridad. etc.
Ingenieros del Gestionar los recursos, Planificación y gestión de
Web de nivel 3 humanos y técnicos del proyectos, análisis de
(gestores de proyecto para conseguir que riesgos, gestión de calidad,
proyectos) las metas se obtengan en el etc.
menor tiempo posible.
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 capa-
ces de fomentar la necesaria cooperación y sinergia entre personas de carac-
terí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-
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 segu-
ridad implementados, con los procesos a los que se da soporte o con los cami-
nos 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 realiza-

ció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 fac-
tibilidad, el análisis, el diseño, la producción, la evaluación y el manteni-
miento. 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 fac-

tores 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, funciona-
les o cognitivas (Lowe y Hall, 1999). Al final de esta fase, el equipo de desa-
rrollo 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. 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 interacti-
vos 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áli-
sis es, precisamente, el análisis de las tareas. Así, se deberá saber qué acti-
vidades 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 pue-
den 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 infor-
mació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 limi-
taciones o estándares a cumplir, si se va a dar soporte al uso de diferentes pla-
taformas de acceso o incluso las características físicas del entorno. Por ejem-
plo, 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 aplica-
ció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 pro-
ducto debe realizar (IEEE, 1990).
■ Los requisitos no funcionales que imponen restricciones a los requi-

sitos funcionales relacionadas con la eficiencia, consistencia, reusabi-
lidad, 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 tra-
ducir 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 per-
mite expresar la solución a los requisitos de una forma abstracta y con una deter-
minada 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-
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 Pro-
veedor de Contenidos) y que uno de esos tipos puede especializarse utili-
zando 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 cla-
ra 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 desarro-
llo 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 Diseño
Se va a dar acceso a Los usuarios se organizarán tal y como se muestra en el siguiente
distintos tipos de diagrama que utiliza notación UML para representar relaciones
usuarios, incluyendo estructurales entre tipos de usuarios.
profesores, tutores,
alumnos, responsables
docentes,
desarrolladores de
contenidos y
administradores.
El diseño es un proceso típicamente creativo y abstracto que se ve res-

tringido 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 cen-
trarse 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 carac-
terí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.
■ Restricciones cognitivas. Los usuarios tienen una características físi-

cas (agudeza visual, capacidad auditiva, etc.) y cognitivas (memoria a
corto y largo plazo, capacidad de razonamiento y de resolución de pro-
blemas) que deben ser respetadas si se pretende construir un sistema
utilizable (Dix y otros, 1998). Por ejemplo, si se muestran varias ani-
maciones simultáneamente, no se puede esperar que el usuario atien-
da 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 perso-
nales 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 rea-
lizar 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 pro-
fundizará 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 diver-

sas 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 conteni-
dos. 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, anima-
ciones, 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 pro-
cesable 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 dis-
ponibles en formato no digital. Así, es muy frecuente que se cuente con víde-
os 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-
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).
Una vez que se tiene la estructura y el contenido, basta con integrar los
contenidos en esa estructura y programar aquellos procesos que sean nece-
sarios. Como resultado de esta fase se habrá construido un sistema o un pro-
totipo, 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 aplicacio-

nes se han diseñado teniendo en cuenta las necesidades de sus usuarios fina-
les, y no sólo las de los desarrolladores. Este proceso va a proporcionar infor-
mación que permita comprobar si los mecanismos de interacción se han
diseñado correctamente, detectando aquellas deficiencias que haya que sol-
ventar 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 bus-
can 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 inter-
pretació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 adap-
tarlo 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 cerra-
dos. 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ífi-
cos, 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-
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 pro-
ceso 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, respectiva-
mente. 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 funcio-
namiento, el mantenimiento u otros atributos del sistema. Por ejem-
plo, 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ápi-
da y flexible del producto, susceptible de ser modificada ante una varia-
ció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 herramien-
tas CASE (Computer Aided Software Engineering) capaces de transfor-
mar automá- ticamente la salida de cada fase en entrada de la siguiente.
• El modelo basado en el uso de prototipos que ofrece una aproxima-
ción iterativa en la que se emplean prototipos para involucrar al usuario.
El uso de prototipos y su evaluación por parte del usuario o de evaluado-

res expertos es básico en los sistemas interactivos, como los sistemas multi-
media. 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 pro-
ceso más flexible que resulta especialmente adecuado para sistemas interac-
tivos el modelo en estrella (Preece y otros, 1994). Las dos siguientes subsec-
ciones 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 desarro-
llar 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 ite-
rativo supone realizar cortos ciclos de análisis y diseño para producir un pro-
totipo que pueda ser evaluado de forma que se obtengan datos fiables sobre
su utilidad. Los resultados de la evaluación pueden hacer replantearse cual-
quiera de las fases previas como se muestra en la figura 4.5, ya que un pro-
blema 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 requisi-
to (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.

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 implementa-
ció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 ite-
ració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 pre-
sió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 siem-
pre que los recursos lo permitan.
4.4.2. Modelo en estrella
Otro modelo de proceso bastante adecuado para el desarrollo de siste-

mas 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 habi-
lidades y conocimientos de sus integrantes, la disponibilidad de los usua-
rios para participar en evaluaciones empíricas o cualquier otro factor, pero
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éc-
nicas 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 deci-
sió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 gene-
rarse en un tiempo récord, por lo que el ciclo de vida debe permitir cre-
ar 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
inútil, para productos a gran escala es imprescindible aplicar un pro-

ceso completamente sistematizado (Lowe y Hall, 1999).
■ Características del equipo de desarrollo: dependiendo de los cono-
cimientos del equipo de desarrollo se podrá adoptar un modelo de pro-
ceso u otro. Así, si la mayor parte de los integrantes tienen un perfil téc-
nico será mejor aplicar un modelo iterativo en el que la participación
de otro tipo de personas (diseñadores gráficos o usuarios) pueda post-
ponerse hasta que se pueda contar con ellos.
En líneas generales, el ciclo de vida en estrella proporciona mayor flexi-
bilidad 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 desarro-
llo 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, estruc-
turales, 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, fina-
lemente, 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 meca-
nismos de interacción.
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) Siempre hay que utilizar prototipos para recoger requisitos.

b) No hace falta involucrar al usuario.
c) Hay que identificar requisitos de distintos tipos.
d) Los requisitos sólo están relacionados con el usuario o con la plata-
forma 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 pro-
veedor 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.

AMESCUA y otros (1995): A. Amescua, L. García, P. Martínez y P. Díaz. Ingeniería del Soft-
ware 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 Disci-
pline, Technical Report CMU/SEI-92-TR-34, Software Engineering Institute, Car-
negie 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-Compu-
ter 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 sys-
tems. En Handbook of Human Computer Interaction, pp. 231-254. Elsevier Scien-
ce, 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 Yogesh-
Deshpande, 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. La etapa de análisis de requisitos en el desarrollo multimedia.

5.2. La especificación de requisitos en el desarrollo multimedia.
5.3. La etapa de diseño en el desarrollo multimedia.
5.4. Resumen.
5.5. Ejercicios de autevaluación.
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 producti-
va. 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 pro-
ductos 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 pro-
ductiva. 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 identifican-
do 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 cuen-
ta 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 mecanis-
mos 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-
tos que se pueden encontrar en un sistema multimedia, las técnicas que pue-
den emplearse para recolectar información sobre esos requisitos y la mane-
ra 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 sec-
ció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 estu-
diar y documentar las características o requisitos que dicho producto debe
tener, dando lugar a una Especificación de Requisitos. En un sistema mul-
timedia, 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 usua-
rio, 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 edu-
cativo (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 rit-
mo 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 ocasio-

nes 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 sim-
plemente 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 organiza-
dos en dos ejes: en el horizontal se distingue entre requisitos sobre el pro-
ducto o sobre el proceso de desarrollo del mismo, y en el vertical sobre el gra-
do de concreción de los mismos.
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 in-
plazo 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 cumpli-
miento, 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 quie-
re 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 dura-
ció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, inclu-
sió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.
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 desti-
nada 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 (conocimien-
tos previos, formación, habilidades) o sociales (por ejemplo, rasgos cultura-
les, 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 cuen-
ta que sólo hay que registrar aquella información que sea realmente relevan-
te 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 experien-
cia) de forma que se satisfagan las necesidades de todos ellos. Así por ejem-
plo, 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 exis-
tentes entre ellos, de manera que no sólo se conozca mejor como éstos se rela-
cionan como entidades sociales sino que también pueda emplearse este cono-
cimiento para proporcionar un acceso personalizado a la información.
El tercer caso presenta sistemas adaptativos en los que es imprescindible

mantener un modelo de usuario que recoja sus características y comporta-
miento 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 deter-
minado 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 ilumina-
ció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 rela-
ciones organizativas que puedan influir en su uso. Finalmente, con el entor-
no 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 com-
pletadas por unidad de tiempo; el número de errores cometidos por los usua-
rios; 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 docu-
mentación; el porcentaje de comentarios favorables y desfavorables; el núme-
ro de comandos erróneos o de repeticiones; y el número de comandos que no
han sido utilizados (Faulkner, 1998).
Para documentar un requisito de usabilidad puede utilizarse una planti-

lla 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 deter-
minada 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 locali-
zar 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. Ade-
má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 últi-
mo 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 pun-
to 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 Jajo-
dia, 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 Peor caso No poder incluir la página

funcionamiento Mínimo nivel aceptable 3 minutos
Nivel esperado 1 minuto
Mejor caso 0,5 segundos
Nivel actual --------------------
5.2.2. Técnicas de recolección de datos

Como se ha podido ver en la subsección anterior, los requisitos de un sis-
tema multimedia son de naturaleza muy variada, tanto por el tipo de infor-
mació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 uti-
lizar 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, estu-
dio de documentación o software de registro (Preece y otros, 2002). Estas téc-
nicas 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 referen-
cia a las características que un producto debería tener, en la evaluación se tra-
ta 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 cuestio-
narios, en tanto en cuanto la respuesta no está tan limitada o dirigida.
Son muy adecuadas para explorar temas (Preece y otros, 2002) y sue-
len arrojar más datos cualitativos que cuantitativos, si bien se requiere
un entrevistador con capacidad para incitar a los participantes a invo-
lucrarse en el análisis e incluso para suscitar temas de discusión. Ade-
más, la presencia de un entrevistador puede cohibir al usuario.
■ 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 entre-
vistas individuales, se pueden identificar puntos de consenso y de con-
flicto 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 usua-
rio 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 etno-
gráficos se enmarcan dentro de estas técnicas de observación emplea-
das 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 Atkin-
son, 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 documenta-
ción o estándares que puedan informar sobre las actividades de las
tareas a realizar, puesto que en muchas ocasiones algunos procedi-
mientos 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, especial-
mente 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 fre-
cuencia para recoger requisitos (IEEE, 1998; Lowe y Hall, 1999) pues-
to 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 uti-
lizan 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).
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 utili-
cretas. zan los usuarios con más fre-
cuencia?
Entrevista Explorar aspectos. ¿Qué contenidos debería tener
el curso?
Grupos de trabajo Confrontar perspectivas distintas. ¿Cómo hay que estructurar la
información?
Observación Conocer el entorno. ¿Cómo son las sesiones de los
alumnos de un curso virtual?
Estudio de Conocer estándares o normativas. ¿Cómo es el proceso de matricu-
documentación lación en el centro de enseñanza?
Estudio de la Aprender de desarrollos similares. ¿Qué estilos de aprendizaje se es-
literatura tán ofreciendo en cursos similares?
Prototipos Confirmar aspectos. ¿Tienen los usuarios problemas al
responder a los tests de nivel?
5.2.3. 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 necesida-
des del usuario se evita implementar funcionalidades innecesarias y se
reduce el número de iteraciones en los procesos de diseño y de pro-
ducción;
■ se proporciona una base sobre la que llevar a cabo estimaciones de cos-
tes 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 conti-
nuas evaluaciones.
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 solu-
ción abordará, entre otras, cuestiones tales como:
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 informa-
ció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 perso-
nales, etc.).
Con este fin es preciso hacer uso de un modelo de diseño que permita tra-
ducir 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ási-
co 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 repre-
sentació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éticamen-
te adecuada sino también cogni-tivamente eficiente.
Los contenidos van a poder ubicarse en diferentes dimensiones o espa-
cios 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
dependa de la presentación de otro y otros elementos (por ejemplo, «en cuan-

to 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 res-
tricciones 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 dis-

tancia 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 Disjuntos (A,B)
y los bordes de los objetos. Juntos (A,B)
Solapados (A,B)
Cubre (A,B)
Contiene (A,B)
Iguales (A,B)
Dirección Orientación relativa entre las esquinas Arriba (A,B)
superiores izquierdas de dos contenidos. 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 (distanciaX, distanciaY)
izquierdas de dos contenidos.
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 segun-
do 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.
Para poder modelarlas es preciso que el método ofrezca mecanismos para

indicar las posiciones de los contenidos haciendo uso no de posiciones abso-
lutas 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 pape-
lera, 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 sepa-
rar 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
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 coor-
denadas. 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 determi-
nada por el alcance de la modificación (modscope) al que pertenece.
A su vez, los alcances estarán incluidos dentro de una lista de modi-
ficaciones (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
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 pue-
de 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 con-
tenidos en sí (cada ítem multimedia que se incluye en el producto) es útil no
sólo porque son elementos conceptualmente distintos, sino porque, ade-
má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 ejem-
plo, un producto multimedia presentado en distintos idiomas tiene la
misma estructura pero distintos contenidos).
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, generaliza-
ció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 con-
tenidos 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 con-
tenidos con los que materializando algún tipo de relación (por ejemplo,
genera-lización/especialización, composición o agregación). Por ejem-
plo, 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 pro-
ductos multimedia: la existencia de una estructura jerárquica que es preciso
mantener. La figura 5.7 muestra un ejemplo de estructura bastante simplifi-
cada 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 documen-
tos que, a su vez, se especializan en tres tipos). Como puede verse, este dia-
grama 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 desapa-
recer»). Además, dichos eventos pueden ser provocados por acciones realiza-
das por el usuario (por ejemplo, «seleccionar un botón») o por el estado sis-
tema (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.
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 aplicacio-

nes 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 inclu-
yen 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 identi-
ficador (por ejemplo un nombre de fichero o un identificador de objeto). Por
ejemplo, los resultados de consultas a bases de datos o los enlaces adaptati-
vos 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 mis-
mas 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
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 perso-
nas 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 ade-
cuados. 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 dispo-
nibilidad 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 termi-
nal), 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 ele-
mentos 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 con-
fidencialidad o integridad pueden establecerse para una aplicación multime-
dia interactiva.
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ísti-

cas fundamentales:
■ Es conceptual, pues las reglas se expresan en función de nodos o con-
tenidos 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 dis-
tintas 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 tam-
bié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ógi-
ca 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 anota-
ció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 exis-
ten 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 con-
siderarse bien como nodos (enlaces entre nodos), o bien como puntos
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 desig-
nar el punto de enganche del enlace dentro del nodo. La forma de pre-
sentar este tipo de enlaces en la pantalla depende de las implementa-
ciones, 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 úti-
les en el caso de las anotaciones incluidas en un mismo nodo, especial-
mente 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
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 con-
siste en relacionar cada nodo con el visitado anteriormente, mediante
la definición de un enlace Nodo Anterior cuyo destino no puede decla-
rarse salvo mediante un procedimiento que lo calcule. Este tipo de
enlaces permite que las asociaciones entre contenidos puedan deter-
minarse 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ña-
dié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 con-
notació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 rea-
lizarse por medio de herramientas avanzadas como son los mapas, índices,
huellas, mecanismos históricos o buscadores (Díaz y otros, 1996) que facili-
tan 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
final. Los tipos de requisitos que suelen identificarse se clasifican en requi-

sitos 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 pue-
den emplearse técnicas tales como los cuestionarios, las entrevistas, los gru-
pos 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 docu-
mento que sea completo, correcto, no ambiguo, modificable, verificable,
con referencias cruzadas y con una clasificación de requisitos según su esta-
bilidad o importancia.
El diseño es la fase en la que se aportan soluciones a los requisitos identi-
ficados en el análisis para lo cual se hace uso de algún método de especifica-
ció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 (pre-
sentación), la manera en que ésta se organiza (estructura); la reacción del sis-
tema 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.1. Un enlace:
a) Siempre hay que utilizar prototipos para recoger requisitos.
b) Puede tener más de un destino.
c) Puede tener más de un destino pero nunca más de un origen.
d) Se define siempre entre un único origen y un único destino.
e) Siempre conlleva un cambio de nodo o página.
5.2. El análisis de requisitos:

a) Retarda el proceso de desarrollo.
b) Se hace al inicio y da lugar a un conjunto invariante de requisitos.
c) Permite detectar requisitos de distinto tipo.
d) 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.
c) Cada elemento de contenido sólo puede tener una única especifica-

ció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) La topología tiene que asumir el valor «disjunto».
b) Hay que indicar la distancia en los dos ejes de coordenadas.
c) La dirección es irrelevante.
d) 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.

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 (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.
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 Specifica-
tions. IEEE Std 830-1998.
LOWE y Hall (1999): D. Lowe y W. Hall. Hypermedia & the web: an engineering appro-
ach. 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. La interfaz de usuario.

6.2. Paradigmas de interacción.
6.3. Estilos de la interacción.
6.4. Principios de diseño.
6.5. Ejemplo de recomendaciones de interacción para un sitio Web de
comercio electrónico.
6.6. Uso de la metáfora.
6.7. Resumen.
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 comuni-
cación no es fructífera es bastante probable que el producto software segura-
mente 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 dispositi-
vo de entrada o salida cuyas características afectarán de algún modo a la con-
secució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 signifi-
cado y un propósito específico (por ejemplo, el uso de iconos). En consecuen-
cia, 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 escri-
torio) 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 produc-
tos 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 desa-
rrollo 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 elec-
tró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 efectivi-
dad y eficiencia de esta comunicación.
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 ejem-
plo, 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 anali-
za 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 disposi-
ció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 usua-
rio 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 escri-
be con un procesador de textos. En cambio, en las interfaces no interacti-
vas el comportamiento de la máquina siempre es el mismo, independien-
temente 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 usua-
rio no puede interactuar.
Centrándose meramente en el intercambio de información, éste puede
producirse de diversas formas. Atendiendo a este criterio se pueden distin-
guir 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 inter-
faz 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 (Pree-
ce 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 pri-
mer 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 siem-
pre 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 pun-
tos clave que ayudarán a realizar un diseño efectivo del sistema es la adop-
ció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 siste-
mas 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/.
telefonía, etc.) hacen que surjan nuevas formas de interacción como la infor-
má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 pre-
misa de que se simplifican las tareas que tiene que realizar el usuario pues-
to 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/.
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 ordena-
dores desaparezcan del entorno, integrándose en él. Como indica Mark Wei-
ser, 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 esfuer-
zo 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 informa-
ció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 ubi-
cua, 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 reali-
zar 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.
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 sub-

yacentes 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/.
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
http://www.research.ibm.com/WearableComputing/.
5
http://tangible.media.mit.edu/.
6.2.6. Realidad aumentada

El paradigma de la realidad aumentada es otro tipo de interfaces tangi-
bles, 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 ejem-
plo 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 comporta-
mientos. 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/.
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 inter-
actú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/.
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 posi-
bles 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.

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 for-
mularios 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 des-
ventajas 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 impre-
decibles, y muchas veces se requieren diálogos de clarificación.
La principal ventaja de este estilo es que no hace falta aprender la sinta-
xis del idioma. Algunas desventajas son: requiere muchos diálogos de clarifi-
cació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 repre-

sentación visual del entorno en el que se mueve el usuario. Las tareas que se
le proporcionan pueden simplificarse manejando directamente los objetos
que le interesen. En la figura 6.11 puede verse el escritorio del sistema ope-
rativo Windows, en el que borrar la carpeta «sobre ed» supondría seleccionar-
lo 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 usua-
rio, 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 inter-
pretar, 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;
• 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 tra-
bajo 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 usua-
rio 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 usua-
rios 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 presenta-
rá modificando sus dimensiones.
• Las secuencias de acciones incluidas en la interfaz deben tener un prin-
cipio 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 cuan-
do 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.
• 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 confu-
sió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 for-
ma 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 DIREC-
TORIO.
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 con-
junto 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 algu-
nas 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 plan-
tear el diseñador a la hora de abordar el desarrollo del producto. Las res-
puestas 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, ten-
ga 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 signifi-
cado 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 conoci-
miento del usuario. Además, no tienen que producirse retrasos innecesa-
rios 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 pun-
to 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).
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 disposi-
ció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 posi-
bilidad 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 conte-
nidos 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/.
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 conte-
nido multimedia (por ejemplo, un icono que represente varios fotogra-
mas 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 nave-
gador)?
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 pare-
ce 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 quie-
re 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 utilizar-
las, y, por último, tiene que ser fiable de manera que el aspecto que
9
http://www.tc-helicon.tc.
proporcione inspire confianza al usuario (por ejemplo, ¿alguien com-

prarí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.
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 animacio-
nes 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 velo-
cidad 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 vocaliza-
ción, entonación, etc.) de manera que el oyente interprete correctamente el
mensaje. Para todos los contenidos multimedia, habrá que analizar si la cali-
dad y comprensión de la información puede verse afectada por retardos debi-
dos 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 ade-
cuado y proporcionado en distintas resoluciones. Ya que cuando se lee
no se leen palabras, sino que las identificamos por su forma, especial-
mente por la parte inferior de la letra más que por la superior, es impor-
tante 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 alma-
cenamiento son directamente proporcionales e inversamente proporcio-
nales 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).
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 aprendi-
zaje y comprensión del sistema que se esté utilizando. Además, la consis-
tencia también se basa en utilizar los mismos nombres para referirse a las
mismas cosas, además de que las mismas funcionalidades deben activar-
se 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 transmi-
tir 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 unida-
des de información (nodo o páginas) sean autocontenidas, evitando en
la medida de lo posible hiperenlazarlas de manera que se le proporcio-
nen al usuario los caminos «razonables», y se utilice los contenidos
multimedia para realzar el contenido del nodo y hacerlo más fácil-

mente identificable.
Otra recomendación es el uso de herramientas de navegación que ayu-
den al usuario a moverse por el espacio de información, proporcio-
nándole pistas sobre dónde está, cómo ha llegado allí y qué puede
hacer. Algunas de estas herramientas de navegación son: visitas guia-
das, 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, repre-
sentació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).
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 localiza-
ció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 patro-
nes 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 mode-
los ya asimilados, situando al usuario en un entorno de trabajo que se ase-
meja 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/.
El empleo de metáforas en el diseño del interfaz ayuda a clarificar la natu-

raleza 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 usua-
rio 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 com-
prensió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 ejem-
plo, 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 expli-
car 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 espa-
cios, 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/.
La metáfora necesita generalmente, y en particular en un sistema multi-

media, ser concreta y familiar, altamente estructurada y explícita, visual y
multimedia, y, además, espacial (Väänänen, 1995). Si un usuario está fami-
liarizado con la metáfora que emplea, el sistema multimedia, podrá com-
prender 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 considerable-
mente 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áfo-
ras espaciales proporcionan al usuario un sólido modelo cognitivo para la
navegación, ya que existe una relación directa entre el espacio de informa-
ción y el de la metáfora.
Algunos ejemplos de las metáforas más empleadas en los sistemas multi-
media 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 educati-
vo, por eso McLellan (1992) ha aconsejado su uso en los sistemas mul-
timedia. 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 preestable-
cida 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 recomenda-
ciones que se han ido exponiendo para la creación del interfaz, hace que cada
diseñador, partiendo de los mismos requisitos, realice un desarrollo multi-

media 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 defi-
ciencias 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 inter-
faces y varios paradigmas de interacción que en la actualidad se está desa-
rrollando y que hacen el campo de la interacción persona-ordenador un
campo fascinante. En las dos secciones siguientes se proporcionan un con-
junto 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 desa-
rrollo. Por último, se han introducido el concepto de metáfora como una for-
ma 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.1. ¿Cómo se denomina la interfaz en la que las entradas de información

son de naturaleza diversa?
a) Multimedia.
b) Multimodal.
c) Conversacional.
d) Textual.
6.2. ¿Qué paradigma tiene como objetivo acercar el mundo físico y al virtual
sobreponiendo elementos virtuales a la realidad?
a) Ubicuo.
b) «Pervasivo».
c) Entorno atentos.
d) Realidad aumentada.
6.3. La mayor ventaja del «Rellenado de espacios».

a) Aprendizaje rápido.
b) Facilidad en la gestión de errores.
c) Simplifica la entrada de información.
d) No hace falta aprender la sintaxis del idioma.
6.4. ¿Quién da un camino más detallado sobre aspectos específicos de la inter-

faz?
a) Principios de diseño.
b) Reglas de diseño.
c) Estándares.
d) 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) Mapas.
b) Visitas guiadas.
c) Mecanismos de vuelta atrás.
d) Mecanismos de búsqueda.

BARKER y MANJI (1991): P. Barker. y K. Manji. Designing Electronic Books. Educatio-
nal 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.
DILLON (1992): A. Dillon. Human Factors issues in the design of hypermedia interfa-
ces. 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.
MORAN (1981): T. P. Moran. The command language grammar: a representation for the
user interface of interactive systems. International Journal of Man-Machine Stu-
dies, 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 Hyper-
media». Springer Verlag (Alemania), págs. 68-78.
Capítulo 7
EVALUACIÓN DE SISTEMAS INTERACTIVOS
ESQUEMA
7.1. El concepto de usabilidad.

7.2. Métodos de evaluación.
7.3. El proceso de evaluación.
7.4. Parámetros para la evaluación de sistemas multimedia.
7.5. Resumen.
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 sis-
tema 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 esta-
blece 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 tie-
ne 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 eva-
luació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-
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 conjun-
to 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 pro-
ducto software.
Los factores incluidos en la segunda vertiente, la práctica, están relacio-
nados 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 efi-
ciente 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 soft-

ware radica en tratar de cuantificar de algún modo su usabilidad1. En dema-
siadas 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 Poin-
ters) 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 pue-
den proporcionar información fiable sobre la usabilidad del producto resul-
tante. De hecho, sólo se podrá afirmar que los usuarios son capaces de utili-
zar 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á res-

ponder 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.
7.1.2. ¿Qué hay que evaluar?

En una aplicación interactiva hay infinidad de aspectos y elementos sus-
ceptibles de ser evaluados, tales como la apariencia de los contenidos, la uti-
lidad de los menús o formularios, e incluso la forma en que los usuarios uti-
lizan 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 inte-
ractiva, 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 consi-
derar 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 pue-
de considerarse un nodo. A su vez, los nodos pueden estar agrupados
de acuerdo con ciertos criterios. Por ejemplo, al pasar este libro a for-
mato 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 cual-
quier 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 ele-
mentos 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 carac-
terí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.
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 dis-
tintas funciones que el usuario pueden realizar se presentan de la for-
ma más apropiada y utilizable.
• Interacción. La interacción hace referencia a la manera en que los usua-
rios dialogan con el sistema para realizar una tarea (por ejemplo, rellenan-
do un cuestionario o resolviendo un ejercicio interactivo). Dentro de esta
categoría se incluyen los comandos ofrecidos para controlar la presenta-
ció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 cuestio-
nes sobre usabilidad que podrían plantearse, como primera aproximación,
para cada uno de estos aspectos con objeto de ayudar a entender el significa-
do 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 con-
seguir 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 produc-
to? 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 con-
seguir 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?
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 comer-
ciales se tiende a evitar la evaluación porque se considera un proceso costo-
so, 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 posi-
tiva 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 imagina-
rios. En muchas ocasiones los integrantes del equipo de desarrollo se
enfrascan en discusiones interminables sobre la utilidad de alguna fun-
ció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 lar-
go 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 conside-
rarse 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 desa-

rrollo de un sistema interactivo con el fin de mejorar la usabilidad del pro-
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 toma-
das 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 frecuente-
mente, 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 desa-
rrollo del producto.
• EVALUACIONES FINALES: que son aquellas que se hacen para asegurar el éxito o
la posible aceptación de un producto ya acabado.
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 for-
ma 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 estu-
dios 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 obje-
tivo de incrementar la comprensión que se tiene sobre lo que los usua-
rios 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 guia-
dos 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 rendi-
miento 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 evalua-
ción, presentado distintos métodos aplicables.
7.2. 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 anterior-
mente 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 com-
portamiento del usuario, tanto en términos físicos como de las operaciones
cognitivas que se deberían realizar. Entra pues dentro del grupo de evalua-
ciones 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í. Permi-
tirá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 emple-
arse 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 propo-
nen una serie de heurísticas para ayudar a los evaluadores a criticar el siste-
ma que se recogen en la tabla 7.2.
TABLA 7.2. Ejemplos de utilización de heurísticas para la evaluación analítica

(ampliados de Preece y otros, 2002)
Heurística Ejemplos de cuestiones
Visibilidad del estado del sistema. ¿Se informa a los usuarios de lo que está ocu-
rriendo en cada momento?
¿Se responde en un plazo razonable?
Equivalencia entre el mundo real ¿Es el lenguaje utilizado en la interfz simple?
y el sistema. ¿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, ¿Son los mensajes de error útiles?
diagnosticar y solventar errores. ¿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 cua-
lificadas 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 interac-
ció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-
ficativos. Sin embargo, los expertos tienen que elegirse con cautela de mane-
ra que se eviten prejuicios y evaluaciones demasiado sesgadas, ya que el obje-
tivo es conseguir reproducir la conducta real del usuario. Por sus caracterís-
ticas, 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 estu-

dios 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 eva-
luació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 apli-
carse 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, sue-
le 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.
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 refle-
ja en la figura 7.3.
FIGURA 7.3. Ejemplo de entrevista semi-estructurada.
Los cuestionarios son menos costosos pero hay que diseñarlos cuidado-
samente de manera que los evaluadores entiendan cada pregunta y las posi-
bles 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 propor-
cionan 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.
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 manipu-
lar 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 implan-
tado en el lugar donde va a ser empleado (Rubin, 1994). Esta técnica se com-
plementa en una etapa posterior con la realización de un Estudio de segui-
miento, 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
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 objeti-
vos perseguidos en la evaluación que no tienen por qué coincidir con los obje-
tivos del sistema.
A este respecto, resulta esencial formular objetivos muy concretos y men-
surables. 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 des-
cripción de qué se entiende por usabilidad, no se puede considerar como un
objetivo alcanzable. Por ello, habrá qué analizar que significa que un produc-
to 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 mecanis-
mo no automatizado, o
• verificar si se ajusta a algún tipo de estándar, recomendación o norma.
TABLA 7.3. Ejemplo de objetivos de la evaluación para un curso virtual

Evaluación de un Comprobar si el curso ayuda a los estudiantes a aprender.
curso virtual 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 presen-
cial, etcétera.
En cualquier caso, es preferible huir de objetivos grandiosos difícilmente

verificables como, por ejemplo, comprobar si un curso virtual mejora de for-
ma 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 proporcio-
nar 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 recur-
sos 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éc-
nicas analíticas o expertas bastará contar con expertos.
Si se invita a evaluadores expertos, éstos deben proceder de diversos cam-
pos, conocer las tareas para las que se utiliza el producto software y poder
asumir el papel de los usuarios.
Si se incluyen usuarios potenciales, debería formarse un grupo que repre-

sente 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 cur-
so 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 volun-
taria y los evaluadores deben ser conscientes de que se está juzgando al siste-
ma 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, administra-
dores, etc.).
• Usuarios con diferentes necesidades (estudiantes avanzados, estu-
diantes 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, tan-

tos 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 cues-
tionarios o entrevistas, incluyendo preguntas con respuestas abiertas que pro-
porcionen 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 ayu-
da 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 interac-
ción del evaluador sea guiada, de manera que no sólo se asegure que se utili-
zan todas las opciones disponibles sino que también se puedan detectar erro-
res. Además, hay que asegurarse de que las tareas permiten recopilar todos
los datos que se quieren recoger.
De forma general se puede decir que hay dos tipos de tareas:

• Tareas dependientes del dominio: son aquellas que ayudan al usua-
rio a conseguir un objetivo y que no pueden generalizarse porque
dependen de la aplicación concreta que se haya desarrollado. Por ejem-
plo, en un curso virtual tareas específicas serían realizar un determina-
do 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 pre-

parar 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 eva-
luadores deben ser conscientes de qué se está evaluando y por qué. Las eva-
luaciones 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.
7.3.5. Elaboración de los resultados
Los resultados deben servir para extraer una serie de conclusiones en tér-
minos de deficiencias detectadas y mejoras propuestas que permitan revisar
el producto para incrementar su utilidad. Para elaborar los datos cuantitati-
vos 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 cuen-

ta 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úme-
ro 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, res-
tricciones temporales, etc.).
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 crite-
rios 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 inclui-
dos, 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 Refleja el grado de libertad concedido al usuario.
Consistencia Mide la coherencia de la aplicación. Se comprueba si
elementos conceptualmente similares se tratan de la mis-
ma 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 con-
trol 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 sis-
tema.
Autoevidencia Expresa la medida en que los usuarios adivinan el pro-
pó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 comu-
nicarse con otros usuarios.
Soporte a la personalización Mide la capacidad del usuario de personalizar el pro-
ducto.

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 pro-
ducto 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 lle-
var a cabo una evaluación formativa.
b) Se podría enmarcar dentro del paradigma de estudios de campo.
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.

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.
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 8
DIRECCIÓN Y METODOLOGÍA
DE PROYECTOS MULTIMEDIA
ESQUEMA
8.1. Proyectos.
8.2. Dirección de proyectos.
8.3. Ciclo de vida.
8.4. Establecimeinto del ámbito.
8.5. Desarrollo del plan de proyecto.
8.6. Ejecución del plan de proyecto.
8.7. Monitorización y control del proyecto.
8.8. Cierre del proyecto.
8.9. Conclusiones.
Los conceptos que se presentan en este capítulo son conceptos generales
de Dirección y Administración de Proyectos de uso totalmente adecuado en
el desarrollo de un Sistema Multimedia. Este tipo de desarrollo goza de todas
las características que definen un proyecto en su sentido más amplio y son,
por tanto, susceptibles de aplicarse todas las ideas que aquí se exponen.
Sin perjuicio de ello, existen en este curso capítulos específicos de Análi-
sis, Diseño e Implantación de Sistemas Multimedia donde se profundiza en
las técnicas, modos y métodos que son específicos a este tipo de proyectos.
Los conceptos de dirección de proyectos que se introducirán a continua-
ción forman parte de las técnicas o «cuerpo de doctrina» de lo que en la lite-
ratura anglosajona (de donde proceden) se denomina Project Management y
que en castellano se ha denominado Dirección Integrada de Proyectos, o sim-
plemente, Dirección de Proyectos.
Estas técnicas tienen su origen en los años 40 del pasado siglo XX, princi-
palmente en proyectos de defensa y aeroespaciales. Después se han converti-
do en técnicas de uso general en la Ingeniería y actualmente se pueden con-
siderar de uso general para cualquier actividad que pueda considerarse un
proyecto, especialmente si este tiene cierta complejidad.
Es fácil encontrar el uso de estas técnicas en proyectos relacionados con
las tecnologías de la información, además de en todos los tipos de proyectos
mencionados anteriormente.
El PMBOK (Project Management Body of Knowledge) (PMBOK, 2000)
publicado por el PMI (Project Management Institute), constituye un «manual-
resumen» de las técnicas de dirección de proyectos, desde la visión del Project
Management Institute. Establecido en 1969 y con sede en Filadelfia, Pensyl-
vania (EE.UU.), el Project Management Institute (PMI) es la asociación profe-
sional sin ánimo de lucro de directores de proyecto principal del mundo, con
más de 100.000 miembros distribuidos por todo el planeta.
El Project Management Institute fue fundado en 1969 por cinco volunta-
rios. Durante este mismo año, se impartieron los primeros seminarios de
PMI en Atlanta, Georgia (EE.UU.). Actualmente, el PMI apoya a más de
100.000 miembros en 125 países por todo el mundo. Los miembros del PMI
son personas que trabajan en dirección de proyectos en diferentes áreas:
ingeniería aeroespacial, industria de automóviles, ingeniería civil, servicios
financieros, tecnología de información, productos farmacéuticos y telecomu-
nicaciones, etc.
El texto que se ha desarrollado en este capítulo está formado por notas de
los autores para uso exclusivo de los lectores de este libro, debido a las diver-
sas fuentes (que se incluyen dentro de la bibliografía de este capítulo) de don-
de se han tomado los principios en que se basa el mismo. En primer lugar, se
presenta un resumen de los conceptos de dirección de proyectos según la con-
cepción del PMI (Project Management Institute) que se expresa en su manual
PMBOK (Project Management Body of Knowledge) (PMBOK, 2000). Este resu-
men se presenta con la idea de facilitar al lector, en castellano, una informa-
ción que se considera muy valiosa para entender el enfoque de gestión de pro-
yectos global que propugna el Project Management Institute de EE. UU., que
está siendo de uso creciente en el mundo de la Dirección de Proyectos.
A continuación se muestra un ejemplo de «Ciclo de Vida» para la Direc-
ción de Proyectos. Se ha elegido el ciclo de vida formulado por R.K. Wysocky
(Wysocky, 2000) por su exposición clara y pedagógica y por estar absoluta-
mente en línea con la metodología anteriormente citada del PMI.
8.1. PROYECTOS
8.1.1. Concepto
DEFINICIÓN: Se puede definir un proyecto (PMBOK, 2000), como:

• Una secuencia de actividades únicas, complejas y conectadas entre sí, con un
objetivo o propósito y que deben ser completadas en un tiempo específico, dentro
de un presupuesto y de acuerdo a unas especificaciones.
Dentro de la definición del Proyecto se pueden desarrollar igualmente:

• Actividades únicas. El proyecto nunca ha sucedido previamente y
nunca sucederá en el futuro bajo las mismas circunstancias.
• Actividades complejas. Las actividades de un proyecto no son tareas
simples y repetitivas. Suelen requerir especiales niveles de capacidad,
acciones creativas y capacidad de juicio para ser realizadas de forma
efectiva.
• Actividades conectadas. Existe un determinado orden en la secuencia
en que las actividades deben ser realizadas para que el proyecto pueda
ser completado
DIRECCIÓN Y METODOLOGÍA DE PROYECTOS MULTIMEDIA 217
• Un objetivo. Un proyecto debe tener un objetivo final.

• En un tiempo específico. Los proyectos tienen una fecha de termina-
ción especificada. Puede estar auto impuesta por el equipo de dirección
del proyecto o externamente por el cliente o peticionario del proyecto.
• Dentro de un presupuesto. De forma análoga al límite temporal los
proyectos presentan un límite de presupuesto habitualmente impuesto
por las condiciones externas del proyecto: el cliente tiene un límite pre-
supuestario para llevar a cabo el proyecto.
• De acuerdo a unas especificaciones. El cliente o peticionario del pro-
yecto espera determinado nivel de funcionalidad y calidad del proyecto.
Las especificaciones nunca son fijas durante la vida de un proyecto, en
especial si éste es de larga duración. Esperar unas especificaciones fijas es
algo fuera de la realidad, de lo que debe ser consciente un buen director de
proyecto, para gestionar adecuadamente estos cambios.
Atendiendo a esta definición, el desarrollo de un Sistema Multimedia
constituye un proyecto en el sentido del Project Management Institute.
8.1.2. Parámetros de un proyecto
Un proyecto viene definido por cuatro parámetros o restricciones: el

alcance, el coste, el tiempo y los recursos. Este conjunto de restricciones son
interdependientes puesto que un cambio en una de ellas puede provocar un
cambio en alguna de las otras para poder volver el proyecto a un equilibrio.
Estas restricciones son de vital importancia en el éxito de un proyecto.
• Alcance. El alcance define «qué» hay que hacer. Es vital tener defini-
do y acordado con el peticionario del proyecto el alcance del mismo.
De lo contrario será imposible dimensionar los demás parámetros del
proyecto. Asociado al alcance del proyecto se debe fijar también un
nivel de calidad. Estos dos parámetros serán los que definirán los
demás.
• Coste. Es el dinero que hay que desembolsar para cubrir los gastos del
uso de los recursos que emplea el proyecto. Generalmente es una res-
tricción externa impuesta al proyecto, al menos como cota superior. El
Director de proyecto tratará de no superar esa cota para poder entregar
el trabajo en el alcance y calidad pedidos
• Tiempo. Es la ventana de tiempo disponible que se tiene para la reali-
zación de las tareas del proyecto. Con el alcance, calidad y coste fijados,
el tiempo y los recursos son las dos únicas variables de que dispone el
director de proyecto para mantener el proyecto en equilibrio.
• Recursos. Son las personas que realizaran el trabajo, y el material

necesario que gasta el proyecto. Es la «energía aportada» al proyecto.
Pueden ser horas de trabajo de los componentes del equipo de proyec-
to, equipos para el trabajo, instalaciones, materiales, etc.
Un «Plan de Proyecto» debe identificar previamente el tiempo, los costes y
los recursos para poder realizar el proyecto con el alcance y la calidad reque-
ridos. Es usual y útil representar todos estos parámetros con el denominado
«triangulo del proyecto» (figura 8.1): se sitúa el coste, los recursos y el tiempo
como lados de un triangulo, del que su área se identifica como el ámbito/al-
cance y la calidad. De esta forma se ve que cualquier variación del ámbi-
to/alcance o nivel de calidad solicitados por el peticionario del proyecto se tra-
ducirán en variaciones de los parámetros coste, tiempo o recursos.
En resumen se puede pensar que un proyecto debe ser un sistema en
equilibrio dinámico frente a las perturbaciones externas que suponen el
ámbito y la calidad, actuando sobre el coste, tiempo y recursos como varia-
bles de control.
o
mp
Alcance
Co
Tie
ste
y
Calidad
Recursos
FIGURA 8.1. Definición del triángulo del proyecto.
8.2. DIRECCIÓN DE PROYECTOS
8.2.1. Concepto y objetivos

Se puede considerar la dirección de proyectos como un área dentro de las
tareas directivas en general. Comparte determinadas áreas de conocimiento
con el resto de tareas directivas pero también tiene determinadas áreas que le
son específicas.
Lo habitual, cuando se piensa en principios de Dirección, es pensar en
Dirección de personas. Se verá como esos principios también son válidos
para la dirección de proyectos.
Un director debe: definir, planificar, ejecutar, controlar y cerrar las activi-
dades de las personas que dirige.
• Definición. Establecer el trabajo a realizar. En la dirección de proyec-
tos esta es una de las tareas prioritarias.
• Planificación. En la planificación se deben cubrir los siguientes pun-
tos:
• Que ha de hacerse.
• Por qué ha de hacerse.
• Quien lo hará.
• Cuando se hará.
• Que recursos serán necesarios para hacerlo.
• Que criterios se debe cumplir para que el proyecto sea declarado
completo.
La planificación reduce la incertidumbre:
• El haber planificado el trabajo permite considerar la salida probable y
establecer los planes correctores necesarios.
La planificación aumenta la eficacia: una vez definido el trabajo a rea-
lizar y los recursos necesarios par realizar el trabajo se está en disposi-
ción de programar el trabajo en paralelo en el tiempo en lugar de en
serie.
El hecho de planificar permite un entendimiento mejor de las metas y
objetivos del proyecto.
La planificación en ocasiones es objeto de críticas argumentando que
tan pronto como un plan se ha finalizado comienzan los cambios al
mismo. En cualquier caso la planificación es necesaria puesto que no
solamente proporciona una guía de lo que hacer, sino que también es
una herramienta para la toma de decisiones.
• Ejecución. Ejecutar el plan de proyecto incluye varios pasos. Además
de organizar al personal, hay que identificar recursos específicos para
llevar a cabo el trabajo definido en el plan. También implica la asigna-
ción de los trabajadores a sus actividades, y la programación de activi-
dades en sus fechas de comienzo y final. La especificación final de la
programación del proyecto aporta juntas todas las variables asociadas

con el proyecto
• Control. Como parte de los procesos iniciales de planificación se cons-
truye una programación inicial.
Esta programación especifica qué debe hacerse, cuando, por quién, y
qué elementos entregables al cliente se esperan.
Independientemente de lo fino que se haya sido con la planificación, el
trabajo del proyecto discurrirá siempre de forma distinta al plan. Las
programaciones siempre sufren modificaciones, esta es la realidad de
la dirección de proyectos.
En cualquier caso el director del proyecto debe tener un sistema que cons-
tantemente monitorice el progreso del proyecto. Esta monitorización se
comparará con los planes establecidos y en función de las diferencias que
se obtengan se podrán tomar las acciones correctoras pertinentes.
• Cierre. El cierre del proyecto es una fase tremendamente importante
en el ciclo de vida de un proyecto, a la que con frecuencia no se le pres-
ta la debida atención, normalmente por las prisas que hay para termi-
nar el mismo y comenzar con otro.
Para abordar una fase de cierre de la forma más provechosa posible se
debería tener en cuenta:
• Si el proyecto ha satisfecho lo que el peticionario del mismo quería
hacer.
• Si el proyecto ha satisfecho lo que el director del proyecto quería
hacer.
• Si el equipo de proyecto ha completado el proyecto de acuerdo con el
plan.
• Qué información se ha recogido para ayudar a proyectos posteriores.
• Si ha funcionado correctamente la metodología de dirección de pro-
yectos y de que manera la ha seguido el equipo de proyecto.
El cierre debe ser una evaluación de lo que se ha hecho y debe propor-
cionar información histórica para futuros proyectos.
8.2.2. Procesos
DEFINICIÓN: Se puede definir un proceso, en el ámbito de la dirección en general y de

la dirección de proyectos en particular, como:
• Una serie de acciones que producen un resultado.
El PMI ha identificado una serie de procesos que conforman la gestión de

proyectos en su aspecto más amplio y de forma transversal a las fases de rea-
lización del proyecto. Los procesos en la dirección de proyectos pueden
encuadrarse dentro de cada una de las áreas de conocimiento que pueden
verse implicadas, y que el PMI identifica como sigue:
• Gestión de la integración.
• Gestión del alcance del proyecto.
• Gestión de tiempos del proyecto.
• Gestión de costes del proyecto.
• Gestión de la calidad del proyecto.
• Gestión de los recursos humanos del proyecto.
• Gestión de la comunicación.
• Gestión de riesgos del proyecto.
• Gestión de suministros.
A su vez existirán procesos específicos para cada una de las fases del pro-
yecto, que siguiendo al PMI son:
• Inicio.
• Planificación.
• Ejecución.
• Control.
• Cierre.
Atendiendo a estas dos clasificaciones, según la fase y según el área de
conocimiento, se puede establecer una tabla completa de todos los distintos
procesos que puede implicar la dirección de proyectos de la forma más gene-
ral posible.
Se reproduce aquí la lista general de procesos que el PMI en el PMBOK
describe en su edición del 2000 (tabla 8.1). A continuación se desglosan las
distintas áreas y actividades.
TABLA 8.1. Tabla de procesos en la dirección de proyectos
Áreas Inicio Planificación Ejecucion Control Cierre

Gestión de la Desarrollo del Plan de Ejecución del Control de
integración Proyecto Plan de cambios inte-
Proyecto grado
Gestión del Inicio Planificación del Verificación
alcance del alcance del alcance
proyecto Definición del alcance Control de
cambios del
alcance
Gestión de Definición de Control de la
tiempos del actividades programación
proyecto Secuenciamiento de de actividades
actividades
Estimación de la
duración de
actividades
Desarrollo de la
programación de
actividades
Gestión de Planificación de los Control de cos-
costes del recursos tes
proyecto Estimación de costes
Establecimiento del
presupuesto
Gestión de la Planificación de la Garantía de Control de
calidad del calidad calidad calidad
proyecto
Gestión de los Planificación de la Desarrollo del
recursos organización equipo de
humanos del Creación del equipo trabajo
proyecto de trabajo
Gestión de la Planificación de las Distribución de Informes de Cierre
comunicació comunicaciones la información seguimiento administrativo
del proyecto
Gestión de Planificación de la Monitoriza-
riesgos del gestión de riesgos ción y control
proyecto Identificación de los de riesgos
riesgos
Análisis cualitativo de
riesgos
Análisis cuantitativo
de riesgos
Planificación de la
respuesta a los
riesgos
Gestión de Planificación de la Pedidos Cierre del
suministros adquisición Selección de contrato
Planificación de los suministradores
pedidos Administración
de contratos
— Gestión de la integración
En este área se incluyen los procesos relativos a asegurar que varios
elementos del proyecto están coordinados de forma adecuada.
• Desarrollo del Plan de Proyecto. Integración y coordinación de
todos los planes de proyecto para crear un documento consistente
y coherente.
• Ejecución del Plan de Proyecto. Lleva a cabo el plan de proyecto
ejecutando las actividades incluidas en él.
• Control de los cambios integrado. Coordinación de cambios a lo
largo de todo el proyecto.
• Gestión del alcance del proyecto
En este área se incluyen los procesos relativos a asegurar que el pro-
yecto incluye todo el trabajo requerido y sólo el trabajo requerido
para completar el proyecto con éxito.
• Iniciación. Autorización del proyecto o la fase.
• Planificación del alcance. Desarrollo de una exposición escrita
del alcance del proyecto como base para las decisiones futuras
del proyecto.
• Definición del alcance. Subdivisión de los grandes elementos entre-
gables del proyecto en elementos más pequeños y manejables.
• Verificación del alcance. Formalización de la aceptación del alcan-
ce del proyecto.
• Control de cambios del alcance. Control de cambios en el alcance
del proyecto.
— Gestión de tiempos del proyecto
yecto se finaliza dentro del tiempo requerido. Incluye:
• Definición de actividades. Identificación de las actividades específi-
cas que deben llevarse a cabo para producir los diferentes elemen-
tos entregables del proyecto, etc.
• Secuenciamiento de actividades. Identificación y documentación
de las dependencias entre actividades.
• Estimación de la duración de actividades. Estimación del numero
de periodos laborables que van a ser necesarios para completar
actividades individuales.
• Desarrollo de la programación de actividades. Análisis de las se-
cuencias de las actividades, duraciones de las actividades y requeri-
mientos de recursos para crear la planificación de proyecto.
• Control de la programación de actividades. Control de cambios en

la programación del proyecto.
— Gestión de costes del proyecto
yecto se finaliza dentro del presupuesto asignado y aprobado. Incluye:
• Planificación de recursos. Determinación de qué recursos (perso-
nas, equipos, materiales) y que cantidades de cada uno deben usar-
se para llevar a cabo las actividades del proyecto.
• Estimación de costes. Desarrollo de una aproximación de los costes de
los recursos necesarios para completar las actividades del proyecto.
• Establecimiento del presupuesto. Reparto del montante total de la
estimación de costes entre las actividades de trabajo unitarias.
• Control de costes. Control de los cambios sobre el presupuesto del
proyecto.
— Gestión de la calidad del proyecto
yecto satisfaga las necesidades para las que ha sido acometido. Incluye:
• Planificación de la calidad. Identificación de los criterios de calidad
que son relevantes al proyecto y determinación de cómo alcanzarlos.
• Garantía de la calidad. Evaluación del rendimiento del conjunto del
proyecto de una forma regular para proporcionar confianza de que
el proyecto satisfará los criterios de calidad pertinentes.
• Control de la calidad. Monitorización de resultados específicos del
proyecto para determinar si se acatan los criterios de calidad perti-
nentes e identificación de las vías de eliminación de las causas de
comportamiento insatisfactorio.
— Gestión de los recursos humanos del proyecto
En este área se incluyen los procesos relativos a asegurar que se reali-
za el uso más eficaz de las personas involucradas en el proyecto.
• Planificación de la organización. Identificación, documentación y
asignación de roles en el proyecto, responsabilidades e interrelacio-
nes de dependencia funcional.
• Creación del equipo de trabajo. Obtención de los recursos humanos
necesarios asignados al proyecto.
actividades individuales.
• Desarrollo del equipo de trabajo. Desarrollo de las habilidades indi-

viduales y de equipo para mejorar el rendimiento o desempeño del
proyecto.
— Gestión de la comunicación
En este área se incluyen los procesos relativos a asegurar una genera-
ción, colección, diseminación, almacenamiento y desecho final de la
información del proyecto apropiados y en el tiempo correcto. Incluye:
• Planificación de la comunicación. Determinación de las necesida-
des de información y comunicaciones de los involucrados en el pro-
yecto: quién necesita la información, cuando la necesitan y como
debe suministrárseles.
• Distribución de la información. Hacer que la información necesaria
esté disponible para los involucrados en el proyecto en tiempo y for-
ma adecuados.
• Informes de progreso o desempeño. Recolección y diseminación de
la información de progreso o desempeño del proyecto. Incluye
informes del estado, medida de progreso y previsiones.
• Cierre administrativo. Generación, colección y diseminación de la
información para formalizar la finalización de fases o del proyecto.
— Gestión de riesgos del proyecto
La gestión de riesgos es el proceso sistemático de identificación, análisis
y respuesta a los riesgos del proyecto. Incluye maximizar la probabili-
dad y consecuencias de los eventos positivos y minimizar la pro-
babilidad y consecuencias de los eventos adversos a los objetivos del
proyecto. Incluye:
• Planificación de la gestión de riesgos. Decisión de cómo enfocar y
planificar las actividades de la gestión de riesgos para un proyecto.
• Identificación de los riesgos. Determinación de los riesgos que pue-
den afectar al proyecto y documentación de sus características.
• Análisis cualitativo de los riesgos. Realización del análisis cualitati-
vo de riesgos y de las condiciones para priorizar sus efectos en los
objetivos del proyecto.
• Análisis cuantitativo de los riesgos. Medida de la probabilidad y
consecuencias de los riesgos y estimación de sus implicaciones en
los objetivos del proyecto.
• Planificación de la respuesta al riesgo. Desarrollo de procedimien-
tos y técnicas para realzar las oportunidades y reducir las amenazas
de riesgo a los objetivos del proyecto.
• Monitorización y control del riesgo. Monitorización de riesgos resi-

duales, identificación de nuevos riesgos, ejecución de planes de
reducción del riesgo, evaluación de su efectividad a través del ciclo
de vida del proyecto.
— Gestión de suministros
En este área se incluyen los procesos necesarios para adquirir bienes
y servicios externos a la organización que realiza el proyecto, para
completar el alcance del proyecto. Incluye:
• Definición de actividades. Identificación de las actividades específi-
cas que deben llevarse a cabo para producir los diferentes elemen-
tos entregables del proyecto.
• Secuenciamiento de actividades. Identificación y documentación
de las dependencias entre actividades.
actividades individuales
• Desarrollo de la programación de actividades. Análisis de las
secuencias de las actividades, duraciones de las actividades y reque-
rimientos de recursos para crear la planificación de proyecto.
• Control de la programación de actividades. Control de los cambios
en la programación del proyecto.
8.3. CICLO DE VIDA

Se habla de ciclo de vida como del conjunto de fases y tareas que confor-
man la realización de una actividad en el tiempo.
Este concepto está tremendamente generalizado en la actualidad, encon-
trándonos con expresiones tales como: ciclo de vida de un servicio, ciclo de
vida del proceso de venta, ciclo de vida del desarrollo de software, etc.
En este sentido y centrándose en el área de interés de proyectos, se dis-
tinguirá entre:
• Ciclo de vida de un proyecto.
• Ciclo de vida de la dirección de proyectos.
8.3.1. Ciclo de vida de un proyecto

Es normal dividir cada proyecto en fases de cara a mejorar la gestión del
mismo. Estas fases a su vez contienen hitos que permiten ejecutar un control
sobre las actividades del día a día de la ejecución del proyecto. El conjunto de
estas fases es denominado ciclo de vida del proyecto.
Cada fase del proyecto vendrá marcada por la terminación de una serie de
«entregables», es decir de una serie de realizaciones tangibles y verificables
(un análisis de viabilidad, un diseño detallado, un prototipo, etc.)
La conclusión de una fase del proyecto está marcada por una revisión de
los entregables claves y de la actividad realizada en el proyecto a la fecha para:
a) Determinar si el proyecto deberá continuar hasta la siguiente fase.
b) Detectar y corregir errores de forma eficiente en cuanto a costes.
Estas revisiones de fin de fase se suelen denominar finales de fase o sim-
plemente reuniones de seguimiento, o reuniones de progreso.
Cada fase del proyecto habitualmente incluye un conjunto de entregables
definidos, designados para establecer el nivel deseado de control por parte de
la dirección. La mayor parte de esos entregables están relacionados con el
entregable principal de la fase y las fases habitualmente se denominan en
relación con esos entregables principales. Así se puede hablar de: Diseño,
Construcción, Prueba, Arranque, Concepto, etc.
El ciclo de vida del proyecto sirve para definir el comienzo y el final de un
proyecto. Por ejemplo si una organización identifica una oportunidad a la que
quiere responder, autorizará un análisis de necesidades o un estudio de viabi-
lidad para decidir si debe acometer o no el proyecto. La definición del ciclo de
vida del proyecto determinará si el estudio de viabilidad se trata como la pri-
mera fase del proyecto o de forma aislada como un proyecto separado.
El ciclo de vida determinará también qué acciones de transición se inclu-
yen al principio y al final del proyecto, de esta manera el ciclo de vida del pro-
yecto enlaza el proyecto con las operaciones del servicio continuo de la orga-
nización encargada de la realización.
La secuencia de fases definida por la mayor parte de ciclos de vida de pro-
yectos implica la transferencia de tecnología o conocimiento en alguna forma
(requerimientos de diseño, diseño para fabricación, etc.). Los entregables de
la fase precedente son aprobados habitualmente antes que el trabajo comien-
ce en la siguiente fase. Sin embargo la fase siguiente ha comenzado algunas
veces previamente a la aprobación de la aprobación de los entregables de la
fase previa cuando los riesgos involucrados son juzgados aceptables.
Los ciclos de vida de los proyectos generalmente definen
• Que trabajo técnico debe hacerse en cada fase.
• Quien debe estar involucrado en cada fase.
Los ciclos de vida de los proyectos pueden ser muy generales o por el con-
trario con un alto nivel de detalle. Estos últimos, más detallados, son conoci-
dos como metodologías o métodos de dirección de proyectos (más correcta-
mente, en castellano).
Para el caso concreto de Proyectos de Sistemas Multimedia que se trata

en este libro, se cita en el capítulo correspondiente a las Fases de Desarrollo,
los ciclos de vida específicos para estos proyectos.
8.3.2. Ciclo de vida de la dirección de proyecto

La actividad de dirigir un proyecto tiene su propio ciclo de vida que es
similar en cualquier proyecto, independientemente del área de conocimiento
en que se sitúe el mismo. Por eso se hablará del Ciclo de Vida de la Dirección
de Proyectos de forma general e independiente al Ciclo de Vida del proyecto
que será específico del área de conocimiento del proyecto en cuestión.
Siguiendo las directrices del PMI (PMBOK, 2000) y la experiencia de
Wysocki (Wysocki, 2000), se podrá establecer un ciclo de vida de la gestión de
proyectos con cinco etapas. Esas etapas coinciden con las etapas habituales
de una actividad de dirección: definición, planificación, ejecución, control y
cierre.
Como ya se vió, el PMI clasificaba los procesos inherentes a la dirección
de proyectos en procesos de inicio, planificación, ejecución, control y cierre.
Entre los procesos de planificación y ejecución existe un bucle de realimen-
tación gobernado por los procesos de control. Esta situación se esquematiza
en la figura 8.2.
INICIO PLANIFICACIÓN EJECUCIÓN
CONTROL
CIERRE
FIGURA 8.2. Bucle de realimentación de los procesos de dirección de proyectos.

Usando este concepto Wysocki (Wyscocky, 2000) y sus colaboradores ide-

aron un ciclo de vida de la dirección de proyectos con cinco fases, divididas a
su vez en cinco actividades por fase
a) Establecimiento del alcance
b) Desarrollo del plan detallado de proyecto
c) Ejecución del plan de proyecto
d) Monitorización y control del avance
e) Cierre del proyecto
Se usará este ciclo de vida en estas notas para nuestro propósito pedagó-
gico, porque resulta claro y estructurado. El alumno podrá comprobar que
existen otras estructuraciones similares de Ciclos de Vida de Dirección de
Proyectos en otros autores relacionados con la Dirección de Proyectos.
Establecimiento del alcance Desarrollo del plan detallado Ejecución del plan
•Exposición del problema / oportunidad •Identificación de las actividades del proyecto •Localizac. y organizac. del equipo de trabajo
•Establecimiento de la meta del proyecto •Estimación de la duración de las actividades •Establecim. de las reglas de func. del equipo
•Definición de los objetivos del proyecto •Determinación de los recursos necesarios •Establec. del nivel de los recursos
•Identificación de los criterios para el éxito •Construccion/análisis de la red de actividades •Programación de los “paquetes de trabajo”
•Listado de suposiciones, riesgos y obstáculos •Preparación de la propuesta de proyecto •Documentación de los “paquetes de trabajo”
Monitorizac./control del avance

•Establec. del sistema de inform. de avance
•Instal. herram./procesos de control de cambios
•Definic. del proceso de escalación de problemas
•Monitor. del avance del proyecto frente al plan
•Revisión del plan de proyecto
Cierre del proyecto

•Obtención de la aceptación del cliente
•Implantación de los “entregables”
•Finalización de la documentación del proyecto
•Realizac. De una auditoría de postimplantación
•Distribuir el informe final del proyecto
FIGURA 8.3. Bucle de realimentación de los procesos de dirección de proyectos.

Ampliación de funciones.
• Establecimiento del alcance

En esta fase se establece una exposición inicial del proyecto. Se prepa-
rará un documento que describirá que problema u oportunidad se va a
resolver o abordar por el proyecto; la meta del proyecto y sus objetivos;
cómo se medirá el éxito del proyecto; y que riesgos, obstáculos y supo-

siciones pueden afectar al resultado del proyecto. Este documento
será breve (no mas de una o dos hojas) y se le podrá denominar
«Declaración de la visión de conjunto del proyecto» (Project Overview
Statement – POS). Este documento recibe varios nombres en el argot
habitual de los proyectos: «Documento de entendimiento», «Exposi-
ción del alcance», «Definición inicial del proyecto» o «Exposición del
trabajo». Habitualmente asociados a este primer documento deben
figurar un análisis coste-beneficio, un análisis de retorno de la inver-
sión, etc. que suelen ser necesarios para tomar la decisión de abordar
o no el proyecto.
• Desarrollo del plan detallado de proyecto
En esta fase se desarrollaran los detalles del plan de proyecto. Para lle-
gar a este plan, deberán tenerse reuniones formales de planificación
entre todos los involucrados en el proyecto. Los productos de estas reu-
niones de planificación serán la descripción detallada de cada activi-
dad a realizar, los recursos necesarios para realizar cada actividad, las
fechas programadas de comienzo y fin de cada actividad, el coste y la
fecha de finalización estimados para el proyecto. Con todos estos «pro-
ductos» se redactará un documento que se denominará «Propuesta de
proyecto» que una vez aprobado indicará el inicio de la siguiente fase.
• Ejecución del plan de proyecto
En esta fase se designará el equipo de proyecto, las programaciones

concretas de trabajo, así como las descripciones específicas del mismo.
Esta fase da paso a la de control que puede suponer un bucle de reali-
mentación «Control ➔ Desarrollo de plan modificado ➔ Ejecución de
plan modificado ➔ Control», tal como se esquematiza en el diagrama
del ciclo de vida.
• Monitorización y control del avance
• Tan pronto como comienza el trabajo del proyecto, comienza la fase de

monitorización y control. Se definirán una serie de informes de estado
de proyecto normalizados que se usarán para monitorizar el avance
del proyecto. Una parte importante de esta fase es la gestión de cam-
bios, para ello se establecerán procedimientos que permitan el proce-
so de peticiones de cambio. En esta fase también se activa el bucle de
realimentación que permite el control, puesto que los cambios origi-
narán siempre replanificaciones del proyecto. Se gestionará también
la problemática asociada con las finalizaciones anteriores o posterio-
res a la programación del trabajo de las distintas actividades. Para tra-
tar todo lo planteado, se dispondrá de un procedimiento de escalación
de problemas.
• Cierre del proyecto

Esta fase comienza con la aceptación del proyecto por parte del
cliente. Los criterios de finalización del proyecto deben haber sido
claramente establecidos y acordados con el cliente como parte del
plan de proyecto. Las actividades más habituales del cierre de un
proyecto serán: La instalación y/o puesta en explotación de los ele-
mentos entregables, la creación de los informes y documentación
finales o de cierre de proyecto y la realización de una auditoria de
post-implantación.
8.4. ESTABLECIMIENTO DEL ÁMBITO
8.4.1. Introducción
Es absolutamente imprescindible para el desarrollo de un proyecto

comenzar con un perfecto entendimiento de qué se va a realizar. Este enten-
dimiento debe estar claro y acordado entre el peticionario (cliente) y el reali-
zador del proyecto (proveedor).
«Si no se sabe dónde se va, cómo saber cuando se llegará y cómo saber si
ya se ha llegado».
Este entendimiento claro y de común acuerdo debe detallarse por escrito
en un documento escrito en un lenguaje capaz de ser entendido por todos los
involucrados en el proyecto. Este documento se denominará, siguiendo a
Wysocki: Exposición de la visión de conjunto del proyecto (Project Ove-
view Statement, POS).
Adicionalmente y si la complejidad del proyecto lo aconseja se escri-
birá un documento más extenso que profundice y desarrolle el anterior
para los miembros del equipo de desarrollo del proyecto. Este documen-
to por ser de uso más restringido y dirigido a especialistas en el desarro-
llo del proyecto podrá usar un lenguaje más concreto y técnico que el
anterior. Este documento se denominará, siguiendo a Wysocki: Exposi-
ción de la definición del proyecto (Project Definition Statement,
PDS).
El documento POS se desarrollará a lo largo de sesiones conjuntas de pla-
nificación del proyecto en la que todos los involucrados moderados conve-
nientemente por el director del proyecto proporcionaran su conocimiento
para la realización de este documento.
El PDS se desarrollará de forma similar, pero basándose en el POS elabo-
rado, y restringiendo el grupo participante en las sesiones de planificación, al
equipo de especialistas en el desarrollo del proyecto.
Las partes de un POS/PDS serán:

• Declaración o establecimiento del problema a resolver o la oportunidad
de negocio a abordar.
• Establecimiento de la meta del proyecto.
• Establecimiento de los objetivos del proyecto.
• Identificación de los criterios de éxito.
• Lista de suposiciones, riesgos y obstáculos.
• Anexos.
• Análisis de riesgos.
• Análisis financieros.
8.4.2. Exposición del problema o la oportunidad

Esta exposición constituye un hecho que no precisa de ser definido o
defendido. Una exposición de un problema o una oportunidad que es conoci-
da y aceptada por la organización constituye el cimiento sobre el que cons-
truir la base lógica del proyecto.
8.4.3. Establecimiento de la meta del proyecto

Es establecer lo que se intenta realizar para abordar el problema o la
oportunidad identificada en la sección anterior.
Un proyecto tiene una meta. La meta proporciona el propósito y la
dirección del proyecto. Define el producto final a entregar de forma que
todo el mundo entienda que hay que llevar a cabo en términos claros. La
exposición o manifestación de la meta será guiada como punto continuo de
referencia para las cuestiones que aparezcan acerca del alcance o el propó-
sito del proyecto.
La exposición de la meta no debe tener ninguna terminología que pueda
resultar incomprensible para alguien que pueda leerla. Debe estar escrita en
el lenguaje del negocio de la organización, de forma que cualquier persona
involucrada en el proyecto (no sólo el equipo de trabajo de desarrollo del pro-
yecto) la entienda sin mayores explicaciones.
Resulta conveniente que en la redacción de la meta se siga la regla
«SMART»:
• Specific.- Ser específico en la determinación del objetivo.
• Measurable.-Establecer indicadores del progreso medibles.
• Assignable.- Hacer el objeto asignable a una persona para su finalización

• Realistic.- Expresar lo que se puede hacer de una forma realista con los
recursos disponibles.
• Time-related.- Poner de manifiesto cuándo se alcanzará el objetivo
8.4.4. Objetivos
Constituye el desarrollo detallado de la meta descrita en el apartado
anterior. Definen los límites del alcance del proyecto. De hecho los objetivos
que se escriben para una meta específica no son más que una descomposi-
ción de la expresión de la meta en un conjunto necesario y suficiente de
objetivos.
Se podría decir que la meta es el «resumen para la dirección» de los
objetivos.
Para la exposición de objetivos se aconseja incluir cuatro partes:
• Un resultado. Exposición de lo qué ha de llevarse a cabo.
• Un marco temporal. La fecha de terminación esperada.
• Unos parámetros para medida. Las parámetros que se usaran para
valorar el éxito.
• Unas acciones. Cómo se alcanzará el objetivo.
8.4.5. Factores de éxito

Es la respuesta a la pregunta: ¿Por qué se quiere hacer el proyecto?
Es el valor de negocio medible que resultará de hacer el proyecto. Es la
venta del proyecto a la alta dirección.
Los criterios de éxito deben responder a la pregunta de ¿qué debe ocurrir
para decir que el proyecto tenga éxito?
Los criterios deben ser cuantificables y medibles y, si es posible, ser expre-
sados en términos de valor para el negocio o actividad de la organización
peticionaria del proyecto.
La mejor opción es manifestar claramente el impacto del proyecto en la
cuenta de resultados. Esto se puede expresar desde el punto de vista de incre-
mento en los márgenes, mayores ingresos, mejoras en la productividad,
reducción de costes de fabricación, etc.
Si no es posible expresarse en cuanto a beneficios para la cuenta de resul-
tados se puede considerar como alternativa exposiciones cuantificables del
impacto del proyecto en la eficacia y eficiencia, en la calidad y en la satisfac-

ción del cliente.
Puesto que la dirección trabaja con elementos tangibles se deben expre-
sar nuestros criterios de éxito en términos cuantitativos, las medidas subje-
tivas del éxito no funcionaran bien como medidas del éxito de cara a la
dirección.
8.4.6. Supuestos, riesgos y obstáculos

Aquí se identifican los factores que afectaran el resultado del proyecto y
que se quieren poner de manifiesto ante la dirección. Estos factores pueden
afectar a los entregables del proyecto, a la realización de los criterios de éxi-
to, a la capacidad del equipo de proyecto de completar el proyecto según se
ha planeado o a cualquier otra condición de entorno o relativa a la organiza-
ción que sea relevante para el proyecto.
En el POS se colocan los riesgos generales que se quiere que conozca la
dirección mientras que en el PDS se hará un listado más exhaustivo e riesgos
que deben conocer todos los miembros del proyecto.
Los riesgos pueden ser:
• Tecnológicos.
• Del entorno.
• Interpersonales.
• Culturales.
8.4.7. Formulario o modelo para el POS / PDS

A continuación se incluye un ejemplo posible de formulario o modelo del
POS (tabla 8.2).
TABLA 8.2. Formulario POS / PDS

Exposición de la Nombre del proyecto Número de Director del
visión de conjunto proyecto proyecto
del proyecto
Problema / Oportunidad
Meta
Objetivos
Criterios de éxito
Supuestos, riesgos, obstáculos
8.5. DESARROLLO DEL PLAN DE PROYECTO
8.5.1. Identificación de las actividades

Una vez definido el proyecto de forma detallada y sus objetivos es nece-
sario realizar un estudio exhaustivo de las actividades a realizar en el mismo.
Esta descomposición permitirá el análisis detallado de la realización de cada
una de las tareas así como la posterior identificación de los recursos necesa-
rios para la ejecución de las mismas y los costes asociados a ellas.
La «estructura de desagregación del trabajo» (EDT) es una descripción

jerárquica del trabajo que deberá realizarse para completar el proyecto tal
como se definió en el documento de «exposición de la visión de conjunto del
proyecto» (Project Oveview Statement, POS).
Objetivo i
Actividad 1 Actividad 2 ... ... Actividad n NIVEL 1
Actividad 1 Actividad 2 ... ... Actividad k NIVEL 2
Actividad j NIVEL p
Tarea 1 Tarea 2 .... Tarea m (nivel más bajo)
FIGURA 8.4. Estructura de desagregación del trabajo (EDT).
Existen dos términos, actividad y tarea, que se suelen usar indistinta-

mente llevando a confusión. En este texto se usará actividad como un con-
junto de tareas:
• Actividad: Cualquier subdivisión del trabajo.
• Tarea: Una subdivisión más pequeña del trabajo, que forma parte una
actividad.
Para generar una EDT, lo más conveniente es hacerlo en una sesión con-
junta de planificación de proyecto en la que intervienen todos los involucra-
dos en el mismo.
Creación del esquema EDT de arriba hacia abajo

Este es el enfoque más sistemático y útil para la mayor parte de los
proyectos.
Existen otros enfoques de abajo hacia arriba que usan técnicas de «tor-
menta de ideas» (brainstorming), que no se consideraran en estas notas.
En este enfoque de arriba hacia abajo, se parte de los objetivos definidos
en el POS, para cada objetivo se establecen las actividades de primer nivel o
nivel más alto y a partir de ahí se va desagregando cada actividad en otras
actividades y así sucesivamente hasta que se llega a las actividades que tiene
el suficiente nivel de detalle o desagregación, según las reglas que más ade-
lante se expondrán. Estas actividades de nivel más bajo tendrán el suficiente
nivel de detalle para ser descompuestas en tareas.
Se sabrá que se ha alcanzado el nivel más bajo de desagregación si se
cumplen las siguientes condiciones:
• Es medible el estatus o el grado de finalización.
• Los eventos de comienzo y fin están claramente definidos.
• La actividad tiene al menos un elemento entregable.
• El tiempo y el coste se pueden estimar con relativa facilidad.
• La duración de la actividad se encuentra entre límite aceptables.
• Las asignaciones de trabajo son independientes.
8.5.2. Estimación de la duración de las actividades

La duración de las actividades es una magnitud más complicada de obte-
ner puesto que no se suele conocer con precisión salvo en casos de proyectos
muy repetitivos o en sistemas de fabricación en serie. Por tanto se tendrá que
trabajar con una estimación de la duración en la mayor parte de los casos.
Para ello se dispone de las técnicas que se abordan a continuación.
8.5.3. Técnica de similitud con otras actividades

Algunas de las actividades del proyecto serán similares a otras de otros
proyectos de las que se conozca la duración. Así se puede obtener una esti-
mación directa o por extrapolación.
8.5.4. Técnica de análisis de datos históricos

Si se dispone de una buena práctica de Dirección de proyectos, se dis-
pondrá de datos de históricos de proyectos con tiempos estimados y tiempos
reales de duración de actividades. Estos datos históricos constituirán una
importante base de datos de conocimiento para la estimación de la duración
de las actividades. Estos datos históricos aplicaran no solo a la duración sino
también a los perfiles necesarios y a otras características de cada una de las

actividades.
8.5.5. Técnica de asesoramiento por expertos
Si las actividades del proyecto corresponden a tecnologías no maduras o

novedosas, no existirá experiencia en la organización en cuanto a datos histó-
ricos o semejantes y será preciso recurrir al asesoramiento de expertos en esas
tecnologías que aportaran datos acerca de las duraciones y perfiles requeridos.
8.5.6. Técnica «Delphi»
Es una técnica de grupo que pretende extraer y resumir el conocimiento

del grupo para llegar a una estimación.
Se plantea el problema a un grupo de expertos, en este caso la duración
de la actividad. Se tabulan los datos y se pide a los que han emitido los datos
mas alejados de la media que expliquen sus razones. Se realiza una segunda
y tercera iteraciones, en el mismo sentido. La estimación del dato (la dura-
ción) será el promedio de los últimos datos obtenidos.
8.5.7. Técnica de los «tres puntos»
La duración de las actividades es una variable aleatoria. Para cualquier

ocurrencia de la actividad no es posible conocer en que extremo cae la dura-
ción de la actividad pero se pueden hacer afirmaciones estadísticas acerca de
su verosimilitud en cada caso.
Para realizar esto existe un marco de trabajo que proporciona un método
para abordar esta situación. Para ello se necesitan tener tres estimaciones de
la duración: optimista, pesimista y la más realista. La estimación más opti-
mista es la que tiene en cuenta que todo salga bien, la más pesimista la que
considera todo lo que puede ir mal, y la más verosímil es la que considera la
duración más probable. La estimación, considerando que la distribución de
la variable aleatoria «duración de la actividad» sigue una distribución Beta se
calcularía como sigue:
O = Estimación Optimista de la duración
P = Estimación Pesimista de la duración
R = Estimación más Realista de la duración
E = (O+4*R+P)/6
siendo E la estimación de la duración.
8.5.8. Técnica «Delphi mejorada» o de «banda ancha»

Es la combinación de la técnica Delphi con la de los tres puntos. El grupo
de expertos en lugar de hacer una única estimación de la duración cada uno,
realiza tres estimaciones (pesimista, optimista y realista) y se procede con las
tres iteraciones de la técnica Delphi.
8.5.9. Estimación de los recursos necesarios

Los recursos necesarios para la realización de las actividades serán:
• Personal. Suelen ser los recursos más difíciles de programar debido a
la disponibilidad.
• Instalaciones. Estas van desde salas de reunión para las sesiones de
planificación, hasta instalaciones específicas de datos (CPDs, sistemas
de comunicaciones, etc.) o instalaciones industriales.
• Equipos. Equipamiento informático, equipamiento tecnológico espe-
cífico del proyecto, maquinaria, etc.
• Dinero. Aquí se incluirán los gastos inherentes al proyecto: viajes,
comidas, repuestos de los equipos, etc.
• Materiales. Es todo aquello que es necesario para la fabricación de ele-
mentos o construcción: acero, cables, materiales de construcción, etc.
Para el caso de recursos humanos o personal será útil disponer de las si-
guientes tablas.
Tabla «actividades»/«capacidades requeridas»
Esta es una tabla de requerimientos o necesidades para cada una de las

actividades. Tendrá un aspecto similar a la siguiente. Capacidad se puede
identificar por «conocimientos de...»
TABLA 8.3. Tabla actividades/capacidades requeridas

Capacidad 1 Capacidad 2 Capacidad k
Actividad 1
Actividad 2
Actividad n
Tabla «personal»/«capacidades disponibles»
Es la tabla que representa las capacidades disponibles en la organización

para la realización de actividades de proyecto.
TABLA 8.4. Tabla personal/capacidades disponibles

Capacidad 1 Capacidad 2 Capacidad k
Persona 1
Persona 2
Persona m
Tabla «actividades»/«personal»
De las tablas 8.3 y 8.4 se deduce la tabla de asignación de las personas a

las actividades del proyecto según sus capacidades (tabla 8.5).
TABLA 8.5. Tabla actividades/personal

Actividad 1 Actividad 2 Actividad n
Persona 1
Persona 2
Persona m
8.5.10. Programación temporal. Construcción y análisis

de la red del proyecto
El diagrama de red del proyecto es la representación gráfica de la secuen-
cia en que se realizaran las actividades del proyecto.
Las actividades y su duración son los elementos básicos necesarios para
construir la representación secuencial gráfica del proyecto.
La representación gráfica en diagrama de red proporciona dos elementos

de información adicionales acerca del proyecto:
• El instante mas temprano en el que cada trabajo puede comenzar en
cada actividad.
• La fecha más temprana de terminación del proyecto.
La idea del diagrama de red es representar la secuencia de actividades
mediante una red o grafo, que es un conjunto de nodos y conexiones orienta-
das entre ellos. Existen dos posibilidades para la construcción de estos grafos
que son las que se explican a continuación.
8.5.11. Técnica de Actividades en las flechas (Activities on

Arrows – AOA)
En este método se colocan las actividades en las flechas del grafo, siendo
los nodos la representación de los hitos de comienzo y final de la actividad
(figura 8.5).
Act. 1 2
1
Act. 3
Act. 2
4 Act. 5
5
Act. 4
3
Act. 6
6
FIGURA 8.5. Técnica de actividades en las flechas (AOA).
Este método fue el usado en origen para los diagramas de red, pero actual-
mente se prefiere el siguiente (actividades en los nodos) debido a las ventajas
que presenta para la programación temporal con uso de ordenadores.
8.5.12. Técnica de Actividades en los nodos (Activities on

Nodes – AON)
Este método es justamente el dual del anterior. Ubica las actividades en

los nodos del grafo, siendo los eventos de finalización de una actividad y
comienzo de la siguiente las flechas orientadas que indican a su vez la
secuencia o precedencia de actividades.
Este diagrama se suele denominar diagrama de precedencia (figura 8.6).
Act 1 Act 3
Inicio Act 5 Act 6 Fin
Act 2 Act 4
FIGURA 8.6. Técnica de actividades en los nodos (AON).
8.5.13. Diagramas de precedencia con AON
Para crear el diagrama de precedencia se procede como se recoge a con-

tinuación:
1. Se listaran las actividades y sus relaciones de precedencia.
2. Se creará un nodo de inicio.
3. Se dibujará flechas desde el nodo de comienzo al primer nodo de
actividad.
4. Se colocaran en la secuencia correcta las siguientes actividades (pre-
decesoras ➔ sucesoras).
5. Se repetirá el proceso a la inversa (sucesoras ‡ predecesoras).
6. Se creará el nodo de fin.
7. Se revisará todo el diagrama de nuevo para ver si está correcto.
Para su análisis se seguirá el siguiente método: se realizarán dos recorridos
sobre el diagrama para poder calcular los tiempos que figuran en la tabla 8.6,
para cada una de las actividades del diagrama.
TABLA 8.6. Análisis del diagrama de procedencia con AON

Comienzo más temprano ES Early start
Finalización más temprana EF Early finish
Comienzo más tardío LS Late start
Finalización más tardía LF Late finish
Y se escribirán sobre la actividad como indica la figura 8.7.
ES EF
Tarea j
Duración = T
LS LF
FIGURA 8.7. Análisis del diagrama de procedencia con AON. Actividad.
Una actividad y su sucesora no tienen porque ser contiguas en el tiempo,

es decir el instante final de la predecesora no tiene porque coincidir con el
instante inicial de la sucesora. Esta situación se pone de manifiesto, a modo
de ejemplo, en la figura 8.8, que representa una vista del calendario de tare-
as, resultado de una planificación. Pueden existir retrasos (R), la sucesora
comienza R unidades de tiempo después del instante de finalización de la
predecesora. En el caso de existir adelantos (A) la sucesora comenzara A uni-
dades de tiempo antes del instante de finalización de la predecesora. Esto
R
habrá de tenerse en cuenta en el análisis de la red.
Oct 2003
ID Actividad / Tarea Comienzo Fin Duración
30 1 2 3 4 5 6 7 8 9 10 11 12 13
1 Tarea 1 30/09/2003 30/09/2003 1d
2 Tarea 2 07/10/2003 10/10/2003 4d
3 Tarea 3 02/10/2003 03/10/2003 2d
4 Tarea 4 03/10/2003 07/10/2003 3d
5 Tarea 5 09/10/2003 09/10/2003 1d
A
FIGURA 8.8. Actividades: adelantos y retrasos.
Primer recorrido: Relaciones fin a comienzo:

1. Se establece el comienzo más temprano para la primera actividad.
2. Se comienza a la izquierda y se trabaja de izquierda a derecha.
3. Se usan las relaciones EFj = ESj + Tj ; ESj+1 = EFj + R (-A).
4. Cuando una actividad sucesora tiene múltiples predecesoras, se usa-
rá la finalización mas temprana (EF) mayor de las predecesoras
como comienzo mas temprano (ES) de la sucesora.
5. Se continuará hasta el final de la red.
Segundo recorrido: Relaciones de comienzo a fin:
1. Se establece la finalización más tardía (LF) de la última tarea igual al
de la finalización más temprana de la misma.
2. Se comienza a la derecha de la red y se trabaja de derecha a izquierda.
3. Se usan las relaciones LSj = LFj – Tj ; LFj-1 = LSj – R (+A).
4. Cuando una actividad predecesora tiene múltiples sucesoras, se usará
el comienzo más tardío (LS) menor de las sucesoras como finalización
más tardía de la predecesora.
5. Se continúa hasta el comienzo de la red.
Las tareas pueden tener holguras. Se definen dos clases de holguras:
• Holgura total: (LFj – EFj) o bién (LSj – ESj)
• Holgura libre: (ESj – EFj-1)
8.5.14. Método del Camino Crítico (Critical Path Method – CPM)

Usando el diagrama de precedencia anteriormente analizado se puede defi-
nir el camino critico como aquel camino en la red en el que cualquier retraso
en las actividades afectará a la duración de la programación del proyecto.
Este camino crítico representa también:
• El camino más largo (de mayor duración) de todos los caminos posi-
bles de la red del proyecto.
• El camino en que todas sus actividades presentan holgura cero.
• La duración total del proyecto.
El método de programación que usa el diagrama de precedencia con
duración determinista de las actividades se denomina Método del Camino Crí-
tico (CPM – Critical Path Meted)
8.5.15. Metodo PERT Program Evaluation

and Review Technique
Si se usan los diagramas de precedencia, pero para la estimación de la dura-
ción de las actividades se considera que ésta es una distribución de probabili-
dad, y se usa el método de los tres puntos explicado anteriormente para estimar
duraciones esperadas, entonces se hablará de método PERT de programación.
En ocasiones a los diagramas de precedencia de un proyecto se les deno-
mina Diagramas PERT, de forma incorrecta, ya que como se ha visto solo se
estará ante el método PERT si se considera la duración de las actividades
como una distribución de probabilidad.
8.5.16. Diagrama de Gantt

Tradicionalmente se ha usado el denominado diagrama de Gantt como
herramienta de programación temporal del proyecto. Este diagrama no es
más que un calendario de tareas resultado de una programación previa reali-
zada mediante las técnicas de red expuestas anteriormente. En ningún caso
se aconseja usarlo como «entrada» a la programación, pues no permite el
cálculo de tiempos anteriormente expuesto, ni de las holguras temporales de
las tareas. Es útil como «salida» o resultado de la programación. En la figu-
ra 8.9 se presenta el formato de este diagrama, que ya anteriormente fue
mencionado como calendario de tareas.
Oct 2003
ID Actividad / Tarea Comienzo Fin Duración
30 1 2 3 4 5 6 7 8 9 10 11 12 13
1 Tarea 1 30/09/2003 30/09/2003 1d
2 Tarea 2 07/10/2003 10/10/2003 4d
3 Tarea 3 02/10/2003 03/10/2003 2d
4 Tarea 4 03/10/2003 07/10/2003 3d
5 Tarea 5 09/10/2003 09/10/2003 1d
FIGURA 8.9. Diagrama de Gantt.
8.6. EJECUCIÓN DEL PLAN DE PROYECTO
8.6.1. Creación, organización y gestión del equipo de trabajo
Creación del equipo
Los planes de proyecto y su ejecución son eficaces si el director del pro-

yecto y su equipo, que son los que lo implantaran, lo son.
Cuando se forma un equipo de trabajo no solo hay que tener en conside-

ración las capacidades o habilidades técnicas de sus miembros, sino también
los papeles que jugará cada uno y la «química» que exista entre ellos y el
director de proyecto.
Un equipo de proyecto tendrá en general tres grupos de personas.
• El director del proyecto
Es quien lleva el liderazgo del proyecto. Es responsable de finalizar el
proyecto a tiempo, dentro del presupuesto establecido y de acuerdo con
las especificaciones.
— Entre sus capacidades destacan:
— Experiencia.
— Pericia en planteamientos estratégicos y liderazgo.
— Pericia técnica.
— Aptitud para las relaciones interpersonales.
— Talento directivo.
• El equipo principal
Tiene un papel clave en el proyecto, proporcionando capacidades de
aplicación general en el mismo. Pueden ser responsables de diversas
actividades claves, o conjuntos de actividades.
Participan junto con el director de proyecto en las tareas de planifica-
ción del mismo.
— Entre las capacidades de sus componentes destacan:
— Capacidad de compromiso.
— Flexibilidad.
Orientación a tareas.
— Capacidad para trabajar dentro de programaciones y restriccio-
nes.
— Disposición para proporcionar confianza y apoyo.
— Orientación al trabajo en equipo.
— Pensamiento abierto.
— Capacidad para trabajar a través de las estructuras y las autoridades
en la organización.
— Capacidad para usar herramientas de administración de proyectos.
• El equipo fluctuante o temporal

Aportan capacidades específicas que no poseen los componentes del
equipo principal. Se vinculan al proyecto por periodos determinados
de tiempo, justo cuando sus capacidades son necesarias.
El uso de personal temporal en el proyecto complica la gestión del pro-
yecto, ya que es más difícil formar equipo con personas que no tienen
una vinculación definitiva al proyecto, sino que solamente prestan sus
servicios cuando son requeridos.
Organización y gestión del equipo
Una vez elegido el personal que formará el equipo de trabajo es preciso

comenzar a trabajar para pasar de contar con un conjunto de personas a con-
tar con un equipo de trabajo.
Existen algunos temas a tener en cuenta que conviene mencionar
• Autoridad y responsabilidad
El director del proyecto tiene la responsabilidad de finalizar el proyec-
to a tiempo, dentro del presupuesto y cumpliendo las especificaciones.
Para ello la organización le dota de la autoridad necesaria. La autori-
dad puede delegarla en otros profesionales (en especial en grandes pro-
yectos) que serán los responsables de cada una de las actividades, pero
la responsabilidad no se delega.
• Reglas de funcionamiento
Para funcionar como un equipo es preciso dotarse de unas reglas de
funcionamiento interno, un modelo de relación que permita trabajar
juntos con la máxima eficacia.
Estas reglas definirán de que forma:
— Trabaja junto el equipo.
— Se toman las decisiones.
— Se resuelven los conflictos.
— Se informa del progreso.
8.6.2. Revisión de la programación temporal en función

de la disponibilidad de los recursos
Una vez terminado el proceso de programación con la construcción del

diagrama de red, ya se está en condiciones de saber cuando hay que realizar
las actividades, en que orden, con qué recursos, etc. Ahora se necesitará
determinar si se puede llevar a cabo la programación diseñada con los recur-
sos disponibles.
8.6.3. Nivelación de recursos
Lo habitual es que la programación temporal de recursos realizada traiga

consigo una sobreasignación de recursos en determinados periodos, ya que el
foco de la programación se realizó sólo teniendo en cuenta fechas de comien-
zo y final de las actividades, así como su duración, pero no se tuvo en cuenta
la disponibilidad de los recursos. Las técnicas que permiten evitar o paliar en
alguna medida esa sobreasignación constituye lo que se ha dado en denomi-
nar «nivelación de recursos».
Se puede hablar de tres técnicas principales para la nivelación de recur-
sos:
• Uso de las holguras de las actividades. En las actividades que pre-
sentan holgura se dispone de una ventana de tiempo para su realiza-
ción que viene marcada por el intervalo ES-LF. El uso adecuado de esa
ventana permitirá paliar las posibles sobreasignaciones de recursos.
• Desplazamiento de la fecha de finalización. No en todos los proyec-
tos la fecha de finalización es un factor crítico e inamovible. Si se pue-
de jugar con la fecha de terminación o con ésta y las holguras se dispo-
ne de una buena herramienta para nivelar recursos.
• Uso de «horas extras». El uso de horas extras puede ayudar a aliviar
la sobreasiganción porque permite realizar más cantidad de trabajo sin
variar la programación temporal. Hay que ver si económicamente es
posible puesto que es habitual que el coste total del proyecto sea una
restricción inamovible
Se pueden usar otras técnicas más «imaginativas» para la nivelación de
recursos tales como mayor descomposición de las actividades, alargar activi-
dades con recursos a tiempo parcial, etc.
8.6.4. Creación de los «Paquetes de trabajo»
Otra actividad a realizar una vez terminado el proceso de programación

es la especificación clara del trabajo a realizar en cada actividad. Se recuer-
da que las actividades estaban formadas por tareas en el último nivel de
desagregación del trabajo. Este conjunto de tareas a realizar en cada activi-
dad del nivel más bajo de desagregación es lo que se denomina «Paquetes de
trabajo».
8.6.5. Documentación de los «Paquetes de trabajo»

Los paquetes de trabajo describen en detalle las tareas a realizar para
completar el trabajo de una actividad. Son útiles también como herramienta
de seguimiento, pues permiten ver con detalle cuánto trabajo del previsto se
ha realizado.
Para documentarlos se usarán dos documentos:
— La hoja de asignaciones de los paquetes de trabajo.
— El informe de descripción del paquete de trabajo.
• Hoja de asignaciones del Paquete de Trabajo
Es esencialmente un directorio de los distintos paquetes de trabajo del
proyecto, las fechas de comienzo y finalización y los responsables asig-
nados. Tendrá un aspecto similar a la tabla 8.7.
TABLA 8.7. Hoja de asignación del paquete de trabajo
Hoja de asignaciones de los Paquetes Proyecto Director del Proyecto

de Trabajo
PAQUETE PROGRAMACIÓN RESPONSABLE

DE TRABAJO
Num. Marca Nombre ES – Fecha más temprana LS – Fecha mas tardía Nombre Información de
de de comienzo de finalización contacto
finaliza
ción
• Informe de descripción del Paquete de Trabajo

Describe los detalles de cómo se va a llevar a cabo el trabajo de la acti-
vidad.
Las descripciones deben ser completas, de forma que cualquier miem-
bro del equipo de proyecto pueda leerlas y entender que es lo que ha de
hacerse para completar la actividad.
Cada tarea debe estar descrita de forma que el estado del paquete de
trabajo pueda ser determinado fácilmente. Lo ideal es que la lista de
tareas sea una lista de comprobación, de forma que una vez que se
hayan marcado todas las tareas como completadas se puede dar por
finalizada la actividad. Así el porcentaje de realización de la actividad
es el porcentaje de tareas marcadas como finalizadas.
Este informe puede tener un aspecto similar al que se presenta en la
tabla 8.8.
TABLA 8.8. Informe de descripción del paquete de trabajo
Descripción del Paquete de Trabajo Proyecto Director del Proyecto
Nombre del paquete de trabajo Número Fecha comienzo Fecha de fin
TAREA RESPONSABLE
Num. Marca Nombre Descripción Duración Nombre Información de
de contacto
finaliza
ción
8.7. MONITORIZACIÓN Y CONTROL DEL PROYECTO

El plan de proyecto puede verse como un sistema sometido a perturba-
ciones que tiene que mantenerse en equilibrio dinámico frente a las mismas.
La monitorización del proyecto servirá para descubrir, cuanto antes, situa-
ciones de desequilibrio de forma que sea posible reaccionar con planes de
acción correctores.
Monitorización
Para poder monitorizar la realización del proyecto se instauraran una

serie de informes que estarán designados para presentar el grado de concor-
dancia de la realización en curso del proyecto con el plan realizado para el
mismo y para que esa misma información que presentan sea útil para corre-
gir las variaciones respecto a ese plan. Estos informes podrán ser en forma de
tablas o gráficos, siendo esta última la opción preferible para poder mostrar
tendencias. Los parámetros generalmente monitorizados tienen que ver con
niveles de rendimiento, costes y programaciones temporales.
Ejemplos comunes de informes de monitorización (o seguimiento) son:
• Programación temporal actual frente a la planificada.
• Tendencias en la programación temporal.
• Uso de recursos actual frente al planificado.
Control
Son las acciones tomadas en función del resultado de los informes. Estas
acciones están diseñadas para que cuando se implanten devuelvan el proyec-
to a una situación de conformidad con el plan de proyecto.
En general se puede decir que cuanto mayor control, menos riesgo de
desviación. Como en casi todo es preciso no llevar esta situación al extremo y
llegar a un equilibrio entre las acciones de control y el riesgo de resultados
desfavorables.
8.7.1. Información de progreso

Para poder controlar se necesita conocer si existen desviaciones. Este
conocimiento lo proporciona un sistema de generación de informes que
mantenga informado al director del proyecto de todas las variables que des-
criben el comportamiento de proyecto en comparación con el plan realizado.
Estos informes serán de los tipos que se mencionan a continuación.
Informes del periodo en curso

Informan del progreso de aquellas actividades que tienen programada su
realización durante el periodo que cubre el informe.
Informes acumulativos
Contienen la historia del proyecto desde su comienzo hasta el final del
periodo abarcado por el informe.
Informes de excepciones
Ponen de manifiesto las discrepancias frente al plan. Deben ser informes
escuetos para la dirección, por lo tanto deben poder ser interpretados de for-
ma rápida. Puede ser aconsejable introducir apéndices con información más
detallada con las causas de las discrepancias.
Informes de variaciones o discrepancias.

Son similares a los anteriores pero con información amplia sobre las dis-
crepancias. Si se presentan en forma tabular tendrán tres columnas: el valor
planificado, el valor actual y la diferencia. Los valores tabulados son habi-
tualmente la programación temporal y el coste.
8.7.2. Herramientas de generación de informes
Gantt de seguimiento
Así como en su momento se habló del error que supone usar el diagrama
de Gantt como herramienta de planificación y programación para el proyec-
to, debido a sus carencias en la representación de secuencias e interrelacio-
nes entre unas actividades con otras, sin embargo si resulta de extraordinaria
utilidad como herramienta de informe de seguimiento del proyecto en cuan-
to a fechas se refiere, ya que de un vistazo proporciona toda la información
precisa en cuanto a desviaciones de la programación temporal se refiere. En
este diagrama se presentará el diagrama de Gantt de la planificación y super-
puesto con cada una de las tareas el porcentaje de finalización de cada una de
ellas, en la fecha de generación del informe.
Diagramas de tendencia de hitos

Los hitos constituyen acontecimientos significativos en la vida del pro-
yecto. Es muy conveniente realizar un seguimiento de estos hitos para reali-
zar un adecuado control del proyecto
Los hitos se programan en el proyecto al igual que las actividades (de hecho
se les podría considerar actividades de duración nula). Por lo tanto será preci-
so vigilar las desviaciones que se producen en el cumplimiento de los hitos
(figura 8.10).
Estos diagramas, mostrando la tendencia de los hitos, hablan de la vida
del proyecto indicando su tendencia al retraso, a ir según lo planificado o,
como se pone de manifiesto en la segunda figura, indican algún desajuste en
la realización del proyecto, por aparecer puntos radicalmente fuera de ten-
dencia, que será preciso estudiar con más detenimiento.
En En
adelanto adelanto
Desviación
Desviación
En En
retraso retraso
Hitos Hitos
FIGURA 8.10. Diagrama de tendencia de hitos.
8.7.3. Gestión de cambios

Es radicalmente imposible definir necesidades de forma precisa para un
proyecto que tendrá una vida de varios meses o incluso de algunos años. Esta
situación lleva a que de forma ineludible aparecerán cambios a lo planifica-
do a lo largo de la vida de proyecto. El cambio es una situación intrínseca a
la Dirección de Proyectos, por lo que será preciso disponer de un buen siste-
ma de gestión de los mismos.
Las dos actividades fundamentales para la gestión de cambios son:
• La implantación de un registro de peticiones de cambio.
• La evaluación de impacto de los cambios solicitados.
Para poder implantar la primera será preciso disponer de un «Documen-
to de petición de cambios» en el que la petición de cualquier cambio debe
quedar perfectamente documentada.
Para la constancia de la evaluación del impacto se configurará el docu-
mento «Exposición del impacto del cambio» en el que los expertos del pro-
yecto manifestaran con profundidad qué influencia tiene el cambio en la pla-
nificación del proyecto.
En función del estudio de impacto se decidirá si se implanta el cambio, si
se implanta con modificaciones o si no resulta posible su implantación.
8.8. CIERRE DEL PROYECTO

El cierre del proyecto se produce una vez que el cliente ha aprobado todos
los elementos entregables del mismo.
En el cierre del proyecto se deben realizar las siguientes actividades:

• Obtención de la aceptación por parte del cliente de todos los elementos
entregables.
• Instalación de todos los elementos a entregar.
• Documentación del proyecto.
• Realización del informe final.
• Realización de auditoria de post-implantación.
• Celebración del éxito.
8.8.1. Aceptación del cliente
Puede ser una aceptación informal en la que el cliente firma la aceptación

sin realizar pruebas específicas de aceptación, por haberse ido realizando en
su momento en las diversas entregas a lo largo de la vida del proyecto.
Se podrá, por el contrario, realizar una aceptación formal para la que
habrá que disponer unas pruebas de aceptación solicitadas por el cliente. En
este caso la firma de la aceptación no se producirá hasta la superación de
dichas pruebas.
8.8.2. Instalación de todos los elementos a entregar
Esto supone crear un plan de despliegue de la instalación de los entrega-

bles, que implica la elaboración de un mini-proyecto con sus fases y tareas.
8.8.3. Documentación del proyecto
Suele ser la parte más difícil de completar en el cierre de un proyecto. La

documentación suele ser una tarea poco atractiva pero de una importancia
fundamental pues es:
• Una referencia para futuros cambios en los elementos entregables.
• Un registro histórico para la estimación de duraciones y costes de las
actividades/tareas de futuros proyectos.
• Un recurso de formación para futuros Directores de Proyecto.
• Una información valiosa para la formación y desarrollo posterior del
equipo de trabajo.
Una documentación completa del proyecto debería incluir:
• Documento de «Exposición de la Visión General» (POS).

• Documento de Propuesta de Proyecto, realizado al final de la fase de
planificación con la descripción completa de la misma.
• Programaciones temporales originales y modificadas por la nivelación
de recursos.
• Actas de todas las reuniones del equipo de trabajo.
• Copias de todos los informes de seguimiento.
• Documentos de diseño.
• Informes de cuestiones excepcionales.
• Documentos de aceptación del cliente.
• Informe de la auditoria de post-implantación.
Esta documentación no se improvisa en unas cuantas jornadas de traba-
jo al final del proyecto. La documentación debe ser un continuo a lo largo de
la vida del proyecto y será preciso que un miembro de equipo sea el respon-
sable de recopilar y mantener la documentación que se genera en una «Car-
peta de Proyecto», preferiblemente en forma electrónica.
8.8.4. Realización del Informe Final
El informe final actuará como la historia del proyecto que podrá ser con-
sultada por otros para estudiar los progresos e impedimentos que se han pro-
ducido durante aquel.
El formato del Informe Final del Proyecto podrá tomar diferentes aspectos
pero el contenido deberá tratar de los siguientes puntos:
• Valoración general frente a los factores de éxito establecidos.
• Organización.
• Técnicas utilizadas.
• Puntos débiles y puntos fuertes.
• Recomendaciones del equipo para el futuro.
8.8.5. Realización de auditoria de post-implantación
Esta auditoria es una evaluación de los objetivos del proyecto y de los

logros en las actividades medidos frente al plan de proyecto, presupuesto,
plazos, calidad de los entregables, especificaciones y satisfacción del cliente.
En esta auditoria deberá responder a las siguientes preguntas:

• ¿Se ha alcanzado el objetivo del proyecto?
• ¿Se ha realizado el trabajo a tiempo, dentro del presupuesto y de acuer-
do con las especificaciones?
• ¿Esta satisfecho el cliente con los resultados?
• ¿Se han puesto de manifiesto los valores para el negocio (revisar facto-
res de éxito en el POS)?
• ¿Qué lecciones se han aprendido acerca del método de dirección del
proyecto aplicado?
• ¿Qué ha funcionado bien, que ha funcionado mal?
8.8.6. Celebración del éxito
El fin de un proyecto implica el fin de unas relaciones de equipo que se

han ido formando a lo largo de la vida del proyecto, especialmente si la exten-
sión de este ha abarcado meses o algún año. Los miembros del equipo han
crecido profesionalmente durante este tiempo, se han creado relaciones de
amistad, se han intercambiado consejos y guías. Pero el proyecto se acaba y
hay que deshacer el equipo. Merece una celebración de cierre de proyecto.
Nunca se debe pasar por alto una oportunidad de mostrar al equipo de
trabajo la valoración que se tiene de él. La lealtad, motivación y compromiso
de un equipo de trabajo se ven influidas positivamente mediante estas valo-
raciones.
8.9. RESUMEN
En este capítulo se han presentado las técnicas generales de Dirección de

Proyectos desde le enfoque que realiza el Project Management Institute de
EE. UU.
Se han expuesto estas técnicas con la suficiente generalidad para que
sean aplicables a un proyecto multimedia sin especiales alteraciones o modi-
ficaciones. Se han hecho referencia a técnicas específicas de la tecnología
multimedia cuando éstas se consideran de especial necesidad, remitiendo al
alumno a los capítulos específicos que profundizan en las mismas.
Se ha presentado, como ejemplo, una metodología genérica de Dirección
de Proyectos elaborada por Wysocky (Wysocky, 2000) de forma que el alum-
no pueda asimilar los conceptos en un marco metodológico, más pedagógico
y práctico.

8.1. Entre las siguientes, existe una característica que no es propia del con-
cepto de proyecto, según el PMI:
a) Es un conjunto de actividades complejas.
b) Es un conjunto de actividades conectadas.
c) Es un conjunto de actividades periódicas.
d) Es un conjunto de actividades realizadas de acuerdo a unas especifi-
caciones.
8.2. La técnica conocida como «Estructura de desagregación del trabajo» -

EDT (Work Breakdown Structure – WBS):
a) Permite estimar la duración de las actividades.
b) Permite conocer las tareas a realizar en el proyecto.
c) Define los objetivos del proyecto.
d) Divide las tareas a realizar para permitir un uso más eficaz de los
recursos.
8.3. La técnica Delphi:

a) Es una técnica para estimar el coste de las actividades que usa méto-
dos estadísticos.
b) Es una técnica estadística que precisa de tres estimaciones previas
(pesimista, realista y optimista).
c) Permite realizar simulaciones en lenguaje Delphi.
[d) Es una técnica de grupo que permite extraer el conocimiento del
mismo para proporcionar estimaciones en general.
8.4. El Camino Crítico según la técnica del Diagrama de Precedencias:

a) Es el camino de menor duración para la realización del proyecto de
entre todos los posibles.
b) Es el camino que permite usar la holgura de las tareas para solucio-
nar problemas de sobreasignación de recursos.
c) Permite calcular la duración del proyecto.
d) Es en el que se sitúan las tareas fundamentales del proyecto.
8.5. Los informes de progreso acumulativos o históricos son propios de:

a) Las sesiones de planificación para confeccionar el «Visión de con-
junto del proyecto» con ayuda de datos históricos de otros proyectos.
b) La etapa de monitorización y control.

c) La etapa de implantación de prototipos.
d) La etapa de cierre del proyecto para acumular datos que sirvan para
el futuro.

COLMENAR (2003): Antonio Colmenar, Manuel A. Castro, Julio Perez, Alfonso Vara.
Gestion de proyectos con Microsoft Project 2002. Ed. RA-MA. Madrid, 2003.
DOMINGO (2000): Alberto Domingo Ajenjo. Dirección y Gestión de Proyectos. Un enfo-
que práctico. Ed RA-MA. Madrid, 2000.
MS-PROJECT (2002): Carl Chatfield, Timothy Johnson. Microsoft Project paso a paso.
Versión 2002. Ed. McGraw-Hill. Madrid, 2002.
PMBOK (2000): Project Management Institute. Project Management Book of Know-
ledge, 2000.
PRESSMAN (1995): Roger S. Pressman. Ingeniería del Software. Un enfoque práctico.
Ed McGraw Hill. España. Madrid, 1995.
WYSOCKI (2000): Robert K. Wysocki, Robert Beck, David B. Crane. Effective Project
Management, 2ª Ed. Ed. John Wiley & Sons, USA, 2000.
Capítulo 9
EJEMPLOS DE DESARROLLO
ESQUEMA
9.1. Now-Graduado: ejemplo de análisis y diseño.

9.2. Ejemplo de evaluación de la usabilidad.
9.3. Resumen.
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 pro-
cesos de análisis, diseño y evaluación (Capítulos 5, 6 y 7). Con objeto de ilus-
trar 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 MacroMe-
dia Director, haciendo hincapié en las fases de análisis, diseño e implementa-
ción. Este ejemplo se ha considerado adecuado porque tanto por las caracte-
rí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 implementa-
ció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 ayu-
dar a adultos a adquirir los conocimientos fundamentales del Graduado
Escolar (Aedo y otros, 1997). El Graduado Escolar es una cualificación bási-
ca 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 estu-
dios puedan ahora obtener este título. Puesto que la mayor parte de los adul-
tos tienen dificultades para seguir cursos presenciales, ya sea por cargas labo-
rales o familiares, y, además no suelen tener un hábito de estudio, se
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 hiperme-
dia 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úl-
tiples 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 uti-
lidad 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, mante-
niendo 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 englo-
ban 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 fun-
cionales, 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, inclu-
yendo programadores, analistas o diseñadores gráficos, como representantes
de los usuarios. Así pues, desde el principio se evidenció la necesidad de lle-
var 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 conteni-
dos 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 mis-
mo concepto desde distintas perspectivas, con el fin de enriquecer el apren-
dizaje de las alumnas.
Otro aspecto fundamental era la necesidad de incluir ejercicios interacti-
vos de diverso tipo así como de actividades complementarias, no necesaria-
mente 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 indepen-
diente 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 Gra-
duado Escolar, podía caerse en la utilización de una interfaz infantil, que des-
motivarí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 caracte-
rísticas de la presentación, como por ejemplo la estética o el lenguaje
empleado.
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, locu-
ciones 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 mul-
timedia 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 conside-
rar 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 cen-
tros 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 usabili-
dad de Now-Graduado pueden resumirse en tres metas básicas:
• Debe ser útil. Se pretende que el sistema ayude a sus usuarios a apren-
der 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 funda-
mentales del hipertexto es que la libertad de navegación puede no favo-
recer el aprendizaje en algunos casos, especialmente en aquellos en los
que por las características de los estudiantes o del tema o por condicio-
nantes 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 estu-
diarlo a él. No hay que olvidar que el esfuerzo del usuario debe cen-
trarse 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.
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 Principios de diseño
Debe ser útil • Estructurar el material didáctico.
• Restringir la navegación.
• Fomentar la participación del usuario.
• Considerar las necesidades y preferencias del usuario.
Debe ser fácil • Hacer un uso de creativo de la multimedia.
de usar y aprender • Evitar enlaces y servicios innecesarios.
• Crear una interfaz de usuario homogénea y consistente
• Incluir pistas visuales.
• Considerar el uso de metáforas.
Debe provocar • Incluir actividades interactivas.
una actitud positiva • Aplicar una estética adecuada y atrayente.
del usuario
9.1.8. 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 obje-
tos (Díaz y otros, 2001a).
A modo de ejemplo, la figura 1 recoge la estructura lógica de Now-Gra-
duado 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 sis-
tema se organiza como una jerarquía de nodos, que pueden ser:
• contenedores de información (nodos simples, representados en la figu-
ra por medio de las cajas con borde sencillo), o,
• composiciones de otros nodos (nodos compuestos, representados en la

figura por medio de las cajas con borde doble e icono en forma de jerar-
quía). Existen dos relaciones de composición, de acuerdo con el mode-
lo 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 Pre-
sentació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 com-
plejo 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ódu-
lo), 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 Ejerci-
cios, 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 mis-
ma 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 usua-
rio 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 pri-
mera 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 Ayu-
da y Curso). La selección del destino se hace en tiempo de utilización, com-
probando 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 Glo-
sario 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
FIGURA 9.1. Estructura lógica de Now-Graduado.
parte del estudiante, en cada Página se le proponen también enlaces asociati-

vos a otras páginas sobre temas relacionados (véase el enlace reflexivo Asocia-
ció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 defini-
ción en el Glosario (véase el enlace Mención). Éstos últimos suponen abrir
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 inclu-
ye 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 encontrar-
se 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 pro-
ducto. 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.

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 implemen-
tó 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 correspon-
den 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.

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ña-
dos 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, len-
gua 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 especiali-
zan (figura 9.1). En la parte superior hay una barra que incluye una herra-
mienta 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.

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 usua-
rio 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-Gradua-
do, destinadas a la clasificación de conceptos y a la identificación, respectiva-
mente. 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

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 sec-
ció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 histo-
rias. 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 biblio-
teca de libros, un conjunto de elementos periféricos y los estilos de aprendi-
zaje del usuario.
El eje central son los libros que se encuentran en una biblioteca (o libre-
rí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
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 finali-
zar 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 tradicio-
nal aumentada con ciertas posibilidades del entorno electrónico.
La aplicación se desarrolló con Hypercard y desde el principio se consi-
deró básico realizar una evaluación con expertos cuyos comentarios pudie-
ran 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.
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 estable-
ce un conjunto de tareas que se pueden realizar con el sistema y que permi-
ten conseguir algún objetivo de los que se quieren evaluar. Cada tarea se des-
compone 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.
TABLA 9.2. Actores involucrados en la técnica de evaluación Jogthrough

Actor Responsabilidades
Presentador • Describe la tarea a evaluar.
• Ejecuta las acciones que conlleva esa tarea e identifica caminos alter-
nativos.
Evaluador • Enfoca la descripción del presentador.
• Responde a las cuestiones que se le hacen.
Moderador • Conduce la reunión, manteniendo el foco de atención.
• Resuelve dudas.
• Provoca discusiones y comentarios.
Notario • 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 siste-
ma 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).
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 cues-
tionario 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 pun-
tuació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

9.2.5. Elaboración de los resultados

Una vez finalizada la sesión de evaluación era preciso analizar los resul-
tados para extraer conclusiones sobre la medida en que los objetivos plantea-
dos 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 dis-
tinta 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 rela-
cionadas 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.

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 posi-
tiva 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 pro-

ducto multimedia a través de dos ejemplos. En el primero, Now-Gradua-
do, 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 hinca-
pié 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 produc-
to, describiendo las distintas actividades a realizar a través de la evalua-
ció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 requisi-
tos del producto a desarrollar.
c) Sólo se estudian las características de los usuarios, porque el funcio-
namiento 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 entre-
ga establecido.
b) El diseño conceptual no debe ser independiente de la plataforma de
implementación.
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) Se utilizó Jogthrough porque es una técnica de evaluación analítica.
b) Se utilizó Jogthrough porque es una técnica de evaluación empírica.
c) Se utilizó Jogthrough porque estaba en fase de diseño.
d) 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) Los evaluadores son usuarios reales.
b) Se ejecutan acciones que se descomponen en tareas.
c) Se analizan sólo las características de la interfaz de usuario.
d) 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 Multime-
dia and Hypermedia, 5 (1). Págs. 49-72.
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.
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 10
ARQUITECTURA Y CONFIGURACIÓN
DE LOS SISTEMAS MULTIMEDIA
ESQUEMA
10.1. Arquitectura general de los sistemas multimedia

10.2. Dispositivos y elementos hardware para aplicaciones multimedia.
10.3. Soporte multimedia en los sistemas operativos.
10.4. Bases de datos multimedia.
10.5. Redes con soporte específico para aplicaciones multimedia.
10.6. Diseño arquitectónico para sistemas multimedia.
10.7. Resumen.
El término «arquitectura», en su segunda acepción, según el Diccionario
de la Real Academia Española, hace referencia a la «estructura lógica y física
de los componentes de un computador». Sin embargo, esta definición sólo
tiene en cuenta la disposición de los elementos de un hipotético ordenador
aislado. Hoy en día se habla, en términos más amplios, tanto de «arquitectu-
ra software» como de «arquitectura hardware», y también de «arquitectura de
red». La primera describe la estructura de alto nivel de los programas que
conforman las aplicaciones —incluyendo a los sistemas operativos—, mien-
tras que la segunda describe las características físicas de los ordenadores que
se utilizan para la ejecución de esos programas. La arquitectura de red, que
atañe a las dos anteriores, y en ocasiones se considera como parte de ellas,
describe la configuración de las interconexiones entre las máquinas, que
serán el soporte de las comunicaciones entre los programas que en éstas últi-
mas se ejecutan. Por tanto, en lo tocante a los sistemas multimedia, la arqui-
tectura será la descripción de la disposición o estructura de los componentes
hardware y software interconectados que conforman una aplicación multi-
media determinada.
En este capítulo, se introducirán los elementos arquitectónicos más

importantes desde el punto de vista de las aplicaciones multimedia. Se debe
tener en cuenta que la caracterización de estos sistemas no reside meramen-
te en el soporte de más de un tipo de medio —ya que, desde ese punto de vis-
ta una aplicación con texto e imágenes sería multimedia—, sino en determi-
nadas propiedades relacionadas con la combinación de varios de esos
medios. Más concretamente, y siguiendo la descripción que se propone en
(Steinmetz y Nahrstedt, 1995), estas propiedades serán: la combinación —a
partir de soportes independientes— de medios discretos como las imágenes,
con medios continuos, como el sonido o el vídeo; su integración y sincroni-
zación; y la posibilidad de distribuirse por una red de ordenadores.
Se expondrán primero los aspectos generales de las diferentes partes

que configuran la arquitectura de este tipo de sistemas, para terminar con
algunas nociones básicas sobre cuándo y de qué modo debe integrarse el
«diseño arquitectónico» dentro del ciclo de desarrollo de aplicaciones inte-
ractivas.
10.1. ARQUITECTURA GENERAL DE LOS SISTEMAS

MULTIMEDIA
Un sistema multimedia puede ser tan simple como una breve presenta-
ción que organiza la navegación en la página Web de una empresa, o puede
ser tan complejo como un conjunto de aplicaciones que proporcionan confe-
rencias virtuales, simulaciones y presentaciones interactivas en un entorno
de aprendizaje multimedia. Por ello, cuando se habla de la arquitectura de los
sistemas multimedia, forzosamente se debe hacer referencia a un conjunto
general de elementos, que deberán seleccionarse u obviarse en cada proyecto
multimedia, dependiendo de los requisitos funcionales y no funcionales del
mismo. Estos elementos, en primer lugar, pueden dividirse en dos aspectos
bien diferenciados: la arquitectura hardware y la arquitectura software, que
aparecen diferenciados en la figura 10.1.
APLICACIONES MULTIMEDIA
SOFTWARE ESPECÍFICO PARA LA MULTIMEDIA
SERVIDORES DE SISTEMAS DE GESTIÓN

DISTRIBUCIÓN DE BASES DE DATOS
MULTIMEDIA MULTIMEDIA
SOFTWARE DEL SISTEMA OPERATIVO
SOFTWARE DE GESTIÓN DE
GESTIÓN DE PROCESOS RED PARA LA DISTRIBUCIÓN
MULTIMEDIA
HARDWARE
ARQUITECTURAS DE
DISPOSITIVOS
COMPUTADOR
MULTIMEDIA
MULTIMEDIA
FIGURA 10.1. Arquitectura general de los sistemas multimedia.
La arquitectura hardware incluye los elementos físicos que intervienen en

el funcionamiento de la aplicación multimedia, incluyendo elementos proce-
sadores (ordenadores que ejecutan los programas) y dispositivos de entra-
ARQUITECTURA Y CONFIGURACIÓN DE LOS SISTEMAS MULTIMEDIA 287
da/salida (cámaras, monitores, sistemas de reproducción de audio, sistemas

de almacenamiento masivo, etc.). En algunos casos, la arquitectura física de
los propios computadores proporciona facilidades específicamente pensadas
para la multimedia; un ejemplo muy conocido es el de los procesadores MMX
del fabricante Intel.
En el caso de que la aplicación multimedia sea distribuida, a los procesa-
dores y dispositivos se le añadirán los elementos físicos de la red (conexiones
que habilitan la comunicación entre los programas que se ejecutan en los
procesadores).
Sobre el hardware —especializado para la multimedia o no— se tienen los
servicios del sistema operativo. De entre los diferentes módulos que compo-
nen los sistemas operativos, hay dos partes fundamentales que es importante
tener en cuenta para las aplicaciones multimedia, además, lógicamente, del
soporte para los dispositivos multimedia concretos que sean necesarios. El
primero de estos módulos es el de planificación o gestión de procesos, que en
ocasiones puede permitir un tratamiento especial de los procesos correspon-
dientes a aplicaciones multimedia en ejecución, dotándoles de una prioridad
o reserva de tiempo de procesador adecuada para permitir la correcta ejecu-
ción de los mismos en tiempo real. En segundo lugar, existen sistemas opera-
tivos especializados que ofrecen servicios de transmisión de red especializa-
dos para datos multimedia.
La tercera capa del esquema general incluye a todos los programas espe-
cializados en el almacenamiento y difusión de datos multimedia. Entre ellos,
los sistemas de gestión de bases de datos especializados y los servidores de
difusión de datos multimedia son los más utilizados en las arquitecturas exis-
tentes (estos últimos se describen brevemente en el capítulo 11).
Por último, las aplicaciones multimedia finales se ejecutan con el soporte
del software y hardware que se acaba de describir. Es importante resaltar que
en muchos desarrollos, el soporte hardware y software es convencional, es
decir, no tiene ninguna característica especializada para la multimedia de las
que se han descrito. No obstante, en sistemas con requisitos de tiempo de res-
puesta o sincronización elevados, suele ser necesario el uso de elementos
específicos.
DEFINICIÓN: Arquitectura general de los sistemas multimedia.

• La arquitectura general de los sistemas multimedia comprende los elementos hard-
ware, software y de red especializados que pueden utilizarse en la construcción de
ese tipo de sistemas.
• Esa arquitectura incluye elementos hardware, como procesadores o dispositivos
especializados, protocolos o sistemas de gestión de tráfico de red especializados,
y software específico para estos sistemas, como bases de datos o servidores de dis-
tribución de datos especializados.
En el resto de este capítulo, se describen algunos de los elementos de la

arquitectura general que se muestra en la figura 1, con el objetivo de propor-
cionar una visión general de los elementos que deben tenerse en cuenta al
realizar el diseño arquitectónico de un sistema multimedia.
10.2. DISPOSITIVOS Y ELEMENTOS HARDWARE

PARA APLICACIONES MULTIMEDIA
En la actualidad, existe hardware específico para el procesamiento de datos
multimedia. Este hardware consiste esencialmente en arquitecturas de proce-
sador especializadas, y dispositivos de almacenamiento o de procesamiento de
datos. A continuación se describe una panorámica de ambas categorías.
10.2.1. Arquitecturas de procesador para multimedia

Las aplicaciones multimedia pueden ser soportadas por un amplio rango de
arquitecturas de procesadores, que van desde las arquitecturas de procesadores
dedicados a las arquitecturas de propósito general que han incorporado con-
juntos de instrucciones que permiten dar soporte a estas aplicaciones. Partien-
do de esta base, se puede clasificar las arquitecturas de procesador en lo refe-
rente a soporte multimedia tal y como se muestra en la figura 10.2 (Furth, 1999):
Arquitecturas
de función
específica Arquitecturas
Procesadores
multimedia programables
dedicados flexibles
Arquitecturas
Arquitecturas de programables
procesadores multimedia Arquitecturas
programables
adaptadas
Procesadores
de propósito
general
FIGURA 10.2. Taxonomía de las arquitecturas de procesadores para soporte multimedia.
Los procesadores dedicados están orientados a ejecutar funciones especí-

ficas multimedia tales como la compresión y descompresión de vídeo y audio
o la visualización de aplicaciones gráficas 2D y 3D. La elección de la arqui-
tectura del procesador está condicionada a requisitos tales como la velocidad

y potencia esperada de las funciones, las restricciones en la integración de
circuitos y el coste. Atendiendo a la combinación de estos parámetros se pue-
den seleccionar arquitecturas de función específica o arquitecturas progra-
mables.
Las arquitecturas de función específica, como AV6110 MPEG-2, son las

exclusivamente dedicadas a funciones multimedia. Se fabrican para la codi-
ficación/decodificación de un estándar concreto, por lo que no requieren ser
programables (o lo son minímamente). Esto hace que resulten altamente efi-
cientes y rápidas, pero poco flexibles. Además los costes de producción que
tienen asociados son más bajos que en otro tipo de arquitecturas, dado que se
consigue optimizar el área de silicio en el que construirlas.
Frente a las arquitecturas de función específica, y dentro de las arquitec-

turas dedicadas por completo a dar soporte específico a aplicaciones multi-
media, existen también arquitecturas programables, que permiten manejar
ciertos cambios en los requisitos, como posibles extensiones del dominio de
la aplicación, mediante cambios de software. Estas arquitecturas pueden ser
arquitecturas flexibles, que se pueden programar por completo, como, por
ejemplo, TI-MVP, o bien arquitecturas adaptadas, como VSP3 de NEC, que se
pueden programar en menor medida que las anteriores pero que incorporan
módulos dedicados a algunas tareas pertenecientes a la codificación/decodi-
ficación de vídeo. La diferencia entre estas dos últimas arquitecturas progra-
mables radica de nuevo en el ratio eficiencia/flexibilidad; mientras que las
primeras son muy flexibles, las segundas son más eficientes a costa de perder
parte de esa flexibilidad.
De entre los procesadores de propósito general, algunos proporcionan un

conjunto de instrucciones multimedia dentro de su juego de instrucciones, de
manera que en lugar de ejecutar funciones específicas multimedia propor-
cionan las instrucciones para soportar operaciones genéricas de procesa-
miento de vídeo, como las instrucciones de direccionamiento eficiente de
datos o el soporte de tipos de 8 bits (píxels), sin perder la compatibilidad con
el procesamiento de datos de otro tipo de aplicaciones. Un ejemplo muy
conocido de este tipo de procesadores son los MMX, como el Pentium MMX
de Intel. En los procesadores MMX (siglas que provienen del inglés MultiMe-
dia eXtensions, extensiones multimedia) se han añadido 57 nuevas instruc-
ciones a las 200 disponibles en el Pentium que están optimizadas para reali-
zar las operaciones más frecuentes utilizadas en programas multimedia
como reproducción de vídeo digital o gráficos en tres dimensiones, e incluye
8 instrucciones de 64 bits. El procesador utiliza la técnica de instrucción úni-
ca de datos múltiples (SIMD, Single Instruction Multiple Data), que permite
que el procesador acelere muchas tareas multimedia que necesitan usar cál-
culos intensivos gracias a la posibilidad de operar en paralelo diferentes
datos empaquetados.
DEFINICIÓN: Arquitectura de procesador para multimedia.

• Existen arquitecturas de microprocesador que tienen en cuenta de manera explíci-
ta el soporte de aplicaciones multimedia. Entre ellas se tienen procesadores multi-
media dedicados, y arquitecturas de propósito general que proporcionan opera-
ciones optimizadas para determinadas funciones habituales en las aplicaciones
multimedia.
10.2.2. Dispositivos de almacenamiento y proceso multimedia
El cualquier sistema informático la forma en la que se almacenan y recu-

peran los datos juega un papel clave dada la importancia de tener tiempos de
respuesta aceptables a las peticiones de información que las aplicaciones
puedan hacer a disco. Estas necesidades son todavía más acuciantes en siste-
mas multimedia, donde dicha recuperación debe ser lo más rápida posible
para que el usuario no perciba interrupciones o saltos en el proceso de los
datos. Todo esto, unido a las características singulares de los datos multime-
dia, como su tamaño, su composición formada por varias corrientes de datos
(audio, imágenes en movimiento, etc), la necesidad de recuperación síncrona de
los datos de las corrientes, etc., ha hecho necesario no solo el estudio de nuevos
tipos de dispositivos de almacenamiento sino también el estudio de cómo orga-
nizar los discos y ubicar los datos en ellos.
Frente a las organizaciones de disco que se venían utilizando en discos
convencionales, como la grabación con densidad variable (VDR, Variable
Density Recording), existen otras que permiten obtener mayor eficiencia en el
almacenamiento y recuperación de datos multimedia, como la grabación con
densidad constante (CDR, Constant Density Recording). En este formato de
disco las pistas se agrupan en zonas concéntricas en las que la densidad de
grabación está optimizada por zona y es aproximadamente igual. En este tipo
de formato, el tiempo de transferencia de datos, es decir, el tiempo requerido
para leer los datos requeridos en la pista actual, es menor en las zonas más
alejadas del centro que en las más internas. Esto es debido a que las llamadas
zonas externas (las más alejadas del centro) tienen mayor diámetro y por lo
tanto contienen más bits y sectores; puesto que el disco rota a una velocidad
angular constante, las cabezas de lectura y escritura recorren más bits en el
mismo tiempo que si estuvieran procediendo a la lectura en la zona interna.
Esta forma de organizar los discos es actualmente utilizada en disco IDE y
SCSI, y consiste, resumiendo, en formar desde el centro del disco hacia afue-
ra varias zonas de cilindros, cada una con más sectores por pista que la mas
interna anterior, frente a organizaciones donde todas las pistas contienen el
mismo número de sectores fijo.
Cómo el controlador de disco ubique los datos en él una vez organizado
es también algo muy importante en las prestaciones de los sistemas multi-
media. Piensese que incluso en un disco de organización eficiente, si dos

objetos de datos que se solicitan siempre uno a continuación de otro, por
ejemplo, una imagen y su sonido, se graban en zonas de disco muy alejadas
tardarán más en recuperarse si se tiene en cuenta el tiempo de posiciona-
miento y la latencia de rotación, que si están situados en posiciones físicas
contiguas. Existen muchas técnicas para realizar esta ubicación en disco y
cada una de ellas afecta de una manera u otra las prestaciones del disco. A
continuación se enumerarán algunas de las más significativas para situar los
datos multimedia en un solo disco:
• Ubicación contigua intercalada (interleaved). A la hora de ubicar los
datos multimedia en disco hay dos posibilidades básicas. La primera es
colocar los bloques de los diferentes flujos de medios de manera aleato-
ria, lo que no resulta viable dado que no se garantizan los límites desea-
bles en tiempo de posicionamiento y latencia para acceder a una
secuencia de vídeo o audio continua, o bien colocar los bloques de
manera contigua para garantizar este acceso continuo, lo que también
tiene problemas inherentes de fragmentación así como grandes gastos
de copia en la inserción y borrado. La técnica de ubicación contigua
intercalada (Rangan y Vin 1993) permite alcanzar una solución óptima
al respecto. Se utiliza sobre todo para mezclar de manera óptima flujos
que se deben recuperar juntos. En primer lugar los datos de cada flujo
se dividen en bloques de acuerdo a la longitud del bloque de disco y
agrupar contiguamente bloques de diferentes flujos, a los que se deno-
mina bloques de medios. Los bloques de medios se graban uno tras otro
dejando entre dos bloques un hueco suficientemente grande como para
poder almacenar otro bloque de medios de otros flujos pero cuyo tama-
ño también garantice las restricciones de acceso al siguiente bloque a
recuperar en tiempo real, es decir, que el tiempo que se tarde en acceder
al siguiente bloque de medios sea menor que el tiempo que debe trans-
currir hasta que el usuario visualice dicho bloque sin retardos. La figu-
ra 10.3 muestra como quedarían los bloques de medios en el soporte:
G G N N N
M’1 M’’ M’2 M’’2 M’3 M’’ M’4 M’’ M’5 M’’ M’6 M’’
M1 M2 M3 M4 M5 M6
FIGURA 10.3. Ubicación contigua intercalada.
En esta figura se observan bloques de medios Mi formados por datos de

los flujos M’ y M’’ se intercalan dejando huecos Gi entre ellos, o bien
aprovechando esos huecos para almacenar Ni bloques de otra secuen-
cia de otro flujo N.
• Ubicación basada en frecuencia. Esta técnica (Chen y Thapar, 1996)

se utiliza sobre discos organizados mediante grabación de densidad
constante, donde existen diferencias en las velocidades de transferen-
cia de datos entre las zonas externas e internas del disco. Aprovechan-
do estas características, se pueden situar físicamente los datos que más
frecuentemente se acceden en las zonas más exteriores del disco, pues-
to que su velocidad de transferencia es más alta, dejando las zonas
internas para datos que no se acceden con tanta frecuencia, tal y como
se muestra en la figura 10.4.
... V’n
V’’m V’1
…... V’’1
V’2
…... V’’2
V’3
…...
...
...
FIGURA 10.4. Ubicación basada en frecuencia.
Suponiendo que los datos de la secuencia V’ son aquellos que más a

menudo se acceden ,en la figura 4 se puede observar cómo dicho flujo
V’i se sitúa en la zona externa de un disco CDR, ubicándose el resto de
los datos en zonas consecutivas hacia el interior del disco según su fre-
cuencia de acceso los datos del flujo V’’ serán los siguientes más acce-
didos y así sucesivamente.
• Ubicación balanceada de carga. Con este método de ubicación se
pretenden optimizar las prestaciones de discos con grabación con den-
sidad constante atendiendo al ancho de banda y tamaño de los objetos
multimedia. Puesto que en discos CDR el tiempo de posicionamiento
es menor y la velocidad de transferencia mayor en las zonas externas,
si los objetos con un ancho de banda grande se graban en ellas las peti-
ciones de acceso a estos objetos se responderán más rápidamente, evi-
tando que se encolen muchas peticiones a disco y mejorando por lo
tanto las prestaciones del sistema.
Si bien se han expuesto técnicas de ubicación de los datos multimedia en
un único disco con objeto de optimizar las prestaciones del mismo, hay que
tener en cuenta que existen otras para organizar los datos en múltiples discos
e incluso en sistemas de almacenamiento jerárquico (Leung y Tse, 1999),
aunque la correcta elección de una ubicación de los datos intra-disco es fun-
damental para el éxito de las demás organizaciones.
10.3. SOPORTE MULTIMEDIA EN LOS SISTEMAS OPERATIVOS
Los sistemas operativos tienen como misión principal la gestión eficiente

del hardware, proporcionando a las aplicaciones unas interfaces de más alto
nivel. Las aplicaciones multimedia demandan la integración de datos prove-
nientes de diferentes dispositivos en tiempo real para sus usuarios. Esta nece-
sidad de procesamiento de datos continuos en tiempo real afecta fundamen-
talmente a la gestión de procesos del sistema operativo, que debe extenderse
con el concepto de reserva de recursos previa a la ejecución.
Como se ha expuesto, los sistemas multimedia tienen ciertos requisitos
típicos de un sistema en tiempo real en cuanto a la integración y procesa-
miento de datos, si bien hay que considerar que dichos requisitos son menos
estrictos que en los sistemas en tiempo real típicos con tiempos límite (dead-
line) estrictos y cuyo vencimiento tendría consecuencias catastróficas. Con-
cretamente, los sistemas multimedia tienen requisitos de tiempo real distin-
tos de los sistemas típicos (Steinmezt y Nahrstedt, 1995):
• La tolerancia a fallos suele ser menos estricta que en aquellos sistemas
en tiempo real que tienen impacto físico directo, aunque existan deter-
minadas aplicaciones, como las operaciones quirúrgicas donde el cum-
plimiento de los requisitos de recuperación del sistema han de ser muy
rigurosos.
• El cumplimiento de los tiempos límites no suele ser tan crucial, aunque
por supuesto debe ser evitado, sobre todo en lo que al audio respecta.
Este tipo de tiempos límites se conoce en sistemas de tiempo real como
tiempos límites suaves (soft deadlines), que se diferencian de los tiem-
pos estrictos (hard deadlines) en que o bien no pueden ser perfecta-
mente determinados o bien su incumplimiento no produce resultados
catastróficos.
• Las tareas críticas que se deben planificar en los sistemas multimedia
son periódicas, puesto que responden al procesamiento de una secuen-
cia de datos digital continua, y este tipo de planificación es más senci-

lla que la de tareas esporádicas, cruciales en sistemas de tiempo real de
otra naturaleza.
• El ancho de banda demandado por el flujo de medios no es siempre el
mismo, y por lo tanto puede someterse a cierta negociación, ajustándo-
se dinámicamente.
En vista de todo esto, se puede considerar que a la hora de tratar datos
multimedia los dos cuellos de botella principales en cuanto a gestión de
recursos del sistema, se refiere, son el disco y el procesador (CPU). Los siste-
mas operativos deben hacer frente por los tanto a la planificación de ambos
de una manera especial, ya que, aunque un sistema multimedia disponga de
dispositivos de almacenamiento conveniente organizados y sobre los que se
realiza una buena ubicación de los datos, si el subsistema del sistema opera-
tivo que se encarga de planificar la CPU no realiza una buena gestión las peti-
ciones pueden sufrir retrasos que interrumpan el procesamiento y planifica-
ción de otros recursos del sistema. En lo que resta de apartado se veran las
políticas de los sistemas multimedia para planificar las tareas de CPU.
Los sistemas operativos más habituales que pueden procesar datos multi-
media, por ejemplo Unix SVR4, utilizan algoritmos de planificación de la
CPU basados en colas multinivel donde los procesos son servidos con políti-
cas round-robin. En ellas los procesos pueden cambiar de nivel y de prioridad
de manera dinámica, por ejemplo si tienen una actividad intensa de entra-
da/salida o si, por ejemplo, se quedan «dormidos» por más de un segundo.
Esta política hace que en principio las aplicaciones típicas multimedia pue-
dan mantener su prioridad, pero otros procesos de menor prioridad acabarán
eventualmente llegando a los niveles de prioridad superiores de manera que
la presencia de una prioridad para un proceso multimedia no garantiza un
tiempo mínimo de ejecución por unidad de tiempo que asegure la calidad de
la reproducción.
Uno de los algoritmos de planificación de CPU más utilizados para siste-
mas multimedia (y por extensión en los sistemas de tiempo real) es el algo-
ritmo rate monotonic (Liu y Layland, 1973). La planificación tiene unos pre-
rrequisitos muy claramente definidos, que dadas las características de los
datos multimedia, hacen que el algoritmo sea especialmente adecuado para
el procesamiento de este tipos de información. Dichos prerrequisitos consis-
ten básicamente en que:
1. Todas las peticiones que soliciten las tareas y que tengan tiempo lími-
te deben producirse a intervalos regulares (periódicamente). Solamen-
te pueden ser aperiódicas las peticiones sin tiempo límite.
2. Los tiempos límites sólo deben implicar restricciones en cuanto a que
una tarea debe ser acabada antes de que la siguiente petición tenga
lugar.
3. Las tareas son independientes.

4. El tiempo de ejecución de cada proceso es constante.
Rate monotonic realiza una asignación de prioridades estática (lo que vie-
ne a evitar algunos problemas de otras políticas de planificación ya expues-
tas) en función del periodo de la tarea: a periodo de petición más corto —o lo
que es lo mismo: mayor frecuencia de peticiones— mayor prioridad. El com-
portamiento básico de dicho algoritmo puede observarse en la figura 10.5. En
dicha figura se observan dos procesos con distinta frecuencia de peticiones a
CPU. Puesto que el proceso 1 es más frecuente, se le asigna mayor prioridad.
Otro aspecto que merece la pena destacar es el tiempo límite de cada tarea,
que tal y como se especificó en el segundo prerrequisito del algoritmo, la
tarea debe finalizar antes de que se produzca otra petición del mismo proce-
so (obsérvese que los tiempos límites del proceso 2 son más amplios que los
del proceso 1 puesto que su periodo es también mayor). La CPU se asigna por
prioridad de la tarea, por lo que puede ser expropiada cuando llega una peti-
ción de mayor prioridad, algo que ocurre, por ejemplo, mientras se ejecuta la
tarea A y llega la tarea 2.
TL_2 TL_4
TL_1 TL_A TL_3 TL_B Tiempos límite
Proceso 1 1 2 3 4 5
Proceso 2 A B C
CPU 1 A 2 3 B 4 5 C ....
t
FIGURA 10.5. Funcionamiento básico del algoritmo rate monotonic.
Existe una generalización del algoritmo de planificación rate monotonic

conocida como deadline monotonic (Leung y Whitehead, 1982) que es válido
para procesos cuyos tiempos límites no son iguales al periodo de la petición.
En este caso, las prioridades son asignadas de acuerdo a dichos tiempos
límites.
Los algoritmos previamente comentados son aplicables para sistemas en

tiempo real estrictos, pero ¿cómo realizan la planificación de la CPU los sis-
temas multiservicio? Un ejemplo de cómo realizar la política de asignación
de CPU en este tipo de sistema es la que sigue el sistema operativo QLinux
Multimedia (Sundaram et al, 2000). La planificación de QLinux parte de las
desventajas de otro tipo de planificadores. Se ha visto que en algunos de ellos,
como Unix SVR4 pueden llegar a darse problemas que no permitan garanti-
zar en cualquier caso el correcto procesamiento de aplicaciones o datos mul-
timedia. Existen soluciones a este hecho, como la creación de clases de pro-
cesos donde se asignan prioridades fijas (Schulzrinne, 1999). Esto tiene a su
vez como inconveniente que algunas tareas de prioridad más bajas que las
que se tienen que ejecutar en tiempo real pueden morir de inanición. QLinux
sigue mecanismos basados en velocidad, por los que no se establece priori-
dad alguna a las tareas, sino que se asigna CPU (recursos en general) a la
tarea en función de su peso, es decir, del tiempo de CPU que necesita, bien sea
de manera relativa respecto al tiempo que necesitan el resto de tareas o de
manera absoluta, permitiendo el reajuste dinámico de los recursos.
10.4. BASES DE DATOS MULTIMEDIA

Los sistemas de gestión de bases de datos (SGBD) son programas especia-
lizados en proporcionar servicios de almacenamiento persistente y consulta
de información, soportando grandes volúmenes de datos. De esta manera, las
aplicaciones «delegan» los servicios de almacenamiento y consulta en los
SGBD, que proporcionan estructuras para hacer más uniforme y eficiente el
acceso a los datos. En las aplicaciones multimedia, los datos son de naturale-
za muy heterogénea, lo cual requiere de un tratamiento especializado. Esta
especialización es lo que ha dado lugar a los sistemas de gestión de bases de
datos multimedia (SGBDM), que, además de los servicios habituales de un
SGBD, deben cumplir con una serie de requisitos específicos:
• Almacenamiento de diferentes tipos de información en formatos
diversos. Cada tipo de información (audio, vídeo) posee unas caracte-
rísticas especiales, que requieren de una política de almacenamiento
distinta, con diferentes formatos de almacenamiento posibles. Además,
en ocasiones los datos están distribuidos en diferentes dispositivos de
almacenamiento secundario, por ejemplo, en CDROMs y en discos
magnéticos, y es el gestor el que se encarga de proporcionar un acceso
uniforme.
• Soporte de modelos de datos específicos. Los diferentes tipos de
datos deben especificarse mediante modelos de datos que sean lo sufi-
cientemente ricos como para expresar sus características especiales.
Por ejemplo, la dimensión temporal en el caso del vídeo no está direc-
tamente soportada en los modelos de datos actuales, como el modelo
relacional. El modelo de la orientación a objetos proporciona un sopor-

te adecuado, si se utiliza como marco para crear un modelo de datos
multimedia específico (Atarais y Hamakaw, 1999).
• Métodos de búsqueda específicos. La búsqueda de imágenes, soni-
dos u otros tipos multimedia está relacionada con el «contenido» de las
mismas (Heller y Martin, 1999), de modo que se deben proporcionar
métodos de búsqueda —y de indexación para la búsqueda— acordes
con las mismas, además de los métodos de consulta convencionales.
• Independencia del formato. Las interfaces de búsqueda deben ser
capaces de buscar en un medio determinado como el sonido, indepen-
dientemente de la técnica de codificación del mismo que se esté utili-
zando para sonidos determinados. Además, las interfaces de progra-
mación deben ser independientes del tipo multimedia, aunque si el
programador lo considera oportuno para una situación concreta,
deben permitir acceder a los detalles concretos de un formato.
• Transferencia de datos en tiempo real. Los tipos multimedia conti-
nuos como el vídeo requieren de operaciones de almacenamiento y
recuperación especialmente largas, cosa que debe tener en cuenta el
gestor.
• Acceso simultáneo a datos multimedia. Diferentes aplicaciones pue-
den acceder a los mismos datos multimedia en el mismo instante de
tiempo. Las posibles colisiones en el uso de la información deben ser
controladas por el gestor.
• Consistencia en los datos. La consistencia en los datos multimedia
tiene aspectos específicos que deben tenerse en cuenta. Entre ellos cabe
citar, siguiendo la terminología descrita en (Steinmetz y Nahrstedt,
1995) los siguientes:
— Las relaciones de atributo proporcionan diferentes descripciones o
presentaciones del mismo elemento. Por ejemplo, si se tiene en la
base de datos una información sobre la entidad «pájaro», atributos
de diferentes tipos multimedia pueden utilizarse como descriptores
de las diferentes razas de gatos. Por ejemplo, un atributo puede ser
el sonido de sus cantos, y otro el estilo de su vuelo, almacenado
como vídeo.
— Las relaciones de composición permiten estructurar datos multi-
media. Por ejemplo, un dato denominado «tema» puede estar cons-
tituido por diferentes partes o «secciones», y éstas tener «ejercicios»
que pueden contener presentaciones en vídeo sincronizadas con el
texto.
— Las relaciones de substitución proporcionan diferentes representacio-
nes equivalentes de una misma información. Por ejemplo, un resulta-
do estadístico puede proporcionarse como tabla de datos, como gráfi-

ca e incluso como gráfica animada mostrando diferentes aspectos.
— Las relaciones de sincronización describen relaciones temporales
entre diferentes datos multimedia. Un ejemplo típico es la sincroni-
zación de audio y vídeo en una presentación.
DEFINICIÓN: Bases de datos multimedia.

• Las bases de datos multimedia están especializadas en el tratamiento de grandes
volúmenes de datos de tipos con características distintas. Proporcionan mecanis-
mos para la descripción de los datos multimedia, así como para el establecimien-
to de relaciones entre elementos de diferentes tipos.
Además de esas características, los SGBDM deben estar especialmente

preparados para el almacenamiento de grandes volúmenes de datos, ya que
la información multimedia en muchos casos ocupa más espacio de almace-
namiento. Es importante resaltar que muchos de los SGBD relacionales
comerciales más difundidos actualmente como Oracle o SQL Server no pro-
porcionan servicios para cumplir con los requisitos que se acaban de descri-
bir. Aunque en ellos se pueden guardar datos multimedia, lo que realmente se
hace es guardarlos como objetos binarios grandes (binary large object,
BLOB), como simples «flujos de bytes» sin un tipo específico. Todas las carac-
terísticas mencionadas han dado lugar a la consideración de una arquitectu-
ra específica para los SGDBM. En la figura 10.6 se describe una arquitectura
de referencia, adaptada de la propuesta por Ghafoor (Ghafoor, 1995).
Interfaz de usuario
Herramientas Interfaz de Edición Herramientas de

de navegación Consultas multimedia administración
Capa de integración multimedia
Composición multimedia Procesamiento de consultas
SGBD Texto SGBD Imágenes SGBD Audio SGBD Video
Texto Imágenes Audio Video
FIGURA 10.6. Arquitectura de referencia de un sistema de gestión de bases de datos multimedia.

En esta arquitectura se puede ver cómo el almacenamiento de cada tipo

de datos tiene su propio sistema de almacenamiento y recuperación, integra-
dos mediante un lenguaje de consultas común a todos ellos, y una interfaz
que permite expresar las relaciones entre diversos tipos que son inherentes a
la multimedia. Además, estos gestores cuentan con herramientas de edición,
administración y consulta adaptadas a las características especiales de las
combinaciones de tipos de datos.
10.5. REDES CON SOPORTE ESPECÍFICO

PARA APLICACIONES MULTIMEDIA
El concepto de reserva de recursos que aparece en los sistemas operativos

preparados para la multimedia es trasladable a la reserva de capacidad de la
red cuando se enfrenta a aplicaciones multimedia distribuidas.
Dadas las características de los datos multimedia ya definidas, hay que
tener en cuenta que los sistemas multimedia en red tienen los siguientes
requisitos para con los protocolos y servicios de transmisión (Steinmetz y
Nahrstedt, 1995) derivados de sus características inherentes:
1. Las peticiones de datos son sensibles en el tiempo, y, como ya se ha
dicho, están acotadas por tiempos límite. Esto implica, por ejemplo,
que los retrasos en la transmisión entre fuente y destino estén acota-
dos en el tiempo, así como que la variación de los mismos sea baja.
2. Alto tráfico de salida, puesto que el vídeo y el audio se transmiten
como flujos que suelen ser de larga duración y suelen tener grandes
variaciones de volumen respecto al tiempo.
3. Se necesitan garantías de servicio, es decir, que los servicios de proce-
samiento y comunicación deben estar garantizados durante todo el
tiempo que dure la comunicación, lo que en ocasiones se ve dificulta-
do dadas las diferentes formas de tráfico de red producidas por apli-
caciones multimedia heterogéneas.
4. Se necesita no solo cierta fiabilidad en la transmisión, sino que esta se
proporcione bajo restricciones temporales, con objeto de que las apli-
caciones multimedia puedan ofrecer una buena calidad de servicio.
Puesto que estos requisitos son muy heterogéneos e incluso dependen del
tipo de aplicación multimedia que los solicite se han llegado a parametrizar.
Esta parametrización permite varias cosas. Por un lado se pueden flexibilizar
y personalizar los servicios , y por otro se puede controlar la calidad del ser-
vicio ofrecido por la red. El organismo internacional de organización de
estándares (ISO) a estandarizado estos parámetros a través de la noción de
calidad de servicio (QoS —quality of service— en inglés) (Nahrstedt, 1999).
DEFINICIÓN: Calidad de servicio (QOS).

• Según ISO, la calidad de servicio es el concepto que especifica cuán buenos son
los servicios de red ofrecidos a una aplicación, multimedia en nuestro caso.
• La calidad de servicio se mide de acuerdo a lo que la aplicación necesita de los
servicios de red, que viene especificado mediante parámetros concretos estandari-
zados cuyo valor se puede negociar entre ambas partes.
Obviamente, no todas las redes están preparadas para soportar transmi-

siones multimedia con las garantías necesarias. Diseñar redes sobre las que
realizar estas transmisiones ha supuesto un gran reto en los últimos años, del
que han surgido distintas aproximaciones (Sharda, 1999) como las redes
ATM. Pero en la red Internet, los esfuerzos hoy en día se centran en el proto-
colo de presentación RTSP (Real Time Stream Protocol). El protocolo HTTP
no se puede considerar apropiado para presentar flujos multimedia puesto
que está enteramente basado en TCP, que, entre otros inconvenientes, fuerza
la fiabilidad pero sin tener en cuanta restricciones temporales y además no
resulta apropiado para realizar multidifusión (multicasting). RSTP surge
como protocolo para paliar estas deficiencias.
RSTP (Schulzrinne, 2003) es un protocolo de control para presentación
multimedia cliente-servidor diseñado para soportar el envío eficiente de flu-
jos multimedia sobre redes IP, por lo que permite aprovechar la infraestruc-
tura actual de la Web. RTSP utiliza a su vez un protocolo de transporte dis-
tinto de TCP, conocido como RTP (Realtime Transport Protocol) (Schulzrinne,
1996), que proporciona el formato de paquete para flujos de datos multime-
dia y otro tipo de datos que tengan que ser transmitidos en tiempo real.
El protocolo RTSP, frente a HTTP, está diseñado para trabajar con flujos
de datos con restricciones temporales. Además, dispone de mecanismos para
el posicionamiento sobre el contenido de ficheros multimedia bajo restric-
ciones temporales —lo que se conoce como time-based seeking— y permite
controlar el envío en multidifusión de flujos, sin perder la posibilidad de
mantener soluciones híbridas multidifusión-unidifusión. Estas característi-
cas hacen que actualmente se esté utilizando para transmisiones por Internet
de vídeo bajo demanda donde no es necesario descargar todo el fichero para
poder visualizarlo, sino que mediante una aplicación de cliente se puede rea-
lizar el típico control de vídeo (pausa, rebobinar, avanzar y posicionamiento
absoluto) sobre datos multimedia almacenados en servidores.
10.6. DISEÑO ARQUITECTÓNICO PARA SISTEMAS MULTIMEDIA
El diseño arquitectónico es una actividad de Ingeniería del Software

cuyo propósito es obtener una descripción de alto nivel de los elementos
hardware y software del sistema proyectado, así como de las relaciones entre
los mismos. Esta descripción o arquitectura establece las líneas maestras del
futuro sistema, y permite la construcción de «prototipos arquitectónicos»
para probar tempranamente el sistema como concepto. Los elementos bási-
cos que deben describirse en una arquitectura son de dos tipos: hardware y
software. Los primeros incluyen la configuración de los procesadores (orde-
nadores personales, servidores, dispositivos en general) y su interconexión
(arquitectura de red). Los segundos incluyen las aplicaciones que conforma-
rán el sistema (que pueden ser más de una, como en el caso de los sistemas
cliente-servidor), los componentes y/o software comercial que se utilizarán
(incluyendo los sistemas de almacenamiento de datos), y los modelos de
procesos e hilos requeridos para obtener un rendimiento y escalabilidad
apropiados.
Como se describe en (Hofmeister, Nord y Soni, 2000), el diseño de la
arquitectura software está íntimamente relacionado con otras actividades del
ciclo de Ingeniería. La figura 10.7 muestra estas relaciones.
Requisitos, cualidades deseadas Restricciones
ANÁLISIS DE
REQUISITOS Y DISEÑO DE LA
MODELADO DEL DISEÑO DE LA
ARQUITECTURA SOFTWARE ARQUITECTURA
DOMINIO HARDWARE
Arquitectura Software
Restricciones de implementación
DISEÑO DETALLADO,
CODIFICACIÓN, INTEGRACIÓN y
PRUEBA
FIGURA 10.7. Relación del diseño arquitectónico con otras actividades del desarrollo.
Así, el análisis de requisitos y el modelo del dominio de la aplicación

determinarán los bloques constitutivos básicos de la arquitectura software
necesaria. Por ejemplo, en sistemas colaborativos se deberá determinar la
existencia de aplicaciones que actúen como clientes y, opcionalmente, la exis-
tencia de servidores donde se centralicen y auditen las interacciones de los
usuarios.
Por otro lado, la arquitectura software determinará el hardware seleccio-

nado, de modo que si se plantea una arquitectura distribuida, será necesario
disponer del soporte de red necesario, y también se requerirá un dimensio-
namiento de la capacidad de proceso de cada uno de los nodos hardware que
conformen la aplicación. Actualmente, el diseño arquitectónico suele ir
acompañado de la implementación de un prototipo arquitectónico, que no es
otra cosa que una aplicación en la cual se ejercitan todos los elementos dis-
puestos en la arquitectura, pero cubriendo sólo alguna funcionalidad simple
de las requeridas. Este prototipo permite llegar a un buen nivel de detalle en
el diseño de la arquitectura hardware, y sirve también para probar la eficacia
de las posibles herramientas de autoría u otros módulos software (bases de
datos, servidores de streamming) antes de comprometer los recursos de desa-
rrollo con una tecnología concreta. En el caso de que nuestra aplicación
requiera la distribución masiva de multimedia a través de una red de ordena-
dores, es fundamental realizar un test de carga para probar la capacidad de
los servidores de distribución y también las condiciones de tráfico de red
necesarias para llegar a una calidad de visualización óptima.
Además, cuando a partir de la arquitectura software se comienzan las
actividades de diseño detallado y codificación —una vez seleccionadas las
herramientas de construcción necesarias— podrán aparecer nuevos requisi-
tos de índole no funcional que no estaban previstos inicialmente, y que
supondrán modificaciones a la arquitectura original de manera iterativa.
DEFINICIÓN: Diseño arquitectónico de sistemas multimedia.

El diseño arquitectónico es una actividad de Ingeniería del Software posterior al aná-
lisis de requisitos y previa a la implementación del sistema, cuyo objetivo es determi-
nar la estructura de alto nivel del software, así como la configuración del hardware y
de los elementos de red necesarios para la aplicación dada. En muchas ocasiones, el
desarrollo de un prototipo arquitectónico es el mejor medio para la determinación de
esos aspectos generales de la aplicación.
10.7. RESUMEN
La arquitectura de un sistema multimedia es la disposición de los ele-

mentos hardware y software —así como la distribución en red de los mis-
mos— para conseguir la funcionalidad y la calidad de ejecución requeridas
para la aplicación concreta.
Entre los elementos hardware, se dispone de procesadores específicos o
con instrucciones optimizadas para la multimedia, así como dispositivos de
muy diversa índole especialmente preparados para este tipo de aplicaciones.
Entre los elementos software, los propios sistemas operativos tienen
variantes de sus algoritmos de planificación que permiten dar un mejor ren-
dimiento para cargas de proceso típicas de la multimedia, y existen protoco-

los de red especializados para la distribución eficiente de la multimedia.
También el almacenamiento y recuperación de datos, que en el caso de la
multimedia tiene requisitos muy altos, cuenta con arquitecturas de base de
datos especializadas para dar un mejor soporte a los diversos tipos de datos
que se combinan en la multimedia.
La selección de los elementos arquitectónicos descritos depende de los
requisitos funcionales y no funcionales de la aplicación multimedia que se
esté considerando construir. Por ello, la actividad de diseño arquitectónico
toma una especial relevancia en este tipo de aplicaciones, dada la gran
variedad de elementos software y hardware específicos disponibles para
ellas.

10.1. ¿Qué afirmación es correcta en lo referente a arquitecturas genéricas
de aplicaciones multimedia?:
a) La parte de servicios de transmisión de datos multimedia por red
forma parte de la capa hardware.
b) La capa software se divide en tres capas a su vez: sistema operativo,
software específico de soporte y la aplicación en sí.
c) La capa hardware de la arquitectura de una aplicación multimedia
debe incluir un elemento que sea un procesador con soporte especí-
fico multimedia.
d) Una aplicación multimedia se puede ejecutar sobre una arquitectu-
ra convencional (sin ninguna característica especializada para la
multimedia).
10.2. ¿Qué caracteriza a los procesadores de propósito general frente a los

procesadores multimedia dedicados?
a) Su flexibilidad.
b) Su eficiencia.
c) Que no se pueden programar.
d) Ningún procesador de propósito general puede ser utilizado para
ejecutar aplicaciones multimedia.
10.3. ¿Qué técnica de ubicación de datos multimedia en disco optimiza la

recuperación de flujos que deben procesarse juntos?
a) La grabación con densidad constante.
b) La ubicación balanceada de carga.
c) La ubicación basada en frecuencia.

d) La ubicación contigua intercalada.
10.4. ¿Cuál de los siguientes requisitos derivados de las características inheren-

tes de las aplicaciones y datos multimedia tienen que tenerse en cuenta en
sistemas multimedia en red para poder transmitir este tipo de datos?
a) El tráfico de salida no es significativo.
b) El tráfico de red es homogéneo.
c) Los retrasos en la transmisión entre fuente y destino tienen que
estar acotados en el tiempo.
d) Ninguna de las opciones anteriores es verdadera.
10.5. ¿Qué ventajas aporta en protocolo RSTP para la distribución de datos

multimedia?
a) El procolo RSTP permite el envío fiable de datos.
b) El protocolo RSTP permite realizar transmisiones bajo restriccio-
nes temporales.
c) El protocolo RSTP soporta tanto unidifusión como multidifusión.
d) Todas las opciones anteriores son verdaderas.

ATARAIS y HAMAKAW (1999): A. Atarashi. y R. Hamakaw: Multimedia Objects. Handbo-
ok of Multimedia Computing (ed: B. Fuhrt), CRC.
CHEN y THAPAR (1996): S. Chen y M. Thapar: Zone-Bit-Recording-Enhanced Vídeo
Data Layout Strategies. Proc. of Modeling, Analysis And Simulation of Computer
and Telecommunication Systems MASCOTS.
FURTH (1999) B. Furth: Processor Architectures for Multimedia. Handbook of Multi-
media Computing (ed: B. Fuhrt), CRC.
GHAFOOR (1995): A. Ghafoor: Multimedia Database Management Systems. ACM Com-
puting Surveys 27(4).
HELLER y MARTIN (1999): R.S. Heller y C.D. Martin: Multimedia Taxonomy for Design
and Evaluation. Handbook of Multimedia Computing (Ed: B. Fuhrt), CRC.
HOFMEISTER, NORD y SONI (2000): C. Hofmeister, R. Nord y D. Soni: Applied software
architecture. Addison Wesley.
LEUNG y TSE (1999): C.H.C. Leung y P.K.C. Tse: Storage Organizations for Multimedia
Data. Handbook of Multimedia Computing (Ed: B. Fuhrt), CRC.
LEUNG y WHITEHEAD (1982): J.Y.T. Leung y J. Whitehead: On the Coplexity of Fixed-
Priority Scheduling of Periodic, Real-Time Tasks. Perfomance Evaluation, 2.
LIU y LAYLAND (1973): C.L. Liu y J.W. Layland: Scheduling Algorithms For Multipro-
gramming in a Hard Real Time Environment. Journal of the ACM, 20.
NAHRSTEDT (1999): K. Nahrstedt: Quality of Service in Networked Multimedia Sys-
tems. Handbook of Multimedia Computing (Ed: B. Fuhrt), CRC.
RAGAN y VIN (1993): P.V. Rangan y H.M. Vin: Efficient Storage Techniques ofr Digital
Continuous Multimedia. IEEE Trasn. On knowledge and Data Engineering 5(4).
SCHULZRINNE y otros (1996): Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.:
RTP: A Transport Protocol for Real-Time Applications (RFC 1889). Internet Engi-
neering Task Force. Disponible en http://www.ietf.org/rfc/rfc1889.txt. Consultado
en mayo de 2003.
SCHULZRINNE y otros (2003): Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.:
Real Time Streaming Protocol (RTSP) (Internet Draft). Internet Engineering Task
Force. Disponible en http://www.rtsp.org/2003/drafts/draft03/draft-ietf-mmusic-
rfc2326bis-03.txt. Consultado en mayo de 2003.
SCHULZRINNE (1999): H. Schulzrinne: Operating System Issues for Continuous Media.
Handbook of Multimedia Computing (ed: B. Fuhrt), CRC.
SHARDA (1999): N. Sharda: Multimedia Networks. Handbook of Multimedia Compu-
ting (Ed: B. Fuhrt), CRC.
STEINMETZ y NAHRSTEDT (1995): W. Steinmetz, K. Nahrstedt: Multimedia: computing,
communications and applications. Prentice Hall.
SUNDARAM et al. (2000): V. Sundaram, A. Chandra, P. Goyal, P. Shenoy, J. Sahni y H.
Vin, H.. Application Performance in the QLinux Multimedia Operating System.
Proc. of the 8th ACM Conference on Multimedia.

Capítulo 11
INTEGRACIÓN DE LOS SISTEMAS
MULTIMEDIA EN WEB
ESQUEMA
11.1. La arquitectura Web y los sitemas multimedia.

11.2. Lenguajes Web para los sistemas multimedia.
11.3. Algunos tipos de aplicaciones multimedia en la Web.
11.4. Resumen.
Internet es una red global que se ha constituido en fenómeno social trans-
formador —como indica Castells (Castells, 2001)— debido a su universaliza-
ción progresiva y al creciente uso de la World Wide Web como medio de
comunicación. La estructura básica de esta Web, complementada con la tec-
nología multimedia, amplifican sus capacidades respectivas, ya que la pri-
mera permite una mejor distribución y una mayor disponibilidad para los
contenidos multimedia, y a su vez, estos contenidos permiten una interac-
ción más rica de los usuarios con la Web. De esta manera, la multimedia pue-
de distribuirse a cualquier parte del mundo de manera inmediata mediante la
Web, en lugar de utilizar medios más costosos, como la distribución por CD-
ROM, y además, las aplicaciones multimedia en la Web pueden personalizar-
se a sus usuarios a medida que estos las utilizan.
Sin embargo, la sinergia entre la multimedia y la Web presenta también
una problemática totalmente nueva. Esta problemática es esencialmente
relativa al ancho de banda de la red, ya que la distribución masiva de multi-
media aumenta considerablemente el consumo de recursos de red necesarios
para su difusión, y en consecuencia, aumenta también el tiempo de latencia
general de la red. El origen de esta disfunción está en que los protocolos de
red en los que se basa Internet no fueron originariamente pensados para la
distribución masiva de multimedia. Para solventar este problema, en los últi-
mos años han aparecido tecnologías concretas para la multimedia en la Web,
como el formato SWF que utilizan las animaciones Flash, se han desarrolla-
do técnicas de difusión específicas como el streamming, y también se han
propuesto nuevos protocolos para la mejora de la red, como el protocolo
IPv6, que considera la difusión multimedia como uno de sus requisitos fun-
damentales.
En este capítulo se ofrece una visión general de los sistemas multimedia
en Web, comenzando por una revisión de la arquitectura general Web, y su
adecuación para los sistemas multimedia, pasando después a detallar cómo
se integra los sistemas multimedia en las aplicaciones Web. Se termina con
una revisión de algunos de los tipos de aplicaciones multimedia más relevan-
tes en este entorno.
11.1. LA ARQUITECTURA WEB Y LOS SISTEMAS MULTIMEDIA

En esta sección se ofrece una síntesis de la arquitectura general Web, para
pasar a discutir su adecuación para la distribución de aplicaciones multime-
dia, y algunas extensiones existentes que vienen a paliar ciertas deficiencias.
11.1.1. Arquitectura General Web

La Web es un sistema de información accesible universalmente, que utili-
za el lenguaje de marcas Hypertext Markup Language (HTML) como medio
fundamental de estructuración. Este lenguaje hace que la Web conforme un
sistema hipermedia. Los sistemas hipermedia (Díaz, Catenazzi y Aedo, 1996)
son sistemas que combinan las características del hipertexto y la multimedia.
El hipertexto se basa esencialmente en la estructuración de las aplicaciones en
nodos, que incorporan una serie de contenidos, de manera que los usuarios
pasan de un nodo a otro mediante el recorrido de los enlaces. Ésta es la carac-
terística fundamental, la no «linealidad» o «secuencialidad» de los contenidos,
gracias a la navegación habilitada por los enlaces. Cuando los contenidos pue-
den ser de diferentes tipos, incluyendo tipos continuos como el vídeo o el
audio, con sus posibles relaciones de sincronización, se dice que la estructura
hipertextual se ha extendido para dar lugar a una estructura hipermedial. Es
importante resaltar que en hipermedia, los enlaces pueden tener como origen
o destino tipos de datos no textuales, como se describe en (Fluckiger, 1995).
DEFINICIÓN: La Web como sistema hipermedia.

• La Web es un tipo de sistema hipermedia concreto, que utiliza el lenguaje HTML
para definir su estructura hipermedial. Como tal, permite la inclusión y combina-
ción de contenidos de diferentes tipos continuos o no, en una estructura formada
por nodos y enlaces.
Más adelante aparecerán algunas limitaciones del lenguaje HTML para la

multimedia, y cómo han tratado de suplirse con tecnologías complementarias.
De momento, es importante tener claro que la Web es un tipo concreto de sis-
tema hipermedia con unas características concretas; existen otros, muchos de
carácter experimental, que proporcionan funcionalidades más ricas que la
Web, como por ejemplo Microcosm (Hall, Davis, y Hutchings, 1996). Para cla-
rificar la noción de hipermedia que implica la Web, a continuación se muestra
un ejemplo muy básico de estructura hipermedia construida en la Web.
La figura 11.1 muestra una representación gráfica conceptual de un sitio
Web muy simple, con tres páginas HTML (tres nodos), y seis enlaces, tres de
ellos conectan páginas HTML unas con otras, otro conecta dos partes de la
misma página, un quinto conecta una página HTML con un vídeo en forma-
to MPEG, y el sexto es la inclusión de una imagen en formato JPEG en la
INTEGRACIÓN DE LOS SISTEMAS MULTIMEDIA EN WEB 311
página HTML principal. Esta página es un ejemplo de una página personal

(homepage, según la jerga común en la Web) de un individuo, que proporcio-
na algunos datos sobre sí mismo.
FIGURA 11.1. Ejemplo simple de estructura Web con contenidos multimedia.
Los ficheros HTML que aparecen en la figura 1 tienen el contenido que se

muestra en los siguientes listados (nótese que se ha optado por simplificar al
máximo su estructura para enfatizar sólo los elementos que se muestran en
la figuras 11.2, 11.3 y 11.4).
<html>
<head>
<title>Página principal</title>
</head>
<body>
<p>
<h1>Página principal de Juan Sanz.</h1><br>
<a href="cv.html">Curriculum Vitae</a> /
<a href="vacaciones.html">Mis últimas vacaciones.</a>
</p>
<p id="texto1">
La multimedia tiene diversas <a href="#aplicaciones">aplicaciones</a>.
<br>
...
</p>
<img src="foto.jpg" alt="Esquema de las aplicaciones multimedia.">
<p id="texto2">
Entre las aplicaciones de la multimedia nos encontramos con:
<a name="aplicaciones">
<ul>
<li>Sistemas educativos.</li>
<li>Presentaciones interactivas</li>
<li>etc.</li>
</ul>
</p>
</body>
</html>
FIGURA 11.2. Principal.html.

<html>
<head>
<title>Curriculum Vitae de Juan Sanz</title>
</head>
<body>
<h1>Curriculum Vitae</h1>
<h2>Nombre: Juan Sanz Sanz</h2>
<p>
En 1992 obtuve el título de Licenciado en Informática, y actualmen•te
trabajo en una consultora de comercio electrónico.
</p>
<a href="principal.html">Volver a la página principal</a>
</body>
</html>
FIGURA 11.3. cv.html.
<html>
<head>
<title>Mis últimas vacaciones</title>
</head>
<body>
<h1>Vacaciones de verano 2003</h1>
<p>
Pulsando <a href="vídeo1.mpeg">aquí</a> podrás ver un vídeo de mis
vacaciones de verano
en Lloret de Mar.
</p>
</body>
</html>
FIGURA 11.4. vacaciones.html.
En este ejemplo se ve otro elemento conceptual importante de la hiper-

media: el concepto de ancla. Un ancla es un contenido, nodo o fragmento de
contenido que actúa como origen o destino de un enlace. Así, en el ejemplo se
ve que pueden ser anclas las páginas HTML, las imágenes o los vídeos, y tam-
bién puntos concretos dentro de una página HTML, como se ha visto en el
caso del enlace interno dentro de la página principal. Actualmente, el con-
cepto de ancla en la Web se ha extendido de modo que cualquier parte de un
nodo en la Web pueda ser «direccionado» mediante el lenguaje XPointer1,
pero no se tratará aquí, ya que su uso aún no está generalizado.
Es importante notar que de los enlaces que aparecen en el ejemplo que se
acaba de describir, la forma de activación o puesta en funcionamiento de los
mismos no es igual para todos ellos. Concretamente, la imagen incorporada
en la página principal (que es en propiedad un enlace a un contenido visual
1
http://www.w3.org/TR/xptr/
no continuo) se activa y se incluye en el espacio de visualización de la misma

de manera automática. Sin embargo, los enlaces entre las páginas, dentro de
la página principal, y de la página a la secuencia de vídeo sólo se activan
cuando el usuario realiza una acción sobre ellos, tal como activarlos median-
te el ratón. Esta peculiaridad de la marca IMG de HTML implica que al aña-
dir imágenes en HTML, éstas deben tener un tamaño razonable, para evitar
que se ralentice la carga de la página en el navegador.
Una vez visto este ejemplo, cabe preguntarse ¿la estructura que se describe
en la figura 11.1 puede considerarse un sistema multimedia? Es claramente una
estructura en la cual se combinan tipos de datos de diferentes características,
pero no existe ninguna relación de sincronización entre elementos de diferentes
tipos. Por tanto, a pesar de ser una estructura multimedia de tipo hipermedial,
no posee características de sincronización y secuenciación entre contenidos,
por lo cual, puede considerarse una aplicación multimedia muy básica.
Según lo visto, los contenidos en la Web pueden ser de diferentes tipos.
Estos tipos se denominan en HTML tipos MIME (Multipurpose Internet Mail
Extensions). Estos tipos son una manera estandarizada de nombrar a los dife-
rentes tipos de datos, de modo que los navegadores de Internet sepan cómo
tratar un contenido que están recibiendo de acuerdo a su tipo.
Hay cinco tipos «generales», que tienen después multitud de subtipos.
Los tipos generales son texto, imágenes, audio, vídeo y un quinto tipo deno-
minado «aplicación». Este último tipo sirve para indicar que el contenido que
está llegando al navegador tiene una interpretación que no casa en ninguna
de las categorías anteriores. A continuación se muestran algunos ejemplos.
Dentro de la categoría de texto, se tiene el subtipo «text/plain» que indica
que lo que se envía es texto sin ningún tipo de información de formato; tam-
bién se tiene, lógicamente, el subtipo ‘text/html’ que indica que lo que se está
transmitiendo es texto con marcas de HTML. La imagen y el vídeo que se
mostró en el ejemplo de la figura 11.1 tendrían los subtipos «image/jpeg» y
«vídeo/mpeg» respectivamente. Dentro de los tipos «aplicación» se pueden
ver por ejemplo el de los ficheros PDF, que sería «application/pdf», el de las
presentaciones PowerPoint «vnd.ms-powerpoint» o el de los ficheros compri-
midos «application/zip». En caso de que un determinado contenido no ten-
ga un tipo conocido o se quiera simplemente transferir como un fichero sin
formato determinado, se ve el tipo «application/octet-stream». Cuando un
navegador recibe un contenido de este tipo, su acción por defecto es permitir
que ese contenido se guarde en el sistema de ficheros del usuario.
DEFINICIÓN: Tipos MIME.

• Los tipos MIME son una clasificación de los diferentes tipos y subtipos de conteni-
dos que pueden darse en la Web. Incluyen categorías generales para texto, imá-
genes, vídeo y audio, y también para otros formatos que no encajen en las cate-
gorías anteriores.
La infraestructura tecnológica de la Web es la red Internet, que a su vez se

basa esencialmente en el protocolo TCP/IP. Sobre este protocolo se distribu-
ye el HTML mediante un protocolo de nivel superior denominado HTTP. El
protocolo HTTP constituye un modelo de aplicación basado en solicitudes de
recursos a servidores Web. De este modo, un servidor Web es una aplicación
que actúa como contenedora de recursos de información (de contenidos,
según las descripciones anteriores), y los clientes de estos servidores solicitan
la descarga de los mismos mediante el uso de unos identificadores denomi-
nados Uniform Resource Identifiers (URI)2, que no son otra cosa que cadenas
de caracteres con un formato específico que identifican los recursos disponi-
bles en la Web. Los clientes más habituales en la Web —aunque no los úni-
cos— son los navegadores, que son aplicaciones especializadas en recorrer la
Web, orientadas a los usuarios de la Web.
Así, volviendo al ejemplo de la figura 11.1, el usuario desde su navegador soli-
citaría la página principal (u otra) mediante una URI que indicase dónde se halla
alojada. Por ejemplo, escribiría una URI tal como http://www.juanperez.es/
principal.html, suponiendo que los contenidos estuviesen alojados en un servi-
dor con ese nombre. Al hacer la solicitud, el navegador pide al servidor la página
mediante una solicitud HTTP como la siguiente:
GET http://www.juanperez.es/principal.html HTTP/1.0

User-Agent: HTTPTool/1.0
En la solicitud se indica el identificador del recurso y la versión del pro-

tocolo HTTP que se está utilizando. Además, en ocasiones se envía más infor-
mación en la forma de cabeceras (headers). Una cabecera típica es User-Agent,
que informa del navegador que está enviando la petición.
En consecuencia, el servidor devuelve una respuesta HTTP con la cabe-
cera de la figura 11.5:
H
HTTP/1.0 200 OK
Date: Fri, 31 Dec 2002 23:59:59 GMT
Content-Type: text/html
Content-Length: 715
<html>
...
FIGURA 11.5. Cabecera de la respuesta HTTP que devuelve el servidor.
2
http://www.ietf.org/rfc/rfc2396.txt
En esa respuesta, se indica la versión del protocolo junto a un código indi-

cando si ha habido error o no, la fecha de la respuesta, el tipo MIME del con-
tenido que se va a devolver y su longitud. A continuación viene el contenido
en sí, en este caso, el fichero HTML correspondiente.
Debido al elemento IMG, el navegador realizará automáticamente una
nueva solicitud HTTP, pero en este caso el servidor devolverá una respuesta
indicando el tipo MIME del contenido que está enviando.
Este es el proceso básico de la Web como sistema multimedia. A conti-
nuación se ven ampliaciones y extensiones que se le han ido añadiendo con el
tiempo para proporcionar funcionalidades más avanzadas.
11.1.2. Extensiones a Internet para los sistemas multimedia

La red Internet se basa en el protocolo de nivel de red denominado IP
(Comer, 2000). En 1991, el grupo Internet Engineering Task Force (IETF)3 deci-
dió que la versión del protocolo IP que estaba en uso (IPv4) necesitaba adicio-
nes significativas para solucionar una serie de problemas planteados por el
crecimiento de Internet y las demandas más avanzadas de sus usuarios. El
diseño de esa nueva versión de IP se conoce como IPv6 o IPng. Entre las nove-
dades de IPv6 hay mejoras en el direccionamiento, la seguridad y el rendi-
miento, pero lo que interesa aquí es que entre los requisitos de IPv6 se encuen-
tra desde su origen el soporte de aplicaciones multimedia con gran consumo
de ancho de banda. Actualmente, IPv6 sólo se encuentra en redes experimen-
tales, y tardará tiempo en sustituir a la infraestructura actual basada en IPv4,
sin embargo, es importante destacar al menos dos características de IPv6 que
sin duda serán fundamentales en la multimedia sobre la Web del futuro:
• En primer lugar, el tráfico multimedia es en muchas ocasiones multi-
destino (multicast), ya que suelen tener un destino que difunde los con-
tenidos a muchos receptores. IPv6 proporciona mejoras en las transmi-
siones multi-destino.
• En segundo lugar, IPv6 permite el tráfico de datos en tiempo real. Este
concepto contrasta con el tráfico en IPv4, que es de tipo best effort, es
decir, no se puede garantizar un ancho de banda determinado a una
aplicación. El tráfico en tiempo real (como la difusión de vídeo, por
ejemplo) es típicamente sensible a retardos de red y a pérdidas por con-
gestión de la red. Para ello, en IPv6 se habla de «Servicio Integrado»,
que permite reservar un ancho de banda mínimo para determinadas
clases de usuarios, garantizando una calidad de servicio (quality of ser-
vice, QoS) determinada.
3
http://www.ietf.org/
Aunque los detalles técnicos del nuevo protocolo caen fuera de los objeti-
vos de esta obra, pueden consultarse por ejemplo en (Gai, 1998).
DEFINICIÓN: Sistema Multimedia en IPv6.

IPv6 es el nombre del protocolo de red que está destinado a sustituir el actual protocolo
IPv4 en el que se sustenta Internet. Este protocolo extendido incorpora características
específicas para las aplicaciones multimedia. Concretamente, mejora las comunicacio-
nes multidestino (multicast) y está preparado para el tráfico en tiempo real —que requie-
ren muchas aplicaciones multimedia— permitiendo la reserva de un ancho de banda
mínimo para un determinado usuario o aplicación.
Junto a las extensiones a la infraestructura de red de Internet, se hace

necesaria una extensión de HTML para dar mejor soporte a características
multimedia avanzadas, como es la sincronización entre contenidos de diver-
sos tipos. El avance más relevante es la aparición de la especificación del len-
guaje de marcas Synchronized Multimedia Integration Language (SMIL).
SMIL es un lenguaje que tiene cierta similitud con el HTML, pero proporcio-
na elementos para sincronizar tipos continuos o discretos de manera explíci-
ta, entre otras funcionalidades, tal y como se muestra en el siguiente ejemplo
ilustrativo. La figura 11.6 incluye un fragmento de SMIL:
<par>
<a href="#Noticias"> <img src="boton1.jpg"/> </a>
<a href="#ElTiempo"> <img src="boton2.jpg"/></a>
<excl>
<par id="Noticias" begin="0s">
<video src="noticias.mpg"/>
<text src="subtitulos.html"/>
</par>
<par id="ElTiempo">
<img src="miercoles.jpg"/>
<audio src="miercoles_sonido.mp3"/>
</par>
</excl>
</par>
FIGURA 11.6. Fragmento de SMIL.
En el ejemplo, se muestran dos botones que activan las secciones de

«noticias» o «El Tiempo» de un hipotético periódico virtual. Cuando se pulsa
una de ellas, se activa la correspondiente presentación, con nombre «Noti-
cias» y «ElTiempo». El elemento excl hace que sean excluyentes, es decir, que
sólo una de ellas se visualice, de manera que si se está viendo «Noticias» y se
pulsa el otro botón, las noticias pararán y comenzará «ElTiempo» y vicever-
sa. Por otro lado, cada una de las presentaciones implica a dos medios sin-
cronizados, cosa que especifica el elemento par. En un caso, los subtítulos se
sincronizan con el vídeo de las noticias, y en el otro, el sonido se sincroniza
con la imagen del mapa del tiempo.
DEFINICIÓN: El lenguaje SMIL.

• El lenguaje SMIL es un lenguaje de marcas, similar al HTML, que proporciona ele-
mentos para la definición de presentaciones multimedia con sincronización entre
diferentes tipos de contenidos multimedia.
Por otro lado, aprovechando la infraestructura de tipos MIME y la posi-

bilidad de extender los navegadores —que se describirá en la siguiente sec-
ción—, han aparecido tipos MIME que representan combinaciones multime-
dia complejas. Por ejemplo, el lenguaje Virtual Reality Modeling Language
(VRML) permite definir modelos tridimensionales para su visualización en el
navegador. Un tipo multimedia que está alcanzando gran popularidad en la
Web actualmente es el derivado de la aplicación Flash del fabricante Macro-
media. El tipo SWF4 (Shockwave Flash File Format) permite crear animacio-
nes interactivas basadas en gráficos vectoriales y sonidos que ocupan menos
espacio que las animaciones basadas en mapas de bits.
Además de las extensiones anteriores, han aparecido también servidores
especializados en multimedia, que complementan a los servidores Web habi-
tuales, proporcionando servicios avanzados para la difusión de vídeo o audio.
Las peticiones a los mismos se realizan mediante URIs —introducidas direc-
tamente o solicitadas por navegación de enlaces—, como en los servidores
Web, pero la respuesta del servidor es diferente.
Estos servidores utilizan una tecnología denominada tecnología de stre-
amming. Esta tecnología permite la descarga progresiva de contenidos conti-
nuos como el vídeo, el audio o las animaciones mientras se va mostrando al
usuario en tiempo real. Es importante resaltar que este modo de operación es
completamente diferente al de los servidores Web convencionales. Con servi-
dores convencionales, si se quiere ver un vídeo, primero se tiene que descar-
gar completamente, y después comienza su visualización. Una variante inter-
media es el pseudo-streamming o descarga progresiva. En la descarga
progresiva, los usuarios esperan a que se descargue una «porción significati-
va» antes de comenzar la visualización (o la audición).
En el streamming real, los servidores utilizan protocolos de difusión espe-
cíficos. Un ejemplo es el protocolo Real Time Streaming Protocol (RTSP)5, que
utilizan los productos del fabricante RealNetworks entre muchos otros.
4
http://www.openswf.org/
5
http://www.rtsp.org/
Las tres tecnologías de streamming más utilizadas actualmente en la Web son

las de RealMedia, QuickTime y WindowsMedia, con diferentes servidores de stre-
amming así como diferentes reproductores. El reproductor de WindowsMedia
actualmente está integrado con el navegador Explorer del fabricante Microsoft.
DEFINICIÓN: Tecnologías de streamming.

• Las tecnologías de streamming en Internet permiten la descarga progresiva de la
multimedia, permitiendo su uso sin necesidad de descargar completamente los con-
tenidos. Estas tecnologías requieren servidores, clientes y protocolos especializados.
Aunque la tecnología de streamming se va difundiendo poco a poco en

Internet, el ancho de banda necesario para que la presentación se siga en
tiempo real sigue siendo muy grande, por lo cual, cada tecnología tiene méto-
dos de compresión del flujo de datos, para tratar de minimizar el consumo de
recursos de red. Además, debido a la gran actividad de red y de procesamien-
to de los servidores de streamming, estos suelen tener un hardware indepen-
diente del resto de los servidores que conformen el sitio Web.
11.2. LENGUAJES WEB PARA LOS SISTEMAS MULTIMEDIA
Como ya se ha mencionado, el lenguaje básico de la Web actual es el Hyper-

text Markup Language (HTML), que se distribuye a través del protocolo HTTP
sobre el protocolo TCP/IP. Como su nombre indica, HTML es un lenguaje origi-
nariamente diseñado para el texto, y como tal tiene importantes limitaciones
para la multimedia. HTML proporciona básicamente soporte a imágenes fijas
bidimensionales, ya que el soporte para formatos no textuales específicos es res-
ponsabilidad de los navegadores de la Web. Por ejemplo, el formato GIF98a pro-
porciona una forma rudimentaria de animación de imágenes, y la práctica tota-
lidad de los navegadores actuales lo soportan. Pero a pesar de ese soporte del
navegador, HTML no proporciona facilidades para audio o animaciones, ni para
sincronización que permita realizar presentaciones complejas. Estas limitacio-
nes iniciales han dado lugar a extensiones del lenguaje HTML de naturaleza
diversa. En el resto de esta sección se describen algunas de las más notables.
11.2.1. Lenguajes de script para manipulación de HTML
El lenguaje HTML en su versión original no proporcionaba ninguna

característica de interactividad, si se excluye la navegación a través de los
enlaces, aunque ésta no es propiamente una interacción con la página, sino
la sustitución de la misma por el destino del enlace. Esta deficiencia motivó
la aparición de lenguajes complementarios que permiten interactuar con la
página. Así aparecieron los lenguajes de script como el javascript y el VBS-
cript. Estos son lenguajes interpretados por el navegador6, y tienen la funcio-

nalidad básica de permitir la interactividad con los elementos de la página.
Por ello, son lenguajes de propósito específico, especializados en la manipu-
lación de los elementos de la página HTML que los contiene.
Esa manipulación de los elementos de la página se realiza mediante unas
interfaces de programación que ven en la página HTML como un árbol,
acuerdo a lo especificado por el Document Object Model (DOM).
Los lenguajes de script originales eran incompatibles y dependientes del
navegador que mostraba la página, lo cual acarreaba serios problemas para
el desarrollo de Webs que funcionasen en diferentes tipos de navegadores.
Actualmente, los lenguajes de script más utilizados como javascript y JScript
están basados en una especificación común estandarizada, denominada
ECMAScript7, que asegura un cierto grado de compatibilidad, al menos en la
estructura básica del lenguaje.
Para hacerse una idea de cómo se puede añadir interactividad a las pági-
nas, se va a ver un ejemplo muy simple que utiliza javascript para modificar
un elemento de una página HTML, incluido en la figura 11.7.
<html>
<head>
<title>Ejemplo javascript</title>
<script language="javascript">
function cambia_imagen(numero){
document.all["imagen"].src= numero + ".jpg";
}
</script>
</head>
<body>
<p>
Pulse en cada botón para cambiar la imagen.
</p>
<hr>
<img id="imagen" src="inicial.jpg">
<hr>
<button onclick="cambia_imagen('uno');">Mapa</button>
<button onclick="cambia_imagen('dos');">Datos demográficos</button>
<button onclick="cambia_imagen('tres');">Principales carreteras</button>
</body>
</html>
FIGURA 11.7. Ejemplo que utiliza javascript para modificar un elemento de una página HTML.
6
Es importante no confundir estos lenguajes de script cuyos programas se ejecutan en el
navegador con los lenguajes de script que se ejecutan en los servidores Web, como son JSP, ASP
o PHP. Éstos últimos están orientados a la generación dinámica de HTML, y por ello se les sue-
le denominar como lenguajes «de servidor», para diferenciarlos de los que se ejecutan en el nave-
gador que se suelen denominar «de cliente».
7
http://www.ecma-international.org/publications/standards/ECMA-262.HTM
La página HTML del de la figura 11.7 simplemente muestra un mensaje,

una imagen (inicial.jpg) y tres botones indicando en este caso tres vistas de
un país determinado. Sobre esta estructural básica, se ilustran dos extensio-
nes fundamentales al HTML:
• En primer lugar, la interactividad de la página se consigue mediante la
posibilidad de definir «manejadores de eventos». En el ejemplo, el even-
to de interfaz de usuario «pulsar botón» se captura mediante el corres-
pondiente atributo onclick del elemento button, que hace referencia al
manejador, en este caso, a la función javascript cambia_imagen.
• La función cambia_imagen se ejecutará en respuesta a la pulsación de
uno de los botones. Lo fundamental de estas funciones es que pueden
manipular el HTML de la página mediante el uso de una representa-
ción de la misma como árbol DOM. En el ejemplo, se modifica el atri-
buto src de la imagen de la página, para pasar a mostrar otra. Para ello,
se utiliza el objeto predefinido document, que representa a la página
entera, y se utiliza el atributo id de la imagen para manipularla.
Este sencillo ejemplo muestra cómo los lenguajes de script pueden utili-
zarse para añadir interactividad a la página Web, incluso creando pequeñas
animaciones de manera rudimentaria.
DEFINICIÓN: Lenguajes de script en HTML.

• Los lenguajes de script para HTML como el javascript, permiten escribir programas
interactivos que manipulan el HTML de la página como si fuese una estructura de
tipo árbol, denominada árbol DOM.
11.2.2. Extensiones del navegador

Los navegadores actuales son aplicaciones que permiten ser extendidas,
añadiendo funcionalidades que se integran en el navegador como si fuesen
una parte integrante de él. Esta arquitectura interna de los navegadores ha
permitido numerosas estén-siones de diversa índole.
Se mencionan aquí tres tipos de extensiones —applets, plugins8 y aplica-
ciones auxiliares— que difieren en su manera de integrarse con el navegador,
aunque cumplen esencialmente la misma función.
Se llaman applets, de manera genérica, a pequeñas aplicaciones que pue-
den ejecutarse en el navegador, cuando la página HTML que las contiene
hace referencia a ellas. Estas aplicaciones se descargan al navegador en un
8
Se ha decidido conservar los términos en inglés applet y plugin debido a su uso extendido
y a no tener una traducción directa y ampliamente reconocida al castellano.
formato de código independiente de la plataforma, y una máquina virtual las

ejecuta como parte de la página. Un applet ocupa un área rectangular del nave-
gador y gestiona su propia entrada y visualización. Debido a que los applets
son programas de complejidad arbitraria, pueden utilizarse para contener
multimedia interactiva de cualquier tipo. La única restricción que se debe
tener en cuenta por el desarrollador es su tiempo de descarga. Actualmente, la
mayoría de los applets se desarrollan en lenguaje Java o en lenguajes de la pla-
taforma Microsoft. Los applets realizados con esta última tecnología se deno-
minan componentes ActiveX, y son funcionalmente equivalentes a los applets
de Java.
El fragmento de código de la figura 11.8 es el esqueleto de un applet en el
lenguaje Java. Los métodos init y destroy se ejecutan respectivamente en los
momentos en los que el applet se carga y descarga del navegador. Los méto-
dos start y stop se ejecutarán cuando cada vez que el applet se muestre u ocul-
te en el navegador (por ejemplo, si se navega a otra página y a continuación
se retorna a la misma). Por lo demás, los applets son un área de visualización
sobre la cual se puede componer una aplicación de interfaz gráfica de usua-
rio de igual modo a como se haría para una aplicación de interfaz gráfica
convencional.
public class MiApplet extends java.applet.Applet {

public void init() {
}
public void destroy() {
}
public void start() {
}
public void stop() {
}
}
FIGURA 11.8. Esqueleto de un applet en el lenguaje Java.
La diferencia fundamental entre un applet y los lenguajes de script que se

ha visto anteriormente es que los primeros se programan en lenguajes que no
están integrados con el propio HTML, mientras que los lenguajes como javas-
cript están íntimamente ligados a él.
Los plugins son bibliotecas software que se añaden al navegador sin nece-
sidad de reinstalarlo ni reiniciarlo, extendiendo sus funcionalidades. En
muchos casos, los plugins se utilizan para dar soporte a nuevos tipos de datos
que no soportaba originariamente el navegador. De esta manera, si el nave-
gador detecta que un recurso solicitado no tiene un formato soportado por él
mismo, comprobará su lista de plugins, y entregará el recurso a las bibliote-
cas del plugin, que tomará como área de visualización el área completa del
navegador o una región de la misma.
Por último, las extensiones auxiliares de los navegadores son una varian-
te de los plugins, en la cual, cuando el navegador detecta un tipo de recurso
no conocido, entrega los datos a una aplicación auxiliar independiente. La
diferencia que tienen con los plugins es que la presentación de ese conteni-
do está separada del área de visualización del navegador, y es independiente
de éste.
DEFINICIÓN: Applets y plugins

• Los navegadores Web actuales están preparados para aceptar extensiones de su
funcionalidad.
• Los applets son pequeños programas que se descargan y se ejecutan en el nave-
gador. El lenguaje de programación más utilizado para escribir applets es el len-
guaje Java.
• Los plugins son módulos que se instalan sobre el navegador, y sirven para gestio-
nar un determinado formato de datos. Así, el navegador delega la visualización de
esos tipos de datos en las bibliotecas del plugin.
11.2.3. Lenguajes de marcado específicos para los sistemas

multimedia
Si bien el lenguaje HTML permite la inclusión de contenidos multimedia,
y sus extensiones permiten añadir interactividad a la estructura hipermedia,
HTML no proporciona en sí mismo facilidades para la sincronización de los
contenidos multimedia que permitan definir aplicaciones multimedia com-
plejas. Se puede desarrollar este tipo de aplicaciones utilizando extensiones,
pero recurriendo a un lenguaje específico como el SMIL que ya se ha men-
cionado anteriormente.
Un lenguaje muy utilizado actualmente es el ActionScript, que se utiliza
para crear animaciones interactivas, y que permite manipulaciones comple-
jas de objetos multimedia. Este lenguaje es el que se utiliza para realizar las
animaciones que después pueden verse en los navegadores que tienen un plu-
gin instalado para interpretar el formato SWF.
11.3. ALGUNOS TIPOS DE APLICACIONES MULTIMEDIA

EN LA WEB
La posibilidad de acceso global a Internet ha favorecido la aparición de
sistemas multimedia en muy diversos tipos de aplicaciones en Internet
(Furht, 1999). En el resto de este apartado se revisan algunos de los tipos de
aplicaciones multimedia en la Web, con el objetivo de ilustrar la variedad de
aplicaciones posibles. Los dos primeros son ejemplos que se encuentran con
bastante frecuencia actualmente, mientras que el tercero es más una prome-

sa que una realidad en la Web actual.
11.3.1. Aplicaciones educativas
Los sistemas multimedia son un recurso didáctico importante en la edu-

cación o formación a distancia o semi-presencial. Debe tenerse en cuenta que
los individuos no aprenden de manera natural utilizando métodos pasivos,
sino que el mecanismo más eficaz de aprendizaje consiste en fijarse objeti-
vos, formular preguntas, actuar, equivocarse, corregirse y, finalmente, gene-
rar respuestas. De otra forma ¿quién aprendió a andar, nadar, hablar y tantas
otras cosas asistiendo a clases?
El principal inconveniente de aplicar técnicas que permitan al estudiante
aprender de manera natural en la formación académica es que este tipo de
aprendizaje requiere una cantidad inusual de atención individualizada para el
alumno por parte de sus educadores, lo que no siempre es posible, bien por
cantidad de recursos disponibles o por la ausencia de presencialidad. Los pro-
gramas de ordenador juegan entonces un papel importante, ya que no sólo
posibilitan esta individualización, sino que además permiten presentar tareas
que motiven e interesen a cada alumno en particular, les permiten seguir enfo-
ques exploratorios, habilitan la opción de recuperar las situaciones cuando se
cometen errores y les ofrecen control sobre la tarea de aprendizaje.
Pero no siempre los programas de ordenador son herramientas que faci-
liten el aprendizaje natural. Cuando se utilizan programas que simulan las
técnicas didácticas que se ponen casi siempre de manifiesto en las clases de
la escuela, se están reproduciendo de manera automática los mismos incon-
venientes que estas tienen, y que básicamente derivan de no utilizar los
mecanismos que hacen que las personas aprendan como lo hacen de mane-
ra natural. Esto ocurre cuando, por ejemplo, se utiliza el programa como un
mero libro electrónico, donde el alumno sólo tiene que pasar página utili-
zando un botón.
Los sistemas multimedia tiene importantes características que hacen que
los programas de ordenador sean herramientas didácticas útiles, puesto que
entre otras cosas, permiten presentar las tareas de manera más atrayente y
aumentar el grado de interacción, si bien por sí solas no son garantía de éxi-
to; hace falta saber combinarlas en lo que autores como Schank (Schank,
1994) denominan arquitecturas de aprendizaje. Estas arquitecturas explotan
la presencia de elementos multimedia en aplicaciones para conseguir apren-
dizajes efectivos, y son directamente utilizables en aplicaciones Web, como
por ejemplo:
• La arquitectura de aprendizaje activo basado en simulación. Un ejem-
plo elocuente de este tipo de arquitectura son los simuladores de labo-
ratorios químicos o físicos, donde los sistemas multimedia permiten,

no solo generar el espacio visual e interactivo donde el estudiante tiene
por completo el control de las acciones, sino que también permite
insertar ficheros de vídeo y/o audio donde el profesor responda a pre-
guntas o explique conceptos importantes en una determinada secuen-
cia de acciones.
• La arquitectura de aprendizaje basado en anécdotas. Los sistemas mul-

timedia también puede ser útil para estudiar aquellas materias que
requieren mucha memorización y son monótonas, por lo que el apren-
dizaje puede no llegar a ser efectivo. Por ejemplo, existen programas
para estudiar a través de la Web geografía, donde se explota que es más
fácil aprender las características geográficas de los sitios visitándolos
en lugar de memorizándolas. Así, el estudiante puede planificar un via-
je utilizando un mapa de carreteras y se le van presentado vídeos tanto
de la ruta como del sitio de destino, de manera que se minimice el
esfuerzo de memorización.
• Aprendizaje dirigido a objetivos. El estudio eficaz de diversas materias

hace necesario que el alumno adopte con libertad los objetivos que
desea alcanzar de manera paulatina y que tenga el control de cómo
conseguirlos adaptando el entorno de aprendizaje a sus necesidades.
Por ejemplo, existen aplicaciones multimedia que ponen al estudiante
en la situación de resolver un hipotético problema práctico, y le ofrecen
diversos medios para llegar a un solución, como aquellas que le propo-
nen jugar el papel de un consultor que debe aconsejar a un cliente. La
aplicación proporciona al consultor diferentes medios como grabacio-
nes en vídeos de expertos, simulaciones de entrevistas interactivas con-
versacionales o la posibilidad de consultar una base de datos multime-
dia sobre el tema tratado. El estudiante construye su propio camino de
indagación con los recursos que se le ofrecen.
Estas y otras aplicaciones multimedia se utilizan actualmente tanto en

enseñanza reglada a través de la Web como en formación empresarial basada
en la Web, contando con un gran número de contenidos multimedia predise-
ñados como los que ofrece la empresa SkillSoft.
11.3.2. Conferencias virtuales
Uno de los usos más extendidos de la tecnología multimedia en la Web es

la difusión de conferencias o charlas a través de Internet (webcasting), de
modo que se produce el efecto de una «conferencia a distancia», es decir, la
difusión de vídeo y audio sincronizados en determinadas franjas horarias,
como ocurre con la televisión, pero pudiendo añadir, en algunos casos, la
interacción con los participantes remotos. Este uso de la multimedia es posi-
ble gracias a la tecnología de streamming de la que ya se ha hablado. Una

sesión de WebCasting requiere varios pasos que se enlazan en un flujo conti-
nuo de información. En primer lugar, el audio o vídeo debe capturarse y
enviarse vía satélite, línea telefónica u otro tipo de conexión al centro de codi-
ficación. En la fase de codificación, la señal original se convierte a un forma-
to preparado para el streamming, como los conocidos WindowsMedia, Real-
Media o QuickTime. Una vez se tienen los ficheros en ese formato, la
distribución se realiza mediante servidores especializados, llegando a una
interfaz Web preparada para el evento.
En el contexto de la tecnología de Webcasting se habla de «canales», utili-
zados en el mismo sentido que se usa para hacer referencia a canales de radio
o televisión. De hecho, y a pesar de la relativa juventud de esta tecnología, ya
existen formatos abiertos para la definición de canales. Un ejemplo es la
especificación CDF (Channel Definition Format) propuesta por Microsoft,
que permite definir los meta-datos descriptivos de un canal, como su horario,
título y autor.
La arquitectura de los sistemas de webcasting puede implicar a producto-
res de contenidos y consumidores de información, de manera directa o con
intermediarios. En el caso más general, estos sistemas tendrían la configura-
ción que se muestra en la figura 11.9.
SmarTraveler Usuario
Servidor PointCast
Repetidor I-Server Receptor Castanet
de PointCast
Usuario
MBN Servidor CastaNet

Proxy BackWeb Aplicación de
Información
Metereológica
Servidor BackWeb
Receptor PointCast
FIGURA 11.9. Arquitectura general de un sistema compuesto de Webcasting.
En la arquitectura de la figura 11.9 aparecen varios tipos diferentes de

entidades intermediarias entre productores de información (generalmente,
empresas, como SmarTraveler o MBN) y consumidores de contenidos (usua-
rios o aplicaciones de usuario final):
• Los servidores que empaquetan y emiten los contenidos de los provee-

dores.
• Los repetidores que proporcionan escalabilidad al conjunto de los ser-
vidores.
• Los receptores, que permiten localizar los contenidos y recibir notifi-
cación de sus actualizaciones.
Esta arquitectura general refleja la complejidad que puede llegar a impli-
car un sistema de WebCasting que alcance a un gran número de usuarios,
como pueden ser los de la cadena de noticias BBC.
11.3.3. Recuperación de información multimedia

La recuperación de información en Internet es un conjunto de técnicas de
procesamiento y organización de la información que persigue la construc-
ción de buscadores que permitan a los usuarios de la Web encontrar infor-
mación y contenidos a partir de la formulación de consultas simples, como
puede ser la escritura de una o varias palabras o frases.
Esta importante área de aplicación ha dado como fruto técnicas de inde-
xación de documentos en la Web (Baeza-Yates y Ribeiro-Neto, 1999), que se
han incorporado en los populares buscadores de la Web —como Google o
AltaVista—, y que constituyen hoy una de las aplicaciones fundamentales sin
las que la Web no podría hoy concebirse.
Ahora bien, la mayor parte de los buscadores sólo habilita la búsqueda de
información textual, quedando la búsqueda de información en otros tipos de
datos relegada en muchos casos a buscar en las descripciones textuales aso-
ciadas a los mismos. Sin embargo, esta limitación hace que muchos de los
contenidos en Internet queden fuera del alcance de los buscadores, lo cual ha
llevado a la investigación en técnicas de recuperación de contenidos para
tipos de datos concretos diferentes del texto.
La recuperación de información multimedia basada en el contenido
requiere un concepto de similaridad entre contenidos que es dependiente del
tipo de datos. Por ejemplo, es posible preguntarse ¿qué hace a dos imágenes
o a dos ficheros de audio similares? Incluso se pueden plantear consultas más
complejas, como por ejemplo «busca dos evoluciones de cotización en bolsa
que tengan el mismo perfil de variación» a partir de gráficos con esas cotiza-
ciones. Esto lleva al planteamiento de que para cada tipo de búsqueda con-
creta se requiere una extracción previa de sus características relevantes, y
éstas pueden variar dependiendo de la intención de la búsqueda en sí. Por
ejemplo, al buscar imágenes puede interesar basarse en características pre-
ceptúales como el color o la luminosidad, o bien se pueden buscar objetos
semánticamente reconocibles dentro de las imágenes (por ejemplo, coches de
un tipo determinado).
De lo que se acaba de plantear se deduce que la recuperación de informa-

ción multimedia es realmente un área que abarca múltiples facetas y objeti-
vos, dependientes tanto del tipo y combinación de los medios en los que se
busca, como de las características de los mismos que se tienen en cuenta en
la búsqueda. Por ello, aquí se limita a describir brevemente dos aplicaciones
concretas, que son ilustrativas de la problemática de este tipo de recupera-
ción de información.
Como primer ejemplo, se puede citar la búsqueda por imágenes —una
revisión de trabajos en el área puede encontrarse en (Goodrum, 2000)— que
está incorporada, entre otros, en el Sistema Gestor de Base de Datos DB2 de
IBM. En este tipo de búsqueda, las consultas se especifican mediante un
ejemplo de la imagen o la característica de la imagen que se desea buscar. Por
ejemplo, los usuarios pueden dibujar un ejemplo, o seleccionar colores o tex-
turas de una paleta.
En el caso del color, la búsqueda se realiza mediante la comparación de
los histogramas de color de las imágenes o de regiones de éstas. La similitud
entre texturas se puede calcular comparando la variación entre niveles de gris
de regiones de imágenes. Por último, la búsqueda basada en formas se basa
en una detección previa de objetos dentro de las imágenes que requieren la
identificación de los bordes de los mismos o de regularidades en fragmentos
de las imágenes.
En segundo lugar, la recuperación de audio (Foote, 1999) tiene dos ver-
tientes fundamentales: la recuperación basada en características del habla y
la recuperación del sonido en general, sin asumir que en el sonido hay un dis-
curso hablado. En el primer caso, se utiliza una representación estadística de
cada uno de los eventos del habla, como puede ser la pronunciación de una
palabra. Esos modelos estadísticos de la fonética de las palabras actúan en
este caso como patrones de similitud. Aunque estas técnicas tienen una bue-
na tasa de acierto para vocabularios limitados, en casos más generales como
la búsqueda de noticias habladas, su fiabilidad se reduce considerablemente.
La segunda de las vertientes presenta problemas más complicados, y se basan
actualmente en características preceptúales del sonido como el brillo, el tono
o la intensidad.
11.4. RESUMEN
La Web conforma un sistema hipermedia basado en el lenguaje HTML
que es accesible universalmente a través de la red Internet, lo cual le con-
fiere un carácter de medio de comunicación de masas. El lenguaje HTML
permite la descarga de contenidos multimedia integrados en la estructura
hipermedia, basándose en el concepto de tipo multimedia (tipos MIME).
Sin embargo, los protocolos de la red y los servidores Web originales no
fueron preparados de manera específica para la distribución masiva de
multimedia, lo cual origina una problemática relativa esencialmente al

ancho de banda y la latencia del uso de Internet. Tampoco el lenguaje
HTML original ni los primeros navegadores de la Web fueron pensados ori-
ginariamente como elementos para dar soporte a la sincronización de con-
tenidos multimedia y la interacción con los mismos.
Las deficiencias señaladas han llevado a diversas extensiones de la tecno-
logía Web original en diferentes dimensiones.
Por un lado, los nuevos protocolos de red propuestos para Internet, que
se basan en la nueva versión del protocolo de red IP denominado IPv6, con-
sideran la distribución multimedia como uno de sus requisitos esenciales.
Además, han aparecido servidores y protocolos para Internet que permiten la
difusión más eficiente de la multimedia, siendo la tecnología de streamming
la más relevante de estas innovaciones.
Por otro lado, se ha propuesto el lenguaje de marcas SMIL, similar al
HTML, para la definición de presentaciones multimedia sincronizadas, y
han aparecido formatos de datos multimedia que han alcanzado gran popu-
laridad, como el formato SWF, que se acompaña de un lenguaje de progra-
mación específico para la multimedia, denominado ActionScript. Ante esta
proliferación de tipos de datos específicos, los navegadores se han conver-
tido en aplicaciones extensibles —siendo los applets y los plugins los meca-
nismos de extensión fundamentales— y han incorporado lenguajes de
cliente que permiten a los usuarios una interacción más rica con las pági-
nas Web.
La sinergia de la Web y la tecnología multimedia ha dado lugar a diversos
tipos de aplicaciones, siendo las aplicaciones educativas, las conferencias vir-
tuales y la recuperación de información multimedia algunas de las más utili-
zadas e importantes.
11.1. ¿Cuál de los siguientes tipos están incluidos como tipos MIME estándar?
a) Imagen.
b) Texto.
c) Audio.
d) Todos los anteriores.
11.2. ¿Qué nuevas características aporta el protocolo IPv6 frente a IPv4?

a) Ofrece soporte para el tráfico de datos en tiempo real.
b) Mejora la seguridad de la transmisión.
c) Posibilita realizar comunicaciones multidestino.

d) Todas las anteriores.
11.3. ¿Cuál de las siguientes no es una tecnología de streaming?

a) WindowsMedia
b) JavaScript
c) QuickTime
d) RealMedia
11.4. ¿Cuál de las siguientes no se puede considerar una extensión del nave-
gador?
a) Document Object Model (DOM).
b) Plugins.
c) Applets.
d) Aplicaciones auxiliares independientes asociadas al navegador.
11.5. ¿Cuál de las siguientes afirmaciones es verdadera en referencia a siste-

mas hipermedia?
a) Un determinado minuto de un vídeo puede ser ancla destino de un
enlace.
b) Un determinado minuto de un fichero de audio puede ser ancla des-
tino de un enlace.
c) Un determinado fragmento de contenido de un fichero html puede
ser ancla destino de un determinado enlace.
d) A un determinado fragmento de contenido no se puede acceder de
forma aletoria.

BAEZA-YATES y RIBEIRO-NETO (1999): R. Baeza-Yates y B. Ribeiro-Neto: Modern Infor-
mation Retrieval. ACM Press Series/Addison Wesley, New York.
CASTELLS (2001): M. Castells: La Galaxia Internet. Barcelona: Areté.
COMER (2000): D. Comer: Internetworking With TCP/IP Volume 1: Principles Proto-
cols, and Architecture, 4th edition, Prentice Hall.
DÍAZ, Catenazzi y Aedo (1996): P. Díaz, N. Catenazzi e I. Aedo: De la Multimedia a la
Hipermedia. Ra-Ma.
FLUCKIGER (1995): F. Fluckiger: Understanding Networked Multimedia. Prentice Hall.
FOOTE (1999): J. Foote: «An Overview of Audio Information Retrieval». Multimedia
Systems, 7(1): 2-11, ACM Press/Springer-Verlag.
FURTH (1999): B. Furht (editor). Handbook of Internet and Multimedia Systems and
Applications, CRC Press.
GAI (1998): S. Gai: Internetworking IPv6 with Cisco Routers. McGraw-Hill Computer
Communications Series.
GOODRUM (2000) A.A. Goodrum: «Image information retrieval: An overview of current
research». Informing Science, 3(2).
HALL, DAVIS y HUTCHINGS (1996): W. Hall, H. Davis y G. Hutchings: Rethinking Hyper-
media: The Microcosm Approach. Electronic Publishing Series, 4. Kluwer Acade-
mic Publishers.
SCHANK (1994): R.C. Schank: «Active Learning through Multimedia». IEEE Multime-
dia, 1(1): 69-78, IEEE Inc.
Capítulo 12
LENGUAJES DE PROGRAMACIÓN
PARA SISTEMAS MULTIMEDIA
ESQUEMA
12.1. Herramientas para la programación multimedia.

12.2. Uso de lenguajes de propósito específico.
12.3. Uso de lenguaje de propósito general.
12.4. Criterios de selección.
12.5. Resumen.
En la fase de implementación dentro del desarrollo de un sistema multi-
media, los desarrolladores deben seleccionar una o varias herramientas de
entre las existentes para la construcción del mismo. Actualmente existe una
gran variedad de opciones disponibles, que van desde el uso de una herra-
mienta de autoría que no requiera conocimientos técnicos de programación
—como puede ser el caso de las herramientas Flash de Macromedia—, hasta
el uso de un lenguaje de programación de propósito general —como Java o
C#—, pasando por opciones intermedias en las cuales se combinen varios
tipos de herramientas. En la actualidad, también es frecuente encontrar equi-
pos de desarrollo pluri-disciplinares, que cuentan con dos perfiles diferentes,
el de diseñador o creador de contenidos y el de programador. Los primeros,
que habitualmente no son programadores, suelen utilizar herramientas de
autoría para la creación gráfica y la composición de animaciones. Los segun-
dos son los encargados de integrar esos contenidos en la plataforma infor-
mática correspondiente.
En este capítulo se describen los rasgos generales de las opciones existen-
tes y algunos criterios de selección, y se profundiza en el concepto de lengua-
je de programación específico para los sistemas multimedia, tomando como
caso concreto el del lenguaje ActionScript. También se ilustra el uso de len-
guajes de programación de propósito general con una visión panorámica de
las bibliotecas que el lenguaje Java proporciona para el desarrollo de funcio-
nalidades multimedia.
12.1. HERRAMIENTAS PARA LA PROGRAMACIÓN

MULTIMEDIA
La construcción de un sistema multimedia una vez diseñado pasa por la

elección y el uso de herramientas informáticas. Esta selección dependerá de
la complejidad del sistema que se quiere diseñar, y de las funcionalidades
requeridas. Se puede considerar en primer lugar dos opciones:
• Utilizar una herramienta de autoría multimedia con soporte explícito
para la edición de los contenidos multimedia y su sincronización.
• Utilizar lenguajes de programación de propósito general — como pue-

de ser Java o C# — utilizando las bibliotecas de programación adecua-
das. Por ejemplo, en Java pueden utilizarse las bibliotecas Java2D o
Java3D para el propósito específico del manejo de imágenes u objetos
tridimensionales, respectivamente.
La primera de las opciones requiere del conocimiento de la herramienta

concreta, que tendrá un paradigma de autoría determinado. En el segundo
caso, se utilizarán entornos de programación no específicos para la multime-
dia, lo cual hace más laborioso y complicada la construcción de la aplicación,
ya que esos entornos no cuentan con herramientas visuales de manipulación
y sincronización de diferentes medios.
Este capítulo se centra en el uso de lenguajes de programación y no de

herramientas de autoría específicas, ya que éstas últimas serán tratadas en el
Capítulo 13. Dentro de estos lenguajes, se tienen que diferenciar dos catego-
rías claramente diferenciadas:
• Lenguajes de propósito general, con bibliotecas para multimedia.
• Lenguajes de propósito específico, especialmente diseñados para laos

sistemas multimedia.
Los lenguajes de propósito específico, en la mayoría de los casos, se utili-

zan dentro de herramientas de autoría, para complementar las funcionalida-
des de edición generales con la potencia de un lenguaje de programación. Tal
es el caso del lenguaje Lingo, que se utiliza dentro de la herramienta de auto-
ría Director de Macromedia.
DEFINICIÓN: Tipos de lenguajes para la programación multimedia.
• Los lenguajes de programación pueden clasificarse en dos categorías básicas res-

pecto a sus capacidades para la programación multimedia. Por un lado, existen
lenguajes de propósito general, como Java o C#, que proporcionan bibliotecas
para la manipulación de multimedia. En segundo lugar, existen lenguajes de pro-
pósito específico en los cuales el soporte de multimedia forma parte de la propia
definición básica del lenguaje. Estos últimos normalmente están integrados en
herramientas de autoría y permiten una mayor productividad al estar directamente
integrados en ellos muchos conceptos multimedia.
A continuación, se describen brevemente dos posibles opciones de las

muchas existentes, como ejemplos ilustrativos de la variedad de herramien-
tas disponibles. Concretamente, se va a tratar primero el lenguaje de propó-
sito específico ActionScript que se integra en las herramientas Flash de
Macromedia, para pasar a continuación a describir las facilidades que ofrece
el lenguaje de programación Java en lo relativo a los sistemas multimedia.
LENGUAJES DE PROGRAMACIÓN PARA SISTEMAS MULTIMEDIA 335
12.2. USO DE LENGUAJES DE PROPÓSITO ESPECÍFICO
El formato de animaciones denominado Flash ha constituido uno de los éxi-

tos más recientes en la historia de Internet. La idea de este formato es la de codi-
ficar animaciones multimedia interactivas y potencialmente complejas para su
distribución eficiente a través de la Web, de modo que los navegadores «entien-
dan» este formato a través de una extensión (plugin). El fabricante Macromedia
creó la herramienta de diseño multimedia Flash tras comprar la compañía Futu-
reWave en el año 1996. Desde entonces, se han sucedido las versiones de la
herramienta, y han aparecido otras de diferentes fabricantes que generan el mis-
mo formato de animaciones. Estudios recientes estiman que más de 500 millo-
nes de usuarios en el mundo son hoy usuarios de animaciones Flash.
El formato Flash es hoy un formato binario abierto1 denominado SWF opti-
mizado para su descarga a través de la Web. ActionScript es el lenguaje de progra-
mación interpretado que utilizan las herramientas Flash para controlar los ele-
mentos que componen las animaciones, y permitir introducir interactividad en las
mismas, de modo que la animación pueda responder a las acciones del usuario.
En esta sección se describen algunos casos específicos de programación
multimedia que pueden realizarse con este lenguaje. Lógicamente, los ele-
mentos tratados en esta sección cubre sólo una pequeña parte de las posibili-
dades del lenguaje; para una descripción más amplia puede consultarse algu-
nos de los manuales existentes, como por ejemplo (Moock, 2001).
El lenguaje ActionScript tiene una sintaxis muy similar al lenguaje JavaS-
cript que utilizan algunos navegadores de la Web. De hecho, ambos lenguajes
tienen hoy una base común, que es la que se describe en la especificación
estándar ECMA-262 (Schulzrinne y otros, 1996).
ActionScript es un lenguaje basado en objetos, de modo que las animacio-
nes y los elementos que conforman las mismas son objetos, que tienen propie-
dades y métodos. Las propiedades y métodos de un objeto vienen determinadas
por la clase a la que pertenece. Así, toda película en Flash es un objeto que per-
tenece a la clase MovieClip. Si se coloca un botón en un fotograma de una pelí-
cula, ese botón será un objeto que pertenezca a la clase PushButton, tendrá pro-
piedades tales como label, que representa el texto que muestra el botón, y
métodos como getLabel() que permiten recuperar esa etiqueta.
Así, los elementos de una animación Flash se exponen como objetos. Por
ejemplo, si se tiene la línea de tiempo con un número de fotogramas mostra-
da en la figura 12.1.
Se puede incluir un dibujo de un óvalo coloreado con las herramientas
de dibujo. Ahora bien, para poder manipular el óvalo como objeto desde
1
http://www.openswf.org/.
FIGURA 12.1. Línea de tiempo con número de fotogramas en Flash.
ActionScript se tiene que convertir en instancia de un símbolo. Así, se puede

convertir el óvalo dibujado en símbolo utilizando la opción «convertir en sím-
bolo» del menú contextual del óvalo, tal y como se muestra en la figura 12.2.
FIGURA 12.2. Cuadro de diálogo para convertir un dibujo en símbolo utilizando Flash.
De este modo, nuestra figura se convierte en un elemento (o clase) de la

biblioteca, de manera que se pueden colocar las instancias de la misma que
interesen (figura 12.3).
FIGURA 12.3. Biblioteca de símbolos de Flash.
Así, como muestra la figura 12.4. se coloca una instancia denominada

ovalo1 en el primer fotograma de la primera capa.
FIGURA 12.4. Inclusión de un fotograma en Flash.
En este momento, se pueden asociar acciones en ActionScript a ese ele-

mento para conseguir efectos de animación. Como ovalo1 es de tipo «Clip de
película», es posible asociarle eventos mediante onClipEvent (figura 12.5),
que toma como parámetro el tipo de evento de entre una serie de eventos
posibles (load, unload, enterFrame, mouseDown, etc.). Si se utiliza el evento
load, se ejecutará el manejador cuando se «carge» nuestro ovalo1, es decir,
cuando se llegue al fotograma en que aparece. Dentro de ese manejador de
evento de carga, se puede asociar al evento enterFrame de ovalo1 una función
Bajar. Esta asociación hace que cada vez que el objeto ovalo1 cambie de foto-
grama, se ejecute el código asociado.
FIGURA 12.5. Asociación de eventos a un tipo «Clip de película» en Flash.
El código de Bajar accede a las propiedades de ovalo1 mediante la refe-

rencia implícita this, y se limita a modificar la posición vertical del objeto,
modificando la propiedad predefinida _y (en ActionScript los objetos y pro-
piedades predefinidos van precedidos de un subrayado). La llamada a la fun-
ción predefinida trace permite mostrar mensajes en una ventana de texto
preparada para la depuración de las animaciones. De esta manera, se ha con-
seguido el efecto de una animación en la cual el óvalo se desplaza por la pan-
talla hacia abajo según van transcurriendo los fotogramas.
También se puede asociar comportamiento a botones. Por ejemplo, se va
a colocar en el primer fotograma de la primera capa de una nueva animación
dos botones, a los que se llamaran boton1 y boton2 respectivamente, como se
muestra en la figura 12.6.
Si se selecciona el primer botón, se puede escribir código asociado al mis-
mo. Por ejemplo, se puede definir qué se debe hacer cuando se presiona el
botón mediante el código que se muestra en la figura 12.7.
En ese código se ve un comentario (precedido de doble barra), el uso de
una variable denominada texto, y el acceso a los botones por su nombre, a
partir de _root, que es un objeto que designa a la película como un todo. Ade-
más, se ven las invocaciones a setLabel() y getLabel() sobre los botones.
FIGURA 12.6. Colocación de dos botones como primer fotograma de una nueva
animación Flash.
FIGURA 12.7. Ejemplo de código asociado al evento de presionar un botón.
Como se ve, existe una estructura de objetos definidos implícitamente para

acceder a los elementos de la presentación, de igual modo que en el JavaScript
de los navegadores se tienen los objetos implícitos window y document a par-
tir de los cuales se puede manipular la ventana del navegador y el documento
HTML actual, respectivamente.
DEFINICIÓN: Estructura general de Actionscript.

• ActionScript es un lenguaje sintácticamente igual a JavaScript, que se integra
en herramientas de composición multimedia. En ActionScript las animaciones y
los objetos que se colocan en ellas son instancias de clases determinadas, a las
cuales se pueden asociar eventos. Para modificar las propiedades o invocar a
métodos de las instancias, se utiliza la «notación punto» habitual en progra-
mación orientada a objetos, y se accede a los elementos a partir de instancias
predefinidas. Por ejemplo, _root, que representa a la presentación Flash como
un todo.
12.3. USO DE LENGUAJES DE PROPÓSITO GENERAL
Todo lenguajes de programación de propósito general permite extender

sus funcionalidades mediante la adición de bibliotecas de algún tipo. En los
lenguajes de programación orientados a objetos, estas bibliotecas suelen
denominarse marcos (frameworks) de clases. Los marcos son de propósito
específico, es decir, vienen a complementar el lenguaje con funcionalidades
de un dominio concreto. El conjunto de los métodos públicos de las clases
expuestas en esos marcos conforma una interfaz de programación o API
(Application Programmer Interface).
El conjunto de bibliotecas de Java que tratan de facilitar la programación
de aplicaciones multimedia se agrupan bajo la denominación común de
«Java Media APIs», e incluyen, entre otros, a los siguientes marcos de clases:
1. Java2D. Proporciona soporte avanzado para imágenes y gráficos bidi-
mensionales. Permite combinar imágenes con texto y con dibujo a
mano alzada («line art»). Permite componer imágenes, tratar su opa-
cidad (canales alfa) y manipulación del color y aplicación de filtros
para la manipulación de imágenes.
2. Java3D. Permite la manipulación y visualización de objetos tridimen-
sionales, incluyendo soporte para la especificación VRML.
3. Advanced Imaging. Este marco facilita el procesamiento de imágenes a
través de la red, incluyendo el recorte, aumento de contraste, cambio de
dimensiones o aplicación manipulación del dominio de las frecuencias.
4. Java Media Framework (JMF). Estas bibliotecas permiten la captura y
reproducción —incluyendo el streamming— de tipos de datos conti-
nuos como el sonido o el vídeo. Incluye soporte para los protocolos
RTP/RTSP (real time – streaming – protocol) que permiten la integra-
ción con servidores multimedia comerciales basados en ellos.
5. Shared Data Toolkit. Esta biblioteca permite integrar el resto de las
bibliotecas multimedia de Java en aplicaciones orientadas a la colabo-
ración en red, como pueden ser pizarras electrónicas, chats interacti-
vos o presentaciones remotas.
6. Sound. Proporciona soporte de bajo nivel para operaciones de audio
como la grabación, reproducción, mezcla y secuenciación y síntesis
MIDI.
7. Speech. Estas bibliotecas (actualmente aún en desarrollo) permiten la
integración de reconocimiento y síntesis de voz.
Las bibliotecas que se acaban de mencionar conforman una extensa
interfaz para la programación multimedia, que no está incluida en la distri-
bución estándar del compilador de Java (el conocido como JDK – Java Deve-
lopment Kit). A continuación, se van a tratar los aspectos fundamentales de

JMF como ilustración de las posibilidades que ofrece el lenguaje, no sin antes
proporcionar una visión del soporte original, básico, de multimedia que pro-
porcionaban las primeras versiones de Java. Esto permitirá apreciar la dife-
rencia entre el soporte rudimentario original y las capacidades actuales, con
el objetivo de tener ciertas nociones que permitan discernir si un lenguaje de
programación de propósito general determinado proporciona un soporte
«básico» o «avanzado» para la programación multimedia.
DEFINICIÓN: Soporte multimedia en Java.

• El lenguaje de programación Java proporciona bibliotecas de clases específicas
para la programación multimedia. Además de algunas clases de soporte básico en
el entorno de desarrollo, proporciona una serie de bibliotecas especializadas bajo
el nombre común de «Java Media APIs».
12.3.1. Soporte básico de Java para animaciones y sonido
El JDK no proporciona un soporte integrado como el de las herramientas

Flash para desarrollar animaciones. Sin embargo, se pueden crear animacio-
nes en interfaces gráficas utilizando técnicas de movimiento de imágenes
controladas por programa. Si la rotación de imágenes se produce a una velo-
cidad superior a 10 cambios por segundo, los usuarios la percibirán como
animación en lugar de cómo sustitución de imágenes. Suponiendo que se
cuenta con una secuencia de imágenes apropiada para la animación, se pue-
de crear un applet que muestre la animación creando un hilo de ejecución
independiente (Thread). Este hilo de ejecución será el encargado de cambiar
las imágenes, quedando el hilo general del applet libre para otras tareas que
pudiesen tener que realizarse (como, por ejemplo, responder a las entradas
del usuario).
Un ejemplo con las imágenes GIF que se muestran en la figura 12.8. Cada
imagen conformará un marco (frame) de la animación resultante, que estará
contenida en un applet.
FIGURA 12.8. Secuencia de imágenes para producir un efecto de animación.

El applet se cargará desde la correspondiente página HTML, y en este

caso, la velocidad en marcos por segundo de la animación se especificará
como parámetro en la figura 9.
<html>
<head></head>
<body>
<applet code="Animacion.class">
<param name="fps" value="10">
</applet>
</body>
</html>
Figura 12.9. Velocidad en marcos por segundo de la animación.
El código del applet será el de la figura 12.10.

En ese código se ve cómo al iniciarse el applet (método init()), se toma
el parámetro de velocidad de animación, y se cargan en un array las imáge-
nes que conforman la misma. Cuando comienza la ejecución del applet
(método start()) se crea un nuevo hilo de ejecución asociado a la propia ins-
tancia del applet. De este modo, ese hilo de ejecución comenzará a ejecutar el
método run() en la misma clase (nótese que Thread requiere que el objeto al
que se le asocia tenga un método run() implementado, como consecuencia
de la implementación de la interfaz Runnable).
El hilo de ejecución invocará a repaint(), que, en la mayoría de los casos
(a menos que el número de llamadas a repaint() sea tan alto que no deje
tiempo al applet a hacer las correspondientes invocaciones), hará que el
applet invoque a su vez implícitamente al método paint(). Éste último se
encarga de dibujar la imagen que está indicada por el índice frame, que avan-
za en cada iteración dentro del método run(). Nótese que, a pesar de que el
código toma la hora actual del sistema, para hacer más precisa la temporiza-
ción, ésta nunca es completamente exacta, ya que la máquina virtual puede
tener otros hilos en ejecución, que hacen que el tiempo indicado a sleep() no
coincida con el tiempo de cambio de la imagen.
Tal y como está programado el ejemplo, en algunos sistemas operativos y
para velocidades altas, se producirá un efecto de «interferencias» o «flash»
(flickering) que dificulta la visualización. El problema reside en que el proce-
so de dibujar cada marco es largo, y además, antes de dibujar el siguiente, se
«limpia» el anterior. Este segundo problema puede eliminarse redefiniendo el
método update(), que es el que se invoca cuando se necesita «repintar». Por
defecto, éste método borra el área de visualización, y después invoca a
paint(). Se puede evitar el borrado redefiniéndolo como en la figura 12.11.
import java.awt.*;
public
class Animacion extends java.applet.Applet implements Runnable {
Image frames[];
int frame;
int retardo;
Thread animador;
/**
* Inicializamos el applet tomando como parametro
* la velocidad en frames por segundo (fps).
*/
String str = getParameter("fps");
int fps = (str != null) ? Integer.parseInt(str) : 10;
retardo = (fps > 0) ? (1000 / fps) : 100;
// Cargamos las imagenes:
frames = new Image[5];
for (int i = 0 ; i < 5 ; i++) {
frames[i] = getImage(getCodeBase(), "bufalo" + i + ".gif");
}
/**
* Cuando el applet aparece, creamos un hilo de ejecución
* para animar las imagenes.
*/
animador = new Thread(this);
animador.start();
}
/**
* Método que ejecuta el hilo de ejecución 'animador'.
*/
public void run() {
long inicio = System.currentTimeMillis();
while (animador!=null) {
// Mostramos la siguiente imagen:
repaint();
// "dormimos" el tiempo restante.
try {
inicio += retardo;
Thread.sleep(Math.max(0, inicio -
System.currentTimeMillis()));
} catch (InterruptedException e) { break; }
// Pasamos a la siguiente imagen:
frame++; if (frame ==5) frame = 0;
}
}
/**
* Cuando el applet no es visible, perdemos la referencia
* al hilo, haciendo que la animación pare.
*/
animador = null;
}
/**
* Dibuja un frame de la animación.
*/
public void paint(Graphics g) {
g.drawImage(frames[frame], 0, 0, null);
}
}
FIGURA 12.10. Código del applet de velocidad en marcos por segundo de la animación.
public void update(Graphics g){
paint(g);
FIGURA 12.11. Evitar el borrado.
Otro método para hacer más suave la visualización es el «buffer doble».

Este método consiste en crear una imagen sin visualizarla, dibujar el mar-
co en ella, y una vez que esté preparada, se copia al contexto de visualiza-
ción de una sola vez, de modo que el dibujo de la imagen se ha hecho «offli-
ne», siendo esta operación más eficiente que la de hacerlo directamente en
la pantalla.
Además del tipo de animación que se acaba de ver, también pueden crear-
se sprites en Java, que son objetos que se mueven por el área de visualización,
y que tienen un fondo transparente. Igual que en el ejemplo que se acaba de
ver, el control del movimiento se hace de manera explícita mediante el códi-
go Java, pudiendo incorporar detección de colisiones o superposición de spri-
tes, añadiendo la lógica apropiada.
Un problema adicional relacionado con el dibujo de imágenes es que en
ocasiones, Java comienza a dibujar la imagen en pantalla antes de que la ima-
gen se haya cargado (o «descargado» en el caso de Internet), produciendo un
efecto de visualización incompleta. Aunque este efecto puede ser deseable en
algunas situaciones, en el caso de las animaciones es mejor esperar a que las
imágenes estén completamente disponibles antes de comenzar. Para ello, se
puede utilizar la clase java.awt.MediaTracker, que permite cargar imágenes
antes de la visualización, y monitorizar su estado, para evitar mostrarlas
antes de que estén completamente cargadas (con el método checkID).
Desde sus primeras versiones, el JDK proporcionaba soporte para la
reproducción de sonido mediante la interfaz java.applet.AudioClip, que
proporciona los métodos autodescriptivos play(), stop() y loop(). Esta
interfaz permitía en sus primeras versiones la reproducción de sonidos en
formato .au, proporcionando sonido mono de 8 bits y hasta 8000 Hz. A par-
tir de la versión 1.2 del JDK, el soporte del motor de audio se expande a los
formatos: MIDI (tipos 0 y 1), RMF, WAVE y AIFF.
A continuación se muestra el código de un simple applet que carga un fiche-
ro WAV y muestra tres botones con la disposición mostrada en la figura 12.12.
import java.applet.*;
import java.awt.*;
import java.awt.event.*;
public class AudioApplet extends Applet {
Button play;
Button stop;
Button loop;
AudioClip clip;
public void init()

{
play=new Button("Play");
stop=new Button("Stop");
loop=new Button("Loop");
// Asociamos los manejadores de eventos a los botones:

play.addActionListener(new EventosBoton());
stop.addActionListener(new EventosBoton());
loop.addActionListener(new EventosBoton());
//Incluimos los botones en el applet:
add(play);
add(stop);
add(loop);
//Inicializamos el clip de audio

clip=getAudioClip(getCodeBase(),"diudeno.wav");
}
public void stop()

{
clip.stop();
}
public void destroy()

{
clip.stop();
}
// Clase "interna" con los manejadores:
class EventosBoton implements ActionListener
{
public void actionPerformed(ActionEvent e)
{
String action=e.getActionCommand();
if(action.equals("Play"))
clip.play();
else if(action.equals("Stop"))
clip.stop();
else if(action.equals("Loop"))
clip.loop();
}
}
}
FIGURA 12.12. Apariencia de un ejemplo sobre applets.
Nótese que la instancia de AudioClip se obtiene a partir del propio con-

texto del applet, indicando como directorio el directorio en el que reside el
propio código del applet. Las interfaces «Sound» mencionadas anteriormen-
te como parte de los Java Media APIs no son otra cosa que una interfaz com-
pleta para la manipulación del mismo motor de sonido de Java que utiliza la
sencilla interfaz AudioClip.
DEFINICIÓN: Soporte básico de multimedia en el JDK.

El entorno de desarrollo básico de Java permite el desarrollo de aplicaciones multime-
dia, realizando un control explícito de las animaciones y/o sincronizaciones a través del
programa. Para ello, es necesario crear hilos de ejecución (clase Thread) para cada una
de las tareas multimedia concurrentes, y utilizar las clases que proporciona Java para
cargar imágenes, sonido o dibujar gráficos.
12.3.2. Conceptos fundamentales de Java Media Framework

(JMF)
Java Media Framework (JMF) es conjunto de interfaces de programación
en Java orientado a la incorporación de medios continuos en las aplicacio-
nes y applets de Java. En su versión 1.0, proporcionaba soporte para la pre-
sentación de medios continuos, y en la versión 2.0 actual, añade funcionali-
dades de captura, almacenamiento y control del procesamiento de esos
medios.
En JMF el tipo del contenido es sinónimo de «tipo de fichero», por ejem-
plo, son tipos QuickTime, MPEG o AIFF. Los flujos multimedia (media stre-
am) son flujos de datos provenientes de disco, de una conexión de red, o de
un dispositivo de captura. Cada uno de estos flujos puede tener varios tracks
o canales (por ejemplo, uno de audio y uno de vídeo). Los flujos multimedia
son básicamente de dos tipos:
• Flujos pull, en los cuales la transmisión de los datos se inicia y contro-
la en el cliente. El protocolo HTTP o la carga de un fichero de disco per-
tenecen a esta categoría.
• Tipo push, en los cuales es el servidor el que controla el flujo de datos.
Un ejemplo es el protocolo RTP.
Los flujos multimedia pasan en muchos casos por ciertos tipos de proce-
samiento antes de llegar a la aplicación cliente. Estos procesamientos inclu-
yen la demultiplexión o separación de canales, la decodificación o descom-
presión de ciertos canales, la conversión de formato de algunos canales y
posiblemente, la aplicación de filtros para producir efectos determinados. Por
tanto, aparecen diferentes elementos que se pueden manipular, incluyendo los
multiplexores/demultiplexores, los codecs (compresores-descompresores de
canales), los filtros, los propios dispositivos de visualización y en ocasiones,

elementos para la combinación o sincronización de diferentes canales.
La arquitectura general de JMF es la que se muestra en la figura 12.13.
Básicamente, JMF proporciona un API de alto nivel que abstrae de las carac-
terísticas de los diferentes procesamientos que tienen lugar en las aplicacio-
nes multimedia (multiplexión, compresión, filtrado, multiplexión, dibujo o
renderización, etc.).
Aplicaciones y applets Java
APIs de presentación y procesamiento
API para Plug-Ins
demultipl. codecs filtros multiplx. renderiz.

FIGURA 12.13. Arquitectura general de JMF.
Los formatos soportados por JMF incluyen los siguientes tipos comu-
nes: AIFF, AU, AVI, GSM, MIDI, MPEG, QuickTime, RMF y WAV. Pueden
programarse procesadores de otros formatos, o especializaciones de los
existentes mediante el concepto de extensión mediante plugins que ofrece
JMF, figura 12.14.
DEFINICIÓN: Java media framework (JMF).

Las interfaces de JMF permiten desarrollar funcionalidades típicas de la manipulación de
medios continuos (vídeo, audio, animaciones, etc.), incluyendo la carga o captura, el
procesamiento y la reproducción o grabación. JMF soporta una serie de formatos o tipos
de datos, y permite crear extensiones para soportar otros diferentes.
El API JMF consta fundamentalmente de interfaces para la captura, pro-

cesamiento y reproducción de flujos multimedia. Para ello, utiliza el concep-
to de gestor (manager), con las siguientes categorías:
1. La interfaz Manager se encarga de la creación de otros gestores con-
cretos como Players, Processors, DataSources y DataSinks. Así, para
crear reproductores o procesadores, hay que invocar a los métodos

make() de la interfaz Manager.
2. PackageManager, que mantiene el registro de las clases gestoras JMF

disponibles en una determinada instalación (es decir, Players, Pro -
cessors, etc.).
3. CaptureDeviceManager que mantiene el registro de los dispositivos de

captura disponibles.
4. PlugInManager que mantiene un registro de plugins JMF, tales como
Multiplexers, Demultiplexers, Codecs, Effects, and Renderers.
FIGURA 12.14. La aplicación de registro JMF.
Los gestores disponibles en una determinada instalación de JMF pueden

manipularse —además de a través de las interfaces mencionadas— mediante
la aplicación «JMF Registry Editor» proporcionada con JMF. En la figura
14puede verse su estructura general, y la descripción de un multiplexor para
formato QuickTime.
Una aplicación de reproducción de un flujo multimedia constará básica-
mente de un objeto que implemente la interfaz Player y otro que implemen-
te DataSource.
El código básico para realizar una reproducción dentro de un applet es el
de la figura 12.15.
import java.applet.*;
import java.awt.*;
import java.net.*;
import javax.media.*;
public class PlayerApplet extends Applet implements
ControllerListener {
Player player = null;
setLayout(new BorderLayout());
String fichero = getParameter("FICHERO");
try {
URL mediaURL = new URL(getDocumentBase(), fichero);
player = Manager.createPlayer(mediaURL);
player.addControllerListener(this);
}
catch (Exception e) {
System.err.println(e);
}
}
player.start();
}
player.stop();
player.deallocate();
}
public void destroy() {
player.close();
}
public synchronized void controllerUpdate(ControllerEvent event)
{
if (event instanceof RealizeCompleteEvent) {
Component comp;
if ((comp = player.getVisualComponent()) != null)
add ("Center", comp);
if ((comp = player.getControlPanelComponent()) != null) •
add ("South", comp);
validate();
}
}
}
FIGURA 12.15. Código básico para realizar una reproducción dentro de un applet.
En el código de la figura 12.15 se puede comprobar cómo se solicita un

reproductor a la clase Manager, que seleccionará el reproductor adecuado de
acuerdo al tipo MIME del fichero que se ha indicado como parámetro del
applet. El Player pasa por una serie de estados de los cuales se puede obtener
notificación:
• «No realizado» cuando el reproductor aún no «conoce» nada sobre el
flujo que debe procesar.
• «Realizándose» cuando el reproductor está en el proceso de adquirir

los recursos que necesita para el procesamiento del flujo.
• «Realizado» cuando el reproductor conoce el medio que debe procesar
y tiene los recursos necesarios para hacerlo. Es en este momento cuan-
do puede mostrar los recursos de visualización propios del medio (pan-
talla, panel de control, etc.).
• «Precargando» cuando el reproductor se está preparando para comenzar a
mostrar su flujo de datos, cargando los datos propiamente dichos y adqui-
riendo los recursos de reproducción necesarios para cada tipo de datos.
• «Precargado» cuando está preparado para mostrar su flujo de datos.
• «Comenzado» cuando el reloj que mide el tiempo de la reproducción ya
ha comenzado a funcionar.
Así, cuando se recibe la notificación de que el flujo está «realizado», se
colocan el componente visual y el panel de control en las partes «centro» y
«sur» del gestor de posición del applet. La figura 12.16 muestra la configura-
ción resultante, con el panel de control abierto.
En la figura 16 se ve la velocidad y otros datos de los canales del vídeo, así
como la configuración de plugins que se han puesto en funcionamiento para
ver el vídeo AVI. Se tienen dos canales de salida (DirectDraw y DirectSound),
y el canal de la imagen utiliza el decodificador de Cinepak.
La sincronización de dos o más Players puede realizarse gracias a que
todos ellos implícitamente tienen un reloj (definido por la super-interfaz
Clock). Así, se pueden sincronizar las líneas de tiempo de dos reproductores
mediante la invocación:
player1.setTimeBase(player2.getTimeBase());
También se pueden realizar sincronizaciones más complejas, haciendo

que uno de los reproductores actúe como controlador de los demás.
DEFINICIÓN: Reproducción de flujos multimedia en JMF.

• A través de la clase Manager, se pueden obtener reproductores (Players) para dife-
rentes tipos de datos multimedia. Estos reproductores generan eventos que permi-
ten controlar por programa el estado de preparación y carga del flujo. Además,
JMF incorpora en estos reproductores un mecanismo para el control temporal que
permite construir sincronizaciones entre flujos multimedia.
Una de las características importantes que ofrece JMF es la posibilidad de

incorporar flujos multimedia en tiempo real. Para ello, soporta el protocolo
Real Time Transport Protocol (RTP). Esto permite que el cliente pueda comen-
zar a mostrar el flujo sin que éste se haya descargado completamente del ser-
FIGURA 12.16. Ejecución del applet reproductor de medios.
vidor. RTP permite flujos unicast o multicast, y suele superponerse al proto-

colo de transporte UDP, que proporciona menos sobrecarga de procesamien-
to que TCP (aunque, lógicamente, no garantiza la recepción de todos los
paquetes de datos). La figura 12.17 muestra la arquitectura de RTP, donde
cabe apreciar que existe otro protocolo denominado Real-Time Control Proto-
col (RTCP) que permite la monitorización de la calidad del servicio de RTP
subyacente, entre otras funciones de control.
RTP proporciona funciones para la identificación del tipo de datos que se
transmiten, para la secuenciación de los paquetes de datos, y también para la
FIGURA 12.17. Estructura en capas del protocolo RTP.
sincronización de flujos multimedia de diferentes fuentes. En RTP, las sesio-

nes son asociaciones de un conjunto de aplicaciones (participantes) que se
están comunicando mediante RTP, es decir, que actúan como emisores,
receptores o ambos. De este modo, el protocolo proporciona soporte para
aplicaciones de conferencia virtual compartida por muchos usuarios.
JMF proporciona dos plugins para la paquetización y reconstrucción de flu-

jos RTP. Por tanto, los reproductores RTP pueden utilizarse de igual manera
que con otros tipos de flujos de datos. Para construir un reproductor RTP, es
necesario utilizar un objeto MediaLocator para especificar la dirección de la
sesión RTP, como muestra el siguiente fragmento de código en la figura 12.18.
String url= "rtp://www.mediaserver.com/vídeo/3";

MediaLocator mrl= new MediaLocator(url);
if (mrl == null) {
System.err.println("Error en la construcción del localizador
RTP");
return false;
}
// Creamos el reproductor:
try {
player = Manager.createPlayer(mrl);
} catch (NoPlayerException e) {
return false;
} catch (MalformedURLException e) {
return false;
} catch (IOException e) {
return false;
}
FIGURA 12.18. Construcción de un reproductor RTP.

Este código causará la conexión al primer flujo RTP encontrado dentro de

la sesión indicada. Cuando se detecten datos en la sesión, el reproductor
pasará al estado de «realizado», permitiendo comenzar la visualización de la
reproducción.
DEFINICIÓN: Streamming multimedia distribuido en JMF.

JMF proporciona soporte para el protocolo de distribución mediante streaming RTP.
El tratamiento de los flujos RTP es similar al de otros tipos de flujo multimedia.
Además de las funcionalidades vistas en esta sección, JMF proporciona

interfaces para la captura de flujos multimedia, para el procesamiento pre-
vio a la reproducción, y para el control exhaustivo de flujos RTP mediante
RTCP.
12.4. CRITERIOS DE SELECCIÓN
La selección de las herramientas es un paso muy importante, previo a

la fase de implementación de la aplicación multimedia. Esta es una decisión
más de Ingeniería del Software que implica un estudio previo de las opcio-
nes disponibles en el momento determinado, teniendo en cuenta las opciones
existentes en el mercado, así como las opciones de software de libre dis-
tribución.
Los criterios de selección de la herramienta pueden a grandes rasgos
resumirse en los siguientes puntos a considerar:
1. La capacitación y perfil del equipo de desarrollo condicionan el uso de
unas u otras herramientas.
2. El calendario del proyecto. Hay que tener en cuenta que las herra-
mientas de autoría proporcionan una mayor productividad para la
mayoría de los desarrollos.
3. El tercer factor, como en toda decisión de ingeniería, es el coste de la
decisión tomada, tanto en términos de licencias de desarrollo y pro-
ducción, como, en su caso, de costes de formación para el equipo de
desarrollo.
4. Por último, pero no menos importante, hay que tener en cuenta las
funcionalidades requeridas a la aplicación, así como la arquitectura
hardware y software en la que deberá implantarse. Estos requisitos
funcionales y no funcionales lógicamente limitan el abanico de herra-
mientas adecuadas a cada desarrollo concreto.
Además de los criterios mencionados, en ocasiones es necesario conside-

rar también la compatibilidad con estándares existentes, que suele ser impor-
tante para la futura interoperabilidad entre aplicaciones.
12.5. RESUMEN
Desde el punto de vista de la Ingeniería del Software, se pueden conside-

rar dos opciones fundamentales para la selección de los lenguajes de progra-
mación para una aplicación multimedia. En primer lugar, los lenguajes de
programación específicos para los sistemas multimedia proporcionan opera-
ciones y objetos especialmente preparados para la manipulación y sincroni-
zación de elementos de diferentes tipos, habitualmente integrados dentro de
un entorno visual de autoría. En segundo lugar, algunos lenguajes conven-
cionales permiten la adición de bibliotecas específicas para la manipulación
de elementos multimedia, programando explícitamente las funciones de inte-
gración y sincronización de elementos de diferentes tipos.
El lenguaje ActionScript se integra en entornos de composición de ani-
maciones como las herramientas Flash de Macromedia, y permite asociar
eventos a los diferentes elementos que conforman la presentación. Así, esos
elementos son instancias de clases que tienen propiedades y métodos, y la
manipulación de las propiedades o la invocación de los métodos se realizan
mediante la notación punto habitual en programación orientada a objetos.
El lenguaje de propósito general orientado a objetos Java cuenta con
bibliotecas básicas para la manipulación de imágenes y dibujos, así como para
la reproducción de sonidos. El programador es responsable de diseñar las
interacciones entre los elementos mediante hilos de ejecución independientes.
Además, una colección de interfaces de programación bajo la denominación
de «Java Media APIs» permite manipulaciones más avanzadas, incluyendo la
compatibilidad con protocolos de difusión multimedia actuales como RTP.
12.1. ¿Cuál de las siguientes afirmaciones respecto a ActionScript es falsa?

a) ActionScript es un lenguaje orientado a objetos.
b) ActionScript es un lenguaje de propósito general.
c) Las herramientas Flash utilizan ActionScript para controlar las ani-
maciones.
d) ActionScript permite introducir interactividad entre el usuario y la
animación.
12.2. La biblioteca que permite integrar el resto de las bibliotecas multime-

dia de Java en aplicaciones orientadas a la colaboración en red, como
pueden ser pizarras electrónicas, chats interactivos o presentaciones
remotas, se llama:
a) Advanced imaging.
b) Shared data toolkit.
c) Speech.
d) Share Data Toolkit.
12.3. ¿Qué formato de los siguientes es soportado por JMF sin necesidad de
incorporar extensiones?
a) MIDI
b) EPS
c) GIF
d) NFG
12.4. ¿De que interfaces no consta el API JMF?

a) Interfaz de captura.
b) Interfaz de reproducción.
c) Interfaz de conversión de tablas de colores.
d) Interfaz de procesamiento.
12.5. El JDK se conoce como:

a) Multiplexación/Demultiplexación.
b) Empaquetado y reconstrucción de flujos.
c) Renderización.
d) Distribución estándar del compilador de Java.

MOOCK (2001): C. Moock «ActionScript: The Definitive Guide. Mastering Flash Pro-
gramming», O’Reilly.
SCHULZRINNE y otros (1996): Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.:
RTP: A Transport Protocol for Real-Time Applications (RFC 1889). Internet Engi-
neering Task Force. Disponible en http://www.ietf.org/rfc/rfc1889.txt. Consultado
en mayo de 2003.

Capítulo 13
HERRAMIENTAS DE AUTOR
ESQUEMA
13.1. ¿Qué es una herramienta de autor?

13.2. ToolBook II.
13.3. Dreamweaver.
13.4. Authorware.
13.5. La tecnología Flash.
13.6. Director.
13.7. Resumen.
13.9. Referencias bibliográficas
Si el análisis y el diseño de un producto multimedia son procesos com-
plejos, de los que ya se ha hablado en el capítulo 5 de este libro, la producción
tampoco es una labor sencilla ni meramente técnica. De hecho, para crear un
producto multimedia no sólo hacen falta programadores, sino que se requie-
ren diseñadores multimedia con un tipo de conocimiento y habilidades com-
pletamente distintos. Es más, en la mayoría de las ocasiones, las aplicaciones
multimedia son elaboradas por personas sin conocimientos de programación
o de lenguajes de marcado o modelado, pero que tienen la necesidad de utili-
zar esta tecnología como potente medio de transmisión de sus ideas. Junto a
esta situación, no hay que olvidar la vertiginosa y continua aparición de nue-
vas tecnologías en este campo, que hace difícil estar al día en técnicas de
implementación.
Por estas, entre otras razones, las herramientas de autor gozan cada día
de mayores adeptos. Este tipo de aplicaciones software ofrecen interfaces
sencillas y visuales, habitualmente de manipulación directa, con las que
generar un producto multimedia sin necesidad de programar. Al mismo tiem-
po, suelen incluir la posibilidad de programar e incluir servicios más com-
plejos, de manera que son útiles tanto para desarrolladores con conocimien-
tos técnicos como para aquellos que no los tienen. Además, al permitir crear
productos multimedia complejos en un tiempo muy reducido, se convierten
en candidatas ideales para utilizar técnicas como el prototipado rápido para
el análisis o el diseño de aplicaciones.
En este capítulo se analizarán las herramientas de autor para productos

multimedia. Obviamente, dado el ingente número de herramientas existentes
en el mercado, no se pretende elaborar un catálogo de la mismas, sino que se
ha optado por presentar algunas que se han considerado bastante represen-
tativas y difundidas. El capítulo se inicia con una breve introducción al con-
cepto de herramienta de autor, en el que se comentan clasificaciones de las
mismas, ya sea atendiendo al modelo de información o metáfora que asu-
men, ya sea atendiendo al paradigma de creación de aplicaciones que ofre-
cen. A continuación se describirán algunas herramientas de autor como son
ToolBook, Dreamweaver, Authorware, herramientas que soportan la tecnolo-
gía Flash o Director.
13.1. ¿QUÉ ES UNA HERRAMIENTA DE AUTOR?
Las herramientas de autor tienen la finalidad de servir de elemento de

escritura y de edición para los autores de aplicaciones interactivas multime-
dia. Estos autores son, en la mayoría de los casos, los propios desarrolladores
del sistema que se han reconvertido asumiendo tanto las labores propias de
la implementación como otras más creativas, necesarias para este nuevo tipo
de escritura y edición, en la que contenidos de naturaleza diversa se funden
formando un discurso multimedia.
DEFINICIÓN: Herramienta de autor.

• Aplicación o conjunto de aplicaciones que facilitan el desarrollo sin que sea nece-
sario tener conocimientos específicos de programación.
Las herramientas de autor proporcionan una gran variedad de servicios que

dependen del entorno en el que el autor trabaje y del tipo de aplicación que quie-
ra desarrollar. Desde el punto de vista de la interfaz, la utilización de lenguajes
visuales de comunicación, en los que la manipulación directa de objetos, las
cajas de diálogos y los menús desplegables son las formas más usuales para la
interacción persona-ordenador, es la fórmula más usada en este tipo de herra-
mientas, debido a que el autor puede ignorar aspectos de programación (por
ejemplo, reservar espacios de memoria para los punteros) que no son interesan-
tes para su cometido. Ésta es precisamente una de las principales ventajas de las
herramientas de autor, ya que al descargar a los autores de la carga que supone
utilizar un lenguaje de programación, modelado o marcado, le permiten centrar
sus esfuerzos en otros aspectos del diseño más relevantes, como por ejemplo la
aplicación de principios de diseño que incrementen la usabilidad.
Son muchas las características que tienen cumplir estas herramientas de
autor para que ayuden en el proceso de creación (Díaz y otros, 1996), pudién-
dose destacar las siguientes:
• Soporte a la edición y composición multimedia. En primer lugar,
una exigencia básica para todo entorno de autoría es la existencia de
mecanismos para preparar y manipular material multimedia. La tec-
nología no debe mermar las capacidades expresivas y creativas del
autor, sino que debe permitirle emplear imaginativamente la informa-
ción. Así, por ejemplo, el autor puede necesitar analizadores ortográfi-
cos para revisar sus escritos, editores de dibujo integrados para prepa-
rar sus gráficos y aplicaciones para manipular el material videográfico.
Las herramientas actuales generalmente incorporan estos mecanismos
facilitando la labor del autor.
• Soporte a la especificación de eventos. Además, estas herramientas
deben permitir el uso de contenidos de información que sean capaces
HERRAMIENTAS DE AUTOR 361
de reaccionar ante eventos, ya sean producidos desde el exterior (v.g., el

movimiento del ratón) o desde el interior (por ejemplo, un interlo de
tiempo desde el inicio de la sesión) del sistema interactivo.
• Soporte a la inclusión de metadatos y atributos. Otra característica
relevante a tener en cuenta es la posibilidad de asociar atributos o
metadatos a estos contenidos, ya sean semánticos o de interfaz, para
que el autor pueda controlar tanto su significado en el contexto como
su apariencia.
• Soporte a la especificación de la interacción. También las herra-
mientas de autor deben disponer de funciones con las que poder cons-
truir, de forma sencilla, mecanismos de ayuda para la interacción (por
ejemplo, mecanismos de navegación), así como comandos para la bús-
queda de información, ya sea por medio de cadenas de caracteres, de
consultas con un lenguaje de interrogación, o de algún mecanismo más
complejo, como podría ser la utilización de los metadatos anterior-
mente mencionados.
Normalmente, las herramientas de autor se clasifican de acuerdo al
modelo de información que utilizan, ya que habitualmente simulan un espa-
cio conocido por el autor y el lector, es decir, utilizan una metáfora como base
del desarrollo (sección 6.6). Al recrear un espacio conocido se suele facilitar
la labor del autor y del lector en el desarrollo y uso de la aplicación. En la
tabla 13.1 se muestran algunos ejemplos de metáforas asumidas en herra-
mientas de autor comerciales.
TABLA 13.1. Metáforas usadas en herramientas de autor

Herramienta Metáfora Significado
HyperCard Pila Una aplicación multimedia se define como una
pila de tarjetas.
Toolbook Libro Una aplicación multimedia se define como un
libro con páginas.
Director Película Una aplicación multimedia se define como un
escenario en el que participan unos actores
siguiendo un guión.
Por otro lado, las herramientas de autor también se pueden clasificar en

función de cómo se describe el comportamiento de los elementos de la apli-
cación (Väänänen, 95). Atendiendo a este criterio se puede distinguir entre:
• herramientas basadas en guiones (scripts), en las que el autor escri-
be guiones de comportamiento asociados a los contenidos con los que
interactúa el usuario (por ejemplo, ToolBook),
• herramientas basada en iconos, que son aquellas que ofrecen al

autor una serie de iconos para definir la secuencia de aparición de los
contenidos en la aplicación (por ejemplo, Authorware), y
• herramientas basadas en el tiempo, dentro de las que se enmarcan
aquellas herramientas que permiten construir sistemas basando el
desarrollo en una línea de tiempo sobre la que se sincronizan y alinean
los contenidos (por ejemplo, Macromedia Director).
A continuación, se introducen algunas de las herramientas de autor más
conocidas y utilizadas en el desarrollo de aplicaciones multimedia, como son:
ToolBook, Dreamweaver, Authorware, Flash y Director.
13.2. TOOLBOOK II
ToolBook II (Asymetrics, 2003) es una herramienta de desarrollo basada
en objetos que proporciona herramientas para la creación de éstos y un
potente lenguaje de programación, denominado OpenScript. Esta herra-
mienta hace posible crear aplicaciones multimedia interactivas con sofistica-
das interfaces de usuario, que incluyen elementos tales como ventanas,
menús y cajas de diálogos, sin necesidad de tener grandes conocimientos de
informática, de tal forma que desarrolladores no expertos pueden generar
sistemas potentes y útiles. Ejemplos de aplicaciones creadas con ToolBook
podrían ser:
• Aplicaciones hipermedia, tales como sistemas de documentación inte-
ractivos.
• Aplicaciones educativas interactivas, tales como tutoriales o puestos de
información.
• Aplicaciones de bases de datos, utilizando la interfaz como front-end.
• Juegos que usan elementos gráficos.
ToolBook se podrá utilizar como entorno interactivo para la creación y
ejecución de aplicaciones en un entorno Windows, encargándose de la comu-
nicación con el sistema operativo y de la gestión de los distintos objetos defi-
nidos sobre la pantalla, así como de la interacción con el usuario (por ejem-
plo, detectar si el ratón o una tecla se ha pulsado). En la siguiente figura se
puede ver un esquema de cómo funciona desde el punto de vista operativo
ToolBook.
De cara al autor, y tal y como se mecionó en el apartado anterior, ToolBo-
ok usa la metáfora de un libro como base del desarrollo de todas sus aplica-
ciones, lo que quiere decir que cualquier aplicación está formada por uno o
más ficheros denominados libros (Book). Al igual que un libro de papel, los
libros de ToolBook también están divididos en páginas (Pages), representan-
FIGURA 13.1. Funcionamiento de la herramienta ToolBook.
do cada una de ellas una ventana de una aplicación. Cada página contiene
campos (Fields), botones (Buttons) y gráficos (Graphics), y tanto a ellas como
a sus elementos se les denomina, en terminología ToolBook, objetos. Cada
página puede tener diferentes objetos, pudiendo además compartir algunos
con otras si se encuentran en la plantilla (Background). Los objetos que inclu-
ye ToolBooK son los siguientes:
• Libro (Book). Es un archivo que contiene al resto de los objetos, así
como la información contenida en ellos, por lo que se podría equiparar
con un sistema o subsistema.
• Plantilla (Background). Está formada por elementos que son comu-
nes a una serie de páginas. Un mismo libro puede tener varias planti-
llas, pero una plantilla pertenece a un único libro.
• Página (Page). Es el elemento que se visualiza en ToolBook. Una plan-
tilla puede contener varias páginas, pero una página pertenece a una
única plantilla.
• Visores (Viewers). Son las ventanas en las que se visualizan las páginas
de cualquier libro, pudiendo definirse varios visores para el mismo libro.
• Botón (Button). Es un objeto que produce acciones como respuesta a
un evento, por ejemplo, el cursor ha pasado por encima, ha sido pulsa-
do con el ratón, etc. Sus formas son diversas, siendo posible asociarles
una representación gráfica.
• Campo (Field). Los campos son contenedores de información textual
y gráfica, siendo posible tener distintos tipos de texto dentro de cada
campo. Tienen formas y tamaños distintos en función de las necesida-
des de la aplicación y del gusto del diseñador.
• Gráficos (Graphic). Son aquellos gráficos realizados con las herra-

mientas de dibujo incluidas dentro de ToolBook.
• Imágenes (PaintObject). Son las imágenes importadas desde cual-
quier editor de gráficos.
• OLE. Son elementos externos a ToolBook que pueden ser embebidos o
enlazados desde un libro.
• Anclas (Hotwords). Son aquellas palabras dentro de los campos que
permiten hacer saltos a distintas páginas o libros, es decir, que actúan
como origen de un enlace.
Los botones, campos, gráficos, imágenes y objetos OLE pueden pertenecer a:
• la plantilla, en cuyo caso es lo mismo que decir que están contenidos en
toda página que haga uso de esa plantilla, o a
• la página, en cuyo caso sólo están en esa página.
De estas descripciones se desprende que en ToolBook existe una jerar-
quía de objetos como se refleja en la figura 13.2. En el nivel superior se
encuentra el objeto libro que contiene a todos los demás. En un segundo
nivel, están las plantillas que contendrán de 1 a N páginas y de 0 a N objetos.
Las páginas, a su vez, incluirán de 0 a N objetos. Además, todos los objetos
tienen un conjunto de propiedades asociadas que permiten caracterizarlos
tanto desde un punto de vista físico (por ejemplo, fontStyle es una propiedad
que permite cambiar el estilo de un texto) o lógico (por ejemplo, name es una
propiedad que sirve para nombrar un objeto concreto). Además, todos los
objetos tienen un identificador único que permite al desarrollador hacerles
referencia evitando que se produzcan ambigüedades o solapamientos.
FIGURA 13.2. Jerarquía de objetos en ToolBook.

Existen dos niveles de uso de ToolBook:

• nivel de autor (Author), que permite al usuario crear y modificar obje-
tos, escribir programas, incluir gráficos, etc., y,
• nivel de lector (Reader), en el que los usuarios pueden navegar por las
páginas, escribir y dar formato a los textos, imprimir, ejecutar progra-
mas, etc.
En las figuras 13.3 y 13.4 se muestra el mismo libro visto desde la pers-
pectiva del autor y del lector. Como se puede apreciar en el primer caso, Tool-
book muestra un conjunto de herramientas que le permiten modificar cual-
quiera de los objetos que participan en la aplicación, mientras que en el
segundo de los casos, el lector sólo puede interactuar con la información que
le ofrece el libro.
El lenguaje de programación que se usa en el desarrollo se denomina
OpenScript. Es un lenguaje que tiene como filosofía la programación basada
en objetos, si bien no es un lenguaje realmente orientado a objetos. Esto es
debido a que aunque utilice el concepto de objeto como elemento central del
desarrollo no admite algunas características básicas de este paradigma como
puede ser la generalización.
Todos los objetos tienen una propiedad denominada script que contiene
los guiones que definen sus comportamientos tanto ante eventos predefinidos
(por ejemplo, el ratón ha pasado por encima del objeto) como ante eventos
específicos definidos por el desarrollador. En la siguiente tabla se muestran
dos ejemplos de guiones que definen el comportamiento ante un evento pre-
definido (fila superior) y ante un evento definido por el desarrollador (fila infe-
rior). Cuando un objeto envía un mensaje indicando que se ha producido un
determinado evento (por ejemplo la sentencia send «mi evento» en la fila
superior de la tabla 13.2) el objeto receptor de este mensaje ejecutará el guión
correspondiente a ese evento, en este caso el guión mostrado en la fila inferior.
TABLA 13.2. Un ejemplo de guión definido con OpenScript
Evento Guión
Predefinido to handle buttonClick
if target is button «More info»
send «miEvento»
end if
end buttonClick
Definido por el programador to handle miEvento

go to page «history»
end miEvento
FIGURA 13.3. Visión de autor de un libro de ToolBook.
FIGURA 13.4. Visión del lector de un libro de ToolBook.

Para facilitar la labor del desarrollador, existe un editor de acciones pre-

definidas que se pueden integrar en cualquier objeto mediante una simple
selección de ratón y, además, son directamente exportables a formatos Web
soportados tanto por el navegador Internet Explorer como por Netscape.
También los desarrolladores, en este caso expertos, pueden integrar rutinas
creadas con lenguajes como C++, C o VisualBasic en su aplicación ToolBook.
Finalmente, cabe destacar que esta herramienta de autor permite progra-
mar aplicaciones de forma sencilla y accediendo a todas las características del
entorno. Además, las versiones actuales han evolucionado hacia potentes herra-
mientas de desarrollo de contenidos educativos que cumplen los estándares de
la industria del «e-learning», tales como SCORM1 («Sharable Content Object
Reference Model») o AICC2 («Aviation Industry CBT (Computer-Based Training)
Committee»), y que hacen posible al publicación del producto final tanto en
Web, a través de una extensión denominada Neuron, como en soportes estáticos
(por ejemplo, DVD), como en forma de soluciones híbridas en las que ambas
formas de publicación pueden coexistir simultáneamente. Toolbook proporcio-
na una interfaz de simulación que ayuda a desarrollar estas aplicaciones híbri-
das, permitiendo al desarrollador observar que pasos siguen los usuarios, cómo
introducen información o cómo interactúan con la aplicación, pudiendo evaluar
sus respuestas y su actividad. Además, se pueden integrar todo tipo de informa-
ción de vídeo y de sonido utilizando tecnología de streaming.
13.3. DREAMWEAVER
Dreamweaver (Macromedia, 2003) es una herramienta de autor de la
compañía Macromedia que permite generar de manera sencilla páginas
HTML. Con este fin, facilita una serie de herramientas visuales para que las
personas que generan estas páginas no tengan que tener necesariamente
conocimientos de este lenguaje de marcado, y así puedan componer una
página Web sin tener que editar manualmente el código. También es posible
acceder en todo momento al código HTML automáticamente generado por la
herramienta, por lo que el desarrollador que si tenga conocimientos sobre
lenguajes de marcado podrá insertar cualquier tipo de etiqueta o información
sobre el código fuente, modificación que automáticamente se refleja en la
composición visual de la página.
Otras características interesantes de esta herramienta son:
• Posibilidad de trabajar con distintos lenguajes de marcado y hojas
de estilo. Dreamweaver permite, además de trabajar con documentos
HTML, la edición de documentos que utilizan otros lenguajes de mar-
1
http://www.adlnet.org/
2
http://www.aicc.org/
cado como son XML y XHTML, pudiéndose todos ellos combinar con
hojas de estilo desarrolladas con CSS2.
• Inclusión de documentos interpretados en el servidor. Además de
la edición de documentos que se interpretan en el cliente se pueden
desarrollar documentos que se interpreten en el servidor utilizando tec-
nologías como PHP, ASP.NET, ASP y JSP.
• Existencia de librerías. El desarrollador tiene a su disposición libre-
rías que permiten una generación rápida de código, facilitando la
actualización de bases de datos a través de formularios, el recuerdo de
las páginas que el usuario ha visitado, así como su identificación para
realizar operaciones en las que es necesario conocer la identidad del
usuario.
• Gestión de sitios Web. Dreamweaver también permite la gestión de
sitios Web, especialmente si estos son los servidores que la propia
empresa desarrolla, denominados ColdFusion, permitiendo versiones
de los documentos así como la actualización de los mismos.
El área de trabajo de Dreamweaver es flexible, lo que le permite adaptar-
se a distintas formas de trabajar y diversos niveles de experiencia. Cuenta con
algunos componentes que se utilizan habitualmente:
• La ventana de documento, que muestra el documento que se está
creando o editando. En la figura 13.5 está abiertas tanto la visión de
marcado, parte superior de la ventana, como la visión gráfica, parte
inferior.
• Las opciones más habituales, a las que se puede acceder a través de
los iconos rápidos. En la figura 13.5 se pueden ver estos iconos en la
parte superior de la ventana del documento.
• El inspector de propiedades, que muestra las propiedades del objeto
o texto seleccionado, pudiéndose modificar cualquiera de las propieda-
des disponibles. En la figura se encuentra situada en la parte inferior,
siendo las propiedades que se pueden modificar las relativas al texto, ya
que objeto seleccionado es de este tipo.
• Los menús contextuales, que permiten acceder rápidamente a
comandos útiles relacionados con la selección o área con la que se está
trabajando. En la figura, se puede ver donde se encuentra el cursor, el
menú contextual correspondiente a la pantalla de edición de la etique-
tas HTML.
FIGURA 13.5. Algunos de los componentes de Dreamweaver.
Las diferencias principales de Dreamweaver con respecto a otros editores

de páginas Web son:
• Genera un código HTML bastante limpio y compatible con la mayoría
de los navegadores.
• Incluye varias herramientas adicionales que permiten aumentar la pro-
ductividad, tales como la creación de mapas de navegación, generación
de tablas, de formularios, etc.
• Ofrece varias herramientas para optimizar y gestionar el sitio Web
completo en remoto, de manera que el usuario puede trabajar local-
mente y cuando haya finalizado su labor enviar las páginas al servidor,
para lo cual incluye un cliente FTP con opciones que permiten mante-
ner actualizados tanto el sitio local como el remoto. En la figura 13.6 se
puede ver algunos de los parámetros que se configuran para definir el
sitio Web que se está desarrollando, y en particular los del sitio local.
• Añade algunas funciones predefinidas de Javascript, llamadas «Beha-
viors», que facilitan mucho la inclusión de controles y efectos habitua-
les de los lenguajes basados en guiones (script) a desarrolladores que no
tiene conocimientos de programación. En la figura 13.7 se puede ver la
lista de comportamientos definidos dentro de la página, los cuales son

fácilmente modificables y adaptables para que funcionen en alguno de
los navegadores más utilizados.
• Genera código interpretable tanto por el servidor (por ejemplo, código
PHP o código JSP) como por el cliente, de manera que se puede conectar
las páginas generadas de forma muy sencilla con servidores de base de
datos, facilitando la generación de páginas con información dinámica.
• Coordina la edición gráfica y la edición del código esta muy lograda, de
manera que en todo momento la visión gráfica y textual de la página se
corresponden totalmente. Esto permite a los programadores y diseña-
dores experimentados añadir elementos al HTML no soportados de
manera visual por Dreamweaver.
FIGURA 13.6. Ventana para la definición del sitio local en Dreamweaver.

FIGURA 13.7. Ventana para la definición del comportamientos en Dreamweaver.
13.4. AUTHORWARE
Authorware (Macromedia, 2003) es una herramienta de autor para la
creación de sistemas Web y de sistemas de tele-educación, que integra gráfi-
cos, sonido, animación, texto y vídeo dentro un sistema multimedia interac-
tivo. La interfaz de esta herramienta permite el desarrollo rápido de cual-
quier aplicación utilizando mecanismo que agilizan el desarrollo, como por
ejemplo el uso de técnicas de arrastrar y soltar («drag and drop»).
Authorware se caracteriza por emplear una línea de flujo para la defini-
ción de la estructura y de la participación de los distintos contenidos multi-
media en la aplicación, haciendo las veces de flujo de programa. En la figura
13.8 se puede ver el entorno de desarrollo de esta herramienta y la ejecución
de la aplicación en la ventana inferior izquierda. Para la definición de este
ejemplo se han utilizado varios niveles, cada uno de los cuales tiene una línea
de ejecución. En la figura se muestran tres distintas, cada una de ellas en un
nivel diferente. Haciendo una similitud con la programación imperativa cada
una de estas líneas correspondería a un subprograma de un programa. Cada
línea de flujo contiene una serie de iconos que se corresponden con las accio-
nes que se tienen que llevar a cabo cuando la ejecución de la aplicación llegue
al punto que representa.
Authorware permite la publicación de los contenidos tanto en formato

CD como en formato Web, añadiendo al servidor todas las extensiones nece-
sarias para poder visualizar las presentaciones realizadas en cualquier nave-
gador a través del correspondiente conector (plug-in). En la figura 13.9 se
muestra la pantalla que sirve para configurar el tipo de salida que se quiere
producir como resultado final. Además, Authorware ofrece una opción para
poder realizar la publicación Web retrasada (batch) útil cuando el producto
resultante consta de muchos archivos.
Authorware está concebida como una herramienta para el desarrollo de
material educativo, por esa razón las últimas versiones dan soporte a los últi-
mos estándares de tecnología educativa, como AICC y SCORM, lo que facili-
ta la integración de sus contenidos en cualquier plataforma de LMS (Learning
Management System).
FIGURA 13.8. Una aplicación de Authorware.

FIGURA 13.9. Pantalla de configuración de Authorware.
13.5. LA TECNOLOGÍA FLASH

La tecnología Flash (OpenSWF, 2003) es una creación de la empresa
Macromedia que permite el desarrollo de contenidos multimedia con carac-
terísticas avanzadas, tales como la sincronización, la animación, el sonido y
la interactividad. A diferencia de los casos anteriores, Flash no es una herra-
mienta de autor concreta sino una tecnología que ha tenido un gran auge en
los últimos tiempos que se está convirtiendo en un estándar de facto para la
creación de contenidos multimedia para la Web.
Aunque originalmente esta tecnología nace ligada a los productos de
Macromedia, en la actualidad hay herramientas de otras empresas que tam-
bién generan contenidos en el denominado «formato Flash», que no es otra
cosa que un formato de datos denominado SWF. Los dos principios básicos
de este formato son:
• para el almacenamiento de los contenidos utiliza la tecnología vectorial y
• es compatible con tecnología de streaming, lo que permite empezar a
visualizar la información sin haberla descargado totalmente.
Los contenidos Flash pueden incorporarse a cualquier documento

HTML, ubicarse tanto en servidores Web convencionales como en especiali-
zados, y ser visualizados en navegadores como Netscape o Internet Explorer.
En este último caso, se requiere la instalación en dicho navegador de un
conector (plug-in) que reconozca el formato de las animaciones. En el caso de
la compañía Macromedia, este conector se denomina Flash Player y puede
obtenerse gratuitamente en el sitio Web de la compañía (Macromedia, 2003).
En los siguientes subapartados se introducen los conceptos básicos de
esta tecnología para, a continuación, describir una herramienta de autor
para esta tecnología: 3D Flash Animator.
13.5.1. Características de Flash
En las aplicaciones multimedia, la sincronización en el tiempo es un elemen-

to esencial en la mayoría de los casos (Díaz y otros, 2001), como ya se comentó
en el capítulo 5 (sección 5.2). En Flash para indicar cómo los elementos de la apli-
cación participan en ella se utiliza una línea de tiempo, dividida en fotogramas:
• Línea de tiempo (Timeline). Es la zona en la que se controla la
secuencia de aparición de los diferentes elementos (gráficos, textos,
sonidos, etc.)
• Fotograma (Frame). Es cada uno de los «momentos» que componen la
línea de tiempo (análogos a los fotogramas de las películas). Para cada uno
de ellos se especifican los objetos que aparecen y qué características tienen.
Debido a esa sincronización temporal, un determinado elemento como
una imagen, puede que aparezca en algunos fotogramas y en otros no. Para
conseguirlo, una técnica habitual es crear varias capas en la animación, de
forma que éstas pueden ocultarse, mostrarse o superponerse, consiguiendo
los efectos de aparición o desaparición de los elementos.
• Capas (Layers). Las capas son como láminas en las que se pueden
colocar objetos de forma que se superpongan.
La interactividad de la multimedia hace referencia al hecho de que los
usuarios pueden interactuar con los elementos mediante los dispositivos de
entrada (teclado y ratón, fundamentalmente), provocando reacciones de la
aplicación a tales interacciones. Técnicamente, los sucesos que recibe la apli-
cación se denominan eventos, y las reacciones a los mismos (que debe espe-
cificar el desarrollador de los contenidos) se denominan acciones.
• Evento (Event). Es un estímulo que provoca una reacción en el siste-
ma como pueden ser pulsar el ratón o una tecla.
• Acción (Action). Es el resultado con el que responde el sistema ante el
evento provocado.
13.5.2. 3D Flash Animator

FlashAnimator (3dfa, 2993) permite la edición de dos tipos de elementos
multimedia:
• Los objetos, que son contenidos individuales, que no constituyen por
sí mismos un contenido Flash, pero pueden utilizarse como parte de
uno de ellos.
• Los proyectos, que sí constituyen animaciones Flash.
Es importante resaltar que FlashAnimator trabaja por defecto con unos
formatos de fichero propios, con extensiones especiales, pero permite expor-
tar estos contenidos propietarios al formato SWF de Flash. En la siguiente
figura 13.10 se puede ver el entorno de desarrollo de una animación de esta
herramienta.
FIGURA 13.10. El entorno de la herramienta 3D Flash Animator.
Los objetos que permite desarrollar esta herramienta son de tres tipos:
• imágenes de mapas de bits;
• guiones (scripts), que son fragmentos de programa que sirven para aña-
dir interactividad a las presentaciones, y,
• sonidos.
Estos objetos se pueden combinar en una línea de tiempo, de manera que

se sincronizan como se puede ver en la figura 13.11, en la que cinco objetos
están posicionados en una línea de tiempo junto a un evento y diversas esce-
nas que nos permiten definir esas relaciones temporales entre los elementos.
La ejecución de este proyecto consiste en:
1. La imagen red sky aparece en la escena 1, justo al empezar la anima-
ción.
2. A los dos segundos, comienza a sonar «Chiquito» y además se mues-
tra, con efecto de explosión, la imagen desert night sky.
3. A los dos segundos, comienza la escena 3, y se muestra cloudy blue sky.
Simultáneamente, como se ve en la imagen en los eventos de la esce-
na, se para el sonido «Chiquito».
4. A los dos segundos, aparece el título 3D.
FIGURA 13.11. La línea de tiempo de Flash Animator.

13.6. DIRECTOR
Director (Macromedia, 2003) es una herramienta de Macromedia que
facilita el desarrollo de sistemas interactivos basándose en el uso de la metá-
fora del cine. Por esta razón, cuando el desarrollador realiza un proyecto tie-
ne que pensar en los elementos que participan en una película, tales como el
escenario, el reparto de actores y el guión:
• El escenario es el espacio en el que se desarrollan las acciones.
• Los actores son los contenidos multimedia que participan en la pelícu-
la, siendo por lo tanto el reparto una lista de contenidos.
• El guión define cuándo y dónde deben aparecer cada uno de los acto-
res sobre el escenario, describiendo las acciones que ocurrirán en la
película.
En la figura 13.12 se muestra la apariencia de una aplicación desarrolla-
da con Director, así como las ventanas que corresponden al reparto de acto-
res (cast) y al guión de la película (score).
FIGURA 13.12. El entorno de desarrollo de Director.

Director permite utilizar como actores contenidos en la mayoría de los

formatos multimedia existentes, tales como RealVideo, QuickTime, GIF,
SWF, etc., pudiéndose publicar en cualquier medio tanto estático (por ejem-
plo, DVD) como dinámico (a través de Shockwave player). Además, como
puede incluir contenidos multimedia en formato Flash es posible incluir
complejos elementos multimedia sin necesidad de un alto coste de almace-
namientos/transmisión ya que se beneficia del uso de los gráficos vectoriales
de los que hace uso esta tecnología (sección 13.5.1). Estos elementos se pue-
den gestionar de manera eficiente mediante Lingo, el lenguaje de programa-
ción que proporciona Director, pudiendo acceder desde la aplicación a las
propiedades de ese contenido Flash. Lingo también ofrece al desarrollador la
posibilidad de gestionar todos los actores, así como de todas las característi-
cas de la película.
13.7. RESUMEN
Este capítulo ha presentado las herramientas de autor como aplicaciones
que facilitan la construcción de aplicaciones interactivas multimedia tanto a
expertos desarrolladores como aquellos que no sean tan experimentados.
Estas herramientas suelen proporcionar mecanismos de manipulación direc-
ta, de manera que mediante simples movimientos de ratón se pueden crear
aplicaciones muy complejas.
En concreto, se han introducido un conjunto de herramientas de autor
con características muy distintas como son:
• ToolBook, que se basa en el uso de la metáfora del libro y que tiene un
potente lenguaje de guión denominado OpenScript.
• Dreamweaver, que es un editor visual de documentos Web, tanto
HTML como XML, y que permite la creación de documentos estáticos
y dinámicos.
• Authorware, que utiliza una línea de flujo en la que se localizan iconos
que representan los objetos que aparecen en la pantalla.
• Flash, que es una tecnología que usan muchas herramientas como 3D
Flash Animator en la que los objetos multimedia se sincronizan en una
línea de tiempo.
• Director, que tiene como base la metáfora del cine en la que los actores
aparecen en el escenario en determinadas secuencias.

13.1. Las herramientas de autor se basan en el siguiente paradigma de inte-
racción:
a) Computación ubicua.
b) Computación vestible.
c) Manipulación directa.
d) Realidad virtual.
13.2. ¿Qué elemento es característico de las herramientas de autor?

a) Lenguajes de programación imperativos.
b) Interfaces tangibles.
c) Editores de contenidos multimedia.
d) La metáfora del libro.
13.3. ¿Qué herramienta se basa en el uso de pilas de tarjetas?

a) ToolBook.
b) HyperCard.
c) Authorware.
d) Director.
13.4. ¿Qué herramienta de autor está orientada al desarrollo de contenidos

educativos?
a) Authorware.
b) Flash Animator.
c) Director.
d) Dreamweaver.
13.5. ¿Qué herramienta de autor utiliza la metáfora de las páginas de un libro?

a) Director.
b) Dreamweaver.
c) Flash Animator.
d) ToolBook.
13.9. REFERENCIAS BIBLOGRÁFICAS

ASYMETRICS (2003): ToolBook. Accesible en http://www.asymetrics.com
DÍAZ y otros (1996): Paloma Díaz, Nadia Catenazzi e Ignacio Aedo. De la multimedia
a la hipermedia. Ed. Rama, Madrid, 1996.
DÍAZ y otros (2001): Paloma Díaz, Ignacio Aedo y Fivos Panetsos. Modeling the dyna-
mic behavior of hypermedia applications. IEEE Transactions on Software Engi-
neering, vol 27 (6), Junio 2001, págs 550-572.
MACROMEDIA (2003a): DreamWeaver. Accesible en http://www.macromedia.com
MACROMEDIA (2003b): Authorware. Accesible en http://www.macromedia.com
OPENSWF (2003): Flash 6.0 (MX) Specifications. Accesible en http://www.openswf.org/
VÄÄNÄNEN (1995): 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.
3dfa (2993): 3D Flash Animator. Accesible en http://www.3dfa.com/
Capítulo 14
LENGUAJES DE MARCADO
Y DE PRESENTACIÓN
ESQUEMA
14.1. Lenguajes de marcado genéricos.

14.2. Lenguajes de presentación.
14.3. Modelado de mundos virtuales utilizando VRML.
14.4. Resumen.
En el mundo de los documentos en papel, el término marcado hace refe-
rencia a la manera en la que el editor anota los manuscritos con especifica-
ciones tipográficas y otros datos sobre su presentación. En los documentos
electrónicos, el marcado es el término empleado para describir los códigos,
denominados también etiquetas, añadidos al texto electrónico que definen la
estructura y el formato en el que tiene que aparecer. Puede ser utilizado, ade-
más, para propósitos muy diferentes como son la escritura, la impresión, el
intercambio, la presentación de pantallas, etc.
La gran variedad de lenguajes de marcado y su patente incompatibilidad
constituyen la causa de los problemas que se plantean al intercambiar un
documento entre plataformas heterogéneas. Los lenguajes estándar propor-
cionan una manera de solventar este hecho, ya que son independientes de la
aplicación y de la plataforma hardware, empleando para marcar el documen-
to, en la mayoría de los casos, código ASCII.
Cuando se habla de lenguajes de marcado, es importante distinguir entre
la estructura lógica y física del documento.
DEFINICIÓN: La estructura lógica.

• La estructura lógica está formada por las partes que lo componen y por sus
relaciones.
DEFINICIÓN: La estructura física.

• La estructura física indica la apariencia del documento, ya sea en el papel o sobre
la pantalla, incluyendo sus componentes físicos, el posicionamiento de los elemen-
tos y la tipografía empleada.
En la figura 14.1 se pueden ver algunos de los componentes que describen

la lógica y la estructura física del documento.
Estructura Lógica Tipos de Marcado Estructura Física
Identificador de Capítulo Capítulo Diecinueve Palatino 14. Centrado

Nombre Capítulo Título Palatino 14. Centrado. Negrita
Párrafo Capítulo Este es el primer párrafo del capítulo diecinueve. Courier 12.
Identificador de Sección Sección 1 Helvética 14. Centrado

Nombre Sección Título Sección 1 Helvética 14. Centrado. Negrita
Courier 10.
Etiqueta 1: Elemento 1 de la lista.
Lista de
Elementos
Courier 10. Izquierda. Negrita

Etiqueta n: Elemento n de la lista
Identificador de Sección Sección 2 Helvética 14. Centrado

Nombre Sección Título Sección 2 Helvética 14. Centrado. Negrita
Párrafo Sección Aquí vendría un texto explicativo de lo que viene Courier 12. Izquierda
a continuación.
Courier 10.
Lista de
Elementos
Courier 10. Izquierda. Negrita

Etiqueta 4: Elemento n de la lista
FIGURA 14.1. Estructura lógica versus estructura física en el documentos.
En este capítulo se presentan un conjunto de lenguajes de marcado

que se utilizan habitualmente en los entornos Web y algunos lenguajes de
presentación que permiten adaptar la presentación de la información
contenida en esos documentos. Además, y para finalizar, se presenta el
VRML como lenguaje de modelado que permite la definición de mundos
virtuales que permiten al usuario navegar por la información en tres
dimensiones.
14.1. LENGUAJES DE MARCADO GENÉRICOS
Los lenguajes de marcado genérico describen la estructura de un docu-

mento y sus atributos, sin especificar el proceso que se debe realizar sobre él.
DEFINICIÓN: Los lenguajes de marcado genéricos.

• Los lenguajes de marcado genéricos son aquellos que sirven para especificar
la estructura de cualquier documento sin tener en cuenta los aspectos relativos
a la presentación.
Esto supone que el mismo documento se puede presentar de muchas mane-

ras, de acuerdo con las normas de estilo que se le apliquen. A continuación se
LENGUAJES DE MARCADO Y DE PRESENTACIÓN 385
presentan los lenguajes más conocidos y que se utilizan para la publicación en

Web.
14.1.1. SGML
SGML (Standard Generalized Markup Language) es un ejemplo de lengua-
je genérico que apareció con el identificador 8879 como norma ISO (Interna-
tional Organization for Standardization) en 1986. La comunidad editorial fue
la que dio origen a esta norma, al considerar que la flexibilidad en el diseño
de los documentos era de máxima importancia. El objetivo que perseguía era
proporcionar una manera normalizada de transmitir los documentos en un
formato adecuado para los procesos de edición e impresión. SGML es apro-
piado para describir texto altamente estructurado, aunque también se pue-
den incluir en los documentos otros elementos, como por ejemplo diagramas
y gráficos, independientemente de su formato de codificación.
SGML contiene las reglas para crear una infinita variedad de lenguajes de
marcado, pero no describe el formato de los documentos marcados. Una defi-
nición similar clasifica a SGML como un sistema para especificar lenguajes de
marcado, es decir, un metalenguaje. Esto hace posible que, mediante la utili-
zación de una definición de tipo de documento (denominada DTD Document
Type Definition), se pueda especificar la estructura lógica de una clase de
escrito.
DEFINICIÓN: DTD (Document Type Definition).

• Una DTD es una definición formal que indica qué elementos se incluyen como con-
tenidos de los documentos y en qué orden.
Cada elemento en el documento se marca mediante una etiqueta de

comienzo y otra de final. Estas etiquetas vienen especificadas mediante un
identificador genérico, que define el tipo del elemento (por ejemplo, párrafo,
cabecera o figura) y unas características, o atributos, que cualifican al identi-
ficador. En concreto una DTD define:
• los identificadores genéricos de los elementos que se permiten en un
tipo de documento;
• para cada elemento, los posibles atributos y sus rangos de valores, así
como el que toma por defecto; su estructura y su contenido, incluyen-
do los subelementos que pueden ocurrir y en qué orden.
Una DTD considera un documento como un árbol, cuya raíz es el propio
documento. Un ejemplo de cómo podría aparecer un elemento en una DTD
se puede ver en la tabla 14.1. Antología, poema, título, estrofa y línea son los
identificadores genéricos de los elementos. El elemento antología se define
mediante un conjunto de poemas (poema+). Cada ítem en el grupo necesita,

a su vez, una mayor definición, hasta llegar a elementos terminales que no se
subdividen en otros.
TABLA 14.1. Definición de una antología de poemas en una DTD

<!ELEMENT antologia - - (poema+)>
<!ELEMENT poema - - (titulo?, estrofa+)>
<!ELEMENT titulo - - (#PCDATA) >
<!ELEMENT estrofa - - (linea+) >
<!ELEMENT línea - - (#PCDATA) >
No es único el documento que cumple esa DTD sino que pueden ser
muchas las antologías de poemas que se publiquen. Por esa razón puede
haber muchos documentos que cumplan la misma DTD, aunque no debería
haber más que una DTD para un tipo de documento. A continuación se pre-
senta un ejemplo de documento que cumple la DTD anterior (tabla 14.2).
A partir de la definición de SGML se han generado diversos lenguajes de
marcado que sirven, o han servido, para el desarrollo de aplicaciones hiper-
media/Web. Es cierto que normalmente estos lenguajes no se utilizan direc-
tamente, sino que normalmente se usan herramientas de autor que generan
el código en alguno(s) de los lenguajes que se mencionan a continuación (por
ejemplo, Macromedia DreamWeaver). De esta forma el programador no se
preocupa ni de la sintaxis ni de la semántica asociada a los códigos concretos
si no que mediante lenguajes visuales establece la estructura, el contenido y
la apariencia de los hiperdocumentos que conforman su aplicación. Algunos
de los lenguajes de marcado más conocidos son: HTML, XML, XHTML,
HyTime y SMIL.
TABLA 14.2. Un documento concreto que sigue la DTD definida anteriormente
<antologia>
<poema>
<titutlo>The SICK ROSE</titulo>
<estrofa>
<linea>O Rose thou art sick,</linea>
<linea>The invisible worm,</linea>
<linea>That flies the night</linea>
<linea>In the howling storm:</linea>
</estrofa>
<estrofa>
<linea>Has found out thy bed</linea>
<linea>Of crimson joy:</linea>
<linea>And his dark secret love</linea>
<linea>Does thy life destroy.</linea>
</estrofa>
</poema>
<!—aqui van más poemas -->
<antologia>
14.1.2. HTML (Hypertextual Markup Language)

HTML es una aplicación de SGML que incluye tipos de documentos pre-
definidos. Por ello, todos los documentos de tipo HTML contienen los mis-
mos elementos y los mismos atributos, es decir todos los documentos de este
tipo tienen la misma estructura pero no los mismos contenidos. La última
versión de HTML es la 4.01 siendo una recomendación no una especificación
ya que no se llegó a un acuerdo total sobre ella. Esta norma ha ido desvir-
tuándose de tal manera que además de elementos conceptuales como pueden
ser los enlaces, contiene también elementos de presentación (por ejemplo, el
elemento para poner en negrita un texto).
Todos los documentos que cumplen la norma HTML, por tanto, siguen la
especificación de una DTD concreta que es interpretable por los navegadores
que existen en la actualidad. En este proceso de interpretación, el navegador
se encarga de transformar cada una de las marcas que definen la estructura
del documento en una representación física que el usuario pueda compren-
der. En el ejemplo siguiente, se muestra una página HTML que muestra la
estructura fundamental de un documento y, a su derecha, su visualización
utilizando un navegador, tabla 14.3.
TABLA 14.3. Un ejemplo de HTML

<HTML>
<HEAD>
<TITLE>Título de mi página</TITLE>
<META name=autor content=”Pepe”>
</HEAD>
<BODY>
Este es un ejemplo de página web:<BR>
<IMG src=””><BR>
</BODY>
</HTML>
FIGURA 14.2. La representación en el navegador del ejemplo de la tabla 14.3.

Todo documento HTML está formado por una cabecera (HEAD) y un

cuerpo (BODY). En la cabecera se incluye toda la información relativa al
documento como puede ser meta-información que es información sobre la
información o un título que se utilizará por el navegador en la lista de pági-
nas visitadas o como título de la ventana que muestra el documento. En la
parte del cuerpo se incluirá toda la información relativa al documento junto
con las etiquetas que dan forma al mismo. En el ejemplo anterior, la etiqueta
<BR> sirve para que la imagen que aparece a continuación del texto se mues-
tre en la línea siguiente, mientras que la etiqueta <IMG> se utiliza para
incluir la imagen que se indica en el atributo src.
14.1.3. HyTime (Hypermedia/Time-Based Structuring

Language)
HyTime es una extensión de SGML que especifica un conjunto de concep-

tos básicos con los que se puede definir la estructura lógica de documentos
hipertextuales y multimedia. HyTime normaliza aquellos mecanismos que se
refieren a la localización de porciones de documentos hipermedia y sus com-
ponentes multimedia de información, incluyendo enlaces, alineamiento en el
espacio y sincronización en el tiempo, es decir, proporciona una manera
homogénea de enlazar a un documento cualquier tipo de elemento, en cual-
quier parte y en cualquier instante. Sirve como base de intercambio de infor-
maciones hipermedia, independientemente de la aplicación que las haya
creado, y se ocupa de normalizar la estructura del documento y la identifica-
ción de los objetos de información que lo conforman. HyTime, por tanto, no
establece los contenidos del hiperdocumento, ni la codificación de la infor-
mación, ni los objetos, ni la aplicación que trabaja sobre ellos, ni arquitectu-
ras de documentos particulares, ni tipos de enlaces, ni tipos de documentos.
Debido a la dificultad en su uso, esta norma no ha sido utilizada de una for-
ma masiva, aunque muchas de sus ideas se encuentran en las normas que en
la actualidad se están imponiendo.
14.1.4. XML (Extensible Markup Language)
XML es una aplicación de SGML, lo que significa que en su especifica-

ción se indican como se deben describir los elementos que participan en el
hiperdocumento pero no los elementos en sí. Por tanto, cuando se quiere des-
cribir un documento mediante XML hay que describir en primer lugar el tipo
de documento en que se basa, es decir la DTD, y a continuación los conteni-
dos concretos asociados a cada elemento. Un ejemplo de construcción de
aplicaciones con XML es el desarrollo de normas para tipos concreto de
documentos, como puede ser un libro electrónico. Una iniciativa en este cam-
po, el desarrollo de una DTD para libros electrónicos a partir de XML, es
OpenEBook, un estándar en el que numerosas empresas del sector bibliográ-

fico están trabajando de manera que con una misma plataforma se puedan
leer, comprar, distribuir, etc. libros electrónicos que tengan un formato
común.
La descripción de la DTDs se hace de una forma muy similar a como se
hace en SGML como se puede apreciar en la siguiente definición, tabla 14.4.
TABLA 14.4. Ejemplo de DTD de XML

<?xml version="1.0"?>
<!DOCTYPE BOOK [
<!ELEMENT p (#PCDATA)>
<!ELEMENT BOOK (OPENER,SUBTITLE?,INTRODUCTION?,(SECTION | •PART)+)>
<!ELEMENT OPENER (TITLE_TEXT)*>
<!ELEMENT TITLE_TEXT (#PCDATA)>
<!ELEMENT SUBTITLE (#PCDATA)>
<!ELEMENT INTRODUCTION (HEADER, p+)+>
<!ELEMENT PART (HEADER, CHAPTER+)>
<!ELEMENT SECTION (HEADER, p+)>
<!ELEMENT HEADER (#PCDATA)>
<!ELEMENT CHAPTER (CHAPTER_NUMBER, CHAPTER_TEXT)>
<!ELEMENT CHAPTER_NUMBER (#PCDATA)>
<!ELEMENT CHAPTER_TEXT (p)+>
]>
Esta descripción del tipo de documento puede aparecer en el propio

documento que cumple esa DTD o puede encontrarse dentro del documento
una referencia hacia donde localizarla, de manera que cuando se compruebe
la validez de un documento que dice que cumple una determinada especifi-
cación, se localizará en primer lugar donde se encuentra su especificación y,
a continuación, se realizará esa comprobación, tabla 14.5.
TABLA 14.5. Ejemplo de documento que cumple la DTD del ejemplo de la tabla 4
<?XML versión=”1.0” standalone=”no”?>

<!DOCTYPE BOOK SYSTEM “www.myDTD.es/dtds/book.dtd”>
<BOOK>
<OPENER>
<TITLE_TEXT>Mi libro</TITLE_TEXT>
</OPENER>
<PART>
<HEADER>Bienvenido a mi libro</HEADER>
<CHAPTER>
<CHAPTER_NUMBER>Capítulo 1</CHAPTER_NUMBER>
<CHAPTER_TEXT>
<p>Este libro es el que voy a escribir</p>
<p>Aunque todavía no se de qué va</p>
</CHAPTER_TEXT>
</CHAPTER>
</PART>
</BOOK>
14.1.5. XHTML (The Extensible Hypertext Markup

Language)
XHTML es una nueva definición de HTML a partir de XML. Este lengua-

je se basa en la redefinición de las DTDs de HTML versión 4 mediante XML
lo que permite entre otras cosas que los documentos siguiendo XHTML se
puedan visualizar tanto en navegadores de HTML como en los de XML. Por
otro lado, como los documentos XHTML son documentos XML deben estar
bien formados, es decir deben cumplir exactamente con la especificación,
cosa que no ocurre con los documentos HTML que los navegadores lo visua-
lizan correctamente aunque el documento no cumpla exactamente la norma.
En el siguiente ejemplo de la tabla 14.6 se visualiza un documento HTML mal
formado, es decir, que no cumple con la especificación (por ejemplo, no se
cierra la etiqueta <html> o no se abre la etiqueta <head>), y su representación
mediante un navegador, que como se puede apreciar se hace correctamente,
figura 3.
TABLA 14.6. Ejemplo de documento HTML mal formado

<HTML>
<HEAD>
<TITLE>Título de mi página</TITLE>
<BODY>
Este es un ejemplo de página web:<BR>
<IMG src="oso.gif"><BR>
</BODY>
FIGURA 14.3. Representación gráfica en el navegador del documento de la tabla 6.
Otras diferencias entre un documento HTML y un documento XHTML son:

• El orden de apertura de un elemento debe corresponder con el orden de
cerrado del mismo.
• Las etiquetas deben de estar escritas en minúsculas.

• Todos los elementos de XHTML deben cerrarse, incluidos aquellos que
sean una única etiqueta.
Además, permite la inclusión de programas dentro de su contenido
siguiendo el modelo de objetos que define la especificación DOM (Document
Object Model), la cual permite actualizar y modificar los contenidos, estruc-
tura y estilo de los documentos de forma dinámica.
Los documentos XHTML están formados por tres partes. La primera de
ellas indica el tipo de documento del que se trata (DOCTYPE), mientras las
otras dos son la cabecera (HEAD) y el cuerpo (BODY) que se han menciona-
do anteriormente en la descripción de HTML. Los tipos de documentos que
existen son tres dependiendo del grado de cumplimiento de la DTD que se
quiere utilizar:
• estricto, que indica que el documento cumple de forma estricta la DTD
de XHTML y que no usa ninguna característica de presentación sino
características de estilo para definirla. La forma de indicar que el docu-
mento cumple de esta manera la DTD es:
• <!DOCTYPE html PUBLIC «-//W3C//DTD XHTML 1.0 Strict//EN»
«http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd»>
• de transición, que indica que se quiere usar las características de pre-
sentación de HTML porque se va a visualizar en navegadores que no
pueden utilizar características de estilo. La forma de indicar que el
documento cumple de esta manera la DTD es:
• <!DOCTYPE html PUBLIC «-//W3C//DTD XHTML 1.0 Transitional//EN»
«http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd»>
• para uso de marcos, cuando se quiere dividir la ventana del navegador
en varias áreas con el uso de la etiquta FRAMESET de HTML. La for-
ma de indicar que el documento cumple de esta manera la DTD es:
• <!DOCTYPE html PUBLIC «-//W3C//DTD XHTML 1.0 Frameset//EN»
«http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd»>
A continuación se muestra un ejemplo de documento XHTML (tabla 7),
que cumple estrictamente la especificación de XHTML y que tiene como
resultado la misma página que se ha presentado anteriormente, añadiéndole
el icono que representa que el documento cumple estrictamente la especifi-
cación de XHTML, figura 14.4.
TABLA 14.7. Ejemplo de documento HTML mal formado

<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<title>Título de mi página</title>
</head>
<body>
<p>
Este es un ejemplo de página web:<br />
<img src="oso.gif" alt="Esta imagen es un oso" />
<a href="http://validator.w3.org/check/referer">
</p>
<p>
<img src=http://www.w3.org/Icons/valid-xhtml10 alt="Valid XHTML 1.0!"

height="31" width="88" />
</a>
</body>
</p>
</html>
FIGURA 14.4. Ejemplo de visualización del documento XHTML de la tabla 14.7.
14.1.6. SMIL (Synchronized Multimedia Integration Language)

SMIL es un lenguaje basado en XML para la definición de aplicaciones
multimedia interactivas, de manera que un autor puede describir el compor-
tamiento temporal de presentaciones multimedia, asociar enlaces a conteni-
dos de cualquier tipo (por ejemplo, vídeos, sonidos, programas, etc.) y descri-
bir la presentación en la pantalla. SMIL (se pronuncia smile —sonrisa—) no es
una solución que intente competir con tecnologías existentes de representa-
ción multimedia (por ejemplo, Quicktime o Flash) sino que lo que pretende es
integrar esas tecnologías de manera estándar para que puedan combinarse.
Existen numerosos visualizadores de documentos SMIL que permiten

mostrar todas sus características. Algunos de los más conocidos son: Real-
Player, Quicktime Player (la versión gratuita sólo permite ver documentos
muy sencillos) y GRINS Player. Además, algunos navegadores Web, como
Internet Explorer, permiten visualizar también estos documentos.
Un documento SMIL se compone de una cabecera (HEAD) y un cuerpo
(BODY). En la cabecera se definen tanto la metainformación del documento
como información relativa a como deben aparecer en la pantalla los elemen-
tos de información. En el cuerpo del documento se incluirán los contenidos
del documento así como las relaciones entre ellos. En el siguiente ejemplo, se
muestra un documento SMIL que muestra las dos partes que se han mencio-
nado anteriormente. En la primera se establece el nombre del autor del docu-
mento («pepe») y se divide la pantalla en dos zonas, una denominada «video»
y la otra «imagen», definiendo el punto superior izquierda de la zona («top»
y «left») y el ancho y alto de la misma (width y height). En el cuerpo del docu-
mento se indica que se muestren de forma simultánea («par») tres conteni-
dos, un vídeo, una imagen y un sonido. Además, se indica que el video se
muestre en la región que se ha denominado «video» y la imagen en la que ha
denominado «imagen». En la figura 14.5 se puede apreciar el resultado al
visualizar el documento en el visor RealPlayer, tabla 14.8.
TABLA 14.8. Ejemplo de documento SMIL

<smil>
<head>
<meta name="author" content="pepe" />
<layout>
<region id="video" top="10px" left="100px" width="240px" height="250px" •/>
<region id="imagen" top="10px" left="350px" width="240px" height="120px"• />
</layout>
</head>
<body>
<par>
<video region="video" src="lear24.avi" />
<img region="imagen" src="oso.gif" />
<audio src="animals.wav" />
</par>
</body>
</smil>
FIGURA 14.5. Un ejemplo de visualización del documento SMIL de la tabla.
14.1.7. WML (Wireless Markup Language)

El denominado protocolo WAP (Wireless Application Protocol) permite el
desarrollo de aplicaciones sobre dispositivos móviles a través de redes ina-
lámbricas. Se verá cómo se desarrollan aplicaciones WAP sencillas, sin entrar
en detalles sobre la arquitectura de sus protocolos subyacentes. Para ello, se
verá exclusivamente en los lenguajes WML y WMLScript, que son los equiva-
lentes dentro del mundo «inalámbrico» al HTML y al JavaScript (o lenguajes
similares, como VBScript o ECMAScript) dentro de las redes que usan el pro-
tocolo TCP/IP como hace Internet.
Los documentos WML pueden mostrarse en teléfonos móviles, pero tam-
bién en cualquier otro dispositivo que contenga un micronavegador (es decir,
un dispositivo que sepa interpretar WML y WMLScript), como puede ser una
agenda personal (PDA) o una aplicación en nuestro ordenador personal. Por
ello, en ocasiones se hará referencia a cualquiera de estos dispositivos con el
término general «agente de usuario» en lugar de hablar exclusivamente de los
teléfonos móviles.
Los documentos escritos en WML pueden accederse mediante URLs, de
manera similar a cómo se hace con las páginas HTML. Para ello, se necesita
un navegador WML, que puede estar empotrado en un teléfono móvil o ser

un emulador que se utiliza desde un ordenador personal. En la figura 14.6 se
puede ver uno de estos emuladores de teléfono móvil, en concreto del teléfo-
no «Nokia 6210», el cual se puede utilizar para navegar por esas páginas.
FIGURA 14.6. Ejemplo de emulador de un teléfono móvil para acceder a documentos WAP.
Además de los emuladores a través de la Web, hay otros que pueden ins-
talarse en el ordenador personal, y que son en ocasiones más fáciles de utili-
zar, como por ejemplo, DeckIt (http://www.pyweb.com/tools/). Una vez des-
cargado e instalado no sólo se podrá navegar con él sino que puede ir
mostrando el código WML mientras se navega (figura 14.7).
El lenguaje WML es un lenguaje de descripción de páginas que permite
definir la presentación de la información en el teléfono móvil, solicitar entra-
das del usuario y responder a ciertas interacciones del usuario con el móvil,
como puede ser la pulsación de una tecla. Este lenguaje se basa en una DTD
de XML por lo que todo documento WML es a su vez un documento XML
tabla 14.9.
Los documentos WML están formados una definición de tipo de docu-
mento, y un mazo de cartas que se corresponden con las pantallas que se
visualizan en el visor del dispositivo. A continuación, se presenta una ejemplo
de documento WML que incluye una única carta en el mazo y su visualiza-
ción (dependiendo de las dimensiones y tipos de letra del mismo).
FIGURA 14.7. Ejemplo de emulador DeckIt.
TABLA 14.9. Un ejemplo de documento WML y su visualización en un terminal
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<!– – Muestra un mensaje en el micro-navegador– –>

<card>
<p>
Mi primera aplicacion WAP
</p>
</card>
</wml>
FIGURA 14.8. Representación visual del documento de la tabla 14.9.

Todos estos ejemplos de lenguajes de marcado se basan en la definición

de la estructura de los elementos, indicando cuáles existen en el dominio del
documento y como participan en él, es decir lo que anteriormente se ha deno-
minado lenguajes de marcado genéricos. Pero estos lenguajes de marcado se
complementan con otros lenguajes que se utilizan para describir cual es la
apariencia final en el soporte físico de visualización.
14.2. LENGUAJES DE PRESENTACIÓN

Manteniendo en mente la separación entre los contenidos del documento
y la presentación del documento, hasta el momento se han mostrado una
panorámica de los primeros. A continuación, se presentan una serie de len-
guajes que permiten realizar el segundo de los procesos, la presentación, de
manera que se pueda homogeneizar la visualización de los documentos inde-
pendientemente del contenido que incluyan.
DEFINICIÓN: Los lenguajes de presentación.

• Los lenguajes de presentación son aquellos que sirven para definir las características
de presentación que finalmente tendrá la información contenida en los documentos.
14.2.1. DSSSL Document Style Semantics and Specification

Language
Un ejemplo es DSSSL que tiene como objetivo definir el nivel de presen-
tación independientemente de los sistemas de procesamiento, con lo cual el
usuario puede especificar el aspecto de cada uno de los elementos de la DTD.
Este lenguaje normalmente se utiliza en combinación con HyTime indicando
la apariencia de los objetos definidos en sus documentos.
14.2.2. CSS Cascading Style Sheets

Otro ejemplo, de uso más extendido, es CSS que define la apariencia de
los elementos HTML o XML que se muestran en un navegador Web. La idea
básica en este tipo de lenguaje es el uso de la página física sobre la que se defi-
nen algunas características de su apariencia, como puede ser la posición de
un contenido o la tipografía utilizada.
14.2.3. XSL Extensible Stylesheet Language

Un paso más adelante es XSL que, ampliando las ideas de los dos lengua-
jes anteriores y basando su descripción en XML, permite la definición de la
presentación de documentos XML. El proceso de construcción consiste en

dos pasos. En el primero se transforma el documento XML expandiendo el
documento y calculando aquellos apartados dependientes del estilo (por
ejemplo, tipo de ordenación de una lista, inclusión de un índice de conteni-
dos, etc.). En el segundo paso, se prepara el documento para ser presentado
en el dispositivo de visualización (navegador, impresora, teléfono móvil, etc.)
adaptándolo a las características propias del dispositivo.
Para realizar la primera de las tareas, la transformación, se utiliza el len-
guaje XSLT (XSL Transformations) que describe las reglas de transformación
asociando patrones con plantillas de manera que cada transformación esta-
blece un documento XML distinto. En el siguiente ejemplo, se muestra un
documento XML que contiene varios mensajes (en el apartado a) de la tabla
14.10). Como ya se ha dicho a este documento se le puede aplicar diversas
transformaciones, como por ejemplo la primera que se muestra (en el apar-
tado b) de la tabla 14.10), que consiste en mostrar todos los elementos de
cada uno de los mensajes o la segunda de ellas (en el apartado c) de la tabla
14.10) en la que la transformación consiste en mostrar unicamente el emisor
del mensaje y el cuerpo del mismo.
TABLA 14.10. Un documento XML y dos posibles transformaciones de ese documento
<?xml version="1.0"?> <xsl:stylesheet <xsl:stylesheet

<!DOCTYPE mensajes SYSTEM xmlns:xsl="http://www.w3.org/TR/WD- xmlns:xsl="http://www.w3.org/TR/WD-
"mensaje.dtd"> xsl"> xsl">
<?xml-stylesheet type="text/xsl" href= <xsl:template match="/"> <xsl:template match="/">
"mensajetemplate.xsl" ?> <xsl:apply-templates/> <xsl:apply-templates/>
<mensajes> </xsl:template> </xsl:template>
<mensaje fecha="27/02/2003"> <xsl:template match="mensajes"> <xsl:template match="mensajes">

<para>Ana</para> <xsl:apply-templates <xsl:apply-templates select="mensaje"
<de>Susana</de> select="mensaje" /> />
<asunto>Recordatorio</asunto> </xsl:template> </xsl:template>
<texto>No te olvides...</texto>
</mensaje> <xsl:template match="mensaje"> <xsl:template match="mensaje">
<xsl:apply-templates select="para"/> <xsl:apply-templates select="de"/>
<mensaje fecha="27/02/2003"> <xsl:apply-templates select="de"/> <xsl:apply-templates select="texto"/>
<para>David</para> <xsl:apply-templates select="asunto"/> </xsl:template>
<de>Susana</de> <xsl:apply-templates select="texto"/>
<asunto>Comer</asunto> </xsl:template> <xsl:template match="de">
<texto>voy a las 2?</texto> De:<xsl:value-of select= "."/>
</mensaje> <xsl:template match="para"> </xsl:template>
Para:<xsl:value-of select= "."/>
</mensajes> </xsl:template> <xsl:template match="texto">
Texto:<xsl:value-of select= "."/>
<xsl:template match="de"> </xsl:template>
De:<xsl:value-of select= "."/>
</xsl:template> </xsl:stylesheet>
<xsl:template match="asunto">
Asunto:<xsl:value-of select= "."/>
</xsl:template>
<xsl:template match="texto">
Texto:<xsl:value-of select= "."/>
</xsl:template>
</xsl:stylesheet>
a) b) c)
El segundo de los procesos mencionados anteriormente, la presentación

del documento, consiste en relacionar los elementos que conforman el docu-
mento con la presentación que se quiere realizar. Esto quiere decir que, por
ejemplo, el mismo documento transformado puede ser visto de distintas
maneras, por ejemplo, dependiendo del tipo de dispositivo con el que se acce-
da a la información.
14.3. MODELADO DE MUNDOS VIRTUALES UTILIZANDO

VRML
La realidad virtual consiste en recrear una realidad de una manera vir-

tual. La virtualidad puede tener muchos niveles en función del grado de
inmersión que el usuario pueda llegar a realizar en esa realidad, es decir,
como sus sentidos participan en la realidad recreada, como por ejemplo si la
realidad es un jardín de rosas si se recrea el aroma, el tacto, el espacio, etc. Es
decir, no se trata de una mera representación gráfica tridimensional estática,
sino más bien de un escenario, donde el usuario puede adentrarse, rodear los
objetos y examinarlos, cambiar la perspectiva e incluso interactuar con otros
usuarios, representados bajo la forma de avatares. La realidad virtual de
escritorio hace referencia a aquella en la que el grado de inmersión es nulo ya
que consiste en recrear en la pantalla espacios de tres dimensiones por los
que el usuario puede moverse mediante el uso de un ratón, joystick, etc.
VRML (Virtual Reality Modeling Language) es un lenguaje de modelado
con el que se puede generar esta realidad virtual de escritorio mediante la
definición de mundos interactivos en Internet. A estos mundos se les deno-
mina mundos «virtuales» porque los usuarios pueden interactuar con los
objetos de una forma similar a como lo hacen en el mundo real.
Aunque su nombre es similar al de los lenguajes de marcado menciona-
dos anteriormente, se diferencia de ellos en el cambio de la palabra «marca-
do» por «modelado», la cual hace referencia al carácter gráfico, y por lo tan-
to, bastante más complejo, de este lenguaje. Mientras que en el caso de los
lenguajes de marcado se «marca» o «etiqueta» el texto para darle formato, en
el caso del VRML se requiere una mayor planificación, así como una cierta
habilidad para la programación.
La manera más habitual de acceder a estos mundos virtuales es por
medio de un navegador tradicional de Web al que se le ha instalado un conec-
tor (plugin) de VRML que interprete los comandos del lenguaje, y permita
adentrarse e interactuar con el mundo virtual. Uno de los más conocidos de
estos conectores es Cortona de la empresa Parrallel Graphics.
Este tipo de aplicaciones son muy utilizadas en entornos de entrenamiento
ya que facilitan el aprendizaje con un costo muy inferior al que tendría en
situaciones reales. Algunos ejemplos en los que el uso de estas aplicaciones se

han generalizado son:
• Arquitectura/urbanismo: Visitas virtuales, urbanismo, agencias inmo-
biliarias. Ejemplo: visita virtual por Glasgow:
• http://iris.abacus.strath.ac.uk/gary/Miscellaneous/final/
• Industria: presentación de objetos (diseño), explicación del funciona-
miento o del montaje, robótica. Ejemplo: diseño de distintos artefactos
mecánicos en:
• http://www.bergen.org/Present/TechnologyHighSchool/Active/
design_projects.html
• Arte: galerías, música, escenas, instalaciones virtuales. Ejemplo: Museo
de la Casa de la Moneda (España) en:
• http://www.fnmt.es/esp/museo/evisita.htm
• Ciencia: astronomía, física, química, matemáticas, medicina, etc.
Ejemplo: modelos moleculares complejos en:
• http://www.ch.ic.ac.uk/rzepa/vrml/
• Cultura: museos y bibliotecas virtuales reconstrucción arqueológica,
teatro. Ejemplo: Museo interactivo de la Casa de la Moneda en España:
• http://www.fnmt.es/esp/museo/evisita.htm
• Educación: presentación de temas, interacción, bibliotecas. Ejemplo:
sistema educativo sobre las barreras arquitectónicas para discapacita-
dos en:
• http://www.health.uottawa.ca/vrlab/start.html
• Comercio electrónico: galerías comerciales, demostración de produc-
tos, gráficos comerciales, aplicaciones interactivas para construir el
producto (v.g. diseñe su cocina). Ejemplo: joyería en Internet:
• http://www.fabric8.com/jigowat/
Para crear un mundo de realidad virtual se utiliza un fichero de texto, cre-
ado con un procesador cualquiera de textos que se debe guardar con la exten-
sión .wrl. Este fichero constituye un documento VRML, que será ejecutado por
el visualizador, de manera completamente análoga a los documentos HTML,
que son ficheros de texto con la extensión .html y que son ejecutados por los
navegadores para visualizar las páginas del Web. También se pueden crear
estos documentos utilizando ciertos programas editores de VRML, que los
generan automáticamente, sin necesidad de saber programar en este lenguaje.
En líneas generales, un documento VRML contiene los siguientes elemen-
tos: línea de cabecera, que contiene información sobre la versión de VRML se
está utilizando; escena, que es un grafo de nodos que describe las característi-
cas y comportamiento de los elementos de presentación; prototipos, que per-
miten al diseñador agrupar bajo un mismo elemento un conjunto de formas,
sensores, interpoladores y comportamientos; y sentencias de ruta, que permi-
ten encaminar los eventos entre distintos nodos.
En la tabla 14.11 se puede ver un ejemplo de definición de mundo virtual,
en concreto de un mesa con cuatro patas, y de su visualización utilizando el
conector Cortona en el navegador Internet Explorer (figura 14.9).
TABLA 14.11. Ejemplo de mundo virtual definido con VRML
#VRML V2.0 utf8

Shape {
appearance Appearance {
material Material {
emissiveColor 0.5 0.2 0
}
}
geometry Box {
size 2.0 0.2 3.0
}
}
Transform {
translation -0.9 -0.85 -1.4
children [
DEF pata Shape {
appearance Appearance {
material Material {
emissiveColor 0.3 0.2 0
}
}
geometry Cylinder{
radius 0.05
height 1.5
}
}
]
}
Transform {
translation 0.9 -0.85 -1.4
children [
USE pata
]
}
Transform {
translation -0.9 -0.85 1.4
children [
USE pata
]
}
Transform {
translation 0.9 -0.85 1.4
children [
USE pata
]
}
FIGURA 14.9. La visualización del mundo virtual de la tabla 11.
14.4. RESUMEN
En este capítulo se han presentado los lenguajes de marcado como herra-
mienta a la hora de implementar un sistema en Web. Se han separado los len-
guajes de marcado orientados a la definición de la estructura del documento y
los orientados a su presentación. Entre los primeros, los de definición de la
estructura del documento, se considera que SGML es el padre del conjunto de
lenguajes que se están utilizando en la actualidad para crear aplicaciones para
Web, como por ejemplo HTML, XML y XHTML. Los lenguajes de presentación
se encargan de presentar la información de acuerdo a un conjunto de reglas
que permiten especificar como se muestran los contenidos. Ejemplos de este
tipo de lenguajes son DSSSL, CSS y XSL. Por último, se ha presentado un len-
guaje de modelado, no de marcado, de mundos virtuales como es VRML.

14.1. Indique qué afirmación es la correcta:
a) Un lenguaje de marcado sirve únicamente para dar formato a los
contenidos de un documento.
b) Un lenguaje de marcado genérico sirve para indicar cuales son los

elementos de presentación del documento.
c) Existe un lenguaje de marcado de la presentación para cada tipo de
dispositivo que se vaya a utilizar.
d) SGML es un metalenguaje para crear lenguajes de marcado.
14.2. Entre las diferencias citadas entre un documento HTML y un docu-

mento XHTML, indique qué afirmación no es la correcta:
a) El orden de apertura de un elemento debe corresponder con el
orden de cerrado del mismo.
b) Las etiquetas deben de estar escritas en minúsculas.
c) HyTime es una aplicación de XML.
d) Todos los elementos de XHTML deben cerrarse, incluidos aquellos
que sean una única etiqueta.

a) CSS es un lenguaje para definir la presentación de los elementos de
un documento HyTime.
b) XSL es un lenguaje que indica como presentar documentos HTML.
c) XSL es un lenguaje basado en XML.
d) DSSSL sirve para especificar la estructura de los documentos
XHTML.

a) Sólo existe un tipo de realidad virtual.
b) VRML es un lenguaje que sirve para definir documentos con ele-
mentos en tres dimensiones.
c) VRML sirve para la creación de realidad virtual de escritorio.
d) VRML es una aplicación de SGML.
15.5. ¿Qué tipo de lenguaje de marcado es el más apropiado para un sistema

multimedia?
a) HTML
b) XHTML
c) XML
d) SMIL

BIRBECK (2001): M. Birbeck (Editor): Professional XML (Programmer to Program-
mer). Wrox.
DEROSE y DURAND (1994): S.J. DeRose y D.G. Durand: «Making Hypermedia Work:
HyTime». Kluwer Academic Publishers. Boston.
HERWIJNEN (1990): E. Van Herwijnen: «Practical SGML». Kluwer Academic Publis-
hers. Dordretch.
KENNEDY y SLOWINSKI (2000): T. Kennedy y M. Slowinski: SMIL add in multimedia to
the web. Sams Publishing.
(w3c, 2003) http://wwwçw3c.org.
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 Kos̆ice.
15.5. Sistemas de telepesentación y emisión remota de vídeo.
15.6. Resumen.
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 pre-
sentaciones, aplicaciones de trabajo cooperativo, etc. Por otro lado, el domi-
nio 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 auto-
res 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 sis-
tema.
En este capítulo, se describen ejemplos de desarrollo de sistemas multi-
media 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 aplica-
ciones 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
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 res-
to 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 don-
de 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 aplica-
ciones multimedia de red.
A su vez estos dos grandes grupos se subdividen en varios más (no exclu-
yentes), 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 multime-
dia. 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.
EJEMPLOS DE DESARROLLO DE SISTEMAS MULTIMEDIA 409
Aplicaciones de
comunicación
interpersonal
Aplicaciones de
Aplicaciones
distribución
Aplicaciones para la síncronas
comunicación entre
personas Aplicaciones de
teleconferencia en
grupo
Aplicaciones
asíncronas
Aplicaciones
Multimedia Aplicaciones de
respuesta simple
Aplicaciones
interactivas Aplicaciones de
interacción múltiple
Aplicaciones para la
comunicación entre
personas y sistemas Aplicaciones de
distribución a grupos
cerrados
Aplicaciones de
distribución
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 sis-

temas se pueden dividir según el tipo de acceso que se haga al sistema multi-
media 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 ocu-
rre, por ejemplo, en aplicaciones de video bajo demanda—, sin necesidad
de que el sistema haya iniciado la comunicación y sin restricción en cuan-
to 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
aplicaciones se pueden clasificar a su vez en aplicaciones de respuesta sim-

ple, 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 edu-
cativas, por poner un ejemplo.
Cuando se habla de aplicaciones de distribución se hace referencia a apli-

caciones multimedia donde la interacción la inicia el sistema multimedia, y
bien puede tratarse de aplicaciones de distribución a grupos cerrados o gru-
pos 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 distribu-
ció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 respon-

diendo al dominio de la aplicación. Un clasificación que responde a este cri-
terio es la que puede consultarse en (Gibbs y Tsichritzis, 1995). Según esta
clasificación, existen diversas categorías de aplicaciones multimedia: jue-
gos electrónicos, sistemas de presentación multimedia, herramientas de
autor para contenidos multimedia, sistemas de mensajería multimedia, sis-
temas de conferencia multimedia o aplicaciones de servicios multimedia,
que a su vez pueden dividirse en aplicaciones de servicios médicos, de ser-
vicios bancarios, aplicaciones educativas o aplicaciones de comercio in-
teractivo, por citar algunas. Cabe destacar que los tipos establecidos en la
clasificación que hacen Gibbs y Tsichritzis no pueden considerarse exclu-
yentes, puesto que una aplicación pueden pertenecer a más de uno; por
ejemplo, se puede considerar una aplicación multimedia educativa comple-
ja 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 Multime-
dia 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 mul-
timedia. Para conseguir tal fin, la clasificación se realiza de acuerdo a crite-
rios 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. 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 facili-
ten 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» virtua-
les 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 guia-
das 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 princi-
pales: «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,
pero otras, como la que se muestra en la figura 15.3 combinan audio con sub-
tí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 (correspon-

dientes 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 presenta-
ción es un servidor Web estándar, habiendo sido desarrolladas las pre-
sentaciones con la herramienta Flash 5 de Macromedia, y utilizando com-
presión MPEG para combinar varios canales de sonido. El equipo de
desarrollo estaba formado por estudiantes con conocimientos de publica-
ción en Web y multimedia, y los expertos de las diferentes instituciones
participantes trabajaron colaborativamente utilizando técnicas tan sim-
ples 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 servi-
cios médicos. Concretamente se construyen sistemas de información médica
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 mag-
né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, Europe-
an Multimedia Services for Medical Imaging) (Rahms y otros, 1997). El prin-
cipal objetivo de dicho proyecto es la creación de un servicio médico multi-
media 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 diferen-
tes escenarios diferenciados entre los que se incluye la radiología, la cardio-
logí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.

Para todos los escenarios actuales de uso la aplicación dispone de un con-

junto 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 procesa-
miento 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 multi-
media médicos, la aplicación contiene servicios síncronos, como la video-
conferencia, asíncronos, como la mensajería electrónica multimedia, e
interactivos, como la recuperación y procesamiento de imágenes e histo-
rias 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édi-
cas se realiza bajo el estándar DICOM 3.0, que define cómo se deben comu-
nicar 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. 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 Power-
Point. 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 corres-
pondientes 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 ser-
vicio 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 gru-
po 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.

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 Me-
dia 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 descargar-
los previamente por completo, permite administrar opciones de seguridad y
proporciona tecnologías que permiten el flujo inteligente (intelligent data stre-
aming), es decir, que la transmisión del flujo de medias se ajusta al ancho de
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 clien-
te 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 fun-
ciones 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 encuen-
tros, puesto que permiten que los participantes en las mismas no se encuen-
tren 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 obte-
ner 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 conferencian-
te, 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) per-
miten 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 acon-
tece 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 «hombres-
cámara» y el «director» se produce el intercambio de órdenes necesario
para obtener una grabación lo más correcta y profesional posible. Las órde-
nes 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.
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áma-

ras 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 nue-
vas 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 huma-
nos, de manera que los posibles usuarios podían observar en su interfaz (figu-
ra 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. RESUMEN
En este capítulo se realiza una descripción general de algunas aplicacio-
nes 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 necesa-
rio partir de algún tipo de taxonomía que permita clasificar la aplicación des-
crita 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 perso-
nas 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 aplica-
ció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 multi-
media 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 multime-
dia 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 cua-
tro servicios hospitalarios distintos utilizando redes ATM y servicios de vi-
deoconferencia, 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 recu-
perar 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 aplica-
ción está íntegramente diseñada utilizando tecnología Windows Media, tan-
to 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.

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 comunica-
ció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 aplicacio-

nes 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 aplicacio-
nes 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 des-

crita 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 pro-
tocolo 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ín-
crona.
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?
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.

FLUCKIGER (1995): Fluckiger, F. Understanding Networked Multimedia: Applications
and Technology. Prentice-Hall Europe, 1995.
GEORGANAS, (1997): Georganas, N.: Multimedia Applications Development: Experien-

ces. 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 Inform-
taion 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 Tech-
niques For Assessing Audio And Video Quality In Real-Time Interactive Commu-
nications. Tutorial realizado en Human Computer Interaction 2001 IHM-HCI
2001, Lille, Francia, 2001. Disponible en: http://www-mice.cs.ucl.ac.uk/multime-
dia/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://first-
monday.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 Telepresen-
tations, 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.

ANEXO

SOLUCIONES A LOS EJERCICIOS DE AUTOCOMPROBACIÓN:
Capítulo 1:
1.1. b)
1.2. b)
1.3. d)
1.4. a)
1.5. b)
Capítulo 2:
2.1. d)
2.2. b)
2.3. c)
2.4. a)
2.5. a)
Capítulo 3:
3.1. a)
3.2. d)
3.3. b)
3.4. a)
3.5. c)
Capítulo 4:
4.1. b)
4.2. c)
4.3. c)
4.4. a)
4.5. b)
Capítulo 5:
5.1. a)
5.2. c)
5.3. b)
5.4. c)
5.5. d)
Capítulo 6:
6.1. b)
6.2. d)
6.3. c)
6.4. b)
6.5. d)
Capítulo 7:
7.1. b)
7.2. b)
7.3. d)
7.4. b)
7.5. d)
ANEXO 427
Capítulo 8:
8.1. c)
8.2. b)
8.3. d)
8.4. c)
8.5. b)
Capítulo 9:
9.1. b)
9.2. d)
9.3. c)
9.4. b)
9.5. d)
Capítulo 10:
10.1. b)
10.2. a)
10.3. d)
10.4. c)
10.5. d)
Capítulo 11:
11.1. d)
11.2. d)
11.3. b)
11.4. a)
11.5. c)
Capítulo 12:
12.1. b)
12.2. d)
12.3. a)
12.4. c)
12.5. d)
Capítulo 13:
13.1. c)
13.2. c)
13.3. b)
13.4. a)
13.5. d)
Capítulo 14:
14.1. d)
14.2. c)
14.3. c)
14.4. c)
14.5. d)
Capítulo 15:
15.1. b)
15.2. b)
15.3. b)
15.4. a)
15.5. d)
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
U.D. 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.
Unidad Didáctica
Paloma Díaz Pérez es licenciada y doctora en Informática por la Universidad Politécnica
A. Colmenar Santos M. A. Castro Gil

de Madrid, siendo en la actualidad catedrática de Universidad del Departamento de Informática
J. Peire Arroba
de la Universidad Carlos III de Madrid. Sus intereses se centran en el proceso de desarrollo de
F. Mur Pérez
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
Colecciones de la UNED 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
Cada vez son más y mejores las herramientas de edición comité ejecutivo de IEEE Learning Technology Task Force.
Unidades Didácticas multimedia disponibles en el mercado a precios razonables. 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
Cuadernos de la UNED Sin embargo, el mayor problema está en la formación adecuada
M. A. Sicilia Urbán P. Losada de Dios

desarrollado su labor docente e investigadora en ambas Universidades, estando actualmente en
A. Vara de Llano
la Universidad de Alcalá de Henares. Ha trabajado como consultor, tutor y arquitecto software
Aula Abierta de los autores potenciales de trabajos multimedia. Se pretende 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
con este libro presentar, de forma clara y sistemática, las líneas la incertidumbre.
Estudios de la UNED de acción principales de análisis, diseño y evaluación de una 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
Actas y Congresos aplicación multimedia. 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
Estudios de Educación a Distancia La obra Sistemas Multimedia: análisis, diseño y evaluación 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
va permitir al lector interesado: Ferroviarios de RENFE. Es profesor asociado de la E.T.S. de Ingenieros Industriales de la UNED
Educación Permanente • Analizar los requisitos de los sistemas multimedia, y su
y sido durante 1 año profesor asociado en la E.T.S. de Ingenieros Industriales de la Universidad
I. Aedo Cuevas
Politécnica de Madrid y durante 4 años profesor asociado en la Escuela Politécnica Superior de
la Universidad Carlos III de Madrid.
P. Díaz Pérez
integración en los sistemas de información actuales. Antonio Colmenar Santos es doctor Ingeniero Industrial e Ingeniero Industrial, especialidad
• Identificar los distintos componentes de éstos, así como 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
las distintas plataformas de distribución existentes: CD- 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
ROM, Intranet, Internet, etc. y de Control DIEEC de la UNED. Ha sido profesor asociado en el Departamento de Tecnología
• Promover la capacidad de diseño de sistemas, su

interrelación con la interfaz de usuario y los requisitos
SISTEMAS MULTIMEDIA: 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
del mismo.
• Evaluar los diferentes sistemas multimedia utilizados en
Ingeniería
en Informática
ANÁLISIS, DISEÑO 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.
los actuales sistemas de información.
Para ello se incluyen los siguientes contenidos temáticos: (2º ciclo) Y EVALUACIÓN 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
• Medios tradicionales y medios digitales de la información 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
(textos, sonidos, imagen, animación, vídeo, 3D, etc.). 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
• Análisis, diseño, evaluación y dirección de proyectos de 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,
sistemas multimedia y de la interfaz de usuario. impartiendo cursos de formación y realizando la gestión y el soporte de los servidores del
Departamento.
• Plataformas de difusión (CD-ROM, Intranet, Internet,
etc.). Integración de sistemas multimedia en la www.
Ignacio Aedo Cuevas 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
La obra incluye además, como valor añadido, un tema Paloma Díaz Pérez 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
específico de dirección y metodología de proyectos multimedia. Miguel Ángel Sicilia Urbán 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
ANÁLISIS, DISEÑO Y EVALUACIÓN

de Ingeniería Eléctrica, Electrónica y de Control, ETSII de la UNED.
¡Esperamos que el lector vea cumplidas sus expectativas…!
Alfonso Vara de Llano 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,
Antonio Colmenar Santos 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
Pablo Losada de Dios 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
Francisco Mur Pérez
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
ISBN 84-362-4996-8
Manuel Alonso Castro Gil 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
Juan Peire Arroba 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
UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA proyectos de investigación, tanto nacionales como internacionales. Es miembro del IEEE.

Sistemas Multimedia PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemas Multimedia PDF

Cargado por

Copyright:

Formatos disponibles

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

A. Colmenar Santos M. A. Castro Gil

M. A. Sicilia Urbán P. Losada de Dios

• Promover la capacidad de diseño de sistemas, su

ANÁLISIS, DISEÑO Y EVALUACIÓN

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

Quedan rigurosamente prohibidas, sin la autorización escrita

Librería UNED: Bravo Murillo, 38; 28015 Madrid

1.1. La comunicación a distancia .......................................................... 21

2.8. Formatos de sonido ......................................................................... 57

3.1. Las animaciones. Principios, herramientas y técnicas de animación . 70

4.1. Ingeniería del software y multimedia............................................... 110

5.1. La etapa de análisis de requisitos en el desarrollo multimedia...... 136

6.1. La interfaz de usuario........................................................................ 163

6.3. Estilos de la interacción .................................................................... 171

7.1. El concepto de usabilidad ................................................................. 192

8.1. Proyectos .......................................................................................... 216

9.1. Now-Graduado: ejemplo de análisis y diseño .................................. 261

10.1. Arquitectura general de los sistemas multimedia.......................... 286

11.1. La arquitectura Web y los sistemas multimedia............................ 310

12.1. Herramientas para la programación multimedia .......................... 333

13.1. ¿Qué es una herramienta de autor?................................................ 360

13.5. La tecnología Flash .......................................................................... 373

14.1. Lenguajes de marcado genéricos .................................................... 384

15.1. Tipos de aplicaciones multimedia................................................... 407

El término que aparece con mayor frecuencia en los medios de comuni-

apretar un botón de vez en cuando. Es la característica que les distingue, por

modelado, animación, render y composición, y proporcionan algunos conse-

rrollo goza de todas las características que definen un proyecto en su sentido

mercado, no se pretende elaborar un catálogo de la mismas, sino que se ha

1.1. La comunicación a distancia.

1.1. LA COMUNICACIÓN A DISTANCIA

1.1.1. Las primeras telecomunicaciones

La necesidad de las comunicaciones a distancia es tan antigua como la

como los cambios tecnológicos provocan modificaciones sociales, y vicever-

1.1.2. El telégrafo óptico

Así, después de las señales luminosas, se produce ya entrado el siglo XVIII

suponerse, para transmitir un mensaje, que necesariamente debía ser corto,

1.1.3. El telégrafo de señales eléctricas

Uno de los primeros experimentos que se realizaron fue en Aranjuez. El

Cuesta imaginar, lo que sería hoy día transmitir la información a distan-

Pero será en el año 1837 cuando se va a producir un avance significativo

1.1.4. La radio y el teléfono

El siguiente paso estaba cantado, lo que la sociedad demandaba era

transmitió con la TV en color, por supuesto ¡también mecánica! En 1937 la

1.1.6. La electrónica al servicio de la comunicación

Queda por explicar la parte electrónica, cómo y cuándo nace la electró-

popularizarse los PCs (ordenadores personales). Sin embargo, socialmente

1.2. LA REVOLUCIÓN DE LAS COMUNICACIONES. INTERNET

Si se analizan hoy día los periódicos aparecen casi a diario referencias a

A partir de esta fecha se suceden los cambios de denominación y los usos

1.3. SISTEMAS Y PROCESADO DE LA INFORMACIÓN:

1.4. EL CONCEPTO DE MULTIMEDIA

vocablo multimedia y su evolución desde varias múltiples perspectivas:

1.4.1. Perspectiva empresarial

Para autores centrados en la temática de los Medios de Comunicación de

1.4.2. Perspectiva de la pluralidad mediática

La pluralidad mediática al hablar de multimedia, destaca la literalidad

1.4.3. Perspectiva informática

En muchos catálogos de productos informáticos se encuentra el vocablo

1.4.4. Perspectiva contemporánea

En las últimas reuniones nacionales e internacionales, así como en Con-