Sistemas Multimedia

55521UD01A01 55521UD01A01 55521UD01A01 Ignacio Aedo Cuevas es doctor en Informtica por la Universidad Politcnica de Madrid
lleva trabajando en el campo de la hipermedia desde 1990, participando en numerosos proyectos

internacionales, nacionales y regionales tanto con financiacin pblica como privada en el rea
de sistemas interactivos. Es autor de ms de cien artculos y congresos tanto nacionales como
U.D. internacionales, siendo adems miembro del consejo editor de la revista IFETS&IEEE LTTF
Journal of Educational Technology and Society. En la actualidad es catedrtico de Universidad del
Departamento de Informtica de la Universidad Carlos III de Madrid.
Unidad Didctica
Paloma Daz Prez es licenciada y doctora en Informtica por la Universidad Politcnica
A. Colmenar Santos M. A. Castro Gil

de Madrid, siendo en la actualidad catedrtica de Universidad del Departamento de Informtica
J. Peire Arroba
de la Universidad Carlos III de Madrid. Sus intereses se centran en el proceso de desarrollo de
F. Mur Prez
sistemas interactivos as como en la incorporacin de las tecnologas de la informacin y de las
comunicaciones en el proceso de aprendizaje, habiendo participado en numerosos proyectos
Colecciones de la UNED relacionados con estos temas. Adems, es autora de numerosos artculos internacionales en las
revistas ms prestigiosas en los mbitos de su inters (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 informticos y con la hipermedia. Es miembro del
Cada vez son ms y mejores las herramientas de edicin comit ejecutivo de IEEE Learning Technology Task Force.
Unidades Didcticas multimedia disponibles en el mercado a precios razonables. Miguel ngel Sicilia Urbn es doctor Ingeniero en Informtica por la Universidad Carlos
III de Madrid e Ingeniero en Informtica por la Universidad Pontificia de Salamanca. Ha
Cuadernos de la UNED Sin embargo, el mayor problema est en la formacin adecuada
M. A. Sicilia Urbn 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 imprecisin y
con este libro presentar, de forma clara y sistemtica, las lneas la incertidumbre.
Estudios de la UNED de accin principales de anlisis, diseo y evaluacin de una Alfonso Vara de Llano es Ingeniero Industrial por la Escuela Tcnica Superior de Ingenieros
Industriales de la Universidad Politcnica de Madrid, en la especialidad Electricidad, intensificacin
Actas y Congresos aplicacin multimedia. Electrotecnia. Actualmente es gerente de Proyectos en la Divisin de Servicios Profesionales de
Compaq, recientemente fusionada con Hewlett Packard. Anteriormente ha trabajado como Jefe
Estudios de Educacin a Distancia La obra Sistemas Multimedia: anlisis, diseo y evaluacin de Proyectos en UITESA (actualmente integrada en IBERINCO perteneciente a al grupo
IBERDROLA) y como ingeniero en el Laboratorio de Ensayos Dinmicos de Vehculos
va permitir al lector interesado: Ferroviarios de RENFE. Es profesor asociado de la E.T.S. de Ingenieros Industriales de la UNED
Educacin Permanente Analizar los requisitos de los sistemas multimedia, y su
y sido durante 1 ao profesor asociado en la E.T.S. de Ingenieros Industriales de la Universidad
I. Aedo Cuevas
Politcnica de Madrid y durante 4 aos profesor asociado en la Escuela Politcnica Superior de
la Universidad Carlos III de Madrid.
P. Daz Prez
integracin en los sistemas de informacin actuales. Antonio Colmenar Santos es doctor Ingeniero Industrial e Ingeniero Industrial, especialidad
Identificar los distintos componentes de stos, as como Electrnica y Automtica por la ETSII de la UNED e Ingeniero Tcnico Industrial por la Escuela
Universitaria de Ingeniera Tcnica Industrial de la Universidad de Valladolid, especialidad
las distintas plataformas de distribucin existentes: CD- Electricidad, intensificacin Electrnica, Regulacin y Automatismos. Actualmente es Profesor
titular en el rea de Ingeniera Elctrica del Departamento de Ingeniera Elctrica Electrnica
ROM, Intranet, Internet, etc. y de Control DIEEC de la UNED. Ha sido profesor asociado en el Departamento de Tecnologa
Promover la capacidad de diseo de sistemas, su

interrelacin con la interfaz de usuario y los requisitos
SISTEMAS MULTIMEDIA: Electrnica en la Universidad Politcnica de Alcal de Henares y en el DIEEC de la UNED.
Es profesor titular en excedencia del cuerpo de Profesores de Educacin Secundaria y de Profesores
Tcnicos de Formacin Profesional en las especialidades de Sistemas Electrnicos y Equipos
Elctricos, respectivamente. Ha trabajado para la AECI-ICI como experto asesor en el proyecto
INTECNA (Nicaragua). Es miembro de la seccin espaola de la International Solar Energy
del mismo.
Evaluar los diferentes sistemas multimedia utilizados en
Ingeniera
en Informtica
ANLISIS, DISEO Society (ISES) y ha trabajado en diferentes proyectos relacionados con las energas renovables.
Ha pertenecido a la Association for the Advancement of Computing in Education. Es experto en
aplicaciones de Sistemas Multimedia y posee diferentes publicaciones prcticas apoyndose en
estas tcnicas. Actualmente, es Coordinador de Virtualizacin en la ETSII de la UNED.
los actuales sistemas de informacin.
Para ello se incluyen los siguientes contenidos temticos: (2 ciclo) Y EVALUACIN Pablo Losada de Dios es Ingeniero Tcnico de Telecomunicaciones por la Escuela
Universitaria de Ingenieros Tcnicos de Telecomunicacin de la Universidad Politcnica de
Madrid, en la especialidad de Imagen y Sonido. Ha obtenido el Premio a los mejores Materiales
Didcticos en Ciencias Experimentales del Consejo Social de la UNED en 1998. Posee los
Medios tradicionales y medios digitales de la informacin ttulos de Postgrado de Especialista Universitario en Comunicaciones: Redes, Servicios e InfoVa,
Desarrollo de Aplicaciones Multimedia: Aplicaciones para InfoVa y Sistemas de Gestin de
(textos, sonidos, imagen, animacin, vdeo, 3D, etc.). Bases de Datos, todos otorgados por la UNED. Ha realizado los cursos oficiales de Microsoft
de administracin y gestin de Redes NT. En la actualidad trabaja en la UNED como Tcnico
Anlisis, diseo, evaluacin y direccin de proyectos de Especialista para el apoyo informtico del profesorado del Departamento de Ingeniera Elctrica,
Electrnica y de Control de dicha Escuela, colaborando en proyectos del departamento,
sistemas multimedia y de la interfaz de usuario. impartiendo cursos de formacin y realizando la gestin y el soporte de los servidores del
Departamento.
Plataformas de difusin (CD-ROM, Intranet, Internet,
etc.). Integracin de sistemas multimedia en la www.
Ignacio Aedo Cuevas Francisco Mur Prez es doctor Ingeniero Industrial por la Escuela Tcnica Superior de
Ingenieros Industriales de la UNED e Ingeniero Industrial, especialidad Electricidad, intensificacin
La obra incluye adems, como valor aadido, un tema Paloma Daz Prez Electrnica y Automtica por la Escuela Tcnica Superior de Ingenieros Industriales de la
Universidad Politcnica de Madrid. Ha obtenido el Premio Extraordinario de Doctorado de la
especfico de direccin y metodologa de proyectos multimedia. Miguel ngel Sicilia Urbn UNED. Ha obtenido el Premio a los mejores Materiales Didcticos en Ciencias Experimentales
del Consejo Social de la UNED en el ao 1999. Actualmente es profesor titular en el Departamento
ANLISIS, DISEO Y EVALUACIN

de Ingeniera Elctrica, Electrnica 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 Tcnica Superior
de Ingenieros Industriales de la Universidad Politcnica de Madrid (UPM) e Ingeniero Industrial,
Antonio Colmenar Santos especialidad Electricidad, intensificacin Electrnica y Automtica, 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 aportacin a la Investigacin Cientfica sobre Aplicaciones de la
Electricidad en los Procesos Industriales. Ha obtenido el Premio a los mejores Materiales
Didcticos en Ciencias Experimentales del Consejo Social de la UNED en los aos 1997 y
Francisco Mur Prez
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 ao 2001. Actualmente es
Catedrtico de Universidad del rea de Tecnologa Electrnica en el Departamento de Ingeniera
ISBN 84-362-4996-8
Manuel Alonso Castro Gil Elctrica, Electrnica y de Control, ETSII de la UNED, a la vez que es Vicerrector de Nuevas
Tecnologas de la UNED. Ha sido Director del Centro de Servicios Informticos de la UNED
Juan Peire Arroba y Subdirector de Investigacin y Doctorado, y de Gestin Acadmica de la ETSII. Ha participado
en numerosos proyectos de investigacin 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 lneas de investigacin y docencia. Ha trabajado cinco
aos 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 direccin de ISES Espaa.
Juan Peire Arroba es doctor Ingeniero Industrial por la Escuela Tcnica Superior de
Ingenieros Industriales de la Universidad Politcnica de Madrid e Ingeniero Industrial, especialidad
Electricidad por la misma Escuela. Licenciado en Derecho por la Universidad Complutense de
Madrid. Actualmente es Catedrtico de Universidad del rea de Tecnologa Electrnica en el
Departamento de Ingeniera Elctrica, Electrnica y de Control, ETSII de la UNED. Ha sido
Director del Departamento. Ha obtenido el Premio a los mejores Materiales Didcticos en
Ciencias Experimentales del Consejo Social de la UNED en los aos 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 ao 1999. Ha trabajado varios aos como Consultor
especializado en la creacin de Empresas Tecnolgicas, as como ha dirigido y dirige diversos
UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA proyectos de investigacin, tanto nacionales como internacionales. Es miembro del IEEE.
SISTEMAS MULTIMEDIA: ANLISIS, DISEO
Y EVALUACIN
UNIDADES DIDCTICAS
Ignacio Aedo Cuevas Pablo Losada de Dios
Paloma Daz Prez Francisco Mur Prez
Miguel ngel Sicilia Urbn Manuel Alonso Castro Gil
Alfonso Vara de Llano Juan Peire Arroba
Antonio Colmenar Santos
ANLISIS, DISEO
Y EVALUACIN
UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

UNIDADES DIDCTICAS (55521UD01A01)
SISTEMAS MULTIMEDIA: ANLISIS, DISEO Y EVALUACIN
Quedan rigurosamente prohibidas, sin la autorizacin escrita

de los titulares del Copyright, bajo las sanciones establecidas en las leyes,
la reproduccin total o parcial de esta obra por cualquier medio o procedimiento,
comprendidos la reprografa y el tratamiento informtico, y la distribucin
de ejemplares de ella mediante alquiler o prstamo pblicos.
UNIVERSIDAD NACIONAL
DE EDUCACIN A DISTANCIA - Madrid, 2004
Librera UNED: Bravo Murillo, 38; 28015 Madrid

Tels.: 91 298 75 60/73 73, e-mail: libreria@adm.uned.es
Ignacio Aedo, Paloma Daz, Miguel ngel Sicilia, Alfonso Vara, Antonio Colmenar,
Pablo Losada de Dios, Francisco Mur, Manuel Alonso Castro y Juan Peire
ISBN: 84-362-4996-8
Depsito legal: M. 5383-2004
Primera edicin: febrero de 2004
Impreso en Espaa - Printed in Spain
Imprime: LERKO PRINT, S.A.
Paseo de la Castellana, 121. 28046 Madrid

NDICE
Presentacin.............................................................................................. 13
CAPTULO 1
MULTIMEDIA Y COMUNICACIN. SISTEMAS MULTIMEDIA
1.1. La comunicacin a distancia .......................................................... 21

1.2. La revolucin de las comunicaciones. Internet ............................. 26
1.3. Sistemas y procesado de la informacin: Informtica.................. 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 diseo de un proyecto
multimedia ....................................................................................... 37
1.9. Resumen ........................................................................................... 40
1.10. Ejercicios de autoevaluacin........................................................... 41
1.11. Referencias bibliogrficas ............................................................... 42
CAPTULO 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 imgenes digitales ........................................................ 51
2.5. Formatos de archivos ...................................................................... 54
2.6. El sonido digital. Conceptos previos .............................................. 55
2.7. CD-AUDIO ........................................................................................ 56
8 SISTEMAS MULTIMEDIA: ANLISIS, DISEO Y EVALUACIN
2.8. Formatos de sonido ......................................................................... 57

2.9 Extraccin-Compresin-Reproduccin .......................................... 60
2.10. Resumen .......................................................................................... 62
CAPTULO 3
MEDIOS: ANIMACIN Y VDEO
3.1. Las animaciones. Principios, herramientas y tcnicas de animacin . 70

3.2. Imgenes en 3 dimensiones. Creacin y animacin........................ 78
3.3. Elementos bsicos para comenzar a digitalizar vdeo .................... 88
3.4. Edicin y efectos del vdeo digital .................................................... 95
3.5. Resumen ............................................................................................. 102
3.6. Ejercicios de autoevaluacin............................................................. 103
3.7. Referencias bibliogrficas ................................................................. 104
CAPTULO 4
FASES DEL DESARROLLO DE SISTEMAS MULTIMEDIA
4.1. Ingeniera del software y multimedia............................................... 110

4.2. Caractersticas 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 autevaluacin............................................................... 129
CAPTULO 5
ANLISIS Y DISEO DE SISTEMAS MULTIMEDIA
5.1. La etapa de anlisis de requisitos en el desarrollo multimedia...... 136

5.2. La especificacin de requisitos en el desarrollo multimedia .......... 137
5.3. La etapa de diseo en el desarrollo multimedia .............................. 145
5.4. Resumen ............................................................................................. 157
CAPTULO 6
DISEO DE UNA INTERFAZ DE USUARIO
6.1. La interfaz de usuario........................................................................ 163

6.2. Paradigmas de interaccin ................................................................ 165
NDICE 9
6.3. Estilos de la interaccin .................................................................... 171

6.4. Principios de diseo........................................................................... 174
6.5. Ejemplo de recomendaciones de interaccin para un sitio Web de
comercio electrnico.......................................................................... 176
6.6. Uso de la metfora ............................................................................. 183
6.7. Resumen ............................................................................................. 186
CAPTULO 7
EVALUACIN DE SISTEMAS INTERACTIVOS
7.1. El concepto de usabilidad ................................................................. 192

7.2. Mtodos de evaluacin ...................................................................... 199
7.3. El proceso de evaluacin ................................................................... 203
7.4. Parmetros para la evaluacin de sistemas multimedia ................. 208
7.5. Resumen ............................................................................................. 208
CAPTULO 8
DIRECCIN Y METODOLOGA DE PROYECTOS MULTIMEDIA
8.1. Proyectos .......................................................................................... 216

8.2. Direccin 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. Ejecucin del plan de proyecto....................................................... 245
8.7. Monitorizacin y control del proyecto ........................................... 250
8.8. Cierre del proyecto........................................................................... 253
8.9. Resumen ........................................................................................... 256
CAPTULO 9
EJEMPLOS DE DESARROLLO
9.1. Now-Graduado: ejemplo de anlisis y diseo .................................. 261

9.2. Ejemplo de evaluacin de la usabilidad ........................................... 272
9.3. Resumen ............................................................................................. 279
9.4. Ejercicios de autevaluacin............................................................... 279
CAPTULO 10
ARQUITECTURA Y CONFIGURACIN 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 especfico para aplicaciones multimedia........ 299
10.6. Diseo arquitectnico para sistemas multimedia.......................... 300
10.7. Resumen ........................................................................................... 302
CAPTULO 11
INTEGRACIN 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
CAPTULO 12
LENGUAJES DE PROGRAMACIN PARA SISTEMAS MULTIMEDIA
12.1. Herramientas para la programacin multimedia .......................... 333

12.2. Uso de lenguajes de propsito especfico ....................................... 335
12.3. Uso de lenguajes de propsito general ........................................... 340
12.4. Criterios de seleccin ....................................................................... 353
12.5. Resumen ........................................................................................... 354
CAPTULO 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 tecnologa Flash .......................................................................... 373

13.6. Director ............................................................................................. 377
13.7. Resumen ........................................................................................... 378
13.9. Referencias biblogrficas................................................................. 380
CAPTULO 14
LENGUAJES DE MARCADO Y DE PRESENTACIN
14.1. Lenguajes de marcado genricos .................................................... 384

14.2. Lenguajes de presentacin .............................................................. 397
14.3. Modelado de mundos virtuales utilizando VRML ......................... 399
14.4. Resumen ........................................................................................... 402
CAPTULO 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. Telediagnstico y otros servicios multimedia en medicina: proyecto
EMERALD ........................................................................................ 412
15.4. VIDEOSERVER: Experiencia en la Universidad de Kosice.......... 415
15.5. Sistemas de telepresentacin y emisin remota de vdeo ............. 417
15.6. Resumen ........................................................................................... 419
ANEXO
SOLUCIONES A LOS EJERCICIOS DE AUTOCOMPROBACIN .... 425

PRESENTACIN
El trmino que aparece con mayor frecuencia en los medios de comuni-

cacin es Multimedia. Una de las definiciones tecnolgicas para el con-
cepto de multimedia es la integracin de dos o ms medios distintos y el
ordenador personal. Los sistemas multimedia constituyen una nueva for-
ma de comunicacin que hace uso de diferentes medios como la imagen, el
diseo, el texto, grficos, voz, msica, animacin o vdeo en un mismo
entorno. La presentacin multimedia facilita utilizar la combinacin ptima
de medios para presentar la informacin en forma atractiva adecuada a
situaciones especificas, manteniendo la atencin del usuario y contribuyen-
do significativamente a facilitar y mejorar los procesos de Enseanza/Apren-
dizaje (E/A). Adems, permiten al usuario controlar cmo y cundo ha de
obtener acceso a esa informacin. En el multimedia se concentran las diver-
sas aportaciones de cada medio para un nico fin: la transmisin de un con-
cepto al usuario.
A travs del multimedia se posibilita la realizacin de un aprendizaje ms
interactivo, facilita un entorno hecho a la medida de los usuarios, logrando
que las interfaces sean menos fras, ms intuitivas y amigables. Mediante
estos sistemas se obliga al usuario a intervenir en el proceso de transferencia
de informacin, participando activamente en el mismo.
La interactividad es el nivel de relacin y de respuesta mutua entre usua-
rio y medio, es la caracterstica ms definitoria de los sistemas multimedia
educativos. Por desgracia, interactividad tambin es uno de los trminos de
los que ms han abusado los vendedores de equipos informticos, lo que ha
contribuido a crear cierta confusin de su significado. No pocas veces se han
presentado a bombo y platillo como interactivos programas informticos
que tan slo posibilitan un nivel mnimo de relacin entre el usuario y la
mquina. No se incrementa significativamente la interactividad y la partici-
pacin del alumno en la construccin de su aprendizaje porque tenga que
apretar un botn de vez en cuando. Es la caracterstica que les distingue, por

ejemplo, de la imagen en movimiento que combina grficos, sonido y texto, y
que encontramos en muchos programas de televisin, pero que no invitan al
usuario a tomar decisiones, a responder a preguntas, o a buscar informacin.
No es posible mantener con ellos una relacin recproca.
Este concepto de multimedia, tal y como hoy se entiende, constituye un
fenmeno relativamente nuevo en la actual sociedad de la informacin; esto
no debe ser excusa para seguir improvisando diseos o ir saliendo al paso
como cada uno puede de situaciones mas o menos apuradas a la hora de
implementar una aplicacin multimedia.
La obra Sistemas Multimedia: anlisis, diseo y evaluacin, que tiene
en sus manos, pretende afrontar del reto de formalizar y sistematizar las lne-
as de accin principales de anlisis, diseo y evaluacin implicadas en toda
aplicacin multimedia. Este libro incluye adems, como valor aadido, un
tema especfico de Direccin y metodologa de proyectos multimedia.
Las aplicaciones multimedia sern cada vez mejores si somos capaces de
dar la formacin adecuada a los potenciales autores de trabajos multimedia.
Para ello se ha escrito este libro, con la intencin de preparar a todas aquellas
personas que de una u otra forman vayan a formar parte de un equipo de cre-
acin de productos multimedia.
Para ello el captulo 1 comienza pasando revista a la historia de la apari-
cin de las diferentes formas de comunicacin, se podr observar la acelera-
cin vertiginosa que lleva la implantacin de estas nuevas tecnologas de la
informacin. Se pretende dejar bien claro el concepto de multimedia y las
posibilidades que esta ofrece, teniendo siempre en cuenta que el diseo y la
construccin de un proyecto multimedia van de la mano, y que con frecuen-
cia, los mejores resultados son producto de una retroalimentacin continua,
as como de modificaciones a lo largo del proceso de produccin.
Cuando el flujo de la informacin, que aparece en la pantalla del ordena-
dor, es controlable por el usuario, se empieza a hablar de hipertexto. En el
captulo 2 se muestran las bases para la confeccin 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 obtencin de imgenes digitales, as como
los principales formatos en los que estas pueden archivarse. A continuacin
se muestran los conceptos que proporcionan los fundamentos para poder
comprender el funcionamiento del sonido digital.
Con el estado actual de la tecnologa, cualquier usuario con un PC y una
videocmara puede realizar su aportacin al mundo de la edicin de vdeo.
En el captulo 3, se presentan los conceptos bsicos a tener en cuenta antes
de adentrarse en el mundo de la edicin del vdeo digital. Tambin se mues-
tra una ligera iniciacin al mundo de la animacin 3D. Se trata el proceso de
PRESENTACIN 15
modelado, animacin, render y composicin, y proporcionan algunos conse-

jos sobre la creacin de grficos y animacin 3D para el Web.
En el captulo 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 mtodos de ingeniera del software
que son aplicables al desarrollo de sistemas interactivos y en los que de algn
modo se recoge la experiencia adquirida por otros diseadores. Con este fin
se ve, entre otros temas, por qu de la utilizacin de ingeniera del software
en el desarrollo de aplicaciones multimedia.
En el captulo 5 se profundiza en el anlisis de requisitos para sistemas
multimedia as como en la etapa de diseo. Con este fin, se inicia este tema
con el objetivo del anlisis, para pasar a continuacin a profundizar en los
tipos de requisitos que se pueden encontrar en un sistema multimedia, las
tcnicas que pueden emplearse para recolectar informacin 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 captulo se cierra
con el estudio de las necesidades de modelado que presentan los productos
multimedia, enfocndolas en seis perspectivas: presentacin, estructura,
comportamiento, seguridad, funciones y navegacin.
Desde los aos ochenta, el diseo 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 captulo 6 se presentarn, en primer lugar, distintos
tipos de interfaces de usuario, as como varios paradigmas de interaccin,
para pasar a continuacin a presentar los estilos bsicos de interaccin. Tam-
bin se mostrarn las ocho reglas de oro para la construccin de una interfaz
y algunas recomendaciones para el desarrollo de sitios Web de comercio elec-
trnico, para finalizar introduciendo el concepto de metfora.
El objetivo del captulo 7 ser profundizar en qu consiste la evaluacin
de sistemas multimedia, qu tcnicas existen para evaluar y cundo debe o
puede utilizarse cada una de ellas, cmo puede realizarse el proceso de eva-
luacin y qu aspectos se puede analizar en l para obtener informacin
valiosa de cara a mejorar la interaccin con el sistema. Para ello se va a
comenzar analizando el concepto de usabilidad. A continuacin, se intentar
dar una visin de qu se entiende por evaluacin, viendo brevemente qu se
puede evaluar, por qu, cundo y cmo. Finalmente, se profundiza en la for-
ma de llevar a cabo la evaluacin presentando algunos mtodos de evalua-
cin, un proceso genrico para proceder con la evaluacin y algunos aspectos
que se pueden medir durante el proceso de evaluacin de un producto multi-
media.
Como valor aadido a este libro, en el captulo 8, se desgranan los con-
ceptos generales de Direccin y Administracin de Proyectos de uso total-
mente adaptado al desarrollo de un Sistema Multimedia. Este tipo de desa-
rrollo goza de todas las caractersticas que definen un proyecto en su sentido

ms amplio y son, por tanto, susceptibles de aplicarse todas las ideas que
aqu se exponen.
En el captulo 9 se muestran dos experiencias o casos prcticos, en pri-
mer, lugar, el desarrollo de Now-Graduado, un CD multimedia educativo
implementado con MacroMedia Director, haciendo hincapi en las fases de
anlisis, diseo e implementacin. Este ejemplo se ha considerado adecuado
porque tanto por las caractersticas del producto (tales como la inclusin 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 sistemtico en el que, independientemente de las restric-
ciones de recursos, se haga algn tipo de anlisis y de diseo conceptual
antes de pasar a la implementacin. A continuacin, se presentar como
ejemplo de evaluacin el caso de CESAR, un sistema hipermedia educativo,
cuya evaluacin permiti extraer tiles conclusiones no slo para mejorar el
propio producto sino tambin para el proceso de evaluacin.
En el captulo 10, se introducirn los elementos arquitectnicos ms
importantes desde el punto de vista de las aplicaciones multimedia. Se debe
tener en cuenta que la caracterizacin de estos sistemas no reside meramen-
te en el soporte de ms de un tipo de medio ya que, desde ese punto de vis-
ta una aplicacin con texto e imgenes sera multimedia, sino en determi-
nadas propiedades relacionadas con la combinacin de varios de esos
medios. Se expondrn primero los aspectos generales de las diferentes partes
que configuran la arquitectura de este tipo de sistemas, para terminar con
algunas nociones bsicas sobre cundo y de qu modo debe integrarse el
diseo arquitectnico dentro del ciclo de desarrollo de aplicaciones inte-
ractivas.
El captulo 11 ofrece una visin general de la multimedia en la Web,
comenzando por una revisin de la arquitectura general de la Web, y su ade-
cuacin para la multimedia, pasando despus a detallar cmo se integra la
multimedia en las aplicaciones Web. Se termina con una revisin de algunos
de los tipos de aplicaciones multimedia ms relevantes en este entorno.
En el captulo 12 se describen los rasgos generales de las opciones exis-
tentes y algunos criterios de seleccin, y se profundiza en el concepto de len-
guaje de programacin especfico para la multimedia, tomando como caso
concreto el del lenguaje ActionScript. Tambin se ilustra el uso de lenguajes
de programacin de propsito general con una visin panormica de las
bibliotecas que el lenguaje Java proporciona para el desarrollo de funcionali-
dades multimedia.
El captulo 13 analiza las herramientas de autor para productos multi-
media. Obviamente, dado el ingente nmero de herramientas existentes en el
PRESENTACIN 17
mercado, no se pretende elaborar un catlogo de la mismas, sino que se ha

optado por presentar algunas que se han considerado bastante representati-
vas y difundidas. El captulo se inicia con una breve introduccin al concep-
to de herramienta de autor, en el que se comentan clasificaciones de las mis-
mas, ya sea atendiendo al modelo de informacin o metfora que asumen, ya
sea atendiendo al paradigma de creacin de aplicaciones que ofrecen. A con-
tinuacin se describirn algunas herramientas de autor como son ToolBook,
Dreamweaver, Authorware, herramientas que soportan la tecnologa Flash o
Director.
En el captulo 14 se presentan un conjunto de lenguajes de marcado que
se utilizan habitualmente en los entornos Web y algunos lenguajes de pre-
sentacin que permiten adaptar la presentacin de la informacin contenida
en esos documentos. Adems, y para finalizar, se presenta VRML como len-
guaje de modelado que permite la definicin de mundos virtuales que permi-
ten al usuario navegar por la informacin en tres dimensiones.
Y finalmente, en el captulo 15 se describen ejemplos de desarrollo de sis-
temas multimedia concretos, con el objetivo de ofrecer una panormica de
los mtodos, tcnicas y herramientas de desarrollo que pueden utilizarse.

Captulo 1
MULTIMEDIA Y COMUNICACIN.
SISTEMAS MULTIMEDIA
ESQUEMA
1.1. La comunicacin a distancia.

1.2. La revolucin de las comunicaciones. Internet.
1.3. Sistemas y procesado de la informacin: Informtica.
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 diseo de un proyecto mul-
timedia.
1.9. Resumen.
1.10. Ejercicios de autoevaluacin.
1.11. Referencias bibliogrficas.
El inters que hoy en da despierta en la sociedad todo lo relativo a las
nuevas tecnologas de la comunicacin, los sistemas multimedia e Internet,
as como el inmenso abanico de oportunidades que ahora se abre, es conse-
cuencia del rpido progreso de las tecnologas de las telecomunicaciones y de
la informtica, as como, del masivo uso y abaratamiento de los ordenadores
personales.
Hoy en da a nadie sorprende la posibilidad de encender el ordenador y a
travs del mismo, utilizando las superautopistas de la informacin, realizar
las tutoras 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 resolucin de la ltima prueba presencial, del ltimo
examen, para los que no estn habituados a la terminologa especfica que se
utiliza en la UNED.
En el primer captulo de este libro, antes de abordar las posibilidades y limi-
taciones que estas tecnologas 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
aceleracin vertiginosa que lleva la implantacin de estas nuevas tecnologas.
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 diseo y la construccin de un proyecto multimedia van de
la mano. Aunque un proyecto multimedia no es ms que la combinacin de
texto, grficos, sonido y elementos de vdeo. Con frecuencia, los mejores
resultados son producto de una realimentacin continua, as como de modi-
ficaciones a lo largo del proceso de produccin.
1.1. LA COMUNICACIN A DISTANCIA
1.1.1. Las primeras telecomunicaciones
La necesidad de las comunicaciones a distancia es tan antigua como la

historia del hombre, un rpido viaje por la historia permitir comprender
como los cambios tecnolgicos provocan modificaciones sociales, y vicever-

sa. Cuando la sociedad se decide a introducir un cambio, se necesita desa-
rrollar una nueva aplicacin tecnolgica. Y a veces una nueva aplicacin tec-
nolgica, produce un cambio social.
La primera forma de comunicacin a distancia que se conoce, despus
del habla, o hablando con ms precisin, del grito, ha sido la utilizacin del
fuego en la noche o el humo en el da, o, en zonas donde la visibilidad era
muy reducida, la utilizacin de seales acsticas, como el clebre tam-tam
africano.
De esta manera existen multitud de ejemplos que ilustran estas prcticas,
as, ya Homero en la Ilada habla del fuego para sealar la llegada de una flo-
ta venida a socorrer a los sitiados de Troya. O en pocas ms recientes y con
una significacin muy especial para los espaoles, estn las seales de fuego
que utilizaron los ingleses para avisar de la llegada de la mal llamada Arma-
da Invencible en 1588.
Otras veces, la informacin, o la velocidad de su transmisin dependa de
la velocidad del mensajero, as el envo de palomas mensajeras, o la clebre
transmisin de la victoria griega en Maratn en el 490 a. C.
De esta forma, surgir otra forma de comunicacin, la del envo de men-
sajeros, correos, desde los reales de la Edad Media, hasta los envos que habi-
tualmente realiza la UNED a sus miles de estudiantes.
Sin embargo, el envo de correos, sea sobre papel, papiro o de palabra, ya
sea a caballo, en tren, coche o en avin, poco va a avanzar en el curso de la
historia, si no es por el avance de los medios de comunicacin. En definitiva,
en donde se van a producir los avances ms espectaculares y que van a cam-
biar el mundo, es con los modernos medios de comunicacin a distancia o
telecomunicacin (Peire, 2001).
1.1.2. El telgrafo ptico
As, despus de las seales luminosas, se produce ya entrado el siglo XVIII

el primer telgrafo, que, pese a lo que la gente puede pensar, no es el de Mor-
se, sino el sistema ptico de Claude Chappe. ste, se compona de una torre
con tres brazos articulados, y por combinaciones de las posiciones de los mis-
mos, reproduca letra a letra un mensaje. Algo muy similar a las indicaciones
que se utilizan en los cdigos de banderas en los barcos.
Este sistema inevitablemente deba disponer de torres situadas en las
zonas ms altas de la orografa de la zona. En cada torre deba existir un emi-
sor (el que realizaba las seales) y de un receptor (otra persona provista de su
correspondiente catalejo que deba interpretar las seales). De esta manera, y
de torre en torre se lograba transmitir un mensaje. Como es lgico y puede
MULTIMEDIA Y COMUNICACIN. SISTEMAS MULTIMEDIA 23
suponerse, para transmitir un mensaje, que necesariamente deba ser corto,

se requera tal cantidad de medios materiales y humanos que solo podan
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 Pars y Lille anunciando 1a reconquista de Quesno
por las tropas de la Repblica (Peire, 2001).
1.1.3. El telgrafo de seales elctricas
Despus del desarrollo de estos sistemas pticos, que desde luego no fun-
cionaba muy bien, en los pases ms septentrionales de Europa como Ingla-
terra y Suecia, se comprendi la necesidad de buscar un mtodo de comuni-
cacin 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-
nologas que actualmente imparte el Departamento de Ingeniera Elctrica,
Electrnica y de Control de la UNED.
Uno de los primeros experimentos que se realizaron fue en Aranjuez. El

sistema consista en transmitir seales elctricas al operador, el cual en fun-
cin de la intensidad y del sitio donde se le aplicaban las descargas elctricas
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 sera hoy da transmitir la informacin a distan-

cia, en una experiencia como las que habitualmente se realiza en la UNED,
realizando descargas elctricas sobre nuestros alumnos para poderles trans-
mitir nuestras enseanzas a distancia.
Pero ser en el ao 1837 cuando se va a producir un avance significativo

en la transmisin de la informacin. En estas fechas aparece Morse, el cual
propone un telgrafo distinto al ptico. Utiliza en vez de seales pticas,
seales elctricas, 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-
macin es muy sencilla: un cdigo digital que posteriormente se har suma-
mente popular, consiste en transmitir nicamente dos tipos de caracteres,
puntos y rayas. Este sistema rpidamente goza de una amplia aceptacin. Sin
embargo, la dependencia de un soporte fsico para su transmisin hacia nece-
sario buscar otros medios, sobre todo despus de que tras la inauguracin de
lo que se puede considerar la primera lnea martima 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 das, 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 contena oro en su interior (Peire, 2001).
1.1.4. La radio y el telfono
El siguiente paso estaba cantado, lo que la sociedad demandaba era

poder transmitir informacin sin necesidad de un soporte fsico, es decir,
conseguir la telegrafa sin hilos, sera Guillermo Marconi quien lo hara posi-
ble, por lo que obtuvo el premio Nobel de Fsica en el ao 1989, a la edad de
45 aos.
Una vez explicado cmo nacieron el correo y el telgrafo, el siguiente
paso que la Sociedad ya demandaba era el transmitir el habla a distancia.
Paradjicamente, lo que se buscaba en aquella poca no era tanto la
transmisin del habla, sino la posibilidad de enviar ms de una comunica-
cin sobre un mismo cable utilizando el cdigo Morse.
Fue el 14 de febrero de 1876, cuando Alejandro Graham Bell patent su
invento del telfono. Lo que no todos los historiadores cuentan es que E.
Gray realiz una patente del telfono slo dos horas despus, y lo que an
menos cuentan los historiadores es que el dispositivo que utiliz Bell al reali-
zar su famosa conexin de Dr. Watson venga aqu, le necesito, la realiz
segn un dispositivo similar a las patentes de Gray y distintas a las descritas
por l en sus patentes.
En 1886 funcionaban en Espaa tres redes exclusivamente urbanas per-
tenecientes a tres compaas 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
tecnologa de la ITT. Bajaron las tarifas y en diez aos se multiplic el nme-
ro de abonados llegndose a los 343.092. Para poner de manifiesto la lenti-
tud con la que se desarrolla el telfono basta decir que se necesitar casi un
cuarto de siglo para que en 1947 se instaurare el primer servicio telefnico
entre Madrid y Nueva York (Peire, 2001).
1.1.5. La televisin
Falta la TV. Lo que poca gente sabe hoy, es que los primeros televisores
que existieron fueron mecnicos, y funcionaban con un principio de funcio-
namiento que se puede considerar idntico al de las actuales TV. Estaban for-
madas por un disco con pequeos taladros dispuestos sobre una trayectoria
espiral. De esta manera por cada revolucin del disco se trazaban por toda la
imagen tantas lneas 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 electrnicos. Estas patentes datan de 1884.
La primera demostracin pblica de una TV fue en 1925 en Londres. Cua-
tro aos ms tarde comenzaba a emitir la clebre BBC. Incluso en 1928 se
transmiti con la TV en color, por supuesto tambin mecnica! En 1937 la

BBC normaliz la utilizacin del sistema electrnico.
En Espaa las emisiones televisivas se inician en 1948 con la transmisin
desde el Stand de Phillips Ibrica en la Feria de Muestras de Barcelona, sin
embargo todava transcurrirn ocho aos para el primer servicio de TVE.
Concretamente fue el 28 de octubre de 1956, hace algo mas de cuarenta aos
desde esa primera transmisin televisiva.
A los tres meses haba 3.000 madrileos con TV. Tres horas de emisin
diaria de 9 a 12 de la noche. Un alcance de 70 km, y ms de 50 empleados.
En 1957, despus de las vacaciones de agosto, vacaciones que por supues-
to se tomaba la TV espaola, aparece un compaero inseparable hasta nues-
tros das, el Telediario. En 1971 se televisa en Espaa el primer programa de
televisin en color que como no poda ser menos, era una corrida de toros.
Cuatro aos ms tarde el 20% de las emisiones era en color. A finales de los
70 se calcula que el 93% de los espaoles tena TV, y la media de televisores
por familia es, hoy da, superior a la de telfonos fijos (Peire, 2001).
1.1.6. La electrnica al servicio de la comunicacin
Queda por explicar la parte electrnica, cmo y cundo nace la electr-

nica y el ordenador, que cambiaron decisivamente la tecnologa de las comu-
nicaciones, siendo hoy da impensable la existencia de una radio, una televi-
sin o telecomunicaciones sin electrnica, aunque y como se ha visto
nacieron sin necesidad de la electrnica, y con un funcionamiento, que
como la TV mecnica son totalmente similares, por no decir idnticas a las
actuales de la TV.
A comienzos del siglo XX hicieron su aparicin las vlvulas de vaco, que
hicieron posible la amplificacin electrnica y las radios de nuestras abue-
las, los partes de guerra, los radares, etc. Sin embargo esta electrnica de
vlvulas no hubiera podido realizar lo que se puede considerar la mayor revo-
lucin industrial y sociolgica desde los tiempos de la mquina de vapor.
En diciembre de 1947 aparece el transistor. Cuando se publican apenas
unas lneas en la ltima pgina 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 aos despus volara al espacio guiado por una electrnica en
base a las vlvulas.
Sin embargo, el nacimiento de lo que se denomina electrnica de estado
slido, y el boom que iba a propiciar, no haba hecho ms que empezar.
En 1964 aparece el primer circuito integrado, en 1971 el primer micro-
procesador (el corazn de un ordenador) y en la dcada de los 80 empiezan a
popularizarse los PCs (ordenadores personales). Sin embargo, socialmente

todava no se vislumbran los grandes cambios que se avecinan.
Nuevamente, la gente del siglo XX est acostumbrada a los cambios tec-
nolgicos y no se vislumbra el tremendo impacto social que se viene encima.
Dnde est el cambio del microprocesador, si en 1969 se pudo llegar a la
Luna sin l? Donde se podra englobar la famosa frase de Neil Alden Arms-
trong cuando aluniz y pronunci lo que hoy da son palabras que han pasa-
do a la historia Un pequeo paso para el hombre y un paso gigante para la
Humanidad. Con este hito se cumpla uno de los ms viejos sueos de la
Humanidad.
Sin embargo, no es hasta finales de la dcada 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 epgrafe se ha analizado sucintamente la historia, corta en el
tiempo pero vertiginosa en cuanto a transformaciones tecnolgicas y sociales
provocadas por las nuevas posibilidades que ofrecen las telecomunicaciones,
unidas a la autntica locomotora del cambio que es la industria microelec-
trnica (Peire, 2001).
1.2. LA REVOLUCIN DE LAS COMUNICACIONES. INTERNET
Si se analizan hoy da los peridicos aparecen casi a diario referencias a

una nueva palabra mgica, 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), tambin en ese mismo da publica Los robots han
muerto, llegan los knowbots, seres cibernticos virtuales que tienen como
misin imposible navegar por la red Internet en busca la informacin 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 estratgicos de
las guerras. La idea de Internet la lanza el Departamento de Defensa Ameri-
cano. Su objetivo, es garantizar la comunicacin de los principales centros
operativos americanos en caso de que ocurriera una catstrofe nuclear. A
mediados de los 60, en plena guerra fra, haba 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 operacin 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 Brbara y la Universidad de Utah.
A partir de esta fecha se suceden los cambios de denominacin 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 ms cientficas. En 1987 se inician los servicios comerciales de
UUNET (Unix to Unix Copy Program protocol). El siguiente hito y ya muy
reciente, es la prctica absorcin 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 aos en los que aparecen estas aplicaciones son an ms
impresionantes. El correo electrnico eclosiona a mediados de los 70 (en USA), a
comienzos de los 90 los programas conocidos como Archie, Wais, Goopher (estos
productos ya salen prcticamente de una manera simultnea 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 ms utili-
zadas Intranet.
Hasta aqu se ha puesto de manifiesto la vertiginosa velocidad de cambio
de estas nuevas tecnologas, que sin duda alguna estn influyendo de manera
decisiva en los cambios sociales y polticos en el mbito mundial, y que el
concepto inicialmente quimrico para muchos de la Aldea global empiece
a hacerse da a da una realidad tangible (Colmenar, 1999a).
1.3. SISTEMAS Y PROCESADO DE LA INFORMACIN:

INFORMTICA
Hace slo 20 aos no exista el miniordenador ni las actuales redes de comu-
nicacin. El cambio es tan rpido que se puede aventurar que en dos aos los
equipos se vuelven obsoletos, y si se pierde el carro de estos avances, se est en
riesgo de obsolescencia. La situacin es de una autntica tirana tecnolgica.
El reto de los sistemas informticos 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, sern superadas.
Quiz la postura de abrir compuertas sea la que ms facilite el discurrir del ro.
Sin embargo, la penetracin de las nuevas tecnologas de comunicacin,
presenta una caracterstica muy importante. Los tiempos en que se empiezan a
utilizar socialmente los nuevos avances, cada vez son ms cortos. Si no, y como
muestra pinsese que desde que se patent el telfono en 1876 hasta que se rea-
liz la primera conexin entre Madrid y Nueva York, 1947, pasaron 69 aos.
Desde la primera demostracin pblica de la TV en Inglaterra en 1925,
pasaron 23 aos hasta la primera demostracin en Espaa.
Desde que NSFNET absorbe a ARPANET, iniciando tmidamente lo que
puede denominarse el boom de Internet hasta hoy da que ya es una reali-
dad consolidada en Espaa, han transcurrido menos de diez aos. Es ms, la
mayora de las aplicaciones, programas, etc., se suelen lanzar, comercial-
mente hablando, de manera simultnea en todas las partes del mundo.
Es por ello por lo que se puede estar seguro del futuro y el auge que a tra-
vs de esta nueva tecnologa, la unin de los PCs y las super-autopistas de la
informacin van a revolucionar, ya lo estn haciendo, aspectos estructurales
de nuestra sociedad y sobre todo sern un fundamental elemento de cambio
en la manera de entender en un futuro muy cercano la tele-enseanza y todo
esto, aunque paradjicamente, en un mundo donde la mitad de la poblacin
todava no ha realizado su primera llamada telefnica.
Llegados a este punto parece obligado encontrar un nexo de unin en
todas las tecnologas de la comunicacin. Qu tienen en comn los trabajos
de Gutemberg con la invencin del telfono o del transistor? Pues bien en
poca reciente todas estas tecnologas estn basadas en el procesado masivo
de la informacin, informacin en el sentido que todo el mundo entiende:
libros, artculos periodsticos, leyes, cartas, escritos hablados o en vdeo, etc.,
engloban las llamadas ciencias de la informacin.
Las Ciencias de la Informacin se encuentran relacionadas con los proce-
sos de almacenamiento, transferencia, recuperacin, y tratamiento de la
informacin. Intentan conjuntar disciplinas tan variadas como las ciencias
de la computacin, la lingstica, la ciberntica, y otras ciencias que ayuden
a los procesos de recuperacin, gestin, almacenamiento y control de la
informacin (Peire, 2001).
Las races de las ciencias de la informacin yacen en tres desarrollos fun-
damentales acaecidos durante la segunda guerra mundial: los desarrollos de
Shanon-Weaver, las teoras de Norbert Wiener y el rpido desarrollo de los
ordenadores de silicio (principalmente los ordenadores personales) ocurri-
dos a partir de los aos 70 .
1.4. EL CONCEPTO DE MULTIMEDIA

El concepto de multimedia ha evolucionado en los ltimos aos. Hoy se
puede afirmar que ha adquirido un nuevo significado ms preciso y menos
ambiguo y general. A continuacin, se analiza la delimitacin conceptual del
vocablo multimedia y su evolucin desde varias mltiples perspectivas:

empresarial, etimolgica, meditica, informtica e integradora de lenguajes.
1.4.1. Perspectiva empresarial
Para autores centrados en la temtica de los Medios de Comunicacin de

Masas (prensa, radio, cine y televisin), 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 meditica
La pluralidad meditica al hablar de multimedia, destaca la literalidad

del significado etimolgico. Cada vez que se utiliza ms de un medio, lo deno-
minan Multimedia o suma de medios, pues etimolgicamente su significa-
do es claro y parecera lejos de originar ningn debate: Multi-Media =
Muchos Medios.
1.4.3. Perspectiva informtica
En muchos catlogos de productos informticos se encuentra el vocablo

Multimedia referido al hardware que permite intercambiar datos entre dis-
tintos ordenadores. Productores de software describen tambin con ese tr-
mino paquetes en los que combinan textos y grficos con animacin en una
misma pantalla. La palabra multimedia se ha convertido para las empresas
de hardware y software en un elemento imprescindible en el mrketing
actual de sus productos.
1.4.4. Perspectiva contempornea
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 imgenes fijas y en movimiento inclu-
yendo vdeo, imgenes fotogrficas, grficos y animacin con sonido, tex-
tos y datos generados por ordenador y programas de ordenador. Toda la
informacin de un programa multimedia sonido, imgenes, textos y
datos puede grabarse en un solo soporte, generalmente un disco ptico.
1.4.5. Sistemas multimedia como integracin de lenguajes

Uno de los aspectos que se encuentan en cualquier sistema multimedia
correctamente diseado es la integracin de lenguajes. No se trata de una sim-
ple superposicin o adicin de imagen, sonido, etc., sino de un cuidado proceso
en el que se crea un producto audiovisual donde se hallan las potencialidades
expresivas y artsticas de varios lenguajes. La integracin supone que el disea-
dor y productor tienen un concepto definido de la imagen icnica y de la ima-
gen sonora, unidas por un ritmo interno y externo. En el multimedia, el mensa-
je se hace ms complejo en su diseo y realizacin, para que pueda ser mejor
entendido. Es el sonido, con frecuencia, el que da las pautas de comprensin
tanto de las imgenes individuales como de las secuencias. Y cuando se habla de
sonido se incluyen las cuatro facetas fundamentales de todo mensaje audio:
palabra, msica, efectos y silencios. Son tambin importantes la variedad de
voces y los matices expresivos que se consiguen con una locucin adecuada.
Sera deseable la definicin (acordada por parte de quienes trabajan e
investigan en este campo) de un modelo para el diseo de hiperdocumentos
que sea general, abstracto, consistente y seguro, y que ofrezca soluciones al
acceso, creacin y modificacin de la informacin.
DEFINICIN: Diferentes individuos y grupos estn usando los trminos que describen
una idea de una forma clara para su propio pensamiento. Pero entre los grupos, la idea
y los significados asociados con ese trmino, varan considerablemente. Por ello es nece-
sario dejar claros aqu los conceptos de estos trminos.
Multimedia es la integracin de todas las formas de comunicacin y de presentar la
informacin (se puede presentar en forma de textos, imgenes, sonido y vdeo).
Hipermedia es el conjunto de componentes lgicos 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 estn conectadas con una base
de datos o/y imgenes.
Navegar es acceder por los distintos nodos a las partes del programa. Se presen-
ta la informacin de una forma aleatoria, en lugar de secuencial.
1.5. SISTEMAS MULTIMEDIA TRADICIONALES

Bajo esta denominacin se agrupan una serie de sistemas como son: el
diaporama, como primer multimedia, la multivisin, 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 ms que un mon-
taje de diapositivas sonorizadas, o un montaje sonoro ilustrado con diaposi-
tivas, ambas posibilidades tambin interesantes y con numerosas aplicacio-

nes didcticas. Algunos autores definen el diaporama como:
un medio de comunicacin grupal, abierto, que une diferentes medios de
expresin: imgenes, palabras, msica, ruidos, dilogos, silencios, poesa,
narracin y ritmo, con una unidad esttica y significativa. La clave del dia-
porama reside en la conexin de los lenguajes que no deben estorbarse, ni
ser redundantes.
Hace aos reciban nombres inapropiados como son: Fotomontaje (el

vocablo se refiere a la manipulacin de fotografas, propia de las publica-
ciones escritas). En algunos pases latinoamericanos lo llaman Diapofilm
o Sonoviso. Tambin 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 creacin fsica del ambiente, del
movimiento y del ritmo), la palabra (da fuerza y claridad conceptual, rigor
formal y concrecin) y la imagen (concretiza visualmente, evoca y sugiere).
La elaboracin 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 mnimo de 10 aos, incluso menos.
La calidad tcnica, aunque es importante, es menos decisiva que el proceso
de creacin-realizacin. Si el resultado va a ser visionado slo por la clase del
grupo realizador, como es lo habitual, las carencias tcnicas, incluso los erro-
res y los fallos, son comprendidos por todos. A continuacin, se distinguen
algunas fases de su realizacin:
1. Planificacin o idea inicial (se escoge el tema o idea central).
2. Redaccin del guin (se parte de una sinopsis, resumen del contenido
del diaporama).
3. Seleccin de las diapositivas. Se elegirn fotos simblicas o foto-repor-
tajes.
4. Preparacin del sonido (voces adecuadas, eleccin de la msica, rui-
dos y efectos necesarios, etc.).
5. Grabacin del sonido.
6. Comprobacin de la grabacin y del ritmo imagen/sonido.
7. Evaluacin y correcciones, si es preciso.
Es importante que el docente sepa utilizar adecuadamente el diaporama,
para conseguir todos sus efectos pedaggicos. En este sentido son aconseja-
bles las siguientes recomendaciones:
a) Antes de la proyeccin: Preparar los elementos tcnicos de proyec-
cin y sonido, pantalla, oscurecimiento de la sala, etc. Ambientar al
grupo y situar el contexto.
b) Proyectar el diaporama sin cortes ni interrupciones.

c) Despus de la proyeccin: Facilitar la expresin e intercomunica-
cin del grupo, facilitar el descubrimiento del mensaje expresado, rea-
lizacin de distintas actividades: dibujo, expresin corporal, cartel,
etc.
Hoy la filosofa del medio tiende cada vez ms a apearse de la pantalla y
alojarse en soportes tridimensionales, ambientes y recintos imaginarios pro-
gramados a base de luces, colores, rayos lser, vdeos, autmatas, etc. La tec-
nologa ha hecho que la multivisin crezca en extensin y evolucione rpida-
mente.
1.5.2. Multivisin
En la Feria Mundial de Bruselas de 1958 se presentaron por primera vez

dos espectculos de multivisin en los pabellones holands y checo, basados
en la proyeccin simultnea y sincronizada de pelculas de cine. Aos des-
pus, en la Exposicin Universal de Sevilla, en casi todos los pabellones pod-
an encontrarse presentaciones de multivisin. Uno de los espectculos de
ms xito en la Expo 92 fue el programa Audiovisual del Lago, donde se
incorporaron algunos de los ltimos adelantos tcnicos de la multivisin.
Hoy en da, no se concibe una exposicin, una feria, una convencin impor-
tante, etc., sin un programa de multivisin, que tambin se denomina Multi-
pantalla, Multi-imagen, y Multiproyeccin.
La caracterstica principal de la multivisin es la espectacularidad de
su presentacin, que proporciona abundante informacin junto con un
impacto expresivo. El espectculo multivisin est ms prximo a las leyes
de la msica, donde slo cuenta la perfeccin interna, como la variacin,
el contraste o la repeticin. La aportacin tcnica de la multivisin reside
en la utilizacin de grandes pantallas en las que se proyectan imgenes
(casi siempre fijas) procedentes de varios proyectores coordinados por un
ordenador, mientras se incorpora a la comunicacin un mensaje sonoro,
generalmente estreo. La sensacin de movimiento se consigue intercam-
biando imgenes estticas con rapidez y ritmo, jugando con el impacto del
mosaico icnico.
Las presentaciones multivisin son controladas mediante un microorde-
nador. Un codificador transforma las rdenes del software a su propio cdi-
go de datos. Las unidades de control de programacin y proyeccin, desgra-
ciadamente no estn estandarizadas y son entre s incompatibles, excepto el
sistema sueco Dataton que lee AVL, Electrosonic y Arion. Este hecho ha difi-
cultado la popularizacin de este medio. El inconveniente de la multivisin
ha sido siempre lo laborioso de su ejecucin y lo aparatoso de la maquinaria.
La entrada de los sistemas informticos ha simplificado la infraestructura y
ha aumentado las prestaciones, pero la multivisin est ms cerca del espec-

tculo que de la didctica.
1.5.3. Paquetes instructivos
Los paquetes instructivos, tambin denominados paquetes autodidc-

ticos, paquetes multimedia y documentos integrados, tienen su origen
en los primeros trabajos de enseanza programada, donde se persegua 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
vdeo, programas informticos, textos, etc.
Actualmente los paquetes instructivos han alcanzando progresivos niveles de
desarrollo. La documentacin de la Reforma Educativa, referente a cualquier
nivel, insiste en la importancia de los recursos didcticos y en facilitar elementos
de aprendizaje personal a los discentes. Siguiendo a la pedagoga 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
Educacin, 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 diseados para reforzar el proceso de ensean-
za/aprendizaje (E/A) a base de recursos didcticos multimedia.
El creciente desarrollo de la enseanza a distancia ha potenciado los
paquetes instructivos. En el Tratado de Maastricht se ha insistido en que una de
las prioridades europeas de enseanza es la enseanza a distancia. Se prev un
aumento notable en todos los pases de esta metodologa de aprendizaje en la
que estn presentes tanto entidades pblicas 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 verboicnica. El alumno recibe estos paquetes de aprendizaje con
recursos plurales a los que puede acceder desde diferentes equipos tcnicos y
en distintas condiciones ambientales. Entre las ventajas de utilizacin de los
paquetes didcticos multimedia, se destacan (Castro y otros, 1996):
a) Facilitan la enseanza individualizada y el aprendizaje activo.
b) Proporcionan una enseanza modular adaptable.
c) Ahorran tiempo a profesores y alumnos.
d) Facilitan la evaluacin.
En la tabla 1 se refleja de forma esquemtica, las lneas de accin princi-
pales de diseo de un paquete instructivo multimedia.
TABLA 1.1. Lneas de accin principales de diseo de un paquete instructivo multimedia
1. Aprendizaje de las posibilidades tcnicas y didcticas de los medios a usar.

2. Eleccin del tema y su aplicacin.
3. Preparacin del proyecto.
4. Anlisis (objetivos, tareas de aprendizaje, etc.).
5. Diseo de lo que hay que ensear, su secuencia, medios empleados y lneas de
evaluacin.
6. Comprobacin del diseo del paquete instructivo.
7. Desarrollo de guiones de textos, audio, imagen, vdeo.
8. Evaluacin formativa de la preproduccin.
9. Produccin del material: textos, audio, imagen, vdeo.
10. Comprobacin con grupo el piloto y evaluacin.
11. Produccin definitiva.
12. Implantacin.
13. Revisiones peridicas y puesta al da.
1.6. SISTEMAS MULTIMEDIA ACTUALES

El concepto de multimedia ha evolucionado hasta llegar, en la actualidad, a
un sistema que facilita la combinacin interactiva de imgenes fijas y en movi-
miento, sonido, textos, grficos, animacin, etc., coordinados por un ordenador,
generalmente con soporte de disco ptico. Uno de los primeros multimedia, den-
tro de esta lnea conceptual, ha sido el Videodisco Interactivo, que une la capaci-
dad de memoria del ordenador y la imagen en movimiento con sonido del vdeo,
combinando textos, grficos, etc. Hoy existen numerosas plataformas multime-
dia, que se diferencian entre s por cuatro caractersticas (Castro y otros, 1999):
a) Capacidad de memoria.
b) Capacidad de audio, vdeo y grficos.
c) Sistemas de presentacin.
d) Estndares tcnicos 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 ms grficos.
c) CD-ROM (Compact Disk-Read Only Memory) o Disco Compacto-
Memoria de slo lectura.
d) CD-V (Compact Disk-Video) o Disco Compacto Video.

e) IV (Interactive Video) o Vdeo Interactivo.
f) CD-I (Compact-Disk Interactive) o Disco Compacto Interactivo.
g) DVD (Disco Vdeo Digital).
El Compact Disk Interactive (CD-I), iniciado por Philips y desarrollado
con Sony y Matushita, pareca ser una de las plataformas con ms posibili-
dades. Integra en un solo soporte de gran capacidad todos los datos, textos,
grficos, imgenes y sonidos. El Videodisco Interactivo (VD-I) presenta gran
calidad en informacin para los procesos de aprendizaje/formacin indivi-
dualizados. Actualmente el futuro apunta hacia el DVD, entre otras razones
por ser capaz de almacenar una mayor cantidad de informacin.
En los programas multimedia actuales se pueden destacar las caracters-
ticas siguientes:
a) Interactividad
Se denomina interaccin a la comunicacin recproca, a la accin y
reaccin. Una mquina que permite al usuario hacerle una pregun-
ta o pedir un servicio es una mquina interactiva. La interaccin
es una de las caractersticas educativas bsicas potenciada con los
sistemas multimedia y permite al usuario buscar informacin,
tomar decisiones y responder a las distintas propuestas que ofrece el
sistema.
b) Ramificacin
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 ramificacin cada alumno puede acceder a lo
que le interesa y necesita prescindiendo del resto de datos.
c) Transparencia
En cualquier presentacin la audiencia debe fijarse en el mensaje
ms que en el medio empleado. El usuario, el alumno, etc., debe
poder llegar al mensaje sin estar obstaculizado por la complejidad de
la mquina. La tecnologa de interaccin hombre-mquina (ratn,
pantalla tactosensible, teclados, lpiz ptico, etc.) debe ser tan trans-
parente como sea posible, permitiendo la utilizacin de los sistemas
de manera sencilla y rpida, sin que haga falta conocer cmo funcio-
na el sistema.
d) Navegacin
El concepto de navegacin se ha convertido en una sntesis de los
nuevos sistemas interactivos de informacin. Los sistemas multime-
dia permiten navegar, por todos esos mares de la informacin con-

tempornea, 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 (Garca, 1983):

a) Presenta las ventajas comunes a todas las tecnologas, permitiendo
adems una mayor interaccin.
b) Ofrece la posibilidad de controlar el flujo de informacin.
c) Gracias a la informacin almacenada en un disco ptico, ofrece gran
rapidez de acceso y durabilidad.
d) Une todas las posibilidades de la Informtica y de los medios audiovi-
suales.
e) Un programa multimedia bien diseado permite actualizar con facili-
dad los contenidos, con pequeos cambios en el software.
f) Mejora el aprendizaje, pues el alumno avanza por el sistema segn su
ritmo individual de aprendizaje, pedir informacin, se adentrar en
temas nuevos cuando tenga dominados los anteriores, etc.
g) Incrementa la retencin. La memorizacin de ncleos de informacin
importantes aumentar significativamente gracias a la interaccin y a
la combinacin de imgenes, grficos, textos, etc., junto a las simula-
ciones con representaciones de la vida real.
h) Aumenta la motivacin y el gusto por aprender. El aprendizaje se con-
vierte de este modo en un proceso ldico.
i) Reduce el tiempo de aprendizaje
j) Presenta consistencia pedaggica. La informacin contenida es la
misma en distintos momentos y para diferentes alumnos.
k) La metodologa, dentro de su variedad, es homognea.
l) La evaluacin de procesos y no slo de resultados, ofrece ecuanimi-
dad.
m) Es hoy en da uno de los medios de instruccin con mayor calidad.
n) Mejoran las condiciones del aprendizaje no slo recibiendo ms y
mejor informacin, sino, sobre todo, mejorando los procesos cogni-
tivos, favoreciendo la interaccin, 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 produccin del material de paso.
b) Falta de estandarizacin. Hay una multiplicidad de marcas y estnda-
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 estn preparados
para el uso de esta tecnologa y, adems, con frecuencia tienen cierto
miedo que revierte en tecnofobia.
e) Los multimedia mediocres o malos confunden a los alumnos inun-
dndoles con elementos complejos y distractivos.
1.8. RECOMENDACIONES A TENER EN CUENTA

EN EL DISEO 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 travs de un flujo constante de los temas principa-
les, dejando as que los usuarios hagan bifurcaciones para explorar ms 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 retroalimentacin positiva inmediata y
sentirse recompensada. Si esto es as, enseguida sonren, se divierten y quie-
ren seguir profundizando. Emocionante significa que ha de sacarle provecho
a su procesador y todas sus capacidades, grficas y de sonido, para vehicular
algo dinmico y excitante que compita con lo que la gente est acostumbra-
da a ver en cine o televisin.
El diseo y la construccin de un proyecto multimedia van de la mano.
Con frecuencia, los mejores resultados son producto de una retroalimenta-
cin continua, as como de modificaciones a lo largo del proceso de produc-
cin. Un proyecto multimedia no es ms que un arreglo de texto, grficos,
sonido y elementos de vdeo. Pero el modo en que se componen estos ele-
mentos hace que cada proyecto sea diferente, tomando la forma que le dan el
propsito del proyecto y los mensajes que contiene. Muchos mapas de nave-
gacin son esencialmente no lineales. En estos sistemas de navegacin los
espectadores tienen la libertad de saltar a un ndice, un glosario, diferentes
mens, el mdulo de Ayuda o Acerca de, etc., (figuras 1.1 y 1.2).
FIGURA 1.1. Mdulo de Ayuda
El guin para un proyecto se organiza secuencialmente, pantalla por pan-

talla, y cada pantalla se aboceta con notas de diseo y especificaciones. Los
guiones son piezas cortas que describen con gran detalle cada imagen, ani-
macin, segmento de pelcula, sonido, texto y seales de navegacin. Los
guiones son la pareja de los mapas de navegacin durante el proceso de dise-
o (Castro y otros, 2002).
FIGURA 1.2. Mdulo de Glosario.

La mayora de los sistemas de desarrollo de multimedia permiten hacer

que una parte de la pantalla, o cualquier objeto, se convierta en un botn o
rea sensible. Cuando se hace clic en un botn sobre esa localizacin, algo
sucede, y esto hace que multimedia no sea slo interactiva sino emocionante.
El diseo de navegacin proporciona botones lgicos, de modo que sus accio-
nes se comprendan intuitivamente por medio de la representacin grfica, de
sus iconos o por sealamientos de texto. No se debe forzar a los usuarios a
aprender muchos iconos nuevos o especiales; se mantendr la curva de
aprendizaje al mnimo. Tambin es importante incluir botones que ejecuten
tareas bsicas de mantenimiento, tales como terminar el proyecto en un pun-
to dado, o cancelar una actividad.
El diseo de pantallas de ordenador excelentes requiere un conjunto
especial de habilidades artsticas que no todos los programadores tienen. Un
artista grfico de multimedia siempre se pone en el papel del usuario final
durante el proceso de diseo y generacin, seleccionando colores que se ven
bien, especificando las fuentes de texto y diseando 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 tcnica, por tanto, no es una categora absoluta, sino que
estar mediatizada mientras que la misma sea efectiva para la creacin de un
cierto clima positivo. La posibilidad del alumnado y el profesorado jueguen
un papel protagonista en su relacin con el medio no es un asunto balad des-
de una perspectiva tcnica. Indicadores para evaluar los medios podran ser:
los lenguajes en cada medio, integracin de los medios, calidad de trata-
mientos textos, audios, vdeos, etc., potencialidad informativo-comunicativa-
educativa, presentacin de la produccin, interactividad y navegabilidad,
pertinencia de la interfaz, las articulaciones de los medios, las instrucciones
de instalacin 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 / pequeo, 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 maysculas iniciales, o un solo objeto de
color brillante sobre una pantalla en escalas de grises.
Sombreados en varios tonos. Gradientes.
Grficos invertidos para remarcar los textos e imgenes importantes.
Objetos en varios tonos y texto en dos y tres dimensiones.
(Contina)
TABLA 1.2. Recomendaciones para las presentaciones multimedia (Continuacin)
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 botn.
Patrones de bordes con demasiados adornos.
La necesidad de hacer ms de dos clics para terminar.
Incluir demasiados nmeros.
Demasiadas palabras (separe la informacin en frases pequeas).
Demasiados elementos importantes presentados rpidamente.
1.9. RESUMEN
La necesidad de las comunicaciones a distancia es tan antigua como la
historia del hombre. Actualmente se est ante una autntica tirana tecnol-
gica. Hace slo 20 aos no exista el ordenador personal ni las actuales redes
de comunicacin. El cambio es tan rpido que se puede aventurar que en dos
aos 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 aos. Hoy, se
puede decir, que ha adquirido un nuevo significado ms preciso y menos
ambiguo y general. En este captulo se ha analizado la delimitacin concep-
tual del vocablo multimedia y su evolucin desde una serie de perspectivas:
empresarial, etimolgica, meditica, informtica e integradora de lenguajes.
El primer multimedia fue el Diaporama, que combinaba la palabra, la
imagen, y el sonido. En 1958 se present la Multivisin, con grandes aportes
tecnolgicos, pero basados en la tcnica del diaporama, slo que est ms
cerca del espectculo que de la didctica. Luego aparecieron los Paquetes
Instructivos, diseados para reforzar el proceso de enseanza aprendizaje.
Los actuales sistemas Multimedia permiten no slo usar la informacin,
sino tambin modificarla desde el ordenador.
1.10. EJERCICIOS DE AUTOEVALUACIN
1.1. El nacimiento de lo que se denomina electrnica de estado slido fue

debido a la aparicin de:
a) Las vlvulas de vaco.
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. Cul 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 Informacin se encuentran relacionadas con los pro-

cesos de:
a) Almacenamiento, transferencia, recuperacin, y tratamiento de la
informacin.
b) Recuperacin, manipulacin, almacenamiento y control de la situacin.
c) Almacenamiento, transferencia y tratamiento de la informacin.
d) Manipulacin, almacenamiento y control de la situacin.
1.5. Al referirse a una actividad en la que participan o se integran varios

medios: prensa, radio, cine y televisin, se est hablando de multimedia
desde una perspectiva:
a) Etimolgica.
b) Empresarial.
c) Meditica.
d) Informtica.
1.11. REFERENCIAS BIBLIOGRFICAS

CASTRO y otros (1996): M. Castro. Comparacin de Tcnicas y Herramientas de Autor
para la Generacin de Aplicaciones Educativas. II Congreso de Tecnologas Apli-
cadas a la Enseanza de la Electrnica, Sevilla.
CASTRO y otros (1999): M. Castro. Herramientas Hipermedia y/o Multimedia en Los
Procesos de Enseanza/Aprendizaje en la Educacin Superior a Distancia. 8
Encuentro Iberoamericano de Educacin Superior a Distancia. Quito-Ecuador
del 22 al 24 de julio de 1999.
CASTRO y otros (2002): M. Castro. Diseo y desarrollo multimedia: Sistema, imagen,
sonido y vdeo. RA-MA, 2002.
CASTRO y otros (1999): M. Castro. Sistemas bsicos de comunicaciones. RA-MA, 1999.
COLMENAR (1999a): A. Colmenar. M. Castro, y J. Peire. Aplicaciones Didcticas de los
Sistemas Multimedia en la Enseanza a Distancia. 8. Encuentro Iberoamericano
de Educacin Superior a Distancia. Quito-Ecuador del 22 al 24 de julio de 1999.
COLMENAR (1999b): A. Colmenar. Propuesta de Diseo Curricular en un Marco Cons-
tructivista para los Diferentes Niveles del Nuevo Sistema Educativo: Aplicacin a
las Energas Renovables. Tesis Doctoral. UNED, 1999.
GARCA (1983): L. Garca. Los Medios Audiovisuales al Servicio de la Enseanza.
Madrid: Servicio de Publicaciones del ICE de la Universidad Politcnica de
Madrid, 1983.
PEIRE (2001): J. Peire. Sesin de Apertura del 9. Encuentro Iberoamericano de Edu-
cacin Superior a Distancia. Cartagena de Indias, julio de 2001.
Captulo 2
MEDIOS: TEXTO, IMAGEN Y SONIDO
ESQUEMA
2.1. Hipertexto.
2.2. Hipermedia
2.3. OCR. Reconocimiento ptico de Caracteres.
2.4. Captura de imgenes digitales.
2.5. Formatos de archivos.
2.6. El sonido digital. Conceptos previos.
2.7. CD-AUDIO.
2.8. Formatos de sonido.
2.9. Extraccin-compresin-reproduccin.
2.10. Resumen.
El hipertexto se ha utilizado desde un principio en Informtica para
almacenar informacin y presentar sta en forma de texto entendible, los
avances en hardware y programacin han permitido aadir grficos y mejo-
rar la presentacin de la informacin. Cuando el flujo de la informacin, 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 acuados, los sis-
temas hipertexto han alcanzado auge en la actualidad, con el abaratamiento
y popularizacin de los perifricos de almacenamiento masivo de datos y la
llegada de Internet. En este capitulo se muestran las bases para la confeccin
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 imgenes 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 obtencin de
imgenes digitales, 2.4, as como los principales formatos en los que estas
pueden archivarse, 2.5.
A continuacin 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 ms adecuados para su documento. WAV, MP3, MIDI,
son algunos de los mltiples formatos de sonido. En este tema se pretende,
desde un punto de vista prctico, descifrar qu se esconde tras este laberinto
de nombres de archivos de sonido digital. Despus de su lectura sabr cul 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 versin estrictamente terica del Hipertexto responde exactamente a
las formas bsicas del estructuralismo y propone que cada pieza del texto,
cada palabra, ser tratada como un elemento relacionable en un sistema de
informacin. De esta manera, se puede acceder a enormes cantidades de

datos relacionados a travs de palabras claves y bsquedas (Castro y otros,
1996).
A diferencia de lo que son las llamadas a pie de pgina o notas de un tex-
to, los distintos cuerpos o espacios textuales del hipertexto poseen autono-
ma. Crecen y se modifican de forma independiente y slo se ven cuando son
activados a travs de las palabras claves o puntos de conexin, 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, yndose por las ramas como se suele decir y haciendo
mencin 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
mquina una herramienta para su propio crecimiento; los primeros hiper-
textos creados en papel, jams gozaron de versiones electrnicas y entre otros
se pueden contar el libro de Julio Cortzar Rayuela, considerado como un
hipertexto, ya que puede leerse de manera lineal hasta el captulo 56 o tomar
el camino que sugiere el autor. Algunos poemas de Cortzar tambin estn
construidos en forma hipertextual. El Jardn de los senderos que se bifurcan o
El Aleph, de Jorge Luis Borges, son libros que tambin hablan en clave de
hipertextualidad. En la coleccin 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 aadi, fue la posibilidad de presentar los
distintos cuerpos en forma casi inmediata permitiendo, a travs de opciones
de fcil acceso, avanzar o retroceder para navegar por los mares de la infor-
macin (Boom, 1987).
Por lo tanto, la diferencia bsica entre un hipertexto y un texto tradicio-
nal es la naturaleza exclusivamente secuencial de la informacin que presen-
ta este ltimo. El hipertexto por el contrario, representa una red o sistema de
informacin en el que no se sigue un nico orden de lectura. Las sucesivas
unidades de informacin estn entrelazadas mediante vnculos 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 informacin mediante
enlaces activables.
Algunas formas de enlazar entre s los diferentes nodos del hipertexto se
logran mediante un conjunto de botones que permiten la navegacin hacia la
prxima pgina o a la pgina anterior, abandonar la sesin de trabajo o el libro,
solicitar orientaciones generales sobre cmo utilizar el hipertexto, consultar el
ndice temtico, buscar directamente contenidos especificados mediante pala-
bras claves, realizar evaluaciones del aprendizaje o ejecutar comprobaciones
MEDIOS: TEXTO, IMAGEN Y SONIDO 47
prcticas 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 ratn 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 ratn (letras de
color, palabras activas, frases o imgenes) y su objetivo (texto plano, otro hiper-
texto, una imagen, una secuencia de vdeo o un sonido) (Colmenar, 1999b).
Un hipertexto debe estructurarse jerrquicamente, pues as se facilita la
entrada a ste por mltiples 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 mltiples formas, desde aplicaciones infor-
mticas personalizadas como Visual Basic, Borland C, Delphi, Toolbook, etc.,
hasta pequeas herramientas que generan hipertexto en formato .HLP (como
es el caso del procesador de texto Word), es decir, documentos que son ledos
por la ayuda de Windows, programa que acompaa al entorno por lo que la
visualizacin de estos ficheros est garantizada desde la instalacin 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 ms fielmente se adaptan a la definicin 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 jerrquica de un hipertexto.

autor, como un entorno de creacin 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 presentacin de las mismas se puede realizar
por su orden natural o en cualquier orden que se disee mediante enlaces
hipertexto. Con el fin de moverse a travs de las distintas pantallas, se pulsa
cualquier palabra de enlace con el ratn, 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 publicacin hipertexto un carcter multimedia ms amplio (Cas-
tro y otros, 1999).
Un sistema hipertextual completo debe proporcionar herramientas de
creacin y edicin 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
construccin, modificacin y actualizacin de documentos.
En la figura 2.2 se muestra un modelo general de arquitectura de sistemas
hipertextuales. Como primer nivel estn 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 informacin, mientras que el autor puede, ade-
ms, actualizar el sistema con las herramientas de mantenimiento. La infor-
macin 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 bsicas de acceso a la informacin, mediante navegacin y por
interrogacin. La experiencia en hipertextos ha demostrado que los mecanis-
mos de acceso por navegacin no son suficientes. En algunas aplicaciones
normalmente caracterizadas por grandes redes estructuradas y heterogne-
as, los usuarios tienden a perderse mientras estn buscando la informacin
de partida. En consecuencia para reforzar los mecanismos de acceso (nave-
gadores grficos, visualizador de la red, etc.), muchos sistemas hipertextua-
les soportan otros tipos de bsqueda por contenidos, que permite a los usua-
rios examinar el hiperdocumento con una pregunta (Castro y otros, 2002).
2.2. HIPERMEDIA
Como extensin del trmino hipertexto (escritura no secuencial), aparece

el trmino hipermedia, que implica enlaces y navegacin en un material
almacenado en cualquier medio: texto, vdeo, sonido, msica, grficos, etc.
Hipermedia es el trmino que define el almacenamiento y recuperacin de
informacin mediante un ordenador de una manera no secuencial. La habi-
lidad para moverse en la informacin textual y las imgenes es slo 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 sinni-
mos los trminos 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 escneres o sistemas de digitalizacin.
Para su correcto funcionamiento hace falta un software especial, que suele
incluirse con el aparato. La combinacin 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 errneos. 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 introduccin de datos. Al hacer OCR, el escner (o el
ordenador) se limita a convertir la pgina de texto fsica a una imagen digita-
lizada; posteriormente, el software OCR se encarga de traducir sus lneas 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, ms tarde, arrancar el programa de OCR, leer desde el disco el mapa de
bits y convertirlo en una pgina perfectamente editable por el procesador de
textos habitual (Castro y otros, 2002).
El reconocimiento de caracteres pticos (OCR) es una tecnologa utili-
zada en aplicaciones comerciales desde 1950. Fue diseada inicialmente
para leer lo que se conoce como tipologas estilizadas. Estas tipologas,
como OCR-A, incluyen conjuntos completos de caracteres alfanumricos
junto con caracteres especiales que son digitalizados o ledos mecnica-
mente proporcionando, de esa manera, un mtodo de alta velocidad de
entrada de datos libre del teclado. Hay dos formas principales de abordar el
reconocimiento de caracteres pticos: la comparacin contra un juego de
caracteres existente o la extraccin de rasgos. La comparacin ve el
carcter impreso y compara esa imagen con una base de datos de posibles
opciones. La extraccin de rasgos mira los elementos estructurales y su
combinacin para reconocer el carcter (figura 2.3). En los ltimos aos, la
tecnologa 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 ms poderosos. Por
ejemplo, la mayora de los equipos actuales de OCR son capaces de leer
tipologas comunes de oficina, como la Courier y tambin tipologas estili-
zadas y tipologas proporcionales que se encuentran en los peridicos y
revistas. De hecho, muchos utilizan el trmino reconocimiento de caracte-
res inteligentes (ICR) ya que,este trmino, 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 aos, cuando bajaron los pre-
cios de los escneres y llegaron al pequeo usuario, cuando han empezado
a mejorarse hasta los lmites que se conocen hoy.
FIGURA 2.3. Reconocimiento por extraccin de rasgos.

2.4. CAPTURA DE IMGENES DIGITALES
Por todos es conocido que una imagen vale ms que mil palabras, la
imagen juega un papel fundamental en el campo del multimedia; a continua-
cin, se ver cmo es posible introducir en el ordenador una imagen no digi-
tal, cmo obtener directamente imgenes digitales, as como qu son y don-
de encontrar lbumes de imgenes digitales.
2.4.1. El escner
El dispositivo ptico que puede leer documentos y convertirlos en unos

y ceros para posteriormente ser tratados por un programa informtico, reci-
be el nombre de escner. stos pueden interpretar fotos, dibujos y textos, y
almacenarlos en un archivo grfico en el ordenador. Si el aparato es bueno, y
se reconoce el original a una resolucin elevada, la diferencia entre el origi-
nal y la exploracin ser muy pequea. Con el escner, una fotografa puede
ser explorada, incorporada en un documento despus de retocarla ligera-
mente y ser impresa en muy pocos minutos.
E1 avance tecnolgico de la mayora de los escneres permite que puedan
ser utilizados para todo tipo de trabajos. El tamao 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. Adems, si no se
dispone de impresora y escasea el espacio, existen escneres multifuncin,
que en una sola mquina permiten escanear e imprimir.
Casi todos los fabricantes incluyen con sus productos algn 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 caracterstica ms importante de un escner es su resolucin, la canti-
dad de informacin que es capaz de procesar el escner, indicando el nivel de
detalles en la imagen que el escner 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 escner tiene una resolucin de 300x600, significa que
tiene una resolucin horizontal de 300 ppp y una resolucin vertical de 600
ppp. Y cuando se dice que un escner tiene una resolucin de 600 ppp es que
tanto la resolucin horizontal como la vertical es de 600 ppp. La resolucin
de un escner se facilita, habitualmente, de dos maneras/formas: resolucin
ptica y resolucin interpolada.
Las imgenes digitalizadas se guardan en unos archivos de formato grfico
denominados, segn la forma de almacenamiento, grficos vectoriales o mapas
de bits (bitmaps). Un mapa de bits consiste en un mosaico rectangular de pun-
tos, denominados pxeles. Por lo tanto, un pxel es el elemento ms pequeo

del que est compuesta una imagen. Cada pxel lleva asignado un valor, desde
un bit de informacin, 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 ms utilizada actualmente es la de 24 bits. Los
bitmaps de 24 bits estn 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 ms de esta pro-
fundidad de color para visualizar en pantalla, imprimir o hacer algo que no
sean procesos internos de clculo de los programas o sensibilidades pticas de
los escneres, no tiene demasiado sentido, porque el ojo humano no es capaz
de distinguir tantos tonos y matices (Castro y otros, 2002).
2.4.2. Cmaras fotogrficas digitales

En pleno siglo XXI el hecho de que las cmaras digitales estn predestina-
das a sustituir a las convencionales es algo que no parece razonable discutir.
La actual tendencia de bajada de precios y el incremento ms que notable de
la resolucin ptica y de la calidad general de las cmaras disponibles en el
mercado en el mercado parecen confirmarlo. Las ventajas de una cmara
digital son muy variadas: permiten crear fotografas rpidamente para su
inclusin en una pgina Web, realizar trabajos escolares, tener fotografas 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
comunicacin 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. Cmara fotogrfica digital.

2.4.3. Clip-Arts
Existen lbumes de imgenes profesionales (llamados ClipArt), figura 2.5,
y de fotografas que son muy fciles de conseguir. Las imgenes y las fotos
son los elementos que ms habitualmente se incorporan a los programas
multimedia. Muchos paquetes incluyen muestras de diferentes compaas
creadoras de imgenes y fotos. Por ejemplo, CorelDRAW 96 incorpora 22.000
imgenes y smbolos, as como 100 fotografas de alta resolucin. Si eso no
fuera suficiente (y para muchos profesionales no lo es), Corel vende bibliote-
cas de imgenes y fotos adicionales, con otras 200.000 imgenes. Sin embar-
go, hay que tener en cuenta que la calidad de las imgenes y las fotos puede
variar enormemente. Slo porque se trate de un producto comercializado no
significa que tenga una categora verdaderamente profesional. Image Club es
una compaa que siempre se ha considerado lder en la categora de las im-
genes profesionales de alta calidad. Este Club tambin ofrece fotografas pro-
fesionales. Adobe adquiri Image Club en 1995. Se puede visitar la pgina de
presentacin de Image Club en: http://www.adobe.com/imageclub. Otras dos
compaas que disponen de imgenes digitales impresionantes son Photo-
Disk y CMCD. CMCD es una compaa de la firma de diseo Clemont Mok, y
sus fotos las distribuye PhotoDisk. Una tendencia en las imgenes fotogrfi-
cas es la utilizacin de objetos de uso cotidiano y metforas al respecto. Se
pueden visitar las ltimas novedades de los objetos de uso cotidiano de
CMCD en la direccin:
http://www.cmdesigns.com
Tenga en cuenta que no existe un formato estndar para las fotografas y

las imgenes 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 condicin 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. Coleccin de Clip-Arts.

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

parmetros de pixeles o puntos, tales como posiciones y colores. Esto es slo
cierto en el caso de los archivos raster o de tipo bitmap (mapa de bits), muy
empleados para almacenar fotografas. Los archivos con datos vectoriales
contienen ecuaciones matemticas que evitan la degradacin de los conteni-
dos ante las operaciones de edicin. Son empleados de forma masiva por los
programas de CAD, ilustracin y diseo grfico. Los metafiles son un tipo
especial de archivos que pueden contener informacin bitmap o vectorial. Un
claro ejemplo es el Windows Metafile o WMF, un peculiar formato que inclu-
ye llamadas a funciones de la interfaz grfica de Windows. Las animaciones
son almacenadas en formatos especiales de datos raster con estructuras pre-
paradas para la reproduccin secuencial. Por ltimo, existen formatos de
objetos multidimensionales que incluyen los datos y el cdigo para su inter-
pretacin y archivos multimedia que pueden almacenar todos estos tipos de
datos junto con informacin audiovisual. La idoneidad y conveniencia de
uno u otro formato depende de la finalidad que vayan a tener los trabajos que
contienen. Los formatos ms utilizados son las que se citan a continuacin
(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 compresin. Sus principales ventajas son que no tie-
ne ninguna prdida de color y lo suelen utilizar todos los programas que se
ejecutan en Windows, aunque tiene el inconveniente de su gran tamao.
Existe tambin una derivacin con compresin, empleando un algoritmo

de compresin RLE (Run Lenght Encoding) de 4 u 8 bits. El mtodo RLE es
idneo ante imgenes que incluyen patrones repetitivos y bloques de puntos
similares, funciona comprimiendo cadenas secuenciales iguales, cambindo-
las por el smbolo repetido y el nmero de veces que se repite.
2.5.2. GIF (Graphics Interchange Group, Grupo de Intercambio

de Grficos)
Hasta hace poco ha sido el ms 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 slo permite 8 bits (256 colo-
res). Todava se sigue utilizando en Internet, ya que goza de un alto nivel de
compresin, puede crear grficos 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 grficos es mnimo.
Los archivos GIF soportan tipos de imgenes de color indexado, as como
imgenes en escala de grises y de lneas.
2.5.3. JPEG
Fue diseado por el grupo Joint Photographics Experts Group (la Unin
del Grupo de Expertos Fotogrficos). Es el formato ms utilizado actualmente
en Internet y es muy vlido para crear fotografas de alta calidad, color ver-
dadero y un tamao reducido. Ideal para el almacenamiento masivo de
imgenes. Hay que tener presente que, aunque admite unos grados de com-
presin muy elevados (a mayor compresin, mayor prdida de detalle en la
imagen final) no es conveniente superar un nivel de compresin de 15:1.
JPEG es el estndar a elegir, debido a su alta resolucin y a su elevada
compresin. Muchos editores grficos, tal como Adobe Photoshop, permiten
elegir una configuracin de alta calidad para efectuar la compresin. La ele-
vada calidad se comprime, con una relacin comprendida entre 5:1 y 15:1.
Reduce los archivos de imagen aproximadamente a un 10% de su tamao ori-
ginal (o an menos). El algoritmo JPEG pierde algunos de los datos, ya que
identifica e ignora los pxeles 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 escner durante la digitalizacin de

los documentos. Debido a su escasa compresin, su mayor defecto es el
tamao de la imagen resultante. Sin embargo, juega a su favor el que es
soportado por todos los programas de tratamiento de imgenes e incluye
todos los tipos de color (puede almacenar imgenes de 1, 8, 12 y 24 bits de
color por pxel o imgenes de 32 bits separadas en componentes CMYK con
un canal alpha para transparencias y otros efectos). Es el formato indicado
para utilizar la separacin de colores CMYK, utilizada en impresin. Este for-
mato ofrece libertad para elegir el tipo de compresin 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 analgica y

que los ordenadores emplean sonido digital, deber realizarse una transforma-
cin. Para realizar esta conversin se toman unas muestras de ondas a unos
intervalos de tiempo concretos. Se denomina frecuencia de muestreo al nmero
de muestras tomadas por segundo, cuanto mayor sea este nmero mayor ser la
calidad del sonido y mayor ser la cantidad de datos a almacenar. Las frecuen-
cias ms 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 nmero de bits utilizado mayor ser la
calidad de dicho sonido, es decir la reproduccin de dicho sonido se realizar
con mayor precisin, si bien tambin hay que tener en cuenta que un mismo
archivo grabado a 16 bits ocupa el doble de espacio que uno de 8 bits. El nme-
ro de canales de audio muestreados determinar si el sonido es monofnico (un
solo canal) o estereofnico (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 proporcionarn los fundamentos para poder com-
prender el funcionamiento del sonido digital y un conocimiento que le ayuda-
r a seleccionar los formatos de archivo ms adecuados para su documento.
El sonido en el CD almacenado ha sido muestreado a 44 kHz y una reso-
lucin de 16 bits en estreo. Una cancin o tema corresponde exactamente a
una pista. Mediante un lser se leen los datos del CD y son traducidos por un
circuito conversor digital-analogico (DAC) a seales electromagnticas que
sern transmitidas a travs de un cable, que estar conectado a un amplifica-
dor o auriculares. El paso contrario, es decir, la grabacin de una seal ana-
lgica a un CD en formato digital se hace mediante un convertidor analgico-
digital (ADC), (figura 2.6) (De Furia, 1986).
Tambin hay que destacar el auge del MiniDisc, que permite la grabacin
de 74 minutos de msica con un tamao parecido a un disquete de 3 1/2 y que
ofrece la ventaja de poder grabar en un mismo soporte hasta un milln 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 parmetros ms 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. Adems, esa fre-
cuencia slo debe utilizarse en las muestras de alta calidad. Si un archivo de
sonido slo contiene voz, ser suficiente utilizar 8 bits y 8 kHz (De Furia, 1987).
2.7. CD-AUDIO
La aparicin de los primeros estndares multimedia se remonta a princi-
pios de la dcada de los aos ochenta. El primero de los formatos fue el CD-
FIGURA 2.6. Conversin analgico digital y viceversa de una seal.
Audio, desarrollado por Sony, y cuyas especificaciones se recogen en el deno-

minado Libro rojo, el primero de una serie de manuales tcnicos 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 msica.
2.8. FORMATOS DE SONIDO

Las muestras de sonido, al igual que sucede con los formatos destinados a
grficos, pueden ser transportadas en varios tipos de archivos. Su variedad no
es tan grande como sucede con los formatos grficos, pero todos ellos contie-
nen una serie de parmetros comunes que informan de la frecuencia de mues-
treo empleada en la grabacin, del nmero de canales de la muestra, de los bits
de cuantificacin digital y de otros datos importantes sobre bucles de repeti-
cin (loops) e informacin adicional por citar tan slo dos ejemplos.
Los editores grficos de audio (EGA) son unas sofisticadas aplicaciones
que facilitan la grabacin, reproduccin y edicin de audio digital. Sound
Forge (programa que se comentar un poco ms adelante) es un soberbio
software shareware que incluye funciones tpicas de los editores comerciales y
alguna que otra para trabajar con varias muestras de sonido al mismo tiempo
y la edicin se lleva a cabo con el ratn tal y como si fuera un lpiz que per-
mitiera pintar el sonido. Aplica varios efectos de sonido tales como ecos,
reverberaciones, distorsiones y panoramas. Todas sus operaciones de edicin
son inteligentes, de tal forma que la frecuencia de muestreo, resolucin y

nmero de canales son convertidos de forma automtica 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 combinacin
de los atributos soportados por un formato particular (De Furia, 1987).
Uno de los elementos que rodea cualquier tecnologa emergente es la apa-

ricin 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 mayora 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 extensin
.VOC se refiere a la voz (voice en ingls), y es el formato que utilizan por
defecto las tarjetas de sonido SoundBlaster. La extensin .IFF suele referirse
a un archivo de sonido de la plataforma Amiga. stos son formatos no estn-
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 opcin de formato de archi-
vo RIFF en varios editores de sonido. Los archivos waveform se pueden guar-
dar como archivos de sonido estreo o mono, con 8 o 16 bits. Los archivos
donde se almacenan estos sonidos digitalizados tienen, en sistemas PC, la
extensin . 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 informacin que lo va a
caracterizar, y viene representada por 4 parmetros: duracin temporal, fre-
cuencia de muestreo, resolucin y grabacin mono o stereo. El registro digi-

tal de una forma de onda se lleva a cabo mediante aproximaciones numricas
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 odo humano, de forma

que elimina toda la informacin que no se necesita. Para ello utiliza un siste-
ma denominado Codificacin de SubBandas, proceso por el cual la seal se
descompone en subbandas a travs de un banco de filtros o cualquier otro
mtodo semejante. Las subbandas obtenidas, se comparan a continuacin
con el original mediante un modelo psicoacstico que determina cules son
las bandas importantes y cules se pueden eliminar. Dependiendo de la cali-
dad que se desee obtener, se eliminarn ms 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 estndar tipo Huff-
man o LZW. El proceso de codificacin es mucho ms complicado que el de
decodificacin, por ello se tarda mucho ms en codificar un archivo MP3 que
en reproducirlo.
El escaso tamao de los ficheros de sonido en este formato de compre-
sin sin apenas perder calidad, lo hace ideal para grabar grandes cantidades
de msica con calidad CD (toda la discografa de grandes bandas como los
Rolling o Queen entran en un solo CD y ms si se utiliza DVD) y, sobre todo,
ofrece la posibilidad de intercambiar canciones e incluso discos completos a
travs de Internet en un tiempo de conexin ms 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 informticas con sistemas de archivos compatibles.
Estos archivos son un buen recurso para la inclusin de temas musicales en
aplicaciones multimedia, pues al contener nicamente los datos referentes a
las notas musicales y su interpretacin, ocupan muy poco espacio fsico en
las unidades de almacenamiento. Por ejemplo, los archivos que contienen
audio muestreado de alta calidad (44,1 kHz estreo con 16 bits de resolucin)
requieren 10 MB por minuto de sonido, mientras que una secuencia MIDI en
formato MIDI File con una duracin igual, tan slo requiere 10 kB. Por otro
lado, la reproduccin de estos archivos no exige los mismos recursos que
necesita la reproduccin de audio digital, aspecto decisivo para la sobrecarga
del sistema. El nivel de edicin inherente a un archivo MIDI es mayor que el
que se posee por el momento sobre los archivos muestreados, facilitndose
los cambios de tempo o velocidad de reproduccin y los cambios del tono y

las notas de los instrumentos del tema musical. La Asociacin Internacional
de fabricantes MIDI o IMA public una normativa de estandarizacin 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 ms
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 aparicin de los sistemas de compresin de audio en Internet datan de

la dcada de los aos noventa. Vistas las amplias capacidades de transmisin
de informacin, muchos ingenieros comenzaron a darle vueltas a la cabeza
en busca de un sistema de compresin que permitiera reducir el tamao de
los archivos de audio (los que ms capacidad ocupan, junto con los de vdeo),
de tal manera que fuera posible transmitir esa informacin a travs de la Red.
Con esto, la radio y la televisin podran hacerse un hueco en Internet, al
tiempo que favorecera la aparicin de emisoras y productoras de contenidos
diversos ampliando el elenco de informacin existente. Aunque los inicios
fueron ms bien parcos, compaas como RealNetworks, Microsoft y Vxtre-
me, comenzaron a investigar en este campo ofreciendo soluciones y sistemas
diferentes.
Uno de los ms populares es el conocido RealAudio o RealVideo, depen-
diendo de la fuente de informacin que se vaya a emitir. Su versin permite
convertir al ordenador conectado a la Red en un autntico sintonizador de
canales de radio y televisin a travs de Internet (Castro y otros, 2002).
El sistema de RealNetworks se basa en la tecnologa streaming, que con-
siste en dividir en paquetes muy pequeos un archivo para enviarlo inmedia-
tamente a su destino y que pueda ejecutarse mientras otros paquetes van lle-
gando. Gracias a esa tecnologa, es capaz de reproducir audio, vdeo,
imgenes estticas, texto y animaciones en tiempo real con casi cualquier
tipo de conexin.
2.9. EXTRACCIN - COMPRESIN - REPRODUCCIN
Para pasar un disco de formato CD-Audio a ficheros MP3 son necesarios

dos pasos principalmente: la extraccin digital de audio y la compresin. 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
solan cumplir las unidades ms antiguas. Si nuestra unidad es capaz de
hacerlo, se buscar un programa que realice esta funcin, entre los sharewa-
re destaca el Windac, que permite la extraccin a velocidad variable de una
forma bastante eficaz, aunque hay otros muchos (los programas de graba-
cin de CD, que suelen utilizar las grabadoras, tambin tienen extraccin de
audio, aunque generalmente slo pueden leer a velocidad simple). Esto tam-
bin 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 compresin 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 prdida de cali-
dad, y por tanto un disco que ocupaba 600 MB pasar a ocupar 50 MB. Para
ello ser necesario un programa de compresin, tambin 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 parmetros para modificar la calidad (lo ide-
al es comprimir en estreo a 44,1 kHz, 16 bits y 128 kbps). Adems, en la
compresin se pueden incluir datos como el nombre de la cancin, 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 cartulas personalizadas a fin de hacer
ms completa y atractiva la reproduccin de este tipo de ficheros (figura 2.7).
Winamp, nacido casi al mismo tiempo que el propio formato (por no
mentir, algunos meses despus), ha evolucionado como ninguno, siendo la
punta de lanza en cuanto a reproduccin de ficheros MP3. En sus ltimas
versiones, soporta muchos ms formatos de audio, siendo una buena herra-
mienta para la reproduccin por defecto de nuestros ficheros de sonido en
general. Asimismo, las posibilidades de personalizacin mediante skins o las
de ampliacin utilizando plug-ins hacen de este software uno de los ms ver-
stiles. Adems, ahora vuelve a ser de tipo freeware, despus de haber estado
disponible como share durante algn tiempo, sin duda el reproductor ms
utilizado.
FIGURA 2.7. Winamp.

2.10. RESUMEN
La diferencia bsica entre un hipertexto y un texto tradicional es la natu-
raleza exclusivamente secuencial de la informacin que presenta este ltimo.
El hipertexto por el contrario, representa una red o sistema de informacin
en el que no se sigue un nico orden de lectura. Las sucesivas unidades de
informacin estn entrelazadas mediante vnculos o punteros que permiten
desplazarse en el documento.
Un sistema hipertextual completo debe proporcionar herramientas de
creacin y edicin 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
construccin, modificacin y actualizacin de documentos.
La imagen juega un papel fundamental en el campo de la multimedia, en
este captulo se ha visto como es posible introducir en el ordenador una ima-
gen no digital, como obtener directamente imgenes digitales as como qu
son y donde encontrar lbumes de imgenes digitales.
Cuando se tiene que archivar una imagen digitalizada, se puede elegir
entre ms de un par de docenas de formatos grficos diferentes. A todos ellos
se les identifica por las tres letras de su extensin. La mayora de los progra-
mas actuales para retoque de fotografas, dibujo, ilustracin cuentan con
diferentes filtros de importacin y exportacin 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 parmetros ms 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. Adems, esa
frecuencia slo debe utilizarse en las muestras de alta calidad. Si un archivo
de sonido slo contiene voz, ser suficiente utilizar 8 bits y 8 kHz.
Las muestras de sonido, al igual que sucede con los formatos destinados
a grficos, pueden ser transportadas en varios tipos de archivos. Su varie-
dad no es tan grande como sucede con los formatos grficos, pero todos
ellos contienen una serie de parmetros comunes que informan de la fre-
cuencia de muestreo empleada en la grabacin, del nmero de canales de la
muestra, de los bits de cuantificacin digital y de otros datos importantes
sobre bucles de repeticin (loops) e informacin adicional por citar tan slo
dos ejemplos.
Finalmente, se recomienda al lector que quiera profundizar en los con-
tenidos de este captulo la referencia (Castro y otros, 2002).

2.1. Indicar cul de las siguientes afirmaciones no es correcta:
a) La diferencia bsica entre un hipertexto y un texto tradicional es la natura-
leza exclusivamente secuencial de la informacin 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 jerrquicamente, pues as se
facilita la entrada a ste por mltiples 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 escner.
c) Las Cmaras digitales fotogrficas.
d) La tarjeta de imagen XWZ.
2.3. El formato ms utilizado actualmente en Internet y es muy vlido para

crear fotografas de alta calidad, color verdadero y un tamao reducido.
Ideal para el almacenamiento masivo de imgenes. Que admite unos
grados de compresin 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 estreo o mono, con 8 o 16 bits, estos
sonidos tienen, en sistemas PC, la extensin:
a) WAV.
b) MIDI.
c) MP3.
d) RealAudio.
2.5. Al principio de cada fichero WAV est almacenada la informacin que lo

va a caracterizar, y viene representada por 4 parmetros:
a) Duracin temporal, frecuencia de muestreo, resolucin y grabacin

mono o estreo.
b) Extensin del fichero, frecuencia de muestreo, resolucin y graba-
cin mono o estreo.
c) Duracin temporal, frecuencia de muestreo, propiedades y grabacin
mono o estreo.
d) Fecha de creacin, frecuencia de muestreo, resolucin y grabacin
mono o estreo.

BOOM (1987): M. Boom. Msica con Midi. Microsoft Press.
CASTRO y otros (1996): M. Castro. Comparacin de Tcnicas y Herramientas de Autor
cadas a la Enseanza de la Electrnica, Sevilla.
CASTRO y otros (1999): M. Castro. Herramientas Hipermedia y/o Multimedia en Los
Procesos de Enseanza/Aprendizaje en la Educacin Superior a Distancia. 8
Encuentro Iberoamericano de Educacin Superior a Distancia. Quito-Ecuador
del 22 al 24 de julio de 1999.
CASTRO y otros (2002): M. Castro. Diseo y desarrollo multimedia: Sistema, imagen,
COLMENAR (1999): A. Colmenar. M. Castro, y J. Peire. Aplicaciones Didcticas de los
Sistemas Multimedia en la Enseanza a Distancia. 8 Encuentro Iberoamerica-
no de Educacin Superior a Distancia. Quito-Ecuador del 22 al 24 de julio de
1999.
COLMENAR (1999): A. Colmenar. Propuesta de Diseo Curricular en un Marco Cons-
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. Implementacin 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 ms. Ricordi, 1993.
GARCA (1983): L. Garca. Los Medios Audiovisuales al Servicio de la Enseanza.
Madrid: Servicio de Publicaciones del ICE de la Universidad Politcnica de
Madrid, 1983.
HAUS (1993): G. Haus. Procesamiento de msica. A-R Editions, Inc., 1993.
HECQUET (1990): A. Hecquet. Entorno Midi. Ra-Ma, 1990.

IGLESIAS (2002): P. Iglesias. Postproduccin 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, gua del usuario. RA-MA, 1992.
YAVELOW (1992): C. Yavelow. La Biblia de la msica y el sonido. IDG Books, 1992.

Captulo 3
MEDIOS: ANIMACIN Y VDEO
ESQUEMA
3.1. Las animaciones. Principios, herramientas y tcnicas de animacin.

3.2. Imgenes en 3 dimensiones. Creacin y animacin.
3.3. Elementos bsicos para comenzar a digitalizar vdeo.
3.4. Edicin y efectos del vdeo digital.
3.5. Resumen.
Actualmente es posible disponer de buenos paquetes de software infor-
mtico de animacin que realizan en cuestin de segundos muchas de las
pesadas tareas que en pocas no muy lejanas tenan que realizar varias per-
sonas durante semanas o meses. Adems, el software de animacin por
ordenador proporciona todas las ventajas de la edicin digital. Dentro del
primer apartado de este captulo, se describen algunos principios y termi-
nologa bsica de animacin, incluidos aspectos especficos de animacin
informtica.
Uno de los medios digitales que ms tarde se ha incorporado al mundo
multimedia, principalmente motivado por su complejidad de creacin y la
gran cantidad de recursos que consume del ordenador, son las imgenes en
tres dimensiones. Cuando se combinan imgenes 3D con animaciones, se
pueden conseguir interfaces ms intuitivas y fciles de usar, a la vez que se
consigue mejorar las posibilidades de transmisin de informacin al usuario.
Una imagen o animacin 3D puede proporcionar vistas alternativas de una
estructura compleja, como por ejemplo una escultura, una pieza mecnica,
un corazn, etc., adems de aadir atractivo visual a las pginas. En el apar-
tado Imgenes en tres dimensiones. Creacin y animacin se van a desarrollar
las formas de crear tridimensionalidad, as como una ligera iniciacin al
mundo de la animacin 3D. En sus apartados se trata el proceso de modela-
do, animacin, render y composicin, y proporcionan algunos consejos sobre
la creacin de grficos y animacin 3D para la Web. Todos estos aspectos son
tratados en la seccin 3.2.
Con el estado actual de la tecnologa, cualquier usuario con un PC y una
vdeocmara puede realizar su aportacin al mundo de la edicin de vdeo.
En el tercer apartado, Elementos bsicos para comenzar a digitalizar vdeo, se
presentan los conceptos bsicos a tener en cuenta antes de adentrarse en el
mundo de la edicin del vdeo digital, y ya en el cuarto apartado de este tema
Edicin y efectos del vdeo digital se expone una visin del mundo de la edi-
cin de vdeo digital de forma que le permita decidir si quiere adentrarse o no
en su aprendizaje.
3.1. LAS ANIMACIONES. PRINCIPIOS, HERRAMIENTAS

Y TCNICAS DE ANIMACIN
3.1.1. Animacin en celuloide

El trmino celuloide hace referencia a la pelcula transparente que se uti-
lizaba en la animacin tradicional dibujada a mano. En la actualidad, esta
pelcula transparente es de acetato (figura 3.1).
La animacin se dibuja en diferentes acetatos o celuloides que, por lo
general, se superponen para producir un solo cuadro de animacin. Existe un
celuloide para la capa de fondo y otro para cada objeto que se mueve de for-
ma independiente sobre el fondo.
Esta superposicin 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 cmo progresa la animacin en el tiempo. Muchos de
los procesos y la terminologa de la animacin tradicional basada en celuloi-
de se han llevado a la animacin por ordenador.
FIGURA 3.1. Ejemplo de tcnica de animacin por superposicin de acetatos.

MEDIOS: ANIMACIN Y VDEO 71
3.1.2. Animacin en cuadros

Es la forma ms sencilla de visualizar animacin, significa mostrar una
secuencia de archivos grficos para producir la ilusin de movimiento. Las
imgenes grficas se muestran en una rpida sucesin, cada imagen es lige-
ramente diferente de la anterior. Las imgenes grficas se muestran tan rpi-
damente que la persona que las visualiza piensa que percibe una imagen en
movimiento. En las pelculas, son 24 imgenes o cuadros por segundo, pero
en una aplicacin multimedia se puede reducir a 16. Para reproducirlo en un
ordenador, cada archivo grfico tiene que estar pintado en la pantalla para
cada cuadro de animacin (figura 3.2).
Tanto Shockwave de Macromedia como QuickTime de Apple Computer,
as como la mayor parte del software de animacin 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 tendra que
hacerse en este tipo de animacin basada en cuadros, slo tienen que actua-
lizar las partes de la pantalla que hayan cambiado entre cuadros. Esta com-
presin lleva a tamaos ms pequeos de archivos y a una reproduccin ms
rpida.
3.1.3. Animacin de sprites, trayectorias y vectores

La animacin basada en sprites es muy similar a la tcnica tradicional de
animacin donde un objeto se superpone y anima sobre un grfico de fondo
esttico, es muy comn en programas de animacin por ordenador. Un spri-
te es cualquier parte de la animacin que se mueve de forma independiente,
FIGURA 3.2. Animacin de un objeto 3D con la tcnica de cuadros.

FIGURA 3.3. Animacin a base de sprites en la herramienta de creacin Director.
como por ejemplo un nio corriendo o un planeta en rotacin. Cada sprite se

mueve como un objeto independiente y se puede animar en un lugar fijo,
como en el caso del planeta en rotacin, o moverse a lo largo de una trayec-
toria, como en el caso de un nio corriendo.
Los requisitos de tamao de archivos y ancho de banda para animacin
basada en sprite son, por lo general, menores que para la animacin basada
en cuadros, ya que se diferencian en que no tiene que actualizar toda la pan-
talla para cada cuadro, como sucede con la animacin basada en cuadros, en
la animacin sprite slo se actualiza la parte de la pantalla que lo contiene.
En ocasiones la animacin sprite se denomina animacin 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
animacin. 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 animacin.
Por ejemplo, se podra crear un bucle de animacin que contenga tres o
cuatro cuadros de un nio caminando. La trayectoria del nio caminando es
su trayectoria de movimiento; cuando se anime, se podr ver al nio movien-

do sus piernas a medida que se desplaza por la pantalla. La mayor parte del
software de animacin por ordenador le permite crear bucles de animacin
de este tipo.
Cuando los objetos se mueven, por lo general, no siguen una lnea recta;
como tal, las trayectorias de movimiento son ms crebles si son curvas. Los
programas de animacin por ordenador normalmente le permiten crear tra-
yectorias de movimiento curvas basadas en splines. Los splines son repre-
sentaciones matemticas 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 animacin de un avin de caza a reaccin.
FIGURA 3.4. Animaciones basadas en trayectorias curvas o splines.
Hoy son muchos los programas de animacin 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 animacin sprite basada en bitmap resulta la animacin
basada en vectores. En lugar de utilizar bitmaps para los sprites, los pro-
gramas basados en vectores utilizan frmulas matemticas para describirlos.
Estas frmulas son similares a las frmulas que describen curvas spline.
Puesto que los objetos son frmulas matemticas, no bitmaps, el tamao de
los archivos es mucho menor. Otra ventaja de la animacin basada en vecto-

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

El nmero de cuadros por segundo de animacin se expresa con el deno-
minado ndice del cuadro. Estos ndices para pelculas son de 24 cuadros por
segundo, para vdeo de 30 y se puede reducir hasta 12 cuadros por segundo
para aplicaciones multimedia. El ndice mnimo de cuadro depende de la ani-
macin. ndices de cuadro de 10 a 15 cuadros por segundo presentan, por lo
general, resultados aceptables.
3.1.5. Puntos clave de trayectoria o extrusin

Al proceso de crear cuadros intermedios entre puntos clave se le conoce
como extrusin. En la animacin tradicional, los animadores ms experi-
mentados dibujaban los cuadros ms importantes o los puntos clave de la
trayectoria. Estos cuadros establecen los puntos principales, definen el flujo
de accin y crean el estilo grfico de la animacin.
FIGURA 3.5. Tcnica de animacin por extrusin o por creacin 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 sita los puntos clave a lo largo de una lnea de tiempo.
La distancia entre los puntos clave en esa lnea determina la cantidad de
tiempo entre ellos, y a su vez, el tiempo entre los puntos clave determina el
nmero 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. Animacin de personajes
Este tipo de animacin es la que se puede ver, por lo general, en los dibu-
jos animados, es un tipo especial de animacin. Se diferencia del resto de
tipos de animacin, como por ejemplo grficos en movimiento o logos ani-
mados, en el hecho de que implica formas orgnicas complejas con mltiples
movimientos secundarios y jerrquicos. En el simple movimiento de un per-
sonaje animado que hable, adems 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 tcnicas se presentan ms
adelante en este mismo apartado.
3.1.7. Pistas y secuenciadores de animacin
Un buen programa de animacin por ordenador proporciona mltiples

capas que se pueden utilizar para crear una animacin. Cada objeto ani-
mado se sita 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 sitan en la escena. La mayor parte del software de
animacin por ordenador utiliza una lnea de tiempo basada en pistas o un
secuenciador para la coreografa de la animacin. Esta lnea de tiempo
basada en pistas y secuenciador proporciona una visin preliminar de la
animacin.
Cada pista representa una propiedad que se anima con el tiempo. La pis-
ta contiene el punto clave e informacin de la animacin para esa propiedad.
Cada objeto individual puede tener asociadas varias pistas de animacin; un
solo objeto puede tener una pista separada para cada uno de los parmetros
que varan con el paso del tiempo, como por ejemplo la posicin, tamao,
forma, velocidad o propiedades de la superficie. Se puede crear un punto cla-
ve al elegir un punto en la lnea de tiempo y luego elegir un valor para un
parmetro que vare con el tiempo, como por ejemplo la posicin o color. El
ordenador genera cuadros intermedios entre los puntos clave interpolando
los valores para los parmetros especificados.
FIGURA 3.6. Tcnica de animacin de personaje en Director.
3.1.8. Tcnicas de animacin

Se analizan a continuacin algunas de las tcnicas ms utilizadas en ani-
macin:
Piel de cebolla.
Recortes.
Deceleracin/aceleracin y curvas de velocidad.
Accin secundaria y accin sobrepuesta.
Lnea de accin.
Exageracin.
No existen reglas mejores ni peores; la tcnica que funcione mejor depen-
der de la animacin concreta y de los objetivos del diseo. Estas tcnicas
incluyen formas de dibujar animaciones y formas de realizar su coreografa.
a) Piel de cebolla
Muchos programas de animacin 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 caractersticas de capas y trans-
parencia en programas de proceso de imgenes como Photoshop para simular-
lo. Es una tcnica de dibujo tramada prestada de la animacin tradicional de
celuloide que ayuda al animador a crear la ilusin de movimiento. En la anima-
cin tradicional, cada cuadro se dibuja en capas de acetato o celuloide transpa-
rente. En lugar de trabajar en cada cuadro por separado, los animadores sitan
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 animacin son otra tcnica tomada prestada de la anima-

cin tradicional de celuloide. Cuando el movimiento de un personaje est limi-
tado, por ejemplo, a decir hola con la mano, es ms 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 grfi-
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 tc-
nica es de utilidad a la hora de animar movimiento limitado como, por ejem-
plo, los movimientos de la boca durante los dilogos.
c) Deceleracin/Aceleracin 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 transicin 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 reduccin y aceleracin 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 pequeos entre cuadros, mientras que los movi-
mientos rpidos tienen mayores cambios. Las transiciones entre un estado de
FIGURA 3.7. Animacin 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 difciles de establecer de forma suavizada aunque,

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

en la direccin del movimiento, como si fuera de goma. Es una forma de dar
la sensacin de peso.
FIGURA 3.8. Ejemplo de tcnica de animacin por estirado y aplastamiento del objeto.
3.2. IMGENES EN 3 DIMENSIONES. CREACIN

Y ANIMACIN
3.2.1. Programas de 2D para crear 3D

La forma ms sencilla de crear imgenes 3D es a partir de una imagen
plana o 2D y aadirle dimensionalidad. Hoy casi todos los programas de dise-
o 2D incluyen herramientas para agregar sombras, texturas, efectos de ilu-
minacin y superficies de relieve, que producen un efecto de tridimensionali-
dad a objetos planos. Los objetos 3D ms sencillos que pueden crearse son
dar relieve a texto plano y crear botones de accin en 3D jugando con mapas
de relieve e iluminacin del objeto plano.
Existen otros mtodos sencillos para dar tridimensionalidad como son la
posibilidad de dar perspectiva a figuras planas, aadir contornos concntri-
cos, tcnicas de golpeo y apretamiento, etc.
FIGURA 3.9. Creacin de un elemento de tres dimensiones a partir de uno de dos.
3.2.2. Programas para crear grficos 3D

Son diferentes las tareas de un proceso de creacin de grficos 3D:
En la tarea de modelado, se crea la estructura bsica de sus objetos y
se sita en un mundo 3D.
En la de animacin, por lo general, se asignan diferentes posiciones de
puntos claves de trayectoria a los objetos en una lnea de tiempo. El
ordenador genera cuadros intermedios entre esos puntos clave (extru-
sin) para simular movimiento en su mundo 3D, y realiza todo el tra-
bajo de crear perspectiva, iluminacin, sombras y efectos ambientales.
Esta tarea es similar a la animacin de puntos clave en programas de
animacin 2D, pero ms potente.
En el render, el ordenador pinta su mundo 3D en funcin de la ilumi-
nacin, propiedades del material y vistas de la cmara que ha creado.
Las propiedades del material definen el color, textura y propiedades de
superficie de un objeto. Las luces y los efectos atmosfricos definen el
entorno de su mundo.
La tarea final es unir o componer grficos 3D con otros elementos gr-
ficos utilizando programas como Photoshop, Debabeiizer, Director,
AfterEffects o Premiere.
Disear un mundo 3D no es un proceso sencillo, lineal, paso a paso, sino que,
por lo general, implica alternar entre el modelado y la animacin, realizando ren-
ders de prueba en diferentes puntos para comprobar varios aspectos de su mun-
do, y luego realizar una presentacin final de alta calidad que puede llevar
muchos minutos, horas o incluso das. Los procesos de modelado, animacin,
render y composicin se tratan con detalle ms adelante en este mismo apartado.
Los siguientes apartados proporcionan ms detalles sobre lo que necesi-
ta, en trminos de requisitos de sistema y software, para crear grficos 3D.
3.2.3. Requisitos de sistema para 3D

Los programas grficos en tres dimensiones requieren mucha memoria
RAM y disco duro. Cuanto ms complejos sean los modelos y animaciones, y
cuantos ms mapas de textura se utilicen, ms memoria se necesitar. Adems
se puede tener abiertos otros programas, como Photoshop, mientras se trabaja
en el programa 3D, lo que supone ms memoria. Es decir, se tendr que dispo-
ner de tanta memoria como pueda. Igualmente sucede con la capacidad de
clculo del ordenador, deber ser tan rpida como sea posible. Tambin se nece-
sita mucho espacio en disco ya que, por regla general, una animacin 3D de 1
MB puede generar fcilmente 10 MB de archivos intermedios.
3.2.4. Software 3D
Como se ha mencionado anteriormente, el proceso de diseo en 3D impli-
ca varias tareas. Estas tareas son el modelado, animacin, render y composi-
cin. Los programas de software en tres dimensiones gestionan una o ms de
estas tareas.
FIGURA 3.10. Pantalla de trabajo de la aplicacin 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, animacin y render. Virtus
Walkthrough Pro, Gryphon Morph, el Valls Group PixclPutty y Metaflo pro-
porcionan caractersticas especializadas de modelado, animacin 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 produccin.
El programa 3D que se elija debera ser capaz de exportar animaciones
como pelculas QuickTime, una secuencia de archivos PICT numerados,
archivos BMP o archivos TARGA. PICs es un formato comn para exportar
animacin. Tambin se debera soportar importar/exportar el formato DXF
de AutoCAD, utilizado para intercambiar modelos 3D entre diferentes pro-
gramas EPS o EPSF que permite importar curvas Bzier 2D y grficos de pro-
gramas como FrceHand e Illustrator.
FIGURA 3.11. Pantalla de trabajo de la aplicacin de modelo 3D, 3D Studio MAX.

3.2.5. Cmo funciona el mundo 3D

En programas 3D, se agrega una tercera dimensin 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-
cisin 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 parmetros que se pueden editar como la
perspectiva y la orientacin. En un principio, es muy fcil 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 bsicas, como
por ejemplo el cubo, la esfera y el cono, que se pueden utilizar para crear mode-
los ms 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 bsica de un mundo 3D (tambin denominado un modelo). Los
modelos se construyen a partir de curvas Bzier. Se puede posicionar objetos
en su mundo 3D por medio del ratn 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 difcil decir dnde se encuentra un objeto
dentro del sistema de coordenadas 3D, cuando se cree un objeto, quiz sea ms
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 cmo se orienta el objeto en el espacio 3D.
3.2.7. Animacin
La animacin se crea a partir de una secuencia de imgenes fijas o cua-
dros que se reproducen rpidamente en sucesin, de modo que el ojo lo per-
cibe como un movimiento continuo.
FIGURA 3.12. Dos perspectivas de un modelo 3D bsico.

Los programas de tres dimensiones con posibilidades de animacin, nor-

malmente utilizan una lnea 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 vrtices individua-
les, o controlar puntos. Las trayectorias de movimiento son curvas editables.
Los formatos de salida ms habituales para las animaciones 3D son las
secuencias de Bitmaps o como pelculas 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 atmosfricos.
Iluminar un mundo 3D es similar a iluminar una escena o una parte de una
pelcula, con la excepcin de que se pueden situar las luces en cualquier lugar
en el espacio 3D y se pueden cambiar fcilmente 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
especficos, 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 fsica. 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 estn hechos y la iluminacin 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. Tambin se pueden animar,
proyectar y situar texturas con orientaciones diferentes, y se puede simular efec-
tos de iluminacin y parmetros de transparencia con mapas de texturas. Algu-
nos programas soportan incluso pelculas QuickTime como mapas de textura.
Las texturas procedurales utilizan ecuaciones matemticas para gene-
rar propiedades de superficie. Puesto que las texturas procedurales son clcu-
los matemticos, 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 libreras de texturas. Se
pueden utilizar programas de creacin 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 vdeo son otras
formas de crear texturas del mundo real.
3.2.11. Diseo del interfaz 3D

Los botones y los cuadros de dilogo se han convertido en algo comn en
los interfaces de usuario. Los grficos en tres dimensiones se inclinan por el
sentido tctil, lo que aumenta la sensacin de encontrarse directamente
manipulando objetos en la pantalla del ordenador.
Un interfaz de usuario 3D bien diseado ofrece una impresin visual ms
clara de sus funciones. El diseo de un interfaz de usuario en tres dimensio-
nes utiliza los mismos principios que el diseo del interfaz de usuario 2D.
Aqu tiene algunos consejos para su diseo:
FIGURA 3.15. Ejemplo de un Interfaz con inclusin de elementos y sistema de navegacin 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 iluminacin es suficiente para proporcionar la impresin de una ter-
cera dimensin.
Utilice luces paralelas (luces distantes en Extreme 3D) especialmente si

necesita reducir su interfaz a varios colores.
Utilice posiciones numricas 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 mtodos de mayor calidad llevan mayor can-
tidad de tiempo. Existen diferentes mtodos 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. Composicin
La composicin es el proceso de unir diferentes elementos grficos en

una sola imagen o animacin. Algunas veces es mejor realizar el render de
objetos y animaciones 3D por separado.
La composicin 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 aplicacin es utili-

zar un fondo 3D. Si crea su fondo como un modelo en un programa 3D, resul-
ta sencillo cambiar la perspectiva, iluminacin y efectos atmosfricos 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 cmara y las vistas en el programa 3D. Evite superficies planas
paralelas a la pantalla del ordenador. La iluminacin en un ngulo bajo y las
sombras tambin pueden agregar un sentido de profundidad. Una tcnica
sencilla, como agregar un desenfoque gaussiano a la capa de fondo, crea una
sensacin de profundidad en la escena. Asegrese que el fondo no compite
visualmente con el contenido del interfaz y que tiene un estilo grfico 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 deberan estar iluminados desde la misma direc-
cin.
Las luces deberan ser de una intensidad y color similar.
Los parmetros de entorno global, como la luz ambiental y la niebla,
deberan ser los mismos en los grficos 3D generados, a menos que est
diseando para conseguir un determinado efecto.
Utilizar colores y propiedades de superficie similares para asignar a sus
grficos una unidad de estilo.
Antes de iniciar el render, determine el orden de las capas de sus grfi-
cos 3D y planifique la composicin de acuerdo a ello.
Decida, en un principio, cmo desea componer las sombras: Desea
generar las sombras con el objeto 3D, agregarlas ms tarde como una
capa aparte, o dibujarlas directamente en el fondo con alguna herra-
mienta?
Es una buena idea generar sus imgenes 3D con unas dimensiones ms
grandes que lo que vaya a necesitar, y luego cambiar el tamao de la imagen
a las dimensiones que desea para su proyecto. La calidad de los grficos que
se cambian de tamao es mejor si empieza con un grfico grande y luego
reduce el tamao, en lugar de empezar con uno pequeo.
FIGURA 3.16. Detalle del cuadro de opciones de renderizacin de la aplicacin

3D Studio MAX.
3.3. ELEMENTOS BSICOS PARA COMENZAR

A DIGITALIZAR VDEO
3.3.1. Conceptos tcnicos

La Cinta: Para grabar las seales de vdeo se emplea la denominada cin-
ta magntica, consiste en un soporte de polister recubierto por partculas de
compuestos frricos dispersos en un adhesivo. Las de xido de cobalto de alta
energa son las de mayor nivel de calidad.
El Vdeo: El vdeo es un sistema dedicado al almacenamiento de imge-
nes en movimiento y sonidos sincronizados para su posterior reproduccin
tantas veces como se desee. La edicin de vdeo digital no es otra cosa que el
paso de las seales de vdeo analgicas a seales de vdeo digitales. A conti-
nuacin, se detallan ambos tipos de seales:
Vdeo analgico: Cada fotograma se representa por una seal fluc-
tuante de voltaje, lo que se conoce como una seal de forma de onda
analgica. En el vdeo compuesto todos los componentes de brillo,
color e informacin de sincronizacin se combinan en una sola seal.
Como consecuencia de esto la calidad es menor y las prdidas genera-
cionales mayores.
El vdeo por componentes reduce este problema. En este formato se
toman los distintos componentes de la seal de vdeo y se emiten
como seales separadas. Gracias a estas mejoras surgi el nacimiento

de formatos como S-Vdeo y RGB.
Vdeo digital: Es una representacin digital de la seal analgica (la
informacin va en forma de bits). Adicionalmente el vdeo digital pue-
de exportarse a cinta analgica para su uso en los reproductores tra-
dicionales. La seal, a diferencia del vdeo analgico, no se degrada en
calidad de una generacin a otra. Utilizar el ordenador para el vdeo
digital aporta muchas ventajas, ya que se puede acceder aleatoria-
mente a las pelculas almacenadas y se pueden comprimir (con el aho-
rro de espacio de almacenamiento que esto conlleva).
Diferentes tipos de ediciones de vdeo: En general, la edicin de vdeo
analgico conlleva una destruccin del original, es decir, que cualquier
modificacin que se realice durante la edicin sobre el original hace que ste
cambie y, por tanto, se destruya su estado inicial. En la edicin de vdeo digi-
tal no se destruye el original. Los efectos, alteraciones, recortes y cambios
que se apliquen a un corte de vdeo para utilizarlo en un proyecto determina-
do no afectan al vdeo a partir del cual se est trabajando. Los trminos des-
tructivo/no destructivo definen el tipo de procedimiento que se utiliza para
editar el vdeo.
Fotogramas o Frames: Estos trminos (en espaol y en ingls) se van a
manejar continuamente a la hora de editar vdeo. Hacen referencia a las im-
genes fijas que se muestran a lo largo de un segundo de pelcula (ya sea vdeo o
televisin). Existen varios estndares de televisin y cada uno de ellos se basa
en una cantidad de frames o fotogramas emitidos por segundo (figura 3.17).
El ordenador y la televisin no manejan el vdeo de igual manera. A con-
tinuacin, se establece la diferencia entre vdeo no entrelazado y entrelazado:
Vdeo no entrelazado: El monitor del ordenador suele utilizar un pro-
ceso denominado escaneado progresivo para actualizar la informa-
cin que muestra la pantalla. De forma que en el fotograma se mues-
tran todas las lneas de la imagen.
Vdeo entrelazado: Cada uno de los fotogramas o frames queda divi-
dido en dos campos, uno de ellos contiene las lneas pares y el otro las
impares de la imagen. En televisin, primero se muestra el primer
campo (es decir, las lneas pares) y despus el segundo, percibiendo el
ojo la imagen completa.
La Secuencia: Se denomina secuencia a la sucesin ininterrumpida de
escenas o planos que integran una etapa descriptiva, una etapa de la accin o
un tramo coherente y concreto del argumento (figura 3.18).
La Pelcula: Se puede decir que una pelcula es la sucesin de mltiples
secuencias. Cuando se trabaja con archivos de vdeo en el ordenador, se guar-
darn en formato de pelcula, los ms 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 relacin que existe entre la seal til y

los ruidos inherentes al sistema. La calidad en la edicin digital depen-
der de la cantidad de bits que utilice la tarjeta de digitalizacin para reali-
zar el muestreo de la informacin analgica. Tambin depender la calidad
de las ediciones de vdeo, del sistema de conexin utilizado para unir el dis-
positivo fuente con la tarjeta de digitalizacin. El tipo de conexin que se
puede encontrar en las tarjetas de digitalizacin domsticas es RCA y S-
Vdeo.
Resolucin: Se refiere a la definicin que proporciona en lneas y es un
parmetro fundamental al hablar del vdeo. El grado de definicin de una
imagen depende del ancho de banda que pueda manejar el sistema. En Euro-
pa el factor de resolucin horizontal es de 80 lneas por cada MHz de seal
tratada. La resolucin vertical consiste en la cantidad de lneas de escaneado
horizontales. Debe tener en cuenta que en la industria del vdeo se habla de
resolucin horizontal como si la pantalla tuviera la misma anchura que altu-
ra, cuando en realidad suele ofrecer una relacin de cuatro tercios, y en el
futuro se apunta este dato hacia la relacin 16:9.
Resolucin espacial o tamao de ventana: La resolucin espacial, es
decir, el espacio que debe ocupar una imagen en funcin de su resolucin
para que se visualice con la calidad adecuada es el motivo de que existan dife-
rentes tamaos de ventana en el vdeo por ordenador.
En Estados Unidos, NTSC 640 x 480 pxeles, por lo que se ha asumido que
el estndar para el vdeo 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 pxeles de resolucin.
Estndares: No se pueden olvidar los diferentes estndares de televisin
que existen: PAL, NTSC y SECAM principalmente. Cada uno trabaja con una
resolucin y velocidad distintos y, en el caso de que se quiera volcar de nuevo
a cinta un vdeo una vez editado, se deben conocer dichos parmetros para
que la pelcula pueda ser reproducida en un aparato de vdeo. En Espaa, al
igual que en la mayor parte de Europa Occidental (a excepcin de Francia) se
utiliza el denominado PAL (Phase Alternation Line) que consta de 625 lneas
horizontales a una velocidad de 25 fotogramas por segundo.
Luminancia y crominancia: Se trata de las seales referentes a la luz y
el color en la seal de vdeo. Se las denomina tambin Luma y Croma. La
seal 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
parmetros, la luzluminancia y el colorcrominancia, son los principales dife-
renciadores de los distintos tipos de vdeo:
Vdeo compuesto (Composite vdeo): Toma su nombre del hecho de
que emite el factor luminancia (Y) de una imagen de vdeo y el factor
crominancia (C) como un compuesto de ambos. Generalmente la
salida de un reproductor VHS es una seal compuesta (YC).
Super-vdeo (S-Vdeo): Emite el vdeo separando la luminancia de la
crominancia, lo que permite obtener una mayor resolucin.
RGB (Red, Green, Blue o rojo, verde y azul): Tiene la mejor calidad.
Emite el vdeo en funcin de una mezcla de las porciones de rojo, ver-
de y azul del espectro visible de luz, en lugar de en funcin de la lumi-
nancia y la crominancia. Aunque no hay una correlacin directa entre
RGB y YUV (uno de los formatos ms comunes del color en el vdeo
analgico) ambos tienen varios niveles de profundidad de color (can-
tidad mxima de colores que se pueden mostrar).
Compresin: Se trata del proceso de reduccin del tamao de la infor-
macin digital. La compresin permite almacenar razonablemente grandes
cantidades de vdeo en el disco duro. Existen dos tipos de compresin: con
prdidas y sin prdidas. La compresin con prdidas 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 informacin
redundante, eliminando la informacin que el ojo humano no es capaz de
detectar.
3.3.2. Los requerimientos del hardware y software

para la digitalizacin
Lo primero es conectar el aparato reproductor de vdeo o la videocmara
a la tarjeta. Todas las tarjetas deben venir provistas de cables con conectores
para entrada/salida de audio y vdeo, a las que deber conectar un cable
cuyos contactos sean adecuados a las tomas de la tarjeta.
Seguidamente, debe introducirse la cinta de vdeo que contiene la pelcula
que se desea digitalizar en el aparato de vdeo o videocmara. Conviene posicio-
nar la cinta de vdeo 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 edicin, en el caso de trabajar con Adobe Premiere, el
programa presentar un cuadro de dilogo de Configuraciones de proyecto
nuevo (figura 3.19). En este cuadro se deber elegir QuickTime o AVI para el
Modo de edicin. 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 edicin. Si se estuviera produciendo la versin final de un
programa de vdeo en formato NTSC, se debera seleccionar 29,97. Hacer clic
en Siguiente para abrir la seccin Configuraciones de vdeo del cuadro Con-
figuraciones de proyecto nuevo (figura 3.20).
En tamao, se debe escribir 240 en el cuadro izquierdo para definir la
anchura del previo. Puesto que la opcin Aspecto 4:3 est activada, aparece-
r automticamente 180 para la altura de los fotogramas del previo. Esta con-
figuracin 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 dilogo de Configuraciones de proyecto nuevo de Premiere.

FIGURA 3.20. Seccin Configuraciones de vdeo del cuadro Configuraciones de proyecto nuevo.
Muchas de las configuraciones de proyecto que se acaban de definir

determinan cmo se construir y se exportar el programa de vdeo. Ahora
Premiere est configurado para trabajar con clips importados.
En el men Archivo, hay que seleccionar Capturar. Esta opcin muestra
un men desplegable en el que se deber elegir Captura de clips. Se abrir
una ventana (con el tamao que se haya seleccionado) con un nico botn en
su parte superior para grabar (figura 3.21).
FIGURA 3.21. Ventana Captura de clips.

3.3.3. Sugerencias para la captura de vdeo

La grabacin digital de vdeo de fotograma completo con movimiento
normal requiere un ordenador rpido con mucho espacio en disco. El tama-
o de los fotogramas, el nmero 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 vdeo.
A medida que se aumenta de calidad, se aumenta la cantidad de datos
requeridos para representar el vdeo. Los avances recientes en el poder de los
procesadores y en memoria han permitido que los sistemas informticos de
sobremesa procesen datos con suficiente eficacia para capturar, almacenar y
proyectar vdeo digital.
La posibilidad de capturar el vdeo de la ms alta calidad depende del
vdeo de origen y del hardware. Ya que la calidad del vdeo capturado no
superar nunca la calidad del vdeo de origen, debera usar el vdeo de origen
de la ms alta calidad posible.
Son varios los factores hardware que afectan a la velocidad mxima de los
fotogramas y al tamao de imagen que se puede conseguir durante la captu-
ra y la proyeccin. Seguidamente se abordan para una mayor informacin
los siguientes temas:
La velocidad de la tarjeta de captura: A mayor velocidad de la tar-
jeta de vdeo, ms velozmente se dibujarn los fotogramas de vdeo en
pantalla. Para capturar vdeo de fotograma completo a 30 fps, la
mayora de las tarjetas capturan slo uno de dos campos (la mitad de
las lneas de pantalla) en cada fotograma y replican los datos para
completar el fotograma. La calidad de imagen resulta comprometida.
Para capturar imgenes de tamao 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, ms
velozmente podrn 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 ms. 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 vdeo ser la mitad de la velocidad de transferencia de datos.
Puede conseguir velocidades de transferencia ms altas mediante
conexiones especiales SCSI, como las matrices de disco, SCSI II o
SCSI rpido (fast).
La velocidad de la CPU: Cuanto ms rpida sea la CPU, ms rpida-
mente podr el ordenador procesar los datos necesarios para capturar
y proyectar el vdeo 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 pelcula. Debera tambin reducir el tamao del cache
de disco y asegurarse de que la asignacin de memoria virtual no es
ms 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 estndares ms rpidos de bus
son el VESA Local Bus, o VL-Bus, y el nuevo estndar 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 mtodo mejor para la captura de vdeo es
directamente en memoria, RAM. Capturar en memoria RAM es ms rpi-
do que capturar en un disco duro, y se recomienda cuando tiene sufi-
ciente memoria libre para almacenar la pelcula capturada. Sin embargo,
el tamao de la pelcula se limita a la cantidad de memoria libre. La can-
tidad de memoria que necesita depende del tamao de imagen, velocidad
de fotograma, mtodo de compresin y duracin del vdeo capturado.
Experimente con un corte para averiguar si tiene suficiente memoria.
3.4. EDICIN Y EFECTOS DEL VDEO DIGITAL

Una vez digitalizada la pelcula 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 grabacin 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 despus se pulsar el botn Inicio situado a la derecha del rea
de estado.
Ser preciso despus posicionar el manejador en el fotograma en que se
quiera que termine la seleccin 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 pestaa 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 porcin que se desea aadir al proyecto en primer
lugar. Un cuadro de alerta le preguntar si se quiere guardar el archivo antes de
aadirlo al proyecto. Como se coment anteriormente, sta es una de las venta-
jas de algunas aplicaciones: permiten realizar videoedicin 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 ubicacin 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.
Quedarn automticamente numerados para poder trabajar con ellos.
Cada uno de los cortes que se hayan arrastrado a la ventana de Proyecto
se irn almacenando en ella. Adems quedarn identificados por el nmero
de corte de que se trate, y se podr ver una pequea ventana con la primera
imagen de ese corte e informacin sobre su duracin y resolucin.
Seguidamente hay que elegir del men Ventana la seleccin Ventana de
construccin y, aparecer la Ventana de construccin del proyecto. sta
cuenta con varias pistas de vdeo, audio y transiciones. Por el momento se
utilizar la primera pista de vdeo 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 pelcula a esta
pista y colocarlo al principio de la misma (a la izquierda). Despus debe repa-
tirse con los restantes cortes. Se puede observar en la ventana de Construccin
que, segn se coloca un corte sobre ella, distribuye los fotogramas a lo largo
de la pista de vdeo. 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 vdeo en el espacio visual disponible.
Para previsualizar lo que se acaba de construir hay que pulsar Enter o
hacer clic en el botn de la parte superior derecha de la ventana de construc-
cin, marcado con el smbolo de reproducir. Aparecer la ventana de Visuali-
zacin monitor (figura 3.22). Es preciso reproducir la grabacin para com-
probar la forma en que quedar finalmente. Una vez que se tenga ms
confianza con el proceso de digitalizacin se podrn realizar ms acciones en
la pelcula, hacer cortes, eliminar o duplicar fotogramas, insertar transicio-
nes entre unas secuencias y otras o incluir ttulos sobre el vdeo.
3.4.1. El Volcado a cinta de vdeo
Una vez construido el vdeo, podr ser convertido en una pelcula en una
cinta. Para ello, en el men Archivo, hay que seleccionar Exportar y se abrir
un men desplegable donde se deber escoger Pelcula (o utilizar la combi-
nacin de teclas Ctrl+M) y aparecer el cuadro de dilogo Exportar pelcula y
hacer clic en Configuraciones.
FIGURA 3.22. Ventana de Visualizacin monitor.
El cuadro de dilogo Exportar pelcula pedir que se d un nombre y una

ubicacin al archivo. Adems, informar en su parte inferior de la resolucin
de la pelcula, fotogramas por segundo, codec de compresin y configuracin
de audio.
En el cuadro de dilogo de Configuraciones para exportar pelcula
podrn 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 varan segn el tipo de archi-
vo que se elija.
Rango: Se deber seleccionar Microsoft AVI, aunque tambin cuenta
con diversas opciones adicionales.
Exportar Vdeo: Deber seleccionarse esta casilla de verificacin para
exportar las pistas vdeo o tambin, no es nuestro caso, deseleccionar-
se para evitar la exportacin de las mismas.
Exportar Audio: Al no preocuparse todava del sonido se puede dese-
leccionar la casilla de verificacin.
Abrir al acabar: Es conveniente seleccionar esta opcin. Marque esta
casilla de verificacin si quiere que el programa abra automticamen-
te la pelcula una vez terminada.
Si la tarjeta de digitalizacin no ofrece la posibilidad de mostrar un panel
desde el que se pueda controlar los parmetros relativos a la salida de vdeo,
se podr emplear las opciones que Adobe Premiere ofrece para ello, se deben
seguir los pasos siguientes:
FIGURA 3.23. Configuraciones para exportar pelcula.
1. Generar la pelcula utilizando el codec de la tarjeta.

2. Cuando finalice el proceso, elegir la funcin para ello, en el men Archivo,
hay que seleccionar Exportar y se abrir un men desplegable donde se
deber escoger Imprimir en vdeo. Aparecer la ventana de la figura 24.
3. En la ventana de Imprimir en vdeo, se debern ajustar la duracin de
barras de color y de pantalla negra.
4. En este mismo cuadro de dilogo se podrn realizar otro tipo de ajus-
tes que permitirn alterar el tamao de la pelcula. En el caso de que
incremente el tamao de cuadro mediante estos ajustes, la aplicacin
interpolar la informacin para obtener las nuevas dimensiones. Esto
significa que se estar perdiendo resolucin en la pelcula.
4. Pulsar el botn de grabar en el dispositivo analgico y, a continuacin,
hacer clic en el botn Aceptar de Imprimir en vdeo.
Esperar a que finalice el proceso y detener la grabacin en el aparato de
vdeo. Comprobar que el resultado es adecuado reproduciendo la pelcula desde
la cinta analgica y visualizndola en un monitor o en la pantalla del ordenador.
3.4.2. Formatos de vdeo

En el vdeo digital, adems de todo lo abordado en puntos anteriores, es
necesario pensar en la tecnologa multimedia con un sistema operativo capaz
de controlar el hardware de produccin.
Windows hace posible la instalacin de diferentes tecnologas: Vdeo for
Windows (ya obsoleta) DirectX y QuickTime. A estas tecnologas se les debe
aadir las especficas para la reproduccin de vdeo y audio en Internet.
FIGURA 3.24. Vetana de Imprimir vdeo.
Estas tecnologas se encuentran a nivel de sistema operativo, y son las

nicas que permiten la comunicacin con la tarjeta de captura de vdeo y las
que precisan las aplicaciones de edicin de vdeo para su correcto funciona-
miento. Las tecnologas como DirectX o QuickTime tambin son las respon-
sables de limitar el tipo de informacin que se va a poder manejar durante el
proceso de edicin. Esto ser as siempre que se grabe el archivo resultante
en un formato compatible con la propia tecnologa.
AVI (Audio Video Interleave)
Hoy DirectX, es el formato de vdeo utilizado por el software de repro-

duccin Video for Windows, y est soportado por la mayora de herramientas
de creacin en entorno Windows.
Su caracterstica principal es el entrelazado de los datos de vdeo con los
de audio dentro del archivo que contiene la secuencia, y as se produce la sin-
cronizacin entre audio y vdeo.
Otras caractersticas podran ser:
Reproduccin desde disco duro o CD-ROM.
Reproduccin en ordenadores con memoria limitada al trabajar con
un rango medio de ndices de transferencia de informacin.
Rpida carga y reproduccin al usar slo algunos cuadros de vdeo a
la vez, y una porcin de vdeo.
El gran auge de este formato ha sido debido a la extensin de las plata-
formas Windows que integran por defecto este formato de almacenamiento y
reproduccin.
QuickTime
Se podra decir que QuickTime es algo ms que un formato de vdeo, es

un formato multimedia que proporciona entornos de vdeo (almacenamiento
y reproduccin), audio digital, realidad virtual, etc.
QuickTime proporciona un interfaz estndar, reproduccin y caractersti-

cas para comprimir/descomprimir en mltiples plataformas.
Est soportado por plataformas Windows y Macintosh, y se encuentra
altamente integrado con las actuales tarjetas de captura de vdeo MPEG A y B.
QuickTime engloba cuatro elementos:
Un sistema de software.
Un conjunto de algoritmos de compresin.
Un formato estndar de ficheros de vdeo.
Un interfaz para definir la captura de vdeo, compresin y caracters-
ticas de reproduccin.
Usa codecs ms adecuados para Macintosh, como son Animation,
Video, Photo-Jpeg; codecs para plataformas Windows como es Intel
Indeo en sus diversas versiones.
Una pelcula QuickTime es un conjunto de pistas en las que se contie-
nen distintos tipos de datos multimedia, todos ellos coordinados con
un sistema comn de tiempos para lograr su sincronismo.
En resumen, es un formato de caractersticas similares a AVI, pero que
incluye una serie de opciones y herramientas de valor aadido que lo
convierten en un sistema multiplataforma.
La tecnologa que se decida instalar en el equipo tendr una gran
importancia a la hora de determinar la calidad de los proyectos, la
integracin con mltiples medios de volcado y la calidad de reproduc-
cin desde ordenador.
3.4.3. Codecs
Se va a ver a continuacin una buena cantidad de esquemas de compre-
sin y descompresin. En cualquier caso, tanto la tecnologa QuickTime
como Vdeo para Windows y DirectX soportan un mayor nmero de codecs
que los que aqu se recogen.
MPEG (Moving Pictures Experts Group)
Su aplicacin est muy extendida entre diversas tecnologas de vdeo y
multimedia. Se ha convertido en un formato internacionalmente aceptado.
Su principal virtud como compresor es la de generar archivos suficientemen-
te pequeos; por tanto, se podr trabajar con ms minutos de vdeo al ocupar
ste menos espacio en el disco duro. Como descompresor, su principal carac-
terstica es reproducir vdeo 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 descompresin MPEG. Existen varias ver-

siones de compresin MPEG, ya que algunas de las evoluciones de este for-
mato se han centrado en el tratamiento del sonido o del vdeo digital en for-
mato DVD (Digital Versatile Disk).
MPEG ha ido evolucionando hacia una serie de subformatos capaces de
ofrecer un rendimiento especfico segn la calidad que se desee obtener. Por
ejemplo, el MPEG original realiza los procesos de descompresin por soft-
ware, mientras que los algoritmos MPEG-2 y 3 realizan la descompresin
mediante tarjeta hardware para lograr la reproduccin a pantalla completa.
Existen algunas utilidades software que permiten la compresin y reproduc-
cin 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 digitalizacin de vdeo para permitir la captu-
ra en formato PAL. Cuando se va reproducir una pelcula con compresin
JPEG, es necesario que el ordenador tenga instalada la misma tarjeta que se
utiliz para su captura. Para disminuir esta limitacin, lo ms recomendable
es grabar la pelcula final utilizando otro compresor que soporte la compre-
sin espacial o de menor prdida.
Es un sistema sucesor de las aplicaciones de retoque fotogrfico. El siste-
ma JPEG a diferencia de los anteriores esquemas de compresin/descompre-
sin, comprime la informacin fotograma a fotograma; es decir, que no tiene
en cuenta la informacin de las imgenes posteriores ni de las anteriores.
Este compresor es de tipo destructivo por lo que desde el punto de vista
de la calidad, la compresin JPEG implica prdida de informacin: elimina
para la correcta visualizacin de los fotogramas comprimidos aquella infor-
macin que considera redundante o innecesaria.
MJPEG
En este caso, a diferencia del codec MPEG, la compresin se realiza
teniendo en cuenta, tanto la informacin de la imagen a comprimir, como la
de las anteriores y posteriores. Las pelculas comprimidas con formato
MJPEG s podrn editarse posteriormente. El resultado generado por este
codec es un menor tamao de archivo y mayor calidad de la pelcula digitali-
zada. QuickTime ofrece dos variantes del codec MJPEG: A y B. Ambas varian-
tes del codec ofrecen los mismos ajustes de personalizacin al usuario, el
resultado obtenido variar considerablemente en la tasa de transferencia. La
variante MJPEG-A suele generar archivos muy pequeos, adems de mante-
ner una tasa de transferencia apta para su inclusin en ttulos CD-ROM. Por
el contrario, la variante MJPEG-B genera archivos de mayor tamao (inclu-
so, en ciertas condiciones, el tamao 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 pelcula.
Intel Indeo
Un archivo de vdeo 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 vdeo com-
primidos con Indeo en formato .AVI pueden ejecutarse en Vdeo para Windows
(Windows 3.x,.Windows 95 y superiores), y los clips de vdeo comprimidos con
el codec Indeo en formato .MOV pueden ejecutarse en QuickTime.
Su tecnologa est basada en un compresor/descompresor (codec) en for-
ma de controlador de software que comprime los datos de vdeo digital para
almacenarlos y los descomprime para su reproduccin en un PC multimedia.
Para que un ordenador pueda ejecutar archivos comprimidos con Indeo debe
instalarse el codec de vdeo de Indeo, utilizando el programa de instalacin
de Intel. En definitiva, Indeo es el software de captura de vdeo digital, com-
presin y descompresin de Intel.
Cinepak
En este codec la calidad de la compresin est supeditada al valor que el
usuario fije como mximo para la transmisin de datos; por tanto, la imagen
se ve bastante mermada por la prdida de la informacin requerida durante
el proceso de compresin que, por otra parte, es algo lento.
Cuando se reproduce la pelcula desde CD-ROM, se obtienen muy buenos
resultados trabajando a 320x240 pxeles de tamao de cuadro y con una velo-
cidad de reproduccin de 15 a 25 imgenes por segundo. Para Internet, pue-
den utilizarse los mismos valores, si bien debe bajarse a 90 kB por segundo el
valor correspondiente al mximo para la tasa de transferencia. De esta forma
se ajusta ms al ancho de banda proporcionado por los mdems, aunque
tambin 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-
cin de los ajustes que se hayan realizado para la compresin.
Permite tambin que se pueda incrementar el flujo de los datos de peque-
o tamao seleccionando la casilla de verificacin Aumentar flujo de datos
bajos, configurando as el mantenimiento del flujo de datos deseado.
3.5. RESUMEN
La forma ms sencilla de crear imgenes 3D es a partir de una imagen
plana o 2D y aadirle dimensionalidad. Hoy casi todos los programas de dise-
o 2D incluyen herramientas para agregar sombras, texturas, efectos de ilu-
minacin y superficies de relieve, que producen un efecto de tridimensionali-

dad a objetos planos. Los objetos 3D ms sencillos que pueden crearse son
dar relieve a texto plano y crear botones de accin en 3D jugando con mapas
de relieve e iluminacin del objeto plano.
Existen otros mtodos sencillos para dar tridimensionalidad como son la
posibilidad de dar perspectiva a figuras planas, aadir contornos concntri-
cos, tcnicas de golpeo y apretamiento, etc.
Actualmente es posible disponer de buenos paquetes de software infor-
mtico de animacin que realizan en cuestin de segundos muchas de las
pesadas tareas que en pocas no muy lejanas tenan que realizar varias per-
sonas durante semanas o meses. Adems, el software de animacin por orde-
nador proporciona todas las ventajas de la edicin digital.
El vdeo es un sistema dedicado al almacenamiento de imgenes en movi-
miento y sonidos sincronizados para su posterior reproduccin tantas veces
como se desee. En la actualidad cabe hablar de dos tipos de vdeo, el vdeo
analgico y el vdeo digital. La edicin de vdeo digital no es otra cosa que el
paso de las seales de vdeo analgicas a seales de vdeo digitales.
A medida que se aumenta de calidad, se aumenta la cantidad de datos
requeridos para representar el vdeo. Los avances recientes en el poder de los
procesadores y en memoria han permitido que los sistemas informticos de
sobremesa procesen datos con suficiente eficacia para capturar, almacenar y
proyectar vdeo digital.
Finalmente, al igual que en el captulo anterior, se recomienda al lector
que quiera profundizar en los contenidos de este captulo, la referencia (Cas-
tro y otros, 2002).

3.1. La pelcula transparente que se utilizaba en la animacin tradicional
dibujada a mano responde al termino:
a) Animacin en celuloide.
b) Animacin en cuadros.
c) Animacin de sprites.
d) Animacin de trayectorias.
3.2. A continuacin se citan algunas de las tcnicas ms utilizadas en ani-

macin, una de ellas no es correcta:
a) Piel de cebolla.
b) Recortes.
c) Deceleracin/aceleracin y curvas de velocidad.

d) Hiteresis.
3.3. Son diferentes las tareas de un proceso de creacin de grficos 3D. La

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

puntos claves de trayectoria a los objetos en una lnea 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) Extrusin.
b) PixclPutty.
c) EPSF.
d) Modelo.
3.5. A la sucesin ininterrumpida de escenas o planos que integran una eta-

pa descriptiva, una etapa de la accin o un tramo coherente y concreto
del argumento de un vdeo, se denomina:
a) Resolucin.
b) Luminancia.
c) Secuencia.
d) Compresin.

ADOBE PREMIERE, 2002. Manual de usuario de Adobe Premiere.
CASTRO y otros, 1996. M. Castro. Comparacin de Tcnicas y Herramientas de Autor
cadas a la Enseanza de la Electrnica, Sevilla,.
CASTRO y otros, 2002. M. Castro. Diseo y desarrollo multimedia: Sistema, imagen,
COLMENAR, 1999. A. Colmenar. M. Castro, y J. Peire. Aplicaciones Didcticas de
los Sistemas Multimedia en la Enseanza a Distancia. 8 Encuentro Ibero-
americano de Educacin Superior a Distancia. Quito-Ecuador, del 22 al 24 de

julio de 1999.
COLMENAR, 1999. A. Colmenar. Propuesta de Diseo Curricular en un Marco Cons-
GARCA, 1983. L. Garca. Los Medios Audiovisuales al Servicio de la Enseanza. Madrid:
Servicio de Publicaciones del ICE de la Universidad Politcnica de Madrid, 1983.
MORATA, 1998. R. Morata y D. Insa. Multimedia e Internet. Ed. Paraninfo, 1998.
RODRGUEZ, 1998. F. J. Rodrguez y A. Garca. Videoedicin Digital. Ed. Paraninfo. 1998.

Captulo 4
FASES DEL DESARROLLO
DE SISTEMAS MULTIMEDIA
ESQUEMA
4.1. Ingeniera del software y multimedia.

4.2. Caractersticas 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 ingeniera
en el que se siguen una serie de fases de manera sistemtica para conseguir
un producto de la mayor calidad posible. La ausencia de aplicacin este tipo
de mtodos bien definidos para el desarrollo de aplicaciones informticas dio
lugar en la dcada de los 70 a lo que comnmente se ha venido denominando
desde entonces crisis del software, convertida ya en afliccin crnica para
Roger Pressman, y que origin la aparicin de la ingeniera del software
como la disciplina que propone la utilizacin de un enfoque sistemtico,
disciplinado y cuantificable para el desarrollo, operacin 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 aplicacin 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 slida teora ni mto-
dos formales que puedan aplicarse debido a las caractersticas especiales de
este tipo de sistemas. Ms en concreto, suele argumentarse que debido al
carcter pluridisciplinar del equipo de desarrollo y la premura con la que se
suele trabajar, es imposible aplicar un mtodo de ingeniera.
El objetivo de este captulo 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 mtodos de ingenie-
ra del software que son aplicables al desarrollo de sistemas interactivos y
en los que de algn modo se recoge la experiencia adquirida por otros dise-
adores. Con este fin el captulo se inicia haciendo una introduccin al por
qu de la utilizacin de ingeniera del software en el desarrollo de aplica-
ciones multimedia como introduccin a la seccin 4.2 en que se lleva a cabo
un anlisis de esas caractersticas de los sistemas interactivos que hacen
que no sea plausible la aplicacin de mtodos tradiciones, entendiendo
como tradicionales aquellos propios del desarrollo de sistemas de informa-
cin. A continuacin se estudiarn, en la seccin 4.3, de forma escueta las
fases tpicas del proceso de desarrollo, puesto que algunas de ellas se abor-
dan de forma completa en otros captulos, as como posibles modelos de
proceso en la seccin 4.4.
4.1. INGENIERA 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 ingeniera del software con el fin de establecer un
vocabulario mnimo que se utilizar a lo largo de este captulo. 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 genrica,
una serie de fases entre las que se encuentran el anlisis, el diseo, la imple-
mentacin y las pruebas o la instalacin, pero en ningn 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-
cin del paradigma adoptado (por ejemplo, en cascada, iterativo, en espiral o
incremental).
DEFINICIN: Ciclo de vida del desarrollo de software.

Es el periodo de tiempo que se inicia con la decisin de desarrollar un producto soft-
ware y que finaliza cuando ste se entrega
DEFINICIN: Modelo de proceso del ciclo de vida del desarrollo de software.

Paradigma que establece de forma racional cmo llegar desde las necesidades del
usuario a un producto software concreto a travs de una serie de fases.
El modelo de proceso, a su vez, tampoco es un mtodo de desarrollo.

Mientras el modelo establece una secuenciacin en las fases del desarrollo,
el mtodo propone de forma detallada qu actividades deben llevarse a
cabo durante cada una de las fases, qu productos o entidades de diseo
deben generarse y tambin ofrece principios bsicos, guas o consejos para
producir un software de mayor calidad. As, existen distintos modelos de
proceso que determinan cmo llevar a cabo las distintas fases del desarro-
llo y, a su vez, para cada modelo de proceso existirn diversos mtodos que
indicarn qu hacer en cada fase as como las interacciones entre las dis-
tintas fases.
La adopcin de mtodos de ingeniera durante el proceso de desarrollo de
los productos software, independientemente del tipo de producto del que se
trate, hace posible una aplicacin sistemtica de conocimiento cientfico con
objeto de construir soluciones efectivas y eficientes a un problema dado
(Berry, 1992). As, la utilizacin 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,
disear interfaces adecuadas y estructurar la informacin 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 mtricas 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 aplicacin va a a ser fcil

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
reutilizacin, la facilidad de mantenimiento, la gestin del proceso y las
medidas tanto del producto como del propio proceso.
4.2. CARACTERSTICAS DEL DESARROLLO MULTIMEDIA
Los sistemas interactivos y multimedia tienen caractersticas intrnsecas

que requieren de enfoques distintos a los que se aplican en otras disciplinas.
As, la primera caracterstica singular que hay que destacar es que en el ciclo
de vida es preciso introducir una nueva fase: la evaluacin. El objetivo de
esta fase, que no debe confundirse con las tpicas pruebas del software pues-
to que no tienen ninguna relacin, es analizar la utilidad de la aplicacin.
Esta fase es tan importante en el desarrollo de sistemas interactivos que el
presente libro le dedica un captulo completo, el septimo.
Adems, existen otros aspectos a tener en cuenta en el proceso de desa-

rrollo de sistemas interactivos que afectan a la seleccin del modelo de pro-
ceso y que hacen que se precisen mtodos especficos que tengan en cuenta
las peculiaridades de este tipo de productos software, entre las que cabe des-
tacar las que se describen a continuacin:
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 especficos.

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 travs de un dilogo que se establece entre el usuario y la mquina, di-
logo que se materializa a travs 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
simplificacin del modelo propuesto por Roy Rada en (Rada, 1995).
FIGURA 4.1. Modelo simplificado de la interaccin entre el usuario y la mquina (basado

en el propuesto en Rada, 1995).
Los agentes que participan en la interaccin son dos: la persona y el orde-

nador, y el canal a travs del cual se materializa el dilogo 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 cul es la secuencia de pasos a
seguir para conseguir su objetivo. Cuando una persona se pone delante de
una mquina para completar una tarea, analiza las funciones que le ofrece el
producto software y realiza una accin orientada a conseguir su objetivo. A
su vez, en el entorno de la mquina el soporte a dicha tarea est implementa-
do de una determinada forma y cada interaccin del usuario da lugar a un
procesamiento que va a generar una salida especfica que el usuario inter-

pretar para decidir si el sistema funciona como l haba 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 interaccin
Tarea: Poner la fecha a una carta en un procesador de textos

Atencin Observa los botones de la barra de herramientas del procesador de tex-
tos tratando de encontrar alguno que inserte la fecha de hoy.
Cognicin Identifica un botn que podra justificar la fecha a la izquierda de la
pgina pero no encuentra uno que inserte la fecha fi tendr que escribir
la fecha y luego justificarla.
Intencin Escribe la fecha, selecciona el texto y pulsa el botn.
Codificacin Observa la respuesta que se produce por parte de la aplicacin: la fecha
ha sido justificada a la izquierda.
Evaluacin 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 accin sobre la interfaz (la intencin) y, tras recibir la respuesta de la
aplicacin, realiza otras actividades cognitivas que le hacen llegar a una con-
clusin sobre el funcionamiento de la aplicacin y la consecucin 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 podra
existir una opcin 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
mquina 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 diseo centrado en el usuario.
DEFINICIN: Diseo centrado en el usuario.

Enfoque de desarrollo en el que juegan un papel central tanto el usuario como sus
necesidades.
El diseo centrado en el usuario, trmino acuado por Gould y Lewis en

1985, tiene como objetivo maximizar la usabilidad del producto para lo cual
se asumen cuatro principios bsicos (Gould y otros, 1997):
Focalizacin temprana y continua en el usuario: es preciso estudiar

las caractersticas cognitivas, antropolgicas, 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 empricas: 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 vlidos sobre la utilidad del sistema.
Diseo iterativo: el modelo de proceso debe permitir iteraciones en
las que se tengan en cuenta los datos empricos recibidos de la interac-
cin del usuario con el producto para mejorarlo.
Diseo integrado: todos los aspectos del diseo de la usabilidad, ya
sea la interfaz, la documentacin o el plan de implantacin, 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 diseo, y,
evaluar esas soluciones frente a los requisitos.
El modelo de proceso elegido, que determina cmo secuenciar estas acti-
vidades depender de mltiples factores, pero siempre se deberan emplear
mtodos que den soporte a las cuatro actividades fundamentales que permi-
ten contar la participacin 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 planificacin de la participacin del usuario incluyen:
es preciso especificar desde el comienzo del desarrollo cundo y cmo
van a participar los usuarios, ya sean stos expertos en el dominio de la
aplicacin o usuarios reales,
hay que tener en cuenta que es conveniente tratar con el usuario en su
entorno de trabajo, y,
la terminologa y la notacin a emplear deben ser familiares para el
usuario o fciles 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 diseo centrado en el humano y sus relaciones (ISO, 1999).
Toda la informacin proporcionada por los usuarios, ya sea en discusio-

nes sobre el anlisis y el diseo o en evaluaciones de prototipos, debe em-
plearse para mejorar el proceso de interaccin convirtindose en una valiosa
entrada para los procesos de anlisis, diseo y construccin.
4.2.2. Equipo de desarrollo pluridisciplinar

El desarrollo de un sistema interactivo es un proceso que tiene mltiples
facetas y, adems, no todas ellas son de carcter tecnolgico. 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 informtico y
por sus usuarios. Para comprender las necesidades del usuario se pueden
requerir conocimientos de psicologa, sociologa, antropologa e incluso
fisiologa, especialmente si el desarrollo en cuestin no slo incluye softwa-
re sino tambin hardware. Por otra parte el sistema informtico puede divi-
dirse en el software de la aplicacin, que ser desarrollado por personal fun-
damentalmente tcnico, y la interfaz de usuario, que requerir de la
intervencin de especialistas en diseo, ingeniera, lingstica o arte
(Faulkner, 1998).
FIGURA 4.3. Visin 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 mninamente pluridiscipli-
nar, contando al menos con:
tcnicos capaces de realizar el anlisis, diseo e implementacin del
software de la aplicacin,
especialistas en las necesidades de los usuarios que puedan tomar deci-
siones sobre las opciones de diseo (psiclogos, socilogos o, por ejem-
plo, pedagogos en un sistema destinado a la enseanza), y,
diseadores grficos y otros especialistas en el tratamiento de informa-
cin multimedia.
En la tabla 4.2 se muestra las habilidades que deberan 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, diseo grfico y
multimedia, etc.
(Continua)
TABLA 4.2. (Continuacin)
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 programacin y
(publicadores) marcado para Web (HTML,
XML, XSL, SMIL, etc), etc.
Encargados del Actualizar y mantener los
mantenimiento del contenidos de informacin. Uso de las bases de datos y/o
Web de lenguajes de marcado.
Administrador del Gestionar el servidor Web, Arquitecturas
Web responsabilizndose 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 documentacin hardware/software existentes
del anlisis y del diseo, (caractersticas, limitaciones,
establecer los procedimientos etc.), tcnicas de
de operacin y de especificacin y modelado,
mantenimiento, definir la publicacin de pginas Web,
poltica de seguridad. etc.
Ingenieros del Gestionar los recursos, Planificacin y gestin de
Web de nivel 3 humanos y tcnicos del proyectos, anlisis de
(gestores de proyecto para conseguir que riesgos, gestin de calidad,
proyectos) las metas se obtengan en el etc.
menor tiempo posible.
El hecho de que el equipo de desarrollo sea pluridisciplinar no slo tiene

implicaciones durante los procesos de planificacin y gestin del proyecto
multimedia, sino tambin en el modelo de proceso y el mtodo de desarrollo
elegidos, puesto que stos debern contar con actividades y productos capa-
ces de fomentar la necesaria cooperacin y sinergia entre personas de carac-
tersticas, conocimientos y habilidades de diversa ndole.
4.2.3. Requisitos de modelado

A la hora de desarrollar un producto multimedia es necesario elegir un
mtodo cuyas etapas y productos hagan posible analizar y disear cada una de
las caractersticas 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 estticos, tema que se abordar
de manera detallada en el siguiente captulo. El mtodo de desarrollo debe
ofrecer productos que permitan modelar todas las caractersticas de las apli-
caciones multimedia, ya estn stas relacionadas con la forma en que debe

presentarse la informacin, con la estructura lgica de la aplicacin, con las
posibilidades de interaccin 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 navegacin 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-

cin de una serie de actividades, independientemente de la secuencia que se
siga en las mismas (seccin 4.4), entre las que se cuentan el estudio de la fac-
tibilidad, el anlisis, el diseo, la produccin, la evaluacin y el manteni-
miento. En las siguientes subsecciones se comentan brevemente dichas fases
como introduccin a los modelos de proceso presentados en la seccin 4.4.
Se proporcionar ms informacin sobre cada fase, las actividades a realizar
o los mtodos aplicables en los captulos 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 tcnico como prctico. En el caso de
un sistema interactivo, es importante analizar la aceptacin que ste podra
tener antes de embarcarse en un complejo y costoso desarrollo. Aspectos
como la adecuacin social del sistema o su utilidad prctica pueden tenerse
en cuenta a este efecto (Nielsen, 1993).
Durante el estudio de factibilidad se deben considerar todos aquellos fac-

tores que podran afectar al desarrollo y al xito del producto final, entre los
que se cuentan las limitaciones econmicas, tcnicas, 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 aplicacin se quiere realizar,
cul es su potencial utilidad,
qu tipo de usuarios la van a emplear y cmo,
cundo estar disponible,
qu limitaciones tendr asociadas (v.g. restricciones legales) o
cul es su relacin con otros productos.

4.3.2. Anlisis
El anlisis es una actividad orientada a estudiar las caractersticas 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 bsicas de la etapa de anli-
sis es, precisamente, el anlisis 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.
Adems, es preciso conocer las caractersticas de los usuarios que pue-
den afectar al diseo. Por ejemplo, hay que tener en cuenta las capacidades o
discapacidades fsicas o cognitivas, la diversidad cultural, la edad, el sexo o
cualquier otro parmetro que pueda influir en la forma de presentar la infor-
macin o en la manera en que se va a producir la interaccin.
Tambin habr que analizar el entorno de operacin, en el cual se va a
hacer uso del producto a desarrollar. As habr que establecer si existen limi-
taciones o estndares a cumplir, si se va a dar soporte al uso de diferentes pla-
taformas de acceso o incluso las caractersticas fsicas del entorno. Por ejem-
plo, si se va a instalar un punto urbano de informacin, ser necesario tener
en cuenta caractersticas ambientales, como la luminosidad o el ruido, a la
hora de disear la interfaz de usuario.
El objetivo ltimo de esta fase es entender qu debe hacer el producto y
generar una especificacin o pliego de requisitos en la que se recojan todas
las caractersticas funcionales, no funcionales y de usabilidad de la aplica-
cin. Como se ver en el captulo 5 existen diversos mtodos para llevar a
cabo este estudio, entre las que se encuentran la realizacin de entrevistas, el
uso de prototipos, casos de uso y escenarios o el anlisis jerrquico de tareas
(Preece y otros, 2002).
DEFINICIN: Especificacin de requisitos.

Documentacin sobre las caractersticas de un producto que recoge qu debera
hacer sin entrar en cmo se va a desarrollar.
En general suele organizarse los requisitos de un sistema interactivo en

tres categoras:
Los requisitos de usabilidad determinan qu se va a entender por un
nivel aceptable de utilizacin y de aceptacin 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, adecuacin a estndares, 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 informacin sobre
los contenidos del curso de forma eficiente.
No funcional El curso ser accedido masivamente de forma remota y utilizando
una conexin va mdem.
4.3.3. Diseo
El proceso de diseo consiste en convertir una especificacin de lo qu el
producto debe hacer en una propuesta, ms o menos formal, de cmo debe
hacerlo. Durante el diseo se va a especificar, en consecuencia, aspectos tales
como:
cmo se va a estructurar la informacin,
cmo se va a presentar la informacin al usuario,
cmo funciona la aplicacin,
cmo va a poder interactuar el usuario con el producto en cada
momento, o
cmo 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 diseo que permita tra-
ducir las necesidades en productos ms o menos formales que puedan ser
discutidos por parte de los diversos miembros del equipo de desarrollo.
DEFINICIN: Modelo de diseo (Daz y otros, 1996).

Especificacin de las caractersticas y funciones de un producto software que per-
mite expresar la solucin a los requisitos de una forma abstracta y con una deter-
minada notacin.
Por ejemplo, la tabla 4.4 muestra cmo un requisito sobre los tipos de
usuarios que va a haber en un curso multimedia son interpretados utilizan-
do un diagrama propio de la metodologa para aplicaciones hipermedia

Ariadne (Daz y otros, 2001). En dicho diagrama se muestra grficamente
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 especificacin,
que podr ampliarse incluyendo caractersticas y capacidades de acceso
para cada tipo de usuario, permite representar de forma no ambigua y cla-
ra un requisito. Adems, se utiliza una notacin 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 especificacin informal durante el diseo

para un curso multimedia
Anlisis Diseo
Se va a dar acceso a Los usuarios se organizarn tal y como se muestra en el siguiente
distintos tipos de diagrama que utiliza notacin UML para representar relaciones
usuarios, incluyendo estructurales entre tipos de usuarios.
profesores, tutores,
alumnos, responsables
docentes,
desarrolladores de
contenidos y
administradores.
El diseo es un proceso tpicamente creativo y abstracto que se ve res-

tringido por limitaciones tcnicas, cognitivas y no tcnicas (Lowe y Hall,
1999) que deberan haberse recogido durante el anlisis y que deben tenerse
en cuenta durante el diseo de determinadas partes del producto:
Restricciones tcnicas. Si bien se suele decir que el diseo debe cen-
trarse slo en el cmo hacer las cosas, no se puede hacer un buen dise-
o si se ignoran ciertas restricciones de la plataforma tcnica, como
por ejemplo la forma en que se va a distribuir el producto o las carac-
tersticas tpicas de la plataforma de uso. As, si la mayor parte de los
usuarios acceden a un curso virtual haciendo uso de un mdem, no es
lgico plantear un diseo en el que se incluya la videoconferencia
como principal medio de comunicacin.
Restricciones cognitivas. Los usuarios tienen una caractersticas fsi-

cas (agudeza visual, capacidad auditiva, etc.) y cognitivas (memoria a
corto y largo plazo, capacidad de razonamiento y de resolucin 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 simultneamente, no se puede esperar que el usuario atien-
da a su contenido.
Restricciones no tcnicas. 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 informacin que viola la legalidad vigente (v.g. datos perso-
nales de otros usuarios).
El diseo 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 diseo pueden emplearse diferentes niveles de abstraccin y producir
diagramas o especificaciones conceptuales o incluso prototipos que ayuden a
establecer la solucin ms adecuada para cada problema. El captulo 5 pro-
fundizar en mtodos y tcnicas de diseo para productos multimedia.
4.3.4. Produccin
A la hora de producir o generar una aplicacin multimedia existen diver-

sas actividades a tener en cuenta, como se muestra en la figura 4.4.
En primer lugar es preciso establecer la organizacin de la aplicacin, es
decir identificar de qu conceptos se va a hablar o qu pantallas se van a
incluir. Una aplicacin multimedia est formada por una serie de nodos o
unidades indivisibles de presentacin en las que se incluyen varios conteni-
dos. As, cada ventana o cada marco puede considerarse un nodo. Durante la
etapa de definicin de la estructura se identificaran los nodos y la forma en
que stos se secuencian. Adems, se determinarn los contenidos que se van
a incluir en cada una de esos nodos, ya sean textos, grficos, dibujos, anima-
ciones, simulaciones, mundos virtuales, msica, 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 guin que describa
cmo debe ser el contenido y que haya que generar ste, pero tambin es
posible que se quieran utilizar contenidos que existen pero que no estn dis-
ponibles en formato no digital. As, es muy frecuente que se cuente con vde-
os o sonidos analgicos y con textos e imgenes en papel que se desean
incluir. En este caso el paso previo es la digitalizacin utilizando el hardware
y software adecuado. Una vez obtenido un archivo en formato digital se pasa-
r a retocar el contenido multimedia editndolo con herramientas software

al efecto. Este proceso, ya sea de creacin o de digitalizacin y edicin, no
slo requiere software y hardware especfico, sobre el que se puede consultar
en los temas especficos de este libro, sino tambin de la participacin de
especialistas en diseo multimedia capaces de editar y generar contenidos de
calidad.
FIGURA 4.4. Proceso de produccin de aplicaciones multimedia, ampliacin

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. Evaluacin
La evaluacin tiene como misin primordial asegurar que las aplicacio-

nes se han diseado teniendo en cuenta las necesidades de sus usuarios fina-
les, y no slo las de los desarrolladores. Este proceso va a proporcionar infor-
macin que permita comprobar si los mecanismos de interaccin se han
diseado correctamente, detectando aquellas deficiencias que haya que sol-
ventar o proponiendo mejoras.
Es muy importante tener presente que en ningn caso la evaluacin es
una parte de la etapa de pruebas y depuracin, ya que los errores que se bus-
can con la evaluacin estn relacionados con la forma de interactuar con el
producto desarrollado y tienen su origen en una mala comprensin o inter-
pretacin de la forma en que el usuario se comunica con el sistema, y no con
posibles fallos o errores en el cdigo.
La evaluacin es una fase tan importante en el desarrollo de sistemas
interactivos que en este libro se le dedica todo un captulo, 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 caracterstica o para adap-
tarlo a cambios en el entorno (IEEE, 1990).
Se estima que en sistemas de informacin 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 aplicacin multimedia se concibe como un CD
que una vez generado no va a evolucionar. Pero salvo en esos casos especfi-
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 caractersti-
cas de la plataforma de acceso, estn en permanente evolucin, 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 debera ser preciso llevar a cabo un mantenimiento
correctivo pues todos los fallos de software o de interaccin deberan
haberse detectado en las fases de produccin y evaluacin, 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 seran 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 podra dedicar a optimizar cdigo o a hacer ms flexible y
modular el sistema para hacer ms eficiente su modificacin. Este tipo
de mantenimiento es tambin bastante habitual en las aplicaciones
multimedia.
4.4. MODELOS DE PROCESO PARA EL DESARROLLO

MULTIMEDIA
Algunos de los paradigmas clsicos 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 versin rpi-
da y flexible del producto, susceptible de ser modificada ante una varia-
cin en los requisitos.
El modelo en espiral, en el que se hace un desarrollo iterativo basado
en el anlisis de riesgos.
El modelo basado en transformaciones, que hace uso de herramien-
tas CASE (Computer Aided Software Engineering) capaces de transfor-
mar automticamente la salida de cada fase en entrada de la siguiente.
El modelo basado en el uso de prototipos que ofrece una aproxima-
cin iterativa en la que se emplean prototipos para involucrar al usuario.
El uso de prototipos y su evaluacin por parte del usuario o de evaluado-

res expertos es bsico en los sistemas interactivos, como los sistemas multi-
media. Por ello, de los modelos de proceso descritos anteriormente el nico
que sera aplicable es el diseo iterativo. Adems, existe otro modelo de pro-
ceso ms 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 aplicacin al
desarrollo de sistemas multimedia.
4.4.1. Diseo iterativo o modelo de proceso basado en el uso

de prototipos
El diseo iterativo es una aproximacin 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 diseo iterativo conlleva el compromiso de desarro-
llar algo rpido, el prototipo, que permita probar si las decisiones de diseo
son o no apropiadas (Preece y otros, 2002). Con este compromiso, el diseo ite-
rativo supone realizar cortos ciclos de anlisis y diseo para producir un pro-
totipo que pueda ser evaluado de forma que se obtengan datos fiables sobre
su utilidad. Los resultados de la evaluacin 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 comprensin de los requisitos
del producto (reinicio en la etapa de anlisis), a un mal diseo de un requisi-
to (reinicio en la etapa de diseo) o a un aspecto de implementacin (reinicio
en la etapa de implementacin de prototipos).
FIGURA 4.5. Modelo de proceso basado en prototipos.

A la hora de desarrollar los prototipos hay tres enfoques bsicos (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 electrnico) 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 caractersticas de la aplicacin, se establecer el
entorno tcnico de desarrollo y se iniciar la verdadera implementa-
cin en la que poco, o nada, del cdigo generado para los prototipos
se podr reutilizar.
Desarrollo incremental: el producto final se construye como una
serie de mdulos o componentes, de forma que en cada ciclo de la ite-
racin se incluye un nuevo mdulo al producto anterior. Por ejemplo,
cuando una empresa se plantea generar su sitio Web y est bajo la pre-
sin de salir a la palestra cuanto antes, este tipo de modelo de proceso
le permite publicar un producto an no completo (por ejemplo, slo
pginas informativas) e ir aadiendo nuevos mdulos segn estos se
vayan produciendo (por ejemplo, venta on-line, personalizacin,
comunicacin con proveedores, etc.).
Desarrollo evolutivo: el prototipo va evolucionando en cada iteracin
hasta conseguir el producto final. Esta sera la situacin idnea 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 evaluacin 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
(anlisis, diseo, implementacin o desarrollo de prototipos) o en la que se
pueda, de acuerdo con las caractersticas del equipo de desarrollo, las habi-
lidades y conocimientos de sus integrantes, la disponibilidad de los usua-
rios para participar en evaluaciones empricas 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 especificacin formal, con
el fin de confirmar si realmente se estn teniendo en cuenta las necesidades
y caractersticas de los usuarios. En el captulo 7 se presentan diversas tc-
nicas de evaluacin que pueden aplicarse en las distintas fases del ciclo de
vida.
4.4.3. Seleccin 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 diseo iterativo, ciclo de vida
en estrella o cualquier otro que se considere adecuado.
Existen mltiples factores que influyen de manera decisiva en esta deci-
sin, 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 rcord, por lo que el ciclo de vida debe permitir cre-
ar un producto o un prototipo en un tiempo mnimo (Lowe y Hall,
1999).
Tamao de la aplicacin: no es lo mismo desarrollar una pequea
aplicacin, por ejemplo un CD sobre la Antigua Roma que se va a
entregar con una revista, que una aplicacin de gran envergadura,
como por ejemplo el sitio Web de un banco electrnico. Cada tipo de
aplicacin requiere de un tipo de ciclo de vida. As, mientras que para
productos pequeos un enfoque muy formal puede ser engorroso e
intil, para productos a gran escala es imprescindible aplicar un pro-

ceso completamente sistematizado (Lowe y Hall, 1999).
Caractersticas 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 tc-
nico ser mejor aplicar un modelo iterativo en el que la participacin
de otro tipo de personas (diseadores grficos o usuarios) pueda post-
ponerse hasta que se pueda contar con ellos.
En lneas 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 captulo ha abordado algunas cuestiones genricas sobre el desarro-
llo de productos multimedia, enfocando ste como un proceso sistemtico en
el que es preciso aplicar mtodos propios de la ingeniera del software.
Se han puesto de manifiesto algunas caractersticas y requisitos propios
de los productos multimedia que hacen precisa la adopcin de modelos de
proceso y mtodos 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 caractersticas de presentacin, navegacin, estruc-
turales, de comportamiento, de seguridad o de interaccin.
Se han presentado brevemente las fases del desarrollo, que incluiran el
estudio de la factibilidad, el anlisis, el diseo, la produccin, la evaluacin y
el mantimiento, viendo brevemente en qu consiste cada una de ellas. Y, fina-
lemente, se han estudiado posibles modelos de proceso que establezcan cmo
secuenciar estas fases y se han presentado algunos factores que influyen en la
seleccin del modelo de proceso, como son la disponibilidad de usuarios y de
recursos o las caractersticas del equipo de desarrollo.
4.6. EJERCICIOS DE AUTEVALUACIN
4.1. El desarrollo de productos multimedia:

a) No difiere en nada del de otro producto informtico.
b) Requiere involucrar al usuario para verificar la validez de los meca-
nismos de interaccin.
c) Consta de menos fases que el desarrollo de cualquier otro producto

informtico.
d) No puede llevarse a cabo utilizando mtodos propios de la ingeniera
del software.
4.2. El diseo centrado en el usuario:
a) No permite aplicar un mtodo sistemtico.

b) Slo se aplica a productos multimedia.
c) Plantea la necesidad de obtener medidas empricas sobre la validez
de las decisiones del diseo.
d) Es una alternativa frente al diseo iterativo.
4.3. Durante la etapa de anlisis 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 slo estn 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 tcnicos ms

profundos que el proveedor de contenidos.
b) El encargado del mantenimiento hace las mismas labores que el pro-
veedor de contenidos.
c) Ningn miembro podra asumir varias funciones en un mismo desarrollo.
d) El ingeniero del Web de nivel 3 se encarga de realizar el anlisis y el
diseo de la aplicacin.
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 ms flexible que el basado en
prototipos, pero, en contrapartida, es menos sistemtico.
c) La evaluacin incluye las fases tradicionales de pruebas del software
y verificacin de requisitos.
d) Nunca se lleva a cabo la fase de mantenimiento.

AMESCUA y otros (1995): A. Amescua, L. Garca, P. Martnez y P. Daz. Ingeniera del Soft-
ware de Gestin: Anlisis y diseo 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.
DAZ y otros (1996): P. Daz, N. Catenazzi e I. Aedo. De la multimedia a la hipermedia.
Ed. Rama, Madrid, 1996.
DAZ y otros (2001): P. Daz, 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.

Captulo 5
ANLISIS Y DISEO DE SISTEMAS
MULTIMEDIA
ESQUEMA
5.1. La etapa de anlisis de requisitos en el desarrollo multimedia.

5.2. La especificacin de requisitos en el desarrollo multimedia.
5.3. La etapa de diseo en el desarrollo multimedia.
5.4. Resumen.
5.5. Ejercicios de autevaluacin.
Diferentes estudios demuestran que el fracaso en los proyectos software
se debe, en muchas ocasiones, a un mal anlisis 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 ms producti-
va. Entender para qu debe servir un producto y a quin 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 Anlisis de Requisitos. En los pro-
ductos multimedia, esencialmente concebidos como sistemas interactivos,
esta necesidad es an ms acuciante si cabe. Es imprescindible que antes
de comenzar a implementar el producto se tengan claras sus principales
caractersticas, a quin va destinado, qu tipo de actividades se van a llevar
a cabo con l, de qu manera se va a utilizar y dnde, de tal forma que se
pueda organizar el subsiguiente desarrollo de la forma ms eficiente y pro-
ductiva. Sin embargo, tambin hay que tener en cuenta que el anlisis de
requisitos va a ser un proceso iterativo y evolutivo, en la medida en que
segn se vaya avanzando en el proceso de desarrollo se van a ir identifican-
do nuevas necesidades o se van a conocer ms detalladamente las que ya se
haban identificado.
Asimismo la etapa de diseo juega un papel fundamental en el ciclo de

desarrollo de sistemas interactivos ya que permite abordar la resolucin de
los requisitos aplicando un nivel de abstraccin que hace posible llegar a
una solucin conceptual de los mismos. Durante el diseo se debe dar
lugar a una completa especificacin del sistema en la que se tenga en cuen-
ta su estructura, la informacin que contiene, el modo en que se presenta
sta al usuario final, la forma de interaccin con el sistema, los mecanis-
mos de acceso a la informacin o las reglas que se encargan de preservar
la seguridad.
El objetivo de este captulo es profundizar en el anlisis de requisitos

para sistemas multimedia as como en la etapa de diseo. Con este fin, se
inicia el captulo introduciendo en la seccin 5.1 el objetivo del anlisis, para
pasar a continuacin en la seccin 5.2 a profundizar en los tipos de requisi-
tos que se pueden encontrar en un sistema multimedia, las tcnicas que pue-
den emplearse para recolectar informacin 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 captulo se cierra con la sec-
cin 5.3 en las que se estudian las necesidades de modelado que presentan
los productos multimedia, enfocndolas en seis perspectivas: presentacin,
estructura, comportamiento, seguridad, funciones y navegacin.
5.1. LA ETAPA DE ANLISIS DE REQUISITOS

EN EL DESARROLLO MULTIMEDIA
Tal y como se haba comentado en el captulo 4, el anlisis es una fase del

proceso de desarrollo de un producto software que tiene como objetivo estu-
diar y documentar las caractersticas o requisitos que dicho producto debe
tener, dando lugar a una Especificacin de Requisitos. En un sistema mul-
timedia, como sistema interactivo, habr que estudiar las caractersticas de
sus usuarios, de las tareas que se espera realizar con el sistema a desarrollar
y del propio entorno de operacin. Antes de pasar a estudiar en ms detalle
cmo realizar el anlisis es preciso ampliar el concepto que se tiene de usua-
rio, ya que no slo 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 trmino
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 slo habra que analizar las caractersticas de sus
potenciales usuarios (ya sean acadmicos, administrativos o estudiantes) y
del cliente que contrata el desarrollo, sino que tambin habra 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.
DEFINICIN: El objetivo del anlisis de requisitos en un sistema interactivo es (Preece y

otros, 2002):
Estudiar a los usuarios, las tareas que stos realizan y el entorno de operacin
para identificar necesidades.
Producir un conjunto de requisitos estables que sirvan de gua durante el proceso
de diseo.
Al tratar de abordar la especificacin de requisitos en los desarrollos

multimedia, hay que tener en cuenta que esta especificacin se va a hacer de
ANLISIS Y DISEO 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 caractersticas que el producto
deber tener. Esto no significa que la fase de anlisis deba evitarse, sino sim-
plemente que debe contemplarse de una forma ms flexible (Preece y otros,
2002), una flexibilidad que ya debera 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 diseo conceptual o incluso durante la
implementacin y evaluacin 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 ESPECIFICACIN DE REQUISITOS

EN EL DESARROLLO MULTIMEDIA
Un requisito es una propiedad o caracterstica que un sistema debe

cumplir para que sus destinatarios lo consideren vlido. Para conseguir esa
aceptacin por parte de los usuarios es preciso que el producto final sea til
y utilizable, unas caractersticas que no suelen ser fcilmente definibles. El
anlisis de requisitos en un sistema multimedia es una actividad esencial
que trata de extraer del entorno y del usuario todas aquellas caractersticas
relevantes para el diseo y la produccin, unas caractersticas que varan en
su naturaleza con respecto a otros tipos de aplicaciones software. De hecho,
la disciplina denominada ingeniera de los requisitos hace hincapi en la
importancia de llevar a cabo una buena recogida de requisitos, entendida
sta como un proceso de ingeniera iterativo y evolutivo (Preece y otros,
2002).
En este apartado se describirn los tipos de requisitos que se pueden
identificar en sistemas multimedia, algunas tcnicas para recoger datos
sobre las necesidades de sus destinatarios y en formatos para producir una
especificacin 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 concrecin 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 concrecin de los mismos.
TABLA 5.1. Ejemplos de requisitos de distinto nivel de abstraccin

Concreto Vago
Proceso R1. El producto se entregar en un R2. Se utilizar un mtodo que in-
plazo de doce meses a la firma de volucre al usuario.
esta especificacin.
Producto R3. El producto se distribuir como un R4. El producto tendr una esttica
nico CD autocontenido, que incluir adecuada para nios.
toda la informacin y los programas
necesarios para su utilizacin.
Cuanto ms concreto sea un requisito ms sencillo ser verificar su cumpli-

miento, por lo que el anlisis de requisitos debera 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
ms en detalle para tratar de formularlo de una manera ms precisa. As, en el
requisito R2 de la tabla 1 habr que indicar qu grado de participacin 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 esttica adecuada para nios (v.g, la que un grupo de nios en
representacin de los usuarios finales considere adecuada, la que siga algn tipo
de recomendacin al uso, la que aprueben expertos en interfaz de usuario, etc.).
Adems, los requisitos pueden clasificarse de acuerdo con su objetivo.
As, en ingeniera del software se ha trabajado tradicionalmente con dos tipos
de requisitos: los funcionales y los no funcionales (IEEE, 1990).
DEFINICIN: Un requisito funcional:

establece las funciones que el sistema o producto debe permitir realizar.
Los requisitos funcionales estarn relacionados pues con las tareas que el
usuario puede llevar a cabo con la aplicacin, incluyendo aquellas relacionadas
con: el acceso a la informacin (por ejemplo uso de buscadores, ndices o mapas,
mecanismos histricos, controles de reproduccin de contenidos con una dura-
cin implcita, etc.); la modificacin de la informacin o de la estructura (por
ejemplo, capacidades de anotacin, personalizacin, uso de marcadores, inclu-
sin de nuevos contenidos, etc.); o la capacidad de comunicarse o colaborar con
otros usuarios (por ejemplo, mecanismos de comunicacin sincrnica o asincr-
nica, notificacin de eventos, creacin de grupos de inters, etc.).
DEFINICIN: Un requisito no funcional:

impone una serie de restricciones a los requisitos funcionales relacionadas con la
eficiencia, consistencia, reusabilidad, flexibilidad, mantenimiento, adecuacin a
estndares, reglas de seguridad, aspectos legales o corporativos, etc.
Los requisitos no funcionales no son funciones sino caractersticas que

deben verificarse en el funcionamiento o en la estructura de la aplicacin. Sin
embargo esta distincin no es siempre evidente y, adems, los requisitos no
funcionales pueden afectar a los funcionales y viceversa. As por ejemplo,
limitar el tamao de la ventana de visualizacin es un requisito funcional o
no funcional?
Por ello, a estos dos tipos de requisitos se aaden otras cuatro categoras
que permiten recoger aspectos importantes de cualquier sistema interactivo
y clasificar las propiedades de una forma ms apropiada: los requisitos de
usuario, del entorno, de usabilidad y de datos (Preece y otros, 2002).
DEFINICIN: Un requisito de usuario:

hace relacin a caractersticas relevantes del grupo de usuarios a los que va desti-
nada la aplicacin.
Existen muchas caractersticas de los usuarios que pueden tenerse en

cuenta a la hora de disear el producto, ya sea sobre aspectos personales (por
ejemplo, edad, sexo, capacidades fsicas y mentales), cognitivos (conocimien-
tos previos, formacin, habilidades) o sociales (por ejemplo, rasgos cultura-
les, funcin social, etc.). A la hora de estudiar al usuario se puede recurrir a
estudios psico-sociolgicos y antropomtricos, si bien hay que tener en cuen-
ta que slo hay que registrar aquella informacin que sea realmente relevan-
te y tenga algn tipo de influencia en el desarrollo del producto multimedia
(Elsom-Cook, 2001). Adems, se puede estudiar al usuario como:
un nico grupo, del que se extraern aquellos aspectos comunes que
puedan influir en la utilidad del sistema,
una serie de grupos distintos con necesidades de interaccin diferentes, o
como un individuo con caractersticas propias que deben ser tenidas
en cuenta.
En el primer caso, los requisitos se emplean para mejorar un diseo que
es nico, mientras que en los otros dos los diseos deben adaptarse, de forma
automtica o no, a las caractersticas de los usuarios.
En el segundo caso pueden considerarse distintos tipos de usuarios en
funcin de diversos parmetros (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 slo se conozca mejor como stos se rela-
cionan como entidades sociales sino que tambin pueda emplearse este cono-
cimiento para proporcionar un acceso personalizado a la informacin.
El tercer caso presenta sistemas adaptativos en los que es imprescindible

mantener un modelo de usuario que recoja sus caractersticas y comporta-
miento mediante alguna tcnica de representacin del conocimiento as
como algn tipo de mecanismo de inferencia que pueda deducir qu hacer en
funcin de esas caractersticas.
DEFINICIN: 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 tcnico, fsico, organizativo y social. As,
en el entorno tcnico habr que tener en cuenta si se va a emplear un deter-
minado hardware o software que pueda afectar al desarrollo. Tambin puede
resultar interesante analizar in situ el entorno fsico en que se va a utilizar
para detectar si existen parmetros (por ejemplo, nivel de ruidos o ilumina-
cin) que puedan a afectar a la utilidad del diseo. 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 interaccin social.
DEFINICIN: Un requisito de usabilidad:

analiza la capacidad de ser usado de un producto.
La usabilidad, de la que se hablar ms detalladamente en el captulo 7

dedicado al proceso de evaluacin, suele medirse en trminos de efectividad,
eficiencia, seguridad, utilidad y facilidad de aprendizaje. Desde la ingeniera
de la usabilidad se insiste en que la usabilidad es una caracterstica ms del
producto software y que puede medirse siguiendo mtodos rigurosos, de
manera que la especificacin de requisitos relacionados con esta propiedad
debe hacerse cuidadosamente. As, ser preciso que las metas de usabilidad
se expresen acompaadas de una serie de mtricas (Good y otros, 1986) que
permitan valorar la aceptacin 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 nmero de errores cometidos por los usua-
rios; el tiempo empleado para resolver los errores; la frecuencia de uso de la
ayuda y de la documentacin; el tiempo empleado en la ayuda y en la docu-
mentacin; el porcentaje de comentarios favorables y desfavorables; el nme-
ro de comandos errneos o de repeticiones; y el nmero 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 electrnico: la inclusin de una pgina que ya est
creada dentro de un curso electrnico. Para ello los usuarios debern locali-
zar dnde ubicar la pgina y aadirla. Como caractersticas generales del
atributo se tienen (Faulkner, 1998): la mtrica que se va a emplear, los tipos
de usuarios involucrados y las precondiciones que deben satisfacerse. Ade-
ms, tal y como propone en (Whiteside y otros, 1998) se aaden 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 mnimo 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 evaluacin del
sistema).
DEFINICIN: Un requisito de datos:

es aquel que recoge caractersticas 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
tamao, la persistencia, la precisin o el valor (Preece y otros, 2002). A este
respecto, sera interesante incluir la integridad de los datos como un pun-
to bsico a tener en cuenta, particularmente importante en el caso de que
se lleve a cabo una gestin descentralizada de los mismos (Ammann y Jajo-
dia, 2000), en la que hay que tener en cuenta los mltiples factores que
pueden hacer que los datos no sean consistentes, fiables, actuales, vlidos
o accesibles.
TABLA 5.2. Ejemplo de requisito de usabilidad

Atributo Eficiencia de Aadir una pgina a un curso concreto
Mtrica Tiempo requerido para completar la tarea.
Usuarios Profesores.
Precondiciones Haber utilizado el curso durante al menos 3 sesiones.
Haber creado la pgina.
Criterios de Peor caso No poder incluir la pgina

funcionamiento Mnimo nivel aceptable 3 minutos
Nivel esperado 1 minuto
Mejor caso 0,5 segundos
Nivel actual --------------------
5.2.2. Tcnicas de recoleccin de datos

Como se ha podido ver en la subseccin anterior, los requisitos de un sis-
tema multimedia son de naturaleza muy variada, tanto por el tipo de infor-
macin 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 tcnicas que permitan extraer informacin tanto del usuario
como del entorno.
La recoleccin 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 tcnicas para recoger informacin, entre las que se cuentan
los cuestionarios, entrevistas, grupos de trabajo o talleres, observacin, estu-
dio de documentacin o software de registro (Preece y otros, 2002). Estas tc-
nicas son similares a las que se utilizan durante el proceso de evaluacin (cap-
tulo 7) pues de hecho tanto el anlisis de requisitos como la evaluacin
comparten un objetivo comn: la recoleccin de datos. La principal diferencia
radica en que mientras durante el anlisis los datos a recopilar hacen referen-
cia a las caractersticas que un producto debera tener, en la evaluacin 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 tcnicas, algunas
de las cules se abordan con ms detalle en el captulo 7. Una caracterstica
bsica de estas tcnicas es que son complementarias y que, habitualmente, se
suelen utilizar varias para recolectar informacin sobre el mismo requisito.
Cuestionarios. Los cuestionarios son una forma eficaz y barata de
recopilar informacin cualitativa y cuantitativa sobre cuestiones que
tienen una respuesta muy especfica (Preece y otros, 2002). El mayor
problema es disearlos de manera que se pueda recoger informacin
relevante, puesto que las respuestas a las preguntas pueden disearse
de distintas formas y conseguir motivar a los participantes para que
rellenen la encuesta.
Entrevistas. Las entrevistas ofrecen ms 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 ms datos cualitativos que cuantitativos, si bien se requiere
un entrevistador con capacidad para incitar a los participantes a invo-
lucrarse en el anlisis e incluso para suscitar temas de discusin. Ade-
ms, 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 discusin 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, adems, se da lugar a una relacin ms estrecha y directa entre
destinatarios del producto y desarrolladores.
Observacin. El objetivo de esta tcnica es tener informacin 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-
grficos se enmarcan dentro de estas tcnicas de observacin emplea-
das en las etapas iniciales del proceso de desarrollo. En estos estudios
el etngrafo 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 etngrafo dedica una temporada a convivir en el
mismo ambiente que el usuario y no slo observa a estos sino tambin
las interfaces y productos software que stos utilizan en su rutina, con el
fin de detectar requisitos o entenderlos mejor (Shneiderman, 1998).
Estudio de documentacin. En esta tcnica se estudia documenta-
cin o estndares que puedan informar sobre las actividades de las
tareas a realizar, puesto que en muchas ocasiones algunos procedi-
mientos ya estn sujetos a algn tipo de regulacin que es preciso tener
en cuenta (Preece y otros, 2002).
Estudio de la literatura. Otra valiosa fuente de informacin, especial-
mente adecuada si el equipo de desarrollo no tiene mucha experiencia
en el dominio de aplicacin del producto, es buscar en la literatura
ejemplos de productos similares (Lowe y Hall, 1999).
Prototipos. Los prototipos son una tcnica 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 ms 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 tcnica 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 predisposicin
1
Recurdese que el modelo de proceso para un sistema multimedia tiene que ser cclico,
por lo que el anlisis no slo se realiza al principio del desarrollo (captulo 7).
para participar en el anlisis, 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 tcnicas de recogida de datos en el proceso de anlisis

Tcnica Objetivo bsico Ejemplo
Cuestionario Responder a preguntas muy con- Qu navegador para web utili-
cretas. zan los usuarios con ms fre-
cuencia?
Entrevista Explorar aspectos. Qu contenidos debera tener
el curso?
Grupos de trabajo Confrontar perspectivas distintas. Cmo hay que estructurar la
informacin?
Observacin Conocer el entorno. Cmo son las sesiones de los
alumnos de un curso virtual?
Estudio de Conocer estndares o normativas. Cmo es el proceso de matricu-
documentacin lacin en el centro de enseanza?
Estudio de la Aprender de desarrollos similares. Qu estilos de aprendizaje se es-
literatura tn ofreciendo en cursos similares?
Prototipos Confirmar aspectos. Tienen los usuarios problemas al
responder a los tests de nivel?
5.2.3. La especificacin de requisitos

Los requisitos deben plasmarse de manera ms o menos detallada en un
documento, de tal manera que este documento pueda convertirse en una til
gua durante todo el proceso de desarrollo, ya sea para disear, para construir
o para evaluar. Una buena Especificacin o Pliego de Requisitos tiene las
siguientes ventajas (IEEE, 1998):
se establece una base slida 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 nmero de iteraciones en los procesos de diseo y de pro-
duccin;
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 travs de conti-
nuas evaluaciones.
Para ello es preciso elaborar un documento que sea correcto, completo,

no ambiguo, consistente, verificable, modificable, con referencias cruzadas
fcilmente seguibles y en el que los requisitos se ordenen por importancia o
por su nivel de estabilidad. En el campo de la ingeniera del software se ha
venido utilizando como formato para la documentacin de los requisitos el
estndar de ANSI/IEEE sobre especificacin de requisitos software (IEEE,
1998) cuyo formato se refleja en la figura 5.1.
FIGURA 5.1. Formato de una Especificacin de Requisitos, segn 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 DISEO EN EL DESARROLLO

MULTIMEDIA
El diseo tiene como objetivo primordial pasar de la especificacin de

requisitos, en la que se indica para qu debe servir un producto y a quin, a
una propuesta de solucin que indica cmo va a ser dicho producto. Esa solu-
cin abordar, entre otras, cuestiones tales como:
FIGURA 5.2. Especificacin de un requisito con el formato Volere (Preece y otros, 2002).
la manera en la que se va a estructurar la informacin (por ejemplo,

secuencialmente, en un grafo, jerrquicamente, etc.);
la forma en la que se va a presentar la informacin al usuario (por
ejemplo, tipos de contenidos multimedia que se van a utilizar, ritmo de
presentacin, sincronizaciones, estilos de interaccin, etc.);
el funcionamiento de aplicacin (por ejemplo, cmo se van a poder
realizar las distintas tareas, etc.);
cmo va a poder interactuar el usuario con el producto en cada
momento (por ejemplo qu eventos de usuario se van a gestionar y
cmo, qu resultados producen los eventos, etc.), o,
la aplicacin de ciertas reglas de accesibilidad y de seguridad (por
ejemplo, qu mecanismos se van a incluir para hacer que la informa-
cin sea accesible a todos los usuarios, quin va a poder modificar la
informacin o la estructura, quin va a poder hacer anotaciones perso-
nales, etc.).
Con este fin es preciso hacer uso de un modelo de diseo que permita tra-
ducir las necesidades en productos ms 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 diseo
que se muestran en la figura 5.3 (Daz y otros, 2001b).
FIGURA 5.3. Perspectivas de modelado para productos multimedia.
5.3.1. Modelado de la Presentacin

La forma en que se presenta la informacin es sin duda un aspecto bsi-
co en un producto multimedia, y no slo por razones estticas, puesto que la
manera y el ritmo de presentacin 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 composicin multimedia
en la que los objetos van apareciendo y desapareciendo del espacio de repre-
sentacin, es preciso establecer una coreografa de los contenidos armnica
y eficiente, de manera que se consiga no slo una presentacin estticamen-
te adecuada sino tambin cogni-tivamente eficiente.
Los contenidos van a poder ubicarse en diferentes dimensiones o espa-
cios finitos de coordenadas, que sern como mnimo dos: el de la ventana
bidimensional (o tridimensional) y el del tiempo. Adems, estos contenidos
pueden colocarse en un punto concreto de ese espacio (por ejemplo, el vdeo
demostracin se inicia en el segundo 5), o bien hacer que su presentacin
dependa de la presentacin de otro y otros elementos (por ejemplo, en cuan-

to acaba el vdeo demostracin se muestra un botn para continuar). Con
este fin, es preciso que el mtodo elegido permita establecer relaciones o res-
tricciones espacio-temporales entre contenidos.
DEFINICIN: Relacin espacio-temporal.

Es aquella que refleja ciertas caractersticas que tienen las posiciones de dos o ms
contenidos en un determinado espacio de representacin.
Una relacin espacial puede representarse por medio de la topologa, la dis-

tancia y la direccin a que se encuentran los objetos involucrados como se
muestra en la tabla 5.4 utilizando la notacin propuesta en (Daz y otros, 2001a).
TABLA 5.4. Ejemplo de notacin para relaciones espaciales

Parmetro Significado Valores
Topologa Relacin 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)
Direccin Orientacin 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 relacin temporal puede indicarse por medio de un desplazamiento

entre el momento de inicio de la presentacin y el de finalizacin entre dos
contenidos. Por ejemplo, si un vdeo que dura 3 segundos se inicia un segun-
do despus de abrir un nodo, la relacin temporal entre este contenido y el
resto de los que se incluyan desde el principio se indicar de la forma (3, -).
DEFINICIN: Restriccin espacio-temporal.

Una restriccin espacio-temporal es una especificacin dada por el diseador que
obliga a que se verifiquen ciertas caractersticas que tienen las posiciones de dos
o ms contenidos en un determinado espacio de representacin.
Para poder modelarlas es preciso que el mtodo 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 alineacin por el borde superior entre
dos contenidos utilizando la notacin 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 restriccin.
A modo de resumen, la tabla 5.5 muestra algunos ejemplos de relaciones

y restricciones que podran incluirse en sistemas multimedia.
TABLA 5.5. Ejemplos de relaciones y restricciones espacio-temporales

Relacin espacial En el escritorio, cuando un fichero es soltado dentro de la pape-
lera, el icono del fichero desaparece.
Restriccin espacial Todos los campos del formulario tienen que estar justificados a la
izquierda.
Relacin temporal Si un vdeo 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 slo se presenta el vdeo.
Restriccin temporal El vdeo y su correspondiente subttulo 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 visualizacin a travs de una
plataforma Web (captulo 14, Lenguajes de marcado y de presentacin).
Otro aspecto relevante de cara a la presentacin es la posibilidad de sepa-
rar las caractersticas de presentacin del contenido en s, de manera que se
potencie la reutilizacin y la accesibilidad. Cada contenido puede ir acompa-
ado de unas especificaciones de presentacin (por ejemplo tamao de letra,
color, tipografa o incluso estilo retrico para un texto). En esa especificacin
se puede considerar la posibilidad de recoger: la proyeccin y modificacin
de objetos tal y como se definen en HyTime (DeRose y Durand, 1994):
Proyeccin de eventos: se trata de poder transformar la posicin y la
extensin de un evento desde un espacio de coordenadas a otro. A cada
evento se le pueden aplicar una o ms proyecciones (projectr) que

determinarn su posicin y extensin en el nuevo espacio de coor-
denadas. Cada proyeccin se realiza dentro de un alcance (proscope)
que determina un rango dentro del espacio de coordenadas origen
en el que aplicar la proyeccin. Los alcances de proyeccin 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 proyeccin de los eventos.
En la figura 5.5 se muestran dos proyeccin sobre el mismo objeto
(un vdeo): la primera es una transformacin de 1 a 3 que se aplica a
unos determinados frames, es decir, se ralentiza el vdeo durante
esos frames a un tercio de su velocidad; la segunda proyeccin es de
1 a 0, es decir, una serie de frames del vdeo no se van a mostrar.
FIGURA 5.5. Funcionamiento del mdulo de proyeccin de eventos en HyTime.
Modificacin de eventos: permite especificar modificadores de

objetos as como sus combinaciones. Cada modificador de objeto
(object modifier) tendr efecto nicamente en la extensin determi-
nada por el alcance de la modificacin (modscope) al que pertenece.
A su vez, los alcances estarn incluidos dentro de una lista de modi-
ficaciones (wand). Como ejemplo se muestra en la figura 5.6 una
doble modificacin sobre las imgenes un vdeo: en la primera de
ellas se superponen unas lneas oblicuas y en la segunda unas lneas
horizontales.
Adems, puede haber varias especificaciones para el mismo objeto, de
manera que se seleccione la ms adecuada para cada usuario o para el
FIGURA 5.6. Funcionamiento del mdulo de modificacin 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 informacin 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 informacin (Daz 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 pgina de un libro
electrnico, por ejemplo; mientras que sus contenidos sern los diversos
textos, imgenes, fotos, grficos, vdeos, animaciones, sonidos, etc., que se
presenten en los distintos nodos que conforman la aplicacin.
La separacin, lgica y fsica, de los contenedores (nodos) y de los con-
tenidos en s (cada tem multimedia que se incluye en el producto) es til no
slo porque son elementos conceptualmente distintos, sino porque, ade-
ms, facilita:
compartir informacin por referencia (como se hace en HTML con
imgenes 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).
Adems 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 pgina concreta es un nodo simple.
Un nodo compuesto es aquel que est compuesto por otros nodos con
los que materializando algn tipo de relacin (por ejemplo, generaliza-
cin/especia-lizacin, composicin o agregacin). Por ejemplo, en el
libro multimedia el captulo es una agregacin de pginas, y la novela
es una generalizacin 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
funcin de localizacin pero no se embeben en ellos, de forma que se
facilita el mantenimiento y la reutilizacin de contenidos (Daz y otros,
1996).
Un contenido compuesto es aquel que est compuesto por otros con-
tenidos con los que materializando algn tipo de relacin (por ejemplo,
genera-lizacin/especializacin, composicin o agregacin). Por ejem-
plo, una barra de botones es una agregacin de varios contenidos.
El hecho de que el mtodo empleado permita representar la estructura a
travs de estos objetos compuestos y de relaciones estructurales va a hacer
posible reflejar una situacin que se produce en la mayor parte de los pro-
ductos multimedia: la existencia de una estructura jerrquica 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 catlogo, la informacin de los usuarios y los documen-
tos que, a su vez, se especializan en tres tipos). Como puede verse, este dia-
grama slo incluye informacin estructural que refleja cmo se organiza la
informacin.
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 botn Parar se detiene la ejecucin del
vdeo) 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). Adems, dichos eventos pueden ser provocados por acciones realiza-
das por el usuario (por ejemplo, seleccionar un botn) o por el estado sis-
tema (por ejemplo, tres segundos despus de acceder al nodo principal se
salta al ndice). As pues, el mtodo de desarrollo debe tener en cuenta la
necesidad de especificar estas reacciones como parte esencial del modelado
de la aplicacin interactiva.
FIGURA 5.7. Diagrama estructural de una biblioteca electrnica basado en

la metodologa Ariadne (Daz 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
especificacin procedimental. Es habitual que muchos objetos que se inclu-
yen en el sistema no existan como tales en la base de informacin del mismo
y que no se pueda hacer referencia a ellos por medio de algn 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 algn tipo de procedimiento o de regla que los genere en
tiempo de ejecucin. En consecuencia, durante el desarrollo tambin debe
tenerse en cuenta este tipo de objetos, normalmente denominados virtuales.
Modelado de la seguridad. Cuando un producto multimedia va a ser
utilizado por mltiples 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 tendrn 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 especificacin
de una poltica de seguridad de alto nivel (Fernndez y otros, 1996) en la que
se describe quin puede hacer qu en qu contexto y no a los mecanismos

fsicos que se implementarn para proporcionar acceso seguro (por ejemplo,
firma digital, cifrado, etc.). Desde esa perspectiva ms conceptual que fsica,
la seguridad puede analizarse de acuerdo con tres propiedades:
Confidencialidad: est relacionada con la prevencin del acceso no

autorizado a la informacin. El objetivo bsico es salvaguardar los
datos ante operaciones de lectura por parte de usuarios, ya sean perso-
nas o programas, no habilitados para ello. Por ejemplo quin puede
ver las notas de un alumno? sera una regla de confidencialidad.
Integridad: supone garantizar que la informacin no se ha falseado o

daado, esto es, que no se han realizado modificaciones inadecuadas,
de forma que cuando el usuario acceda a ella sea completa y exacta.
Por ejemplo quin pone las notas de un alumno y en qu plazos?
sera una regla de integridad.
Disponibilidad: establece que los usuarios habilitados para ello

podrn acceder a la informacin cuando lo requieran. El sistema
deber adems responder dentro de unos mrgenes de tiempo ade-
cuados. Por ejemplo cualquier alumno puede acceder a sus notas a
travs de Internet y desde cualquier dispositivo sera 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 parmetros y situaciones que van ms all de los lmites
del sistema informtico (por ejemplo, capacidad de acceso fsico a un termi-
nal), por lo que habitualmente no se incluyen como parte del modelado de la
seguridad.
El mtodo de desarrollo debe permitir integrar la especificacin de la

poltica de seguridad, que determine la confidencialidad y la integridad, de
tal manera que sta se exprese en los mismos trminos que el resto de las
caractersticas de la aplicacin. As, si la presentacin o la estructura se
indican utilizando nodos y contenidos, las reglas de seguridad tambin
deben escribirse haciendo uso de esas mismas abstracciones y no de ele-
mentos fsicos como puedan ser ficheros, directorios o tuplas de una base
de datos.
La integracin de la seguridad como una parte ms del desarrollo hace de

ste un proceso integrador y ms completo. Mtodos como Ariadne (Daz 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 aplicacin multime-
dia interactiva.
TABLA 5.6. Ejemplos de reglas de seguridad en un sistema multimedia

Confidencialidad Quin puede/no puede acceder a un determinado nodo.
Quin puede/no puede acceder a un determinado contenido de un
nodo.
Integridad Quin puede/no puede modificar un determinado nodo o contenido.
Quin puede/no puede crear nodos o contenidos.
Quin puede/no puede borrar nodos o contenidos.
Quin puede/no puede personalizar nodos o contenidos.
Como puede verse en la tabla 6, esta especificacin tiene dos caractersti-

cas fundamentales:
Es conceptual, pues las reglas se expresan en funcin de nodos o con-
tenidos y no se tiene en cuenta si stos son ficheros, directorios o estn
almacenados en algn tipo de base de datos.
Es multi-nivel, pues las reglas permiten restringir el acceso a un nivel
ms detallado que el del contenedor de la informacin (nodo), de
manera que se puede conseguir que dos usuarios distintos tengan dis-
tintas vistas y distintas capacidades de manipulacin para el mismo
nodo o para sus contenidos.
Modelado de funciones. El funcionamiento de la aplicacin debe tam-
bin especificarse como en cualquier otro tipo de producto software. Esta no
es una caracterstica especial de los sistemas multimedia y por tanto no se
profundizar en este tema.
Modelado de la navegacin. Gran parte de los productos multimedia son
en realidad hipermedia, puesto que incluyen enlaces o relaciones navegables
entre conceptos (Daz y otros, 1996). En este caso, es preciso poder especificar
esa estructura de navegacin, que no hay que confundir con la estructura lgi-
ca que se mencionaba en el epgrafe Modelado de la estructura.
DEFINICIN: Enlace.
Un enlace es una conexin 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-
cin o una definicin; presentar una ilustracin o esquema; ver un ndice, etc.
Adems, 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 (Daz 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
especficos dentro de los nodos (enlaces entre posiciones). Los primeros

expresan una relacin semntica entre todo el contenido de un nodo y
otro concepto, y suelen representarse en el origen mediante un icono,
de forma que esta conexin global se localiza fsicamente en una zona
de la pantalla. En los enlaces entre posiciones se conecta un elemento
de informacin incluido dentro de un nodo con otro contenido o nodo
relacionado. En este caso, se suele emplear el trmino 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 ms usual remarcar de algn 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
travs 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 ms fcil de mantener
que dos unidireccionales puesto que en el caso de que uno de los nodos
cambie de nombre, slo 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 orgenes y un
nico destino se emplean normalmente para representar conexiones
genricas que afectan a muchos elementos del hipertexto (por ejemplo,
enlaces a un nodo de ayuda), de manera que si se cambia el destino
slo 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 condicin. Por ejemplo, en un sistema de
aprendizaje, la seleccin de un enlace Ejercicios llevar a cada alumno
al problema que le corresponde resolver. Tambin 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 informacin como tal sino que se crea en tiempo de utilizacin
del hiperdocumento. Este tipo de enlace, definido por medio de alguna
especificacin funcional se denomina virtual. Un sencillo ejemplo con-
siste en relacionar cada nodo con el visitado anteriormente, mediante
la definicin 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 dinmica, dependiendo de algn tipo de condicin
presente en el momento de su activacin, dotando as de una cierta
capacidad de inferencia a los sistemas hipertextuales.
Enlaces con tipo. Se puede aumentar la definicin del enlace aa-
dindole ciertas propiedades, ya sea en forma de tipo o de atributos.
As por ejemplo, Conklin propuso la primera distincin entre enlaces
estructurales, que responden a relaciones jerrquicas (por ejemplo,
entre captulos de un libro), y los enlaces referenciales, que reflejan
una conexin semntica entre dos elementos sin ningn tipo de con-
notacin estructural.
Enlaces con atributos. Otra posibilidad es la asignacin de atributos,
en nmero no definido, que incrementen la semntica de los enlaces,
permitiendo su utilizacin en el planteamiento de consultas directas en
un lenguaje de interrogacin. As, por ejemplo, en un hipertexto al que
accediesen mltiples lectores, podra existir la opcin de realizar una
rpida visita por las ltimas novedades incluidas, de manera que se
mostrara un subhipertexto formado por aquellos nodos y enlaces cuyo
atributo Fecha de creacin no superase un determinado valor.
Adems de a travs de una estructura de enlaces, la navegacin suele rea-
lizarse por medio de herramientas avanzadas como son los mapas, ndices,
huellas, mecanismos histricos o buscadores (Daz y otros, 1996) que facili-
tan la orientacin en grandes espacios de informacin.
5.4. RESUMEN
El anlisis es una actividad bsica en el desarrollo de cualquier sistema
interactivo pues va a permitir extraer criterios de aceptacin 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 mtrica
para poder verificarlo. Para recoger informacin sobre estos requisitos pue-
den emplearse tcnicas tales como los cuestionarios, las entrevistas, los gru-
pos de trabajo, la observacin, el estudio de documentacin 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 algn docu-
mento que sea completo, correcto, no ambiguo, modificable, verificable,
con referencias cruzadas y con una clasificacin de requisitos segn su esta-
bilidad o importancia.
El diseo es la fase en la que se aportan soluciones a los requisitos identi-
ficados en el anlisis para lo cual se hace uso de algn mtodo de especifica-
cin o modelo. En el caso de los sistemas multimedia habr que tener en
cuenta que es preciso disear la forma en que se muestra la informacin (pre-
sentacin), la manera en que sta se organiza (estructura); la reaccin 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 informacin (navegacin).
5.1. Un enlace:
a) Siempre hay que utilizar prototipos para recoger requisitos.
b) Puede tener ms de un destino.
c) Puede tener ms de un destino pero nunca ms de un origen.
d) Se define siempre entre un nico origen y un nico destino.
e) Siempre conlleva un cambio de nodo o pgina.
5.2. El anlisis 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 implementacin.
5.3. Al modelar la presentacin de un producto multimedia:

a) Slo se consideran aspectos estticos.
b) Se pueden emplear relaciones temporales para crear presentaciones
ms dinmicas.
c) Cada elemento de contenido slo puede tener una nica especifica-

cin de las caractersticas de presentacin.
d) Se define la forma en que se accede a los nodos.
5.4. De acuerdo con la notacin explicada en este captulo, para decir que
dos contenidos estn alineados por la izquierda:
a) La topologa tiene que asumir el valor disjunto.
b) Hay que indicar la distancia en los dos ejes de coordenadas.
c) La direccin es irrelevante.
d) La distancia en el eje de la Y es 0.
5.5. El diseo conceptual de la estructura de un producto multimedia:

a) Depende de la plataforma de implementacin.
b) Slo se pueden utilizar relaciones de generalizacin/especializacin
y agregacin.
c) Se describe cmo navegar por la informacin.
d) Refleja qu entidades de informacin hay, cules son simples y cu-
les son compuestas, y cmo 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,
pgs. 59-69.
DE ROSE y DURAND (1994): S. DeRose y D. Durand, Making Hypermedia Work: A Users
Guide to HyTime Kluwer Academic Publishers, Dordrecht 1994
DAZ y otros (2001a): P. Daz, I. Aedo y F. Panetsos. Modeling the dynamic behavior of
hypermedia applications. IEEE Transactions on Software Engineering, vol 27 (6),
Junio 2001, pgs. 550-572.
DAZ y otros (2001b): P. Daz, I. Aedo y S. Montero. Ariadne, a development method for
hypermedia. Dexa 2001. LNCS 2113, pgs. 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. CHI86 Proceedings, pgs.
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.
Captulo 6
DISEO DE UNA INTERFAZ DE USUARIO
ESQUEMA
6.1. La interfaz de usuario.

6.2. Paradigmas de interaccin.
6.3. Estilos de la interaccin.
6.4. Principios de diseo.
6.5. Ejemplo de recomendaciones de interaccin para un sitio Web de
comercio electrnico.
6.6. Uso de la metfora.
6.7. Resumen.
La interfaz es el canal de comunicacin a travs del cual se realiza la
transferencia de informacin entre el usuario y la mquina, y si esta comuni-
cacin no es fructfera es bastante probable que el producto software segura-
mente no goce de gran aceptacin.
Como medio de comunicacin, la interfaz es fsica. As por ejemplo, el
usuario utilizar un teclado, una pantalla, un ratn o cualquier otro dispositi-
vo de entrada o salida cuyas caractersticas afectarn de algn modo a la con-
secucin de sus objetivos. Pero la interfaz tambin es simblica, en la medida
en que cada uno de los elementos que se presentan al usuario tiene un signifi-
cado y un propsito especfico (por ejemplo, el uso de iconos). En consecuen-
cia, la interfaz no slo ofrece una forma de control sino tambin un entorno
de trabajo, que, de cara al usuario, puede ser explcito (por ejemplo, un escri-
torio) o no (por ejemplo, un lenguaje de comandos) (Dillon, 1991).
Desde los aos ochenta, el diseo de la interfaz de usuario ha ido
adquiriendo una importancia cada vez mayor en el desarrollo de produc-
tos software de calidad. En este captulo se presentarn, en primer lugar,
distintos tipos de interfaces de usuario, as como varios paradigmas de
interaccin, para pasar a continuacin a presentar los estilos bsicos de
interaccin. Al final del captulo se mostrarn las ocho reglas de oro para
la construccin de una interfaz y algunas recomendaciones para el desa-
rrollo de sitios Web de comercio electrnico, para finalizar introduciendo
el concepto de metfora.
6.1. LA INTERFAZ DE USUARIO
Un sistema multimedia es un sistema interactivo en el que la interaccin

debe concebirse como un dilogo entre el usuario y el producto software con
objeto de completar una tarea, ya sea sta seguir un curso, leer un libro elec-
trnico, visitar un museo virtual o comprar unas entradas para el cine. La
interfaz es el medio a travs del cual ese dilogo se materializa, de ah la
importancia de llevar a cabo un diseo cuidadoso que maximice la efectivi-
dad y eficiencia de esta comunicacin.
DEFINICIN: Interfaz de usuario.

Comprende aquellos aspectos del sistema con los que el usuario entra en contacto
(Moran, 1981)
Puesto que un sistema informtico est formado por un hardware y

un software, la interfaz afectara 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 ratn o la pantalla son
dispositivos de interaccin bastante habituales. En este texto no se anali-
za el diseo de dispositivos hardware por estar poco relacionado con el
objeto del libro. En relacin con el software, el usuario tiene a su disposi-
cin una serie de objetos (por ejemplo, ventanas, iconos, mens, etc.) con
los que interacta para conseguir sus objetivos. Este captulo se centra en
la forma de disear esos componentes del software que conforman la
interfaz de usuario con el fin de mejorar la comunicacin entre el usuario
y la mquina.
El primer aspecto a considerar a la hora de disear la interfaz de usua-
rio es si el usuario va a interaccionar con ella o no (Daz y otros, 1996). En
el primer caso, tiene lugar un intercambio de informacin bidireccional
entre el usuario y la mquina, 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 mquina siempre es el mismo, independien-
temente del usuario o de su entorno, como suele ocurrir cuando se ve
televisin. En este texto se supone que las aplicaciones multimedia son
bsicamente interactivas y no simples presentaciones con las que el usua-
rio no puede interactuar.
Centrndose meramente en el intercambio de informacin, 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 slo se emplea texto para la
comunicacin en ambos sentidos (desde la mquina 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.
Grfica: es aquella interfaz en la que se puede utilizar texto e imagen
en la comunicacin desde la mquina a la persona. Este tipo de inter-
faz era la que ofrecan, por ejemplo, los sistemas hipertexto (Daz 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
vdeo en la comunicacin desde la mquina a la persona. Este es sin
DISEO DE UNA INTERFAZ DE USUARIO 165
duda el estilo predominante en las aplicaciones multimedia en las

que se emplean diversos recursos para transmitir informacin al
usuario.
Multimodal: es aquella interfaz en la que no slo la presentacin de la
informacin es multimedia sino que la entrada al sistema tambin 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 haca uso de gestos y sonido. En pri-
mer lugar sealaba con el dedo el objeto que quera mover, luego deca
put that, de nuevo sealaba con el dedo dnde haba que ponerlo y
deca there para finalizar.
Conversacional: es aquella en la que el usuario se comunica con la
mquina conversando. Es un tipo especial de interfaz multimodal en el
que se establece un dilogo al estilo tradicional. Este tipo de interfaces
conllevan tcnicas de procesamiento de lenguaje natural que no siem-
pre son necesarias en las interfaces multimodales (vase 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 INTERACCIN

Antes de desarrollar cualquier tipo de sistema interactivo, uno de los pun-
tos clave que ayudarn a realizar un diseo efectivo del sistema es la adop-
cin de un determinado paradigma de interaccin.
DEFINICIN: Paradigma de interaccin.

Se entiende por paradigma una filosofa o forma de pensar sobre el diseo de la
interaccin, 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 diseo son: tiempo compartido, las unidades de
vdeo, las herramientas de programacin, la informtica personal, los siste-
mas de ventanas y la metfora. En la actualidad el paradigma ms utilizado
es la manipulacin directa pero los avances que se estn produciendo en la
sociedad de la informacin (por ejemplo, miniaturizacin, acceso en red,
1
http://gn.www.media.mit.edu/groups/gn/projects/humanoid/.
telefona, etc.) hacen que surjan nuevas formas de interaccin como la infor-
mtica ubicua, la informtica pervasiva, la informtica que se lleva puesta
(wearable computing), las interfaces tangibles, la realidad aumentada y los
entornos atentos (attentive environments). A continuacin se describen
estos paradigmas.
6.2.1. Manipulacin directa

El paradigma de manipulacin directa se basa en el desarrollo de una
representacin 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
utilizacin de este tipo de interaccin son el escritorio de algunos sistemas
operativos, videojuegos, sistemas de control areo, etc. Aunque este tipo de
paradigmas se asocian habitualmente con entornos WIMP (Windows,
Icons, Mouse and Pull-down menus) pueden ser implementados tambin,
por ejemplo, como entornos virtuales en los que el usuario interacta con
objetos recreados por ordenador. Este es el caso de la figura 6.1 en la que se
FIGURA 6.1. Un ejemplo de manipulacin directa en entornos virtuales

(Universdidad de Stanford)2.
2
http://www-graphics.stanford.edu/.
puede apreciar un usuario que interacta de forma virtual con un cuerpo

humano virtual.
6.2.2. Informtica ubicua

La informtica ubicua tiene como objetivo fundamental que los ordena-
dores desaparezcan del entorno, integrndose en l. Como indica Mark Wei-
ser, un visionario de la computacin ubicua, La computacin ubicua no
producir nada nuevo, sino que lo har ms rpido y fcil, con menos esfuer-
zo y una menor gimnasia mental, transformar lo que es aparentemente
posible. Esto no quiere decir que los ordenadores se hagan ms pequeos y
porttiles 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-
cin. En la figura 6.2 se puede ver tres dispositivos integrados en una oficina
(CommChair, DynaWall e InteracTable).
FIGURA 6.2. Tres ejemplos de informtica ubicua (Fraunhofer Institut fr Integrierte

Publikations und Informationssysteme).
6.2.3. Informtica pervasiva

La informtica pervasiva es un paso hacia delante en la informtica ubi-
cua, teniendo como idea subyacente el poder interactuar con la informacin
desde cualquier lugar y en cualquier momento. Ejemplos de este paradigma
son los frigorficos que incorporan una conexin a Internet para poder reali-
zar la compra, las agendas electrnicas que a travs de tecnologa Bluetooh
permiten la conexin inalmbrica con la oficina central, etc. En la figura 6.3
se puede ver una representacin grfica de una solucin de la compaa IBM
para poder realizar este tipo de informtica.
FIGURA 6.3. Una representacin de informtica pervasiva (IBM)3.
6.2.4. Computacin que se lleva puesta
La informtica que se lleva puesta se inspira en muchas de las ideas sub-

yacentes a la informtica ubicua. La idea fundamental de este paradigma es
que las tecnologas multimedia y de comunicaciones pueden integrarse en
las ropas que portan las personas. Esto quiere decir que las gafas, jersis,
joyas, etc. proporcionan un medio con el cual el usuario puede interactuar
con la informacin 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 fsico, encontrando formas de combinar
la informacin 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 fsico y el virtual. En la figura 6.6 se puede ver un ejem-
plo de realidad aumentada en el que sobre un papel fsico se integra una
representacin virtual de una torre con reloj, de manera que cuando el papel
se mueva tambin 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 interaccin 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 autnomos de acuerdo a la voz y la cara del dueo.
6
http://www.se.rit.edu/~jrv/.
FIGURA 6.7. Un ejemplo de un entorno atento (Sony)7.
6.3. ESTILOS DE LA INTERACCIN

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-
acta con el sistema de maneras muy diversas. Al definir la interfaz en cualquiera
de estos paradigmas el diseador puede utilizar cualquiera de los siguientes estilos
de interaccin bsicos (Shneiderman, 1998): seleccin por men, rellenado de
espacios, lenguajes de comandos, lenguaje natural y manipulacin directa.
6.3.1. Seleccin por men

En la seleccin por men, los usuarios leen una lista de elementos y eligen
el ms apropiado para la tarea que tienen que realizar, aplican una determinada
sintaxis para indicar su seleccin (por ejemplo, sitan el cursor encima de la
opcin), la confirman (por ejemplo, pulsan con el cursor la opcin), se inicia la
accin y observan sus efectos. En la figura 6.8, el usuario ha desplegado el men
FIGURA 6.8. Ejemplo de interfaz de seleccin por men.
7
http://www.aibo.com/.
Archivo y ha situado el cursor sobre la opcin Guardar como. A continuacin,

deber pulsar el ratn sobre la opcin y esperar la respuesta del sistema.
Algunas de las ventajas de este estilo de interaccin son: un aprendizaje
rpido, utilizacin de estructuras de decisin y una fcil gestin de errores.
Algunas desventajas son: el peligro de utilizar muchos mens, 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,
situndose 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 mtodo de introduccin 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
facturacin de una venta.
FIGURA 6.9. Ejemplo de interfaz de espacios en blanco.

Algunas de las ventajas de este estilo de interaccin son: se simplifica la

entrada de informacin, permite utilizar herramientas para la gestin 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 sensacin 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 instruccin
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 interaccin son: es flexible, da la

iniciativa al usuario y permite la creacin 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 cmoda de

interaccin hombre-mquina, 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 situacin actual, son impre-
decibles, y muchas veces se requieren dilogos de clarificacin.
La principal ventaja de este estilo es que no hace falta aprender la sinta-
xis del idioma. Algunas desventajas son: requiere muchos dilogos de clarifi-
cacin, es algunas veces impredecible y puede requerir un esfuerzo aadido.
6.3.5. Interfaces de manipulacin directa
En los interfaces de manipulacin directa, el diseador crea una repre-

sentacin 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 supondra seleccionar-
lo con el cursor y arrastrarlo hasta la papelera.
FIGURA 6.11. Ejemplo de interfaz de manipulacin directa.
Estos tipos de interfaz pueden emplearse de forma aislada o bien se pueden

combinar. La seleccin del ms apropiado va a depender de parmetros tales
como el tipo de informacin 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 interaccin son: se representa
visualmente el concepto de la tarea, se puede aprender fcilmente 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 ms fcil esta labor), requieren dispositivos externos y, en
muchos casos, la realidad no se ha reflejado de manera fiel.
6.4. PRINCIPIOS DE DISEO

Se puede decir que no existen panaceas en la creacin de la interfaz, pero
s una serie de lneas 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 lneas pueden ser:
principios de diseo, que dan cuerpo a las teoras de diseo de la
informacin en forma de recomendaciones;
reglas, que dan un camino ms detallado sobre aspectos especficos de

la interfaz;
guas de estilo, que son una coleccin de reglas de diseo y principios
que aseguran una apariencia similar en un conjunto de aplicaciones
(por ejemplo, las guas de las aplicaciones Windows de Microsoft), y,
estndares, que son colecciones internacionalmente reconocidas de
reglas y principios que proporcionan al diseador con un marco de tra-
bajo basado en la experiencia (por ejemplo, ISO 13407 es un estndar
dedicado a la definicin de los procesos de diseo centrado en el usua-
rio en sistemas interactivos).
Ben Shneiderman ha definido unos principios de diseo, denominadas
las ocho reglas de oro, que se han de tener en cuenta en el diseo de cualquier
interfaz (Shneiderman, 1998) y que ayudan al diseador 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
terminologa idntica en los mensajes, mens y pantallas de ayuda. Un
ejemplo de consistencia sera usar siempre el comando Nuevo para
crear cualquier elemento, en vez de tener comandos alternativos
dependiendo de la situacin.
La interfaz debe permitir accesos rpidos, de tal manera que los usua-
rios que utilicen frecuentemente el sistema puedan reducir el nmero de
interacciones. Algunos ejemplos de este tipo de tcnica son el empleo de
teclas de funcin 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 tamao 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 bsqueda de una palabra en un editor de
texto se inicia con la aparicin 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 condicin (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 accin si no dispone de toda la informacin necesaria.
Pero como es inevitable que el usuario se equivoque, el sistema debera
proporcionar mecanismos de vuelta atrs despus de realizar una tarea
compleja.
La interfaz debe permitir deshacer acciones. Las unidades reversibles

pueden ser una accin simple, una entrada de un dato o un grupo de
acciones completo. Por ejemplo, cuando se borra un elemento por confu-
sin se debe poder anular la accin, recuperando el elemento eliminado.
La interfaz se debe disear de manera que el control de la interaccin
lo tenga el usuario, ya que as se sentir ms cmodo con el sistema.
La interfaz debe permitir el empleo de frmulas con una sintaxis ya
construida, abreviaciones, cdigos y otros tipos de informacin, de for-
ma que el usuario pueda recordarlas ms fcilmente. Un claro ejemplo
de esta recomendacin es el uso de la palabra DIR en vez de DIREC-
TORIO.
6.5. EJEMPLO DE RECOMENDACIONES DE INTERACCIN

PARA UN SITIO WEB DE COMERCIO ELECTRNICO
Estos principios bsicos 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 diseador a poder asegurar que su
sistema es til y utilizable. En este sentido en esta seccin se presentan algu-
nas pistas y recomendaciones a tener en cuenta aplicadas en el terreno del
comercio electrnico, aunque vlidas para cualquier entorno, y en concreto
al caso de las tiendas electrnicas, a travs de preguntas que se podra plan-
tear el diseador a la hora de abordar el desarrollo del producto. Las res-
puestas a estas preguntas estn basadas en el trabajo de uno de los gurs en
el campo de la interaccin como es Jackob Nielsen. (Nielsen, 1999).
P.1. Cmo conseguir que el usuario realice rpidamente la tarea, ten-
ga un porcentaje bajo de errores y una alta satisfaccin?
Para que el usuario realice rpidamente una determinada tarea debe
estar familiarizado con la misma, de manera que comprenda su signifi-
cado y alcance. Adems, la descomposicin de la tarea en acciones, as
como su secuenciacin, tiene que ser la adecuada de acuerdo al conoci-
miento del usuario. Adems, no tienen que producirse retrasos innecesa-
rios debido a un mal dimensionamiento de la pgina, de manera que el
tiempo de respuesta estndar no debera superar un segundo. Otra forma
de que se realice rpidamente la tarea, es evitar incluir distracciones en
la informacin, evitando que se produzca sobrecarga tanto desde el pun-
to de vista de peso de la pgina como de cantidad de informacin. El
usuario estar ms 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 electrnica 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. Indicacin al usuario de que tarea est realizando y cules le quedan
por hacer (BOL)8.
P2. Cul es la velocidad esperada en la interaccin?

La velocidad de interaccin depende de muchos factores tales como la
edad, el conocimiento del medio, la familiaridad con la tarea, la disposi-
cin del dispositivo y del usuario, etc., por lo que es muy difcil disear un
sitio Web que se adapte perfectamente a todo tipo de usuarios. Habr que
tener en cuenta que el usuario novel prefiere velocidades ms lentas que los
expertos, por lo que la seleccin por mens es un buen mecanismo para
ellos, el cual debera combinarse con acceso mediante teclas rpidas para
que los expertos no se aburran utilizando el sistema. Adems, 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 pgina y se pregunta y ahora
qu? Para responder a esta pregunta, la interfaz debe proporcionar toda
la informacin necesaria para que el usuario pueda tomar una decisin
correcta sin tener que pulsar el botn de vuelta atrs.
Adems, todos los caminos para realizar las acciones que permite el sistema
tienen que estar accesibles, por lo que no se deben crear caminos especficos
para las opciones generales. Para ello, el diseador deber considerar la posi-
bilidad de incluir un directorio que ofrezca todas las alternativas, as como
un motor de bsqueda que facilite el acceso a informaciones especficas.
P4. Qu consideraciones tiene que tener en cuenta el diseador si se
quiere incluir informacin multimedia?
La primera consideracin que hay que tener en cuenta es la capacidad
de almacenamiento necesario para poder contener toda la informacin
del sitio. En segundo lugar, habr que considerar que este tipo de conte-
nidos requiere un ancho de banda para su transmisin muy superior al
de la informacin textual pudiendo producirse retardos inadmisibles en
la recuperacin de las pginas, 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 pgina 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 pelcula).
Figura 6.13. Ejemplo de m-icon (TC-Helicon)9.
P.5. Qu hacer si se requiere una aplicacin externa (distinta del nave-

gador)?
Es muy habitual proporcionar al usuario informacin que no puede

visualizarse directamente a travs del navegador que est utilizando.
Cuando ocurre esto, la interfaz debe advertirlo avisando al usuario de
este hecho y proporcionndole los mecanismos necesarios para poder
recuperar ese contenido (por ejemplo, mediante un enlace a la pgina
desde la que puede descargar ese software o mediante la ejecucin de un
proceso que inicie la fase de instalacin del mismo).
P.6. Cul es el periodo de funcionamiento del sistema?
Una de las caractersticas ms 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 seran los aspectos de interaccin, no es
as ya que este es un parmetro muy importante para que el usuario este
satisfecho con el sitio Web.
P.7. Cmo orientar el diseo del sitio Web?
El diseo 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 pgina
le enganche, tambin tiene que ser utilizable por parte del cliente
comprendiendo cules 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-

prara en un sitio que se llame www.estonofunciona.com?). Adems,
se tiene que considerar las caractersticas y necesidades del pblico al
cual se quiere atraer, teniendo en cuenta caractersticas 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 bsqueda al usuario, as como la facilidad de comprar
cualquier obra.
FIGURA 6.14. Un buen ejemplo de diseo orientado al producto y a sus usuarios

(Egallery)10.
10
http:// www.artbrokerage.com/mall/mall.htm.
P.8. Es ms importante la legibilidad o la vistosidad del sitio?

Por supuesto, es ms importante la legibilidad que la vistosidad del sitio Web.
La legibilidad no se refiere nicamente al tipo de letra utilizado sino tambin
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 comprensin sin crear distracciones innecesarias al
lector (por ejemplo, un icono en movimiento que cambia el foco de atencin
o simultanear elementos que requieran la atencin). Si se utilizan animacio-
nes o grficos muy complejos, se reduce de manera significativa la eficiencia
del sistema y, por lo tanto, se crea insatisfaccin en el usuario. Adems la velo-
cidad de captacin de informacin de cada usuario es distinta por lo que hay
que realizar una composicin armnica de los contenidos que permita una
comprensin 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-
cin, entonacin, etc.) de manera que el oyente interprete correctamente el
mensaje. Para todos los contenidos multimedia, habr que analizar si la cali-
dad y comprensin de la informacin puede verse afectada por retardos debi-
dos a la congestin en la red y al ancho de banda del servidor/cliente.
Cuando se utiliza informacin textual, se debe utilizar una tipografa
que sea ntida (por ejemplo, se suele recomendar una tipografa de tipo
serif para los ttulos y una sans serif para el texto) y con un tamao 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 ms que por la superior, es impor-
tante elegir una tipografa que no d lugar a ambigedades. Tambin
por esta razn, es mejor utilizar letras minsculas que maysculas 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 razn hay que adoptar una solucin 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 inters del cliente.
A la hora de definir el tamao en pixels de la imagen hay que tener en
cuenta que la imagen debera poder verse completa en configuraciones
estndar (por ejemplo, podra tener una tamao de 350 x 600 pixels para
una resolucin de 480 x 640), pero adems habra que tener en cuenta
que si se va a querer imprimir se va a hacer habitualmente en un tama-
o de papel estndar (por ejemplo, 670 x 535 pixels para papel US letter).
FIGURA 6.15. El sitio Web de una galera 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 semntico del color y de otros
recursos audiovisuales (tipografa, sonidos, etc.) lo que facilita el aprendi-
zaje y comprensin del sistema que se est utilizando. Adems, la consis-
tencia tambin se basa en utilizar los mismos nombres para referirse a las
mismas cosas, adems de que las mismas funcionalidades deben activar-
se siempre del mismo modo y producir el mismo tipo de resultados.
P.10. Cmo tiene que ser la informacin que muestre el sistema?
Las funciones y los datos que proporciona, el sistema tienen que ser
tangibles, lo que significa que tiene que ser explcito como se utiliza el
sistema y para qu sirve la informacin. El sistema tienen que transmi-
tir al usuario su intencionalidad, as como la de la informacin incluida
en l. Adems, todos los controles tienen que ser visibles y dar pistas de
cmo se utilizan, ya que en algunas ocasiones y debido a un mal diseo
el usuario puede que no sepa como hacer una determinada tarea o
accin, o como se utiliza el mecanismo para poder llegar a realizarla.
La principal recomendacin que se puede dar es que todas las unida-
des de informacin (nodo o pginas) 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 ms fcil-

mente identificable.
Otra recomendacin es el uso de herramientas de navegacin que ayu-
den al usuario a moverse por el espacio de informacin, proporcio-
nndole pistas sobre dnde est, cmo ha llegado all y qu puede
hacer. Algunas de estas herramientas de navegacin son: visitas guia-
das, que son caminos ms o menos lineales a travs del espacio de
informacin establecido por el diseador (figura 6.16); mapas, repre-
sentacin grfica del contenido del sistema (figura 6.17); mecanismos
de vuelta atrs, posibilidad de volver al nodo anteriormente visitado;
facilidades de ayuda, proporcionan una gua general para utilizar el
sistema e informacin especfica sobre elementos y situaciones en las
que los usuarios podran encontrarse; y los mecanismos de bsqueda,
complementan la navegacin til para acceso rpido a informacin de
la que se tiene algn conocimiento.
FIGURA 6.16. Una visita guiada por una galera de arte (Egallery).
FIGURA 6.17. Un ejemplo de mapa (Disney)11.
6.6. USO DE LA METFORA

Cuando una persona est leyendo crea representaciones mentales que se
asemejan a la estructura de un documento de papel, en trminos de localiza-
cin espacial y de organizacin global (Dillon, 1992). Estas representaciones,
o modelos, se derivan de aos de lectura de distintos tipos de documentos. La
misma conclusin se puede extrapolar para otros contextos, deducindose
que cuando un usuario se encuentra en una situacin conocida aplica patro-
nes de comportamiento adquiridos a travs de la experiencia. La utilizacin
de metforas (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 situacin real.
DEFINICIN: Metfora.
La metfora es la utilizacin de una realidad conocida por el usuario para dirigir
el comportamiento e interaccin de un sistema.
11
http://www.disney.com/.
El empleo de metforas en el diseo del interfaz ayuda a clarificar la natu-

raleza de los elementos de informacin que contiene el sistema, y consigue que
el usuario capte la manera en la que stos estn relacionados. Adems, al usua-
rio se le facilitar el acceso a las herramientas que ya le son conocidas, lo cual le
permitirn situarse rpidamente en el entorno de trabajo. Hammond y Allison
(1987) subrayan la importancia de la integracin de la metfora en el diseo del
sistema, ya que puede servir para el doble propsito de disciplinar al diseador
y ayudar al usuario a aprender. Esta integracin permitir, adems, acercar el
modelo conceptual del sistema al modelo mental del usuario. Estos autores
argumentan tambin que en las metforas existen dos dimensiones relevantes
para la comprensin de la informacin: el mbito y el nivel de descripcin.
El mbito se puede equiparar al nmero de conceptos dirigidos a la com-
prensin del usuario del sistema. Las metforas 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
electrnicos publicados por GlassBook12). Una metfora de mbito ms
pequeo es la metfora hidrulica, que utiliza tuberas para el transporte de
la informacin en los sistemas operativos Unix y MS-DOS (comando pipe).
El nivel de descripcin de la metfora equivale al tipo de informacin que
se intenta transmitir. Este tipo puede ser de muy alto nivel, tal como pensar
sobre las tareas y su ejecucin, o de muy bajo, reflejando una sintaxis de
comandos que permita recordarlos fcilmente. Las metforas no necesitan
estar destinadas a todos los niveles de descripcin, ya que no tienen que expli-
car todos los aspectos del sistema. Tampoco todas las caractersticas de la
metfora tienen que regir la aplicacin, as que, si parece ser inapropiada en
algn nivel de la descripcin, es mejor no forzarla. Una regla importante es
evitar relaciones errneas entre la metfora y el dominio del sistema, puesto
que el usuario puede sentirse engaado.
Se pueden cubrir varios aspectos de un sistema multimedia utilizando
metforas (Vnnen, 1995):
la presentacin, es decir, cmo aparecen, suenan e incluso se sienten
los objetos y los espacios de informacin;
la estructura, es decir, cules son las relaciones entre los distintos espa-
cios, y,
la interactividad, es decir, cmo interacta el usuario con la informacin.
Es importante que no se produzcan inconsistencias entre estos aspectos
(Eberts, 1994).
12
http.//www.glassbook.com/.
La metfora necesita generalmente, y en particular en un sistema multi-

media, ser concreta y familiar, altamente estructurada y explcita, visual y
multimedia, y, adems, espacial (Vnnen, 1995). Si un usuario est fami-
liarizado con la metfora que emplea, el sistema multimedia, podr com-
prender de manera rpida e intuitiva su funcionamiento y si, adems, se le
hace explcita la estructura de la informacin, se podr reducir considerable-
mente el problema de la prdida en el espacio de navegacin del sistema. La
multimedia ayudar a mejorar la calidad de la metfora utilizando todos los
canales sensoriales como base de adquisicin de la informacin. Las metfo-
ras espaciales proporcionan al usuario un slido modelo cognitivo para la
navegacin, ya que existe una relacin directa entre el espacio de informa-
cin y el de la metfora.
Algunos ejemplos de las metforas ms 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
comunicacin de informacin, especialmente en un contexto educati-
vo, por eso McLellan (1992) ha aconsejado su uso en los sistemas mul-
timedia. Segn esta autora hay tres razones fundamentales para
emplear historias:
proporcionan una estructura de la informacin familiar y conocida;
pueden reducir la carga cognitiva de la navegacin, gracias a la
riqueza de la informacin, y,
pueden ayudar a convertir la interactividad inherente al sistema en
una participacin activa y creativa mediante el uso de los elementos
involucrados en la historia.
b) La metfora del viaje consiste en la inclusin en el sistema de visitas
guiadas, de manera que el usuario piensa que est viajando por ella. El
xito de este tipo de metfora depende de la habilidad del diseador
para crear distintos caminos, as como de las opciones de seleccin
que proporcione al usuario.
c) En la metfora del museo, el conocimiento est expuesto del mismo
modo en que se podra 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 metfora del libro para
representar los contenidos, la estructura y los servicios. El corpus del
conocimiento est incluido en sus pginas de informacin electrnica,
que se muestran sobre una pantalla (Reynolds y Derose, 1992).
La interpretacin de la metfora empleada, as como de las recomenda-
ciones que se han ido exponiendo para la creacin del interfaz, hace que cada
diseador, partiendo de los mismos requisitos, realice un desarrollo multi-

media distinto. Adems, el cumplimiento de estas normas no significa que el
sistema resuelva satisfactoriamente las expectativas de los usuarios. Por todo
ello, en el captulo 7 se ver cmo se puede evaluar la interfaz creada, con la
finalidad de concluir no slo si el producto es bueno, sino cules son las defi-
ciencias a solventar para mejorarlo.
6.7. RESUMEN
En este captulo se ha presentado el diseo de la interaccin como uno

de los elementos fundamentales en el desarrollo de cualquier aplicacin
multimedia, y a la interfaz como elemento que sirve de comunicacin entre
el usuario y el sistema. Se han presentado, tambin, distintos tipos de inter-
faces y varios paradigmas de interaccin que en la actualidad se est desa-
rrollando y que hacen el campo de la interaccin 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
diseador de este tipo de sistemas puede hacerse cuando afronta un desa-
rrollo. Por ltimo, se han introducido el concepto de metfora 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. Cmo se denomina la interfaz en la que las entradas de informacin

son de naturaleza diversa?
a) Multimedia.
b) Multimodal.
c) Conversacional.
d) Textual.
6.2. Qu paradigma tiene como objetivo acercar el mundo fsico 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 rpido.
b) Facilidad en la gestin de errores.
c) Simplifica la entrada de informacin.
d) No hace falta aprender la sintaxis del idioma.
6.4. Quin da un camino ms detallado sobre aspectos especficos de la inter-

faz?
a) Principios de diseo.
b) Reglas de diseo.
c) Estndares.
d) Guas de estilo.
6.5. Qu herramienta de navegacin complementa la navegacin mediante

un acceso rpido a informacin de la que se tiene algn conocimiento?
a) Mapas.
b) Visitas guiadas.
c) Mecanismos de vuelta atrs.
d) Mecanismos de bsqueda.

BARKER y MANJI (1991): P. Barker. y K. Manji. Designing Electronic Books. Educatio-
nal and Learning Technology International (ETTI). 28 (4), pgs. 273-280.
BOLT (1980): R. A. Bolt. Put that there: Voice and gesture at the graphics interface.
Computer Graphics, 14(3), pgs. 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), pgs. 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 Bretaa), pgs. 75-90.
MCLELLAN, (1992): H. McLellan. HyperStories: some guidelines for instructional
designers. Journal of research on computing in education. 25 (1), pgs. 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), pgs. 3-50.
NIELSEN (1999): J. Nielsen. Designing Web usability. New Riders Pub. (versin 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), pgs. 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. pgs. 224-225.
SHNEIDERMAN (1998): B. Shneiderman. Designing user interfaces. Pearson educacin.
VNNEN (1995): K. Vnnen. Metaphor-based User Interfaces for Hyperspaces.
Eds. Schuler, W., Hannemann, J. y Streiz, N. Designing User Interface for Hyper-
media. Springer Verlag (Alemania), pgs. 68-78.
Captulo 7
EVALUACIN DE SISTEMAS INTERACTIVOS
ESQUEMA
7.1. El concepto de usabilidad.

7.2. Mtodos de evaluacin.
7.3. El proceso de evaluacin.
7.4. Parmetros para la evaluacin de sistemas multimedia.
7.5. Resumen.
Los sistemas multimedia son aplicaciones interactivas con las que el
usuario establece un dilogo 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 dilogo sea fructfero, es
decir, lograr que el usuario sea capaz de utilizar la aplicacin para satisfacer
sus objetivos en el mnimo tiempo posible y cometiendo el mnimo nmero
de errores.
La interfaz, ya sea fsica o simblica, es el canal a travs del cual se esta-
blece dicha comunicacin entre la persona y el ordenador. Si bien existen
reglas o guas de diseo que pueden ayudar al desarrollador a incrementar la
calidad de la interfaz, como se ha visto en el captulo 6, stas slo pueden
tomarse como meros consejos ya que slo se podr afirmar que los usuarios
son capaces de utilizar con xito un sistema si se ha realizado una evaluacin
que corrobore este hecho.
La evaluacin, que como se ver en este captulo puede llevarse a cabo en
todas las fases del proceso de desarrollo, va a proporcionar informacin que
permita comprobar si los mecanismos de interaccin se han diseado
correctamente, detectando aquellas deficiencias que haya que solventar o
proponiendo mejoras. Es muy importante tener presente que en ningn caso
la evaluacin es una parte de la etapa de pruebas y depuracin, ya que los
errores que se buscan con la evaluacin estn relacionados con la forma de
interactuar con el producto desarrollado y tienen su origen en una mala
comprensin o interpretacin de la forma en que el usuario se comunica con
el sistema, y no con posibles fallos o errores en el cdigo. La evaluacin tie-
ne como misin primordial asegurar que las aplicaciones se han diseado
teniendo en cuenta las necesidades de sus usuarios finales, y no slo las de
los desarrolladores.
El objetivo de este captulo es profundizar en qu consiste la evaluacin
de sistemas multimedia, qu tcnicas existen para evaluar y cundo debe o
puede utilizarse cada una de ellas, cmo puede realizarse el proceso de eva-
luacin y qu aspectos se puede analizar en l para obtener informacin
valiosa de cara a mejorar la interaccin con el sistema. Para ello se va a
comenzar analizando en la seccin 7.1 en el concepto de usabilidad. A con-
tinuacin, la seccin 7.2 intentar dar una visin de qu se entiende por

evaluacin, viendo brevemente qu se puede evaluar, por qu, cundo y
cmo. Finalmente, se profundiza en la forma de llevar a cabo la evaluacin
presentando algunos mtodos de evaluacin (seccin 7.3), un proceso gen-
rico para proceder con la evaluacin (seccin 7.4) y algunos aspectos que se
pueden medir durante el proceso de evaluacin de un producto multimedia
(seccin 7.5)
7.1. EL CONCEPTO DE USABILIDAD

La aceptacin de un producto software depende en general de un conjun-
to de parmetros (reflejados en la figura 7.1) que segn (Nielsen, 1993) tiene
dos vertientes: una social y otra prctica.
FIGURA 7.1. Parmetros relacionados con la aceptacin de un producto software.
La aceptacin 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, hbitos y normas del lugar en el que se va a implantar el pro-
ducto software.
Los factores incluidos en la segunda vertiente, la prctica, estn relacio-
nados con parmetros como el coste de la aplicacin, la compatibilidad, la
fiabilidad o la utilidad. ste ultimo aspecto es probablemente el ms difcil de
medir. Para que un sistema sea realmente til tiene que ser funcionalmente
correcto y, adems, debe ser posible que el usuario lo emplee de manera efi-
ciente para conseguir el fin para el cual se ha diseado. En este sentido, se
puede considerar que un usuario es capaz de usar con xito un sistema, o lo
que es lo mismo:
EVALUACIN DE SISTEMAS INTERACTIVOS 193
DEFINICIN: Un producto es USABLE, si (Rubin, 1994):

Ayuda al usuario a conseguir sus metas.
Es fcil de emplear: se cometen pocos errores y su uso es eficiente.
El producto es fcil 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 algn modo su usabilidad1. En dema-
siadas ocasiones, los diseadores tienden a calificar sus aplicaciones como
sencillas, amigables, intuitivas o fciles de utilizar simplemente por
el hecho de haber empleado interfaces WIMP (Windows Icons Menus Poin-
ters) o de manipulacin directa y basndose en su experiencia o la de sus
colegas al utilizar la aplicacin (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
ingeniera de la usabilidad (Mayhew, 1999). A lo largo de este captulo se
intentar dar una visin de cmo llevar a cabo la evaluacin para conseguir
datos fiables y tiles sobre la usabilidad de los sistemas multimedia.
7.1.1. Qu es la evaluacin
El hecho de aplicar guas o recomendaciones de diseo sobre la interfaz
de usuario no asegura que la aplicacin resultante sea utilizable, puesto que
siempre habr que tener en cuenta las reacciones del usuario ante el sistema
final. Puesto que la aplicacin interactiva se desarrolla con objeto de facilitar
unas tareas realizadas por un determinado tipo de usuarios, slo ellos pue-
den proporcionar informacin fiable sobre la usabilidad del producto resul-
tante. De hecho, slo se podr afirmar que los usuarios son capaces de utili-
zar con xito un sistema si se ha realizado una evaluacin que corrobore este
hecho, ya que, segn palabras de Benyon (1990), la evaluacin va a permitir
valorar y mejorar la interfaz para adaptarla a las caractersticas y necesidades
de los usuarios.
DEFINICIN: La EVALUACIN permite:

establecer si un sistema cumple las necesidades del usuario y si ste est satisfecho
con el sistema
Antes de pasar a estudiar ms en detalle la evaluacin, se intentar res-

ponder a algunas preguntas tpicas que aclaran el sentido de este proceso de
ingeniera de la usabilidad, como son qu evaluar, para qu, cundo y cmo.
7.1.2. Qu hay que evaluar?

En una aplicacin interactiva hay infinidad de aspectos y elementos sus-
ceptibles de ser evaluados, tales como la apariencia de los contenidos, la uti-
lidad de los mens o formularios, e incluso la forma en que los usuarios uti-
lizan los productos en su entorno puede ofrecer valiosa informacin para
disear la aplicacin (Preece y otros., 2002).
Un sistema multimedia es una aplicacin software intrnsecamente inte-
ractiva, pues el usuario est constantemente dialogando con el sistema para
obtener informacin. 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 aplicacin:
Estructura. Desde esta perspectiva se evalan las relaciones existentes
entre los distintos contenidos. La aplicacin multimedia est formada
por una serie de nodos o unidades indivisibles de presentacin 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 organizara en captulos que, a su vez, se
estructuraran en secciones que, finalmente, se compondran de una
serie de pginas cada una de las cuales contendr uno o ms elementos
de contenido. Estas relaciones puramente estructurales, as como cual-
quier otra de carcter semntico que se establezcan entre contenidos,
deben ser analizadas para comprobar si reflejan el conocimiento del
dominio que tiene el usuario.
Navegacin. En la navegacin se analizan las diversas formas en las
que el usuario puede moverse por la informacin. 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 tambin hay que analizar.
Contenidos. Esta perspectiva hace referencia a cada uno de los ele-
mentos de informacin que se utilizan en un producto multimedia. Por
ejemplo, una definicin de un trmino, una imagen o un vdeo que lo
ilustran seran tres contenidos distintos. Los contenidos de un sistema
multimedia pueden ser o no los adecuados, una adecuacin que en
muchas ocasiones depende ms del objetivo del sistema y de las carac-
tersticas de sus usuarios que de la calidad de cada contenido individual.
Presentacin. 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 trmino usabilidad no aparece en el Diccionario de la Real Academia Espaola,
se emplear en este captulo por considerarse aceptado en el mbito de los sistemas interactivos.
analizara lo que comnmente se llama interfaz de usuario, teniendo

en cuenta si la manera en la que los elementos de informacin y las dis-
tintas funciones que el usuario pueden realizar se presentan de la for-
ma ms apropiada y utilizable.
Interaccin. La interaccin 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
categora se incluyen los comandos ofrecidos para controlar la presenta-
cin multimedia, la utilizacin de mens, formularios y cualquier otro tipo
de mecanismo de interaccin cuya usabilidad debe ser contrastada.
As pues, la usabilidad del sistema podra analizarse de acuerdo a estos
cinco grandes bloques. Como ejemplo, la tabla 7.1 recopila algunas cuestio-
nes sobre usabilidad que podran plantearse, como primera aproximacin,
para cada uno de estos aspectos con objeto de ayudar a entender el significa-
do y la extensin del trmino usabilidad. Se ofrecer una descripcin ms
elaborada sobre posibles criterios a evaluar en una aplicacin 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 informacin est bien estructurada, de manera que cada nodo se
identifica con un nico concepto u objetivo?
Navegacin Se pueden utilizar las opciones de navegacin disponibles para con-
seguir los objetivos del usuario?
Se puede localizar rpidamente un concepto?
Se le facilitan mecanismos de orientacin?
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? Presentacin Se presentan los contenidos de forma armnica y se
usan para potenciar la comprensin del tema tratado?
Se utilizan caractersticas de presentacin para resaltar la informacin
clave?
Se satura al usuario con la informacin presentada?
Son evidentes las opciones disponibles?
Se hace explcita la estructura del sistema mediante pistas?
Interaccin Se pueden utilizar las opciones de interaccin disponibles para con-
seguir los objetivos del usuario?
Se restringe a los usuarios la utilizacin de la informacin?
Puede el usuario controlar el comportamiento de los elementos que
participan en el sistema?
7.1.3. Por qu hay qu evaluar?
La respuesta ms evidente e inmediata es que la evaluacin tiene como

misin 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 debera ser una razn suficientemente importante para justificar la
evaluacin de productos multimedia. Sin embargo, en los desarrollos comer-
ciales se tiende a evitar la evaluacin 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 evaluacin es una inversin 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 ms posi-
tiva en los usuarios que suelen ver en los productos multimedia una
sobrecarga de aprendizaje que puede evitar la utilizacin 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-
cin, debates que se zanjaran llevando a cabo una evaluacin.
Llevar a cabo un proceso de ingeniera de usabilidad en vez de debates.
Del mismo modo que el resto de los requisitos de una aplicacin son
analizados, diseados y verificados siguiendo un proceso ms 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 basndose en
buenas prcticas o reglas de oro.
Reducir el tiempo que tarda en salir al mercado el producto. En la
medida en que la evaluacin ayuda a detectar y solventar problemas
desde el inicio del desarrollo, el producto puede estar listo en menos
tiempo y cumpliendo requisitos bsicos 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 slido que puede conside-
rarse como una versin 1.1 2.0.
7.1.4. Cundo hay que evaluar?
La evaluacin 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 evaluacin se puede realizar durante distintas fases dentro del
ciclo de vida, utilizando en cada una de ellas la tcnica ms apropiada. Como
puede verse en la figura 7.2, la evaluacin se puede considerar como una
tarea central que proporciona informacin para validar las decisiones toma-
das en cada una de las restantes fases.
FIGURA 7.2. El papel de la evaluacin en el ciclo de desarrollo de aplicaciones software,

basado en el ciclo de vida en estrella descrito en (Preece y otros., 1994).
Durante el anlisis, se podrn emplear tcnicas para la extraccin de

requisitos de usabilidad que darn lugar a diseos conceptuales que hay que
contrastar antes de llevar a la prctica, ya sea en forma de maquetas o de
implementaciones ms completas. Adems, y de acuerdo con los resultados
de la evaluacin, se debera modificar el sistema que est en desarrollo. Este
proceso de modificacin del diseo del sistema se debe repetir frecuente-
mente, teniendo en cuenta los resultados de la evaluacin, de manera que se
d lugar a un diseo iterativo (Preece y otros., 2002).
De forma muy general, se distingue entre dos tipos de evaluaciones:
DEFINICIN: Tipos de evaluaciones.
EVALUACIONES FORMATIVAS: que sirven para comprobar que las necesidades

de los usuarios se estn teniendo en cuenta durante el proceso de diseo y desa-
rrollo del producto.
EVALUACIONES FINALES: que son aquellas que se hacen para asegurar el xito o
la posible aceptacin de un producto ya acabado.
7.1.5. Cmo hay que evaluar?
La forma de evaluar depende bsicamente de qu y cundo se va evaluar.

Adems, cualquier tipo de evaluacin, se siga la tcnica que se siga, se gua
por un conjunto de creencias, explcitas o implcitas, que pueden ser tambin
secundadas por la teora y que se conocen como paradigmas de evaluacin
(Preece y otros., 2002).
DEFINICIN: Paradigma de evaluacin.

Conjunto de asunciones sobre el objetivo de la evaluacin y la forma en que sta
debe llevarse a cabo.
Algunos paradigmas de evaluacin son:

Evaluaciones rpidas (Quick and dirty): se trata de conseguir de for-
ma muy rpida algn tipo de informacin sobre si las ideas de los dise-
adores estn 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.
Anlisis de usabilidad: se estudia qu harn los potenciales usuarios
al tratar de llevar a cabo tareas tpicas con el producto, midiendo el
tiempo requerido para completar las tareas y el nmero 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 comprensin que se tiene sobre lo que los usua-
rios hacen habitualmente y cmo les afecta la tecnologa.
Evaluaciones predictivas: en las que una serie de expertos aplican su
conocimiento sobre usuarios tpicos de la aplicacin, a menudo guia-
dos por heursticas, para predecir problemas de usabilidad
Para cada paradigma se podrn utilizar una o varias tcnicas.
DEFINICIN: Tcnica de evaluacin.

Proceso que puede aplicarse para realizar algn tipo de evaluacin o una parte de
la misma.
Ejemplos de tcnicas son: observar a los usuarios mientras emplean el

producto, preguntarles su opinin, preguntar a expertos, analizar el rendi-
miento de los usuarios o modelar ese rendimiento para predecir la eficiencia.
En la siguiente seccin se profundiza en la forma de llevar a cabo la evalua-
cin, presentado distintos mtodos aplicables.
7.2. MTODOS DE EVALUACIN
Es posible identificar diferentes mtodos para realizar la evaluacin de

un sistema en los que, de algn modo, subyace un paradigma de evaluacin
que pueden llevarse a cabo utilizando algn tipo de tcnica de las anterior-
mente mencionadas.
DEFINICIN: Mtodo de evaluacin.

Descripcin ms o menos detallada de una forma de llevar a cabo la evaluacin.
As por ejemplo, reinterprendo la clasificacin propuesta por Benyon en

(Benyon y otros., 1990) se pueden considerar cuatro mtodos de evaluacin:
Evaluacin analtica.
Evaluacin experta.
Evaluacin emprica.
Evaluacin experimental.
7.2.1. La evaluacin analtica
Este tipo de evaluacin hace uso de una descripcin formal o semiformal

del sistema (por ejemplo, un guin o storyboard) con el fin de predecir el com-
portamiento del usuario, tanto en trminos fsicos como de las operaciones
cognitivas que se deberan realizar. Entra pues dentro del grupo de evalua-
ciones predictivas, ya que al no ser necesario que exista el sistema sino tan
slo una especificacin del mismo, cualquier dato sobre la usabilidad se basa
en conjeturas sobre la forma en que el usuario interactuar. Adems, en
muchas ocasiones, se asume tambin el paradigma de la evaluacin rpida.
Los datos obtenidos en una evaluacin analtica sern muy genricos y no
directamente extrapolables a conclusiones sobre utilidad real, en tanto en
cuanto lo que se evala es una especificacin y no un producto en s. Permi-
tirn comprobar si se est yendo en una direccin adecuada, si bien no hacen
posible validar la usabilidad del sistema. Las evaluaciones analticas suelen
utilizarse en las fases de anlisis o diseo, ya que requiere pocos recursos, no
necesita prototipos costosos ni pruebas de usuario. Adems, pueden emple-
arse para analizar la factibilidad y la aceptacin social de un producto.
Un ejemplo de mtodo de evaluacin analtica es la evaluacin heurstica
propuesta por Jakob Nielsen en (Nielsen, 1994), en el que los autores propo-
nen una serie de heursticas para ayudar a los evaluadores a criticar el siste-
ma que se recogen en la tabla 7.2.
TABLA 7.2. Ejemplos de utilizacin de heursticas para la evaluacin analtica

(ampliados de Preece y otros, 2002)
Heurstica 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 estndares. La presentacin de la informacin se hace
siguiendo unas normas de estilo?
Producen funciones similares resultados similares?
Se ajusta el producto a algn estndar 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 guas sobre la forma de solucionar
el problema?
Prevencin de errores. Es fcil cometer errores?
Dnde y cmo?
Reconocimiento frente a recuerdo. Estn siempre visibles los objetos, acciones y
opciones disponibles?
Flexibilidad y eficiencia. Se adapta a las caractersticas del usuario o de
la plataforma?
Existen atajos para usuarios expertos?
Diseo esttico y minimalista. Hay informacin innecesaria?
Hay funciones innecesarias?
Ayuda y documentacin. La ayuda es contextual?
Es fcil de utilizar?
Se puede buscar de forma eficiente?
7.2.2. La evaluacin experta

Este mtodo de evaluacin, que se enmarcara dentro del paradigma de la
evaluacin predictiva, consiste en elegir una serie de personas altamente cua-
lificadas en el diseo de interfaces de usuario o en el tipo de aplicacin bajo
examen e invitarlas a juzgar el sistema e identificar los problemas de interac-
cin que encontrarn los usuarios.
Es un mtodo 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 caracters-
ticas, es un mtodo idneo para utilizarse en las fases de anlisis, diseo y
prototipado.
Un ejemplo de tcnica de evaluacin experta es el Walktrough que se ver
en detalle en el captulo 9, Ejemplos de desarrollo.
7.2.3. La evaluacin emprica
Este mtodo abarcara los paradigmas de estudios de usabilidad y estu-

dios de campo, pues tiene como objetivo enfrentar a usuarios reales con la
aplicacin para detectar los problemas de usabilidad. Existen dos tcnicas
ampliamente utilizadas para este fin: la evaluacin por observacin y la eva-
luacin por examen. En ambos casos se requiere que el sistema est en una
fase de desarrollo muy avanzada.
En la evaluacin por observacin se obtienen datos sobre la conducta
del usuario mientras ste est empleando el sistema. Para ello pueden apli-
carse las siguientes tcnicas:
observacin directa: un evaluador toma notas sobre las acciones del
usuario;
grabacin en vdeo: la actividad del usuario se graba y se visualiza con
o sin su participacin;
uso de software de registro: la interaccin del usuario con el sistema se
graba automticamente en ficheros (log) que, posteriormente pueden
estudiarse para reconstruir de algn 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 tcnicas, con la excepcin del software de registro, se dice
que son mtodos 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 evaluacin por observacin es un mtodo 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, dnde se encuentran las principales dificultades,
medidas de ejecucin o la frecuencia de errores de usuario.
La evaluacin por examen hace uso de entrevistas o cuestionarios con

el propsito de recoger opiniones subjetivas de los usuarios.
Las entrevistas consumen muchos recursos y requieren un entrevistador
capaz de extraer informacin 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 disearlos 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 ms difciles de analizar, pero propor-
cionan una fuente de informacin mayor ya que dan la opcin de expresar
opiniones, posibles mejoras, etc.
Las cuestiones cerradas pueden disearse de distintas formas, algunas de
las cuales se muestran en la figura 7.4.
FIGURA 7.4. Ejemplos de diseo de cuestionarios.
7.2.4. La evaluacin experimental

Por ltimo, en una evaluacin experimental, el evaluador puede manipu-
lar diferentes factores asociados con el diseo de la interfaz y estudiar sus
efectos en varios aspectos del rendimiento del usuario. Esto requiere un buen
conocimiento de mtodos experimentales y un gran consumo de tiempo y
recursos. Normalmente este mtodo se aplica cuando se ha desarrollado por
completo el prototipo. Una tcnica utilizada en esta fase es el Estudio en el
terreno, que consiste en una revisin del producto cuando ya ha sido implan-
tado en el lugar donde va a ser empleado (Rubin, 1994). Esta tcnica se com-
plementa en una etapa posterior con la realizacin de un Estudio de segui-
miento, que consiste en recoger datos de empleo de una versin para mejorar
la siguiente, usando exmenes, entrevistas y observaciones (Rubin, 1994).
7.3. EL PROCESO DE EVALUACIN

Los mtodos y tcnicas 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 seleccin que se haga de los mismos. No obstante, e
independientemente del mtodo o tcnica que se aplique, la evaluacin 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 evaluacin que se comenta
en las siguientes subsecciones.
FIGURA 7.5. El proceso de evaluacin (segn Daz y otros, 1996).
7.3.1. Definicin del objetivo de la evaluacin

En primer lugar hay que establecer de manera clara y precisa los objeti-
vos perseguidos en la evaluacin 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 aplicacin. Sin embargo, proponerse medir la usabilidad, sin ms des-
cripcin 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 tambin se encuentran:
comparar el producto con otro u otros similares;
analizar si mejora algn proceso que se haca a travs de un mecanis-
mo no automatizado, o
verificar si se ajusta a algn tipo de estndar, recomendacin o norma.
TABLA 7.3. Ejemplo de objetivos de la evaluacin para un curso virtual

Evaluacin 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 ms til que otro curso similar.
Comprobar si el curso es preferido frente a otro de formato presen-
cial, etctera.
En cualquier caso, es preferible huir de objetivos grandiosos difcilmente

verificables como, por ejemplo, comprobar si un curso virtual mejora de for-
ma genrica el proceso de aprendizaje.
7.3.2. Seleccin de la tcnica de evaluacin
Como se ha comentado anteriormente, existen diversos paradigmas,

mtodos y tcnicas de evaluacin. La seleccin de uno u otro depende de
mltiples 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. Preparacin de la evaluacin
La evaluacin 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.
Seleccin de los evaluadores. Es preciso decidir quin va a proporcio-
nar informacin durante el proceso de evaluacin, para lo cual habr que
tener en cuenta los objetivos de la evaluacin, la tcnica elegida y los recur-
sos disponibles. Si se ha optado por una evaluacin emprica o experimental
ser preciso contar con usuarios reales o potenciales, mientras que con tc-
nicas analticas 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, debera formarse un grupo que repre-

sente a los distintos tipos de usuarios finales. Adems, hay que conseguir que
las condiciones bajo las cuales se realiza la evaluacin recreen un entorno de
uso verdico, 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 seleccin de unos u otros dependeran, entre otros aspectos, del
objetivo del curso.
En cualquiera de las situaciones, la participacin 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.).
Etctera.
Expertos Diseadores de interfaces interactivas.
Diseadores instructivos.
Pedagogos, socilogos, psiclogos, etc.
Expertos en usabilidad.
Etctera.
Seleccin de los datos a recoger. Es necesario determinar qu dato, tan-

tos cuantitativos como cualitativos, se recopilarn y elaborarn para extraer
las conclusiones de acuerdo a los objetivos iniciales.
Los datos cuantitativos sern 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 nmero de errores cometidos.
En cambio, los cualitativos se recogern con protocolos verbales y cues-
tionarios o entrevistas, incluyendo preguntas con respuestas abiertas que pro-
porcionen informacin que pueda ser posteriormente analizada, por ejemplo,
Cmo se podra mejorar el producto para llevar a cabo la tarea X? Como ayu-
da se pueden emplear criterios como los presentados en la siguiente seccin.
Definicin de las tareas a realizar. Si se quieren estudiar todos los
mecanismos de interaccin de la aplicacin, es conveniente que la interac-
cin del evaluador sea guiada, de manera que no slo se asegure que se utili-
zan todas las opciones disponibles sino que tambin se puedan detectar erro-
res. Adems, 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 aplicacin concreta que se haya desarrollado. Por ejem-
plo, en un curso virtual tareas especficas seran realizar un determina-
do ejercicio o hacer un resumen de una leccin.
Tareas genricas: que son aquellas consideradas como propias de
cualquier producto multimedia. La tabla 7.5 resume algunos ejemplos
de tareas genricas.
TABLA 7.5. Ejemplos de tareas para un curso virtual

Navegacin Exploracin secuencial del producto.
Exploracin asociativa del producto.
Bsqueda Localizacin de un nodo por importancia.
Localizacin de un nodo por contenido.
Personalizacin Inclusin de anotaciones.
Inclusin de elementos personales (contenidos, enlaces, etc.).
Edicin Actualizacin de contenidos.
Actualizacin de la estructura.
Preparacin de los mecanismos de registro. Finalmente es preciso pre-

parar los artefactos a travs de los cuales se va a recopilar informacin, ya
sean cuestionarios, entrevistas, grabaciones o software de registro.
7.3.4. Realizacin de la evaluacin
Al realizar la evaluacin hay que recrear un entorno real. Adems, 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 comn de opiniones para obtener
resultados ms significativos.
Si se prev una evaluacin larga, se dividir en varias sesiones para no
cansar a los evaluadores, ya que la fatiga puede dar lugar a una falta de
inters que falsee los resultados de la evaluacin. En algunas ocasiones
llevar a cabo una sesin de prueba dentro del propio equipo de desarrollo
para depurar el proceso de evaluacin puede ser adecuado, sobre todo si
no se cuenta con una gran disponibilidad por parte de los evaluadores
reales.
7.3.5. Elaboracin de los resultados
Los resultados deben servir para extraer una serie de conclusiones en tr-
minos de deficiencias detectadas y mejoras propuestas que permitan revisar
el producto para incrementar su utilidad. Para elaborar los datos cuantitati-
vos suelen emplearse mtodos estadsticos, como por ejemplo la presencia,
moda, rango, valor mnimo, medio, mximo, desviacin tpica, frecuencia,
etc. Los datos cualitativos requieren normalmente de mayor interpretacin
para extraer informacin de utilidad.
7.4. PARMETROS PARA LA EVALUACIN 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 ms riguroso
que la experiencia o intuicin de los desarrolladores.
DEFINICIN: Criterio de evaluacin.

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 podran tenerse en cuen-

ta al establecer los datos a recopilar (seccin 7.4) y que estn basados en los
trabajos presentados en (Garzotto y otros., 1995; Ficarra, 1997; Aedo y Daz,
2001).
7.5. RESUMEN
En conclusin, la evaluacin se debe realizar durante todo el ciclo de

desarrollo, de manera que el producto final haya pasado por el mayor nme-
ro de filtros posibles, acercndolo y adaptndolo a las necesidades de la
empresa y del usuario.
La evaluacin puede realizarse siguiendo distintos mtodos (evaluacin
analtica, experta, emprica y experimental) cada uno de los cuales responde
a uno o ms paradigmas de evaluacin (evaluaciones rpidas, estudios de
usabilidad, estudios de campo y evaluaciones predictivas). En general, la
seleccin de un enfoque u otro depende de diversos factores, entre los que se
encuentran los recursos disponibles, el objetivo de la evaluacin, 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 parmetros o crite-
rios que hagan posible recopilar informacin relevante sobre la potencial
usabilidad de un producto multimedia.
TABLA 7.6. Criterios para la evaluacin de productos multimedia

Riqueza Mide la cantidad de elementos de informacin inclui-
dos, la expresividad de cada uno de ellos y la variedad
de formas de acceso e interaccin.
Capacidad de prediccin Expresa la medida en que los usuarios se anticipan al
resultado de una operacin.
Naturaleza de la metfora Representa la calidad del proceso de comunicacin
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.
Autonoma Refleja el grado de libertad concedido al usuario.
Consistencia Mide la coherencia de la aplicacin. Se comprueba si
elementos conceptualmente similares se tratan de la mis-
ma forma.
Esttica Mide cmo la incorporacin de informacin multimedia
aumenta la comprensin de los conceptos
Transparencia del significado Se utiliza para medir cmo los trminos utilizados en los
contenidos no causan ambigedades. La terminologa
utilizada, tanto para los contenidos como para el con-
trol del sistema, tienen un nico sentido, de manera que
el usuario entiende de forma inequvoca 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-
psito de cualquier elemento que se est presentando.
Soporte a la autora Permite recoger la medida en que el usuario puede
modificar el sistema hipermedia.
Soporte a la colaboracin Refleja la capacidad del usuario de colaborar y comu-
nicarse con otros usuarios.
Soporte a la personalizacin Mide la capacidad del usuario de personalizar el pro-
ducto.

7.1. Al evaluar un producto multimedia:
a) Slo se debe analizar la calidad de los contenidos.
b) Hay que tener en cuenta los mecanismos de acceso a la informacin.
c) Slo se pueden recolectar datos subjetivos que recojan las opiniones
de los usuarios.
d) No se puede recurrir a tcnicas de evaluacin analtica, puesto que
stas se basan en conjeturas no siempre trasladables al mundo real.
7.2. La evaluacin:
a) Retarda el tiempo de entrega pero permite obtener un producto de
mayor calidad.
b) Evita elucubrar sobre la bondad de un diseo, convirtiendo el diseo
de la usabilidad en un proceso de ingeniera.
c) Es una alternativa frente al diseo iterativo.
d) Slo 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 evaluacin:

a) Implican el uso de una nica tcnica muy concreta.
b) Las evaluaciones rpidas, los anlisis de usabilidad o los estudios de
campo son algunos de los paradigmas ms habituales.
c) Determinan el ciclo de vida del producto software.
d) Si se hace una evaluacin predictiva puede emplearse una tcnica de
evaluacin emprica.
7.5. Con respecto a la evaluacin analtica:

a) Hace uso de prototipos analizados por expertos y usuarios para lle-
var a cabo una evaluacin formativa.
b) Se podra enmarcar dentro del paradigma de estudios de campo.
c) La evaluacin por examen es una tcnica analtica que hace uso de

entrevistas y cuestionarios para recoger opiniones de los evaluadores.
d) La evaluacin heurstica es una tcnica analtica que ofrece algunas
guas para detectar problemas de usabilidad.

AEDO y DAZ (2001): I. Aedo y P. Daz. 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 Bretaa.
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 practitioners
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.

Captulo 8
DIRECCIN Y METODOLOGA
DE PROYECTOS MULTIMEDIA
ESQUEMA
8.1. Proyectos.
8.2. Direccin de proyectos.
8.3. Ciclo de vida.
8.4. Establecimeinto del mbito.
8.5. Desarrollo del plan de proyecto.
8.6. Ejecucin del plan de proyecto.
8.7. Monitorizacin y control del proyecto.
8.8. Cierre del proyecto.
8.9. Conclusiones.
Los conceptos que se presentan en este captulo son conceptos generales
de Direccin y Administracin de Proyectos de uso totalmente adecuado en
el desarrollo de un Sistema Multimedia. Este tipo de desarrollo goza de todas
las caractersticas que definen un proyecto en su sentido ms amplio y son,
por tanto, susceptibles de aplicarse todas las ideas que aqu se exponen.
Sin perjuicio de ello, existen en este curso captulos especficos de Anli-
sis, Diseo e Implantacin de Sistemas Multimedia donde se profundiza en
las tcnicas, modos y mtodos que son especficos a este tipo de proyectos.
Los conceptos de direccin de proyectos que se introducirn a continua-
cin forman parte de las tcnicas 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 Direccin Integrada de Proyectos, o sim-
plemente, Direccin de Proyectos.
Estas tcnicas tienen su origen en los aos 40 del pasado siglo XX, princi-
palmente en proyectos de defensa y aeroespaciales. Despus se han converti-
do en tcnicas de uso general en la Ingeniera y actualmente se pueden con-
siderar de uso general para cualquier actividad que pueda considerarse un
proyecto, especialmente si este tiene cierta complejidad.
Es fcil encontrar el uso de estas tcnicas en proyectos relacionados con
las tecnologas de la informacin, adems 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 tcnicas de direccin de proyectos, desde la visin del Project
Management Institute. Establecido en 1969 y con sede en Filadelfia, Pensyl-
vania (EE.UU.), el Project Management Institute (PMI) es la asociacin profe-
sional sin nimo de lucro de directores de proyecto principal del mundo, con
ms de 100.000 miembros distribuidos por todo el planeta.
El Project Management Institute fue fundado en 1969 por cinco volunta-
rios. Durante este mismo ao, se impartieron los primeros seminarios de
PMI en Atlanta, Georgia (EE.UU.). Actualmente, el PMI apoya a ms de
100.000 miembros en 125 pases por todo el mundo. Los miembros del PMI
son personas que trabajan en direccin de proyectos en diferentes reas:
ingeniera aeroespacial, industria de automviles, ingeniera civil, servicios
financieros, tecnologa de informacin, productos farmacuticos y telecomu-
nicaciones, etc.
El texto que se ha desarrollado en este captulo 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 bibliografa de este captulo) 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 direccin de proyectos segn la con-
cepcin 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-
cin que se considera muy valiosa para entender el enfoque de gestin de pro-
yectos global que propugna el Project Management Institute de EE. UU., que
est siendo de uso creciente en el mundo de la Direccin de Proyectos.
A continuacin se muestra un ejemplo de Ciclo de Vida para la Direc-
cin de Proyectos. Se ha elegido el ciclo de vida formulado por R.K. Wysocky
(Wysocky, 2000) por su exposicin clara y pedaggica y por estar absoluta-
mente en lnea con la metodologa anteriormente citada del PMI.
8.1. PROYECTOS
8.1.1. Concepto
DEFINICIN: Se puede definir un proyecto (PMBOK, 2000), como:

Una secuencia de actividades nicas, complejas y conectadas entre s, con un
objetivo o propsito y que deben ser completadas en un tiempo especfico, dentro
de un presupuesto y de acuerdo a unas especificaciones.
Dentro de la definicin 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
DIRECCIN Y METODOLOGA DE PROYECTOS MULTIMEDIA 217
Un objetivo. Un proyecto debe tener un objetivo final.

En un tiempo especfico. Los proyectos tienen una fecha de termina-
cin especificada. Puede estar auto impuesta por el equipo de direccin
del proyecto o externamente por el cliente o peticionario del proyecto.
Dentro de un presupuesto. De forma anloga al lmite temporal los
proyectos presentan un lmite de presupuesto habitualmente impuesto
por las condiciones externas del proyecto: el cliente tiene un lmite 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 duracin. 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 definicin, el desarrollo de un Sistema Multimedia
constituye un proyecto en el sentido del Project Management Institute.
8.1.2. Parmetros de un proyecto
Un proyecto viene definido por cuatro parmetros 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 dems parmetros del
proyecto. Asociado al alcance del proyecto se debe fijar tambin un
nivel de calidad. Estos dos parmetros sern los que definirn los
dems.
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-
triccin 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-
zacin 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 energa 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 parmetros con el denominado
triangulo del proyecto (figura 8.1): se sita 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 variacin del mbi-
to/alcance o nivel de calidad solicitados por el peticionario del proyecto se tra-
ducirn en variaciones de los parmetros coste, tiempo o recursos.
En resumen se puede pensar que un proyecto debe ser un sistema en
equilibrio dinmico 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. Definicin del tringulo del proyecto.
8.2. DIRECCIN DE PROYECTOS
8.2.1. Concepto y objetivos

Se puede considerar la direccin de proyectos como un rea dentro de las
tareas directivas en general. Comparte determinadas reas de conocimiento
con el resto de tareas directivas pero tambin tiene determinadas reas que le
son especficas.
Lo habitual, cuando se piensa en principios de Direccin, es pensar en
Direccin de personas. Se ver como esos principios tambin son vlidos
para la direccin de proyectos.
Un director debe: definir, planificar, ejecutar, controlar y cerrar las activi-
dades de las personas que dirige.
Definicin. Establecer el trabajo a realizar. En la direccin de proyec-
tos esta es una de las tareas prioritarias.
Planificacin. En la planificacin se deben cubrir los siguientes pun-
tos:
Que ha de hacerse.
Por qu ha de hacerse.
Quien lo har.
Cuando se har.
Que recursos sern necesarios para hacerlo.
Que criterios se debe cumplir para que el proyecto sea declarado
completo.
La planificacin reduce la incertidumbre:
El haber planificado el trabajo permite considerar la salida probable y
establecer los planes correctores necesarios.
La planificacin aumenta la eficacia: una vez definido el trabajo a rea-
lizar y los recursos necesarios par realizar el trabajo se est en disposi-
cin 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 planificacin en ocasiones es objeto de crticas argumentando que
tan pronto como un plan se ha finalizado comienzan los cambios al
mismo. En cualquier caso la planificacin es necesaria puesto que no
solamente proporciona una gua de lo que hacer, sino que tambin es
una herramienta para la toma de decisiones.
Ejecucin. Ejecutar el plan de proyecto incluye varios pasos. Adems
de organizar al personal, hay que identificar recursos especficos para
llevar a cabo el trabajo definido en el plan. Tambin implica la asigna-
cin de los trabajadores a sus actividades, y la programacin de activi-
dades en sus fechas de comienzo y final. La especificacin final de la
programacin del proyecto aporta juntas todas las variables asociadas

con el proyecto
Control. Como parte de los procesos iniciales de planificacin se cons-
truye una programacin inicial.
Esta programacin especifica qu debe hacerse, cuando, por quin, y
qu elementos entregables al cliente se esperan.
Independientemente de lo fino que se haya sido con la planificacin, el
trabajo del proyecto discurrir siempre de forma distinta al plan. Las
programaciones siempre sufren modificaciones, esta es la realidad de
la direccin de proyectos.
En cualquier caso el director del proyecto debe tener un sistema que cons-
tantemente monitorice el progreso del proyecto. Esta monitorizacin se
comparar con los planes establecidos y en funcin de las diferencias que
se obtengan se podrn 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 atencin, normalmente por las prisas que hay para termi-
nar el mismo y comenzar con otro.
Para abordar una fase de cierre de la forma ms provechosa posible se
debera tener en cuenta:
Si el proyecto ha satisfecho lo que el peticionario del mismo quera
hacer.
Si el proyecto ha satisfecho lo que el director del proyecto quera
hacer.
Si el equipo de proyecto ha completado el proyecto de acuerdo con el
plan.
Qu informacin se ha recogido para ayudar a proyectos posteriores.
Si ha funcionado correctamente la metodologa de direccin de pro-
yectos y de que manera la ha seguido el equipo de proyecto.
El cierre debe ser una evaluacin de lo que se ha hecho y debe propor-
cionar informacin histrica para futuros proyectos.
8.2.2. Procesos
DEFINICIN: Se puede definir un proceso, en el mbito de la direccin en general y de

la direccin de proyectos en particular, como:
Una serie de acciones que producen un resultado.
El PMI ha identificado una serie de procesos que conforman la gestin de

proyectos en su aspecto ms amplio y de forma transversal a las fases de rea-
lizacin del proyecto. Los procesos en la direccin de proyectos pueden
encuadrarse dentro de cada una de las reas de conocimiento que pueden
verse implicadas, y que el PMI identifica como sigue:
Gestin de la integracin.
Gestin del alcance del proyecto.
Gestin de tiempos del proyecto.
Gestin de costes del proyecto.
Gestin de la calidad del proyecto.
Gestin de los recursos humanos del proyecto.
Gestin de la comunicacin.
Gestin de riesgos del proyecto.
Gestin de suministros.
A su vez existirn procesos especficos para cada una de las fases del pro-
yecto, que siguiendo al PMI son:
Inicio.
Planificacin.
Ejecucin.
Control.
Cierre.
Atendiendo a estas dos clasificaciones, segn la fase y segn el rea de
conocimiento, se puede establecer una tabla completa de todos los distintos
procesos que puede implicar la direccin de proyectos de la forma ms gene-
ral posible.
Se reproduce aqu la lista general de procesos que el PMI en el PMBOK
describe en su edicin del 2000 (tabla 8.1). A continuacin se desglosan las
distintas reas y actividades.
TABLA 8.1. Tabla de procesos en la direccin de proyectos
reas Inicio Planificacin Ejecucion Control Cierre

Gestin de la Desarrollo del Plan de Ejecucin del Control de
integracin Proyecto Plan de cambios inte-
Proyecto grado
Gestin del Inicio Planificacin del Verificacin
alcance del alcance del alcance
proyecto Definicin del alcance Control de
cambios del
alcance
Gestin de Definicin de Control de la
tiempos del actividades programacin
proyecto Secuenciamiento de de actividades
actividades
Estimacin de la
duracin de
actividades
Desarrollo de la
programacin de
actividades
Gestin de Planificacin de los Control de cos-
costes del recursos tes
proyecto Estimacin de costes
Establecimiento del
presupuesto
Gestin de la Planificacin de la Garanta de Control de
calidad del calidad calidad calidad
proyecto
Gestin de los Planificacin de la Desarrollo del
recursos organizacin equipo de
humanos del Creacin del equipo trabajo
proyecto de trabajo
Gestin de la Planificacin de las Distribucin de Informes de Cierre
comunicaci comunicaciones la informacin seguimiento administrativo
del proyecto
Gestin de Planificacin de la Monitoriza-
riesgos del gestin de riesgos cin y control
proyecto Identificacin de los de riesgos
riesgos
Anlisis cualitativo de
riesgos
Anlisis cuantitativo
de riesgos
Planificacin de la
respuesta a los
riesgos
Gestin de Planificacin de la Pedidos Cierre del
suministros adquisicin Seleccin de contrato
Planificacin de los suministradores
pedidos Administracin
de contratos
Gestin de la integracin
En este rea se incluyen los procesos relativos a asegurar que varios
elementos del proyecto estn coordinados de forma adecuada.
Desarrollo del Plan de Proyecto. Integracin y coordinacin de
todos los planes de proyecto para crear un documento consistente
y coherente.
Ejecucin del Plan de Proyecto. Lleva a cabo el plan de proyecto
ejecutando las actividades incluidas en l.
Control de los cambios integrado. Coordinacin de cambios a lo
largo de todo el proyecto.
Gestin del alcance del proyecto
En este rea se incluyen los procesos relativos a asegurar que el pro-
yecto incluye todo el trabajo requerido y slo el trabajo requerido
para completar el proyecto con xito.
Iniciacin. Autorizacin del proyecto o la fase.
Planificacin del alcance. Desarrollo de una exposicin escrita
del alcance del proyecto como base para las decisiones futuras
del proyecto.
Definicin del alcance. Subdivisin de los grandes elementos entre-
gables del proyecto en elementos ms pequeos y manejables.
Verificacin del alcance. Formalizacin de la aceptacin del alcan-
ce del proyecto.
Control de cambios del alcance. Control de cambios en el alcance
del proyecto.
Gestin de tiempos del proyecto
yecto se finaliza dentro del tiempo requerido. Incluye:
Definicin de actividades. Identificacin de las actividades especfi-
cas que deben llevarse a cabo para producir los diferentes elemen-
tos entregables del proyecto, etc.
Secuenciamiento de actividades. Identificacin y documentacin
de las dependencias entre actividades.
Estimacin de la duracin de actividades. Estimacin del numero
de periodos laborables que van a ser necesarios para completar
actividades individuales.
Desarrollo de la programacin de actividades. Anlisis de las se-
cuencias de las actividades, duraciones de las actividades y requeri-
mientos de recursos para crear la planificacin de proyecto.
Control de la programacin de actividades. Control de cambios en

la programacin del proyecto.
Gestin de costes del proyecto
yecto se finaliza dentro del presupuesto asignado y aprobado. Incluye:
Planificacin de recursos. Determinacin de qu recursos (perso-
nas, equipos, materiales) y que cantidades de cada uno deben usar-
se para llevar a cabo las actividades del proyecto.
Estimacin de costes. Desarrollo de una aproximacin de los costes de
los recursos necesarios para completar las actividades del proyecto.
Establecimiento del presupuesto. Reparto del montante total de la
estimacin de costes entre las actividades de trabajo unitarias.
Control de costes. Control de los cambios sobre el presupuesto del
proyecto.
Gestin de la calidad del proyecto
yecto satisfaga las necesidades para las que ha sido acometido. Incluye:
Planificacin de la calidad. Identificacin de los criterios de calidad
que son relevantes al proyecto y determinacin de cmo alcanzarlos.
Garanta de la calidad. Evaluacin 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. Monitorizacin de resultados especficos del
proyecto para determinar si se acatan los criterios de calidad perti-
nentes e identificacin de las vas de eliminacin de las causas de
comportamiento insatisfactorio.
Gestin de los recursos humanos del proyecto
En este rea se incluyen los procesos relativos a asegurar que se reali-
za el uso ms eficaz de las personas involucradas en el proyecto.
Planificacin de la organizacin. Identificacin, documentacin y
asignacin de roles en el proyecto, responsabilidades e interrelacio-
nes de dependencia funcional.
Creacin del equipo de trabajo. Obtencin 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 desempeo del
proyecto.
Gestin de la comunicacin
En este rea se incluyen los procesos relativos a asegurar una genera-
cin, coleccin, diseminacin, almacenamiento y desecho final de la
informacin del proyecto apropiados y en el tiempo correcto. Incluye:
Planificacin de la comunicacin. Determinacin de las necesida-
des de informacin y comunicaciones de los involucrados en el pro-
yecto: quin necesita la informacin, cuando la necesitan y como
debe suministrrseles.
Distribucin de la informacin. Hacer que la informacin necesaria
est disponible para los involucrados en el proyecto en tiempo y for-
ma adecuados.
Informes de progreso o desempeo. Recoleccin y diseminacin de
la informacin de progreso o desempeo del proyecto. Incluye
informes del estado, medida de progreso y previsiones.
Cierre administrativo. Generacin, coleccin y diseminacin de la
informacin para formalizar la finalizacin de fases o del proyecto.
Gestin de riesgos del proyecto
La gestin de riesgos es el proceso sistemtico de identificacin, anlisis
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:
Planificacin de la gestin de riesgos. Decisin de cmo enfocar y
planificar las actividades de la gestin de riesgos para un proyecto.
Identificacin de los riesgos. Determinacin de los riesgos que pue-
den afectar al proyecto y documentacin de sus caractersticas.
Anlisis cualitativo de los riesgos. Realizacin del anlisis cualitati-
vo de riesgos y de las condiciones para priorizar sus efectos en los
objetivos del proyecto.
Anlisis cuantitativo de los riesgos. Medida de la probabilidad y
consecuencias de los riesgos y estimacin de sus implicaciones en
los objetivos del proyecto.
Planificacin de la respuesta al riesgo. Desarrollo de procedimien-
tos y tcnicas para realzar las oportunidades y reducir las amenazas
de riesgo a los objetivos del proyecto.
Monitorizacin y control del riesgo. Monitorizacin de riesgos resi-

duales, identificacin de nuevos riesgos, ejecucin de planes de
reduccin del riesgo, evaluacin de su efectividad a travs del ciclo
de vida del proyecto.
Gestin de suministros
En este rea se incluyen los procesos necesarios para adquirir bienes
y servicios externos a la organizacin que realiza el proyecto, para
completar el alcance del proyecto. Incluye:
Definicin de actividades. Identificacin de las actividades especfi-
cas que deben llevarse a cabo para producir los diferentes elemen-
tos entregables del proyecto.
Secuenciamiento de actividades. Identificacin y documentacin
de las dependencias entre actividades.
actividades individuales
Desarrollo de la programacin de actividades. Anlisis de las
secuencias de las actividades, duraciones de las actividades y reque-
rimientos de recursos para crear la planificacin de proyecto.
Control de la programacin de actividades. Control de los cambios
en la programacin del proyecto.
8.3. CICLO DE VIDA

Se habla de ciclo de vida como del conjunto de fases y tareas que confor-
man la realizacin de una actividad en el tiempo.
Este concepto est tremendamente generalizado en la actualidad, encon-
trndonos 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 centrndose en el rea de inters de proyectos, se dis-
tinguir entre:
Ciclo de vida de un proyecto.
Ciclo de vida de la direccin de proyectos.
8.3.1. Ciclo de vida de un proyecto

Es normal dividir cada proyecto en fases de cara a mejorar la gestin del
mismo. Estas fases a su vez contienen hitos que permiten ejecutar un control
sobre las actividades del da a da de la ejecucin del proyecto. El conjunto de
estas fases es denominado ciclo de vida del proyecto.
Cada fase del proyecto vendr marcada por la terminacin de una serie de
entregables, es decir de una serie de realizaciones tangibles y verificables
(un anlisis de viabilidad, un diseo detallado, un prototipo, etc.)
La conclusin de una fase del proyecto est marcada por una revisin 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 direccin. La mayor parte de esos entregables estn relacionados con el
entregable principal de la fase y las fases habitualmente se denominan en
relacin con esos entregables principales. As se puede hablar de: Diseo,
Construccin, 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 organizacin identifica una oportunidad a la que
quiere responder, autorizar un anlisis de necesidades o un estudio de viabi-
lidad para decidir si debe acometer o no el proyecto. La definicin 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 tambin qu acciones de transicin 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-
nizacin encargada de la realizacin.
La secuencia de fases definida por la mayor parte de ciclos de vida de pro-
yectos implica la transferencia de tecnologa o conocimiento en alguna forma
(requerimientos de diseo, diseo para fabricacin, 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 aprobacin de la aprobacin 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 tcnico 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, ms detallados, son conoci-
dos como metodologas o mtodos de direccin de proyectos (ms correcta-
mente, en castellano).
Para el caso concreto de Proyectos de Sistemas Multimedia que se trata

en este libro, se cita en el captulo correspondiente a las Fases de Desarrollo,
los ciclos de vida especficos para estos proyectos.
8.3.2. Ciclo de vida de la direccin 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 site el mismo. Por eso se hablar del Ciclo de Vida de la Direccin
de Proyectos de forma general e independiente al Ciclo de Vida del proyecto
que ser especfico del rea de conocimiento del proyecto en cuestin.
Siguiendo las directrices del PMI (PMBOK, 2000) y la experiencia de
Wysocki (Wysocki, 2000), se podr establecer un ciclo de vida de la gestin de
proyectos con cinco etapas. Esas etapas coinciden con las etapas habituales
de una actividad de direccin: definicin, planificacin, ejecucin, control y
cierre.
Como ya se vi, el PMI clasificaba los procesos inherentes a la direccin
de proyectos en procesos de inicio, planificacin, ejecucin, control y cierre.
Entre los procesos de planificacin y ejecucin existe un bucle de realimen-
tacin gobernado por los procesos de control. Esta situacin se esquematiza
en la figura 8.2.
INICIO PLANIFICACIN EJECUCIN
CONTROL
CIERRE
FIGURA 8.2. Bucle de realimentacin de los procesos de direccin de proyectos.

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

aron un ciclo de vida de la direccin 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) Ejecucin del plan de proyecto
d) Monitorizacin y control del avance
e) Cierre del proyecto
Se usar este ciclo de vida en estas notas para nuestro propsito pedag-
gico, porque resulta claro y estructurado. El alumno podr comprobar que
existen otras estructuraciones similares de Ciclos de Vida de Direccin de
Proyectos en otros autores relacionados con la Direccin de Proyectos.
Establecimiento del alcance Desarrollo del plan detallado Ejecucin del plan
Exposicin del problema / oportunidad Identificacin de las actividades del proyecto Localizac. y organizac. del equipo de trabajo
Establecimiento de la meta del proyecto Estimacin de la duracin de las actividades Establecim. de las reglas de func. del equipo
Definicin de los objetivos del proyecto Determinacin de los recursos necesarios Establec. del nivel de los recursos
Identificacin de los criterios para el xito Construccion/anlisis de la red de actividades Programacin de los paquetes de trabajo
Listado de suposiciones, riesgos y obstculos Preparacin de la propuesta de proyecto Documentacin 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 escalacin de problemas
Monitor. del avance del proyecto frente al plan
Revisin del plan de proyecto
Cierre del proyecto

Obtencin de la aceptacin del cliente
Implantacin de los entregables
Finalizacin de la documentacin del proyecto
Realizac. De una auditora de postimplantacin
Distribuir el informe final del proyecto
FIGURA 8.3. Bucle de realimentacin de los procesos de direccin de proyectos.

Ampliacin de funciones.
Establecimiento del alcance

En esta fase se establece una exposicin 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;
cmo se medir el xito del proyecto; y que riesgos, obstculos 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
Declaracin de la visin de conjunto del proyecto (Project Overview
Statement POS). Este documento recibe varios nombres en el argot
habitual de los proyectos: Documento de entendimiento, Exposi-
cin del alcance, Definicin inicial del proyecto o Exposicin del
trabajo. Habitualmente asociados a este primer documento deben
figurar un anlisis coste-beneficio, un anlisis de retorno de la inver-
sin, etc. que suelen ser necesarios para tomar la decisin 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, debern tenerse reuniones formales de planificacin
entre todos los involucrados en el proyecto. Los productos de estas reu-
niones de planificacin sern la descripcin 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 finalizacin 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.
Ejecucin del plan de proyecto
En esta fase se designar el equipo de proyecto, las programaciones

concretas de trabajo, as como las descripciones especficas del mismo.
Esta fase da paso a la de control que puede suponer un bucle de reali-
mentacin Control Desarrollo de plan modificado Ejecucin de
plan modificado Control, tal como se esquematiza en el diagrama
del ciclo de vida.
Monitorizacin y control del avance
Tan pronto como comienza el trabajo del proyecto, comienza la fase de

monitorizacin y control. Se definirn una serie de informes de estado
de proyecto normalizados que se usarn para monitorizar el avance
del proyecto. Una parte importante de esta fase es la gestin de cam-
bios, para ello se establecern procedimientos que permitan el proce-
so de peticiones de cambio. En esta fase tambin se activa el bucle de
realimentacin que permite el control, puesto que los cambios origi-
narn siempre replanificaciones del proyecto. Se gestionar tambin
la problemtica asociada con las finalizaciones anteriores o posterio-
res a la programacin del trabajo de las distintas actividades. Para tra-
tar todo lo planteado, se dispondr de un procedimiento de escalacin
de problemas.
Cierre del proyecto

Esta fase comienza con la aceptacin del proyecto por parte del
cliente. Los criterios de finalizacin del proyecto deben haber sido
claramente establecidos y acordados con el cliente como parte del
plan de proyecto. Las actividades ms habituales del cierre de un
proyecto sern: La instalacin y/o puesta en explotacin de los ele-
mentos entregables, la creacin de los informes y documentacin
finales o de cierre de proyecto y la realizacin de una auditoria de
post-implantacin.
8.4. ESTABLECIMIENTO DEL MBITO
8.4.1. Introduccin
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 dnde se va, cmo saber cuando se llegar y cmo saber si
ya se ha llegado.
Este entendimiento claro y de comn 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: Exposicin de la visin de conjunto del proyecto (Project Ove-
view Statement, POS).
Adicionalmente y si la complejidad del proyecto lo aconseja se escri-
bir un documento ms extenso que profundice y desarrolle el anterior
para los miembros del equipo de desarrollo del proyecto. Este documen-
to por ser de uso ms restringido y dirigido a especialistas en el desarro-
llo del proyecto podr usar un lenguaje ms concreto y tcnico que el
anterior. Este documento se denominar, siguiendo a Wysocki: Exposi-
cin de la definicin del proyecto (Project Definition Statement,
PDS).
El documento POS se desarrollar a lo largo de sesiones conjuntas de pla-
nificacin del proyecto en la que todos los involucrados moderados conve-
nientemente por el director del proyecto proporcionaran su conocimiento
para la realizacin de este documento.
El PDS se desarrollar de forma similar, pero basndose en el POS elabo-
rado, y restringiendo el grupo participante en las sesiones de planificacin, al
equipo de especialistas en el desarrollo del proyecto.
Las partes de un POS/PDS sern:

Declaracin 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.
Identificacin de los criterios de xito.
Lista de suposiciones, riesgos y obstculos.
Anexos.
Anlisis de riesgos.
Anlisis financieros.
8.4.2. Exposicin del problema o la oportunidad

Esta exposicin constituye un hecho que no precisa de ser definido o
defendido. Una exposicin de un problema o una oportunidad que es conoci-
da y aceptada por la organizacin constituye el cimiento sobre el que cons-
truir la base lgica 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 seccin anterior.
Un proyecto tiene una meta. La meta proporciona el propsito y la
direccin del proyecto. Define el producto final a entregar de forma que
todo el mundo entienda que hay que llevar a cabo en trminos claros. La
exposicin o manifestacin 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 exposicin de la meta no debe tener ninguna terminologa que pueda
resultar incomprensible para alguien que pueda leerla. Debe estar escrita en
el lenguaje del negocio de la organizacin, de forma que cualquier persona
involucrada en el proyecto (no slo el equipo de trabajo de desarrollo del pro-
yecto) la entienda sin mayores explicaciones.
Resulta conveniente que en la redaccin de la meta se siga la regla
SMART:
Specific.- Ser especfico en la determinacin del objetivo.
Measurable.-Establecer indicadores del progreso medibles.
Assignable.- Hacer el objeto asignable a una persona para su finalizacin

Realistic.- Expresar lo que se puede hacer de una forma realista con los
recursos disponibles.
Time-related.- Poner de manifiesto cundo se alcanzar el objetivo
8.4.4. Objetivos
Constituye el desarrollo detallado de la meta descrita en el apartado
anterior. Definen los lmites del alcance del proyecto. De hecho los objetivos
que se escriben para una meta especfica no son ms que una descomposi-
cin de la expresin de la meta en un conjunto necesario y suficiente de
objetivos.
Se podra decir que la meta es el resumen para la direccin de los
objetivos.
Para la exposicin de objetivos se aconseja incluir cuatro partes:
Un resultado. Exposicin de lo qu ha de llevarse a cabo.
Un marco temporal. La fecha de terminacin esperada.
Unos parmetros para medida. Las parmetros que se usaran para
valorar el xito.
Unas acciones. Cmo 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 direccin.
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 trminos de valor para el negocio o actividad de la organizacin
peticionaria del proyecto.
La mejor opcin 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 mrgenes, mayores ingresos, mejoras en la productividad,
reduccin de costes de fabricacin, 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-

cin del cliente.
Puesto que la direccin trabaja con elementos tangibles se deben expre-
sar nuestros criterios de xito en trminos cuantitativos, las medidas subje-
tivas del xito no funcionaran bien como medidas del xito de cara a la
direccin.
8.4.6. Supuestos, riesgos y obstculos

Aqu se identifican los factores que afectaran el resultado del proyecto y
que se quieren poner de manifiesto ante la direccin. Estos factores pueden
afectar a los entregables del proyecto, a la realizacin de los criterios de xi-
to, a la capacidad del equipo de proyecto de completar el proyecto segn se
ha planeado o a cualquier otra condicin de entorno o relativa a la organiza-
cin que sea relevante para el proyecto.
En el POS se colocan los riesgos generales que se quiere que conozca la
direccin mientras que en el PDS se har un listado ms exhaustivo e riesgos
que deben conocer todos los miembros del proyecto.
Los riesgos pueden ser:
Tecnolgicos.
Del entorno.
Interpersonales.
Culturales.
8.4.7. Formulario o modelo para el POS / PDS

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

Exposicin de la Nombre del proyecto Nmero de Director del
visin de conjunto proyecto proyecto
del proyecto
Problema / Oportunidad
Meta
Objetivos
Criterios de xito
Supuestos, riesgos, obstculos
8.5. DESARROLLO DEL PLAN DE PROYECTO
8.5.1. Identificacin 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 descomposicin permitir el anlisis detallado de la realizacin de cada
una de las tareas as como la posterior identificacin de los recursos necesa-
rios para la ejecucin de las mismas y los costes asociados a ellas.
La estructura de desagregacin del trabajo (EDT) es una descripcin

jerrquica del trabajo que deber realizarse para completar el proyecto tal
como se defini en el documento de exposicin de la visin 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 ms bajo)
FIGURA 8.4. Estructura de desagregacin del trabajo (EDT).
Existen dos trminos, actividad y tarea, que se suelen usar indistinta-

mente llevando a confusin. En este texto se usar actividad como un con-
junto de tareas:
Actividad: Cualquier subdivisin del trabajo.
Tarea: Una subdivisin ms pequea del trabajo, que forma parte una
actividad.
Para generar una EDT, lo ms conveniente es hacerlo en una sesin con-
junta de planificacin de proyecto en la que intervienen todos los involucra-
dos en el mismo.
Creacin del esquema EDT de arriba hacia abajo

Este es el enfoque ms sistemtico y til para la mayor parte de los
proyectos.
Existen otros enfoques de abajo hacia arriba que usan tcnicas 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 ms 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 desagregacin, segn las reglas que ms ade-
lante se expondrn. Estas actividades de nivel ms bajo tendrn el suficiente
nivel de detalle para ser descompuestas en tareas.
Se sabr que se ha alcanzado el nivel ms bajo de desagregacin si se
cumplen las siguientes condiciones:
Es medible el estatus o el grado de finalizacin.
Los eventos de comienzo y fin estn claramente definidos.
La actividad tiene al menos un elemento entregable.
El tiempo y el coste se pueden estimar con relativa facilidad.
La duracin de la actividad se encuentra entre lmite aceptables.
Las asignaciones de trabajo son independientes.
8.5.2. Estimacin de la duracin de las actividades

La duracin de las actividades es una magnitud ms complicada de obte-
ner puesto que no se suele conocer con precisin salvo en casos de proyectos
muy repetitivos o en sistemas de fabricacin en serie. Por tanto se tendr que
trabajar con una estimacin de la duracin en la mayor parte de los casos.
Para ello se dispone de las tcnicas que se abordan a continuacin.
8.5.3. Tcnica de similitud con otras actividades

Algunas de las actividades del proyecto sern similares a otras de otros
proyectos de las que se conozca la duracin. As se puede obtener una esti-
macin directa o por extrapolacin.
8.5.4. Tcnica de anlisis de datos histricos

Si se dispone de una buena prctica de Direccin de proyectos, se dis-
pondr de datos de histricos de proyectos con tiempos estimados y tiempos
reales de duracin de actividades. Estos datos histricos constituirn una
importante base de datos de conocimiento para la estimacin de la duracin
de las actividades. Estos datos histricos aplicaran no solo a la duracin sino
tambin a los perfiles necesarios y a otras caractersticas de cada una de las

actividades.
8.5.5. Tcnica de asesoramiento por expertos
Si las actividades del proyecto corresponden a tecnologas no maduras o

novedosas, no existir experiencia en la organizacin en cuanto a datos hist-
ricos o semejantes y ser preciso recurrir al asesoramiento de expertos en esas
tecnologas que aportaran datos acerca de las duraciones y perfiles requeridos.
8.5.6. Tcnica Delphi
Es una tcnica de grupo que pretende extraer y resumir el conocimiento

del grupo para llegar a una estimacin.
Se plantea el problema a un grupo de expertos, en este caso la duracin
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 estimacin del dato (la dura-
cin) ser el promedio de los ltimos datos obtenidos.
8.5.7. Tcnica de los tres puntos
La duracin de las actividades es una variable aleatoria. Para cualquier

ocurrencia de la actividad no es posible conocer en que extremo cae la dura-
cin de la actividad pero se pueden hacer afirmaciones estadsticas acerca de
su verosimilitud en cada caso.
Para realizar esto existe un marco de trabajo que proporciona un mtodo
para abordar esta situacin. Para ello se necesitan tener tres estimaciones de
la duracin: optimista, pesimista y la ms realista. La estimacin ms opti-
mista es la que tiene en cuenta que todo salga bien, la ms pesimista la que
considera todo lo que puede ir mal, y la ms verosmil es la que considera la
duracin ms probable. La estimacin, considerando que la distribucin de
la variable aleatoria duracin de la actividad sigue una distribucin Beta se
calculara como sigue:
O = Estimacin Optimista de la duracin
P = Estimacin Pesimista de la duracin
R = Estimacin ms Realista de la duracin
E = (O+4*R+P)/6
siendo E la estimacin de la duracin.
8.5.8. Tcnica Delphi mejorada o de banda ancha

Es la combinacin de la tcnica Delphi con la de los tres puntos. El grupo
de expertos en lugar de hacer una nica estimacin de la duracin cada uno,
realiza tres estimaciones (pesimista, optimista y realista) y se procede con las
tres iteraciones de la tcnica Delphi.
8.5.9. Estimacin de los recursos necesarios

Los recursos necesarios para la realizacin de las actividades sern:
Personal. Suelen ser los recursos ms difciles de programar debido a
la disponibilidad.
Instalaciones. Estas van desde salas de reunin para las sesiones de
planificacin, hasta instalaciones especficas de datos (CPDs, sistemas
de comunicaciones, etc.) o instalaciones industriales.
Equipos. Equipamiento informtico, equipamiento tecnolgico espe-
cfico del proyecto, maquinaria, etc.
Dinero. Aqu se incluirn los gastos inherentes al proyecto: viajes,
comidas, repuestos de los equipos, etc.
Materiales. Es todo aquello que es necesario para la fabricacin de ele-
mentos o construccin: acero, cables, materiales de construccin, 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 organizacin

para la realizacin 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 asignacin de las personas a

las actividades del proyecto segn 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. Programacin temporal. Construccin y anlisis

de la red del proyecto
El diagrama de red del proyecto es la representacin grfica de la secuen-
cia en que se realizaran las actividades del proyecto.
Las actividades y su duracin son los elementos bsicos necesarios para
construir la representacin secuencial grfica del proyecto.
La representacin grfica en diagrama de red proporciona dos elementos

de informacin adicionales acerca del proyecto:
El instante mas temprano en el que cada trabajo puede comenzar en
cada actividad.
La fecha ms temprana de terminacin 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 construccin de estos grafos
que son las que se explican a continuacin.
8.5.11. Tcnica de Actividades en las flechas (Activities on

Arrows AOA)
En este mtodo se colocan las actividades en las flechas del grafo, siendo
los nodos la representacin 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. Tcnica de actividades en las flechas (AOA).
Este mtodo 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 programacin temporal con uso de ordenadores.
8.5.12. Tcnica de Actividades en los nodos (Activities on

Nodes AON)
Este mtodo es justamente el dual del anterior. Ubica las actividades en

los nodos del grafo, siendo los eventos de finalizacin 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. Tcnica 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-

tinuacin:
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 anlisis se seguir el siguiente mtodo: se realizarn 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. Anlisis del diagrama de procedencia con AON

Comienzo ms temprano ES Early start
Finalizacin ms temprana EF Early finish
Comienzo ms tardo LS Late start
Finalizacin ms tarda LF Late finish
Y se escribirn sobre la actividad como indica la figura 8.7.
ES EF
Tarea j
Duracin = T
LS LF
FIGURA 8.7. Anlisis 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 situacin 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 planificacin. Pueden existir retrasos (R), la sucesora
comienza R unidades de tiempo despus del instante de finalizacin de la
predecesora. En el caso de existir adelantos (A) la sucesora comenzara A uni-
dades de tiempo antes del instante de finalizacin de la predecesora. Esto
R
habr de tenerse en cuenta en el anlisis de la red.
Oct 2003
ID Actividad / Tarea Comienzo Fin Duracin
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 ms 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 mltiples predecesoras, se usa-
r la finalizacin 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 finalizacin ms tarda (LF) de la ltima tarea igual al
de la finalizacin ms 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 mltiples sucesoras, se usar
el comienzo ms tardo (LS) menor de las sucesoras como finalizacin
ms tarda de la predecesora.
5. Se contina hasta el comienzo de la red.
Las tareas pueden tener holguras. Se definen dos clases de holguras:
Holgura total: (LFj EFj) o bin (LSj ESj)
Holgura libre: (ESj EFj-1)
8.5.14. Mtodo del Camino Crtico (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 duracin de la programacin del proyecto.
Este camino crtico representa tambin:
El camino ms largo (de mayor duracin) de todos los caminos posi-
bles de la red del proyecto.
El camino en que todas sus actividades presentan holgura cero.
La duracin total del proyecto.
El mtodo de programacin que usa el diagrama de precedencia con
duracin determinista de las actividades se denomina Mtodo 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 estimacin de la dura-
cin de las actividades se considera que sta es una distribucin de probabili-
dad, y se usa el mtodo de los tres puntos explicado anteriormente para estimar
duraciones esperadas, entonces se hablar de mtodo PERT de programacin.
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 mtodo PERT si se considera la duracin de las actividades
como una distribucin de probabilidad.
8.5.16. Diagrama de Gantt

Tradicionalmente se ha usado el denominado diagrama de Gantt como
herramienta de programacin temporal del proyecto. Este diagrama no es
ms que un calendario de tareas resultado de una programacin previa reali-
zada mediante las tcnicas de red expuestas anteriormente. En ningn caso
se aconseja usarlo como entrada a la programacin, pues no permite el
clculo de tiempos anteriormente expuesto, ni de las holguras temporales de
las tareas. Es til como salida o resultado de la programacin. 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 Duracin
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. EJECUCIN DEL PLAN DE PROYECTO
8.6.1. Creacin, organizacin y gestin del equipo de trabajo
Creacin del equipo
Los planes de proyecto y su ejecucin 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-

racin las capacidades o habilidades tcnicas de sus miembros, sino tambin
los papeles que jugar cada uno y la qumica 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 estratgicos y liderazgo.
Pericia tcnica.
Aptitud para las relaciones interpersonales.
Talento directivo.
El equipo principal
Tiene un papel clave en el proyecto, proporcionando capacidades de
aplicacin 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-
cin del mismo.
Entre las capacidades de sus componentes destacan:
Capacidad de compromiso.
Flexibilidad.
Orientacin a tareas.
Capacidad para trabajar dentro de programaciones y restriccio-
nes.
Disposicin para proporcionar confianza y apoyo.
Orientacin al trabajo en equipo.
Pensamiento abierto.
Capacidad para trabajar a travs de las estructuras y las autoridades
en la organizacin.
Capacidad para usar herramientas de administracin de proyectos.
El equipo fluctuante o temporal

Aportan capacidades especficas 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 gestin del pro-
yecto, ya que es ms difcil formar equipo con personas que no tienen
una vinculacin definitiva al proyecto, sino que solamente prestan sus
servicios cuando son requeridos.
Organizacin y gestin 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 organizacin le dota de la autoridad necesaria. La autori-
dad puede delegarla en otros profesionales (en especial en grandes pro-
yectos) que sern 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 relacin que permita trabajar
juntos con la mxima eficacia.
Estas reglas definirn de que forma:
Trabaja junto el equipo.
Se toman las decisiones.
Se resuelven los conflictos.
Se informa del progreso.
8.6.2. Revisin de la programacin temporal en funcin

de la disponibilidad de los recursos
Una vez terminado el proceso de programacin con la construccin 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 programacin diseada con los recur-
sos disponibles.
8.6.3. Nivelacin de recursos
Lo habitual es que la programacin temporal de recursos realizada traiga

consigo una sobreasignacin de recursos en determinados periodos, ya que el
foco de la programacin se realiz slo teniendo en cuenta fechas de comien-
zo y final de las actividades, as como su duracin, pero no se tuvo en cuenta
la disponibilidad de los recursos. Las tcnicas que permiten evitar o paliar en
alguna medida esa sobreasignacin constituye lo que se ha dado en denomi-
nar nivelacin de recursos.
Se puede hablar de tres tcnicas principales para la nivelacin 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-
cin 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 finalizacin. No en todos los proyec-
tos la fecha de finalizacin es un factor crtico e inamovible. Si se pue-
de jugar con la fecha de terminacin 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 sobreasigancin porque permite realizar ms cantidad de trabajo sin
variar la programacin temporal. Hay que ver si econmicamente es
posible puesto que es habitual que el coste total del proyecto sea una
restriccin inamovible
Se pueden usar otras tcnicas ms imaginativas para la nivelacin de
recursos tales como mayor descomposicin de las actividades, alargar activi-
dades con recursos a tiempo parcial, etc.
8.6.4. Creacin de los Paquetes de trabajo
Otra actividad a realizar una vez terminado el proceso de programacin

es la especificacin clara del trabajo a realizar en cada actividad. Se recuer-
da que las actividades estaban formadas por tareas en el ltimo nivel de
desagregacin del trabajo. Este conjunto de tareas a realizar en cada activi-
dad del nivel ms bajo de desagregacin es lo que se denomina Paquetes de
trabajo.
8.6.5. Documentacin 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 tambin como herramienta
de seguimiento, pues permiten ver con detalle cunto trabajo del previsto se
ha realizado.
Para documentarlos se usarn dos documentos:
La hoja de asignaciones de los paquetes de trabajo.
El informe de descripcin 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 finalizacin y los responsables asig-
nados. Tendr un aspecto similar a la tabla 8.7.
TABLA 8.7. Hoja de asignacin del paquete de trabajo
Hoja de asignaciones de los Paquetes Proyecto Director del Proyecto

de Trabajo
PAQUETE PROGRAMACIN RESPONSABLE

DE TRABAJO
Num. Marca Nombre ES Fecha ms temprana LS Fecha mas tarda Nombre Informacin de
de de comienzo de finalizacin contacto
finaliza
cin
Informe de descripcin del Paquete de Trabajo

Describe los detalles de cmo 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 fcilmente. Lo ideal es que la lista de
tareas sea una lista de comprobacin, 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 realizacin 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 descripcin del paquete de trabajo
Descripcin del Paquete de Trabajo Proyecto Director del Proyecto
Nombre del paquete de trabajo Nmero Fecha comienzo Fecha de fin
TAREA RESPONSABLE
Num. Marca Nombre Descripcin Duracin Nombre Informacin de
de contacto
finaliza
cin
8.7. MONITORIZACIN Y CONTROL DEL PROYECTO

El plan de proyecto puede verse como un sistema sometido a perturba-
ciones que tiene que mantenerse en equilibrio dinmico frente a las mismas.
La monitorizacin del proyecto servir para descubrir, cuanto antes, situa-
ciones de desequilibrio de forma que sea posible reaccionar con planes de
accin correctores.
Monitorizacin
Para poder monitorizar la realizacin del proyecto se instauraran una

serie de informes que estarn designados para presentar el grado de concor-
dancia de la realizacin en curso del proyecto con el plan realizado para el
mismo y para que esa misma informacin que presentan sea til para corre-
gir las variaciones respecto a ese plan. Estos informes podrn ser en forma de
tablas o grficos, siendo esta ltima la opcin preferible para poder mostrar
tendencias. Los parmetros generalmente monitorizados tienen que ver con
niveles de rendimiento, costes y programaciones temporales.
Ejemplos comunes de informes de monitorizacin (o seguimiento) son:
Programacin temporal actual frente a la planificada.
Tendencias en la programacin temporal.
Uso de recursos actual frente al planificado.
Control
Son las acciones tomadas en funcin del resultado de los informes. Estas
acciones estn diseadas para que cuando se implanten devuelvan el proyec-
to a una situacin de conformidad con el plan de proyecto.
En general se puede decir que cuanto mayor control, menos riesgo de
desviacin. Como en casi todo es preciso no llevar esta situacin al extremo y
llegar a un equilibrio entre las acciones de control y el riesgo de resultados
desfavorables.
8.7.1. Informacin de progreso

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

Informan del progreso de aquellas actividades que tienen programada su
realizacin 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 direccin, por lo tanto deben poder ser interpretados de for-
ma rpida. Puede ser aconsejable introducir apndices con informacin ms
detallada con las causas de las discrepancias.
Informes de variaciones o discrepancias.

Son similares a los anteriores pero con informacin amplia sobre las dis-
crepancias. Si se presentan en forma tabular tendrn tres columnas: el valor
planificado, el valor actual y la diferencia. Los valores tabulados son habi-
tualmente la programacin temporal y el coste.
8.7.2. Herramientas de generacin de informes
Gantt de seguimiento
As como en su momento se habl del error que supone usar el diagrama
de Gantt como herramienta de planificacin y programacin para el proyec-
to, debido a sus carencias en la representacin 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 informacin
precisa en cuanto a desviaciones de la programacin temporal se refiere. En
este diagrama se presentar el diagrama de Gantt de la planificacin y super-
puesto con cada una de las tareas el porcentaje de finalizacin de cada una de
ellas, en la fecha de generacin 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 podra considerar actividades de duracin 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 segn lo planificado o,
como se pone de manifiesto en la segunda figura, indican algn desajuste en
la realizacin del proyecto, por aparecer puntos radicalmente fuera de ten-
dencia, que ser preciso estudiar con ms detenimiento.
En En
adelanto adelanto
Desviacin
Desviacin
En En
retraso retraso
Hitos Hitos
FIGURA 8.10. Diagrama de tendencia de hitos.
8.7.3. Gestin de cambios

Es radicalmente imposible definir necesidades de forma precisa para un
proyecto que tendr una vida de varios meses o incluso de algunos aos. Esta
situacin lleva a que de forma ineludible aparecern cambios a lo planifica-
do a lo largo de la vida de proyecto. El cambio es una situacin intrnseca a
la Direccin de Proyectos, por lo que ser preciso disponer de un buen siste-
ma de gestin de los mismos.
Las dos actividades fundamentales para la gestin de cambios son:
La implantacin de un registro de peticiones de cambio.
La evaluacin de impacto de los cambios solicitados.
Para poder implantar la primera ser preciso disponer de un Documen-
to de peticin de cambios en el que la peticin de cualquier cambio debe
quedar perfectamente documentada.
Para la constancia de la evaluacin del impacto se configurar el docu-
mento Exposicin del impacto del cambio en el que los expertos del pro-
yecto manifestaran con profundidad qu influencia tiene el cambio en la pla-
nificacin del proyecto.
En funcin del estudio de impacto se decidir si se implanta el cambio, si
se implanta con modificaciones o si no resulta posible su implantacin.
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:

Obtencin de la aceptacin por parte del cliente de todos los elementos
entregables.
Instalacin de todos los elementos a entregar.
Documentacin del proyecto.
Realizacin del informe final.
Realizacin de auditoria de post-implantacin.
Celebracin del xito.
8.8.1. Aceptacin del cliente
Puede ser una aceptacin informal en la que el cliente firma la aceptacin

sin realizar pruebas especficas de aceptacin, 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 aceptacin formal para la que
habr que disponer unas pruebas de aceptacin solicitadas por el cliente. En
este caso la firma de la aceptacin no se producir hasta la superacin de
dichas pruebas.
8.8.2. Instalacin de todos los elementos a entregar
Esto supone crear un plan de despliegue de la instalacin de los entrega-

bles, que implica la elaboracin de un mini-proyecto con sus fases y tareas.
8.8.3. Documentacin del proyecto
Suele ser la parte ms difcil de completar en el cierre de un proyecto. La

documentacin suele ser una tarea poco atractiva pero de una importancia
fundamental pues es:
Una referencia para futuros cambios en los elementos entregables.
Un registro histrico para la estimacin de duraciones y costes de las
actividades/tareas de futuros proyectos.
Un recurso de formacin para futuros Directores de Proyecto.
Una informacin valiosa para la formacin y desarrollo posterior del
equipo de trabajo.
Una documentacin completa del proyecto debera incluir:
Documento de Exposicin de la Visin General (POS).

Documento de Propuesta de Proyecto, realizado al final de la fase de
planificacin con la descripcin completa de la misma.
Programaciones temporales originales y modificadas por la nivelacin
de recursos.
Actas de todas las reuniones del equipo de trabajo.
Copias de todos los informes de seguimiento.
Documentos de diseo.
Informes de cuestiones excepcionales.
Documentos de aceptacin del cliente.
Informe de la auditoria de post-implantacin.
Esta documentacin no se improvisa en unas cuantas jornadas de traba-
jo al final del proyecto. La documentacin 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 documentacin que se genera en una Car-
peta de Proyecto, preferiblemente en forma electrnica.
8.8.4. Realizacin 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:
Valoracin general frente a los factores de xito establecidos.
Organizacin.
Tcnicas utilizadas.
Puntos dbiles y puntos fuertes.
Recomendaciones del equipo para el futuro.
8.8.5. Realizacin de auditoria de post-implantacin
Esta auditoria es una evaluacin 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 satisfaccin 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 mtodo de direccin del
proyecto aplicado?
Qu ha funcionado bien, que ha funcionado mal?
8.8.6. Celebracin 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-
sin de este ha abarcado meses o algn ao. Los miembros del equipo han
crecido profesionalmente durante este tiempo, se han creado relaciones de
amistad, se han intercambiado consejos y guas. Pero el proyecto se acaba y
hay que deshacer el equipo. Merece una celebracin de cierre de proyecto.
Nunca se debe pasar por alto una oportunidad de mostrar al equipo de
trabajo la valoracin que se tiene de l. La lealtad, motivacin y compromiso
de un equipo de trabajo se ven influidas positivamente mediante estas valo-
raciones.
8.9. RESUMEN
En este captulo se han presentado las tcnicas generales de Direccin de

Proyectos desde le enfoque que realiza el Project Management Institute de
EE. UU.
Se han expuesto estas tcnicas con la suficiente generalidad para que
sean aplicables a un proyecto multimedia sin especiales alteraciones o modi-
ficaciones. Se han hecho referencia a tcnicas especficas de la tecnologa
multimedia cuando stas se consideran de especial necesidad, remitiendo al
alumno a los captulos especficos que profundizan en las mismas.
Se ha presentado, como ejemplo, una metodologa genrica de Direccin
de Proyectos elaborada por Wysocky (Wysocky, 2000) de forma que el alum-
no pueda asimilar los conceptos en un marco metodolgico, ms pedaggico
y prctico.

8.1. Entre las siguientes, existe una caracterstica que no es propia del con-
cepto de proyecto, segn el PMI:
a) Es un conjunto de actividades complejas.
b) Es un conjunto de actividades conectadas.
c) Es un conjunto de actividades peridicas.
d) Es un conjunto de actividades realizadas de acuerdo a unas especifi-
caciones.
8.2. La tcnica conocida como Estructura de desagregacin del trabajo -

EDT (Work Breakdown Structure WBS):
a) Permite estimar la duracin 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 ms eficaz de los
recursos.
8.3. La tcnica Delphi:

a) Es una tcnica para estimar el coste de las actividades que usa mto-
dos estadsticos.
b) Es una tcnica estadstica que precisa de tres estimaciones previas
(pesimista, realista y optimista).
c) Permite realizar simulaciones en lenguaje Delphi.
[d) Es una tcnica de grupo que permite extraer el conocimiento del
mismo para proporcionar estimaciones en general.
8.4. El Camino Crtico segn la tcnica del Diagrama de Precedencias:

a) Es el camino de menor duracin para la realizacin del proyecto de
entre todos los posibles.
b) Es el camino que permite usar la holgura de las tareas para solucio-
nar problemas de sobreasignacin de recursos.
c) Permite calcular la duracin del proyecto.
d) Es en el que se sitan las tareas fundamentales del proyecto.
8.5. Los informes de progreso acumulativos o histricos son propios de:

a) Las sesiones de planificacin para confeccionar el Visin de con-
junto del proyecto con ayuda de datos histricos de otros proyectos.
b) La etapa de monitorizacin y control.

c) La etapa de implantacin 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. Direccin y Gestin de Proyectos. Un enfo-
que prctico. Ed RA-MA. Madrid, 2000.
MS-PROJECT (2002): Carl Chatfield, Timothy Johnson. Microsoft Project paso a paso.
Versin 2002. Ed. McGraw-Hill. Madrid, 2002.
PMBOK (2000): Project Management Institute. Project Management Book of Know-
ledge, 2000.
PRESSMAN (1995): Roger S. Pressman. Ingeniera del Software. Un enfoque prctico.
Ed McGraw Hill. Espaa. Madrid, 1995.
WYSOCKI (2000): Robert K. Wysocki, Robert Beck, David B. Crane. Effective Project
Management, 2 Ed. Ed. John Wiley & Sons, USA, 2000.
Captulo 9
EJEMPLOS DE DESARROLLO
ESQUEMA
9.1. Now-Graduado: ejemplo de anlisis y diseo.

9.2. Ejemplo de evaluacin de la usabilidad.
9.3. Resumen.
En los captulos precedentes se han abordado las fases de que consta el
proceso de desarrollo de sistemas multimedia (Captulo 4), as como los pro-
cesos de anlisis, diseo y evaluacin (Captulos 5, 6 y 7). Con objeto de ilus-
trar los conceptos previamente estudiados, este captulo se va a centrar en
mostrar ejemplos concretos de anlisis, diseo y evaluacin.
Este captulo 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 anlisis, diseo e implementa-
cin. Este ejemplo se ha considerado adecuado porque tanto por las caracte-
rsticas del producto (tales como la inclusin 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
algn tipo de anlisis y de diseo conceptual antes de pasar a la implementa-
cin.
A continuacin, se presentar como ejemplo de evaluacin el caso de
CESAR, un sistema hipermedia educativo, cuya evaluacin permiti extraer
tiles conclusiones no slo para mejorar el propio producto sino tambin
para el proceso de evaluacin.
9.1. NOW-GRADUADO: EJEMPLO DE ANLISIS Y DISEO
Now-Graduado es una aplicacin hipermedia, es decir una combinacin

de multimedia e hipertexto, que se desarroll en el ao 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 cualificacin bsi-
ca y esencial para optar a gran nmero de trabajos y, de hecho, hay exmenes
que permiten que aquellos adultos que en su momento abandonaron los estu-
dios puedan ahora obtener este ttulo. Puesto que la mayor parte de los adul-
tos tienen dificultades para seguir cursos presenciales, ya sea por cargas labo-
rales o familiares, y, adems no suelen tener un hbito de estudio, se
consider que un sistema interactivo que cubriera los temas ms difciles

resultara de gran utilidad. Adems, se opt por una organizacin 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 ml-
tiples experiencias.
Los sistemas hipermedia son intrnsecamente interactivos (Rada y
otros, 1995) y la interactividad es bsica en cualquier proceso educativo.
La incorporacin de contenidos multimedia no slo resulta de gran uti-
lidad para mejorar la comprensin de ciertos conceptos y procesos sino
que, adems, hace el producto ms grato y ameno favoreciendo as una
actitud positiva por parte del usuario final.
La hipermedia ofrece la posibilidad de gestionar grandes volmenes de
informacin de una manera consistente y, al mismo tiempo, mante-
niendo relaciones entre distintos conceptos.
En las siguientes secciones se describen los procesos de anlisis, diseo y
construccin que se llevaron a cabo durante la elaboracin de este producto,
con objeto de ilustrar los conceptos presentados en los captulos 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 categora de requisitos no funcionales, mientras que los segundos
hacen referencia a mltiples caractersticas del sistema, ya sean concernientes
a los usuarios, a la informacin a ofrecer, a las funcionalidades a soportar o a
las caractersticas del entorno. En los siguientes epgrafes se describen algunos
de los requisitos ms relevantes organizados en las categoras introducidas en
el captulo 5 (Anlisis y diseo 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 aplicacin tena que ser llevado a cabo formando un
equipo multidisciplinar, en el que participasen tanto personal tcnico, inclu-
yendo programadores, analistas o diseadores grficos, como representantes
de los usuarios. As pues, desde el principio se evidenci la necesidad de lle-
var a cabo un proceso iterativo.
Adems, al tratarse de un proyecto concreto se contaba con unos plazos
de entrega firmes, por lo que la participacin de los representantes de los
usuarios tampoco poda retrasar el proceso de desarrollo.
EJEMPLOS DE DESARROLLO 263
Otro aspecto destacable dentro de esta categora de requerimientos es

que se parta de un curso en formato tradicional, cuya estructura y conteni-
dos se queran respetar.
9.1.3. Requisitos funcionales
Dentro de esta categora se incluyen todas las caractersticas relacionadas

con la forma en que deber funcionar el sistema, independientemente de las
restricciones tcnicas o de cualquier otro tipo.
En este sentido, la primera caracterstica que deba tener el producto era
posibilitar el estudio de los diferentes temas tratados en el curso, ya fueran
aspectos tericos o prcticos. Adems, tambin se quera que las alumnas
pudieran revisar los temas ya estudiados.
El temario se estructuraba en tres mdulos temticos: matemticas,
socionaturales y lengua, de forma que las alumnas podran elegir qu quer-
an estudiar. Adems, estas materias no eran completamente independientes,
puesto que entre ellas existiran enlaces que facilitaran 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 podra ser visitar un museo. Con
ello se pretenda reforzar el proceso de aprendizaje y prolongarlo ms all de
los lmites de la sesin de trabajo con el producto multimedia.
Adems se quera que se pudieran incluir recursos didcticos, tales como
un glosario o un diccionario, que fuera accesible tanto de forma indepen-
diente como a travs 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 temtica del producto, los contenidos propios del Gra-
duado Escolar, poda caerse en la utilizacin de una interfaz infantil, que des-
motivara a sus usuarios que podran sentirse infravalorados.
Adems, el hecho de que el producto estuviera orientado a mujeres en
exclusiva influy en algunas de las decisiones relacionadas con las caracte-
rsticas de la presentacin, como por ejemplo la esttica o el lenguaje
empleado.
9.1.5. Requisitos de datos

Con respecto a los datos se determin que estos seran de naturaleza
diversa, siendo preciso incluir textos, imgenes, dibujos, animaciones, locu-
ciones y vdeos. Si bien se requera la mayor calidad posible, el producto
deba distribuirse como un nico CD, por lo que la cantidad de material mul-
timedia a incluir deba restringirse.
Adems, el curso deba poder utilizarse en sistemas operativos Windows
y sin necesidad de tener que instalar ningn software adicional, por lo que los
formatos multimedia deban ser aquellos que pudieran presentarse en dicha
plataforma (por ejemplo, vdeos en formato AVI).
9.1.6. Requisitos del entorno

Dentro de este apartado se impusieron restricciones tales como conside-
rar que el curso se utilizara tanto en casa como en un centro con el apoyo de
tutores. Adems, se estableci que habra un curso de iniciacin 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 prctica del producto final. Los requisitos de usabili-
dad de Now-Graduado pueden resumirse en tres metas bsicas:
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 desorientacin del usuario sea mnima. Este ltimo es
un aspecto muy importante, puesto que uno de los problemas funda-
mentales del hipertexto es que la libertad de navegacin puede no favo-
recer el aprendizaje en algunos casos, especialmente en aquellos en los
que por las caractersticas de los estudiantes o del tema o por condicio-
nantes externos se requiera un acceso ms guiado.
Debe ser fcil de usar y aprender. Los usuarios deben comprender el
objetivo del producto y cmo pueden emplearlo para alcanzar sus
metas. Adems, se debe reducir la sobrecarga cognitiva que supone
aprender a utilizar el Now-Graduado, pues el tiempo que los usuarios
inviertan debe estar bsicamente 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 diseo orientados a cumplir estos requisitos. Dichos principios
se encuentran recogidos en la tabla 9.1.
TABLA 9.1. Requisitos de usabilidad

Requisito Principios de diseo
Debe ser til Estructurar el material didctico.
Restringir la navegacin.
Fomentar la participacin del usuario.
Considerar las necesidades y preferencias del usuario.
Debe ser fcil Hacer un uso de creativo de la multimedia.
de usar y aprender Evitar enlaces y servicios innecesarios.
Crear una interfaz de usuario homognea y consistente
Incluir pistas visuales.
Considerar el uso de metforas.
Debe provocar Incluir actividades interactivas.
una actitud positiva Aplicar una esttica adecuada y atrayente.
del usuario
9.1.8. Diseo conceptual

Una vez analizadas las caractersticas del producto, es preciso plantear
soluciones que tengan en cuenta dichos requisitos. Para ello se puede realizar
un diseo conceptual de la aplicacin que sea independiente de la plataforma
de implementacin, de tal manera que esas soluciones se expresan haciendo
uso de abstracciones que son fcilmente comprensibles por parte de todos los
miembros del equipo de desarrollo, independientemente de su formacin
previa.
Con este fin, en el proceso de elaboracin de Now-Graduado se recurri
al modelo de referencia para hipermedia denominado Labyrinth (Daz y
otros, 1997), que haba sido empleado en otras experiencias similares como
puede consultarse en (Lpez-Rey y otros, 1999). Por medio de este modelo
fue posible representar la estructura lgica del producto, las facilidades de
navegacin que se iban a ofrecer al usuario as como las caractersticas de
presentacin, las posibilidades de interaccin o la creacin dinmica de obje-
tos (Daz y otros, 2001a).
A modo de ejemplo, la figura 1 recoge la estructura lgica de Now-Gra-
duado a travs de un Diagrama Estructural, propio de la metodologa de
desarrollo Ariadne (Daz y otros, 2001b) que, a su vez, se basa en el modelo
de representacin Labyrinth. Como puede apreciarse en dicha figura, el sis-
tema se organiza como una jerarqua de nodos, que pueden ser:
contenedores de informacin (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-
qua). Existen dos relaciones de composicin, de acuerdo con el mode-
lo adoptado: la generalizacin (representada por medio de una flecha
desde el hijo al padre) y la agregacin (representada por medio de un
rombo con origen en el padre).
As, segn se muestra en la figura 9.1, Now-Graduado se compone de cuatro
elementos: la Presentacin, la Ayuda, el Glosario y el Curso en s. El nodo Pre-
sentacin es un nodo simple en el que se mostrar, a modo de introduccin, una
animacin 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 informacin, 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 Definicin). El Curso es un nodo ms com-
plejo puesto que, por una parte, se indica su estructura y, por otra, sus variantes.
El Curso se organiza como una agregacin de mdulos (nodo compuesto Mdu-
lo), cada uno de los cules se compone de lecciones (nodo compuesto Leccin),
que a su vez constan de pginas (nodo compuesto Pgina) que pueden ser de
tres tipos diferentes: pginas de teora (nodo compuesto Teora, formado por
nodos simples del tipo Concepto), de ejercicios teora (nodo compuesto Ejerci-
cios, formado por nodos simples del tipo Ejercicio) o una pgina para ampliar
conocimientos sobre el tema tratado (nodo Saber ms). Por otra parte, el Curso
se especializa en tres materias, representadas respectivamente por los nodos
compuestos Socionaturales, Lengua y Matemticas, 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 aplicacin
se hace uso de un Diagrama de Navegacin (Daz y otros, 2001), en el que se
indican caminos de navegacin entre los nodos. Para ello se pueden establecer
enlaces unidireccionales, bidireccionales, n-arios o binarios entre distintos
nodos (Daz y otros, 1996). La figura 9.2 muestra cmo puede acceder el usua-
rio a Now-Graduado. Desde la Presentacin, 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 Presentacin) y dos destinos (los nodos Ayu-
da y Curso). La seleccin del destino se hace en tiempo de utilizacin, 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 pgina en que
se estuvo (vase enlace Estudiar) o bien repasar lo que se ha hecho hasta el
momento, con lo que se accede a un ndice creado dinmicamente y en el que
slo se incluyen los conceptos y ejercicios ya estudiados (vanse los enlaces
Repasar y Seleccin). En cada Pgina se incluyen enlaces a la Ayuda y al Glo-
sario y, adems, existe una secuencia entre las pginas de una misma leccin,
de manera que se proporciona una herramienta de lectura lineal (vase el
enlace reflexivo Anterior/Siguiente). Para promover una actitud activa por
FIGURA 9.1. Estructura lgica de Now-Graduado.
parte del estudiante, en cada Pgina se le proponen tambin enlaces asociati-

vos a otras pginas sobre temas relacionados (vase el enlace reflexivo Asocia-
cin), ejercicios relacionados con ese tema (vase el enlace Ejercicicios) as
como enlaces directos entre trminos presentados en esa pgina y su defini-
cin en el Glosario (vase el enlace Mencin). stos ltimos suponen abrir
una ventana modal en la que se presenta ese concepto. ste y otros aspectos
de presentacin se indican tambin con el mismo modelo, si bien no se inclu-
ye aqu la especificacin por no aportar nada al objeto de este captulo. Ms
informacin sobre el modelo Labyrinth y el mtodo Ariadne puede encontrar-
se en (Daz y otros, 1997; Daz y otros, 2001a; Daz y otros, 2001b).
Esta representacin, que es independiente de la plataforma, puede ser
discutida con los representantes de los usuarios para identificar la estructura
lgica del sistema o las caractersticas de navegacin e interaccin 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 presentacin, como los colo-
FIGURA 9.2. La navegacin a travs de los nodos de Now-Graduado.

res o tamaos, que son ms llamativos y fciles de cambiar y, en cambio, se

centra en las caractersticas conceptuales del sistema. Una buena prctica
consiste en acompaar estos diagramas conceptuales con prototipos de usar
y tirar (Preece y otros, 2002), de manera que tambin pueda visualizarse la
interfaz y se puedan discutir en el equipo de desarrollo todo tipo de aspectos.
9.1.9. Implementacin
Como se coment al inicio de este captulo, Now-Graduado se implemen-
t utilizando Marcomedia Director. La aplicacin final era un sistema hbrido,
en el que el componente principal era un CD con los contenidos del curso que
haca 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 haba hecho en
las sesiones precedentes para poder actuar en consecuencia. Las siguientes
figuras muestran algunas de las pantallas de la aplicacin que se correspon-
den con algunos de los nodos conceptuales descritos en la seccin anterior. Al
describirlos, se har hincapi en aquellos aspectos de diseo 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 ensea-
dos a nios, se opt por una esttica apropiada para adultos. Adems se hizo
un uso semntico del color, de manera que cada temtica (matemticas, len-
gua o socionaturales) se asoci con un color especfico que dominara su
interfaz (azul, rojo y verde, respectivamente). Aquellas zonas comunes, como
esta pantalla del Curso, tienen un fondo formado por una combinacin de los
tres iconos, mientras que las zonas especficas de cada bloque temtico estn
dominadas por su correspondiente color (figuras 9.4 y 9.5).
Las pginas, del tipo que fueran, tenan una estructura similar que se
defina en el nodo Pgina 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 localizacin, que indica dnde se encuentra el usuario, y unas
herramientas de generales, como son el acceso a la ayuda, a la presentacin
o la finalizacin de la sesin de trabajo (representados, respectivamente por
los tres iconos de la derecha). Puesto que esta parte es genrica y no depende
FIGURA 9.4. Una pgina de Teora de Lengua en Now-Graduado.

del tema estudiado, su fondo es una combinacin de los iconos de los tres
temas del curso. Sin embargo, como el resto de la pantalla se destina al tema
especfico 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 aplicacin 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 animacin (en el caso del ttulo El espaol en el
mundo), se abre una ventana modal con la definicin de un trmino (vase
la palabra resaltada mensajes y la ventana modal abierta) o se traslada al
usuario a una nueva pgina 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 clasificacin de conceptos y a la identificacin, respectiva-
mente. Mientras en el primer caso el usuario puede arrastrar alimentos para
incluirlos en la categora 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 programacin basada en eventos.
FIGURA 9.5. Un ejercicio de clasificacin en Now-Graduado

FIGURA 9.6. Un ejercicio de identificacin en Now-Graduado
9.2. EJEMPLO DE EVALUACIN DE LA USABILIDAD

Otra fase bsica del desarrollo de sistemas multimedia o hipermedia es la
evaluacin, pues permite mejorar la utilidad del producto final. En esta sec-
cin, se muestra cmo se llev a cabo la evaluacin de CESAR (Aedo y otros,
1995), un entorno de aprendizaje hipermedia destinado a ayudar a nios con
deficiencias auditivas a conseguir la competencia necesaria en los lenguajes
gestual y escrito. Este sistema inicia al nio 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 (Daz
y otros, 1996) en la que se pueden ver tres componentes bsicos: una biblio-
teca de libros, un conjunto de elementos perifricos y los estilos de aprendi-
zaje del usuario.
El eje central son los libros que se encuentran en una biblioteca (o libre-
ra) y que estn 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 categora 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 nio puede pegar aquellas
cosas que desee o crear otras nuevas haciendo uso de un estuche. Para finali-
zar esta breve descripcin del sistema, la figura 9.8 muestra una pgina del
cuento en la que, como puede verse, se adopta la metfora del libro tradicio-
nal aumentada con ciertas posibilidades del entorno electrnico.
La aplicacin se desarroll con Hypercard y desde el principio se consi-
der bsico realizar una evaluacin 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 continuacin.
9.2.1. Definicin del objetivo de la evaluacin

Los objetivos de esta evaluacin, que se encuentra documentada en (Aedo
y otros, 1996), pueden resumirse en dos:
Analizar si los nios pueden beneficiarse de los cuentos electrnicos, el
hipertexto y la multimedia durante el aprendizaje.
FIGURA 9.8. Una pgina de un cuento de CESAR.
Examinar si el sistema ayuda a los nios sordos a adquirir la necesaria

competencia en los lenguajes signado y escrito.
9.2.2. Seleccin de la tcnica de evaluacin

Se aplic la tcnica de evaluacin denominada Jogthrough, variante del
Walkthrough, que permite estudiar la utilidad de un sistema en proceso de
diseo, como era el caso de CESAR. De acuerdo con esta tcnica, se estable-
ce un conjunto de tareas que se pueden realizar con el sistema y que permi-
ten conseguir algn objetivo de los que se quieren evaluar. Cada tarea se des-
compone en una o ms acciones. Varios expertos evalan dichas tareas con
un cuestionario y se utiliza tambin software de registro y grabacin en
vdeo. Durante la evaluacin participan cuatro tipo de actores, recogidos en
la tabla 9.2.
TABLA 9.2. Actores involucrados en la tcnica de evaluacin Jogthrough

Actor Responsabilidades
Presentador Describe la tarea a evaluar.
Ejecuta las acciones que conlleva esa tarea e identifica caminos alter-
nativos.
Evaluador Enfoca la descripcin del presentador.
Responde a las cuestiones que se le hacen.
Moderador Conduce la reunin, manteniendo el foco de atencin.
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 evala con el cuestionario.
El Presentador introduce el objetivo de la tarea.
El Presentador indica la primera accin a realizar.
Los evaluadores identifican problemas de la interfaz en funcin del
porcentaje de usuarios que tendrn problemas.
Se pasa a la siguiente accin 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 mtodo sugestivo y eficiente para evaluar un siste-
ma no terminado como era el caso de CESAR.
9.2.3. Preparacin de la evaluacin

Durante la preparacin de la evaluacin, 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.
Adems, este ensayo permiti refinar el nmero y tipo de evaluadores que
deberan 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 evaluacin de CESAR.
9.2.4. Realizacin de la evaluacin

Al iniciarse la sesin de evaluacin de CESAR, el presentador describi
tanto la tcnica 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 introduca la tarea o la accin a realizar.
El Moderador haca las preguntas oportunas.
Se invitaba a los evaluadores a entablar un coloquio y a dar una pun-
tuacin entre 0 y 3 en las preguntas cerradas.
Se emple software de registro y una cmara de vdeo.
FIGURA 9.10. Tareas realizadas durante la evaluacin de CESAR.
FIGURA 9.11. Ejemplo de descomposicin de tareas en actividades

9.2.5. Elaboracin de los resultados

Una vez finalizada la sesin de evaluacin era preciso analizar los resul-
tados para extraer conclusiones sobre la medida en que los objetivos plantea-
dos se haban satisfecho.
En las preguntas cerradas se calcul la media por tarea de la agregacin de
las respuestas de todos los evaluadores (vase como ejemplo la parte superior
de la figura 9.12). Tambin se estudi la media por evaluador, dado que su dis-
tinta formacin y experiencia poda hacer ms o menos relevante su juicio.
Por ejemplo, las opiniones del logopeda y del pedagogo en las cuestiones rela-
cionadas con actividades de aprendizaje podran ser ms fundadas que las del
desarrollador del software, si bien las de este ltimo tampoco son desdeables.
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 podran realizarse.
En conclusin, puede decirse que se trat de una experiencia muy posi-
tiva en la que se recogieron opiniones de personas que no pertenecan al
grupo de desarrollo y que, adems, tenan una perspectiva del producto
muy distinta, lo cual permiti mejorar la interfaz del sistema y contar con
una cierta evidencia emprica sobre la posible utilidad de CESAR.
9.3. RESUMEN
En este captulo se han ilustrado las fases del desarrollo de un pro-

ducto multimedia a travs de dos ejemplos. En el primero, Now-Gradua-
do, se ha presentado cmo realizar el anlisis de requisitos y el diseo,
tanto el conceptual y como el de la interfaz de usuario, hacindose hinca-
pi en el hecho de que siempre puede aplicarse un enfoque sistemtico.
En el segundo se ha ejemplificado el proceso de evaluacin de un produc-
to, describiendo las distintas actividades a realizar a travs de la evalua-
cin de CESAR.
9.4. EJERCICIOS DE AUTEVALUACIN
9.1. En el anlisis 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) Slo se estudian las caractersticas de los usuarios, porque el funcio-
namiento de la aplicacin se analiza durante la fase de diseo.
d) Se puede realizar utilizando la tcnica denominada Jogthrough.
9.2. Seale las afirmaciones que considere ciertas con respecto al proceso de
desarrollo de un sistema multimedia:
a) No se puede realizar el anlisis ni el diseo si hay un plazo de entre-
ga establecido.
b) El diseo conceptual no debe ser independiente de la plataforma de
implementacin.
c) No se pueden usar prototipos de usar y tirar si se sigue un enfoque

sistemtico.
d) El diseo conceptual puede simultanearse con el uso de prototipos.
9.3. En la evaluacin de CESAR:

a) Se utiliz Jogthrough porque es una tcnica de evaluacin analtica.
b) Se utiliz Jogthrough porque es una tcnica de evaluacin emprica.
c) Se utiliz Jogthrough porque estaba en fase de diseo.
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 acceda al sistema.
b) Se emple un modelo de referencia de hipermedia para realizar un
diseo conceptual del producto.
c) El diagrama estructural inclua enlaces y nodos.
d) El anlisis no se llev a cabo por no considerarse de utilidad.
9.5. En la tcnica utilizada para evaluar CESAR:

a) Los evaluadores son usuarios reales.
b) Se ejecutan acciones que se descomponen en tareas.
c) Se analizan slo las caractersticas 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. Pgs. 63-68.
AEDO y otros (1996): I. Aedo, N. Catenazzi y P. Daz. The evaluation of a Hypermedia
Learning Environment: The CESAR experience. Journal of Educational Multime-
dia and Hypermedia, 5 (1). Pgs. 49-72.
Ed. Rama, Madrid.
DAZ y otros (2001a): P. Daz, I. Aedo y Fivos Panetsos. Modeling the dynamic behavior
of hypermedia applications. IEEE Transactions on Software Engineering, vol 27
(6), Junio. Pgs. 550-572.
DAZ y otros (2001b): P. Daz, I. Aedo y S. Montero. Ariadne, a development method for
hypermedia. Dexa 2001. LNCS 2113. Pgs. 764-774.
LPEZ-REY y otros (1999): A. Lpez-Rey, F. Panetsos, M. Castro y J. Peire. Utilizacin

del modelo Labyrinth en el diseo de la aplicacin Now-meta. Congreso Nacional
de Informtica Educativa (CONIED99). Puertollano, Espaa, 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). Pgs. 389-395.

Captulo 10
ARQUITECTURA Y CONFIGURACIN
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 especfico para aplicaciones multimedia.
10.6. Diseo arquitectnico para sistemas multimedia.
10.7. Resumen.
El trmino arquitectura, en su segunda acepcin, segn el Diccionario
de la Real Academia Espaola, hace referencia a la estructura lgica y fsica
de los componentes de un computador. Sin embargo, esta definicin slo
tiene en cuenta la disposicin de los elementos de un hipottico ordenador
aislado. Hoy en da se habla, en trminos ms amplios, tanto de arquitectu-
ra software como de arquitectura hardware, y tambin 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 caractersticas fsicas de los ordenadores que
se utilizan para la ejecucin de esos programas. La arquitectura de red, que
atae a las dos anteriores, y en ocasiones se considera como parte de ellas,
describe la configuracin de las interconexiones entre las mquinas, que
sern 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 descripcin de la disposicin o estructura de los componentes
hardware y software interconectados que conforman una aplicacin multi-
media determinada.
En este captulo, se introducirn los elementos arquitectnicos ms

importantes desde el punto de vista de las aplicaciones multimedia. Se debe
tener en cuenta que la caracterizacin de estos sistemas no reside meramen-
te en el soporte de ms de un tipo de medio ya que, desde ese punto de vis-
ta una aplicacin con texto e imgenes sera multimedia, sino en determi-
nadas propiedades relacionadas con la combinacin de varios de esos
medios. Ms concretamente, y siguiendo la descripcin que se propone en
(Steinmetz y Nahrstedt, 1995), estas propiedades sern: la combinacin a
partir de soportes independientes de medios discretos como las imgenes,
con medios continuos, como el sonido o el vdeo; su integracin y sincroni-
zacin; y la posibilidad de distribuirse por una red de ordenadores.
Se expondrn primero los aspectos generales de las diferentes partes

que configuran la arquitectura de este tipo de sistemas, para terminar con
algunas nociones bsicas sobre cundo y de qu modo debe integrarse el
diseo arquitectnico 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-
cin que organiza la navegacin en la pgina 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 debern 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 ESPECFICO PARA LA MULTIMEDIA
SERVIDORES DE SISTEMAS DE GESTIN

DISTRIBUCIN DE BASES DE DATOS
MULTIMEDIA MULTIMEDIA
SOFTWARE DEL SISTEMA OPERATIVO
SOFTWARE DE GESTIN DE
GESTIN DE PROCESOS RED PARA LA DISTRIBUCIN
MULTIMEDIA
HARDWARE
ARQUITECTURAS DE
DISPOSITIVOS
COMPUTADOR
MULTIMEDIA
MULTIMEDIA
FIGURA 10.1. Arquitectura general de los sistemas multimedia.
La arquitectura hardware incluye los elementos fsicos que intervienen en

el funcionamiento de la aplicacin multimedia, incluyendo elementos proce-
sadores (ordenadores que ejecutan los programas) y dispositivos de entra-
ARQUITECTURA Y CONFIGURACIN DE LOS SISTEMAS MULTIMEDIA 287
da/salida (cmaras, monitores, sistemas de reproduccin de audio, sistemas

de almacenamiento masivo, etc.). En algunos casos, la arquitectura fsica de
los propios computadores proporciona facilidades especficamente pensadas
para la multimedia; un ejemplo muy conocido es el de los procesadores MMX
del fabricante Intel.
En el caso de que la aplicacin multimedia sea distribuida, a los procesa-
dores y dispositivos se le aadirn los elementos fsicos de la red (conexiones
que habilitan la comunicacin 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 mdulos que compo-
nen los sistemas operativos, hay dos partes fundamentales que es importante
tener en cuenta para las aplicaciones multimedia, adems, lgicamente, del
soporte para los dispositivos multimedia concretos que sean necesarios. El
primero de estos mdulos es el de planificacin o gestin de procesos, que en
ocasiones puede permitir un tratamiento especial de los procesos correspon-
dientes a aplicaciones multimedia en ejecucin, dotndoles de una prioridad
o reserva de tiempo de procesador adecuada para permitir la correcta ejecu-
cin de los mismos en tiempo real. En segundo lugar, existen sistemas opera-
tivos especializados que ofrecen servicios de transmisin de red especializa-
dos para datos multimedia.
La tercera capa del esquema general incluye a todos los programas espe-
cializados en el almacenamiento y difusin de datos multimedia. Entre ellos,
los sistemas de gestin de bases de datos especializados y los servidores de
difusin de datos multimedia son los ms utilizados en las arquitecturas exis-
tentes (estos ltimos se describen brevemente en el captulo 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 caracterstica especializada para la multimedia de las
que se han descrito. No obstante, en sistemas con requisitos de tiempo de res-
puesta o sincronizacin elevados, suele ser necesario el uso de elementos
especficos.
DEFINICIN: 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 construccin de
ese tipo de sistemas.
Esa arquitectura incluye elementos hardware, como procesadores o dispositivos
especializados, protocolos o sistemas de gestin de trfico de red especializados,
y software especfico para estos sistemas, como bases de datos o servidores de dis-
tribucin de datos especializados.
En el resto de este captulo, se describen algunos de los elementos de la

arquitectura general que se muestra en la figura 1, con el objetivo de propor-
cionar una visin general de los elementos que deben tenerse en cuenta al
realizar el diseo arquitectnico de un sistema multimedia.
10.2. DISPOSITIVOS Y ELEMENTOS HARDWARE

PARA APLICACIONES MULTIMEDIA
En la actualidad, existe hardware especfico 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 continuacin se describe una panormica de ambas categoras.
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 propsito 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 funcin
especfica Arquitecturas
Procesadores
multimedia programables
dedicados flexibles
Arquitecturas
Arquitecturas de programables
procesadores multimedia Arquitecturas
programables
adaptadas
Procesadores
de propsito
general
FIGURA 10.2. Taxonoma de las arquitecturas de procesadores para soporte multimedia.
Los procesadores dedicados estn orientados a ejecutar funciones espec-

ficas multimedia tales como la compresin y descompresin de vdeo y audio
o la visualizacin de aplicaciones grficas 2D y 3D. La eleccin de la arqui-
tectura del procesador est condicionada a requisitos tales como la velocidad

y potencia esperada de las funciones, las restricciones en la integracin de
circuitos y el coste. Atendiendo a la combinacin de estos parmetros se pue-
den seleccionar arquitecturas de funcin especfica o arquitecturas progra-
mables.
Las arquitecturas de funcin especfica, como AV6110 MPEG-2, son las

exclusivamente dedicadas a funciones multimedia. Se fabrican para la codi-
ficacin/decodificacin de un estndar concreto, por lo que no requieren ser
programables (o lo son minmamente). Esto hace que resulten altamente efi-
cientes y rpidas, pero poco flexibles. Adems los costes de produccin que
tienen asociados son ms 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 funcin especfica, y dentro de las arquitec-

turas dedicadas por completo a dar soporte especfico a aplicaciones multi-
media, existen tambin arquitecturas programables, que permiten manejar
ciertos cambios en los requisitos, como posibles extensiones del dominio de
la aplicacin, 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
mdulos dedicados a algunas tareas pertenecientes a la codificacin/decodi-
ficacin de vdeo. 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 ms eficientes a costa de perder
parte de esa flexibilidad.
De entre los procesadores de propsito general, algunos proporcionan un

conjunto de instrucciones multimedia dentro de su juego de instrucciones, de
manera que en lugar de ejecutar funciones especficas multimedia propor-
cionan las instrucciones para soportar operaciones genricas de procesa-
miento de vdeo, como las instrucciones de direccionamiento eficiente de
datos o el soporte de tipos de 8 bits (pxels), 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 ingls MultiMe-
dia eXtensions, extensiones multimedia) se han aadido 57 nuevas instruc-
ciones a las 200 disponibles en el Pentium que estn optimizadas para reali-
zar las operaciones ms frecuentes utilizadas en programas multimedia
como reproduccin de vdeo digital o grficos en tres dimensiones, e incluye
8 instrucciones de 64 bits. El procesador utiliza la tcnica de instruccin ni-
ca de datos mltiples (SIMD, Single Instruction Multiple Data), que permite
que el procesador acelere muchas tareas multimedia que necesitan usar cl-
culos intensivos gracias a la posibilidad de operar en paralelo diferentes
datos empaquetados.
DEFINICIN: Arquitectura de procesador para multimedia.

Existen arquitecturas de microprocesador que tienen en cuenta de manera explci-
ta el soporte de aplicaciones multimedia. Entre ellas se tienen procesadores multi-
media dedicados, y arquitecturas de propsito 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 informtico 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 informacin que las aplicaciones
puedan hacer a disco. Estas necesidades son todava ms acuciantes en siste-
mas multimedia, donde dicha recuperacin debe ser lo ms rpida posible
para que el usuario no perciba interrupciones o saltos en el proceso de los
datos. Todo esto, unido a las caractersticas singulares de los datos multime-
dia, como su tamao, su composicin formada por varias corrientes de datos
(audio, imgenes en movimiento, etc), la necesidad de recuperacin sncrona de
los datos de las corrientes, etc., ha hecho necesario no solo el estudio de nuevos
tipos de dispositivos de almacenamiento sino tambin el estudio de cmo orga-
nizar los discos y ubicar los datos en ellos.
Frente a las organizaciones de disco que se venan utilizando en discos
convencionales, como la grabacin con densidad variable (VDR, Variable
Density Recording), existen otras que permiten obtener mayor eficiencia en el
almacenamiento y recuperacin de datos multimedia, como la grabacin con
densidad constante (CDR, Constant Density Recording). En este formato de
disco las pistas se agrupan en zonas concntricas en las que la densidad de
grabacin 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 ms
alejadas del centro que en las ms internas. Esto es debido a que las llamadas
zonas externas (las ms alejadas del centro) tienen mayor dimetro y por lo
tanto contienen ms bits y sectores; puesto que el disco rota a una velocidad
angular constante, las cabezas de lectura y escritura recorren ms 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 ms sectores por pista que la mas
interna anterior, frente a organizaciones donde todas las pistas contienen el
mismo nmero de sectores fijo.
Cmo el controlador de disco ubique los datos en l una vez organizado
es tambin algo muy importante en las prestaciones de los sistemas multi-
media. Piensese que incluso en un disco de organizacin eficiente, si dos

objetos de datos que se solicitan siempre uno a continuacin de otro, por
ejemplo, una imagen y su sonido, se graban en zonas de disco muy alejadas
tardarn ms en recuperarse si se tiene en cuenta el tiempo de posiciona-
miento y la latencia de rotacin, que si estn situados en posiciones fsicas
contiguas. Existen muchas tcnicas para realizar esta ubicacin en disco y
cada una de ellas afecta de una manera u otra las prestaciones del disco. A
continuacin se enumerarn algunas de las ms significativas para situar los
datos multimedia en un solo disco:
Ubicacin contigua intercalada (interleaved). A la hora de ubicar los
datos multimedia en disco hay dos posibilidades bsicas. 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 lmites desea-
bles en tiempo de posicionamiento y latencia para acceder a una
secuencia de vdeo o audio continua, o bien colocar los bloques de
manera contigua para garantizar este acceso continuo, lo que tambin
tiene problemas inherentes de fragmentacin as como grandes gastos
de copia en la insercin y borrado. La tcnica de ubicacin contigua
intercalada (Rangan y Vin 1993) permite alcanzar una solucin 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 tambin 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 quedaran los bloques de medios en el soporte:
G G N N N
M1 M M2 M2 M3 M M4 M M5 M M6 M
M1 M2 M3 M4 M5 M6
FIGURA 10.3. Ubicacin 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.
Ubicacin basada en frecuencia. Esta tcnica (Chen y Thapar, 1996)

se utiliza sobre discos organizados mediante grabacin 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 caractersticas, se pueden situar fsicamente los datos que ms
frecuentemente se acceden en las zonas ms exteriores del disco, pues-
to que su velocidad de transferencia es ms alta, dejando las zonas
internas para datos que no se acceden con tanta frecuencia, tal y como
se muestra en la figura 10.4.
... Vn
Vm V1
... V1
V2
... V2
V3
...
...
...
FIGURA 10.4. Ubicacin basada en frecuencia.
Suponiendo que los datos de la secuencia V son aquellos que ms a

menudo se acceden ,en la figura 4 se puede observar cmo dicho flujo
Vi se sita en la zona externa de un disco CDR, ubicndose el resto de
los datos en zonas consecutivas hacia el interior del disco segn su fre-
cuencia de acceso los datos del flujo V sern los siguientes ms acce-
didos y as sucesivamente.
Ubicacin balanceada de carga. Con este mtodo de ubicacin se
pretenden optimizar las prestaciones de discos con grabacin con den-
sidad constante atendiendo al ancho de banda y tamao 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 respondern ms rpidamente, evi-
tando que se encolen muchas peticiones a disco y mejorando por lo
tanto las prestaciones del sistema.
Si bien se han expuesto tcnicas de ubicacin 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 mltiples discos
e incluso en sistemas de almacenamiento jerrquico (Leung y Tse, 1999),
aunque la correcta eleccin de una ubicacin de los datos intra-disco es fun-
damental para el xito de las dems organizaciones.
10.3. SOPORTE MULTIMEDIA EN LOS SISTEMAS OPERATIVOS
Los sistemas operativos tienen como misin principal la gestin eficiente

del hardware, proporcionando a las aplicaciones unas interfaces de ms alto
nivel. Las aplicaciones multimedia demandan la integracin 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 gestin de procesos del sistema operativo, que debe extenderse
con el concepto de reserva de recursos previa a la ejecucin.
Como se ha expuesto, los sistemas multimedia tienen ciertos requisitos
tpicos de un sistema en tiempo real en cuanto a la integracin y procesa-
miento de datos, si bien hay que considerar que dichos requisitos son menos
estrictos que en los sistemas en tiempo real tpicos con tiempos lmite (dead-
line) estrictos y cuyo vencimiento tendra consecuencias catastrficas. Con-
cretamente, los sistemas multimedia tienen requisitos de tiempo real distin-
tos de los sistemas tpicos (Steinmezt y Nahrstedt, 1995):
La tolerancia a fallos suele ser menos estricta que en aquellos sistemas
en tiempo real que tienen impacto fsico directo, aunque existan deter-
minadas aplicaciones, como las operaciones quirrgicas donde el cum-
plimiento de los requisitos de recuperacin del sistema han de ser muy
rigurosos.
El cumplimiento de los tiempos lmites no suele ser tan crucial, aunque
por supuesto debe ser evitado, sobre todo en lo que al audio respecta.
Este tipo de tiempos lmites se conoce en sistemas de tiempo real como
tiempos lmites 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
catastrficos.
Las tareas crticas que se deben planificar en los sistemas multimedia
son peridicas, puesto que responden al procesamiento de una secuen-
cia de datos digital continua, y este tipo de planificacin es ms senci-

lla que la de tareas espordicas, 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 negociacin, ajustndo-
se dinmicamente.
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 gestin 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 planificacin 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 ubicacin de los datos, si el subsistema del sistema opera-
tivo que se encarga de planificar la CPU no realiza una buena gestin las peti-
ciones pueden sufrir retrasos que interrumpan el procesamiento y planifica-
cin de otros recursos del sistema. En lo que resta de apartado se veran las
polticas de los sistemas multimedia para planificar las tareas de CPU.
Los sistemas operativos ms habituales que pueden procesar datos multi-
media, por ejemplo Unix SVR4, utilizan algoritmos de planificacin de la
CPU basados en colas multinivel donde los procesos son servidos con polti-
cas round-robin. En ellas los procesos pueden cambiar de nivel y de prioridad
de manera dinmica, por ejemplo si tienen una actividad intensa de entra-
da/salida o si, por ejemplo, se quedan dormidos por ms de un segundo.
Esta poltica hace que en principio las aplicaciones tpicas multimedia pue-
dan mantener su prioridad, pero otros procesos de menor prioridad acabarn
eventualmente llegando a los niveles de prioridad superiores de manera que
la presencia de una prioridad para un proceso multimedia no garantiza un
tiempo mnimo de ejecucin por unidad de tiempo que asegure la calidad de
la reproduccin.
Uno de los algoritmos de planificacin de CPU ms utilizados para siste-
mas multimedia (y por extensin en los sistemas de tiempo real) es el algo-
ritmo rate monotonic (Liu y Layland, 1973). La planificacin tiene unos pre-
rrequisitos muy claramente definidos, que dadas las caractersticas de los
datos multimedia, hacen que el algoritmo sea especialmente adecuado para
el procesamiento de este tipos de informacin. Dichos prerrequisitos consis-
ten bsicamente en que:
1. Todas las peticiones que soliciten las tareas y que tengan tiempo lmi-
te deben producirse a intervalos regulares (peridicamente). Solamen-
te pueden ser aperidicas las peticiones sin tiempo lmite.
2. Los tiempos lmites slo deben implicar restricciones en cuanto a que
una tarea debe ser acabada antes de que la siguiente peticin tenga
lugar.
3. Las tareas son independientes.

4. El tiempo de ejecucin de cada proceso es constante.
Rate monotonic realiza una asignacin de prioridades esttica (lo que vie-
ne a evitar algunos problemas de otras polticas de planificacin ya expues-
tas) en funcin del periodo de la tarea: a periodo de peticin ms corto o lo
que es lo mismo: mayor frecuencia de peticiones mayor prioridad. El com-
portamiento bsico 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 ms frecuente, se le asigna mayor prioridad.
Otro aspecto que merece la pena destacar es el tiempo lmite 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 peticin del mismo proce-
so (obsrvese que los tiempos lmites del proceso 2 son ms amplios que los
del proceso 1 puesto que su periodo es tambin mayor). La CPU se asigna por
prioridad de la tarea, por lo que puede ser expropiada cuando llega una peti-
cin 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 lmite
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 bsico del algoritmo rate monotonic.
Existe una generalizacin del algoritmo de planificacin rate monotonic

conocida como deadline monotonic (Leung y Whitehead, 1982) que es vlido
para procesos cuyos tiempos lmites no son iguales al periodo de la peticin.
En este caso, las prioridades son asignadas de acuerdo a dichos tiempos
lmites.
Los algoritmos previamente comentados son aplicables para sistemas en

tiempo real estrictos, pero cmo realizan la planificacin de la CPU los sis-
temas multiservicio? Un ejemplo de cmo realizar la poltica de asignacin
de CPU en este tipo de sistema es la que sigue el sistema operativo QLinux
Multimedia (Sundaram et al, 2000). La planificacin 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 creacin de clases de pro-
cesos donde se asignan prioridades fijas (Schulzrinne, 1999). Esto tiene a su
vez como inconveniente que algunas tareas de prioridad ms bajas que las
que se tienen que ejecutar en tiempo real pueden morir de inanicin. 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 funcin 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 dinmico de los recursos.
10.4. BASES DE DATOS MULTIMEDIA

Los sistemas de gestin de bases de datos (SGBD) son programas especia-
lizados en proporcionar servicios de almacenamiento persistente y consulta
de informacin, soportando grandes volmenes de datos. De esta manera, las
aplicaciones delegan los servicios de almacenamiento y consulta en los
SGBD, que proporcionan estructuras para hacer ms uniforme y eficiente el
acceso a los datos. En las aplicaciones multimedia, los datos son de naturale-
za muy heterognea, lo cual requiere de un tratamiento especializado. Esta
especializacin es lo que ha dado lugar a los sistemas de gestin de bases de
datos multimedia (SGBDM), que, adems de los servicios habituales de un
SGBD, deben cumplir con una serie de requisitos especficos:
Almacenamiento de diferentes tipos de informacin en formatos
diversos. Cada tipo de informacin (audio, vdeo) posee unas caracte-
rsticas especiales, que requieren de una poltica de almacenamiento
distinta, con diferentes formatos de almacenamiento posibles. Adems,
en ocasiones los datos estn distribuidos en diferentes dispositivos de
almacenamiento secundario, por ejemplo, en CDROMs y en discos
magnticos, y es el gestor el que se encarga de proporcionar un acceso
uniforme.
Soporte de modelos de datos especficos. Los diferentes tipos de
datos deben especificarse mediante modelos de datos que sean lo sufi-
cientemente ricos como para expresar sus caractersticas especiales.
Por ejemplo, la dimensin temporal en el caso del vdeo no est direc-
tamente soportada en los modelos de datos actuales, como el modelo
relacional. El modelo de la orientacin a objetos proporciona un sopor-

te adecuado, si se utiliza como marco para crear un modelo de datos
multimedia especfico (Atarais y Hamakaw, 1999).
Mtodos de bsqueda especficos. La bsqueda de imgenes, soni-
dos u otros tipos multimedia est relacionada con el contenido de las
mismas (Heller y Martin, 1999), de modo que se deben proporcionar
mtodos de bsqueda y de indexacin para la bsqueda acordes
con las mismas, adems de los mtodos de consulta convencionales.
Independencia del formato. Las interfaces de bsqueda deben ser
capaces de buscar en un medio determinado como el sonido, indepen-
dientemente de la tcnica de codificacin del mismo que se est utili-
zando para sonidos determinados. Adems, las interfaces de progra-
macin deben ser independientes del tipo multimedia, aunque si el
programador lo considera oportuno para una situacin concreta,
deben permitir acceder a los detalles concretos de un formato.
Transferencia de datos en tiempo real. Los tipos multimedia conti-
nuos como el vdeo requieren de operaciones de almacenamiento y
recuperacin especialmente largas, cosa que debe tener en cuenta el
gestor.
Acceso simultneo 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 informacin deben ser
controladas por el gestor.
Consistencia en los datos. La consistencia en los datos multimedia
tiene aspectos especficos que deben tenerse en cuenta. Entre ellos cabe
citar, siguiendo la terminologa 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 informacin sobre la entidad pjaro, 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 vdeo.
Las relaciones de composicin 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 vdeo sincronizadas con el
texto.
Las relaciones de substitucin proporcionan diferentes representacio-
nes equivalentes de una misma informacin. Por ejemplo, un resulta-
do estadstico puede proporcionarse como tabla de datos, como grfi-

ca e incluso como grfica animada mostrando diferentes aspectos.
Las relaciones de sincronizacin describen relaciones temporales
entre diferentes datos multimedia. Un ejemplo tpico es la sincroni-
zacin de audio y vdeo en una presentacin.
DEFINICIN: Bases de datos multimedia.

Las bases de datos multimedia estn especializadas en el tratamiento de grandes
volmenes de datos de tipos con caractersticas distintas. Proporcionan mecanis-
mos para la descripcin de los datos multimedia, as como para el establecimien-
to de relaciones entre elementos de diferentes tipos.
Adems de esas caractersticas, los SGBDM deben estar especialmente

preparados para el almacenamiento de grandes volmenes de datos, ya que
la informacin multimedia en muchos casos ocupa ms espacio de almace-
namiento. Es importante resaltar que muchos de los SGBD relacionales
comerciales ms 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 especfico. Todas las carac-
tersticas mencionadas han dado lugar a la consideracin de una arquitectu-
ra especfica 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 Edicin Herramientas de

de navegacin Consultas multimedia administracin
Capa de integracin multimedia
Composicin multimedia Procesamiento de consultas
SGBD Texto SGBD Imgenes SGBD Audio SGBD Video
Texto Imgenes Audio Video
FIGURA 10.6. Arquitectura de referencia de un sistema de gestin de bases de datos multimedia.

En esta arquitectura se puede ver cmo el almacenamiento de cada tipo

de datos tiene su propio sistema de almacenamiento y recuperacin, integra-
dos mediante un lenguaje de consultas comn a todos ellos, y una interfaz
que permite expresar las relaciones entre diversos tipos que son inherentes a
la multimedia. Adems, estos gestores cuentan con herramientas de edicin,
administracin y consulta adaptadas a las caractersticas especiales de las
combinaciones de tipos de datos.
10.5. REDES CON SOPORTE ESPECFICO

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 caractersticas 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 transmisin (Steinmetz y
Nahrstedt, 1995) derivados de sus caractersticas inherentes:
1. Las peticiones de datos son sensibles en el tiempo, y, como ya se ha
dicho, estn acotadas por tiempos lmite. Esto implica, por ejemplo,
que los retrasos en la transmisin entre fuente y destino estn acota-
dos en el tiempo, as como que la variacin de los mismos sea baja.
2. Alto trfico de salida, puesto que el vdeo y el audio se transmiten
como flujos que suelen ser de larga duracin y suelen tener grandes
variaciones de volumen respecto al tiempo.
3. Se necesitan garantas de servicio, es decir, que los servicios de proce-
samiento y comunicacin deben estar garantizados durante todo el
tiempo que dure la comunicacin, lo que en ocasiones se ve dificulta-
do dadas las diferentes formas de trfico de red producidas por apli-
caciones multimedia heterogneas.
4. Se necesita no solo cierta fiabilidad en la transmisin, 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 heterogneos e incluso dependen del
tipo de aplicacin multimedia que los solicite se han llegado a parametrizar.
Esta parametrizacin 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 organizacin de
estndares (ISO) a estandarizado estos parmetros a travs de la nocin de
calidad de servicio (QoS quality of service en ingls) (Nahrstedt, 1999).
DEFINICIN: Calidad de servicio (QOS).

Segn ISO, la calidad de servicio es el concepto que especifica cun buenos son
los servicios de red ofrecidos a una aplicacin, multimedia en nuestro caso.
La calidad de servicio se mide de acuerdo a lo que la aplicacin necesita de los
servicios de red, que viene especificado mediante parmetros concretos estandari-
zados cuyo valor se puede negociar entre ambas partes.
Obviamente, no todas las redes estn preparadas para soportar transmi-

siones multimedia con las garantas necesarias. Disear redes sobre las que
realizar estas transmisiones ha supuesto un gran reto en los ltimos aos, del
que han surgido distintas aproximaciones (Sharda, 1999) como las redes
ATM. Pero en la red Internet, los esfuerzos hoy en da se centran en el proto-
colo de presentacin 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 adems no
resulta apropiado para realizar multidifusin (multicasting). RSTP surge
como protocolo para paliar estas deficiencias.
RSTP (Schulzrinne, 2003) es un protocolo de control para presentacin
multimedia cliente-servidor diseado para soportar el envo 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 diseado para trabajar con flujos
de datos con restricciones temporales. Adems, 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 envo en multidifusin de flujos, sin perder la posibilidad de
mantener soluciones hbridas multidifusin-unidifusin. Estas caractersti-
cas hacen que actualmente se est utilizando para transmisiones por Internet
de vdeo bajo demanda donde no es necesario descargar todo el fichero para
poder visualizarlo, sino que mediante una aplicacin de cliente se puede rea-
lizar el tpico control de vdeo (pausa, rebobinar, avanzar y posicionamiento
absoluto) sobre datos multimedia almacenados en servidores.
10.6. DISEO ARQUITECTNICO PARA SISTEMAS MULTIMEDIA
El diseo arquitectnico es una actividad de Ingeniera del Software

cuyo propsito es obtener una descripcin de alto nivel de los elementos
hardware y software del sistema proyectado, as como de las relaciones entre

los mismos. Esta descripcin o arquitectura establece las lneas maestras del
futuro sistema, y permite la construccin de prototipos arquitectnicos
para probar tempranamente el sistema como concepto. Los elementos bsi-
cos que deben describirse en una arquitectura son de dos tipos: hardware y
software. Los primeros incluyen la configuracin de los procesadores (orde-
nadores personales, servidores, dispositivos en general) y su interconexin
(arquitectura de red). Los segundos incluyen las aplicaciones que conforma-
rn el sistema (que pueden ser ms de una, como en el caso de los sistemas
cliente-servidor), los componentes y/o software comercial que se utilizarn
(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 diseo de la
arquitectura software est ntimamente relacionado con otras actividades del
ciclo de Ingeniera. La figura 10.7 muestra estas relaciones.
Requisitos, cualidades deseadas Restricciones
ANLISIS DE
REQUISITOS Y DISEO DE LA
MODELADO DEL DISEO DE LA
ARQUITECTURA SOFTWARE ARQUITECTURA
DOMINIO HARDWARE
Arquitectura Software
Restricciones de implementacin
DISEO DETALLADO,
CODIFICACIN, INTEGRACIN y
PRUEBA
FIGURA 10.7. Relacin del diseo arquitectnico con otras actividades del desarrollo.
As, el anlisis de requisitos y el modelo del dominio de la aplicacin

determinarn los bloques constitutivos bsicos de la arquitectura software
necesaria. Por ejemplo, en sistemas colaborativos se deber determinar la
existencia de aplicaciones que acten 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 tambin se requerir un dimensio-
namiento de la capacidad de proceso de cada uno de los nodos hardware que
conformen la aplicacin. Actualmente, el diseo arquitectnico suele ir
acompaado de la implementacin de un prototipo arquitectnico, que no es
otra cosa que una aplicacin en la cual se ejercitan todos los elementos dis-
puestos en la arquitectura, pero cubriendo slo alguna funcionalidad simple
de las requeridas. Este prototipo permite llegar a un buen nivel de detalle en
el diseo de la arquitectura hardware, y sirve tambin para probar la eficacia
de las posibles herramientas de autora u otros mdulos software (bases de
datos, servidores de streamming) antes de comprometer los recursos de desa-
rrollo con una tecnologa concreta. En el caso de que nuestra aplicacin
requiera la distribucin masiva de multimedia a travs de una red de ordena-
dores, es fundamental realizar un test de carga para probar la capacidad de
los servidores de distribucin y tambin las condiciones de trfico de red
necesarias para llegar a una calidad de visualizacin ptima.
Adems, cuando a partir de la arquitectura software se comienzan las
actividades de diseo detallado y codificacin una vez seleccionadas las
herramientas de construccin necesarias podrn aparecer nuevos requisi-
tos de ndole no funcional que no estaban previstos inicialmente, y que
supondrn modificaciones a la arquitectura original de manera iterativa.
DEFINICIN: Diseo arquitectnico de sistemas multimedia.

El diseo arquitectnico es una actividad de Ingeniera del Software posterior al an-
lisis de requisitos y previa a la implementacin del sistema, cuyo objetivo es determi-
nar la estructura de alto nivel del software, as como la configuracin del hardware y
de los elementos de red necesarios para la aplicacin dada. En muchas ocasiones, el
desarrollo de un prototipo arquitectnico es el mejor medio para la determinacin de
esos aspectos generales de la aplicacin.
10.7. RESUMEN
La arquitectura de un sistema multimedia es la disposicin de los ele-

mentos hardware y software as como la distribucin en red de los mis-
mos para conseguir la funcionalidad y la calidad de ejecucin requeridas
para la aplicacin concreta.
Entre los elementos hardware, se dispone de procesadores especficos 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 planificacin que permiten dar un mejor ren-
dimiento para cargas de proceso tpicas de la multimedia, y existen protoco-

los de red especializados para la distribucin eficiente de la multimedia.
Tambin el almacenamiento y recuperacin 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 seleccin de los elementos arquitectnicos descritos depende de los
requisitos funcionales y no funcionales de la aplicacin multimedia que se
est considerando construir. Por ello, la actividad de diseo arquitectnico
toma una especial relevancia en este tipo de aplicaciones, dada la gran
variedad de elementos software y hardware especficos disponibles para
ellas.

10.1. Qu afirmacin es correcta en lo referente a arquitecturas genricas
de aplicaciones multimedia?:
a) La parte de servicios de transmisin 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 especfico de soporte y la aplicacin en s.
c) La capa hardware de la arquitectura de una aplicacin multimedia
debe incluir un elemento que sea un procesador con soporte espec-
fico multimedia.
d) Una aplicacin multimedia se puede ejecutar sobre una arquitectu-
ra convencional (sin ninguna caracterstica especializada para la
multimedia).
10.2. Qu caracteriza a los procesadores de propsito general frente a los

procesadores multimedia dedicados?
a) Su flexibilidad.
b) Su eficiencia.
c) Que no se pueden programar.
d) Ningn procesador de propsito general puede ser utilizado para
ejecutar aplicaciones multimedia.
10.3. Qu tcnica de ubicacin de datos multimedia en disco optimiza la

recuperacin de flujos que deben procesarse juntos?
a) La grabacin con densidad constante.
b) La ubicacin balanceada de carga.
c) La ubicacin basada en frecuencia.

d) La ubicacin contigua intercalada.
10.4. Cul de los siguientes requisitos derivados de las caractersticas 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 trfico de salida no es significativo.
b) El trfico de red es homogneo.
c) Los retrasos en la transmisin 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 distribucin de datos

multimedia?
a) El procolo RSTP permite el envo fiable de datos.
b) El protocolo RSTP permite realizar transmisiones bajo restriccio-
nes temporales.
c) El protocolo RSTP soporta tanto unidifusin como multidifusin.
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 Vdeo
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.

Captulo 11
INTEGRACIN 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 fenmeno social trans-
formador como indica Castells (Castells, 2001) debido a su universaliza-
cin progresiva y al creciente uso de la World Wide Web como medio de
comunicacin. La estructura bsica de esta Web, complementada con la tec-
nologa multimedia, amplifican sus capacidades respectivas, ya que la pri-
mera permite una mejor distribucin y una mayor disponibilidad para los
contenidos multimedia, y a su vez, estos contenidos permiten una interac-
cin ms 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 ms costosos, como la distribucin por CD-
ROM, y adems, 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 tambin
una problemtica totalmente nueva. Esta problemtica es esencialmente
relativa al ancho de banda de la red, ya que la distribucin masiva de multi-
media aumenta considerablemente el consumo de recursos de red necesarios
para su difusin, y en consecuencia, aumenta tambin el tiempo de latencia
general de la red. El origen de esta disfuncin est en que los protocolos de
red en los que se basa Internet no fueron originariamente pensados para la
distribucin masiva de multimedia. Para solventar este problema, en los lti-
mos aos han aparecido tecnologas concretas para la multimedia en la Web,
como el formato SWF que utilizan las animaciones Flash, se han desarrolla-
do tcnicas de difusin especficas como el streamming, y tambin se han
propuesto nuevos protocolos para la mejora de la red, como el protocolo
IPv6, que considera la difusin multimedia como uno de sus requisitos fun-
damentales.
En este captulo se ofrece una visin general de los sistemas multimedia
en Web, comenzando por una revisin de la arquitectura general Web, y su
adecuacin para los sistemas multimedia, pasando despus a detallar cmo
se integra los sistemas multimedia en las aplicaciones Web. Se termina con
una revisin de algunos de los tipos de aplicaciones multimedia ms relevan-
tes en este entorno.
11.1. LA ARQUITECTURA WEB Y LOS SISTEMAS MULTIMEDIA

En esta seccin se ofrece una sntesis de la arquitectura general Web, para
pasar a discutir su adecuacin para la distribucin 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 informacin accesible universalmente, que utili-
za el lenguaje de marcas Hypertext Markup Language (HTML) como medio
fundamental de estructuracin. Este lenguaje hace que la Web conforme un
sistema hipermedia. Los sistemas hipermedia (Daz, Catenazzi y Aedo, 1996)
son sistemas que combinan las caractersticas del hipertexto y la multimedia.
El hipertexto se basa esencialmente en la estructuracin 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-
terstica fundamental, la no linealidad o secuencialidad de los contenidos,
gracias a la navegacin habilitada por los enlaces. Cuando los contenidos pue-
den ser de diferentes tipos, incluyendo tipos continuos como el vdeo o el
audio, con sus posibles relaciones de sincronizacin, 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).
DEFINICIN: 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 inclusin y combina-
cin de contenidos de diferentes tipos continuos o no, en una estructura formada
por nodos y enlaces.
Ms adelante aparecern algunas limitaciones del lenguaje HTML para la

multimedia, y cmo han tratado de suplirse con tecnologas complementarias.
De momento, es importante tener claro que la Web es un tipo concreto de sis-
tema hipermedia con unas caractersticas concretas; existen otros, muchos de
carcter experimental, que proporcionan funcionalidades ms ricas que la
Web, como por ejemplo Microcosm (Hall, Davis, y Hutchings, 1996). Para cla-
rificar la nocin de hipermedia que implica la Web, a continuacin se muestra
un ejemplo muy bsico de estructura hipermedia construida en la Web.
La figura 11.1 muestra una representacin grfica conceptual de un sitio
Web muy simple, con tres pginas HTML (tres nodos), y seis enlaces, tres de
ellos conectan pginas HTML unas con otras, otro conecta dos partes de la
misma pgina, un quinto conecta una pgina HTML con un vdeo en forma-
to MPEG, y el sexto es la inclusin de una imagen en formato JPEG en la
INTEGRACIN DE LOS SISTEMAS MULTIMEDIA EN WEB 311
pgina HTML principal. Esta pgina es un ejemplo de una pgina personal

(homepage, segn la jerga comn 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 (ntese que se ha optado por simplificar al
mximo su estructura para enfatizar slo los elementos que se muestran en
la figuras 11.2, 11.3 y 11.4).
<html>
<head>
<title>Pgina principal</title>
</head>
<body>
<p>
<h1>Pgina 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 ttulo de Licenciado en Informtica, y actualmente
trabajo en una consultora de comercio electrnico.
</p>
<a href="principal.html">Volver a la pgina 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="vdeo1.mpeg">aqu</a> podrs ver un vdeo 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 acta como origen o destino de un enlace. As, en el ejemplo se
ve que pueden ser anclas las pginas HTML, las imgenes o los vdeos, y tam-
bin puntos concretos dentro de una pgina HTML, como se ha visto en el
caso del enlace interno dentro de la pgina 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 an no est generalizado.
Es importante notar que de los enlaces que aparecen en el ejemplo que se
acaba de describir, la forma de activacin o puesta en funcionamiento de los
mismos no es igual para todos ellos. Concretamente, la imagen incorporada
en la pgina 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 visualizacin de la misma

de manera automtica. Sin embargo, los enlaces entre las pginas, dentro de
la pgina principal, y de la pgina a la secuencia de vdeo slo se activan
cuando el usuario realiza una accin sobre ellos, tal como activarlos median-
te el ratn. Esta peculiaridad de la marca IMG de HTML implica que al aa-
dir imgenes en HTML, stas deben tener un tamao razonable, para evitar
que se ralentice la carga de la pgina 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 caractersticas,
pero no existe ninguna relacin de sincronizacin entre elementos de diferentes
tipos. Por tanto, a pesar de ser una estructura multimedia de tipo hipermedial,
no posee caractersticas de sincronizacin y secuenciacin entre contenidos,
por lo cual, puede considerarse una aplicacin multimedia muy bsica.
Segn 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 cmo
tratar un contenido que estn recibiendo de acuerdo a su tipo.
Hay cinco tipos generales, que tienen despus multitud de subtipos.
Los tipos generales son texto, imgenes, audio, vdeo y un quinto tipo deno-
minado aplicacin. Este ltimo tipo sirve para indicar que el contenido que
est llegando al navegador tiene una interpretacin que no casa en ninguna
de las categoras anteriores. A continuacin se muestran algunos ejemplos.
Dentro de la categora de texto, se tiene el subtipo text/plain que indica
que lo que se enva es texto sin ningn tipo de informacin de formato; tam-
bin se tiene, lgicamente, el subtipo text/html que indica que lo que se est
transmitiendo es texto con marcas de HTML. La imagen y el vdeo que se
mostr en el ejemplo de la figura 11.1 tendran los subtipos image/jpeg y
vdeo/mpeg respectivamente. Dentro de los tipos aplicacin se pueden
ver por ejemplo el de los ficheros PDF, que sera 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 accin por defecto es permitir
que ese contenido se guarde en el sistema de ficheros del usuario.
DEFINICIN: Tipos MIME.

Los tipos MIME son una clasificacin de los diferentes tipos y subtipos de conteni-
dos que pueden darse en la Web. Incluyen categoras generales para texto, im-
genes, vdeo y audio, y tambin para otros formatos que no encajen en las cate-
goras anteriores.
La infraestructura tecnolgica 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 aplicacin basado en solicitudes de
recursos a servidores Web. De este modo, un servidor Web es una aplicacin
que acta como contenedora de recursos de informacin (de contenidos,
segn 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 especfico que identifican los recursos disponi-
bles en la Web. Los clientes ms 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-
citara la pgina principal (u otra) mediante una URI que indicase dnde se halla
alojada. Por ejemplo, escribira 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 pgina
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 versin del pro-

tocolo HTTP que se est utilizando. Adems, en ocasiones se enva ms infor-
macin en la forma de cabeceras (headers). Una cabecera tpica es User-Agent,
que informa del navegador que est enviando la peticin.
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 versin del protocolo junto a un cdigo 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 continuacin viene el contenido
en s, en este caso, el fichero HTML correspondiente.
Debido al elemento IMG, el navegador realizar automticamente 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 bsico de la Web como sistema multimedia. A conti-
nuacin se ven ampliaciones y extensiones que se le han ido aadiendo con el
tiempo para proporcionar funcionalidades ms 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 versin 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 ms avanzadas de sus usuarios. El
diseo de esa nueva versin 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 slo 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 caractersticas de IPv6 que
sin duda sern fundamentales en la multimedia sobre la Web del futuro:
En primer lugar, el trfico 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 trfico de datos en tiempo real. Este
concepto contrasta con el trfico en IPv4, que es de tipo best effort, es
decir, no se puede garantizar un ancho de banda determinado a una
aplicacin. El trfico en tiempo real (como la difusin de vdeo, por
ejemplo) es tpicamente sensible a retardos de red y a prdidas por con-
gestin de la red. Para ello, en IPv6 se habla de Servicio Integrado,
que permite reservar un ancho de banda mnimo para determinadas
clases de usuarios, garantizando una calidad de servicio (quality of ser-
vice, QoS) determinada.
3
http://www.ietf.org/
Aunque los detalles tcnicos del nuevo protocolo caen fuera de los objeti-
vos de esta obra, pueden consultarse por ejemplo en (Gai, 1998).
DEFINICIN: 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 caractersticas
especficas para las aplicaciones multimedia. Concretamente, mejora las comunicacio-
nes multidestino (multicast) y est preparado para el trfico en tiempo real que requie-
ren muchas aplicaciones multimedia permitiendo la reserva de un ancho de banda
mnimo para un determinado usuario o aplicacin.
Junto a las extensiones a la infraestructura de red de Internet, se hace

necesaria una extensin de HTML para dar mejor soporte a caractersticas
multimedia avanzadas, como es la sincronizacin entre contenidos de diver-
sos tipos. El avance ms relevante es la aparicin de la especificacin 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 explci-
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 hipottico peridico virtual. Cuando se pulsa
una de ellas, se activa la correspondiente presentacin, con nombre Noti-
cias y ElTiempo. El elemento excl hace que sean excluyentes, es decir, que
slo una de ellas se visualice, de manera que si se est viendo Noticias y se
pulsa el otro botn, las noticias pararn 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 subttulos se
sincronizan con el vdeo de las noticias, y en el otro, el sonido se sincroniza
con la imagen del mapa del tiempo.
DEFINICIN: El lenguaje SMIL.

El lenguaje SMIL es un lenguaje de marcas, similar al HTML, que proporciona ele-
mentos para la definicin de presentaciones multimedia con sincronizacin 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-
cin, 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 visualizacin en el
navegador. Un tipo multimedia que est alcanzando gran popularidad en la
Web actualmente es el derivado de la aplicacin Flash del fabricante Macro-
media. El tipo SWF4 (Shockwave Flash File Format) permite crear animacio-
nes interactivas basadas en grficos vectoriales y sonidos que ocupan menos
espacio que las animaciones basadas en mapas de bits.
Adems de las extensiones anteriores, han aparecido tambin servidores
especializados en multimedia, que complementan a los servidores Web habi-
tuales, proporcionando servicios avanzados para la difusin de vdeo o audio.
Las peticiones a los mismos se realizan mediante URIs introducidas direc-
tamente o solicitadas por navegacin de enlaces, como en los servidores
Web, pero la respuesta del servidor es diferente.
Estos servidores utilizan una tecnologa denominada tecnologa de stre-
amming. Esta tecnologa permite la descarga progresiva de contenidos conti-
nuos como el vdeo, el audio o las animaciones mientras se va mostrando al
usuario en tiempo real. Es importante resaltar que este modo de operacin es
completamente diferente al de los servidores Web convencionales. Con servi-
dores convencionales, si se quiere ver un vdeo, primero se tiene que descar-
gar completamente, y despus comienza su visualizacin. Una variante inter-
media es el pseudo-streamming o descarga progresiva. En la descarga
progresiva, los usuarios esperan a que se descargue una porcin significati-
va antes de comenzar la visualizacin (o la audicin).
En el streamming real, los servidores utilizan protocolos de difusin espe-
cficos. 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 tecnologas de streamming ms 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.
DEFINICIN: Tecnologas de streamming.

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

Internet, el ancho de banda necesario para que la presentacin se siga en
tiempo real sigue siendo muy grande, por lo cual, cada tecnologa tiene mto-
dos de compresin del flujo de datos, para tratar de minimizar el consumo de
recursos de red. Adems, 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 bsico de la Web actual es el Hyper-

text Markup Language (HTML), que se distribuye a travs del protocolo HTTP
sobre el protocolo TCP/IP. Como su nombre indica, HTML es un lenguaje origi-
nariamente diseado para el texto, y como tal tiene importantes limitaciones
para la multimedia. HTML proporciona bsicamente soporte a imgenes fijas
bidimensionales, ya que el soporte para formatos no textuales especficos es res-
ponsabilidad de los navegadores de la Web. Por ejemplo, el formato GIF98a pro-
porciona una forma rudimentaria de animacin de imgenes, y la prctica 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
sincronizacin 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 seccin se describen algunas de las ms notables.
11.2.1. Lenguajes de script para manipulacin de HTML
El lenguaje HTML en su versin original no proporcionaba ninguna

caracterstica de interactividad, si se excluye la navegacin a travs de los
enlaces, aunque sta no es propiamente una interaccin con la pgina, sino
la sustitucin de la misma por el destino del enlace. Esta deficiencia motiv
la aparicin de lenguajes complementarios que permiten interactuar con la
pgina. 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 bsica de permitir la interactividad con los elementos de la pgina.
Por ello, son lenguajes de propsito especfico, especializados en la manipu-
lacin de los elementos de la pgina HTML que los contiene.
Esa manipulacin de los elementos de la pgina se realiza mediante unas
interfaces de programacin que ven en la pgina 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 pgina, lo cual acarreaba serios problemas para
el desarrollo de Webs que funcionasen en diferentes tipos de navegadores.
Actualmente, los lenguajes de script ms utilizados como javascript y JScript
estn basados en una especificacin comn estandarizada, denominada
ECMAScript7, que asegura un cierto grado de compatibilidad, al menos en la
estructura bsica del lenguaje.
Para hacerse una idea de cmo se puede aadir interactividad a las pgi-
nas, se va a ver un ejemplo muy simple que utiliza javascript para modificar
un elemento de una pgina 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 botn 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 demogrficos</button>
<button onclick="cambia_imagen('tres');">Principales carreteras</button>
</body>
</html>
FIGURA 11.7. Ejemplo que utiliza javascript para modificar un elemento de una pgina 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 estn orientados a la generacin dinmica 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 pgina 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 pas determinado. Sobre esta estructural bsica, se ilustran dos extensio-
nes fundamentales al HTML:
En primer lugar, la interactividad de la pgina se consigue mediante la
posibilidad de definir manejadores de eventos. En el ejemplo, el even-
to de interfaz de usuario pulsar botn se captura mediante el corres-
pondiente atributo onclick del elemento button, que hace referencia al
manejador, en este caso, a la funcin javascript cambia_imagen.
La funcin cambia_imagen se ejecutar en respuesta a la pulsacin de
uno de los botones. Lo fundamental de estas funciones es que pueden
manipular el HTML de la pgina mediante el uso de una representa-
cin de la misma como rbol DOM. En el ejemplo, se modifica el atri-
buto src de la imagen de la pgina, para pasar a mostrar otra. Para ello,
se utiliza el objeto predefinido document, que representa a la pgina
entera, y se utiliza el atributo id de la imagen para manipularla.
Este sencillo ejemplo muestra cmo los lenguajes de script pueden utili-
zarse para aadir interactividad a la pgina Web, incluso creando pequeas
animaciones de manera rudimentaria.
DEFINICIN: Lenguajes de script en HTML.

Los lenguajes de script para HTML como el javascript, permiten escribir programas
interactivos que manipulan el HTML de la pgina 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,
aadiendo funcionalidades que se integran en el navegador como si fuesen
una parte integrante de l. Esta arquitectura interna de los navegadores ha
permitido numerosas estn-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 funcin.
Se llaman applets, de manera genrica, a pequeas aplicaciones que pue-
den ejecutarse en el navegador, cuando la pgina HTML que las contiene
hace referencia a ellas. Estas aplicaciones se descargan al navegador en un
8
Se ha decidido conservar los trminos en ingls applet y plugin debido a su uso extendido
y a no tener una traduccin directa y ampliamente reconocida al castellano.
formato de cdigo independiente de la plataforma, y una mquina virtual las

ejecuta como parte de la pgina. Un applet ocupa un rea rectangular del nave-
gador y gestiona su propia entrada y visualizacin. Debido a que los applets
son programas de complejidad arbitraria, pueden utilizarse para contener
multimedia interactiva de cualquier tipo. La nica restriccin que se debe
tener en cuenta por el desarrollador es su tiempo de descarga. Actualmente, la
mayora de los applets se desarrollan en lenguaje Java o en lenguajes de la pla-
taforma Microsoft. Los applets realizados con esta ltima tecnologa se deno-
minan componentes ActiveX, y son funcionalmente equivalentes a los applets
de Java.
El fragmento de cdigo de la figura 11.8 es el esqueleto de un applet en el
lenguaje Java. Los mtodos init y destroy se ejecutan respectivamente en los
momentos en los que el applet se carga y descarga del navegador. Los mto-
dos start y stop se ejecutarn cuando cada vez que el applet se muestre u ocul-
te en el navegador (por ejemplo, si se navega a otra pgina y a continuacin
se retorna a la misma). Por lo dems, los applets son un rea de visualizacin
sobre la cual se puede componer una aplicacin de interfaz grfica de usua-
rio de igual modo a como se hara para una aplicacin de interfaz grfica
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
estn integrados con el propio HTML, mientras que los lenguajes como javas-
cript estn ntimamente ligados a l.
Los plugins son bibliotecas software que se aaden 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 visualizacin el rea completa del
navegador o una regin 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 aplicacin auxiliar independiente. La
diferencia que tienen con los plugins es que la presentacin de ese conteni-
do est separada del rea de visualizacin del navegador, y es independiente
de ste.
DEFINICIN: Applets y plugins

Los navegadores Web actuales estn preparados para aceptar extensiones de su
funcionalidad.
Los applets son pequeos programas que se descargan y se ejecutan en el nave-
gador. El lenguaje de programacin ms utilizado para escribir applets es el len-
guaje Java.
Los plugins son mdulos que se instalan sobre el navegador, y sirven para gestio-
nar un determinado formato de datos. As, el navegador delega la visualizacin de
esos tipos de datos en las bibliotecas del plugin.
11.2.3. Lenguajes de marcado especficos para los sistemas

multimedia
Si bien el lenguaje HTML permite la inclusin de contenidos multimedia,
y sus extensiones permiten aadir interactividad a la estructura hipermedia,
HTML no proporciona en s mismo facilidades para la sincronizacin 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 especfico 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 despus 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 aparicin 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 ms una prome-

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

cacin o formacin a distancia o semi-presencial. Debe tenerse en cuenta que
los individuos no aprenden de manera natural utilizando mtodos pasivos,
sino que el mecanismo ms eficaz de aprendizaje consiste en fijarse objeti-
vos, formular preguntas, actuar, equivocarse, corregirse y, finalmente, gene-
rar respuestas. De otra forma quin aprendi a andar, nadar, hablar y tantas
otras cosas asistiendo a clases?
El principal inconveniente de aplicar tcnicas que permitan al estudiante
aprender de manera natural en la formacin acadmica es que este tipo de
aprendizaje requiere una cantidad inusual de atencin 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 slo
posibilitan esta individualizacin, sino que adems permiten presentar tareas
que motiven e interesen a cada alumno en particular, les permiten seguir enfo-
ques exploratorios, habilitan la opcin 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
tcnicas didcticas que se ponen casi siempre de manifiesto en las clases de
la escuela, se estn reproduciendo de manera automtica los mismos incon-
venientes que estas tienen, y que bsicamente 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 electrnico, donde el alumno slo tiene que pasar pgina utili-
zando un botn.
Los sistemas multimedia tiene importantes caractersticas que hacen que
los programas de ordenador sean herramientas didcticas tiles, puesto que
entre otras cosas, permiten presentar las tareas de manera ms atrayente y
aumentar el grado de interaccin, si bien por s solas no son garanta 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 simulacin. Un ejem-
plo elocuente de este tipo de arquitectura son los simuladores de labo-
ratorios qumicos o fsicos, 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 tambin permite
insertar ficheros de vdeo 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 ancdotas. Los sistemas mul-

timedia tambin puede ser til para estudiar aquellas materias que
requieren mucha memorizacin y son montonas, por lo que el apren-
dizaje puede no llegar a ser efectivo. Por ejemplo, existen programas
para estudiar a travs de la Web geografa, donde se explota que es ms
fcil aprender las caractersticas geogrficas de los sitios visitndolos
en lugar de memorizndolas. As, el estudiante puede planificar un via-
je utilizando un mapa de carreteras y se le van presentado vdeos tanto
de la ruta como del sitio de destino, de manera que se minimice el
esfuerzo de memorizacin.
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 cmo
conseguirlos adaptando el entorno de aprendizaje a sus necesidades.
Por ejemplo, existen aplicaciones multimedia que ponen al estudiante
en la situacin de resolver un hipottico problema prctico, y le ofrecen
diversos medios para llegar a un solucin, como aquellas que le propo-
nen jugar el papel de un consultor que debe aconsejar a un cliente. La
aplicacin proporciona al consultor diferentes medios como grabacio-
nes en vdeos 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
indagacin con los recursos que se le ofrecen.
Estas y otras aplicaciones multimedia se utilizan actualmente tanto en

enseanza reglada a travs de la Web como en formacin empresarial basada
en la Web, contando con un gran nmero de contenidos multimedia predise-
ados como los que ofrece la empresa SkillSoft.
11.3.2. Conferencias virtuales
Uno de los usos ms extendidos de la tecnologa multimedia en la Web es

la difusin de conferencias o charlas a travs de Internet (webcasting), de
modo que se produce el efecto de una conferencia a distancia, es decir, la
difusin de vdeo y audio sincronizados en determinadas franjas horarias,
como ocurre con la televisin, pero pudiendo aadir, en algunos casos, la
interaccin con los participantes remotos. Este uso de la multimedia es posi-
ble gracias a la tecnologa de streamming de la que ya se ha hablado. Una

sesin de WebCasting requiere varios pasos que se enlazan en un flujo conti-
nuo de informacin. En primer lugar, el audio o vdeo debe capturarse y
enviarse va satlite, lnea telefnica u otro tipo de conexin al centro de codi-
ficacin. En la fase de codificacin, la seal 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
distribucin se realiza mediante servidores especializados, llegando a una
interfaz Web preparada para el evento.
En el contexto de la tecnologa de Webcasting se habla de canales, utili-
zados en el mismo sentido que se usa para hacer referencia a canales de radio
o televisin. De hecho, y a pesar de la relativa juventud de esta tecnologa, ya
existen formatos abiertos para la definicin de canales. Un ejemplo es la
especificacin CDF (Channel Definition Format) propuesta por Microsoft,
que permite definir los meta-datos descriptivos de un canal, como su horario,
ttulo y autor.
La arquitectura de los sistemas de webcasting puede implicar a producto-
res de contenidos y consumidores de informacin, de manera directa o con
intermediarios. En el caso ms general, estos sistemas tendran la configura-
cin 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 Aplicacin de
Informacin
Metereolgica
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 informacin (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-
cacin de sus actualizaciones.
Esta arquitectura general refleja la complejidad que puede llegar a impli-
car un sistema de WebCasting que alcance a un gran nmero de usuarios,
como pueden ser los de la cadena de noticias BBC.
11.3.3. Recuperacin de informacin multimedia

La recuperacin de informacin en Internet es un conjunto de tcnicas de
procesamiento y organizacin de la informacin que persigue la construc-
cin de buscadores que permitan a los usuarios de la Web encontrar infor-
macin y contenidos a partir de la formulacin de consultas simples, como
puede ser la escritura de una o varias palabras o frases.
Esta importante rea de aplicacin ha dado como fruto tcnicas de inde-
xacin 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 podra hoy concebirse.
Ahora bien, la mayor parte de los buscadores slo habilita la bsqueda de
informacin textual, quedando la bsqueda de informacin en otros tipos de
datos relegada en muchos casos a buscar en las descripciones textuales aso-
ciadas a los mismos. Sin embargo, esta limitacin hace que muchos de los
contenidos en Internet queden fuera del alcance de los buscadores, lo cual ha
llevado a la investigacin en tcnicas de recuperacin de contenidos para
tipos de datos concretos diferentes del texto.
La recuperacin de informacin 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 imgenes
o a dos ficheros de audio similares? Incluso se pueden plantear consultas ms
complejas, como por ejemplo busca dos evoluciones de cotizacin en bolsa
que tengan el mismo perfil de variacin a partir de grficos con esas cotiza-
ciones. Esto lleva al planteamiento de que para cada tipo de bsqueda con-
creta se requiere una extraccin previa de sus caractersticas relevantes, y
stas pueden variar dependiendo de la intencin de la bsqueda en s. Por
ejemplo, al buscar imgenes puede interesar basarse en caractersticas pre-
ceptales como el color o la luminosidad, o bien se pueden buscar objetos
semnticamente reconocibles dentro de las imgenes (por ejemplo, coches de
un tipo determinado).
De lo que se acaba de plantear se deduce que la recuperacin de informa-

cin multimedia es realmente un rea que abarca mltiples facetas y objeti-
vos, dependientes tanto del tipo y combinacin de los medios en los que se
busca, como de las caractersticas de los mismos que se tienen en cuenta en
la bsqueda. Por ello, aqu se limita a describir brevemente dos aplicaciones
concretas, que son ilustrativas de la problemtica de este tipo de recupera-
cin de informacin.
Como primer ejemplo, se puede citar la bsqueda por imgenes una
revisin 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 bsqueda, las consultas se especifican mediante un
ejemplo de la imagen o la caracterstica 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 bsqueda se realiza mediante la comparacin de
los histogramas de color de las imgenes o de regiones de stas. La similitud
entre texturas se puede calcular comparando la variacin entre niveles de gris
de regiones de imgenes. Por ltimo, la bsqueda basada en formas se basa
en una deteccin previa de objetos dentro de las imgenes que requieren la
identificacin de los bordes de los mismos o de regularidades en fragmentos
de las imgenes.
En segundo lugar, la recuperacin de audio (Foote, 1999) tiene dos ver-
tientes fundamentales: la recuperacin basada en caractersticas del habla y
la recuperacin del sonido en general, sin asumir que en el sonido hay un dis-
curso hablado. En el primer caso, se utiliza una representacin estadstica de
cada uno de los eventos del habla, como puede ser la pronunciacin de una
palabra. Esos modelos estadsticos de la fontica de las palabras actan en
este caso como patrones de similitud. Aunque estas tcnicas tienen una bue-
na tasa de acierto para vocabularios limitados, en casos ms generales como
la bsqueda de noticias habladas, su fiabilidad se reduce considerablemente.
La segunda de las vertientes presenta problemas ms complicados, y se basan
actualmente en caractersticas preceptales 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 travs de la red Internet, lo cual le con-
fiere un carcter de medio de comunicacin de masas. El lenguaje HTML
permite la descarga de contenidos multimedia integrados en la estructura
hipermedia, basndose 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 especfica para la distribucin masiva de
multimedia, lo cual origina una problemtica 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 sincronizacin de con-
tenidos multimedia y la interaccin con los mismos.
Las deficiencias sealadas han llevado a diversas extensiones de la tecno-
loga Web original en diferentes dimensiones.
Por un lado, los nuevos protocolos de red propuestos para Internet, que
se basan en la nueva versin del protocolo de red IP denominado IPv6, con-
sideran la distribucin multimedia como uno de sus requisitos esenciales.
Adems, han aparecido servidores y protocolos para Internet que permiten la
difusin ms eficiente de la multimedia, siendo la tecnologa de streamming
la ms relevante de estas innovaciones.
Por otro lado, se ha propuesto el lenguaje de marcas SMIL, similar al
HTML, para la definicin de presentaciones multimedia sincronizadas, y
han aparecido formatos de datos multimedia que han alcanzado gran popu-
laridad, como el formato SWF, que se acompaa de un lenguaje de progra-
macin especfico para la multimedia, denominado ActionScript. Ante esta
proliferacin de tipos de datos especficos, los navegadores se han conver-
tido en aplicaciones extensibles siendo los applets y los plugins los meca-
nismos de extensin fundamentales y han incorporado lenguajes de
cliente que permiten a los usuarios una interaccin ms rica con las pgi-
nas Web.
La sinergia de la Web y la tecnologa multimedia ha dado lugar a diversos
tipos de aplicaciones, siendo las aplicaciones educativas, las conferencias vir-
tuales y la recuperacin de informacin multimedia algunas de las ms utili-
zadas e importantes.
11.1. Cul de los siguientes tipos estn incluidos como tipos MIME estndar?
a) Imagen.
b) Texto.
c) Audio.
d) Todos los anteriores.
11.2. Qu nuevas caractersticas aporta el protocolo IPv6 frente a IPv4?

a) Ofrece soporte para el trfico de datos en tiempo real.
b) Mejora la seguridad de la transmisin.
c) Posibilita realizar comunicaciones multidestino.

d) Todas las anteriores.
11.3. Cul de las siguientes no es una tecnologa de streaming?

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

mas hipermedia?
a) Un determinado minuto de un vdeo 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.
DAZ, Catenazzi y Aedo (1996): P. Daz, 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.
Captulo 12
LENGUAJES DE PROGRAMACIN
PARA SISTEMAS MULTIMEDIA
ESQUEMA
12.1. Herramientas para la programacin multimedia.

12.2. Uso de lenguajes de propsito especfico.
12.3. Uso de lenguaje de propsito general.
12.4. Criterios de seleccin.
12.5. Resumen.
En la fase de implementacin dentro del desarrollo de un sistema multi-
media, los desarrolladores deben seleccionar una o varias herramientas de
entre las existentes para la construccin del mismo. Actualmente existe una
gran variedad de opciones disponibles, que van desde el uso de una herra-
mienta de autora que no requiera conocimientos tcnicos de programacin
como puede ser el caso de las herramientas Flash de Macromedia, hasta
el uso de un lenguaje de programacin de propsito general como Java o
C#, pasando por opciones intermedias en las cuales se combinen varios
tipos de herramientas. En la actualidad, tambin es frecuente encontrar equi-
pos de desarrollo pluri-disciplinares, que cuentan con dos perfiles diferentes,
el de diseador o creador de contenidos y el de programador. Los primeros,
que habitualmente no son programadores, suelen utilizar herramientas de
autora para la creacin grfica y la composicin de animaciones. Los segun-
dos son los encargados de integrar esos contenidos en la plataforma infor-
mtica correspondiente.
En este captulo se describen los rasgos generales de las opciones existen-
tes y algunos criterios de seleccin, y se profundiza en el concepto de lengua-
je de programacin especfico para los sistemas multimedia, tomando como
caso concreto el del lenguaje ActionScript. Tambin se ilustra el uso de len-
guajes de programacin de propsito general con una visin panormica de
las bibliotecas que el lenguaje Java proporciona para el desarrollo de funcio-
nalidades multimedia.
12.1. HERRAMIENTAS PARA LA PROGRAMACIN

MULTIMEDIA
La construccin de un sistema multimedia una vez diseado pasa por la

eleccin y el uso de herramientas informticas. Esta seleccin depender de
la complejidad del sistema que se quiere disear, y de las funcionalidades
requeridas. Se puede considerar en primer lugar dos opciones:
Utilizar una herramienta de autora multimedia con soporte explcito
para la edicin de los contenidos multimedia y su sincronizacin.
Utilizar lenguajes de programacin de propsito general como pue-

de ser Java o C# utilizando las bibliotecas de programacin adecua-
das. Por ejemplo, en Java pueden utilizarse las bibliotecas Java2D o
Java3D para el propsito especfico del manejo de imgenes u objetos
tridimensionales, respectivamente.
La primera de las opciones requiere del conocimiento de la herramienta

concreta, que tendr un paradigma de autora determinado. En el segundo
caso, se utilizarn entornos de programacin no especficos para la multime-
dia, lo cual hace ms laborioso y complicada la construccin de la aplicacin,
ya que esos entornos no cuentan con herramientas visuales de manipulacin
y sincronizacin de diferentes medios.
Este captulo se centra en el uso de lenguajes de programacin y no de

herramientas de autora especficas, ya que stas ltimas sern tratadas en el
Captulo 13. Dentro de estos lenguajes, se tienen que diferenciar dos catego-
ras claramente diferenciadas:
Lenguajes de propsito general, con bibliotecas para multimedia.
Lenguajes de propsito especfico, especialmente diseados para laos

sistemas multimedia.
Los lenguajes de propsito especfico, en la mayora de los casos, se utili-

zan dentro de herramientas de autora, para complementar las funcionalida-
des de edicin generales con la potencia de un lenguaje de programacin. Tal
es el caso del lenguaje Lingo, que se utiliza dentro de la herramienta de auto-
ra Director de Macromedia.
DEFINICIN: Tipos de lenguajes para la programacin multimedia.
Los lenguajes de programacin pueden clasificarse en dos categoras bsicas res-

pecto a sus capacidades para la programacin multimedia. Por un lado, existen
lenguajes de propsito general, como Java o C#, que proporcionan bibliotecas
para la manipulacin de multimedia. En segundo lugar, existen lenguajes de pro-
psito especfico en los cuales el soporte de multimedia forma parte de la propia
definicin bsica del lenguaje. Estos ltimos normalmente estn integrados en
herramientas de autora y permiten una mayor productividad al estar directamente
integrados en ellos muchos conceptos multimedia.
A continuacin, 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 especfico ActionScript que se integra en las herramientas Flash de
Macromedia, para pasar a continuacin a describir las facilidades que ofrece
el lenguaje de programacin Java en lo relativo a los sistemas multimedia.
LENGUAJES DE PROGRAMACIN PARA SISTEMAS MULTIMEDIA 335
12.2. USO DE LENGUAJES DE PROPSITO ESPECFICO
El formato de animaciones denominado Flash ha constituido uno de los xi-

tos ms recientes en la historia de Internet. La idea de este formato es la de codi-
ficar animaciones multimedia interactivas y potencialmente complejas para su
distribucin eficiente a travs de la Web, de modo que los navegadores entien-
dan este formato a travs de una extensin (plugin). El fabricante Macromedia
cre la herramienta de diseo multimedia Flash tras comprar la compaa Futu-
reWave en el ao 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 ms 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 travs de la Web. ActionScript es el lenguaje de progra-
macin 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 animacin pueda responder a las acciones del usuario.
En esta seccin se describen algunos casos especficos de programacin
multimedia que pueden realizarse con este lenguaje. Lgicamente, los ele-
mentos tratados en esta seccin cubre slo una pequea parte de las posibili-
dades del lenguaje; para una descripcin ms 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 comn, que es la que se describe en la especificacin
estndar 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 mtodos. Las propiedades y mtodos de un objeto vienen determinadas
por la clase a la que pertenece. As, toda pelcula en Flash es un objeto que per-
tenece a la clase MovieClip. Si se coloca un botn en un fotograma de una pel-
cula, ese botn ser un objeto que pertenezca a la clase PushButton, tendr pro-
piedades tales como label, que representa el texto que muestra el botn, y
mtodos como getLabel() que permiten recuperar esa etiqueta.
As, los elementos de una animacin Flash se exponen como objetos. Por
ejemplo, si se tiene la lnea de tiempo con un nmero 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. Lnea de tiempo con nmero de fotogramas en Flash.
ActionScript se tiene que convertir en instancia de un smbolo. As, se puede

convertir el valo dibujado en smbolo utilizando la opcin convertir en sm-
bolo del men contextual del valo, tal y como se muestra en la figura 12.2.
FIGURA 12.2. Cuadro de dilogo para convertir un dibujo en smbolo 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 smbolos 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. Inclusin de un fotograma en Flash.
En este momento, se pueden asociar acciones en ActionScript a ese ele-

mento para conseguir efectos de animacin. Como ovalo1 es de tipo Clip de
pelcula, es posible asociarle eventos mediante onClipEvent (figura 12.5),
que toma como parmetro 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 funcin
Bajar. Esta asociacin hace que cada vez que el objeto ovalo1 cambie de foto-
grama, se ejecute el cdigo asociado.
FIGURA 12.5. Asociacin de eventos a un tipo Clip de pelcula en Flash.
El cdigo de Bajar accede a las propiedades de ovalo1 mediante la refe-

rencia implcita this, y se limita a modificar la posicin 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-
cin predefinida trace permite mostrar mensajes en una ventana de texto
preparada para la depuracin de las animaciones. De esta manera, se ha con-
seguido el efecto de una animacin en la cual el valo se desplaza por la pan-
talla hacia abajo segn van transcurriendo los fotogramas.
Tambin se puede asociar comportamiento a botones. Por ejemplo, se va
a colocar en el primer fotograma de la primera capa de una nueva animacin
dos botones, a los que se llamaran boton1 y boton2 respectivamente, como se
muestra en la figura 12.6.
Si se selecciona el primer botn, se puede escribir cdigo asociado al mis-
mo. Por ejemplo, se puede definir qu se debe hacer cuando se presiona el
botn mediante el cdigo que se muestra en la figura 12.7.
En ese cdigo 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 pelcula como un todo. Ade-
ms, se ven las invocaciones a setLabel() y getLabel() sobre los botones.
FIGURA 12.6. Colocacin de dos botones como primer fotograma de una nueva
animacin Flash.
FIGURA 12.7. Ejemplo de cdigo asociado al evento de presionar un botn.
Como se ve, existe una estructura de objetos definidos implcitamente para

acceder a los elementos de la presentacin, de igual modo que en el JavaScript
de los navegadores se tienen los objetos implcitos window y document a par-
tir de los cuales se puede manipular la ventana del navegador y el documento
HTML actual, respectivamente.
DEFINICIN: Estructura general de Actionscript.

ActionScript es un lenguaje sintcticamente igual a JavaScript, que se integra
en herramientas de composicin 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
mtodos de las instancias, se utiliza la notacin punto habitual en progra-
macin orientada a objetos, y se accede a los elementos a partir de instancias
predefinidas. Por ejemplo, _root, que representa a la presentacin Flash como
un todo.
12.3. USO DE LENGUAJES DE PROPSITO GENERAL
Todo lenguajes de programacin de propsito general permite extender

sus funcionalidades mediante la adicin de bibliotecas de algn tipo. En los
lenguajes de programacin orientados a objetos, estas bibliotecas suelen
denominarse marcos (frameworks) de clases. Los marcos son de propsito
especfico, es decir, vienen a complementar el lenguaje con funcionalidades
de un dominio concreto. El conjunto de los mtodos pblicos de las clases
expuestas en esos marcos conforma una interfaz de programacin o API
(Application Programmer Interface).
El conjunto de bibliotecas de Java que tratan de facilitar la programacin
de aplicaciones multimedia se agrupan bajo la denominacin comn de
Java Media APIs, e incluyen, entre otros, a los siguientes marcos de clases:
1. Java2D. Proporciona soporte avanzado para imgenes y grficos bidi-
mensionales. Permite combinar imgenes con texto y con dibujo a
mano alzada (line art). Permite componer imgenes, tratar su opa-
cidad (canales alfa) y manipulacin del color y aplicacin de filtros
para la manipulacin de imgenes.
2. Java3D. Permite la manipulacin y visualizacin de objetos tridimen-
sionales, incluyendo soporte para la especificacin VRML.
3. Advanced Imaging. Este marco facilita el procesamiento de imgenes a
travs de la red, incluyendo el recorte, aumento de contraste, cambio de
dimensiones o aplicacin manipulacin del dominio de las frecuencias.
4. Java Media Framework (JMF). Estas bibliotecas permiten la captura y
reproduccin incluyendo el streamming de tipos de datos conti-
nuos como el sonido o el vdeo. Incluye soporte para los protocolos
RTP/RTSP (real time streaming protocol) que permiten la integra-
cin 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-
racin en red, como pueden ser pizarras electrnicas, chats interacti-
vos o presentaciones remotas.
6. Sound. Proporciona soporte de bajo nivel para operaciones de audio
como la grabacin, reproduccin, mezcla y secuenciacin y sntesis
MIDI.
7. Speech. Estas bibliotecas (actualmente an en desarrollo) permiten la
integracin de reconocimiento y sntesis de voz.
Las bibliotecas que se acaban de mencionar conforman una extensa
interfaz para la programacin multimedia, que no est incluida en la distri-
bucin estndar del compilador de Java (el conocido como JDK Java Deve-
lopment Kit). A continuacin, se van a tratar los aspectos fundamentales de

JMF como ilustracin de las posibilidades que ofrece el lenguaje, no sin antes
proporcionar una visin del soporte original, bsico, 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
programacin de propsito general determinado proporciona un soporte
bsico o avanzado para la programacin multimedia.
DEFINICIN: Soporte multimedia en Java.

El lenguaje de programacin Java proporciona bibliotecas de clases especficas
para la programacin multimedia. Adems de algunas clases de soporte bsico en
el entorno de desarrollo, proporciona una serie de bibliotecas especializadas bajo
el nombre comn de Java Media APIs.
12.3.1. Soporte bsico 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 grficas utilizando tcnicas de movimiento de imgenes
controladas por programa. Si la rotacin de imgenes se produce a una velo-
cidad superior a 10 cambios por segundo, los usuarios la percibirn como
animacin en lugar de cmo sustitucin de imgenes. Suponiendo que se
cuenta con una secuencia de imgenes apropiada para la animacin, se pue-
de crear un applet que muestre la animacin creando un hilo de ejecucin
independiente (Thread). Este hilo de ejecucin ser el encargado de cambiar
las imgenes, 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 imgenes GIF que se muestran en la figura 12.8. Cada
imagen conformar un marco (frame) de la animacin resultante, que estar
contenida en un applet.
FIGURA 12.8. Secuencia de imgenes para producir un efecto de animacin.

El applet se cargar desde la correspondiente pgina HTML, y en este

caso, la velocidad en marcos por segundo de la animacin se especificar
como parmetro 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 animacin.
El cdigo del applet ser el de la figura 12.10.

En ese cdigo se ve cmo al iniciarse el applet (mtodo init()), se toma
el parmetro de velocidad de animacin, y se cargan en un array las imge-
nes que conforman la misma. Cuando comienza la ejecucin del applet
(mtodo start()) se crea un nuevo hilo de ejecucin asociado a la propia ins-
tancia del applet. De este modo, ese hilo de ejecucin comenzar a ejecutar el
mtodo run() en la misma clase (ntese que Thread requiere que el objeto al
que se le asocia tenga un mtodo run() implementado, como consecuencia
de la implementacin de la interfaz Runnable).
El hilo de ejecucin invocar a repaint(), que, en la mayora de los casos
(a menos que el nmero 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 implcitamente al mtodo paint(). ste ltimo se
encarga de dibujar la imagen que est indicada por el ndice frame, que avan-
za en cada iteracin dentro del mtodo run(). Ntese que, a pesar de que el
cdigo toma la hora actual del sistema, para hacer ms precisa la temporiza-
cin, sta nunca es completamente exacta, ya que la mquina virtual puede
tener otros hilos en ejecucin, 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 visualizacin. El problema reside en que el proce-
so de dibujar cada marco es largo, y adems, antes de dibujar el siguiente, se
limpia el anterior. Este segundo problema puede eliminarse redefiniendo el
mtodo update(), que es el que se invoca cuando se necesita repintar. Por
defecto, ste mtodo borra el rea de visualizacin, y despus invoca a
paint(). Se puede evitar el borrado redefinindolo 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 ejecucin
* para animar las imagenes.
*/
animador = new Thread(this);
animador.start();
}
/**
* Mtodo que ejecuta el hilo de ejecucin '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 animacin pare.
*/
animador = null;
}
/**
* Dibuja un frame de la animacin.
*/
public void paint(Graphics g) {
g.drawImage(frames[frame], 0, 0, null);
}
}
FIGURA 12.10. Cdigo del applet de velocidad en marcos por segundo de la animacin.
public void update(Graphics g){
paint(g);
FIGURA 12.11. Evitar el borrado.
Otro mtodo para hacer ms suave la visualizacin es el buffer doble.

Este mtodo 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-
cin de una sola vez, de modo que el dibujo de la imagen se ha hecho offli-
ne, siendo esta operacin ms eficiente que la de hacerlo directamente en
la pantalla.
Adems del tipo de animacin que se acaba de ver, tambin pueden crear-
se sprites en Java, que son objetos que se mueven por el rea de visualizacin,
y que tienen un fondo transparente. Igual que en el ejemplo que se acaba de
ver, el control del movimiento se hace de manera explcita mediante el cdi-
go Java, pudiendo incorporar deteccin de colisiones o superposicin de spri-
tes, aadiendo la lgica apropiada.
Un problema adicional relacionado con el dibujo de imgenes 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 visualizacin incompleta. Aunque este efecto puede ser deseable en
algunas situaciones, en el caso de las animaciones es mejor esperar a que las
imgenes estn completamente disponibles antes de comenzar. Para ello, se
puede utilizar la clase java.awt.MediaTracker, que permite cargar imgenes
antes de la visualizacin, y monitorizar su estado, para evitar mostrarlas
antes de que estn completamente cargadas (con el mtodo checkID).
Desde sus primeras versiones, el JDK proporcionaba soporte para la
reproduccin de sonido mediante la interfaz java.applet.AudioClip, que
proporciona los mtodos autodescriptivos play(), stop() y loop(). Esta
interfaz permita en sus primeras versiones la reproduccin de sonidos en
formato .au, proporcionando sonido mono de 8 bits y hasta 8000 Hz. A par-
tir de la versin 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 continuacin se muestra el cdigo de un simple applet que carga un fiche-
ro WAV y muestra tres botones con la disposicin 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.
Ntese 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 cdigo 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 manipulacin del mismo motor de sonido de Java que utiliza la
sencilla interfaz AudioClip.
DEFINICIN: Soporte bsico de multimedia en el JDK.

El entorno de desarrollo bsico de Java permite el desarrollo de aplicaciones multime-
dia, realizando un control explcito de las animaciones y/o sincronizaciones a travs del
programa. Para ello, es necesario crear hilos de ejecucin (clase Thread) para cada una
de las tareas multimedia concurrentes, y utilizar las clases que proporciona Java para
cargar imgenes, sonido o dibujar grficos.
12.3.2. Conceptos fundamentales de Java Media Framework

(JMF)
Java Media Framework (JMF) es conjunto de interfaces de programacin
en Java orientado a la incorporacin de medios continuos en las aplicacio-
nes y applets de Java. En su versin 1.0, proporcionaba soporte para la pre-
sentacin de medios continuos, y en la versin 2.0 actual, aade funcionali-
dades de captura, almacenamiento y control del procesamiento de esos
medios.
En JMF el tipo del contenido es sinnimo 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 conexin 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 vdeo). Los flujos multimedia
son bsicamente de dos tipos:
Flujos pull, en los cuales la transmisin 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 categora.
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 aplicacin cliente. Estos procesamientos inclu-
yen la demultiplexin o separacin de canales, la decodificacin o descom-
presin de ciertos canales, la conversin de formato de algunos canales y
posiblemente, la aplicacin 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 visualizacin y en ocasiones,

elementos para la combinacin o sincronizacin de diferentes canales.
La arquitectura general de JMF es la que se muestra en la figura 12.13.
Bsicamente, JMF proporciona un API de alto nivel que abstrae de las carac-
tersticas de los diferentes procesamientos que tienen lugar en las aplicacio-
nes multimedia (multiplexin, compresin, filtrado, multiplexin, dibujo o
renderizacin, etc.).
Aplicaciones y applets Java
APIs de presentacin 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 extensin mediante plugins que ofrece
JMF, figura 12.14.
DEFINICIN: Java media framework (JMF).

Las interfaces de JMF permiten desarrollar funcionalidades tpicas de la manipulacin de
medios continuos (vdeo, audio, animaciones, etc.), incluyendo la carga o captura, el
procesamiento y la reproduccin o grabacin. 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 reproduccin de flujos multimedia. Para ello, utiliza el concep-
to de gestor (manager), con las siguientes categoras:
1. La interfaz Manager se encarga de la creacin de otros gestores con-
cretos como Players, Processors, DataSources y DataSinks. As, para
crear reproductores o procesadores, hay que invocar a los mtodos

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

disponibles en una determinada instalacin (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 aplicacin de registro JMF.
Los gestores disponibles en una determinada instalacin de JMF pueden

manipularse adems de a travs de las interfaces mencionadas mediante
la aplicacin JMF Registry Editor proporcionada con JMF. En la figura
14puede verse su estructura general, y la descripcin de un multiplexor para
formato QuickTime.
Una aplicacin de reproduccin de un flujo multimedia constar bsica-
mente de un objeto que implemente la interfaz Player y otro que implemen-
te DataSource.
El cdigo bsico para realizar una reproduccin 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. Cdigo bsico para realizar una reproduccin dentro de un applet.
En el cdigo de la figura 12.15 se puede comprobar cmo 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 parmetro del
applet. El Player pasa por una serie de estados de los cuales se puede obtener
notificacin:
No realizado cuando el reproductor an no conoce nada sobre el
flujo que debe procesar.
Realizndose 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 visualizacin 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 reproduccin 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 reproduccin ya
ha comenzado a funcionar.
As, cuando se recibe la notificacin 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 posicin del applet. La figura 12.16 muestra la configura-
cin resultante, con el panel de control abierto.
En la figura 16 se ve la velocidad y otros datos de los canales del vdeo, as
como la configuracin de plugins que se han puesto en funcionamiento para
ver el vdeo AVI. Se tienen dos canales de salida (DirectDraw y DirectSound),
y el canal de la imagen utiliza el decodificador de Cinepak.
La sincronizacin de dos o ms Players puede realizarse gracias a que
todos ellos implcitamente tienen un reloj (definido por la super-interfaz
Clock). As, se pueden sincronizar las lneas de tiempo de dos reproductores
mediante la invocacin:
player1.setTimeBase(player2.getTimeBase());
Tambin se pueden realizar sincronizaciones ms complejas, haciendo

que uno de los reproductores acte como controlador de los dems.
DEFINICIN: Reproduccin de flujos multimedia en JMF.

A travs 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 preparacin y carga del flujo. Adems,
JMF incorpora en estos reproductores un mecanismo para el control temporal que
permite construir sincronizaciones entre flujos multimedia.
Una de las caractersticas 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. Ejecucin 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, lgicamente, no garantiza la recepcin 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 monitorizacin de la calidad del servicio de RTP
subyacente, entre otras funciones de control.
RTP proporciona funciones para la identificacin del tipo de datos que se
transmiten, para la secuenciacin de los paquetes de datos, y tambin para la
FIGURA 12.17. Estructura en capas del protocolo RTP.
sincronizacin de flujos multimedia de diferentes fuentes. En RTP, las sesio-

nes son asociaciones de un conjunto de aplicaciones (participantes) que se
estn comunicando mediante RTP, es decir, que actan 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 paquetizacin y reconstruccin 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 direccin de la
sesin RTP, como muestra el siguiente fragmento de cdigo en la figura 12.18.
String url= "rtp://www.mediaserver.com/vdeo/3";

MediaLocator mrl= new MediaLocator(url);
if (mrl == null) {
System.err.println("Error en la construccin 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. Construccin de un reproductor RTP.

Este cdigo causar la conexin al primer flujo RTP encontrado dentro de

la sesin indicada. Cuando se detecten datos en la sesin, el reproductor
pasar al estado de realizado, permitiendo comenzar la visualizacin de la
reproduccin.
DEFINICIN: Streamming multimedia distribuido en JMF.

JMF proporciona soporte para el protocolo de distribucin mediante streaming RTP.
El tratamiento de los flujos RTP es similar al de otros tipos de flujo multimedia.
Adems de las funcionalidades vistas en esta seccin, JMF proporciona

interfaces para la captura de flujos multimedia, para el procesamiento pre-
vio a la reproduccin, y para el control exhaustivo de flujos RTP mediante
RTCP.
12.4. CRITERIOS DE SELECCIN
La seleccin de las herramientas es un paso muy importante, previo a

la fase de implementacin de la aplicacin multimedia. Esta es una decisin
ms de Ingeniera 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-
tribucin.
Los criterios de seleccin de la herramienta pueden a grandes rasgos
resumirse en los siguientes puntos a considerar:
1. La capacitacin 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 autora proporcionan una mayor productividad para la
mayora de los desarrollos.
3. El tercer factor, como en toda decisin de ingeniera, es el coste de la
decisin tomada, tanto en trminos de licencias de desarrollo y pro-
duccin, como, en su caso, de costes de formacin para el equipo de
desarrollo.
4. Por ltimo, pero no menos importante, hay que tener en cuenta las
funcionalidades requeridas a la aplicacin, as como la arquitectura
hardware y software en la que deber implantarse. Estos requisitos
funcionales y no funcionales lgicamente limitan el abanico de herra-
mientas adecuadas a cada desarrollo concreto.
Adems de los criterios mencionados, en ocasiones es necesario conside-

rar tambin la compatibilidad con estndares existentes, que suele ser impor-
tante para la futura interoperabilidad entre aplicaciones.
12.5. RESUMEN
Desde el punto de vista de la Ingeniera del Software, se pueden conside-

rar dos opciones fundamentales para la seleccin de los lenguajes de progra-
macin para una aplicacin multimedia. En primer lugar, los lenguajes de
programacin especficos para los sistemas multimedia proporcionan opera-
ciones y objetos especialmente preparados para la manipulacin y sincroni-
zacin de elementos de diferentes tipos, habitualmente integrados dentro de
un entorno visual de autora. En segundo lugar, algunos lenguajes conven-
cionales permiten la adicin de bibliotecas especficas para la manipulacin
de elementos multimedia, programando explcitamente las funciones de inte-
gracin y sincronizacin de elementos de diferentes tipos.
El lenguaje ActionScript se integra en entornos de composicin de ani-
maciones como las herramientas Flash de Macromedia, y permite asociar
eventos a los diferentes elementos que conforman la presentacin. As, esos
elementos son instancias de clases que tienen propiedades y mtodos, y la
manipulacin de las propiedades o la invocacin de los mtodos se realizan
mediante la notacin punto habitual en programacin orientada a objetos.
El lenguaje de propsito general orientado a objetos Java cuenta con
bibliotecas bsicas para la manipulacin de imgenes y dibujos, as como para
la reproduccin de sonidos. El programador es responsable de disear las
interacciones entre los elementos mediante hilos de ejecucin independientes.
Adems, una coleccin de interfaces de programacin bajo la denominacin
de Java Media APIs permite manipulaciones ms avanzadas, incluyendo la
compatibilidad con protocolos de difusin multimedia actuales como RTP.
12.1. Cul de las siguientes afirmaciones respecto a ActionScript es falsa?

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

dia de Java en aplicaciones orientadas a la colaboracin en red, como
pueden ser pizarras electrnicas, 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 reproduccin.
c) Interfaz de conversin de tablas de colores.
d) Interfaz de procesamiento.
12.5. El JDK se conoce como:

a) Multiplexacin/Demultiplexacin.
b) Empaquetado y reconstruccin de flujos.
c) Renderizacin.
d) Distribucin estndar del compilador de Java.

MOOCK (2001): C. Moock ActionScript: The Definitive Guide. Mastering Flash Pro-
gramming, OReilly.
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.

Captulo 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 tecnologa Flash.
13.6. Director.
13.7. Resumen.
13.9. Referencias bibliogrficas
Si el anlisis y el diseo de un producto multimedia son procesos com-
plejos, de los que ya se ha hablado en el captulo 5 de este libro, la produccin
tampoco es una labor sencilla ni meramente tcnica. De hecho, para crear un
producto multimedia no slo hacen falta programadores, sino que se requie-
ren diseadores multimedia con un tipo de conocimiento y habilidades com-
pletamente distintos. Es ms, en la mayora de las ocasiones, las aplicaciones
multimedia son elaboradas por personas sin conocimientos de programacin
o de lenguajes de marcado o modelado, pero que tienen la necesidad de utili-
zar esta tecnologa como potente medio de transmisin de sus ideas. Junto a
esta situacin, no hay que olvidar la vertiginosa y continua aparicin de nue-
vas tecnologas en este campo, que hace difcil estar al da en tcnicas de
implementacin.
Por estas, entre otras razones, las herramientas de autor gozan cada da
de mayores adeptos. Este tipo de aplicaciones software ofrecen interfaces
sencillas y visuales, habitualmente de manipulacin 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 ms com-
plejos, de manera que son tiles tanto para desarrolladores con conocimien-
tos tcnicos como para aquellos que no los tienen. Adems, al permitir crear
productos multimedia complejos en un tiempo muy reducido, se convierten
en candidatas ideales para utilizar tcnicas como el prototipado rpido para
el anlisis o el diseo de aplicaciones.
En este captulo se analizarn las herramientas de autor para productos

multimedia. Obviamente, dado el ingente nmero de herramientas existentes
en el mercado, no se pretende elaborar un catlogo de la mismas, sino que se
ha optado por presentar algunas que se han considerado bastante represen-
tativas y difundidas. El captulo se inicia con una breve introduccin al con-
cepto de herramienta de autor, en el que se comentan clasificaciones de las
mismas, ya sea atendiendo al modelo de informacin o metfora que asu-
men, ya sea atendiendo al paradigma de creacin de aplicaciones que ofre-
cen. A continuacin se describirn algunas herramientas de autor como son
ToolBook, Dreamweaver, Authorware, herramientas que soportan la tecnolo-
ga 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 edicin para los autores de aplicaciones interactivas multime-
dia. Estos autores son, en la mayora de los casos, los propios desarrolladores
del sistema que se han reconvertido asumiendo tanto las labores propias de
la implementacin como otras ms creativas, necesarias para este nuevo tipo
de escritura y edicin, en la que contenidos de naturaleza diversa se funden
formando un discurso multimedia.
DEFINICIN: Herramienta de autor.

Aplicacin o conjunto de aplicaciones que facilitan el desarrollo sin que sea nece-
sario tener conocimientos especficos de programacin.
Las herramientas de autor proporcionan una gran variedad de servicios que

dependen del entorno en el que el autor trabaje y del tipo de aplicacin que quie-
ra desarrollar. Desde el punto de vista de la interfaz, la utilizacin de lenguajes
visuales de comunicacin, en los que la manipulacin directa de objetos, las
cajas de dilogos y los mens desplegables son las formas ms usuales para la
interaccin persona-ordenador, es la frmula ms usada en este tipo de herra-
mientas, debido a que el autor puede ignorar aspectos de programacin (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 programacin, modelado o marcado, le permiten centrar
sus esfuerzos en otros aspectos del diseo ms relevantes, como por ejemplo la
aplicacin de principios de diseo que incrementen la usabilidad.
Son muchas las caractersticas que tienen cumplir estas herramientas de
autor para que ayuden en el proceso de creacin (Daz y otros, 1996), pudin-
dose destacar las siguientes:
Soporte a la edicin y composicin multimedia. En primer lugar,
una exigencia bsica para todo entorno de autora es la existencia de
mecanismos para preparar y manipular material multimedia. La tec-
nologa no debe mermar las capacidades expresivas y creativas del
autor, sino que debe permitirle emplear imaginativamente la informa-
cin. As, por ejemplo, el autor puede necesitar analizadores ortogrfi-
cos para revisar sus escritos, editores de dibujo integrados para prepa-
rar sus grficos y aplicaciones para manipular el material videogrfico.
Las herramientas actuales generalmente incorporan estos mecanismos
facilitando la labor del autor.
Soporte a la especificacin de eventos. Adems, estas herramientas
deben permitir el uso de contenidos de informacin que sean capaces
HERRAMIENTAS DE AUTOR 361
de reaccionar ante eventos, ya sean producidos desde el exterior (v.g., el

movimiento del ratn) o desde el interior (por ejemplo, un interlo de
tiempo desde el inicio de la sesin) del sistema interactivo.
Soporte a la inclusin de metadatos y atributos. Otra caracterstica
relevante a tener en cuenta es la posibilidad de asociar atributos o
metadatos a estos contenidos, ya sean semnticos o de interfaz, para
que el autor pueda controlar tanto su significado en el contexto como
su apariencia.
Soporte a la especificacin de la interaccin. Tambin las herra-
mientas de autor deben disponer de funciones con las que poder cons-
truir, de forma sencilla, mecanismos de ayuda para la interaccin (por
ejemplo, mecanismos de navegacin), as como comandos para la bs-
queda de informacin, ya sea por medio de cadenas de caracteres, de
consultas con un lenguaje de interrogacin, o de algn mecanismo ms
complejo, como podra ser la utilizacin de los metadatos anterior-
mente mencionados.
Normalmente, las herramientas de autor se clasifican de acuerdo al
modelo de informacin que utilizan, ya que habitualmente simulan un espa-
cio conocido por el autor y el lector, es decir, utilizan una metfora como base
del desarrollo (seccin 6.6). Al recrear un espacio conocido se suele facilitar
la labor del autor y del lector en el desarrollo y uso de la aplicacin. En la
tabla 13.1 se muestran algunos ejemplos de metforas asumidas en herra-
mientas de autor comerciales.
TABLA 13.1. Metforas usadas en herramientas de autor

Herramienta Metfora Significado
HyperCard Pila Una aplicacin multimedia se define como una
pila de tarjetas.
Toolbook Libro Una aplicacin multimedia se define como un
libro con pginas.
Director Pelcula Una aplicacin multimedia se define como un
escenario en el que participan unos actores
siguiendo un guin.
Por otro lado, las herramientas de autor tambin se pueden clasificar en

funcin de cmo se describe el comportamiento de los elementos de la apli-
cacin (Vnnen, 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
interacta 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 aparicin de los
contenidos en la aplicacin (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 lnea de tiempo sobre la que se sincronizan y alinean
los contenidos (por ejemplo, Macromedia Director).
A continuacin, se introducen algunas de las herramientas de autor ms
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 creacin de stos y un
potente lenguaje de programacin, denominado OpenScript. Esta herra-
mienta hace posible crear aplicaciones multimedia interactivas con sofistica-
das interfaces de usuario, que incluyen elementos tales como ventanas,
mens y cajas de dilogos, sin necesidad de tener grandes conocimientos de
informtica, de tal forma que desarrolladores no expertos pueden generar
sistemas potentes y tiles. Ejemplos de aplicaciones creadas con ToolBook
podran ser:
Aplicaciones hipermedia, tales como sistemas de documentacin inte-
ractivos.
Aplicaciones educativas interactivas, tales como tutoriales o puestos de
informacin.
Aplicaciones de bases de datos, utilizando la interfaz como front-end.
Juegos que usan elementos grficos.
ToolBook se podr utilizar como entorno interactivo para la creacin y
ejecucin de aplicaciones en un entorno Windows, encargndose de la comu-
nicacin con el sistema operativo y de la gestin de los distintos objetos defi-
nidos sobre la pantalla, as como de la interaccin con el usuario (por ejem-
plo, detectar si el ratn o una tecla se ha pulsado). En la siguiente figura se
puede ver un esquema de cmo 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 metfora de un libro como base del desarrollo de todas sus aplica-
ciones, lo que quiere decir que cualquier aplicacin est formada por uno o
ms ficheros denominados libros (Book). Al igual que un libro de papel, los
libros de ToolBook tambin estn divididos en pginas (Pages), representan-
FIGURA 13.1. Funcionamiento de la herramienta ToolBook.
do cada una de ellas una ventana de una aplicacin. Cada pgina contiene
campos (Fields), botones (Buttons) y grficos (Graphics), y tanto a ellas como
a sus elementos se les denomina, en terminologa ToolBook, objetos. Cada
pgina puede tener diferentes objetos, pudiendo adems 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 informacin contenida en ellos, por lo que se podra equiparar
con un sistema o subsistema.
Plantilla (Background). Est formada por elementos que son comu-
nes a una serie de pginas. Un mismo libro puede tener varias planti-
llas, pero una plantilla pertenece a un nico libro.
Pgina (Page). Es el elemento que se visualiza en ToolBook. Una plan-
tilla puede contener varias pginas, pero una pgina pertenece a una
nica plantilla.
Visores (Viewers). Son las ventanas en las que se visualizan las pginas
de cualquier libro, pudiendo definirse varios visores para el mismo libro.
Botn (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 ratn, etc. Sus formas son diversas, siendo posible asociarles
una representacin grfica.
Campo (Field). Los campos son contenedores de informacin textual
y grfica, siendo posible tener distintos tipos de texto dentro de cada
campo. Tienen formas y tamaos distintos en funcin de las necesida-
des de la aplicacin y del gusto del diseador.
Grficos (Graphic). Son aquellos grficos realizados con las herra-

mientas de dibujo incluidas dentro de ToolBook.
Imgenes (PaintObject). Son las imgenes importadas desde cual-
quier editor de grficos.
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 pginas o libros, es decir, que actan
como origen de un enlace.
Los botones, campos, grficos, imgenes y objetos OLE pueden pertenecer a:
la plantilla, en cuyo caso es lo mismo que decir que estn contenidos en
toda pgina que haga uso de esa plantilla, o a
la pgina, en cuyo caso slo estn en esa pgina.
De estas descripciones se desprende que en ToolBook existe una jerar-
qua de objetos como se refleja en la figura 13.2. En el nivel superior se
encuentra el objeto libro que contiene a todos los dems. En un segundo
nivel, estn las plantillas que contendrn de 1 a N pginas y de 0 a N objetos.
Las pginas, a su vez, incluirn de 0 a N objetos. Adems, todos los objetos
tienen un conjunto de propiedades asociadas que permiten caracterizarlos
tanto desde un punto de vista fsico (por ejemplo, fontStyle es una propiedad
que permite cambiar el estilo de un texto) o lgico (por ejemplo, name es una
propiedad que sirve para nombrar un objeto concreto). Adems, todos los
objetos tienen un identificador nico que permite al desarrollador hacerles
referencia evitando que se produzcan ambigedades o solapamientos.
FIGURA 13.2. Jerarqua 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 grficos, etc., y,
nivel de lector (Reader), en el que los usuarios pueden navegar por las
pginas, 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 aplicacin, mientras que en el
segundo de los casos, el lector slo puede interactuar con la informacin que
le ofrece el libro.
El lenguaje de programacin que se usa en el desarrollo se denomina
OpenScript. Es un lenguaje que tiene como filosofa la programacin 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 caractersticas bsicas de este paradigma como
puede ser la generalizacin.
Todos los objetos tienen una propiedad denominada script que contiene
los guiones que definen sus comportamientos tanto ante eventos predefinidos
(por ejemplo, el ratn ha pasado por encima del objeto) como ante eventos
especficos 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 enva 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 guin
correspondiente a ese evento, en este caso el guin mostrado en la fila inferior.
TABLA 13.2. Un ejemplo de guin definido con OpenScript
Evento Guin
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. Visin de autor de un libro de ToolBook.
FIGURA 13.4. Visin 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
seleccin de ratn y, adems, son directamente exportables a formatos Web
soportados tanto por el navegador Internet Explorer como por Netscape.
Tambin los desarrolladores, en este caso expertos, pueden integrar rutinas
creadas con lenguajes como C++, C o VisualBasic en su aplicacin ToolBook.
Finalmente, cabe destacar que esta herramienta de autor permite progra-
mar aplicaciones de forma sencilla y accediendo a todas las caractersticas del
entorno. Adems, las versiones actuales han evolucionado hacia potentes herra-
mientas de desarrollo de contenidos educativos que cumplen los estndares 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 publicacin del producto final tanto en
Web, a travs de una extensin denominada Neuron, como en soportes estticos
(por ejemplo, DVD), como en forma de soluciones hbridas en las que ambas
formas de publicacin pueden coexistir simultneamente. Toolbook proporcio-
na una interfaz de simulacin que ayuda a desarrollar estas aplicaciones hbri-
das, permitiendo al desarrollador observar que pasos siguen los usuarios, cmo
introducen informacin o cmo interactan con la aplicacin, pudiendo evaluar
sus respuestas y su actividad. Adems, se pueden integrar todo tipo de informa-
cin de vdeo y de sonido utilizando tecnologa de streaming.
13.3. DREAMWEAVER
Dreamweaver (Macromedia, 2003) es una herramienta de autor de la
compaa Macromedia que permite generar de manera sencilla pginas
HTML. Con este fin, facilita una serie de herramientas visuales para que las
personas que generan estas pginas no tengan que tener necesariamente
conocimientos de este lenguaje de marcado, y as puedan componer una
pgina Web sin tener que editar manualmente el cdigo. Tambin es posible
acceder en todo momento al cdigo HTML automticamente generado por la
herramienta, por lo que el desarrollador que si tenga conocimientos sobre
lenguajes de marcado podr insertar cualquier tipo de etiqueta o informacin
sobre el cdigo fuente, modificacin que automticamente se refleja en la
composicin visual de la pgina.
Otras caractersticas interesantes de esta herramienta son:
Posibilidad de trabajar con distintos lenguajes de marcado y hojas
de estilo. Dreamweaver permite, adems de trabajar con documentos
HTML, la edicin de documentos que utilizan otros lenguajes de mar-
1
http://www.adlnet.org/
2
http://www.aicc.org/
cado como son XML y XHTML, pudindose todos ellos combinar con
hojas de estilo desarrolladas con CSS2.
Inclusin de documentos interpretados en el servidor. Adems de
la edicin de documentos que se interpretan en el cliente se pueden
desarrollar documentos que se interpreten en el servidor utilizando tec-
nologas como PHP, ASP.NET, ASP y JSP.
Existencia de libreras. El desarrollador tiene a su disposicin libre-
ras que permiten una generacin rpida de cdigo, facilitando la
actualizacin de bases de datos a travs de formularios, el recuerdo de
las pginas que el usuario ha visitado, as como su identificacin para
realizar operaciones en las que es necesario conocer la identidad del
usuario.
Gestin de sitios Web. Dreamweaver tambin permite la gestin de
sitios Web, especialmente si estos son los servidores que la propia
empresa desarrolla, denominados ColdFusion, permitiendo versiones
de los documentos as como la actualizacin 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 visin de
marcado, parte superior de la ventana, como la visin grfica, parte
inferior.
Las opciones ms habituales, a las que se puede acceder a travs de
los iconos rpidos. 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, pudindose 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 mens contextuales, que permiten acceder rpidamente a
comandos tiles relacionados con la seleccin 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 edicin 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 pginas Web son:
Genera un cdigo HTML bastante limpio y compatible con la mayora
de los navegadores.
Incluye varias herramientas adicionales que permiten aumentar la pro-
ductividad, tales como la creacin de mapas de navegacin, generacin
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 pginas 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 parmetros que se configuran para definir el
sitio Web que se est desarrollando, y en particular los del sitio local.
Aade algunas funciones predefinidas de Javascript, llamadas Beha-
viors, que facilitan mucho la inclusin de controles y efectos habitua-
les de los lenguajes basados en guiones (script) a desarrolladores que no
tiene conocimientos de programacin. En la figura 13.7 se puede ver la
lista de comportamientos definidos dentro de la pgina, los cuales son

fcilmente modificables y adaptables para que funcionen en alguno de
los navegadores ms utilizados.
Genera cdigo interpretable tanto por el servidor (por ejemplo, cdigo
PHP o cdigo JSP) como por el cliente, de manera que se puede conectar
las pginas generadas de forma muy sencilla con servidores de base de
datos, facilitando la generacin de pginas con informacin dinmica.
Coordina la edicin grfica y la edicin del cdigo esta muy lograda, de
manera que en todo momento la visin grfica y textual de la pgina se
corresponden totalmente. Esto permite a los programadores y disea-
dores experimentados aadir elementos al HTML no soportados de
manera visual por Dreamweaver.
FIGURA 13.6. Ventana para la definicin del sitio local en Dreamweaver.

FIGURA 13.7. Ventana para la definicin del comportamientos en Dreamweaver.
13.4. AUTHORWARE
Authorware (Macromedia, 2003) es una herramienta de autor para la
creacin de sistemas Web y de sistemas de tele-educacin, que integra grfi-
cos, sonido, animacin, texto y vdeo dentro un sistema multimedia interac-
tivo. La interfaz de esta herramienta permite el desarrollo rpido de cual-
quier aplicacin utilizando mecanismo que agilizan el desarrollo, como por
ejemplo el uso de tcnicas de arrastrar y soltar (drag and drop).
Authorware se caracteriza por emplear una lnea de flujo para la defini-
cin de la estructura y de la participacin de los distintos contenidos multi-
media en la aplicacin, haciendo las veces de flujo de programa. En la figura
13.8 se puede ver el entorno de desarrollo de esta herramienta y la ejecucin
de la aplicacin en la ventana inferior izquierda. Para la definicin de este
ejemplo se han utilizado varios niveles, cada uno de los cuales tiene una lnea
de ejecucin. En la figura se muestran tres distintas, cada una de ellas en un
nivel diferente. Haciendo una similitud con la programacin imperativa cada
una de estas lneas correspondera a un subprograma de un programa. Cada
lnea de flujo contiene una serie de iconos que se corresponden con las accio-
nes que se tienen que llevar a cabo cuando la ejecucin de la aplicacin llegue
al punto que representa.
Authorware permite la publicacin de los contenidos tanto en formato

CD como en formato Web, aadiendo al servidor todas las extensiones nece-
sarias para poder visualizar las presentaciones realizadas en cualquier nave-
gador a travs 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. Adems, Authorware ofrece una opcin para
poder realizar la publicacin 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 razn las ltimas versiones dan soporte a los lti-
mos estndares de tecnologa educativa, como AICC y SCORM, lo que facili-
ta la integracin de sus contenidos en cualquier plataforma de LMS (Learning
Management System).
FIGURA 13.8. Una aplicacin de Authorware.

FIGURA 13.9. Pantalla de configuracin de Authorware.
13.5. LA TECNOLOGA FLASH

La tecnologa Flash (OpenSWF, 2003) es una creacin de la empresa
Macromedia que permite el desarrollo de contenidos multimedia con carac-
tersticas avanzadas, tales como la sincronizacin, la animacin, el sonido y
la interactividad. A diferencia de los casos anteriores, Flash no es una herra-
mienta de autor concreta sino una tecnologa que ha tenido un gran auge en
los ltimos tiempos que se est convirtiendo en un estndar de facto para la
creacin de contenidos multimedia para la Web.
Aunque originalmente esta tecnologa nace ligada a los productos de
Macromedia, en la actualidad hay herramientas de otras empresas que tam-
bin generan contenidos en el denominado formato Flash, que no es otra
cosa que un formato de datos denominado SWF. Los dos principios bsicos
de este formato son:
para el almacenamiento de los contenidos utiliza la tecnologa vectorial y
es compatible con tecnologa de streaming, lo que permite empezar a
visualizar la informacin 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 instalacin en dicho navegador de un
conector (plug-in) que reconozca el formato de las animaciones. En el caso de
la compaa Macromedia, este conector se denomina Flash Player y puede
obtenerse gratuitamente en el sitio Web de la compaa (Macromedia, 2003).
En los siguientes subapartados se introducen los conceptos bsicos de
esta tecnologa para, a continuacin, describir una herramienta de autor
para esta tecnologa: 3D Flash Animator.
13.5.1. Caractersticas de Flash
En las aplicaciones multimedia, la sincronizacin en el tiempo es un elemen-

to esencial en la mayora de los casos (Daz y otros, 2001), como ya se coment
en el captulo 5 (seccin 5.2). En Flash para indicar cmo los elementos de la apli-
cacin participan en ella se utiliza una lnea de tiempo, dividida en fotogramas:
Lnea de tiempo (Timeline). Es la zona en la que se controla la
secuencia de aparicin de los diferentes elementos (grficos, textos,
sonidos, etc.)
Fotograma (Frame). Es cada uno de los momentos que componen la
lnea de tiempo (anlogos a los fotogramas de las pelculas). Para cada uno
de ellos se especifican los objetos que aparecen y qu caractersticas tienen.
Debido a esa sincronizacin temporal, un determinado elemento como
una imagen, puede que aparezca en algunos fotogramas y en otros no. Para
conseguirlo, una tcnica habitual es crear varias capas en la animacin, de
forma que stas pueden ocultarse, mostrarse o superponerse, consiguiendo
los efectos de aparicin o desaparicin de los elementos.
Capas (Layers). Las capas son como lminas 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 ratn, fundamentalmente), provocando reacciones de la
aplicacin a tales interacciones. Tcnicamente, los sucesos que recibe la apli-
cacin 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 estmulo que provoca una reaccin en el siste-
ma como pueden ser pulsar el ratn o una tecla.
Accin (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 edicin 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 animacin 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:
imgenes de mapas de bits;
guiones (scripts), que son fragmentos de programa que sirven para aa-
dir interactividad a las presentaciones, y,
sonidos.
Estos objetos se pueden combinar en una lnea de tiempo, de manera que

se sincronizan como se puede ver en la figura 13.11, en la que cinco objetos
estn posicionados en una lnea de tiempo junto a un evento y diversas esce-
nas que nos permiten definir esas relaciones temporales entre los elementos.
La ejecucin de este proyecto consiste en:
1. La imagen red sky aparece en la escena 1, justo al empezar la anima-
cin.
2. A los dos segundos, comienza a sonar Chiquito y adems se mues-
tra, con efecto de explosin, la imagen desert night sky.
3. A los dos segundos, comienza la escena 3, y se muestra cloudy blue sky.
Simultneamente, 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 ttulo 3D.
FIGURA 13.11. La lnea de tiempo de Flash Animator.

13.6. DIRECTOR
Director (Macromedia, 2003) es una herramienta de Macromedia que
facilita el desarrollo de sistemas interactivos basndose en el uso de la met-
fora del cine. Por esta razn, cuando el desarrollador realiza un proyecto tie-
ne que pensar en los elementos que participan en una pelcula, tales como el
escenario, el reparto de actores y el guin:
El escenario es el espacio en el que se desarrollan las acciones.
Los actores son los contenidos multimedia que participan en la pelcu-
la, siendo por lo tanto el reparto una lista de contenidos.
El guin define cundo y dnde deben aparecer cada uno de los acto-
res sobre el escenario, describiendo las acciones que ocurrirn en la
pelcula.
En la figura 13.12 se muestra la apariencia de una aplicacin desarrolla-
da con Director, as como las ventanas que corresponden al reparto de acto-
res (cast) y al guin de la pelcula (score).
FIGURA 13.12. El entorno de desarrollo de Director.

Director permite utilizar como actores contenidos en la mayora de los

formatos multimedia existentes, tales como RealVideo, QuickTime, GIF,
SWF, etc., pudindose publicar en cualquier medio tanto esttico (por ejem-
plo, DVD) como dinmico (a travs de Shockwave player). Adems, como
puede incluir contenidos multimedia en formato Flash es posible incluir
complejos elementos multimedia sin necesidad de un alto coste de almace-
namientos/transmisin ya que se beneficia del uso de los grficos vectoriales
de los que hace uso esta tecnologa (seccin 13.5.1). Estos elementos se pue-
den gestionar de manera eficiente mediante Lingo, el lenguaje de programa-
cin que proporciona Director, pudiendo acceder desde la aplicacin a las
propiedades de ese contenido Flash. Lingo tambin ofrece al desarrollador la
posibilidad de gestionar todos los actores, as como de todas las caractersti-
cas de la pelcula.
13.7. RESUMEN
Este captulo ha presentado las herramientas de autor como aplicaciones
que facilitan la construccin de aplicaciones interactivas multimedia tanto a
expertos desarrolladores como aquellos que no sean tan experimentados.
Estas herramientas suelen proporcionar mecanismos de manipulacin direc-
ta, de manera que mediante simples movimientos de ratn se pueden crear
aplicaciones muy complejas.
En concreto, se han introducido un conjunto de herramientas de autor
con caractersticas muy distintas como son:
ToolBook, que se basa en el uso de la metfora del libro y que tiene un
potente lenguaje de guin denominado OpenScript.
Dreamweaver, que es un editor visual de documentos Web, tanto
HTML como XML, y que permite la creacin de documentos estticos
y dinmicos.
Authorware, que utiliza una lnea de flujo en la que se localizan iconos
que representan los objetos que aparecen en la pantalla.
Flash, que es una tecnologa que usan muchas herramientas como 3D
Flash Animator en la que los objetos multimedia se sincronizan en una
lnea de tiempo.
Director, que tiene como base la metfora 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-
raccin:
a) Computacin ubicua.
b) Computacin vestible.
c) Manipulacin directa.
d) Realidad virtual.
13.2. Qu elemento es caracterstico de las herramientas de autor?

a) Lenguajes de programacin imperativos.
b) Interfaces tangibles.
c) Editores de contenidos multimedia.
d) La metfora 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 metfora de las pginas de un libro?

a) Director.
b) Dreamweaver.
c) Flash Animator.
d) ToolBook.
13.9. REFERENCIAS BIBLOGRFICAS

ASYMETRICS (2003): ToolBook. Accesible en http://www.asymetrics.com
DAZ y otros (1996): Paloma Daz, Nadia Catenazzi e Ignacio Aedo. De la multimedia
a la hipermedia. Ed. Rama, Madrid, 1996.
DAZ y otros (2001): Paloma Daz, Ignacio Aedo y Fivos Panetsos. Modeling the dyna-
mic behavior of hypermedia applications. IEEE Transactions on Software Engi-
neering, vol 27 (6), Junio 2001, pgs 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/
VNNEN (1995): Metaphor-based User Interfaces for Hyperspaces. Eds. Schuler, W.,
Hannemann, J. y Streiz, N. Designing User Interface for Hypermedia. Springer
Verlag (Alemania), pgs. 68-78.
3dfa (2993): 3D Flash Animator. Accesible en http://www.3dfa.com/
Captulo 14
LENGUAJES DE MARCADO
Y DE PRESENTACIN
ESQUEMA
14.1. Lenguajes de marcado genricos.

14.2. Lenguajes de presentacin.
14.3. Modelado de mundos virtuales utilizando VRML.
14.4. Resumen.
En el mundo de los documentos en papel, el trmino marcado hace refe-
rencia a la manera en la que el editor anota los manuscritos con especifica-
ciones tipogrficas y otros datos sobre su presentacin. En los documentos
electrnicos, el marcado es el trmino empleado para describir los cdigos,
denominados tambin etiquetas, aadidos al texto electrnico que definen la
estructura y el formato en el que tiene que aparecer. Puede ser utilizado, ade-
ms, para propsitos muy diferentes como son la escritura, la impresin, el
intercambio, la presentacin 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 heterogneas. Los lenguajes estndar propor-
cionan una manera de solventar este hecho, ya que son independientes de la
aplicacin y de la plataforma hardware, empleando para marcar el documen-
to, en la mayora de los casos, cdigo ASCII.
Cuando se habla de lenguajes de marcado, es importante distinguir entre
la estructura lgica y fsica del documento.
DEFINICIN: La estructura lgica.

La estructura lgica est formada por las partes que lo componen y por sus
relaciones.
DEFINICIN: La estructura fsica.

La estructura fsica indica la apariencia del documento, ya sea en el papel o sobre
la pantalla, incluyendo sus componentes fsicos, el posicionamiento de los elemen-
tos y la tipografa empleada.
En la figura 14.1 se pueden ver algunos de los componentes que describen

la lgica y la estructura fsica del documento.
Estructura Lgica Tipos de Marcado Estructura Fsica
Identificador de Captulo Captulo Diecinueve Palatino 14. Centrado

Nombre Captulo Ttulo Palatino 14. Centrado. Negrita
Prrafo Captulo Este es el primer prrafo del captulo diecinueve. Courier 12.
Identificador de Seccin Seccin 1 Helvtica 14. Centrado

Nombre Seccin Ttulo Seccin 1 Helvtica 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 Seccin Seccin 2 Helvtica 14. Centrado

Nombre Seccin Ttulo Seccin 2 Helvtica 14. Centrado. Negrita
Prrafo Seccin Aqu vendra un texto explicativo de lo que viene Courier 12. Izquierda
a continuacin.
Courier 10.
Lista de
Elementos
Courier 10. Izquierda. Negrita

Etiqueta 4: Elemento n de la lista
FIGURA 14.1. Estructura lgica versus estructura fsica en el documentos.
En este captulo se presentan un conjunto de lenguajes de marcado

que se utilizan habitualmente en los entornos Web y algunos lenguajes de
presentacin que permiten adaptar la presentacin de la informacin
contenida en esos documentos. Adems, y para finalizar, se presenta el
VRML como lenguaje de modelado que permite la definicin de mundos
virtuales que permiten al usuario navegar por la informacin en tres
dimensiones.
14.1. LENGUAJES DE MARCADO GENRICOS
Los lenguajes de marcado genrico describen la estructura de un docu-

mento y sus atributos, sin especificar el proceso que se debe realizar sobre l.
DEFINICIN: Los lenguajes de marcado genricos.

Los lenguajes de marcado genricos son aquellos que sirven para especificar
la estructura de cualquier documento sin tener en cuenta los aspectos relativos
a la presentacin.
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 continuacin se
LENGUAJES DE MARCADO Y DE PRESENTACIN 385
presentan los lenguajes ms conocidos y que se utilizan para la publicacin en

Web.
14.1.1. SGML
SGML (Standard Generalized Markup Language) es un ejemplo de lengua-
je genrico 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 diseo
de los documentos era de mxima importancia. El objetivo que persegua era
proporcionar una manera normalizada de transmitir los documentos en un
formato adecuado para los procesos de edicin e impresin. SGML es apro-
piado para describir texto altamente estructurado, aunque tambin se pue-
den incluir en los documentos otros elementos, como por ejemplo diagramas
y grficos, independientemente de su formato de codificacin.
SGML contiene las reglas para crear una infinita variedad de lenguajes de
marcado, pero no describe el formato de los documentos marcados. Una defi-
nicin similar clasifica a SGML como un sistema para especificar lenguajes de
marcado, es decir, un metalenguaje. Esto hace posible que, mediante la utili-
zacin de una definicin de tipo de documento (denominada DTD Document
Type Definition), se pueda especificar la estructura lgica de una clase de
escrito.
DEFINICIN: DTD (Document Type Definition).

Una DTD es una definicin 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 genrico, que define el tipo del elemento (por ejemplo, prrafo,
cabecera o figura) y unas caractersticas, o atributos, que cualifican al identi-
ficador. En concreto una DTD define:
los identificadores genricos 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 raz es el propio
documento. Un ejemplo de cmo podra aparecer un elemento en una DTD
se puede ver en la tabla 14.1. Antologa, poema, ttulo, estrofa y lnea son los
identificadores genricos de los elementos. El elemento antologa se define
mediante un conjunto de poemas (poema+). Cada tem en el grupo necesita,

a su vez, una mayor definicin, hasta llegar a elementos terminales que no se
subdividen en otros.
TABLA 14.1. Definicin de una antologa de poemas en una DTD

<!ELEMENT antologia - - (poema+)>
<!ELEMENT poema - - (titulo?, estrofa+)>
<!ELEMENT titulo - - (#PCDATA) >
<!ELEMENT estrofa - - (linea+) >
<!ELEMENT lnea - - (#PCDATA) >
No es nico el documento que cumple esa DTD sino que pueden ser
muchas las antologas de poemas que se publiquen. Por esa razn puede
haber muchos documentos que cumplan la misma DTD, aunque no debera
haber ms que una DTD para un tipo de documento. A continuacin se pre-
senta un ejemplo de documento que cumple la DTD anterior (tabla 14.2).
A partir de la definicin 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 cdigo en alguno(s) de los lenguajes que se mencionan a continuacin (por
ejemplo, Macromedia DreamWeaver). De esta forma el programador no se
preocupa ni de la sintaxis ni de la semntica asociada a los cdigos concretos
si no que mediante lenguajes visuales establece la estructura, el contenido y
la apariencia de los hiperdocumentos que conforman su aplicacin. Algunos
de los lenguajes de marcado ms 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 ms poemas -->
<antologia>
14.1.2. HTML (Hypertextual Markup Language)

HTML es una aplicacin 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
versin de HTML es la 4.01 siendo una recomendacin no una especificacin
ya que no se lleg a un acuerdo total sobre ella. Esta norma ha ido desvir-
tundose de tal manera que adems de elementos conceptuales como pueden
ser los enlaces, contiene tambin elementos de presentacin (por ejemplo, el
elemento para poner en negrita un texto).
Todos los documentos que cumplen la norma HTML, por tanto, siguen la
especificacin de una DTD concreta que es interpretable por los navegadores
que existen en la actualidad. En este proceso de interpretacin, el navegador
se encarga de transformar cada una de las marcas que definen la estructura
del documento en una representacin fsica que el usuario pueda compren-
der. En el ejemplo siguiente, se muestra una pgina HTML que muestra la
estructura fundamental de un documento y, a su derecha, su visualizacin
utilizando un navegador, tabla 14.3.
TABLA 14.3. Un ejemplo de HTML

<HTML>
<HEAD>
<TITLE>Ttulo de mi pgina</TITLE>
<META name=autor content=Pepe>
</HEAD>
<BODY>
Este es un ejemplo de pgina web:<BR>
<IMG src=><BR>
</BODY>
</HTML>
FIGURA 14.2. La representacin 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 informacin relativa al
documento como puede ser meta-informacin que es informacin sobre la
informacin o un ttulo que se utilizar por el navegador en la lista de pgi-
nas visitadas o como ttulo de la ventana que muestra el documento. En la
parte del cuerpo se incluir toda la informacin 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 continuacin del texto se mues-
tre en la lnea 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 extensin de SGML que especifica un conjunto de concep-

tos bsicos con los que se puede definir la estructura lgica de documentos
hipertextuales y multimedia. HyTime normaliza aquellos mecanismos que se
refieren a la localizacin de porciones de documentos hipermedia y sus com-
ponentes multimedia de informacin, incluyendo enlaces, alineamiento en el
espacio y sincronizacin en el tiempo, es decir, proporciona una manera
homognea 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 aplicacin que las haya
creado, y se ocupa de normalizar la estructura del documento y la identifica-
cin de los objetos de informacin que lo conforman. HyTime, por tanto, no
establece los contenidos del hiperdocumento, ni la codificacin de la infor-
macin, ni los objetos, ni la aplicacin 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 estn imponiendo.
14.1.4. XML (Extensible Markup Language)
XML es una aplicacin de SGML, lo que significa que en su especifica-

cin 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 continuacin los conteni-
dos concretos asociados a cada elemento. Un ejemplo de construccin de
aplicaciones con XML es el desarrollo de normas para tipos concreto de
documentos, como puede ser un libro electrnico. Una iniciativa en este cam-
po, el desarrollo de una DTD para libros electrnicos a partir de XML, es
OpenEBook, un estndar en el que numerosas empresas del sector bibliogr-

fico estn trabajando de manera que con una misma plataforma se puedan
leer, comprar, distribuir, etc. libros electrnicos que tengan un formato
comn.
La descripcin de la DTDs se hace de una forma muy similar a como se
hace en SGML como se puede apreciar en la siguiente definicin, 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 descripcin 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-
cacin, se localizar en primer lugar donde se encuentra su especificacin y,
a continuacin, se realizar esa comprobacin, tabla 14.5.
TABLA 14.5. Ejemplo de documento que cumple la DTD del ejemplo de la tabla 4
<?XML versin=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>Captulo 1</CHAPTER_NUMBER>
<CHAPTER_TEXT>
<p>Este libro es el que voy a escribir</p>
<p>Aunque todava no se de qu va</p>
</CHAPTER_TEXT>
</CHAPTER>
</PART>
</BOOK>
14.1.5. XHTML (The Extensible Hypertext Markup

Language)
XHTML es una nueva definicin de HTML a partir de XML. Este lengua-

je se basa en la redefinicin de las DTDs de HTML versin 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 especificacin,
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 especificacin (por ejemplo, no se
cierra la etiqueta <html> o no se abre la etiqueta <head>), y su representacin
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>Ttulo de mi pgina</TITLE>
<BODY>
Este es un ejemplo de pgina web:<BR>
<IMG src="oso.gif"><BR>
</BODY>
FIGURA 14.3. Representacin grfica 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 minsculas.

Todos los elementos de XHTML deben cerrarse, incluidos aquellos que
sean una nica etiqueta.
Adems, permite la inclusin de programas dentro de su contenido
siguiendo el modelo de objetos que define la especificacin DOM (Document
Object Model), la cual permite actualizar y modificar los contenidos, estruc-
tura y estilo de los documentos de forma dinmica.
Los documentos XHTML estn 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 descripcin 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 caracterstica de presentacin sino
caractersticas 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 transicin, que indica que se quiere usar las caractersticas de pre-
sentacin de HTML porque se va a visualizar en navegadores que no
pueden utilizar caractersticas 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 continuacin se muestra un ejemplo de documento XHTML (tabla 7),
que cumple estrictamente la especificacin de XHTML y que tiene como
resultado la misma pgina que se ha presentado anteriormente, aadindole
el icono que representa que el documento cumple estrictamente la especifi-
cacin 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>Ttulo de mi pgina</title>
</head>
<body>
<p>
Este es un ejemplo de pgina 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 visualizacin 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 definicin 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, vdeos, sonidos, programas, etc.) y descri-
bir la presentacin en la pantalla. SMIL (se pronuncia smile sonrisa) no es
una solucin que intente competir con tecnologas existentes de representa-
cin multimedia (por ejemplo, Quicktime o Flash) sino que lo que pretende es
integrar esas tecnologas de manera estndar para que puedan combinarse.
Existen numerosos visualizadores de documentos SMIL que permiten

mostrar todas sus caractersticas. Algunos de los ms conocidos son: Real-
Player, Quicktime Player (la versin gratuita slo permite ver documentos
muy sencillos) y GRINS Player. Adems, algunos navegadores Web, como
Internet Explorer, permiten visualizar tambin estos documentos.
Un documento SMIL se compone de una cabecera (HEAD) y un cuerpo
(BODY). En la cabecera se definen tanto la metainformacin del documento
como informacin relativa a como deben aparecer en la pantalla los elemen-
tos de informacin. En el cuerpo del documento se incluirn 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 simultnea (par) tres conteni-
dos, un vdeo, una imagen y un sonido. Adems, se indica que el video se
muestre en la regin 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 visualizacin 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 mviles a travs de redes ina-
lmbricas. Se ver cmo 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 inalmbrico 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 telfonos mviles, pero tam-
bin 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 aplicacin en nuestro ordenador personal. Por
ello, en ocasiones se har referencia a cualquiera de estos dispositivos con el
trmino general agente de usuario en lugar de hablar exclusivamente de los
telfonos mviles.
Los documentos escritos en WML pueden accederse mediante URLs, de
manera similar a cmo se hace con las pginas HTML. Para ello, se necesita
un navegador WML, que puede estar empotrado en un telfono mvil o ser

un emulador que se utiliza desde un ordenador personal. En la figura 14.6 se
puede ver uno de estos emuladores de telfono mvil, en concreto del telfo-
no Nokia 6210, el cual se puede utilizar para navegar por esas pginas.
FIGURA 14.6. Ejemplo de emulador de un telfono mvil para acceder a documentos WAP.
Adems de los emuladores a travs de la Web, hay otros que pueden ins-
talarse en el ordenador personal, y que son en ocasiones ms fciles de utili-
zar, como por ejemplo, DeckIt (http://www.pyweb.com/tools/). Una vez des-
cargado e instalado no slo se podr navegar con l sino que puede ir
mostrando el cdigo WML mientras se navega (figura 14.7).
El lenguaje WML es un lenguaje de descripcin de pginas que permite
definir la presentacin de la informacin en el telfono mvil, solicitar entra-
das del usuario y responder a ciertas interacciones del usuario con el mvil,
como puede ser la pulsacin 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 estn formados una definicin 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 continuacin, se presenta una ejemplo
de documento WML que incluye una nica carta en el mazo y su visualiza-
cin (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 visualizacin 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. Representacin visual del documento de la tabla 14.9.

Todos estos ejemplos de lenguajes de marcado se basan en la definicin

de la estructura de los elementos, indicando cules existen en el dominio del
documento y como participan en l, es decir lo que anteriormente se ha deno-
minado lenguajes de marcado genricos. Pero estos lenguajes de marcado se
complementan con otros lenguajes que se utilizan para describir cual es la
apariencia final en el soporte fsico de visualizacin.
14.2. LENGUAJES DE PRESENTACIN

Manteniendo en mente la separacin entre los contenidos del documento
y la presentacin del documento, hasta el momento se han mostrado una
panormica de los primeros. A continuacin, se presentan una serie de len-
guajes que permiten realizar el segundo de los procesos, la presentacin, de
manera que se pueda homogeneizar la visualizacin de los documentos inde-
pendientemente del contenido que incluyan.
DEFINICIN: Los lenguajes de presentacin.

Los lenguajes de presentacin son aquellos que sirven para definir las caractersticas
de presentacin que finalmente tendr la informacin 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-
tacin 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 combinacin con HyTime indicando
la apariencia de los objetos definidos en sus documentos.
14.2.2. CSS Cascading Style Sheets

Otro ejemplo, de uso ms extendido, es CSS que define la apariencia de
los elementos HTML o XML que se muestran en un navegador Web. La idea
bsica en este tipo de lenguaje es el uso de la pgina fsica sobre la que se defi-
nen algunas caractersticas de su apariencia, como puede ser la posicin de
un contenido o la tipografa utilizada.
14.2.3. XSL Extensible Stylesheet Language

Un paso ms adelante es XSL que, ampliando las ideas de los dos lengua-
jes anteriores y basando su descripcin en XML, permite la definicin de la
presentacin de documentos XML. El proceso de construccin 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 ordenacin de una lista, inclusin de un ndice de conteni-
dos, etc.). En el segundo paso, se prepara el documento para ser presentado
en el dispositivo de visualizacin (navegador, impresora, telfono mvil, etc.)
adaptndolo a las caractersticas propias del dispositivo.
Para realizar la primera de las tareas, la transformacin, se utiliza el len-
guaje XSLT (XSL Transformations) que describe las reglas de transformacin
asociando patrones con plantillas de manera que cada transformacin 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 transformacin 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 presentacin

del documento, consiste en relacionar los elementos que conforman el docu-
mento con la presentacin 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 informacin.
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 funcin del grado de
inmersin 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 jardn de rosas si se recrea el aroma, el tacto, el espacio, etc. Es
decir, no se trata de una mera representacin grfica tridimensional esttica,
sino ms 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 inmersin 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 ratn, 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
definicin 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 carcter grfico, y por lo tan-
to, bastante ms 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 planificacin, as como una cierta
habilidad para la programacin.
La manera ms 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 ms 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 tendra 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: presentacin de objetos (diseo), explicacin del funciona-
miento o del montaje, robtica. Ejemplo: diseo de distintos artefactos
mecnicos en:
http://www.bergen.org/Present/TechnologyHighSchool/Active/
design_projects.html
Arte: galeras, msica, escenas, instalaciones virtuales. Ejemplo: Museo
de la Casa de la Moneda (Espaa) en:
http://www.fnmt.es/esp/museo/evisita.htm
Ciencia: astronoma, fsica, qumica, matemticas, medicina, etc.
Ejemplo: modelos moleculares complejos en:
http://www.ch.ic.ac.uk/rzepa/vrml/
Cultura: museos y bibliotecas virtuales reconstruccin arqueolgica,
teatro. Ejemplo: Museo interactivo de la Casa de la Moneda en Espaa:
http://www.fnmt.es/esp/museo/evisita.htm
Educacin: presentacin de temas, interaccin, bibliotecas. Ejemplo:
sistema educativo sobre las barreras arquitectnicas para discapacita-
dos en:
http://www.health.uottawa.ca/vrlab/start.html
Comercio electrnico: galeras comerciales, demostracin de produc-
tos, grficos comerciales, aplicaciones interactivas para construir el
producto (v.g. disee su cocina). Ejemplo: joyera 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-
sin .wrl. Este fichero constituye un documento VRML, que ser ejecutado por
el visualizador, de manera completamente anloga a los documentos HTML,
que son ficheros de texto con la extensin .html y que son ejecutados por los
navegadores para visualizar las pginas del Web. Tambin se pueden crear
estos documentos utilizando ciertos programas editores de VRML, que los
generan automticamente, sin necesidad de saber programar en este lenguaje.
En lneas generales, un documento VRML contiene los siguientes elemen-
tos: lnea de cabecera, que contiene informacin sobre la versin de VRML se
est utilizando; escena, que es un grafo de nodos que describe las caractersti-
cas y comportamiento de los elementos de presentacin; prototipos, que per-
miten al diseador 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 definicin de mundo virtual,
en concreto de un mesa con cuatro patas, y de su visualizacin 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 visualizacin del mundo virtual de la tabla 11.
14.4. RESUMEN
En este captulo 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 definicin de la estructura del documento y
los orientados a su presentacin. Entre los primeros, los de definicin de la
estructura del documento, se considera que SGML es el padre del conjunto de
lenguajes que se estn utilizando en la actualidad para crear aplicaciones para
Web, como por ejemplo HTML, XML y XHTML. Los lenguajes de presentacin
se encargan de presentar la informacin 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 afirmacin es la correcta:
a) Un lenguaje de marcado sirve nicamente para dar formato a los
contenidos de un documento.
b) Un lenguaje de marcado genrico sirve para indicar cuales son los

elementos de presentacin del documento.
c) Existe un lenguaje de marcado de la presentacin 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 afirmacin 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 minsculas.
c) HyTime es una aplicacin 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 presentacin 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) Slo 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 creacin de realidad virtual de escritorio.
d) VRML es una aplicacin de SGML.
15.5. Qu tipo de lenguaje de marcado es el ms 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://wwww3c.org.
Captulo 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. Telediagnstico y otros servicios multimedia en medicina: proyecto EMERALD
15.4. VIDEOSERVER: Experiencia en la Universidad de Kosice.
15.5. Sistemas de telepesentacin y emisin remota de vdeo.
15.6. Resumen.
Como se ha visto a lo largo del libro, las aplicaciones multimedia se
caracterizan esencialmente por la combinacin de datos independientes de
diferentes tipos, entre los cuales se encuentran medios continuos, como el
vdeo o el audio, y medios discretos, como el texto o los grficos. Ahora bien,
esa sencilla caracterizacin incluye a aplicaciones que pueden pertenecer a
dominios muy diversos, como la medicina, la educacin, el entretenimiento
e incluso el arte, y esas aplicaciones pueden tener adems caractersticas
muy diferentes: pueden ser aplicaciones hipermedia en la Web, simples pre-
sentaciones, aplicaciones de trabajo cooperativo, etc. Por otro lado, el domi-
nio de aplicacin 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 caractersticas 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 descripcin 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 aplicacin como el aspecto ms importante del sis-
tema.
En este captulo, se describen ejemplos de desarrollo de sistemas multi-
media concretos, con el objetivo de ofrecer una panormica de los mtodos,
tcnicas y herramientas de desarrollo que pueden utilizarse.
15.1. TIPOS DE APLICACIONES MULTIMEDIA
La descripcin y comprensin de aplicaciones multimedia concretas se

realiza ms fcilmente si se posee una visin global de qu tipos de aplica-
ciones multimedia se pueden encontrar. Obviamente, no existe una nica y
definitiva clasificacin de aplicaciones multimedia, sino que atendiendo a
distintos criterios pueden existir distintas taxonomas, todas ellas vlidas.
Por ejemplo, se pueden clasificar las aplicaciones de acuerdo a qu actores
interactan mediante el uso de la aplicacin, ya sean personas o sistemas, o
de acuerdo al dominio de la aplicacin, ya sea educativo, ldico, dedicado a

la presentacin, etc. En esta seccin se describirn algunas de estas posibles
taxonomas para poder clasificar las aplicaciones que se describen en el res-
to del captulo en funcin de las mismas.
Como ya se ha descrito, las aplicaciones multimedia se pueden clasificar
de acuerdo a qu actores interactan gracias al uso de la aplicacin, 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 aplicacin son al menos dos humanos, y por
lo tanto el objetivo principal de la aplicacin suele ser facilitar la
comunicacin 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 informacin
multimedia.
Como se puede deducir de las caractersticas de esta primera divisin a
alto nivel, esta taxonoma est especialmente indicada para clasificar aplica-
ciones multimedia de red.
A su vez estos dos grandes grupos se subdividen en varios ms (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 divisin ms representativa que se puede realizar del tipo es de acuerdo al
carcter sncrono o asncrono de las aplicaciones.
Las aplicaciones sncronas son aquellas en las que tanto el/los usuarios
emisores de la comunicacin como el/los usuarios receptores deben estar
presentes en el mismo instante de tiempo, para poder llevar a cabo una
comunicacin 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 comunicacin 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 comunicacin multimedia bidireccional entre dos o ms grupos
de personas.
En las aplicaciones asncronas las personas no tienen por qu estar
conectadas simultneamente para poder comunicarse informacin multime-
dia. Ejemplos de este tipos de aplicaciones son las aplicaciones de correo
electrnico con soporte multimedia o las listas de distribucin con soporte
para contenidos multimedia.
EJEMPLOS DE DESARROLLO DE SISTEMAS MULTIMEDIA 409
Aplicaciones de
comunicacin
interpersonal
Aplicaciones de
Aplicaciones
distribucin
Aplicaciones para la sncronas
comunicacin entre
personas Aplicaciones de
teleconferencia en
grupo
Aplicaciones
asncronas
Aplicaciones
Multimedia Aplicaciones de
respuesta simple
Aplicaciones
interactivas Aplicaciones de
interaccin mltiple
Aplicaciones para la
comunicacin entre
personas y sistemas Aplicaciones de
distribucin a grupos
cerrados
Aplicaciones de
distribucin
Aplicaciones de
distribucin a grupos
abiertos
FIGURA 15.1. Taxonoma de aplicaciones, de acuerdo a actores que se comunican

mediante ella.
Las aplicaciones multimedia para la comunicacin entre personas y sis-

temas se pueden dividir segn el tipo de acceso que se haga al sistema multi-
media en aplicaciones interactivas o aplicaciones de distribucin.
En las aplicaciones interactivas el usuario es siempre el que inicia la
interaccin con el sistema, que no tiene porqu realizarse en tiempo real.
As, un usuario puede pedir informacin en un momento dado como ocu-
rre, por ejemplo, en aplicaciones de video bajo demanda, sin necesidad
de que el sistema haya iniciado la comunicacin y sin restriccin en cuan-
to a cundo debe responder el usuario a cualquier indicacin del sistema.
Una vez que el usuario ha iniciado la interaccin 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 interaccin finaliza cuando el sistema
produce una respuesta a la peticin inicial del usuario, como ocurre en los
sistemas de recuperacin de informacin multimedia, o aplicaciones de
interaccin mltiple, que son aquellas donde la interaccin continua a lo
largo de la sesin, que es el caso habitual en aplicaciones multimedia edu-
cativas, por poner un ejemplo.
Cuando se habla de aplicaciones de distribucin se hace referencia a apli-

caciones multimedia donde la interaccin la inicia el sistema multimedia, y
bien puede tratarse de aplicaciones de distribucin a grupos cerrados o gru-
pos abiertos. En las aplicaciones de distribucin a grupos cerrados el sistema
inicia la interaccin slo si el usuario pertenece a un determinado grupo,
como ocurre, por ejemplo, en aplicaciones que sirven contenidos multimedia
(peridicos o no) a sus suscriptores vase algunos servidores de noticias o
listas de distribucin o en aplicaciones que sirven contenidos a usuarios de
un determinado perfil dentro de un grupo. En las aplicaciones de distribu-
cin a grupos abiertos no se requieren que el destinatario de la informacin
pertenezca a ninguna categora en especial.
Otra forma tpica de clasificar las aplicaciones multimedia es respon-

diendo al dominio de la aplicacin. Un clasificacin que responde a este cri-
terio es la que puede consultarse en (Gibbs y Tsichritzis, 1995). Segn esta
clasificacin, existen diversas categoras de aplicaciones multimedia: jue-
gos electrnicos, sistemas de presentacin multimedia, herramientas de
autor para contenidos multimedia, sistemas de mensajera multimedia, sis-
temas de conferencia multimedia o aplicaciones de servicios multimedia,
que a su vez pueden dividirse en aplicaciones de servicios mdicos, de ser-
vicios bancarios, aplicaciones educativas o aplicaciones de comercio in-
teractivo, por citar algunas. Cabe destacar que los tipos establecidos en la
clasificacin que hacen Gibbs y Tsichritzis no pueden considerarse exclu-
yentes, puesto que una aplicacin pueden pertenecer a ms de uno; por
ejemplo, se puede considerar una aplicacin multimedia educativa comple-
ja que incluya juegos y un sistema de presentacin de contenidos, por poner
un caso.
En la actualidad se estn ultimando otro tipo de taxonomas, como ETNA

(siglas en ingls de Taxonoma para la Evaluacin 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 taxonoma es disponer de un mtodo para determinar el
nivel de calidad de video y audio que requieren las distintas aplicaciones mul-
timedia. Para conseguir tal fin, la clasificacin se realiza de acuerdo a crite-
rios que tienen impacto en dicha calidad, como la actividad o tarea para la
que est diseada la aplicacin, 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 pases han visto en la Web un potencial medio de
difusin cultural para sus recursos, que permite llegar a una audiencia ms
amplia. Por ello, muchas de estas instituciones han habilitado el acceso a sus
catlogos o colecciones a travs de Internet. Actualmente, se considera que la
simple publicacin de elementos en catlogos no explota todo el potencial de
la interaccin con el navegador, y carece de elementos narrativos que facili-
ten an ms la difusin a audiencias de ndoles diversas (Vergo y otros, 2002).
As, han comenzado a aparecer muestras o exposiciones guiadas virtua-
les temticas que mejoran la experiencia de los usuarios mediante un flujo
narrativo continuo combinado con informacin contextual.
En esta redaccin 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 difusin cultural.
El objetivo del proyecto (Nickerson, 2002) es dar a conocer la historia de
la regin de la meseta del Colorado a travs de grabaciones e imgenes 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 presentacin 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 slo de audio,
pero otras, como la que se muestra en la figura 15.3 combinan audio con sub-
ttulos, msicas de fondo y la sucesin de las imgenes en movimiento de la
zona que ilustran el discurso en primera persona.
FIGURA 15.3. Narracin histrica sincronizada en primera persona.
Por tanto, la aplicacin permite el acceso por tres criterios (correspon-

dientes a las tres secciones principales) a una coleccin de presentaciones
multimedia en primera persona que utilizan diferentes combinaciones de
tipos multimedia.
Es importante resaltar que la tecnologa subyacente a esta presenta-
cin es un servidor Web estndar, habiendo sido desarrolladas las pre-
sentaciones con la herramienta Flash 5 de Macromedia, y utilizando com-
presin MPEG para combinar varios canales de sonido. El equipo de
desarrollo estaba formado por estudiantes con conocimientos de publica-
cin en Web y multimedia, y los expertos de las diferentes instituciones
participantes trabajaron colaborativamente utilizando tcnicas tan sim-
ples como el correo electrnico o el protocolo de transferencia de ficheros
FTP.
15.3. TELEDIAGNSTICO Y OTROS SERVICIOS MULTIMEDIA

EN MEDICINA: PROYECTO EMERALD
La multimedia est teniendo un amplio campo de aplicacin en los servi-
cios mdicos. Concretamente se construyen sistemas de informacin mdica
integrados para cubrir reas como la captura de imgenes o videos digitales

de gran calidad y su posterior retransmisin entre servicios hospitalarios o
incluso entre hospitales con objeto de facilitar el telediagnstico en funcin
de datos de distinta naturaleza (radiografas, tomografas, resonancias mag-
nticas, etc.).
Uno de los proyectos ms recientes en esta lnea es el proyecto europeo
EMERALD (Servicios Multimedia Europeos para imgenes mdicas, Europe-
an Multimedia Services for Medical Imaging) (Rahms y otros, 1997). El prin-
cipal objetivo de dicho proyecto es la creacin de un servicio mdico multi-
media avanzado que facilite el trabajo cooperativo y la coordinacin 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 radiologa, la cardio-
loga, la mamografa y la radiociruga. En la figura 15.4 se puede observar
una videoconferencia desarrollada en el escenario de radiologa, llevada a
cabo con EMERALD.
FIGURA 15.4. Sesin de videoconferencia con visualizacin de radiografas.

Para todos los escenarios actuales de uso la aplicacin dispone de un con-

junto de servicios comunes como videoconferencias, soporte para trabajo en
grupo, transmisin de ficheros de datos, digitalizacin de audio y video,
almacenamiento, recuperacin mediante consultas, visualizacin y procesa-
miento de informacin multimedia de acuerdo al estndar DICOM (Figura
15.5) y mensajera multimedia.
FIGURA 15.5. Aplicacin del proyecto EMERALD, procesamiento y visualizacin

de imgenes digitales.
En cuanto al tipo de aplicacin, y teniendo en cuenta que se trata de un

sistema integrado, EMERALD se puede considerar de distinto tipo segn
el uso que se haga de ella. Dentro de las aplicaciones de servicios multi-
media mdicos, la aplicacin contiene servicios sncronos, como la video-
conferencia, asncronos, como la mensajera electrnica multimedia, e
interactivos, como la recuperacin y procesamiento de imgenes e histo-
rias clnicas.
EMERALD hace uso del protocolo IP sobre ATM, y soporta codificacin
de video a 15 fps, siguiendo el estndar JPEG con un ratio de transmisin
de 2 a 5 Mbits/s. Como ya se ha indicado, la transmisin de imgenes mdi-
cas se realiza bajo el estndar DICOM 3.0, que define cmo se deben comu-
nicar los equipos de tomas de imgenes mdicas, as como especifica qu
datos que se necesitan del paciente y de la imagen mdica y que formato
deben tener.
15.4. VIDEOSERVER: EXPERIENCIA EN LA UNIVERSIDAD

DE KOSICE
Otro tipo de aplicacin multimedia muy comn es la implementacin de
servidores de video. Se va a presentar a continuacin una implementacin
concreta llevado a cabo en la Universidad de Kosice (Eslovaquia) diseada
para almacenar presentaciones de video con otro soporte de presentacin
multimedia, como es la visualizacin de transparencias creadas con Power-
Point. La aplicacin 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 estn llevando a cabo
sesiones como acceder a contenidos multimedia de grabaciones en video corres-
pondientes a una clase o sesin informativa. Para asistir virtualmente a un aula se
puede consultar la planificacin de reservas de dichas aulas as como consultar
los datos de la sesin que tendr lugar (figura 15.6). Teniendo en cuenta este ser-
vicio de la aplicacin, sta se puede considerar una aplicacin educativa de tipo
sncrono, ms concretamente se trata de una aplicacin persona-grupo, puesto
que la comunicacin es sncrona y unidireccional, del profesor o ponente al gru-
po que conforma su audiencia virtual, permitiendo igualmente la asincrona ya
que almacena las sesiones de manera que se pueden visualizar posterioremente.
FIGURA 15.6. Aulas virtuales en Videoserver y la planificacin de su ocupacin.

La segunda funcionalidad que permite la aplicacin es la de visualizar

sesiones de eventos anteriores. El usuario puede seleccionar la sesin que
desee dentro de una coleccin organizada por eventos y, mientras se muestra
el video de la sesin tambin se puede visualizar la presentacin multimedia
que el profesor o ponente utilizara en su momento (figura 15.7). Desde el
punto de vista de este servicio, la aplicacin Videoserver se puede catalogar
como una aplicacin interactiva de respuesta simple.
FIGURA 15.7. Visualizacin de una sesin almacenada con Videoserver. En la parte

izquierda de la pantalla aparece la reproduccin de video y en la parte derecha
se muestran las transparencias utilizadas en la sesin.
La aplicacin est construida sobre tecnologas Microsoft Media. Se ha

utilizado Windows Media Tools para la creacin 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 tecnologas que permiten el flujo inteligente (intelligent data stre-
aming), es decir, que la transmisin del flujo de medias se ajusta al ancho de
banda de la conexin que establece el usuario, permitiendo que incluso para

una conexin realizada con mdem, la calidad de la reproduccin en el clien-
te sea adecuada.
15.5. SISTEMAS DE TELEPRESENTACIN Y EMISIN

REMOTA DE VDEO
Uno de las utilidades ms recientes de la multimedia es la retransmisin

de video en tiempo real. Aplicaciones que permitan llevar a cabo estas fun-
ciones son de sumo inters 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 grabacin hacen falta profesionales que graben
en cada momento de la conferencia lo ms adecuado, ya sea el conferencian-
te, la proyeccin 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 grabacin en una sala de conferencias teniendo en
cuenta todos estos factores. La arquitectura del sistema, como la de cualquier
aplicacin multimedia (Captulo 10), est formada por una capa hardware y
una capa software.
La capa hardware est formada por diferentes cmaras, micrfonos y
los ordenadores que lo controlan, mientras que la capa software (adems de
los sistemas operativos y controladores necesarios para la transmisin en
red) contiene mdulos que permiten la correcta grabacin de los que acon-
tece en la sala. Ms concretamente, el sistema que se describe consta de
cuatro cmaras (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 cmara tiene
asociado un ordenador que la controla y que gracias a mdulos software
juega el papel del hombre-cmara. Cada uno de estos ordenadores est
conectado con otro que hace las veces de director. Entre los hombres-
cmara y el director se produce el intercambio de rdenes necesario
para obtener una grabacin lo ms correcta y profesional posible. Las rde-
nes estn programadas en funcin de los estados de cada hombre-cmara
y sobre la base de una serie de reglas obtenidas de profesionales humanos.
El director, una vez obtenidas las secuencias de los hombres-cmara
las mezcla y codifica para su transmisin y posterior visualizacin tanto en
multidifusin como bajo demanda.
FIGURA 15.8. Arquitectura en bloques de la aplicacin de grabacin automtica

de Rui y otros.
La aplicacin que se est describiendo ha sido evaluada tanto por cma-

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 cmaras e incorporar nue-
vas reglas y estados al sistema. La evaluacin se llev a cabo permitiendo la
grabacin simultnea tanto por el sistema como por los profesionales huma-
nos, de manera que los posibles usuarios podan 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 aplicacin

de teletrasmisin de Rui.
15.6. RESUMEN
En este captulo se realiza una descripcin general de algunas aplicacio-
nes multimedia concretas con objeto de que el lector tenga un espectro
amplio de cmo se han desarrollado y para qu fin. Para ello se hace necesa-
rio partir de algn tipo de taxonoma que permita clasificar la aplicacin des-
crita de acuerdo a un determinado criterio.
En el primer apartado se han esbozado algunas de estas taxonomas.
Con mayor detalle se describi cmo se pueden clasificar aplicaciones de
acuerdo al tipo de actores entre los que media la aplicacin, ya sean perso-
nas o sistemas. Tambin se ha mencionado ms someramente la existencia
de otras clasificaciones que responden a criterios como el dominio de la
aplicacin o a cmo se lleva a cabo la tarea para la que se dise la aplica-
cin, el tipo usuario que la realiza y las condiciones ambientales en las que
se desarrolla.
La primera aplicacin que se describe es un ejemplo de aplicacin multi-
media para la exhibicin de patrimonio cultural. Se trata de una aplicacin
desarrollada en Flash 5.0 y con compresin MPEG para dar a conocer la
regin e historia de las mesetas de Colorado (EEUU).
El segundo caso que se describe muestra cmo una aplicacin multime-
dia se puede utilizar en el mbito mdico. 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 diagnsticos en cua-
tro servicios hospitalarios distintos utilizando redes ATM y servicios de vi-
deoconferencia, transmisin, almacenamiento y procesamiento de video e
imgenes digitales entre otros.
A continuacin se muestr una aplicacin que permite almacenar y recu-
perar videos a travs de Internet as como conectarse a aulas virtuales para
poder visualizar lo que ocurre en su interior. La arquitectura de esta aplica-
cin est ntegramente diseada utilizando tecnologa Windows Media, tan-
to para la generacin de contenidos como para el suministro de servicios y
acceso en el cliente.
Por ltimo se describi una sistema multimedia para la difusin de video.
En este ejemplo se muestra una arquitectura multimedia cubriendo tanto sus
capas hardware como las software. El sistema automatiza la grabacin de lo
que ocurre en un lugar de reunin mediante un sistema controlado por reglas
obtenidas de profesionales humanos. La grabacin puede ser visualizada en
tiempo real o bajo demanda.

15.1. De que tipo es la aplicacin de telepresentacin descrita en la seccin 4?
a) Aplicacin de comunicacin entre personas sncrona de comunica-
cin interpersonal.
b) Aplicacin de comunicacin entre personas asncrona.
c) Aplicacin para la comunicacin entre personas y sistemas.
d) Aplicacin para FNS.
15.2. Cul 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 comunicacin interpersonal no son aplicacio-
nes interactivas.
d) Las aplicaciones no tienen que ser interactivas.
15.3. Cul de las siguientes aplicaciones es cierta respecto a la aplicacin

descrita en la seccin 2?
a) La aplicacin utiliza un servidor Web especializado con streamming
de vdeo.
b) La aplicacin est basada en el formato Flash de presentaciones
multimedia.
c) El desarrollo de la aplicacin se realiz utilizando herramientas de
autor colaborativas.
d) El sistema WGF es el ms completo.
15.4. Cules de estas afirmaciones son ciertas respecto a la aplicacin des-

crita en la seccin 3?
a) La aplicacin est basada en el estndar DICOM que define cmo se
deben comunicar los equipos de captura de imgenes mdicas.
b) La aplicacin est basada en el estndar DICOM que especifica el pro-
tocolo TCP/IP sobre redes ethernet como requisito de comunicacin.
c) Es una aplicacin que no permite ningn tipo de comunicacin sn-
crona.
d) El sistema VRF no es operativo en WWW.
15.5. Cul de las siguientes afirmaciones es falsa respecto a la aplicacin

descrita en la seccin 15.4?
a) La aplicacin VIDEOSERVER es una aplicacin de comunicacin

entre personas que permite la comunicacin sncrona.
b) La aplicacin VIDEOSERVER es una aplicacin de comunicacin
entre personas que permite la comunicacin asncrona.
c) La aplicaciones est construida con tecnologas especializadas de
streamming de vdeo.
d) La aplicacin permite tener dos presentaciones simultneas 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), pgs. 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, GENCI y CECH, 2002) Jakab, F., Genci, J y Cech, A.: Experimental Videoserver
implementation at Technical University of Ko_ice. International Conf. On Inform-
taion Technology Based Higher Education and Training ITHET02, 2002. pgs.
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., Martnez, F., Fraile, E., Garca-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 CHI2003.
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 AUTOCOMPROBACIN:
Captulo 1:
1.1. b)
1.2. b)
1.3. d)
1.4. a)
1.5. b)
Captulo 2:
2.1. d)
2.2. b)
2.3. c)
2.4. a)
2.5. a)
Captulo 3:
3.1. a)
3.2. d)
3.3. b)
3.4. a)
3.5. c)
Captulo 4:
4.1. b)
4.2. c)
4.3. c)
4.4. a)
4.5. b)
Captulo 5:
5.1. a)
5.2. c)
5.3. b)
5.4. c)
5.5. d)
Captulo 6:
6.1. b)
6.2. d)
6.3. c)
6.4. b)
6.5. d)
Captulo 7:
7.1. b)
7.2. b)
7.3. d)
7.4. b)
7.5. d)
ANEXO 427
Captulo 8:
8.1. c)
8.2. b)
8.3. d)
8.4. c)
8.5. b)
Captulo 9:
9.1. b)
9.2. d)
9.3. c)
9.4. b)
9.5. d)
Captulo 10:
10.1. b)
10.2. a)
10.3. d)
10.4. c)
10.5. d)
Captulo 11:
11.1. d)
11.2. d)
11.3. b)
11.4. a)
11.5. c)
Captulo 12:
12.1. b)
12.2. d)
12.3. a)
12.4. c)
12.5. d)
Captulo 13:
13.1. c)
13.2. c)
13.3. b)
13.4. a)
13.5. d)
Captulo 14:
14.1. d)
14.2. c)
14.3. c)
14.4. c)
14.5. d)
Captulo 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 Informtica por la Universidad Politcnica de Madrid
lleva trabajando en el campo de la hipermedia desde 1990, participando en numerosos proyectos
internacionales, nacionales y regionales tanto con financiacin pblica como privada en el rea
de sistemas interactivos. Es autor de ms de cien artculos y congresos tanto nacionales como
U.D. internacionales, siendo adems miembro del consejo editor de la revista IFETS&IEEE LTTF
Journal of Educational Technology and Society. En la actualidad es catedrtico de Universidad del
Departamento de Informtica de la Universidad Carlos III de Madrid.
Unidad Didctica
Paloma Daz Prez es licenciada y doctora en Informtica por la Universidad Politcnica
A. Colmenar Santos M. A. Castro Gil

de Madrid, siendo en la actualidad catedrtica de Universidad del Departamento de Informtica
J. Peire Arroba
de la Universidad Carlos III de Madrid. Sus intereses se centran en el proceso de desarrollo de
F. Mur Prez
sistemas interactivos as como en la incorporacin de las tecnologas de la informacin y de las
comunicaciones en el proceso de aprendizaje, habiendo participado en numerosos proyectos
Colecciones de la UNED relacionados con estos temas. Adems, es autora de numerosos artculos internacionales en las
revistas ms prestigiosas en los mbitos de su inters (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 informticos y con la hipermedia. Es miembro del
Cada vez son ms y mejores las herramientas de edicin comit ejecutivo de IEEE Learning Technology Task Force.
Unidades Didcticas multimedia disponibles en el mercado a precios razonables. Miguel ngel Sicilia Urbn es doctor Ingeniero en Informtica por la Universidad Carlos
III de Madrid e Ingeniero en Informtica por la Universidad Pontificia de Salamanca. Ha
Cuadernos de la UNED Sin embargo, el mayor problema est en la formacin adecuada
M. A. Sicilia Urbn 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 imprecisin y
con este libro presentar, de forma clara y sistemtica, las lneas la incertidumbre.
Estudios de la UNED de accin principales de anlisis, diseo y evaluacin de una Alfonso Vara de Llano es Ingeniero Industrial por la Escuela Tcnica Superior de Ingenieros
Industriales de la Universidad Politcnica de Madrid, en la especialidad Electricidad, intensificacin
Actas y Congresos aplicacin multimedia. Electrotecnia. Actualmente es gerente de Proyectos en la Divisin de Servicios Profesionales de
Compaq, recientemente fusionada con Hewlett Packard. Anteriormente ha trabajado como Jefe
Estudios de Educacin a Distancia La obra Sistemas Multimedia: anlisis, diseo y evaluacin de Proyectos en UITESA (actualmente integrada en IBERINCO perteneciente a al grupo
IBERDROLA) y como ingeniero en el Laboratorio de Ensayos Dinmicos de Vehculos
va permitir al lector interesado: Ferroviarios de RENFE. Es profesor asociado de la E.T.S. de Ingenieros Industriales de la UNED
Educacin Permanente Analizar los requisitos de los sistemas multimedia, y su
y sido durante 1 ao profesor asociado en la E.T.S. de Ingenieros Industriales de la Universidad
I. Aedo Cuevas
Politcnica de Madrid y durante 4 aos profesor asociado en la Escuela Politcnica Superior de
la Universidad Carlos III de Madrid.
P. Daz Prez
integracin en los sistemas de informacin actuales. Antonio Colmenar Santos es doctor Ingeniero Industrial e Ingeniero Industrial, especialidad
Identificar los distintos componentes de stos, as como Electrnica y Automtica por la ETSII de la UNED e Ingeniero Tcnico Industrial por la Escuela
Universitaria de Ingeniera Tcnica Industrial de la Universidad de Valladolid, especialidad
las distintas plataformas de distribucin existentes: CD- Electricidad, intensificacin Electrnica, Regulacin y Automatismos. Actualmente es Profesor
titular en el rea de Ingeniera Elctrica del Departamento de Ingeniera Elctrica Electrnica
ROM, Intranet, Internet, etc. y de Control DIEEC de la UNED. Ha sido profesor asociado en el Departamento de Tecnologa
Promover la capacidad de diseo de sistemas, su

interrelacin con la interfaz de usuario y los requisitos
SISTEMAS MULTIMEDIA: Electrnica en la Universidad Politcnica de Alcal de Henares y en el DIEEC de la UNED.
Es profesor titular en excedencia del cuerpo de Profesores de Educacin Secundaria y de Profesores
Tcnicos de Formacin Profesional en las especialidades de Sistemas Electrnicos y Equipos
Elctricos, respectivamente. Ha trabajado para la AECI-ICI como experto asesor en el proyecto
INTECNA (Nicaragua). Es miembro de la seccin espaola de la International Solar Energy
del mismo.
Evaluar los diferentes sistemas multimedia utilizados en
Ingeniera
en Informtica
ANLISIS, DISEO Society (ISES) y ha trabajado en diferentes proyectos relacionados con las energas renovables.
Ha pertenecido a la Association for the Advancement of Computing in Education. Es experto en
aplicaciones de Sistemas Multimedia y posee diferentes publicaciones prcticas apoyndose en
estas tcnicas. Actualmente, es Coordinador de Virtualizacin en la ETSII de la UNED.
los actuales sistemas de informacin.
Para ello se incluyen los siguientes contenidos temticos: (2 ciclo) Y EVALUACIN Pablo Losada de Dios es Ingeniero Tcnico de Telecomunicaciones por la Escuela
Universitaria de Ingenieros Tcnicos de Telecomunicacin de la Universidad Politcnica de
Madrid, en la especialidad de Imagen y Sonido. Ha obtenido el Premio a los mejores Materiales
Didcticos en Ciencias Experimentales del Consejo Social de la UNED en 1998. Posee los
Medios tradicionales y medios digitales de la informacin ttulos de Postgrado de Especialista Universitario en Comunicaciones: Redes, Servicios e InfoVa,
Desarrollo de Aplicaciones Multimedia: Aplicaciones para InfoVa y Sistemas de Gestin de
(textos, sonidos, imagen, animacin, vdeo, 3D, etc.). Bases de Datos, todos otorgados por la UNED. Ha realizado los cursos oficiales de Microsoft
de administracin y gestin de Redes NT. En la actualidad trabaja en la UNED como Tcnico
Anlisis, diseo, evaluacin y direccin de proyectos de Especialista para el apoyo informtico del profesorado del Departamento de Ingeniera Elctrica,
Electrnica y de Control de dicha Escuela, colaborando en proyectos del departamento,
sistemas multimedia y de la interfaz de usuario. impartiendo cursos de formacin y realizando la gestin y el soporte de los servidores del
Departamento.
Plataformas de difusin (CD-ROM, Intranet, Internet,
etc.). Integracin de sistemas multimedia en la www.
Ignacio Aedo Cuevas Francisco Mur Prez es doctor Ingeniero Industrial por la Escuela Tcnica Superior de
Ingenieros Industriales de la UNED e Ingeniero Industrial, especialidad Electricidad, intensificacin
La obra incluye adems, como valor aadido, un tema Paloma Daz Prez Electrnica y Automtica por la Escuela Tcnica Superior de Ingenieros Industriales de la
Universidad Politcnica de Madrid. Ha obtenido el Premio Extraordinario de Doctorado de la
especfico de direccin y metodologa de proyectos multimedia. Miguel ngel Sicilia Urbn UNED. Ha obtenido el Premio a los mejores Materiales Didcticos en Ciencias Experimentales
del Consejo Social de la UNED en el ao 1999. Actualmente es profesor titular en el Departamento
ANLISIS, DISEO Y EVALUACIN

de Ingeniera Elctrica, Electrnica 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 Tcnica Superior
de Ingenieros Industriales de la Universidad Politcnica de Madrid (UPM) e Ingeniero Industrial,
Antonio Colmenar Santos especialidad Electricidad, intensificacin Electrnica y Automtica, 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 aportacin a la Investigacin Cientfica sobre Aplicaciones de la
Electricidad en los Procesos Industriales. Ha obtenido el Premio a los mejores Materiales
Didcticos en Ciencias Experimentales del Consejo Social de la UNED en los aos 1997 y
Francisco Mur Prez
1999. Ha recibido el premio a la "Innovative Excellence in Teaching, Learning & Technology"
del "Center for the Advancement of Teaching and Learning" del ao 2001. Actualmente es
Catedrtico de Universidad del rea de Tecnologa Electrnica en el Departamento de Ingeniera
ISBN 84-362-4996-8
Manuel Alonso Castro Gil Elctrica, Electrnica y de Control, ETSII de la UNED, a la vez que es Vicerrector de Nuevas
Tecnologas de la UNED. Ha sido Director del Centro de Servicios Informticos de la UNED
Juan Peire Arroba y Subdirector de Investigacin y Doctorado, y de Gestin Acadmica de la ETSII. Ha participado
en numerosos proyectos de investigacin 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 lneas de investigacin y docencia. Ha trabajado cinco
aos 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 direccin de ISES Espaa.
Juan Peire Arroba es doctor Ingeniero Industrial por la Escuela Tcnica Superior de
Ingenieros Industriales de la Universidad Politcnica de Madrid e Ingeniero Industrial, especialidad
Electricidad por la misma Escuela. Licenciado en Derecho por la Universidad Complutense de
Madrid. Actualmente es Catedrtico de Universidad del rea de Tecnologa Electrnica en el
Departamento de Ingeniera Elctrica, Electrnica y de Control, ETSII de la UNED. Ha sido
Director del Departamento. Ha obtenido el Premio a los mejores Materiales Didcticos en
Ciencias Experimentales del Consejo Social de la UNED en los aos 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 ao 1999. Ha trabajado varios aos como Consultor
especializado en la creacin de Empresas Tecnolgicas, as como ha dirigido y dirige diversos
UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA proyectos de investigacin, tanto nacionales como internacionales. Es miembro del IEEE.

Sistemas Multimedia

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Sistemas Multimedia

Enviado por

Direitos autorais:

Formatos disponíveis

55521UD01A01 55521UD01A01 55521UD01A01 Ignacio Aedo Cuevas es doctor en Informtica por la Universidad Politcnica 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 Urbn P. Losada de Dios

Promover la capacidad de diseo de sistemas, su

ANLISIS, DISEO Y EVALUACIN

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA

Quedan rigurosamente prohibidas, sin la autorizacin escrita

Librera UNED: Bravo Murillo, 38; 28015 Madrid

1.1. La comunicacin a distancia .......................................................... 21

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

3.1. Las animaciones. Principios, herramientas y tcnicas de animacin . 70

4.1. Ingeniera del software y multimedia............................................... 110

5.1. La etapa de anlisis de requisitos en el desarrollo multimedia...... 136

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

6.3. Estilos de la interaccin .................................................................... 171

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

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

9.1. Now-Graduado: ejemplo de anlisis y diseo .................................. 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 programacin multimedia .......................... 333

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

13.5. La tecnologa Flash .......................................................................... 373

14.1. Lenguajes de marcado genricos .................................................... 384

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

El trmino que aparece con mayor frecuencia en los medios de comuni-

apretar un botn de vez en cuando. Es la caracterstica que les distingue, por

modelado, animacin, render y composicin, y proporcionan algunos conse-

rrollo goza de todas las caractersticas que definen un proyecto en su sentido

mercado, no se pretende elaborar un catlogo de la mismas, sino que se ha

1.1. La comunicacin a distancia.

1.1. LA COMUNICACIN A DISTANCIA

1.1.1. Las primeras telecomunicaciones

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

como los cambios tecnolgicos provocan modificaciones sociales, y vicever-

1.1.2. El telgrafo ptico

As, despus de las seales luminosas, se produce ya entrado el siglo XVIII

suponerse, para transmitir un mensaje, que necesariamente deba ser corto,

1.1.3. El telgrafo de seales elctricas

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

Cuesta imaginar, lo que sera hoy da transmitir la informacin a distan-

Pero ser en el ao 1837 cuando se va a producir un avance significativo

1.1.4. La radio y el telfono

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

transmiti con la TV en color, por supuesto tambin mecnica! En 1937 la

1.1.6. La electrnica al servicio de la comunicacin

Queda por explicar la parte electrnica, cmo y cundo nace la electr-

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

1.2. LA REVOLUCIN DE LAS COMUNICACIONES. INTERNET

Si se analizan hoy da los peridicos aparecen casi a diario referencias a

A partir de esta fecha se suceden los cambios de denominacin y los usos

1.3. SISTEMAS Y PROCESADO DE LA INFORMACIN:

1.4. EL CONCEPTO DE MULTIMEDIA

vocablo multimedia y su evolucin desde varias mltiples perspectivas:

1.4.1. Perspectiva empresarial

Para autores centrados en la temtica de los Medios de Comunicacin de

1.4.2. Perspectiva de la pluralidad meditica

La pluralidad meditica al hablar de multimedia, destaca la literalidad

1.4.3. Perspectiva informtica

En muchos catlogos de productos informticos se encuentra el vocablo

1.4.4. Perspectiva contempornea

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

multimedia es un sistema que facilita todo el material de equipo y de pasos