Modelo de Proceso de la Ingeniería de la Usabilidad y la Accesibilidad (MPIu+a)

MPIu+a es una metodología (o modelo) de desarrollo de sistemas interactivos que tiene como meta principal poner al usuario en el centro del desarrollo, buscando maximizar la usabilidad y la experiencia de usuario del sistema final, así como que sea totalmente accesible.

Características del modelo MPIu+a

MPIu+a es un modelo (o metodología) de desarrollo de sistemas interactivos que sigue los principios del Diseño Centrado en el Usuario cuyas principales características son:

Organización conceptual

Como ya se ha mencionado con anterioridad, una de las metas más importantes de este modelo de proceso es conseguir «casar» el modelo de desarrollo de sistemas interactivos de la Ingeniería del Software con los principios básicos de la Ingeniería de la Usabilidad y los de la accesibilidad proporcionando una metodología que sea capaz de guiar a los equipos de desarrollo durante el proceso de implementación de un determinado sistema interactivo.

Tres pilares básicos

El esquema está organizado en base a una serie de módulos o etapas que determinan la fase de desarrollo en la que nos encontramos y ubica en un nodo concreto la actividad del conocimiento existente en IPO. Esto, en definitiva, no hace más que «poner cada cosa en su sitio», dotando de las pautas a seguir durante el diseño de un sistema interactivo.

En la Ingeniería de la Usabilidad y en la IPO, en general, hay dos conceptos muy importantes que deben realizarse de manera sistemática desde el inicio del desarrollo y no pueden cesar hasta la finalización del sistema: El prototipado y la evaluación.

El esquema refleja muy claramente, con una codificación en colores, estos tres conceptos a modo de tres pilares básicos:

La Ingeniería del Software, en el formato «clásico» de ciclo de vida en cascada iterativo o evolutivo (columna de la izquierda de color azul).
El prototipado (columna central de color verde), como metodología que engloba técnicas que permitirán la posterior fase de evaluación.
La evaluación (columna de la derecha, de color amarillo) que engloba y categoriza a los métodos de evaluación existentes.

El usuario

Si alguien tiene la potestad de calificar algo como «user friendly» este es únicamente el supuesto «user» o usuario, que es la persona que interacciona con el sistema.

En los modelos de desarrollo actuales los diseñadores y/o los programadores deciden por los usuarios, escogiendo las metáforas, organizando la información y los enlaces, eligiendo las opciones de los menús, etc. Dichas personas incluso, etiquetan sus aplicaciones como amigables al usuario (con el famoso «user friendly») a pesar de que ningún usuario real haya dado su aprobación a tal característica.

Un proceso de Diseño Centrado en el Usuario debe dejar claro de que es así sólo con mirar el esquema la primera vez. Esto es lo que queda reflejado al disponer a éste en la parte central y por encima del resto de etapas todo el modelo de proceso.

Otro aspecto determinante en este modelo de proceso es que se da mucha importancia no sólo a los usuarios, sino también a los implicados (o stakeholders) en cuanto a que son personas que sin ser usuarios directos del sistema su actividad se ve afectada por el mismo. Queda claro, pues, que el usuario está en el centro del desarrollo y en las facetas en las que interviene.

Un Método Iterativo

Establecer procesos repetitivos es un aspecto natural que se da en cualquier otro ámbito de ingeniería, sea de la disciplina que sea.

Por poner un ejemplo de otra disciplina, en el mundo de la edificación existe incluso antes de empezar con la excavación del terreno una serie de reuniones (iteraciones) arquitecto-cliente (desarrollador-usuario) para conseguir que el diseño del futuro edificio se adapte a las necesidades de sus inquilinos.

Dicho proceso de repetición aplicado a la Ingeniería del Software también existe, aunque suele producirse en la fase final del proceso.

Volvamos al ejemplo anterior. ¿Qué pasaría si las reuniones entre el cliente y el arquitecto se realizasen una vez que la estructura del edificio ya estuviese levantada?. ¿Podría, por ejemplo, cambiar la posición o el tamaño de una ventana? o incluso ¿podría abrirse una nueva ventana en una pared maestra?…. Y si ello fuese técnicamente posible ¿cuál sería su coste?.

El esquema propuesto dispone de una serie de flechas cuyo objetivo no es otro que visualizar que desde todas las fases se promueve la participación activa de los usuarios, tanto en el análisis de requisitos como en el diseño y en la realización de prototipos y/o su posterior evaluación.

Pueden observarse dos tipos de flechas, unas delgadas que se corresponden con el modelo de la IS, y otras más gruesas que convierten la IS en un verdadero modelo centrado en el usuario. Éstas últimas indican, entre otras cosas, donde interviene el usuario.

Sencillez

Mayoritariamente los desarrolladores de sistemas interactivos que pretendemos que la usabilidad sea un factor determinante de los mismos estamos de acuerdo en que sus interfaces, sin perder su capacidad comunicativa y funcional, tienen que ser cuanto más sencillas y simples mejor.

Y si estamos de acuerdo con la premisa anterior estaremos igualmente de acuerdo con la idea de que la metodología que les permita llevar a cabo su trabajo de manera más eficiente sea también muy sencilla y simple.

El esquema aquí presentado nace con esta idea como trasfondo para todo el equipo de desarrollo: Es escueto, con pocos nodos y ramificaciones y sin caminos condicionales que dificultan su comprensión.

Las diferentes representaciones del sistema (diseño…) deben ser comprensibles, tanto por todos los componentes de los equipos (multidisciplinares) de desarrollo como por los usuarios y cualquier implicado que esté involucrado en el sistema, que sólo será posible construyendo dichas representaciones lo más simples posibles.

Adaptado al modelo mental de los equipos multidisciplinares

El constante contacto con personas procedentes de áreas de conocimiento tan diversas como los componentes del grupo de investigación GRIHO ha servido para constatar la tan referenciada necesidad y a la vez la valiosa aportación que supone trabajar con estos equipos multidisciplinares.

Entre otros aspectos, experimentalmente hemos comprobado que los modelos mentales de las diferentes personas distan mucho entre ellos, hecho que supone que surgen más dificultades de las previstas si los mecanismos de comunicación no son eficientes y las herramientas formales de modelado no son suficientemente simples.

Respecto a éstos, se ha constatado que utilizar métodos descriptivos en lenguaje natural junto con herramientas de uso habitual (aspectos comprensibles por todos los miembros del equipo) facilita el proceso comunicativo entre las personas que intervienen en el desarrollo.

Disponer, por otra parte, de un equipo de desarrollo formado por gente tan diversa no significa que todos ellos estén presentes en todas las fases del proyecto. Ni siquiera es preciso que todos tengan una visión completa de la evolución del desarrollo, lo que sí que es necesario es que cada uno tenga la visión necesaria y precisa del sistema desde su punto de vista y concerniente a su participación durante el proceso de desarrollo.

Anteriormente se han argumentado las razones por la que es necesaria la participación de cada una de las diferentes disciplinas durante el proceso de desarrollo de sistemas interactivos y la participación de cada disciplina en el proceso de desarrollo software. La siguiente figura refleja, de forma esquematizada, en un cuadro bidimensional que ubica gráficamente la relación disciplina-fase MPIu+a, dicha participación:

Finalmente, no podemos olvidar que tanto los usuarios como los implicados en el sistema forman parte de este conglomerado pluridisciplinar y consecuentemente el modelo es también comprensible para ellos.

Flexibilidad

Debe destacarse también que el modelo no tiene ni un sentido lineal ni restrictivo, sino que fomenta la libre aplicación del mismo: Será el equipo de desarrollo (representados normalmente por el responsable del proyecto en desarrollos de envergadura considerable o el diseñador o programador más experimentado en desarrollos menores) junto con los propios requisitos del sistema, las particularidades de los usuarios y los resultados de las diferentes evaluaciones quien marcará cuantas iteraciones deben realizarse, como deben hacerse y el flujo de las acciones a realizar en cada iteración.