Embed Size (px)
Citation preview
UNIVERSIDAD TÉCNICA FEDERICO SANTA MARÍA
DEPARTAMENTO DE ELECTRÓNICA VALPARAÍSO – CHILE
“DESARROLLO DE UN SISTEMA DE
INFORMACIÓN Y GESTIÓN DE
EVALUACIONES”
NICOLÁS ANDRÉS ALEXIS GRANDÓN ESPINOZA
MEMORIA DE TITULACIÓN PARA OPTAR AL TÍTULO DE INGENIERO
CIVIL TELEMÁTICO
PROFESOR GUÍA: TOMÁS ARREDONDO VIDAL
PROFESOR CORREFERENTE: PEDRO GAJARDO ADARO
DICIEMBRE 2010
ii
Agradecimientos
Este trabajo de título, representa el término de la etapa más emocionante de mi vida. Es
fruto del esfuerzo, dedicación y largos años de aprendizaje, que fueron compartidos con
muchísimas personas y que de alguna u otra manera forman parte de esto.
Quiero dedicar y agradecer a mis padres, porque siempre se han preocupado por mi
bienestar, me entregaron amor, paz, confianza, y lo que eternamente agradeceré, me
dieron una gran educación.
A mi hermano Carlos, por creer en mis capacidades, ser un gran motivador e incentivarme
a formar parte de esta gran institución educativa.
A mí querida hermana Andrea, por ayudarme durante todo el camino. Me escuchaste y
aconsejaste en momentos muy difíciles.
Al Dieguito, mi partner en Puerto Montt, Valparaíso y parece que en cualquier lugar en
donde me encuentre. Gracias por compartir y acompañarme durante gran parte de la vida.
Al amor de la vida, Romanita. Estoy seguro que quedaré corto con las palabras pero…
Gracias por ser una gran compañera, amiga y cómplice. Por aparecer en el momento
preciso y preocuparte siempre de mí.
A Francisco Durán, Erwin Hernández, Pedro Gajardo y Tomás Arredondo, por las
críticas, sugerencias y ayuda prestada durante la etapa de desarrollo del trabajo y, por
supuesto, la confianza depositada.
Al departamento de Matemática, por permitirme ser parte de su equipo de trabajo, en
especial a María Estrella, Andrea, Don Manuel y Don Augusto, por el afecto y
preocupación entregado durante los años que compartimos.
Finalmente, a mis compañeros y amigos, por compartir alegrías, bromas, frustraciones,
lealtades e innumerables vivencias que marcaron esta gran etapa.
iii
Desarrollo de un Sistema de Información y Gestión de
Evaluaciones
Nicolás Andrés Alexis Grandón Espinoza
Memoria para optar al título de Ingeniero Civil Telemático
Profesor Guía: Tomás Arredondo Vidal
Diciembre 2010
Resumen
La medición de los conocimientos adquiridos por el estudiante a través de una evaluación
o certamen, es un proceso habitual en los cursos dictados por el departamento de
Matemática de la Universidad Técnica Federico Santa María. Sin embargo, los avances
tecnológicos y el rol que está cumpliendo hoy en día la información, obligan a incorporar
nuevos sistemas que ayuden a la obtención y entrega de ésta, de forma rápida y eficiente.
Actualmente, este proceso se lleva a cabo de forma manual, por cada evaluación de los
distintos cursos, y, si bien, la metodología utilizada es la misma en cada iteración, al
tratarse de evaluaciones con configuraciones distintas, cada repetición se trata de un
proceso totalmente nuevo.
Esta contribución presenta el diseño e implementación de un sistema Web que automatiza
el proceso de corrección, cálculo de notas y adquisición de información estadística,
respecto de las evaluaciones realizadas en un curso específico.
Esta propuesta optimiza el proceso en cuestión, disminuyendo considerablemente el
tiempo utilizado y contribuyendo a la toma de decisiones de la organización.
Palabras claves: Sistema, gestión, información de evaluaciones
iv
Índice General
Capítulo 1: Introducción ......................................................................................................... 8
Capítulo 2: Estado del arte.................................................................................................... 10
2.1 Sistemas existentes ..................................................................................................... 10
2.2 Identificación del Problema ........................................................................................ 11
2.3 Conclusiones ............................................................................................................... 12
Capitulo 3: Propuesta ........................................................................................................... 13
3.1 Objetivos ..................................................................................................................... 13
3.2 Requerimientos ........................................................................................................... 14
3.2.1 Requerimientos funcionales ................................................................................ 14
3.2.2 Requerimientos no funcionales ........................................................................... 15
Capitulo 4: Diseño ................................................................................................................ 16
4.1 Modelo de datos ......................................................................................................... 16
4.2 Especificación ............................................................................................................. 17
4.2.1 Perfiles de usuario ............................................................................................... 17
4.3 Casos de uso ............................................................................................................... 19
4.3.1 Casos de uso del Alumno .................................................................................... 19
4.3.2 Casos de uso del Profesor .................................................................................... 19
4.3.3 Casos de uso del Administrador .......................................................................... 21
4.4 Arquitectura ................................................................................................................ 23
4.4.1 Arquitectura cliente-servidor ............................................................................... 23
4.4.2 Arquitectura MVC ............................................................................................... 25
4.5 Tecnologías de programación ..................................................................................... 26
4.6 Resumen de tecnologías ............................................................................................. 27
Capítulo 5: Implementación ................................................................................................. 28
v
5.1 Procesos del sistema ................................................................................................... 28
5.1.1 Motor de corrección ............................................................................................ 28
5.1.2 Motor de cálculo de nota ..................................................................................... 29
5.1.3 Motor de lectura de datos desde archivo ............................................................. 32
5.2 Interfaces de presentación .......................................................................................... 34
5.2.1 Interface de Alumno ............................................................................................ 34
5.2.2 Interface de Profesor ............................................................................................ 35
5.2.3 Interface de Administrador .................................................................................. 36
5.3 Características del servidor ......................................................................................... 37
Capitulo 6: Verificaciones, validaciones y recomendaciones ............................................. 39
6.1 Pruebas de funcionalidades ........................................................................................ 39
6.1.1 Prueba de funciones ............................................................................................. 39
6.1.2 Pruebas de archivos de entrada ............................................................................ 39
6.1.3 Pruebas en motor de corrección y cálculo ........................................................... 40
6.1.4 Pruebas de marcha blanca.................................................................................... 40
6.2 Pruebas de rendimiento .............................................................................................. 40
6.2.1 Pruebas de software ............................................................................................. 40
6.2.2 Pruebas de hardware ............................................................................................ 41
6.3 Recomendaciones de respaldo .................................................................................... 42
6.4 Recomendaciones de seguridad .................................................................................. 42
Capitulo 7: Conclusiones ...................................................................................................... 44
7.1 Trabajos futuros .......................................................................................................... 45
Glosario ................................................................................................................................ 46
Bibliografía ........................................................................................................................... 47
vi
Índice de figuras
Figura 1: Descripción del proceso de corrección ................................................................. 11
Figura 2: Modelo de datos propuesto ................................................................................... 16
Figura 3: Definición de tipos de usuarios ............................................................................. 18
Figura 4: Casos de uso del usuario alumno .......................................................................... 19
Figura 5: Casos de uso del usuario profesor ......................................................................... 20
Figura 6: Casos de uso del administrador ............................................................................. 21
Figura 7: Arquitectura cliente-servidor del sistema ............................................................. 24
Figura 8: Arquitectura de desarrollo MVC .......................................................................... 26
Figura 9: Diagrama de flujo del motor de corrección .......................................................... 29
Figura 10: Configuración de ponderaciones ......................................................................... 30
Figura 11: Diagrama de flujo del motor de cálculo de nota ................................................. 32
Figura 12: Ejemplo de archivo tipo y su cabecera................................................................ 34
Figura 13: Descripción del interface del alumno.................................................................. 35
Figura 14: Descripción del interface del profesor ................................................................ 36
Figura 15: Descripción del interface del administrador ....................................................... 37
vii
Índice de tablas Tabla 1: Requerimientos funcionales ................................................................................... 14
Tabla 2: Requerimientos no funcionales .............................................................................. 15
Tabla 3: Descripción de las tablas del Modelo de datos....................................................... 16
Tabla 4: Descripción de los privilegios de usuarios ............................................................. 18
Tabla 5: Descripción del caso de uso, alumno consulta sus resultados ................................ 19
Tabla 6: Descripción del caso de uso, profesor selecciona un curso .................................... 20
Tabla 7: Descripción del caso de uso, profesor selecciona evaluación ................................ 20
Tabla 8: Descripción del caso de uso, profesor visualiza resultados de paralelo ................. 20
Tabla 9: Descripción del caso de uso, administrador crea un curso ..................................... 21
Tabla 10: Descripción del caso de uso, administrador ingresa inscripciones ...................... 21
Tabla 11: Descripción del caso de uso, administrador crea una evaluación ........................ 22
Tabla 12: Descripción del caso de uso, el administrador ingresa evaluaciones ................... 22
Tabla 13: Descripción del caso de uso, administrador ingresa una pauta ........................... 22
Tabla 14: Descripción del caso de uso, administrador ejecuta el proceso de corrección ..... 22
Tabla 15: Descripción del caso de uso, administrador calcula las notas .............................. 23
Tabla 16: Resumen de tecnologías ....................................................................................... 27
Tabla 17: Lista de tareas que requieren archivos debido al volumen de datos .................... 33
Tabla 18: Cabeceras requeridas para la importación de datos desde archivo ...................... 34
Tabla 19: Especificaciones del servidor ............................................................................... 38
Tabla 20: Tiempos de respuesta del sistema SGIE............................................................... 41
Tabla 21: Uso de CPU y RAM de SGIE .............................................................................. 41
Tabla 22: Tiempo de UPTIME del Servidor ........................................................................ 42
Capítulo 1: Introducción
En los últimos años, las tecnologías de información y comunicaciones (TIC) han tomado
un rol protagónico en un mundo cada vez más digitalizado, haciéndolas parte importante
de nuestras vidas.
El crecimiento explosivo de internet y el uso de intranets, han supuesto una transformación
en las necesidades de información de las organizaciones, es decir, hoy es casi un requisito
que la información sea accesible desde cualquier lugar dentro o fuera de la organización, y
además, que esta información sea compartida entre todas las partes involucradas de forma
completa o limitada de acuerdo a los privilegios que se tengan. En este contexto, las
aplicaciones web se han convertido en sistemas complejos, donde los interfaces de usuario
son cada vez más parecidos a las aplicaciones de escritorio, dando servicio a procesos de
negocio de gran envergadura con requisitos estrictos de accesibilidad y respuesta.
Estas necesidades han significado un movimiento creciente de cambio de las aplicaciones
tradicionales de escritorio hacia las aplicaciones web, debido principalmente, a que los
sitios web se han convertido en aplicaciones capaces de interactuar más o menos
sofisticada con el usuario.
El objetivo de este trabajo es diseñar, desarrollar e implementar un sistema web que
permita gestionar las evaluaciones realizadas en uno o más cursos del departamento de
Matemática de forma rápida y eficiente. En otras palabras, automatizar el proceso de
corrección y cálculo de notas. El sistema permitirá además entregar información
estadística, a través de gráficos y tablas de resumen, de los resultados de una evaluación
específica por paralelo, carrera y campus.
El sistema debe cumplir una serie de requerimientos definidos por el usuario que se
detallan en el capítulo 3. Un punto crítico en este aspecto consiste en que las evaluaciones
9
realizadas son del tipo alternativas, esto implica que, una evaluación consiste en un
cuadernillo de cantidad variable de preguntas y una hoja de respuestas donde el alumno
marca la alternativa que considera correcta. Esta hoja de respuestas es posteriormente
digitalizada a través de un software de reconocimiento óptico de marcas, que proporciona
distintas alternativas de almacenamiento entre las que se encuentra: exportación a un
archivo MS Excel.
En el capítulo 2 de este trabajo se describe el estado del arte, se detalla la realización del
proceso sin el sistema propuesto, y como esto justifica el desarrollo de la aplicación.
El capítulo 3 expone la propuesta del Sistema de Información y Gestión de Evaluaciones
(SGIE). Se definen los objetivos en base a los requerimientos realizados por el usuario.
En el capítulo 4 se explica el diseño de la aplicación Web. Involucra el modelo de datos,
definición de las funciones importantes del sistema, casos de usos, arquitectura y las
tecnologías a utilizar.
El capítulo 5 describe la implementación del sistema, interfaces y características técnicas
del servidor de instalación.
El desempeño del sistema, las recomendaciones de respaldo y temas de seguridad, son
tratados en el capítulo 6.
Finalmente, en el capítulo 7 se entregan las conclusiones y resultados obtenidos del
trabajo. Además se exponen observaciones y recomendaciones para la realización de
desarrollos futuros.
10
Capítulo 2: Estado del arte
2.1 Sistemas existentes
Si bien existen sistemas que colaboran en el ámbito educativo a la gestión de notas de los
estudiantes, no existe un sistema cuyas características sean similares a la aplicación
propuesta. En la etapa de investigación sobre el estado del arte, se encontró la aplicación
SchoolTrack1 que es un avanzado sistema de gestión académica, el cual permite reducir el
tiempo de procesos administrativos rutinarios, como transcribir calificaciones a libros de
clases, calcular promedios, copiar notas a las libretas de cada alumno, imprimir libretas de
calificaciones, generar automáticamente informes, entre otras cosas.
El Sistema de Información de Gestión Académica2 de la universidad, es otra aplicación e
integra a múltiples unidades de la estructura organizacional, al igual que el sistema
SchoolTrack antes mencionado.
Evidentemente, estas aplicaciones son bastante más complejas e involucran a muchas otras
áreas dentro de una organización educativa, pero no constituyen una solución adecuada
para el problema y realidad del departamento de Matemática, no obstante, estos sistemas
permiten proyectar este trabajo hacia una posible integración, ya que está enfocado a un
proceso complementario.
El Sistema de Información y Gestión de Evaluaciones (SGIE), es un proyecto totalmente
innovador y nace de la necesidad de realizar eficaz y eficientemente un proceso crítico
dentro del departamento de Matemática.
1 Para mayor información, visitar el sitio http://www.colegium.com/productos/schooltrack.html 2 Sistema de Información de Gestión Académica. Véase en http://www.siga.usm.cl/
2.2 Id
El pro
realiza
1.
2.
3.
3 Dispo
dentificaci
oceso de co
ado manualm
Escáner OM
un archivo
Corrección
proporcion
evaluacion
con una pa
Cálculo de
cada evalu
correctas, o
ositivo reconoce
ión del Pro
orrección, c
mente cada v
Figura
MR3: El usu
o MS Excel.
n: El usuario
na MS Exce
nes digitaliza
auta para det
e Nota: Una
uación la no
omitidas, obj
edor de marcas
oblema
cálculo de n
vez que es ev
a 1: Descripció
uario digitali
o a través d
el, debe pro
adas, es dec
terminar las r
a vez finaliz
ota correspon
bjetadas y ma
s ópticas
notas y obt
valuado un c
ón del proceso
iza los certám
de las herra
ogramar un
cir, se compa
respuestas c
zada la corre
ndiente, de
alas.
tención de
curso. Este se
o de correcció
menes de lo
amientas y f
script que
ara cada pre
correctas.
ección, el us
acuerdo a l
gráficos inf
e detalla en
ón
os alumnos y
funciones de
corrija cad
egunta de un
suario debe
la cantidad
formativos
la figura 1:
y los exporta
e cálculo qu
da una de l
na evaluació
calcular pa
de respuest
11
es
a a
ue
as
ón
ara
as
12
4. Información Estadística: El usuario debe confeccionar gráficos y tablas de resumen
para cada paralelo o cualquier otra información relevante para la toma de
decisiones del departamento.
2.3 Conclusiones
Si bien, no se especificó el tiempo utilizado por el usuario en cada etapa, debido a que se
trata de una variable que depende de varios factores, entre los que se encuentran: cantidad
de alumnos que rindieron la evaluación, número de preguntas de la evaluación, cantidad de
paralelos del curso, ponderación de las respuestas correctas, omitidas, objetadas y malas en
la fórmula de la nota y la cantidad de información estadística que se desee obtener. Se
deduce que las horas hombre utilizadas, pueden disminuirse considerablemente con un
sistema fácil de usar que automatice este proceso, configurando adecuadamente los
parámetros de una evaluación particular.
Además, si la plataforma en la que se desarrolla la solución es adecuada, la información
obtenida por el sistema puede ser compartida a través de la red y proporcionar distintos
privilegios de accesos, permitiendo así la participación de todas las partes interesadas.
13
Capitulo 3: Propuesta
Se propone el desarrollo sobre una plataforma cliente-servidor, es decir, una aplicación
Web que permita el acceso a información que interesa a distintos actores. Esta debe
desplegar cuadros estadísticos y gráficos, y proveer funcionalidades que correspondan al
nivel de privilegios que tenga el usuario que accede a esta información.
Al existir distintos actores, con intereses y funciones totalmente distintas, esta solución
propone el desarrollo de distintos interfaces de usuarios, este enfoque contribuye así a un
desarrollo modular y que beneficiará futuras funcionalidades.
La importancia de seguir una metodología en el desarrollo de una aplicación radica en
lograr identificar tareas que sean sistemáticas, predecibles y repetibles, a fin de mejorar la
productividad en el desarrollo y la calidad del producto de software. A continuación se
detallan las características más relevantes del proyecto entre los que se encuentran
objetivos, principales funciones, arquitectura y tecnologías de desarrollo.
3.1 Objetivos
Los objetivos generales del proyecto son:
• Diseñar y desarrollar un producto de software que permita almacenar y procesar
las evaluaciones de los alumnos pertenecientes a un curso.
• Automatizar el proceso de corrección de una evaluación específica, de acuerdo a
una pauta y el conjunto de evaluaciones rendidas.
• Calcular las notas correspondiente de cada evaluación
• Entregar información resumen y detallada, a través de tablas y gráficos, respecto
de los resultados obtenidos en una evaluación según paralelo, campus o carrera.
• Soportar distintos perfiles de usuarios y privilegios.
14
• Implementar un interfaz que despliegue los resultados obtenidos por un alumno a
lo largo de un curso, de forma personalizada.
3.2 Requerimientos
La extracción de requisitos y requerimientos constituye la primera etapa en el desarrollo de
la aplicación y proporcionan los objetivos principales que tiene el sistema. A continuación
se determinan los requerimientos funcionales y no funcionales que debe cumplir el
sistema.
3.2.1 Requerimientos funcionales
La tabla 1 corresponde a los requerimientos funcionales, es decir, procesos que deberá
cumplir el sistema.
Tabla 1: Requerimientos funcionales
Requerimiento Descripción Resumen por evaluación Consulta sobre los resultados generales obtenidos en
una evaluación específica de un curso. Resumen por paralelo, campus o carrera de una evaluación
Consulta sobre los resultados generales obtenidos por un paralelo, campus o carrera en una evaluación.
Detalle de inscritos y resultados Consulta acerca de los alumnos inscritos en un paralelo y sus respectivas respuestas en una evaluación.
Privilegios de acceso Se debe tener un control de acceso a la aplicación de acuerdo al perfil de cada usuario.
Exportar información Proveer la funcionalidad de exportar la información desplegada por el sistema a otro formato.
Información por alumno Consultar los resultados de un alumno durante el trascurso del curso, de forma personalizada.
Definir Curso Ingresar los cursos que serán dictados durante el período.
Definir Paralelo Ingresar los paralelos de cada curso creado para el período.
Asignación de paralelo a profesor Asignar los profesores encargados durante el período a un paralelo específico.
Crear Evaluación Administrar y configurar las evaluaciones a través de un interfaz fácil de usar.
15
Cálculo de Nota Ingresar y administrar la fórmula de cálculo de nota para cada evaluación.
3.2.2 Requerimientos no funcionales
Corresponde a los requerimientos visibles para el usuario, que no representan una
funcionalidad, pero sí un requisito que debe cumplir la aplicación, se describen en la tabla
2.
Tabla 2: Requerimientos no funcionales
Requerimiento Descripción Ingresar Alumnos Poblar la base de datos desde un archivo con información de
los alumnos. Ingresar Inscritos Ingresar desde archivo la información de los alumnos
inscritos en un paralelo de un curso. Ingresar Evaluaciones Ingresar desde archivo las respuestas de los alumnos para una
evaluación específica. Motor de corrección Determinar respecto de una pauta las respuestas correctas e
incorrectas de las evaluaciones. Motor de cálculo de nota Calcular en base a los parámetros entregados por el
administrador las notas obtenidas en cada evaluación. Considerar volumen de transacciones
En procesos masivos se debe considerar métodos que hagan eficiente procesos con gran cantidad de datos.
Ca
4.1 MEl mo
sistem
emple
N° 1 U2 P
3 A
4 C
pitulo
Modelo de odelo de dat
ma y las rela
a el sistema
Tabla Usuario Profesor
Admin
Campus
o 4: Di
datos tos correspo
aciones que
y las relacio
F
Tabla 3: D
ContEs uespeEs uexcluContCasa
iseño
onde a una
existen ent
ones.
Figura 2: Mod
Descripción d
tiene la inforuna extensiócífica del pruna extensióusiva del admtiene los daa Central)
definición a
tre ellos. La
delo de datos p
e las tablas de
Drmación de lón de la ta
rofesor ón de la taministradortos relacion
abstracta de
a figura 2 r
propuesto
el Modelo de d
Descripciónlos usuarios abla Usuari
abla Usuari
nados con lo
e los datos
representa el
datos
que accedenio, contiene
io, contiene
os campus. (
que utiliza
l modelo qu
n al sistemae informació
e informació
(Ej: Santiag
16
el
ue
ón
ón
go,
17
5 Curso Estructura de almacenamiento para los distintos cursos que maneja el sistema. (Ej: MAT021 2010-1)
6 Perfil Define la estructura para ingresar el grado de responsabilidad que tiene un profesor respecto del curso. (Ej: Coordinador, Coordinador docente)
7 Asignación Define el esqueleto para relacionar a un profesor con un paralelo
8 Paralelo Estructura que almacena los paralelos correspondientes a un curso
9 Certamen Almacena la configuración e información de una evaluación para el curso específico
10 Pauta Define la estructura para almacenar cada pregunta y su respectiva respuesta de una evaluación
11 TipoProfesor Especifica el rol que cumple el profesor en el paralelo
12 EstadoInscripcion Estructura que almacena los estados de una inscripción. (Ej: inscrito, des inscrito)
13 Inscripcion Relaciona a un alumno con un paralelo y su respectivo estado. 14 Evaluacion Define la estructura de almacenamiento de las evaluaciones
rendidas por un alumno. 15 Carrera Estructura que almacena la información de las carreras de un
campus 16 Alumno Estructura que almacena toda la información de los alumnos (Ej:
nombres, rol, rut, apellidos, etc.) 17 Respuesta Almacena las preguntas y respuestas de una evaluación rendida
por un alumno. 18 Sesiones Mantiene un registro de todos los accesos que ha tenido el
sistema desde los interfaces de usuario
4.2 Especificación
Corresponde al comportamiento esperado que debe tener el software una vez desarrollado.
Es una etapa crítica debido a que el éxito del proyecto radicará en la identificación de las
necesidades del negocio y de la identificación, recolección, clasificación, priorización y
especificación de las actividades de los usuarios que utilizarán el sistema.
4.2.1 Perfiles de usuario
Se identifican 3 tipos de usuarios principales que se muestran en la figura 3. El profesor
tiene sub categorías que le dan mayores privilegios dentro del sistema.
Los pr
Prof
Coo
Coo
Alu
Adm
rivilegios de
Usuarifesor
ordinador
ordinador Do
umno
ministrador
Fig
cada usuari
Tabla 4
o
ocente
gura 3: Defini
o se describ
4: Descripción
Podrá revisestá asignadPodrá revisatenga asigna
Podrá revisencuentran eSólo tiene evaluacioneSe encargarDebe ingrealumnos, pr
ición de tipos d
en en la tabl
n de los privile
ar los resuldo durante elar los resultado y sea res
sar toda la ien el sistemapermisos de
es que ha renrá de la gestesar al sisterofesores, cu
de usuarios
la 4.
egios de usuari
Descripciónltados de lol período. tados de los sponsable du
informacióna. e visualizar
ndido. tión del sisteema toda l
ursos, paralel
ios
os paralelos
paralelos y urante el per
n de los cur
r los resulta
ema y la basla informacilos y evaluac
en los que
cursos que ríodo.
rsos que se
ados de las
se de datos. ión de los ciones.
18
4.3 CCorres
diferen
primar
sistem
funcio
4.3.1 C
La figu
4.3.2 C
Descri
aquell
Casos de ussponden a u
ntes actores
rios son aqu
ma, mientras
one normalm
Casos de us
ura 4 describ
Tab
Caso de UsActores: Propósito: Resumen:
Tipo
Casos de us
ibe las inter
as de tipo pr
so una definició
s. Existen c
uellos que re
que los cas
mente.
o del Alumn
be las accion
Figu
bla 5: Descrip
so: ConsAlumVisuaEl uslos rhoja
Prima
o del Profes
racciones qu
rimarias.
ón de las in
casos de uso
epresentan p
sos de uso
no
nes que pued
ura 4: Casos d
pción del caso
sulta sus resumno alizar la infosuario luego esultados obde respuesta
ario
sor
ue el usuari
nteracciones
os primario
procesos del
secundarios
de realizar el
de uso del usu
de uso, alumn
ultados
ormación de de identificabtenidos en as correspond
io profesor
desarrollad
os y secund
l negocio y
s son necesa
l alumno en
uario alumno
no consulta su
su (s) evaluarse en el si su evaluacdiente.
tiene con e
das entre el
darios. Los
son fundam
arios para q
el sistema.
us resultados
uación (es) stema, consu
ción y desca
el sistema y
sistema y lo
casos de us
mentales en
que el sistem
ulta por arga su
se describe
19
os
so
el
ma
en
T
Caso de UsActores: Propósito: Resumen:
Tipo
Ta
Caso de UsActores: Propósito: Resumen:
Tipo
Tabla 8
Caso de UsActores: Propósito:
Figu
abla 6: Descri
so: SelecProfeSelecEl usde lavisuaPrima
bla 7: Descrip
so: SelecProfeSelecEl usde evPrima
: Descripción
so: Ver rProfeSelec
ura 5: Casos d
ipción del caso
ccionar cursoesor cciona el cursuario luegoa lista, segalizar los resuario
pción del caso
ccionar evaluesor cciona la evasuario luego valuaciones, ario
del caso de us
resultados deesor cciona las vi
de uso del usua
o de uso, profe
o
rso para su vo de identificgún sus privultados.
de uso, profes
uación
aluación parade seleccionaquella que
so, profesor vi
e paralelo
stas disponib
ario profesor
esor seleccion
visualizacióncarse en el vilegios, el
sor selecciona
a su visualiznar un cursodesee visua
isualiza result
bles acerca d
na un curso
n sistema, sell curso que
a evaluación
zación o, escoge dealizar.
tados de paral
de resultados
ecciona e desea
la lista
lelo
s
20
4.3.3 C
Descri
aquell
Resumen:
Tipo
Casos de us
ibe las accio
as de tipo pr
Ta
Caso de UsActores: Propósito: Resumen:
Tipo
Tabla
Caso de UsActores:
El usde laaquélPrima
o del Admin
ones que el
rimarias.
Fig
abla 9: Descri
so: CrearAdmCrearEl usserá aPrima
10: Descripci
so: IngreAdm
suario luegoa lista de pal que desee vario
nistrador
administrad
gura 6: Casos
ipción del caso
r cursos ministrador
r un nuevo csuario crea uadministradoario
ón del caso de
esar inscripciministrador
de seleccioaralelos dispver los result
dor puede r
de uso del adm
o de uso, admi
curso para eluno o máso a través de
e uso, adminis
iones
onar una evaponibles segtados obteni
realizar en e
ministrador
inistrador cre
l período o secursos para
el sistema.
strador ingres
aluación, escgún sus prividos.
el sistema y
ea un curso
emestre. el semestre
sa inscripcione
coge de vilegios,
y se describe
e y que
es
21
en
22
Propósito: Ingresar a los alumnos inscritos en un curso Resumen: El usuario ingresa por archivo o manualmente las
inscripciones de los alumnos para un curso y sus respectivos paralelos.
Tipo Primario
Tabla 11: Descripción del caso de uso, administrador crea una evaluación
Caso de Uso: Crear evaluación Actores: Administrador Propósito: Configura una evaluación Resumen: El usuario crea y configura una evaluación. Selecciona el
número de preguntas, fecha, define el nombre y tipo de evaluación, etc.
Tipo Primario
Tabla 12: Descripción del caso de uso, el administrador ingresa evaluaciones
Caso de Uso: Ingresar evaluaciones Actores: Administrador Propósito: Ingresar las evaluaciones digitalizadas Resumen: El usuario luego de seleccionar un curso y evaluación,
ingresa desde un archivo las evaluaciones digitalizadas de los alumnos.
Tipo Primario
Tabla 13: Descripción del caso de uso, administrador ingresa una pauta
Caso de Uso: Ingresar pauta Actores: Administrador Propósito: Ingresar pauta de la evaluación Resumen: El usuario luego de seleccionar la evaluación, ingresa la
pauta correspondiente. Tipo Primario
Tabla 14: Descripción del caso de uso, administrador ejecuta el proceso de corrección
Caso de Uso: Corregir evaluaciones Actores: Administrador
23
Propósito: Corrige las evaluaciones de un curso Resumen: El usuario luego de seleccionar la evaluación e ingresar la
pauta, gatilla el proceso de corrección que determina las buenas, malas, omitidas y objetadas, para cada evaluación rendida.
Tipo Primario
Tabla 15: Descripción del caso de uso, administrador calcula las notas
Caso de Uso: Calcular nota Actores: Administrador Propósito: Calcula la nota de la evaluación Resumen: El usuario luego de corregir, gatilla el proceso de cálculo
de nota previa configuración de las ponderaciones que tendrán las respuestas buenas, malas, omitidas y objetadas.
Tipo Primario
4.4 Arquitectura
Corresponde al diseño de la estructura del sistema. Consiste en una aplicación cliente-
servidor, cuya codificación es del tipo MVC4. Al identificarse 3 perfiles de usuarios, con
roles y acciones totalmente distintas, se define la construcción de interfaces de usuarios
para cada perfil. La ventaja principal de crear interfaces diferentes para cada perfil, radica
en la facilidad de desarrollar nuevas funcionalidades protegiendo los privilegios de accesos
y acciones.
4.4.1 Arquitectura cliente-servidor
La figura 7 muestra la configuración del sistema y las relaciones que existen entre las
tecnologías utilizadas.
4 El Modelo-Vista-Controlador es un patrón de diseño para el desarrollo de aplicaciones web que consiste en separar el código en 3 capas. Véase en http://www.symfony-project.org/jobeet/1_4/Doctrine/es/04
Los di
dispon
•
•
istintos usua
nibles, la des
Base de D
distintos m
realizar las
Procesos d
administra
Figura 7
arios del sist
scripción de
Datos: Es d
módulos acce
s transaccion
del sistema:
ador. Se encu
7: Arquitectur
ema necesita
los compon
donde se al
ederán a la m
nes con la ba
: Correspon
uentra el mot
ra cliente-serv
an de un clie
entes se desc
lmacenará t
misma por m
ase de datos.
de procesos
tor de correc
vidor del sistem
ente Web pa
cribe a conti
toda la info
medio de con
s críticos del
cción y el mo
ma
ara acceder a
inuación:
ormación de
nexiones PH
l sistema uti
otor de cálcu
a los módulo
el sistema, l
HP y SQL, pa
ilizados por
ulo de notas
24
os
los
ara
el
.
25
• Interface Administrador: Contiene el conjunto de módulos que permiten al
administrador gestionar el sistema en su totalidad. Cada módulo presta herramientas
para la creación, modificación y eliminación de datos.
• Interface Profesor: Incluye los módulos que permiten al profesor acceder a los
cursos y paralelos en los que tiene relación. El módulo de visualización posibilita
analizar los resultados de una evaluación a través de distintas vistas, es decir,
gráficos o tablas, en detalle o resumen. Además, el módulo exportación permite
almacenar localmente la información contenida en el sistema.
• Interface Alumno: Permite al alumno visualizar los resultados de las evaluaciones
rendidas.
4.4.2 Arquitectura MVC
Esta arquitectura de software o patrón de diseño Modelo-Vista-Controlador permite al
desarrollador separar los datos, el interfaz de usuario y la lógica de control en 3
componentes distintos.
• Modelo o Capa lógica del negocio: Accede a la capa de almacenamiento de datos y
define las reglas del negocio o funcionalidad del sistema, es decir, son clases
orientadas a la interacción con la base de datos.
• Vista o Capa de presentación: Muestra la información del modelo al usuario. Es el
diseño o interfaz de usuario.
• Controlador o Capa de datos: Gestiona las entradas del usuario y eventos del
sistema, es decir, donde se maneja el modelo y se invocan las vistas.
La ventaja principal de programar con este patrón de diseño radica en permitir integrar
fácilmente nuevas funcionalidades al sistema, sin afectarlo mayormente y reutilizando
código, debido al desarrollo modular y separación de las tecnologías utilizadas. Esta
disgre
interfa
totalid
El sigu
1. 2. 3. 4. 5.
4.5 T
El de
interpr
5 Mayo6 Sitio w
gación perm
az de usuari
dad.
uiente diagra
El usuario
El Control
El Modelo
Para la actu
El Control
Tecnología
esarrollo de
retado PHP
r información web oficial en h
mite simplific
io. En concl
ama de secu
Figu
gatilla el ev
ador recibe e
o (si es neces
ualización la
ador recibe e
s de progr
l sistema W
P6 debido a
en sitio http://whttp://www.ph
car una migr
lusión, ayud
encia expon
ura 8: Arquite
vento.
el evento y l
sario) llama a
a Vista pued
el control
ramación
Web se rea
a la gran c
www.symfonyhp.net/
ración del m
da a una ma
e la interacc
ectura de desa
lo traduce en
a la vista par
de solicitar da
aliza utiliza
cantidad de
-project.org/jo
motor de base
antención ef
ción entre los
arrollo MVC5
n una petició
ra su actuali
atos al mode
ando el len
e documenta
obeet/1_4/Doct
e de datos o
ficiente del s
s component
ón al Modelo
zación
elo.
nguaje de
ación, la p
trine/es/04
el cambio d
sistema en s
tes.
o.
programació
posibilidad d
26
del
su
ón
de
27
integración con distintas API, generosa biblioteca de funciones y flexibilidad en la
codificación que permite un desarrollo ágil y ordenado.
Para la capa de presentación del sistema, se utiliza lenguaje de marcado HTML por su
mantención simple y codificación clara. Para complementar se utiliza Javascript como
solución a la validación de datos y plantillas CSS para generar un interfaz que permita a los
usuarios una atractiva y fácil navegación. La generación de gráficos se realiza con la API
de GoogleChart7, debido a su fácil integración, utilización y gran abanico de gráficos.
Finalmente, como motor de base de datos se utiliza PostgreSQL8, ya que es un sistema de
gestión de base de datos relacional orientada a objetos, libre, en continua evolución,
confiable y gran cantidad de documentación.
4.6 Resumen de tecnologías
La tabla 16, resume las tecnologías utilizadas en las distintas partes del sistema:
Tabla 16: Resumen de tecnologías
Sistema Tecnología Almacenamiento PostgreSQL Procesamiento archivos de entrada PHP Motor de corrección y cálculo de notas PHP Interfaces de usuarios HTML / CSS Validación de datos Javascript / PHP Gráficos GoogleChart API
7 Para ver la API en detalle visitar http://code.google.com/intl/es-CL/apis/chart/ 8 Mayor información acerca del motor de base de datos Postgresql en http://www.postgresql.org/
28
Capítulo 5: Implementación
Considerando el diseño, es posible identificar aquellos procesos críticos del sistema y que
merecen ser detallados.
5.1 Procesos del sistema
El sistema debe realizar procesos que se repiten periódicamente, pero existen procesos que
requieren especial énfasis debido a que parte fundamental del éxito de la aplicación pasa
por la correcta operación de estos. Los módulos o motores más relevantes se exponen en
los siguientes puntos:
5.1.1 Motor de corrección
El motor de corrección se encarga de determinar para cada evaluación la calidad o
efectividad de una respuesta, es decir, decreta si una respuesta está correcta, mala, omitida
u objetada. Para determinar a cuál de los distintos casos corresponde, se debe tener
previamente una pauta de la evaluación para poder ser comparada.
La ejecución del motor requiere de los siguientes componentes:
• Existencia de una configuración de evaluación
• Presencia de una pauta para la configuración de evaluación
• Presencia de al menos una evaluación de alumno
Una vez cumplido los requisitos mencionados, es posible gatillar el proceso de corrección.
El diagrama de flujo puede ser apreciado en la figura siguiente:
29
Figura 9: Diagrama de flujo del motor de corrección
5.1.2 Motor de cálculo de nota
Este motor se encarga de valorar las evaluaciones a través de la asignación de una nota.
Las respuestas que componen una evaluación tienes 4 estados definidos por:
•
•
•
•
Los es
repres
La No
define
•
•
Buena: Co
evaluación
Mala: Cor
Omitida: C
Objetada:
cuya evalu
stados tienen
enta un ejem
ota máxima
en de la sigui
12 (BUEN
evaluación
es de 8,3.
1 (OMITI
omitida su
orresponde
n del desarro
rresponde a u
Corresponde
Correspond
uación del de
n un peso de
mplo de fórm
Figu
de una eva
iente forma:
NAS): Corr
n, por lo tant
IDAS): Def
ma 1 punto
a una respu
llo ha sido v
una respuest
e a una respu
de a una res
esarrollo ha s
entro de la f
mula para una
ura 10: Config
aluación es
responde a
o, el peso o
fine el peso
en la nota fin
uesta con e
validado.
ta con valor d
uesta cuyo v
spuesta con
sido invalida
fórmula que
a evaluación
guración de po
100 y la mí
l número t
valor que tie
que tiene u
nal.
el mismo va
distinto a la
alor es 0.
el mismo v
ado.
calcula la n
n:
onderaciones
ínima 0. Lo
total de pr
ene una resp
una respuest
alor que la
pauta.
valor que el
nota. La ima
os valores d
reguntas ef
puesta buena
ta omitida,
pauta y cu
de la pauta
agen siguien
el ejemplo
fectivas de
a en el ejemp
es decir, ca
30
uya
a y
nte
se
la
plo
ada
31
• 1 (OBJETADAS): Determina el peso que tiene una respuesta objetada. Al igual
que el caso anterior, ésta suma 1 punto en la nota final.
• 0 (MALAS): Las respuestas malas no suman puntaje.
Suponga para el ejemplo que una corrección determinó que una evaluación tuvo 5
respuestas buenas, 4 omitidas, 2 objetadas y 1 mala, la nota de tal evaluación es:
NOTA = 8,3 * 5 + 1 * 4 + 1 * 2 + 0 * 1 = 48
La ejecución del motor requiere de los siguientes componentes:
• El motor de corrección debió ser ejecutado de manera exitosa.
• Definir los pesos para cada uno de los 4 estados que puede adoptar una respuesta.
Una vez cumplido los requisitos mencionados, es posible gatillar el proceso de cálculo de
nota. El diagrama de flujo puede ser apreciado en la figura 11:
32
Figura 11: Diagrama de flujo del motor de cálculo de nota
5.1.3 Motor de lectura de datos desde archivo
La necesidad de poblar la base de datos con grandes volúmenes de datos, requiere de
funciones que aceleren el proceso.
33
El formato de archivo permitido por el sistema para realizar el poblamiento masivo de
datos es MS Excel97-2003 (*.xls). Se define este tipo de archivo debido a que la
información original viene desde otros sistemas en el mencionado formato. Para la lectura
y manejo de este tipo de archivos se integró la librería desarrollada en lenguaje PHP
llamada phpexcelreader.
El motor de lectura de datos desde archivo permite optimizar y automatizar las siguientes
tareas:
Tabla 17: Lista de tareas que requieren archivos debido al volumen de datos
Tarea Descripción Frecuencia Ingresar alumnos al sistema
Poblamiento de todos los alumnos que inscriben algún curso administrado a través del sistema
1 vez al año
Ingresar inscripciones a curso
Proceso que relaciona a las alumnos con un paralelo de un curso específico
1 vez al semestre por cada curso
Importar evaluaciones rendidas en un curso
Proceso que ingresar al sistema las evaluaciones rendidas por los alumnos y sus respectivas respuestas
Muchas veces en un semestre por cada curso
Importar apelaciones aceptadas en una evaluación
Actualiza las evaluaciones y respuestas con las apelaciones que han sido aceptadas
Muchas veces en un semestre por cada curso
Los requisitos para aquellas tareas que involucran a cursos o evaluaciones son:
• Existencia del curso de inscripción
• Presencia de los paralelos correspondientes al curso
• Presencia de una configuración de evaluación
Además, como método de validación de archivo, este debe cumplir con las siguientes
características.
• El archivo debe contener como nombre la cadena .xls
• Cada archivo debe cumplir con una cabecera específica
Las ca
Ingres
Ingres
ImporEvaluImpor
La figu
5.2 InUno d
diferen
interfa
gatilla
Los di
distrib
5.2.1 I
Corres
obteni
abeceras que
Tabla 1
Tarea sar Alumnos
sar Inscripci
rtar uaciones rtar Apelació
ura 12 mues
nterfaces dde los aspecto
ntes usuario
az sea claro
ado.
istintos inter
bución que ti
Interface de
sponde al in
idos en las ev
e deben tener
18: Cabeceras
s alumn
iones inscr1.xls
evalu
ón apela
stra un archiv
Figura
de presentos fundamen
os visualizar
o, simple y
rfaces se exp
iene en la pa
e Alumno
nterfaz más
valuaciones
r los archivo
s requeridas p
Ej. Nombrenos2010.xls
ripcionesMAs
uacionesC1_
acionesC1_M
vo tipo para
12: Ejemplo
tación ntales de la a
rán y admin
entregue l
ponen a con
antalla.
s simple y
rendidas.
os para cada
para la import
e Archivo s
AT021_2010-
_MAT022.xls
MAT022.xls
el caso ingr
de archivo tip
aplicación, lo
nistrarán la
a informaci
ntinuación, ju
provee una
tarea son:
tación de dato
RUT|DVPATER
RUT|DVPATERPSU|SIG
RUT|DV
RUT|D
resar inscripc
po y su cabece
o constituye
información
ión adecuad
unto con un
a vista al a
os desde archiv
CabeV|CARRERA|R
RNO|MATERNO
V|CARRERA|RRNO|MATERNOGLA|PARALEL
V|COD_CERT|
DV|PREGUNT
ciones.
ra
e el interfaz c
n. Es primo
da de acuer
na breve des
alumno de l
vo
ecera ROL|NOMBREO|ANOINGRE
ROL|NOMBREO|ANOINGRELO|VTR
COD_LIBRO
TA|RESULTA
con el cual lo
ordial, que
rdo al even
cripción de
los resultado
34
ES| ESO|PSU
ES| ESO|
ADO
os
el
nto
la
os
1.
2.
3. 4.
5.
5.2.2 I
El inte
una ev
Notas de lo
Resumen d
respectiva
Despliegue
El alumno
correspond
Muestra el
Interface de
erfaz del pro
valuación en
Figura
os certámene
de la cantida
Nota.
e de la Pauta
o puede vi
de a lo que e
l estado de co
e Profesor
ofesor prove
un paralelo
a 13: Descripc
es rendidos p
ad de respue
a y las respue
sualizar la
ntrega el sis
onexión, IP
ee las herram
.
ción del interfa
por el alumn
estas Buenas
estas del alu
hoja de re
tema como s
de conexión
mientas para
face del alumn
no.
s, Malas, Om
umno que se
espuestas di
sus respuest
n, fecha y ho
a que éste v
no
mitidas y Ob
ingresaron a
igitalizada
tas.
ora.
visualice los
bjetadas con
al sistema.
y verificar
resultados d
35
su
si
de
1.
2.
3.
4.
5.
5.2.3 I
Provee
usuari
Menú prin
que se pue
Menú secu
la evaluaci
Pantalla pr
realizadas.
Menú terc
provee la f
Muestra el
Interface de
e las accion
os, cursos, p
Figura
ncipal, se en
de acceder d
undario, se d
ión que se de
rincipal, se
iario, cambi
función de ex
l estado de co
e Administr
nes necesari
paralelos, var
a 14: Descripci
ncuentran las
desde cualqu
despliega cua
esea visualiz
despliega t
ia las vistas
xportación c
onexión, IP
rador
ias para la
riables del s
ión del interfa
s acciones g
uier punto de
ando es sele
zar.
toda la infor
(Tabla/Grá
como archivo
de conexión
administrac
istema, entre
ace del profeso
generales. Si
el sistema.
eccionado un
rmación rel
áfico) de la i
o MS Excel.
n, fecha y ho
ción general
e otros.
or
iempre está
n curso y los
lacionada a
información
.
ora.
l del sistem
visible por
s resultados
las peticion
n desplegada
ma, gestión d
36
lo
de
nes
a y
de
1.
2.
3.
5.3 C
El sist
ubicad
muestr
Menú prin
visible por
Pantalla pr
opción sele
Muestra el
Característ
tema se ha
do en el edi
ra las caracte
Figura 15
ncipal, se en
r lo que se pu
rincipal, se
eccionada en
l estado de co
ticas del se
instalado en
ificio F de
erísticas del
5: Descripción
ncuentran la
uede acceder
despliegan
n el menú pr
onexión, IP
ervidor
n el laborato
la Universid
servidor y l
del interface
as acciones
r desde cualq
todas las a
rincipal.
de conexión
orio de rede
dad Técnica
as versiones
del administr
generales d
quier punto
acciones dis
n, fecha y ho
es del depar
a Federico S
s de software
rador
del sistema.
del sistema.
sponibles de
ora.
rtamento de
Santa María
e instalados.
Siempre e
e acuerdo a
Matemática
a. La tabla 1
37
stá
la
as,
19
38
Tabla 19: Especificaciones del servidor
Hardware Software Modelo Dell PowerEdge R210 S.O. Debian Lenny 5.0.4 Xeon Processor 2.53 GHZ 8MB Caché, HT, Turbo.
Apache 2.2.9-10
8GB Memoria RAM Postgress 8,3 Tarjeta red Intel Gigabit ET Dual Port PHP 5.2.6-1 160 GB Disco Duro 1 500 GB Disco Duro 2
39
Capitulo 6: Verificaciones, validaciones y
recomendaciones
Con el fin de verificar y validar la correcta implementación del sistema propuesto, fue
necesario someterlo a una serie de test, tanto funcionales como de rendimiento, con el fin
de observar su comportamiento en condiciones normales de operación, buscar posibles
fallas y sugerir lineamientos generales para futuras implementaciones u optimizaciones.
6.1 Pruebas de funcionalidades
En primera instancia, fue necesario verificar y validar la aplicación implementada, esto es,
que el comportamiento del sistema desarrollado efectivamente realiza los procesos para los
cuales fue diseñado y que cumple con los requerimientos planteados al inicio de la fase de
desarrollo del producto. El procedimiento empleado y los resultados obtenidos se detallan
a continuación.
6.1.1 Prueba de funciones
Debido a la gran cantidad de funciones que el sistema incorpora, se realizaron pruebas por
cada una de éstas, a medida que eran implementadas en la etapa de desarrollo. Los
objetivos de estas pruebas consistieron en buscar errores en el código y verificar que los
registros en la base de datos correspondieran a los ingresados a través del interface de
usuario.
6.1.2 Pruebas de archivos de entrada
Como el sistema permite el poblamiento de la base de datos desde archivo, fue necesario
verificar y validar el archivo de entrada. Se confeccionaron distintos archivos con datos
válidos e inválidos para determinar los errores y efectos sobre el sistema. Estas pruebas
permitieron generar reglas para la validación de archivos, es decir, se definió que cada
40
archivo en su contenido debe contener como encabezado una estructura particular y como
nombre de archivo contener una cadena de caracteres específico.
6.1.3 Pruebas en motor de corrección y cálculo
Las funciones de corrección y cálculo corresponden a procesos críticos que merecen
especial atención y por ende, pruebas que garanticen la exactitud de los cómputos
realizados. La verificación y validación de ambas se realizaron tomando un conjunto de
2000 evaluaciones aproximadamente y comparando los resultados entregados por el
sistema con los realizados por medio del antiguo método, es decir, a través de la hoja de
cálculo de MS Excel. El procedimiento consistió en determinar la cantidad de preguntas
buenas, malas, omitidas y objetadas para cada evaluación, para posteriormente calcular la
nota correspondiente y finalmente obtener el promedio y desviación estándar del total de
las evaluaciones.
6.1.4 Pruebas de marcha blanca
El sistema permaneció el primer semestre del 2010 en marcha blanca. Estuvo bajo la
supervisión y operación de varios profesores y administradores de la red del departamento
de Matemática. El objetivo consistió en determinar errores funcionales o aspectos molestos
del interfaz gráfico.
6.2 Pruebas de rendimiento
Un aspecto esencial de una adecuada operación del sistema, radica en la velocidad de
respuesta que tiene ante una o varios solicitudes que involucran muchos datos. A
continuación se explican las pruebas de software y hardware realizadas.
6.2.1 Pruebas de software
Uno de los objetivos principales del sistema es la optimización del tiempo utilizado en el
proceso de corrección y cálculo de notas. En la tabla siguiente se muestra los tiempos de
procesamiento del sistema ante un cierto volumen de datos versus lo que demora un
operario realizando el mismo análisis.
41
Tabla 20: Tiempos de respuesta del sistema SGIE
N° de evaluaciones
N° de preguntas
T° de respuesta SGIE [s] T° aprox. Operario [s]
% Tiempo reducido
T° Corrección [s]
T° Cálculo de Nota [s]
2034 18 566,34 1,94 14400 96,06494 18 138,38 0,47 14400 99,03803 14 222,72 0,76 14400 98,45751 12 201,75 0,71 14400 98,59273 12 72,43 0,26 14400 99,49
Cabe mencionar que los gráficos y estadísticas de los resultados de un curso, se generan
instantáneamente cuando el usuario profesor navega a través del sistema, con un tiempo de
respuesta aproximado de 1 segundo.
6.2.2 Pruebas de hardware
La tabla 21 expone el uso de CPU y memoria RAM que utiliza el sistema al ejecutar el
proceso de corrección.
Tabla 21: Uso de CPU y RAM de SGIE
N° de Procesos en paralelo
% CPU % Memoria
1 31,2 1,3 2 88,4 2,6 3 93,7 4,1
El sistema fue estresado por medio de la ejecución de varios procesos de corrección en
paralelo, los resultados obtenidos se observan en la tabla 21. Si bien, corregir las
evaluaciones es habitual, no necesariamente es un proceso que deba realizarse
paralelamente a otro, no obstante la aplicación lo realiza, si bien, con un alto consumo de
CPU, los tiempos de entrega de información son en promedio 25 segundos por sobre los
entregados en la tabla 20 según el volumen de datos, lo que supone un bajo costo en
tiempo.
42
Además, los tiempos de UPTIME y DOWNTIME se muestran en la tabla 22, junto a la
causa que significó la falla.
Tabla 22: Tiempo de UPTIME del Servidor
Servidor UPTIME [días] DOWNTIME [días] Causa
260 2 Falla de Hardware 1 Falla del sistema eléctrico
6.3 Recomendaciones de respaldo
Se sugiere realizar las siguientes prácticas para mantener el sistema de datos y hardware
respaldado ante cualquier evento, sea este fortuito o premeditado.
• Realizar un respaldo de la base de datos por cada evaluación que se ingrese al
sistema, con el fin de mantener las últimas transacciones hechas.
• Respaldar el archivo de respaldo en otro equipo físico, que contenga como mínimo,
las mismas medidas de acceso y seguridad que el servidor en donde se encuentra
instalado el sistema.
• Tener previamente configurado un segundo servidor con la misma configuración de
servicios que el de producción, para el caso en que éste falle.
6.4 Recomendaciones de seguridad
El sistema tiene incorporado un módulo de privilegios de usuarios y actualmente tienen
configuraciones estrictas de acceso a la base de datos y al servidor. Se recomienda ser
cuidadoso en los siguientes puntos:
• Planificar adecuadamente posibles nuevos accesos a la base de datos y privilegios
de usuario.
43
• Mantener un registro de que usuarios tienen acceso a los servidores de interés.
• Conservar las claves de acceso en un lugar seguro.
• Para el caso de nuevos desarrollos, se debe identificar a aquellos usuarios que
utilizarán las nuevas funciones y si los privilegios que tienen son acordes a la
implementación.
• Mantener un acceso restringido desde redes externas o ajenas de los servidores y
servicios que éstos proveen.
44
Capitulo 7: Conclusiones
Dado los resultados obtenidos en el diseño, implementación y tiempo que ha estado en
producción el sistema, es posible concluir, que es factible la puesta en marcha de un
sistema que cumpla con los requerimientos propuesto al principio del proyecto. Así
mismo, es posible afirmar que la aplicación es estable, flexible y escalable en el tiempo a
nuevas funcionalidades.
El sistema ha sido una solución tecnológica que puede generar un salto cualitativo en lo
que a gestión de notas se refiere, no solo a nivel departamental, si no que de toda una
Universidad.
La descomposición del sistema en módulos, permite la integración de nuevas
funcionalidades, incentivando a futuros desarrolladores realizar aportes que signifiquen
enriquecer una aplicación emergente que puede generar mayores y mejores prestaciones.
En cuanto a los tiempos utilizados en el proceso de corrección y cálculo de notas antes del
proyecto, la aplicación ha demostrado ser una solución real en la optimización de este.
Disminuyendo por sobre el 90%, el tiempo utilizado de forma manual por un operario.
Esto sin considerar que los tiempos de entrega de información son instantáneos, debido a
que se trata de una aplicación Web que se encuentra disponible en la red en todo momento
y para cualquier usuario que tenga autorización y acceso a éste.
El sistema cumple cabalmente con los objetivos propuestos. Permite gestionar un curso y
las evaluaciones que son realizadas en el. Además, automatiza la inscripción de alumnos
en los respectivos paralelos y la corrección con su respectivo cálculo de nota de las
evaluaciones que éstos realizan. Finalmente, proporciona resúmenes estadísticos y los
presente a través de tablas y gráficos a los usuarios con privilegios.
45
7.1 Trabajos futuros
El sistema es la base para futuros desarrollos que proporcionen un mayor valor a la
aplicación, generando nuevos despliegues de información que no fueron considerados en
los alcances del proyecto en su inicio. A continuación se exponen futuras mejoras que
pueden ser implementadas.
• Desarrollar un módulo de seguridad que garantice la integridad de los datos
procesados, es decir, utilizar un método que detecte si una nota ha sido alterada
ilícitamente y cuál (es) fueron.
• Generar pruebas que detecten vulnerabilidades que pueda tener el sistema y
solucionarlos para evitar accesos no autorizados.
• Desarrollar un módulo que relacione una pregunta con una materia, permitiendo
generar nuevas estadísticas que provean a un profesor visualizar de forma clara el
rendimiento de una evaluación en una materia específica.
46
Glosario
API: Interfaz de programación de aplicaciones (Application Programming Interface).
CSS: Hojas de estilo en cascada (Cascading Style Sheets).
CPU: Unidad central de procesamiento (Central processing unit)
DOWNTIME: Tiempo que ha estado no disponible un servidor.
GoogleChart API: Sistema generador de gráficos mediante peticiones http.
HTML: Lenguaje de marcado de Hipertexto.
HTTP: Protocolo de transferencia de Hipertexto (Hypertext Transfer Protocol).
Javascript: Lenguaje de scripting orientado a objetos.
MS Excel: Hoja de cálculo de Microsoft Office.
OMR: Reconocedor de marcas ópticas (optical mark recognition).
PHP: Lenguaje de programación interpretado.
PostgreSQL: Sistema de gestión de base de datos relacional orientada a objetos
Producto de Software: Aplicación diseñada para un usuario.
RAM: Memoria de acceso aleatorio (Random-access memory)
Sitio WEB: Colección de páginas web relacionadas por contenidos, imágenes, vídeos u
otros archivos digitales.
TIC: Tecnologías de la información y la comunicación.
UPTIME: Tiempo de funcionamiento sin interrupciones de un servidor.
47
Bibliografía
[1] Sistema de gestión académica, ShoolTrack
http://www.colegium.com/productos/schooltrack.html
[2] Sistema de información de gestión académica.
http://www.siga.usm.cl
[3] Manual en línea PHP
http://php.net/manual/es/index.php
[4] Documentación en línea PostgreSQL
http://www.postgresql.org/docs/manuals/
[5] CSS tutorial, Abril 2010
http://www.w3schools.com/css/
[6] Guía del desarrollador, API de Google Chart, Abril 2010
http://code.google.com/intl/es-CL/apis/chart/
[7] Wikipedia. Ingeniería de Software, Enero 2010
http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software
[8] Designs by Darren - Free CSS Website Templates
http://www.designsbydarren.com/
[9] Practical Symfony – Web PHP framework
http://www.symfony-project.org/jobeet/1_4/Propel/es/04
