Prototipo y Evaluación Capítulo 9 Por que se necesita evaluar durante el proceso iterativo de diseño? La cantidad de métodos disponibles y como seleccionar.

Slides:



Advertisements
Presentaciones similares
Como crear y usar una rúbrica
Advertisements

Entrenando Instructores Para Entrenar
DISEÑO DE EXPERIMENTOS
INGENIERIA DE REQUISITOS
DISEÑO ORIENTADO AL OBJETO
CÓMO TRANSFORMAR LA AUTO-EVALUACIÓN EN UNA HERRAMIENTA DE APRENDIZAJE
EJECUTAR Y CONTROLAR EL PLAN DE MANTENIMIENTO
2. Diseño y Desarrollo del Producto
METODO DE ANALISIS DE FALLAS
OPERACIÓN Y CONTROL DE UN CENTRO DE CÓMPUTO
Administración de Procesos de Pruebas
Sistema de Gestión de la Calidad
Una vez que haya dominado el material de este capítulo, podrá:  Entender los cuatro modelos principales de elaboración de prototipos.  Usar la elaboración.
Técnicas de Capacitación
M.S.C. Ivette Hernández Dávila
Desarrollo Orientado a Objetos con UML
Seleccionar preguntas y planear la evaluación. ¿Qué queremos decir con “seleccionar preguntas”? Las preguntas de evaluación son las preguntas que su evaluación.
Capítulo 3 Etapas de un Proyecto de simulación
Buneder poblete karim david Saldaña ortiz alejandro ssd4
Capitulo 1 Explicar que son los sistemas interactivos Explicar que significa diseñar un sistema interactivo exitoso Enfatizar la necesidad de métodos de.
Curso-Taller Capacitación para Coaches de Conservación
DISEÑO DE LA INTERFAZ DE USUARIO
Fase Inicial Grupo 6 – PIS – 2013.
Copyright © 2014 by The University of Kansas Recolectar y analizar información.
DISEÑO DE SOFTWARE 1ª. Parte
Ingenieria de software
Mt. Martín Moreyra Navarrete.
Ingeniería de Requisitos
Módulo 12 Herramienta de aseguramiento de la calidad del PSA 1.
Análisis y Diseño Orientado a Objetos utilizando UML
Juan Antonio del Valle Flores
MEDIDA DE LA USABILIDAD EN APLICACIONES DE ESCRITORIO
Cómo adquirir programas
Capítulo 8 Análisis de Usabilidad y Inspección
Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)
Implementación OHSAS TEMA: Implementación OHSAS Ing. Larry D. Concha B. UNIVERSIDAD AUTONOMA SAN FRANCISCO.
Metodología para solución de problemas
Evaluación de Sistemas y de sus Interfaces
Un Repaso  Entrenamiento adecuado no ocurre sin mucho trabajo  Requiere que todo sea muy bien planeado  Hay.
Modelos en el manejo de información
CICLO DE VIDA Y NORMAALIZACION DE UN SISTEMA DE BASE DE DATOS
INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE
Ing. Noretsys Rodríguez. Definición de Conceptos  Falla: Ocurre cuando un programa no se comporta de manera adecuada. Es una propiedad estadística de.
INTRODUCCIÓN AL PROCESO UNIFICADO DE DESARROLLO DESOFTWARE
Christian Monrreal Gonzalez Daryl Silverman Aguilar Gone
Maestría en Informática Aplicada a la Educación
MC Luz María Moreno Aguilar Noviembre 2009
Alexander Aristizabal Ángelo flores herrera
Capitulo 1 Roger S. Presman
Copyright © 2014 by The University of Kansas Recolectando y análizando datos.
Estimación por casos de uso.  Un caso de uso representa una unidad de interacción entre uno y el sistema. Un Caso de Uso es una unidad simple de trabajo.
TIPOS DE PRUEBAS DEL SOFTWARE
Posgrado en Sistemas Computacionales Heurísticas de usabilidad MC Luz María Moreno Aguilar Noviembre 2009.
METODOLOGIAS DE DESARROLLO DE SOFTWARE
Ingeniería de Requerimientos
Los métodos de aprendizaje colaborativo comparten la idea de que los estudiantes trabajan juntos para aprender y son responsables del aprendizaje de.
Proceso de Diseño de Interfaces
Modelo Prescriptivos de proceso
1 Módulo de Fundamentos 5 Incidencia. 2 Sección 1 Roles y tipos de incidencia en situaciones de emergencia Sección 2 Principios del enfoque de derechos.
problemas de la calidad del software
Un requerimiento es una condición o capacidad a la que el sistema (siendo construido) debe conformar [ Rational ]. Un requerimiento de software puede.
Proceso de desarrollo de Software
Marco de Trabajo para Indexación, Clasificación y Recopilación Automática de Documentos Digitales Javier Caicedo Espinoza Gonzalo Parra Chico.
Métodos instruccionales
TEMA 5 OBJETIVOS Datos que se recogen a través de estudios cuidadosamente planeados La selección de métodos que existen: entrevista, observación y cuestionarios.
Taller de investigación 1
RAPID APPLICATION DEVELOPMENT RAD. Proceso de RAD Involucrar en todos los aspectos al usuario en el desarrollo del sistema Uso continuo y repetitivo de.
Bachillerato Ingeniería en Informática Fundamentos de Computación.
Objetivos de la prueba Los objetivos principales de realizar una prueba son: Detectar un error. Tener un buen caso de prueba, es decir que tenga más probabilidad.
 La gestión de proyectos una disciplina que ha tomado fuerza en la medida en que buena parte de lo que se hace tanto a nivel personal como profesional.
Transcripción de la presentación:

Prototipo y Evaluación Capítulo 9 Por que se necesita evaluar durante el proceso iterativo de diseño? La cantidad de métodos disponibles y como seleccionar entre ellos Como conducir la evaluación como una investigación real, con objetivos específicos de aprendizaje y los pasos Como escribir planes concisos y reportes de evaluación Como construimos los prototipos y las herramientas que usamos Métodos informales de evaluación Métodos iterativos de chequeo en el campo

Evaluación Formativa El diseño es evaluado de acuerdo a los requerimientos La evaluación es realizada bajo condiciones reales Los resultados de la evaluación se incorporan en la próxima versión mejorada Ver Figura 9.1 (dos diseños alternativos en un paquete de CAD, un menú pull-down corriente y B un menú alternativo en forma de torta). El proceso de evaluación. La construcción del prototipo y su evaluación siguiendo los requerimientos o las especificaciones del problema, reportamos resultados que influencian la próxima etapa en el desarrollo de las especificaciones del diseño.

Evaluación Sumativa Conducir una evaluación a Full Escala puede significar que todas las otras actividades de diseño se deben parar Otra alternativa es evaluar cuando el diseño está completo Pero la evaluación sumativa presenta los siguientes problemas El diseño puede fallar en su evaluación, pero ya no hay tiempo para rectificar las fallas Se corre el peligro de no realizar ninguna evaluación

Técnicas Formativas Simples Esto minimiza la cantidad tiempo durante el cual el diseño se para: A. Aprendiendo a partir del diseño y de la construcción de prototipos, descubriendo los problemas en el prototipo que no se visualizaron en el papel B. Aplicar pruebas informales al prototipo inicial, probándolo nosotros mismos o invitando a otros a probarlo. C. Conducir una serie de estudios de campo de mejoras progresivas de el mismo prototipo Una cuarta opción no discutida en esta lección D. Chequear una componente del diseño bajo condiciones controladas, típicamente en un laboratorio de usabilidad Proveer resultados más exactos que otros métodos

Realizando la Investigación Las etapas básicas: 1. Se identifican las propiedades de usabilidad a ser medidas, estableciendo requerimientos particulares que el diseño debe alcanzar 2. Se pondrá a punto el prototipo para ser usado para la evaluación 3. Se diseña el experimento, se localizan a los usuarios que realizarán la prueba, definiremos las actividades que el usuario va a realizar y programaremos las pruebas 4. Nosotros aplicaremos las pruebas y recogeremos la data; a cada usuario se le explicará de que trata la prueba, antes de realizarla 5. Se analizará la data para establecer como las condiciones de la prueba han afectado la eficiencia de las actividades 6. Se concluirá definiendo acerca de las mejoras que requiere el diseño. Las etapas 3, 4, y 5 representan el proceso del diseño experimental.

Análisis y Diseño del Experimento La clase de resultados que esperamos para: Las clases que esperamos evitar: No se aprecia diferencia - Resultados confusos debido a experimentos mal realizados Sin significancia estadística

El Plan de Investigación y su Reporte Dos etapas esenciales en la documentación de la evaluación Figura 9.4. Los roles del plan de investigación y su reporte

Documentación a través de Pro formas Pro forma: Un plan de dos oraciones o reporte que sumariza el documento completo. La primera oración: Se requiere de una maquina de tickets que el usuario la primera vez que la use sea capaz de operarla exitosamente sin entrenamiento previo… La segunda oración: ….. Nosotros intentamos llevar a cabo un examen de laboratorio de la maquina para confirmar que por lo menos un 95% de los usuarios pueden completar normalmente su compra sin dificultad. También es util en la documentación el análisis de usabilidad por ejemplo, un reporte de análisis: Se requiere que el paquete de graficación produzca una secuencia de copias de planos, la cual debe tomar un tiempo mínimo de preparación. Nosotros hemos establecido un conjunto de predicciones de tiempo-rendimiento para los pasos en la tarea de graficar los planos,y y han mostrado que cada plano tomara al usuario aproximadamente 40 segundos

Ejemplos de Planes de Pro formas y Reportes Chequeo informal de una herramienta de dibujo para pantallas grandes (basado en Pedersen et al., 93): Se requiere una herramienta de dibujo para pantallas grandes que pueda mantener y aumentar las prácticas de reuniones informales normales. Nosotros proponemos confirmar que reúne los requerimientos en un chequeo de usuarios informales. Este es un requerimiento de la herramienta de dibujo para pantalla grande que ella debe mantener y aumentar las practicas de reuniones informales normales. Nosotros hemos conducido examen informales a los usuarios que confirman la utilidad de la herramienta pero indica la complejidad de la interface del usuario disuade a algunos usuarios potenciales.

Ejemplos de Planes de Pro formas y Reportes La evaluaciones de un ambiente de video (Gaver et al., 92) Es un requerimiento del ambiente de video que colegas físicamente separados fueran capaces de trabajar juntos natural y efectivamente. Nuestra intención es montar una prueba de campo continua para determinar la efectividad del ambiente en el soporte de trabajo distribuido. Es un requerimiento del ambiente de video que los colegas físicamente separados sean capaces de trabajar juntos,de una manera efectiva y natural. Nosotros hemos llevado a cabo una prueba de campo la cual se extendió por varios años, la cual ha generado un numero de descubrimientos, identificando la necesidad de soportar el rango completo de trabajo compartido y conocer los deseos de los usuarios para ambas privacidad y percepción completa.

Ejemplos de planes Pro Forma y Reportes Pruebas controladas de una maquina rápida de tickets de transito: Se requiere de la maquina de ticket que los usuario la primera vez que la use sea capaz de operarla exitosamente sin entrenamiento previo. Nosotros intentamos llevar a cabo un examen de laboratorio de la maquina para confirmar que por lo menos un 95% de los usuarios pueden completar normalmente su compra sin dificultad. Se requiere de la maquina de ticket que los usuario la primera vez que la use sea capaz de operarla exitosamente sin entrenamiento previo. Nosotros hemos llevado a cabo un examen de laboratorio de la maquina para confirmar que por lo menos un 94% de los usuarios pueden completar normalmente su compra en menos de 60 segundos.

Prototipo Los prototipos son comúnmente chequeados durante el diseño del sistema interactivo. Los prototipos deben tener propiedades especiales. Dominados por la necesidad de Diseñar e implementar una interfaz del usuario completa, de tal manera que el sistema pueda ser chequeado externamente con tareas validas. Y para hacer esto con restricciones de tiempo, haciendo uso de herramientas de prototipos apropiadas.

Herramientas para construcción Prototipos Características deseables, identificadas por Hix y Hartson(1993) Fácil de desarrollar y modificar apariencias de las pantallas. Facilidad de enlazar pantallas y modificar los enlaces. Servir de soporte para un rango de tipos de interfaces de usuarios. Servir soporte para una variedad de dispositivos de entrada. Proveer los medios para usar programas externos y acceder textos, gráficos y otros medios externos. La herramientas que ofrecen estar características incluyen Hypercard, Visual Basic, Tcl/tk

Aprendiendo mientras se realiza el prototipo Por ejemplo: ¿Que tan grande debe ser una caja para que se acomoden nombres de 24 caracteres? ¿Que problemas surgen al usar un menú unido a una caja?

Prueba informal del prototipo Considere el siguiente problema de diseño: Diseñe un equipo manual, interactivo que sirva de soporte al usuario para que rápida y fácilmente grabe y reproduzca los mensajes de voz. Una prueba informal nos habilitara a responder la siguiente pregunta: ¿Que tan exitosa es la herramienta de reconocer mensajes de acuerdo a una categoría de nombres? ¿Cómo la rata del reconocimiento es afectada por el número de categorías en uso? ¿Qué clases de errores hace debido al ruido del ambiente? ¿Es afectado por el tono de la voz de los usuarios? ¿Es lo suficientemente rápida en la operación para q se prefiera en lugar de un registrador de microcassette? ¿? ¿Es fácil aprender utilizar?

Conduciendo una prueba informal Las seis etapas son afectadas: Identificar las características principales. Nos centramos en las características identificadas en la declaración del problema o en los primeros documentos sobre los requisitos. 2. Desarrollar el prototipo. Todo lo que necesitamos es un prototipo que (a) tiene las funciones para apoyar las tareas del interés (b) tiene el funcionamiento para permitir una prueba realista (c) tenga bastante robustez para sobrevivir cada prueba sin fallar seriamente. 3. Diseño experimental. Necesitamos un número pequeño de los usuarios, a quienes fijamos una gama conveniente de las tareas de prueba patrón, elegido para probar la funcionalidad del prototipo tan completa como sea posible. 4. Recoger datos. La observación directa y la grabación de videos y los protocolos concurrentes son especialmente efectivos. 5. Análisis de datos. Las buenas y malas características del diseño serán probablemente obvias enseguida; podemos también tomar medidas de rendimiento simples. 6. Conclusiones finales. El resultado primario de la prueba informal es una lista de los cambios del diseño.

Caso de Estudio Una herramienta colaborativa de dibujo Bly and Minneman (1990). B: Bien, eso está Ok, eso luce como A: El cual es B: este. A: Cuál es, si usted toma su caja azul B: huh A y observe que la izquierda superior de la caja. De abajo hacia la derecha, es una línea diagonal DIBUJA NDO B: La derecha. A: entre estos dos. Lo que me distes es el punto de partida oooh, es la versión de adentro -hacia fuera. Lo siento, tu tienes razón B: Entonces yo hago esto por que yo quiero que el míos sea estrecho. Bien, solamente dibújalo mejor de lo que yo acabo de hacer

Pruebas de campo iterativas La importancia de ganar la participación del usuario La necesidad de considerar las seis etapas 1. Identificar las propiedades principales Retrasar este paso hasta que hemos desarrollado el prototipo, hemos identificado nuestros usuarios y hemos instalado el sistema Entonces conduzca las investigaciones según las características de lo que nos concierne Evite confundir a los usuarios cambiando constantemente el sistema.

Pruebas de campo iterativas (continuación) 2. Preparando el prototipo Un prototipo a full escala, dirigido a los niveles adecuados de la confiabilidad y del funcionamiento Apropiado para modificarlo a medida que la prueba de campo está en proceso Los problemas con el diseño serán descubiertos durante el proceso de hacer el prototipo. Incluya un tiempo para corregirlos.

Pruebas de campo iterativas (continuación) 3. Diseño del experimento Planee invertir una cantidad muy grande de esfuerzo en identificar a usuarios y planear sus tareas? Necesite encontrar una organización conveniente del usuario y ganar su compromiso con la evaluación.Implica normalmente la aprobación del alto nivel de la gerencia Identifique a un grupo de usuario, introdúzcalo al proyecto asegure su compromiso también.Evite a grupos de trabajos altamente críticos para la organización Deber preparase para correr los dos sistemas el nuevo y el viejo en paralelo

Pruebas de campo iterativas (continuación) 3. Diseño del experimento Selección de actividades a realizar: debe acercarse tanto como sea posible a la clase de actividad para la cual se ha diseñado el sistema. Las actividades deben también proporcionar oportunidades de conducir experimentos y de variar la manera en la cual la actividad es realizada

Pruebas de campo iterativas (continuación) 4. Realización de las pruebas Los usuarios deben ser bien entrenados antes de que se realicen las pruebas; dé un tiempo de plazo, para este entrenamiento Asegúrese que el sistema está preparado adecuadamente con los datos Haga pruebas al inicio, para medir que tan rápido los usuarios aprenden e identificar los problemas de familiarización Realice otras pruebas más adelante cuando los usuarios están completamente familiarizados con el sistema y han comenzado a ajustarse a sus prácticas del trabajo.

Pruebas de campo iterativas (continuación) 5. Análisis Enfocarse en antes y después de la investigación Por ejemplo, medir la mejoría en el rendimiento de las tareas y en la reducción en errores a medida que los usuarios ganan familiaridad Buscar efectos similares a medida que los cambios se le hacen al diseño

Pruebas de campo iterativas (continuación) 5. Análisis Derivando conclusiones Permita la posibilidad de cambios inmediatos en el diseño Algunos cambios se deberán posponer para futuros proyectos

Caso de Estudio: Evaluando a Tívoli,una herramienta de soporte para reuniones Ver Pedersen et al. (1993). Los pizarrones electrónicos Tivoli se encuentran en tres localidades No se tomó ninguna acción especial para entrenar a los usuarios Conclusiones básicas Se lograron reuniones exitosas con Tivoli Se usó con frecuencia en reuniones de lluvias de ideas Trabajo lo suficientemente bien como para justificar una versión Multi-sitios Pero tiende a ser usado por un participante de la reunión, los diseñadores erraron al incrementar la funcionalidad

Caso de Estudio: Evaluando a Tívoli,una herramienta de soporte para reuniones. Ver Pedersen et al. (1993). Un resumen pro-forma: Es un requisito de Tivoli que debe permitir la intervención de varios participantes, Hemos conducido pruebas informales con usuario que confirman la utilidad de la herramienta pero indican que la complejidad de la interfaz, disuade a algunos usuarios potenciales, y conduce a una práctica en la cual todo el uso lo realiza un miembro de la reunión.

Tarea Ejercicios 1, 4, 6 y 7