Proceso de Diseño de Interfaces

Slides:



Advertisements
Presentaciones similares
U.M.L A/Gx. Diego Gutiérrez Application Analysis and Design.
Advertisements

Sección 1 Configuración y Tablas Básicas
UML DCU -DS Alvaro Garrido V..
SISTEMAS DE GESTIÓN DE LA SEGURIDAD DE LA INFORMACIÓN
También conocido como Diseño Lógico Rodrigo Salvatierra Alberú.
Unidad 1 DISEÑO DE ALGORITMOS ING. Nelwi Baez. MSC
TEMA 8: DIAGRAMAS EN UML.
CLIENTE / PROVEEDOR.
METODO DE ANALISIS DE FALLAS
Gestión de proyectos Es la primera etapa de Ingeniería del Software.
Resolución de Problemas Algoritmos y Programación
Ciclo de desarrollo del software
DECISIONES DE MERCADOTECNIA “Proceso de la toma de decisiones”
CÓMO REALIZAR UN PROYECTO
Prof. César Luza Montero
INGENIERIA DE REQUERIMIENTOS
TALLER DE TRABAJO FINAL
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Aspectos Avanzados de la Tecnología de Objetos
Evaluación de Productos
Diseño de un Sistema de Control en Tiempo Real para el Kernel del Sistema Operativo utilizando MatLab-SimuLink Por: MARCO ANTONIO ESPINEL CANGUI DIRECTOR:
Desarrollo Orientado a Objetos con UML
Manual del Usuario Perfil 03. Reportes Web. Ver. 1.1
DSOO - María Eugenia Valencia
Buneder poblete karim david Saldaña ortiz alejandro ssd4
“Especificación de Requerimientos”
Propuesta de una metodología para el desarrollo de proyectos informáticos empleando la herramienta para el diseño automatizado GeneXus Autor: Dipl.-Ing.
Ing. Héctor Abraham Hernández Erazo
DISEÑO DE LA INTERFAZ DE USUARIO
Ingeniería de Software Orientado a Objetos
DISEÑO DE SOFTWARE 1ª. Parte
Técnicas para la obtención de requerimientos
Las etapas de un proyecto
Módulo 12 Herramienta de aseguramiento de la calidad del PSA 1.
Análisis y Diseño Orientado a Objetos utilizando UML
REQUERIMIENTOS DE SOFTWARE
Unidad VI Documentación
Contexto Proyecto consolidado dentro de la línea de investigación de Sistemas de Información en el Dpto. de Ingeniería en Sistemas de Información de la.
Metodología para el desarrollo de Software educativo POO
WEBQUEST. ¿QUÈ ES UNA WEBQUEST?  Webquest significa indagación, investigación a través de la Web.  Consiste en presentarle al alumnado un problema,
Herramientas básicas Control de Calidad.
Metodología para solución de problemas
Evaluación de Sistemas y de sus Interfaces
Plan de Sistemas de Información (PSI)
INGENIERÍA DE SOFTWARE
CICLO DE VIDA Y NORMAALIZACION DE UN SISTEMA DE BASE DE DATOS
Programa de Auditoría Interna
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.
Christian Monrreal Gonzalez Daryl Silverman Aguilar Gone
COMPLETA LOS ESPACIOS CON LA PALABRA ADECUADA 1.LOS _______________________ SE DEFINEN COMO LA _________________LÓGICA DE _________PARA SOLUCIONAR UN.
Roles de Open UP.
Introducción al proceso de verificación y validación.
CICLO DE VIDA CLÁSICO DE UN SISTEMA
Actividades en el Proceso de desarrollo de Software
ANÁLISIS ESTRUCTURADO
Utilizar Costo Promedio Ponderado en el Software Administrativo SAW
EduCat Prototipos. Introducción En las próximas páginas se muestra un bosquejo de lo que será la interfaz gráfica de nuestro programa, EduCat, para los.
Proceso de Diseño de Interfaces
problemas de la calidad del software
REVISION Y AUDITORIA.
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
Computer Assisted Audit Techniques (CAATs)
Marco de Trabajo para Indexación, Clasificación y Recopilación Automática de Documentos Digitales Javier Caicedo Espinoza Gonzalo Parra Chico.
Fundamentos de Computación
Taller de investigación 1
Plan de Pruebas de Aceptación
Entregables del Proyecto
1 PRESENTACIÓN DE PRODUCTO SISTEMA DE ADMINISTRACIÓN DE BIENES INMUEBLES Y BIENES MUEBLES.
Transcripción de la presentación:

Proceso de Diseño de Interfaces

Diseño centrado en el usuario “Diseño para los usuarios” Involucra a los usuarios como parte integral del equipo de diseño “Feedback” de los usuarios Test iterativo de las ideas y prototipos Requiere que el equipo de diseño incluya especialistas en usabilidad No implica delegar la responsabilidad de la interfaz en los usuarios

Principales Fases Análisis Diseño Construcción Comprensión de los usuarios, tareas y objetos de la futura interfaz Requerimientos de la interfaz Diseño Definición de la “forma” de la interfaz Estructura (objetos y acciones) de la interfaz Construcción Creación y test de los prototipos Detección de problemas de usabilidad Documentación del prototipo, para su implementación por el equipo de desarrollo

Análisis Identifica las tareas, información, conceptos, y terminología utilizada por los usuarios Propósito: Documentar y verificar la información acerca de: Usuarios Forma de trabajo actual Forma de trabajo esperada con el nuevo sistema

Análisis Resultados: Equipo de Análisis Perfiles de los usuarios Análisis de las tareas actuales Descripciones de las tareas futuras Especificaciones de usabilidad Escenarios de casos de uso Equipo de Análisis Diseñador de interfaces Usuarios / especialistas en el dominio Personal técnico

Proceso de análisis 1. Identificar estado actual y alcance 2. Definir los perfiles del usuario 3. Obtener datos 4. Documentar tareas actuales 5. Documentar problemas y oportunidades 6. Describir las tareas futuras 7. Definir especificaciones de usabilidad 8. Desarrollo de escenarios con casos de uso 9. Testing

Identificar estado actual y alcance Alcance: actividades que permitirá efectuar la interfaz Tareas de alto nivel: Ej. Escribir cheques bancarios,efectuar balances de cuentas bancarias, registrar depósitos,.... Punto de partida para el trabajo de análisis Identificar restricciones de la interfaz Hardware y software disponible, características del proyecto, requerimientos particulares Ejs. Tipo de monitores disponibles Plataformas Estándares de diseño de la empresa

Identificar Estado Actual y Alcance Aplicación “Check-Ease”: Restricciones de Diseño de la Interfaz IBM PC 486 o superiores (clones). Progresivamente, se cambiarán por computadores portátiles Modems con velocidades de 14400 bps. Monitores EGA y VGA. Resolución mínima 640 x 480. Pantallas color y monocromáticas Seguir las guías de MS Windows 95

Definir perfiles de los usuarios “Los programadores no son los usuarios” “Diseñar PARA los usuarios” Describir claramente las características de los usuarios Una clasificación “experto” / “novato” / “frecuente” / “infrecuente” no es suficiente Considerar Experiencia con los ambientes de software y hardware a utilizar Experiencia previa de los usuarios en la realización de las tareas Frecuencia de uso esperada

Definir perfiles de los usuarios Perfil de los usuarios (1) Aplicación: Control de Cheques para PCs Potenciales usuarios: adultos, actualmente utilizando PCs, MS Windows 95, y una cuenta bancaria Experiencia con el Hardware: 100% tiene una PC (o clon). No se comprarán equipos para esta aplicación. 100% tiene un mouse Experiencia con el software e interfaz: Más del 90% está utilizando una aplicación MS Windows95, tal como un procesador de texto o planilla de cálculo. Los usuarios no comprarán ni necesitarán aprender W95 para esta aplicación Menos del 50% ha utilizado anteriormente un modem Experiencia con aplicaciones similares: Menos del 15% está utilizando otra aplicación electrónica de control bancario

Definir perfiles de los usuarios Perfil de los usuarios (2) Experiencia en las tareas: Todos tienen una cuenta bancaria Probablemente sólo el 40% efectúa controles de sus cuentas, los usuarios no son banqueros ni contadores Actualmente, menos del 10% efectúa un control electrónico del banco desde su casa Frecuencia de uso: desde muy baja (cada 2 meses) a baja (2 veces por mes) Requerimientos clave de la interfaz sugeridos por el perfil: Seguir el estilo de interfaz W95 La facilidad de aprendizaje será importante Construirla de acuerdo al modelo mental actual de los controles manuales Proveer un modelo intuitivo para los aspectos del modem No suponer una alta comprensión de los procedimientos de control de su cuenta bancaria

Obtener datos Datos acerca de los usuarios y las tareas desarrolladas Métodos para obtener los datos Entrevistas a los los usuarios en su lugar de trabajo Alternativa no muy costosa Peligros en la descripción de los usuarios: Muy simplificada Información no presente Demasiado nivel de detalle Diferentes interpretaciones Este método debiera ser combinado con los restantes

Obtener datos Simulación de la forma de trabajo con los usuarios (“role playing”) Puede brindar información adicional No se trata exactamente de la situación real, por lo que puede tener los mismos inconvenientes de las entrevistas “Estudios de campo” Observación de usuarios reales en el lugar de trabajo Forma más completa y rápida de obtener los datos Permite observar el contexto de trabajo Ambiente físico, stress, distracciones, ruido, iluminación Consideraciones: Definir claramente los propósitos de la observación Planificar claramente las posibles preguntas con los usuarios Posibilidad de utilizar videos No perturbar, distraer o incomodar a los usuarios en el estudio Solamente recoger datos. No pensar en la posible interfaz!

Documentar las tareas actuales Descripción de tareas manuales, automatizadas o combinadas Objetivo: comprender la forma en la que los usuarios llevan a cabo sus tareas, y el modelo mental que tienen de las mismas Para cada tarea debe describirse: Nombre de la tarea Flujo de tareas (precedentes, siguientes, posibles interrupciones) Dependencias con otras tareas Frecuencia de la tarea Información con la que trabajan los usuarios en la tarea Documentos y herramientas necesarias para efectuar la tarea Elementos resultantes de la tarea Errores y problemas típicos en la tarea Terminología y conceptos Comentarios de los usuarios acerca de la forma en que llevan a cabo la tarea Características del ambiente de trabajo en el que se realiza la tarea

Documentar las tareas actuales Descripción de las tareas desde la perspectiva del usuario. Documentación a producir: Diagramas Descripción detallada de las tareas actuales Muestran principalmente el flujo dentro de la tarea, aunque restringe la cantidad de texto que puede incluirse

Documentar las tareas actuales

Documentar las tareas actuales

Documentar las tareas actuales Documentación a producir Tablas Documenta todos los datos necesarios para crear la interfaz Frecuencia Información necesaria Información ingresada por el usuario Comentarios

Documentar las tareas actuales Ej. Control de cheques (1) #Tarea Tarea Frecu-encia Requisitos de datos en pantalla Requisitos de entrada Comentarios 1.0 Controlar cheques 1.1 Encontrar cheque Alta Número de cheque Fecha Propósito Cantidad Resumen de cuenta del banco Recorrer el resumen de cuenta El resumen está ordenado por número de cuenta, los usuarios pueden buscar por otros parámetros Todos los bancos usan el mismo formato: Fecha-Nro-Cantidad? 1.1.1 Ingresar nuevo cheque Baja ó Modera-da Feedback de datos ingresados Número de Cheque Cobrado? Los usuarios prefieren que los cheques estén ordenados numéricamente

Documentar las tareas actuales Ej. Control de cheques (2) #Tarea Tarea Frecu-encia Requisitos de datos en pantalla Requisitos de entrada Comentarios 1.2 Verificar Alta Igual 1.1 Ninguno 1.3 Indicar si el cheque fue cobrado Indicador de Cobrado o no Estado de cobro del cheque Los usuarios necesitarán remover el cheque (etc)

Documentar las tareas actuales Ej. Pago de Cuentas (1) #Tarea Tarea Frecu-encia Requisitos de datos en pantalla Requisitos de entrada Comentarios 1.1 Obtener el registro de control de cuenta bancaria Alta 1.2 Obtener las Facturas a Pagar 1.3 Sumar las facturas y comparar con saldo actual Ver saldo actual y total de las facturas Sumar cada monto de 1 factura, restar del saldo actual Si el usuario no puede hallar una calculadora, debe hacerlo manualmente 1.4 Decidir si existen suficientes fondos para pagar todas las facturas Ver saldo actual menos el total de las facturas

Documentar las tareas actuales Ej. Pago de cuentas (2) #Tarea Tarea Frecu-encia Requisitos de datos en pantalla Requisitos de entrada Comentarios 1.5 Si no existen fondos suficientes, decidir cuanto se pagará de cada factura Baja Ver saldo actual y total de las facturas Sumar cantidad a pagar de cada facturas, restar del saldo actual Tedioso. Requiere calcular y recalcular el saldo 1.6 Escribir cheques Alta Ver cheques y facturas Escribir cheques, beneficiario, monto numérico, monto textual, firma, fecha 1.7 Ingresar cheques en el registro Ver cheques y registro Escribir numero de cheque, fecha, beneficiario, y monto Redundancia. Escribir cheques y asentarlos en registro 1.8 Calcular nuevo saldo Ver registro Restar cada entrada del saldo actual

Documentar las tareas actuales Documentación a producir Bosquejos Muestra una vista de alto nivel del trabajo actual No proporcionan muchos detalles Útiles para resumir la forma de operación de la tarea Forma visual de representar el ambiente y la localización de los usuarios al realizar las tareas

Documentar las tareas actuales

Documentar problemas y oportunidades Descripción de los principales inconvenientes actuales en la realización de las tareas Tarea: Pago de Facturas - Problemas y Oportunidades Si no se dispone de una calculadora, las sumas y restas deben hacerse mentalmente o manualmente El saldo actual podría no estar actualizado, hay que calcularlo previamente Proceso sujeto a errores: depende de cálculos correctos Es tedioso calcular y recalcular el saldo en cada paso La escritura manual no es buena, las personas pueden leer erróneamente el monto de un cheque Redundancia: se deben escribir los cheques, y luego repetir toda la información en el registro de cheques Sería deseable mantener un conocimiento de lo que se ha gastado en diferentes categorías (alimentación, medicina, etc.)

Documentar problemas y oportunidades Asociar los problemas identificados con las descripciones de las tareas actuales

Documentar problemas y oportunidades

Descripción de las tareas futuras Similar a la descripción de las tareas actuales Descripción en alto nivel de las tareas futuras Diagramas o bosquejos Las tablas proporcionan un mayor nivel de detalle, no necesario en este paso Refinamiento provisto posteriormente por los Escenarios de casos de uso

Descripción de las tareas futuras

Definir especificaciones de usabilidad Definir lo que se entiende por “interfaz usable” en la interfaz a desarrollar Identificar los principales atributos de usabilidad del sistema Ej. Facilidad de aprendizaje Eficiencia Precisión en la tarea Facilidad de uso Generalmente pueden ser obtenidas a partir de: Características del sistema a desarrollar Problemas que intenta solucionar la interfaz a desarrollar Perfiles de los usuarios

Definir especificaciones de usabilidad Para cada atributo, identificar como será medido: Ej. Tiempo para completar una tarea Número de errores en una tarea Facilidad de uso promedio (obtenida por cuestionarios) Para cada medición, indicar los valores aceptables 20 minutos 2 errores 50% con nota 8 o mayor Pueden indicarse niveles mínimos, aceptables. Incluir otros elementos importantes Indicar la información que dispondrá cada usuario en la tarea Indicar documentación a proveer

Definir especificaciones de usabilidad “Check Ease” - Especificaciones de Usabilidad Facilidad de Aprendizaje Sin ningún tipo de entrenamiento, y utilizando solamente la ayuda y documentación online, el 90 % de los usuarios (adultos, comprendiendo el idioma español, actualmente con una cuenta corriente bancaria, actualmente usando otras aplicaciones MS Windows) debiera poder comenzar la ejecución de la aplicación “Check-Ease”, abrir una registro de control de cheques, y registrar un cheque en menos de 15 minutos (la primera vez) Luego de haber completado un tutorial corto (20 minutos o menos), y utilizando la ayuda y documentación online, el 75 %de los usuarios (adultos con una cuenta corriente bancaria, efectúen o no manualmente el control de sus cheques, actualmente usando aplicaciones MS Windows, comprendiendo el idioma español) debiera poder efectuar correctamente un control de su cuenta bancaria.

Definir especificaciones de usabilidad “Check Ease” - Especificaciones de Usabilidad Facilidad de uso Luego de haber comenzado correctamente la ejecución de la aplicación “Check-Ease”, y registrado un cheque al menos 3 veces, el 75% de los usuarios adultos debieran poder efectuar esta tarea en 5 minutos o menos (con PCs 386) Facilidad de Aprendizaje 75% de los usuarios (adultos, con PCs 386, con experiencia en MS Windows, comprendiendo el idioma español) podrán configurar las características del modem de “Check-Ease” en 20 minutos o menos. 90% debiera poder hacerlo en 40 minutos o menos Luego de un tutorial de 20 minutos, y utilizando sólo la ayuda y documentación online, el 90% de los usuarios (adultos, comprendiendo el idioma español, actualmente con una cuenta corriente bancaria, utilizando otras aplicaciones MS Windows) debieran poder pagar sus cuentas en menos de 30 minutos (primera vez)

Definir especificaciones de usabilidad Comportamiento Medible Criterios Elementos clave Usuarios Pagar 10 facturas Menos de 30 minutos la primera vez, y 20 minutos las siguientes veces Disponibilidad de ayuda online y un tutorial de 20 minutos (y el tutorial es usado!) Dominio del español, utilizan aplicaciones MS Windows, con una cuenta corriente bancaria

Escenarios de casos de uso Tareas y subtareas que describen la forma en la que trabajará el usuario con el nuevo sistema de software Ayuda a determinar un flujo correcto de las ventanas en la interfaz Descripciones de las tareas futuras Partes pueden ser implementadas por un (nuevo) sistema de software, pero no necesariamente todas las partes Escenarios de casos de uso Sólo detalla tareas que involucran a la interfaz a desarrollar Vinculación entre la descripción de las tareas futuras y el diseño de la interfaz

Escenarios de casos de uso Escenario de caso de uso: Pago de Facturas con cheques impresos 1. Ingreso de facturas (nombre del beneficiario y fecha de pago) en una planilla 2. Ver el nuevo saldo (saldo actual menos cada monto a pagar) 3. Decidir si existen suficientes fondos para pagar las facturas a. Si existen (80% de las veces), ir al paso 4 b. Si no existen (20%), marcar las facturas que no se pagarán (80%) o cambiar los montos de pago (20%), luego ir al paso 4 4. Indicar al sistema que pague las facturas 5. Colocar las opciones de impresión para los cheques 6. Colocar el papel de impresión de cheques en la impresora 7. Imprimir los cheques 8. Observar los cheques 9. Reimprimir los cheques si existe un problema (30% de las veces) 10. Observar el registro actualizado de la cuenta corriente bancaria (es observado 50% de las veces) 11. Generar reportes (50% de las veces). Nota: para mas detalles, ver escenario de generación de reportes.

Escenarios de casos de uso Guías para el desarrollo de escenarios efectivos Escribirlos desde el punto de vista del usuario, no del sistema El escenario describe un conjunto de tareas del usuario Utilizar como fuente un listado de las tareas del usuario Incluir información acerca de la frecuencia de las tareas y subtareas Las tareas más frecuentes deben ser más fáciles de efectuar Indicar excepciones Indicar claramente las tareas críticas Escribirlos textualmente (en forma clara) Los diagramas pueden ser interpretados de distintas formas, por diferentes personas

Escenarios de casos de uso Los escenarios de casos de uso para diseño de interfaces deben focalizarse en las acciones del usuario Los casos de uso convencionales (ej. Jacobson, UML) generalmente contienen una descripción las acciones realizadas por el software del sistema Ej. Escenario del sistema El usuario ingresa cada factura (nombre del beneficiario y monto) en el sistema. El sistema muestra el nuevo saldo, calculado a partir del saldo actual menos el monto de cada factura ingresada. El usuario puede deseleccionar una factura o cambiar el monto a pagarse. El sistema recalcula el saldo a medida que se efectúan estos cambios. Cuando se procesan las facturas para su pago, el sistema imprime los cheques, actualiza el registro de la cuenta corriente bancaria, y recalcula el saldo.

Escenarios de casos de uso Los escenarios de los diseñadores de la interfaz y del sistema deben ser coordinados. Un mismo escenario puede usarse como base para el caso de uso de la interfaz y el caso de uso del sistema Cooperación entre ambos grupos de trabajo Ambos escenarios deben corresponderse entre sí Pueden diseñarse ambos escenarios al mismo tiempo (o primeramente el escenario de la interfaz)

Escenarios de casos de uso Escenario de Interfaz: Pago de Facturas con cheques impresos Escenario del Sistema: Pago de Facturas con cheques impresos 1. Ingreso de facturas (nombre del beneficiario y fecha de pago) en una planilla 1. El sistema muestra los datos de cada factura: beneficiario, fecha de pago, y cantidad; el sistema muestra el saldo actual en la cuenta corriente bancaria 2. Ver el nuevo saldo (saldo actual menos cada monto a pagar) 2. El sistema recalcula el saldo, al ingresarse cada factura (si es que va a pagarse) 3. Decidir si existen suficientes fondos para pagar las facturas a. Si existen (80% de las veces), ir al paso 4 b. Si no existen (20%), marcar las facturas que no se pagarán (80%) o cambiar los montos de pago (20%), luego ir al paso 4 3. Si el usuario modifica el monto a pagar, mostrar el nuevo monto. Si el usuario elige no pagar una factura, marcarla como no seleccionada. 4. Indicar al sistema que pague las facturas 4. El sistema ingresa las facturas como una entrada en el registro de la cuenta, y recalcula el nuevo saldo

Escenarios de casos de uso Escenario de Interfaz: Pago de Facturas con cheques impresos Escenario del Sistema: Pago de Facturas con cheques impresos 5. Indicar las opciones de impresión para los cheques 5. Mostrar las opciones para la impresión de cheques 6. Colocar el papel de impresión de cheques en la impresora 6. Nada 7. Imprimir los cheques 7. El sistema imprime los cheques 8. Observar los cheques 8. Nada 9. Reimprimir los cheques si existe un problema (30% de las veces) 9. Alertar al usuario acerca del estado de la impresión. Permitir al usuario indicar cuales cheques deben ser reimpresos 10. Observar el registro actualizado de la cuenta corriente bancaria (es observado 50% de las veces) 10. Mostrar el registro de la cuenta bancaria actualizada 11. Generar reportes (50% de las veces). Nota: para mas detalles, ver escenario de generación de reportes. 11. Ver escenario de generación de reportes.

Test Verificación de las actividades llevadas a cabo en el análisis Verificar los perfiles obtenidos de los usuarios Verificar la descripción de las tareas con los usuarios Verificar las especificaciones de usabilidad Verificar los escenarios de casos de uso con los usuarios.