• No se han encontrado resultados

Metodología de Diseño de Software Educativo Infantil Edición Única

N/A
N/A
Protected

Academic year: 2020

Share "Metodología de Diseño de Software Educativo Infantil Edición Única"

Copied!
109
0
0

Texto completo

(1)

(2) METODOLOGÍA DE DISEÑO DE SOFTWARE EDUCATIVO INFANTIL. TESIS MAESTRÍA EN CIENCIAS EN TECNOLOGÍA INFORMÁTICA. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. POR. ELSA JOSEFINA LOZANO DE LA ROSA. MAYO 2000.

(3) METODOLOGÍA DE DISEÑO DE SOFTWARE EDUCATIVO INFANTIL. TESIS MAESTRÍA EN CIENCIAS EN TECNOLOGÍA INFORMÁTICA. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. POR. ELSA JOSEFINA LOZANO DE LA ROSA. MAYO 2000.

(4) METODOLOGÍA DE DISEÑO DE SOFTWARE EDUCATIVO INFANTIL. TESIS. MAESTRÍA EN CIENCIAS EN TECNOLOGÍA INFORMÁTICA. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. POR. ELSA JOSEFINA LOZANO DE LA ROSA. MAYO 2000.

(5) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY DIVISIÓN DE COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES DIRECCIÓN DE PROGRAMAS DE POSGRADO EN ELECTRÓNICA, COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES. Los miembros de comité de tesis recomendamos que la presente tesis de la Ing. Elsa Josefina Lozano de la Rosa sea aceptada como requisito parcial para obtener el grado académico de MAESTRA EN CIENCIAS EN TECNOLOGÍA INFORMÁTICA. Comité de Tesis:. Lic. Moraima Campoell Dávila, MCA ASESORA PRINCIPAL. Lic. Ma. de Lourdes Francke Ramm, MA, MDO SINODAL. Ing. Carlos Maldonado Salazar, MAI SINODAL. Carlos Scheel Mayenberger, PhD. Director de los Programas de Posgrado en Electrónica, Computación, Información y Comunicaciones MAYO 2000.

(6) METODOLOGÍA DE DISEÑO DE SOFTWARE EDUCATIVO INFANTIL. POR. ELSA JOSEFINA LOZANO DE LA ROSA. TESIS. Presentada a la División de Computación, Información y Comunicaciones. Este trabajo es requisito parcial para obtener el grado de Maestra en Ciencias en Tecnología Informática. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY. MAYO 2000.

(7) DEDICATORIAS. A mis padres, Héctor y Pilar, por todo lo que me han dado y por haberme dado la vida. A mi tía Juli, por tu cariño y apoyo. A Myrna, por tantos años de amistad, por tu alegría y tu confianza. A Susana, por tu amistad y tu compañía. A Iris e Isabel, por todo el apoyo que me han dado en diversos momentos de mi vida y por seguir estando tan cerca de mí a pesar de la distancia.. iv.

(8) AGRADECIMIENTOS. A mi asesora Moraima Campbell, por todo tu apoyo, interés, entusiasmo y confianza en mi proyecto de investigación. A mis sinodales Lourdes Francke y Carlos Maldonado, gracias por sus valiosas aportaciones y por el tiempo que dedicaron a mi proyecto. A Lorena Garza por toda la ayuda que me brindaste en la elaboración del prototipo. A mis sobrinas de corazón, Marielita y Nancy, gracias por colaborar en mi proyecto, fue muy agradable trabajar con ustedes.. V.

(9) RESUMEN. El propósito de esta investigación consiste en proporcionar una base para el desarrollo de software educativo infantil de manera que el usuario se involucre durante todo el proceso de desarrollo. El desarrollo de software educativo infantil debe ser un proceso interdisciplinario en el cual deben participar profesionales de diversas áreas, así como también niños como parte fundamental del proceso. La metodología presentada hace adaptaciones a la metodología para diseño de interfaces propuesta en [Garza, 1999]; se basa en el modelo iterativo con prototipos, además se realizan pruebas de usabilidad para comprobar que la aplicación es adecuada a los usuarios. Para validar la metodología se realiza una aplicación de la misma donde se siguen los pasos propuestos para así obtener un prototipo de alto nivel cuyo objetivo es enseñar números y cantidades a niños en edad preescolar.. vi.

(10) TABLA DE CONTENIDO LISTA DE FIGURAS. X. LISTA DE TABLAS. XI. CAPÍTULO 1 INTRODUCCIÓN. 1. 1.1 OBJETIVO 1.2 PROBLEMA 1.3 METODOLOGÍA 1.4 PRODUCTO 1.5 ALCANCE 1.6 JUSTIFICACIÓN 1.7 HIPÓTESIS 1.8 VALIDACIÓN 1.9 LIMITACIONES 1.10 CAPÍTULOS. l 2 2 2 2 2 3 3 3 4. CAPÍTULO 2 METODOLOGÍAS DE DISEÑO DE SISTEMAS. 5. 2.1 CONCEPTO DE SISTEMA COMPUTACIONAL 2.2 PARADIGMAS DE DISEÑO DE SISTEMAS. 5 6. 2.2.1 Metodologías de diseño tradicionales 2.2.1.1 Modelo de cascada 2.2.2 Especificación de requerimientos 2.2.2.1 Prototipeo rápido 2.2.2.2 Técnicas deprototipeo 2.2.3 Modelo iterativo. 6 7 8 8 9 10. 2.3 TÉCNICAS DE DISEÑO. 14. 2.3.1 Diseño participativo 2.3.2 Investigación cooperativa e investigación contextual. 2.4 SISTEMAS FORMATIVOS E INFORMATIVOS 2.5 DISEÑO 1NSTRUCCIONAL. 14 15. 16 17. CAPÍTULO 3 INTERFAZ HUMANO-COMPUTADORA. 18. 3.1 ANTECEDENTES 3.2 CONCEPTOS DE INTERACCIÓN E INTERFAZ HUMANO-COMPUTADORA 3.3 INTERFAZ "AMIGABLE" 3.4 DIVERSIDAD EN LA INTERACCIÓN 3.4.1 Perfil del usuario 3.4.1.1 Antecedentes del usuario 3.4.1.2 Factores 3.4.1.3 Factores psicológicos/cognitivos. fisiológicos/físicos. 3.4.1.4 Factores de uso e interés sobre la aplicación. vii. 18 18 19 19 20 21 22 22. 22.

(11) 3.4.1.5 Factores compuestos 3.4.2 Perfiles de las actividades 3.4.3 Estilos de interacción. 23 23 24. 3.5 DISEÑO DE INTERFAZ. 24. 3.5.1 Modelos de diseño de interfaz 3.5.2 Modelos del usuario. 26 27. CAPITULO 4 APRENDIZAJE INFANTIL Y SOFTWARE EDUCATIVO 4.1 TEORÍAS DEL APRENDIZAJE. 28 28. 4.1.1 Enfoque de Piaget. 30. 4.2 APLICACIONES COMPUTACIONALES EDUCATIVAS. 4.2.1 Logo. 30. 31. 4.3 JUEGOS COMPUTACIONALES 4.4 INTERACCIÓN NIÑO-TECNOLOGÍA 4.5 DESARROLLO COGNITIVO. 32 32 37. 4.5.1 Teoría de Piaget independiente de los estados 4.5.2 Teoría de Piaget dependiente de los estados Período. 4.6 TEORÍA DE DOMAN. 38 39 39. 41. 4.6.1 Aprendizaje de matemáticas. 42. CAPITULO 5 METODOLOGÍA PROPUESTA. 45. 5.1 DEFINICIÓN DEL SISTEMA 5.2 ANÁLISIS COGNITIVO. 45 46. 5.2.1 5.2.2 5.2.3 5.2.4. Análisis del contexto: usuario Análisis de los modelos del usuario Definición de objetivos de aprendizaje Descripción de actividades. 47 49 49 50. 5.3 ANÁLISIS DE LA CONVERSACIÓN. 50. 5.3.1 Elaboración de prototipo de bajo nivel 5.3.2 Identificación de marcas lingüísticas 5.3.3 Traducción de marcas a signos 5.3.3.1 Representación de ideas gráficamente 5.3.3.2 Color 5.3.3.3 Sonido 5.3.3.4 Animación 5.3.3.5 Video 5.4 ANÁLISIS SEMIÓTICO 5.4.1 Selección y carácter de los signos 5.4.2 Dimensiones semióticas. 51 51 51 52 52 52 53 53 54 54 54. 5.5 ELABORACIÓN DE PROTOTIPO DE ALTO NIVEL 5.6 PRUEBAS DE USABILIDAD. 55 55. CAPITULO 6 APLICACIÓN DE LA METODOLOGÍA. 57. 6.1 DEFINICIÓN DEL SISTEMA. 57. 6.2 ANÁLISIS COGNITIVO. 57 viii.

(12) 6.2.1 Análisis del contexto: usuario 6.2.2 Análisis de los modelos del usuario 6.2.3 Definición de objetivos de aprendizaje 6.2.4 Descripción de actividades. 58 59 59 60. 6.3 ANÁLISIS DE LA CONVERSACIÓN. 61. 6.3.1 Elaboración de prototipo de bajo nivel 6.3.2 Identificación de marcas lingüísticas 6.3.3 Traducción de marcas a signos 6.3.3.1 Representación de ideas gráficamente 6.3.3.2 Color 6.4 ANÁLISIS SEMIÓTICO 6.5 ELABORACIÓN DE PROTOTIPO DE ALTO NIVEL 6.6 PRUEBAS DE USABILIDAD. 61 61 62 62 62 63 66 70. CAPITULO 7 CONCLUSIONES Y TRABAJOS FUTUROS 7.1 7.2 7.3 7.4 7.5 7.6. 71. EXPERIENCIAS CON COLEGIOS EXPERIENCIAS CON DESARROLLADORES EXPERIENCIAS CON NIÑOS EXPERIENCIAS DE LA APLICACIÓN DE LA METODOLOGÍA CONSIDERACIONES GENERALES TRABAJOS FUTUROS. 71 72 73 73 74 74. ANEXO 1: ESTUDIO DE CASOS CENTROS EDUCATIVOS. 76. ANEXO 2: ENCUESTA CENTROS EDUCATIVOS. 81. ANEXO 3: ESTUDIO DE CASOS DESARROLLADORES DE SOFTWARE. 82. ANEXO 4: ENCUESTA DESARROLLADORES. 85. ANEXO 5: OBSERVACIÓN DE USUARIOS POTENCIALES. 86. ANEXO 6: GUÍA DE OBSERVACIÓN. 88. ANEXO 7: PROTOTIPO DE BAJO NIVEL. 90. BIBLIOGRAFÍA. 92. VITA. 95. ix.

(13) LISTA DE FIGURAS FIGURA 2.1: MODELO DE CASCADA DE DESARROLLO DE SISTEMAS FIGURA 2.2: ALTERNATIVA DE PROTOTIPOS PARA LAS PRE-ESPECIFICACIONES [CONNELL, 1995] FIGURA 2.3 PROTOTIPO THROWA WA Y DENTRO DE LA ESPECIFICACIÓN DE REQUERIMIENTOS [Dix, 1998] FIGURA 2.4 PROTOTIPO INCREMENTAL DENTRO DEL CICLO DE VIDA [Dix, 1998] FIGURA 2.5 PROTOTIPO EVOLUTIVO A TRAVÉS DEL CICLO DE VIDA [Dix, 1998] FIGURA 5.1 METODOLOGÍA PROPUESTA PARA DESARROLLO DE SOFTWARE INFANTIL FIGURA 5.2 ANÁLISIS COGNITIVO FIGURA 5.3 ANÁLISIS DE LA CONVERSACIÓN FIGURA 5.4 ANÁLISIS SEMIÓTICO FIGURA 6.1 PANTALLA PRINCIPAL FIGURA 6.2 PANTALLA DE SELECCIÓN DE OBJETOS PARA LAS LECCIONES FIGURA 6.3 PANTALLA DE EJERCICIOS. X. 7 8 10 11 11 46 46 49 52 66 67 68.

(14) LISTA DE TABLAS TABLA 4.1 PERÍODOS DEL DESARROLLO DE JEAN PIAGET. xi. 39.

(15) 1 CAPITULO 1. INTRODUCCIÓN La intervención del usuario dentro del proceso de diseño de software es una consideración importante de la filosofía de Interacción Humano-Computadora (HCI). Las diferentes personas involucradas en el proceso de diseño de interfaces proveen valiosa información que puede contribuir en gran medida a la realización de un proyecto computacional. Para diseñar la interfaz de un sistema utilizando la filosofía centrada en el usuario, se realiza un análisis previo, estudiando tanto al usuario, revisando aspectos como edad, sexo, habilidades físicas, educación, motivación y personalidad, así como su actividad y las tareas por las que éste tiene interés de realizar. Generalmente las personas que diseñan "asumen" lo que el usuario necesita o piensa; sin embargo, en realidad están diseñando de acuerdo a lo que ellos mismos (los diseñadores) quisieran, lo cual es totalmente erróneo [Azar, 1996 y Campbell, 1998]. Un conjunto de metodologías han sido desarrolladas actualmente para observar y entender a los adultos como usuarios de tecnología. En general éstas se utilizan en ambientes de trabajo donde se definen claramente las ideas para un producto de usuario final. Las metodologías de observación y participación no toman en cuenta la dificultad en el estudio de la interacción entre niños y tecnología, la cual está en un constante cambio [Druin, 1998]. Cuando se diseña un producto multimedia para médicos, se piensa que es un "crimen" no incluir un número representativo de médicos en el proceso de diseño y pruebas del sistema. Desafortunadamente, no se ve ese "crimen" cuando se diseñan productos de software para niños. Debe recordarse que los niños no son sólo "adultos pequeños", no se pueden modificar las iníerfaces de software y hardware creados para adultos y esperar que éstos sean valiosos para niños [Druin, 1996a]. 1.1 Objetivo Determinar los factores que intervienen en el proceso de diseño de una herramienta multimedia para niños, analizando la contribución de los niños dentro de este proceso, particularmente revisando las metodologías existentes para adultos y la posibilidad de adaptación de las mismas al entorno infantil..

(16) 2. 1.2 Problema Al desarrollar aplicaciones computacionales para niños por lo general éstos no son tomados en cuenta dentro del proceso de diseño; además el software utilizado por niños mexicanos es en gran medida una traducción del software diseñado para el mercado extranjero, debido a esto, el niño tiene que ajustarse o adaptarse a un tipo de cultura que no le corresponde.. 1.3 Metodología Esta investigación es cualitativa ya que se basa en información recopilada por medio de entrevistas y revisión de información bibliográfica. La metodología a seguir es la siguiente: • Investigación bibliográfica sobre metodologías de desarrollo de software, interfaz humano-computadora, aprendizaje infantil y software educativo. • Investigación de campo mediante entrevistas a maestros de computación en centros educativos. . Revisión de adaptaciones realizadas a las metodologías de diseño para adultos, al diseñar aplicaciones para niños. • Entrevistas a desarrolladores de software sobre las metodologías utilizadas al desarrollar software infantil en México. • Definición de los factores que intervienen en el proceso de diseño de software infantil. • Generación de una metodología de diseño de software para niños. • Aplicación de la metodología en un caso práctico. 1.4 Producto El producto de esta investigación es una metodología de diseño de software adaptada al entorno infantil, en la cual se toma en cuenta la intervención del niño dentro del proceso de diseño. 1.5 Alcance Mediante el análisis de los factores que intervienen en el proceso de diseño de una herramienta multimedia para niños se fomentará el desarrollo de aplicaciones de software infantiles en México, además se apoyará a los diseñadores con una metodología de diseño adecuada para niños..

(17) 3 1.6 Justificación Los niños viven en un mundo de adultos. La mayoría de las cosas están hechas por y para adultos. El niño debe desenvolverse en un ambiente que por lo general "le queda grande", ya sea hablando de su estatura o capacidad tanto física como mental. Los niños han sido generalmente "olvidados" por los adultos al momento de desarrollar la tecnología. Los adultos asumen que por el hecho de que fueron niños hace ya una buena cantidad de años pueden recordar lo que pensaban o sentían en aquella época de su vida. Respecto a la tecnología, muchas veces los adultos hacen suposiciones de que a los niños les gustaría tal o cual característica dentro de la interfaz del software, en lugar de hacer el análisis involucrando a los usuarios propiamente dichos, los niños. En México es muy poco el software que se desarrolla para niños, por lo que la presente investigación propone un modelo que involucre al niño dentro del proceso de diseño, el cual sea válido dentro del contexto cultural y social mexicano. 1.7 Hipótesis En el proceso de diseño de aplicaciones de software infantil es indispensable la intervención del niño. 1.8 Validación Se realizará una aplicación de la metodología propuesta en un caso práctico. 1.9 Limitaciones • Se hace un análisis de los factores que intervienen en el proceso de diseño de interfaz del usuario, no del sistema en general. • Existen diferentes metodologías para el diseño de interfaces, pero adaptación se realiza en base a la metodología propuesta en [Garza, 1999]. • La muestra de colegios encuestados es pequeña y sólo incluyó colegios privados del área metropolitana de Monterrey, N.L..

(18) 4. 1.10 Capítulos La tesis se encuentra dividida en siete capítulos, que se describen a continuación: Capítulo 1. Introducción. Capítulo 2. Metodologías de diseño de sistemas Se explican brevemente algunas de las metodologías de software existentes y las adaptaciones que se han hecho a las mismas para desarrollar software infantil.. Capítulo 3. Interfaz Humano-Computadora Se explican los conceptos principales en los que se basa la filosofía de diseño de interfaces centrada en el usuario.. Capítulo 4. Aprendizaje infantil y software educativo Se exponen las bases en las que se fundamentan las principales teorías sobre el aprendizaje infantil.. Capítulo 5. Metodología propuesta Se explican las diferentes etapas de la metodología que se propone para diseño de software infantil.. Capítulo 6. Aplicación de la metodología Se realiza un aplicación de la metodología propuesta en un caso práctico.. Capítulo 7. Conclusiones Se presentan las conclusiones obtenidas del proceso de investigación realizado, también se mencionan los trabajos futuros que se pueden realizar en torno a este tema..

(19) 5. CAPITULO 2. METODOLOGÍAS DE DISEÑO DE SISTEMAS "Los humanos pueden hacer cosas en diferentes formas. La forma particular de hacer algo en forma conjunta es un diseño. Si una forma de hacer algo produce un resultado más satisfactorio que otro, algunos diseños pueden ser mejores que otros" [Martin, 1996].. 2.1 Concepto de sistema computacional Para hablar sobre metodologías de diseño de sistemas, primero debemos definir qué es un sistema computacional. En [Pressman, 1998] se menciona la definición del diccionario Webster sobre un sistema basado en computadora: Un sistema basado en computadora es un conjunto o arreglo de elementos que están organizados para realizar un objetivo predefinido procesando información. El objetivo puede ser soportar alguna función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema: • Software: Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método lógico, procedimiento o control requerido. • Hardware: Dispositivos electrónicos que proporcionan capacidad de cálculo y dispositivos electromecánicos que proporcionan una función externa. . Personas: Usuarios y operadores del hardware y software. « Base de datos: Colección de información organizada que se accesa por medio del software. • Documentación: Manuales, formularios y otra información descriptiva que retrata el empleo y operación del sistema. . Procedimientos: Pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema..

(20) 6. 2.2 Paradigmas de diseño de sistemas Cuando se desarrolla un sistema computacional es necesario seguir una serie de pasos para llevar a cabo las actividades del proceso de desarrollo. Existen diversos paradigmas de diseño, los cuales han ido evolucionando a través del tiempo. Debe establecerse una diferencia entre metodologías y técnicas de diseño. Según [Sawyer, 1998], una metodología representa un conjunto de tareas y su secuencia para definir los procesos de producción. Las técnicas son conjuntos de acciones llevadas a cabo para completar una tarea en particular. Típicamente, una metodología se divide en muchas técnicas y una herramienta provee automatización o estructura a una técnica. Entre las metodologías se encuentran: . Cascada. . Iterativa. • Orientada a objetos. • Cleanroom. • Rapid Application Development (RAD). Algunas técnicas de diseño: . Diseño participanvo. . Prototipeo rápido. • Ingeniería de requerimientos. • Herramientas estructuradas. • Joint Application Development (JAD). Herramienta de diseño: • Computer-Aided Software Engineering (CASE). 2.2.1 Metodologías de diseño tradicionales La mayor parte de los métodos de diseño tradicionales de software evolucionaron en los 1960's y 1970's, éstos se enfocaban principalmente a la conversión de sistemas manuales a sistemas electrónicos. Por lo tanto, el diseño de software se orientaba más hacia la duplicación de los sistemas manuales existentes en lugar de rediseñar esos sistemas para aprovechar los beneficios computacionales [Mullin, 1990]. En [Dewitz, 1996] se menciona que las metodologías de diseño tradicionales se desarrollaron cuando la tecnología de información consistía en minicomputadoras y mainframes, las cuales era accesadas por terminales "tontas"; en esa época casi todos los accesos a los datos requerían la intervención del especialista en sistemas de información. Actualmente los usuarios son más demandantes en el acceso a los recursos de información y requieren un diseño de sistemas muy diferente al utilizado en los 1970's y principios de los 1980's. Esto ha revelado varios problemas con las metodologías de desarrollo tradicionales:.

(21) 7. • Las técnicas estructuradas no se adaptan al modelo de los requerimientos de los sistemas de actuales. • Las metodologías de desarrollo tradicionales son muy costosas y consumen demasiado tiempo. • Las metodologías de diseño tradicionales son inflexibles para proyectos grandes. 2.2.1.1 Modelo de cascada El modelo de cascada (Figura 2.1) es un paradigma de diseño de sistemas tradicional, en el cual cada etapa debe terminarse antes de empezar con la siguiente. Ésta es una de las principales desventajas del modelo, ya que no hay retroalimentación por parte de los usuarios para poder regresar a una etapa anterior y rehacerla o modificarla.. Figura 2.1: Modelo de cascada de desarrollo de sistemas En [Pressman, 1998] se menciona que el modelo de cascada es el paradigma más antiguo y más extensamente utilizado en la ingeniería de software. Sin embargo, presenta algunos problemas: • Los proyectos raras veces siguen el modelo secuencial que propone el modelo. • A menudo es difícil que el cliente exponga explícitamente todos los requisitos al inicio del proyecto..

(22) 8. El cliente debe tener paciencia. Una versión de trabajo del programa no estará disponible hasta que el proyecto esté muy avanzado. 2.2.2 Especificación de requerimientos Durante la fase de especificación de requerimientos del sistema el diseñador y el cliente tratan de realizar una descripción de qué es lo que se espera que haga el sistema [Dix, 1998]. La especificación de requerimientos requiere de comunicación humana. Lo primero que debe hacerse es que los clientes y los diseñadores entiendan los problemas de trabajo y el impacto de las soluciones técnicas [Holtzblatt, 1995]. Un proceso exitoso de especificación de requerimientos incluye una relación efectiva entre los clientes, los diseñadores y miembros del equipo de trabajo. Este proceso requiere de comunicación entre personas que no tienen los mismos antecedentes o experiencias. Las técnicas deben considerar las dinámicas interpersonales y las diferencias de idiosincrasia para lograr entender completamente el problema del cliente y las soluciones potenciales [Holtzblatt, 1995]. 2.2.2.1 Prototipeo rápido Una de las técnicas utilizadas en la fase de especificación de requerimientos es el prototipeo rápido. Si los usuarios supieran cuáles son sus requerimientos desde el inicio del proyecto de desarrollo y si los desarrolladores estuvieran perfectamente habilitados para entender los requerimientos de los usuarios y traducirlos en especificaciones de software, entonces sería necesario únicamente buenos paradigmas de modelación estáticos [Connell, 1995]. Un prototipo rápido es la representación del concepto de un producto mediante un diseño visual en papel, diapositivas o pantallas. El prototipo provee una base para el diálogo mucho más efectivo entre desarrolladores y usuarios que el texto o los modelos estáticos [Druin, 1996 y Connell, 1995]. Los prototipos se utilizan cuando se quiere mostrar a los usuarios un modelo de trabajo para ayudarlos a entender mejor las características y funciones del nuevo sistema. Observando un modelo de trabajo del sistema, los usuarios son más capaces de especificar lo que necesitan que el sistema haga y saber cuándo lo está haciendo correctamente [Dewitz, 1996]. El prototipeo rápido es usado para ayudar a determinar la funcionalidad de la aplicación, estructura de datos y características de control de un sistema [Connell, 1995]..

(23) 9. En [Connell, 1995] se menciona que un prototipo rápido tiene las siguientes características: • • • •. Se construye rápidamente • Los usuarios pueden probar el sistema y dar retroalimentación Es fácil de modificar Al inicio es intencionalmente incompleto. La figura 2.2 indica que se debe realizar un análisis rápido de la intersección entre los requerimientos pre-especificados por el usuario y los requerimientos reales, para entonces construir un prototipo de esta especificación que es intencionalmente incompleta y luego proceder con la definición de requerimientos a través de un proceso iterativo [Connell, 1995].. Figura 2.2: Alternativa de prototipos para las pre-especifícaciones [Connell, 1995] 2.2.2.2 Técnicas de prototipeo En [Dix, 1998] se describen algunas técnicas disponibles para producir prototipos rápidos. • Storyboards: Probablemente la noción más simple de un prototipo es el storyboard, el cual es una descripción gráfica de la apariencia exterior del sistema propuesto, sin tener alguna funcionalidad. Los Storyboards no requieren muchos recursos computacionales para construirlos, de hecho, pueden ser modelados sin ayuda de una computadora. Los Storyboards proporcionan una imágenes instantáneas de la interfaz en puntos particulares de la interacción. Evaluar las impresiones del.

(24) 10. cliente o usuario pueden determinarse relativamente rápido si el diseño se dirige en la dirección correcta. Los paquetes computacionales de dibujo existentes en la actualidad hacen posible crear storyboards con la ayuda de la computadora en lugar de hacerlos manualmente. Aunque el diseño gráfico factible en la pantalla puede parecer poco sofisticado, es más realista porque al final tendrá que ser desplegado en una pantalla. También es posible proporcionar animación mediante una secuencia de imágenes instantáneas. La animación ilustra los aspectos dinámicos de la interacción del usuario con el sistema la cual no puede ser posible mediante los storyboards basados en papel. Simulaciones de funcionalidad limitada: Para demostrar las funciones de la aplicación se debe tener más funcionalidad en el prototipo. Los storyboards y las técnicas de animación no son suficientes para este propósito ya que no pueden describir los aspectos interactivos del sistema. Para hacer esto, cierta parte de la funcionalidad debe ser simulada por el equipo de diseño. Las herramientas que permiten hacer estas simulaciones proporcionan al diseñador la capacidad de construir rápidamente objetos de interacción de texto y gráficas además de agregar cierto funcionamiento que simule la funcionalidad del sistema. Una vez que la simulación se haya construido, puede ser evaluada y cambiada rápidamente para reflejar los resultados del estudio de evaluación con varios usuarios. Apoyo con programación de alto nivel: Algunos lenguajes de programación de alto nivel facilitan la tarea del diseñador para programar ciertas características de un sistema interactivo a costa de otras características del sistema como la velocidad de respuesta o el ahorro de espacio. Estos lenguajes de alto nivel permiten al programador agregar funcionalidad a las interacciones específicas que el usuario será capaz de realizar, como posicionarse en un botón de la pantalla y darle un click con el ratón. 2.2.3 Modelo iterativo Las herramientas de prototipeo se han vuelto más sofisticadas a través del tiempo. Debido a esto ha surgido el modelo iterativo, donde el prototipo puede elaborarse mediante herramientas de prototipeo, con lo cual la retroalimentación del usuario puede efectuarse durante todo el proceso de desarrollo [Druin, 1996]. Los requerimientos para un sistema interactivo no pueden ser especificados completamente desde el inicio del ciclo de vida. La única forma de asegurarse sobre algunas características del diseño potencial es construirlo y probarlo con usuarios reales. Entonces el diseño puede modificarse para corregir cualquier suposición falsa que sería revelada en las pruebas. Ésta es la esencia del diseño iterativo, un proceso de diseño que trata de resolver problemas de requerimientos incompletos realizando varios diseños, mejorando en forma incremental acercándose hacia el producto final en cada paso [Dix, 1998]..

(25) 11 Desde la perspectiva técnica, el diseño iterativo se basa en el uso de prototipos, los cuales simulan algunas de las características del sistema propuesto. En [Dix, 1998] se menciona que existen tres clases de prototipos: • Throw away: El prototipo se crea y se prueba. Los resultados obtenidos de este proceso son usados para construir el producto final, pero el prototipo actual se descarta. La figura 2.3 describe el procedimiento para llegar a una especificación final de requerimientos para luego continuar con el resto de proceso de diseño. • Incrementa!: El producto final se construye mediante componentes separados. Existe un diseño general para el sistema final, pero está particionado en componentes pequeños e independientes. El producto final es liberado como una serie de productos, en donde cada versión incluye un componente adicional. (Figura 2.4) • Evolutivo: El prototipo no se descarta y sirve como base para la siguiente iteración del diseño. En este caso, el sistema actual es visto como una evolución de una versión limitada inicial hacia su liberación final (Figura 2.5). Los prototipos evolutivos también son apropiados para las modificaciones que deben hacerse al sistema que resultan de la operación y mantenimiento del ciclo de vida.. Requerimientos preliminares. Requerimientos finales. Figura 2.3 Prototipo throw away dentro de la especificación de requerimientos [Dix, 1998] Los prototipos difieren de acuerdo a la funcionalidad y al desempeño que proporcionan relativo al producto final. Una animación de requerimientos puede involucrar funcionalidad limitada o simular un pequeño aspecto del comportamiento interactivo para propósitos de evaluación. La importancia de un prototipo radica en la realidad que proyecta. El prototipo de un sistema interactivo es usado para probar los requerimientos evaluando su impacto con usuarios reales [Dix, 1998]..

(26) 12. Identificación de componentes. Entregar incremento. Operación y mantenimiento Entregar sistema. Figura 2.4 Prototipo incremental dentro del ciclo de vida [Dix, 1998].. Construir prototipo. Evaluar prototipo. Operación y mantenimiento. Figura 2.5 Prototipo evolutivo a través del ciclo de vida [Dix, 1998]..

(27) 13. 2.3 Técnicas de diseño Existen diversas técnicas para involucrar al usuario en el proceso de especificación de requerimientos. Mediante estas técnicas es posible conocer al usuario, así como también obtener diversas ideas, metáforas, elaborar prototipos de bajo nivel, etc. A continuación se describen las técnicas de diseño participativo, la cual es una técnica utilizada tanto con adultos como con niños; las siguientes técnicas que se mencionan son investigación cooperativa e investigación contextual, las cuales son adaptaciones que Allison Druin ha hecho a algunas técnicas de diseño para trabajar con niños. 2.3.1 Diseño participativo Una técnica de prototipeo que ha llegado a ser muy popular es el diseño participativo. Los precursores de esta propuesta fueron investigadores escandinavos, esta técnica enfatiza la importancia de habilitar un equipo de personas para hacer sugerencias sobre el diseño de un proyecto. En general se utilizan herramientas de prototipeo de bajo nivel al principio del proceso mediante una "lluvia de ideas" para explorar varias posibilidades de diseño. Una vez que esto es plasmado por el equipo en papel, modelos o en video, se puede elaborar un prototipo computacional [Druin, 1996]. En [Reyes, 1997] se menciona que Wildman describe técnicas que se enfocan a llevar a cabo el diseño de interfaces mediante dinámicas de grupo. Debido a que expertos y usuarios tienen diferentes habilidades, experiencia, conocimientos, etc. se requiere buscar la manera de nivelar estos aspectos de tal forma que se pueda obtener la máxima creatividad y contribución de los participantes. Se recomiendan las dinámicas de grupo porque a través de ellas se logra estrechar las relaciones interpersonales, estableciendo un equilibrio entre el sentido de pertenencia y liderazgo, además se estimula la creatividad y cohesión del grupo. En [Reyes, 1997] se mencionan las dinámicas de grupo propuestas por Wildman: • CARD (Collaborative Analysis of Requirements and Design): En esta dinámica de grupo se presentan las actividades del usuario mediante la utilización de cartas o tarjetas con el fin de proporcionar una visión del trabajo o la utilización de un sistema de cómputo. CARD puede ubicarse en el espacio taxonómico de prácticas de diseño participativo en la etapa inicial del ciclo de desarrollo. La cantidad de personas que pueden participar en el grupo es pequeña y existe una participación equitativa entre los usuarios y los diseñadores. • Buckets: Se utiliza para diseño conceptual de bases de datos. En esta dinámica de grupo la meta es llegar a un modelo que refleje el consenso del participante en la estructura y contenido de los datos, de esta forma se contribuye a revelar la percepción del usuario de su proceso de trabajo. Buckets se localiza casi al final.

(28) 14. del ciclo de desarrollo y cuenta con una participación activa de los usuarios en las actividades de diseño. Diseño de iconos: El propósito de esta dinámica de grupo es generar alternativas de diseño de iconos que sean significativos para el usuario. Esta dinámica de grupo involucra la participación directa del usuario en las actividades de diseño. Para que sea efectivo es conveniente que se trabaje con grupos chicos. Metáforas de interfaz: Es una técnica de diseño de interfaces de usuario que ayuda al mejor entendimiento de ideas complejas de diseño mediante la utilización de metáforas, estimulando el pensamiento creativo. Al igual que CARD, esta dinámica también se encuentra ubicada en el espacio taxonómico de prácticas de diseño participativo al inicio del ciclo de desarrollo. PICTIVE (Plástic Interface for Collaborative Technology Initiatives Through Video Exploration): Es una técnica para llevar a cabo el diseño de interfaces a través de un grupo heterogéneo de participantes mediante la utilización de objetos de oficina. PICTIVE es de gran utilidad cuando se va a la mitad del ciclo de desarrollo e involucra que los usuarios participen directamente en las actividades de diseño. Teatro de interfaces: Esta técnica se utiliza para revisar y criticar el diseño de una interfaz a través de la actuación de las actividades y operaciones de la misma por un grupo de actores integrado por usuarios, diseñadores, etc., con el fin de hacer un rediseño. El teatro de interfaces funciona mejor si se efectúa con grupos numerosos de personas y es útil cuando el ciclo de desarrollo está en una fase avanzada. 2.3.2 Investigación cooperativa e investigación contextúa! El método de investigación cooperativa (cooperative inquiry) está basado en la idea de que los usuarios pueden ser compañeros de los desarrolladores para poder conocer lo que los usuarios requieren [Druin, 1999]. Mediante la investigación cooperativa se puede conocer rápidamente una gran cantidad de información sobre las necesidades de los usuarios acerca de las actividades que son parte del contexto del usuario [Druin, 1999]. Mediante investigación contextual (contextual inquiry), un equipo de investigadores observan y analizan el ambiente de los usuarios para obtener patrones de actividad, de comunicación, artefactos y relaciones culturales. Se desarrollan diagramas y modelos de las experiencias de campo que eventualmente pueden llevar al diseño de storyboards, prototipos y nuevas tecnologías. Este método es muy importante trabajando con niños, sobre todo de edades entre 3 y 7 años, ya que tienen dificultades para abstraer describiendo lo que necesitan y quieren de la tecnología [Druin, 1999]..

(29) 15. Mediante el uso de papel, crayones, plastilina, cordel, etc., los prototipos de bajo nivel proporcionan las mismas bases a los niños y a los adultos. No es necesario enseñar a las personas como hacer prototipos, ya que usando materiales básicos llega a ser un procedimiento natural tanto para los diseñadores jóvenes y adultos. Esta forma de prototipeo es barata y bastante efectiva en tormentas de ideas. De estos prototipos de bajo nivel emergen posteriormente los prototipos de alto nivel [Druin, 1999]. Los investigadores deben colectar datos en el ambiente de los usuarios. Se requiere al menos dos personas que tomen notas y un ínteractor. El interactor debe ser un observador participativo, hablando naturalmente con los niños, sin tomar notas y formando parte de la experiencia activamente. El interactor no debe ser un entrevistador, debe hacer preguntas relacionadas con lo que está pasando en el momento [Druin, 1999]. Los niños entre 3 y 5 años pueden ser a veces poco verbales o menos auto reflexivos al discutir el mundo que les rodea. Por lo tanto, para entender cuáles pueden ser las necesidades de estos niños, las técnicas de observación deben capturar los patrones de actividad exploratoria de los niños [Druin, 1998].. 2.4 Sistemas formativos e informativos Cuando se va a elaborar un proyecto de software, es necesario definir el uso que tendrá; en [Campbell, 1998] se definen dos tipos de sistemas según su uso: • Informativos • Formativos Sistemas informativos Son conocidos también como sistemas de referencia. Por lo general son volúmenes de información que se transfieren de un medio a otro (de un medio impreso a un medio digital). Las ventajas de este tipo de sistemas es que se pueden almacenar grandes cantidades de información en un solo disco compacto, así como también se puede agregar simulaciones animadas, sonidos y video digital. Sistemas formativos • Sistemas de apoyo a la enseñanza: Estas aplicaciones incluyen a los sistemas que utiliza un maestro o instructor para apoyar sus exposiciones o presentaciones. • Sistemas de apoyo al aprendizaje: Estos sistemas se diseñan y desarrollan siguiendo un modelo pedagógico. En general estos sistemas presentan objetivos, la exposición de un tema y ejercicios de autoevaluación.. ¿82S50.

(30) 16. Ambientes de aprendizaje: Este tipo de sistemas facilitan el acceso a los sistemas de las dos categorías anteriores mediante una interfaz común y ofrecen elementos mediante los cuales el estudiante puede hacer anotaciones, dejar marcados los temas consultados, puede enriquecer el material con sus propias contribuciones, sistemas para accesar tutores virtuales, correo electrónico y herramientas para diseñar y desarrollar su propio material. 2.5 Diseño instruccional Instrucción es la adquisición de información para producir aprendizaje. Métodos son los procedimientos de instrucción que se seleccionan para ayudar a los aprendices a lograr los objetivos o para internalizar el contenido del mensaje. Medios son los encargados de transportar la información entre el transmisor y el receptor. Estos vehículos son considerados como medios instruccionales cuando transmiten mensajes para lograr un cambio de comportamiento [Heinich, 1990]. Frecuentemente los instructores usan medios sin alguna referencia de cómo guiar las experiencias contenidas en esos medios para que puedan ser usadas por los aprendices. Cuando no se cuenta con buenos fundamentos conceptuales, el uso de materiales específicos puede llegar a ser simplemente mecánico, con la esperanza de que lo que es presentado a los aprendices eventualmente tendrá algún significado para ellos. Los instructores pueden desarrollar bases conceptuales y teóricas para seleccionar materiales específicos y métodos conociendo las relaciones entre medios, aprendizaje e instrucción [Heinich, 1990]. En [Heinich, 1990] se define un modelo llamado ASSURE el cual es una guía para planear e impartir instrucción en donde se incorporan los medios. • Análisis de los aprendices (Analyze Learners): El primer paso en la planeación es identificar los aprendices. Se debe conocer a los estudiantes para seleccionar el mejor medio para lograr los objetivos. La audiencia puede ser analizada en términos de (1) características generales y (2) capacidades específicas conocimientos, habilidades y actitudes acerca del tópico. • Expresar objetivos (State Objectives): El siguiente paso es expresar los objetivos lo más específicos que sean posibles. Los objetivos pueden provenir de diversas fuentes como una guía curricular o pueden ser desarrollados por un instructor. Deben establecerse en base de los aprendices (audiencia) y serán capaces de obtener un resultado de la instrucción (comportamiento). Deben incluirse las condiciones en las cuales el estudiante ejecutará y el grado aceptable de ejecución. • Selección del medio y materiales (Select Media and Materials): Una vez que se ha identificado la audiencia y establecido los objetivos, se ha establecido el principio (conocimiento actual de la audiencia, habilidades y actitudes) y los puntos finales.

(31) 17. (objetivos) de la instrucción. La siguiente tarea es construir un "puente" entre esos dos puntos. Existen tres opciones: (1) seleccionar materiales disponibles, (2) modificar los materiales existentes o (3) diseñar nuevos materiales. Utilizar materiales (Utilize Materials): Una vez que se han seleccionado, modificado o diseñado los materiales, se debe planear cómo los materiales serán usados y que tanto tiempo se dedicará a ellos. Posteriormente se procederá a preparar la clase y a tener listo el equipo necesario para después presentar el material. Ejecución requerida del aprendiz (Require Learner Performance): Los aprendices deben practicar lo que están esperando aprender y deben ser reforzados por la respuesta correcta. La primera vez que se espera que realicen el comportamiento que se espera obtener de los objetivos no debe ser en los exámenes. Esto debe lograrse en las actividades de la lección que permitan a los aprendices responder y recibir retroalimentación de su ejecución o respuesta. Evaluar/Revisar (Evalúate/Revise): Después de la instrucción es necesario evaluar su impacto y efectividad. Para esto debe evaluarse el proceso instruccional completo. ¿Cumplieron los aprendices con los objetivos? ¿Ayudaron los medios para lograr los objetivos? ¿Pudieron usar correctamente los materiales todos los estudiantes?.

(32) 18. CAPÍTULO 3 INTERFAZ HUMANO-COMPUTADORA "Una representación basada en computadora sin un participante humano es como el sonido de un árbol cayendo en un bosque deshabitado" [Laurel, 1991].. 3.1 Antecedentes Las interfaces de usuario han ido evolucionando a través del tiempo conforme se ha avanzado en el área de los sistemas computacionales. Para mostrar los avances en el campo de interacción humano-computadora en [Treu, 1994] se describen varios períodos en el tiempo: • Período 1 (1940-1970): La tecnología dominaba mientras el usuario era algo secundario. Con equipos "mainframe" operados en modo batch, el diseño se enfocaba en cómo obtener más funcionalidad del hardware y software. Era el inicio del uso interactivo de las computadoras y en esa época no era una prioridad hacer la vida más sencilla al usuario. • Período 2 (1970-1980): Los avances en la tecnología habilitaron y estimularon más atención al usuario con sistemas de tiempo compartido, minicomputadoras, redes computacionales y terminales CRT, con lo que el usuario se benefició en gran medida. Los usuarios adquirieron más conocimientos en esta área y se volvieron más demandantes. Como resultado, lentamente surgió el diseño orientado al usuario. « Período 3 (1980-1990's): El usuario se consideró como prioridad mientras la tecnología se convertía en una herramienta de apoyo. Con la reducción de tamaño de los componentes computacionales y la introducción de funciones orientadas al usuario en las estaciones de trabajo, sistemas de ventanas, dispositivos interactivos, gráficas, color, etc., llegó a ser factible diseñar la interfaz de tal forma que cumpliera con los requerimientos y necesidades de los usuarios individuales.. 3.2 Conceptos de interacción e interfaz humano-computadora Es necesario hacer distinción entre los conceptos de interacción e interfaz que están muy relacionados. En [Azar, 1996] se menciona que el usuario interactúa con las computadoras a través de la interfaz de usuario y a este proceso de comunicación se le denomina interacción hombre-computadora..

(33) 19. En [Treu, 1994] se señala que interacción humano-computadora es la combinación de acciones físicas, lógicas, conceptuales y diálogos entre un usuario humano y una computadora, para lograr un propósito específico. Interfaz humano-computadora es el medio a través del cual se pueden conectar e interactuar un usuario humano y una computadora, tanto el medio físico (visual, auditivo, táctil), como los métodos y patrones que soportan la interacción humano-computadora [Treu, 1994]. Una interfaz de usuario incluye los aspectos del sistema que son "visibles" a los usuarios y que permiten a éstos interactuar con los datos del sistema, software y hardware [Dewitz, 1996]. 3.3 Interfaz "amigable" El concepto de interfaz "amigable" es usado frecuentemente en anuncios publicitarios, lo cual indica que la interfaz debe ser sencilla de usar, sin embargo no sólo debe tener estas características, sino que también debe cumplir con la funcionalidad que el usuario requiere. "Amigable" es una frase llamativa que es muy atractiva al momento de escribir folletos de ventas de computadoras, pero debe ser definida en forma más precisa y delimitada, o ser reemplazada por otros conceptos más claros [Treu, 1994a]. En [Shneiderman, 1992] se menciona que un componente crítico del diseño de sistemas interactivos es el reemplazo del vago concepto de "amigable" con cinco criterios medibles: • • • • •. Tiempo de aprendizaje Velocidad de funcionalidad Razón de errores Retención a través del tiempo Satisfacción subjetiva. 3.4 Diversidad en la interacción Debido a la gran diversidad que puede existir entre los usuarios y las tareas que realizan, el diseñador puede desarrollar diversos estilos de interacción. En [Shneiderman, 1992] se propone que antes de comenzar un diseño debe realizarse un estudio de los usuarios y de la situación tan completa y precisa como sea posible. Las capacidades y limitaciones de cada usuario, la aplicación computacional y la computadora, especialmente la interfaz de usuario, son factores que el diseñador debe.

(34) 20. reconocer y tomar en cuenta. Esto requiere de gran conocimiento y habilidad por parte del diseñador. El diseñador debe ser capaz de distinguir entre los factores que son importantes de los que no lo son, en el contexto de tratar de lograr las metas de diseño que se han establecido. Los factores resultantes del estudio de estas características deben ser tomados en cuenta para las decisiones de diseño [Treu, 1994a]. 3.4.1 Perfil del usuario Para determinar el perfil del usuario se deben definir sus características o atributos haciendo una descripción clara y concisa de sus intereses, habilidades, preferencias, etc. Los factores humanos son todas las características (psicológicas, fisiológicas, sociales, etc.) que tienen potencial de influenciar el diseño de la interacción orientada al humano [Treu, 1994]. Los usuarios involucrados en el diseño poseen características específicas que pueden ser identificadas de acuerdo a diversas clasificaciones. En [Treu, 1994] se propone una clasificación de estas características: •. Antecedentes del usuario • Experiencia • Educación • Habilidades • Conocimientos Factores fisiológicos/físicos . Vista . Oído • Tacto • Destreza Factores psicológicos/cognitivos • Aprendizaje • Memoria Razonamiento • Actitudes • Creencias • Expectativas. •. Factores de uso e interés sobre la aplicación Elección (de la aplicación) • Frecuencia (de uso) Objetivos (de uso).

(35) 21. Factores compuestos • Preferencias y desempeño . Modelo mental. Por su parte, Ben Shneiderman menciona en [Shneiderman, 1992] que al diseñar un sistema interactivo deben considerarse los siguientes factores: • • « • •. Habilidades físicas y lugar de trabajo Habilidades cognitivas y perceptuales Diferencias individuales Diversidad cultural e internacional Usuarios con discapacidades. Los datos básicos sobre las dimensiones humanas provienen de un estudio antropométrico considerando factores como sexo, edad, nacionalidad, estatura, etc. La gran diversidad de estas medidas estáticas nos recuerdan que no existe un usuario "promedio", por lo tanto deben realizarse múltiples versiones de un sistema para adecuarlas al tipo de usuario [Shneiderman, 1992]. El proceso de conocer a los usuarios nunca termina, ya que es un campo muy amplio y algunas de sus características individuales se mantienen en constante cambio. Cada paso que se acerque al entendimiento de los usuarios y el reconocimiento de los mismos como individuos cuya perspectiva es diferente de la del diseñador, es un paso para acercarse más a un diseño exitoso [Shneiderman, 1992]. 3.4.1.1 Antecedentes del usuario En [Shneiderman, 1992] se menciona que debe hacerse una diferencia entre los niveles de experiencia de los usuarios para utilizar esas diferencias al momento de diseñar la interfaz: • Usuarios principiantes: Estos usuarios no tienen conocimiento sobre el uso del sistema y probablemente tienen poco conocimiento sobre aspectos computacionales. Los usuarios principiantes tienen conocimientos superficiales de la tarea y pueden llegar a presentar ansiedad al momento de utilizar las computadoras, lo cual podría llegar a inhibir su aprendizaje. Superar estas limitaciones es un gran reto para el diseñador. Debe existir una pequeña cantidad de términos y de posibilidades para que el usuario principiante sea capaz de llevar a cabo algunas tareas simples para ganar confianza, reducir ansiedad y tener reforzamiento positivo para el éxito. Es importante la retroalimentación positiva cuando se realiza una tarea, además de mensajes adecuados cuando ocurra un error..

(36) 22. • Usuarios intermitentes: Muchos usuarios pueden tener conocimientos en algún tipo de sistemas, pero serán usuarios intermitentes de otra variedad de sistemas. Estos usuarios son capaces de mantener conocimientos semánticos de las tareas y los conceptos computacionales, pero tendrán dificultad de retener el conocimiento sintáctico. Para que estos usuarios ejecuten sus tareas adecuadamente serán necesarias secuencias de acción consistentes, mensajes con significado y ayudas frecuentes. • Usuarios expertos: Estos usuarios tienen conocimiento sobre los aspectos sintácticos y semánticos del sistema, quieren realizar su trabajo rápidamente, demandan rápidos tiempos de respuesta, requieren poca y breve retroalimentación y además buscan ejecutar acciones con pocas teclas o selecciones. 3.4.1.2 Factores fisiológicos/físicos Este tipo de factores se refieren a las características físicas inherentes de los usuarios en general y/o de ciertos usuarios en particular. Por lo tanto se deben hacer las adaptaciones necesarias al hardware o a la interfaz para que cumplan adecuadamente con el tipo de usuario al que está dirigido [Treu, 1994]. 3.4.1.3 Factores psicológicos/cognitivos El diseñador debe tomar en cuenta las posibilidades de estos factores y los efectos que pudieran tener, si son significativos, en el diseño de características a ser especificadas e implementadas. Estos rasgos deben ser capaces de ayudar las deficiencias del usuario y a reforzar sus capacidades [Treu, 1994]. 3.4.1.4 Factores de uso e interés sobre la aplicación Este conjunto de factores proporcionan una visualización de lo que se considera que el usuario está interesado en hacer con una computadora debido a su experiencia. Alternativamente, para usuarios que aún no han utilizado la computadora con ciertas aplicaciones, esta categoría debe considerar factores posibles a ser anticipados para usuarios nuevos o sin experiencia. Además de indicar las elecciones sobre las aplicaciones a ser diseñadas, el perfil debe dar una guía sobre qué tan frecuente o regularmente se espera que el usuario interactúe con la computadora para las aplicaciones elegidas [Treu, 1994]..

(37) 23. 3.4.1.5 Factores compuestos Modelos mentales Un modelo mental es la estructura de conceptos, componentes, acciones y/o tareas que el usuario ha construido en su mente para lograr una visualización al interactuar con una computadora [Treu, 1994]. En [Treu, 1994] se proponen las principales alternativas para las bases que fundamentan un modelo mental: 1. Lenguaje: Es utilizado para expresar lo que el usuario quiere hacer y cómo lo quiere hacer, se relaciona con los "objetos" de interés en el ambiente del sistema, también es usado para entender las respuestas de la computadora. Los paradigmas basados en el lenguaje son inherentes a varias técnicas de interacción. 2. Metáforas: Son usadas para relacionar un patrón conocido de actividad del usuario con las actividades interactivas en una computadora. 3. Acciones y objetos: Son utilizados para concentrarse en tareas específicas de la aplicación y cómo las acciones pueden manipular los objetos. 4. Organización espacial: Para arreglar diversos componentes (visibles e invisibles) en un patrón de visualización coherente y lógico para que sea capaz de funcionar adecuadamente en la mente del usuario. El usuario debe ser capaz de manejar el lenguaje y las reglas, debe ser capaz de llevar a cabo una "simulación mental" de las acciones del sistema y los objetos involucrados en una aplicación [Treu, 1994]. Debido a la gran cantidad de diferencias individuales pueden existir varios modelos mentales diferentes. Estos no sólo difieren entre usuarios, sino que difieren dentro de un mismo usuario en particular, incluso para la misma aplicación computacional, de una sesión interactiva a otra [Treu, 1994]. 3.4.2 Perfiles de las actividades Después de definir el perfil del usuario, los diseñadores deben determinar las actividades que realizará la aplicación. Las actividades se deben determinar antes comenzar el diseño, aunque frecuentemente el análisis de la actividad se realiza informalmente o implícitamente. Algunos factores a considerar cuando se efectúan decisiones del diseño de la arquitectura son la frecuencia relativa de uso y el nivel de complejidad de las acciones..

(38) 24. Análisis de la tarea: Estudio detallado de una tarea para determinar su naturaleza, propósito y componentes, además el orden en el cual deben ser llevados a cabo [Treu, 1994]. 3.4.3 Estilos de interacción En [Shneiderman, 1992] se propone que al terminar el análisis de las actividades, el diseñador puede elegir entre los siguientes estilos de interacción: . Selección de menúes: El usuario escoge de una lista de elementos el más apropiado a la actividad a ejecutar. Este estilo de interacción es apropiado para los usuarios principiantes e intermitentes y puede ser útil a los usuarios frecuentes si el desplegado y los mecanismos de selección son rápidos. • Llenado de formas: Cuando se requiere una entrada de datos, los menúes resultan incómodos, por lo cual el llenado de formas es apropiado. Los usuarios ven un desplegado de campos relacionados, mueven el cursor entre los campos, y teclean los datos cuando lo desean. Debido a que debe tenerse habilidad con el teclado, mensajes y campos donde se permitirá la captura, se requerirá de cierto entrenamiento. Este estilo de interacción es apropiado para usuarios intermitentes o frecuentes. • Lenguaje de comandos: Para usuarios frecuentes este tipo de interacción provee un gran control. Los usuarios deben aprender la sintaxis y expresar las alternativas rápidamente, sin embargo, se requiere de cierto entrenamiento y existen grandes tasas de error. • Lenguaje natural: Este tipo de interacción proporciona poco contexto para determinar el siguiente comando, frecuentemente requiere de un diálogo de certificación, y puede ser lento y más molesto que las alternativas. Sin embargo puede ser útil para los usuarios que tienen un completo dominio de la tarea y donde el uso intermitente no permite la utilización de lenguaje de comandos. • Manipulación directa: Cuando el diseñador puede crear una representación visual de las acciones, la tarea del usuario puede simplificarse significativamente porque puede manipular directamente los objetos de interés. Mediante la selección de las representaciones visuales de los objetos y acciones, los usuarios puedefl realizar las tareas rápidamente y observar los resultados inmediatamente. Este tipo de interacción es atractiva para los usuarios principiantes, fácil de recordar para los intermitentes, y mediante un buen diseño, puede ser rápida para usuarios frecuentes..

(39) 25. 3.5 Diseño de interfaz Cuando se desarrolla un sistema computacional, debe darse una especial importancia al diseño de la interfaz de usuario. De acuerdo a [Martin, 1996], sería erróneo tratar al diseño de interfaces como un proceso aislado dentro de la tarea de diseñar la aplicación completa. En [Reyes, 1997] se menciona que los requerimientos de los sistemas de información deben obtenerse utilizando una comunicación efectiva entre los analistas de sistemas y los usuarios. Los paradigmas de desarrollo de sistemas fueron creados con el fin de obtener un sistema con calidad, es decir, que sea funcional y que sea amigable para el usuario. Sin embargo, con frecuencia los responsables del desarrollo de sistemas pasan por alto un análisis exhaustivo de las necesidades del usuario en cuanto a presentación del sistema se refiere, enfocándose principalmente a los requerimientos generales. Esto es un hecho aún cuando existen en la actualidad muchos trabajos de investigación que hablan exclusivamente de diseño de medios de interacción entre una persona y una computadora Diseñar es un proceso creativo e impredecible. Los diseñadores de sistemas interactivos deben mezclar los conocimientos de factibilidad técnica con un sentido estético casi místico de lo que puede atraer a los usuarios. Carroll y Rosson citados en [Shneiderman, 1992] caracterizan el diseño de la siguiente forma: . Diseñar es un proceso, no un estado y no puede ser representado adecuadamente en forma estática. . El proceso de diseño no es jerárquico, no es estrictamente "bottom-up", ni "topdown". • El proceso es radicalmente de transformación; involucra el desarrollo de soluciones parciales e intermedias que puede ser que no se tomen en cuenta en el diseño final. . Diseñar implica intrínsecamente descubrir nuevas metas. El proceso de diseño de interfaz es una serie de decisiones. Estas decisiones van desde la posición de un objeto, el uso de una técnica, color, estilo y material. Debe diferenciarse entre diseñar para uno mismo o diseñar para otra persona. Diseñar para otras personas involucra responsabilidad, una responsabilidad de entender las necesidades de la otra persona y proporcionarle una solución satisfactoria [Martin, 1996]. Cuando un sistema interactivo está bien diseñado, la interfaz casi desaparece, permitiendo a los usuarios concentrarse en su trabajo, exploración o diversión. Crear un ambiente en el cual las tareas se realicen casi sin esfuerzo requiere de mucho trabajo por parte del diseñador [Shneiderman, 1992]. En [Shneiderman, 1992] se menciona que al diseñar un sistema interactivo debe cumplir con las siguientes características:. . Funcionalidad.

(40) 26. . Confíabilidad, disponibilidad, seguridad e integridad de los datos . Estandarización, integración, consistencia y portabilidad Diversas investigaciones han demostrado que el rediseño de la interfaz humanocomputadora puede hacer una importante diferencia en el tiempo de aprendizaje, velocidad de funcionamiento, tasas de error, y satisfacción del usuario [Shneiderman, 1992]. Existen muchas teorías que describen los múltiples aspectos de los sistemas interactivos. En [Shneiderman, 1992] se cita una propuesta del modelo que Foley y van Dam desarrollaron a finales de los 70's: 1. El modelo conceptual es el modelo mental del sistema interactivo. 2. El nivel semántico describe los significados transmitidos por la entrada de comandos del usuario y el desplegado de salida de la computadora. 3. El nivel sintáctico define como las unidades semánticas se combinan en una oración con el fin de que la computadora realice cierta tarea. 4. El nivel léxico trabaja con las dependencias del dispositivo y con los mecanismos precisos por los cuales el usuario especifica la sintaxis. 3.5.1 Modelos de diseño de interfaz En [Gentner, 1996] se mencionan dos propuestas de modelos de diseño de interfaz: • Perspectiva orientada al mecanismo • Perspectiva orientada a la actividad Cuando se diseñan interfaces los diseñadores deben seleccionar la propuesta de modelo de diseño más apropiada al proyecto con el que se está trabajando [Gentner, 1996]. El modelo orientado al mecanismo proporciona mayores beneficios a los ingenieros y desarrolladores, ya que permite accesar toda la funcionalidad del sistema. Una interfaz basada en la perspectiva orientada a la actividad es más fácil de aprender y usar, pero proporciona acceso sólo a una parte de las capacidades del sistema. La principal ventaja del modelo orientado a la actividad es que el aprendizaje es mucho más rápido y más efectivo, sin embargo puede no ser apropiado para todos los usuarios [Gentner, 1996]. Las aplicaciones que serán utilizadas por usuarios que no usan frecuentemente el sistema deben enfocarse en la facilidad de aprendizaje y memorización. Esto implica que el diseño de interfaz debe basarse en el modelo de la actividad del usuario, aún si esto incrementa la complejidad del diseño del sistema o reduce su poder. El mecanismo del sistema no debe ser relevante para los usuarios que lo usan con poca frecuencia, por lo que debe esconderse tanto como sea posible [Gentner, 1996]..

(41) 27. Es razonable esperar que los usuarios frecuentes inviertan más tiempo y esfuerzo en aprender un nuevo sistema si pueden obtener mayores beneficios adaptándose al mismo [Gentner, 1996]. Es conveniente incluir en el equipo de diseño a algunos individuos - posibles usuarios - que sean principiantes en la arquitectura del sistema. Finalmente, las tareas del usuario deben ser completamente examinadas para que cambien en paralelo con los cambios tecnológicos y proporcionen oportunidades para nuevos diseños de interfaces [Gentner, 1996]. 3.5.2 Modelos del usuario En [Janlert, 1989] se mencionan los siguientes modelos del usuario en la interacción hombre-computadora, los cuales analizan la actividad del usuario, al usuario y a la aplicación: • Modelo del usuario acerca de la aplicación: A este modelo también se le llama modelo mental o modelo semántico. Este modelo apoya en muchas tareas al usuario planeando sus actividades importantes. . Modelo del usuario acerca de la actividad: Es la percepción personal del usuario acerca de la actividad que éste hace. Por actividad del usuario se entiende el establecimiento de metas, conceptos, métodos, instrumentos, formas de trabajo, etc. • Modelo psicológico y cognitivo del usuario: El objetivo es modelar los procesos mentales que se realizan en la mente del usuario cuando se encuentra interactuando con la aplicación computacional. Estos modelos van desde modelos generales de patrones de trabajo (selección, ejecución, evaluación, etc.) a modelos de tareas específicas como el uso del teclado. • Modelo de la aplicación acerca del usuario: Cada programa es construido de acuerdo a un número de suposiciones sobre el usuario. Por ejemplo, el diseñador puede asumir que el usuario escucha y lee, puede leer textos de acuerdo a cierta velocidad. « Modelo del diseñador acerca del usuario: El diseñador debe tener un gran conocimiento sobre el usuario, desde el conocimiento general sobre los niños, al conocimiento específico sobre la relación de los niños con la tecnología. Este modelo debe especializarse en el grupo particular de usuarios a los que está dirigido. . Modelo del diseñador acerca de la actividad: Es la percepción que el diseñador tiene sobre la actividad que el usuario realiza, donde el diseñador propone algo en base a lo que observa del usuario..

(42) 28. Modelo propuesto por el diseñador: Es el modelo que propone el diseñador partiendo de la premisa de que es éste quien tiene experiencia y ha adaptado una estrategia de diseño basado en el conocimiento que ya adquirió sobre el modelo del usuario..

(43) 29 CAPÍTULO 4. APRENDIZAJE INFANTIL Y SOFTWARE EDUCATIVO "Children learn by doing" [Druin, 1996].. 4.1 Teorías del aprendizaje Una de las principales interrogantes de los investigadores de las ciencias relacionadas con el desarrollo intelectual ha sido lograr entender cómo es que el individuo adquiere conocimientos. Debido a esto han surgido una serie de teorías que tratan de explicar este complejo proceso llamado aprendizaje. Como la infancia es la época de la vida en la que el individuo comienza a involucrarse dentro de las diferentes clases de aprendizaje, algunas de estas teorías se basan en el estudio del aprendizaje infantil. Dos de las teorías que explican el desarrollo del aprendizaje en el niño son: • •. Construccionismo Constructivismo. Ambas teorías piensan que los niños poseen conocimientos antes de ir a la escuela y necesitan ayuda en construir lo que ellos conocen. Los niños son participantes activos en su propio aprendizaje. El objetivo de la educación es pasar el conocimiento obtenido por el aprendizaje informal hacia el aprendizaje formal [Druin, 1996]. El énfasis de los constructivistas consiste en utilizar material relevante y emplear estrategias de enseñanza para motivar a los niños a aprender. Los niños poseen un conjunto de conceptos y habilidades por medio de las cuales puede construir conocimiento para resolver los problemas del ambiente; el rol del maestro es proveer las bases para la construcción del conocimiento [Druin, 1996 y Kent, 1995]. El construccionismo se basa en la idea que el niño debe encontrar por sí mismo el conocimiento específico que él necesita. Los construccionistas buscan crear ambientes y objetos de juego para que los niños puedan continuar aprendiendo cosas nuevas de forma tan natural como Piaget mostraba en su aprendizaje sin instrucción. Para Piaget el conocimiento no se da a un observador pasivo, sino que más bien el conocimiento de la realidad tiene que ser descubierto y construido por la actividad infantil [Druin, 1996]. El aprendizaje depende de la etapa de desarrollo en la que se encuentra el individuo, puede considerarse como un proceso que es provocado y en el cual debe contarse con un reforzamiento externo por parte del maestro, además debe complementarse por un reforzamiento interno autorregulador del sujeto. Piaget señala que "toda información.

(44) 30. adquirida desde el exterior lo es siempre en función de un marco o esquema interno, más o menos estructurado" [Ginsburg, 1997].. 4.1.1 Enfoque de Piaget A partir de 1920, el psicólogo suizo Jean Piaget realizó una serie de investigaciones para determinar la forma en que se desarrolla el conocimiento de los individuos; sus resultados fueron que esto se basa principalmente en el desarrollo del sistema nervioso y las funciones mentales. Elaboró un esquema de los estadios del desarrollo cognoscitivo (pensar, reconocer, percibir, recordar, generalizar), separando cada etapa del niño en períodos (sensorio-motriz, pre-operatorio, operatorio concreto y operatorio formal). La lógica y forma de pensar de los niños son completamente diferente a la de los adultos debido a que el conocimiento se va desarrollando en base a estructuras mentales que se van haciendo más completas conforme el niño va avanzando en el desarrollo. Los experimentos de Piaget mostraron que los niños adquieren conocimientos sin ser enseñados por un maestro. La conclusión de esto no es que los maestros sean innecesarios, sino que los niños son buenos aprendices. El rol del maestro es capitalizar lo que el niño sabe mediante sus propias estrategias de aprendizaje y ayudarlo a desarrollar otras nuevas estrategias para adquirir más conocimientos [Druin, 1996]. 4.2 Aplicaciones computacionales educativas Con los avances de la tecnología y la incorporación de los mismos a los ambientes en los que el niño se desenvuelve, como la casa y la escuela; además de los maestros, libros, apoyos escolares, juguetes y la intervención de los padres en el proceso formativo del niño, la computadora hizo acto de presencia. Las aplicaciones de software para niños se han hecho cada vez completas al incluir en ellas interfaces gráficas y sonido. Actualmente existen juegos, historias y actividades multimedia donde se combina la educación y el entretenimiento. Las herramientas de enseñanza-aprendizaje que existen actualmente en ambientes multimedia que utilizan computadoras son: Libros interactivos: Guían a los niños en cada paso del camino, ofreciendo un patrón establecido para el aprendizaje (ej. Drill-and-Practicé). •. Medios expresivos: Ofrecen a los niños herramientas para crear y explorar su propios patrones para el aprendizaje (ej. Logo). •. Propuestas híbridas: Ofrecen ambas opciones, de aprendizaje guiado a través de un conjunto establecido de información y la opción de crear sus propias.

Figure

Figura 2.1: Modelo de cascada de desarrollo de sistemas
Figura 2.2: Alternativa de prototipos para las pre-especifícaciones [Connell, 1995]
Figura 2.3 Prototipo throw away dentro de la especificación de requerimientos [Dix, 1998]
Figura 2.4 Prototipo incremental dentro del ciclo de vida [Dix, 1998].
+7

Referencias

Documento similar

Debido al riesgo de producir malformaciones congénitas graves, en la Unión Europea se han establecido una serie de requisitos para su prescripción y dispensación con un Plan

Como medida de precaución, puesto que talidomida se encuentra en el semen, todos los pacientes varones deben usar preservativos durante el tratamiento, durante la interrupción

No había pasado un día desde mi solemne entrada cuando, para que el recuerdo me sirviera de advertencia, alguien se encargó de decirme que sobre aquellas losas habían rodado

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

Después de una descripción muy rápida de la optimización así como los problemas en los sistemas de fabricación, se presenta la integración de dos herramientas existentes

b) Pensar que las normas «anteriores» no pertenecen a los nuevos sistemas jurídicos del nuevo orden jurídico del nuevo orden estatal, pero que son aplicables. Si CRNA no se reformula

Ciaurriz quien, durante su primer arlo de estancia en Loyola 40 , catalogó sus fondos siguiendo la división previa a la que nos hemos referido; y si esta labor fue de

La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de