You are on page 1of 6

Usabilidad y arquitectura del software

Resumen: Qué es la Arquitectura del Software y que relación tiene con la usabilidad. Tener en
cuenta la usabilidad en el momento del diseño de la arquitectura de un sistema interactivo nos
puede ahorrar muchos quebraderos de cabeza.

El Iceberg de la usabilidad

Se podría decir que, en el diseño de un sistema, hay tres aspectos a tener en cuenta:

· la presentación de la información
· la funcionalidad de la aplicación
· la Arquitectura del Software

Hasta hace poco, se asumía que la usabilidad era una propiedad exclusiva de la presentación de
la información. Se creía que, encapsulando la capa de presentación y separándola del resto, se
podía desarrollar la aplicación y, de forma iterativa, pasar los tests de usabilidad. Tras cada test,
tan sólo sería necesario resolver los problemas modificando la presentación y, gracias a esta
separación, la funcionalidad no quedaría afectada.

En realidad, este modelo de desarrollo ha fallado a menudo. ¿Cuántas veces hemos tenido que
correr a realizar cambios profundos en la funcionalidad de una aplicación después de haber
detectado problemas de usabilidad? Dick Berry, en su analogía del Iceberg de la usabilidad,
explica que los aspectos relacionados con la presentación, es decir, lo que normalmente
entendemos como look & feel, sólo afectan en un 40% a la usabilidad. El 60% restante está
influenciado por lo que él llama “modelo del usuario”, que está constituido por los objetivos que el
usuario quiere alcanzar con sus tareas.
Berry relaciona el modelo del usuario con el modelo de objetos propio de la interfaz de usuario,
en el sentido estricto de la OOP (programación orientada a objetos), que incluye, entre otras
cosas, los objetos y las metáforas de la interfaz. Este modelo de objetos, siempre según Berry,
es el que permite al usuario relacionar sus objetivos con la funcionalidad del sistema.

Por lo tanto, y esto ya es de cosecha propia, para conseguir una buena usabilidad, no basta con
tener en cuenta la capa de presentación, sino que es preciso que la usabilidad se contemple
también en el momento de la definición de la funcionalidad de la aplicación.

Usabilidad y Arquitectura del Software

Sin embargo, a menudo hay que ir más lejos y no basta con tener en cuenta la presentación y la
funcionalidad. Sobre todo en sistemas complejos, como pueden ser los entornos distribuidos, los
transaccionales, los multicanal y aquéllos en los que puede haber miles de usuarios conectados
simultáneamente, hay que tener en cuenta la usabilidad desde el inicio del diseño del sistema, es
decir, desde lo que se denomina momento de Arquitectura del Software.

Es bien sabido por los ingenieros del software que cuanto más tarde se detectan los problemas,
más cuesta arreglarlos. ¿Cuántas veces nos ha pasado que, al diseñar una interfaz,
desearíamos crear interacciones y diálogos que el entorno tecnológico no nos permite? Y
siempre acabamos exclamando: ¡Pero si esto mismo lo hice en tal otro sitio! La respuesta de los
técnicos no se hace esperar y, utilizando un vocabulario lleno de siglas y conceptos técnicos, nos
dicen que en su plataforma esto no es posible.

Me refiero a cosas como que el usuario pueda visualizar el progreso de sus peticiones, que
pueda deshacer acciones (undo), que pueda disponer de un entono multilingüe, que pueda
cancelar una operación que lleva mucho tiempo en espera, que pueda reutilizar información que
ha introducido anteriormente, y muchas otras cosas.

Si analizamos estos escenarios de interacción, veremos que la causa de que no se puedan


implementar es que no se tuvo en cuenta al usuario al inicio del diseño del sistema, es decir, en
la Arquitectura del Software.

¿Qué es la Arquitectura del Software?

Existen muchas definiciones de Arquitectura del Software y no parece que ninguna de ellas haya
sido totalmente aceptada. En un sentido amplio podríamos estar de acuerdo en que la
Arquitectura del Software es el diseño de más alto nivel de la estructura de un sistema, programa
o aplicación y tiene la responsabilidad de:

· Definir los módulos principales


· Definir las responsabilidades que tendrá cada uno de estos módulos
· Definir la interacción que existirá entre dichos módulos:
o Control y flujo de datos
o Secuenciación de la información
o Protocolos de interacción y comunicación
o Ubicación en el hardware

La Arquitectura del Software aporta una visión abstracta de alto nivel, posponiendo el detalle de
cada uno de los módulos definidos a pasos posteriores del diseño.
La definición oficial de Arquitectura del Software es la IEEE Std 1471-2000 que reza así: “La
Arquitectura del Software es la organización fundamental de un sistema formada por sus
componentes, las relaciones entre ellos y el contexto en el que se implantarán, y los principios
que orientan su diseño y evolución”.

Los productos resultantes de la Arquitectura del Software

El objetivo principal de la Arquitectura del Software es aportar elementos que ayuden a la toma
de decisiones y, al mismo tiempo, proporcionar conceptos y un lenguaje común que permitan la
comunicación entre los equipos que participen en un proyecto. Para conseguirlo, la Arquitectura
del Software construye abstracciones, materializándolas en forma de diagramas (blueprints)
comentados.

No hay estándares en cuanto a la forma y lenguaje a utilizar en estos blueprints. De todas


formas, existe consenso en cuanto a la necesidad de organizar dichas abstracciones en vistas,
tal y como se hace al diseñar un edificio. La cantidad y tipos de vistas difiere en función de cada
tendencia arquitectónica.

Quizá uno de los modelos más conocidos es el “4+1” de Philippe Kruchten, vinculado al Rational
Unified Process (RUP), que define cuatro vistas diferentes:

· Vista lógica: describe el modelo de objetos.


· Vista de proceso: muestra la concurrencia y sincronía de los procesos.
· Vista física: muestra la ubicación del software en el hardware.
· Vista de desarrollo: describe la organización del entorno de desarrollo.
· Existe una quinta vista que consiste en una selección de casos de uso o de escenarios que los
arquitectos pueden elaborar a partir de las cuatro vistas anteriores.

Ejemplos de Arquitectura del Software: J2EE y MVC

Para ilustrar un poco lo que se ha explicado hasta ahora, a continuación se muestran dos
diagramas de arquitectura en un entorno J2EE. Ambos diagramas están disponibles en
Designing Enterprise Applications with the J2EE Platform, Second Edition.

El primer diagrama consiste en una vista lógica que muestra los componentes y servicios típicos
de un entorno J2EE.
El segundo diagrama es una vista de proceso que muestra las relaciones entre las capas model,
view y controller de la arquitectura MVC bajo J2EE.

La investigación sobre Arquitectura del Software y Usabilidad


El interés por la relación entre Arquitectura del Software y usabilidad no es nuevo, pero
recientemente han aparecido algunos trabajos que abren el camino a la práctica del resultado de
las investigaciones. Este año, tanto en Viena, en la Conference on Human Factors in Computing
Systems (CHI2004), como en Edimburgo, en la International Conference on Software
Engineering (ICSE04), un equipo liderado por Len Bass ha impartido un tutorial sobre el tema,
cuyo título es bastante ilustrativo: Avoiding “We can’t change THAT!”: Software Architecture &
Usability (Cómo evitar “¡Esto no se puede cambiar!”: Arquitectura del Software y Usabilidad). En
el equipo docente, junto a Bass estaban Bonni E. John y dos investigadoras españolas, Natalia
Juristo y Maribel Sánchez-Segura.

Escenarios de usabilidad sensibles a la Arquitectura del Software

El trabajo de Bass y de este equipo se basa en inventariar una serie de escenarios de usabilidad
sensibles a la Arquitectura del Software. Esto significa determinar una serie de momentos de
interacción o tareas del usuario que, para que el sistema los pueda soportar, tienen que estar
definidos en la Arquitectura del Software.

Hasta el momento, este inventario está compuesto de 26 escenarios que se pueden consultar en
el documento CMU/SEI-2001-TR-005 de Bass y otros.

La lista completa es demasiado extensa para el objetivo del presente artículo pero, a modo de
ejemplo, se enumeran a continuación los cinco primeros escenarios:
1. Agregación de datos: Poder aplicar simultáneamente una acción a un conjunto de datos u
objetos.
2. Agregación de comandos: Agrupar acciones que se puedan ejecutar de una sola vez.
3. Comandos de cancelación
4. Uso de aplicaciones de forma concurrente
5. Validación automática de la entrada de datos

Patrones arquitecturales

Bass continúa con una propuesta de patrón arquitectural para cada escenario (sobre el tema de
patrones, consultad el artículo de Luis Villa, Patrones para el diseño de interfaz, publicado en
Grancomo).

El objetivo es doble:
· Facilitar a los expertos en usabilidad una checklist con escenarios que muestre aspectos de
usabilidad importantes a tener en cuenta en tiempo de requerimientos.
· Facilitar a los arquitectos patrones que los guíen en el momento de dar soporte a los
escenarios.

Otro documento interesante es: Patrones de Usabilidad: Mejora de la Usabilidad del Software
desde el momento Arquitectónico (PDF), de Natalia Juristo y Maribel Sánchez-Segura. Una de
las aportaciones más interesantes de este documento es que describe el procedimiento de
obtención de los patrones de usabilidad que han de servir para construir los patrones
arquitectónicos.

Resumen

Siempre que se tenga la oportunidad, sería necesario que la usabilidad se tuviera presente
desde el inicio del diseño de un sistema, es decir, desde el momento de la Arquitectura del
Software. Pero, para que esta participación sea realmente efectiva, arquitectos y expertos en
usabilidad deberían tener un lenguaje común. Es en este sentido en el que los escenarios de
usabilidad y los patrones arquitectónicos pueden ser de gran ayuda.

Joseph Casanovas : casanovas@emailpersonal.com Actualmente estoy en el Área de


Innovación de “la Caixa”, empresa en la que he trabajado siempre en áreas tecnológicas.
En los últimos años he tenido la suerte de trabajar en lo que me gusta, la usabilidad, la
mayor parte del tiempo dedicado a la Intranet y a la plataforma financiera de “la Caixa”.

Me licencié ya mayorcito en Publicidad, los únicos estudios en mi época en los que se


podía aprender a la vez algo de diseño, sicología y sistemas documentales. También
tengo un master en Ingeniería del Software, actividad en la cual he trabajado durante
muchos años. Doy algunas clases de IPO/HCI en la Escuela Universitaria Politécnica de Mataró y parece que les gusta
ya que de momento siguen contando conmigo. Entré en contacto con la usabilidad cuando a finales de los ochenta me
compré un Mac. Para mi eso fue una bendición. No había Internet y empecé a gastarme un pastón en libros importados
para poder entender las razones de ese diseño de interfaz. Ponerlo en práctica ha sido lo más difícil, pero con el tiempo y
los errores uno va aprendiendo.

Publicando Originalmente en http://www.alzado.org/articulo.php?id_art=355


Permitida la reproducción citando al autor e incluyendo un enlace al artículo original.

You might also like