sistemas multimedia analisis, diseño y evaluacion

Colecciones de la UNED

Unidades DidcticasCuadernos de la UNEDAula AbiertaEstudios de la UNEDActas y CongresosEstudios de Educacin a DistanciaEducacin Permanente

Ignacio Aedo Cuevas es doctor en Informtica por la Universidad Politcnica de Madridlleva trabajando en el campo de la hipermedia desde 1990, participando en numerosos proyectosinternacionales, nacionales y regionales tanto con financiacin pblica como privada en el reade sistemas interactivos. Es autor de ms de cien artculos y congresos tanto nacionales comointernacionales, siendo adems miembro del consejo editor de la revista IFETS&IEEE LTTFJournal of Educational Technology and Society. En la actualidad es catedrtico de Universidad delDepartamento de Informtica de la Universidad Carlos III de Madrid.

Paloma Daz Prez es licenciada y doctora en Informtica por la Universidad Politcnicade Madrid, siendo en la actualidad catedrtica de Universidad del Departamento de Informticade la Universidad Carlos III de Madrid. Sus intereses se centran en el proceso de desarrollo desistemas interactivos as como en la incorporacin de las tecnologas de la informacin y de lascomunicaciones en el proceso de aprendizaje, habiendo participado en numerosos proyectosrelacionados con estos temas. Adems, es autora de numerosos artculos internacionales en lasrevistas 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 relacionadoscon el proceso de desarrollo de sistemas informticos y con la hipermedia. Es miembro delcomit ejecutivo de IEEE Learning Technology Task Force.

Miguel ngel Sicilia Urbn es doctor Ingeniero en Informtica por la Universidad CarlosIII de Madrid e Ingeniero en Informtica por la Universidad Pontificia de Salamanca. Hadesarrollado su labor docente e investigadora en ambas Universidades, estando actualmente enla Universidad de Alcal de Henares. Ha trabajado como consultor, tutor y arquitecto softwareen diferentes empresas, y actualmente desarrolla su labor investigadora en el rea de hipermediaadaptativa y los sistemas educativos, con especial nfasis en el tratamiento de la imprecisin yla incertidumbre.

Alfonso Vara de Llano es Ingeniero Industrial por la Escuela Tcnica Superior de IngenierosIndustriales de la Universidad Politcnica de Madrid, en la especialidad Electricidad, intensificacinElectrotecnia. Actualmente es gerente de Proyectos en la Divisin de Servicios Profesionales deCompaq, recientemente fusionada con Hewlett Packard. Anteriormente ha trabajado como Jefede Proyectos en UITESA (actualmente integrada en IBERINCO perteneciente a al grupoIBERDROLA) y como ingeniero en el Laboratorio de Ensayos Dinmicos de VehculosFerroviarios de RENFE. Es profesor asociado de la E.T.S. de Ingenieros Industriales de la UNEDy sido durante 1 ao profesor asociado en la E.T.S. de Ingenieros Industriales de la UniversidadPolitcnica de Madrid y durante 4 aos profesor asociado en la Escuela Politcnica Superior dela Universidad Carlos III de Madrid.

Antonio Colmenar Santos es doctor Ingeniero Industrial e Ingeniero Industrial, especialidadElectrnica y Automtica por la ETSII de la UNED e Ingeniero Tcnico Industrial por la EscuelaUniversitaria de Ingeniera Tcnica Industrial de la Universidad de Valladolid, especialidadElectricidad, intensificacin Electrnica, Regulacin y Automatismos. Actualmente es Profesortitular en el rea de Ingeniera Elctrica del Departamento de Ingeniera Elctrica Electrnicay de Control DIEEC de la UNED. Ha sido profesor asociado en el Departamento de TecnologaElectrnica 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 ProfesoresTcnicos de Formacin Profesional en las especialidades de Sistemas Electrnicos y EquiposElctricos, respectivamente. Ha trabajado para la AECI-ICI como experto asesor en el proyectoINTECNA (Nicaragua). Es miembro de la seccin espaola de la International Solar EnergySociety (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 enaplicaciones de Sistemas Multimedia y posee diferentes publicaciones prcticas apoyndose enestas tcnicas. Actualmente, es Coordinador de Virtualizacin en la ETSII de la UNED.

Pablo Losada de Dios es Ingeniero Tcnico de Telecomunicaciones por la EscuelaUniversitaria de Ingenieros Tcnicos de Telecomunicacin de la Universidad Politcnica deMadrid, en la especialidad de Imagen y Sonido. Ha obtenido el Premio a los mejores MaterialesDidcticos en Ciencias Experimentales del Consejo Social de la UNED en 1998. Posee losttulos de Postgrado de Especialista Universitario en Comunicaciones: Redes, Servicios e InfoVa,Desarrollo de Aplicaciones Multimedia: Aplicaciones para InfoVa y Sistemas de Gestin deBases de Datos, todos otorgados por la UNED. Ha realizado los cursos oficiales de Microsoftde administracin y gestin de Redes NT. En la actualidad trabaja en la UNED como TcnicoEspecialista para el apoyo informtico del profesorado del Departamento de Ingeniera Elctrica,Electrnica y de Control de dicha Escuela, colaborando en proyectos del departamento,impartiendo cursos de formacin y realizando la gestin y el soporte de los servidores delDepartamento.

Francisco Mur Prez es doctor Ingeniero Industrial por la Escuela Tcnica Superior deIngenieros Industriales de la UNED e Ingeniero Industrial, especialidad Electricidad, intensificacinElectrnica y Automtica por la Escuela Tcnica Superior de Ingenieros Industriales de laUniversidad Politcnica de Madrid. Ha obtenido el Premio Extraordinario de Doctorado de laUNED. Ha obtenido el Premio a los mejores Materiales Didcticos en Ciencias Experimentalesdel Consejo Social de la UNED en el ao 1999. Actualmente es profesor titular en el Departamentode Ingeniera Elctrica, Electrnica y de Control, ETSII de la UNED.

Manuel-Alonso Castro Gil es doctor Ingeniero Industrial por la Escuela Tcnica Superiorde Ingenieros Industriales de la Universidad Politcnica de Madrid (UPM) e Ingeniero Industrial,especialidad Electricidad, intensificacin Electrnica y Automtica, por la misma Escuela. Haobtenido el Premio Extraordinario de Doctorado de la UPM as como el Premio Viesgo 1988a la Tesis Doctoral por la aportacin a la Investigacin Cientfica sobre Aplicaciones de laElectricidad en los Procesos Industriales. Ha obtenido el Premio a los mejores MaterialesDidcticos en Ciencias Experimentales del Consejo Social de la UNED en los aos 1997 y1999. 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 esCatedrtico de Universidad del rea de Tecnologa Electrnica en el Departamento de IngenieraElctrica, Electrnica y de Control, ETSII de la UNED, a la vez que es Vicerrector de NuevasTecnologas de la UNED. Ha sido Director del Centro de Servicios Informticos de la UNEDy Subdirector de Investigacin y Doctorado, y de Gestin Acadmica de la ETSII. Ha participadoen numerosos proyectos de investigacin como investigador, coordinador y director y ha publicadoen revistas y congresos, tanto nacionales e internacionales. Ha publicado igualmente diversoslibros y material multimedia dentro de sus lneas de investigacin y docencia. Ha trabajado cincoaos como Ingeniero de Sistemas en Digital Equipment Corporation. Pertenece al comitorganizador de los congresos internacionales IEEE FIE, ISES y TAEE, as como es revisor ypresidente 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 deIngenieros Industriales de la Universidad Politcnica de Madrid e Ingeniero Industrial, especialidadElectricidad por la misma Escuela. Licenciado en Derecho por la Universidad Complutense deMadrid. Actualmente es Catedrtico de Universidad del rea de Tecnologa Electrnica en elDepartamento de Ingeniera Elctrica, Electrnica y de Control, ETSII de la UNED. Ha sidoDirector del Departamento. Ha obtenido el Premio a los mejores Materiales Didcticos enCiencias Experimentales del Consejo Social de la UNED en los aos 1997 y 1999. Ha recibidoel premio a la "Innovative Excellence in Teaching, Learning & Technology" del "Center for theAdvancement of Teaching and Learning" del ao 1999. Ha trabajado varios aos como Consultorespecializado en la creacin de Empresas Tecnolgicas, as como ha dirigido y dirige diversosproyectos de investigacin, tanto nacionales como internacionales. Es miembro del IEEE.

I. A

edo

Cue

vas

P. D

az

Pre

zM

. A. S

icili

a U

rbn

A. V

ara

de L

lano

A. C

olm

enar

San

tos

P. L

osad

a de

Dio

s

F. M

ur P

rez

M. A

. Cas

tro

Gil

J. P

eire

Arr

oba

Ignacio Aedo CuevasPaloma Daz PrezMiguel ngel Sicilia UrbnAlfonso Vara de LlanoAntonio Colmenar SantosPablo Losada de DiosFrancisco Mur PrezManuel Alonso Castro GilJuan Peire Arroba

SISTEMAS MULTIMEDIA:ANLISIS, DISEOY EVALUACIN

UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIA UNIVERSIDAD NACIONAL DE EDUCACIN A DISTANCIASIST

EM

AS

MU

LTIM

ED

IA:

AN

LI

SIS,

DIS

E

O Y

EV

ALU

AC

IN

Ingenieraen Informtica(2 ciclo)

55521UD01A0155521UD01A01

ISBN 84-362-4996-8

Cada vez son ms y mejores las herramientas de edicinmultimedia disponibles en el mercado a precios razonables.Sin embargo, el mayor problema est en la formacin adecuadade los autores potenciales de trabajos multimedia. Se pretendecon este libro presentar, de forma clara y sistemtica, las lneasde accin principales de anlisis, diseo y evaluacin de unaaplicacin multimedia.

La obra Sistemas Multimedia: anlisis, diseo y evaluacinva permitir al lector interesado:

Analizar los requisitos de los sistemas multimedia, y suintegracin en los sistemas de informacin actuales.

Identificar los distintos componentes de stos, as comolas distintas plataformas de distribucin existentes: CD-ROM, Intranet, Internet, etc.

Promover la capacidad de diseo de sistemas, suinterrelacin con la interfaz de usuario y los requisitosdel mismo.

Evaluar los diferentes sistemas multimedia utilizados enlos actuales sistemas de informacin.

Para ello se incluyen los siguientes contenidos temticos: Medios tradicionales y medios digitales de la informacin

(textos, sonidos, imagen, animacin, vdeo, 3D, etc.). Anlisis, diseo, evaluacin y direccin de proyectos de

sistemas multimedia y de la interfaz de usuario. Plataformas de difusin (CD-ROM, Intranet, Internet,

etc.). Integracin de sistemas multimedia en la www.La obra incluye adems, como valor aadido, un tema

especfico de direccin y metodologa de proyectos multimedia.Esperamos que el lector vea cumplidas sus expectativas!

55521UD01A01

Uni

dad

Did

cti

caU.D.

Captulo 4

FASES DEL DESARROLLODE 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.4.6. Ejercicios de autoevaluacin.4.7. Referencias bibliogrficas.

El desarrollo de cualquier producto software es un proceso de ingenieraen el que se siguen una serie de fases de manera sistemtica para conseguirun producto de la mayor calidad posible. La ausencia de aplicacin este tipode mtodos bien definidos para el desarrollo de aplicaciones informticas diolugar en la dcada de los 70 a lo que comnmente se ha venido denominandodesde entonces crisis del software, convertida ya en afliccin crnica paraRoger Pressman, y que origin la aparicin de la ingeniera del softwarecomo la disciplina que propone la utilizacin de un enfoque sistemtico,disciplinado y cuantificable para el desarrollo, operacin y mantenimientodel 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, lamayor 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 deeste tipo de sistemas. Ms en concreto, suele argumentarse que debido alcarcter pluridisciplinar del equipo de desarrollo y la premura con la que sesuele 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 yen 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 porqu 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 caboun anlisis de esas caractersticas de los sistemas interactivos que hacenque no sea plausible la aplicacin de mtodos tradiciones, entendiendocomo tradicionales aquellos propios del desarrollo de sistemas de informa-cin. A continuacin se estudiarn, en la seccin 4.3, de forma escueta lasfases tpicas del proceso de desarrollo, puesto que algunas de ellas se abor-dan de forma completa en otros captulos, as como posibles modelos deproceso en la seccin 4.4.

4.1. INGENIERA DEL SOFTWARE Y MULTIMEDIA

Antes de pasar a estudiar en detalle las peculiaridades del proceso dedesarrollo de las aplicaciones multimedia, resulta conveniente repasar algu-nos conceptos propios de la ingeniera del software con el fin de establecer unvocabulario 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 queestas fases tengan que realizarse siguiendo una determinada secuencia. Elmodelo de proceso es el que establece una forma de trabajo concreta en fun-cin del paradigma adoptado (por ejemplo, en cascada, iterativo, en espiral oincremental).

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 delusuario 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 acabo durante cada una de las fases, qu productos o entidades de diseodeben generarse y tambin ofrece principios bsicos, guas o consejos paraproducir un software de mayor calidad. As, existen distintos modelos deproceso que determinan cmo llevar a cabo las distintas fases del desarro-llo y, a su vez, para cada modelo de proceso existirn diversos mtodos queindicarn 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 delos productos software, independientemente del tipo de producto del que setrate, hace posible una aplicacin sistemtica de conocimiento cientfico conobjeto 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):

110 SISTEMAS MULTIMEDIA: ANLISIS, DISEO Y EVALUACIN

entender los objetivos y requisitos del producto a desarrollar,

disear interfaces adecuadas y estructurar la informacin de acuerdocon las necesidades del usuario,

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

gestionar el proceso de desarrollo de manera eficiente,

emplear mtricas que recojan aspectos del desarrollo con los que sepueda controlar su progreso,

documentar aspectos relevantes del desarrollo y

llevar a cabo un desarrollo que asegure que la aplicacin va a a ser fcilde mantener.

El objetivo fundamental ser pues obtener productos de calidad y llevar acabo 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, lareutilizacin, la facilidad de mantenimiento, la gestin del proceso y lasmedidas tanto del producto como del propio proceso.

4.2. CARACTERSTICAS DEL DESARROLLO MULTIMEDIA

Los sistemas interactivos y multimedia tienen caractersticas intrnsecasque 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 ciclode vida es preciso introducir una nueva fase: la evaluacin. El objetivo deesta 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 elpresente 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 cuentalas 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.

FASES DEL DESARROLLO DE SISTEMAS MULTIMEDIA 111

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 unasimplificacin del modelo propuesto por Roy Rada en (Rada, 1995).


FIGURA 4.1. Modelo simplificado de la interaccin entre el usuario y la mquina (basadoen 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 lainterfaz. El conocimiento sobre la tarea a realizar lo tiene la persona, que esrealmente quien sabe qu quiere hacer y cul es la secuencia de pasos aseguir para conseguir su objetivo. Cuando una persona se pone delante deuna mquina para completar una tarea, analiza las funciones que le ofrece elproducto software y realiza una accin orientada a conseguir su objetivo. Asu 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 laTabla 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 lapgina pero no encuentra uno que inserte la fecha fi tendr que escribirla 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 fechaha sido justificada a la izquierda.

Evaluacin El objetivo ha sido conseguido satisfactoriamente, luego se ha seguido elproceso 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 cabouna accin sobre la interfaz (la intencin) y, tras recibir la respuesta de laaplicacin, 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 resultadorecibido es el esperado, puede que el proceso seguido no sea el ptimo. Dehecho en el ejemplo mostrado, el usuario no se ha dado cuenta de que podraexistir una opcin para insertar la fecha directamente sin tenerla que escribirl, de forma que se eviten errores innecesarios.

El hecho de que el conocimiento de la tarea resida en el usuario y que lamquina deba responder de la manera que ste espera, lleva a la necesidad decontar con dicho usuario durante el proceso de desarrollo. El enfoque dedesarrollo que hace que el usuario y sus necesidades reales se conviertan enlas directrices del proceso de desarrollo de un producto software se conocecomo 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 susnecesidades.

El diseo centrado en el usuario, trmino acuado por Gould y Lewis en1985, tiene como objetivo maximizar la usabilidad del producto para lo cualse asumen cuatro principios bsicos (Gould y otros, 1997):


Focalizacin temprana y continua en el usuario: es preciso estudiarlas caractersticas cognitivas, antropolgicas, de actitud y los patronesde comportamiento de los usuarios. Para ello es preciso entender lanaturaleza 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 eldesarrollo.

Medidas empricas: los usuarios reales, o representantes de grupos deusuarios reales, deben enfrentarse a prototipos o maquetas del pro-ducto para llevar a cabo tareas, de tal forma que se puedan recoger yanalizar datos vlidos sobre la utilidad del sistema.

Diseo iterativo: el modelo de proceso debe permitir iteraciones enlas 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, yasea 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 forinteractive 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 emplearmtodos 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 teneren cuenta durante la planificacin de la participacin del usuario incluyen:

es preciso especificar desde el comienzo del desarrollo cundo y cmovan a participar los usuarios, ya sean stos expertos en el dominio de laaplicacin o usuarios reales,

hay que tener en cuenta que es conveniente tratar con el usuario en suentorno de trabajo, y,

la terminologa y la notacin a emplear deben ser familiares para elusuario o fciles de entender y de aprender, de tal manera que stesiempre comprenda lo que se le est mostrando y pueda contrastarlofrente a su conocimiento del entorno de la tarea.


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 valiosaentrada 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 mltiplesfacetas y, adems, no todas ellas son de carcter tecnolgico. As, de acuerdocon (Perece y otros, 1994) se puede ver un sistema interactivo formado poruna 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 ypor sus usuarios. Para comprender las necesidades del usuario se puedenrequerir conocimientos de psicologa, sociologa, antropologa e inclusofisiologa, 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 laintervencin de especialistas en diseo, ingeniera, lingstica o arte(Faulkner, 1998).


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

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 delsoftware 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 eldesarrollo 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 Webampliadas de Hansen y otros, 2001

Miembro del Labor Habilidades/Conocimientosequipo

Usuarios Aportar opiniones Conocimiento de la tarea ay experiencia de uso del realizar y del dominio en queproducto. se lleva a cabo la misma.

Proveedores de Producir contenidos Principios de usabilidad,contenidos multimedia. creatividad, diseo grfico y

multimedia, etc.


FIGURA 4.3. Visin modular de un sistema interactivo.

(Continua)

TABLA 4.2. (Continuacin)

Miembro del Labor Habilidades/Conocimientosequipo

Ingenieros del Publicar el material en Web. Bases de datos, cgis, html yWeb de nivel 1 lenguajes de programacin y(publicadores) marcado para Web (HTML,

XML, XSL, SMIL, etc), etc.

Encargados del Actualizar y mantener losmantenimiento del contenidos de informacin. Uso de las bases de datos y/oWeb de lenguajes de marcado.

Administrador del Gestionar el servidor Web, ArquitecturasWeb responsabilizndose de su cliente/servidor,

eficiencia, integridad, comunicaciones, protocolos,seguridad, etc. mecanismos de seguridad,

etc.

Ingenieros del Analizar los requisitos, PlataformasWeb de nivel 2 producir la documentacin hardware/software existentes

del anlisis y del diseo, (caractersticas, limitaciones,establecer los procedimientos etc.), tcnicas dede 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 deWeb 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 tieneimplicaciones durante los procesos de planificacin y gestin del proyectomultimedia, sino tambin en el modelo de proceso y el mtodo de desarrolloelegidos, 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 unmtodo cuyas etapas y productos hagan posible analizar y disear cada una delas caractersticas del sistema. Las aplicaciones multimedia imponen algunosrequisitos en lo referente a las capacidades expresivas del modelo a utilizarque debe aunar ciertos aspectos cognitivos y estticos, tema que se abordarde manera detallada en el siguiente captulo. El mtodo de desarrollo debeofrecer productos que permitan modelar todas las caractersticas de las apli-


caciones multimedia, ya estn stas relacionadas con la forma en que debepresentarse la informacin, con la estructura lgica de la aplicacin, con lasposibilidades 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 DESARROLLOMULTIMEDIA

El proceso de desarrollo de aplicaciones multimedia conlleva la realiza-cin de una serie de actividades, independientemente de la secuencia que sesiga 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 fasescomo introduccin a los modelos de proceso presentados en la seccin 4.4.Se proporcionar ms informacin sobre cada fase, las actividades a realizaro 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 softwarees factible, tanto desde un punto de vista tcnico como prctico. En el caso deun sistema interactivo, es importante analizar la aceptacin que ste podratener antes de embarcarse en un complejo y costoso desarrollo. Aspectoscomo la adecuacin social del sistema o su utilidad prctica pueden tenerseen 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 losque 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 orequisitos 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 tieneconocimiento 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 odiscapacidades fsicas o cognitivas, la diversidad cultural, la edad, el sexo ocualquier 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 ahacer 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 teneren cuenta caractersticas ambientales, como la luminosidad o el ruido, a lahora de disear la interfaz de usuario.

El objetivo ltimo de esta fase es entender qu debe hacer el producto ygenerar una especificacin o pliego de requisitos en la que se recojan todaslas caractersticas funcionales, no funcionales y de usabilidad de la aplica-cin. Como se ver en el captulo 5 existen diversos mtodos para llevar acabo este estudio, entre las que se encuentran la realizacin de entrevistas, eluso 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 deberahacer sin entrar en cmo se va a desarrollar.

En general suele organizarse los requisitos de un sistema interactivo entres categoras:

Los requisitos de usabilidad determinan qu se va a entender por unnivel aceptable de utilizacin y de aceptacin del producto final porparte 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 uncurso interactivo multimedia.

TABLA 4.3. Ejemplos de requisitos para un curso multimedia

Tipo Requisito

Usabilidad El curso podr ser utilizado por alumnos sin conocimientos previosen la materia as como por alumnos que desean especializarse.

Funcional Se incluir un buscador que permita localizar informacin sobrelos contenidos del curso de forma eficiente.

No funcional El curso ser accedido masivamente de forma remota y utilizandouna conexin va mdem.

4.3.3. Diseo

El proceso de diseo consiste en convertir una especificacin de lo qu elproducto debe hacer en una propuesta, ms o menos formal, de cmo debehacerlo. Durante el diseo se va a especificar, en consecuencia, aspectos talescomo:

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 cadamomento, o

cmo se va a poder acceder al producto aplicando ciertas reglas deaccesibilidad 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 serdiscutidos 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 deusuarios que va a haber en un curso multimedia son interpretados utilizan-


do un diagrama propio de la metodologa para aplicaciones hipermediaAriadne (Daz y otros, 2001). En dicho diagrama se muestra grficamenteque 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 accesopara cada tipo de usuario, permite representar de forma no ambigua y cla-ra un requisito. Adems, se utiliza una notacin sencilla de aprender quepermite que el diagrama sea discutido en el seno de un equipo de desarro-llo pluridisciplinar as como con los propios usuarios, para comprobar si seha comprendido bien el requisito antes de invertir recursos en implementarun prototipo.

TABLA 4.4. Ejemplos de requisitos y su especificacin informal durante el diseopara un curso multimedia

Anlisis Diseo

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 tenerseen 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, comopor 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 losusuarios acceden a un curso virtual haciendo uso de un mdem, no eslgico plantear un diseo en el que se incluya la videoconferenciacomo principal medio de comunicacin.


Se va a dar acceso adistintos tipos deusuarios, incluyendoprofesores, tutores,alumnos, responsablesdocentes,desarrolladores decontenidos yadministradores.

Los usuarios se organizarn tal y como se muestra en el siguientediagrama que utiliza notacin UML para representar relacionesestructurales entre tipos de usuarios.

Restricciones cognitivas. Los usuarios tienen una caractersticas fsi-cas (agudeza visual, capacidad auditiva, etc.) y cognitivas (memoria acorto y largo plazo, capacidad de razonamiento y de resolucin de pro-blemas) que deben ser respetadas si se pretende construir un sistemautilizable (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 considerarcomo son aspectos legales, de seguridad o de autenticidad. As, no sepuede permitir por ejemplo que un curso virtual permite a sus usuariosacceder 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 queamalgamar distintos requisitos bajo una misma perspectiva. A la hora de rea-lizar el diseo pueden emplearse diferentes niveles de abstraccin y producirdiagramas o especificaciones conceptuales o incluso prototipos que ayuden aestablecer 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, esdecir identificar de qu conceptos se va a hablar o qu pantallas se van aincluir. Una aplicacin multimedia est formada por una serie de nodos ounidades indivisibles de presentacin en las que se incluyen varios conteni-dos. As, cada ventana o cada marco puede considerarse un nodo. Durante laetapa de definicin de la estructura se identificaran los nodos y la forma enque stos se secuencian. Adems, se determinarn los contenidos que se vana incluir en cada una de esos nodos, ya sean textos, grficos, dibujos, anima-ciones, simulaciones, mundos virtuales, msica, sonido o cualquier otro tipode contenido que se considere de utilidad para conseguir los objetivos delproducto.

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 describacmo debe ser el contenido y que haya que generar ste, pero tambin esposible 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 deseanincluir. En este caso el paso previo es la digitalizacin utilizando el hardwarey software adecuado. Una vez obtenido un archivo en formato digital se pasa-


r a retocar el contenido multimedia editndolo con herramientas softwareal efecto. Este proceso, ya sea de creacin o de digitalizacin y edicin, noslo requiere software y hardware especfico, sobre el que se puede consultaren los temas especficos de este libro, sino tambin de la participacin deespecialistas en diseo multimedia capaces de editar y generar contenidos decalidad.


FIGURA 4.4. Proceso de produccin de aplicaciones multimedia, ampliacinde la propuesta de (Lowe y Hall, 1999).

Una vez que se tiene la estructura y el contenido, basta con integrar loscontenidos 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 seencuentre 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 handiseado correctamente, detectando aquellas deficiencias que haya que sol-ventar o proponiendo mejoras.

Es muy importante tener presente que en ningn caso la evaluacin esuna 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 elproducto 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 conposibles fallos o errores en el cdigo.

La evaluacin es una fase tan importante en el desarrollo de sistemasinteractivos 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 uncomponente del mismo una vez que ya se ha entregado, ya sea para corregirerrores, 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 deldesarrollo se invierte en mantenimiento, cosa que en el caso de los sistemasmultimedia puede variar, especialmente cuando se trata de productos cerra-dos. En algunas ocasiones la aplicacin multimedia se concibe como un CDque una vez generado no va a evolucionar. Pero salvo en esos casos especfi-cos, las aplicaciones multimedia deben mantenerse como cualquier otro tipode producto software, un mantenimiento especialmente acusado en el casode los sitios Web.

El mantenimiento puede ser de tres tipos:

Adaptativo: es aquel que se produce para hacer frente a un entornocambiante. En los productos multimedia el mantenimiento adaptativoes crucial ya que las necesidades del usuario, incluidas las caractersti-


cas de la plataforma de acceso, estn en permanente evolucin, por loque habr que tener en cuenta nuevos requisitos.

Correctivo: es aquel que est destinado a solventar problemas que sehayan detectado durante el uso del producto. Si se ha seguido un pro-ceso iterativo, no debera ser preciso llevar a cabo un mantenimientocorrectivo pues todos los fallos de software o de interaccin deberanhaberse detectado en las fases de produccin y evaluacin, respectiva-mente. No obstante, es cierto que en muchas ocasiones es precisoentregar el producto antes de que se hayan llevado a cabo todas lasverificaciones y evaluaciones que seran necesarias, por lo que siguesiendo necesario este proceso que corrija los errores que se vayanencontrando.

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 ymodular el sistema para hacer ms eficiente su modificacin. Este tipode mantenimiento es tambin bastante habitual en las aplicacionesmultimedia.

4.4. MODELOS DE PROCESO PARA EL DESARROLLOMULTIMEDIA

Algunos de los paradigmas clsicos de modelo de proceso son (Amescuay otros, 1995):

El modelo en cascada, que exige finalizar una fase antes de poderpasar a la siguiente.

El modelo incremental, en la que se van construyendo versiones delsistema, cada una de las cuales hace frente a un subconjunto de losrequisitos.

Elmodelo 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.

Elmodelo en espiral, en el que se hace un desarrollo iterativo basadoen el anlisis de riesgos.

El modelo basado en transformaciones, que hace uso de herramien-tas CASE (Computer Aided Software Engineering) capaces de transfor-mar autom- ticamente la salida de cada fase en entrada de la siguiente.

El modelo basado en el uso de prototipos que ofrece una aproxima-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 nicoque 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 aldesarrollo de sistemas multimedia.

4.4.1. Diseo iterativo o modelo de proceso basado en el usode prototipos

El diseo iterativo es una aproximacin muy utilizada en el proceso dedesarrollo de aplicaciones interactivas puesto que permite incorporar alusuario y tener en cuenta sus necesidades desde el pricipio del proyecto. Porsu propia naturaleza, el diseo iterativo conlleva el compromiso de desarro-llar algo rpido, el prototipo, que permita probar si las decisiones de diseoson 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 sobresu 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 requisitosdel 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 (reinicioen 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 yotros, 1998):

Prototipos de usar y tirar: los prototipos se utilizan para adquirirconocimiento sobre las tareas a las que el producto debe dar soporte ysobre las necesidades de los usuarios, pero una vez evaluados no seutilizan para construir el sistema final. Por ejemplo, antes de iniciar eldesarrollo de un complejo sitio Web (v.g. un banco electrnico) eshabitual hacer unas primeras maquetas con alguna herramienta deautor que genere HTML y sin que se acceda a ninguna base de datosni se programen complejas funciones. Una vez que se hayan decididogran parte de las caractersticas de la aplicacin, se establecer elentorno tcnico de desarrollo y se iniciar la verdadera implementa-cin en la que poco, o nada, del cdigo generado para los prototiposse podr reutilizar.

Desarrollo incremental: el producto final se construye como unaserie 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 procesole permite publicar un producto an no completo (por ejemplo, slopginas informativas) e ir aadiendo nuevos mdulos segn estos sevayan produciendo (por ejemplo, venta on-line, personalizacin,comunicacin con proveedores, etc.).

Desarrollo evolutivo: el prototipo va evolucionando en cada iteracinhasta 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 noimpone 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 procesode 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 sepueda, 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


siempre se pueden y se deben evaluar los resultados de cualquier fase, yasean stos un prototipo, un sistema o una simple especificacin formal, conel fin de confirmar si realmente se estn teniendo en cuenta las necesidadesy caractersticas de los usuarios. En el captulo 7 se presentan diversas tc-nicas de evaluacin que pueden aplicarse en las distintas fases del ciclo devida.

4.4.3. Seleccin del modelo de proceso

A la hora de abordar el desarrollo de un producto multimedia concreto espreciso adoptar un modelo de proceso, ya sea diseo iterativo, ciclo de vidaen 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, yen 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 pequeaaplicacin, por ejemplo un CD sobre la Antigua Roma que se va aentregar con una revista, que una aplicacin de gran envergadura,como por ejemplo el sitio Web de un banco electrnico. Cada tipo deaplicacin requiere de un tipo de ciclo de vida. As, mientras que paraproductos pequeos un enfoque muy formal puede ser engorroso e


FIGURA 4.6. Modelo de proceso en estrella.

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 participacinde 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 decada momento. Por otro lado, el desarrollo iterativo marca unas pautas aseguir que pueden resultar de utilidad cuando requiere disciplinar a losmiembros 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 enel que es preciso aplicar mtodos propios de la ingeniera del software.

Se han puesto de manifiesto algunas caractersticas y requisitos propiosde los productos multimedia que hacen precisa la adopcin de modelos deproceso y mtodos de desarrollo especialmente propuestos para este tipo deaplicaciones, entre las que se cuentan el hecho de que el equipo de desarrollosea pluridisciplinar, que el proceso tenga que estar centrado en el usuario yque 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 elestudio de la factibilidad, el anlisis, el diseo, la produccin, la evaluacin yel mantimiento, viendo brevemente en qu consiste cada una de ellas. Y, fina-lemente, se han estudiado posibles modelos de proceso que establezcan cmosecuenciar estas fases y se han presentado algunos factores que influyen en laseleccin del modelo de proceso, como son la disponibilidad de usuarios y derecursos 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 productoinformtico.

d) No puede llevarse a cabo utilizando mtodos propios de la ingenieradel 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 validezde 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 msprofundos que el proveedor de contenidos.

b) El encargado del mantenimiento hace las mismas labores que el pro-veedor de contenidos.

c) Ningnmiembropodra asumir varias funciones enunmismodesarrollo.d) El ingeniero del Web de nivel 3 se encarga de realizar el anlisis y eldiseo 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 enprototipos, pero, en contrapartida, es menos sistemtico.

c) La evaluacin incluye las fases tradicionales de pruebas del softwarey verificacin de requisitos.

d) Nunca se lleva a cabo la fase de mantenimiento.


4.7. REFERENCIAS BIBLIOGRFICAS

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 forhypermedia. 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. PrenticeHall, 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 Hierarchyfor Web Information System Development. Web Engineering: Managing Diversityand 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. IEEEStd. 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 engineeringapproach. 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: beyondhuman computer interaction. John Wiley &Sons, 2002

RADA (1995): R. Rada. Interactive Media. Springer-Verlag, 1995.


Captulo 5

ANLISIS Y DISEO DE SISTEMASMULTIMEDIA

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.5.6. Referencias bibliogrficas.

Diferentes estudios demuestran que el fracaso en los proyectos softwarese debe, en muchas ocasiones, a un mal anlisis de requisitos (Preece yotros, 2002), que deriva en un producto que ni satisface las necesidades desus usuarios ni las expectativas del propio equipo de desarrollo, que si bienha 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 algunautilidad tiene que ser una prioridad en cualquier desarrollo de software,puesto que este conocimiento es el que ha de guiar el resto del proceso. Estees 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 antesde comenzar a implementar el producto se tengan claras sus principalescaractersticas, a quin va destinado, qu tipo de actividades se van a llevara cabo con l, de qu manera se va a utilizar y dnde, de tal forma que sepueda organizar el subsiguiente desarrollo de la forma ms eficiente y pro-ductiva. Sin embargo, tambin hay que tener en cuenta que el anlisis derequisitos va a ser un proceso iterativo y evolutivo, en la medida en quesegn 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 sehaban identificado.

Asimismo la etapa de diseo juega un papel fundamental en el ciclo dedesarrollo de sistemas interactivos ya que permite abordar la resolucin delos requisitos aplicando un nivel de abstraccin que hace posible llegar auna solucin conceptual de los mismos. Durante el diseo se debe darlugar 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 presentasta 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 preservarla seguridad.

El objetivo de este captulo es profundizar en el anlisis de requisitospara sistemas multimedia as como en la etapa de diseo. Con este fin, seinicia el captulo introduciendo en la seccin 5.1 el objetivo del anlisis, parapasar 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 elresto 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 presentanlos productos multimedia, enfocndolas en seis perspectivas: presentacin,estructura, comportamiento, seguridad, funciones y navegacin.

5.1. LA ETAPA DE ANLISIS DE REQUISITOSEN EL DESARROLLO MULTIMEDIA

Tal y como se haba comentado en el captulo 4, el anlisis es una fase delproceso de desarrollo de un producto software que tiene como objetivo estu-diar y documentar las caractersticas o requisitos que dicho producto debetener, dando lugar a una Especificacin de Requisitos. En un sistema mul-timedia, como sistema interactivo, habr que estudiar las caractersticas desus usuarios, de las tareas que se espera realizar con el sistema a desarrollary del propio entorno de operacin. Antes de pasar a estudiar en ms detallecmo 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 quedecir algo con respecto al mismo. Por ello, en los sistemas interactivos suelehablarse de destinatarios o stakeholders incluyendo dentro de este trminoa todas aquellas personas, comunidades o grupos cuyas necesidades debenser tenidas en cuenta (Elsom-Cook, 2001). As por ejemplo al desarrollar unaUniversidad Virtual no slo habra que analizar las caractersticas de suspotenciales usuarios (ya sean acadmicos, administrativos o estudiantes) ydel cliente que contrata el desarrollo, sino que tambin habra que considerarlas necesidades y opiniones de instituciones involucradas en el proceso edu-cativo (por ejemplo, organismos internacionales, nacionales, regionales olocales) 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 yotros, 2002):

Estudiar a los usuarios, las tareas que stos realizan y el entorno de operacinpara identificar necesidades.

Producir un conjunto de requisitos estables que sirvan de gua durante el procesode diseo.

Al tratar de abordar la especificacin de requisitos en los desarrollosmultimedia, hay que tener en cuenta que esta especificacin se va a hacer de


forma incremental y flexible, puesto que no se suelen, ni en muchas ocasio-nes se pueden, identificar a priori todas las caractersticas que el productodeber 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 sehaya adoptado. As, es muy probable que gran parte de los requisitos se vayanidentificando en etapas tales como el diseo conceptual o incluso durante laimplementacin y evaluacin de prototipos.

Durante esta importante fase del proceso de desarrollo se van a recogerdatos, a interpretarlos y a convertirlos en requisitos estables, que puedanemplearse para verificar la usabilidad y utilidad del sistema final.

5.2. LA ESPECIFICACIN DE REQUISITOSEN EL DESARROLLO MULTIMEDIA

Un requisito es una propiedad o caracterstica que un sistema debecumplir para que sus destinatarios lo consideren vlido. Para conseguir esaaceptacin por parte de los usuarios es preciso que el producto final sea tily utilizable, unas caractersticas que no suelen ser fcilmente definibles. Elanlisis de requisitos en un sistema multimedia es una actividad esencialque trata de extraer del entorno y del usuario todas aquellas caractersticasrelevantes para el diseo y la produccin, unas caractersticas que varan ensu naturaleza con respecto a otros tipos de aplicaciones software. De hecho,la disciplina denominada ingeniera de los requisitos hace hincapi en laimportancia de llevar a cabo una buena recogida de requisitos, entendidasta como un proceso de ingeniera iterativo y evolutivo (Preece y otros,2002).

En este apartado se describirn los tipos de requisitos que se puedenidentificar en sistemas multimedia, algunas tcnicas para recoger datossobre las necesidades de sus destinatarios y en formatos para producir unaespecificacin 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 eincluso del propio proceso de desarrollo y tener un nivel de concrecin muydispar. 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.

ANLISIS Y DISEO DE SISTEMAS MULTIMEDIA 137

TABLA 5.1. Ejemplos de requisitos de distinto nivel de abstraccin

Concreto Vago

Proceso

Producto

Cuanto ms concreto sea un requisito ms sencillo ser verificar su cumpli-miento, por lo que el anlisis de requisitos debera tender a producir requisitosclaros, concretos y que puedan medirse. As, cuando un requisito se exprese deuna forma vaga (como R2 y R4 en la tabla 5.1), tal vez sea necesario estudiarloms en detalle para tratar de formularlo de una manera ms precisa. As, en elrequisito 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 decompromiso, qu tipo de usuario, etc.) y en R4 ser preciso detallar qu seentiende por esttica adecuada para nios (v.g, la que un grupo de nios enrepresentacin de los usuarios finales considere adecuada, la que siga algn tipode 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 tiposde 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 elusuario puede llevar a cabo con la aplicacin, incluyendo aquellas relacionadascon: el acceso a la informacin (por ejemplo uso de buscadores, ndices omapas,mecanismos histricos, controles de reproduccin de contenidos con una dura-cin implcita, etc.); la modificacin de la informacin o de la estructura (porejemplo, capacidades de anotacin, personalizacin, uso de marcadores, inclu-sin de nuevos contenidos, etc.); o la capacidad de comunicarse o colaborar conotros 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 laeficiencia, consistencia, reusabilidad, flexibilidad, mantenimiento, adecuacin aestndares, reglas de seguridad, aspectos legales o corporativos, etc.


R2. Se utilizar un mtodo que in-volucre al usuario.

R4. El producto tendr una estticaadecuada para nios.

R1. El producto se entregar en unplazo de doce meses a la firma deesta especificacin.

R3. El producto se distribuir como unnico CD autocontenido, que incluirtoda la informacin y los programasnecesarios para su utilizacin.

Los requisitos no funcionales no son funciones sino caractersticas quedeben verificarse en el funcionamiento o en la estructura de la aplicacin. Sinembargo esta distincin no es siempre evidente y, adems, los requisitos nofuncionales pueden afectar a los funcionales y viceversa. As por ejemplo,limitar el tamao de la ventana de visualizacin es un requisito funcional ono funcional?

Por ello, a estos dos tipos de requisitos se aaden otras cuatro categorasque permiten recoger aspectos importantes de cualquier sistema interactivoy clasificar las propiedades de una forma ms apropiada: los requisitos deusuario, 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 encuenta a la hora de disear el producto, ya sea sobre aspectos personales (porejemplo, 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 aestudios 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 quepuedan 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 tenidasen cuenta.

En el primer caso, los requisitos se emplean para mejorar un diseo quees nico, mientras que en los otros dos los diseos deben adaptarse, de formaautomtica o no, a las caractersticas de los usuarios.

En el segundo caso pueden considerarse distintos tipos de usuarios enfuncin 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 ungrafo 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 imprescindiblemantener un modelo de usuario que recoja sus caractersticas y comporta-miento mediante alguna tcnica de representacin del conocimiento ascomo algn tipo de mecanismo de inferencia que pueda deducir qu hacer enfuncin 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 aquellasrestricciones 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 puederesultar interesante analizar in situ el entorno fsico en que se va a utilizarpara detectar si existen parmetros (por ejemplo, nivel de ruidos o ilumina-cin) que puedan a afectar a la utilidad del diseo. Con respecto al entornoorganizativo se trata de ver aspectos tales como el tipo de soporte con quevan 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 productocomo 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 7dedicado al proceso de evaluacin, suele medirse en trminos de efectividad,eficiencia, seguridad, utilidad y facilidad de aprendizaje. Desde la ingenierade la usabilidad se insiste en que la usabilidad es una caracterstica ms delproducto software y que puede medirse siguiendo mtodos rigurosos, demanera que la especificacin de requisitos relacionados con esta propiedaddebe hacerse cuidadosamente. As, ser preciso que las metas de usabilidadse expresen acompaadas de una serie de mtricas (Good y otros, 1986) quepermitan valorar la aceptacin que tendr el producto final. Normalmentesuelen emplearse criterios tales como: el tiempo requerido para completaruna 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 laayuda 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 nohan 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 deun 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 estcreada dentro de un curso electrnico. Para ello los usuarios debern locali-zar dnde ubicar la pgina y aadirla. Como caractersticas generales delatributo se tienen (Faulkner, 1998): la mtrica que se va a emplear, los tiposde usuarios involucrados y las precondiciones que deben satisfacerse. Ade-ms, tal y como propone en (Whiteside y otros, 1998) se aaden una serie devalores que proporcionan una escala bastante til a la hora de analizar losresultados obtenidos: el valor que se obtendr en el peor caso, en el mejor, elnivel 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 delsistema).

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 talescomo los tipos de datos que van a incluirse en el sistema, su volatilidad, eltamao, la persistencia, la precisin o el valor (Preece y otros, 2002). A esterespecto, sera interesante incluir la integridad de los datos como un pun-to bsico a tener en cuenta, particularmente importante en el caso de quese 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 quepueden hacer que los datos no sean consistentes, fiables, actuales, vlidoso 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 pginafuncionamiento 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 semiden. Para tener un conocimiento apropiado de los mismos ser preciso uti-lizar diferentes tcnicas que permitan extraer informacin tanto del usuariocomo del entorno.

La recoleccin de datos tiene como objetivo fundamental obtener datossuficientes, relevantes y apropiados para definir un conjunto estable derequisitos o para expandir, clarificar y confirmar ese conjunto en caso de queya existiese. Durante esta actividad se debe llegar a conocer la forma en queel 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 ylas razones de por qu las cosas son como son.

Existen varias tcnicas para recoger informacin, entre las que se cuentanlos 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 evaluacincomparten un objetivo comn: la recoleccin de datos. La principal diferenciaradica 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 estdesarrollando est realmente satisfaciendo las necesidades de sus usuarios.En los siguientes apartados se comentan brevemente estas tcnicas, algunasde las cules se abordan con ms detalle en el captulo 7. Una caractersticabsica de estas tcnicas es que son complementarias y que, habitualmente, sesuelen utilizar varias para recolectar informacin sobre el mismo requisito.

Cuestionarios. Los cuestionarios son una forma eficaz y barata derecopilar informacin cualitativa y cuantitativa sobre cuestiones quetienen una respuesta muy especfica (Preece y otros, 2002). El mayorproblema es disearlos de manera que se pueda recoger informacinrelevante, puesto que las respuestas a las preguntas pueden disearsede distintas formas y conseguir motivar a los participantes para querellenen 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 requiereun 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 queparticipen varios usuarios o destinatarios junto con miembros delequipo de desarrolla, de forma que se fomente la discusin en gruposobre temas relevantes del producto y se obtengan distintos puntos devista 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 entredestinatarios 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 hacees que un miembro del equipo de desarrollo observe al usuario durantesu 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 estudiosel etngrafo participa, de forma patente o infiltrado, en la vida diariade 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 elmismo ambiente que el usuario y no slo observa a estos sino tambinlas interfaces y productos software que stos utilizan en su rutina, con elfin 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 lastareas a realizar, puesto que en muchas ocasiones algunos procedi-mientos ya estn sujetos a algn tipo de regulacin que es preciso teneren 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 experienciaen el dominio de aplicacin del producto, es buscar en la literaturaejemplos 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 omenos interactivos y observar sus reacciones reales.

A modo de resumen, la tabla 5.3 recopila las situaciones en las que es tilcada 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 uotras dependiendo de diversos factores, entre los que se cuentan el momento deldesarrollo 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 dela 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

Entrevista

Grupos de trabajo

Observacin

Estudio dedocumentacin

Estudio de laliteratura

Prototipos

5.2.3. La especificacin de requisitos

Los requisitos deben plasmarse de manera ms o menos detallada en undocumento, de tal manera que este documento pueda convertirse en una tilgua durante todo el proceso de desarrollo, ya sea para disear, para construiro para evaluar. Una buena Especificacin o Pliego de Requisitos tiene lassiguientes ventajas (IEEE, 1998):

se establece una base slida para alcanzar un acuerdo sobre lo que elproducto 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 sereduce 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.


Responder a preguntas muy con-cretas.

Explorar aspectos.

Confrontar perspectivas distintas.

Conocer el entorno.

Conocer estndares o normativas.

Aprender de desarrollos similares.

Confirmar aspectos.

Qu navegador para web utili-zan los usuarios con ms fre-cuencia?

Qu contenidos debera tenerel curso?

Cmo hay que estructurar lainformacin?

Cmo son las sesiones de losalumnos de un curso virtual?

Cmo es el proceso de matricu-lacin en el centro de enseanza?

Qu estilos de aprendizaje se es-tn ofreciendo en cursos similares?

Tienen los usuarios problemas alresponder a los tests de nivel?

Para ello es preciso elaborar un documento que sea correcto, completo,no ambiguo, consistente, verificable, modificable, con referencias cruzadasfcilmente seguibles y en el que los requisitos se ordenen por importancia opor su nivel de estabilidad. En el campo de la ingeniera del software se havenido utilizando como formato para la documentacin de los requisitos elestndar de ANSI/IEEE sobre especificacin de requisitos software (IEEE,1998) cuyo formato se refleja en la figura 5.1.

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

5.3. LA ETAPA DE DISEO EN EL DESARROLLOMULTIMEDIA

El diseo tiene como objetivo primordial pasar de la especificacin derequisitos, en la que se indica para qu debe servir un producto y a quin, auna propuesta de solucin que indica cmo va a ser dicho producto. Esa solu-cin abordar, entre otras, cuestiones tales como:


FIGURA 5.1. Formato de una Especificacin de Requisitos, segn IEEE, 1998.

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 (porejemplo, tipos de contenidos multimedia que se van a utilizar, ritmo depresentacin, sincronizaciones, estilos de interaccin, etc.);

el funcionamiento de aplicacin (por ejemplo, cmo se van a poderrealizar las distintas tareas, etc.);

cmo va a poder interactuar el usuario con el producto en cadamomento (por ejemplo qu eventos de usuario se van a gestionar ycmo, qu resultados producen los eventos, etc.), o,

la aplicacin de ciertas reglas de accesibilidad y de seguridad (porejemplo, qu mecanismos se van a incluir para hacer que la informa-cin sea accesible a todos los usuarios, quin va a poder modificar lainformacin o la estructura, quin va a poder hacer anotaciones perso-nales, etc.).


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

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 serdiscutidos por parte de los diversos miembros del equipo de desarrollo. Enlos sistemas multimedia se pueden considerar las seis perspectivas de diseoque se muestran en la figura 5.3 (Daz y otros, 2001b).

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 lamanera y el ritmo de presentacin de los contenidos pueden determinar engran medida el xito de un producto multimedia.

Por un lado hay que tener en cuenta que en una composicin multimediaen la que los objetos van apareciendo y desapareciendo del espacio de repre-sentacin, es preciso establecer una coreografa de los contenidos armnicay 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 ventanabidimensional (o tridimensional) y el del tiempo. Adems, estos contenidospueden colocarse en un punto concreto de ese espacio (por ejemplo, el vdeodemostracin se inicia en el segundo 5), o bien hacer que su presentacin


FIGURA 5.3. Perspectivas de modelado para productos multimedia.

dependa de la presentacin de otro y otros elementos (por ejemplo, en cuan-to acaba el vdeo demostracin se muestra un botn para continuar). Coneste fin, es preciso que el mtodo elegido permita establecer relaciones o

sistemas multimedia analisis, diseño y evaluacion

Documents