237-262-1-pb

7/24/2019 237-262-1-PB

1/19

Revista EIA, ISSN 1794-1237 Nmero 13, p. 123-141. Julio 2010

Escuela de Ingeniera de Antioquia, Medelln (Colombia)

Artculo recibido 19-II-2010. Aprobado 8-VI-2010Discusin abierta hasta diciembre de 2010

* Ingeniera de Sistemas, Universidad del Valle. Magster en Ingeniera de Sistemas y Computacin, Universidad delos Andes. Estudiante de Doctorado, Universitat de Girona, Espaa. Docente, Escuela de Ingeniera de Sistemas yComputacin, Universidad del Valle. Cali, Colombia. [email protected]; [email protected]

** Ingeniero de Sistemas y Magster (c) en Ingeniera de Sistemas, Universidad del Valle. Docente, Escuela de Ingenierade Sistemas y Computacin, Universidad del Valle. Cali, Colombia. [email protected]

*** Diseador Industrial, Universidad Industrial de Santander. Especialista en Diseo de Ambientes de Aprendizaje.Magster (c) en Ingeniera de Sistemas, Universidad del Valle. Docente, Departamento de Diseo, Facultad de ArtesIntegradas, Universidad del Valle. Cali, Colombia. [email protected]

PROPUESTA PARA INCORPORAR EVALUACINY PRUEBAS DE USABILIDAD DENTRO DE UN PROCESO

DE DESARROLLO DE SOFTWARE

BEATRIZE. FLORIN*OSWALDOSOLARTE**JAVIERM. REYES***

RESUMEN

La usabilidad es crtica para el xito de los sistemas de software interactivos. Las pruebas y evaluacionesde usabilidad durante el desarrollo del producto han ganado amplia aceptacin como estrategia para mejorarla calidad del producto. La introduccin temprana de las perspectivas de usabilidad en un producto es muyimportante para brindar una clara visibilidad de aspectos de calidad, tanto para los desarrolladores como losusuarios de pruebas. Sin embargo, la evaluacin y pruebas de usabilidad no es comn que se tomen en cuentacomo elementos indispensables del proceso de desarrollo de software. Este artculo expone una propuesta paraintroducir la evaluacin y pruebas de usabilidad dentro de un desarrollo de software, basndose en la reutilizacinde artefactos de software. Adicionalmente, propone la introduccin de un auditor dentro de la clasificacin deactores para las pruebas de usabilidad y una mejora de las listas de chequeo utilizadas para evaluacin heurstica,

agregndoles aspectos cuantitativos y cualitativos.

PALABRAS CLAVE: desarrollo de software; interaccin humano-computador; pruebas de usabilidad;evaluacin de usabilidad; evaluacin heurstica; listas de chequeo heursticas.

7/24/2019 237-262-1-PB

2/19

124 RevistaEIA

PROPUESTAPARAINCORPORAREVALUACINYPRUEBASDEUSABILIDAD...

PROPOSAL FOR INTRODUCING USABILITY EVALUATION AND TESTINGWITHIN A SOFTWARE DEVELOPMENT PROCESS

ABSTRACT

Usability is critical to consider an interactive software system successful. Usability testing and evaluationduring product development have gained wide acceptance as a strategy to improve product quality. Early intro-duction of usability perspectives in a product is very important in order to provide a clear visibility of the qualityaspects not only for the developers, but also for the testing users as well. However, usability evaluation and testingare not commonly taken into consideration as an essential element of the software development process. Then,this paper exposes a proposal to introduce usability evaluation and testing within a software development throughreuse of software artifacts. Additionally, it suggests the introduction of an auditor within the classification of actorsfor usability tests. It also proposes an improvement of checklists used for heuristics evaluation, adding quantitativeand qualitative aspects to them.

KEY WORDS: software development; human-computer interaction; usability testing; usability evaluation;

heuristic evaluation; heuristics checklists.

PROPOSTA PARA INCORPORAR A AVALIAO E PROVAS DE USABILIDADEDENTRO DE UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

RESUMO

A usabilidade crtica para o sucesso dos sistemas de software interativos. As provas e avaliaes de usa-bilidade durante o desenvolvimento do produto tm ganhado ampla aceitao como estratgia para melhorar aqualidade do produto. A introduo adiantada das perspectivas de usabilidade em um produto muito importantepara brindar uma clara visibilidade de aspectos de qualidade tanto para os desenvolvedores como os usurios de

provas. No entanto, a avaliao e provas de usabilidade no comum que se tomem em conta como elementosindispensveis do processo de desenvolvimento de software. Este artigo expe uma proposta para introduziravaliao e provas de usabilidade dentro de um desenvolvimento de software, baseando-se na reutilizao deartefatos de software. Adicionalmente, prope a introduo de um auditor dentro da classificao de atores paraas provas de usabilidade e uma melhoria das listas de reviso utilizadas para avaliao heurstica, acrescentando-lhes aspectos quantitativos e qualitativos.

PALAVRAS-CDIGO: desenvolvimento de software; interao humano-computador; provas de usabilidade;avaliao de usabilidade; avaliao heurstica; listas de reviso heursticas.

1. INTRODUCCIN

La usabilidad ha sido considerada un atributode calidad del software determinante para el xitode un proyecto, generndole un inters creciente enel mundo del desarrollo de software como factor decalidad (Ferr, 2003; Cheikhi, Abran y Suryn, 2006).Las valoraciones de usabilidad en software se hanrealizado desde 1971. Para el ao 2003 elNational

Institute of Standards and Technology(NIST) identifi-caba ms de 30 tcnicas para conducir valoracionesde usabilidad (Ramli y Jaafar, 2008). Actualmente,la usabilidad es considerada como un atributo de lacalidad del uso del software (ISO/IEC, 2009). Estanueva definicin permite hacer medidas ms preci-sas sobre la usabilidad de un producto de software(Bevan, 2009).

7/24/2019 237-262-1-PB

3/19

125Escuela de Ingeniera de Antioquia

Los mtodos de valoracin de usabilidadpueden dividirse en tres grupos: mtodos de anlisis,mtodos de inspeccin y mtodos de indagacin. Enlos primeros los usuarios representativos trabajan

en tareas tpicas utilizando el sistema o prototipo,los evaluadores se concentran en observar como lainterfaz posibilita en los usuarios realizar las tareas.En los segundos, se concentran en evaluar la interfazpor parte de especialistas en usabilidad o desarrolla-dores de software. En los terceros, los evaluadoresse concentran en obtener informacin respecto alos gustos, disgustos, necesidades y comprensin delsistema de parte de los usuarios.

Desde el punto de vista de los participantes, se

podran resumir estos tres mtodos en dos grandesgrupos: mtodos no empricosy mtodos empricos.Aqullos implican la participacin de expertos espe-cialistas en usabilidad, y stos se conciben como ins-trumentos de anlisis que requieren la participacinde usuarios. En esta investigacin se ha adoptadoesta segunda clasificacin, ya que abarca la anteriorde manera ms coherente para los intereses que seabordaron en las pruebas.

En la valoracin de usabilidad de software,

tanto las evaluaciones heursticas (Gonzlez, Lorsy Pascual, 2001; Nielsen, 1993) como las pruebas deusuario (Nielsen, 1993) generan un puente entre lasideas que tienen los desarrolladores sobre la interfazy las ideas de los usuarios. La evaluacin heursticaes un mtodo no emprico (evaluacin de expertos)(Rubin y Chisnell, 2008), mientras que las pruebas deusabilidad se basan en mtodos empricos (pruebascon usuarios). El objetivo de ambas es realizar tareasque arrojen realimentacin a los desarrolladorespara depurar eficazmente la interfaz de usuario

(Rosenbaum, 1989). Una de las grandes ventajas dela evaluacin heurstica es que no requiere una largaplanificacin y que puede usarse desde las etapasiniciales del proceso de desarrollo del sistema con losmismos desarrolladores de la aplicacin (Gonzlez,Lors y Pascual, 2001).

En particular, los acercamientos iniciales deNielsen (1999) y de Nielsen y Loranger (2006) alrespecto de las evaluaciones heursticas en la webarrojan una serie de principios heursticos como

requisitos mnimos para el diseo de interfaces webms usables y accesibles. Estos principios se tomancomo punto de partida para las evaluaciones de-sarrolladas en esta investigacin, junto con los deTidwell (2006) y LabIUtil (2003), Gonzlez, Lorsy Pascual (2001) y Shneiderman y Plaisant (2006).

A pesar de las ventajas, la evaluacin y prue-bas de usabilidad, por lo general, no son tomadas encuenta como elementos indispensables del procesode desarrollo de software. Algunas propuestas en

torno a este planteamiento se encuentran en Hakiel(1997), Cysneiros y Kushniruk (2003), Tao (2005),Singh (2008) y una paralela a nuestro trabajo enAveledo y De la Rosa (2010). Hakiel (1997) hablade dos problemas relacionados con la usabilidaden el desarrollo de software; el primero es que losrequisitos slo tienen en cuenta la ingeniera delproducto, y el segundo se refiere a que no se tienenen cuenta los factores humanos en el proceso dedesarrollo; el autor plantea una serie de actividadesorientadas a la usabilidad a travs de las etapas del

desarrollo de software; sin embargo, slo hace re-ferencia a las actividades asociadas en cada etapa,pero no propone artefactos o mecanismos concre-tos que ayuden a evaluar la usabilidad. Cysneiros yKushniruk (2003) se enfocan slo en solucionar lasposibles interpretaciones de usabilidad por mediode la construccin de un catlogo de conceptosrelacionados. Este catlogo se usa para construirlos requisitos de usabilidad del proyecto. Tao (2005)propone un modelo basado en estados de mquinay heursticas de usabilidad. Los estados de mquinapermiten representar la interaccin del usuario conel sistema, y las heursticas de usabilidad se aplicanpara mejorar el diseo de las interfaces de usuario.Este modelo se enfoca en mejorar la formacin enusabilidad para aplicarla al proceso de desarrollode software. Singh (2008) extiende la metodologagil Scrum incluyendo la usabilidad en el proceso; a

7/24/2019 237-262-1-PB

4/19

126 RevistaEIA


esta propuesta la llama U-SCRUM. El autor planteala necesidad de tener dos personas encargadas delproducto: el responsable de la funcionalidad y elresponsable de la usabilidad. No obstante, se debe

tener cuidado al aplicar esta metodologa, ya quelos dos responsables mencionados podran entraren desacuerdo, si no se trabaja el desarrollo delproducto como un objetivo comn. Los tipos deartefactos que propone Singh (2008) son: los rolesde usuario, la visin de experiencia de usuario y elplan del producto; en esta propuesta no se mencionacmo se evaluarn las caractersticas de usabilidadni un mecanismo para verificarlas.

Haciendo una mejora de los trabajos anterio-res, el objetivo principal de este estudio es proponeractividades y artefactos que enriquezcan el procesode desarrollo de software a partir de la introduccintemprana de requisitos de usabilidad en un producto;las tareas la permiten y los artefactos entregablesayudan a verificar que esas tareas se cumplan conti-nuamente en el proceso. En ese sentido este estudiocontina las propuestas de Granollers et al.(2005), deJuristo, Moreno y Snchez-Segura (2007) y de Avele-do, De la Rosa y Moreno (2008). En la propuesta serelacionan evaluaciones heursticas con pruebas de

usuarios, conectando los artefactos propuestos, tantode las evaluaciones como de las pruebas. La ideaprincipal es combinar las plantillas de evaluacinheursticas realizadas por expertos, para que tambinsirvan de gua a los usuarios durante las pruebasde usabilidad. Con esta propuesta se brinda unaclara visibilidad de los aspectos de usabilidad paralos desarrolladores y para los usuarios de pruebasdesde etapas tempranas del desarrollo. La propuestaest pensada para evitar impactar negativamente laduracin y costos del proyecto.

Dentro de esta investigacin tambin sesintetiza la clasificacin de actores, propuesta pordiferentes autores, para las pruebas de usabilidady se propone la figura del auditor dentro de estaclasificacin.

Florin et al.(2007) presentan actividades yartefactos que se usaron durante el desarrollo de laplataforma computacional PREDICA (PlataformaExperimental para Sistemas de Recomendacin,

Descubrimiento de Conocimiento, InterfacesAdaptativas y Consultas Avanzadas). El propsitodel proyecto PREDICA fue desarrollar unaplataforma experimental para facilitar la bsquedade documentos en el rea de la computacin cuyainterfaz se adapta a un modelo de usuario definidoy que ofrece recomendaciones con base en unperfil de consulta. Las interfaces de PREDICA sonevaluadas y probadas dentro de este estudio,en el cual las pruebas con usuarios descritas secomplementan con otras basadas en la tcnica de

anlisis de tarea y actividad (Kafure, 2000 y 2004;Medeiros, Kafure y Lula, 2000), documentadas enKafure et al.(2007).

El artculo est distribuido de la siguiente ma-nera. En la seccin 2 se presentan la clasificacin deactores para las pruebas y evaluaciones heursticasde usabilidad y la propuesta del actor auditor. En laseccin 3 se describen las actividades y artefactospropuestos. En la seccin 4 se describe la aplicacindel modelo propuesto al desarrollo de la biblioteca

digital PREDICA. En la seccin 5 se exponen los re-sultados de investigacin. Finalmente, se presentanlas conclusiones y referencias bibliogrficas.

2. CLASIFICACIN DE ACTORESDE PRUEBAS

De acuerdo con los planteamientos de May-hew (1999), Granollers, Lors y Caas (2005) yAlarcn et al. (2007), el usuario forma parte delproceso de desarrollo en diversas etapas. Uno de losconceptos fundamentales en este sentido es la itera-cin en el proceso de evaluacin, donde se puedenrealimentar los prototipos funcionales con base encriterios estructurados de usabilidad (Shneidermany Plaisant, 2006).

7/24/2019 237-262-1-PB

5/19


De las estrategias de clasificacin de usuariosplanteadas por Mayhew (1999) y Granollers, Lorsy Caas (2005) se utilizaron dos: la estrategia deconocimiento y experiencia, que se basa en la fre-

cuencia de uso de las herramientas computacionales,y la estrategia de estructuracin de las tareas deinteraccin, basada en los modelos mentales de losusuarios con respecto al uso de las tecnologas ensu trabajo. La clasificacin responde a la necesidadde categorizar a los usuarios dentro de unos nivelesde desempeo, porque esto facilita los procesos deevaluacin de las interfaces de usuario (Shneidermany Plaisant, 2006).

Utilizando las estrategias anteriores se pre-sentan cinco grupos de usuarios de prueba. Dosde los grupos involucran expertos en usabilidad, elauditorpropuesto en este artculo y el desarrolladorpropuesto por Aveledo y Moreno (2008) y los otrostres corresponden a diferentes tipos de usuarios dela aplicacin de software desarrollada propuestospor Shneiderman y Plaisant (2006). Los grupos deusuarios de prueba de esta clasificacin podranadecuarse a cualquier tipo de aplicacin de softwareque se quiera adelantar. A continuacin se presentanlos cinco grupos de clasificacin de usuarios.

Usuario novato o inexperto.Usuario que tienepoco conocimiento de las herramientas computacio-nales y cuya interaccin con aplicaciones similaresa la que se quiere construir no es frecuente. Dedicaentre un 0 % y 20 % de sus actividades a tareas si-milares a las que se realizarn con el producto desoftware por construir.

Usuario intermedio.Es aquel usuario que utilizacon frecuencia el computador. Dedica entre un 20 %y 80 % de sus actividades a tareas similares a las

que se ejecutarn con el producto de software porconstruir.

Usuario avanzado.Este usuario ocupa muchotiempo interactuando con herramientas computacio-nales, que suele usarlas por razones de trabajo. El 80 %o ms de sus actividades involucran tareas similares alas que se llevarn a cabo con el producto de software.

Desarrollador. Se propone al desarrolladorcomo un integrante ms del proceso de evaluacionesde usabilidad. Para evitar las observaciones tcnicasque se alejan un poco de los criterios de interaccin

humano-computador (IHC) se han utilizado listas dechequeo que dan las pautas para que los desarro-lladores tengan la posibilidad de observar ms decerca la interaccin.

Auditor.Es quien realiza la verificacin delsistema desde el punto de vista funcional, pero te-niendo en cuenta criterios de usabilidad. Por tanto,es el experto en usabilidad planteado por Gonzlez,Lors y Pascual (2001), que adems debe tenerconocimientos en ingeniera de software y en lastecnologas utilizadas en el desarrollo del producto.El auditor no participa en las etapas de anlisis eimplementacin del software. Provee una visinms holstica del proceso de interaccin, pues seencarga de evaluar, con base en unas heursticasclaras planteadas con anterioridad al proceso mismode la evaluacin. Esto permite que la evaluacin sedesarrolle de una manera menos subjetiva y evitala posibilidad de tener apreciaciones que estndescontextualizadas respecto a la interaccin de losusuarios potenciales con la aplicacin.

3. PROPUESTA DE TAREAS YARTEFACTOS DE USABILIDADDENTRO DEL DESARROLLODE SOFTWARE

Esta propuesta incluye tareas de pruebas deusabilidad desde etapas tempranas del desarrollo desoftware y se aleja de la visin de que slo corres-ponden a las etapas finales o de transicin. De estamanera busca cambiar la concepcin de esperar aque el producto de software est construido paraindagar en l los aspectos de usabilidad y, en cambio,propone anticiparse, para tener en cuenta aspectosde usabilidad desde las etapas de levantamiento derequisitos y diseo del software para luego realizar lasejecuciones de pruebas y evaluaciones de usabilidady finalizar con la verificacin de la interfaz.

7/24/2019 237-262-1-PB

6/19

128 RevistaEIA


La propuesta est pensada para grupos dedesarrollo medianos, donde los desarrolladoresestn familiarizados con la realizacin de tareas depruebas durante la implementacin. Se debe capa-

citar previamente a los desarrolladores en el rea deusabilidad del tipo de productos que crean, con elfin de que puedan cumplir con el papel de expertosen usabilidad. Como los desarrolladores conocen losprincipios de usabilidad antes de la construccin dela interfaz, esto les permite tenerlos en cuenta en elproceso de implementacin (Ferr, 2003).

Pensando en lograr la reutilizacin de arte-factos, esta propuesta plantea basar la ejecucin depruebas y evaluaciones heursticas de usabilidadprincipalmente en un tipo de artefacto: las listas dechequeo mejoradas. Las listas de chequeo bsicasestn creadas a partir de un conjunto de heursticas(en el caso de este proyecto las denominaremoscaractersticas) de usabilidad recopiladas de laspropuestas de Nielsen (1993), Tidwell (2006) yLabIUtil (2003), Gonzlez, Lors y Pascual (2001) yShneiderman y Plaisant (2006). Los expertos en usa-bilidad aportarn otras caractersticas a las listas dechequeo segn la aplicacin de software particularque se desarrollar. Estas caractersticas sirven como

material de referencia para realizar una evaluacinconsistente y objetiva. Las mejoras que se apliquen alas listas en esta propuesta se explicarn al final de estaseccin. La reutilizacin de la lista de chequeo es unaherramienta importante a la hora de evaluar, puesesto ayud a centralizar las observaciones en aspectosque tenan que ver en forma directa con la interfazy el desempeo del usuario eficaz y eficientemente.

La propuesta, entonces, busca enfrentar eldesarrollo del producto de software desde una pers-

pectiva centrada en los principios de usabilidad paralograr un producto de software de calidad en el uso.La tabla 1 muestra que cada tarea de usabilidad estasociada con uno o varios artefactos entregables conlos que se quiere verificar su cumplimiento, p. ej. enla etapa de ingeniera de requisitos esta tabla muestraque se debe hacer la revisin de escenarios actuales,

la descripcin de las caractersticas de usabilidaddeseadas, las funcionalidades del software que ten-drn mayor impacto en los usuarios y, por ltimo,la definicin de requisitos de uso y validacin. Estas

tareas se verifican con algunos artefactos entregables,como el modelado para la especificacin de contextode uso (MEC). El MEC es un artefacto que describecul ser el entorno de uso de la aplicacin, es decir,en qu condiciones y con qu herramientas se usar.Tambin se debe entregar en esta etapa la lista decaractersticas de usabilidad (LCU), el documentode requisitos validados (DRV) y el documento depriorizacin de requisitos (DPR). A continuacin semuestra la descripcin completa de las tareas y arte-factos de usabilidad que se debern entregar en cada

una de las etapas de desarrollo de software. Paraclaridad de las figuras posteriores, a cada artefactose le asocia un identificador.

La figura 1 describe los actores involucradosen las actividades de usabilidad planteadas dentro decada etapa de un proceso de desarrollo de software,y se especifican sus responsabilidades con respectoa los artefactos propuestos.

Para la etapa de Ingeniera de Requisitos, el

desarrollador es responsable de los entregablesplanteados, pero necesita de los usuarios del siste-ma (avanzado e intermedio) para tomar en cuentala visin de ellos sobre las tareas por desarrollar ysus expectativas sobre la interfaz. Para la etapa deAnlisis y Diseo, los expertos en usabilidad (desa-rrollador y auditor) construyen las plantillas de listasde chequeo de usabilidad. El desarrollador debeplasmar el diseo de las interfaces de usuario y laespecificacin funcional.

Para la etapa de codificacin y pruebas, losdesarrolladores codifican teniendo en cuenta losrequisitos de usabilidad establecidos y para cadaversin hacen evaluaciones de usabilidad con lasplantillas que ellos mismos construyeron. Tambinse encargan de la depuracin de la interfaz. Si seutilizan ingenieros de pruebas, seran estos quienes

7/24/2019 237-262-1-PB

7/19


realicen las evaluaciones heursticas de usabilidadjunto con los desarrolladores. Para la etapa deprue-bas con usuarios, los usuarios ejecutan las pruebasde usabilidad basndose en las plantillas de listas dechequeo construidas por los desarrolladores o audi-tores; los desarrolladores deben hacer el anlisis delos resultados y proponer las listas de depuracin delsoftware. Finalmente, para la etapa de verificacin,

los auditores realizan las evaluaciones de usabilidadcon las plantillas de listas de chequeo que ellos mis-mos construyeron,deben realizar tambin el anlisisde problemas encontrados y sintetizar una lista deinconformidades o nuevos requisitos. Es impor-tante aclarar que cada etapa genera una serie deartefactos que son insumo para la etapa siguiente,como se aprecia en la figura 1;el proceso se concibe

Tabla 1.Tareas y artefactos de usabilidad propuestos

Tareas de usabilidad Artefactos entregables

Ingeniera de Requisitos (anlisis del negocio, especicacin de requisitos funcionales y no funcionales, validacin

de requisitos)

Revisin de escenarios actuales o deseados

(usuarios, tareas, ambientes)

Descripcin de caractersticas de usabilidaddeseadas

Denicin de las funciones del software con

mayor impacto en las tareas de los usuarios

Denicin de requisitos de uso y su validacin

Modelado para la especicacin del contexto de uso (MEC).

Lista de caractersticas de usabilidad para tener en cuenta dentro

del desarrollo (LCU).

Documento de requisitos validado teniendo en cuenta aspectos

de usabilidad (DRV)

Documento de priorizacin de requisitos de usabilidad del producto

(DPR)

Anlisis y Diseo(subsistemas, componentes, mdulos de software, diseo de pruebas)

Diseo de escenarios y tareas de los usuarios

(diseo de interaccin)

Diseo de la ayudaDiseo de listas de chequeo de usabilidad

(plantillas)

Especicacin funcional del producto con nfasis en el diseo

detallado de la interaccin (EF)

Diseo de la interfaz de usuario (DIU)Plantillas de las listas de chequeo (PLC)

Codifcacin y Pruebas (cdigo fuente, ejecucin de pruebas de los desarrolladores)

Implementacin de las interfaces de usuarioValidacin de los prototipos del software contra

la especicacin, utilizando las listas de chequeo

y la lista de caractersticas de usabilidad para

tener en cuenta

Reporte de la evaluacin de usabilidad realizada por losdesarrolladores (REUD)

Diagnsticos de los defectos de usabilidad (DDU)

Lista de inconformidades para ser depuradas (LID)

Interfaz de usuario validada y depurada (IUV)

Pruebas con Usuarios (ejecucin de pruebas y con usuarios seleccionados)

Validacin de funciones teniendo en cuentaaspectos de usabilidad utilizando listas de

chequeo

Resultados de las pruebas de usabilidad realizadas por los usuarios

(RPUU)Diagnsticos de los defectos de usabilidad (DDU)

Lista de inconformidades para ser depuradas (LI)

Interfaz de usuario depurada nuevamente (IUV)

Verifcacin (vericacin funcional, vericacin del producto, vericacin del sistema)

Vericacin de funciones teniendo en cuenta

aspectos de usabilidad empleando listas de

chequeo

Resultados de la evaluacin de usabilidad realizada por los

auditores del sistema (REUA)

Diagnsticos de los defectos de usabilidad (DDU)

Lista de nuevos requisitos de usabilidad e inconformidades (LI)

7/24/2019 237-262-1-PB

8/19

130 RevistaEIA


de manera cclica e iterativa, en el cual de acuerdocon cada ciclo se van depurando gradualmente lascaractersticas de usabilidad de la aplicacin.

Las listas de chequeo clsicas encontradashasta el momento califican las caractersticas deusabilidad como cumple o no cumple. De estamanera, se pueden obtener resultados imprecisos,ya que es probable que la caracterstica evaluadase encuentre presente pero no est totalmenteimplementada. En este caso no se debera calificarcumple o no cumple, sino que sera mejor ex-presarlo como una expresin numrica de valoresde verdad sobre la totalidad del cumplimiento. Sepropone modificar las listas de chequeo clsicas, queen adelante denominaremos plantillas, agregandopara cada caracterstica que se evala tres metadatossobre la percepcin del evaluador, segn se enunciana continuacin.

Ponderacin de importancia de cada carac-

terstica para el evaluador. Recopilar la impresindel evaluador sobre la relevancia que tiene en l la

caracterstica permitir ms adelante clasificar lascaractersticas de usabilidad ms relevantes paracada tipo de usuario evaluador. La ponderacin de

importancia se califica entre 1 (poco importante) y5 (fundamental).

Calificacin del nivel de cumplimiento de cada

caracterstica para el evaluador.El grupo investigadordecidi que en muchos casos el usuario puede juz-gar que la caracterstica se cumple en algn nivel.Por esto, se decidi incluir la calificacin como laexpresin de un nivel de cumplimiento entre 0 (lacaracterstica no se cumple en absoluto) y 100 (lacaracterstica se cumple por completo). Esto permitedefinir el valor porcentual de conformidad sobrecada caracterstica evaluada desde la perspectivade cada evaluador de la interfaz.

Justificacin de la calificacin.Con este meta-dato se indaga sobre las causas que pueden tener lascalificaciones altas y bajas de nivel de cumplimientoy las razones por las cuales los usuarios ponderancomo alta o baja una caracterstica de usabilidad.

Figura 1.Actores involucrados en el desarrollo de las tareas de usabilidad planteadas

para el ciclo de vida de desarrollo

7/24/2019 237-262-1-PB

9/19


Para evitar la dificultad de llegar a un consenso sobrelas justificaciones lo mejor es proporcionar una listafija de posibles justificaciones.

La tabla 2 describe el esquema general de las

listas de chequeo modificadas. En la seccin 4 semostrarn algunos ejemplos de las plantillas cons-truidas para la evaluacin del software PREDICA.

4. APLICACIN DE LAPROPUESTA

El producto de software particular, en cuyodesarrollo se aplic la propuesta, es una bibliotecadigital web de consulta de documentos en el reade las ciencias de la computacin (PREDICA). El

anlisis de la primera versin del software, hechocon la tcnica de foro de discusin dirigido, permi-ti evolucionar conceptualmente la interfaz hastael punto de sustentar la utilizacin de aplicacionesricas en internet (RIA, por su sigla en ingls deRichInternet Application) como un nuevo paradigma deinteraccin para las versiones siguientes. Utilizar losconceptos de RIA implica enfocarse en nuevas herra-mientas que enriquecen la interaccin del usuario,amplan su experiencia y relacin con la aplicacin

(Eichorn, 2006; OReilly, 2005).La figura 2 muestra las perspectivas de usua-

rios, entregables y tareas para lograr la evaluacinde usabilidad en ciclo de desarrollo empleado parala aplicacin PREDICA.

Se agruparon por lo menos 12 usuarios finalesde pruebas en cada uno de los cinco grupos propues-tos, de acuerdo con su afinidad a Internet y con elporcentaje de actividades dedicadas a la consulta

de material bajo este ambiente. Adicionalmente, seconsideraron los aspectos culturales (nacionalidad,regin, formas de expresin) y del entorno circun-dante al usuario (aplicaciones bajo ambiente webcon las cuales est familiarizado el usuario). Para esteproyecto no se tuvieron en cuenta aspectos tnicosni de sexo, pues se consideraron irrelevantes para laevaluacin propuesta.

Se desarrollaron dos grupos de plantillas o ar-chivos diferentes con listas de chequeo, partiendo de

las listas de chequeo bsicas. Estas plantillas fueronrealizadas por los dos grupos de expertos (desarro-lladores y auditores del sistema). La primera plantillade cada grupo evala la usabilidad de los formulariosde consulta en la interfaz de consulta general y enla avanzada. La segunda plantilla de cada grupoevala la pgina de resultados de los documentosrecuperados del mdulo de consultas generales yavanzadas. La tabla 3 muestra un resumen de unalista de chequeo elaborada por los desarrolladorespara evaluar la usabilidad de los formularios de

consulta. La tabla 4 muestra un resumen de una listade chequeo elaborada por los desarrolladores paraevaluar la usabilidad de la pgina de resultados. Latabla 5 recopila las caractersticas de las plantillas delistas de chequeo.

Tabla 2. Esquema general de las listas de chequeo modicadas

Caracterstica de usabilidadpor comprobar

Ponderacin de

importancia1 (poco), 5

(fundamental)

Nivel de

cumplimiento(0-100)

Justifcacin

Pregunta que indaga sobre el cumplimiento

de una caracterstica de usabilidad_____ _____

Opcin 1

Opcin N

7/24/2019 237-262-1-PB

10/19

132 RevistaEIA


Tabla 3. Resumen de lista de chequeo por los desarrolladores sobre formularios de consulta

Caractersticas de usabilidad

Nivel de

importancia

(1-5)

Cumplimiento

(0 % - 100 %) Justifcacin

Al entrar a la aplicacin se despliega automticamente la

interfaz de consulta general?

La interfaz de consulta general contiene un cuadro de textopara introducir los trminos de la consulta?

La interfaz de consulta general contiene un botn con la

cadena buscar y no otra, para activar la consulta?

El rea de bsqueda est identicada con un encabezado

que titula la opcin de bsqueda?

El cuadro de texto soporta una cantidad de caracteres

adecuada para que el usuario pueda escribir la consulta?

Figura 2.Perspectivas de usuarios, entregables y tareas para lograr la evaluacin de usabilidad

en ciclo de desarrollo empleado para la aplicacin PREDICA

7/24/2019 237-262-1-PB

11/19


Tabla 4. Resumen de lista de chequeo por los desarrolladores sobre pgina de resultados


Nivel de

importancia

(1-5)

Cumplimiento

(0 % - 100 %) Justifcacin

Los resultados se muestran en la misma interfaz de consulta,de tal forma que el usuario no pierde el enfoque general de la

aplicacin?

Los resultados se muestran de forma lineal, de tal forma que los

primeros son aquellos que tienen mayor relevancia con respecto

a todos los trminos especicados en la consulta?

Cada resultado tiene un enlace visible para que el usuario

acceda al documento buscado o a visualizar ms informacin

de ste?

En la pgina de resultados aparece claramente un resumen

o palabras clave que le muestran al usuario el tema de cada

documento encontrado?

La interfaz le muestra al usuario el nmero de documentos

recuperados?

La pgina de resultados mantiene visible la consulta que el

usuario hizo para que pueda ver lo que se encontr con respecto

a lo buscado?

Tabla 5.Caractersticas de las plantillas de listas de chequeo

Grupo de expertos

No. de caractersticas

recopiladas

No. de plantillas

construidas

Interfaces que se someten

a pruebas de usabilidad

Desarrolladores(5 personas)

50 2Formulario de consulta general y

de consulta avanzada. Resultados

de consulta general y de consulta

avanzadaAuditores

(12 personas)65 2

Los resultados de las primeras evaluacionesheursticas elaboradas por los desarrolladores y la

depuracin subsecuente del software contribuyerona la construccin de la versin 2.0 de la interfaz(figura 3).

En las pruebas de usabilidad, los usuarios noconocan de antemano la aplicacin. Al grupo deusuarios de cada grupo se les proporcionaron lasplantillas de evaluacin y se les invit a utilizar la

aplicacin sin ningn manual ni ayuda. Los usuariosreportaron su experiencia con PREDICA calificando

cada una de las caractersticas de usabilidad en lasplantillas.

El anlisis de los resultados de las pruebascon usuarios y las evaluaciones heursticas de losdesarrolladores llevaron a las depuraciones de lainterfaz para producir las versiones 2.1 y 2.2 de lainterfaz (figura 4).

7/24/2019 237-262-1-PB

12/19

134 RevistaEIA


Por ltimo, las evaluaciones heursticas reali-zadas por el grupo de auditores del sistema con suspropias plantillas, cuyos resmenes se presenta en la

tabla 6 y la tabla 7, generaron una tercera ronda dedepuraciones con la que se lleg a la versin actual2.3 de la interfaz (figuras 5 y 6).

Figura 3.Versin 2.0 de la interfaz de consulta general de PREDICA


7/24/2019 237-262-1-PB

13/19


Tabla 6. Resumen de lista de chequeo por los auditores para formularios de consulta


Nivel de

importancia

(1-5)

Porcentaje de

cumplimiento

(0 % - 100 %)

Justifcacin

El usuario tiene cmo elegir el intercambio entre bsqueda

general y avanzada?

Las convenciones de navegacin son consistentes en todo

el sitio web?

El tamao de la letra es lo sucientemente grande para todos

los usuarios?

Se evita generar ventanas sobre ventanas para visualizar los

detalles de un elemento?

Tabla 7. Resumen de lista de chequeo por los auditores para evaluar pgina de resultados


Nivel de

importancia(1-5)

Cumplimiento(0 % - 100 %)

Justifcacin

Se presentan los resultados como una lista de resultados, en

orden descendente, segn alguna estimacin de relevancia?

Cada resultado tiene un enlace que permita encontrar ms

informacin?

Los resultados tienen un resumen de lo encontrado?

Cada resultado tiene un ttulo descriptivo?

Se categorizan los resultados, de tal manera que los mejores

sean los primeros?


7/24/2019 237-262-1-PB

14/19

136 RevistaEIA


5. RESULTADOS Y DISCUSIN

El grupo de investigadores deseaba indagar sila valoracin sobre el cumplimiento de las caracters-ticas de usabilidad en el software es subjetiva al tipode usuario que realiza la ejecucin de las pruebaso evaluaciones. Por tanto, las plantillas propuestas

para las listas de chequeo formulan una calificacinporcentual y no una calificacin absoluta (S o NO)sobre el cumplimiento de cada caracterstica deusabilidad listada (ver tablas 3-6). Para el caso deestudio realizado con PREDICA, el grupo de in-vestigadores realiz el anlisis de las calificacionesrecopiladas que hicieron los desarrolladores y los tresgrupos de usuarios. En este anlisis, para el campocuantitativo Nivel de cumplimiento muestra unatendencia que indica que, segn el tipo de usuario,la calificacin promedio era diferente. La figura 7permite el nivel de satisfaccin de los diferentes tiposde usuario frente a la usabilidad del sistema para laprimera ronda de pruebas conjunta sobre la versin2.0 del sistema PREDICA. Es importante destacarque en este contexto la satisfaccin no se refiere ala apreciacin esttica y satisfaccin subjetiva de los

elementos grficos de la interfaz de usuario, sino ala satisfaccin de usuario respecto al cumplimientoo no de las caractersticas de usabilidad presentadasen la plantilla.

Para las pruebas sucesivas con usuarios, lacalificacin del campo cuantitativo Nivel de cum-plimiento muestra una tendencia que indica queel nivel de satisfaccin general sobre la usabilidaddel software aumentaba tras cada depuracin. Lafigura 8 permite apreciar el aumento en el nivel desatisfaccin de los diferentes tipos de usuario frentea la usabilidad del sistema para cada una de lasversiones del software.

Con el anlisis del campo cuantitativo dePonderacin de importancia el grupo de investiga-dores tambin pudo establecer como tendencia quela calificacin del campo para cada caractersticaevaluada en las listas de chequeo es diferente segnel tipo de usuario. La figura 9 muestra el grado deponderacin de importancia general de las carac-tersticas de usabilidad de acuerdo con el tipo deusuario para la versin 2.0 de la interfaz.

Figura 6.Versin 2.3 de la interfaz de consulta avanzada por reas de conocimiento

7/24/2019 237-262-1-PB

15/19


Figura 7.Calicaciones del cumplimiento de usabilidad general para la versin 2.0

Figura 8. Calicaciones de los usuarios del cumplimiento de usabilidad general para cada versin

7/24/2019 237-262-1-PB

16/19

138 RevistaEIA


Con la investigacin tambin se evidenci latendencia de que las listas de chequeo construidaspor auditores son ms exhaustivas que las construi-das por los desarrolladores. En el caso de PREDICA,el anlisis sobre el nmero de caractersticas deusabilidad presentes en las listas de chequeo quemuestra la tabla 5 permite observar que el nmero de

caractersticas recopiladas por los auditores superanen un 30 % al nmero de caractersticas recopiladaspor los desarrolladores.

6. CONCLUSIONES

Esta propuesta de actividades y artefactos esun ejemplo en la literatura que apoya la idea de queintroducir perspectivas de usabilidad desde etapastempranas del desarrollo de software permite alcan-zar un mejor nivel de depuracin de la interfaz antes

de emplear la aplicacin de software. Utilizando estapropuesta, se introducen conceptos de calidad deinterfaces de usuario durante el proceso de desa-rrollo de software, garantizando la usabilidad de losusuarios al final de la entrega del producto.

Figura 9.Ponderacin de importancia general de usabilidad para la versin 2.0

Al utilizar la combinacin de diferentes tcni-cas de calificacin de usabilidad se potencian las re-comendaciones para la depuracin de la interfaz deusuario. Las diferentes tcnicas permiten evaluar demanera separada la usabilidad encontrando algunasrecomendaciones comunes y otras propias. Luegose pueden confrontar resultados para establecer de

forma rpida prioridades sobre las recomendacio-nes que sern depuradas inicialmente y el orden dedepuracin para las subsecuentes.

La reutilizacin de las plantillas de listas dechequeo mejoradas, planteada en esta propuesta,permite realizar la evaluacin heurstica de los exper-tos en usabilidad y tambin ser utilizadas como guapara el desarrollo de las pruebas con usuarios. Estareutilizacin permite la aplicacin de estas dos tcni-cas con ahorro de tiempo y dinero, ya que se suprimela elaboracin de diferentes tipos de artefactos paraambas tcnicas. Adicionalmente, la nueva manerapropuesta de calificar las listas de chequeo brindams herramientas de informacin sobre la percep-cin de los diferentes tipos de usuarios y sus razones.El campo cualitativo Justificacin, agregado a laslistas de chequeo, permite indagar las razones de lacalificacin de los usuarios para cada caracterstica,

7/24/2019 237-262-1-PB

17/19


muy til sobre todo para aquellas calificadas conbajo nivel de cumplimiento que generan elementosconcretos para depurar la interfaz. Para evitar untrabajo tedioso al analizar diferentes justificaciones

y hallar opiniones comunes entre los usuarios, serecomienda ofrecer una lista de justificaciones pre-definidas para cada caracterstica evaluada. En laconstruccin de las listas de chequeo deben tenerseen cuenta los patrones ya definidos de modelos deinterfaces web y comportamientos esperados por losusuarios e incluso tambin los comportamientos nodeseados (antipatrones). Estos patrones y antipatro-nes de usabilidad no deben ser ignorados y, por elcontrario, es un xito tenerlos en cuenta y procurarsu evaluacin desde etapas tempranas del desarrollo.

La propuesta de clasificacin de usuarios pre-sentada es adaptable a cualquier tipo de desarrollo.La idea propuesta de utilizar auditores como evalua-dores en usabilidad es una tcnica que les permiterealizar su tarea de inspeccin de manera sistemticay correcta frente al sistema construido, evaluandono solo la funcionalidad, sino la interaccin de losusuarios; cabe resaltar, como se enunci en la sec-cin 2, que el auditor no se encuentra inmiscuidoen las etapas de anlisis ni de la implementacin

de software, lo cual le da un carcter ms generalrespecto a la evaluacin que realiza; el acierto sepercibe en la interaccin con el grupo de desarrolloy la manera como su perspectiva exgena contribuyea la realimentacin y, por ende, a la correcta evalua-cin del proyecto. Tambin hay que reconocer losbeneficios de introducir las listas de chequeo elabo-radas por desarrolladores desde etapas tempranasdel proceso de desarrollo de software. Por tanto,es bueno utilizar estos dos tipos de expertos parapreparar listas de chequeo, con el fin de ejecutar

evaluaciones de usabilidad desde etapas tempranasy tambin para hacer una revisin ms exhaustivapara las etapas finales del proceso de desarrollo.Se comprob el beneficio planteado de emplear aldesarrollador como un experto de usabilidad para laproduccin de listas de chequeo y adems utilizarlopara la ejecucin de estas evaluaciones. Pero dada la

diferencia en la ponderacin de importancia y nivelde cumplimiento de las caractersticas de usabilidadentre los desarrolladores y los usuarios, es claro queno se pueden dejar de utilizar los usuarios para la

ejecucin de las pruebas de usabilidad.La evaluacin de la interfaz de PREDICA fue

un buen ejercicio, ya que permiti, mediante un de-sarrollo experimental, comprobar el aumento de lasprincipios de usabilidad y disminuir la brecha entrelas necesidades y expectativas de los usuarios y sufuncionalidad. Esto se evidencia en el aumento dela calificacin del Nivel de cumplimientosobre losaspectos de usabilidad en el software para las prue-bas realizadas a los prototipos sucesivos de la interfaz.

7. TRABAJO FUTURO

Las tecnologas de aplicaciones web 2.0proponen nuevos retos en el rea de evaluacinde usabilidad web. Considerando que hay un granacercamiento en la web 2.0 hacia aplicaciones cadavez ms parecidas a las aplicaciones de escritorio,esto disminuye la brecha entre la usabilidad web yla usabilidad de aplicaciones de escritorio, adems,estas tecnologas van en contra de ciertos paradig-

mas de comportamiento de las aplicaciones webtradicionales y de patrones de usabilidad establecidospara el web tradicional. Por lo tanto, se deben realizarestudios de usabilidad para el web 2.0, con el obje-to de definir nuevos patrones de usabilidad web yadaptar algunos que eran tradicionales en la web 1.0,pero que ya no son aplicables en aplicaciones RIA.

AGRADECIMIENTOS

El trabajo descrito en este artculo se enmarca

en el proyecto de investigacin PREDICA, llevadoa cabo por la Escuela de Ingeniera de Sistemas yComputacin (EISC) de la Universidad del Valley financiado por el Instituto Colombiano para elDesarrollo de la Ciencia y la Tecnologa FranciscoJos de Caldas (Colciencias). Se resalta la labor delos ingenieros de desarrollo de PREDICA que

7/24/2019 237-262-1-PB

18/19

140 RevistaEIA


colaboraron con las actividades de pruebas: JavierE. Carrillo y Mauricio Ciprin. Tambin se resalta lalabor de los estudiantes de la asignatura Tcnicasde Pruebas de Software, semestre 2008-A de la

Universidad del Valle, que desempearon el rolde auditores de software. Por ltimo, los autoresexpresan su reconocimiento a las docentes Paola J.Rodrguez, Ivette Kafure y Mara Eugenia Valencia,quienes trabajaron con este equipo de investigacinen las pruebas de usabilidad de PREDICA aplicandola tcnica de anlisis de la tarea y la actividad.

REFERENCIAS

1. Alarcn, H. F.; Hurtado, A. M.; Pardo, C.; Collazos, C.

A. y Pino, F. J. (2007). Integracin de tcnicas de usa-bilidad y accesibilidad en el proceso de desarrollo desoftware de las MiPyMEs.Revista Avances en Sistemase Informtica, vol. 4, No. 3, pp. 149-156.

2. Aveledo, M. and Moreno, A. M. (2008). Responsibili-ties in the usability requirements elicitation process.Journal of Systemics, Cybernetics and Informatics,vol.6, No. 6, pp. 54-60.

3. Aveledo, M.; De la Rosa, A. and Moreno, A. Usabilitydesign recommendations: a first advance, in CISSE 2008.Disponible en http://conference.cisse2008.org/sched-ule.aspx.

4. Aveledo, M. and De la Rosa, A. Incorporating us-ability in the software development process in theProceedings of International Association of Scienceand Technology for Development 2010 (IASTED 2010)on Software Engineering.

5. Bevan, Nigel. Extending quality in use to provide aframework for usability measurement. Lecture Notesin Computer Science, Berlin/Heidelberg: Springer, vol.5619/2009, Book Human Centered Design, 2009, pp.13-22.

6. Cheikhi, L.; Abran, A. and Suryn W. Harmonization ofusability measurements in IS09126 software engineer-ing standards. IEEE ISIE. 2006. Montreal, Quebec,Canada. pp. 3246-3251.

7. Cysneiros, L. M. and Kushniruk, A. 2003, Bringingusability to the early stages of software development.Requirements Engineering Conference. 2003. Proceed-ings. 11th IEEE International, pp. 359-360.

8. Eichorn, J. Understanding AJAX: Using JavaScript tocreate rich internet applications. New Jersey: PrenticeHall, 2006. pp. 4-12.

9. Ferr, X.Incrementos de usabilidad al proceso de desa-rrollo software.VIII Jornadas de Ingeniera del Software

y Bases de Datos, 2003 JISBD. Alicante, Espaa (12-14noviembre, 2003). pp. 293-302.

10. Florin, B. E.; Valencia, M. E.; Rodrguez, P. J.; Milln,M.; Gaona, C. M.; Carrillo J. E. y Ciprin M. (2007).Diseo de una plataforma experimental para labsqueda y recuperacin de documentos en unabiblioteca digital.Ingeniera y Competitividad, vol. 9,No. 2, pp.105-117.

11. Gonzlez, M. P.; Lors, J. y Pascual, A. Evaluacinheurstica. Universidad de Lleida. 2001. Consultado el23 de enero de 2008. Disponible en: http://griho.udl.es/ipo/ipo/pdf/15-Evaluacion-Heuristica.pdf

12. Granollers, T.; Lors, J.; Sendn, M. y Perdrix, F. (2005).Integracin de la IPO y la ingeniera del software:MPlu+a. III. Taller en Sistemas Hipermedia Colabo-rativos y Adaptativos SIHICA2005 (Granada, Espaa,septiembre 13-16, 2005). Disponible en http://www.aipo.es/items.php?id=83.

13. Granollers, T.; Lors, J. y Caas J. J.Diseo de sistemasinteractivos centrados en el usuario.UOC. 2005. http://griho.udl.es/mpiua/mpiua/index.htm Consultado enoctubre de 2007.

14. Hakiel, S. Delivering ease of use (1997). Computer& Control Engineering Journal, vol. 8, No. 2 (Apr.),

pp. 81-87.15. ISO/IEC 25010-3: Systems and software engineering:

software product quality and system quality in use models.

2009. Available in: http://www.iso.org/iso/catalogue_de-tail.htm?csnumber=35733.

16. Juristo, N.; Moreno, A. M. and Sanchez-Segura, M. I.(2007). Guidelines for eliciting usability functionali-ties.IEEE Transactions on Software Engineering,vol.33, No. 11, pp. 744-758.

17. Kafure, I. Validao do formalismo TAOS para a anliseda tarefa no contexto da concepo de interfaces homem-

computador. Tesis (Maestra). Universidade Federalde Campina Grande. http://copin.ufcg.edu.br/ 2000.Consultado en enero de 2008.

18. Kafure, I. Usabilidade da imagem na recuperao dainformao no catlogo pblico de acesso em linha. Tesisde Doutorado, Universidade de Braslia, Departamentode Cincia da Informao e Documentao. 2004.

7/24/2019 237-262-1-PB

19/19


19. Kafure, I.; Valencia, M. E.; Rodrguez, P. J.; Florin, B.E.; Carrillo J. E.; Ciprin, M. y Solarte O.Evaluacin dela usabilidad de la biblioteca digital PREDICA. Memoriasdel Seminario Internacional de Bibliotecas Digitales,Brasil. 2007. Disponible en http://libdigi.unicamp.br/

document/?code=23485.20. LabIUtil - Laboratrio de Utilizabilidade da Informtica.

Critrios ergonmicos. http://www.labiutil.inf.ufsc.br/CriteriosErgonomicos/LabIUtil2003-Crit/100conduc.html. 2007. Consultado en septiembre de 2007.

21. Mayhew, D. The usability engineering lifecycle.MorganKaufmann, 1999. pp. 339-483.

22. Medeiros, J. H.; Kafure, I. and Lula, B. TAOS a task-and-action oriented framework for users task analysisin the context of computer interfaces design. IEEEComputer Society Press. 2000. SCCC 00. Proceedings.XX International Conference, 16-18 Nov. 2000, pp.

24-31.23. Nielsen, J. Usability engineering.Academic Press, 1993.

pp. 115-206.

24. Nielsen, J.Designing web usability: the practice of sim-plicity.Indianapolis: New Riders Publishing, 1999. pp.129-155, 224-238.

25. Nielsen, J. and Loranger, H.Prioritizing web usability.Berkeley: New Riders Press, 2006. pp. 57-121, 137-170.

26. OReilly, T. What is web 2.0:Design patterns and busi-ness models for the next generation of software. [online]2005. http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html. (2005). Con-sulted on January 23, 2008.

27. Ramli, R. and Jaafar, A. e-RUE: A cheap possible solu-tion for usability evaluation, Information Technology,

2008. ITSim 2008. International Symposium on Infor-matic Technology,vol. 3, 2008. pp.1-5.

28. Rosenbaum, S. Usability evaluations versus usabilitytesting: when and why? Professional Communication.IEEE Transactions,vol. 32. 1989. pp. 210-216.

29. Rubin, J. and Chisnell, D. Handbook of usability testing:how to plan, design, and conduct effective tests. WileyTechnical Communications, 2008. 2nded., chapter 1.

30. Shneiderman, B. y Plaisant, C. Diseo de interfaces deusuario. Madrid: Pearson Education. 2006. pp. 143-145.

31. Singh, M. U-SCRUM: An agile methodology for promot-ing usability. In: AGILE 08,Toronto, 2008. pp. 555-560

32. Tao, Y. Introducing usability concepts in early phasesof software development. In: Frontiers in Education,2005. FIE 05. Proceedings 35th Annual Conference.Indianopolis, 19-22 Oct. 2005. pp. T4C - 7-8.

33. Tidwell, J. Designing interfaces: patterns for effectiveinteraction design. OReilly, 2006. pp. 207-239.

237-262-1-pb

Documents