Carmen Chay CIIM2010

Instituto Tecnológico de Orizaba “Coloquio de Investigación Multidisciplinaria” Evento Internacional, Septiembre 30-Octubre 01, Orizaba, Veracruz. _____________________________________________________________________________________________

Orizaba, Veracruz Sept. 30 – Oct. 01, 2010 Coloquio de Investigación Multidisciplinaria

CIIM-2010 715

ADAPTACIÓN DE LA METODOLOGÍA ÁNCORA PARA EL DESARROLLO DE SOFTWARE EDUCATIVO

ISC. Carmen Nicté-Há Chay HernándezFacultad de Estadística e Informática, Xalapa, Ver. México

[email protected]

Dra. María Karen Cortés Verdín Universidad Veracruzana. Xalapa, Ver. México.

[email protected]

Dr. Juan Manuel Fernández Peña Universidad Veracruzana. Xalapa, Ver. México.

[email protected]

Área de participación: Investigación Educativa

Resumen

El software educativo va adquiriendo cada vez más relevancia, al grado que muchos autores han propuesto metodologías para la elaboración de software educativo de calidad. Sin embargo, dichas propuestas no son del todo claras, en algunas fases de desarrollo de software no se especifican los medios para obtener los artefactos o no se precisan que artefactos se producen en cada una de ellas. En general, la mayoría de las metodologías creadas para el desarrollo de software educativo le dan más valor a la parte relacionada con el diseño instruccional y menos importancia, a las fases de desarrollo de software como los requerimientos y el diseño. El presente trabajo, aporta un medio para la adquisición de requerimientos de software educativo a través de la metodología Áncora (Sumano, 2006), enfocada a la fase de requerimientos y que ofrece elementos que indican las actividades que deben realizarse, los artefactos que se producen y la forma de obtenerlos. Para que Áncora cubriera algunas características de diseño instruccional, se le adaptaron algunos elementos. A través de un caso de estudio, se comprobó la efectividad de su utilización en la fase de requerimientos para el desarrollo de un software educativo.

Palabras clave: software educativo, requerimientos, diseño, orientado a objetos.

Introducción

En la actualidad, la tecnología ha avanzado significativamente y las nuevas generaciones van creciendo en un ambiente cada vez más tecnológico. Por tal motivo algunas actividades se han ido renovando para irse adaptando a los nuevos retos y cambios que trae consigo el desarrollo de la tecnología. La educación por tanto, se ve afectada por dichos avances, teniendo que cambiar su forma tradicional de enseñanza y adecuarla a lo que este ambiente demanda, utilizando la tecnología para transmitir los conocimientos de una manera más dinámica y sencilla. Por lo anterior, el software educativo adquiere relevancia, ya que tiene como objetivo servir de apoyo a docentes, alumnos y personas en general que desean aprender o reforzar cierta área del conocimiento. Tal es la importancia de este tipo de software que varios autores como Ricardo Gómez et al (Gómez, 1998) y Brian Blum en (Vaughan, 2006), entre otros, han propuesto o adaptado metodologías que permiten desarrollar software educativo de calidad. Sin embargo, no existe una única metodología que indique exactamente cuál es el camino a seguir en la elaboración de un software educativo. Por tal motivo, los autores han dejado abierta la posibilidad de ir mejorando ó proponiendo nuevas metodologías para desarrollar software educativo.



CIIM-2010 716

Conscientes de lo mencionado y después de haber analizando varias metodologías o propuestas enfocadas al desarrollo de software educativo, surge la necesidad de adaptar dos metodologías, Áncora e Iconix, que permiten a través de sus diferentes artefactos, realizar el análisis de requerimientos y el diseño de una aplicación educativa. Por la extensión del trabajo, en este artículo solo se refleja las adecuaciones realizadas a Áncora para la obtención de requerimientos en el desarrollo de un producto software educativo.

La motivación para realizar el presente trabajo se originó al encontrar carencias en las metodologías analizadas. Una de las deficiencias encontradas fue en la fase de requerimientos del desarrollo de software, donde no se especifican los artefactos producidos ni los elementos de apoyo que nos servirán para obtenerlos. Lo anterior deriva del peso que le dan a la parte de diseño instruccional valorando menos las fases de desarrollo del software.

Áncora es una metodología enfocada a la adquisición de requerimientos software, que ofrece guías y elementos de apoyo para la obtención de requerimientos. Al mismo tiempo permite pasar a la fase de diseño de manera sencilla (Sumano, 2006). Aprovechando las ventajas que presenta Áncora, se le hicieron algunas adaptaciones, con el fin de cubrir algunas características del diseño instruccional y enriquecer Áncora, habilitándola para la adquisición de requerimientos de software educativo.

Materiales y métodos

Para el desarrollo de la propuesta de adaptación de Áncora para la adquisición de requerimientos de software educativo, se seleccionaron algunas metodologías y propuestas existentes para la elaboración de software educativo. Con el fin de extraer características principales, que los respectivos autores, consideran necesarios tenerlos presentes durante el desarrollo de una aplicación educativa. Algunas de las metodologías seleccionadas son: metodología de desarrollo de sistemas multimedia (Vaughan, 2006), propuesta de metodología para el diseño, desarrollo y evaluación de software educativo (Reyes, 2009), ingeniería de software educativo con modelaje orientado por objetos (Gómez, 1998), entre otros. Al hacer un análisis de las metodologías seleccionadas, anteriormente mencionadas, se observó que todas ellas presentan elementos en común expresados de diferentes maneras pero que al final buscan el mismo objetivo: crear software educativo de calidad. Algunos características principales son:

Análisis del público al que se dirigirá el software

Problema ó necesidad educativa a atender

Análisis de contenido (Tema a tratar, actividades para alcanzar el objetivo de enseñanza y forma de evaluarlo)

Actividades ó forma actual de llevar a cabo la enseñanza del tema en cuestión

Elaboración de guiones, metáforas, escenarios

Creación de prototipo ó Storyboard

Diseño de interfaz

Mapas de navegación

Modelos de datos

Elaboración de diagramas de contexto, diagramas de flujo o diagramas de casos de uso Además, para comprender el contexto de diseño instruccional se eligieron el modelo ADDIE (Análisis,Diseño, Desarrollo, Implantación y Evaluación) de (McGriff, 2000) y el diseño instruccional aplicado al desarrollo de software educativo EISE (Especificación Instruccional de Software Educativo) de (Hernández, 2005). Se eligió el modelo ADDIE por ser el modelo de diseño instruccional más



CIIM-2010 717

conocido y considerarse un modelo genérico, del que se derivan otros más. El EISE se seleccionó porque se enfoca a la fase de requerimientos. Considerando características principales para el desarrollo de software educativo, la comprensión del entorno del diseño instruccional y tomando en cuenta los beneficios que ofrece Áncora, se establece la propuesta de seleccionar las actividades de Áncora que permitan obtener los requerimientos de un software educativo. La Tabla 1 presenta las actividades y artefactos producidos en las fases de Áncora para la elaboración de software educativo. Tabla 1. Actividades y artefactos de la metodología Áncora para el desarrollo de software educativo.

Metodología Áncora Fases Actividades y artefactos

Análisis de Requerimientos

A través de entrevistas con los clientes (maestros y pedagogos) y de la lectura del respectivo material proporcionado por ellos, se definirá la asignatura a la que se enfocará el software, el tema a tratar y la forma en que se abordará y evaluará. También se establecerá el objetivo general de aprendizaje, la metáfora que se empleará y, se determinará el público al que se dirigirá el software.

Artefactos:Documento que define la asignatura, contenido, objetivo general de aprendizaje, metáfora y público al que se dirigirá el software. Guión de la situación actual.

Recolección y clasificación de requerimientos

El guión de la propuesta computacional reflejará la metáfora que se sigue, el ambiente de cada escena.

La bitácora de desarrollo permitirá ver cómo el sistema responderá a las diversas acciones que realice el usuario.

En lugar del prototipo rápido se elaborará un Storyboard para presentar gráficamente la estructura de sistema propuesto.

ArtefactosGuión de propuesta computacional, bitácora de desarrollo, Storyboard.

Resolución de conflictos, jerarquización y validación de requerimientos

Modificaciones al guión de la propuesta computacional, de acuerdo a los cambios propuestos por los maestros y pedagogos.

ArtefactosGuión de propuesta computacional e Storyboard con adecuaciones señalas.

Cierre

Trasladar los guiones a casos de uso.

ArtefactosCasos de uso.

Se agregaron algunas características a ciertos artefactos de Áncora para poder cubrir los requerimientos de software educativo. Uno de estos elementos, es el guión de la propuesta computacional al que se propone agregar lo siguiente:

Conocimientos previos del usuario: Se refiere a los conocimientos básicos o mínimos que debe tener el alumno para poder interactuar con el módulo.

Objetivo de aprendizaje: Es el aprendizaje que debe obtener el alumno después de haber interactuado con el módulo.

La Figura 1 se presenta la estructura sugerida para el guión de la propuesta computacional. En la bitácora de desarrollo se propone añadir una fila, al final de cada pista, donde se describan las situaciones favorables y no favorables para el cumplimiento del objetivo de aprendizaje, para esa pista en particular. Por otra parte, en lugar del prototipo, se sugiere utilizar el Storyboard, ya que permite mostrar de manera más completa la estructura del guión de la propuesta computacional. La Figura 2 muestra el formato para la elaboración del Storyboard.



CIIM-2010 718

Guión.- Nombre del sistema.

Pista.- Nombre del módulo.

Papeles.- Roles que se presentan en el módulo.

Utensilios.- Nombre de objetos que se utilizarán.

Condiciones de Entrada.- Eventos que deben cubrirse al iniciar el módulo.

Conocimientos previos del usuario.- Conocimientos básicos que debe tener el alumno para poder interactuar con el módulo.

Condiciones de Salida.- Consecuencias resultantes al finalizar el módulo.

Objetivo de aprendizaje.- Aprendizaje obtenido al finalizar su interacción con el módulo

Escena 1 …. descripción de cada escena.

Escena N

Figura 1. Estructura del guión para la propuesta computacional

Figura 2. Formato para la elaboración del Storyboard.

Resultados y discusión

Para evaluar la propuesta se empleo un caso de estudio, en el que se tiene como finalidad reforzar en los niños de primaria, sus conocimientos en el área de las matemáticas. Empleando la metáfora de una distribuidora de quesos por ser una actividad característica del estado de Veracruz y con la que los niños se pueden identificar. Aplicando Áncora para la parte de requerimientos se obtuvo la siguiente información:

Asignatura: Matemáticas Contenido. Está articulado con base en seis ejes, con sus respectivos temas y subtemas (SEP,

2009) que varían de acuerdo al grado escolar. Considerando lo anterior se tiene lo siguiente: a) Grado escolar: De segundo hasta quinto grado de primaria. b) Temas: Números naturales, capacidad, peso, tiempo y ubicación espacial;

planteamiento y resolución de problemas sencillos en los que se requiera recolectar y registrar información periódicamente; representación de información en tablas de frecuencia y gráficas de barras; registros de los resultados de experimentos aleatorios; representación de los resultados de un experimento aleatorio en tablas y gráficas.

c) Subtemas: Planteamiento y resolución de problemas que impliquen dos o más operaciones con números naturales.

d) Ejes: Introducción del kilómetro como la unidad que permite medir grandes distancias y recorridos largos; capacidad, peso y tiempo; uso del reloj y el calendario, los números sus relaciones y sus operaciones; medición; la predicción y el azar; tratamiento de la información.

Objetivo general de aprendizaje: Ejercitar las operaciones aritméticas básicas, interpretar la información y los resultados de la información dada, aplicada en situaciones de la vida cotidiana.

Título pista Escena No. Referencia

Descripción de la pista Descripción de objetivo de enseñanza Ambiente

Bosquejo de pantalla



CIIM-2010 719

Metáfora: Distribuidora de quesos. El alumno conocerá el proceso de distribución de quesos, bajo un esquema de oferta y demanda.

Público al que se dirigirá. Niños de 7 años en adelante. Guión de propuesta computacional. Con la información recabada se obtuvo la propuesta para el

desarrollo del software. La Figura 3 presenta el guión para la pista comprar recursos. Bitácora de desarrollo. La Tabla 2, presenta parte de la bitácora correspondiente a la escena

adquirir quesos del guión del módulo comprar recursos. Storyboard. Para la escena adquirir quesos de la pista comprar recursos, su representación en

el Storyboard se presenta en la Figura 4. Casos de uso. Por cuestiones de espacio, se omite este modelo en el presente trabajo.

Con las actividades hasta ahora realizadas, se ha observado que los artefactos de Áncora son flexibles y pueden, por lo tanto, adaptarse de acuerdo a las necesidades que implican la adquisición de requerimientos de un software educativo. También se aprecian las ventajas de algunos artefactos, como la bitácora de desarrollo, que permite determinar las respuestas del sistema ante las acciones del usuario y estimar también el tiempo que llevará implementar cada quinteta. La estimación del tiempo ayuda a tener un valor aproximado del tiempo de desarrollo de software. Agregar el objetivo de aprendizaje a la bitácora de desarrollo puede parecer repetitivo después de incluirlo en el Storyboard pero ésto nos permite ver las situaciones u obstáculos que pueden impedir que el objetivo de aprendizaje se alcance y por tanto, tenerlos presente durante el diseño. A pesar de las ventajas de la bitácora de desarrollo, un inconveniente hasta ahora encontrado, es lo tedioso al manejar muchas quintetas, cuando, por la naturaleza del guión, se tienen varios avisos y mensajes para el usuario. Por otra parte, los guiones, han ayudado a realizar de manera sencilla el modelo de casos de uso. En lo referente a la presentación con los clientes, el guión es un artefacto que pude dar un panorama general del software que se va a elaborar y queda reforzada a través de los Storyboard. Cuando se requieren cambios solicitados por los clientes, las modificaciones a estos artefactos no han sido muy complicadas, dado que por su estructura, es fácil de ubicar las secciones y respectivos elementos. Con los resultados hasta ahora obtenidos, se puede decir que la propuesta permite a los desarrolladores con poca experiencia en desarrollo de software educativo obtener los requerimientos de una manera sencilla.



CIIM-2010 720

Figura 3. Guión de propuesta computacional, módulo comprar recursos para la distribuidora de quesos.

Guión: Distribuidora de quesos Pista: Comprar recursos Papeles: D= Distribuidor V= Vendedor Utensilios: CAP= Capital TQ = Tipo Queso TR = Tipo Refrigerador TC = Tipo Camión REF = Refrigerador CAM = Camión Q= Quesos ALM = Almacén CT = Costo CTQ = Costo Total de cada tipo de queso STQ = Suma Total de los costos de los quesos RESULT= Resultado DEM = Demanda CANT = Cantidad FT = Ficha técnica CTT= Compra Total PRE= Precio Msg= Mensaje Condiciones de entrada: D necesita recursos Conocimientos previos del usuario: D maneja operaciones de suma, resta y multiplicación Condiciones de salida: D aumentó sus recursos Objetivo de aprendizaje: Practicar operaciones matemáticas básicas Aprender a tomar decisiones, de qué y cuanto comprar.

Escena 1: Adquirir quesos D selecciona Adquirir quesos y se muestra CAP V muestra lista TQ con su CT D revisa cada TQ con su DEM y CANT en ALM D escribe CANT de TQ a comprar D multiplica CANT de cada TQ por su CT y escribe CTQ D suma los CTQ y escribe STQ CAP es mayor o igual STQ ¿CAP < STQ? D recibe Msg: “No hay suficiente capital” D resta CAP menos STQ D escribe RESULT ¿Resultado incorrecto? D recibe Msg: “Resta incorrecta, intenta de nuevo” D recibe Msg: “Operación correcta!! Felicidades!!” CAP disminuye y se muestra nuevo valor D aumenta ALM de Q D recibe Msg: “ Tienes que asignar precios” D asigna PRE de venta a cada TQ Escena 2: Adquirir camiones D selecciona Adquirir camiones y se muestra CAP V muestra lista CAM con su FT D elige un CAM CAP es mayor o igual CT de CAM ¿CAP < CT CAM? D recibe Msg: “No hay suficiente capital” D resta CAP menos CT D escribe RESULT ¿Resultado incorrecto?

D recibe Msg: “Resta incorrecta, intenta de nuevo” D recibe Msg: “Operación correcta!! Felicidades!!” CAP disminuye y se muestra nuevo valor D aumenta ALM de CAM Escena 3: Adquirir refrigeradores D selecciona Adquirir refrigeradores y se muestra CAP V muestra lista REF con su FT D elige un REF CAP es mayor o igual CT de REF

¿CAP < CT REF?

D recibe Msg: “No hay suficiente capital” D resta CAP menos CT D escribe RESULT ¿Resultado incorrecto?

D recibe Msg: “Resta incorrecta, intenta de nuevo” D recibe Msg: “Operación correcta!! Felicidades!!” CAP disminuye y se muestra nuevo valor D aumenta ALM de REF

Instituto Tecnológico de Orizaba “Coloquio de Investigación Multidisciplinaria” Evento Internacional, Septiembre 30-Octubre 01, Orizaba, Veracruz. _Tabla 2. Bitácora de desarrollo para la escena adquirir quesos de la escena comprar recursos. Quinteta Forma de comprobación Tiempo Tiempo


CIIM-2010 721

propuesto real

D selecciona Adquirir quesos y se muestra CAP

Deseable: El sistema lee exitosamente el archivo donde se guarda CAP y lo despliega en pantalla. Indeseable: Falle la lectura del archivo, no aparezca CAP.

4 hrs.

V muestra lista TQ con su CT

Deseable: El sistema lee exitosamente el archivo donde se guarda el catálogo de los quesos. Presenta en pantalla cada TQ con su respectivo CT. Indeseable: Falle la lectura del archivo, no aparezca ninguna información.

8 hrs.

D revisa cada TQ con su DEM y CANT en ALM

Deseable: El sistema lee exitosamente el archivo donde se guardan los pedidos y el ALM de quesos. Posteriormente muestra en pantalla cada TQ con su respectiva DEM y su CANT en ALM. Indeseable: Falle la lectura del archivo, no aparezcan los TQ, ni sus respectiva DEM. Indeseable: No se muestre la DEM de cada TQ.

8 hrs.

D escribe CANT de TQ a comprar

Deseable: Esté activado el campo de cantidad y D escribe la CANT de cada TQ que desea comprar. Indeseable: No se active el campo y / o no esté visible.

1 hrs.

D multiplica CANT de cada TQ por su CT y escribe CTQ

Deseable: Los campos para escribir el CTQ, estén visibles y activados. El D multiplica la CANT de cada TQ por su respectivo CT y escribe el resultado (CTQ) en el campo cantidad. Indeseable: Campos de CTQ estén inactivos o no visibles.

4 hrs.

D suma los CTQ y escribe STQ

Deseable: El campo de la suma total este visible y activo. El D escribe el campo de suma total, la suma (STQ) de todos los CTQ. Indeseable: El campo de la suma total este inactivo o no visible.

4 hrs.

CAP es mayor o igual STQ

Deseable: El sistema compare CAP disponible con la STQ. Indeseable: El sistema no realice la comparación.

1 hrs.

D recibe Msg: “No hay suficiente capital”

Deseable: Si el CAP es menor al STQ, envíe el Msg: “no hay suficiente capital” y no se permita pasar a la sección de operaciones. Indeseable: No se envíe el Msg. y se permita pasar a la sección de operaciones.

1 hrs.

D resta CAP menos STQ

Deseable: El sistema active la sección para realizar las operaciones, muestre el CAP actual y el D escriba STQ. Indeseable: No se active la sección de operaciones. Indeseable: No aparezca en pantalla el CAP actual.

1 hrs.

D escribe RESULT

Deseable: El campo para escribir RESULT este visible y activo. Indeseable: El campo de resultado este inactivo o no visible.

1 hrs.

D recibe Msg: “Resta incorrecta, intenta de nuevo”

Deseable: El sistema envía Msg: “Resta incorrecta, intenta de nuevo”, cuando el resultado que escribió D es incorrecto. Indeseable: No se envíe ningún mensaje.

1 hrs.

D recibe Msg: “Operación correcta!! Felicidades!!”

Deseable: El sistema envía Msg: “Operación correcta!! Felicidades!!”, cuando el resultado que escribió D es correcto. Indeseable: No se envíe ningún mensaje.

1 hrs.

CAP disminuye y se muestra nuevo valor

Deseable: El sistema realice la resta de CAP menos STQ, actualice el archivo de CAP y muestre en pantalla el CAP actualizado. Indeseable: No aparezca en pantalla el CAP actual. Indeseable: No se actualice el archivo de CAP.

5 hrs.

D aumenta ALM de Q

Deseable: El sistema actualice el archivo del ALM de Q y muestre las nuevas cantidades de cada Q. Indeseable: No se actualice el archivo de ALM de Q y se muestren las nuevas cantidades de cada Q. Indeseable: Se actualice el archivo de almacén de quesos pero no se muestren las nuevas cantidades de cada Q.

5 hrs.

objetivo de

aprendizaje

Deseable: Aprender a interpretar la información que se le presenta y poder tomar decisiones sobre los recursos que posee. Al mismo tiempo reforzar sus conocimientos matemáticos básicos. Indeseable: Que el alumno no entienda la información que se le presenta.



CIIM-2010 722

Figura 4. Storyboard para la escena adquirir quesos de la pista comprar recursos

Conclusiones

Aprovechando las ventajas que presenta Áncora, en la fase de requerimientos software, se le adaptaron algunas características de diseño instruccional con el fin de enriquecerla permitiendo obtener los requerimientos para la elaboración de un software educativo. A través de un caso de estudio se concluyó que las adaptaciones propuestas, a pesar de algunos inconvenientes que pudieran presentarse, es una guía útil para los desarrolladores inexpertos en la elaboración de aplicaciones educativas. Dentro de las actividades pendientes en la fase de requerimientos, se sugiere comprobar que los guiones de la propuesta computacional, presentados en el caso de estudio, puedan ser reutilizables para sistemas similares, característica particular de Áncora (Sumano, 2006). Además, para continuar con el ciclo de vida del desarrollo de software, se propone emplear la metodología Iconix (Rosenberg et al, 2005), que muestra las actividades que se deben realizarse es cada una de sus etapas así

Título pista: Comprar recursos Escena: Adquirir quesos No. Referencia: 1/3

Descripción de la pista: En la pantalla para la compra de quesos se despliega el costo por kilo de cada tipo de queso y la información referente a cada uno de ellos (cantidad que se tiene en almacén y la cantidad demandada por los pedidos). El usuario deberá seleccionar la cantidad que desea comprar de cada tipo de queso, el sistema automáticamente le proporcionará el total de compra de cada tipo de queso. Posteriormente, cuando el usuario termine de seleccionar la cantidad de cada tipo de queso, sumará los totales y el total de su compra. Al final de la pantalla, aparecerá una sección de operaciones donde se mostrará el capital que se tiene hasta ese momento, el usuario escribirá el total de su compra realizada (si el capital es mayor a su total de compra) y restará dicha cantidad al capital. Cuando pulse el botón Comprar se le avisará si fue correcta o no la operación. Cuando la operación sea correcta, se desplegará una pantalla, donde el usuario asignará los precios a los que venderá cada tipo de queso. Cuando el usuario pulse el botón Guardar precios, se regresará a la escena Adquirir quesos. El capital se actualiza después de cada compra. Esta escena tiene la flexibilidad de poder pasar a cualquiera de los otros dos escenarios de compra o a cualquiera de los otros módulos.

Descripción de objetivo de enseñanza: Aprender a utilizar la información presentada y poder tomar decisiones. Practicar en situaciones reales las operaciones básicas matemáticas.

Ambiente: Esta escena representa las actividades que tiene que realizar un distribuidor de quesos para tener su almacén de quesos lo suficientemente lleno para abastecer sus pedidos. También presenta la responsabilidad d l di t ib id i l i d l d t l f i



CIIM-2010 723

como los artefactos que se producen en cada una de ellas. Al utilizar Iconix, se asegura un software de calidad, porque ofrece un fácil mantenimiento y evolución en el desarrollo de un sistema.

Agradecimientos

Agradecemos a la Dra. María de los Ángeles Sumano López el apoyo y estímulo brindado, a través de sus sugerencias y comentarios certeros, para la realización del presente trabajo.

Referencias1 Acosta P. B., Jaramillo V. B. (2008). Desarrollo del sistema de gestión académica de comunidades de

aprendizaje para la universidad intercultural Amawtay Wasi; Tesis de Licenciatura, Escuela Politécnica Nacional, República del Ecuador. 29-150.

2 Gómez C.R., Galvis P. A., Mariño D. Olga. (1998). Ingeniería de software educativo con modelaje orientado por objetos: un medio para desarrollar micromundos interactivos. Informática Educativa UNIANDES-LIDIE. 2(1), 9-20.

3 González A. A. (2009). Multimedia “Tecnologías para la educación”. Software Gurú [Revista electrónica]. Recuperado el 5 de Marzo de 2010, de http://www.sg.com.mx/content/view/892/1/

4 Hernández E. Diseño instruccional aplicado al desarrollo de software educativo. Encuentro Nacional de Educación Superior, Universidad Autónoma de México, México, 20 al 24 de Junio de 2005.

5 López L. TOONIX: Herramienta de apoyo para el aprendizaje del modelo de dominio de la metodología Iconix; Tesis de Maestría, Universidad Veracruzana, Veracruz, México, 2009.

6 Rosenberg D., Stephens M. and Collins M. Agile development with Iconix process: people, process, and pragmatism; Apress, Berkeley,CA, 2005.

7 SEP. Programas de estudios educación básica primaria, Matemáticas. 2009. 8 Sumano A. Áncora: Análisis de requerimientos de software conducente al reuso de artefactos;

Universidad Veracruzana, México, 2006, p. 63-105. 9 Universidad Tecnológica de Bolivar (2008). El guión multimedia. Recuperado el 1 de Mayo de 2010 de

http://www.slideshare.net/chojaraba/guion-multimedia-1833463 10 Vaughan T. Multimedia: Making it work; McGraw-Hill, Berkeley, CA, 2006. 11 Zamudio R. Diseño y aplicación de una guía de usabilidad para el desarrollo de software educativo

multimedia para niños de primer grado de primaria; Tesis de Maestría, Universidad Veracruzana, Veracruz, México, 2008.

Acerca del autor

La I.S.C. Carmen Nicté-Há Chay Hernández cursó sus estudios de licenciatura en Ingeniería en Sistemas Computacionales en el Instituto Tecnológico de Mérida. Actualmente es estudiante de posgrado en la Universidad Veracruzana, en la Maestría en Ingeniería de Software. Así mismo labora como personal de apoyo en la Facultad de Estadística e Informática de la Universidad Veracruzana. La Dra. María Karen Cortés Verdín realizó sus estudios de Licenciatura en Informática de la Universidad Veracruzana. Se graduó como Master of Science in Information Systems por el University of Manchester Institute of Science and Technology (UMIST) en el Reino Unido. Posteriormente se graduó como Maestro en Ingeniería de Software por el Centro de Investigación en Matemáticas A.C. (CIMAT) y como Doctor en Ciencias de la Computación también en el Centro de Investigación en Matemáticas A.C. (CIMAT). Se desempeñó como investigador en el Instituto de Investigaciones Eléctricas (IIE) en Cuernavaca Morelos, desempeño varios puestos en Gobierno del Estado de Veracruz. Actualmente es profesor de Tiempo Completo de la Facultad de Estadística e Informática de la Universidad Veracruzana. El Dr. Juan Manuel Fernández Peña cursó sus estudios de licenciatura en Física en la Facultad de Ciencias de la UNAM (Universidad Autónoma de México), de Maestría en Investigación de Operaciones en el Instituto de Ingeniería de la UNAM y Doctorado en Ciencias de la Computación en el Centro de Investigación en Computación del IPN (Instituto Politécnico Nacional). Trabajó como investigador de 1971 a 1980 en el IIMAS (Instituto de Investigaciones en Matemáticas Aplicadas y en Sistemas) de la UNAM, como docente en diversas Universidades y desarrollando software a particulares. Actualmente es docente en la Universidad Veracruzana.



CIIM-2010 724

Autorización y renuncia

Los autores del presente artículo autorizan al Instituto Tecnológico de Orizaba (ITO) para publicar el escrito en el libro electrónico del coloquio de investigación multidisciplinaria, en su edición 2010. El ITO o los editores no son responsables ni por el contenido ni por las implicaciones de lo que está expresado en el escrito.

Carmen Chay CIIM2010

Documents