Esta semana vimos varios temas pero los temas que mas me llamaron la atención fueron el de modelado de tareas que hicimos con concur task tree, diagramas de casos de uso y el prototipado y los patrones.
Modelado de Tareas
Los modelos de tareas describen las actividades lógicas realizadas por el usuario cuando éste interactúa con la aplicación representando las tareas que el usuario debe de realizar para interactuar con el sistema.
Se emplea para el análisis de requisitos de la interfaz ya que para que la aplicación sea aceptada y satisfactoria para el usuario final, la interfaz es una parte clave en el desarrollo de cualquier aplicación. El modelado de tareas para el diseño y desarrollo de interfaces de usuario consigue un nivel de abstracción superior, haciendo que el desarrollo de software se convierta en un proceso de ingeniería lo que conlleva a conseguir un software de calidad y permite obtener aplicaciones interactivas centradas en el usuario.
El proceso de análisis de tareas se compone de dos partes muy importes; la primera es la obtención de la información necesaria para comprender las actividades que realiza el usuario (fase de análisis) y la segunda labor, es proporcionar una representación de esta información sobre un modelo adecuado (fase de modelado). Estos pasos nos darán una descripción formal del conjunto de acciones que debe realizar el usuario para conseguir un determinado objetivo. La compresión, el conocimiento, las intenciones…etc. quedarán modelados en este análisis.
La información aportada por un modelo de tareas es útil para comprender el dominio de la aplicación identificando las actividades más importantes y sus objetivos. Permite facilitar discusiones ínter disciplinares: El conocimiento de la tarea puede ser útil para el diseñador, usuarios, analistas, psicólogos, sociólogos, etc. También resulta beneficiosa a la hora de realizar el diseño de la nueva aplicación de forma consistente con el actual modelo conceptual, preservando las características más relevantes del funcionamiento lógico. Como última característica se puede destacar el beneficio aportado en el análisis y evaluación de la usabilidad.
Algunos ejemplos de métodos de análisis de tareas son: Hierarchical Task Analysis (HTA), Goal-Operations-Methods-Selection (GOMS), Task Action Grammar (TAG), User Ac-tion Notation (UAN) y la notación ConcurTaskTrees (CTT) que es la más reciente y en la cual se basa este Proyecto Final de Carrera.
La Notación CTT
CTT es una notación desarrollada por Fabio Paternò utilizada para modelar las tareas que un usuario puede llevar a cabo en una aplicación interactiva [1]. Esta notación es especialmente útil para aplicaciones CSCW (Computer-Supported Cooperative Work).
Algunas de las principales ventajas de esta notación son su estructura jerárquica que la hace muy intuitiva, su sintaxis gráfica que la hace sencilla de interpretar, y un conjunto rico de operadores que permite expresar de forma clara las relaciones temporales existentes entre las tareas y los usuarios encargados de llevarlas a cabo
En CTT, se identifican 4 tipos de tareas, en función del actor que la llevará a cabo:
El uso de estos operadores facilita la descripción de comportamientos complejos.
- T1 ||| T2. Entrelazado (Concurrencia independiente). Las acciones de las dos tareas pueden realizarse en cualquier orden.
- T1 |[]| T2. Sincronización (Concurrencia con intercambio de Información). Las dos tareas tienen que sincronizarse en alguna de sus acciones para intercambiar información.
• T1 >> T2. Activar (enabling). Cuando termina T1, se activa T2.
Las dos tareas se realizan de manera secuencial.
- T1 []>> T2. Activar con paso de información. Cuando termina T1 genera algún valor que se pasa a T2 antes de ser activada.
- T1 [] T2. Elección. Selección alternativa entre dos tareas. Una vez que se está realizando una de ellas la otra no está disponible al menos hasta que termine la que esta activa.
- T1 [> T2. Desactivación. Cuando ocurre la primera acción de T2, la tarea T1 se desactiva.
- T1 [][> T2. Desactivación con paso de información. Igual que la anterior pero pasando información de una tarea a la otra.
- T1*. Iteración. La tarea T1 se realiza de forma repetitiva. Se estará realizando hasta que otra tarea la desactive.
- T1(n). Iteración finita. La tarea T1 puede darse n veces. Se utiliza cuando el diseñador conoce cuantas veces tiene que realizarse la tarea
- [T1]. Tarea opcional. No es obligatorio que se realice la tarea.
Cuando describimos las subtareas existente en la tarea de rellenar
un formulario algunas de las subtareas pueden ser opcionales (las de los campos que sean opcionales).
Casos deUso
En el artículo de Frederick P. Brooks encontramos un párrafo que dice: “La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas, y otros sistemas. Ninguna otra parte del trabajo afecta tanto al sistema si es hecha mal. Ninguna es tan difícil de corregir mas adelante… Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto”.
Ejemplo de un caso de uso
Los casos de uso son un método que, justamente, ayudan al Ingeniero de Software a llevar adelante esta parte del desarrollo de un sistema de software.
¿Qué son los Casos de Uso?
Los casos de uso son una técnica para especificar el comportamiento de un sistema:
“Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios.”
Todo sistema de software ofrece a su entorno –aquellos que lo usan– una serie de servicios. Un caso de uso es una forma de expresar cómo alguien o algo externo a un sistema lo usa. Cuando decimos “alguien o algo” hacemos referencia a que los sistemas son usados no sólo por personas, sino también por otros sistemas de hardware y software.
Actores
Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma.
Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos. Los actores se representan con dibujos simplificados de personas.
Los casos de uso tienen las siguientes características:
1) Están expresados desde el punto de vista del actor.
2) Se documentan con texto informal.
3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis está puesto en la interacción.
4) Son iniciados por un único actor.
5) Están acotados al uso de una determinada funcionalidad –claramente diferenciada– del sistema.
Durante la ejecución de un caso de uso, suelen aparecer errores o excepciones. Por ejemplo, mientras se ingresa un pedido, el cliente puede solicitar un producto que está discontinuado. El sistema deberá en este caso informar esta situación al empleado que ingresa el pedido. Esas desviaciones del curso normal del caso de uso se llaman alternativas. Las alternativas tienen las siguientes características:
1) Representan un error o excepción en el curso normal del caso de uso.
2) No tienen sentido por sí mismas, fuera del contexto del caso de uso en el que ocurren.
Si bien en la bibliografía las alternativas se documentan al final del caso de uso, la experiencia demuestra que resulta útil documentar los casos en tablas, mostrando el curso principal en la primera columna, y las alternativas en una segunda columna.
DISEÑO
Cuando se diseña un sistema que funcionara en la web se deben tener en consideración varias cosas. Estos son elementos básicos que no pueden faltar en el sistema.
• Menú de secciones: es una zona de la interfaz en la que se detallan las secciones o categorías en las que está dividida la información contenida en el Sitio Web. Normalmente se ubica en la parte superior de cada página o bien en la zona superior derecha o izquierda. Hasta la aparición de los últimos estudios basados en «eyetracking» no había una recomendación certera acerca de su ubicación; tras éstos, parece indicado ubicarlos en la zona superior o en la zona superior izquierda.
adicionalEyetracking: sistema de comprobación de usabilidad que permite identificar, usando un dispositivo de detección de miradas, lo qué está efectivamente viendo un usuario que interactúa con una pantalla.
• Menú de rastros: es el menú que indica mediante los nombres de cada sección o categoría del menú, la distancia que separa a la página actual de la portada. Por ejemplo, si el usuario está revisando la página del «Programa A», el menú correspondiente debe indicar Portada > Programas > «Programa A». Este menú debe ir siempre debajo de la Identificación de la sección o categoría y sobre el título.
• Identificación de secciones: debe estar en la zona superior de la página, de manera cercana la zona donde se encuentra el logotipo que se haya elegido para identificar al Sitio Web. Puede ser gráfico y por lo mismo tener alguna imagen alusiva a la sección o categoría o bien ser una solución que incorpore sólo texto y color. Sí debe tener en forma destacada el nombre de la sección o categoría y por lo mismo, debe aparecer en todas las pantallas que pertenezcan a dicha ésta. En términos de tamaño, su ancho debe ser el de la zona de contenido y su alto, no menor a 100 pixeles (aproximado) para una adecuada visualización.
• Botones de acción: son aquellos elementos que permiten realizar acciones directas relativas a la navegación y que se muestran como parte de ésta, tales como los correspondientes a «Regreso a la Portada», «Contacto», «Envío de Mail al Sitio» y «Mapa del Sitio».
• Pie de página: aunque regularmente no se le concede importancia en términos de navegación, se entiende que la zona inferior de cada pantalla cumple el relevante papel de completar la información que se ofrece en las zonas superiores de navegación, al entregar datos relativos a la organización (nombre, direcciones, teléfonos) y repetir enlaces que se han entregado en la zona superior, para facilitar el contacto del usuario con el sitio.
Referencias
Ceria, S.Casos de Uso.Un Método Práctico para Explorar Requerimientos
http://www.guiadigital.gob.cl/guia-web. Recuperado el 10 junio 2014
http://santizumaquero.files.wordpress.com/2011/02/trabajosc_mouseion_sfz.pdf. . Recuperado el 10 junio 2014
http://users.dcc.uchile.cl/~psalinas/uml/casosuso.html . . Recuperado el 10 junio 2014
abialeba 