Material Apoyo 2 Parcial PDF

Es una notación para las especificaciones del modelo de tareas útil para apoyar el diseño de aplicaciones interactivas diseñadas específicamente para el diseño basado en modelos de interfaz de usuario. CCT Las principale...

Es una notación para las especificaciones del modelo de tareas útil para apoyar el diseño de aplicaciones interactivas diseñadas específicamente para el diseño basado en modelos de interfaz de usuario. CCT Las principales características de ConcurTaskTrees son: (CONCURTASKTREES) Estructura jerarquica, que proporciona una amplia gama de granularidad en la descripción de estructuras de tareas grandes y pequeñas; Sintaxis grafica, que refleja la estructura lógica en forma de árbol; Notacion concurrente, que admite la ordenación flexible de las tareas a realizar.  NOTACIÓN CTT En CTT,se identifica n 4 tipos de ta rea s,en función del actor que la llevará a cabo: Tareas de usuario: Tareas de aplicación: Tareas de interacción: Tareas abstractas: Tareas realizadas Tareas realizadas por la Son tareas que realiza el Tareas que requieren completamente por el propia aplicación. usuario interactuando con la acciones complejas y que usuario, son tareas aplicación por medio de por ello no es fácil decidir cognitivas o físicas que alguna técnica de donde se van a realizar no interactúan con el interacción. exactamente. Son tareas sistema. que van a ser descompuestas en un conjunto de nuevas subtareas.  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 NOTACION DE CCT acciones para intercambiar información. (CONCURTASKTREES) 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 Para la descripción se utilizan una genera algún valor que se pasa a T2 antes de ser activada. serie de operadores temporales, extensión de los existentes en T1 [] T2. Elección. Selección alternativa entre dos tareas. Una vez que LOTOS, que facilitan la descripción se está realizando una de ellas la otra no está disponible al menos hasta que termine la que esta activa. de las relaciones temporales existentes entre tareas. El uso de T1 [> T2. Desactivación. Cuando ocurre la primera acción de T2, la estos operadores facilita la tarea T1 se desactiva. descripción de comportamientos complejos. 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. CCT (CONCURTASKTREES)-EJEMPLO Como ejemplo de especificación utilizando los ConcurTaskTrees podemos ver, en la Figura, una parte de una aplicación para acceder a información sobre un museo: CCT (CONCURTASKTREES)-EJEMPLO APLICADO A LA TAREA MODELADO DE DIALOGO MODELADO DE DIALOGO  Ejemplo de modelos de diálogo Intencionales, en los cuales todos los interlocutores (usuarios y sistema) tienen la facultad de guiar el diálogo. Además, puede existir un Basados en pregunta- intercambio bidireccional de información entre ellos con la intención de respuesta, que se caracterizan alcanzar unas metas porque sólo el sistema tiene la facultad de dirigir el diálogo y la interacción se basa únicamente en una pregunta realizada por el usuario y una respuesta generada por el sistema, o a la inversa.  MODELADO DE DIALOGO- EJEMPLO APLICADO EN LA TAREA Paciente: Buenas Tardes. Centro Medico: Perfecto Sra. Campuzano su cita queda Centro Medico: Buenas Tardes, gracias por comunicarte con agendada el día miércoles 16/10/2023 con la Dra. Macias en nosotros. ¿En que podemos ayudarte? el área de Ginecología en horario de 10:00am. Paciente: Deseo agendar una cita medica Adicional recuerde llegar con 10 minutos de anticipación y Centro Medico: Perfecto, ¿Para que especialidad deseas la cita? acercarse directamente para la toma de signos vitales. Paciente: Necesitaría la cita para Ginecología. Paciente: Excelente, muchas gracias Centro Medico: Excelente, ayúdame con tu numero de cedula y Centro Medico: Agradecemos su confianza en nuestro centro nombres completos, por favor. medico, que tenga un excelente dia. Paciente: Claro, mi nombre es Magdalena Campuzano y mi cedula es: 1928320293 Centro Medico: Perfecto Sra. Campuzano. Indíqueme ¿En que horario desearía su cita (Mañana-Tardes o Noche)? Paciente: Deseo la cita a las 10:00am, por favor Centro Medico: Excelente. Sra. Campuzano en este horario tenemos disponible una cita con la Dra. Macias el Dia Miércoles 16/10 ¿Estaría bien para usted? Paciente: Si esta muy bien, justo quería una cita con la Dra. Valeriano, muchas gracias MODELADO DE LA PRESENTACIÓN El modelo de la presentación es una descripción de la interfaz de usuario. La mayoría de los modelos de presentación se concentran en representar la interfaz gráfica en 2D, interfaces de usuario basadas en widgets, es decir, las interfaces WIMP (Windows, Icons, Menus y dispositivo apuntador). Sin embargo, poco a poco se han desarrollado modelos de presentación que permiten una representación de interfaces de varios dominios de aplicación: Interfaz de voz mezclada con gráfica, interfaz vocal ,táctil El contenido de los modelos de presentación varía y depende de las diferentes metodologías Es una presentación breve, que tiene como objetivo mostrar y un modelo de negocio y conquistar a potenciales inversores. ¿Sabes cómo elegir el modelo de presentación que va a convencer a esos posibles patrocinadores? No existe una fórmula mágica, pero hay algunas cuestiones esenciales.  MODELADO DE LA PRESENTACIÓN – EJEMPLO EN LA TAREA OPCION 1 INGRESO AL SISTEMA.- El paciente debe ingresar su nombre de usuario y clave de acceso en los campos (Nombre de usuario y clave) y luego presionar el botón "Validarse para entrar". En caso de no tener una cuenta creada el paciente puede presionar el botón de "Registrarse". OPCION 2 CREAR EL FORMULARIO DE REGISTRO.- En caso de no poseer una cuenta, un paciente podrá crear su propio perfil con esta opción. El sistema desplegará un formulario para el ingreso de datos del paciente. Una vez completo el formulario el paciente deberá presionar el botón "Registrarse" para que el sistema cree su perfil. OPCION 3 SOLICITAR CITA: Una vez ingresado al sistema, el paciente podrá asignarse una cita. Primero deberá seleccionar el área de especialidad en que desea la cita. Especialidades disponibles: Medicina general, Obstetricia, Pediatría, Odontología, Psiquiatría, Rayos x, Laboratorio clínico, Ginecología. Luego el sistema desplegara un listado de doctores que pertenezcan a esa área. El paciente deberá seleccionar el doctor de su preferencia. Médicos: Susana Holguin, Joselyn Arroyo, Samuel Quinteros, Michael Macias, Xiomara Alarcón, Yarleni Franco, Marlon Alfonso, Vicky Caicedo, Jhon coronel, Ericka Macias. Cuando selecciona el médico, se desplegará un campo para la selección de la fecha de la cita, una vez ingresado este valor el paciente debe presionar el botón “Buscar horario”. El sistema desplegara un listado de horarios para la fecha seleccionada. Horarios disponibles: lunes a viernes de 08:00AM a 20:00PM. OPCION 4 CONFIRMACION DE AGENDACION DE CITA: Se notifica mediante correo confirmación de cita con fecha, hora, especialidad, nombre de medico y recomendación para la cita.  REDES DE TRANSICIONES DE ESTADOS Un diagrama de transición de estados muestra el comportamiento dependiente del tiempo de un sistema de información. Representa los estados que puede tomar un componente o un sistema y muestra los eventos que implican el cambio de un estado a otro. Los dos elementos principales en estos diagramas son los estados y las posibles transiciones entre ellos. El estado de un componente o sistema representa algún comportamiento que es observable externamente y que perdura durante un periodo de tiempo finito. Viene dado por el valor de uno o varios atributos que lo caracterizan en un momento dado. Una transición es un cambio de estado producido por un evento y refleja los posibles caminos para llegar a un estado final desde un estado inicial. Desde un estado pueden surgir varias transiciones en función del evento que desencadena el cambio de estado, teniendo en cuenta que, las transiciones que provienen del mismo estado no pueden tener el mismo evento, salvo que exista alguna condición que se aplique al evento. Un sistema sólo puede tener un estado inicial, que se representa mediante una transición sin etiquetar al primer estado normal del diagrama. Pueden existir varias transiciones desde el estado inicial, pero deben tener asociadas condiciones, de manera que sólo una de ellas sea la responsable de iniciar el flujo. En ningún caso puede haber una transición dirigida al estado inicial. REDES DE TRANSICIONES DE ESTADOS-EJEMPLO Estado Un estado se representa como un rectángulo con las esquinas redondeadas. El nombre del estado se coloca dentro del rectángulo y debe ser único en el diagrama. Si se repite algún nombre, se asume que simboliza el mismo estado. El estado inicial se representa con un pequeño circulo relleno, y el estado final como un pequeño circulo relleno con una circunferencia que lo rodea. Transición Una transición se representa con una flecha continua que une dos estados y que se dirige al estado al que cambia el componente. Junto a ella se coloca una etiqueta que debe contener al menos el nombre del evento que provoca la transición.  INICIO ESTADO INICIAL REDES DE TRANSICIONES DATOS DE ESTADOS– EJEMPLO EN LA TAREA INTERFAZ INFORMACI INTERFAZ PERFIL ON CITA ESPECIALIDAD SELECCION LISTA AR MOSTRAR ESPECIALIDAD ESPECIALID INFO AD DOCTOR LISTA DE SELECCINA MOSTRAR DOCTOR R DOCTOR INFO FRANJA HORARIA SELECCIO MOSTRAR LISTA NAR INFO HORARIO HORARIO  Diseño centrado en el usuario y prototipado (DCU) 3.1 Elementos básicos del dcu 3.2 Modelos del diseño de la interacción 3.3 Pasos para realizarlo 3.4 Especificaciones de requerimientos 3.5 Prototipado 3.6 Herramientas del prototipado 3.7 Casos practicos del prototipado Diseño centrado en el usuario y prototipado (DCU) El diseño centrado en el usuario (DCU) es un enfoque iterativo en el que se integra a los usuarios en el equipo de diseño, con el objetivo de construir sistemas usables. El DCU requiere de la utilización de técnicas para la producción de soluciones de diseño. En el DCU, se exploran sus elementos básicos, los modelos de diseño de la interacción, los pasos para realizar un DCU, y el proceso para identificar usuarios, necesidades y requerimientos.  3.1 Elementos básicos del dcu El DCU se realiza simultáneamente con el proceso de desarrollo de la parte interna del sistema (análisis y especificación de requerimientos, diseño, implementación y pruebas), independientemente de la metodología de desarrollo que se adopte. Incluso, en algunas etapas, como la de análisis y especificación de requerimientos, el equipo de DCU y el de desarrollo pueden colaborar estrechamente. Además, el DCU debe llevarse a cabo a lo largo de todo el ciclo de vida de un sistema. Existe una serie de elementos básicos del DCU, que son necesarios para crear soluciones de diseño que ayuden a garantizar la satisfacción de los usuarios y la usabilidad del sistema. Estos elementos son caso de aplicaciones web, un grupo de representantes del grupo meta de usuarios puede participar Distribución apropiada de las funciones entre los usuarios y la tecnología: inicialmente, un diseñador no tiene idea clara de lo que un usuario pueda o necesite hacer. Por otro lado, los usuarios no saben lo que la tecnología puede hacer. Es necesario que, como resultado del proceso de DCU, se pueda llegar a identificar cuáles deben ser las responsabilidades de los usuarios y cuáles las de la tecnología. La distribución de responsabilidades se debe hacer tomando en cuenta las habilidades y limitaciones de los usuarios.  Equipos de DCU multidisciplinarios: en el equipo de trabajo es necesaria la variedad de habilidades y conocimientos, que dependerán de la naturaleza del sistema. En el equipo de DCU pueden participar usuarios, expertos en el dominio del sistema, representantes a nivel gerencial, diseñadores y expertos en usabilidad y DCU, expertos en mercadotecnia, diseñadores gráficos, animadores, psicólogos, sociólogos, especialistas en factores humanos y expertos en manejo de grupos, entre otros. Cada uno de los participantes debe tener claramente definidas sus responsabilidades. Si bien es posible que una sola persona represente varios de los roles anteriores, nadie debe representar a los usuarios Proceso iterativo de soluciones de diseño: alcanzar un alto grado de usabilidad en un sistema requiere de que se asuma la idea de que el diseño de la interacción siempre es mejorable. No se espera que el equipo de diseñadores de DCU entienda desde el inicio las necesidades de los usuarios. En cada iteración se consiguen mejoras como resultado del análisis de las evaluaciones en la iteración anterior y la creación de nuevas soluciones de diseño. El proceso iterativo comprende, por tanto, la evaluación de cada propuesta de solución de diseño que se cree, con el objetivo de encontrar problemas de usabilidad y posibilidades de mejora.  3.2 Modelos del diseño de la interacción El diseño de la interacción es fundamental para conseguir que un sistema sea usable, puesto que es uno de los factores determinantes del grado de usabilidad del sistema. Los tres aspectos contemplados en la usabilidad, a saber: eficacia, eficiencia y satisfacción, no se consiguen con solo agregar unos cuantos detalles a la interfaz cuando el sistema ya está listo. El diseño de la interacción influye en la estructura interna del sistema. Por esta razón, en el proceso de DCU se proponen diversas soluciones de diseño, que se someten a evaluación para identificar cuál de ellas ofrece un modelo de interacción que sea de mayor aceptación para los usuarios, a la vez que es atractiva para ellos desde el punto de vista estético. Esto último justifica la participación de profesionales en campos artísticos, tales como diseñadores gráficos y animadores, entre otros. En las distintas iteraciones del proceso de DCU, se incorporan procedimientos de refinamiento y análisis de costo/beneficio para definir, junto con los usuarios, los cambios que se deben realizar en el diseño de la interacción. Para llevar a cabo estos procedimientos y análisis, es importante entender cómo las personas actúan y reaccionan ante eventos que ocurren en los sistemas y cómo se comunican e interactúan entre ellas (Rogers et al., 2011). Para ello, es necesaria la participación de profesionales de las ciencias sociales.  3.3 Pasos para realizarlo Existen varios enfoques sobre cómo llevar a cabo un proceso de DCU. Tomaremos el enfoque del estándar ISO 9241-210 (ISO, 2010), que es un referente en este campo. Según este estándar, son cinco los pasos para realizar un DCU Planificación del proceso de DCU: integración del DCU en todas las fases del ciclo de vida del sistema; determinación de riesgos posibles derivados de una usabilidad pobre; desarrollo de procedimientos para comunicación y retroalimentación para otras actividades del proceso de desarrollo relacionadas con el DCU; definición de hitos en las tareas del DCU; acuerdos acerca de tiempo; definición de responsabilidades y control de cambios. La planificación se puede revisar y actualizar conforme se avance en el proceso Comprensión y especificación del contexto de uso: identificación de usuarios; características, necesidades y objetivos de los usuarios y otros afectados (stakeholders) por el sistema; hardware, software y materiales necesarios mientras se usa el sistema; características y restricciones del ambiente físico, social, organizacional, cultural y técnico. Especificación de los requerimientos de los usuarios: requerimientos derivados de las necesidades de los usuarios y el contexto de uso; requerimientos y objetivos de usabilidad derivados de las características del usuario; solución de posibles conflictos entre distintos requerimientos. Producción de soluciones de diseño: diseño de las tareas del usuario; interfaz de usuario e interacción humano-sistema para alcanzar los requerimientos; cambios en las soluciones de acuerdo con los resultados de las evaluaciones. Evaluación del diseño: participación de evaluadores y usuarios; definición de pruebas que brinden retroalimentación para mejorar la solución de diseño; evaluación de prototipos de parte de los usuarios, preferiblemente con la ejecución de tareas concretas que representen sus necesidades. DCU es un proceso iterativo que inicia con la planificación. Cada iteración comprende la ejecución de cuatro pasos, al final de los cuales, con base en los resultados de la evaluación, se determina si el diseño del sistema sirve para satisfacer los requerimientos. La respuesta a la pregunta de si el sistema satisface los requerimientos que se plantea al final de cada ciclo servirá para determinar cuál es el aspecto a dar prioridad para la siguiente iteración. En los pasos de comprensión y especificación de contexto de uso (CECU), especificación de requerimientos de usuario (ERU), producción de soluciones de diseño (PSD) y evaluación del diseño contra los requerimientos (EDR) se realizan actividades distintas Estas actividades se integran con las que se realizan para el desarrollo de la parte interna del sistema (análisis y especificación de requerimientos, diseño, implementación y pruebas) y en algunas ocasiones pueden ser compartidas por ambos equipos de trabajo (CECU), Actividades de comprensión y especificación de contexto de uso Análisis de usuarios: identificar los posibles usuarios del sistema en desarrollo y sus necesidades conocimientos, habilidades y limitaciones relevantes en términos del sistema. Análisis de tareas: identificar qué hacen o necesitan hacer las personas y cómo. Usualmente se crean descripciones de las tareas, que se analizan para detectar problemas de usabilidad y se evalúan contra los resultados del análisis de usuarios. Especificaciones de usabilidad: cuantificar objetivos de usabilidad, en términos de eficacia, eficiencia y satisfacción de los usuarios. Las especificaciones de usabilidad dependen de los resultados obtenidos en las actividades de análisis de usuarios y de tareas (ERU) Actividades de especificación de requerimientos de usuario (PSD) producción de soluciones de diseño Desarrollo del concepto de producto: crear un modelo mental del sistema que sea compartido tanto por los usuarios como por los diseñadores. Modelo mental es un concepto de la psicología cognitiva que tiene mucha importancia dentro del campo de la interacción humano-computador. Un modelo mental es la idea personal de cómo funciona un sistema. Los usuarios crean su propio modelo mental. Si este no coincide con el modelo mental con el que se desarrolla el sistema, el usuario pensará que es difícil usar el sistema. Por otro lado, un diseñador puede tener su propio modelo mental. Por eso es necesario crear uno compartido por usuarios y diseñadores.  Prototipado: crear distintas propuestas de solución de diseño. El prototipado es fundamental en el proceso iterativo del DCU. En este contexto, un prototipo es útil si sirve para mostrarle a los usuarios cómo será la interacción entre ellos y el sistema. La impresión de los usuarios será insumo necesario para perfeccionar dicha interacción. Diseño de la interacción: definir los entornos de interacción y su comportamiento. Esto incluye definir los elementos que constituyen la interfaz gráfica, si se trata de este tipo de interfaz, y de los elementos físicos cuando los usuarios interactúen con un sistema que contemple tanto hardware como software. El comportamiento se refiere a la coordinación en la interacción entre el usuario y el sistema, lo cual determina un cierto orden en la ejecución de los pasos, por ejemplo. Actividades de evaluación del diseño contra los requerimientos (EDR) evaluación del diseño contra los requerimientos Evaluación de la usabilidad: saber si el sistema satisface las necesidades de los usuarios y si se ajusta a los resultados de las actividades relacionadas con el paso de comprensión y especificación del contexto de uso. Se utilizan distintas técnicas de evaluación, según el grado de avance del proceso de diseño y el propósito de la evaluación La etapa de comprensión y especificación del contexto de uso del DCU incluye la identificación de los usuarios, otros afectados y sus necesidades. Este aspecto es fundamental puesto que el sistema debe estar adaptado a las habilidades físicas, sensoriales y cognitivas de los usuarios, sus personalidades y diferencias culturales. Para identificar a los usuarios y otros afectados, es conveniente tomar en cuenta aspectos técnicos, sociales, organizacionales y humanos. La primera pregunta que debemos plantearnos es quiénes son todos los afectados por el éxito o el fracaso del sistema, usualmente llamados stakeholders. No todos los afectados por un sistema lo son en la misma forma, pero es importante identificarlos a todos pues entre ellos pueden existir conflictos de intereses. Podemos clasificar los stakeholders en cuatro categorías: Primarios: los que directamente interactuarán con el sistema, a quienes usualmente llamaremos usuarios. Secundarios: los que reciben la salida y proveen la entrada al sistema sin interactuar con el sistema. Indirectamente son usuarios del sistema. Terciarios: los que no se involucran con el sistema pero se ven afectados por su éxito o fracaso. Facilitadores: los que tienen a su cargo el desarrollo y la puesta en producción del sistema. Supongamos que estamos pensando en crear un sistema de dispositivos móviles que permitirá a los residentes de una zona reportar malas prácticas ambientales, tales como botaderos ilegales de basura o vertederos de aguas contaminadas a ríos. En este caso, los stakeholders por categoría serían los siguientes Primarios: los que van a utilizar directamente el sistema, o sea, los residentes con el teléfono móvil dispuestos a denunciar las malas prácticas; funcionarios en el gobierno local que recibirán las denuncias y las canalizarán a las autoridades competentes. Secundarios: los encargados de la recolección de basura y las autoridades sanitarias competentes; las autoridades del gobierno local. Terciarios: los que son responsables de las malas prácticas ambientales, tales como las empresas que generen la contaminación y las personas que arrojen la basura en los tiraderos; los residentes de la zona. Facilitadores: el equipo de desarrollo del sistema, el personal del departamento de tecnologías de información del gobierno local. En este ejemplo es fácil ver que existen conflictos de interés entre los distintos stakeholders, pues mientras unos lucharán contra las malas prácticas, otros intentarán perpetuarlas. 3.4 Especificaciones de requerimientos Para especificar los requerimientos, es común la técnica de casos de uso, la cual se plantea dentro de los modelos del lenguaje unificado de modelaje (UML por su nombre en inglés). Los casos de uso son comúnmente empleados por ingenieros de software para describir cómo se va a usar un sistema. Se pueden derivar de los escenarios. Describen la funcionalidad como una secuencia de interacciones entre un usuario y el sistema. Un caso de uso se estructura de forma que se reflejan las acciones del usuario y las respuestas del sistema. Estas respuestas pueden ser de variada índole, como, por ejemplo, despliegue de información, solicitud de entrada de datos al usuario, conexión con otros sistemas o ejecución de algoritmos. A continuación se muestra un ejemplo para el caso de uso “Retirar dinero en un cajero automático”: Caso de uso: Retirar dinero del cajero automático Este caso de uso comienza cuando el cliente inserta la tarjeta de débito o crédito en la ranura para la tarjeta. El sistema lee y valida la información en la tarjeta. El sistema solicita el número de identificación personal (PIN). El cliente ingresa su PIN. El sistema valida el PIN. El sistema pregunta al cliente cuál operación desea realizar. El cliente indica “Retiro de dinero”. El sistema solicita el monto de dinero a retirar. El cliente indica el monto. El sistema se comunica con la red de cajeros automáticos para validar el número de tarjeta, el PIN y la disponibilidad del monto de dinero solicitado. El sistema le indica al cliente que ya puede retirar la tarjeta. El cliente retira la tarjeta de la ranura. El sistema dispensa el monto de dinero solicitado e imprime el recibo. El cliente retira el dinero. Alternativas: 1. Si el número de tarjeta no es válido o no hay disponible el monto de dinero solicitado, el sistema se lo indica al cliente y le indica que retire la tarjeta e inserte otra. 2. Si el PIN no es válido, el sistema le indica al usuario que lo reingrese. Poscondición: Si el cliente insertó una tarjeta de débito, el monto de dinero solicitado ha sido debitado de la cuenta. Si el cliente insertó una tarjeta de crédito, el monto ha sido registrado como una deuda. En ambos casos, el cliente ha recibido el monto solicitado. Como se puede notar en este ejemplo de caso de uso, implícitamente algunas decisiones sobre la interfaz de usuario ya han sido tomadas, tales como que hay una ranura para insertar la tarjeta y ventanas en las que se ingresa en PIN y el monto. Esta situación, en cierta forma, impide concentrarse en la esencia de la tarea del usuario. Para evitarlo, se recomienda el uso de casos de uso esenciales (Constantine y Lockwook, 1999). En estos, se mantiene un nivel muy alto de abstracción. Los casos de uso esenciales se definen en términos de las intenciones de los usuarios y las responsabilidades de sistema. Son útiles durante las iteraciones iniciales del proceso de DCU, en las cuales no se requieren detalles de la interfaz, pues lo importante es construir el modelo conceptual del sistema, o sea un conjunto de ideas compartidas por los usuarios y los diseñadores acerca de cómo funcionará el sistema. Además, al no tomarse tempranamente decisiones sobre la interfaz, dan espacio al equipo de desarrollo para concentrarse en el problema desde la perspectiva del usuario y para crear distintas soluciones de diseño. Por ello, los casos de uso esenciales favorecen la exploración y la innovación. Cualquier caso de uso se puede expresar en su versión esencial. El caso de uso “Retirar dinero en un cajero automático” descrito esta vez como caso de uso esencial se presenta a continuación: Caso de uso esencial: Retirar dinero del cajero automático Intenciones del usuario Responsabilidades del sistema 1. Solicita identificación. 2. Provee identificación 3. Verifica identificación. 4. Ofrece opciones. 5. Escoge opción de retiro 6. Entrega el dinero. 7. Toma el dinero  3.5 Prototipado Un prototipo es un modelo, un medio para probar una idea, refinarla, evaluar su factibilidad técnica y económica, promocionarla y gestionar fondos para su comercialización. Los prototipos son comunes en industrias como la automovilística o la aviación. En particular, en el campo de la IHC, un prototipo es una herramienta que simula o en la que se han implementado partes del sistema que estamos desarrollando, incluida fundamentalmente la interfaz. Existe un amplio rango de prototipos, que incluyen, por ejemplo, una pieza de madera con la que se simula la interacción, un documento estático, una serie de dibujos, una historieta (storyboard) sobre cómo se desarrolla la interacción, un video en la que se ve cómo interactuará el usuario con el sistema, o bien una pieza de software con funcionalidad limitada, con la que un usuario podría o no interactuar Los prototipos se usan en la fase de identificación de requerimientos y son especialmente útiles cuando existe incertidumbre acerca de las necesidades de los usuarios. Sin embargo, es importante resaltar que cualquiera nueva idea de diseño debe ser comunicada a los usuarios por medio de prototipos (Ferré, 2005). Estos sirven como un medio de comunicación que facilita el entendimiento entre diseñadores y usuarios. Por esta misma razón, permiten a los diseñadores establecer un lenguaje común con los usuarios y recibir retroalimentación de estos, fundamental en un proceso de DCU. Algunas de las técnicas de prototipado tienen un costo muy bajo, con lo cual se puede pensar en distintas opciones de diseño. Por esta razón, los prototipos dan espacio a la reflexión sobre el diseño de la interacción. Además, pueden utilizarse para probar un concepto o un modelo de interacción antes de invertir mucho tiempo y dinero. Los prototipos, según la etapa de desarrollo en que se utilicen, son también útiles para poner a prueba aspectos variados, como si cubren las necesidades del sistema, si se sigue una secuencia de operaciones que tiene sentido para los usuarios y si el aspecto de la interfaz de usuario les agrada y les genera sensaciones positivas. Dependiendo del tamaño del sistema, puede no ser posible crear prototipos de todas las tareas que se deben realizar. En este caso, se debe ser selectivo acerca de cuáles partes del sistema prototipar. Por eso, se debe establecer criterios de selección, tal como elegir las tareas más complejas, que impongan mayor carga cognitiva sobre los usuarios o bien aquellas que son de uso más frecuente. En el primer caso, se espera bajar la carga cognitiva y en el segundo lograr un alto nivel de eficiencia en tiempo. Existen tres estrategias para decidir qué prototipar: vertical, horizontal y diagonal (Floría, 2001). En un prototipo vertical, se implementan de manera completa pocas de las funcionalidades del sistema. Ofrece la ventaja de mostrar una sección limitada pero completa del sistema. Si se trata de un prototipo ejecutable, se puede probar dicha sección como si estuviera en producción, aunque se debe recordar a los usuarios que es solo un prototipo. Por el contrario, un prototipo horizontal muestra toda la funcionalidad del sistema, aunque no es funcional. Por tanto, no se puede realizar una prueba real. Por último, un prototipo diagonal comienza como un prototipo horizontal hasta un cierto nivel y después, una sección del sistema se desarrolla con más profundidad. Un prototipo es un producto intermedio del proceso de DCU. Sus características dependen del propósito para el que fue creado y del grado de avance en el proceso de desarrollo. Sin embargo, algunas son comunes para todos los prototipos, tales como que deben Ser construidos en poco tiempo, para tener la oportunidad de construir varias opciones de diseño en un corto periodo Ser oportunos, o sea, estar listos temprano en el proceso para que ayude a clarificar ideas. Ser fácilmente modificables, para que los usuarios sepan que los cambios son posibles y se sientan motivados a solicitarlos. Mostrar cómo será la interacción entre usuarios y sistema, para que al ser evaluados, los usuarios puedan entender cómo se relacionarán con el sistema y no tengan que imaginar cómo será. Ayudar a crear un lenguaje común entre usuarios y miembros del equipo de DCU, como resultado de la relación entre ambas partes en el esfuerzo por conseguir una opción de diseño que satisfaga las necesidades de los usuarios. Sugerir en vez de confirmar, para que los usuarios no los sientan como una imposición del equipo de DCU, sino que sirvan para refinar el diseño.  3.6 Herramientas del prototipado Para la construcción de prototipos de baja fidelidad, los materiales y las herramientas utilizados son sencillos y comunes: papel, cartulina, fichas, notas post-it, tijeras y lápices Cuando se trabaja en el diseño de un sistema para dispositivos móviles, es conveniente utilizar caparazones de estos que permitan tener una idea de las dimensiones que deberán tener los elementos de la interfaz Para unas pocas plataformas existen herramientas de software que permiten ejecutar un prototipo de papel en solo tres pasos: dibujar, fotografiar y simular. El resultado se puede considerar un storyboard. De esta forma, en vez de llevar al usuario o cliente una colección de papeles, se le muestra una aplicación ejecutable, en la que se simula la funcionalidad del sistema Para unas pocas plataformas existen herramientas de software que permiten ejecutar un prototipo de papel en solo tres pasos: dibujar, fotografiar y simular. El resultado se puede considerar un storyboard. De esta forma, en vez de llevar al usuario o cliente una colección de papeles, se le muestra una aplicación ejecutable, en la que se simula la funcionalidad del sistema Disponibilidad de plantillas para diferentes plataformas Disponibilidad de formas y controles predefinidos para varias plataformas Capacidad para crear tanto prototipos de software como storyboards Disponibilidad de imágenes predefinidas para agilizar la creación de storyboards Posibilidad de integrar las pantallas del prototipo en un storyboard Capacidad para agregar anotaciones que sirvan para describir el prototipo