Cuando hablamos de la interfaz de usuario lo hacemos en términos de su "presentación y interacción" ("look and feel"). La presentación (look) comprende la disposición de los elementos de la interfaz (gráficos y texto en la pantalla, botones en un mando a distancia...), mientras que la interacción (feel) hace referencia al procesamiento y a su rendimiento.
En palabras de C. SNYDER en [SNY03], look son pixels y feel es código, y la producción de ambos requiere cierto esfuerzo que varía dependiendo del método de prototipado utilizado. Esta reflexión hace referencia a las interfaces visuales (mayoritarias actualmente) y no a las interfaces multimodales.
Encontramos, pues, que el prototipado comprende dos procesos diferenciados:
- Uno es la presentación. Partiendo de entender el propósito de la interfaz a desarrollar se activa un proceso de pensar en cómo vamos a mostrar este propósito a nuestros usuarios para posteriormente trasladar estos pensamientos en elementos visibles para los ellos.
- Y otro es la interacción, necesaria para que la presentación presente la componente interactiva y así el prototipo muestre sus posibilidades.
En función de la técnica de prototipado escogida, el peso de cada uno de estos procesos será muy distinto, afectando, por tanto, al tiempo de desarrollo y en consecuencia al coste del sistema.
Como ya se ha remarcado, el prototipado constituye uno de los tres pilares básicos del modelo de proceso, constituyendo casi siempre el enlace natural que permite la constante evaluación del desarrollo de la interfaz del usuario y, en general, de todo el sistema.
A continuación, se enumeran las diferentes técnicas de prototipado propuestas como actividades del MPIu+a durante la implementación de un sistema interactivo que queremos construir con elevados niveles de usabilidad y de accesibilidad.
- Bocetos (esbozos)
- Storyboards
- Prototipos de papel
- Maquetas
- Maquetas digitales
- Storyboard navegacional
- Vídeos
- Escenarios
- Prototipos software
Los bocetos son maneras de representar "primeras ideas", ya sea sobre lo que se pretende representar, sobre alguna funcionalidad concreta o sobre qué metáforas se utilizarán. Se usan en la etapa más inicial del diseño, a menudo antes incluso de determinar muchos aspectos del análisis de requisitos, con la finalidad de recoger las primeras impresiones del espacio de trabajo de la interacción.
La clave de los bocetos es su velocidad de producción: Un boceto se realiza en unos 15 ó 20 segundos, de manera que se pueden generar gran cantidad de bocetos en muy poco tiempo. Se trata sólo de una recogida de ideas iniciales.
La técnica del storyboarding tiene sus orígenes en la industria cinematográfica y básicamente consiste en una serie de dibujos o imágenes dispuestos en formato secuencial de viñetas (o storyboards) que, aplicada al diseño de sistemas interactivos, representan cómo un determinado sistema será usado durante la consecución de una determinada tarea. Muestran la evolución de la situación del usuario y su entorno mientras está interactuando con el sistema.
El ejemplo cotidiano que rápidamente nos permite entender de qué trata un storyboard son las historietas de los cómics que todos en alguna ocasión habremos leído.
En [DIX93] se indica que esta técnica es la noción más simple de lo que se entiende por un prototipo, tanto es así que incluso algún autor, como A. SUTCLIFFE en [SUT02], no la clasifica como tal, sino que la considera más una técnica de captura inicial de requisitos del sistema que un prototipo del mismo. Sin embargo, otros autores [PRE02] clasifican el storyboarding como una técnica de prototipaje de baja fidelidad.
A pesar de ello, hemos clasificado el storyboarding como una técnica de prototipado porque realmente se implementa un documento gráfico que sirve para entender partes del sistema, sirve para evaluar aspectos del mismo con usuarios e implicados y sirve, además, en varias etapas del modelo de proceso.
Con esta técnica se pretende crear diferentes vistas del sistema en las primeras etapas de su implementación de la manera más rápida y barata posible [SUT02], empleando para su producción medios tan económicos como son el lápiz y el papel o, si queremos hacerlo un poco más sofisticado, hacer uso de las potentes herramientas de edición gráficas de las que actualmente disponemos.
Los storyboards resultan especialmente indicados para aquellos proyectos en los que la implantación del nuevo sistema cambiará la forma de trabajar o de realizar ciertas tareas de las personas afectadas por él. Con ellos representaremos de una manera gráfica, eficiente e informal la situación actual de un determinado contexto, que será "modificado" con la implantación de un nuevo sistema interactivo, y la situación futura que describa cómo cambiará la realización de las tareas tras la implantación del nuevo sistema. Así, con una representación actual y una futura se favorece la comprensión por parte de todos los miembros del equipo del sistema a desarrollar.
Para lo que no es adecuado realizar un storyboard es para comprobar aspectos referentes a la interactividad del sistema, aunque sí que será útil como material de soporte, tanto para asegurarse que el diseñador ha comprendido el problema como para discutir detalles con los usuarios, implicados y responsables del proyecto acerca de su funcionamiento.
Las siguientes figuras muestran dos ejemplos correspondientes a algunos de los casos implementados en los que podemos ver unos storyboards realizados para representar la situación actual (tal como se está realizando actualmente una determinada acción) y la futura (cómo será tras la implementación del nuevo sistema):
Esta técnica de prototipado de baja fidelidad se basa en la utilización de materiales tan básicos como lápiz, el papel y las tijeras para la creación de prototipos simples pero enormemente versátiles.
Este sistema permite una gran velocidad y flexibilidad en el momento de hacer los prototipos, a la vez que al requerir materiales tan básicos se trata de una técnica "muy económica".
El objetivo de un prototipo de papel no es probar o verificar lo bonito que es el diseño, sino que se trata de verificar si los usuarios son capaces de realizar sus tareas con la interfaz propuesta. La utilización de esta técnica de prototipado no precisa incorporar avances tecnológicos; sólo es necesario que capture la funcionalidad del sistema y que comunique la información y sus interacciones adecuadamente.
Esta técnica de prototipado consiste en dibujar en un papel, sin entrar en grandes detalles estéticos, las interfaces que se van a probar y valorar. Los diferentes estados de la interfaz se van dibujando en hojas separadas y mediante un proceso de ordenación que el diseñador determina permite que el usuario final interactúe con este material simulando el funcionamiento del sistema.
Por ejemplo, supongamos que tratamos de simular el comportamiento de una funcionalidad concreta de una aplicación que se ejecuta en un PDA; los prototipos de papel serán las diferentes representaciones de las pantallas -de tamaño lo más real posible- que el usuario se encontraría como resultado de las diferentes interacciones que produciría.
Al realizar un prototipo de papel no debemos olvidar que de lo que se trata es de reflejar aquellos aspectos de la interfaz del usuario referidos a las interacciones que el sistema le proporciona. Esto indica un prototipo de papel que deberá mostrar dos aspectos muy importantes: Uno es la presentación que hace referencia a qué elementos proporciona dicha interfaz para la interacción y el otro es la navegación en forma de información complementaria con diseño claramente perceptible que facilite la movilidad durante la fase de evaluación del prototipo. La siguiente figura, además de proporcionar otro ejemplo ilustrativo de esta técnica de prototipado, muestra unas pestañas numeradas y recortadas en la parte inferior del papel que agiliza la interacción entre las diferentes pantallas haciendo "más real" la realimentación que recibe el usuario. Estas pestañas dan el soporte necesario a la navegación que hacíamos referencia anteriormente.
En el grupo de investigación GRIHO esta técnica ha sido probada en todos los proyectos referenciados con enorme éxito y aceptación por parte tanto de los integrantes del grupo como por parte de los usuarios que han "probado" el prototipo: El beneficio obtenido comparado con la cantidad y calidad de la información recogida y con el esfuerzo necesario para realizarlo es muy alto.
En el proyecto de la aplicación para los comerciales de la empresa de prefabricados se utilizó un prototipo de papel del sistema para realizar la primera sesión de evaluación con usuarios (más adelante veremos las diferentes técnicas de evaluación) y al finalizar la prueba uno de los usuarios exclamó: "¡Por fin un informático me enseña algo que entiendo!!!". Anécdota que describe por si sola una ventaja importante de esta técnica: la desinhibición del usuario.
Ventajas del prototipado de papel.
- Los problemas (funcionales y de usabilidad) se pueden descubrir en una etapa muy temprana del proceso de diseño, mucho antes de haberlos codificado.
- Favorece la comunicación entre el equipo de diseño-desarrollo, los usuarios y los implicados.
- Favorece tembién la participación de todos los miembros de los equipos multidisciplinarios proporcionando un soporte comunicativo entre las diferentes disciplinas.
- Son muy rápidos de construir y refinar, lo que permite realizar rá interacciones de diseño.
- Los recursos consumidos son mínimos (materiales muy básicos) y económicos.
- Psicológicamente es beneficioso para los usuarios.
- Resulta tan familiar para los usuarios que sin dudarlo intervenien en las modificaciones del diseño.
- El usuario, que es consciente de la facilidad y el bajo coste de prototipo, no se siente cohibido de proponer cualquier cambio.
- Resulta menos intimidante que un ordenador (ayuda a superar el fenómeno conocido como tecnofobia).
- El tiempo dedicado al proceso de codificación es cero.
- No están sujetos a restricciones impuestas por la tecnología -arquitectura del sistema, la base de datos, el ancho de banda, el sistema operativo-, y a pesar de ello ayuda al equipo a anticipar problemas y decisiones derivadas de la tecnología.
- Puede servir como herramienta de marketing y para demostraciones de ventas.
Inconvenientes de los prototipos de papel.
- Por su simplicidad, los prototipos de papel no sirven para realizar evaluaciones detalladas del diseño.
- No puede simular la respuesta del sistema.
- En el momento de evaluarlo es fáil que se den por supuestas cosas que realmente no están en el prototipo.
- No hay un consenso sobre cuál debe ser el nivel de detalle que el prototipo debe implementar ni de la calidad gráfica o de expresividad.
- La construcción de los prototipos de papel parece tan evidente que a menudo se menosprecian aspectos tan importantes como que el prototipo se asemeje al máximo en tamaño y forma al dispositivo para el que estamos realizando -cuanto más realista resulte el prototipo mejor será la realimentación de los usuarios- el prototipo, que suele llevar a rediseños posteriores que inutilizan los ya realizados.
Relacionado con el último inconveniente mencionado, cabe mencionar que si estamos realizando, por ejemplo, un prototipo de papel para simular el funcionamiento de un sistema que se ejecutará utilizando un PDA los prototipos deben implementarse acorde al tamaño real de dicho dispositivo.
En la introducción de [SNY03] J. NIELSEN destaca que el prototipo de papel tiene además otra ventaja habitualmente no mencionada:
"...considere usted todos los libros que ha leído sobre tecnología y ordenadores, diseño web, ¿Cuántas cosas de ellos seguirán siendo válidas dentro de 10 años? ¿y de 20? ... todo lo que aprenda sobre el prototipado de papel podrá utilizarlo en todos los proyectos durante el resto de su carrera".
Utilidad de los prototipos de papel.
Los dos gráficos de la figura c5_8 nos servirán para constatar la utilidad de una técnica tan simple y tan familiar para realizar prototipos de sistemas software. Estos gráficos muestran el resultado de varios profesionales desarrolladores interesados por la usabilidad de los sistemas software a quienes se les planteó (entre otras) la siguiente pregunta: ¿Cuál es el grado de importancia del prototipado de papel en tu trabajo diario?.
El gráfico de la izquierda corresponde a una encuesta que mediante el correo-e personalmente realicé durante el verano de 2003 y que fue contestada por 87 profesionales de diversas disciplinas y ámbitos relacionadas con el desarrollo de software. El de la derecha corresponde a una encuesta realizada en julio de 2002 a 172 profesionales de usabilidad que podemos encontrar en [SNY03].
En ambos casos podemos ver que más del 80% de los profesionales entrevistados encuentran esta técnica útil para su trabajo, muchos de ellos incluso la consideran absolutamente esencial.
Habitualmente cuando hablamos de maquetas nos referimos a modelos en tamaño reducido de un algún objeto, monumento, edificio, etc. En el caso de herramienta o técnica para realizar el prototipado de una parte del sistema solemos referirnos a maquetas como objetos construidos (normalmente a partir de materiales muy básicos) para que sirvan de herramienta con el fin de evaluar una parte física del sistema.
Esta técnica suele ser útil cuando queremos reflejar como será un dispositivo en un momento en el que éste aún no existe (sólo está en la mente de algunos desarrolladores, se sabe que aparecerá pero aun no está disponible, etc.).
Las maquetas constituyen un material de soporte enormemente útil para complementar otras técnicas de prototipado y también para realizar evaluaciones.
En el proyecto de Els Vilars se pretende ofrecer al visitante la posibilidad de realizar una visita utilizando el paradigma de la Realidad Aumentada. Para ello se pensó en un dispositivo móvil parecido a un ordenador portátil en forma y tamaño con la versatilidad de los actuales PDA pero con otras características. Era el dispositivo conocido como tabletPC que actualmente ya se encuentra disponible comercialmente. Para poder simular este dispositivo se realizó con madera y papel una tableta a la que se llegó tras varias iteraciones de prototipos de papel. La siguiente c5_9 muestra algunos de estos prototipos de papel y la maqueta del dispositivo.
Las maquetas digitales son representaciones de calidad en formato digital que normalmente llenan el espacio que hay entre el prototipo de papel y la versión definitiva de una interfaz o parte de ella.
Para realizar una maqueta digital ya no son suficientes los materiales básicos, sino que ya es necesario utilizar herramientas más sofisticadas (editores gráficos...) que precisan de mayor tiempo de desarrollo y mejor preparación de las personas que los realizan. Por el contrario, el mayor nivel de detalle de las maquetas digitales permite visualizar de una manera muy aproximada a la versión final el diseño de la interfaz (colores, estructura de navegación, botones, etc.).
Las maquetas realizadas con papel y lápiz se perciben como herramientas poco detalladas en las que priman más los aspectos conceptuales, mientras que usuarios e implicados ven las maquetas digitales como versiones finales que no se pueden cambiar, por lo que es más adecuado utilizarlas en la fase de diseño.
Un storyboard navegacional (o de uso) es una técnica diferente del storyboard visto anteriormente que consiste en desarrollar una serie de dibujos o imágenes que representan el espacio de navegación, bien sea de todo el sistema, de una parte de él o de una tarea concreta.
Esta técnica es una aportación propia al campo de las técnicas de prototipado que constituye el resultado de conjuntar algunas de las mejores características de varias de las técnicas ya conocidas. El nombre de Storyboard Navegacional proviene del hecho que la representación se realiza por medio de entidades (dibujos o imágenes) que pueden asociarse a una serie de viñetas o storyboards con las que se representa el espacio de navegación.
Con esta técnica se representan en un espacio bidireccional (con papel, en una pizarra, con impresiones de pantalla y flechas con rotulador, etc.) todos los estados de las interfaces (pantallas...) de la parte del sistema que se examinará y todas las posibilidades a nivel interactivo desde cada uno de estos estados para visualizar las posibles acciones o movimientos que el usuario puede realizar mientras interacciona con la interfaz.
Es importante no confundir los estados de las interfaces con los estados del sistema. Las primeras representan las diferentes posibilidades que la interfaz ofrece al usuario, mientras que la segunda hace lo propio con el funcionamiento interno del sistema (aspecto que será tratado en la fase de diseño del sistema en el modelo MPIu+a).
Esta técnica permite comprender el flujo del trabajo de los usuarios, así como el soporte que la interfaz ofrece al usuario en cada paso de la interacción durante la consecución de las diferentes tareas.
Los Storyboards Navegacionales pueden implementarse tanto a partir de secuencias realizadas con prototipos de papel como si éstas son maquetas digitales. Lo que cambiará será la definición y el nivel de detalle, así como el tiempo necesario para su materialización, repercutiendo principalmente en la percepción que el usuario observará.
Rodar o grabar un vídeo permite desarrollar escenas que, gracias al uso de técnicas de preproducción y postproducción, pueden hacer que parezcan reales funcionalidades y sistemas que sólo son ideas, que están en fase muy inicial o que son imposibles de realizar (tecnología inexistente, lugares inalcanzables).
Los prototipos basados en vídeos ofrecen una manera económica de visualizar partes de los sistemas futuros. Aun así, suelen fallar cuando intentan comunicar el sentido global de una nueva experiencia para el usuario, bien sea porque el hardware necesario para el nuevo sistema todavía no existe o porque sea difícil de crear un prototipo fluido e interactivo de un sistema grande [NIE89][NIE93].
El prototipo en vídeo puede ser muy útil en el diseño de interfaces multimodales en el que la interacción se produce mediante más de un canal sensorial o en el diseño de escenarios futuros de los que todavía no se dispone de la tecnología necesaria. Una de las mayores ventajas del vídeo es que permite eliminar todas las limitaciones y restricciones de los dispositivos físicos del mundo real [ROS02, pág. 203].
Un ejemplo interesante, y clásico, del prototipado en vídeo lo constituye el vídeo STARFIRE. A Vision of Future Computing rodado por el equipo de SunSoft (Sun Microsystems) el año 1994, en el que B. TOGNAZZINI reproduce una "visión creíble a diez años vista" acerca de cómo podría interactuarse tecnológicamente en una oficina de una compañía. TOGNAZZINI escogió una product manager, Julie, de una compañía de automóviles que se vio rápidamente sorprendida con la necesidad de realizar una presentación multimedia para una reunión de emergencia con sus superiores [TOG94].
Una película o un vídeo permiten construir la demostración definitiva de un nuevo sistema. No existen limitaciones ni por parte del hardware ni del software. Todo funciona perfectamente sin importar cuantas veces se mira la grabación, y los mensajes pueden conducir al usuario a las conclusiones que el productor tiene en su mente. Ambas características son dos de las ventajas e inconvenientes que el prototipaje en vídeo ofrece [TOG94].
En nuestros proyectos hemos utilizado esta técnica para el caso de la visita al yacimiento arqueológico utilizando la realidad aumentada y en el caso de un nuevo entorno de computación ubicua en el Montsec.
Para el caso del yacimiento arqueológico utilizando la Realidad Aumentada para poder evaluar cómo debería implementarse el sistema o cómo reaccionarían los visitantes ante el nuevo concepto de visita se realizó un prototipo en vídeo del que provienen las siguientes imágenes:
Este prototipo en vídeo realmente constituye una combinación de varias técnicas de prototipado, puesto que para la realización del mismo previamente se ha definido un escenario (que refleje una situación posible del futuro sistema) y su posterior storyboard.
Ventajas de los vídeos.
- Se pueden descubrir problemas de usabilidad en una etapa muy temprana del proceso de diseño.
- Proporciona una simulación dinámica de los elementos de la interfaz que se pueden ver y comentar tanto por el equipo de desarrollo como por los usuarios.
- Aunque parezca lo contrario, no son necesarios muchos recursos.
Inconvenientes de los vídeos.
- Requiere de personal familiarizado con la funcionalidad del sistema que se va a crear para crear el prototipo de vídeo.
- El método en realidad no captura a un usuario interactuando recíprocamente con el prototipo, careciendo del elemento interactivo de otros métodos.
- Al emplear materiales simples y carecer de interactividad, los prototipos de vídeo no apoyan la evaluación de detalle de diseño fino.
- Esta técnica permit tantas opciones y pertenece a un campo tan actual que induce a caer en un grave error. Desperdiciar mucho tiempo en conseguir un vídeo "esteticamente bonito" dejando a menudo detalles importantes para el verdadero propósito del vídeo.
Trabajar con ordenadores y sistemas interactivos en general es algo más que funcionalidades, inapelablemente reestructuran actividades humanas, creando nuevas posibilidades, al mismo tiempo que dificultades. Por otra parte, en cada contexto en el que el ser humano tiene experiencia y actúa proporciona unas restricciones para el desarrollo de sistemas de información.
En el momento en que tengamos que analizar y diseñar software, necesitamos una manera de ver cómo estos nuevos sistemas pueden transformar y restringir los contextos actuales de la actividad humana.
Una aproximación directa es imaginando y documentando las actividades típicas y significativas. Una manera de hacerlo es describiendo las actividades que se realizan durante el proceso de desarrollo, y los escenarios son una forma apropiada de presentar estas descripciones.
Los escenarios, en cuanto a una forma de reflejar las historias sobre personas y sus actividades [CAR00] destacan:
- Los objetivos sugeridos por la apariencia y comportamiento del sistema.
- Qué es lo que las personas quieren hacer con el sistema.
- Qué procedimientos se usan, cuáles no se usan.
- Cuáles se realizan o no satisfactoriamente.
- Qué interpretaciones hacen las personas de lo que les sucede.
Esta técnica sirve tanto para contar la manera como se realizan las acciones actualmente como para hacer imaginaciones de futuro. Lo importante en ambos casos es que el escenario contenga la mayoría (si no la totalidad) de los aspectos que directa o indirectamente intervienen durante el proceso interactivo, destacando aquellos que son claves para que su consecución futura sea posible.
Una reflexión de Peter SCHWARTZ acerca de los escenarios que merece tener en cuenta: Un escenario no es una predicción, simplemente no es posible predecir el futuro con certeza. Un viejo proverbio árabe dice que quién predice el futuro miente, incluso si cuenta la verdad. Deberemos entender los escenarios, por tanto, como vehículos para ayudar a las personas a aprender [SCH96].
Ventajas de la técnica de los escenarios.
- Las descripciones de gente utilizando tecnología representadas en forma de escenarios son exenciales a la hora de discutir y analizar cómo la tecnología remodelada (o puede remodelar) las actividades de los usuarios.
- Las descripciones de los escenarios pueden ser creadas antes de que el sistema sea construido y permiten, por tanto, "sentir" el impacto resultante.
Inconvnientes de la técnica de los escenarios.
- Un escenario, o un conjunto de éstos, no guí explicitamente al diseñador hacia el modelo correcto del sistema a implementar. Un escenario "extremo" puede tender a razonamientos raros o excepcionales o a incidir sobre aspectos relacionados con implicados poco representativos. Esta tendencia es una reconocida "debilidad" de los escenarios [SUT03a]
Características de los escenarios.
- Configuración (setting)
- Definición:
- Detalles de situación que motivan o explican objetivos, acciones y reacciones del/los actor/es
- Sitúa la acción
- Ejemplo:
- Oficina dentro de una organización de la contabilidad, estado del área de trabajo, de las herramientas, etc., al comienzo de la narración.
- Definición:
- Actores
- Definicion:
- Persona/s interactuando con los dispositivos interactivos o cualquier otro elemento descrito en la configuración
- Ejemplo:
- Un contable utilizando una hoja de cálculo por primera vez.
- Definicion:
- Objetivos
- Definición:
- Efectos en la situación que motivan acciones llevadas a cabo por actores.
- Ejemplo:
- Necesidad de comparar las ofertas de un determinado presupuesto.
- Definición:
- Planes
- Definición:
- Actividad mental dirigida a convertir una meta en un comportamiento.
- Ejemplos:
- Abrir el documento darà acceso a la información del presupuesto; redimensionando la ventana dejará espacio libre para abrir otro presupuesto.
- Definición:
- Evaluación
- Definición
- Actividad mental dirigida a interpretar las características de la stiuación.
- Ejemplo:
- Una ventana que es demasiado grande puede ocultar la que está debajo; losbordes oscuros indican que una ventan está activa.
- Definición
- Accions
- Definición
- Describe el comportamiento observable (el diagram de secuencias)
- Ejemplo:
- Abriendo un documento;redimensionando y moviendo ventanas.
- Definición
- Eventos:
- Definición
- Acciones externas o reacciones producidas por el sistema interactivo u otras características descritas en la configuración; algunas pueden ser importantes para el escenario pero ser ocultas a los actores.
- Ejemplo:
- La realimentación (feedback) de la selección de una ventana; la realimentación auditiva del teclado y/o el ratón; apariencia actualizada de las ventanas.
- Definición
Utilidad de los escenarios según la fase del ciclo de vida.
Los escenarios tienen varios roles en el proceso de diseño. Estimulan, por una parte, la imaginación creativa de los diseñadores, mientras que por otra proporcionan herramientas ágiles que dan soporte al razonamiento del sistema en el proceso de diseño [CAR00]. Otro rol asociado a los escenarios es el de escenificar problemas existentes, ayudan enormemente a la comprensión de los mismos a la hora que dejan entrever posibles vías de solución.
El uso de los escenarios supone un punto de partida idóneo para casi todas las fases del ciclo de vida. Así pues los escenarios pueden constituir:
- Ejemplos para el uso del sistema durante la fase de requisitos.
Podremos desarrollar tanto "escenarios imaginativos" a partir de la inspiración para la consecución de nuevas o mejores soluciones o simplemente para simular el funcionamiento de una nueva situación [BAL01] comenzando con la situación actual del sistema a modelar.
También son apropiados para esta fase los escenarios que reflejan problemas pendientes de solucionar. Se logra transmitir la concepción del análisis contextual realizado en esta fase (debiéndose evaluar posteriormente para verificar que la concepción de la escenificación se adapta a la realidad).
- Canales de entrada y modelos de generalización durante la fase de diseño.
Éstos proporcionan cantidades suficientes de información para la implementación formal del modelo conceptual del sistema.
- Una fuente de inspiración y de motivación para la resolución y/o mejora de soluciones existentes en fase de mantenimiento de sistemas interactivos.
El uso de los escenarios puede resultar tan útil que incluso algún modelo de la Ingeniería de la Usabilidad como el de ROSSON y CARROLL [ROS02a] del que ya se ha hablado en el Capítulo 2 (concretamente en el punto 2.1.1.4), basa toda su metodología en el uso de esta técnica.
Maneras de representar los escenarios.
Un escenario entendido como se ha explicado puede representarse de muchas maneras diferentes. Podemos incluso ver que alguna de las técnicas aquí expuestas sólo son maneras de representar los escenarios. Veamos las formas más habituales de representación de escenarios:
- Lenguaje natural:
Las descripciones en lenguaje natural se realizan, como su nombre indica, mediante una narración escrita de la situación que queremos reflejar. Este tipo de narraciones suelen ser las que mejor sirven para producir rápidamente escenarios que pueden ser probados por usuarios. El principal problema es en la forma de describir la situación. Ya vimos que el uso del lenguaje natural puede dar lugar a interpretaciones erróneas [SUT02] o a descripciones demasiado largas que requieren un esfuerzo excesivo por parte de los usuarios.
- Mediante Storyboards:
La previamente comentada técnica del Storyboarding resulta altamente útil para describir escenarios de situaciones concretas que ayuden a entender partes del sistema. Con los storyboards se consigue dotar al escenario descrito en lenguaje natural de la componente gráfica que facilita la comprensión y el detalle.
Las dos figuras siguientes (figura c5_16a y figura c5_16b) muestran el ejemplo de un storyboard que representa un escenario de situación para explicar el cambio que sufrirá el trabajo de los vendedores de la empresa de prefabricados con la incorporación de las nuevas tecnologías. El primero reproduce una situación típica tal y como se realiza actualmente y el segundo tal y como lo hará tras la implantación del nuevo sistema.
- Escenarios en vídeos:
Los vídeos grabados para describir situaciones o escenarios son, sin ninguna duda, la mejor técnica de la que disponemos para representar las situaciones que deseamos describir. Por su parte, también son los que cuestan más dinero, requieren de personas más especializadas, equipos más sofisticados y más tiempo de desarrollo.
En el proyecto de la visita al yacimiento arqueológico se utilizó esta técnica para poder investigar y mostrar a personas externas al grupo de investigación la idea de la propuesta.
- Diagramas de Casos de Uso de UML:
La técnica de los Casos de Uso fue inicialmente pensada para la especificación de requisitos funcionales de sistemas interactivos [JAC93] y actualmente forma parte de los diagramas UML [BOO99] utilizados en la Ingeniería del Software.
De forma resumida, estos diagramas tienen una representación gráfica en los denominados Diagramas de Casos de Uso en los que los actores son representados por símbolos que esquemáticamente tienen forma humana y los casos de uso por elipses. Unas flechas entre el actor y el caso de uso simbolizan la participación de los primeros en los segundos.
Los casos de uso describen escenarios de uso del sistema a partir de secuencias de interacciones entre el sistema y uno o más actores, que obtienen los resultados observables del sistema (considerado como una caja negra). En esta notación los actores representan tanto a personas como a otros sistemas que interactúan con el sistema que se está describiendo [SCH98].
Adeptos de esta notación defienden que al tratarse de una notación formal no hay lugar para las interpretaciones ambiguas, lo que resulta beneficioso para su propósito.
Este tipo de diagramas mayoritariamente son aceptados por los componentes de los equipos de desarrollo que provienen de la IS, que defienden que son fácilmente comprensibles, tanto por clientes y usuarios, sirviendo además de base para las pruebas del sistema y para la documentación de los usuarios [DUR02].
De todas maneras, también es cierto que este tipo de diagramas son escogidos en último lugar por la mayoría de los integrantes de otras disciplinas cuando se les ha dejado escoger entre los diferentes tipos de representación.
Problemática entre los escenarios y los modelos.
Las notaciones abstractas como es el caso de las representaciones de los casos de uso de UML no son suficientes para proporcionar a los usuarios y a los implicados el conocimiento concreto de la situación que representan [GUL03].
El uso de los escenarios constituye una técnica de probada efectividad tanto para la IS como para la IPO. Sin embargo ambas disciplinas difieren en sus preferencias a la hora de describir dichos escenarios: Descripciones expresadas en lenguaje natural habitualmente en IPO se contraponen a representaciones formales en forma de modelos (por ejemplo los diagramas de casos de uso de UML) en la IS [KAI95], aspecto que produce cierta "tensión" entre los seguidores "puros" de cada una de las disciplinas.
Los modelos de diseño basados en modelos pueden ser acusados de representar una visión reducida de la acción, mientras que las descripciones narrativas aportan una representación más amplia, con más detalle, pero lo hacen de manera más informal, dejando lugar a interpretaciones libres por parte del diseñador [SUT03a].
A pesar de ello, estas últimas consiguen integrar de manera más eficiente los integrantes de los equipos pluridisciplinarios necesarios para realizar el DCU, mientras que las primeras son sólo interpretables por los ingenieros software.
A. SUTCLIFFE [SUT03a] recomienda una Xcombinación de ambas representaciones aprovechando las ventajas de cada una de ellas. Menciona como una de las principales razones de esta conclusión el hecho de que una vez analizados y aprendidos los esquemas mentales de la cognición humana (recordemos el punto 3.6 acerca del factor humano) se observa que los modelos vienen a representar esquemas de la memoria que representan conceptos abstractos extraídos de la experiencia diaria, así que su efectividad dependerá de lo bien conectados que estén los esquemas que representan esta memoria especializada con el conocimiento representado por los escenarios: Los modelos necesitan integrar ejemplos -descripciones en lenguaje natural- para ser comprendidos.
Aplicando estas técnicas repetidamente en todos los casos reales mencionados llegamos a la misma conclusión mencionada por A. SUTCLIFFE en el párrafo anterior. Las figuras siguientes muestran la idea de este concepto y su aplicación a dos de los casos desarrollados.
Comentarios de la ISO respecto a los escenarios.
La pág. 6 del estándar ISO 9126-1 [ISO01] se explica cuando al aplicar un modelo de calidad resulta prácticamente imposible definir (para después evaluar) todos los posibles escenarios de un sistema, y tendremos, por tanto, que definir aquel grupo de escenarios que mejor represente la globalidad del sistema.
En el anexo A del mismo documento se explica que la evaluación de los escenarios de tareas de los usuarios es la mejor manera de evaluar la calidad de uso del software; sin embargo, no especifica ningún método para realizar dicha evaluación. Por tanto, si en nuestro modelo de proceso utilizamos la técnica de los escenarios evaluándolos por una de los métodos propuestos por el mismo (ver apartado de evaluación) además de custodiar la usabilidad y la accesibilidad del sistema se estará garantizando la calidad en el uso de dicho sistema software.
Los prototipos de Software son implementaciones realizadas con técnicas de programación del sistema interactivo propuesto que reproducen el funcionamiento de una parte importante de las funcionalidades con el objetivo de probar determinados aspectos del sistema final. Habitualmente se realizan con el lenguaje o la técnica de programación escogida para desarrollar la aplicación, aunque pueden utilizarse otras alternativas.
No suele ser recomendable realizar un prototipo software en las etapas iniciales del ciclo de vida del desarrollo de un sistema (entre otras razones, porque en las etapas iniciales se necesitan prototipos de muy rápida implementación donde faltan aún muchos detalles) y su realización será en sentido "horizontal" o en sentido "vertical" en función del objetivo de la evaluación a realizar con el mismo (recordemos el apartado de dimensiones del prototipado vistos anteriormente en el punto 5.6.1.3).
Normalmente se implementa un prototipo software después de varias iteraciones de Prototipado-Evaluación y se tiene la intención de empezar a ver realmente cómo responde el sistema.
De todas formas, en los últimos años esta técnica de prototipado ha incrementado notablemente su popularidad debido en parte a la constante aparición de los entornos de programación rápida que permiten implementar pequeñas partes del sistema en poco tiempo o incluso a la utilización de herramientas inicialmente pensadas para otros fines como por ejemplo los editores de páginas web avanzados, la herramienta Flash de Macromedia para la creación de animaciones y gráficos vectoriales para uso en Internet o programas de creación de presentaciones como el Microsoft PowerPoint. Este tipo de programas permiten, además, combinar bocetos o prototipos de bajo nivel previamente implementados y, gracias a la facilidad de enlazar distintos elementos, fácil y rápidamente puede crearse un prototipo software.
El aspecto que sí que es necesario tener muy claro es cuál es el propósito de este tipo de prototipos. En primer lugar, debemos tener presente que lo que más nos interesa es probar los aspectos relacionados con la interacción del usuario con el sistema, no se trata, pues, de utilizar parte del desarrollo que se está realizando, sino que es una aplicación con la funcionalidad mínima necsaria para que el usuario pueda realizar las interacciones necesarias que permitan visionar el funcionamiento todavía ficticio del sistema resultante.
En la siguiente figura podemos observar una captura de las pantallas resultantes de realizar la tarea de identificación y comprobaciones básicas del sistema de recogida selectiva de basuras utilizando un PDA como dispositivo interactivo. Se trata de un prototipo en el que no hay aspectos de diseño en el sentido estético del mismo, sino que refleja aspectos interactivos con mucha sencillez.
Ventajas de los prototipos software.
- Habitualmente, la fidelidad o semejanza de un prototipo software con el sistema final es alta.
- Precisamente debido, en gran part, a esta fidelidad, estos prototipos son muy útiles para realizar las evaluaciones de métricas (tipo métricas de rendimiento o de coherencia).
- El usuario tiene la sensación de estar trabajando con un sistema real.
Inconvenientes de los prototipos software.
- Este método requiere habilidades de desarrollo de software, aunque cada vez en menos grado (recordemos que puede realizarse un prototipo software con técnicas como utilizar un programa para realizar presentaciones).
- Aunque rápido, el método consume mucho más tiempo que otros tipos de prototipos (de papel, por ejemplo).
- Se requieren mayores recursos debido a la necesidad de emplear software y hardware específicos.
- Debido a la mayor inversión en cuanto a habilidades y tiempo necesarios suele renunciarse a "tirar" un prototipo, quedando el mismo como una versión preliminar del sistema. Este factor, a la larga, resulta ser un lastre.
- Frecuentemente la última de las ventajas mencionadas se convierte en un grave inconveniente, pues los directivos responsables y los propios usuarios creen que el sistema está casi terminado y tendrán prisa por verlo finalizado.
