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