lunes, 4 de junio de 2012

Usabilidad y Arquitectura del Software

Hasta hace poco asumíamos que la usabilidad únicamente estaba relacionada con la capa de presentación de nuestra aplicación, pero el otro día durante la clase, nuestro profesor dio un ejemplo que me hizo pensar. Estaba explicando cómo mejorar la usabilidad de una página web usando javascript y en lo que hizo yo vi claramente un patrón MVC, y me hizo pensar en la relación que tendría el concepto de usabilidad con la arquitectura que debemos usar para realizar nuestra aplicación.

Según Dick Berry, en su analogía del Iceberg de la usabilidad, los aspectos relacionados con la presentación de una aplicación sólo afectan en un 40% a la usabilidad, mientras que el 60% restante está influenciado por el modelo de usuario, es decir, los objetivos que el usuario quiere alcanzar con sus tareas.



Berry va aún más lejos y relaciona el modelo de usuario del que hablábamos con el modelo de la OOP (programación orientada a objetos). Según Berry es este modelo el que permite al usuario relacionar sus objetivos con la funcionalidad del sistema.

Si diseñamos un software pensando que la usabilidad estará contenida en la capa de presentación, a la hora de programar internamente la aplicación no la tendremos en cuenta y posiblemente cuando nos surja algún problema el diseño de las capas internas estará tan avanzado que será muy complicado hacer cualquier modificación y supondrá un coste muy alto.

Hasta hace relativamente poco tiempo esto no se tenía en cuenta, pero recientemente se está trabajando mucho en este campo, intentando relacionar los patrones que usamos para crear nuestra aplicación con la usabilidad que tendrá ésta depués.

Escenarios de usabilidad y Arquitectura del Sofware

Investigadores como Len Bass han inventariado una serie de momentos de interacción o tareas del usuario que, para que el sistema las pueda soportar, tienen que estar definidas en la Arquitectura del Software. Este listado puede consultarse en el documento CMU/SEI-2001-TR-005. Algunas de estas acciones son:
  • Agregación de datos: Poder aplicar simultáneamente una acción a un conjunto de datos u objetos.
  • Agregación de comandos: Agrupar acciones que se puedan ejecutar de una sola vez.
  • Comandos de cancelación
  • Uso de aplicaciones de forma concurrente
  • etc
En el mismo trabajo Bass propone una solución en forma de patrón software para cada escenario. 
Por ejemplo para el caso de Agregación de datos propone definir 3 entidades distintas:
  • Command Manager: Es el encargado de de manejar los comandos del usuario
  • Grouping Manager: Maneja las definiciones de los grupos y la adición y borrado de los mismos de un grupo.
  • User-visible applicacion data: Este componente da acceso al usuario a los datos de la aplicación.

Conclusiones

Como hemos visto los esfuerzos por incluir la usabilidad cada vez en etapas más tempranas del diseño del software es muy grande, e incluso ya hay algunos patrones estructurales que nos facilitan la labor, por lo que a partir de ahora deberíamos plantearnos usarlos en nuestros futuros desarrollos.