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 Elaboraci—n Construcci—n Transici—n

(Inception) (Elaboration) (Construction) (Transition)

Objetivos del Arquitectura del Capacidad de Producto

Ciclo de Ciclo de Vida Operacionalidad Final
Vida Inicial

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 análisis de las necesidades educativas y del
• Un plan del proyecto que muestre las fases y las entorno educativo.
iteraciones. • Un estudio sobre las teorías de aprendizaje y
• Un caso de negocio inicial el cual incluye: diseño instruccional que definen el formato del
contexto del negocio, criterios de éxito y programa.
planificación financiera. • Una lista de requerimientos pedagógicos
• El modelo de casos de uso con una lista de todos relacionados con el contenido y la población
los casos de uso y los actores que puedan ser estudiantil a la que va dirigida el programa.
identificados. • Revisión de los objetivos y contenidos del
• Un glosario inicial del proyecto. material educativo del programa.
• Un estudio inicial de riesgos. • Establecer los límites de las áreas educativas que
• Una lista de los requerimientos y restricciones se van a desarrollar.
principales del sistema a desarrollar. • Establecer un diseño instruccional para el
• Estándares para el prototipo inicial. proyecto multimedia, incluyendo los instrumentos
• Un mapa de navegación. de evaluación del usuario sobre lo aprendido.
• Una lista inicial de riesgos y su evaluación. • Realizar un estudio sobre las pautas de diseño de
• Una lista de requisitos funcionales y no interfaz adecuadas a la población estudiantil a la
funcionales. que va dirigida el programa.
• Establecer los criterios de evaluación del software
• Un prototipo inicial. educativo basados en las características de
funcionalidad, usabilidad y fiabilidad (MOSCA).
Tabla 1. Actividades correspondientes a la fase de inicio.

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 ACTIVIDADES AGREGADAS A RUP
• Actualización del plan de iteración. • Refinar los modelos instruccionales que se
• Generar una lista revisada de riesgos. utilizan en el proyecto.
• Realizar la arquitectura del software.
• Refinar los requerimientos de diseño gráfico y
• Revisar los requerimientos complementarios. aspectos comunicacionales en base a las pautas

4}
• Construir un tipo de prototipo de interfaz del pedagógicas establecidas.
usuario.
• Actualizar el plan de proyecto y elaborar el plan
de iteración.
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 ACTIVIDADES AGREGADAS A RUP

• Actualizar el plan de iteración. • Probar el diseño instruccional, comunicacional y
• Revisar la lista de riesgos. gráfico, contra los criterios de evaluación
• Gerenciar los recursos (herramientas, base de previamente establecidos.
datos).
• Completar el desarrollo de los componentes
(prototipo funcional).
• Probar los componentes contra los criterios de
evaluación definidos.
• Actualizar el plan de proyecto
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 ACTIVIDADES AGREGADAS A RUP

• Realizar la evaluación del usuario. • Realizar la evaluación del producto por parte del
• Realizar los ajustes necesarios. docente y del estudiante objeto del programa
• Realizar un ajustes de gastos. 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

Apoya el proceso de
Uso de enseñanza y aprendizaje
software educativo a través de PPA
(PPA interactivo)

Docente

Figura 3. Modelo del negocio (PPA: Proyecto Pedagógico de Aula).

6}
 Usuario

registrar usuario validar usuario

introducir respuestas
generar reportes
a actividades

cargar informaci—n
mostrar informaci—n
del estudiante
cargar actividades

eliminar usuario

Figura 4. Casos de uso del sistema.

Nombre del caso Cuento del Cóndor.
de uso
Descripción 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.
Eventos típicos 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. 2. El sistema carga la información de
la primera página del cuento del
3. Termina cuando lee la información de la cóndor Arcoiris.
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 6 el sistema activa la siguiente página
actividades. 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}