por 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 e inconvenientes
Ventajas
- Las descripciones de gente utilizando tecnología representadas en forma de escenarios son esenciales 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.
Inconvenientes
- Un escenario, o un conjunto de éstos, no guía explícitamente 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
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.
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.
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 combinació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.
