Usabilidad

Raquel Tlaxcala Luna 09 de mayo de 2012

i
Resumen

Para el desarrollo de un sistema son importantes las interfaces ya que a travs de ellas se comunica el usuario con la computadora, estas deben de proporcionar una forma amigable de mostrar la informacin, para que el usuario pueda interactuar con el sistema, estas deben de ser usables, en estas se debe de definir muy bien donde ira cada componente para que ayude al usuario en su comprensin. La usabilidad es una de las caractersticas ms importantes que debe de tener un sistema ya que esto determina si es de calidad o no, esta facilita el manejo, la rapidez de con que el usuario va a realizar sus tareas, as como disminuir costos en la aplicacin, tanto en mantenimiento como en capacitacin al usuario, de igual manera se ahorrara tiempo, esta se debe de empezar a definir desde el principio hasta el final, donde se har la comprobacin o validacin de la usabilidad a travs de evaluaciones o test de usabilidad, aqu se medir la diferencia entre lo que se ha hecho y lo que se tiene que hacer. Al igual se recomienda que el diseo este basado en el usuario, donde el usuario es una parte importante para el desarrollo del sistema.

ii
ndice: Capitulo 1. Antecedentes ........................................................................................................................................... 1 1.1. 1.2. Planteamiento del problema..................................................................................................................... 1 Objetivo General y especfico .................................................................................................................. 1 Objetivo General ............................................................................................................................... 1 Objetivos especficos ........................................................................................................................ 2

1.2.1. 1.2.2. 1.3.

Justificacin ................................................................................................................................................ 2

Capitulo 2. Interfaces ................................................................................................................................................. 2 2.1. 2.2. Interfaces .................................................................................................................................................... 2 Caractersticas de las interfaces ............................................................................................................. 3

Capitulo 3. Herramientas CASE ................................................................................................................................ 3 3.1. Herramientas CASE ...................................................................................................................................... 3 3.2. Taxonoma de las Herramientas CASE ..................................................................................................... 5 Capitulo 4. Metodologa DESED ............................................................................................................................... 5 4.1. Metodologa DESED ....................................................................................................................................... 5 4.2. Pasos de la metodologa DESED ................................................................................................................. 8 Capitulo 5. Usabilidad ............................................................................................................................................... 10 5.1. Usabilidad ....................................................................................................................................................... 10 5.2. Atributos de la Usabilidad ............................................................................................................................ 10 5.3. Ciclo de vida de la Usabilidad ..................................................................................................................... 11 5.4. Modelo de proceso de la Ingeniera de la Usabilidad y la Accesibilidad ............................................. 13 5.5. Tcnicas de Usabilidad ................................................................................................................................ 16 Capitulo 6. Resultados y Conclusiones. ................................................................................................................ 20 6.1. Resultados ..................................................................................................................................................... 20 6.2. Conclusiones ................................................................................................................................................. 22 Bibliografa.................................................................................................................................................................. 22

Introduccin

iii
Desde hace varios aos se viene hablando de, por una parte la necesidad de realizar desarrollo de sistemas interactivos usables y, por otra, la necesidad de que estos desarrollos estn realizados mediante tcnicas de ingeniera de software adecuadas, modernas (acorde a los nuevos retos que la tecnologa nos aporta da tras da) y, por supuesto, que sean econmicamente rentables. La usabilidad es una de las caractersticas que en el desarrollo de software no se tomaba mucho en cuenta, y que ahora en la actualidad ha ido tomando ms importancia ya que es una de las caractersticas o atributos de calidad que debe tener todo sistemas, evitando que al usuario pierda tiempo en aprender como se ocupa al igual que permitindole el desarrollo mas rpido de sus tareas. En la actualidad el desarrollo de software necesita ser usable y centrado en el usuario, donde el usuario es una parte importante para el desarrollo. En este presente trabajo se describe primero, el planteamiento del problema, objetivos y la justificacin del mismo, despus se tiene el termino de interfaz, parte importante de los sistemas, herramientas CASE, la metodologa DESED y se describe cada uno de los pasos que contiene esta metodologa, que ayudara en el desarrollo de software educativo. Tambin se describe, tanto el concepto de lo que es usabilidad, sus atributos, lo cual estos los deben de estar presentes en todo sistema ya que ello distingue entre sistema de calidad, tambin se habla de el ciclo de vida mostrando en una imagen de las actividades que conlleva este, la cual contiene tres fases (el anlisis de los requisitos, Diseo/Prueba/Desarrollo y la Instalacin), el modelo de proceso en la cual igual se y las tcnicas de la usabilidad, entre las cuales estn las evaluaciones heursticas, los test de usabilidad donde se mide que tan usable es el sistema.

Capitulo 1. Antecedentes 1.1. Planteamiento del problema

Actualmente existen productos de software educativo que proporcionan una forma novedosa de mostrar la informacin, dichos productos emplean la tecnologa multimedia como imgenes, sonidos y texto.

Pero el desarrollar un producto de software con elementos multimedia, no implica ser software educativo. Entonces para lograr un software con caractersticas formativas se necesita cumplir con ciertos lineamientos, como por ejemplo aspectos de pedagoga y didctica entre otros; y una forma de alcanzar dicho tipo de producto es utilizando la metodologa DESED.

Por otro lado, el desarrollo de software requiere de conocimientos especficos, los cuales no todas las personas los poseen, cuestin que afecta tambin en la produccin de software educativo.

En este sentido, la solucin a dicho problema corresponde al desarrollo automtico de software educativo a travs de una herramienta CASE, la cual se base en la metodologa DESED, de modo que se cubran los requisitos de conocimiento mnimos del usuario para la elaboracin del software y que ste cumpla con los criterios de enseanza solicitados para dicho tipo de producto. Especficamente, para la parte de automatizacin por parte de la herramienta, se necesita contar con interfaces enriquecidas que proporcionen al usuario una experiencia intuitiva, de manera que le permita al usuario llevar un seguimiento de construccin de una forma fcil y sencilla, evitndole as la necesidad de involucrarse con temas respecto a desarrollo de software.

1.2.

Objetivo General y especfico

A continuacin se presentan tanto el objetivo general como los objetivos especficos.

1.2.1. Objetivo General

Desarrollar las interfaces grficas para la herramienta CASE DESED, basada en patrones de diseo de Erick Gama.

1.2.2. Objetivos especficos

A continuacin se muestran los objetivos especficos a realizar. Analizar la metodologa DESED. Analizar e identificar los patrones de diseo a utilizar. Analizar el Modelo-RUX Identificar las tecnologas para el desarrollo de interfaces de Aplicaciones Enriquecidas de Internet. Disear interfaces adecuadas para la herramienta CASE DESED. Disear interfaces para el producto final.

1.3.

Justificacin

Actualmente no se reporta una herramienta CASE para el desarrollo de software educativo basado en la metodologa DESED, sin embargo se realizaron software educativos que satisfacen el objetivo. Actualmente se cuenta con productos desarrollados en base a la metodologa DESED y que satisfacen el objetivo que se tiene para la creacin de software educativo. Para el desarrollo de la herramienta CASE-DESED se necesita contar con interfaces intuitivas, que permitan guiar al usuario desde el diseo hasta la obtencin del producto final. Tambin es importante que cuente con un repositorio que de soporte a las necesidades de la herramienta, almacenando objetos digitales, as como contar con un mdulo de ensamblaje de objetos de la herramienta CASE para la produccin de software educativo. pruebas piloto para la obtencin de productos de

Capitulo 2. Interfaces

2.1.

Interfaces

La idea fundamental en el concepto de interfaz es el de mediacin, entre hombre y mquina. La interfaz es lo que media, lo que facilita la comunicacin, la interaccin, entre dos sistemas de diferente naturaleza, tpicamente: el ser humano y una mquina como la computadora. Esto implica, adems, que se trata de un sistema de traduccin, ya que los dos hablan lenguajes diferentes: verbo-icnico en el caso del hombre y binario en el caso de la computadora.

2.2.

Caractersticas de las interfaces

Una interfaz debe cumplir las condiciones: Naturalidad. El nuevo sistema automatizado debe tender a ser lo ms similar al antiguo. Facilidad de aprendizaje y uso, dos aspectos que no siempre van unidos. Consistencia. La interfaz debe mantener uniformidad en cuanto a estilo, vocabulario, etc.

Naturalidad Una interfaz es natural, cuando provoca al usuario sentimientos de estar como en casa. Todo trabajador tiene: Una forma de actuar Una forma de organizarse Un vocabulario propio para las tareas habituales Un entorno que ya domina, al que est acostumbrado y del que, tal vez, le sea difcil de salir.

Facilidad de aprendizaje y uso Proporcionar al usuario un sistema de ayuda potente. Pero, cuidado! El sistema de ayuda puede ser un obstculo una vez que se domine el producto (esta ayuda no debe ser automtica). Para disfrutar de esta caracterstica, la interfaz debe incorporar: Administracin de perfiles de usuario. Segn el grado de perfil, la interfaz ejecutar unas acciones u otras. Mecanismos de realimentacin que proporcione al usuario informacin sobre la ejecucin actual del trabajo Mecanismos de prevencin de desastres. Sistemas de ayuda: Tratan de evitar que el usuario tenga que acceder a los manuales para resolver una duda puntual. Los mejores sistemas de ayuda son los que se denominan sensibles al contexto. Es capaz de determinar la circunstancia que origina la peticin de ayuda y proporcionar un auxilio muy concreto sobre la materia que interesa.

Consistencia Debe mantenerse una uniformidad a lo largo de toda la extensin de la interfaz: modo de operacin, diseo, etc. Si cada componente acta con distinta filosofa, obliga al usuario a cambiar la mentalidad de trabajo.

Capitulo 3. Herramientas CASE 3.1. Herramientas CASE

Para la definicin de una herramienta CASE, primero se definen mtodo y herramienta: Mtodo.- es un procedimiento aplicado rutinariamente para alcanzar un objetivo. Define los resultados a alcanzar y el camino que conduce a ellos.

4
Herramienta.- es un producto software que libera al ingeniero de software de acciones que generan los resultados definidos por los mtodos. Por tanto ahora se define herramienta CASE: como un conjunto de herramientas y mtodos asociados que proporcionan asistencia automatizada en el proceso de desarrollo del software a lo largo de su ciclo de vida. Las herramientas CASE comprenden la gestin del proyecto (planificacin, estimacin y control), el desarrollo de software (anlisis, diseo, implementacin y validacin) y el mantenimiento de software. Los componentes de la herramienta CASE se muestran en la figura 1. Estos componentes son los siguientes: Repositorio (diccionario) donde se almacenan los elementos definidos o creados por la herramienta, y cuya gestin se realiza mediante el apoyo de un Sistema de Gestin de Base de Datos (SGBD) o de un sistema de gestin de archivos. Meta modelo (no siempre visible), que constituye el marco para la definicin de las tcnicas y metodologas soportadas por la herramienta. Carga o descarga de datos, son facilidades que permiten cargar el repertorio de la herramienta CASE con datos provenientes de otros sistemas, o bien generar a partir de la propia herramienta esquemas de base de datos, programas, etc. que pueden, a su vez, alimentar otros sistemas. Comprobacin de errores, facilidades que permiten llevar a cabo un anlisis de la exactitud, integridad y consistencia de los esquemas generados por la herramienta. Interfaz de usuario, que consta de editores de texto y herramientas de diseo grfico que permitan, mediante la utilizacin de un sistema de ventanas, iconos y mens, con la ayuda del ratn, definir los diagramas, matrices, etc. que incluyen las distintas metodologas.

Figura 1. Componentes de las herramientas CASE

5
Los objetivos de las herramientas CASE son: Automatizar el desarrollo de software aumentando la productividad del equipo y la calidad del software Incrementar la reutilizacin del software. Reducir los costos de desarrollo y mantenimiento Automatizar o simplificar la gestin del proyecto, el desarrollo del software (permitir aplicaciones estructuradas, prototipos, desarrollo visual) y el mantenimiento del software (incluyendo la automatizacin y estandarizacin de la documentacin y su mantenimiento).

3.2. Taxonoma de las Herramientas CASE

Las herramientas CASE se clasifican segn las fases del ciclo de vida del software que abordan [1]: CASE frontales (front-end) o Upper CASE: Herramientas de apoyo a las primeras fases: o o o o o Anlisis Diseo.

CASE dorsales (back-end) o Lower CASE: Herramientas de apoyo a las ltimas fases: Implementacin (generacin de cdigo). Pruebas (caja blanca y caja negra). Mantenimiento.

ICASE (Integrated-CASE).- Contienen elementos de Upper y Lower CASE: contemplan todo el ciclo de desarrollo.

Capitulo 4. Metodologa DESED 4.1. Metodologa DESED

Segn el Dr. Pere Marqus el software educativo son programas para computadoras creados con la finalidad especfica de ser utilizados como medio didctico, es decir, para facilitar los procesos de enseanza y de aprendizaje . Otra definicin de software educativo segn Galvis Panqueva, son aquellos programas que permiten cumplir o apoyar a funciones educativas . Para el desarrollo de software educativo, se deben seguir pasos perfectamente definidos, adems deben cumplirse los requisitos bsicos de Ingeniera de software para el producto terminado sea considerado de calidad. DESED es una metodologa fundamentada en la ingeniera de software que permite desarrollar el tipo de software adecuado para servir de apoyo didctico a los programas de estudio de los niveles de educacin bsica y media .

6
La metodologa consta de 14 pasos en los cuales se toman en consideracin aspectos de Ingeniera de Software, Educacin, Didctica y Diseo grfico, en la figura 2. se muestra un esquema general de la metodologa donde los pasos son los siguientes:

1. Determinar la necesidad de un S.E. 2. Formacin del equipo de trabajo 3. Anlisis y delimitacin del tema 4. Definicin del usuario 5. Estructuracin del contenido 6. Eleccin del tipo de software a desarrollar 7. Eleccin del lenguaje de modelado 8. Diseo de interfaces 9. Definicin de las estructuras de evaluacin 10. Eleccin del ambiente de desarrollo 11. Creacin de una versin inicial 12. Prueba de campo 13. Mercadotecnia 14. Entrega del producto final

Figura 1. Pasos de la metodologa DESED

4.2. Pasos de la metodologa DESED

1.- Determinar la necesidad de un S.E. Un aspecto importante que debe considerarse, es que el SE deber poder cubrir los aspectos primordiales del rea o materia de estudios de que se trate, y que la necesidad de desarrollar un producto de software debe permitir al Ingeniero de Software hacerse de la informacin y las tcnicas didcticas que pudieran ser empleadas al impartir normalmente la asignatura. Adems, debe mejorar sustancialmente la calidad de la educacin. 2.- Formacin del equipo de trabajo Diversos autores analizados concuerdan en que se requiere conformar un grupo de trabajo nutrido para poder desarrollar un SE completo, esto debido a que lo ms importante ya no es slo la informacin, sino que tambin debe tenerse muy presente la forma de presentar la informacin, que en un momento dado se convierte en conocimiento que debe ser adquirido por los estudiantes. 3.- Anlisis y delimitacin del tema Es el momento de reunir la informacin obtenida hasta el momento para definir la amplitud del SE. Se analizan las necesidades presentadas por las personas que requieren el software, determinndose los objetivos particulares de trabajo, es decir, las necesidades deben permitir establecer el mbito de la materia, y determinar los temas especficos, de los planes de estudio, que deben ser considerados para el desarrollo del producto; y esto es sumamente importante, ya que se debe delimitar la amplitud de los temas a cubrir. 4.- Definicin del usuario Basados en la definicin del nivel de enseanza al cual va dirigido el software educativo, deben determinarse las caractersticas del usuario. Es importante definir con claridad al usuario final potencial del S.E., ya que dentro de cada nivel de enseanza, la edad de los alumnos ser determinante para la eleccin y aplicacin de las tcnicas de enseanza que se vayan a tener presentes en el desarrollo del software. 5.- Estructuracin del contenido En este punto de la metodologa, se deben definir los conceptos a considerar para establecer los contenidos temticos que se abarcan en el SE El trabajo conjunto entre el experto en el tema (que muchas veces es el profesor que imparte la materia) y los pedagogos, psiclogos, redactores y editores de la informacin se lleva a cabo en este punto. El experto en el tema y los redactores, definen la amplitud de los contenidos temticos especficos que debern ser mostrados a los alumnos. 6.- Eleccin del tipo de software a desarrollar En el momento de elegir un tipo de software a desarrollar es preciso tener presente los niveles de complejidad de las reas de aprendizaje. El software educativo puede ser visto como un recurso de Enseanza-Aprendizaje; pero tambin de acuerdo con una determinada estrategia de enseanza, el uso de un determinado software puede llevar unas tcnicas de aplicacin implcitas o explcitas; ejercitacin y prctica, simulacin, tutorial; uso individual, competicin, pequeo grupo, etc.(3)

7.- Eleccin del lenguaje de modelado En este paso se elige en que lenguaje se va a modelar el producto desarrollado, en este caso el lenguaje de modelado ser UML.

8.- Diseo de interfaces La interfaz es un punto focal, ya que a travs de ella se lleva a cabo la comunicacin entre el usuario y la computadora. Y es lo que contribuir a la motivacin, eficiencia, comprensin y uso del SE que se desarrollar. Aqu es en donde se hacen realidad algunas de las especificaciones definidas hasta el momento, se toman en cuenta las consideraciones didcticas expuestas en la definicin de necesidades. El desarrollador debe hacer en este punto maquetas de muestra de la interfaz elegida, para poderlas mostrar al equipo de trabajo. 9.- Definicin de las estructuras de evaluacin La finalidad misma del SE es lograr que los alumnos aprendan los contenidos establecidos dentro del la planeacin didctica del curso. Al realizar el SE, debe de proporcionarse a la par de los contenidos de aprendizaje, las formas de evaluacin de los contenidos mismos, para que con estas evaluaciones: el maestro pueda evaluar los aprendizajes, sugerir los repasos de los temas por parte de los alumnos; y que los alumnos puedan retroalimentarse y reafirmar los conceptos aprendidos. 10.- Eleccin del ambiente de desarrollo Es importante que la delimitacin del campo de aplicacin del SE est perfectamente definida, ya que cada desarrollador deber buscar la herramienta que le permita involucrar todas las peticiones de los usuarios potenciales. Cada lenguaje de programacin permite el desarrollo de uno u otro tipo de software. As mismo, se puede explotar segn sean las necesidades que el desarrollador tenga, razn por la cual, se debe tener especial cuidado en la eleccin del ambiente de desarrollo 11.- Creacin de una versin inicial Una vez que se tiene la informacin requerida del ndice temtico, que se ha elegido el ambiente de desarrollo y el tipo de software a realizar, se debe comenzar a planificar los aspectos de implementacin y realizar la implementacin en s. Se deben respetar en todo momento los acuerdos a los que lleg el grupo de trabajo hasta el momento antes de llegar a la implementacin, los cuales debieron recopilarse a lo largo de cada etapa del proceso de desarrollo. La creatividad del Ingeniero de Software es la nica limitante en su desarrollo. 12.- Prueba de campo La primera versin del sistema debe ser puesta a prueba frente al equipo de trabajo para su evaluacin y rectificacin de caractersticas; as mismo, para verificar que las especificaciones establecidas en el anlisis y diseo fueron respetadas por el desarrollador. Una vez que se detecten los posibles errores u omisiones, debe retomarse el desarrollo y volver a orientar la implementacin del nuevo diseo de las modificaciones realizadas, creando una nueva versin del SE 13.- Mercadotecnia En el caso de que el SE haya sido diseado para comercializarlo, en este paso de la metodologa, debe hacerse un recuento de caractersticas de mercadotecnia que harn que el producto sea vendible. Debe elegirse un nombre, un empaque, el modo de distribucin. La estrategia de mercado elegida, es la que har que nuestro software incursione y se presente ante los usuarios finales potenciales, para que pueda afianzarse un mercado. 14.- Entrega del producto final Debe presentarse un producto final a los usuarios potenciales, el cual debe tener el apoyo documentado en caractersticas de instalacin, operacin.

10

Capitulo 5. Usabilidad 5.1. Usabilidad

Definicin Coloquial: Medida en la cual un producto puede ser usado por usuarios especficos para conseguir objetivos especficos con efectividad, eficiencia y satisfaccin en un contexto de uso especificado. Definiciones formales: La norma ISO /ICE 9126 lo define de la siguiente manera: La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones especficas de uso La norma ISO/IEC 9241: define usabilidad de la siguiente manera: Usabilidad es la efectividad, eficiencia y satisfaccin con la que un producto permite alcanzar objetivos especficos a usuarios especficos en un contexto de uso especfico

5.2. Atributos de la Usabilidad

Facilidad de aprendizaje.- Cun fcil es aprender la funcionalidad bsica del sistema, como para ser capaz de realizar correctamente la tarea que desea realizar el usuario. Se mide normalmente por el tiempo empleado con el sistema hasta ser capaz de realizar ciertas tareas en menos de un tiempo dado (el tiempo empleado habitualmente por los usuarios expertos Eficiencia (productividad).- El nmero de transacciones por unidad de tiempo que el usuario puede realizar usando el sistema. Lo que se busca es la mxima velocidad de realizacin de tareas del usuario. Cuanto mayor es la usabilidad de un sistema, ms rpido es el usuario al utilizarlo, y el trabajo se realiza con mayor rapidez. Facilidad para recordar.- Para usuarios intermitentes (que no utilizan el sistema regularmente) es vital ser capaces de usar el sistema sin tener que aprender cmo funciona partiendo de cero cada vez. Este atributo refleja el recuerdo acerca de cmo funciona el sistema que mantiene el usuario, cuando vuelve a utilizarlo tras un periodo de no utilizacin. Manejo de errores.- Este atributo contribuye de forma negativa a la usabilidad de un sistema. Se refiere al nmero de errores cometidos por el usuario mientras realiza una determinada tarea. Un buen nivel de usabilidad implica una tasa de errores baja. Los errores reducen la eficiencia y satisfaccin del usuario, y pueden verse como un fracaso en la transmisin al usuario del modo de hacer las cosas con el sistema. Satisfaccin del usuario.- ste es el atributo ms subjetivo. Muestra la impresin subjetiva que el usuario obtiene del sistema.

11

5.3. Ciclo de vida de la Usabilidad

Mayhew propone el Ciclo de Vida de la Ingeniera de Usabilidad para el desarrollo de IUs usables. El enfoque de este mtodo es el de redisear el proceso de desarrollo completo en torno de la experiencia, mtodos y tcnicas de la ingeniera de usabilidad Mayhew resume la filosofa del ciclo de vida de la ingeniera de usabilidad en los siguientes puntos: El diseo de la IU es clave La integracin de la ingeniera de usabilidad con la IS debe ser particularizada El anlisis de requisitos vale la pena El diseo puede aproximarse en un proceso estructurado de descomposicin (topdown) El diseo, las pruebas y el desarrollo deberan ser iterativos El ciclo de vida completo puede ser estratificado en subconjuntos de funcionalidad Hay una variedad de tcnicas para llevar a cabo cada tarea del ciclo de vida Las tcnicas alternativas hacen que el ciclo de vida sea flexible y adaptable Una implementacin ptima del ciclo de vida requiere la participacin completa de equipos multidisciplinares. El ciclo de vida propuesto estructura las actividades en tres fases: Anlisis de Requisitos, Diseo/Pruebas/Desarrollo, e Instalacin, segn se muestra en la Figura 3.

12

Figura 3. Ciclo de Vida de la Ingeniera de la Usabilidad

Segn Mayhew, las tareas del ciclo de vida de la ingeniera de usabilidad (y en particular la tarea del Anlisis Contextual de Tareas) se centran en proyectos en los cuales un producto especfico ha sido identificado, definido y delimitado. Nombra otras tcnicas de anlisis de tareas que se centran en labores de reingeniera de proceso que incluyen la identificacin de oportunidades para nuevos productos, o en la identificacin de las caractersticas bsicas que deberan incorporarse en nuevos productos. Las actividades de diseo/pruebas/implementacin propuestas estn centradas en el diseo y evaluacin de la IU. Divide tal diseo en tres niveles: modelo conceptual, estndares de diseo de las pantallas, y diseo detallado de la IU. Cada nivel es diseado, a continuacin se construye un prototipo que ilustre el diseo, y se evala su usabilidad antes de proceder al siguiente nivel de diseo de la IU. En el nivel ms abstracto se encuentra el modelo conceptual, que consiste en la definicin de la orientacin bsica de la IU (a proceso o a producto), las ventanas (displays) principales y la navegacin entre los mismos, y las reglas de presentacin a alto nivel para cada producto o proceso y para las ventanas. En el siguiente nivel est los estndares de diseo de las pantallas, que aseguran la consistencia y simplicidad en el diseo detallado a lo largo de todos las ventanas de la interfaz de un producto, en cuanto a uso de controles, localizacin y formato de los elementos estndar de la interfaz, terminologa, uso de las fuentes y tipo de letra, etc. En el nivel ms detallado se encuentra el diseo detallado de la IU, en el que se documenta el diseo de todos los caminos, ventanas e interacciones, conforme a las reglas establecidas

13
en los dos niveles superiores. El conjunto de las decisiones de diseo de los dos niveles superiores se refleja en la gua de estilo del producto. Las actividades relacionadas con el diseo iterativo del modelo conceptual se presentan como tareas que deberan, por un lado, seguir al desarrollo del Modelo de Requisitos de la fase de Anlisis de OOSE, y por otro, preceder o llevarse a cabo en paralelo con el desarrollo del Modelo de Anlisis de la misma fase. La razn para esta precedencia, segn la autora, es que la arquitectura de la aplicacin debera disearse para dar soporte al diseo del modelo conceptual de la IU. Las actividades de diseo de la IU al nivel de estndares de pantalla se desarrollan en paralelo o van despus del Modelo de Anlisis de la fase de Anlisis de OOSE, puesto que, segn la autora, lo ms probable es que no afecte al diseo de la arquitectura. Se llevan a cabo en paralelo con el Modelo de Diseo de la fase de Construccin de OOSE, porque tampoco se considera que afecten al diseo de alto nivel. En cambio, s preceden al Modelo de Implementacin de la fase de Construccin de OOSE.

5.4. Modelo de proceso de la Ingeniera de la Usabilidad y la Accesibilidad

El esquema de la figura 4 muestra las diferentes fases en las que se divide el modelo de proceso de la Ingeniera de la Usabilidad y la Accesibilidad y cmo se relacionan cada una de ellas.

Figura 4. Modelo de Proceso de la Ingeniera de la Usabilidad

14
1.- Organizacin conceptual El esquema est organizado en base a una serie de mdulos o etapas que determinan la fase de desarrollo en la que nos encontramos y ubica en un nodo concreto la actividad del conocimiento existente en IPO (Interaccin persona-ordenador). Esto, en definitiva, no hace ms que poner cada cosa en su sitio, dotando de las pautas a seguir durante el diseo de un sistema interactivo. 2.- Tres pilares bsicos Las metas ms importantes de este modelo de proceso es conseguir enlazar el modelo de desarrollo de sistemas interactivos de la Ingeniera del Software con los principios bsicos de la Ingeniera de la Usabilidad y los de la accesibilidad proporcionando una metodologa que sea capaz de guiar a los equipos de desarrollo durante el proceso de implementacin de un determinado sistema interactivo. En la Ingeniera de la Usabilidad y en la HCI, en general hay dos conceptos muy importantes que deben realizarse de manera sistemtica desde el inicio del desarrollo y no pueden acabar hasta la finalizacin del sistema: El prototipado y la evaluacin. En el esquema se reflejan estos tres conceptos a modo de tres pilares bsicos: La Ingeniera del Software, en el formato "clsico" de ciclo de vida en cascada iterativo o evolutivo (columna de la izquierda). El prototipado (columna central), como metodologa que engloba tcnicas que permitirn la posterior fase de evaluacin. La evaluacin (columna de la derecha) que engloba y categoriza a los mtodos de evaluacin existentes. 3.- El usuario Un proceso de Diseo Centrado en el Usuario debe dejar claro de que es as slo con mirar el esquema la primera vez. Esto es lo que queda reflejado al disponer a ste en la parte central y por encima del resto de etapas todo el modelo de proceso. Otro aspecto determinante en este modelo de proceso es que se da mucha importancia no slo a los usuarios, sino tambin a los implicados en cuanto a que son personas que sin ser usuarios directos del sistema su actividad se ve afectada por el mismo. Queda claro, pues, que el usuario est en el centro del desarrollo y en las facetas en las que interviene. 4.-Un Mtodo Iterativo En todo proceso de desarrollo de software existe una fase ms o menos importante que basndose en una serie de repeticiones se pasa de una aproximacin de la solucin ideal a la solucin definitiva. Este proceso de repeticin, de hecho se produce en cualquier mbito de Ingeniera, sea del tipo que sea. Pensemos por ejemplo en la construccin de un edificio donde existe una serie de reuniones arquitectocliente para que el diseo del futuro edificio se adapte a las necesidades del inquilino o usuario. Las flechas del esquema especifican en que sentido puede ir el flujo del avance en el desarrollo del sistema. Pueden observarse dos tipos de flechas, las ms pequeas son las que se corresponden con

15
el modelo de la IS y las mayores las del modelo del Diseo Centrado en el Usuario (DCU). stas ltimas son las que indican por ejemplo donde interviene el usuario. Puede verse que el modelo no tiene un sentido ni lineal ni restrictivo, lo cual es debido a que pensamos que ser el Grupo de Desarrollo (GD) junto con los requerimientos del desarrollo a implementar el que marcar cuantas iteraciones deben realizarse y cmo se han de llevar a cabo. Y ser ste el que determinar el flujo de las acciones a realizar, proporcionando una libertad altamente agradecida por cualquier persona que precie su esfuerzo. 5.- Sencillez Mayoritariamente los desarrolladores de sistemas interactivos que pretendemos que la usabilidad sea un factor determinante de los mismos estamos de acuerdo en que sus interfaces, sin perder su capacidad comunicativa y funcional, tienen que ser cuanto ms sencillas y simples mejor. Y si estamos de acuerdo con la premisa anterior estaremos igualmente de acuerdo con la idea de que la metodologa que les permita llevar a cabo su trabajo de manera ms eficiente sea tambin muy sencilla y simple. Las diferentes representaciones del sistema (diseo) deben ser comprensibles, tanto por todos los componentes de los equipos (multidisciplinares) de desarrollo como por los usuarios y cualquier implicado que est involucrado en el sistema, que slo ser posible construyendo dichas representaciones lo ms simples posibles. 6.- Adaptado al modelo mental de los equipos multidisciplinares Los modelos mentales de las diferentes personas distan mucho entre ellos, hecho que supone que surgen ms dificultades de las previstas si los mecanismos de comunicacin no son eficientes y las herramientas formales de modelado no son suficientemente simples. Respecto a stos, se ha constatado que utilizar mtodos descriptivos en lenguaje natural junto con herramientas de uso habitual (aspectos comprensibles por todos los miembros del equipo) facilita el proceso comunicativo entre las personas que intervienen en el desarrollo. Disponer, por otra parte, de un equipo de desarrollo formado por gente tan diversa no significa que todos ellos estn presentes en todas las fases del proyecto. Ni siquiera es preciso que todos tengan una visin completa de la evolucin del desarrollo, lo que s que es necesario es que cada uno tenga la visin necesaria y precisa del sistema desde su punto de vista y concerniente a su participacin durante el proceso de desarrollo. No se puede olvidar que tanto los usuarios como los implicados en el sistema forman parte de este conglomerado pluridisciplinar y consecuentemente el modelo es tambin comprensible para ellos. 7.- Flexibilidad El modelo no tiene ni un sentido lineal ni restrictivo, sino que fomenta la libre aplicacin del mismo: Ser el equipo de desarrollo (representados normalmente por el responsable del proyecto en desarrollos de envergadura considerable o el diseador o programador ms experimentado en desarrollos menores) junto con los propios requisitos del sistema, las particularidades de los usuarios y los resultados de las diferentes evaluaciones quien marcar cuantas iteraciones deben realizarse, como deben hacerse y el flujo de las acciones a realizar en cada iteracin

16

5.5. Tcnicas de Usabilidad

Existen tcnicas que ayudan a conseguir un mejor nivel de usabilidad en el software desarrollado. Las tcnicas que se exponen a continuacin van a agruparse segn su uso en dicho ciclo: Especificaciones: Anlisis de usuarios, anlisis de tareas y especificaciones de usabilidad. Diseo: Diseo de la interaccin, prototipado y participacin de usuarios. Evaluacin: Test de usabilidad y evaluacin heurstica. Especificaciones Al principio del proyecto se elaboran unas especificaciones de usabilidad intentando que realmente reflejen el nivel de usabilidad del sistema en los aspectos especficos que ms interesen. Estas especificaciones dirigirn el proceso iterativo de desarrollo, pero para crearlas se necesita identificar previamente a los usuarios y las tareas que van a desarrollar con el sistema. Esta parte est muy relacionada con la Ingeniera de Requisitos. Anlisis de Usuarios Si se desea construir un sistema software usable, se debe primero conocer a fondo a qu usuarios especficos est destinado, cules son sus caractersticas principales. Para esto es necesario conocer cmo piensa el usuario para desarrollar un sistema que trabaja segn ese esquema (y no segn el esquema mental del equipo de desarrollo). Algunos procedimientos que pueden llevarse a cabo son los siguientes: Anlisis de mercado: Adecuado para software comercial. Visitas de campo: Cuando se desarrolla software para una empresa u organizacin es muy til observar al usuario en su entorno de trabajo habitual, ms si cabe en el caso de que el usuario est utilizando un sistema que ser reemplazado por el que se va a construir. Cuestionarios: Sin ser tan til como hablar a los usuarios en su entorno habitual, la informacin acerca de los usuarios puede ser recogida mediante cuestionarios. Tcnicas relacionadas: El anlisis de usuarios puede proporcionar una categorizacin de usuarios, la cual puede ser til a la hora de obtener una muestra de usuarios con los que realizar test de usabilidad. Anlisis de Tareas El trmino Anlisis de Tareas se usa para describir un conjunto de tcnicas que se preocupan de cmo hace la gente para realizar una determinada tarea. El concepto de tarea es similar al de funcin, pero no igual. Una tarea es una actividad con sentido para el usuario, algo que el usuario considera necesario o deseable que se realice.

17
Descomponer la interaccin con el sistema en unidades con sentido para el usuario. Estas unidades sern el punto de partida a la hora de desarrollar el sistema. Si en la actualidad la poblacin de usuarios ya desarrolla una serie de tareas, se realiza un anlisis de tareas actuales durante el anlisis de usuarios, para identificar dichas tareas y el modo en que el usuario las percibe. Tras este primer anlisis opcional, se identifican las tareas que el sistema a desarrollar va a ofrecer, en base a los objetivos que el usuario quiere satisfacer. Las tareas son descompuestas entonces en subtareas y stas en acciones que el usuario realizar en su interaccin con el sistema. El anlisis de usuarios se toma como entrada al anlisis de tareas, y ambos se realizan conjuntamente en determinadas ocasiones. Especificaciones de Usabilidad Se establecen especificaciones de usabilidad como objetivos cuantitativos de usabilidad, los cuales se definen antes de comenzar con el diseo del sistema. Se basan en los cinco atributos de usabilidad bsicos, o en subatributos de los mismos. Cuando se quiere medir la usabilidad del sistema que se est construyendo, es preciso tener un conjunto de especificaciones de usabilidad que puedan ser verificadas, si se define un conjunto de especificaciones de usabilidad para cada atributo de usabilidad que se quiera medir (esto es, que sea importante para el sistema a construir). Deben definirse de modo que puedan medirse, bien mediante test de usabilidad o bien mediante cuestionarios. Diseo Una vez identificadas las tareas a las que el sistema va a dar soporte, se puede empezar a disear la interaccin del sistema, como una primera aproximacin que ser evaluada y, eventualmente, mejorada en posteriores iteraciones. En primer lugar se va describir el diseo de la interaccin del sistema y las tcnicas de prototipado relacionadas con la usabilidad. A continuacin se van a describir dos principios de diseo que implican en distinto grado al usuario en el diseo del sistema: el diseo centrado en el usuario y el diseo participativo. Diseo de la Interaccin El diseo de la interaccin se puede dividir en dos etapas: Diseo del concepto del sistema y diseo de la parte visual de la interaccin. El diseo del concepto del sistema es la actividad ms importante del desarrollo de software, pues definir de qu modo va a funcionar el sistema. Es importante crear un concepto del sistema que pueda ser comprendido y asimilado fcilmente por el usuario. Para ello se pueden usar metforas (como la metfora del escritorio usada por algunos sistemas operativos) basadas en conceptos familiares para el usuario, o bien imitar sistemas ya conocidos por el usuario. El diseo es una actividad creativa y no puede mecanizarse. De todos modos, aunque no hay recetas de cmo crear un buen concepto del sistema, s hay principios generales que nos pueden guiar en dicha tarea, como intentar lograr una consistencia en la interaccin, intentar minimizar la posibilidad de error por parte del usuario, no sobrecargar la memoria del usuario, ofrecer realimentacin al usuario sobre sus acciones, etc.

18
El concepto del sistema se materializa posteriormente al realizar el diseo de la parte visual de la interaccin (interfaz grfica de usuario). Normalmente el diseo desemboca en la creacin de un prototipo para ser evaluado con usuarios. Prototipado El prototipado no es una tcnica exclusiva de la Ingeniera de Usabilidad, pero es muy valiosa en las primeras fases del desarrollo para representar el diseo de la interaccin y evaluar su usabilidad. No es posible conocer la opinin de los usuarios mostrndoles especificaciones tcnicas a un nivel abstracto. Los usuarios entendern mucho mejor prototipos concretos del sistema. Algunas tcnicas de prototipado ayudan a representar la interaccin con un esfuerzo mnimo de implementacin como por ejemplo: Borradores en papel: Al principio del proceso de diseo se pueden crear prototipos sobre papel para mostrarlos al usuario. Normalmente son representaciones de las ventanas de la aplicacin. El diseador acta como sistema, presentando al usuario el siguiente elemento cuando ocurre una transicin entre ventanas. Tcnica del Mago de Oz: Un experto humano acta como sistema, dando las respuestas a las peticiones del usuario. El usuario interacta normalmente con el terminal, pero en vez de haber un software detrs, un desarrollador est frente a otro terminal conectado al primero a travs de la red, y va tecleando la supuesta respuesta del sistema. El usuario normalmente no sabe acerca del truco, para conseguir la sensacin de estar tratando con un sistema real. Escenarios, storyboards y vietas: Un escenario describe una historia de ficcin de un usuario interactuando con el sistema en una situacin concreta. Las vietas son representaciones que capturan la interaccin que ocurre en un escenario. Storyboards son secuencias de vietas que se centran en las principales acciones en una situacin dada. Estas tcnicas posibilitan que el equipo de diseo piense acerca de lo apropiado del diseo actual a las necesidades del usuario, favoreciendo un proceso de diseo ms centrado en el usuario. Participacin de los Usuarios Para que el sistema que est diseando sea realmente como quieren y/o necesitan los usuarios se puede involucrar a stos para que participen en el proceso de diseo. Esta filosofa de diseo se conoce como Diseo Centrado en el Usuario. El Diseo Participativo va un paso ms all y pone a representantes de usuarios como responsables de decisiones de diseo. Diseo Centrado en el Usuario Es la aplicacin al diseo de la filosofa en la que se basa la Ingeniera de Usabilidad. Se trata de centrar el proceso de diseo en el usuario, implicando a los usuarios en el diseo para confirmar que se est desarrollando un sistema que en realidad satisface sus necesidades. La interaccin debe ser diseada desde el punto de vista del usuario. Se desea obtener sistemas que sean fciles de aprender y de utilizar, y efectivos para las tareas a las que dan soporte. Para ello el punto clave es el usuario, y no se puede conocer su punto de vista sin involucrarle en el proceso de desarrollo. Tal participacin se lleva a cabo principalmente mediante la

19
creacin de prototipos a lo largo de todo el proceso de desarrollo, para que un grupo representativo de usuarios los evale.

Diseo Participativo Tambin se conoce como Diseo escandinavo, debido a que surgi en los pases escandinavos y es su principal mbito geogrfico de aplicacin. Es una aproximacin al diseo que pertenece no slo al diseo de sistemas software, sino tambin al diseo industrial. Este enfoque acepta la tesis de que el usuario es el mximo experto en disear un sistema que satisfaga sus necesidades. Los usuarios son los diseadores del sistema, actuando los ingenieros software como consejeros tcnicos que indican qu se puede y qu no se puede hacer. El papel de los usuarios no va a ser el de un elemento pasivo al que se consulta sobre temas especficos, sino como ncleo central del equipo de desarrollo. Cuando hay usuarios participando en el equipo de desarrollo es preciso utilizar medios y lenguaje no tcnicos. Evaluacin La evaluacin de usabilidad permite conocer el nivel de usabilidad que alcanza el prototipo actual del sistema, e identificar los fallos de usabilidad existentes. La evaluacin se realiza usualmente mediante test de usabilidad, complementados con evaluaciones heursticas. Test de Usabilidad Los test de usabilidad son la prctica de usabilidad ms extendida. Consisten en presentar al usuario una serie de tareas a realizar, y pedirle que las realice con el prototipo del sistema. Las acciones y comentarios de usuario se recopilan para un anlisis posterior. Para conseguir unos test de usabilidad con resultados fiables, las condiciones del test y del lugar donde ste se realiza deben ser lo ms parecidas posibles al entorno de uso previsto para el sistema. Evaluacin Heurstica Un experto en usabilidad (o en HCI) puede realizar una evaluacin heurstica del sistema para hacer algunas iteraciones de desarrollo ms cortas, y as ser capaces de realizar ms iteraciones en el proceso de desarrollo. El experto realizar una crtica basado en su experiencia de diseo de la interaccin, o en guas de diseo de usabilidad ampliamente aceptadas, Los expertos proporcionan una informacin distinta a la obtenida de usuarios finales mediante test de usabilidad. Las sugerencias de modificaciones por parte de un experto suelen tener ms valor que las realizadas por usuarios, por ser ms viables y ms precisas acerca de los problemas subyacentes de usabilidad (falta de consistencia, navegabilidad pobre, etc.) Por otra parte, para identificar problemas de usabilidad especficos es preciso realizar test de usabilidad con usuarios reales. La evaluacin heurstica no debe usarse en vez de los test de usabilidad, sino como complemento a los mismos.

20

Capitulo 6. Resultados y Conclusiones. 6.1. Resultados

De acuerdo a Mayhew el diseo de la interfaz de usuario es clave por la cual se disearon algunas interfaces que se muestran a continuacin figura 5, figura 6, figura 7, para despus una vez implementadas se aplicarles el test de usabilidad y evaluaciones heurstica.

Figura 5. Paso 1 Necesidad del Software

21

Figura 6. Paso 2 Equipo de trabajo

Figura 7. Paso 3 Creacin del ndice

22

6.2. Conclusin

Es importante la aplicacin de usabilidad a nuestros sistemas ya que a travs de ella se puede tener sistemas de calidad, antes esta no se tomaba mucho en cuenta y se recomienda aplicarla desde que se inicia con el desarrollo del sistema hasta el final.

Bibliografa

[1] Velzquez Isabel, Sosa Mabel, Revista Iberoamericana de educacin Argentina Pg. 1-12 Universidad Nacional de Santiago, Septiembre 2009 [2] Interfaces de Usuario [En lnea] Disponible: http://trantor.ujaen.es/~mafer/drupal5.1/files/barranco_garcia/ofimatica/tema3.pdf [3]Fundamentos de Ingeniera de software [En lnea] Disponible: http://dis.um.es/~lopezquesada/documentos/FIS_0607/curso/Tema5.pdf [4] Arquitectura de las herramientas CASE [En lnea] Disponible: http://desarrollodeaplicacionesinformaticas.com/index.php/Analisis-y-diseno-detallado-de-aplic.informaticas/Tema-12-Herramientas-CASE/4-arquitectura-de-las-herramientas-case.html [5] Fundamentos de Ingeniera de software [En lnea] Disponible: http://ocw.um.es/ingenierias/fundamentos-de-ingenieria-del-software/material-de-clase-1/capitulo12.pdf [6] Software Educativo [En lnea] Disponible: http://www.lmi.ub.es/te/any96/marques_software/#capitol1 [7] Lpez Azamar Bertha, Metodologa para el desarrollo de software educativo, artculo [En lnea] Disponible: http://www.calameo.com/books/0000542440583e0b64e96 [8] Lpez Azamar Bertha. Metodologa para el desarrollo de software educativo, Instituto Tecnolgico de Orizaba, Mxico 2006.

[9] Ferr, X. Principios bsicos de usabilidad para ingenieros software. V Jornadas de Ingeniera de Software y Bases de Datos 2000. pp. 39-46 Valladolid Espaa. Pg. 1-8. Universidad politcnica de Madrid. Octubre 2004 [10] Ferr, X. Marco de la Integracin de la Usabilidad en el proceso de desarrollo de software, Tesis Doctoral, Universidad politcnica de Madrid. [11] T. Granollers, J. Lors, F. Perdrix, Modelo de Proceso de la Ingenieria de Usabilidad. Intergracin de la ingeniera del Software y la de la Usabilidad, Universidad de Lleida, Lrida Espaa.