PROPUESTA DE UNA METODOLOGÍA DE DESARROLLO DE SOFTWARE EDUCATIVO BAJO UN ENFOQUE DE CALIDAD SISTÉMICA

PROPUESTA DE UNA METODOLOGÍA DE DESARROLLO DE SOFTWARE EDUCATIVO BAJO UN ENFOQUE DE CALIDAD SISTÉMICA María Gabriela Díaz-Antón María Angélica Pérez Anna C. Grimmán Luis E. Mendoza Universidad Simón Bolívar (USB), Caracas, Venezuela Abstract A partir de una metodología de desarrollo de software del área de la ingeniería, como lo es Rational Unified Process (RUP), se realiza una adaptación y extensión para la construcción de software educativo, a través de un proceso bien definido, en donde se incorporan las mejores prácticas de diseño instruccional y de la ingeniería de software. Esta propuesta analiza y describe las fases para el desarrollo de software educativo a fines de producir un producto educativo de calidad, apoyada en el Modelo Sistémico de Calidad (MOSCA) propuesto por el Laboratorio de Información y Sistemas (LISI), Universidad Simón Bolívar, ampliado y enriquecido con los parámetros educativos propuestos por profesionales del área de la educación, del gobierno y de la empresa privada, seleccionados para este estudio. El uso de esta metodología asegura que se produzca desde sus primeras fases de desarrollo, un producto de calidad que cumpla con las características de funcionalidad, usabilidad y fiabilidad, características éstas deseables y necesarias para un material educativo multimedia interactivo. Se elabora además un prototipo de software educativo para niños de 8 a 10 años, para ser usado en Internet, que incorpora la metodología planteada, dentro de un proyecto pedagógico de aula llamado Conservemos nuestra fauna, conteniendo textos y ejercicios sobre el tema de los animales en peligro de extinción. Este trabajo colabora con el uso de las tecnologías en la educación, donde el estudiante aprende conceptos, practica compresión lectora, busca información y trabaja en equipo. La metodología de desarrollo de software implicó el estudio de varios aspectos, entre los cuales están el diseño instruccional, el diseño técnico y la evaluación de software. Se toma un enfoque ecléctico sobre el uso de las metodologías establecidas por cada teoría de aprendizaje y desarrollo instruccional estudiada en el desarrollo del producto final. El diseño técnico se apoya en los estudios realizados sobre las más recientes investigaciones sobre el uso del color, el texto, la imagen, el sonido y el video. Palabras claves: Software educativo, calidad sistémica, evaluación, ingeniería de software, modelo de calidad. Introducción Utilizar la informática como apoyo a los procesos de enseñanza/aprendizaje ha sido una inquietud que durante mucho tiempo ha sido investigada y probada por muchas instituciones y docentes (Cohen, Tsai et al., 1995; Díaz-Antón, 2002; Liu y Reed 1995; Mayer et al., 1997; Yildirim et al., 2001). Su asimilación dentro de instituciones educativas, incluyendo el hogar, ha aumentado en los últimos años, con lo que la demanda por software educativo de calidad es 1}

cada vez mayor. Por lo tanto se investiga sobre las metodologías que se puedan utilizar para desarrollar software educativo de calidad. Se conoce que la construcción de un sistema de software implica la toma de decisiones sobre la arquitectura del sistema (definir los componentes del sistema de software y sus interacciones) (Pressman, 2002). Estas decisiones pueden ser cruciales para el éxito o fracaso del sistema resultante, por lo que se requiere seleccionar un proceso de desarrollo de software con el fin de. obtener la calidad del sistema de software deseada y cumpla con los requerimientos establecidos. Metodologías vigentes de ingeniería de software atienden muy bien estos requerimientos y permiten al equipo encargado de dicha labor asumir con propiedad su función (Pressman, 2002). Diversos autores han utilizado la ingeniería de software para la elaboración de material multimedia interactivo, logrando de esta manera que el proceso de desarrollo y mantenimiento del software educativo sea una actividad que dependa de pautas establecidas, con modelos conceptuales y herramientas de trabajo, y no del arte de aquellos que tengan la experiencia exclusivamente. Dentro de los aportes en ingeniería de software educativo destacan los trabajos de Galvis (2000), Hinostroza, Hepp y Straub (1996), los enfocados a orientación a objetos (Mónica, 1993; Gómez, Galvís y Mariño, 1998.; Ovalle y Padilla, 1998) y los de reutilización de componentes (DiGiano y Roschele, 2000; Roschelle y Kaput, 1996, Neilson y Thomas 1996; Roschelle, Kaput y Kahn, 1998; García, González, Mandado, Pérez, Baltasar y Valdés, 2002). Se conoce además, que para lograr software educativo con las condiciones deseadas, se deben incorporar dentro de las fases de análisis y diseño, aspectos didácticos y pedagógicos, es decir, el diseño instruccional, de manera que faciliten y garanticen la satisfacción de las necesidades educativas del público al que va dirigido el software. Se deben involucrar también a los usuarios, para conseguir identificar necesidades y/o problemas específicos y se puedan establecer mecanismos de resolución adecuados y apoyar cada una de las fases en sólidos principios educativos, comunicativos y computacionales (Mariño 1998, Galvis 2000). Tomando en cuenta todo lo anterior, se decide se decide seleccionar el modelo de RUP (Rational Unified Process) con la incorporación de los aspectos pedagógicos que garanticen las necesidades educativas, para producir software de alta calidad que cumpla con los requerimientos, planificación y presupuesto establecido, ya que es un modelo que involucra un análisis de riesgo, cubre todo el ciclo de vida del producto, soporta un enfoque de desarrollo iterativo e incremental, proporciona iteraciones tempranas que se enfocan en validar y producir una arquitectura de software, y un ciclo de desarrollo inicial que toma la forma de un prototipo ejecutable que gradualmente evoluciona convirtiéndose en el sistema final y además tiene implícito en su proceso de desarrollo la evaluación continua de la calidad con respecto a los requerimientos de calidad deseados (Kruchten, 1996). Además se utiliza el instrumento de evaluación MOSCA, RUP a través de una conjunto de métricas, para asegurar que los atributos de calidad deseados sean satisfechos por el modelo de desarrollo de software (Díaz-Antón, Pérez, Grimmán y Mendoza, 2002). Se realiza una adaptación al modelo RUP para desarrollo de software educativo, en donde se incorporan las mejores prácticas de diseño instruccional y de la ingeniería de software para obtener un software educativo de calidad. En primer lugar se dará una descripción del modelo RUP, para luego establecer las diferentes fases de la metodología para el desarrollo del prototipo y los entregables en cada fase. Asimismo, se describirá brevemente el diseño del prototipo elaborado sobre el tema de los animales en peligro de extinción. 2}

Rational Unified Process (RUP) Rational Unified Process (RUP) es un proceso de Ingeniería de Software planteado por Kruchten (1996) cuyo objetivo es producir software de alta calidad, es decir, que cumpla con los requerimientos de los usuarios dentro de una planificación y presupuesto establecidos. Cubre el ciclo de vida de desarrollo de software. RUP toma en cuenta las mejores prácticas en el modelo de desarrollo de software en particular las siguientes: Desarrollo de software en forma iterativa (repite una acción). Manejo de requerimientos. Utiliza arquitectura basada en componentes. Modela el software visualmente (Modela con Unified Modeling Language,UML) Verifica la calidad del software. Controla los cambios. El proceso iterativo de RUP se organiza en fases (Kruchten, 1996), cada fase se concluye con una piedra de milla (mile stone) principal (ver figura 1). Es importante resaltar que la inclusión de piedras de millas o puntos de revisión, es sumamente importante y en estos puntos se revisan los requerimientos establecidos para cada fase, basados en los controles de calidad. De esta manera, si un producto o proceso no pasa el punto de revisión de calidad, se rediseña o se cancela, evitando así, los problemas de coste extra, de retrabajo, y de productos de mala calidad, que no satisfacen los requerimientos establecidos a nivel educativo, comunicacional, técnico y de diseño gráfico. Los puntos de revisión están basados a su vez en cuestionarios elaborados a partir de métricas establecidas producto de la experiencia y de la investigación (Díaz-Antón, Pérez, Grimmán y Mendoza, 2002). En la figura 2 se puede observar la expresión gráfica equivalente al tiempo y esfuerzo que se dedican a cada una de las fases de RUP. En esta gráfica se puede observar que la inversión de tiempo y esfuerzo en la primera fase y segunda fase es pequeña en comparación con la tercer fase, garantizando así que la mayor parte del trabajo, costo y esfuerzo se realice si y solo si, ha pasado la segunda piedra de milla, o sea, el segundo control de revisión de calidad. Comienzo (Inception) Elaboraci n (Elaboration) Construcci n (Construction) Transici n (Transition) Objetivos del Ciclo de Vida Arquitectura del Ciclo de Vida Capacidad de Operacionalidad Inicial Producto Final Figura 1. Fases de Rational Unified Process (RUP) (Kruchten, 1996) 1ra.fase 2da.fase 3ra.fase 4ta.fase Figura 2. Expresión gráfica del tiempo y esfuerzo dedicados a cada fase de RUP (Kruchten, 1996). 3}

A continuación se presentan los objetivos de cada fase, junto con una tabla comparativa especificando las actividades que se agregaron para el desarrollo de software educativo según la metodología de RUP. Fase de Comienzo o Inicio Está principalmente dirigida al entendimiento de los requerimientos y determinar el alcance del esfuerzo de desarrollo. Se define la idea, la visión y el alcance del proyecto. Esta fase incluye la fase de análisis y diseño que menciona Galvis (2000) en su método de desarrollo de materiales multimedia interactivos. Se incluye un análisis de las necesidades educativas y del entorno educativo, utilizando el modelo de Galvis (2000) y de Lee y Owen (2000), así como el diseño instruccional del proyecto. Los requerimientos de diseño gráfico se satisfacen a través del desarrollo del plan creativo de la interfaz (Ward, 1999). En este plan creativo se integra el trabajo de diseñadores gráficos, analistas de sistemas y docentes especialistas en el área. Esta fase se culmina con los objetivos del ciclo de vida. En la tabla 1 se presenta una lista de los documentos y actividades de esta fase, es decir, los entregables: MODELO RUP ACTIVIDADES AGREGADAS A RUP Un documento con la visión del proyecto. Un plan del proyecto que muestre las fases y las iteraciones. Un caso de negocio inicial el cual incluye: contexto del negocio, criterios de éxito y planificación financiera. El modelo de casos de uso con una lista de todos los casos de uso y los actores que puedan ser identificados. Un glosario inicial del proyecto. Un estudio inicial de riesgos. Una lista de los requerimientos y restricciones principales del sistema a desarrollar. Estándares para el prototipo inicial. Un mapa de navegación. Una lista inicial de riesgos y su evaluación. Una lista de requisitos funcionales y no funcionales. Un prototipo inicial. Tabla 1. Actividades correspondientes a la fase de inicio. Un análisis de las necesidades educativas y del entorno educativo. Un estudio sobre las teorías de aprendizaje y diseño instruccional que definen el formato del programa. Una lista de requerimientos pedagógicos relacionados con el contenido y la población estudiantil a la que va dirigida el programa. Revisión de los objetivos y contenidos del material educativo del programa. Establecer los límites de las áreas educativas que se van a desarrollar. Establecer un diseño instruccional para el proyecto multimedia, incluyendo los instrumentos de evaluación del usuario sobre lo aprendido. Realizar un estudio sobre las pautas de diseño de interfaz adecuadas a la población estudiantil a la que va dirigida el programa. Establecer los criterios de evaluación del software educativo basados en las características de funcionalidad, usabilidad y fiabilidad (MOSCA). Fase de Elaboración Planificar las actividades necesarias y los recursos requeridos, especificando las características y el diseño de la arquitectura del software. Esta fase culmina con la arquitectura del ciclo de vida (ver tabla 2). MODELO RUP Actualización del plan de iteración. Generar una lista revisada de riesgos. Realizar la arquitectura del software. Revisar los requerimientos complementarios. ACTIVIDADES AGREGADAS A RUP Refinar los modelos instruccionales que se utilizan en el proyecto. Refinar los requerimientos de diseño gráfico y aspectos comunicacionales en base a las pautas 4}

Construir un tipo de prototipo de interfaz del usuario. Actualizar el plan de proyecto y elaborar el plan de iteración. pedagógicas establecidas. Tabla 2. Actividades correspondientes a la fase de elaboración. Fase de Construcción Desarrollar el producto y evolucionar la visión; la arquitectura y los planes hasta que el producto en una primera versión esté listo para ser enviado a la comunidad de usuarios. Esta fase culmina con la capacidad inicial de operación (ver tabla 3). MODELO RUP Actualizar el plan de iteración. Revisar la lista de riesgos. Gerenciar los recursos (herramientas, base de datos). Completar el desarrollo de los componentes (prototipo funcional). Probar los componentes contra los criterios de evaluación definidos. Actualizar el plan de proyecto ACTIVIDADES AGREGADAS A RUP Probar el diseño instruccional, comunicacional y gráfico, contra los criterios de evaluación previamente establecidos. Tabla 3. Actividades correspondientes a la fase de construcción. Fase de Transición Realizar la transición del producto a los usuarios, lo cual incluye: manufactura, envío, entrenamiento, soporte y mantenimiento del producto hasta que el cliente esté satisfecho. Esta fase culmina con la versión de producto, la cual a su vez concluye el ciclo (ver tabla 4). MODELO RUP Realizar la evaluación del usuario. Realizar los ajustes necesarios. Realizar un ajustes de gastos. ACTIVIDADES AGREGADAS A RUP Realizar la evaluación del producto por parte del docente y del estudiante objeto del programa educativo, utilizando MOSCA. Tabla 4. Actividades correspondientes a la fase de elaboración. Prototipo El prototipo elaborado es una extensión de esta metodología, cubriendo solo la primera fase de RUP modificado para el desarrollo de software educativo. A continuación se realiza una breve descripción del prototipo y se muestran algunos entregables. El título del proyecto para los alumnos es: Conservemos nuestra fauna, que tiene como eje integrador el tema de los animales que están en peligro de extinción en Venezuela., para utilizarse como parte de un proyecto pedagógico de aula basado en este tema, y dirigido a alumnos de 8 a 10 años de Educación Básica. Las actividades está centradas en el área de Lengua y Literatura con actividades de lectura. El proyecto contempla además las áreas de matemáticas, ciencias, sociales y educación estética para ser desarrolladas posteriormente. Cada 5}

vez que el usuario seleccione uno de los animales, esto le llevará a una interfaz que incluye información sobre cada animal y actividades en las diversas áreas mencionadas anteriormente. Estas actividades procurarán la construcción del conocimiento sin dejar de lado el desarrollo de procesos cognitivos. Las actividades sugeridas para trabajar en el aula y de manera grupal, promueven el desarrollo de habilidades de socialización tales como la cooperación y el trabajo en equipo. A continuación se muestran algunos de los entregables de la primera fase: modelo del negocio (ver figura 3), casos de uso del sistema (ver figura 4), ejemplo de caso de uso: cuento del cóndor (ver tabla 5) y ejemplo de análisis de un riesgo: Insatisfacción de los docentes en el uso del software (ver tabla 6). Estudiante Coordinación Uso de software educativo (PPA interactivo) Apoya el proceso de enseñanza y aprendizaje a través de PPA Docente Figura 3. Modelo del negocio (PPA: Proyecto Pedagógico de Aula). 6}

Usuario registrar usuario validar usuario introducir respuestas a actividades generar reportes cargar actividades cargar informaci n mostrar informaci n del estudiante eliminar usuario Figura 4. Casos de uso del sistema. Nombre del caso de uso Descripción Eventos típicos Cuento del Cóndor. Este proceso se encarga de mostrar a los usuarios el cuento del cóndor Arcoiris que consta de tres páginas enlazadas por una flecha de siguiente y de anterior. Acciones del actor Respuesta del sistema 1. Este se inicia cuando el usuario selecciona el cuento del cóndor Arcoiris de la lista de cuentos en el caso de uso lengua y literatura. 3. Termina cuando lee la información de la primera página del cuento del cóndor Arcoiris 4. El estudiante presiona el botón siguiente. 5. si el estudiante presiona el botón actividades. 2. El sistema carga la información de la primera página del cuento del cóndor Arcoiris. 6 el sistema activa la siguiente página del cuento. 7. El sistema activa el caso de uso actividades de lengua y literatura. Eventos Alternos Al paso 2 : si ocurre algún error en la búsqueda de la base de datos, devuelve un error de conexión con la base de datos para que el estudiante vuelva a intentar. Pre-condiciones Que el caso de uso lengua y literatura haya dado una respuesta correcta. Tabla 5. Ejemplo de un caso de uso: cuento del cóndor. Identificador Insatisfacción de los docentes en el uso del software. Magnitud 5 Descripción Los docentes consideran que las actividades no están de acuerdo al nivel de los estudiantes; no les parece fácil de usar; no encuentran la ayuda necesaria para su utilización; no poseen manuales de ayuda que apoyan el uso del software o no encuentran la manera de insertar el uso del software dentro de sus actividades pedagógicas. 7}

Impacto Debido a que este software está diseñado para ser usado en conjunto con el docente, es de suma importancia su aceptación. El rechazo de los docentes puede implicar el fracaso del proyecto y una pérdida de tiempo en el rediseño de las actividades y/o de la interfaz. Indicadores Evaluaciones de los docentes obtenidas después de la culminación de cada prototipo en las dos primeras fases del proyecto. Estrategia de Establecer prototipos factibles al cambio y reuniones con personal docente para revisión Mitigación del producto cada vez que se culmine un set de actividades y se diseñe la interfaz. Plan de El curso de acción es invertir más tiempo en la modificación del producto. contingencia Tabla 6. Ejemplo de Riesgo: Insatisfacción de los docentes en el uso del software. En las figuras 5, 6, 7 y 8 se muestran algunas interfaces del prototipo: Figura 5. Interfaz principal. Figura 6. Interfaz de información sobre el cóndor. Figura 7. Interfaz del cuento. Figura 8. Interfaz de la evaluación al alumno. Cabe mencionar que a este prototipo se le realizó una evaluación por parte de educadores y estudiantes, y las sugerencias quedaron registradas para posteriores versiones. Conclusiones Esta investigación se centra en estudiar y proporcionar una metodología para la realización de software educativo, una extensión de Rational Unified Process (RUP) al ámbito educativo, debido a que es una metodología abierta y adaptable al desarrollo de software educativo, lo cual garantiza que se lleven a cabo sólo aquellas actividades y modelos que sean necesarios o útiles para el proyecto a desarrollar. El uso de este método de desarrollo de software permite elaborar un producto que garantiza la calidad del software educativo, tanto en su proceso de desarrollo como en el producto final. Es importante resaltar que dentro de esta metodología se incluyen cuestionarios que monitorean el proceso y el producto, así como 8}

también el manejo de los riesgos en el proceso de desarrollo de software educativo. Esta última actividad implica el planteamiento de soluciones a los posibles problemas a través de estrategias de mitigación y los planes de contingencia. El no tomar en cuenta estos elementos tan importantes pueden llevar el desarrollo de un producto de software educativo al fracaso o al no cumplimiento de las metas establecidas. También se toman en cuenta los requerimientos del usuario y del docente Se realizaron modificaciones a nivel del plan creativo de Rational, de manera que incluyera los aspectos relacionados con software educativo. Se incluyó además, en esta metodología de Rational, un estudio de diseño instruccional, ya que se trata de un material educativo diseñado especialmente para apoyar los procesos de instrucción. Para poder tomar las decisiones correspondientes a la etapa de diseño instruccional, se realizó una revisión de las teorías de aprendizaje y diseño instruccional más recientes, tomando los aspectos relevantes de cada una de ellas para la realización del software educativo. Como base para el desarrollo de los requerimientos pedagógicos, se tomó la guía de los términos de referencia del Ministerio de Ciencia y Tecnología de Venezuela: Agenda de educación y tecnología. Se realizó un prototipo inicial, mediante el cual se muestra cómo se lleva a cabo la primera etapa del Rational Unified Process. El prototipo es realizado hasta la etapa de inicio de Rational, la cual está enfocada principalmente en el entendimiento de los requerimientos y la determinación del alcance del esfuerzo de desarrollo del software educativo. En esta etapa se realizaron los documentos iniciales del proyecto, que en este caso, es la realización de un software educativo centrado en el proyecto pedagógico de aula Conservemos nuestra fauna. En estos documentos se establece la idea, la visión del producto, cómo se enmarca en el negocio y el alcance del proyecto, un diseño instruccional inicial, un diseño creativo inicial y un prototipo que algunas veces podría considerarse desechable, ya que a partir de este prototipo comienzan los cambios en las próximas versiones. Esta primera versión del prototipo fue evaluada por expertos y las sugerencias que realizaron están documentadas para posteriores versiones. Referencias Cohen, S., Chechile, R., Smith, G., Tsai, F., Burns, G. (1994) A method for evaluating the effectiveness of educational software Behavior Research Methods, Instruments & Computers, (26) 236-241. DiGiano, C., Roschele, J. (2000) Rapid assembly componentware (RAC) for Education. In Proceedings of the International workshopon advanced learning technologies, at Palmeston North, New Zealand. IIEE, Computer Sociaty Press, Los Alamitos, CA. pp 37 40. Díaz-Antón, G. (2002) Uso de software educativo de calidad como herramientas de apoyo para el aprendizaje. Jornadas educativas: La escuela como instrumento de cambio, IEA, Abril, Caracas. Sitio web: http://www.academia-interactiva.com/articulos.html M.G.Díaz-Antón, M.A. Pérez, A.C..Grimán, L.Mendoza.(2002). Instrumento de evaluación de software educativo bajo un enfoque sistémico. En el 6to. Congreso Iberoamericano de Informática Educativa y 7mo. Taller Internacional de Software Educativo. Vigo 2002. España.. Sitio web: http://www.lisi.usb.ve/publicaciones\mosca.pdf 9}

Galvis, A., (2000) Ingeniería de software educativo. 2da. reimpresión. Universidad de Los Andes. Ediciones UNIANDES. Colombia. García Roselló, E., González Dacosta, J., Pérez Cota, M., García Pérez-Schofield, J., Valdés Pardo,V.G. (2002) Existe una situación de crisis del software? En el 6to. Congreso Iberoamericano de Informática Educativa y 7mo. Taller Internacional de Software Educativo. Vigo 2002. España. García Roselló, E., González Dacosta, J., Mandado, E., Pérez Cota, M., Baltasar García, J., Valdés Pardo,V.G. (2002)Una propuesta para la reutilización de componentes en el proceso de desarrollo de software educativo. VI Congreso Iberoamericano de Informática Educativa y 7mo. Taller Internacional de Software Educativo. Vigo 2002.España. Gómez Castro, R., Galvis Panqueva, A., Mariño Drews, O. (1998) Ingeniería de software educativo con modelaje orientado por objetos: un medio para desarrollar micromundos interactivos. Revista de Informática Educativa. 11 (1), 9 30. Hinostroza, E., Hepp, P., Straub, P. (1996) Un método de desarrollo de software educativo. Revista de Informática Educativa, 9 (1) 9 32. Koper, R. (1995) PROFIL: a method for the development of multimedia courseware. British Journal of Educational Technology, 26 (2), 94 108. Kruchten, P (1996). A rational development process. Crosstalk, 9 (7) Julio, 11-16. Sitio web: www.rational.com/media/whitepapers/xtalk.pdf Liu, M., Reed, W. (1995) The effect of hypermedia-assisted instruction on second language learning. Journal of Educational computing Research. 12, 159 175. Mariño Drews, O. (1998) Desarrollo de micromundos educativos lúdicos: una perspectiva interdisciplinaria. Revista de Informática Educativa. 11, (2) 193 200. Mayer, R., Shustack, M. Blanton, W. (1997) What do children learn from using computers in an informal, collaborative setting?, Educational Technology, March April, 39 (2) 27 31. Mendoza, B., Galvis Panqueva, A. (1999) Ambientes Virtuales de aprendizaje: una metodología para su creación. Revista de Informática Educativa, 12 (2) 295 317. Mónica Carlier, M.E. (1993)Construcción de MECs con diseño orientado por objetos. Revista de Informática Educativa, 6 (1) 45 54. Neilson L., Thomas, R. (1996) Designing educational software as a re-usable resource. Journal of Computer Assisted Learning. 12, 114 126. Pressman, Roger. (2002) Ingeniería de Software: Un enfoque Práctico. McGraw Hill. 10}

Roschelle, J., Kaput, J. (1996) Educational software architecture and systemic impact: the promise of component software. Journal of Educational Commputing Research, 14 (3), 217 228. Sitio web: http://www.simcalc.umassd.edu/newwebsite/downloads/edsoftwarearch.pdf Roschelle,J., Kaput, J., Kahn, T.M. (1998) Scaleable integration of educational software:exploring the promise of componet architectures. Journal of Interactive Media in Education. 98 (6) 31 pp. Sitio web: http://www-jime.open.ac.uk/98/6 Ward, S. (1999) Building Web Solutions with the Rational Unified Process: Unifying the Creative Design Process and the Software Engineering Process. Sitio web: http://www.rational.com/media/whitepapers/76.pdf Yildirim, Z., Yasar, M., Asku, M. (2001) Comparison of Hypermedia Learning and traditional instruction on knowledge acquisition, The Journal of Educational Research. March- April, 94 (4), 207 214. 11}