Analisis Sistematizado de la Incorporacion de laUsabilidad en el Desarrollo de SoftwareJuan Marcelo Ferreira Aranda, Laurent Gianina Daz Molas, Luis Gilberto Salinas

Facultad Politecnica, Universidad Nacional de Asuncion,San Lorenzo, Paraguay, Casilla de Correos 1439

{ jmferreira1978,laumolas, lg.salinas }@gmail.com

ResumenLa calidad es uno de los principales retos de laconstruccion de software. Mientras que la usabilidad es consideradaun atributo de calidad, desde la Ingeniera de Software se la asociatradicionalmente con los requisitos no funcionales y la aplicacion delas recomendaciones de usabilidad quedan postergadas al final deldesarrollo donde los problemas son mas costosos y, en ocasiones,imposibles de resolver. En este artculo presentamos un analisissistematizado incorporando la usabilidad en el desarrollo desde susinicios. Abordamos el desarrollo de un sistema real que trata sobre latramitacion de proyectos de ley en el Poder Legislativo del CongresoNacional Paraguayo desde la perspectiva de dos desarrolladores condistintos niveles de conocimiento en usabilidad. Durante el proceso,evaluamos el impacto de tal incorporacion y evidenciamos queel esfuerzo de implementar las funcionalidades de usabilidad sereduce sustancialmente al distribuir la sobrecarga de trabajo por lasdistintas etapas del desarrollo. Ademas, considerando la usabilidad alinicio hemos evidenciado una reduccion en los costos al minimizarla contratacion de profesionales de la comunidad Human Compu-ter Interaction (HCI) y al mantener actualizada la documentacionasociada al producto software anticipando una mejora en soporte,entrenamiento y productividad.

Palabras ClavesMecanismo de Usabilidad, Patrones de Progra-macion, Proceso de Desarrollo, Pautas de Desarrollo, Analisis deImpacto.

1. INTRODUCCION

En el marco de la calidad de un sistema software, lausabilidad es un atributo importante a tener en cuenta as comola seguridad, el rendimiento, la mantenibilidad, entre otros[3], [8], [9]. Tradicionalmente, la Ingeniera de Software tratala usabilidad como parte de los requisitos no funcionaleslimitandose a una propiedad exclusiva de la presentacion dela informacion y, para desarrollar un producto software usableera suficiente separar la capa de presentacion del resto delas funcionalidades [16]. Debido a la naturaleza del sistemay a las necesidades del usuario, a menudo se debe ir maslejos y no basta con tener en cuenta la presentacion paraobtener un software usable. La comunidad HCI ha propues-to recomendaciones para mejorar la usabilidad y varias deellas tienen impacto directo en la funcionalidad del productosoftware. Estudios recientes han evaluado la relacion entrela usabilidad y los requisitos funcionales sugiriendo que lausabilidad debe ser tenida en cuenta desde las etapas inicialesde la construccion como requisitos funcionales para evitarcostosos cambios posteriores [1], [4], [5], [10].

En este artculo analizamos la incorporacion de la usabilidaden el desarrollo de un producto software desde sus inicios.

Concretamente se evaluan los siguientes mecanismos de usa-bilidad (MUs)1 formalizados como patrones de programacion:Abort Operation, Progress Feedback y Preferences. Se utilizanunas Pautas de Desarrollo de Mecanismos de Usabilidad(PDMUs), descritas en la seccion 2, para estos tres MUs.Los trabajos relacionados a esta investigacion se detallan enla seccion 3. El caso de estudio y la metodologa aplicadapara el analisis estan explicados en la seccion 4. El desarrollode un producto software se realiza desde la perspectiva de dosdesarrolladores con distintos niveles de conocimiento en usabi-lidad partiendo de la educcion2 y especificacion de requisitos,pasando por el analisis y diseno hasta la implementacion. Enla seccion 5 se explica la incorporacion de la usabilidad deacuerdo a las recomendaciones de las PDMUs en las distintasetapas del desarrollo. En la seccion 6 evaluamos el impacto deincorporacion de los MUs. Cada evaluacion aporta datos queproporcionan una estimacion del esfuerzo adicional requeridopara incorporar cada MU en el proceso de desarrollo delsoftware. Finalizamos, en la seccion 7, demostrando que elesfuerzo de la usabilidad tratada en cada etapa del desarrollosuscita mejoras importantes en distintos aspectos al final delproceso tanto para el desarrollador como para el usuario.

2. PAUTAS DE DESARROLLO DE MECANISMOS DEUSABILIDAD O PDMUS

Las Pautas de Desarrollo de Mecanismos de Usabilidad(PDMUs) Development Guidelines for Usability Functiona-lities, a ser utilizadas por los desarrolladores, incluyen losdiferentes artefactos para la incorporacion de los MUs en lasdistintas etapas de desarrollo. Las PDMUs son el resultadode las investigaciones de Rodrguez y colegas [14], [15]donde se buscan soluciones reutilizables para analisis, disenoe implementacion de algunos MUs. Las soluciones obtenidasdan cobertura a las tres etapas principales del desarrollo y yaincluyen las recomendaciones HCI. En resumen, las PDMUsabordan cuatro aspectos importantes:

1. Requisitos: para la captura de requisitos de usabilidadse utiliza la gua de educcion de requisitos por cada

1Un mecanismo de usabilidad es una caracterstica clasificada como dealto impacto en el diseno y esta agrupado en familias. P. ej. Abort Operationpertenece a la familia Undo-Cancel.

2La educcion de requisitos consiste en hallar e identificar los requisitos quedebe satisfacer un determinado sistema software. Se trata de una actividadpropia de la ingeniera del software, anterior al analisis de requisitos.

mecanismo. En [18], [14] se encuentran las guas deeduccion para los mecanismos tratados en este artculo.

2. Analisis y Diseno: se trata del analisis y diseno preli-minar de los componentes para cumplir con las respon-sabilidades asociadas al mecanismo de usabilidad. Sepresenta un conjunto de disenos reutilizables a nivel dediagramas de clase y secuencia para la incorporacion dela usabilidad en la etapa de diseno. En [14] se encuentranlos patrones de diseno para los tres MUs.

3. Escenarios de aplicacion: trata sobre la descripcion delos posibles escenarios de aplicacion de cada mecanis-mo. Los distintos escenarios son esquematizados en unaestructura de arbol. Asimismo, se provee una relacionentre las recomendaciones de la gua de educcion derequisitos de usabilidad, los casos generales resultado delas preguntas de educcion, sus interpretaciones a nivelde aplicaciones web y el estado final del sistema. En[14] se encuentra esta informacion.

4. Patron de diseno e implementacion: hace referencia alpatron de diseno del MU y su correspondiente patronde programacion en php, .Net y Java. La solucionesta basada en un patron porque representa la estructurareconocida dentro de la comunidad de la ingenierade software para proponer soluciones reutilizables. Laplantilla del patron tiene diferentes secciones: un nom-bre, la descripcion del problema al que va dirigido, elcontexto de aplicacion. Segun el tipo de mecanismolas demas secciones varan. En [14] se encuentra, endetalle, la informacion acerca del patron de diseno eimplementacion para los tres MUs.

3. TRABAJOS RELACIONADOS

Varios trabajos analizan la relacion entre la usabilidad yel desarrollo de software. Bass y colegas [2] han estudiadolas implicancias de la usabilidad en momentos especficos deldesarrollo fuera de la interfaz grafica del usuario. Partiendode una serie de escenarios ellos describen la interaccion deun stakeholder con un sistema software atendiendo ciertosaspectos de usabilidad. Como resultado de su experimentose ilustra como el diseno de estos escenarios requiere mo-dificaciones no solo en la interfaz del sistema sino tambienen otras partes de sus funcionalidades produciendo evidenciassustanciales que la relacion entre la usabilidad y la arquitecturadel software va mas alla de separacion de la interfaz de usuarioy las funcionalidades basicas.

Por otro lado, los investigadores del proyecto STATUS[17] tambien han analizado la relacion entre usabilidad yla arquitectura de software. Ellos utilizaron una lnea derazonamiento para describir, en base a su experiencia, comoalgunas cuestiones de usabilidad estan relacionadas con laarquitectura de software. Por ejemplo, para la caracterstica decancelacion, los componentes que procesan acciones necesitanpoder interrumpirse y las consecuencias de las acciones volver-se atras [6], [7]. As, se ilustran intuitivamente las relacionesentre las caractersticas de usabilidad y el diseno del software.

Con posterioridad, las investigaciones avanzaron un pasomas adelantando las cuestiones de usabilidad no ya al momen-to de diseno arquitectonico, sino a la etapa de requisitos. Paraincorporar la usabilidad en las primeras etapas del desarrollo,se ha propuesto una serie de guas para la captura de requisitosque se utilizan durante la educcion de mecanismos de usabili-dad y el proceso de especificacion [13], [18]. Su aproximacionconsiste en definir un conjunto de pautas que faciliten la laborde los analistas en la captura de los requisitos de usabilidad,independientemente de su conocimiento en el area. Estas guasayudan al analista a entender las implicaciones y conocer comoeducir y especificar los mecanismos de usabilidad para unsistema software.

Adicionalmente, dichas investigaciones proveen datos sobreel impacto de incluir las recomendaciones de usabilidad en unsistema software [10], [11]. Los datos recolectados muestranque la construccion de ciertos componentes de usabilidad enun sistema software implica cambios realmente significativosen el diseno.

4. METODOLOGIA DE TRABAJO

Para llevar a cabo el analisis de la incorporacion de los MUsen las diferentes etapas de desarrollo se utiliza la metodologaorientada a objetos [19] basados en los siguientes modelos:

Modelo de requisitos: el modelo de requisitos se expresacomo modelo de casos de uso.Modelo de diseno: las funcionalidades de los casos deuso se expresan en diagramas de clase y secuencia.Modelo de implementacion: los casos de uso seinstrumentan bajo la arquitectura web Modelo-Vista-Controlador (MVC).

En la Figura 1 se muestra el esquema seguido para realizarel analisis sistematizado de la incorporacion de MUs. El siste-ma tomado como caso de estudio automatiza la tramitacionde proyectos de ley en el Poder Legislativo del CongresoNacional Paraguayo. Este sistema registra y da seguimientoa los proyectos de ley: ingreso del proyecto, derivaciones,resultado del proyecto tratado en sesion plenaria, entre otros.Se desarrolla desde la perspectiva de dos desarrolladores A yB, uno con experiencia previa y otro sin experiencia algunaen la aplicacion de MUs. Los artefactos para la incorporacionde la usabilidad son proporcionadas por el Experto3. Cadadesarrollador genera sus propios productos en las distintasetapas. Estos productos evolucionan con la incorporacion delos MUs. Por ejemplo, el documento de requisitos preliminarse transforma en un documento de requisitos final que contienela incorporacion de los MUs. De manera similar, en el diseno,se transforman los diagramas y se mide el impacto que implicadicha transformacion y el incremento en codigo en terminos deprogramacion. El trabajo de incorporacion introduce cambiosque deben ser analizados. Para ello, se registran datos decada etapa en relacion a las funcionalidades del sistema y lasrelacionadas a la usabilidad.

3El experto representa al autor de las soluciones formalizadas comopatrones contenidas en las PDMUs.

Figura 1: Incorporacion y evaluacion de los mecanismos de usabilidaden el proceso de desarrollo

5. INCORPORACION DE MUS EN EL DESARROLLO

El proceso de desarrollo comprende tres etapas iniciandopor la educcion y especificacion de requisitos, pasando porel analisis y diseno hasta la implementacion. Los produc-tos obtenidos en cada etapa (especificacion de requisitos desoftware [ERS], diagramas y codigo fuente) evolucionan conlas caractersticas de usabilidad. Los desarrolladores, haciendouso de las recomendaciones proporcionadas por las PDMUs,introducen transformaciones en los distintos productos decada etapa para converger a un sistema software con nivelesdeseables de usabilidad.

5.1. Educcion y Especificacion de Requisitos

El punto de partida es la elaboracion del documento delos requisitos propios del sistema. Dos desarrolladores A yB participan en esta etapa y cada desarrollador produce sudocumento de requisitos (ERS). La comprension y definicionde las funcionalidades o requisitos del sistema no se logran deuna sola vez, sino que se produce por mejora iterativa. As,varias sesiones de educcion de requisitos son requeridas paraproducir la descripcion estable de una funcionalidad. Con lasversiones estables de los requisitos de ambos desarrolladoresextraemos aquellas funcionalidades comunes en las cualesse realizara la incorporacion de los MUs. La informacionnecesaria sobre los MUs es capturada gracias a un conjuntode preguntas que proporcionan las guas para la educcion derequisitos de usabilidad [13], [18]. Estas guas se encuentranen las PDMUs [14]. La Figura 2 muestra un fragmento deERS de un caso de uso del desarrollador A donde se ve laincorporacion de los MUs Abort Operation y Progress Feed-back en textos resaltados; negrita-cursiva (flujo alternativo) ynegrita-subrayado (flujo basico) respectivamente.

5.2. Analisis y Diseno

La etapa del analisis y diseno inicia a partir del documentode requisitos del sistema con la usabilidad integrada. Cadadesarrollador, haciendo uso de los requisitos obtenidos, elaborael diseno basandose en diagramas de clases y de secuencias del

Figura 2: Fragmento de ERS de un caso de uso con los MUs AbortOperation y Progress Feedback

modelo Unified Modeling Language (UML). Estos diagramasevolucionan con la incorporacion de los MUs. La integracionde la usabilidad se realiza analizando previamente el patron dediseno propuesto, identificando los conectores necesarios parael acople con el diagrama de clases propio del sistema elabo-rado por el desarrollador. El resultado de la incorporacion deMUs en el diagrama de clases elaborado por el desarrolladorA se visualiza en un fragmento del diagrama de clases de laFigura 3. Los nuevos diagramas que aparecen sombreadoscorresponden a los disenos de los mecanismos de usabilidad,cada uno diferenciado por un tipo de letra distinto.

Figura 3: Fragmento del diagrama de clases con los MUs incorpora-dos por el desarrollador A

5.3. Implementacion

Tomando como punto de partida la especificacion de lasclases elaboradas durante el diseno se procede a describir esasclases de forma detallada y en el lenguaje de programaciondeseado, en este caso Java. Posteriormente cada desarrolladorincorpora iterativamente cada MU siguiendo el patron de pro-gramacion equivalente en ese lenguaje. Ambos desarrolladoresA y B inician esta etapa con el esquema de la base de datosmediante el diagrama entidad-relacion (ER). El diagrama ERrepresenta las estructuras de almacenamiento internas y la or-ganizacion de los registros de la base de datos. La construcciondel sistema se realiza bajo la arquitectura de tres capas (MVC).Cada capa se implementa siguiendo las convenciones decodigo para aplicaciones Java basadas en web conocida comoJava Server Faces (JSF). Con las funcionalidades codificadascada desarrollador introduce los mecanismos de usabilidadhaciendo uso de los patrones contenidos en las PDMUs[14]. En la Figura 4 se muestra un fragmento del codigorepresentando a la usabilidad anadida a una funcionalidad delsistema para el MU Progress Feedback por el desarrollador Aresaltado en recuadro sombreado junto con su representacionde la Interfaz de Usuario (IU). Tenga en cuenta que los codigosque implementan las funcionalidades de usabilidad contenidosen las PDMUs pueden ser introducidos a nivel de formulariosde la IU, de clases intermedias (sesiones, controladores) eincluso como estructuras adicionales representadas por tablasen la base de datos.

Figura 4: Fragmento de codigo JSF con el MU Progress Feedbackincorporado por el desarrollador A

6. DISCUSION SOBRE EL IMPACTO DE LOS MUS

La incorporacion de MUs produce cambios en los productosde cada etapa susceptibles de ser evaluados. Estos cambios sonexpresados en terminos cuantitativos (p. ej. Incrementos enlos productos de cada etapa) y cualitativos (p. ej. percepciondel esfuerzo de comprension e incorporacion de los artefactosasociados a cada MU).

6.1. Educcion y Especificacion de RequisitosDurante la etapa de requisitos se ha trabajado con las

guas de educcion de mecanismos de usabilidad [18], [14].Cada desarrollador ha realizado una lectura rapida de lainformacion de cada mecanismo de usabilidad para tener unaidea del problema al cual apunta. Dentro de las apreciacionespercibidas por los desarrolladores para considerar la usabilidaden esta etapa se destacan el lenguaje directo, claro y adaptableen la que estan formuladas las cuestiones de usabilidad enlas mencionadas guas. Igualmente, las preguntas apuntanhacia aspectos reales de la usabilidad materializandose poste-riormente en artefactos concretos (requisitos, diseno, codigo,etc.). Por el contrario, la utilizacion de las guas requiereconocer previamente el dominio del problema y algunosescenarios ejemplos de usabilidad a fin de discutir, adaptar orecomendar su utilidad en aquellas funcionalidades del sistemapotencialmente candidatas. Para cuantificar el impacto de losmecanismos de usabilidad en la educcion de requisitos se haseguido el analisis de impacto de la usabilidad en el disenosoftware realizado en [12] donde se calculan el porcentajede casos de uso que se expanden como consecuencia de losMUs. Las unidades son bajo, medio y alto dependiendo enque intervalo caen (por debajo de 33 %, entre 33 % y 66 %,por encima de 66 %).

En la Tabla 1 se muestra una evaluacion semejante aplicadaal sistema tomado como caso de estudio y el analisis harevelado un nivel de impacto medio-alto de los mecanismosAbort Operation y Progress Feedback quedando el Preferencescomo el de menor grado. Sin embargo, pese a la diferenciaen la cantidad de funcionalidades entre desarrolladores (28 y36), el nivel de impacto obtenido tiende hacia las mismas pro-porciones permaneciendo el mecanismo de usabilidad AbortOperation en el nivel mas alto. Esta situacion proporciona unaidea del probable impacto que recaera en la implementaciondel MU Abort Operation si se pospone la usabilidad enlas etapas finales del desarrollo. Tambien, con los resultadosobtenidos se validan los estudios realizados previamente sobreel analisis del impacto de la usabilidad en el diseno delsoftware [12].

MUs Nivel de impacto A Nivel de impacto BAbort Operation 21/28 Alto 75 % 23/36 Medio 64 %

Progress Feedback 13/28 Medio 46 % 12/36 Medio 33 %Preferences 1/28 Bajo 4 % 1/36 Bajo 3 %

Tabla 1: Impacto de los mecanismos de usabilidad en los requisitos

6.2. Analisis y DisenoLos resultados y reacciones manifestadas por los desarro-

lladores en esta etapa subrayan la necesidad de mejora en losartefactos contenidos en las PDMUs incluyendo indicacionesconcretas en lo que respecta a su utilizacion. Si bien lasPDMUs proveen disenos preliminares reutilizables para intro-ducir la usabilidad en los diagramas, estos disenos carecen desuficiente claridad y expresividad para utilizarlo directamenterequeriendo un analisis exhaustivo previo y en ocasiones, laasistencia del experto en usabilidad por parte de los desarro-lladores. La evaluacion del impacto de la incorporacion de

los MUs en esta etapa ha revelado resultados interesantes.Independientemente de la pericia del desarrollador, la incorpo-racion de los tres MUs en el diagrama de clases (DC) muestraun bajo nivel de impacto (Tabla 2). Es aceptable pensaren el bajo nivel de impacto de todos los MUs porque losdiagramas de clases solo describen la estructura del sistemamostrando sus clases, atributos y las relaciones entre ellossin interaccion alguna. Por otro lado, en la misma tabla, laincorporacion del MU Abort Operation y Progress Feedbacken el diagrama de secuencia (DS) senala una complejidadde interacciones media-baja. Para el caso del Preferences, seha obtenido un nivel de impacto bajo en los diagramas desecuencia. Esta evaluacion muestra, aunque ilustrativamente,que el Abort Operation supone una complejidad importanteen la implementacion, a excepcion del Progress FeedBack yPreferences.

MUs Desarrollador A Desarrollador BDC DS DC DSAbortOperation

Bajo 10 % Medio 35 % Bajo 8 % Medio 47 %

ProgressFeedback

Bajo 15 % Bajo 9 % Bajo 10 % Bajo 18 %

Preferences Bajo 7 % Bajo 2 % Bajo 4 % Bajo 1 %

Tabla 2: Impacto de los mecanismos de usabilidad en el diseno

6.3. Implementacion

Tras la incorporacion de los distintos MUs en el codigodel sistema, hemos observado interesantes posturas adoptadaspor los desarrolladores A y B en esta etapa. Por un lado,los artefactos propuestos para el MU Preferences resultaronmas comprensibles e intuitivos que el MU Abort Operationy el MU Progress Feedback debido al reducido numero deescenarios y un nivel de interaccion casi despreciable con elsistema implementandose nuevas funcionalidades con mnimasmodificaciones en las existentes. Por otro lado, la existenciade escenarios interconectados4 en el MU Abort Operationy la comprension de los mismos ha generado interrogantesal desarrollador en lo que respecta al esfuerzo/beneficio delmecanismo ya que el sistema tomado como caso de estudiocarece de funcionalidades consideradas crticas. A pesar de queel MU Progress Feedback no posee escenarios interconectadosse ha observado una reaccion similar al MU Abort Operationen los desarrolladores A y B, porque obtener la informacionde avance exige el control constante del proceso junto consus interacciones y las consultas implementadas en el sistemaresultaron relativamente simples no justificando el esfuerzo deimplementar tal mecanismo.

Los datos resultantes de la incorporacion de los MUs en estaetapa revelan un bajo nivel de impacto independientementedel mecanismo y del desarrollador. Mas detalladamente, enla Figura 5, los segmentos situados al tope de cada pilaevidencian que los MUs Abort Operation y Progress Feedback

4Los escenarios interconectados hacen referencia a aquellos escenarios enla cual la implementacion de uno requiere la implementacion de otro. Porejemplo, el escenario para guardar cambios requiere implementar tambien lasexcepciones: guardar y hay errores de validacion, guardar y hay errores en labase de datos.

tienen un impacto similar en terminos de incremento denuevas clases en la codificacion y comparativamente un mayorincremento es senalado por el MU Preferences. Tenga encuenta que los incrementos derivados del Abort Operation yProgress Feedback se acentuan cuanto mas funcionalidadesrequieran estos dos mecanismos, no as el Preferences cu-yos incrementos en artefactos permanecen inalterables con elnumero de funcionalidades. La cuantificacion en termino deincremento en metodos tiende hacia las mismas proporciones(Figura 6).

Figura 5: Nivel de impacto en Clases por MU de los desarrolladoresA y B

Figura 6: Nivel de impacto en Metodos por MU de los desarrolladoresA y B

7. CONCLUSIONES Y L INEAS FUTURAS

A las dificultades propias de cualquier desarrollo de soft-ware se suma un nuevo factor, la usabilidad. Al estar ligadala usabilidad de un sistema a los usuarios, necesidades ycondiciones especficas, se convierte en un elemento alta-mente dependiente del usuario y necesita atencion. Ademas,el problema del ingeniero que intenta anadir usabilidad alos sistemas software, es el alto coste en tiempo y esfuerzoque supone tratar la usabilidad durante el desarrollo. Porello, hemos realizado un ANALISIS SISTEMATIZADO DE LAINCORPORACION DE LA USABILIDAD EN EL DESARROLLO

DE SOFTWARE para evidenciar experimentalmente el impactoreal durante el proceso de desarrollo.

A nivel global, los resultados obtenidos revelan que elesfuerzo de dotar a un sistema con caractersticas de usabilidadse distribuye a lo largo de todo el proceso, atenuando lasobrecarga de trabajo que implicara tener en cuenta estascuestiones de usabilidad unicamente en la etapa final deldesarrollo. Esta situacion conlleva beneficios al productor desoftware y al usuario. Entre ellas, considerando ya las cues-tiones de usabilidad desde sus inicios hemos evidenciado quela documentacion asociada al producto software es completay menos susceptible a errores reduciendo costos, por ejemplo,reimpresion y distribucion de manuales. Tambien, como losdesarrolladores han utilizado unos artefactos de usabilidadse reduce la necesidad de contratar profesionales HCI oingenieros especializados para los proyectos software donderequieran niveles deseables de usabilidad. Trasladandonos alambito del usuario, el producto software con niveles deseablesde usabilidad introducira mejoras en los costos de soporte yentrenamiento. En este sentido, cuando un producto softwarees entendible y manejable el entrenamiento sera mnimo norequiriendo soportes frecuentemente. Asimismo, es de esperarque la usabilidad mejore la productividad ya que el usuariosentira dominio del sistema estableciendo sus configuracionespersonales, teniendo el control de sus acciones y estandoinformado del avance de las operaciones que realiza.

Adicionalmente destacamos otras aportaciones:

Experiencia en desarrolladores con distintos perfiles deusabilidad. Hemos realizado la evaluacion del impactoy esfuerzo de introducir la usabilidad en el proceso dedesarrollo desde la perspectiva de dos desarrolladores condistintas habilidades en usabilidad.Mejoras en los artefactos asociados a los mecanismosde usabilidad. Las mejoras incluyen la restructuracion delas pautas, los escenarios de aplicacion y los patronesde programacion en Java. Estas mejoras facilitan lautilizacion y comprension de las pautas para futuroscasos.Datos cuantitativos y cualitativos. El analisis sistemati-zado de la usabilidad aporta datos acerca del impactoy esfuerzo durante el desarrollo. Los datos complemen-tan la evaluacion y proveen informaciones importantesal desarrollador que desea trabajar con caractersticasfuncionales de usabilidad.

Con este analisis permanecen abiertas varias lneas deinvestigacion. Las siguientes lneas parecen prometedoras:

Ampliacion del espectro de casos de los MUs. La cober-tura de mas casos promueve la agregacion de mas datosy mejoras en los artefactos para alcanzar una solucionreutilizable e integrable en libreras o plug-ins.Evaluacion aplicada a otra metodologa y proyecto. Lautilizacion de otras metodologas y otros proyectos ex-tendera la aplicacion de las PDMUs en proyectos dedesarrollo similares.Analisis del impacto utilizando otras metricas. Siguiendo

un marco de referencia similar, abordar otro conjuntorepresentativo de metricas como Factor de acoplamien-to (Coupling Factor CF), Lneas de Codigo (Linesof Code per method LOC), entre otros, aportara uncomplemento valido al analisis y al mejoramiento de losartefactos de la usabilidad.Estudio de costos adicionales. Los datos cuantificados enesta investigacion proporcionan una base para realizaruna estimacion de los costos adicionales derivados enun proyecto software considerando a la usabilidad comoaspecto relevante.

REFERENCIAS[1] BARBACCI, M. R., ELLISON, R., LATTANZE, A. J., STAFFORD, J. A.,

WEINSTOCK, C. B., AND WOOD, W. G. Quality Attribute Workshops,Third Edition, 2003.

[2] BASS, L., AND JOHN, B. E. Linking usability to software architecturepatterns through general scenarios. Journal of Systems and Software 66,3 (2003), 187197.

[3] BOEHM, B. W., BROWN, J. R., KASPAR, H., LIPOW, M., MACLEOD,G. J., AND MERRIT, M. J. Characteristics of Software Quality. TRWseries of software technology. North-Holland, 1978.

[4] BOSCH, J., AND JURISTO, N. Designing software architectures forusability. 25th International Conference on Software Engineering, 2003.Proceedings. 3-10 May 2 (2003), 757758.

[5] CYSNEIROS, L. M., AND KUSHNIRUK, A. Bringing Usability to theEarly Stages of Software Development Usability Ontology References.Engineering (2003).

[6] DE ANDRES, A., BOSH, J., CHARALAMPOS, A., CHATLEY, R., FE-RRE, X., FOLMER, E., JURISTO, N., MAGEE, J., MENEGOS, S., ANDMORENO, A. M. Usability Attributes Affected by Software Architec-ture. Deliverable. 2, 2010.

[7] FOLMER, E., AND BOSH, J. Architecting for Usability; a Survey.Systems and Software 70, 1-2 (2004), 6178.

[8] GOLDEN, E. Early-Stage Software Design for Usability. PhD thesis,Carnegie Mellon University, 2010.

[9] IEEE STD 1061. IEEE Standard For A Software Quality MetricsMethodology Revision And Reaffirmation. Proceedings of IEEE In-ternational Symposium on Software Engineering Standards 1998, IEEEStd 1061-1998 (1998), 278278.

[10] JURISTO, N. Impact of Usability on Software Requirements and Design.Software Engineering International Summer Schools ISSSE 2006-2008(2009), 5577.

[11] JURISTO, N., AND MORENO, A. Moving usability forward to thebeginning of the software development process. Human ComputerInteraction, Bass 1999 (2005).

[12] JURISTO, N., AND MORENO, A. A Glass Box Design: Making theImpact of Usability on. Ifip International Federation For InformationProcessing Part II (2007), 541 554.

[13] JURISTO, N., MORENO, A., AND SANCHEZ-SEGURA, M.-I. Gui-delines for Eliciting Usability Functionalities. IEEE Transactions onSoftware Engineering 33, 11 (Nov. 2007), 744758.

[14] RODRIGUEZ, F. D. Programming Patterns for usability functionali-ties. http://www.grise.upm.es/sites/extras/7/ (ultimo acceso 10/11/2012),2010.

[15] RODRIGUEZ, F. D., AND ACUNA, S. T. Implementacion de unaSolucion Reutilizable para una Funcionalidad de Usabilidad. XVIIJornadas de Ingeniera del Software y Bases de Datos (2012), 14.

[16] SEFFAH, B. A., AND METZKER, E. The Obstacles and Myths ofUsability and Software Engineering. Communications of the ACM 47,12 (2004), 7076.

[17] STATUS. Software Architecture that supports Usability (STATUS).http://www.grise.upm.es/rearviewmirror/projects/status/index.html (ulti-mo acceso 11/01/2012).

[18] USEP. Usability Elicitation Patterns (USEPs). http://www.grise.upm.es/sites/extras/2/useps.pdf (ultimo acceso 11/01/2012).

[19] WEITZENFELD, A. Ingeniera de Software Orientada a Objetos conUML, Java e Internet, 1ra ed. ed. Thompson, 2005.