Artefactos de especificación de requerimientos de usabilidad

Patricio Fagalde - 83810
Artefactos de especificacin de requerimientos de usabilidad

Tesis de Ingeniera en Informtica Facultad de Ingeniera Universidad de Buenos Aires
Patricio Fagalde - pfagalde@gmail.com Tutor: Ing. Carlos Fontela 27/05/2011
Patricio Fagalde
Facultad de Ingeniera
Resumen
Hay diversas maneras de especificar las necesidades de los usuarios, tambin llamados requerimientos. Una de las dimensiones para categorizar el tipo de especificacin es la formalidad, tema de debate en la ingeniera de software. La especificacin de los requerimientos generalmente se redacta en lenguaje natural, lo cual conlleva a tres posibles problemas: ambigedad, imprecisin e inconsistencia. Para mitigar estos problemas, se utilizan tcnicas de verificacin formales, cuya desventaja es que excluyen al usuario del proceso de validacin. Cuanto ms formal sea el lenguaje, ms difcil de comprender ser para los humanos, y menos flexibles a la hora de especificar que el lenguaje natural. Dentro de las clasificaciones posibles de los requerimientos, hay una especie de requerimiento no funcional de especial inters: los de usabilidad. La usabilidad es tomada frecuentemente como el grado en el que el usuario percibe la calidad de la aplicacin, lo cual es un factor de xito considerable para un proyecto como para ser ignorado. Con el fin de conciliar la visin del producto y la visin del usuario, se propone un proceso de diseo centrado en el humano, basado en artefactos con una notacin visual que pueden ser fcilmente validados por los usuarios y utilizados como punto de entrada para la implementacin del sistema.
Patricio Fagalde
Agradecimientos
La obra que hoy est en sus manos no es una mera recoleccin de la investigacin de los ltimos meses de trabajo; significa tambin la conclusin de mi carrera de grado. Por ende, me tomo el atrevimiento de extender este agradecimiento ms all. En primer lugar quiero agradecer a mis familia, compuesta por mis padres Anbal y Patricia y mis tres hermanas, Lucia, Mara Emilia y Delfina. Ellos fueron testigos de mi desarrollo como profesional y tambin como humano. Seguido quiero agradecer a mis amigos, a mis compaeros de trabajo y mis compaeros de facultad. Tales clasificaciones se diluyen hoy, al venir a mi mente, siendo muchos los que caen en ms de una categora. Quiero hacer especial mencin el agradecimiento a mi tutor, Ing. Carlos Fontela por su valiosa colaboracin tanto de la elaboracin de la Tesis como en etapas previas de la carrera. Y esta contribucin no solo se extiende a lo acadmico, sino tambin en el mbito laboral. Finalmente, sera necio decir que lo logr cuando nadie crea en m; Al contrario, siempre me pareci que todos tenan la certeza de que iba a llegar cuando yo no y eso me ayud en mis momentos ms crticos respecto de la carrera. Por eso, este esfuerzo se lo dedico a todos los que compartieron conmigo la ansiedad, el esfuerzo, la dedicacin y los logros. Incluyendo ste.
Patricio Fagalde
Tabla de contenido
Resumen ................................................................................................................................................................... 2 Agradecimientos ................................................................................................................................................... 3 Captulo 1 Introduccin...................................................................................................................................... 8 rea de investigacin ..................................................................................................................................... 8 Requerimientos............................................................................................................................................ 8 Usabilidad ....................................................................................................................................................... 9 Procesos de desarrollo .............................................................................................................................. 9 Identificacin del problema ....................................................................................................................... 10 Aproximacin a la solucin ........................................................................................................................ 11 Estructura de la obra .................................................................................................................................... 12 Trabajos publicados relacionados con esta tesis .............................................................................. 12 Estilo de citas ................................................................................................................................................... 13 Herramientas ................................................................................................................................................... 13 Captulo 2 Estado de la cuestin ................................................................................................................... 14 Introduccin ..................................................................................................................................................... 14 Requerimientos .............................................................................................................................................. 14 Estndar IEEE 830-1998........................................................................................................................ 14 Formalidad ................................................................................................................................................... 17 Prototipado....................................................................................................................................................... 18 Captulo 3 Criterios de diseo ....................................................................................................................... 21 Motivacin ........................................................................................................................................................ 21 Objetivo de los artefactos ........................................................................................................................... 22 Alcance ............................................................................................................................................................... 22 El proceso de desarrollo de software modelo .................................................................................... 23 Roles ............................................................................................................................................................... 24 Notaciones ........................................................................................................................................................ 25 4
Patricio Fagalde
Captulo 4 Capitulo 4: Artefactos de especificacin de requerimientos de usabilidad .......... 28 Descripcin general ...................................................................................................................................... 28 Descripcin detallada de cada etapa ...................................................................................................... 31 Identificar las metas de usabilidad .................................................................................................... 31 Identificar usuarios y tareas ................................................................................................................. 34 Desarrollar el prototipo.......................................................................................................................... 38 Probar el prototipo con los usuarios................................................................................................. 53 Captulo 5 Caso de estudio .............................................................................................................................. 56 Descripcin ....................................................................................................................................................... 56 Documento de especificacin de requerimientos de usabilidad ................................................ 57 Objetivos de usuario ................................................................................................................................ 57 Tipo de usuarios ........................................................................................................................................ 57 Metas de usabilidad.................................................................................................................................. 57 Matriz ............................................................................................................................................................. 58 Documento de especificacin de contexto .......................................................................................... 59 Tarea 1: Registrarse en el sitio ............................................................................................................ 59 Tarea 2: Crear un nuevo tema de debate ........................................................................................ 59 Solucin de diseo ......................................................................................................................................... 61 Diseo de la interaccin ......................................................................................................................... 61 Diseo de la informacin ....................................................................................................................... 63 Diseo de la navegacin ......................................................................................................................... 65 Diseo de la interaccin ......................................................................................................................... 66 Diseo de la informacin ....................................................................................................................... 69 Diseo de la navegacin ......................................................................................................................... 70 Reporte de anomalas................................................................................................................................... 71 Conclusin ............................................................................................................................................................. 72 Anexo A Diccionario de elementos .............................................................................................................. 73 Controles de entrada .................................................................................................................................... 74 5
Patricio Fagalde
Botn .............................................................................................................................................................. 74 Casilla de verificacin .............................................................................................................................. 74 Botn de radio ............................................................................................................................................ 75 Deslizador..................................................................................................................................................... 75 Desplazador ................................................................................................................................................. 75 Menus ............................................................................................................................................................. 75 Entrada de texto ........................................................................................................................................ 76 Seleccin de archivo ................................................................................................................................. 76 Calendario .................................................................................................................................................... 76 Vnculo ........................................................................................................................................................... 76 Controles de salida ........................................................................................................................................ 77 Listado ........................................................................................................................................................... 77 Ttulo .............................................................................................................................................................. 77 Etiqueta ......................................................................................................................................................... 77 Barra de progreso ..................................................................................................................................... 78 Descripcin emergente ........................................................................................................................... 78 Anexo B Definicin de las interacciones ................................................................................................... 79 Tipo de evento ................................................................................................................................................. 79 Anexo C Notacin de mapa de sitio ............................................................................................................. 81 Notacin general ............................................................................................................................................ 81 Vista ..................................................................................................................................................................... 81 Seccin ................................................................................................................................................................ 81 Plantilla .............................................................................................................................................................. 81 Conector ............................................................................................................................................................. 82 Anexo D Clasificacin de las anomalas ..................................................................................................... 83 Motivacin ........................................................................................................................................................ 83 Adherencia ........................................................................................................................................................ 83 Clasificaciones ................................................................................................................................................. 84 6
Patricio Fagalde
Disposicin................................................................................................................................................... 84 Actividad ....................................................................................................................................................... 84 Costo ............................................................................................................................................................... 84 Calendario .................................................................................................................................................... 85 Resolucin .................................................................................................................................................... 85 Sntoma.......................................................................................................................................................... 86 Tipo ................................................................................................................................................................. 87 Usabilidad ..................................................................................................................................................... 88 Glosario ................................................................................................................................................................... 89 Bibliografa ............................................................................................................................................................ 90
Patricio Fagalde
Captulo 1 Introduccin
rea de investigacin
Requerimientos En la ingeniera de software, un requerimiento es una necesidad singular documentada de la manera en que un producto o servicio particular debera desempearse. Bsicamente, los requerimientos deben listar qu debe hacer el sistema, dejando para etapas posteriores como debera hacerse. Otra manera de expresarlo es: un requerimiento expresa las necesidades y las restricciones de un producto de software que contribuyen a la solucin de algunos problemas del mundo real [1] . De acuerdo a Sommerville [2], estos requerimientos se pueden dividir en funcionales y no funcionales . Los requerimientos funcionales son declaraciones de los servicios que el sistema debe proporcionar, cmo debera reaccionar el sistema a ciertos estmulos particulares y cmo debera comportarse en situaciones particulares. Los requerimientos no funcionales son restricciones en los servicios o funciones que ofrece el sistema, como limitaciones de tiempo de respuesta, las limitaciones en el desarrollo de procesos, normas, etc. Dentro de los requerimientos no funcionales, se distinguen los de producto, los organizacionales y los externos. Los requerimientos de producto especifican que el producto entregado debe comportarse de una manera particular, por ejemplo, velocidad de ejecucin, fiabilidad, y otras. Los requerimientos de organizacin son consecuencia de las polticas de organizacin y procedimientos, por ejemplo, normas de procedimiento, con los requisitos de aplicacin. Los requerimientos externos se derivan de factores que son externos al sistema y su proceso de desarrollo, por ejemplo, requisitos de interoperabilidad, requisitos legales, entre otros. En los requerimientos de producto se encuentran englobados entre otros, los requerimientos de usabilidad, que vamos a abordar en este trabajo. Estos pueden definirse como los requerimientos cuyo objetivo es la efectividad, eficiencia y satisfaccin de los grupos de usuarios y tareas a los cuales se dirige este sistema. 8
Patricio Fagalde Usabilidad
La usabilidad es el grado en el cual un producto puede ser utilizado por sus usuarios para lograr metas con efectividad, eficiencia y satisfaccin en un determinado contexto de uso [3]. Est ntimamente relacionada a la percepcin del usuario respecto de la calidad del sistema; los algoritmos internos o la definicin de la arquitectura pueden ser excelentes, pero el usuario no tiene visibilidad de eso, sino de la interfaz con la que interacta. Se acerca a las fronteras del alcance de la ingeniera de software al estar ntimamente ligada con la evaluacin cognitiva y los modelos mentales del usuario, tareas que se desarrollan en el rea de la pedagoga y la psicologa. La usabilidad es un atributo de calidad de software, segn el modelo de calidad de software de ISO 9126-1, como la mantenibilidad y la portabilidad, por ejemplo. Procesos de desarrollo La concepcin de la ingeniera de software sobre los procesos de desarrollo ha ido evolucionando. En sus primeros aos el paradigma era un proceso en cascada; cada fase deba estar terminada para pasar a la siguiente. El enfoque de este proceso es ingenuo, en el sentido de que en la teora, es posible tener todo lo necesario para pasar a la siguiente etapa. Sin embargo, la prctica dicta que muchas veces los requerimientos, especificaciones o desarrollo no estn completos. La carga de recursos no es ptima, dado que por ejemplo los desarrolladores no tienen trabajo hasta que el anlisis termine. Este tipo de proceso no fomenta la vuelta sobre pasos previos y un desarrollo iterativo. A su vez, el nico punto de contacto con el usuario es al principio y al final del desarrollo, lo cual conlleva muchos desvos respecto de la concepcin del producto esperado. Este proceso evoluciona con Boehm y la definicin del proceso en espiral [4]. Este proceso tiene como objetivo reforzar las debilidades de su predecesor; la idea es mitigar los riesgos de mayor exposicin en las fases ms tempranas del proyecto e integrar prototipos previos a la entrega final. Las iteraciones tipificadas por el autor son, sin embargo, muy extensas para el estndar actual (alrededor de dos aos en la propuesta original de Boehm). Sin embargo, lo revolucionario de este trabajo fue romper con el modelo de proceso en cascada y ser precursor en el campo de los procesos iterativos, que es el paradigma vigente y, podra decirse, una caracterstica excluyente en los procesos modernos. 9
Patricio Fagalde
En un mercado que demanda que cada vez se involucre ms al usuario, la ltima dcada ha observado un auge en los procesos giles (al contrario de los procesos ms ceremoniosos y predictivos derivados de RUP). En ellos, se trabaja en iteraciones cortas, con alta integracin de los interesados (clientes y usuarios) en el proyecto, para mejorar la comunicacin, y apunta a generar entregables incrementales a fin de cada iteracin. En cualquier proceso de desarrollo, sea iterativo o en cascada, hay fases definidas y fcilmente reconocibles: Planificacin, elaboracin, despliegue y mantenimiento. Las organizaciones utilizan el proceso de desarrollo como instrumento de su poltica de produccin de software; los puntos de insercin de elementos de calidad y el nfasis que hacen estos elementos sobre el proyecto son las guas que van a caracterizarlo.
Identificacin del problema

Dentro de la ingeniera de software, en los procesos relacionados con la especificacin de los requerimientos, los proyectos de software son crticamente vulnerables cuando estas actividades son realizadas deficientemente. No es casualidad que en el CHAOS Report [5], unas de las mayores causas de xito percibidas en los proyectos de desarrollo de software son el involucramiento de los usuarios y la definicin clara de los requerimientos. Por otro lado, las razones ms importantes por las cuales los proyectos finalizan, pero fuera de presupuesto o calendario, son la falta de informacin del usuario, requerimientos incompletos y requerimientos cambiantes. Y sobre los factores que hicieron fracasar proyectos, tambin segn el CHAOS Report, se repiten las causas como requerimientos incompletos y falta de involucramiento por parte de los usuarios. Es de notar que la suma de los porcentajes de estas causas da ms del 25% sobre el total de causas posibles percibidas. Al da de hoy, estos factores siguen siendo igual de importantes. [6] Se desprende de lo expuesto que poder satisfacer las necesidades del usuario constituye un factor crucial para el xito de un proyecto, y especificar efectivamente los requerimientos de usabilidad es una de los caminos para lograr este objetivo. La manera de diagramar la organizacin de la informacin en la pantalla y el flujo entre ellas, se ha convertido en algo totalmente intuitivo y subjetivo, cuando no debera ser as. Dado que el xito de una aplicacin depende, en gran parte, de la aceptacin por parte del usuario, se debera poner ms nfasis en la formalizacin de estos requerimientos.
10
Patricio Fagalde
Adems, la tecnologa cambia y las herramientas se diversifican, lo que lleva a pensar que estos adelantos se deberan transformar en una mejora en la experiencia del usuario. Sin embargo, no siempre es as. Hacen falta lineamientos especficos, no subjetivos, que permitan aprovechar estas herramientas y lograr que el beneficio llegue a los actores que interacten con el sistema. Uno de los momentos ms crticos, en el sentido de la responsabilidad que se le transfiere al usuario, es cuando se introduce un cambio en la interfaz. En muchos casos, es difcil hacerlo gradualmente, y el mero aviso de que algo va a cambiar pronto, es insuficiente y slo acrecienta la ansiedad. Las tcnicas de especificacin de interfaces de usuario utilizadas actualmente varan desde la informalidad del prototipado rpido, con un experto dibujando en papel la interfaz y simulando la interaccin con el usuario, hasta el prototipado evolutivo, donde el mismo usuario puede verificar la interaccin en interfaces sobre aplicaciones reales. Estos ltimos prototipos evolutivos, son reutilizables, en el sentido de que el desarrollo puede evolucionar a medida que evolucionan los prototipos. Sin embargo, estas soluciones an tienen falencias que solo pueden ser mitigadas con una justificacin completa de las decisiones de diseo tomadas en los traspasos de la tarea al prototipo.
Aproximacin a la solucin
De lo expuesto anteriormente, hay ciclos de software diseados especficamente para hacer nfasis en la usabilidad y la interaccin con el usuario. El problema en este caso es que muchas organizaciones ya tienen sus procesos de desarrollo aceitados y sera una solucin extrema cambiar todo el proceso para mejorar la usabilidad, cuando encima esta presunta mejora puede empeorar otros aspectos de calidad. Por eso, la meta de este trabajo es conciliar una solucin que retenga aspectos comunes en procesos de desarrollo, agregando asimismo elementos que aumenten la calidad en cuanto a la usabilidad. Hasta aqu, cuando hablamos de usabilidad nos hemos referido a la misma en el sentido ms amplio. Pero a partir de ahora nos referiremos a la usabilidad en las pginas web. Para evaluar la usabilidad de un sistema nos basaremos, como se mencion anteriormente, en evidencia objetiva. Por lo tanto, hay que definir elementos que conforman las pantallas de un sistema de manera genrica, dejando de lado la tecnologa que se utilice para la renderizacin. Esto tambin ser til para tipificar la pantalla y adecuarla a un patrn ya conocido. Tambin servir para hacer un doble chequeo con un 11
Patricio Fagalde
test de regresin, que asegure que despus de hacer el cambio la funcionalidad seguir siendo la misma. Otro punto importante es documentar cmo estn ordenados los elementos en la pantalla y poder previsualizar cmo ser el cambio. Por lo tanto, vamos a tener que modelar con una herramienta adecuada. Con la documentacin generada al relevar el sistema obtendremos evidencia, que plasmaremos con la documentacin posterior al cambio en mtricas que ayudarn a evaluar el impacto obtenido. Finalizando, se aplicarn las tcnicas relatadas en un caso de estudio y se mostrarn los resultados obtenidos.
Estructura de la obra
En el captulo 2 se evaluarn las herramientas y metodologas existentes, con sus fortalezas y falencias, para delinear el camino a seguir. En el captulo 3 se definirn los criterios de diseo que se aplicarn a los artefactos a desarrollar. En el captulo 4 se describir el proceso y los artefactos de especificacin de requerimientos de usabilidad. En el captulo 5 se estudiar un caso ilustrativo, en el cual se aplicarn las actividades y artefactos de este trabajo. Finalmente, repasaremos los objetivos y llegaremos a conclusiones sobre el trabajo hecho.
Trabajos publicados relacionados con esta tesis

El proceso de revisin inversa de prototipos propuesto en la actividad de revisin del proceso (Ver Probar el prototipo con los usuarios, Artefactos de especificacin de requerimientos de usabilidad) fue enviado por el autor para la evaluacin en el 12vo Simposio de Argentino de Ingeniera de Software - ASSE en el marco de la edicin 40 de las Jornadas Argentinas de Informtica - JAIIO. Lautaro Mazzitelli, en su tesis de grado de sta misma casa de estudios [7] propone una serie de artefactos en notacin UML para la especificacin de requerimientos de
12
Patricio Fagalde
usabilidad y desarrolla mtricas tiles para evaluar la usabilidad de determinadas interfaces de usuario. Otra tesis de la misma carrera, la de Maia Naftali [8] , trata el tema de la accesibilidad, que est ligado a las interfaces de usuario, pero en otra perspectiva. La accesibilidad es la barrera que tienen los usuarios para poder utilizar el software, por lo tanto se sita en un nivel previo al de la usabilidad.
Estilo de citas
Al no haber un estilo de cita definido por la facultad para el uso en las tesis de grado, se utiliza el estilo del Instituto de Ingenieros Electricistas y Electrnicos (IEEE). Esto consta de encerrar los nmeros de cita entre corchetes y ordenar la lista de referencias por orden de citacin y no alfabticamente.
Herramientas
Para la ilustracin de las vistas se utiliz Balsamiq Mockups. sta aplicacin liviana, desarrollada en la plataforma de Adobe Air, tiene la ventaja de permitir la elaboracin de prototipos que parecen dibujados, reteniendo el aspecto familiar de un dibujo a mano alzada pero con la ventaja de poder ser modificado, incluso concurrentemente, sin tener que desechar el prototipo. Para la ilustracin de los mapas de sitio se utiliz Microsoft Visio.
13
Patricio Fagalde
Captulo 2 Estado de la cuestin

Introduccin
En este captulo se desarrollarn las soluciones alternativas existentes en la especificacin de los requerimientos de usabilidad, independientes del proceso de desarrollo, para poder realizar una evaluacin de las fortalezas y debilidades que presenta cada una y poder sacar los mejores elementos de stas. Para presentar un criterio de evaluacin uniforme, vamos a definir ciertas dimensiones por las cuales podemos medir los requerimientos de usabilidad.
Requerimientos
Estndar IEEE 830-1998 El estndar IEEE 830-1998 [9] sobre las prcticas recomendadas define ocho caractersticas de una buena especificacin de requerimientos Correcta El estndar asegura que no hay herramienta o proceso que asegure la correctitud de la especificacin de los requerimientos. Un algoritmo es correcto si la salida de ste se apega a su especificacin. Extrapolando, podramos decir que una especificacin es correcta si el producto final se apega a la especificacin. Decir que una buena especificacin es correcta, es entonces lo mismo que decir que cumple con sus objetivos, lo cual est implcito. Por lo tanto, al no poder probar esta propiedad de los requerimientos, por lo menos a priori, decimos que lo correcto o incorrecto de un requerimiento est implcito en su calidad. De acuerdo a los autores Zowghi y Gervasi [10], la correctitud es la combinacin justa de completitud y consistencia, lo cual refuerza la idea de que no se evala por s misma. No ambigua Una especificacin no es ambigua si cada requerimiento declarado tiene una sola interpretacin. Como mnimo, esto requiere que cada caracterstica del producto final se describa con un solo trmino. En el caso de que un trmino tenga distinto significado dependiendo de su contexto, deber estar especificado en un glosario. 14
Patricio Fagalde
Cuanto menos formal sea el lenguaje, mayores van a ser estos problemas. A la inversa, cuanto ms formal sea el lenguaje, ms difcil de comprender ser para los humanos, y menos flexibles a la hora de especificar que el lenguaje natural. La especificacin de los requerimientos generalmente se redacta en lenguaje natural, que es la manera de especificar menos formal , pero que suele ser el lenguaje de dominio de los usuarios. Los lenguajes naturales se ven afectados por tres problemas: ambigedad, imprecisin e inconsistencia. La ambigedad en el lenguaje natural es generalmente, semntica o conceptual, y no sintctica (debido a la estructura de las declaraciones). Para mitigar la ambigedad del lenguaje natural, se utilizan los lenguajes de especificacin de requerimientos. Una desventaja de estos lenguajes es que alejan al usuario al no poder validarlos directamente (no entiende los requerimientos). La otra es que quien especifica utilizando esta tcnica debe aprender y conocer el lenguaje. Leite y Franco [11] proponen el lxico extendido del lenguaje (LEL) como una herramienta para entender en mayor profundidad los trminos en el problema del dominio. LEL se basa en la premisa de entender el idioma del problema, sin preocuparse de entender el problema. Es una representacin en lenguaje natural que apunta a capturar el vocabulario de una aplicacin. La meta principal de LEL es registrar signos (palabras o frases) que son especificas del dominio [12]. LEL se puede considerar una herramienta mixta, dado que ofrece una notacin estricta y un mtodo para relevar los trminos, pero su descripcin es en lenguaje natural. Este enfoque es el que se puede considerar ptimo en el relevamiento de requerimientos. Completa Una especificacin est completa si no hay requerimientos con elementos a ser definidos, todos los requerimientos significativos estn expresados y todas las referencias estn definidas. Nuevamente, como con la correctitud, la completitud involucra la definicin de los lmites del sistema, e implica una clausura entre los requerimientos que no es posible con un enfoque informal. Consistente La especificacin de requerimientos debe ser consistente internamente (entre los propios requerimientos) y externa (con otros documentos de especificacin). Para favorecer la
15
Patricio Fagalde
consistencia a veces se eliminan o transforman requerimientos, lo que puede atentar contra la completitud. Priorizable La priorizacin ayuda a las partes interesadas a establecer cules son los requerimientos claves para el negocio. Dentro de una clasificacin previa, se puede dividir los requerimientos entre esenciales, condicionales y opcionales, y en cada lista ordenarlos por prioridad. A travs de distintas iteraciones del proceso de especificacin tambin se pueden ordenar los requerimientos por su estabilidad, o madurez de elicitacin. Verificable Un requerimiento es verificable si existe algn mtodo finito y sin costo excesivo para probarlo. En este aspecto, los requerimientos de usabilidad tienen el mismo problema que otros requerimientos no funcionales: slo pueden comprobarse una vez que el sistema est construido. Es recomendable que se validen con una mtrica que permita una evaluacin del tipo pasa / no pasa, dado que hay atributos de usabilidad que resultan muy subjetivos (un ejemplo de esto es la satisfaccin del usuario). Modificable Si bien todo requerimiento es potencialmente modificable, con esta propiedad nos referimos a que debe ser sencillo modificarlos, a la vez que se mantienen los dems atributos (como completitud y correctitud). Debern tener referencias cuando se relacionen con otros requerimientos, no ser redundantes, y ser atmicos con respecto a la funcionalidad que se especifica. Evaluar que un requerimiento sea modificable debera depender de la naturaleza del dominio tratado. Trazable La trazabilidad es la habilidad de verificar la historia, ubicacin o aplicacin de un tem a travs de identificacin almacenada documentada. El documento habla sobre trazabilidad para atrs (hacia etapas ms tempranas de desarrollo) y hacia delante (documentos derivados de la SRS, como por ejemplo, casos de uso). Anlisis Luego de haber descripto las caractersticas deseables de la especificacin de requerimientos de software (SRS por sus siglas en ingls, Software Requirements Specification), procederemos a clasificar cmo afectan estas caractersticas 16
Patricio Fagalde
particularmente a los requerimientos de usabilidad y cmo se relacionan entre s para poder establecer criterios de evaluacin sobre la calidad de los requerimientos. Que los requerimientos no sean ambiguos contribuye a la consistencia, dado que no hay dos declaraciones que definan distintas cosas. Entre las condiciones de que sea modificable est que no sea redundante. La redundancia fomenta la inconsistencia, debido a que una modificacin en una parte deja inconsistente la parte sin modificar. Que los requerimientos sean atmicos tambin contribuye con la consistencia. Por el otro lado, que un requerimiento sea verificable contribuye a que la especificacin sea completa, dado que las mtricas para verificar son objetivos visibles por el cliente. Que los requerimientos sean priorizables tambin contribuyen a la completitud, al poder discriminar en los que son esenciales para los objetivos de la organizacin y los que no. Por ltimo, la trazabilidad contribuye a la completitud, toda vez que toma elementos de etapas anteriores y es fcil ver si hay algo que sobra o falta de all. Formalidad La formalidad de la especificacin de requerimientos (tanto funcionales como no funcionales) es un tema de debate en la ingeniera de software. La especificacin de los requerimientos generalmente se redacta en lenguaje natural (dominio de los usuarios). Cuanto menos formal sea el lenguaje, mayores van a ser los problemas mencionados anteriormente [9]. A la inversa, cuanto ms formal sea el lenguaje, ms difcil de comprender ser para los humanos, y menos flexibles a la hora de especificar que el lenguaje natural. Las especificaciones informales pueden generar interfaces ambiguas con trminos como selecciona o enva, maneras de desplegar listas o reportes u otras interacciones con el usuario. En los casos que se anexan prototipos, muchas veces resultan deficientes al momento de hacerle entender al usuario el propsito de la pantalla, y cmo sta lo ayuda a alcanzar los objetivos. La especificacin de casos de uso, al no restringir el lxico, sufre de los mismos problemas de ambigedad y verificabilidad que el lenguaje natural, pero es ms fcil de entender para el usuario final. En el otro extremo del espectro, se encuentra la especificacin formal de requerimientos no funcionales. Mylopoulos y otros [13] elaboran un framework en el que estos requerimientos se evalan como objetivos, y en el que la naturaleza formal de su enunciado permite medir el grado en que un grupo de ellos son soportados por un diseo en particular. 17
Patricio Fagalde
Prototipado
El prototipado se refiere a la actividad de crear modelos previos a la construccin final para probar un concepto o proceso. Un prototipo emula ciertas caractersticas del producto final. Un tipo de prototipo conocido por el pblico general, para ejemplificar, puede ser una maqueta para una obra. Muestra las dimensiones relativas, el emplazamiento, da una idea de la visin del arquitecto o del ingeniero, y los interesados pueden dictar un juicio de valor sobre sta. Sin embargo, la obra real va a estar construida en hormign o estructuras metlicas, y no de cartn y telgopor, y sus dimensiones van a ser mucho mayores. Las diferencias en estas caractersticas no le quitan validez al prototipo como modelo. Prototipar tiene mltiples beneficios. Entre ellos, el diseador e implementador pueden tener realimentacin valiosa de los usuarios en las fases tempranas del proyecto. Adems, el cliente y el proveedor pueden comparar si el software construido coincide con las especificaciones. Tambin permite cierta percepcin de la precisin de las estimaciones iniciales del proyecto y si los hitos y vencimientos del calendario pueden ser cumplidos. El grado de completitud y las tcnicas utilizadas en el prototipado han sido desarrollados y debatidos desde los aos setenta. Nielsen [14] define dos dimensiones de prototipado: los prototipos horizontales y los verticales. Los primeros le dan una vista amplia del sistema al usuario , enfocando la atencin en la interaccin ms que la funcionalidad a bajo nivel, como por ejemplo, cualquier aspecto tcnico (el acceso a la base de datos, los protocolos de comunicaciones, etc.). Los prototipos horizontales son tiles para confirmar que se cumplen los requerimientos de la interfaz de usuario y el alcance del sistema. Tambin pueden servir para desarrollar estimaciones preliminares de tiempo, costo y esfuerzo para construir un sistema. Por otro lado, los prototipos verticales se utilizan para especificar en detalle distintas capas de un subsistema especfico. Los prototipos verticales sirven para refinar el diseo de la base de datos, obtener informacin en el volumen de datos y las interfaces que el sistema necesita, realizar el dimensionamiento de la red y establecer las necesidades de performance. Los prototipos verticales clarifican requerimientos complejos bajando a funcionalidad concreta. Otra forma de clasificar los prototipos es en su ciclo de vida, por lo cual se los puede separar en prototipos descartables o prototipos evolutivos. Los prototipos descartables se 18
Patricio Fagalde
refieren a los que se desarrollan cuando el modelo va a ser desechado, en lugar de formar parte del producto final. La fortaleza de los prototipos descartables es la informalidad y la agilidad con las cuales se crean. Los procesos de prototipado rpido permiten que los usuarios se involucren temprano en el desarrollo de software y se obtenga informacin valiosa sin invertir demasiado tiempo. Como desventajas del prototipado rpido, se puede enumerar que no permite visualizar desplazamientos de contenido, dificulta especificar mens desplegables, puede haber inconsistencia en la especificacin entre distintos prototipos y es difcil especificar la relacin con otras pantallas y la reaccin a un estmulo. El prototipado de las pantallas y la modificacin iterativa de los prototipos es un problema frecuente, dado que los prototipos que se muestran al usuario son estticos. Adems, no hay un formato estndar establecido para compartir los prototipos y modificarlos es tan trabajoso como desarrollarlos. Otro concepto relacionado al prototipado es que ste, muchas veces, es descartado despus de desarrollado el producto final. Sera conveniente poder reutilizar el esfuerzo invertido en crear los artefactos para construir el producto final. A continuacin se detallan algunos de los mtodos formales de prototipado utilizados hoy en da: DSDM y el Prototipado Operacional. Dynamic System Development Method (DSDM) es una metodologa de desarrollo de software gil. El enfoque al prototipado que tiene es abierto; pueden tratarse de prototipos verticales u horizontales, y descartables o evolutivos. DSDM clasifica los prototipos en cuatro categoras, de las cuales una de ellas es usabilidad. Los prototipos de este tipo se utilizan para definir, refinar y demostrar aspectos de la interfaz de usuario. En DSDM, los prototipos de usabilidad se desarrollan en la tercera etapa del proceso de desarrollo (iteracin de diseo y construccin). Estos prototipos son construidos en base a los acuerdos logrados en la iteracin anterior donde los prototipos funcionales ya fueron validados. Este prototipo de usabilidad es validado por diferentes grupos de usuarios. La salida de esta parte del proceso son los prototipos de diseo validados. Davis [15] propone la combinacin de prototipado evolutivo y descartable mediante la metodologa de Prototipado Operacional. En ella, un prototipo evolutivo es enviado a 19
Patricio Fagalde
distintos usuarios clave. Un prototipador se sienta con un usuario y va anotando las observaciones hechas por ste. Al finalizar la sesin, el prototipador modifica la primera versin y la transforma en un prototipo descartable. El proceso comienza de nuevo; si un cambio es recibido negativamente por el usuario, se remueve en ese momento. Por otro lado, si el cambio es recibido positivamente por el usuario, el prototipador escribe un pedido de nueva funcionalidad para el equipo de desarrollo. Luego, el equipo de desarrollo, con todos los pedidos de funcionalidad, construye un nuevo prototipo que ser la base de una nueva iteracin de este proceso. En cuanto a herramientas, los wireframes (literal: armazn de alambre) son prototipos visuales que representan la disposicin del contenido en una pgina web. Incluye elementos con los que el usuario interacta, y el foco est en la funcionalidad y no la apariencia. El foco del wireframing est en el tipo de informacin que se brinda, el rango de funciones disponible, las prioridades relativas de la informacin disponible, las reglas para mostrar cierta informacin y el efecto de los distintos escenarios posibles [16]. El wireframe conecta la estructura conceptual subyacente al diseo visual de un sitio. Aunque mayormente se lo asocia con el diseo de pginas web, tambin se puede utilizar para modelar aplicaciones web. Pero el traslado conceptual no es trivial; los grupos de usuarios que utilizan una pgina web y una aplicacin web son muy diferentes.
20
Patricio Fagalde
Captulo 3 Criterios de diseo

Motivacin
Hay varias razones que motivan la necesidad de especificacin de diseo de la interfaz de usuario en un proceso de desarrollo. En la mayora de los casos, la persona que especifica la interfaz puede que no mantenga su compromiso a lo largo de todo el proyecto. Esto deja al resto del equipo slo con presunciones sobre los fundamentos que tuvo el diseador para tomar las decisiones, y hay que adoptar un criterio potencialmente distinto para las modificaciones posteriores. La comunicacin entre el diseador y el resto del equipo puede ser restringida. An si el diseador es parte de la misma organizacin, puede estar afectado a ms de un proyecto. Por lo tanto, esta interaccin informal puede ser limitada con el resto del equipo. Por otro lado, los otros miembros del equipo, sobre todo aquellos de perfil ms funcional o incluso los usuarios, puede que no les resulte natural contactar al diseador, ya que muy probablemente no est entre sus interlocutores habituales. Tambin puede ser que prefieran hacer modificaciones a la interfaz a su propio criterio. Adems, con el tiempo el sistema va mutando, van cambiando las necesidades, y la interfaz va cambiando con ellas. Por eso, otra razn a considerar es que el mantenimiento de un producto no lo suele hacer el mismo equipo original de desarrollo, e incluso temporalmente se realiza fuera del ciclo habitual del proyecto. Sin embargo, casi ninguna metodologa de desarrollo exige la especificacin de estos artefactos. La especificacin de diseo de la interfaz de usuario nos permite, adems de las ventajas mencionadas anteriormente, aclarar nuestro entendimiento sobre los requerimientos y refinar en detalle el dominio del problema a resolver. De esta manera, ambas actividades, el diseo y los requerimientos, se realimentan positivamente. Parece importante hacer una distincin entre los distintos niveles de detalle que suelen asumir las organizaciones a la hora de especificar usabilidad: Una especificacin describe los controles especficos a utilizar, las interacciones, los datos, el contenido y las validaciones de la interfaz de usuario, para crear la experiencia del usuario.
21
Patricio Fagalde -
Una gua de estilo especifica el diseo de las pginas, la eleccin de los controles, y las posiciones de los controles en relacin con el conjunto, con la finalidad de ofrecer un aspecto coherente a lo largo de toda la aplicacin.
Las directrices de usabilidad especifican la misma a un nivel general de objetivos para los distintos tipos de interacciones.
Objetivo de los artefactos

Los artefactos necesarios para especificar requerimientos y diseo de usabilidad tienen los siguientes objetivos:
Que los requerimientos de usabilidad sean unvocamente acordados entre las partes interesadas
Que los fundamentos de las decisiones de diseo queden documentadas y que sigan los lineamientos acordados con los usuarios
Alcance
Para ser fieles a la realidad del mercado actual de aplicaciones, nos enfocaremos en la interaccin en las aplicaciones web. Sin embargo, se har el mayor esfuerzo en no depender de trminos tcnicos que nos limiten a stas. De los autores consultados, es interesante el planteo de Garrett [17]. Este autor establece cinco planos a considerar en el desarrollo de interfaces en la web, que, desde el ms abstracto al ms concreto son1: El plano estratgico (Strategy) El plano de alcance (Scope) El plano estructural (Structural) El plano de esquema (Skeleton) El plano superficial (Superficial)
Dentro del plano de esquema, hay tres componentes de diseo de una pantalla: diseo de la informacin, diseo de la navegacin y diseo de la interfaz. El diseo de la informacin es el que dicta cmo se despliega la informacin en la pantalla. El diseo de la navegacin pertenece a la visin de la web como un sistema de hipertexto; es el diseo de los
1
Garrett, al igual que Quesenbery [20], elige nombrar todos los niveles con la misma letra inicial; en ingls son
todas S, pero la traduccin que se elige aqu no permite tal consonancia
22
Patricio Fagalde
elementos de la interfaz que permiten al usuario navegar la arquitectura de la informacin, y de cmo se le hace entender el destino al que llevan estos enlaces. El diseo de la interfaz especifica cmo se disponen los elementos mediante los cuales el usuario interacta con el sistema. Mientras en las pginas web la informacin que se le brinda al usuario (por ejemplo, textos descriptivos, imgenes u otro contenido multimedia), es preponderante, en una aplicacin web sobresale la interaccin del usuario con el sistema. En este trabajo se especificar un proceso base, en el cual estarn definidas las actividades que soportan los artefactos. La intencin es darle mayor prioridad a la actividad de especificacin de los prototipos, por varias razones. En primer lugar, es el problema central de esta obra. Por otro lado, hay extensa bibliografa e implementaciones de las otras actividades. Sin embargo, estas actividades no son triviales, y sus entradas y salidas son tan importantes como las del proceso de prototipado para asegurarnos los objetivos. Por eso es que estn incluidas como la base del proceso en cuestin.
El proceso de desarrollo de software modelo

No hemos querido elegir un proceso de desarrollo bien conocido, sea Rational Unified Process (RUP), SCRUM, o cualquier otro. Esto por dos razones: para evitar una estructuracin innecesaria, y porque nos limitara excesivamente. En cambio, proponemos la definicin del mismo por medio de sus caractersticas deseables. El proceso de desarrollo debera ser iterativo e incremental: El sistema se desarrolla en ciclos continuos y en periodos cortos de tiempo, enfocndose en porciones pequeas de funcionalidad. Esto permite realizar entregas parciales cuando aplique, lo cual tiene dos ventajas: se valida con el cliente en un ambiente operativo que lo desarrollado se apega a lo especificado previamente; y se mitigan los riesgos derivados de las etapas tempranas de un proyecto. El proceso es guiado por casos de uso: Los casos de uso se utilizan para capturar los requerimientos funcionales y definir los contenidos de las iteraciones. Los casos de uso permiten continuar con la trazabilidad de los requerimientos a lo largo del proceso de desarrollo. Dentro de este proceso de desarrollo, el proceso de diseo propuesto se sita entre la finalizacin de la actividad de captura de requerimientos funcionales y la elaboracin del
23
Patricio Fagalde
sistema, solapndose con una etapa de anlisis detallado de los requerimientos tradicional.
Roles Los roles involucrados en la documentacin de diseo son los siguientes: Analista El analista es el responsable de tomar los requerimientos funcionales y traducirlos en tareas que el diseador pueda afrontar. Debe asegurar la exhaustividad en la descripcin, y definir en distintos niveles de detalle para comprender el problema del dominio completamente. Tambin es responsabilidad del analista recabar los requerimientos de usabilidad y definirlos junto a los usuarios. Diseador El diseador es quien tiene mayor responsabilidad en este proceso de especificacin. En l reside la autoridad en las decisiones de diseo, tanto de establecer un criterio como de justificarlas con un razonamiento. Toma como entradas el anlisis de las tareas y la realimentacin por parte de los usuarios respecto de las soluciones propuestas. Su tarea no es determinista: dos diseadores pueden llegar a distintas soluciones que ante determinados usuarios pueden ser igualmente vlidas. Debe tener en cuenta el contexto en el que se utilizar la aplicacin.
24
Patricio Fagalde Desarrollador
El desarrollador tiene en la especificacin de diseo de interfaz de usuario una referencia a la hora de construir el software. Tambin va brindar realimentacin en la etapa de diseo para ayudar al diseador a definir interfaces que sean realizables, o sea, que se puedan hacer con la tecnologa y recursos disponibles en un tiempo razonable. Estar liberado de la carga de tomar decisiones de diseo y podr enfocarse de lleno a la implementacin del sistema. Lder de proyecto El lder de proyecto puede ver en la especificacin de diseo de interfaz el alcance plasmado en mayor detalle. De ese modo, se torna en una herramienta ms a la hora de la planificacin y el aseguramiento de la calidad en el proyecto. Las actividades propuestas promueven la comunicacin con los usuarios y otros interesados, y son un buen medio para establecer posibles riesgos y buenas prcticas en el manejo de las anomalas. La documentacin generada le permite lograr mayor adherencia del cliente a la solucin propuesta y de entender las necesidades de los usuarios. Sponsors e interesados Los sponsors y dems interesados en general en el proyecto pueden visualizar fcilmente interfaces y como se navega entre las pantallas, que son dominios que pueden entender. Incluso podran tener un resumen de las tareas que realizan los usuarios finales, para priorizar las que ms se apeguen a la realidad y necesidad de la organizacin. Los artefactos son una buena herramienta de comunicacin y son fciles de entender para ellos. Usuarios Finalmente, los usuarios son los actores principales en este proceso. De por s, la eleccin de la arquitectura del proceso est centrada en ellos, por lo que el xito de una iteracin est basado en su aprobacin de las salidas producidas. Los usuarios son parte fundamental en las actividades de relevamiento, tomando como entrada su conocimiento de una tarea y su criterio de xito para los requerimientos de usabilidad, y en la actividad de validacin, revisando si el diseo especificado se apega a las tareas, o si hubo algn defecto en alguna etapa previa.
Notaciones
Green [18] defini unas tcnicas de evaluacin que sirven como criterios de diseo para interfaces, notaciones e interfaces de usuario, llamadas dimensiones cognitivas de las 25
Patricio Fagalde
notaciones. Se pueden utilizar como heursticas para guiar el diseo de un artefacto, como es el caso de esta tesis. Las dimensiones son las siguientes: Viscosidad La viscosidad est relacionada con la complejidad de acciones necesarias para lograr un objetivo. Un sistema viscoso necesita muchas acciones de un usuario para cumplir un objetivo. Por ejemplo, cambiar todos los encabezados a maysculas podra necesitar una accin por encabezado. Los ambientes que contienen abstracciones adecuadas pueden reducir la viscosidad. Se distingue entre viscosidad repetitiva, donde se necesitan varias acciones iguales para rectificar los objetivos, de la viscosidad en cadena, en la cual se necesitan acciones diferentes para recuperar la consistencia. Visibilidad La visibilidad es la habilidad de ver los componentes fcilmente. Los sistemas que ocultan informacin en encapsulaciones reducen la visibilidad. Dado que los ejemplos son importantes para la resolucin de problemas, estos sistemas son obsoletos frente a actividades exploratorias. Una actividad exploratoria es un tipo de investigacin conducida cuando un problema no ha sido totalmente definido. Si la consistencia de la transcripcin se debe mantener, se puede necesitar alta visibilidad. Compromiso prematuro El compromiso prematuro son restricciones en el orden en el que se pueden hacer las cosas, como por ejemplo, estar forzado a definir identificadores demasiado temprano, elegir un camino en un rbol de decisiones, elegir los cubiertos antes de elegir la comida. Dependencias ocultas Las dependencias ocultas son vnculos importantes entre entidades que no son visibles. Si una entidad cita a otra entidad, que a su vez cita a una tercera, cambiar el valor de la tercera entidad podra tener consecuencias inesperadas. Ejemplos de esto son las celdas en hojas de clculo, definiciones de estilo en procesadores de textos, jerarquas de clases complejas, enlaces en HTML. Expresividad de rol La expresividad de rol se refiere a la capacidad de inferir fcilmente el propsito de una entidad. Las notaciones con expresividad de rol hacen fcil descubrir por qu el programador o compositor ha construido una estructura de una manera en particular. En 26
Patricio Fagalde
otras notaciones, las entidades se ven iguales y descubrir las relaciones entre ellas es difcil. Evaluar la expresividad de rol requiere una conjetura razonable sobre representaciones cognitivas pero no requiere que el analista desarrolle su propio anlisis o modelo cognitivo. Propensin a errores La propensin a errores se da cuando la notacin induce a cometer errores y el sistema tiene poca tolerancia. Se sabe suficiente de la psicologa cognitiva de los deslices y errores como para predecir que ciertas notaciones invitan a ellos. La prevencin, por ejemplo la declaracin de identificadores puede corregir este problema. Estas dimensiones son tomadas como guas a la hora de definir los artefactos.
27
Patricio Fagalde
Captulo 4 Artefactos de especificacin de requerimientos de usabilidad

Descripcin general
Un artefacto es, en su definicin ms bsica, un subproducto de un proceso de desarrollo. Por lo tanto, para enmarcar esta investigacin, primero vamos a tipificar el proceso sobre el que vamos a trabajar. Este es un paso fundamental; dado que las caractersticas del proceso determinan los puntos de insercin de los elementos que nos permiten asegurar la calidad del producto respecto de la usabilidad. Como modelo de proceso, vamos a adoptar el que se llama diseo centrado en el humano, o HCD por sus siglas en ingls. sta metodologa tiene muchos aos de desarrollo, fue estandarizada primero en la norma ISO 13407 y recientemente actualizada por la ISO 9241-210. Las ventajas de la adopcin de un proceso de diseo centrado en el humano son, segn la ISO 13407 [19]: Son procesos fciles de entender y usar, con lo cual se reducen los costos de entrenamiento y soporte Mejoran la satisfaccin del usuario y reducen la incomodidad y la tensin Mejoran la productividad de los usuarios y la eficiencia operacional de las organizaciones Mejoran la calidad del producto, el inters de los usuarios y proveen actividad competitiva A continuacin se describen brevemente las actividades de este proceso, relacionndolas con las actividades propuestas por el estndar ISO 13407.
28
Patricio Fagalde
Ilustracin 1 Actividades propuestas por la norma ISO 13407 [19]
Identificar metas de usabilidad (Especificar las metas del usuario y la organizacin) Resumiremos qu metas de usabilidad queremos alcanzar con el diseo que vamos a proponer, poniendo en trminos del usuario cules son sus objetivos. Especificaremos a qu dimensin de la usabilidad estamos apuntando, para llevar cuenta de la prioridad relativa que le estamos dando. La salida de sta actividad es el Documento de Especificacin de Requerimientos de Usabilidad. Identificar usuarios y tareas (Especificar el contexto de uso) Definiremos los roles y la relacin con los usuarios del sistema. Una serie de escenarios representativos que representan tareas frecuentes y/o prioritarias. Se definir por lo menos un escenario por cada meta de usuario. La salida de sta actividad es el Documento de Especificacin de Contexto.
29
Patricio Fagalde
Ilustracin 2 Framework de usabilidad de acuerdo a ISO 9241-11 [3]
El anterior cuadro es un resumen de la definicin de usabilidad de la norma ISO 9241-11. A lo que se refiere es que el contexto de uso de un producto est formado por el propio usuario, la tarea que realiza, el equipamiento que utiliza para realizar la tarea y el ambiente en el que el usuario interacciona. Por ejemplo, un granjero (usuario) que desea plantar semillas (tarea) utilizando un arado (equipamiento) en una granja (ambiente). El producto en este caso sera la tierra. Desarrollar el prototipo (Producir soluciones de diseo) En esta actividad se desarrollar el prototipo de los escenarios seleccionados. Para esto, especificaremos el diseo en tres niveles: Diseo de la interaccin Diseo de la informacin Diseo de la navegacin
La salida de esta actividad es la Solucin de Diseo. Probar el prototipo con los usuarios (Evaluar diseo contra requerimientos) Se revisa de manera sistemtica la solucin de diseo propuesta con el usuario con una modalidad de revisin adaptada para que el usuario gue la misma. La salida de esta etapa es un Reporte de Anomalas. 30
Patricio Fagalde
Descripcin detallada de cada etapa

Identificar las metas de usabilidad En una primera instancia, se relevarn con los usuarios los requerimientos de usabilidad que guiarn las decisiones de diseo. La usabilidad, de acuerdo a Quesenbery [20], tiene cinco dimensiones, a las que llama Las cinco E: Efectividad (Effective) La exhaustividad y precisin con la que los usuarios logran sus objetivos. Eficiencia (Efficient) La velocidad (con precisin) con la que este trabajo puede hacerse. Atractivo (Engaging) Qu tan placentero, satisfactorio o interesante resulta el uso de una interfaz. Tolerante al error (Error tolerant) Qu tan bien el producto previene los errores, y ayuda al usuario a recuperarse en caso de uno. Facilidad de aprendizaje (Easy to learn) Qu tan bien el producto soporta tanto la orientacin inicial como el aprendizaje en profundidad. Es deseable atender a estos cinco atributos de manera uniforme. Sin embargo, hay que definir una prioridad entre estas dimensiones porque a menudo estn interrelacionadas. Ser ms estricto en un sentido puede resultar en degradar la calidad de otro atributo. Por ejemplo, en una aplicacin con formularios extensos, un error sin controlar puede llevar a prdida de informacin y rechazo por parte del usuario si tiene que cargar todos los datos desde cero. Por otro lado, una funcionalidad o tarea que se realiza frecuentemente debera ser rpida de realizar. La prioridad que le daremos a cada una de estas dimensiones vendr dada por los objetivos propuestos. Los autores Lauesen y Younessi [21] realizaron un estudio que recopila los estilos comunes de redaccin de requerimientos de usabilidad en lenguaje natural. Los seis estilos son: Rendimiento Definiendo tareas y grupos de usuario en los que la usabilidad es importante, y mtricas sobre el rendimiento esperado. 31
Patricio Fagalde
Ejemplo: Determinado porcentaje de un grupo de usuarios deber finalizar la tarea correctamente en una cantidad de tiempo estipulada. Defecto Identificando defectos de usabilidad y poniendo una cota superior en ellos Ejemplo: Determinado grupo de usuarios no deber tener ms que una cantidad acordada de inconvenientes para terminar una tarea concreta. Proceso Especificando requerimientos de usabilidad sobre los procesos y no sobre el negocio. Ejemplo: Deber haber por lo menos tres prototipos sobre determinada tarea y debern ser validados con el usuario. Este tipo de requerimiento no aplica, dado que est implcito en el proceso. Subjetivo Pone una meta en la satisfaccin del usuario. Ejemplo: Un determinado porcentaje de usuarios despus de usar el sistema podran calificarlo como satisfactorio. Diseo Especificando prototipos para definir los requerimientos de usabilidad Ejemplo: El sistema deber utilizar determinado control cuyo comportamiento ser como el de otro sistemaestablecido . Este tipo de requerimiento no aplica, dado que est implcito en el proceso. Directriz Definiendo un documento de lineamientos de usabilidad. Ejemplo: Para los ingresos con una cantidad de valores posibles limitados, el usuario deber poder seleccionar un valor de una lista. Este tipo de requerimiento no aplica, dado que est implcito en el proceso.
32
Patricio Fagalde
Entonces tendremos los requerimientos especificados en una plantilla de esta manera: Identificacin Dimensin de usabilidad que mide este requerimiento o o o o o o o o o o o Efectividad Eficiencia Atractivo Tolerancia al error Facilidad de aprendizaje Esencial Condicional Opcional Rendimiento Defecto Subjetivo
Prioridad
Tipo de Redaccin
Declaracin del requerimiento Usuario o rol que lo validar
La salida de esta actividad es un documento con la lista de requerimientos de usabilidad como fue descripta anteriormente. A este artefacto lo llamaremos Documento de Especificacin de Requerimientos de Usabilidad.
33
Patricio Fagalde Identificar usuarios y tareas
En esta etapa necesitamos identificar a los usuarios del sistema y las tareas que necesitan completar. Los usuarios son una parte de los interesados (stakeholders). Un interesado es un individuo que es materialmente afectado por el resultado de un proyecto. En el estudio de la creacin de un sitio web se utiliza mucho la tcnica de relevamiento de personas. Persona es el trmino griego de mscara, y no se refiere al trmino en castellano de persona que es el que manejamos habitualmente. La diferencia es que, en el diseo web se valen de esta tcnica porque no conocen a la instancia de usuario real que va a utilizar su producto. En cambio, en la mayora de los casos en una aplicacin conocemos los usuarios concretos que van a usarla. La persona sirve para dos motivos: uno, tipificar el objetivo de la audiencia que va a ser parte del proyecto, y otra guiar el diseo hacia esa audiencia. Si pudisemos hacer un paralelismo entre las personas y nuestros objetivos, sera fcil de reconocer los roles que cumple un usuario en la organizacin. sta es una clasificacin tpica a la hora de especificar los usuarios. Una serie de preguntas que nos podemos hacer para reconocer a los usuarios del sistema: Quines van a ser los usuarios finales del sistema? Quin va a ser afectado por la salida que produce el sistema? Quin va a evaluar y aprobar los diseos que se producen con este proceso? Hay usuarios externos cuyas necesidades deben ser atendidas?
Para tipificarlos, tendremos en cuenta las siguientes caractersticas, tomadas de las tres dimensiones de los usuarios de Nielsen [14]. La clasificacin deber ser de un conjunto de usuarios con un conjunto de habilidades similares y otras caractersticas que comparten los mismos roles y responsabilidades dentro del mbito del sistema. Usuario Nombre Rol Descripcin general Conocimiento del tipo de sistema (Alto/Medio/Bajo)
34
Patricio Fagalde
Como conocimiento del sistema nos referimos a los mecanismos que se utilizan para convertir las entradas en salidas. Un tipo de sistema puede ser, por ejemplo, una aplicacin web. Conocimiento del dominio (Alto/Medio/Bajo) Como dominio nos referimos al dominio de la naturaleza de las tareas que este usuario tpicamente desempea, como puede ser un empleado que recin ingres a una organizacin, o un gerente con muchos aos de experiencia en una tarea. Conocimiento del medio (Alto/Medio/Bajo) Como medio nos referimos al uso de, por ejemplo, una computadora, un navegador, etc. Un usuario puede conocer muy bien una tarea pero hacerla por otro medio, como por ejemplo, procesar y completar formularios en papel, pero no saber completar un formulario web. Con respecto a las tareas tenemos las siguientes caractersticas: Tareas Nombre de la tarea Objetivo de la tarea Requerimiento funcional relacionado Desglose de la tarea Frecuencia de uso de la tarea Alta Media Baja
Se sugiere que para completar las categoras sugeridas, se tenga en cuenta la apreciacin subjetiva del usuario, y se evidencie el porqu de la decisin. Este es un atributo importante dado que es un factor para poder priorizar en etapas posteriores. A menudo Con frecuencia Frecuentemente Muchas veces Mucho Siempre Tantas veces Todo el da Todo el tiempo 35 Alta Alta Alta Alta Alta Alta Alta Alta Alta
Patricio Fagalde A veces De vez en cuando Generalmente Varias veces Nunca Media Media Media Media Baja
Los trminos como cada ao, cada da, todas las semanas o todos los das dependen fuertemente del uso general que se le da al sistema y queda a criterio de quien releva la tarea. Duracin de la tarea Alta Media Baja
Como en la frecuencia, la duracin de la tarea es un atributo importante y se debe justificar la decisin de la clasificacin objetivamente. Dependencias de la tarea Las dependencias deberan ser otras tareas. Por ejemplo, si como parte de esta tarea es obligatorio asociar un elemento que se crea en otra, vamos a tener como dependencia esta otra tarea. Para desglosar el contenido de la tarea, se propone una forma reducida de anlisis de tareas [22]. El anlisis de tareas es el estudio de lo que el usuario quiere hacer en trminos de acciones o procesos cognitivos para lograr una tarea, proveyendo conocimiento sobre la tarea que el usuario quiere realizar. El proceso de anlisis de tareas tiene los siguientes pasos: 1. Identificar la tarea a ser analizada de una lista de tareas previamente relevadas. 2. Partir esta tarea entre 4 a 8 sub-tareas. Cada una de estas sub-tareas deben estar especificadas en trminos de objetivos y entre ellos deberan cubrir toda el rea de inters. 3. Decidir si este nivel de descomposicin es suficiente o es necesario recabar ms informacin. Hay que tener en mente que en esta etapa es necesario llegar a tener suficiente detalle como para poder especificar la interfaz con el usuario, modelar las interacciones y la navegacin. 4. Volver al paso 2, sta vez subdividiendo las sub-tareas. 36
Patricio Fagalde
5. Una vez terminado el proceso, mostrar el resultado a alguien que conozca bien la tarea pero no haya estado involucrado en el anlisis. Finalmente, para relacionar las tareas con los usuarios, usaremos una matriz simple donde en una dimensin tenemos los usuarios y en la otra tenemos las tareas. Podemos especificar las tareas en las que el usuario es una actor principal o frecuente y aqullas en las que el usuario es un actor secundario, solo forma parte de alguno de los pasos de la tarea o la salida de la tarea no lo afecta en gran medida. La salida de esta actividad sera un documento con la lista de tareas, la lista de usuarios y la matriz de usuarios tareas como fueron descriptas anteriormente. A este artefacto lo llamaremos Documento de Especificacin de Contexto.
37
Patricio Fagalde Desarrollar el prototipo
La solucin de diseo propuesta va a ser compuesta por diferentes partes, segn la separacin del diseo de la interfaz de usuario de Garrett antes citado [17]: El diseo de la interaccin va a estar basado en el Diccionario de elementos, que describe en detalle de qu manera el usuario va a transferir al sistema las entradas. El diseo de la informacin, donde se van a definir las vistas que contendrn los elementos definidos en el diseo de la interaccin. El diseo de la navegacin, que va a estar basado en el Mapa de Sitio, donde se pueden visualizar a alto nivel las vistas y la interaccin entre ellas. Las especificaciones en conjunto van a conformar el artefacto llamado Solucin de diseo.
38
Patricio Fagalde Diseo de la interaccin Descripcin
El diseo de la interaccin consiste en seleccionar los elementos correctos para la tarea que el usuario quiere lograr y ordenarlos en la pantalla de manera que se entienda fcilmente y pueda ponerse productiva rpidamente [17]. Usamos los controles definidos en el
39
Patricio Fagalde Diseo de la navegacin Mapa de sitio
Conectores Interaccin: CLICK_REGISTRAR Vista desde: REGISTRO_DATOS Vista hasta: REGISTRO_CAPTCHA
40
Patricio Fagalde
Reporte de anomalas
El lder completa una planilla con las anomalas detectadas. ID Descripcin 1 No debera ser obligatorio preguntar el sexo para registrarse 2 No hay criterio de bsqueda en la bsqueda rpida 3 Se deberan separar los campos de email en el registro para que sea ms intuitivo 4 La descripcin debera estar marcada como optativa Sntoma Entrada Parmetros incompletos o faltantes Tipo Problema de documentacin tem incompleto Entrada Problema de Descripciones documentacin incorrectas o tem confuso faltantes Entrada Mejora Entrada incorrecta aceptada Entrada Entrada correcta no aceptada Usabilidad Responsable Degradada Analista
Afectada
Analista
Afectada
Diseador
Requerimientos No Mejorar afectada usabilidad
Diseador
Conclusiones del caso de estudio Con este caso de estudio pudimos observar la manera de la cual el usuario y el equipo interactan en el proceso, generando los artefactos. Se ilustr nicamente una iteracin, pero este proceso es netamente iterativo; dado el impacto de las anomalas pueden pasarse a otro ciclo o entregar los requerimientos con observaciones.
41
Patricio Fagalde
Conclusin
Aunque el diseo y el desarrollo idealmente iteran, la realidad dicta que generalmente estas dos etapas se separan. Por lo tanto, muchas veces los diseos se cambian sin aporte del diseador, sin un conocimiento profundo del aporte que el diseo hace a los objetivos del usuario y sin el fundamento de las decisiones de diseo. Los diseos siempre cambian a lo largo del proceso de desarrollo por diversas razones que no es el caso analizar aqu. La documentacin de diseo ayuda a que el producto final se corresponda con los objetivos de usuario originales e informe sobre los cambios requeridos. Tambin es capaz de capturar todas las decisiones y fundamentos tomados para que el resto de los miembros del equipo los tenga presentes. Es responsabilidad de la organizacin que implemente estos artefactos decidir el nivel de detalle en el cual se apega a estas especificaciones de acuerdo a la realidad que dictan sus tipos de clientes y proyectos. Como comentario final, podemos concluir que la aplicacin de estos artefactos tiene los siguientes beneficios: El proceso, al estar basado en HCD, asegura que los requerimientos funcionales y de usabilidad detrs de la interfaz de usuario y el diseo de interaccin son plasmados en el producto final. El diseo es iterativo y tiene como prioridad las metas de los usuarios. La documentacin puede ser utilizada tanto como entradas para la elaboracin del software como para comunicar a los interesados sobre el refinamiento de los requerimientos.
42
Patricio Fagalde
Diccionario de . Se pueden definir ms controles de acuerdo a las necesidades, siguiendo la plantilla especificada. La definicin de la interaccin debera tener, como mnimo: Tipo de evento (Ver
43
Patricio Fagalde Definicin de las interacciones) Causa Consecuencia
La causa y la consecuencia pueden ser una de estas dos cosas: Vista o Seccin (Ver
44
Patricio Fagalde Notacin de mapa de sitio) Elemento (Ver Diccionario de )
El concepto de interaccin se puede ver plasmado en el siguiente diagrama de clases:
Procedimiento 1. Recorremos la tarea, fijndonos si hay un indicio de interaccin del usuario sistema 2. Si encontramos interaccin, buscamos el elemento adecuado para el estmulo (Ver Diccionario de elementos) 3. Agregamos el elemento a la lista de elementos con los siguientes datos: a. ID - autoincremental b. Cdigo Todo en maysculas, palabras separadas por guiones bajos, si el campo es optativo en cursiva
45
Patricio Fagalde
c. Tipo de elemento, seleccionado del Diccionario de elementos o sino, declarar un tipo de elemento para definirlo ms adelante. d. Descripcin Puede ser el texto literal que acompaa la etiqueta de un elemento o una descripcin ms extensa de por qu ese elemento fue seleccionado. 4. Para mayor claridad, estos elementos se pueden agrupar por seccin 5. Para cada interaccin, definirla siguiente manera: Tipo de evento (Ver
46
Patricio Fagalde a. Definicin de las interacciones) b. Causa (Elemento , Seccin o Vista) c. Consecuencia (Elemento, Seccin o Vista) i. Condicin en la cual se da la consecuencia
6. Si quedo algn elemento sin definir, definirlo ahora con la plantilla del Diccionario de elementos La salida de esta parte de la actividad sera un documento con la lista de elementos como fueron descriptos anteriormente y el diccionario de elementos nuevos definidos. A este artefacto lo llamaremos Documento de Especificacin de la Interaccin.
47
Patricio Fagalde Diseo de la informacin Descripcin
Los elementos especificados anteriormente tienen que ser organizados visualmente en la pantalla. Por lo tanto, necesitamos ubicarlos en lo que llamaremos una vista. La vista es una representacin visual de la disposicin de los elementos en una pantalla. Los datos que debe tener esta vista son, como mnimo: Nombre de la vista Dimensiones (pueden ser expresadas en pixeles, mm, cm) Imagen con la disposicin relativa de los elementos, etiquetados
En ocasiones es necesario dar cierta realimentacin al usuario sobre la interaccin. A veces esto es una ventana emergente o una seccin de la pantalla que indica el error, advertencia o informacin adicional. Por lo tanto, se sugiere agregar adems de una vista con la pantalla, como si el usuario la estuviera cargando por primera vez: una vista que ejemplifique cmo se van a mostrar estos mensajes. Procedimiento 1. Crear la imagen de la vista con el tamao suficiente para disponer de los elementos que contiene. No tiene que ser necesariamente en escala 1:1, pero las proporciones deben mantenerse. 2. Recorrerla Lista de elementos generada en el Diseo de la interaccin. Agregar la representacin grfica del elemento a la imagen. 3. Agregar una llamada al elemento con el nmero de ID correspondiente a la Lista de elementos. Una llamada es un nmero dentro de un crculo resaltado. Si la vista est compuesta por ms de una seccin, resaltar las llamadas de las mismas secciones del mismo color. 4. Chequear que la tarea pueda ser recorrida con la pantalla de la manera actual. De lo contrario, volver a la definicin de los elementos o arreglar nuevamente los controles en la vista, segn corresponda. La salida de esta parte de la actividad sera un documento con las vistas como fueron descriptas anteriormente. A ste artefacto lo llamaremos Documento de Especificacin de la Informacin.
48
Patricio Fagalde Diseo de la navegacin Descripcin El diseo de la navegacin tiene que cumplir tres objetivos [17]: -
Proveer a los usuarios con los medios para recorrer la aplicacin Comunicar la relacin con los elementos que contiene Comunicar la relacin entre sus contenidos y la vista actual
Mapa de sitio Un mapa de sitio es una manera de visualizar pginas representativas en una aplicacin que se puede beneficiar de identificar pginas, vistas, estados e instancias de lo que se debe mostrar [23]. No confundir con el mapa de sitio como herramienta alternativa de navegacin, donde los usuarios tienen vnculos a todas las pginas de un sitio y stas estn organizadas por contenido. Debe cumplir con dos condiciones para resultar til: Debe ser una taxonoma, porque queremos clasificar pantallas por su contenido Debe ser jerrquica, para organizar el contenido desde la mayor abstraccin a la materializacin concreta del contenido
La notacin a utilizar en el mapa de sitio est especificada en
49
Patricio Fagalde
Anexo A Definicin de las interacciones

Tipo de evento
Cdigo Teclado KEY_PRESSED Tecla o combinacin de teclas KEY_UP Tecla levantada Cuando la tecla dej de estar presionada KEY_DOWN Puntero MOUSE_OVER De adentro hacia afuera MOUSE_OUT De afuera hacia adentro MOUSE_CLICK MOUSE_DOUBLE_CLICK Clic Doble Clic Cuando el puntero sali del rea de interaccin del elemento Cuando el puntero entr en el rea de interaccin del elemento El usuario hizo clic en el elemento El usuario hizo doble clic en el elemento MOUSE_SECONDARY_CLICK Clic secundario El usuario hizo clic con el botn secundario Vista VIEW_LOAD VIEW_SUBMIT En la carga En el envo Al cargarse la vista Al enviar datos a travs de un Tecla presionada Cuando la tecla fue presionada Cuando la tecla o combinacin de teclas fue presionada y levantada Nombre Descripcin
50
Patricio Fagalde formulario Elemento ELEMENT_BLUR Perder foco
El elemento perdi foco, o sea, estaba seleccionado para ingresar datos pero ahora no lo est ms
ELEMENT_FOCUS
Ganar foco
El elemento gan foco, o sea, fue seleccionado para ingresar datos
ELEMENT_CHANGE
Cambio
El elemento cambi su valor
51
Patricio Fagalde Notacin de mapa de sitio. Conector
El conector es el elemento que permite la unin de navegacin entre dos vistas. La accin de un conector debe ser detallada por separado, y debera tener como mnimo: Identificador del conector Vistas que vincula Identificador de la interaccin que dispara la navegacin
Procedimiento 1. Para todos los vnculos de la Lista de elementos, definir un conector. 2. Para todos los botones que tengan accin de navegacin en la Lista de elementos, definir un conector. 3. Una vez definidos todos los conectores, dibujar todas las vistas relacionadas y sus conexiones. Ver Notacin de mapa de sitio para detalle de la notacin.
52
Patricio Fagalde Probar el prototipo con los usuarios
Para probar la solucin de diseo, se adapta un proceso de recorrida del estndar IEEE Std. 1028-1997 [24]. Introduccin Una recorrida (walkthrough) es una actividad de revisin por pares en el que un programador o diseador conduce miembros del equipo de desarrollo y otras partes interesadas a travs de un producto de software, mientras los participantes hacen preguntas y comentarios acerca de los posibles errores, la violacin de las normas de desarrollo, y otros problemas. El propsito de esta actividad es evaluar y validar el diseo producido en la anterior etapa. Una variacin de la revisin es la revisin inversa. En ese caso, el usuario recorre el producto de software y describe los pasos para llevar a cabo una tarea. La ventaja que esto presupone es que el usuario valida la solucin de diseo, justificando que decisin toma en cada paso. El propsito de esta actividad es evaluar el diseo producido en la etapa anterior. Sus objetivos son: Encontrar anomalas Mejorar el diseo Considerar implementaciones alternativas Evaluar adherencia a especificaciones y estndares
Responsabilidades Los siguientes roles son establecidos para la recorrida: a) Lder b) Registrador c) Autor d) Usuario a) Lder El lder debe conducir el recorrido, manejar las tareas administrativas pertinentes al recorrido (distribuir documentaciones y coordinar la reunin) y asegurarse de que la reunin se lleva de manera ordenada. El lder deber preparar una declaracin de los objetivos para guiar al equipo en el recorrido. Tambin debe limitar a un tem de accin o 53
Patricio Fagalde
decisin determinado para cada punto de discusin. Finalmente, deber expedir la salida de esta actividad. b) Registrador El registrador deber anotar todas las decisiones y acciones identificadas que ocurran en la reunin. Adicionalmente, debe registrar todos los comentarios respecto de las anomalas encontradas, cuestiones de estilo, omisiones, contradicciones, oportunidades de mejora o enfoques alternativos. c) Usuario El usuario debe presentar el diseo en el recorrido. Entrada Las entradas del recorrido son: a) Declaraciones de los objetivos para el recorrido b) La tarea a ser recorrida con el diseo c) El diseo a ser examinado d) Los estndares en vigencia en relacin al diseo e) Categoras de anomalas (Ver Anexo A - Clasificacin de anomalas) Procedimiento 1. El autor hace un resumen del objetivo de la solucin de diseo a presentar. 2. Cada miembro del equipo debe estar preparado para la reunin, habiendo repasado el material de entrada provisto por el lder previamente. 3. El lder presenta a los participantes y describe sus roles. Debe recordar que hay que enfocarse en la deteccin de anomalas y no en su resolucin. Tambin debe recordar que deben comentar sobre el prototipo y no sobre su autor. Los miembros del equipo pueden preguntarle al autor sobre el prototipo. El autor no debe inducir de ninguna manera la manera de llevar a cabo el flujo de la pantalla. 4. Discusin general, basada en los tems que generaron antes la reunin. 5. Discusin detallada, donde el usuario recorre en detalle el prototipo y los mapea con los pasos de la tarea a seguir. Durante la reunin: 1. El autor o el lder deben hacer un resumen en modo de presentacin sobre el prototipo bajo revisin. 54
Patricio Fagalde
2. El lder debe coordinar la discusin sobre las inquietudes generales. 3. El usuario, guindose con la tarea, debe describir, en voz alta, cmo mapea un paso lgico de sta con una accin con el prototipo. 4. Los miembros del equipo deben notar anomalas especficas cuando el usuario llega a una parte del prototipo relacionada. 5. El registrador debe anotar las recomendaciones y acciones que devienen de la discusin de las anomalas. Despus de la reunin, el lder debe emitir la salida de la reunin de acuerdo a lo explicado en la seccin Salida. Salida La salida de la reunin debe tener, como mnimo, los siguientes puntos: Los miembros del equipo y sus roles El producto examinado Una declaracin de los objetivos que deban ser cumplidos durante la reunin y si fueron cumplidos. Una lista de recomendaciones hechas sobre cada anomala Una lista de acciones, fechas lmite y responsables Las recomendaciones hechas por el equipo de trabajo sobre cmo disponer de las deficiencias y anomalas no resueltas Las propuestas hechas por el equipo de trabajo sobre el seguimiento de las anomalas La salida de esta actividad conformar el documento llamado Reporte de anomalas.
55
Patricio Fagalde
Captulo 5 Caso de estudio

Descripcin
Se va a estudiar un caso tpico de interaccin con el usuario: Un foro de debate. Se espera mediante este escenario recorrer todas las actividades del proceso y observar las salidas para verificar cmo se plasman los objetivos de los usuarios en la especificacin. Un foro de debate o tablero de mensajes es un sitio de debate en lnea en el cual la gente puede tener conversaciones en forma de mensajes publicados. Este foro de debate es sobre derecho. Si bien hay muchos usuarios que no estn familiarizados con este tipo de aplicaciones, son los que pueden enriquecer ms los debates con su conocimiento (por ejemplo, abogados con mucha trayectoria que nacieron mucho antes del boom de las computadoras personales y todava usan la mquina de escribir para redactar escritos). Por otro lado, hay estudiantes de derecho que van al sitio buscando informacin y opinin sobre jurisprudencia. Estos usuarios s conocen las herramientas y en su mayora han utilizado un foro de debate anteriormente. Requerimientos funcionales (parciales) El usuario podr registrarse en el sitio. El sitio tendr foros de debate con distintos temas El usuario contar con la posibilidad de crear un nuevo tema de debate en un foro seleccionado.
56
Patricio Fagalde
Documento de especificacin de requerimientos de usabilidad

Objetivos de usuario Los usuarios quieren hacer bien la tarea en el entorno de aprendizaje. Los usuarios quieren expresar su opinin de un tema rpidamente.
Tipo de usuarios Tipo I: Tienen experiencia en herramientas informticas y navegacin web. Han usado foros de debate en lnea de otros proveedores anteriormente. Tipo II: Tienen experiencia en herramientas informticas y navegacin web. No han usado foros de debate en lnea anteriormente. Metas de usabilidad Meta 1: En un grupo de usuarios tipo I, el 80% deber terminar la tarea correctamente. Meta 2: En un grupo de usuarios tipo II, el 60% deber terminar la tarea correctamente. Meta 3: El 80% de los usuarios deber crear un nuevo tema de debate, que contenga no ms de 50 palabras, en menos de cinco minutos. Meta 4: El 80% de los usuarios deber declararse conforme o muy conforme al preguntarle por la facilidad de uso de la herramienta para crear nuevos mensajes Meta 5: No ms del 20% de los usuarios de Tipo II deber declarar en una encuesta que tuvo dificultades para utilizar la herramienta para crear nuevos mensajes por primera vez. Meta 6: El 90% de los usuarios tienen que completar la tarea solamente con la informacin que proporciona el sistema Meta 7: No ms del 20% de los encuestados deber responder afirmativamente a la pregunta sobre si el usuario al ser ofrecido entre ver el mensaje creado o ir a ver otros mensajes, elige ver el mensaje creado para saber si se cre bien.
57
Patricio Fagalde Matriz

Dimensin Facilidad aprendizaje Tolerancia al error Acoplamiento Prioridad Rendimiento
Tipo
Condicional
Efectividad
Eficiencia
ID Nombre
Subjetivo X
Opcional
Esencial
Defecto
Usuario
1 2 3 4 5 6 7
Meta 1 Meta 2 Meta 3 Meta 4 Meta 5 Meta 6 Meta 7 Total
X X X X X X
X X X X X X
X X X X X X
X X 33% 17% 17% 13% 9% 83% 17% 0%
Tipo I Tipo II Todos Todos Tipo II Todos Todos
58
Patricio Fagalde
Documento de especificacin de contexto

Tarea 1: Registrarse en el sitio Flujo normal El usuario ingresa o o o o o o o Nombre Apellido Correo electrnico Confirmacin del correo electrnico Contrasea Sexo (Hombre/Mujer) Da, mes y ao de su fecha de nacimiento
El usuario confirma enviar la informacin que complet El usuario ingresa las palabras que observa en una imagen dinmica El usuario confirma enviar la informacin que complet
Validaciones CAMPOS_OBLIGATORIOS: Todos los campos son obligatorios CORREO_INVALIDO: El correo electrnico debe ser vlido CORREO_NO_COINCIDENTE: Correo electrnico y confirmacin del correo electrnico coinciden CONTRASEA_CORTA: La contrasea debe tener una longitud mnima de 6 caracteres CAPTCHA_COINCIDE: El texto de la imagen dinmica y el texto que complet el usuario deben coincidir Tarea 2: Crear un nuevo tema de debate Precondicin El usuario debe estar registrado y autenticado en el sitio
Flujo normal El usuario selecciona un foro para visualizar sus temas. Los foros estn divididos en categoras y listados de la siguiente manera: o Tiene un mensaje nuevo desde la ltima vez que el usuario visit el foro? (Si/No) o Ttulo del foro o Descripcin del foro 59
Patricio Fagalde o o o
Cantidad de temas Cantidad de mensajes ltimo mensaje Ttulo del tema Fecha Usuario que lo hizo El sistema muestra o Ttulo del foro o La posibilidad de crear un nuevo mensaje o La navegacin dentro del foro o Cuadro de bsqueda rpida o Una lista paginada de temas con los siguientes datos: Tiene un mensaje nuevo desde la ltima vez que el usuario visit el foro? (Si/No) Ttulo del tema Descripcin del tema Navegacin de las pginas del tema, si tiene ms de una Cantidad de respuestas en el tema Autor Lecturas ltimo mensaje Ttulo del tema Fecha Usuario que lo hizo o Lista desplegable con los otros foros para navegacin rpida El sistema despliega los siguientes campos para ser completados: o Asunto o Descripcin o Cuerpo del mensaje El usuario completa los campos y confirma los datos ingresados El sistema crea el mensaje en el foro seleccionado
Validaciones El mensaje tiene que tener ms de N caracteres, siendo N un parmetro a definir por el administrador (LONGITUD_MENSAJE_INSUFICIENTE) Todos los campos del mensaje son obligatorios (CAMPOS_REQUERIDOS)
60
Patricio Fagalde
Solucin de diseo
Diseo de la interaccin Lista de foros ID 1 2 3 4 5 6 6.1 6.2 Nombre MENSAJE_NUEVO TITULO_FORO DESCRIPCION_FORO CANTIDAD_TEMAS CANTIDAD_MENSAJES Tipo Indicador ON/OFF Vnculo Etiqueta/Texto Etiqueta/Nmero Etiqueta/Nmero Descripcin Ttulo del foro Descripcin del foro Cantidad de temas del foro Cantidad de mensajes de los temas del foro Ttulo del tema Formato - Hoy/Ayer/Lu Dom - a las - hh:mm (am/pm) Nombre del usuario del ltimo mensaje
ULTIMO_MENSAJE TITULO_TEMA Vnculo FECHA_ULTIMO_MENSAJE Etiqueta/Fecha
6.3
USUARIO
Vnculo
Temas ID 1 2 3 4 4.1 4.2 5 Nombre TITULO_FORO NUEVO_TEMA NAV_TEMAS CUADRO_BUSQUEDA BUSQUEDA_RAPIDA BUSCAR NAV_FOROS Tipo Ttulo Botn Miga de pan Texto Botn Men Descripcin Titulo del foro Crear nuevo tema Sitio > Foro Cuadro de texto para la bsqueda rpida Botn para buscar Otros foros para navegar
Interaccin Tipo de evento: MOUSE_CLICK Causa: Elemento: NUEVO_TEMA
Consecuencia: Vista: VISTA_NUEVO_TEMA
Tipo de evento: MOUSE_CLICK Causa: Elemento: BUSCAR 61
Patricio Fagalde Consecuencia: Vista: VISTA_BUSQUEDA (No relevada)
Lista de temas ID 1 2 3 4 5 6 7 8 8.1 Nombre MENSAJE_NUEVO TITULO_TEMA DESCRIPCION_TEMA NAV_PAG_MENSAJES RESPUESTAS AUTOR LECTURAS ULTIMO_MENSAJE FECHA_ULTIMO_MENSAJE Tipo Indicador ON/OFF Vnculo Etiqueta Navegacin de tema Etiqueta/Nmero Vnculo Etiqueta/Nmero Etiqueta/Fecha Descripcin Ttulo del tema Descripcin del tema [Ir a la pgina: 1 N ] Cantidad de respuestas del tema Nombre del autor Cantidad de lecturas del tema Formato - Hoy/Ayer/Lu Dom - a las - hh:mm (am/pm) Nombre del usuario del ltimo mensaje
8.2
USUARIO
Vnculo
62
Patricio Fagalde Diseo de la informacin 1: INICIO
2: FORO
63
Patricio Fagalde 3: NUEVO_TEMA
64
Conectores ID 1 2 3 4 5 6 Vista INICIO INICIO INICIO FORO FORO FORO Vinculo TITULO_FORO TITULO_TEMA USUARIO TITULO_TEMA AUTOR USUARIO Destino FORO TEMA PERFIL_USUARIO TEMA PERFIL_USUARIO PERFIL_USUARIO
65
Patricio Fagalde Diseo de la interaccin Elementos ID 1 2 3 4 5 6 7 8 Nombre NOMBRE APELLIDO EMAIL EMAIL_CONFIRMAR CONTRASEA SEXO FECHA REGISTRAR Tipo Texto Texto Texto Texto Texto oculto Men sexo Men fecha Botn
Etiqueta Nombre Apellidos Tu correo electrnico Vuelve a escribir tu correo Contrasea Sexo Fecha de nacimiento Regstrate
Interaccin Tipo de evento: MOUSE_CLICK Causa: Elemento: REGISTRAR
Consecuencia: Vista: REGISTRO_CAPTCHA Condicin: Todos los campos del rea REGISTRAR validan correctamente Vista: REGISTRO_ERROR Condicin: Alguna de las condiciones de validacin no se cumplieron
Elementos ID 1 2 3 4 Nombre CAPTCHA TEXTO_CAPTCHA REGISTRAR VOLVER Tipo Captcha Texto Botn Vnculo Etiqueta Texto que se muestra en la imagen Regstrate < Volver
Eventos Tipo de evento: MOUSE_CLICK Causa: Elemento: REGISTRAR 66
Patricio Fagalde Consecuencia: Vista: REGISTRO_EXITOSO
Condicin: Todos los campos del rea REGISTRAR_CAPTCHA validan correctamente Vista: REGISTRO_CAPTCHA_ERROR Condicin: Alguna de las condiciones de validacin no se cumplieron
Tipo de evento: MOUSE_CLICK Causa: Elemento: VOLVER
Consecuencia: Vista: REGISTRO_DATOS
Elementos definidos Men sexo Valores: Selecciona el sexo: Mujer Hombre
Men fecha El men fecha est compuesto por tres mens Men da Valores: Da: Valores desde el 1 al 31
Men mes Valores Mes: Valores desde enero hasta diciembre
Men ao Ao: 67
Patricio Fagalde Valores desde 2011 hasta 1905
Validacin: Cuando se selecciona un mes donde el da seleccionado anteriormente es invlido (por ejemplo, se selecciona febrero y previamente se haba seleccionado el da 31) el men de da vuelve al valor por defecto.
Captcha El captcha es una prueba para asegurarse que la respuesta no es generada por una computadora. Imagen Valor: Aleatoriamente crea dos palabras distorsionadas Ejemplo
68
Patricio Fagalde Diseo de la informacin 1: REGISTRO_DATOS
2: REGISTRO_CAPTCHA
69
Conectores Interaccin: CLICK_REGISTRAR Vista desde: REGISTRO_DATOS Vista hasta: REGISTRO_CAPTCHA
70
Patricio Fagalde
Reporte de anomalas
El lder completa una planilla con las anomalas detectadas. ID Descripcin 1 No debera ser obligatorio preguntar el sexo para registrarse 2 No hay criterio de bsqueda en la bsqueda rpida 3 Se deberan separar los campos de email en el registro para que sea ms intuitivo 4 La descripcin debera estar marcada como optativa Sntoma Entrada Parmetros incompletos o faltantes Tipo Problema de documentacin tem incompleto Entrada Problema de Descripciones documentacin incorrectas o tem confuso faltantes Entrada Mejora Entrada incorrecta aceptada Entrada Entrada correcta no aceptada Usabilidad Responsable Degradada Analista
Afectada
Analista
Afectada
Diseador
Requerimientos No Mejorar afectada usabilidad
Diseador
Conclusiones del caso de estudio Con este caso de estudio pudimos observar la manera de la cual el usuario y el equipo interactan en el proceso, generando los artefactos. Se ilustr nicamente una iteracin, pero este proceso es netamente iterativo; dado el impacto de las anomalas pueden pasarse a otro ciclo o entregar los requerimientos con observaciones.
71
Patricio Fagalde
Conclusin
Aunque el diseo y el desarrollo idealmente iteran, la realidad dicta que generalmente estas dos etapas se separan. Por lo tanto, muchas veces los diseos se cambian sin aporte del diseador, sin un conocimiento profundo del aporte que el diseo hace a los objetivos del usuario y sin el fundamento de las decisiones de diseo. Los diseos siempre cambian a lo largo del proceso de desarrollo por diversas razones que no es el caso analizar aqu. La documentacin de diseo ayuda a que el producto final se corresponda con los objetivos de usuario originales e informe sobre los cambios requeridos. Tambin es capaz de capturar todas las decisiones y fundamentos tomados para que el resto de los miembros del equipo los tenga presentes. Es responsabilidad de la organizacin que implemente estos artefactos decidir el nivel de detalle en el cual se apega a estas especificaciones de acuerdo a la realidad que dictan sus tipos de clientes y proyectos. Como comentario final, podemos concluir que la aplicacin de estos artefactos tiene los siguientes beneficios: El proceso, al estar basado en HCD, asegura que los requerimientos funcionales y de usabilidad detrs de la interfaz de usuario y el diseo de interaccin son plasmados en el producto final. El diseo es iterativo y tiene como prioridad las metas de los usuarios. La documentacin puede ser utilizada tanto como entradas para la elaboracin del software como para comunicar a los interesados sobre el refinamiento de los requerimientos.
72
Patricio Fagalde
Anexo B Diccionario de elementos

La descripcin de un elemento incluye, como mnimo: Identificador del elemento Descripcin
Interaccin por defecto (Ver
73
Patricio Fagalde Definicin de las interacciones) Imgenes de los estados Instancias comunes
Controles de entrada
Botn Descripcin: Un rectngulo con una leyenda y/o una imagen. Interaccin por defecto
Instancias comunes: Aceptar: Confirmar una accin y navegar a otra pantalla Cancelar: Abortar una accin sin guardar cambios y navegar a otra pantalla Aplicar: Confirmar acciones, pero no navegar a otra pantalla
Casilla de verificacin Descripcin fsica: Es un cuadrado vacio. Descripcin de la interaccin Estados: Seleccionado o no seleccionado. Mtodos de ingreso: Puntero y teclado
Una casilla de verificacin es un elemento de interfaz que permite al usuario seleccionar mltiples opciones de una lista.
74
Patricio Fagalde Botn de radio
Un botn de radio es un control que permite que solo una de las opciones posibles est seleccionada al mismo tiempo. Su nombre viene de las radios de auto viejas que, al presionar uno de los botones, el que estaba seleccionado anteriormente sala para afuera.
Deslizador Un deslizador es un elemento que permite al usuario deslizar, de arriba abajo o izquierda derecha para seleccionar un posible valor. Este control posibilita visualmente elegir entre un rango de valores posibles, y pueden estar marcados algunos valores significativos sobre el deslizador o estar acompaado de un texto (o una entrada de texto) para ir marcando el valor seleccionado o ingresarlo a mano.
Desplazador Un desplazador es un elemento que permite al usuario seleccionar un valor numrico presionando botones para incrementar o disminuirlo.
Menus Un men es un control que permite al usuario seleccionar un elemento Encarnaciones comunes: Select (Se muestra una sola opcin, al presionar en el control se despliegan las opciones posibles) Select mltiple (Se muestran muchas opciones, se pueden elegir varias) Combo box (Se puede tipear un valor o elegir uno de una lista)
75
Patricio Fagalde Entrada de texto
El campo de texto es la expresin ms libre que puede tener un usuario respecto del ingreso. Es un control en el que se puede ingresar un texto sin lmite de longitud. Encarnaciones comunes: Texto comn Texto oculto (por ejemplo, para contraseas) Texto en rea, para escribir detalles o descripciones
Seleccin de archivo Permite seleccionar un archivo en la mquina del cliente, independientemente del sistema operativo. Calendario Permite seleccionar una fecha. Hay que tener especial cuidado con la fecha predefinida, como por ejemplo, cuando se tiene que ingresar una fecha de nacimiento y por defecto el control carga la fecha de hoy.
Vnculo El vnculo lo que hace es, justamente, encadenar un documento con otro. Esto es parte del comportamiento inherente de la web como un protocolo de hipertexto. Generalmente es un texto de distinto color al resto, subrayado. El vnculo impacta en el diseo de la navegacin, dado que define un conector, as como los botones que accionan una navegacin.
76
Patricio Fagalde
Controles de salida
Listado Es comn que en las aplicaciones aparezca una manera tabular de mostrar una bsqueda. Las caractersticas comunes de estos listados son: Hacer clic en el encabezado para ordenar por ese criterio Arrastrar una columna para cambiar el orden Arrastrar el borde de una columna para cambiar su ancho Colores alternados para columnas
Ttulo Un ttulo es un encabezado al principio de una vista o seccin. Sirve para indicar al usuario el lugar en el que est ubicado o qu contenido est visualizando en ese momento.
Etiqueta Una etiqueta es lo que acompaa a un control (de la otra seccin) para clarificar el propsito de ste. Para clarificar, se especifica qu tipo de dato se muestra, como por ejemplo: Texto Nmero Fecha (dd/mm/aaaa)
77
Patricio Fagalde Barra de progreso
Para un proceso que toma mucho tiempo o varios pasos, la barra de progreso da un sentido de eficacia respecto de los pasos que se van haciendo.
Descripcin emergente Es un elemento que muestra una ayuda adicional al usuario al posar el puntero sobre un control.
78
Patricio Fagalde
Anexo C Definicin de las interacciones

Tipo de evento
Cdigo Teclado KEY_PRESSED Tecla o combinacin de teclas KEY_UP Tecla levantada Cuando la tecla dej de estar presionada KEY_DOWN Puntero MOUSE_OVER De adentro hacia afuera MOUSE_OUT De afuera hacia adentro MOUSE_CLICK MOUSE_DOUBLE_CLICK Clic Doble Clic Cuando el puntero sali del rea de interaccin del elemento Cuando el puntero entr en el rea de interaccin del elemento El usuario hizo clic en el elemento El usuario hizo doble clic en el elemento MOUSE_SECONDARY_CLICK Clic secundario El usuario hizo clic con el botn secundario Vista VIEW_LOAD VIEW_SUBMIT En la carga En el envo Al cargarse la vista Al enviar datos a travs de un Tecla presionada Cuando la tecla fue presionada Cuando la tecla o combinacin de teclas fue presionada y levantada Nombre Descripcin
79
Patricio Fagalde formulario Elemento ELEMENT_BLUR Perder foco
El elemento perdi foco, o sea, estaba seleccionado para ingresar datos pero ahora no lo est ms
ELEMENT_FOCUS
Ganar foco
El elemento gan foco, o sea, fue seleccionado para ingresar datos
ELEMENT_CHANGE
Cambio
El elemento cambi su valor
80
Patricio Fagalde
Anexo D Notacin de mapa de sitio

Notacin general
Si un elemento an no ha sido relevado o est fuera del alcance de la demostracin, aparecer con un fondo rayado en diagonal.
Vista
Una vista es la forma ms bsica de representacin en el diseo de navegacin. Est representada por un rectngulo, con un nombre representativo y una referencia de prototipo (de la seccin anterior).
Ilustracin 3 Notacin de una Vista
Seccin
Una seccin es una parte dentro de una vista que es modelada por separado, sea por su complejidad, para simplificar el proceso o porque el ciclo de aprobacin va por separado. El nombre de la seccin debe ser nico porque puede ser utilizado en distintas vistas, pero no se le agrega un ID para que no haya una sobrecarga de notacin. Se utiliza para clarificar el contenido de una vista sin tener que ir al detalle del prototipo.
Ilustracin 4 Notacin de una Seccin
Plantilla
Una plantilla es una vista cuyo contenido vara, pero su estructura no. Para citar un ejemplo, podra ser una vista de edicin de varias entidades (la informacin, el contenido de la entidad, cambia, pero la estructura de la pgina no). Se representa como una pila de vistas.
81
Patricio Fagalde
Ilustracin 5 Notacin de una Plantilla
Conector
Un conector indica la navegacin entre dos componentes en el mapa de sitio. La punta de la flecha indica si la navegacin es en un solo sentido; si no tiene flechas, la navegacin es bidireccional.
Ilustracin 6 Notacin de un Conector
82
Patricio Fagalde
Anexo E Clasificacin de las anomalas

Motivacin
El motivo de la implementacin de una clasificacin de anomalas es mejorar la capacidad de distinguir entre las falencias que presenta nuestra instancia de las actividades. Se tuvieron en cuenta los siguientes pasos para esta adaptacin del estndar. No haba implementacin previa, por lo tanto no hubo que adaptar una clasificacin anterior. Se toma como no necesaria la implementacin estricta del estndar, por lo tanto se revisan todas las clasificaciones sugeridas independientemente de si son obligatorias u opcionales. Se listan todas las categoras y se seleccionan con los siguientes criterios o o Las anomalas potenciales, pueden ser clasificadas fcilmente por este criterio? La informacin que proporciona sta clasificacin: Puede resultar til en un futuro? Aporta a mejorar la experiencia del usuario? Aporta a la gestin del proyecto?
Para cada categora seleccionada, se decide si es esencial para los objetivos del proceso. Si lo es, se la marca como obligatoria. Se documenta cada clasificacin.
Adherencia
Categora IEEE Std 1044-1993 Causa actual Accin correctiva Valor de cliente Disposicin Misin/seguridad Prioridad Usabilidad Actividad Costo Nombre original Actual Cause Corrective Action Customer value Disposition Mission/safety Priorty Product status Project activity Project cost Obligatorio en el estndar
Implementada Obligatorio en el proceso
83
Patricio Fagalde Fase Calidad/ Confiabilidad Riesgo Calendario Repetitividad Resolucin Severidad Sociedad Fuente Causa probable Sntoma Tipo Project phase Project quality/ reliability Project risk Project Schedule Repeatability Resolution Severity Societal Source Suspected cause Symptom Type
Clasificaciones
Disposicin La clasificacin de disposicin describe la manera de la cual fue resuelta la anomala. Clasificacin Cerrada Resolucin implementada No es un problema No est en el alcance del proyecto Duplicada Diferida Combinado con otro problema Actividad La clasificacin de actividad describe en qu fase del proceso fue generada. Clasificacin Descripcin Objetivos La anomala se debe a un defecto en la identificacin de las meta s de usabilidad Contexto La anomala se gener en la etapa de identificacin de los usuarios y las tareas Diseo La anomala se gener en la etapa de soluciones de diseo Descripcin La anomala ha sido abordada y est considerada como completa. La resolucin de la anomala ha sido implementada. La anomala no era un problema. El prototipo se comport de la manera esperada. La anomala no poda ser resuelta, o estaba afuera del alcance como fue definido en las especificaciones. La anomala es idntica a otra anomala reportada. Referenciar a sta ltima. La anomala ser diferida a otra iteracin del proceso La anomala es la misma, o va a ser resuelta con la misma implementacin de la solucin de la anomala referenciada
Costo La clasificacin de costo describe una estimacin aproximada del costo incurrido en abordar el defecto. 84
Patricio Fagalde Clasificacin Alto Medio Bajo Ninguno Calendario
Facultad de Ingeniera Descripcin Resolver esta anomala ser extremadamente costoso. Este cambio requiere un gran esfuerzo. Resolver esta anomala ser costoso. Este cambio requiere un esfuerzo moderado. Resolver esta anomala tendr un costo nominal. Este cambio requiere bajo esfuerzo. Resolver esta anomala o implementar este cambio est incluido en el presupuesto del proyecto, por lo tanto no hay un costo adicional asociado.
La clasificacin de calendario describe una estimacin aproximada del tiempo requerido para abordar el defecto o mejora. Clasificacin Descripcin Alto Resolver esta anomala implicara destruir el calendario. Este cambio requiere un gran esfuerzo Medio Resolver esta anomala cambiaria el calendario significativamente. Este cambio requiere un esfuerzo moderado Bajo Resolver esta anomala tendr poco impacto en el calendario. Este cambio requiere bajo esfuerzo Ninguno Resolver esta anomala o implementar este cambio est planificado en el calendario, por lo tanto no hay impacto en el calendario asociado Resolucin La clasificacin de resolucin describe la decisin que se tom para superar la anomala reportada. Clasificacin Inmediata Correccin del prototipo Actualizar documentacin Capacitacin del usuario Eventual Correccin del prototipo Actualizar documentacin Capacitacin del usuario Diferida Resolver en otra entrega Descripcin La modificacin ser implementada en la iteracin actual. La modificacin ser a travs de un cambio en el diseo del prototipo. La modificacin ser a travs de un cambio de la documentacin. El problema se resolver entrenando al usuario para la operacin del sistema. La modificacin ser implementada en una iteracin futura. Especificar la iteracin o fecha lmite de resolucin. La modificacin ser a travs de un cambio en el diseo del prototipo. La modificacin ser a travs de un cambio de la documentacin. El problema se resolver entrenando al usuario para la operacin del sistema. La modificacin ser abordada en una iteracin futura. La modificacin requerida ser implementada en una 85
Patricio Fagalde
Facultad de Ingeniera versin futura. Ser muy difcil implementar la resolucin de sta anomala. Por lo tanto se requiere una exencin para que podamos entregar la prxima versin con ella. La modificacin no va a ser implementada ni en sta ni en otra iteracin. La anomala no era un problema. El prototipo se comport de la manera esperada. Ser muy difcil implementar la resolucin de sta anomala, por lo tanto se requiere una exencin para que podamos hacer la entrega sin este cambio. Resolver este problema o mejora no justifica el tiempo o dinero destinado para implementarlo. O, hacer esta modificacin traera ms problemas de los que resuelve. No se pudo encontrar una solucin apropiada para el problema reportado. El problema ha sido superado por la resolucin de otra anomala u otra causa. Justificar la causa.
Exencin requerida No se resuelve No es un problema Exencin requerida Resolucin no justificada
Resolucin no identificada Obsoleta Sntoma
La clasificacin de sntomas describe cul es la percepcin del usuario del error Clasificacin Problema de entrada Entrada correcta no aceptada Entrada incorrecta aceptada Descripciones incorrectas o faltantes Parmetros incompletos o faltantes Problema de salida Formato incorrecto Resultados/datos incorrectos Ortografa/Gramtica Cosmtico Falla total percibida Otro Descripcin El prototipo no maneja el ingreso de datos de la manera que el usuario espera El prototipo no acepta el ingreso de datos correctamente El prototipo acepta el ingreso de datos incorrectos que potencialmente van a producir resultados incorrectos. No se muestran mensajes de error. El prototipo no proporciona suficiente descripcin para orientar al usuario para el ingreso de datos El prototipo no muestra todas las opciones o parmetros de entrada necesarios El prototipo no presenta la salida de datos de la manera que el usuario espera El prototipo no presenta los datos en el formato correcto El prototipo no presenta los datos esperados o no estn enmarcados en el contexto El prototipo presenta errores de ortografa o gramtica en la presentacin El prototipo presenta imgenes inadecuadas, o no es percibido positivamente por el usuario debido a problemas estticos El prototipo no cumple con uno o ms requerimientos crticos Otro sntoma que no se encuadra en cualquier otra categora
86
Patricio Fagalde Tipo
La clasificacin de tipo describe con ms detalle de qu tipo de problema se trata. Clasificacin Problema de documentacin Declaracin ambigua tem incompleto tem incorrecto tem faltante tems conflictivos tem confuso tem redundante tem ilgico tem no verificable tem inalcanzable Problema de calidad del documento Inconformidad de estndares No trazable Desactualizado Incompleto Inconsistencia Mejora Requerimientos Nueva prestacin Remover prestacin innecesaria Mejorar usabilidad Otra Falla causada por correccin previa Problema conformidad de estndar Descripcin Problema especfico en la documentacin La declaracin puede ser interpretada de maneras distintas La declaracin o descripcin no parece considerar todos los aspectos de la situacin que intenta describir La declaracin o descripcin es incorrecta La declaracin o descripcin que debe ser incluida en el documento est faltando Dos o ms declaraciones o descripciones estn en conflicto o se contradicen La declaracin o descripcin confunde al lector La declaracin repite otra declaracin y resta claridad La declaracin no tiene sentido en referencia a otras declaraciones dentro del mismo documento u otros documentos a los que se refieren La declaracin no puede ser verificada por ningn medio factible La declaracin no puede ser garantizada en el ciclo de vida del producto Problema con el documento en s Los estndares del documento en cuestin establecidos por las polticas de la organizacin no son alcanzados Los tems no pueden ser referenciados a documentos previos o posteriores El documento no est actualizado a la versin de la iteracin actual El documento tiene una seccin importante faltante El documento contiene informacin que es inconsistente con la informacin en otro documento Una mejora es una sugerencia que cambia los requerimientos de un producto existente para mejorar la usabilidad o funcionalidad del producto Agregar una nueva prestacin, remover una prestacin innecesaria o modificar una prestacin existente para satisfacer ms necesidades del usuario
Cambiar la especificacin de un artefacto para mejorar la experiencia del usuario Una mejora distinta de las mencionadas anteriormente La falla fue causada por la correccin de otro problema o mejora El producto resultante no cumplir con algn estndar, donde sta conformidad est explcitamente especificada en los requerimientos 87
Patricio Fagalde Otra Usabilidad
Facultad de Ingeniera No entra en ninguna de las clasificaciones anteriores
La clasificacin de usabilidad describe de qu manera la usabilidad del producto podra verse afectada. Clasificacin Descripcin Inutilizable El producto no podr utilizarse con sta anomala presente Degradada Algunos aspectos del producto funcionaran, pero otros atributos no lo hacen en la condicin actual Afectada El producto puede ser utilizado, pero una solucin alternativa (de la del mtodo preferido por el usuario) debe ser utilizada para lograr algunos objetivos No afectada La usabilidad del producto no es afectada
88
Patricio Fagalde
Glosario
Anomala: Cualquier condicin que se desva de lo esperado basado en la especificacin de diseo o de las percepciones o experiencias de alguien. Las anomalas pueden ser encontradas en la revisin, prueba, anlisis, compilacin o el uso de los productos de software o la documentacin aplicada [24]. Proceso: un conjunto de actividades que se interrelacionan o interactan para transformar entradas en salidas [25]. Actividad: una coleccin de tareas relacionadas [25]. Usabilidad: Atributo cualitativo que evala cun fcil de usar es una interfaz de usuario. Efectividad: Que el usuario pueda completar su tarea correctamente. Eficiencia: La rapidez con que pueden completar las tareas. Satisfaccin: Que el usuario pueda percibir que ha realizado su tarea de manera correcta.
89
Patricio Fagalde
Bibliografa
[1] IEEE Computer Society, SWEBOK - Guide to the Software Engineering Body of Knowledge., 2004. [2] Ian Sommerville, Software engineering, Octava edicin ed., Harlow, Ed.: Addison Wesley, 2007. [3] International Organization for Standarization, ISO 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11 : Guidance on usability, Primera edicin ed. Geneva, Switzerland, 1998. [4] Barry Boehm, "A Spiral Model of Software Development and Enhancement," ACM SIGSOFT Software Engineering Notes, vol. 11, no. 4, pp. 14-24, Agosto 1986. [5] Standish Group, The CHAOS Report., 1994. [6] Robert Wysocki, Project Management Process Improvement., 2004. [7] Lautaro Mazzitelli, Perfil de usabilidad para UML: definiendo la interaccin con el usuario. Buenos Aires, Argentina, 2009. [8] Maia Naftali, Anlisis e Integracin de mtricas para la Accesibilidad Web. Buenos Aires, 2010. [9] IEEE, "IEEE Std 830-1998 Recommended Practice for Software Requirements Specifications," 1998. [10] Didar Zowghi and Vincenzo Gervasi, "The Three Cs of Requirements: Consistency, Completeness, and Correctness," in Proceedings of REFSQ'02, 2002. [11] JCSP Leite and APM Franco, "A Strategy for Conceptual Model Adquisition," in Proceedings of the First IEEE International Symposium on Requirements Engineering, San Diego, 1994, pp. 243-246. [12] JCSP Leite et al., "Enhacing a Requirements Baseline with Scenarios,".
90
Patricio Fagalde
[13] John Mylopoulos, Lawrence Chung, and Brian Nixon, "Representing and Using NonFunctional Requirements: A Process-Oriented Approach," Universidad de Toronto, Toronto, 1992. [14] Jakob Nielsen, Usability Engineering.: Academic Press, 1993. [15] Alan M. Davis, "Operational Prototyping: A new Development Approach," IEEE Software, p. 71, Septiembre 1992. [16] Dan M. Brown, Communicating Design: Developing Web Site Documentation for Design and Planning, Segunda edicin ed.: New Riders, 2011, p. 169. [17] Jesse James Garrett, The elements of user experience, Segunda Edicin ed.: New Riders, 2011. [18] T. R. G. Green, "Instructions and Descriptions: some cognitive aspects of programming and similar activities," 2000. [19] International Organization for Standardization, "ISO 13407 - Human-centered design processes for interactive systems," Geneva, 1999. [20] Whitney Quesenbery, "Dimensions of Usability: Defining the Conversation, Driving the Process," in UPA 2003 Conference, 2003. [21] Soren Lauesen and Houman Younessi, "Six styles for usability requirements," in Proceedings of REFSQ98, 1988. [22] Martin C Maguire, RESPECT User-Centred Requirements Handbook., 1998. [23] Russ Unger and Carolyn Chandler, A Project Guide to UX Design: For user experience designers in the field or in the making., 2009. [24] IEEE, IEEE 1044.1-1995 Guide to Classification for Software Anomalies., 1995. [25] International Organization for Standardization, ISO/IEC 90003 Software Engineering Guidelines for the application of ISO 9001:2000 to computer software. Geneva, Switzerland, 2004.
91

Artefactos de especificación de requerimientos de usabilidad

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Artefactos de especificación de requerimientos de usabilidad

Uploaded by

Copyright:

Available Formats

Patricio Fagalde - 83810

Artefactos de especificacin de requerimientos de usabilidad

Patricio Fagalde - pfagalde@gmail.com Tutor: Ing. Carlos Fontela 27/05/2011

Patricio Fagalde Usabilidad

Identificacin del problema

Trabajos publicados relacionados con esta tesis

Captulo 2 Estado de la cuestin

Captulo 3 Criterios de diseo

Objetivo de los artefactos

todas S, pero la traduccin que se elige aqu no permite tal consonancia

El proceso de desarrollo de software modelo

Patricio Fagalde Desarrollador

Captulo 4 Artefactos de especificacin de requerimientos de usabilidad

Ilustracin 1 Actividades propuestas por la norma ISO 13407 [19]

Ilustracin 2 Framework de usabilidad de acuerdo a ISO 9241-11 [3]

Descripcin detallada de cada etapa

Declaracin del requerimiento Usuario o rol que lo validar

Patricio Fagalde Identificar usuarios y tareas

Patricio Fagalde Desarrollar el prototipo

Patricio Fagalde Diseo de la interaccin Descripcin

Patricio Fagalde Diseo de la navegacin Mapa de sitio

Conectores Interaccin: CLICK_REGISTRAR Vista desde: REGISTRO_DATOS Vista hasta: REGISTRO_CAPTCHA

Requerimientos No Mejorar afectada usabilidad

Patricio Fagalde Definicin de las interacciones) Causa Consecuencia

Patricio Fagalde Notacin de mapa de sitio) Elemento (Ver Diccionario de )

El concepto de interaccin se puede ver plasmado en el siguiente diagrama de clases:

Patricio Fagalde Diseo de la informacin Descripcin

La notacin a utilizar en el mapa de sitio est especificada en

Anexo A Definicin de las interacciones

Patricio Fagalde formulario Elemento ELEMENT_BLUR Perder foco

El elemento gan foco, o sea, fue seleccionado para ingresar datos

El elemento cambi su valor

Patricio Fagalde Notacin de mapa de sitio. Conector

Patricio Fagalde Probar el prototipo con los usuarios

Captulo 5 Caso de estudio

Documento de especificacin de requerimientos de usabilidad

Patricio Fagalde Matriz

Meta 1 Meta 2 Meta 3 Meta 4 Meta 5 Meta 6 Meta 7 Total

X X 33% 17% 17% 13% 9% 83% 17% 0%

Tipo I Tipo II Todos Todos Tipo II Todos Todos

Documento de especificacin de contexto

ULTIMO_MENSAJE TITULO_TEMA Vnculo FECHA_ULTIMO_MENSAJE Etiqueta/Fecha

Interaccin Tipo de evento: MOUSE_CLICK Causa: Elemento: NUEVO_TEMA

Consecuencia: Vista: VISTA_NUEVO_TEMA

Tipo de evento: MOUSE_CLICK Causa: Elemento: BUSCAR 61

Patricio Fagalde Consecuencia: Vista: VISTA_BUSQUEDA (No relevada)

Patricio Fagalde Diseo de la informacin 1: INICIO

Patricio Fagalde 3: NUEVO_TEMA

Patricio Fagalde Diseo de la navegacin Mapa de sitio

Interaccin Tipo de evento: MOUSE_CLICK Causa: Elemento: REGISTRAR

Eventos Tipo de evento: MOUSE_CLICK Causa: Elemento: REGISTRAR 66

Patricio Fagalde Consecuencia: Vista: REGISTRO_EXITOSO

Tipo de evento: MOUSE_CLICK Causa: Elemento: VOLVER

Consecuencia: Vista: REGISTRO_DATOS

Elementos definidos Men sexo Valores: Selecciona el sexo: Mujer Hombre

Men mes Valores Mes: Valores desde enero hasta diciembre

Patricio Fagalde Valores desde 2011 hasta 1905

Patricio Fagalde Diseo de la informacin 1: REGISTRO_DATOS

Patricio Fagalde Diseo de la navegacin Mapa de sitio

Conectores Interaccin: CLICK_REGISTRAR Vista desde: REGISTRO_DATOS Vista hasta: REGISTRO_CAPTCHA

Requerimientos No Mejorar afectada usabilidad

Anexo B Diccionario de elementos

Interaccin por defecto (Ver