UNIVERSIDAD DE PANAMÁ

FACULTAD DE INFORMÁTICA, ELECTRÓNICA Y COMUNICACIÓN

ESCUELA DE INGENIERÍA EN INFORMÁTICA

IMPLEMENTACIÓN DE LA PLATAFORMA DE EVALUACIÓN EDUCATIVA DE

CIENCIAS Y MATEMÁTICAS DE ESTUDIANTES Y DOCENTES PARA LA
SECRETARÍA NACIONAL DE CIENCIA, TECNOLOGÍA E INNOVACIÓN DE LA
REPÚBLICA DE PANAMÁ.

TRABAJO DE GRADUACIÒN
PARA OPTAR POR EL TÍTULO DE
LICENCIADO EN INFORMÁTICA

ELABORADO POR:
FERNANDO GONZÁLEZ
ROSA JIMÉNEZ

PANAMÁ
DICIEMBRE, 2017
 PROFESOR ASESOR
MGTR. IVÁN PABLO ARMUELLES VOINOV
DEPARTAMENTO DE ELECTRÓNICA Y COMUNICACIÓN
 AGRADECIMIENTO

Detrás de todo estudiante, sin importar el área de estudio, están sus familiares, personas
especiales que con mucho esfuerzo, en nuestros primeros años de vida, nos han guiado
para valorar la educación, forjar las ansias de superación y soñar con un futuro
prometedor.

Un profundo agradecimiento a nuestros padres por ser los pilares indispensables en

nuestras vidas.

Este trabajo no sería posible sin la colaboración de todos los profesores que han formado
parte de nuestras vidas universitarias, estos agentes que han sembrado en nosotros los
pilares de los conocimientos en todas las áreas que nos hacen ser futuros ingenieros.

En especial agradecemos a nuestro asesor, Prof. Iván Armuelles por sus consejos y guía
acertada, durante el desarrollo de la tesis.

Al personal de la Dirección de Aprendizaje y Popularización en la Secretaría Nacional de

Ciencia, Tecnología e Innovación (SENACYT), quienes nos abrieron las puertas y nos
brindaron su confianza para poder trabajar en la elaboración del presente trabajo.

A todos gracias.

El éxito no es una carrera de 100 metros, sino una maratón. Se requiere paciencia,
perseverancia y soportar el dolor para llegar a la meta.

i
 DEDICATORIA

“Dios nos hizo perfectos y no elige a los capacitados, capacita a los

elegidos. Hacer o no hacer algo sólo depende de nuestra
voluntad y perseverancia”.
A mi padre Ulises Jiménez Q.E.P.D.

Dedico este trabajo a mis padres Manuela y Ronaldo por su incondicional apoyo
durante mis años de estudio y por la constante motivación para lograr esta meta.

ii
 INDICE GENERAL

AGRADECIMIENTO ...................................................................................................................... i
DEDICATORIA .............................................................................................................................ii
ÍNDICE DE FIGURAS .................................................................................................................... vi
RESUMEN .................................................................................................................................... viii
INTRODUCCIÓN ........................................................................................................................... ix
CAPÍTULO 1 ................................................................................................................................. 12
ANTECEDENTES DEL PROYECTO .......................................................................................... 12
1.1 Definición del Problema ................................................................................................. 13
1.2 Objetivos de la Investigación ......................................................................................... 13
1.2.1 Objetivos Generales ............................................................................................... 13
1.2.2 Objetivos Específicos ............................................................................................. 13
1.3 Descripción del proyecto ............................................................................................... 14
1.4 Metodología ................................................................................................................... 15
1.5 Delimitación o alcance de la investigación .................................................................... 16
1.6 Restricciones .................................................................................................................. 17
1.7 Justificación e importancia del estudio .......................................................................... 17
1.8 Generalidades de la empresa ........................................................................................ 18
1.8.1 Misión ........................................................................................................................... 18
1.8.2 Visión ........................................................................................................................... 18
1.8.3 Valores .......................................................................................................................... 18
1.8.4 Estructura Organizativa.......................................................................................... 19
1.8.5 Dirección de Aprendizaje y Popularización ............................................................ 19
1.8.6 Dirección de Gestión de Ciencia y Tecnología ....................................................... 19
CAPÍTULO 2 .................................................................................................................................... 21
MARCO TEÓRICO ........................................................................................................................... 21
2.1 Aplicaciones de la Web ........................................................................................................ 22
2.2 Aplicaciones Móviles ............................................................................................................ 23

iii
 2.3 Arquitectura de las aplicaciones Web............................................................................ 25
2.4. Estado de la enseñanza-aprendizaje en escuelas primarias .......................................... 27
CAPÍTULO 3 .................................................................................................................................... 31
ANÁLISIS Y DISEÑO DEL SISTEMA................................................................................................... 31
3.1 Especificación de los requerimientos de la Plataforma ....................................................... 32
3.1.1 Recolección de datos ..................................................................................................... 32
3.1.2 Análisis de la Información ............................................................................................ 33
3.1.3 Presentación de resultados ............................................................................................ 34
3.2 Análisis del Sistema .............................................................................................................. 35
3.2.1 Sistema Actual .............................................................................................................. 35
3.2.1.1 Situación del sistema actual ....................................................................................... 35
3.2.1.2 Diagrama general del sistema actual ..................................................................... 36
3.2.2 Alternativas de Solución ............................................................................................... 36
3.3 Diseño del sistema ............................................................................................................... 40
3.3.1 Sistema propuesto ......................................................................................................... 40
3.3.1.1 Aplicación móvil ........................................................................................................ 40
3.3.1.2 Aplicación web .......................................................................................................... 41
3.3.2 Diagrama General ......................................................................................................... 42
3.3.3 Especificaciones de Hardware y Software .................................................................... 42
3.3.3.1 Hardware.................................................................................................................... 42
3.3.3.2 Software ..................................................................................................................... 43
3.3.4 Seguridad ...................................................................................................................... 44
3.4 Modelado de Base de datos................................................................................................. 44
3.4.1 Diseño Conceptual ............................................................................................................ 44
3.4.2 Diseño Lógico ............................................................................................................... 45
3.4.3 Diseño Físico................................................................................................................. 48
CAPÍTULO 4 ................................................................................................................................. 58
DESARROLLO E IMPLEMENTACIÓN DEL SISTEMA .......................................................... 58
4.1 Desarrollo del sistema y sus Interfaces ................................................................................ 59
4.1.1 Aplicación Web............................................................................................................. 59
4.1.2 Aplicación Móvil .......................................................................................................... 62
4.2 Ejecución, pruebas y ajustes ................................................................................................ 63

iv
 4.3 Resultados y evaluaciones ................................................................................................... 66
4.4.1 Entrenamiento al usuario .............................................................................................. 68
4.4.2 Pruebas en paralelo ...................................................................................................... 68
CONCLUSIONES .............................................................................................................................. 70
RECOMENDACIONES ...................................................................................................................... 71
BIBLIOGRAFÍA................................................................................................................................. 72
ANEXOS .......................................................................................................................................... 58

v
 ÍNDICE DE FIGURAS

Figura 1.1 Organigrama de SENACYT ............................................................................. 19

Figura 2.1 Arquitectura de tres capas................................................................................. 27
Figura 3.1 Reunión preliminar para especificación de requerimientos ............................. 33
Figura 3.2 Diagrama General del Sistema Actual.............................................................. 36
Figura 3.3. Diagrama General del sistema propuesto ........................................................ 42
Figura 3.4 Diseño conceptual de una versión de datos ...................................................... 45
Figura 3.5 Diseño Lógico de Usuarios y sus componentes ............................................... 45
Figura 3.6 Diseño Lógico de Estudiantes y Docentes ....................................................... 46
Figura 3.7 Diseño Lógico de Versión de Datos ................................................................. 46
Figura 3.8 Diseño Lógico de Encuestas y sus componentes.............................................. 47
Figura 3.9 Diseño Lógico de Pruebas y sus componentes ................................................. 47
Figura 3.10 Diseño Físico – Base de datos Plataforma...................................................... 48
Figura 3.11 Diseño Físico – Tabla de Asignaturas ............................................................ 48
Figura 3.12 Diseño Físico – Tabla de Centros Educativos ................................................ 48
Figura 3.13 Diseño Físico – Tabla de Configuración ........................................................ 49
Figura 3.14 Diseño Físico – Tabla de Corregimientos ...................................................... 49
Figura 3.15 Diseño Físico – Tabla de Distritos ................................................................. 49
Figura 3.16 Diseño Físico – Tabla de Docentes ................................................................ 50
Figura 3.17 Diseño Físico – Tabla de relación entre docentes y grupos ........................... 50
Figura 3.18 Diseño Físico – Tabla de Encuestas ............................................................... 50
Figura 3.19 Diseño Físico – Tabla de relación entre encuestas y preguntas ..................... 51
Figura 3.20 Diseño Físico – Tabla de Estudiantes ............................................................. 51
Figura 3.21 Diseño Físico – Tabla de Grupos ................................................................... 51
Figura 3.22 Diseño Físico – Tabla de Permisos ................................................................ 52
Figura 3.23 Diseño Físico – Tabla de Preguntas para encuestas ....................................... 52
Figura 3.24 Diseño Físico – Tabla de Preguntas para pruebas .......................................... 52
Figura 3.25 Diseño Físico – Tabla de Provincias .............................................................. 53
Figura 3.26 Diseño Físico – Tabla de Pruebas .................................................................. 53

vi
Figura 3.27 Diseño Físico – Tabla de relación de pruebas y preguntas ............................ 53
Figura 3.28 Diseño Físico – Tabla de Respuestas de docentes .......................................... 54
Figura 3.29 Diseño Físico – Tabla de Respuestas de Estudiantes ..................................... 55
Figura 3.30 Diseño Físico – Tabla de Respuestas para preguntas de las encuestas .......... 55
Figura 3.31 Diseño Físico – Tabla de Respuestas para preguntas de las pruebas ............. 55
Figura 3.32 Diseño Físico – Tabla de Roles ...................................................................... 56
Figura 3.33 Diseño Físico – Tabla de relación entre roles y permisos .............................. 56
Figura 3.34 Diseño Físico – Tabla de Tablets ................................................................... 56
Figura 3.35 Diseño Físico – Tabla de Usuarios ................................................................. 56
Figura 3.36 Diseño Físico – Tabla de Versiones ............................................................... 57
Figura 3.37 Diseño Físico – Tabla de relación entre versiones y encuestas ...................... 57
Figura 3.38 Diseño Físico – Tabla de relación entre versiones y pruebas ......................... 57
Figura 3.39 Diseño Físico – Tabla de relación entre versions y tabletas ........................... 58
Figura 4.1 Estructura del Proyecto Web – Paquetes de Código JAVA ............................. 61
Figura 4.2 Estructura del Proyecto Web – Archivos para interfaces de usuario ............... 61
Figura 4.3 Estructura del Proyecto Móvil .......................................................................... 63
Figura 4.4 Presentación de avance de la aplicación web ................................................... 65
Figura 4.5 Presentación de avance de la aplicación móvil ...............Error! Bookmark not
defined.66

vii
 RESUMEN

Con el objetivo de cumplir con la finalización del plan de estudios de la carrera de

Ingeniería en Informática en la Universidad de Panamá se ha optado como trabajo de
graduación la opción de tesis. La misma ha sido realizada en La Secretaría Nacional de
Ciencia, Tecnología e Innovación (SENACYT).

La Secretaría Nacional de Ciencia, Tecnología e Innovación (SENACYT) es una

institución autónoma cuya misión es convertir a la ciencia y a la tecnología en
herramientas de desarrollo sostenible de Panamá. Sus proyectos y programas están
enfocados a potenciar el desarrollo científico y tecnológico del país y, de este modo,
cerrar la brecha de la desigualdad y fomentar un desarrollo equitativo que mejore la
calidad de vida de los panameños.

La importancia que tiene la realización este proyecto no es sólo adquirir experiencia en el

ámbito laboral y aplicar los conocimientos adquiridos durante la carrera, sino también
formarnos profesionalmente, fungiendo prácticamente como ingenieros en un ambiente
laboral real, complementando de forma integral nuestra educación. Igualmente se busca
contribuir en la empresa con nuestro trabajo, siendo ésta una experiencia recíproca donde
el beneficio es mutuo.

viii
 INTRODUCCIÓN

Desde la Dirección de Aprendizaje y Popularización de SENACYT surgió el interés y la

necesidad de buscar un mecanismo que permitiera medir el aprendizaje de los estudiantes
panameños en edad escolar primaria, esta iniciativa no es más que un aporte necesario en
la educación que de alguna manera busca decrementar las cifras alarmantes de deserción
escolar que se reflejan en Panamá en los últimos años.

Por medio de la evaluación, se incluyen diferentes estrategias, una de ellas es medir el

aprendizaje de los estudiantes. Todas estas acciones se han estado realizando de forma
manual lo que involucraba mucho tiempo y dificultaba obtener los resultados esperados.

Es por ello que se tomó la decisión de automatizar el proceso de evaluación, SENACYT,

para facilitar esta acción realizó la compra de 210 ordenadores portátiles tipo tableta con
el objetivo de evaluar a los estudiantes y tener los resultados en tiempo real.

Es por ello que se implementó una Plataforma de Evaluación Educativa para tomar
medidas en el proceso de las actividades de enseñanza-aprendizaje de los estudiantes.
Esta herramienta tecnológica permita dar soporte a las pruebas que miden el aprendizaje
de los estudiantes ya que facilita el trabajo de corrección, además de ahorrar papel y
tiempo de captación de los datos.

Para la elaboración del Proyecto se desarrollaron dos aplicaciones cuya comunicación es

bidireccional para lograr las funcionalidades esperadas, los cuales que son los
componentes principales de la Plataforma. Éstas son:
 Aplicación Móvil: esta es la aplicación final para los usuarios (estudiantes,
docentes y otros). Se instaló y ejecutó en tabletas Lenovo.
 Aplicación Servidor: esta es una aplicación web que manipula toda la información
registrada en la aplicación móvil y actualiza sus datos. Se instaló en un servidor de
SENACYT y se ejecuta en un navegador web. Sólo está disponible de manera
interna para el personal del SENACYT

A. El Software permite:
 La elaboración de pruebas, a partir de un banco de preguntas, para la
evaluación del desempeño de los estudiantes en ciencias y matemáticas.
 La elaboración de encuestas a docentes, directores y otros actores del
Sistema Educativo.
 La aplicación de pruebas online y off-line usando tabletas Lenovo Yoga 2
(sistema Android).
 La identificación de los estudiantes por escuela, grado, número de cédula,
nombre y apellido, género, edad, entre otros datos de relevancia.
 Permite almacenar un banco de preguntas categorizadas con una ficha
técnica según tema, nivel, grado de dificultad, respuestas posibles y otros.

ix
  Recupera los resultados en un servidor, todo el proceso debe estar listo
para usar y que sea fácil de implementar por los usuarios.
 Los resultados de las pruebas deben poderse analizar desde distintos
puntos de vista, por ejemplo, que permitan identificar patrones en las
respuestas de los estudiantes, presentar los resultados dentro de una matriz
de análisis y hacer gráficos de los resultados según las preguntas y según
las opciones de respuesta de cada pregunta.
 Posibilidad de elaborar consultas y reportes a la medida y que permita la
descarga de formatos requeridos a SPSS, Access, Excel, etc.
 Capacidad para soportar la realización de al menos 4 evaluaciones por año
de estudiantes de 2do a 6to (aproximadamente 80 centros educativos de
todo el país en el 2015).

B- Aplicación para registrar las observaciones de la práctica docente y ligar esta

observación a la información de escuelas, maestros y alumnos. El Software para la
observación de clases debe “correr” en Tableta Android, el diseño de la pauta de
observación es de SENACYT.

C- El servicio de la plataforma incluye la con……………………………………-24ción

y carga inicial de los centros educativos, grupos, docentes y alumnos que
participarán en los programas integrados en una base de datos que puede
exportarse a Excel. Capacidad de alimentar la plataforma con otras escuelas, etc.

 Capacitación y sensibilización para personal de SENACYT, docentes,

aplicadores.
 Integración de la información de escuela, docentes y las observaciones de
clase, alumnos y sus resultados en las pruebas. La escuela, el alumno o el
docente pueden ser las unidades de análisis.
 Sistema que permita hacer respaldos dentro y fuera de la nube.
 Horas para rediseño según las necesidades a pagarse según el uso

A continuación presentamos el Informe Final de nuestra Tesis que está organizada de la

siguiente forma: en el Capítulo I se exponen los antecedentes del Proyecto; en el Capítulo
II se introduce el Marco Teórico para recordar los fundamentos y aspectos teóricos del
Proyecto de Tesis; en el Capítulo III se explica el Diseño y el Análisis del Sistema desde
las especificaciones de los requisitos hasta el modelado de la Base de Datos; en el
Capítulo IV se describen el Desarrollo e Implementación del Sistema en el que se
presentan evidencias del producto desarrollado, tanto el Cliente como el Servidor.
Finalmente se exponen las Conclusiones y Recomendaciones.

x
 CAPÍTULO 1
ANTECEDENTES DEL PROYECTO
CAPITULO 1. ANTECEDENTES DEL PROYECTO

1.1 Definición del Problema

La Dirección de Aprendizaje y Popularización de La Secretaría Nacional de Ciencia,

Tecnología e Innovación (SENACYT) de la República de Panamá desea realizar un
programa enfocado en mejorar la calidad de la enseñanza en Ciencia Naturales y
Matemáticas para los estudiantes de primaria.

Para llevar a cabo este proceso, de mejora de la calidad de enseñanza, se necesita

implementar una plataforma tecnológica para evaluar el conjunto de actividades de
enseñanza-aprendizaje que reciben los estudiantes. Una herramienta o sistema
informático que permita dar soporte a las pruebas que miden el aprendizaje de los
estudiantes sería muy útil y facilitaría el trabajo de corrección, además de ahorrar papel y
tiempo de captación de datos.

La SENACYT para facilitar esta acción realizó la compra de 210 ordenadores portátiles
tipo tableta que permitirán evaluar a los estudiantes y tener los resultados en tiempo real.
La herramienta tecnológica debe permitir aplicar pruebas elaboradas a partir de un banco
de preguntas, realizar encuestas a docentes, directores y otros actores del Sistema
Educativo, y permitir dar seguimiento a las evaluaciones.

1.2 Objetivos de la Investigación

1.2.1 Objetivos Generales

- Implementar una Plataforma de Evaluación Educativa de Ciencias y Matemáticas
para estudiantes y docentes.

1.2.2 Objetivos Específicos

- Investigar las posibles tecnologías que brinden un ambiente propicio para el

desarrollo e implementación de la plataforma educativa.

- Recopilar información relevante de métodos de enseñanza que contribuyan con el

proceso de aplicación de pruebas a los estudiantes.

- Establecer las bases y requerimientos principales para la elaboración de la

solución tecnológica.

- Analizar y diseñar la estructura y arquitectura del proyecto con base a los

requerimientos y metas especificadas para el sistema.

13
 - Desarrollar un sistema cliente/servidor que permita aplicar pruebas y encuestas,
además de dar seguimiento a los resultados para evaluarlos.

- Implementar una plataforma de evaluación educativa para liberarla y ejecutarla en

los centros educativos.

1.3 Descripción del proyecto

El proyecto tiene como objetivo principal implementar un sistema para la evaluación de

los estudiantes y docentes de los centros educativos primarios del Programa de
Perfeccionamiento Docente de SENACYT.

Esta organización ha solicitado contar con una aplicación móvil que se ejecute en tabletas
Lenovo Yoga 2 con sistema operativo Android adquiridas por SENACYT y donde se
pueda aplicar pruebas a los estudiantes en las asignaturas de ciencias naturales y
matemáticas, además la misma aplicación debe permitir realizar encuestas a los docentes
y darle seguimiento a las evaluaciones y resultados.

Para la elaboración del Proyecto se necesitará desarrollar dos aplicaciones que se

comunicarán entre sí para lograr las funcionalidades esperadas y que son los componentes
principales de la Plataforma. Éstas son:

Aplicación Móvil: esta será la aplicación final para los usuarios (estudiantes, docentes y
otros). Se instalará y ejecutará en las tabletas Lenovo.
Entre algunas de sus funcionalidades podemos mencionar:
 Aplicación de pruebas de Ciencias Naturales y Matemáticas a los estudiantes
 Aplicación de encuestas a los docentes, directores y otros actores del sistema
educativo
 Aplicación de pruebas en modo online y offline
 Identificación de los estudiantes por escuela, grado, maestro, número de
cédula, nombre y apellido, género, edad, entre otros datos de relevancia
 Permitir almacenar un banco de preguntas categorizadas con una ficha técnica
según tema, nivel, grado de dificultad, respuestas posibles y otros
 Registrar las observaciones de la práctica docente y ligar esta observación a la
información de las escuelas, maestros y alumnos.
 Envío de datos registrados al servidor cuando haya conexión a internet.

Aplicación Servidor: esta será una aplicación web que manipulará toda la información
registrada en la aplicación móvil y actualizará sus datos. Se instalará en un servidor de
SENACYT y se ejecutará en un navegador web. Sólo estará disponible de manera interna
para el personal del SENACYT.

14
Entre algunas de sus funcionalidades podemos mencionar:
 Registrar un banco de preguntas, donde se pueda agregar, editar y borrar
preguntas de las pruebas y encuestas.
 Elaboración de las pruebas de Ciencias Naturales o Matemáticas consultando
y/o seleccionando las preguntas del banco de preguntas.
 Elaboración de encuestas para docentes y directores a partir de las preguntas
del banco de preguntas.
 Permitir la carga de las preguntas e imágenes por parte de SENACYT y la
elaboración de las primeras pruebas en el formato existente (PDF o Word) al
formato digital que requiere la plataforma.
 Recuperar los resultados de las pruebas y encuestas enviados por las tabletas
 Los resultados de las pruebas deben poder analizarse desde distintos puntos de
vistas, por ejemplo, que permitan identificar patrones en las respuestas de los
estudiantes, presentar los resultados dentro de una matriz de análisis y hacer
gráficos de los resultados según las preguntas y según las opciones de
respuesta de cada pregunta.
 Posibilidad de elaborar consulta y reportes a la medida y que permita la
descarga de formato requeridos a SPSS, Access, Excel, etc.
 El servicio de la plataforma debe incluir la configuración y carga inicial de los
centros educativos, grupos, docentes y alumnos que participarán en los
programas integrados en una base de datos que pueda exportarse a Excel.
 Capacidad de alimentar la plataforma con otras escuelas, etc.

1.4 Metodología

El proyecto por desarrollar es un sistema informático que debe albergar, desplegar y

procesar información de las pruebas y encuestas que se apliquen.

La metodología de desarrollo de software a utilizar para la construcción de la aplicación

estará basada en un Modelo en Espiral Típico de seis regiones. Se estará evaluando las
funcionalidades principales de la plataforma y se ejecutaran los siguientes pasos cada vez
que se haga una entrega o avance del proyecto.
• Comunicación con el cliente: Inicialmente, se prevé establecer la comunicación
con el personal de SENACYT que estará encargado del proyecto. Se establecerá los
lineamientos iniciales del proyecto, las restricciones, los objetivos, el modo en que se
trabajará, se formulará los puntos importantes a tratar durante todo el proceso de
desarrollo y se ampliará la información general del proyecto.

• Planificación: Una vez obtenido los datos principales se procederá a realizar la

planificación general que incluye definir los requerimientos, tareas, recursos, tiempos,
restricciones y otras informaciones relacionadas con el proyecto.

15
• Análisis de Riesgos: Se realizará una investigación y análisis del impacto,
compatibilidad y requisitos de sistema que se necesitará para la implementación de las
tecnologías a utilizar para el desarrollo. Así como la disponibilidad y experiencia del
personal de SENACYT para el mantenimiento y soporte de la aplicación. Se evaluará
alternativas que solucionen cualquier riesgo técnico y de gestión del proyecto.

• Ingeniería: Se debe contemplar la estructura del proyecto, el análisis y diseño del

sistema y la arquitectura de los componentes software/hardware involucrados en las
diferentes funcionalidades, el análisis funcional y tecnológico del software, la
comunicación entre sistemas, la administración y gestión de datos, etc.

• Construcción y Adaptación: Definir las tareas requeridas para la construcción

del sistema (programación, codificación, configuración y preparación de entornos), las
tareas y documentación para realizar las pruebas al sistema (pruebas unitarias, pruebas de
estrés, pruebas de integración, pruebas de aceptación, etc.), instalar y proporcionar
soporte a los usuarios (instalación de los entregables del sistema y elaboración de
documentación necesaria)

• Evaluación del Cliente: Definir tareas para que el personal encargado del
proyecto valide y valore el funcionamiento de los entregables. En esta fase se puede
sugerir cambios, adicionar requerimientos, eliminar funcionalidades, adicionar mejoras
etc.

Como metodología evolutiva se repetirán los pasos las veces necesarias hasta que se
obtenga el producto final aprobado y listo para ser entregados y puesto en marcha,
siempre que no se extienda más allá del cronograma acordado.

1.5 Delimitación o alcance de la investigación

Para este proyecto se quiere llegar a trabajar con una aplicación móvil para desplegar un
conjunto de cuestionarios y que se registre las respuestas en una tableta, podemos
mencionar que el alcance de la aplicación es lograr captar y evaluar los resultados para
tomar decisiones respecto a los métodos de enseñanza en Ciencias Naturales y
Matemáticas.

La aplicación sólo desplegará pruebas referentes a Ciencias Naturales y Matemáticas,

estarán elaboradas estas pruebas acordes al grado escolar de los estudiantes. Sólo estará
disponible para estudiantes de segundo a sexto grado de primaria de aproximadamente 80
centros educativos.

Primordialmente tiene como objetivo desplegar pruebas y encuestas, ciertas imágenes y

algunas formas de responder (escoger la mejor respuesta, verdadero o falso, etc.). Sólo los
estudiantes, docentes y otros de los centros educativos registrados en la base de datos del
servidor podrán tener acceso a la aplicación. Además, esta aplicación estará instalada en
las 210 tabletas adquiridas por SENACYT siendo exclusivas para estos dispositivos y no

16
se tendrá acceso desde cualquier otro dispositivo no autorizado para realizar las
operaciones a las que se está destinada.

La cantidad de dispositivos disponibles con la aplicación deberán ser distribuidos en

diferentes centros regionales de educación y estos a la vez serán distribuidos y enviados a
los diferentes centros de educación. Siendo utilizados por aula de clase según la
capacidad disponible para los estudiantes.

1.6 Restricciones

Las aplicaciones móviles al trabajar de forma offline pueden contener una base de datos
interna para registrar datos mientras se mantiene sin conexión.

Se debe tomar en cuenta que habrá una cantidad limitada de dispositivos que contarán con
la aplicación instalada, además estos dispositivos tendrán una base de datos interna que
será actualizada constantemente para no exceder con la capacidad de almacenamiento del
dispositivo.

Se debe manipular de manera individual cada dispositivo para que se actualice con el
paquete de preguntas para cada sesión de pruebas que se realicen durante el año según la
región, el centro educativo, los niveles y estudiantes que utilizaran la aplicación.

Otra restricción por evaluar es el tipo de dispositivo, inicialmente será desarrollado para
tableta Lenovo Yoga 2 con sistema operativo Android, las pruebas de las funcionalidades
se realizarán para esta tableta. Cualquier otra tableta o dispositivo móvil debe pasar por
una evaluación para ser considerada apta para ejecutar la aplicación.

El sistema del lado del servidor se desarrollará como aplicación web para que pueda ser
accedida en varios lugares que estén conectados a la red de SENACYT.

Las tecnologías que se utilizarán para este desarrollo deben acoplarse al tipo de
infraestructura tecnológica de SENACYT y se debe verificar lo que se permite utilizar,
por temas de compatibilidad, recursos y necesidades.

1.7 Justificación e importancia del estudio

La educación primaria en nuestro país tiene como objetivo favorecer que los estudiantes
de edad escolar logren el pleno desarrollo de sus capacidades, habilidades y destrezas,
adquiriendo el conocimiento necesario por medio de programas específicos de
enseñanzas.

Este proyecto está enfocado a realizar un estudio y análisis del nivel de aprendizaje de los
estudiantes de primaria en las asignaturas de ciencias naturales y matemáticas y observar
el método de enseñanza que imparten los docentes para así sugerir y plantear nuevas
estrategias de enseñanza que luego podrán ser retroalimentadas a otras escuelas y así
mejorar el nivel de aprendizaje de los estudiantes.
17
1.8 Generalidades de la Empresa
La Secretaría Nacional de Ciencia, Tecnología e Innovación de la República de
Panamá es una institución autónoma, que fue creada por la Ley 13 de 15 de abril de
1997, modificada posteriormente por la Ley 50 de 21 de diciembre de 2005 y por la
Ley 55 de 14 de diciembre de 2007, que le confirió autonomía a la institución en sus
tareas administrativas. La Secretaría trabaja guiada por los lineamientos establecidos
en el Plan Estratégico Nacional de Ciencia, Tecnología e Innovación (PENCYT)
2015-2019.

Todas las actividades, proyectos y programas de la SENACYT tienen como objetivo

fortalecer, apoyar, inducir y promover el desarrollo de la ciencia, la tecnología y la
innovación con el propósito de elevar el nivel de productividad, competitividad y
modernización en el sector privado, el gobierno, el sector académico-investigativo, y
la población en general

1.8.1 Misión

Convertir la ciencia y la tecnología en herramientas de desarrollo sostenible para

Panamá

1.8.2 Visión

Constituirse en el núcleo institucional y focal del desarrollo de la ciencia, la

tecnología y la innovación, como parte integral de la política nacional de desarrollo,
fortaleciendo la identidad cultural y promoviendo la difusión del conocimiento a la
sociedad panameña.

1.8.3 Valores

 Creatividad: Creemos en la creatividad e imaginación como el método preferido de

solución a los problemas.
 Excelencia: La excelencia motiva la mejor ciencia; la SENACYT desea ser
reconocida por la excelencia de su desempeño.
 Relevancia: La SENACYT contribuye a transformar para bien las oportunidades
disponibles de ciencia, tecnología e innovación. Por tanto, busca continuamente
cambiar en forma positiva la realidad circundante.
 Transparencia: La secretaría cree en este valor como principio de armonía con sus
beneficiarios, sus aliados y consigo misma. La transparencia a nuestros usuarios que
la cultura de méritos es la forma en la que SENACYT brinda apoyos.
 Solidaridad: la SENACYT cree en la responsabilidad social como parte del
liderazgo nacional.

18
1.8.4 Estructura Organizativa

Figura 1.1 Organigrama de SENACYT

1.8.5 Dirección de Aprendizaje y Popularización

La Dirección de Aprendizaje y Popularización busca cimentar las bases para el desarrollo

a largo plazo de la Ciencia y la Tecnología en el país, implementando programas de
modernización del aprendizaje y popularización de la ciencia y la tecnología,
promoviendo que los niños y jóvenes desarrollen su máximo potencial en estas áreas:
- Matemáticas
- Ciencias y
- Tecnología

1.8.6 Dirección de Gestión de Ciencia y Tecnología

La Dirección de Gestión de Ciencia y Tecnología es la encargada de articular y coordinar

esfuerzos para fortalecer el sistema de ciencia, tecnología e innovación a través de apoyos
para el desarrollo del capital humano panameño e incentivar actividades relacionadas con
ciencia y tecnología.

Para fortalecer las capacidades científicas nacionales se desarrollan diversos programas

dentro de la Dirección, enfocados en el desarrollo de la Ciencia en el país.

19
 Programa de Fortalecimiento a los Postgrados Nacionales. Este programa se
desarrolla desde el 2007 y busca desarrollar competencias en investigación
científica tanto de docentes como de estudiantes y elevar la calidad académica
de los programas de acuerdo con los estándares internacionales, en cuanto a
cantidad y calidad de los productos científicos. Se ofrece apoyo a las
universidades para que desarrollen programas académicos con un importante
componente de investigación, a nivel de licenciatura, maestría o doctorado,
brindándoles fondos para cubrir los costos de matrícula, colegiatura y de
laboratorios, así como los montos necesarios para que los centros académicos
otorguen y administren asistencia financiera para la manutención de los
estudiantes.

 Programa de movilidad académica y científica. La SENACYT lleva a cabo

varias iniciativas tendentes a fomentar la movilidad académica y de
investigación de sus estudiantes y de profesionales panameños, con el fin de
promover una formación eficiente en instituciones académicas y en centros de
investigación de excelencia.

 PISTA (Programa Interinstitucional de Seguimiento de Talento). El objetivo

principal del programa es detectar, desarrollar y dar seguimiento a niños y
jóvenes panameños con talento académico, a través de un programa de
enriquecimiento extracurricular de formación integral para profundizar el
aprendizaje de manera innovadora y cultivar la pasión por el conocimiento. Se
lanzan convocatorias dirigidas a Universidades en las que se otorgan fondos
para que gestionen y desarrollen el programa.

 Programa de Campamento Científico y Tecnológico: es un medio para

fortalecer la educación en ciencias en jóvenes talentosos de colegios
secundarios públicos y particulares del país y despertar el entusiasmo y la
curiosidad mediante el empleo de metodologías activas que promuevan la
creatividad.

20
 CAPÍTULO 2
MARCO TEÓRICO
2.1 Aplicaciones de la Web

En los tiempos en que el cliente de una aplicación debía ser instalado en cada ordenador
por separado y el servidor recibir las peticiones de todos los clientes, llegaba la tediosa
tarea de agregar o mejorar una funcionalidad en el servidor; esto conllevaba a actualizar
todos los clientes en los diferentes ordenadores donde se encontraban instalados. Se debía
reinstalar la aplicación para poder procesar las mejoras.

Con el surgimiento de las aplicaciones web los usuarios podían obtener las
actualizaciones de manera automática sin necesidad de instalar o reinstalar un cliente. Los
usuarios pueden acceder a los datos del servidor web a través de una red externa
(Internet) o una interna (Intranet) con la ayuda de un navegador web.

Las aplicaciones web se han hecho tan populares debido a lo práctico del navegador web
como cliente ligero, a la independencia del sistema operativo, a la disponibilidad desde
cualquier ordenador con navegador y acceso a red, así como a la facilidad para actualizar
y mantener dichas aplicaciones web sin distribuir e instalar software a miles de usuarios
potenciales.

Se conoce que normalmente las aplicaciones web se estructuran en 3 capas.

La primera capa la ofrece el navegador web en sí, siendo la interfaz que interactúa
directamente con los usuarios y que interpreta el código y páginas que envía el servidor.
La segunda capa la ofrece el servidor que contiene todo el código para recibir, procesar y
responder a las peticiones de los clientes.
La tercera capa la ofrece una base de datos estándar en donde se almacenan los datos y
toda la información de la aplicación.

Desde el punto de vista de la educación las aplicaciones web tienen mucho que aportar en
el proceso de enseñanza-aprendizaje. Una aplicación web educativa conlleva toda una
plataforma donde los estudiantes, docentes y administradores convergen para llevar a
cabo las actividades que se realizan usualmente en un aula de clases, pero esta vez de una
manera virtual con ciertas ventajas que hacen que el proceso de enseñanza-aprendizaje
sea más interactivo y mejorado.

Podemos mencionar algunas ventajas de una aplicación educativa web.

o Los docentes y estudiantes pueden adoptar nuevos roles. Por ejemplo: un estudiante
puede tomar rol de manejador o coordinador al proponer temas de discusión en los
grupos al que pertenezca.
o Favorece el autoaprendizaje, ya que permite trabajar desde casa, no solo desde el
aula.
o Favorece el aprendizaje colaborativo al poner en contacto a través de la red con
comunidades virtuales y compañeros que comparten inquietud por una misma
materia o tema.
o Permiten la realización de trabajos en línea, en grupo y en tiempo real.
o Abren nuevos espacios de comunicación entre profesores, alumnos y familias.

22
 o No se aprende solo escuchando, sino participando y siendo activos en las
asignaciones.
o Los docentes pueden realizar una evaluación más especializada de los resultados,
comentarios o datos que los estudiantes suministren sobre algún tema en específico.
o Se pueden implementar nuevas modalidades de enseñanza aprovechando las nuevas
tecnologías.
o Facilitan la evaluación del aprendizaje en entornos virtuales.

Podemos mencionar algunas ventajas que obtuvimos al decidir desarrollar una aplicación
web para la parte del servidor. Nos enfocamos en que el personal de SENACYT sería el
encargado de administrar y distribuir la información que recibirían los usuarios finales
(estudiantes y docentes).

De esta manera nuestra elección nos brindaría las siguientes ventajas:

o Ahorro de tiempo: La forma más sencilla de hacerles llegar la información a los
usuarios sería por medio de la red en donde se puede enviar y recibir datos de una
manera más rápida.
o Compatibilidad: no habría problemas con compatibilidad de sistemas, ya que solo
basta tener cualquier navegador actualizado para poder utilizar la aplicación
servidor.
o Espacio: la aplicación web se encuentra alojada en el servidor de SENACYT, por
ende, no ocupa espacio en los discos duros de los usuarios.
o Actualizaciones Inmediatas: siempre que ocurra una modificación en las
funcionalidades y páginas del servidor, y luego que los cambios se implementen,
los usuarios siempre estarán conectados a la última versión que se haya lanzado.
o Consumo de recursos bajos: dado que la aplicación no se encuentra en el ordenador
del usuario, las tareas que realiza el software no consumen recursos, salvo lo que
consuma el navegador.
o Multiplataforma: la aplicación web se puede utilizar desde cualquier sistema
operativo.
o Portable: es independiente de la computadora o dispositivo que se utilice
(ordenadores de escritorio, portátiles, tabletas, celulares, etc.)
o Disponibilidad: siempre que se cuente con acceso a una red se puede utilizar la
aplicación en cualquier momento y lugar.

2.2 Aplicaciones Móviles

En nuestra actualidad el uso de dispositivos móviles, para destinarlos a realizar muchas de

las funciones que realizan los ordenadores, se está haciendo cada vez más común.

Cabe mencionar que una aplicación móvil o App (en inglés) es una aplicación informática
diseñada para ser ejecutada en teléfonos inteligentes, tabletas y otros dispositivos, con el

23
fin de efectuar una tarea concreta de cualquier tipo (profesional, educativo, de acceso a
servicios, etc.), facilitando las gestiones o actividades a desarrollar.

Por lo general las aplicaciones móviles se encuentran disponibles a través de plataformas

de distribución, operadas por las compañías propietarias de los sistemas operativos
móviles como Android, iOS, BlackBerry OS, Windows Phone, entre otros.

Las aplicaciones educativas provienen del término en inglés “Application”. La expresión

en sí hace referencia a todo programa o recurso material multimedia, dirigido al uso a
través de dispositivos electrónicos, que se pueda usar como herramienta de soporte en el
ámbito de la educación.

Cuando mencionamos las aplicaciones móviles educativas, no sólo se debe hacer

referencia a herramientas de apoyo a la docencia presencial; además de ello, las
aplicaciones móviles educativas sirven de apoyo a la Educación a distancia, la Educación
en línea o el Aprendizaje electrónico.

Las aplicaciones móviles educativas nos pueden brindar ciertas ventajas e inconvenientes
a la hora de su uso. Podemos mencionar algunas ventajas e inconvenientes de una
aplicación móvil educativa.

Algunas Ventajas
o Movilidad: el aprendizaje no está sujeto al espacio físico de la clase ni a las horas
estrictas de la impartición de la materia.
o Versatilidad: los docentes pueden desarrollar tareas específicas para una materia
con una App en particular o se puede permitir que los estudiantes creen y aporten
ideas a ese desarrollo o proceso de la materia usando Apps diferentes que ellos
conozcan.
o Adaptabilidad: a través del uso de Apps en la clase para el aprendizaje de una
materia determinada, se puede hacer que los estudiantes que menos participan sean
más activos.
o Interconectividad: los estudiantes pueden entrar en contacto con otros estudiantes
de otros lugares e intercambiar información.
o Compromiso: el estudiante adquiere compromisos en el desarrollo de su aprendizaje
porque pasa a ser parte activa en dicho proceso y trabaja de manera activa para
conseguir las tareas y trabajos encomendados.
o Comunicación a tiempo real entre estudiantes y docentes, docentes y padres, y
directivos y padres.
o Permite una cómoda distribución de tareas, recursos a través de internet y
complementos audiovisuales para la docencia.
o Provee de medios complementarios de contacto con estudiantes y padres desde el
centro educativo.
o Ayuda a la superación de las barreras geográficas, tanto en docencia como en
investigación.

24
 o Al trabajar con formatos y medios con los que el estudiante tiene mayor relación, se
refuerza el aprendizaje, además de invertirse menos tiempo en el aula, gracias a los
recursos complementarios a través de Internet.

Algunos inconvenientes:
o Acuerdos comunes: es uso de Apps puede hacer necesario que se creen en la
educación, a nivel general, marcos comunes de actuación en lo que se refiere al
proceso o desarrollo de aprendizaje, al desarrollo de tareas o a criterios de
evaluación.
o Falta de medios: En muchos casos, puede que los medios técnicos no sean los
mejores y aún no estén al alcance no ya de todos los individuos, sino también de
algunos centros escolares. Medios como pueden ser: un buen ancho de banda,
medios técnicos adecuados para desarrollar esas aplicaciones etc.
o Costes adicionales: Existe también el problema de los costes adicionales como
pueden ser los precios o tarifas de algunas Apps, ya que no siempre todos los
contenidos, especialmente los de calidad, son gratuitos. En muchos casos hay un
periodo de prueba de determinadas Apps y luego hay una subscripción.
o El tiempo es oro: En muchas ocasiones, el tiempo que hay que emplear en enseñar
el uso y manejo de ciertas herramientas y aplicaciones para que el estudiante
aprenda a manejarse sin dificultad.

Podemos mencionar algunas ventajas que obtuvimos al decidir desarrollar una aplicación
móvil para la parte del cliente. Nos enfocamos en que los estudiantes y docentes como
usuarios finales tendrían la única función de responder las preguntas de los diferentes
cuestionarios provenientes del servidor.

De esta manera podemos mencionar algunas ventajas de elaborar una aplicación móvil
educativa:
o Ejecución de los cuestionarios: un mismo dispositivo con la aplicación puede ser
utilizado por diferentes estudiantes y docentes.
o Trabajo Offline: para centros educativos donde no haya acceso a una red externa, la
aplicación puede albergar las respuestas de los estudiantes y enviarlas cuando
establezcan comunicación con el servidor.
o Actualización de datos: la aplicación podrá recibir datos nuevos del servidor de
forma automática, siempre y cuando esté conectado a una red.
o Resultados: a medida que los cuestionarios se vayan completando, la aplicación
enviará los resultados al servidor para su posterior análisis.

2.3 Arquitectura de las aplicaciones Web

La administración y procesamientos de los datos recaen en el sistema web cliente-
servidor que se ha desarrollado. Al ser una aplicación web, se ha basado la arquitectura en
un modelo de 3 capas para distribuir el trabajo en las diferentes capas y así procesar o
desplegar la información.
25
Una aplicación web es proporcionada por un servidor web y utilizada por los usuarios que
se conectan desde cualquier punto vía cliente web (navegadores). El servidor distribuye
páginas de información formateada a los clientes que lo solicitan. Los requerimientos son
hechos a través de una conexión de red, y para ello se usa el protocolo HTTP. Una vez
que se solicita esta petición mediante el protocolo HTTP y la recibe el servidor Web,
éste localiza la página Web en su sistema de archivos y la envía de vuelta al navegador
que la solicitó.

Las capas que conforman nuestra aplicación cliente servidor se mencionan a

continuación:
 Capa de presentación (parte en el cliente y parte en el servidor)
Esta es la capa que ve el usuario (personal de Senacyt) desde su navegador web.
o Realiza la petición de la información
o Recoge la información del usuario y la envía a la capa de proceso para su
procesado
o Recibe los resultados de la capa de proceso
o Genera la presentación
o Se visualiza la presentación al usuario
 Capa de negocio (servidor web)
Esta es la capa que realiza operaciones con la información
o Recibe la entrada de datos de la capa de presentación
o Interactúa con la capa de datos para realizar operaciones
o Manda los resultados procesados a la capa de presentación
 Capa de datos (servidor de datos)
Esta es la capa donde se almacena la información procesada
o Almacena los datos
o Recupera los datos
o Mantiene los datos
o Asegura la integridad de los datos

26
 Figura 2.1 Arquitectura de tres capas

2.4. Estado de la enseñanza-aprendizaje en escuelas primarias

El sistema educativo panameño se basa en la Ley Orgánica de Educación promulgada en

1946. El Sistema Educativo Nacional cuenta con el Primer Nivel de Enseñanza o
Educación Básica General (Etapas de Preescolar, Primaria y Premedia); el Segundo Nivel
de Enseñanza o Educación Media y el Tercer Nivel o Educación Superior.

El Ministerio de Educación (MEDUCA) es el Ente Estatal que administra el Sistema

Educativo del Primer Nivel al Segundo Nivel de Enseñanza. Las bases legales e
institucionales del MEDUCA quedaron definidas con la expedición de las Leyes 84 y 89
de 1 de julio de 1941. La estructura funcional del Ministerio de Educación cuenta con
ocho (8) niveles compuestos de la siguiente manera: el nivel político, el directivo, el nivel
de coordinación, el nivel de asesoría, el nivel de fiscalización, el nivel auxiliar de apoyo,
el nivel técnico, el nivel operativo y el nivel ejecutor.

La Ley No. 47 de 1946 Orgánica de Educación, organizada como Texto Único en el 2004
contempla la Educación como un derecho humano en atención a la norma constitucional
del país. Entre las funciones del MEDUCA están las de establecer, organizar, ejecutar y
supervisar las actividades relacionadas con los diferentes niveles educativos, a través del
planeamiento, conjuntamente con las instituciones vinculadas al sector e impulsar un
proceso de modernización de la educación con sentido participativo, concertado, integral,

27
progresivo y con visión de futuro. A través del MEDUCA, el Estado panameño cumple la
misión de administrar el sistema educativo nacional implementando el proceso de
enseñanza-aprendizaje en todos los centros educativos oficiales y particulares que
imparten educación a los niños, niñas, adolescentes, jóvenes y adultos, con planes y
programas de estudio evaluados y reformados según la demanda nacional, con el fin que
adquieran los conocimientos, capacidades y destrezas que les sirvan de instrumento para
desempeñarse en el mundo de la academia y en el campo laboral o productivo. Este
esfuerzo a nivel nacional tuvo como resultado una taza de alfabetización del 95.8% en el
año 2011, el más alto de América Central.

La tarea de educar, en general, es un desafío que se da en todos los niveles educativos del
país; sin embargo, la cobertura de la enseñanza alcanza hoy día en Panamá avances
significativos a tanto en el nivel de preescolar como en el universitario. Sin embargo,
existen abismos en materia educativa en las regiones comarcales y en las provincias de
Darién y Bocas del Toro, entre otras.

La asistencia educativa en los primeros niveles es satisfactoria casi en su totalidad, pero,

al avanzar a pre-media y media disminuye aproximadamente de un nivel de
aproximadamente 96% a un 68% y de ahí, posteriormente, sólo llegan a la universidad un
52% de los estudiantes. Solamente cada quince (15) de cien (100) estudiantes que se
matriculan en la universidad obtienen un título universitario, según datos proporcionados
por el MEDUCA.

El analfabetismo afecta en su mayor parte áreas rurales y comarcales marcadas por el

flagelo de la pobreza. En estas regiones es notable observar la deserción escolar, en los
primeros años de escolaridad; situación que dificulta el desarrollo de nuestro país. El
sistema educativo nacional está expuesto a grandes tempestades respecto a diversas
situaciones, tales como:

- Una gran brecha digital, pues no existen las mismas oportunidades para áreas rurales
y comarcales, en comparación a otras áreas del país.

- La falta de oportunidades y desigualdades en parámetros de Educación, Salud y

Alimentación lo que afecta la calidad de vida de las personas.

La Comisión Económica para América Latina y el Caribe (CEPAL) y la Organización de

Estados Iberoamericanos para la Educación, la Ciencia y la Cultura (OEI) recomiendan a
los países de Iberoamérica aumentar de forma sistemática el presupuesto educativo
incluido Panamá: Es necesario retomar y reestructurar la estructura educativa de un país
para eliminar disparidades educativas existentes en el sistema y este programa debe
comenzar desde las raíces lo que implica la atención en el nivel de preescolar, lo que es el
cimiento de las bases del desarrollo humano para una vida exitosa en sociedad.

La educación infantil en Panamá es ofertada por más de 2,500 instituciones educativas,

además existen otros centros de atención infantil como Centros Familiares y
Comunitarios de Educación

28
Inicial (CEFACEI), Educación Inicial en el Hogar (EIH), Centros de Educación Inicial
Comunitaria (CEIC) y los especializados del Ministerio de Desarrollo Social.

La educación primaria es la que sigue en el aprendizaje y es muy importante en el

desarrollo del ser humano. Sin embargo, no existe equidad entre la educación de áreas
indígenas, áreas rurales de difícil acceso y áreas accesibles que cuentan con los recursos y
la tecnología necesaria para lograr adquirir aprendizajes significativos. La mayor
deserción escolar se da por tanto, en áreas comarcales y rurales de difícil acceso, muchos
de estos niños se dedican al trabajo infantil, lo que impide el logro de una formación
académica sólida.

Estudios de la CEPAL y la OIE atribuyen la repitencia (volver a realizar un grado

educativo o año escolar) y el fracaso escolar en la educación de los países
latinoamericanos a las disparidades sociales, a la gestión educativa y a los recursos
destinados a la educación, la organización y funcionamiento de las escuelas, a la
capacitación de los docentes, a las condiciones en las que desempeñan su trabajo y a las
propias actitudes de los alumnos, condicionadas, a su vez, por su entorno social, familiar,
cultural y educativo.

Atendiendo a algunos estudios, los estudiantes con mayor rendimiento académico se

enmarcan en el 20% cuyos padres poseen una educación a nivel superior.
Lastimosamente, según estudios realizados por el Segundo Estudio Regional
Comparativo y Explicativo (SERCE), se determinó que los docentes panameños tienen
deficiencias marcadas en su formación académica lo que repercute en el proceso de
aprendizaje que se lleva a cabo a diario en las aulas.

Un aspecto preocupante, de las competitividades nacionales, es el desempeño en

matemáticas de los estudiantes de 6to grado. Nuestro País se clasifica entre los países
latinoamericanos con los promedios más bajos, pues los estudiantes no alcanzaron
siquiera el primer nivel. Igual situación ocurre en las pruebas de lectura para el 3er grado,
en el que el país se ubica con calificaciones similares a Ecuador, Guatemala, Nicaragua,
Paraguay, Perú y República Dominicana. Panamá tiene un 11% de sus estudiantes que
están por debajo del Nivel I de desempeño en lectura, lo que implica que no logran
localizar en un texto corto, información con un solo significado.
La UNESCO enfatiza que la falta de competencias en nuestros estudiantes transmitidos
por el entorno escolar es limitante en el desarrollo y creatividad del estudiante lo que
genera un incremento en la pobreza, desempleo y trastornos sociales. Según UNESCO,
“las necesidades de aprendizaje de los jóvenes son muy amplias; comprenden no
solamente las competencias necesarias para ganarse la vida, sino también un desarrollo
personal que siente las bases de una vida gratificante.” Destaca el mismo informe, que los
jóvenes que han crecido en condición de pobreza y exclusión tienen más probabilidades
de haber cursado pocos estudios o de haber abandonado la escuela y, por lo tanto, tienen
menos posibilidades de desarrollar competencias para empleos dignos, en el sector
formal.
Tanto la CEPAL como la UNESCO resaltan la importancia del desarrollo de habilidades
y competencias básicas en nuestros estudiantes, sólo así, se podrán rebasar barreras de
desigualdad y se mejorará la calidad de vida.
29
En Panamá, se han triplicado la cantidad de jóvenes en edades de 15 a 19 años con
grandes déficits educativos lo que implica el poco acceso al campo laboral. Sin embargo,
MEDUCA indica que del 10% registrado en el 2010 en repitencia, para el año 2012 está
realidad tuvo una disminución de un 2.7%. Los niveles de repitencia se incrementan en
Panamá en los niveles de pre-media y media. Algunas de las provincias más afectadas
atendiendo a estudios realizados del 2007 al 2010 fueron Herrera y Bocas del Toro,
realidad que no ha tenido grandes variaciones. Esto es sinónimo de pérdida para el estado
y la familia panameña tanto en parámetros económicos como psicosociales.

Otro diagnóstico importante ha sido provisto por los resultados que arrojaron las pruebas
PISA aplicadas a estudiantes de pre-media, en el año 2009, fueron preocupantes ya que,
de los países participantes, Panamá estuvo entre los últimos cuatro, lo que indica que hay
un déficit en áreas como matemática, español y ciencias naturales. En esta prueba,
Panamá ocupó la posición número 62 entre los 65 participantes. La prueba PISA
(Programa para la Evaluación Internacional de Alumnos) es una iniciativa de la
Organización para la Cooperación y el Desarrollo Económicos (OCDE), que mide la
capacidad de los jóvenes de quince años para resolver problemas a partir de la aplicación
de conocimientos de lectura, estudio de las matemáticas y ciencias naturales. La
evaluación, que se aplicó por primera vez en 2000, se ofrece cada tres años.

En 2015, unos 510 mil estudiantes de 73 países del mundo se sometieron a la prueba, de
una duración promedio de dos horas, con una mezcla de preguntas abiertas y de selección
múltiple, basadas en una situación de la vida real. La versión de 2018 medirá la capacidad
de los estudiantes para comprender los problemas de otros países del continente y del
mundo. En 2009, además de Panamá, tomaron la prueba PISA estudiantes de Argentina,
Brasil, Colombia, Costa Rica, Chile, México, Perú, Trinidad y Tobago y Uruguay.

En aquella ocasión, los panameños mostramos serias deficiencias ciencias y matemáticas,

así como escasa comprensión lectora. Ante los resultados obtenidos, la entonces ministra
Molinar optó por retirar a Panamá de la evaluación de 2012. La administración actual ha
decidido incorporar a Panamá nuevamente la evaluación PISA y se realizan los
preparativos para su aplicación en el 2018. El gobierno ha decidido que los estudiantes
locales se midan en dos de las pruebas ofrecidas por PISA: una es la prueba “regular”,
que se aplica a estudiantes de 15 años y más de séptimo grado en adelante, en la que
participarán 6,300 estudiantes de 150 escuelas públicas y privadas del país.

La segunda se orienta a el “desarrollo componente C”, que medirá las competencias

lectora y matemática de jóvenes de séptimo grado y menos, pero que tienen quince años,
y de una muestra de aquellos jóvenes que están fuera del sistema educativo, o en áreas
rurales. En la evaluación participarán 2,700 estudiantes panameños. Los resultados de
PISA serán dados a conocer en 2019.

El presente proyecto de Tesis consiste en la creación de un sistema de evaluación que

apoye a las actividades preparatorias que realiza el MEDUCA para las pruebas PISA
2018 y el ejercicio de evaluación constante posterior a dicha prueba.

30
 CAPÍTULO 3
ANÁLISIS Y DISEÑO DEL SISTEMA
3.1 Especificación de los requerimientos de la Plataforma

La SENACYT, por medio de la Dirección de Aprendizaje y Popularización,

solicitó primordialmente que se utilizara las tabletas que habían adquirido para la
aplicación de las pruebas y encuestas.
Previamente en el punto 1.3 Descripción del Proyecto, se mencionó algunas
funcionalidades que debía tener la plataforma de evaluación educativa.

Se tomaron en cuentas las funcionalidades con más prioridad para considerarlas

como una primera fase. A partir del recibimiento y aceptación de esta primera fase
se contemplaría otras fases para el mejoramiento y expansión de las
funcionalidades en general, todo esto siguiendo la metodología de desarrollo de
software elegida (modelo espiral).

A partir de las solicitudes iniciales se desglosó y añadió ciertos procesos

necesarios para facilitar el funcionamiento completo de las aplicaciones. Los
requerimientos quedaron a evaluación del personal que recibió el sistema; dichos
requerimientos podrían ser aprobados, modificados o eliminados, así como se
podía sugerir nuevos requisitos no contemplados.

La gran mayoría de los requerimientos fueron propuestos por nosotros al ir

analizando cada funcionalidad y así determinando que componentes
necesitábamos para llegar a los objetivos propuestos por SENACYT. Se
analizaron los requerimientos como un todo en general, y tomando en cuenta que
la plataforma iba a estar compuesta por dos aplicaciones se determinó las
funciones necesarias para integran ambas aplicaciones en temas de comunicación
y manejo de datos.

Para realizar la especificación de los Requerimientos de la Plataforma de

Evaluación Educativa nos basamos en el estándar IEEE 830-1998 Recommended
Practice for Software Requirements Specification.

Los requerimientos para la aplicación web se basaron en las funcionalidades de

creación, administración, distribución y observación de los datos de las 2
aplicaciones de la plataforma. Mientras, que los requerimientos de la aplicación
móvil se basaron en el despliegue, registro y envío de los datos que otorgarían los
estudiantes y docentes al responder los cuestionarios que se le aplicasen.

Para más detalle de los requerimientos del sistema revisar los Anexos del
documento.

3.1.1 Recolección de datos

Siguiendo los pasos del modelo en espiral, el primer punto es establecer la
comunicación con el cliente. Esto se logró realizando reuniones preliminares para
conocer el producto que se deseaba.

32
 El personal de SENACYT involucrado explicó las pautas del sistema,
mencionando como objetivos principales tener un sistema donde se pudiera aplicar
pruebas y encuestas, a docentes y estudiantes, utilizando dispositivos móviles
(unas tabletas). Se nos suministró documentos preliminares con información
general de las funciones del sistema.

Como puntos importantes de las primeras reuniones se mencionaba el uso de las

tabletas, la aplicación de las pruebas para estudiantes y de encuestas para
docentes, la realización de pruebas a partir de un conjunto de preguntas, la
clasificación de las pruebas para dos materias (Ciencias Naturales y Matemáticas),
clasificación por grado escolar, la opción de diferentes formas de responder a las
preguntas, el registro de estudiantes y docentes por centros educativos, entre otros.

Por nuestra parte en las reuniones y correos posteriores dimos nuestras primeras
impresiones y sugerencias de lo que involucraría el desarrollo del sistema
propuesto. Realizamos investigaciones de las posibles tecnologías que podríamos
utilizar y se llegó a un consenso para seguir con el inicio del proyecto.

Se recopilaron todos los datos obtenidos de las reuniones y documentos para

clasificarlos y tener un panorama del alcance y complejidad del proyecto.

Figura 3.1 Reunión preliminar para especificación de requerimientos

3.1.2 Análisis de la Información

Estableciendo los primeros lineamentos y teniendo “libertad” de escoger las
tecnologías para lograr el desarrollo del sistema iniciamos la fase de análisis de la
información para determinar los requisitos de los sistemas.

33
 Tomando en cuenta que sólo se había contemplado que el sistema funcionara en el
dispositivo móvil, y con ayuda de nuestras investigaciones previas, era factible
desarrollar la plataforma en la tableta, pero no iba a cumplir con un requerimiento
que se había mencionado sobre el análisis de los resultados obtenidos de los
cuestionarios. No se iba a poder analizar los resultados si cada tableta contara con
su propia base de datos. Es por eso que decidimos centralizar el lugar donde se
guardarían los resultados. De esta manera ya nos encaminábamos a tener una
segunda aplicación que se encargaría de centralizar los datos de las tabletas.

Continuando con el análisis determinamos que muchas otras funcionalidades que

se tenían contempladas dentro de la aplicación móvil serían mejor relegadas a la
nueva aplicación el cual ya llamábamos aplicación servidor. Las investigaciones
previas de sistemas móviles con base de datos centralizadas nos encaminaron a
armar una plataforma cliente servidor. De esta manera aprovecharíamos las
ventajas de comunicación de los dispositivos móviles para no sobrecargar el
sistema cliente con muchas funcionalidades.

Formuladas las funciones iniciales de cada aplicación nos enfocamos a desglosar o

especificar más los requisitos que necesitaban cada una. De esta forma la mayoría
de las funciones generales quedaron en la aplicación servidor donde los procesos
más extensos se podrían realizar con los recursos de un servidor web. La
aplicación móvil quedó enfocada a sólo desplegar los cuestionarios a los usuarios
finales.

Otro punto que tomamos en cuenta fue la curva de aprendizaje en el desarrollo

móvil. Las tabletas vienen con sistema operativo Android y no estábamos muy
familiarizados con el desarrollo para Android, es por eso que realizar un sistema
extenso en Android nos tomaría mucho más tiempo de lo que se estaba
programado. Mientras que realizar una aplicación web sería más conveniente para
desarrollar funcionalidades especiales solicitadas para la plataforma.

3.1.3 Presentación de resultados

A medida que se iba describiendo los requisitos del sistema, se pensaba en la
forma en que se presentaría los datos y los resultados a los usuarios.

Para la aplicación web se decidió desplegar los catálogos de datos en tablas y se

utilizaría formularios web para registrar y editar la información. Los resultados
obtenidos desde las tabletas se desplegarían en reportes sobre documentos Excel
para su posterior análisis con otras herramientas de análisis de datos.

Para la aplicación móvil se decidió mostrar la información en formato de

cuestionarios, con la pregunta y el espacio para responder. Las pruebas o
encuestas disponibles se mostrarían en listas.

34
 Para el envió y recibo de datos entre aplicaciones se utilizarían servicios web. Este
sería el enlace para que las tabletas actualicen sus datos internos y el servidor
reciba los resultados guardados de las tabletas.

El documento de especificación de requerimientos presenta los resultados de la

recolección y análisis de la información obtenida durante esta etapa. Se intentó
reunir la mayoría de los requisitos predefinidos y los que surgieron durante el
análisis. Esta fase fue de importancia para sentar las bases del desarrollo que se
iba a iniciar, así del cómo lograr un plan de trabajo para determinar los tiempos y
recursos necesarios para lograr el objetivo del proyecto.

3.2 Análisis del Sistema

3.2.1 Sistema Actual

3.2.1.1 Situación del sistema actual
La evaluación del proceso de enseñanza-aprendizaje actualmente no se
encuentra automatizada. El personal encargado de aplicar las pruebas y encuestas
elabora cuestionarios en documentos que luego imprimen para distribuirlos en los
diferentes centros educativos del país.
Se aplican las pruebas en papel a los estudiantes, estos deben resolver cada
pregunta del cuestionario. Las preguntas pueden contener una imagen
representativa o solo el texto descriptivo. Las respuestas pueden ser de tipo
escoger la mejor respuesta, verdadero o falso y llenar espacios. De la misma
manera se elaboran las encuestas para que los docentes respondan seleccionando
una opción o explicándola.

Una vez aplicadas las pruebas y encuestas se reciben los resultados desde el papel
y se procede a la carga en un sistema para su posterior análisis. Este proceso
ayuda, al personal de la Dirección de Aprendizaje, a poder conocer el impacto de
los métodos de enseñanza que se utilizan en los centros educativos primarios y así
modificar o ajustar las estrategias utilizadas.

Al ser un proceso manual no se pueden tener los resultados ni analizarlos en un

tiempo corto, ya que la logística de aplicar pruebas en todos los centros educativos
para luego cargarlos uno por uno al sistema puede ocasionar un margen de error.

Muchos datos importantes que sirven para realizar una mejor clasificación de los
resultados como lo son el sexo, la edad, la ubicación, etc., no llegan directamente
con las pruebas o encuestas. Haciendo que la obtención de estos datos necesite
otro proceso adicional para investigar las generales completas de la persona que se
está evaluando.

35
 3.2.1.2 Diagrama general del sistema actual
A continuación, se muestra un diagrama general del sistema de evaluación actual
implementado por SENACYT.

Figura 3.2 Diagrama General del Sistema Actual

3.2.2 Alternativas de Solución

En las reuniones iniciales se puso en contexto las ideas principales del proyecto.
El uso de las tabletas que SENACYT había adquirido ya era un hecho. Quedaba
resolver cómo se guardarían los datos para su posterior análisis. Se conversó y se
sugirió posibles soluciones para el asunto en cuestión. De parte de SENACYT se
propuso algunas opciones y de nuestra parte igual agregamos posibles esquemas
de cómo desarrollar el proyecto.

A continuación, mencionamos las opciones más cercanas y propuestas para el

desarrollo de la plataforma de evaluación educativa:

- Plataforma de Evaluación Educativa Móvil: se pensó que todas las

funcionalidades del sistema fueran desarrolladas en una aplicación que se
ejecutara en las tabletas de SENACYT.

Entre algunas de las funciones que la aplicación iba a contener se encuentran:

36
 - Elaborar las pruebas y encuestas: en la base de datos interna del
dispositivo deberían estar registradas todas las preguntas y así poder
seleccionar las que conformarían el cuestionario.
- Registro de datos de estudiantes y docentes esto conllevaba a crear
funcionalidades para agregar, editar y eliminar datos de estudiantes,
docentes y otros. Además, era necesario el mantenimiento de los datos
asociados a estos usuarios como lo son el centro educativo, el grado
escolar, el grupo, entre otros.
- Registro de preguntas: había que incluir las funcionalidades para agregar,
editar y eliminar datos de las preguntas. Así como permitir el
almacenamiento de imágenes.
- Análisis de datos: los resultados debían ser desplegados en gráficos y
clasificados por ciertos parámetros como: región, centro educativo,
profesor, sexo, edad, grado, materia, etc.

Se puede mencionar ciertos inconvenientes respecto a desarrollar el proyecto de

esta forma como lo son:
- La aplicación no iba a ser muy ligera para el dispositivo, al tener procesos
extensos como los reportes de los resultados y todas las interfaces y
formularios necesarios para manejar los datos.
- Tarde o temprano la memoria interna del dispositivo se iba a saturar de
imágenes y datos.
- El proceso de registro de datos (preguntas, pruebas, encuestas, estudiantes,
docentes, etc.) se iba a tener que repetir en cada una de las 200 tabletas.
- No había forma de juntar los resultados de varias tabletas para un mejor
análisis. Se iba a tener que verificar la forma exportar los datos a una base
de datos central.
- Todo esto y otros puntos que hacían de esta propuesta la menos adecuada
para lograr el objetivo.

- Plataforma de Evaluación Educativa con micro nube: con el fin de mejorar la

propuesta anterior, el personal de SENACYT mencionó que se podría
implementar el uso de unas micro nubes para las escuelas donde las tabletas
pudieran cargar y descargar datos.

Se utilizaría un dispositivo llamado C3 CRITICAL LINKS, que serviría de

repositorio de contenidos donde se iba a disponer de todas las preguntas, pruebas,
encuestas y otros datos importantes para alimentar a las tabletas de información.
Además, los resultados o respuestas de los estudiantes y docentes al finalizar sus
respectivos cuestionarios se iban a enviar a estos dispositivos.

Las funcionalidades del sistema se mantendrían en su mayoría iguales a la

propuesta anterior salvo la forma de administrar y entregar los datos a las tabletas.

Algunas de las mejoras o beneficios en comparación con la propuesta anterior

están:

37
 - Se evita el inconveniente de tener que registrar manualmente los mismos
datos en las 200 tabletas, ya que estas al conectarse al micro servidor iban
a descargar y actualizar sus datos.
- Los resultados de varias tabletas iban a ser depositadas en un solo micro
servidor.
- La aplicación quedaría más ligera ya que las funcionalidades de
mantenimiento de datos ya no se realizarían desde las tabletas sino por otro
medio.

Se puede mencionar ciertos inconvenientes respecto a desarrollar el proyecto de

esta forma como lo son:
- Agregar el uso de micro nubes con el desarrollo de aplicaciones móviles
alargarían la curva de aprendizaje, ya que se debía investigar más sobre
comunicación y programación en estos tipos de dispositivos.
- Encontrar otras formas de generar la información para alimentar de datos a
la Tablet iba a ser un proceso adicional al desarrollo de la aplicación.
- Aunque los resultados de varias tabletas se guarden en un micro servidor,
estos datos aun no completarían toda la información necesaria para realizar
reportes, estadísticas y análisis. Se tendrían que reunir o comunicar todos
los micro servidores con un servidor principal para juntar los datos.
- Encontrar un mecanismo para actualizar los datos de cada micro servidor
era también un proceso adicional que se debía tomar en cuenta.
- Todo esto y otros puntos que hacían de esta propuesta la más cercana para
lograr el objetivo.

- Plataforma de evaluación Educativa web-móvil: a medida que se iba analizando

las propuestas y conociendo las ventajas y bondades de las tecnologías disponibles
para el desarrollo del sistema, surge esta propuesta en base a experiencias propias
y conocimientos en el ámbito del desarrollo de sistemas.

Las tabletas poseen un sistema operativo que es muy utilizado en la actualidad y

que posee muchas características para lograr los procesos deseados. Adicional a
esto y con tal de facilitar la operación del sistema nos apoyamos en las facilidades
que podemos obtener de las aplicaciones web.

La gran mayoría de aplicaciones móviles de hoy en día se comunican por medio

de servicios web a servidores y a aplicaciones donde se albergan los datos en
bases de datos centralizadas y se encuentra gran parte de la lógica del negocio.

Revisando este esquema de aplicaciones móviles y web, propusimos desarrollar

un sistema cliente servidor compuesto por una aplicación web para la parte
administrativa y una aplicación móvil para los usuarios finales.

Algunas de las mejoras o beneficios en comparación con la propuesta anterior

están:
- No se necesitaría un intermediario (micro servidor) para enviar y recibir las
actualizaciones de datos.
38
 - Los procesos más complejos como la consulta de resultados se pueden
hacer desde una aplicación web. Así como la administración y generación
de las pruebas y encuestas.
- La aplicación móvil puede enfocarse sólo a los usuarios finales y la parte
administrativa ser gestionada por la aplicación web.
- Una base de datos centralizada en un servidor dispondría de datos
actualizados a las aplicaciones.
- El espacio que los datos de la aplicación móvil, en la memoria interna del
dispositivo, ocupen seria reducido. Ya que siempre que haya
actualizaciones, los datos antiguos serán reemplazados.
- Es más sencillo manipular grandes cantidades de datos desde una
aplicación web que desde un dispositivo móvil.

Se puede mencionar ciertos inconvenientes respecto a desarrollar el proyecto de

esta forma como lo son:
- Al no colocar el sistema móvil en una plataforma de distribución, las
actualizaciones en las funciones de la aplicación tendrán que ser
implementadas de forma manual en cada tableta.
- Se debe estar en constante revisiones de las tabletas si están conectadas a
red y correctamente configuradas para comunicarse con el servidor para
obtener actualizaciones.

3.2.3 Selección de la alternativa

Finalmente decidimos seleccionar la última propuesta (sistema cliente - servidor)

ya que era la más completa en cuanto a arquitectura para el desarrollo de una
plataforma tecnológica. Analizamos sus pro y contras para el desarrollo de los
sistemas y el alcance de los objetivos.

Algunos de los criterios que tomamos en cuenta para decidirnos en esta solución
los mencionamos a continuación:
- Dejar la aplicación móvil exclusivamente para uso de estudiantes y
docentes. Por tal motivo decidimos no recargar la aplicación con tantas
funcionalidades que se repitieran y estuvieran en todas las tabletas.
- Relegar las funciones comunes a la aplicación web, porque desde un
servidor web se puede procesar los datos de forma más eficiente.
- Un servidor web albergaría todas las páginas, recursos y otros en un solo
directorio. Así no habría razón de hacer repetidas instalaciones en todos los
ordenadores y sólo se necesitaría un navegador web desde cualquier
ordenador.
- El espacio que ocuparía las imágenes y datos con el trascurrir del tiempo
iba a ser un problema con la capacidad del dispositivo móvil. El servidor
web con más recursos es el indicado para albergar toda esa información.

39
 - La carga masiva de datos se haría más sencilla desde un ordenador ya que
se puede contar con otras herramientas para elaborar el documento con los
datos que se desean cargar. Si esa funcionalidad se ejecutara en un
dispositivo móvil podría consumir muchos recursos del mismo y afectar su
desempeño.
- La transmisión de datos entre servidor y clientes es automática y no es
necesario realizar pasos extras en el proceso de juntar los resultados
finales.
- La aplicación web puede verificar siempre los datos históricos de las
diferentes aplicaciones de pruebas y encuestas.
- A la aplicación móvil se le puede programar el tiempo de sincronización
de datos con un servidor, ahorrándonos el proceso de transferir los datos al
servidor central de forma manual.

3.3 Diseño del sistema

3.3.1 Sistema propuesto

El sistema que propusimos es una plataforma compuesta por dos aplicaciones que se
comunican por medio de una red. En general habrá un módulo administrativo que
llamamos servidor y un módulo informativo que llamamos cliente.

Del lado del servidor tendremos los siguientes componentes:

- Un gestor de base de datos: representa la base de datos central donde todos los
registros estarán alojados. Estos registros alimentan a las dos aplicaciones.
- Un servidor web: representa el repositorio donde están ubicados el código y
páginas de la aplicación web. Además, se colocaron otros recursos como las
imágenes de las preguntas, archivos y el instalable de la aplicación móvil.
Del lado cliente tendremos los siguientes componentes:
- La aplicación móvil que se instalará en las tabletas.
- La aplicación web del cual se accede desde un navegador web.

3.3.1.1 Aplicación móvil

Esta aplicación tienes tres módulos para los usuarios finales.
- Estudiantes: la función de este módulo es presentar los datos generales de los
estudiantes junto con las pruebas disponibles según asignatura y nivel escolar al
que pertenece. Desde este punto los estudiantes acceden para responder las
pruebas y la aplicación registra sus respuestas para luego transferirlas al sistema
servidor.
- Docentes: la función de este módulo es presentar los datos generales de los
docentes junto con las encuestas disponibles. Desde este punto los docentes
acceden para responder las encuestas y la aplicación registra sus respuestas para
luego transferirlas al sistema servidor.

40
 - Administración: la función de este módulo es permitir al personal de SENACYT
configurar el dispositivo para establecer comunicación con el servidor. Además,
se puede solicitar datos al servidor y depurar los registros antiguos de respuestas
guardadas en el dispositivo.

3.3.1.2 Aplicación web

Esta aplicación tiene 3 grandes módulos para los usuarios administrativos.
- Mantenimiento de datos: la función de este módulo es permitir registrar, editar,
eliminar y consultar los datos básicos que alimentan las listas desplegables dentro
de los formularios. Entre los mantenimientos que se incluyen están: centros
educativos, grupos, asignaturas, usuarios del sistema, estudiantes y docentes.
- Elaboración de pruebas y encuestas: la función de este módulo es permitir al
personal de SENACYT construir las pruebas y encuestas que serán desplegadas
en las tabletas. Al igual que el módulo de mantenimiento de datos se podrá
registrar, editar, eliminar y consultar los datos principales de los cuestionarios.
Entre los mantenimientos que se incluyen están: preguntas, pruebas, encuestas y
paquetes de datos (versiones).
- Configuración y Consulta: dentro de este módulo se encuentran las funciones de
carga masiva, reporte de resultados y configuración de parámetros de los sistemas.
Estas funciones son las que componen el inicio y fin del ciclo de aplicación de
pruebas y encuestas. Antes de iniciar un ciclo se establecerían parámetros para
determinar ciertos comportamientos de las aplicaciones. Luego si es necesario se
realiza una carga de datos para alimentar a las aplicaciones. Por último, se
consultan los resultados de los estudiantes y docentes para su posterior análisis
con el fin de encontrar patrones en las respuestas y obtener estadísticas.

41
3.3.2 Diagrama General

Figura 3.3. Diagrama General del sistema propuesto

Desde las tabletas y/o ordenadores los usuarios deben conectarse a la red disponible. Por
medio de la red se envían solicitudes de páginas y datos a la aplicación servidor. El
servidor web por medio de la aplicación envía y recibe datos de la base de datos.

3.3.3 Especificaciones de Hardware y Software

Para determinar el ambiente de desarrollo y ejecución de los sistemas se tomó en cuenta
las tecnologías disponibles que estaban tanto a nuestro alcance como al alcance de
SENACYT. Al ser dos aplicaciones diferentes las que se iban a desarrollar, debíamos
especificar los requisitos mínimos que debían contener el hardware para su correcto
funcionamiento, así como los softwares que nos apoyarían para la ejecución de dichas
aplicaciones.

3.3.3.1 Hardware
Por parte del servidor necesitaríamos un servidor que albergue la base de datos y la
aplicación web. Este servidor puede cumplir con las siguientes especificaciones:
- El servidor puede trabajar con un procesador de 2,5 gigahercios (GHz) como
mínimo.
- La memoria del servidor puede trabajar con un mínimo de 2 GB de RAM
- Disco duro con un mínimo de 3GB de espacio para almacenamientos de archivos
y datos de la aplicación web
- Conexión de red de 56 kilobits por segundo (Kbps) entre los equipos cliente y el
servidor
- Cualquier sistema operativo (Windows, Linux, etc.)

42
Por parte del desarrollador se necesita un ordenador de escritorio o portátil con las
siguientes especificaciones:
- El ordenador puede trabajar con un procesador de 2.5 gigahercios (GHz) como
mínimo.
- La memoria del ordenador puede trabajar con un mínimo de 2 GB de RAM
- Disco duro con un mínimo de 2GB de espacio para almacenamientos de archivos
de las aplicaciones a desarrollar
- Conexión de red de 56 kilobits por segundo (Kbps) mínimo entre los equipos
cliente y el servidor.

Por parte del cliente para la aplicación web se necesitaría un ordenador de escritorio o
portátil con las siguientes especificaciones:
- Memoria RAM de 1GB como mínimo
- Conexión de red de 56 kilobits por segundo (Kbps) mínimo entre los equipos
cliente y el servidor
- El ordenador puede trabajar con un procesador de 2.5 gigahercios (GHz) como
mínimo.
- Sistema operativo Android desde la versión 4.0 en adelante

Por parte del cliente para la aplicación móvil se necesitaría un dispositivo móvil con las
siguientes especificaciones:
- Memoria RAM de 1GB mínimo
- Espacio de almacenamiento de 4GB mínimo
- Procesador mayor de 1.2 gigahercios (GHz)

3.3.3.2 Software

Por parte del servidor necesitaríamos lo siguiente:

- Un gestor de base de datos para MYSQL

- Un servidor para aplicaciones Web (TOMCAT)
- Kit de Desarrollo de JAVA (JDK)
- Servidor web Apache.

Por parte del desarrollador necesitaríamos lo siguiente:

- Un gestor de base de datos para MYSQL

- Un servidor para aplicaciones Web (TOMCAT, Glassfish)
- Kit de Desarrollo de JAVA (JDK)
- Entorno de desarrollo Integrado (Integrated Development Environment - IDE)
para Java
- Entorno de desarrollo Integrado (Integrated Development Environment - IDE)
para Android
- Cliente FTP para transferencia de archivos al servidor (Filezilla, WinSCP)
- Cliente SSH (PUTTY)
- Cliente para administración de MySQL (phpMyAdmin, Toad, etc.)

43
Por parte del cliente para la aplicación web necesitaríamos lo siguiente:

- Un navegador web (Chrome, Firefox, Internet Explorer, etc.)

- Microsoft Excel.

Por parte del cliente para la aplicación móvil necesitaríamos lo siguiente:

- Zip Signer, software para firma de archivos comprimidos

- Un navegador web (Chrome, Firefox, Internet Explorer, etc.)

3.3.4 Seguridad

La seguridad del sistema se estableció a un nivel básico para el control del acceso y
operación según el tipo de usuario que utilice las aplicaciones.

En la aplicación servidor el acceso está controlado por medio de la validación de

credenciales de usuarios. Dentro de la aplicación se encuentra el mantenimiento de
usuarios y roles. Sólo los usuarios debidamente registrados por el administrador pueden
acceder al sistema.

Los usuarios tienen asignado un rol y cada rol tiene diferentes permisos según lo disponga
el administrador del sistema. Lo permisos sirven para habilitar o deshabilitar los botones
y ciertas funciones a los usuarios. Las contraseñas de los usuarios se registran cifradas y
el sistema lo descifra para validar el dato cuando se inicie sesión.
En la aplicación móvil el acceso al sistema y a los módulos están controladas por
contraseñas que se configuran desde la aplicación servidor. Estas contraseñas deben ser
suministradas por los administradores al personal que configura las tabletas para los
usuarios finales.

3.4 Modelado de Base de datos

3.4.1 Diseño Conceptual

A continuación, mostramos el diseño conceptual de la base de datos plataforma:

44
 Figura 3.4 Diseño conceptual de una versión de datos

3.4.2 Diseño Lógico

A continuación, mostramos el diseño lógico de la base de datos plataforma.

Figura 3.5 Diseño Lógico de Usuarios y sus componentes

45
Figura 3.6 Diseño Lógico de Estudiantes y Docentes

Figura 3.7 Diseño Lógico de Versión de Datos

46
Figura 3.8 Diseño Lógico de Encuestas y sus componentes

Figura 3.9 Diseño Lógico de Pruebas y sus componentes

47
3.4.3 Diseño Físico: El modelo de datos físicos representa objetos de datos relacionales
(por ejemplo, tablas, columnas, claves principales y claves externas) y sus relaciones. Se
puede utilizar para generar sentencias DDL que, después, se pueden desplegar en un
servidor de base de datos.

A continuación, mostramos el diseño físico de la base de datos plataforma.

-- Base de datos plataforma

CREATE DATABASE IF NOT EXISTS plataforma CHARSET=utf8;
USE plataforma;
Figura 3.10 Diseño Físico – Base de datos Plataforma

-- Estructura de tabla para la tabla de asignaturas

CREATE TABLE `asignatura` (
`asignatura_id` bigint(20) NOT NULL AUTO_INCREMENT,
`codigo` varchar(10) COLLATE utf8_spanish_ci DEFAULT NULL,
`estado` int(11) DEFAULT NULL,
`nombre` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`asignatura_id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.11 Diseño Físico – Tabla de Asignaturas

-- Estructura de tabla para la tabla de centro educativos

CREATE TABLE `centro_educativo` (
`centro_id` bigint(20) NOT NULL AUTO_INCREMENT,
`codigo` varchar(10) COLLATE utf8_spanish_ci DEFAULT NULL,
`direccion` varchar(150) COLLATE utf8_spanish_ci DEFAULT NULL,
`nombre` varchar(80) COLLATE utf8_spanish_ci DEFAULT NULL,
`poblado` varchar(50) COLLATE utf8_spanish_ci DEFAULT NULL,
`provincia_id` bigint(20) DEFAULT NULL,
`distrito_id` bigint(20) DEFAULT NULL,
`corregimiento_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`centro_id`),
KEY `FK_centro_prodiscor`
(`provincia_id`,`distrito_id`,`corregimiento_id`),
CONSTRAINT `FK_centro_prodiscor` FOREIGN KEY (`provincia_id`,
`distrito_id`, `corregimiento_id`) REFERENCES `corregimiento`
(`provincia_id`, `distrito_id`, `corregimiento_id`)
) ENGINE=InnoDB AUTO_INCREMENT=88 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.12 Diseño Físico – Tabla de Centros Educativos

48
-- Estructura de tabla para la tabla de configuración
CREATE TABLE `configuracion` (
`configuracion_id` bigint(20) NOT NULL AUTO_INCREMENT,
`disponibilidad_version` int(11) NOT NULL,
`cantidad_opciones` int(11) NOT NULL,
`clave_docente` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`ruta_imagenes` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`puntaje_maximo` int(11) NOT NULL,
`ruta_servidor` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`clave_ingreso` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`clave_estudiante` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`clave_administrador` varchar(100) COLLATE utf8_spanish_ci DEFAULT
NULL,
`tiempo_sincronizacion` int(11) NOT NULL,
PRIMARY KEY (`configuracion_id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.13 Diseño Físico – Tabla de Configuración

-- Estructura de tabla para la tabla de corregimiento

CREATE TABLE `corregimiento` (
`provincia_id` bigint(20) NOT NULL,
`distrito_id` bigint(20) NOT NULL,
`corregimiento_id` bigint(20) NOT NULL,
`codigo` bigint(20) NOT NULL,
`corregimiento` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`estado` int(11) NOT NULL,
PRIMARY KEY (`provincia_id`,`distrito_id`,`corregimiento_id`),
KEY `FK_corre_dist` (`provincia_id`,`distrito_id`),
KEY `FK_corre_prov` (`provincia_id`),
CONSTRAINT `FK_corre_dist` FOREIGN KEY (`provincia_id`, `distrito_id`)
REFERENCES `distrito` (`provincia_id`, `distrito_id`),
CONSTRAINT `FK_corre_prov` FOREIGN KEY (`provincia_id`) REFERENCES
`provincia` (`provincia_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
Figura 3.14 Diseño Físico – Tabla de Corregimientos

-- Estructura de tabla para la tabla de distrito

CREATE TABLE `distrito` (
`provincia_id` bigint(20) NOT NULL,
`distrito_id` bigint(20) NOT NULL,
`codigo` bigint(20) NOT NULL,
`distrito` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`estado` int(11) NOT NULL,
PRIMARY KEY (`provincia_id`,`distrito_id`),
KEY `FK_distrito_provincia` (`provincia_id`),
CONSTRAINT `FK_distrito_provincia` FOREIGN KEY (`provincia_id`)
REFERENCES `provincia` (`provincia_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
Figura 3.15 Diseño Físico – Tabla de Distritos

49
-- Estructura de tabla para la tabla de docente
CREATE TABLE `docente` (
`docente_id` bigint(20) NOT NULL AUTO_INCREMENT,
`apellido` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL,
`cedula` varchar(15) COLLATE utf8_spanish_ci DEFAULT NULL,
`nombre` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL,
`centro_id` bigint(20) DEFAULT NULL,
`edad` int(11) DEFAULT NULL,
`sexo` varchar(1) COLLATE utf8_spanish_ci DEFAULT NULL,
`anios_servicio` int(11) DEFAULT NULL,
PRIMARY KEY (`docente_id`),
UNIQUE KEY `UK_cedula` (`cedula`),
KEY `FK_centro_d` (`centro_id`),
CONSTRAINT `FK_centro_d` FOREIGN KEY (`centro_id`) REFERENCES
`centro_educativo` (`centro_id`)
) ENGINE=InnoDB AUTO_INCREMENT=40 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.16 Diseño Físico – Tabla de Docentes

-- Estructura de tabla para la tabla de docente - grupo

CREATE TABLE `docente_grupo` (
`doc_id_dg` bigint(20) NOT NULL,
`grupo_id_dg` bigint(20) NOT NULL,
PRIMARY KEY (`doc_id_dg`,`grupo_id_dg`),
KEY `FK_GRU_DG` (`grupo_id_dg`),
CONSTRAINT `FK_DOC_DG` FOREIGN KEY (`doc_id_dg`) REFERENCES `docente`
(`docente_id`),
CONSTRAINT `FK_GRU_DG` FOREIGN KEY (`grupo_id_dg`) REFERENCES `grupo`
(`grupo_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
Figura 3.17 Diseño Físico – Tabla de relación entre docentes y grupos

-- Estructura de tabla para la tabla de encuesta

CREATE TABLE `encuesta` (
`encuesta_id` bigint(20) NOT NULL AUTO_INCREMENT,
`codigo` varchar(10) COLLATE utf8_spanish_ci NOT NULL,
`estado` int(11) DEFAULT NULL,
`fecha_creacion` datetime NOT NULL,
`nombre` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL,
`instruccion` varchar(300) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`encuesta_id`),
UNIQUE KEY `UK_codigo` (`codigo`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.18 Diseño Físico – Tabla de Encuestas

50
-- Estructura de tabla para la tabla de encuesta - preguntas
CREATE TABLE `encuesta_preguntas` (
`enc_id_ep` bigint(20) NOT NULL,
`preg_id_ep` bigint(20) NOT NULL,
PRIMARY KEY (`enc_id_ep`,`preg_id_ep`),
KEY `FK_PREG_EP` (`preg_id_ep`),
CONSTRAINT `FK_ENC_EP` FOREIGN KEY (`enc_id_ep`) REFERENCES `encuesta`
(`encuesta_id`),
CONSTRAINT `FK_PREG_EP` FOREIGN KEY (`preg_id_ep`) REFERENCES
`preg_docentes` (`preg_doc_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci
Figura 3.19 Diseño Físico – Tabla de relación entre encuestas y preguntas

-- Estructura de tabla para la tabla de estudiante

CREATE TABLE `estudiante` (
`estudiante_id` bigint(20) NOT NULL AUTO_INCREMENT,
`apellido` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL,
`cedula` varchar(15) COLLATE utf8_spanish_ci DEFAULT NULL,
`nombre` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL,
`grupo_id` bigint(20) DEFAULT NULL,
`centro_id` bigint(20) DEFAULT NULL,
`edad` int(11) DEFAULT NULL,
`sexo` varchar(1) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`estudiante_id`),
UNIQUE KEY `UK_cedula` (`cedula`),
KEY `FK_grupo_e` (`grupo_id`),
CONSTRAINT `FK_grupo_e` FOREIGN KEY (`grupo_id`) REFERENCES `grupo`
(`grupo_id`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.20 Diseño Físico – Tabla de Estudiantes

-- Estructura de tabla para la tabla de grupo

CREATE TABLE `grupo` (
`grupo_id` bigint(20) NOT NULL AUTO_INCREMENT,
`nombre` varchar(20) COLLATE utf8_spanish_ci DEFAULT NULL,
`estado` int(11) NOT NULL,
`grado` int(11) NOT NULL,
`centro_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`grupo_id`),
KEY `FK_centro_g` (`centro_id`),
CONSTRAINT `FK_centro_g` FOREIGN KEY (`centro_id`) REFERENCES
`centro_educativo` (`centro_id`)
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci
Figura 3.21 Diseño Físico – Tabla de Grupos

51
-- Estructura de tabla para la tabla de permiso
CREATE TABLE `permiso` (
`permiso_id` bigint(20) NOT NULL AUTO_INCREMENT,
`nombre` varchar(15) COLLATE utf8_spanish_ci NOT NULL,
`descripcion` varchar(50) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`permiso_id`)
) ENGINE=InnoDB AUTO_INCREMENT=145 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.22 Diseño Físico – Tabla de Permisos

-- Estructura de tabla para la tabla de preguntas docentes

CREATE TABLE `preg_docentes` (
`preg_doc_id` bigint(20) NOT NULL AUTO_INCREMENT,
`codigo` varchar(10) COLLATE utf8_spanish_ci NOT NULL,
`definicion` varchar(500) COLLATE utf8_spanish_ci DEFAULT NULL,
`descripcion` varchar(500) COLLATE utf8_spanish_ci DEFAULT NULL,
`tipo_pregunta` int(11) NOT NULL,
`estado` int(11) DEFAULT NULL,
`fecha_creacion` datetime NOT NULL,
`proposito` int(11) NOT NULL,
PRIMARY KEY (`preg_doc_id`),
UNIQUE KEY `UK_codigo` (`codigo`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.23 Diseño Físico – Tabla de Preguntas para encuestas

-- Estructura de tabla para la tabla de preguntas estudiantes

CREATE TABLE `preg_estudiantes` (
`preg_est_id` bigint(20) NOT NULL AUTO_INCREMENT,
`codigo` varchar(10) COLLATE utf8_spanish_ci NOT NULL,
`definicion` varchar(1000) COLLATE utf8_spanish_ci DEFAULT NULL,
`descripcion` varchar(1000) COLLATE utf8_spanish_ci DEFAULT NULL,
`dificultad` int(11) DEFAULT NULL,
`fuente` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`grado` int(11) NOT NULL,
`puntos` int(11) NOT NULL,
`tema` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`tipo_pregunta` int(11) NOT NULL,
`asignatura_id` bigint(20) NOT NULL,
`con_imagen` bit(1) DEFAULT NULL,
`imagen` varchar(100) COLLATE utf8_spanish_ci DEFAULT NULL,
`estado` int(11) DEFAULT NULL,
`fecha_creacion` datetime NOT NULL,
`proposito` int(11) NOT NULL,
`con_justificacion` bit(1) DEFAULT NULL,
PRIMARY KEY (`preg_est_id`),
UNIQUE KEY `UK_codigo` (`codigo`),
KEY `FK_asignatura_pe` (`asignatura_id`),
CONSTRAINT `FK_asignatura_pe` FOREIGN KEY (`asignatura_id`) REFERENCES
`asignatura` (`asignatura_id`)
) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.24 Diseño Físico – Tabla de Preguntas para pruebas

52
-- Estructura de tabla para la tabla de provincia
CREATE TABLE `provincia` (
`provincia_id` bigint(20) NOT NULL,
`codigo` bigint(20) NOT NULL,
`provincia` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`estado` int(11) NOT NULL,
PRIMARY KEY (`provincia_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
Figura 3.25 Diseño Físico – Tabla de Provincias

-- Estructura de tabla para la tabla de prueba

CREATE TABLE `prueba` (
`prueba_id` bigint(20) NOT NULL AUTO_INCREMENT,
`codigo` varchar(10) COLLATE utf8_spanish_ci NOT NULL,
`estado` int(11) DEFAULT NULL,
`fecha_creacion` datetime NOT NULL,
`grado` int(11) NOT NULL,
`nombre` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL,
`puntaje` int(11) NOT NULL,
`asignatura_id` bigint(20) NOT NULL,
`instruccion` varchar(300) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`prueba_id`),
UNIQUE KEY `UK_codigo` (`codigo`),
KEY `FK_asignatura_p` (`asignatura_id`),
CONSTRAINT `FK_asignatura_p` FOREIGN KEY (`asignatura_id`) REFERENCES
`asignatura` (`asignatura_id`)
) ENGINE=InnoDB AUTO_INCREMENT=9 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.26 Diseño Físico – Tabla de Pruebas

-- Estructura de tabla para la tabla de prueba – preguntas

CREATE TABLE `prueba_preguntas` (
`pru_id_pp` bigint(20) NOT NULL,
`preg_id_pp` bigint(20) NOT NULL,
PRIMARY KEY (`pru_id_pp`,`preg_id_pp`),
KEY `FK_PREG_PP` (`preg_id_pp`),
CONSTRAINT `FK_PREG_PP` FOREIGN KEY (`preg_id_pp`) REFERENCES
`preg_estudiantes` (`preg_est_id`),
CONSTRAINT `FK_PRU_PP` FOREIGN KEY (`pru_id_pp`) REFERENCES `prueba`
(`prueba_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
Figura 3.27 Diseño Físico – Tabla de relación de pruebas y preguntas

53
-- Estructura de tabla para la tabla de respuestas docentes
CREATE TABLE `resp_docentes` (
`resp_doc_id` bigint(20) NOT NULL AUTO_INCREMENT,
`respuesta` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`docente_id` bigint(20) NOT NULL,
`version_id` bigint(20) NOT NULL,
`encuesta_id` bigint(20) NOT NULL,
`pregunta_id` bigint(20) NOT NULL,
`centro_id` bigint(20) NOT NULL,
`fecha_respuesta` datetime NOT NULL,
`fecha_recibo` datetime NOT NULL,
`edad` int(11) NOT NULL,
PRIMARY KEY (`resp_doc_id`),
KEY `FK_docente_rd` (`docente_id`),
KEY `FK_version_rd` (`version_id`),
KEY `FK_encuesta_rd` (`encuesta_id`),
KEY `FK_pregunta_rd` (`pregunta_id`),
KEY `FK_escuela_rd` (`centro_id`),
CONSTRAINT `FK_docente_rd` FOREIGN KEY (`docente_id`) REFERENCES
`docente` (`docente_id`),
CONSTRAINT `FK_encuesta_rd` FOREIGN KEY (`encuesta_id`) REFERENCES
`encuesta` (`encuesta_id`),
CONSTRAINT `FK_escuela_rd` FOREIGN KEY (`centro_id`) REFERENCES
`centro_educativo` (`centro_id`),
CONSTRAINT `FK_pregunta_rd` FOREIGN KEY (`pregunta_id`) REFERENCES
`preg_docentes` (`preg_doc_id`),
CONSTRAINT `FK_version_rd` FOREIGN KEY (`version_id`) REFERENCES
`version` (`version_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci
Figura 3.28 Diseño Físico – Tabla de Respuestas de docentes

-- Estructura de tabla para la tabla de respuestas estudiantes

CREATE TABLE `resp_estudiantes` (
`resp_est_id` bigint(20) NOT NULL AUTO_INCREMENT,
`respuesta` varchar(100) COLLATE utf8_spanish_ci NOT NULL,
`estudiante_id` bigint(20) NOT NULL,
`version_id` bigint(20) NOT NULL,
`prueba_id` bigint(20) NOT NULL,
`pregunta_id` bigint(20) NOT NULL,
`centro_id` bigint(20) NOT NULL,
`grado` int(11) NOT NULL,
`fecha_respuesta` datetime NOT NULL,
`fecha_recibo` datetime NOT NULL,
`edad` int(11) NOT NULL,
`justificacion` varchar(500) COLLATE utf8_spanish_ci DEFAULT NULL,
PRIMARY KEY (`resp_est_id`),
KEY `FK_estudiante_re` (`estudiante_id`),
KEY `FK_version_re` (`version_id`),
KEY `FK_pregunta_re` (`pregunta_id`),
KEY `FK_prueba_re` (`prueba_id`),
KEY `FK_escuela_re` (`centro_id`),

54
 CONSTRAINT `FK_escuela_re` FOREIGN KEY (`centro_id`) REFERENCES
`centro_educativo` (`centro_id`),
CONSTRAINT `FK_estudiante_re` FOREIGN KEY (`estudiante_id`) REFERENCES
`estudiante` (`estudiante_id`),
CONSTRAINT `FK_pregunta_re` FOREIGN KEY (`pregunta_id`) REFERENCES
`preg_estudiantes` (`preg_est_id`),
CONSTRAINT `FK_prueba_re` FOREIGN KEY (`prueba_id`) REFERENCES
`prueba` (`prueba_id`),
CONSTRAINT `FK_version_re` FOREIGN KEY (`version_id`) REFERENCES
`version` (`version_id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.29 Diseño Físico – Tabla de Respuestas de Estudiantes

-- Estructura de tabla para la tabla de respuestas a preguntas docentes

CREATE TABLE `resp_preg_docentes` (
`resp_preg_doc_id` bigint(20) NOT NULL AUTO_INCREMENT,
`correcta` bit(1) DEFAULT NULL,
`respuesta` varchar(300) COLLATE utf8_spanish_ci DEFAULT NULL,
`valor` varchar(15) COLLATE utf8_spanish_ci DEFAULT NULL,
`pregunta_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`resp_preg_doc_id`),
KEY `FK_pregunta_rpd` (`pregunta_id`),
CONSTRAINT `FK_pregunta_rpd` FOREIGN KEY (`pregunta_id`) REFERENCES
`preg_docentes` (`preg_doc_id`)
) ENGINE=InnoDB AUTO_INCREMENT=25 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;

Figura 3.30 Diseño Físico – Tabla de Respuestas para preguntas de las encuestas

-- Estructura de tabla para la tabla de respuestas a preguntas

estudiantes
CREATE TABLE `resp_preg_estudiantes` (
`resp_preg_est_id` bigint(20) NOT NULL AUTO_INCREMENT,
`correcta` bit(1) DEFAULT NULL,
`respuesta` varchar(300) COLLATE utf8_spanish_ci DEFAULT NULL,
`valor` varchar(15) COLLATE utf8_spanish_ci DEFAULT NULL,
`pregunta_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`resp_preg_est_id`),
KEY `FK_pregunta_rpe` (`pregunta_id`),
CONSTRAINT `FK_pregunta_rpe` FOREIGN KEY (`pregunta_id`) REFERENCES
`preg_estudiantes` (`preg_est_id`)
) ENGINE=InnoDB AUTO_INCREMENT=160 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.31 Diseño Físico – Tabla de Respuestas para preguntas de las pruebas

55
-- Estructura de tabla para la tabla rol
CREATE TABLE `rol` (
`rol_id` bigint(20) NOT NULL AUTO_INCREMENT,
`estado` int(11) NOT NULL,
`nombre` varchar(35) COLLATE utf8_spanish_ci NOT NULL,
PRIMARY KEY (`rol_id`)
) ENGINE=InnoDB AUTO_INCREMENT=6 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.32 Diseño Físico – Tabla de Roles

-- Estructura de tabla para la tabla rol - permiso

CREATE TABLE `rol_permiso` (
`rol_id_rp` bigint(20) NOT NULL,
`permiso_id_rp` bigint(20) NOT NULL,
PRIMARY KEY (`rol_id_rp`,`permiso_id_rp`),
KEY `FK_PERMISO` (`permiso_id_rp`),
CONSTRAINT `FK_PERMISO` FOREIGN KEY (`permiso_id_rp`) REFERENCES
`permiso` (`permiso_id`),
CONSTRAINT `FK_ROL_USER` FOREIGN KEY (`rol_id_rp`) REFERENCES `rol`
(`rol_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
Figura 3.33 Diseño Físico – Tabla de relación entre roles y permisos

-- Estructura de tabla para la tabla tablet

CREATE TABLE `tablet` (
`tablet_id` bigint(20) NOT NULL AUTO_INCREMENT,
`codigo` varchar(50) COLLATE utf8_spanish_ci DEFAULT NULL,
`serial` varchar(50) COLLATE utf8_spanish_ci DEFAULT NULL,
`estado` int(11) DEFAULT NULL,
PRIMARY KEY (`tablet_id`)
) ENGINE=InnoDB AUTO_INCREMENT=38 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.34 Diseño Físico – Tabla de Tablets

-- Estructura de tabla para la tabla usuario

CREATE TABLE `usuario` (
`usuario_id` bigint(20) NOT NULL AUTO_INCREMENT,
`username` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`password` varchar(250) COLLATE utf8_spanish_ci NOT NULL,
`nombre` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`apellido` varchar(50) COLLATE utf8_spanish_ci NOT NULL,
`correo` varchar(60) COLLATE utf8_spanish_ci NOT NULL,
`estado` int(11) NOT NULL,
`rol_id` bigint(20) DEFAULT NULL,
PRIMARY KEY (`usuario_id`),
UNIQUE KEY `UK_username` (`username`),
KEY `FK_ROL` (`rol_id`),
CONSTRAINT `FK_ROL` FOREIGN KEY (`rol_id`) REFERENCES `rol` (`rol_id`)
) ENGINE=InnoDB AUTO_INCREMENT=11 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.35 Diseño Físico – Tabla de Usuarios

56
-- Estructura de tabla para la tabla version
CREATE TABLE `version` (
`version_id` bigint(20) NOT NULL AUTO_INCREMENT,
`codigo` varchar(15) COLLATE utf8_spanish_ci NOT NULL,
`nombre` varchar(60) COLLATE utf8_spanish_ci DEFAULT NULL,
`estado` int(11) NOT NULL,
`fecha_creacion` datetime NOT NULL,
`fecha_distribucion` datetime NOT NULL,
PRIMARY KEY (`version_id`),
UNIQUE KEY `UK_codigo` (`codigo`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;
Figura 3.36 Diseño Físico – Tabla de Versiones

-- Estructura de tabla para la tabla versión – encuesta

CREATE TABLE `version_encuestas` (
`ver_id_ve` bigint(20) NOT NULL,
`enc_id_ve` bigint(20) NOT NULL,
PRIMARY KEY (`ver_id_ve`,`enc_id_ve`),
KEY `FK_ENC_VE` (`enc_id_ve`),
CONSTRAINT `FK_ENC_VE` FOREIGN KEY (`enc_id_ve`) REFERENCES `encuesta`
(`encuesta_id`),
CONSTRAINT `FK_VER_VE` FOREIGN KEY (`ver_id_ve`) REFERENCES `version`
(`version_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
Figura 3.37 Diseño Físico – Tabla de relación entre versiones y encuestas

-- Estructura de tabla para la tabla versión – prueba

CREATE TABLE `version_pruebas` (
`ver_id_vp` bigint(20) NOT NULL,
`pru_id_vp` bigint(20) NOT NULL,
PRIMARY KEY (`ver_id_vp`,`pru_id_vp`),
KEY `FK_PRU_VP` (`pru_id_vp`),
CONSTRAINT `FK_PRU_VP` FOREIGN KEY (`pru_id_vp`) REFERENCES `prueba`
(`prueba_id`),
CONSTRAINT `FK_VER_VP` FOREIGN KEY (`ver_id_vp`) REFERENCES `version`
(`version_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;
Figura 3.38 Diseño Físico – Tabla de relación entre versiones y pruebas

57
-- Estructura de tabla para la tabla versión – tablet
CREATE TABLE `version_tablet` (
`vt_id` bigint(20) NOT NULL AUTO_INCREMENT,
`fecha_creacion` datetime NOT NULL,
`fecha_actualizacion` datetime NOT NULL,
`tablet_id` bigint(20) NOT NULL,
`version_id` bigint(20) NOT NULL,
PRIMARY KEY (`vt_id`),
KEY `FK_version_t` (`version_id`),
KEY `FK_tablet_t` (`tablet_id`),
CONSTRAINT `FK_tablet_t` FOREIGN KEY (`tablet_id`) REFERENCES `tablet`
(`tablet_id`),
CONSTRAINT `FK_version_t` FOREIGN KEY (`version_id`) REFERENCES
`version` (`version_id`)
) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8
COLLATE=utf8_spanish_ci;

Figura 3.39 Diseño Físico – Tabla de relación entre versions y tabletas

58
 CAPÍTULO 4
DESARROLLO E IMPLEMENTACIÓN DEL SISTEMA
4.1 Desarrollo del sistema y sus Interfaces

Para iniciar el desarrollo del sistema tomamos en cuenta las tecnologías disponibles y el
conocimiento de programación adquirido en nuestros años de estudio. Como se iba a
elaborar dos (2) aplicaciones, decidimos trabajar con el lenguaje de programación que
más conocíamos. Los conocimientos que nos hacían falta los íbamos adquiriendo a
medida que avanzaba el proyecto y gracias al resultado de nuestras investigaciones sobre
los temas involucrados para las diferentes funciones de los sistemas.

4.1.1 Aplicación Web

Para el desarrollo de la aplicación web como lenguaje de programación utilizamos JAVA.

Es el lenguaje con que más familiarizados estamos y el que nos permitiría avanzar más
rápido con la ayuda de ciertos framework de desarrollo disponible para dicho lenguaje.

- JAVA: con este lenguaje nos basamos en la programación orientada a objetos.

Tomando en cuenta que los diferentes módulos de mantenimiento y la elaboración
de pruebas y encuestas representaban una entidad en la base de datos, cada entidad
podía ser definida como un objeto en sí.
De java utilizamos clases, métodos, atributos y procedimientos para entablar la
comunicación e interacción entre las diferentes entidades que conforman el
sistema.
- Spring Tool Suite: es el entorno de desarrollo basado en Eclipse que utilizamos
para realizar la codificación de todos los componentes del proyecto. Con este IDE
creamos clases, paquetes, carpetas, archivos, interfaces, etc., que armarían la
estructura de la aplicación.
- Spring: es el framework para el desarrollo de la aplicación Java que nos permite
agilizar y simplificar la codificación. Este framework nos brinda un conjunto de
clases y librerías que nos facilitó la programación de ciertas funcionalidades. De
esto, hicimos uso de la inyección de dependencias, el uso de anotaciones, el
concepto de JavaBeans o POJO (Plain Old Java Object), entre otros.
- MVC: junto con Spring realizamos la programación basándonos en el patrón de
arquitectura de software MVC (Modelo – Vista – Controlador). Para una
codificación más organizada este patrón separa los datos (modelo) y la lógica del
negocio (controlador) de la interfaz de usuario (vista).
- Maven: esta herramienta nos ayudó a gestionar y comprimir el proyecto para su
posterior instalación en el servidor web. Basándose en el concepto de un modelo
de objeto de proyecto (POM), con Maven pudimos gestionar la compilación, los
informes y la documentación del proyecto a partir de una pieza central de
información. Además, esta herramienta nos facilitó la descarga de librerías
especiales necesarias para el proyecto. Al terminar la compilación del código
fuente se genera un archivo WAR (Web Application Archives).

59
- Hibernate: es la herramienta especial que utilizamos para lograr el mapeo objeto-
relacional (ORM) de la plataforma. Hibernate nos facilitó el mapeo de atributos
entre la base de datos relacional y el modelo de objetos de la aplicación.
- Mysql: es el sistema de gestión de bases de datos relacional que seleccionamos
para construir la base de datos del sistema.
- Tomcat: como se usó JAVA para la codificación de la aplicación web, utilizamos
este servidor web para contener el código fuente y el resto los archivos. El archivo
WAR generado por Maven contiene paginas jsp, html, javascript, hojas de estilo,
servlets y otros ficheros necesarios para el despliegue de la aplicación. Tomcat
toma este archivo lo descomprime y traduce las páginas jsp (java server pages) a
páginas html. Al levantar el servidor tomcat la aplicación queda disponible para su
uso a través de un navegador web.
- JSP: son las páginas web dinámicas basadas en HTML y XML. Utiliza etiquetas
para desplegar los componentes visuales de la interfaz gráfica. Además, utiliza
etiquetas especiales de otras librerías para realizar validaciones y controlar las
operaciones y flujos dentro de las pantallas.
- Interfaz gráfica de aplicación web: el 75% de la aplicación se basa en
mantenimientos de datos. Por tal razón el desarrollo de todos estos
mantenimientos los basamos en las operaciones básicas hacia la base de datos.
Utilizamos las funciones CRUD (Create, Read, Update and Delete) para crear,
leer, actualizar y eliminar datos en el sistema.
Establecimos que las pantallas de mantenimientos inicialmente desplegarían una
tabla o lista de todos los registros disponibles de la tabla que se esté consultando.
Esa pantalla inicial tendría la opción de llamar a un formulario para agregar
nuevos registros y realizar búsqueda de datos por medio de ciertos parámetros.
Cada registro tiene las opciones para consultar, editar y eliminar la información de
la base de datos. Estas son las operaciones más comunes en la mayoría de las
pantallas del sistema, siendo este formato de fácil uso para los usuarios.
- Codificación: iniciamos la programación del sistema creando un proyecto Java
con nuestro entorno de desarrollo Spring Tool Suite (STS). Distribuimos los
archivos en dos grandes grupos para tenerlos mejor organizados.
El primer grupo contiene todos los archivos Java que representan la lógica del
sistema. Dentro se encuentran los controladores o clases que interactúan con la
capa de datos y las interfaces de usuario. Estas clases son las encargadas de
procesar los eventos y solicitudes que realizan los usuarios. Además, se
encuentran los objetos que representan cada tabla de la base de datos y que sirven
para registrar cada dato en el lugar correspondiente.
El segundo grupo contiene todos los recursos y archivos necesarios para el
despliegue de las pantallas a los usuarios. Dentro se encuentran las páginas jsp, los
estilos para la aplicación, los scripts de javascript, las imágenes, etc. Estos
archivos son los que el servidor envía a los navegadores clientes y contienen
formularios, tablas, datos, etc.
Se programó un servicio web que sería el punto de enlace o comunicación entre la
aplicación web y móvil. Los datos del servidor se procesan en ese servicio y se
traducen a un formato que pueden leer las tabletas. Los datos que envían las
60
 tabletas son procesados también en ese servicio y traducidos a código java para su
posterior registro.

Figura 4.1 Estructura del Proyecto Web – Paquetes de Código JAVA

Figura 4.2 Estructura del Proyecto Web – Archivos para interfaces de usuario
61
4.1.2 Aplicación Móvil
Para el desarrollo de la aplicación móvil como lenguaje de programación utilizamos
JAVA. Ya que es el lenguaje para aplicaciones nativas en Android. A pesar de utilizar
código JAVA, la programación Android sigue ciertos estándares y formatos de
codificación que debimos comprender antes de iniciar el desarrollo.

- JAVA: con este lenguaje nos basamos en la programación orientada a objetos.

Tomando en cuenta que los objetos provenientes del servidor representan
entidades o tablas en la base de datos, se necesitó el uso de programación
orientada a objetos.
De java utilizamos clases, métodos, atributos y procedimientos para entablar la
comunicación e interacción entre las diferentes entidades que conforman el
sistema.
- Android Studio: es el entorno de desarrollo oficial para programación Android.
Con este IDE creamos clases, paquetes, carpetas, archivos, interfaces, etc., que
armarían la estructura de la aplicación.
- XML: el diseño de las pantallas en Android trabaja con este lenguaje de marcas.
Aunque el IDE ofrece un área de diseño, se necesitaba tener cierto conocimiento
en XML para agregar características personalizadas a las pantallas.
- SQLite: es el sistema de gestión de bases de datos relacional que utiliza
internamente los dispositivos con sistema operativo Android. Es una base de datos
ligera que alberga los datos que provienen del servidor y los que se generan
directamente en la aplicación.
- Interfaz gráfica de aplicación móvil: se diseñaron las pantallas para que el usuario
se enfocara en los cuestionarios y no tuviera que entretenerse en otras
funcionalidades que les compete a los administradores del sistema o personal
encargado.
Establecimos que las pantallas de pruebas y encuestas iban a desplegarse después
de realizar la búsqueda del estudiante o docente que haría uso del sistema.
El proceso para el uso del sistema móvil inicia ingresando a uno de los tres (3)
módulos disponibles (Estudiantes, Docentes, Administración). Luego se realiza la
búsqueda por número de cédula de la persona y se seleccionaría uno de los
cuestionarios disponibles para esa persona. Dentro del cuestionario se despliega
una pregunta con sus opciones de respuestas y a medida que se contesten las
preguntas se registran los resultados hasta completar el cuestionario.
- Codificación: iniciamos la programación del sistema creando un proyecto Android
con nuestro entorno de desarrollo Android Studio. Distribuimos los archivos en
dos grandes grupos para tenerlos mejor organizados.
El primer grupo contiene todos los archivos Java que representan la lógica del
sistema. Dentro se encuentran los controladores o clases que interactúan con la
capa de datos y las interfaces de usuario. Estas clases son las encargadas de
procesar los eventos y solicitudes que realizan los usuarios. Además, se

62
 encuentran los objetos que representan cada tabla de la base de datos y que sirven
para registrar cada dato en el lugar correspondiente.
El segundo grupo contiene todos los recursos y archivos necesarios para el
despliegue de las pantallas a los usuarios. Dentro se encuentran los diseños XML,
los estilos para la aplicación, las imágenes, etc.

Se utilizaron librerías especiales para que la aplicación pudiera comunicarse con

el servidor para obtener y enviar datos. Y se emparejaron los objetos del servidor
con el cliente para que los datos encajaran en sus respectivas bases de datos.

Figura 4.3 Estructura del Proyecto Móvil

4.2 Ejecución, pruebas y ajustes

Con el esquema en espiral a medida que se iba completando de forma total o parcial una
funcionalidad se realizaba una presentación del avance logrado.

En ambiente de desarrollo armamos nuestro servidor web y compilamos la solución.

Iniciamos el desarrollo sólo con la aplicación web, para la aplicación móvil el desarrollo
no iniciaría hasta que el servidor estuviera adelantado porque el cliente dependía de
muchas funcionalidades para poder ejecutarse de forma adecuada.

63
El módulo de mantenimiento era una de las primordiales antes de iniciar cualquier otro
módulo. Ya que los datos que se generarían en este módulo se necesitaban para completar
la información de las funcionalidades de preguntas, pruebas y encuesta.

Realizamos pruebas a nivel local compilando el código programado y agregando registros

de estudiantes, docentes, centros educativos, usuarios, entre otros. Luego que el proceso
de “agregar” funcionara de la forma esperada, procedíamos con los procesos de “buscar”,
“consultar”, “editar” y “eliminar”.

Cuando un mantenimiento estaba completo ya servía de base para el resto de las entidades
que realizaban las mismas operaciones en la base de datos. A medida que los
mantenimientos iban siendo completados volvíamos a probar todas las operaciones en
base de datos.
Con cada corrección de errores y ajustes en las funcionalidades, se generaba un nuevo
Archivo de aplicación web (WAR) para implementar en nuestro servidor local.
Volvíamos a verificar las funcionalidades y a realizar pruebas de integración para
comprobar el funcionamiento del sistema como un todo.

Al llegar al desarrollo de las funciones más complejas se verificaba que la relación entre
entidades trabajase correctamente. Hacíamos modificaciones en la base de datos al
determinar que necesitábamos nuevos campos en las tablas. Preparábamos todo lo
necesario para el inicio del desarrollo de la aplicación móvil.

SENACYT nos facilitó el servidor donde instalaríamos las herramientas necesarias para
ejecutar la aplicación en un ambiente de pruebas. La primera implementación no logró
conexión con la base de datos y se tuvo que hacer pruebas en local para corregir los
problemas suscitados en el servidor de SENACYT.

Se hizo una presentación explicando las funcionalidades desarrolladas en la SENACYT.

El personal de SENACYT realizó sus observaciones y sugerencias para las
funcionalidades que se observaron. Entramos en otro ciclo de desarrollo agregando y
ajustando las solicitudes hechas por el personal.

Después de un periodo largo de desarrollo y de auto capacitación en programación

Android finalmente iniciamos a codificar los primeros componentes de la aplicación
móvil. El módulo de administración era el componente inicial ya que desde ahí se lograría
el enlace con el servidor.

Se armó una red local para que ambas aplicaciones pudieran comunicarse. Para probar
esta parte nuestro ordenador portátil fungió como servidor ejecutando la aplicación web y
por el otro lado utilizamos una tableta Lenovo suministrada por SENACYT.

Continuamos la programación de los módulos de estudiantes y docentes y la ejecución de

pruebas y encuestas desde la tableta. Todo error o comportamiento no esperado se
solventaba y se volvía a probar para darlo como funcional. Paralelamente se hacía ajuste
en la aplicación web porque se seguía realizando pruebas.

64
Se presentaron los avances de la aplicación móvil para ser evaluados por el cliente (los
miembros de la Dirección de Aprendizaje de la SENACYT). Se hizo observaciones y
ajustes para así iniciar otros ciclos de desarrollo y entrega de avances.

Las aplicaciones se implementaban en los servidores de SENACYT para pruebas en

entornos más reales. Se aplicaban los ajustes en local, se verificaban y se implementaban
para su evaluación y aprobación.

Figura 4.4 Presentación de avance de la aplicación web

65
 Figura 4.5 Presentación de avance de la aplicación móvil

4.3 Resultados y evaluaciones

Al obtener una versión más estable de los sistemas que se implementaban se iniciaba un
periodo de pruebas por parte del cliente (SENACYT). El cliente verificaba que los
requerimientos propuestos se hayan alcanzado o se hacia la observación sobre un cambio
que podría realizarse.

En las pruebas en el ambiente local se respondían desde las tabletas las pruebas y
encuestas. Se trabajaba de modo offline para que los resultados quedasen registrados en la
base de datos de la aplicación. Luego se conectaban los dispositivos a la red para que
envíen los resultados al servidor. El servidor los recibe y desde la pantalla de consulta de
resultados se generaba un archivo Excel con todas las respuestas obtenidas desde las
tabletas. Este es el último paso de ciclo de aplicación de pruebas / encuestas.

En las pruebas desde el ambiente de SENACYT, el personal encargado registraba el

paquete de pruebas y encuestas que las tabletas iban a recibir. Enlazaban las tabletas al
servidor para que descargasen los registros. Procedían a responder las pruebas y encuesta
con cierta cantidad de estudiantes y docentes. Esperaban que las tabletas enviaran los
datos por si solas y luego consultaban los registros que llegaban al servidor.

Los resultados de estas pruebas fueron exitosos al obtener los registros de las tabletas y la
generación de los archivos Excel con las respuestas también se logró.

66
4.4 Implementación final del sistema
Después de realizar todas pruebas y ajustes necesarios, los sistemas quedaron listos para
ser implementados en el servidor de producción. Para realizar la implementación final se
verificó que el servidor cumpliera con los requisitos que solicitamos como lo son:
aumento de memoria RAM, espacio de almacenamiento en disco, gestor de base de datos
MySQL instalado y servidor web para aplicaciones java instalado.

Los pasos que seguimos para realizar la implementación final fueron:

 Compilamos la aplicación web configurada con los datos del servidor final para la
conexión a la base de datos. Se generó el archivo WAR
 Compilamos la aplicación móvil y generamos el archivo APK (instalable de
aplicaciones Android)
 Como el servidor dispone de sistema operativo Linux Centos, iniciamos una
sesión remota con el programa PUTTY.
 Ingresamos las credenciales para conexión que no suministró SENACYT.
 Iniciamos un cliente FTP y transferimos los archivos WAR y APK
(Plataforma.war y plataforma.apk)
 Ingresamos a la ruta donde se encuentra en servidor web y lo apagamos.
 Creamos un directorio en el servidor donde ser guardarían las imágenes de las
preguntas que se vayan creando y el archivo apk.
 Editamos el archivo de configuración del servidor web para que reconozca la ruta
de los archivos
 Ingresamos a la base de datos MySQL con las credenciales suministradas por
SENACYT
 Creamos la base de datos plataforma
 Con el cliente FTP transferimos el script sql para la creación de las tablas del
sistema.
 Ejecutamos el script sql y verificamos que las tablas fueron creadas y se hayan
insertado los datos iniciales.
 Movimos el archivo plataforma.war al directorio webapps del servidor web
tomcat.
 Renombramos el archivo plataforma.war a ROOT.war
 Movimos el archivo plataforma.apk a la ruta de archivos que creamos
previamente.
 Iniciamos el servidor de aplicaciones y esperamos que terminara de iniciar todos
sus componentes.
 Ingresamos desde el navegador a la ruta de la aplicación:
evaluaciones.senacyt.gob.pa
 Iniciamos sesión con un usuario válido del sistema web.
 Ingresamos a la sección de roles y selecciónanos los permisos del rol de
administrador.
 Nos dirigimos a la pantalla de configuración y en el campo de ruta de imágenes
colocamos la ruta completa del directorio que se creó para los archivos

67
  Desde las tabletas ingresamos a la aplicación servidor y descargamos la aplicación
móvil.
 Realizamos la instalación de la aplicación y luego ingresamos,
 Verificamos que las funcionalidades de ambas aplicaciones estuvieran correctas y
listas para su uso.

4.4.1 Entrenamiento al usuario

Durante el periodo de desarrollo se brindaron capacitaciones para que los usuarios fueran
familiarizándose con las aplicaciones, su uso y funcionamiento fueron explicados.

Se convocó a una última capacitación para explicar el funcionamiento total de todo el

ciclo de aplicación y evaluación de las pruebas y encuestas con los dos sistemas.

Por parte nuestra se suministraron los manuales de usuario de las aplicaciones, donde se
explica a detalle todas las operaciones que brinda la plataforma de evaluación educativa.
Verificar los manuales que se encuentran en la sección de Anexos.

Se desarrolló una fase de preguntas y respuestas, se hizo un compendio de todas las

funcionalidades que se pudieron incluir y de las que se podrían implementar en otras fases
futuras.

4.4.2 Pruebas en paralelo

Durante el periodo de prueba de las aplicaciones en el ambiente de pruebas de
SENACYT, nosotros aportábamos escenarios de pruebas para hacer estos ensayos lo más
cercanos a la realidad. Ya que en el momento final se usarán 210 tabletas, trabajando
simultáneamente para enviar y recibir información, la aplicación servidora debe estar
preparada para procesar y atender las solicitudes de las tabletas y de los ordenadores sin
inconvenientes.

4.4.3 Puesta en marcha

SENACYT aún evalúa el uso definitivo de la plataforma que le hemos brindado.

Mientras, aún se mantienen las pruebas para garantizar el correcto desempeño de las
aplicaciones y el dominio total del uso de sus operaciones.

Se espera que para el inicio de clases del periodo académico del 2018 se inicien las
pruebas pilotos en algunos centros educativos.

4.5 Recomendaciones de Mantenimiento y Soporte

Algunas de las recomendaciones que podemos mencionar para mantener a los sistemas
son:

68
- Se debe verificar después de 2 o 3 periodos de aplicar pruebas y encuestas la
memoria de las tabletas. Esto con el fin de que no ocurra errores en la descarga de
datos por falta de espacio en los dispositivos.
- Se debe tener personal capacitado que conozca las tecnologías que se utilizaron
para el desarrollo de los sistemas. Esto es para que se pueda verificar y atender
excepciones durante la ejecución de las pruebas y encuesta.
- Se debe tener uno o varios administradores de base de datos. Esto es primordial ya
que hay ciertas funcionalidades que dependen de un administrador de base de
datos para que suministre información que no está disponible en las aplicaciones.
- Verificar el estado de las tabletas: si tienen carga en la batería, si tienen conexión
a red, si tienen los datos actualizados, etc.
- Debe haber uno o varios administradores del sistema servidor. Esto es para crear
usuarios al personal que manipulará el sistema y para reiniciar contraseñas en caso
de que los usuarios olviden sus credenciales.
- Debe haber personal que supervise el estado del servidor web.
- Además de los manuales de usuario, el personal más experimentado debería dar
capacitaciones a los nuevos usuarios que se integren.
- En los periodos de aplicación de pruebas y encuestas siempre es bueno tener
personal que configure los dispositivos para entregarlos a los estudiantes y
docentes.
- Para futuras actualizaciones o mejoras se necesitaría personal con conocimiento
en el lenguaje de programación JAVA y desarrollo Android
- Verificar bien los datos cuando se va a realizar una carga o actualización masiva
de datos. Apoyarse de los datos del sistema y del administrador de base de datos.

69
 CONCLUSIONES

En los últimos tiempos, tanto el desarrollo de aplicaciones móviles como el

de dispositivos tecnológicos ha evolucionado de manera impresionante, hasta
llegar a un nivel de eficiencia con el que soñábamos hace unos años. La
interacción entre usuario y dispositivo se ha mejorado, y el mercado de
aplicaciones ha crecido en todos los ámbitos, desde el entretenimiento hasta,
también, la educación.

En un futuro, se espera que las apps sean una de las claves por las cuales la
educación presencial quede relegada y se imponga la educación desde casa en
ambientes virtuales. De momento, las posibilidades en el mercado y el mundo de
las apps dedicadas a educación son inmensas, ya que los dispositivos disponibles
son muy variados. La tendencia nos dice que en educación dominará el terreno la
tableta, sustituyendo a los libros de texto tradicionales. Ya se utiliza en muchos
sitios por el ahorro que supone frente al gasto en libros tradicional, que se
acentuará cuando se fabriquen tabletas de bajo coste especiales para educación.

Se observa un mayor interés por investigar las TIC’s en educación, sobre todo a
nivel preescolar, ya que es uno de los terrenos hasta ahora más inexplorados y con
muchas oportunidades que promete mucho en un futuro.

Durante el desarrollo del Proyecto de Tesis se lograron todos los objetivos

específicos perseguidos:
 Se Investigaron las posibles tecnologías que brindan un ambiente propicio
para el desarrollo e implementación de la plataforma educativa.

 Se recopiló información relevante de métodos de enseñanza que

contribuyan con el proceso de aplicación de pruebas a los estudiantes.

 Se establecieron las bases y requerimientos principales para la elaboración

de la solución tecnológica.

 Se analizaron y diseñaron la estructura y la arquitectura del proyecto con

base a los requerimientos y metas especificadas para el sistema.

 Se desarrolló un sistema cliente-servidor que permite aplicar pruebas y

encuestas, además de dar seguimiento a los resultados para evaluarlos.

 Se implementó una plataforma de evaluación educativa para liberarla y

ejecutarla en los centros educativos.

Con todos los objetivos específicos alcanzados se ha logró cumplir con el objetivo
general de nuestra propuesta:

70
 “Implementar una Plataforma de Evaluación Educativa de Ciencias y Matemáticas
para estudiantes y docentes”

RECOMENDACIONES

Algunas recomendaciones en general, las listamos a continuación:

 En cuanto a procesos en general, es importante obtener conocimientos de todos

los procesos que se automatizarán, evaluar la factibilidad, si el tiempo que se invertirá
realmente impactará positivamente a largo plazo produciendo mayores beneficios que
el tiempo invertido en el proceso de automatización.

 Se debe contemplar mejoras o ajustes de la iniciativa descrita en este documento,

ya que esta es una herramienta que nos suministra datos importantes para la
elaboración de estrategias que nos encaminaran al mejoramiento del proceso de
enseñanza-aprendizaje de la educación panameña.

 Incluir en un futuro evaluaciones a sectores de pre-media y media, para conocer el

nivel de enseñanza que los estudiantes de secundaria reciben.

 Incluir pruebas de otras asignaturas, adicionales a las que estaban establecidas en

un principio en el alcance del proyecto.

71
 BIBLIOGRAFÍA

Como bibliografía (infografía), se recomienda los siguientes enlaces:

- Gaspar, A. (02 de 11 de 2012). Las mejores aplicaciones educativas en Android.

Obtenido de
http://recursostic.educacion.es/observatorio/web/en/software/software-
educativo/1070-las-mejores-aplicaciones-educativas-para-android?showall=1
- Girones, J. T. (Tercera edición 2013). El Gran Libro de Android. MOCAMBO,
SA.
- IntelliJ-Google. (s.f.). ANDROID STUDIO. Obtenido de
https://developer.android.com/sdk/index.html
- Menéndez, R. I. (s.f.). Android 100% v1.
- Menéndez, R. I. (s.f.). Android 100% v1. Obtenido de http://jarroba.com/libro-
android-100-gratis/
- Segura, J. A. (s.f.). Tendencias en educación en la sociedad de las tecnologias de
la información. Obtenido de
https://scholar.google.com/citations?user=ummz4n8AAAAJ&hl=es
- Ministerio de Educación de la República de Panamá. "Informe De Revisión
Nacional De Educación Para Todos (EPT) 2015 - Panamá". Organización
Cultural, Científica y Educativa de las Naciones Unidas (UNESCO). 2015
http://unesdoc.unesco.org/images/0023/002300/230035S.pdf

- Carolina Jerez Henríquez. " Segundo Estudio Regional Comparativo y Explicativo

(SERCE)". Oficina Regional de Educación para Amérca Latina y el
Caribe(OREALC/UNESCO Santiago)
http://www.unesco.org/new/es/santiago/education/education-assessment-
llece/second-regional-comparative-and-explanatory-study-serce/

- "Programa Internacional de Evaluación de los Alumnos (PISA)". OCDE,

Organización para la Cooperación y el Desarrollo Económicos, París.
http://www.oecd.org/centrodemexico/medios/programainternacionaldeevaluacion
delosalumnospisa.htm

72
ANEXOS
 Especificación de
Requisitos del Sistema
PLATAFORMA DE EVALUACIÓN EDUCATIVA
PARA CIENCIAS Y MATEMÁTICAS Y
SEGUIMIENTO A DOCENTES
 PREFACIO
Este documento describe los requerimientos de software de la Plataforma de
Evaluación Educativa, cuyo objetivo principal es valorar el desempeño de los
estudiantes de primaria en Ciencias y Matemáticas por medio de pruebas de
conocimientos. Además de dar seguimiento a los métodos de enseñanza de los
docentes mediante la aplicación de encuestas.
Este documento de requerimientos es la base del desarrollo de software del
proyecto. Comprende los puntos importantes a tomar en cuenta para el correcto
funcionamiento del sistema.

HISTORIA DEL DOCUMENTO

Fecha Versión Comentarios Autor

0.1 Versión inicial Fernando González,
Rosa Jiménez
1. INTRODUCCIÓN

Esta Especificación de Requisitos de Sistema para la Plataforma de Evaluación

Educativa está basada en el estándar IEEE 830-1998 Recommended Practice for
Software Requirements Specification.

1.1 Propósito
El objetivo de este documento es especificar, analizar y definir de manera
clara y precisa las funcionalidades y restricciones que tendrá el sistema que se
desea construir, y va dirigida al equipo de desarrollo de software y a las
personas que harán uso del sistema terminado.
Ciertos requerimientos pueden ser modificados, cambiados, eliminados y no
implementados según surja una situación que lo amerite.
Este documento será un medio de comunicación entre cada uno de los roles
implicados en el desarrollo de software y por lo mismo está sujeto a
revisiones, tanto de los desarrolladores como de los usuarios, hasta obtener
su aprobación. En cuanto esto ocurra el documento funcionará como base al
equipo de desarrollo para la construcción del nuevo sistema.

2. REQUISITOS ESPECÍFICOS

En esta sección se definen los requisitos específicos del SISTEMA, se describe la

funcionalidad que desea el usuario para ese requisito.
Primero se presenta algunos atributos de los requisitos en una tabla y luego se
realiza una descripción del mismo.

2.1 Requisitos Funcionales

Número del requisito REQ001 Tipo de requisito Interfaz de Usuario
Nombre Pantalla Inicial
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción La pantalla inicial debe mostrar un formulario para que los usuarios
que tengan acceso al sistema puedan iniciar sesión.
Justificación El sistema debe restringir el acceso al personal no autorizado para
realizar cambios en el sistema.
Criterio de Las credenciales que se ingresen deben ser datos de usuarios
Aceptación / registrados en el sistema.
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ002 Tipo de requisito Interfaz de Usuario

Nombre Formulario de Inicio de Sesión
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe mostrar un formulario donde se soliciten los datos de
usuario. Los datos a solicitar son:
-Nombre de usuario
-Contraseña
Justificación Para que un usuario ingrese al sistema debe brindar los datos
mínimos para validar que se trata de un usuario registrado.
Criterio de -El sistema debe validar que los datos del usuario son correctos.
Aceptación / -No debe permitir el acceso a personal no autorizado.
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ003 Tipo de requisito Interfaz de Usuario

Nombre Ingreso al sistema
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir el acceso a usuarios autorizados.
Justificación Un usuario autorizado debe poder acceder al sistema para interactuar
y realizar los procesos necesarios.
Criterio de El sistema debe mostrar las diferentes funcionalidades según los
Aceptación / permisos del usuario ingresado.
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ004 Tipo de requisito Interfaz de Usuario

Nombre Menú de Opciones
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe mostrar un menú de opciones que contenga las
principales funcionalidades.
Justificación La usabilidad del sistema debe permitir al usuario realizar las
diferentes funcionalidades de una manera sencilla.
Criterio de Al utilizar el menú se debe ingresar a la funcionalidad especificada.
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ005 Tipo de requisito Interfaz de Usuario

Nombre Opciones de Menú
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe desplegar en el menú las siguientes opciones:
-Mantenimiento
-Reportes
-Elaboración de Pruebas/Encuestas
-Configuración
Justificación La Plataforma debe organizar las diferentes funcionalidades según el
objetivo que se desee lograr.
Criterio de Las opciones deben contener las funcionalidades según el criterio
Aceptación / establecido.
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ006 Tipo de requisito De sistema

Nombre Registro de Datos
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir alojar todos los datos y registros en una base
de datos central.
Justificación Los datos obtenidos podrán ser administrados, procesados y
respaldados.
Criterio de Datos disponibles para el uso del sistema.
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ007 Tipo de requisito Funcional

Nombre Mantenimiento de Datos
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir la funcionalidad de registrar, actualizar.
eliminar y verificar los datos de las diferentes entidades.
Justificación Para un óptimo funcionamiento del sistema es requerido contar con
diferentes entidades que faciliten la ejecución de los procesos.
Criterio de
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ008 Tipo de requisito Funcional

Nombre Mantenimiento de Datos
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir la funcionalidad de registrar, actualizar.
eliminar y verificar los datos de las diferentes entidades.
Justificación Para un óptimo funcionamiento del sistema es requerido contar con
 diferentes entidades que faciliten la ejecución de los procesos.
Criterio de Los datos serán registrados, actualizados. eliminados y verificados en
Aceptación / la base de datos
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ009 Tipo de requisito Interfaz de usuario

Nombre Pantalla de Preguntas
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe desplegar un formulario que capture la información
referente a las preguntas de las pruebas y encuestas
Justificación Las preguntas son la base de las pruebas y encuestas.
Criterio de Se registra el detalle de la pregunta.
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ0010 Tipo de requisito Interfaz de usuario

Nombre Pantalla de Preguntas de Estudiantes
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe desplegar un formulario que capture la información
referente a las preguntas de las pruebas de estudiantes
Justificación Las preguntas deben estar relacionadas a un tema de ciencias o
matemáticas.
Criterio de Se debe registrar el tipo, tema y respuesta de la pregunta
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ00 Tipo de requisito Funcional

Nombre Elaboración de Pruebas/Encuesta
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir elaborar una prueba/encuesta a partir de una
lista de preguntas previamente establecidas
Justificación Las pruebas deben estar conformadas por una cantidad de preguntas
seleccionadas.
Criterio de Seleccionar todas las preguntas que conformaran la prueba/encuesta.
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ00 Tipo de requisito Funcional

Nombre Elaboración de Paquete de Pruebas/Encuesta
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir elaborar un paquete que contenga todas las
pruebas/encuestas que serán aplicadas en un momento determinado.
Justificación El sistema móvil se actualizará cuando esté disponible un nuevo
paquete de pruebas/encuestas.
Criterio de Paquete disponible para ser consumido por la aplicación móvil.
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ00 Tipo de requisito Funcional

Nombre Comunicación con aplicación móvil
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir el intercambio de datos entre el servidor y la
aplicación móvil.
Justificación El sistema móvil envía los datos para ser registrados en la base de
datos central.
Criterio de Envió y recepción de datos entre el servidor y la aplicación móvil.
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ00 Tipo de requisito funcional

Nombre Reportes
Fuente Sistema Servidor
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir el análisis de los resultados de las
pruebas/encuestas
Justificación Se necesita un análisis de los resultados para medir el nivel de
enseñanza de los estudiantes.
Criterio de Desplegar los resultados en forma de estadísticas.
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015

Número del requisito REQ00 Tipo de requisito funcional

Nombre Aplicación de pruebas
Fuente Sistema Móvil
Propuesto por SENACYT
Prioridad Alta/Esencial Media/Deseado Baja/ Opcional
Descripción El sistema debe permitir la ejecución de las pruebas
Justificación Los estudiantes responderán a las preguntas de las pruebas.
Criterio de Despliegue de las preguntas de las pruebas.
Aceptación /
Validación
Última modificación Rosa Jiménez 20/12/2015