SEP DGEST

INSTITUTO TECNOL

OGIO DE
ACAPULCO
APLICACI

ON DE EX

AMENES EN UN ENTORNO DE
SERVICIO WEB
PROPUESTA DE INVESTIGACI

ON
PRESENTADA POR:
ALVAREZ BASILIO AUGUSTO
GARCIA ARCETA C

ESAR ADRIAN
GUEVARA DOM

INGUEZ C

ESAR
VALLE TENANGO LUIS ANGEL
SILVA VASQUEZ PATSY KARIME
ASESORA: DRA. M

IRIAM MART

INEZ ARROYO
INGENIER

IA EN SISTEMAS COMPUTACIONALES
ACAPULCO GRO. A JUNIO DE 2014
Resumen
Este trabajo pretende realizar un sistema para aplicar ex amenes en una p agina Web, el
procedimiento se apoya con la implementacion de base de datos para obtener los datos
de los alumnos as como tambien los datos de los profesores, siendo estos los usuarios
principales. En resumen, el proyecto consiste basicamente en dos usuarios el usuario
alumno y el usurario maestro a ambos se le asigna una un usuario y una clave de acceso
para que puedan ingresar a la p agina, al maestro para poder dar de alta el emane y al
alumno para poder realizarlo, los datos se guardan en una base de datos para su uso
futuro.
Para el desarrollo de este proyecto tomamos en cuenta las competencias que conlle-
va la materia, como son las competencias de trabajo en equipo, que esta fue, para
nosotros, la que mas resalto ya que gracias al buen trabajo en equipo logramos el desa-
rrollo completo de dicho proyecto. Las capacidades de an alisis, sntesis y abstracci on
de cada integrante del equipo fueron fundamentales para la concretaci on de cada tema.
La creatividad es otro punto fuerte en el desarrollo de este proyecto, ya que gracias al
trabajo en equipo, se logro una idea unica y general de lo que se pretende realizar.
la propuesta que presentamos se considera un trabajo de investigacion poco te orica
y mas pr actica, lo que quiere decir que es un trabajo dirigido para proyectos de Resi-
dencias profesionales.
II
Abstract
This research tries to make a system for applying tests on one web page , the method
rests with the implementation of database data for students as well as teachers data ,
which are the main users. In summary, the project is basically two users the user and
the usurious student teacher is assigned a both a username and password so they can
access the page , the teacher to enlist the emanate and student to do so , the data is
saved in a database for future use .
For the development of this project we consider the skills involved in art, as are the
skills of teamwork, this was , for us , the one more bump and thanks to good teamwork
we achieved full development of the project. The skills of analysis, synthesis and abs-
traction of each team were instrumental in the concretization of each topic. Creativity
is another strong development point of this project , and thanks to teamwork , a unique
and generally what it is intended to achieve idea.
Our proposal is considered a little research theoretical and more practical , which means
it is a work directed to professionals Residential projects .
III

Indice general
Resume II
Abstract III
Lista de guras VI
Lista de tablas VII
1. Introducci on 1
1.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Planteamiento del problema . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4. Objetivos especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5. Justicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5.1. Analisis F.O.D.A. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.6. Alcances y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Marco te orico 7
2.1. Ingeniera de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. MVC: (Modelo Vista Controlador) . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2. MVC Y JAVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Server pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5.1. Ventajas Server pages . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Sistema de Gestion de Base de Datos (SGBD) . . . . . . . . . . . . . . 13
2.7. Discusi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Metodologa 15
4. Pruebas y resultados 25
IV
5. Cronograma de actividades 34
6. Lugar donde se desarrolla el proyecto 35
6.1. Macrolocalizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.2. Microlocalizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7. Conclusi on 38
8. Referencias 41
V

Indice de guras
3.1. Diagrama de ujo: parte 1 . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Diagrama de ujo: parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Diagrama de ujo: parte 2 . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4. Calidad de una aplicaci on web . . . . . . . . . . . . . . . . . . . . . . . 18
3.5. Fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6. Fases del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.7. Benecios de recoleccion de datos . . . . . . . . . . . . . . . . . . . . . 23
3.8. Recolecci on de los datos . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.1. Prueba de contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2. Prueba de contenido de la base de datos . . . . . . . . . . . . . . . . . 27
4.3. Cargar examen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4. Resultados para el maestro . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5. Prueba de contenido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Cronograma de actividades . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.1. Macrolocalizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2. Microlocalizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
VI

Indice de cuadros
1.2. Cuadro: Analisis FODA . . . . . . . . . . . . . . . . . . . . . . . . . . 5
VII
Captulo 1
Introducci on
En la actualidad decenas de instituciones tanto p ublicas como privadas estan desarro-
llando y ofreciendo programas de educaci on virtual. La incorporacion de las tecnologas
de informaci on y comunicacion en el ambito academico ha trado consigo no s olo el
dar soporte a las actividades curriculares y de investigaci on, sino que ha propiciado el
intercambio de informaci on entre alumnos y docentes de una manera din amica a traves
de la Red, lo que ha dado origen al establecimiento de nuevos ambientes de aprendizaje
basado en el uso de Internet como medio difusor de conocimientos.
Este proyecto consiste en un sistema que sea casi totalmente automatizado en el senti-
do de que si el docente desea cambiar las preguntas no tenga que ser un experto en el
area de computacion, s olo necesitara capturar o cargar un archivo y enviarlo al sistema,
de manera que dicho sistema pueda interpretarlo y guardar la serie de preguntas con
sus respectivas respuestas en una base de datos, desde la cual este mismo generara los
ex amenes.
El objetivo es que el sistema que se encargue de evaluar el desempe no academico de
alumnos que esten cursando cierta materia a traves del ambiente Web. Esto se logra en
base a una serie de preguntas que el profesor proporcionara al sistema, suponiendo que
se cuente con la lista de los alumnos inscritos en el curso, por otro lado, se obtendra un
control de las evaluaciones aplicadas y la calicaci on obtenida por cada estudiante, todo
esto a traves del sistema.
1
1.1. Antecedentes
Actualmente el Instituto Tecnol ogico de Acapulco no cuenta con un sistema de evalua-
ci on automatica en lnea de tal manera que lo que pretende este proyecto es ofrecerles
a los alumnos y profesores una manera distinta y mas viable creando un sitio web en
cual al usuario alumno se le proporcionara una clave de acceso para poder responder
su examen que sera asignado por el profesor de cada materia, el cual tambien se le
proporcionara una clave de acceso para poder dar de alta sus examenes.
Hay varios proyectos en la web que se asemejan al nuestro pero la cuesti on es inno-
var, la idea de la integracion de estos ex amenes en el instituto es que el sea de los
primeros en utilizar dicha herramienta de evaluaci on.
1.2. Planteamiento del problema
En algunos casos, el tiempo con el que cuenta cada profesor no es suciente para aplicar
ex amenes, evaluarlos y adem as revisar tareas (proyectos, investigaciones, etc.). Por esta
raz on es indispensable una herramienta de apoyo con la cual el profesor pueda ahorrar
tiempo y pueda calicar puntos que por la relevancia que tengan dentro del curso no
sean calicados ya que el conocimiento se puede ver reejado de otra manera (hablando
de un curso muy pr actico).
Por otro lado, tenemos un grado de desconanza para aplicar examenes va Web. Debi-
do a que no existe manera de garantizar que los alumnos no esten resolviendo el examen
de manera conjunta (copiando), o que guarden en un archivo las preguntas que se les
presenten con el n de ayudar a otros alumnos que tomar an dicho examen.
Por todo lo anterior se entiende que las calicaciones que obtengan los alumnos en
dicho sistema tendra un valor dentro del curso denido por el docente que decida utili-
zarlo, debido a que el sistema s olo buscar a aplicar de manera transparente a los alumnos
diferentes ex amenes y que el profesor obtenga los resultados de dichos ex amenes para
poder llevar un control de cada alumno dentro de un curso.
2
1.3. Objetivo general
Desarrollar un sistema f acil de utilizar para aplicacion de ex amenes va internet me-
diante la implementaci on de una interfaz gr aca para el sistema en general (uso de
colores y ubicaci on de opciones) y as mismo, desarrollar un sistema que sea de apoyo
a los profesores para la evaluacion de sus alumnos.
1.4. Objetivos especcos
Cambiar la forma de evaluacion de examenes en la instituci on, permitiendo ser
una universidad innovadora.
Generar examenes diferentes para cada alumno.
Dar tiempos adecuados para la realizacion de los examenes para evitar conictos.
Desarrollar una aplicacion que permita:
1.- Ahorrar tiempo que utilizan los profesores calicando ex amenes en hojas
de papel.
2.- Que los profesores puedan cambiar las preguntas de manera sencilla y sin
tener demasiado conocimiento en el area de computacion.
1.5. Justicaci on
Los principales benecios son para el profesor, ya que el sistema pretende que el maestro
no calique los ex amenes de forma manual, si no que esto se realice automaticamente
cuando el alumno termine el examen y lo guarde, de esta manera el maestro en su papel
de administrador, mediante un par de opciones visualiza los resultados de los alumnos
que realizaron el examen. Los benecios para el alumno son un poco distintos que los
del maestro, en este caso el alumno solo puede realizar el examen que el maestro selec-
cione y en el tiempo que este disponible dicho examen, con la satisfacci on que lo puede
realizar desde su casa.
Hablando especcamente del sistema, este pretende ser exible, util, agradable y f acil
de utilizar.
Flexible porque permie al profesor editar sus propias preguntas en base al ritmo del
curso y lo visto en clase, al alumno le da la opci on de aplicar el examen de manera
remota sin tener que estar necesariamente en el aula.
Es util para el profesor porque por un lado, este no necesita emplear tiempo para
3
imprimir en papel sus ex amenes con el riesgo de que no lleve el n umero necesario de
ex amenes, y por el otro lado tampoco es indispensable que tenga que estar presente en
la aplicacion de dichos examenes.
Se puede decir que es agradable porque pretende evitar que el usuario se pierda en
un mar de opciones ya que se busca mayor nivel de simplicidad en la interfaz, ademas
de que el sistema pretende ser lo mas claro posible con los usuarios para que este en-
tienda lo que se esta realizando.
Se puede considerar facil de usar en base a el dise no que se tienen contemplado se-
guir de tal manera que cualquiera de estos usuarios no se encontrase en una situaci on
incomoda o poco entendible.
Por ultimo, la creacion de este tipo de sistema obedece a la necesidad de utilizar un es-
quema basado en un ambiente Web Service. Esto para lograr tener un proceso din amico
el cual puede ser creado con tecnologa, tal como, JSPs, Servlets y Bases de datos. Por
otro lado se tiene que mediante el uso de estas tecnologas se puede asegurar mayor
seguridad en cuanto a la manipulaci on de datos, evitando inconsistencias (por ejemplo,
a traves de la base de datos).
1.5.1. Analisis F.O.D.A.
El an alisis F.O.D.A. nos ha permitido evaluar las diferentes posiciones y puntos de vista
de nuestro proyecto, en el cual nos hemos dado cuenta que de que nuestras fortalezas
son mayores a las debilidades o amenazas, en todo proyecto hay puntos positivos y
negativos, pero para saber si un proyecto puede favorecer o tener impacto social es
necesario evaluar cada una de estos puntos para saber que es factible implementarlo o
llevarlo acabo.
Los puntos positivos de este proyecto pueden llegar a ser motivo para ser implemen-
tados en diferentes tipos de instituciones y de diferente, ya que seria una innovaci on
que cambiara formas de evaluar y formas en que los alumnos se prepararan evitando
copias o posibles acciones que no sean correctas para un alumno.
Con respecto a las debilidades se pueden implementar sistemas de seguridad para que
nuestras amenazas y debilidades se conviertan en factores positivos para nuestro siste-
ma en general.
4
Fortalezas Debilidades
-No hay perdida de datos. -Falta de capacitaci on.
-Base de datos eciente para el -Impresi on de pantallas.
control de los alumnos, maestros y -Si se va la luz o el internet, se
administradores. interrumpe el examen.
-No puede haber redundancia en las -Poca inversi on en publicidad.
evaluaciones. -Recursos informaticos obsoletos
-Reducci on de costos de impresi on. (computadoras antiguas, software
-Resultados de evaluaci on en el sin actualizar, etc).
menor tiempo posible. -Para el mantenimiento de la pagina
se tiene que deshabilitar el servidor.
-Procesos tecnicos y administrativos
de calidad.
-Facilita la comunicacion del estu-
diante mediante foros, chat y correo
personal.
Oportunidades Amenazas
-Innovacion. -Suplantaci on.
-Competencia debil. -Manipulaci on de datos.
-Nuevas areas de trabajo. -Alteraci on de datos.
-El alumno puede realizar su -Denegaci on del servicio.
evaluacion en cualquier lugar que se
encuentre.
-Falla de conexi on.
-Implementaci on en distintas insti-
tuciones.
-Se cuenta con docentes actualizados
en el ambito de la tecnologa.
Cuadro 1.2: Tabla que en conclusi on muestra el FODA del sistema en general
5
1.6. Alcances y limitaciones
Alcances
Implementar un sitio web que permita realizar evaluaciones a los alumnos de las dife-
rentes carreras del instituto tecnol ogico. El aula virtual debe permitir a los estudiantes
ya matriculados en la instituci on interactuar con sus profesores mediante la realizacion
de preguntas y respuestas a traves del internet.
Sitio web: se deber a mostrar todas las preguntas para la realizaci on de los ex amenes de
las diferentes carreras y materias.
Ciencias basicas
Sistemas
Electromec anica
Bioqumica
Arquitectura
Se tendra una secci on donde se mostrara un formulario en el cual el usuario pueda
ponerse en contacto con un directivo de la instituci on.
Limitaciones:
El sitio web de la institucion tendr a como lmite de desarrollo los siguientes puntos:
No incluye alta en buscadores
No incluye herramientas y tecnicas de posicionamiento en buscadores
El aula virtual incluye la instalacion conguraci on y dise no.
El servidor que albergara la base de datos del sistema deber a permanecer conectado a
Internet las 24 horas, puesto que este host ser a quien atienda las peticiones de lectura
y escritura de los usuarios que accedan al internet.
6
Captulo 2
Marco teorico
Antes de entrar en detalle en cuestiones tecnicas hay que describir brevemente los termi-
nos que se utilizar an a lo largo de este documento comenzando por la Web continuando
con Ingeniera de Software, patr on de dise no MVC, tecnologa JSP / Servlet y nal-
mente con la denici on de Base de Datos.
Respecto a los trabajos relacionados con nuestro proyecto, estos trabajan bajo los mo-
delos de vistas (MVC: modelo vista controlador). Los ex amenes en lnea realizados en
la UNAM por la facultad de medicina son almacenados en una base de datos realizada
en PostgreSQL, esto debido a que este programa de bases de datos tiene un uso amplio
en las distintas modalidades de conexion de base de datos con el lenguaje de programa-
ci on PHP, siendo este lenguaje utilizado para la creaci on de la aplicaci on que maneja
la aplicacion de los ex amenes en lnea.
Dicho programa de aplicaci on de ex amenes consta de cuatro ventanas o paginas prin-
cipales:
La primera de ellas es la de introducci on de contrase na, la cual registra el nombre
del usuario y la contrase na del alumno.
La segunda es la de validaci on de contrase na, donde si es v alida la contrase na se
despliega los datos del alumno.
La tercera es unndice y un mapa del examen que contiene el n umero de problemas
a resolver.
La cuarta muestra en pantalla el problema que se esta resolviendo as como las
ayudas correspondientes antes previsto.
Estas acciones permiten mejorar el proceso de seleccion, ya que a traves del uso y la
puesta en marcha de las nuevas Tecnologas de la Informaci on y la Comunicaci on, per-
miten que las universidades brinden un servicio de calidad para la poblacion. En un
7
examen en lnea, los sustentantes siguen un proceso similar al que utilizan en un examen
en papel, pero emplean la computadora para ejecutar distintas tareas:
Revisan las preguntas del examen en la pantalla de una computadora en vez de en-
contrarlas impresas en un cuadernillo.
Para contestarlas, seleccionan la opci on correcta con el rat on de la computadora en
lugar de llenar ovalos con l apiz.
En toda aplicaci on de ex amenes en lnea, ademas de las acciones que com unmente
realiza el aplicador, tambien es necesario ejecutar tareas tecnicas previas, orientadas a
garantizar que los equipos cumplan con los requerimientos mnimos especicados para
el Sistema de ex amenes en lnea.
Se presenta la informaci on necesaria para los dos tipos de funciones que deben lle-
varse a cabo en un centro de aplicaci on de ex amenes en lnea:
Soporte tecnico: Estan relacionadas con la preparaci on de la infraestructura tec-
nol ogica.
Aplicador: Se orientan hacia la logstica de la aplicacion y la atenci on al usuario du-
rante esta.
Estas dos funciones pueden ser desarrolladas por dos personas distintas o por el mismo
individuo.
Un ejemplo a gran escala de ex amenes en lnea, son los que realiza Microsoft para
la certicaci on de sus programas de paquetera de Microsoft oce. La certicaci on de
Microsoft se realiza en un programa llamado iQsystem, el cual incorpora una serie de
ex amenes que al abrirlos nos despliega el tipo de examen a realizar, ya sea de Oce
Word, Power Point, Exel, etc.
Dicho programa nos brinda cierto tiempo para la realizacion de un examen, esto para
que el que lo realiza lo haga con tiempo y forma y por decirlo as, no hacer trampa.
Al terminar el examen nos arroja un resultado con la calicaci on obtenida y nos da
un documento validado para que con el podamos exigir nuestro certicado directo de
Microsoft.
Todo estos artculos o proyectos, tiene en com un que usan el modelo de vista y control
para desarrollar un software que el usuario pueda utilizar sin problema alguno y de esta
manera uno como administrador de dicho software poder manipular las entradas a la
aplicaci on.
MVC es un patr on de dise no utilizado para proveer una solucion al problema de recu-
8
rrencia de funciones, es decir, se separan los componentes por dos razones principales;
primero ahorrar lneas de c odigo permitiendo recurrencia de ciertas funciones y segundo
que si alg un componente de la aplicacion cambia no afecte a la estructura general del
sistema.
B asicamente el MVC es:
Modelo: Contiene el n ucleo de la funcionalidad (dominio) de la aplicacion. Encapsula
el estado de la aplicacion. No sabe nada / independiente del Controlador y la Vista.
Vista: Es la presentacion del Modelo. Puede acceder al Modelo pero nunca cambiar
su estado. Puede ser noticada cuando hay un cambio de estado en el Modelo.
Controlador: Reacciona a la petici on del Cliente, ejecutando la accion adecuada y crean-
do el modelo pertinente.
Asi tambien, utilizando algunas de ellas framework para aplicaciones java que imple-
menta el modelo MVC.
2.1. Ingeniera de software
La aplicaci on de un enfoque sistematico, disciplinado y cuanticable al desarrollo ope-
racional (funcionamiento) y mantenimiento del software; es decir, la aplicaci on de in-
geniera al software [3].
Ahora tenemos que entender el concepto de software ya que la denici on anterior gira
alrededor de esta palabra. Software es el conjunto de requerimientos operacionales,
especicaciones, c odigo, guas, manuales y documentaci on de mantenimiento de un sis-
tema basado en computadora [4]. A grandes rasgos la ingeniera de software se reere
al conjunto de operaciones (an alisis, dise no, desarrollo y pruebas) que se deben realizar
antes, durante el desarrollo y hasta la deliberaci on del software [3].
2.2. MVC: (Modelo Vista Controlador)
Como describe el termino Patron de Dise no no es nada nuevo, s olo hoy en da esta sien-
do utilizado de manera mas com un, ya que un patron de dise no no es exclusivo del
desarrollo de software debido a que se puede aplicar a cualquier area que involucre la
tarea de dise nar. Por otro lado MVC es un patron de dise no utilizado para proveer una
soluci on al problema de recurrencia de funciones, es decir, se separan los componentes
por dos razones principales; primero ahorrar lneas de codigo permitiendo recurrencia
de ciertas funciones y segundo que si alg un componente de la aplicacion cambia no
9
afecte a la estructura general del sistema [5].
Un patr on de dise no se puede decir que es independiente del lenguaje de programa-
ci on que se desee utilizar, pero es aplicable a diversos dominios de problema, pero
semejantes desde el punto de vista de la estructura l ogica de la soluci on, es decir, uti-
liza principios de dise no orientado a objetos. Teniendo esto en consideraci on entonces
un patron es una estructura com un que tienen diferentes aplicaciones y/u objetos [5].
El Modelo Vista Controlador (MVC), es a grandes rasgos:
a)El Modelo es todo acceso a Base de Datos, y funciones que controlan la integri-
dad de los datos y una peque na l ogica de negocio.
b)La Vista es la cara de la aplicaci on, la presentaci on visual de los datos, o la transfor-
maci on de la misma.
c)El Controlador, a simple vista el Modelo o acceso a datos y la Vista o capa de pre-
sentaci on requieren un eslabon que parece perdido, pues el controlador se encarga de
esta necesaria funci on, enlazar el acceso a datos con la presentacion de los mismos [5].
Para el caso m as especco en la web tenemos un modelo muy conocido por todos,
aquel que separa la presentacion del acceso a datos, en una aplicacion Web en Java
(JSP para este caso), tenemos que procesar muchas peticiones y enviar la misma can-
tidad de respuestas, hacen que la p agina soporte demasiado trabajo, para el cual no
est a dise nada, de igual manera al usarse scripting en su forma m as pura, hace que el
resultado sea totalmente desfavorable. La aplicaci on se hace cada vez m as lenta, con
cada peticion.En el caso del patr on MVC el procesamiento se lleva a cabo entre sus
tres componentes. El Controlador recibe una orden y decide quien la lleva a cabo en el
modelo. Una vez que el modelo (la l ogica de negocio) termina sus operaciones devuelve
el ujo vuelve al controlador y este enva el resultado a la vista o capa de presentacion
[4], [5].
El Controlador en cierta forma debe tener un registro de la relaci on entre ordenes
que le pueden llegar y la logica de negocio que le corresponde (es como una operadora
de telefono que recibe una peticion y une dos lneas).
MVC es un derivado de los modelos convencionales. Aprovecha muchas ideas expresa-
das y quiz as dejadas a medias. El acceso a la Base de Datos, puede seguir controlado
por un Bean o una clase java. El Modelo de petici on y respuesta al usuario sufre
una transformaci on, la Vista es en este caso quien se encarga de la respuesta al usuario
(JSPs), mientras que la sobrecarga de tareas, como procesar las peticiones y generar
datos de acuerdo a las mismas los realiza el Servlet, un componente medio, que act ua
de Controlador entre el modelado de los datos y la Vista [5].
10
2.2.1. Ventajas
Que ventajas obtenemos de este modelo? Una separaci on total entre l ogica de negocio
y presentacion. A esto se le pueden aplicar opciones como el multi-lenguaje, distintos
dise nos de presentacion, etc., sin alterar la l ogica de negocio. La separacion de capas
como presentaci on, l ogica de negocio, acceso a datos es fundamental para el desarrollo de
arquitecturas consistentes, reutilizables y m as f acil de mantener, lo que al nal resulta
en un ahorro de tiempo en el desarrollo de posteriores proyectos[5].
2.2.2. MVC Y JAVA
En el lenguaje Java disponemos de unas clases muy sencillas para implantar el modelo
MVC por ejemplo: la clase Observer, Observable del paquete util. Aunque esa imple-
mentaci on del MVC con esas clases se podra hacer a un nivel muy simple de interacci on
entre unas pocas clases [8].
Java represent o (o representa) uno de los pilares mas importantes en desarrollo de
aplicaciones distribuidas usando scripting del lado del servidor, que se conozca hasta
la actualidad. Es por eso que el Modelo MVC esta orientado al lenguaje m as abierto y
portable que se haya construido [5], [6].
En al ambito del desarrollo Web se siguen unas pautas que tratan m as o menos de
conseguir un desarrollo estructurado de las aplicaciones, donde la vericaci on de sesi on
se centraliza y cada caso de uso se distingue claramente. En muchos desarrollos Web se
dise na consciente o inconscientemente siguiendo este patr on, por tanto la adopci on del
modelo Struts no debiera ser un problema mayor. Adem as hay que tener en cuenta que
Struts nos da parte del trabajo hecho, funciona correctamente, y nos da ciertos extras.
Teniendo en cuenta adem as las aportaciones de grupos de desarrollo (taglibs nuevos,
etc.), la adopci on de esta plataforma puede resultar muy interesante [7], [10].
2.3. Struts
Struts es un framework para aplicaciones Web java que implementa el modelo MVC.
Realmente lo que provee es un conjunto de clases y TAG-LIBS que conforman el Con-
trolador, la integraci on con el Modelo (o l ogica de negocio) y facilitan la construcci on de
vistas. Naturalmente, el Modelo o l ogica de negocio es la parte que se debe desarrollar.
Por eso Struts es una plataforma sobre la que montamos la l ogica de negocio, y esta
plataforma nos permite dividir la l ogica de la presentaci on entre otras cosas [7].
Utilizando Struts nunca se llega a una pagina de la capa de presentacion directamente.
Esto es, en la URL nunca se llega a una pagina JSP o HTML a traves de su nombre.
De eso se trata el MVC, la presentaci on est a separada en otra capa [7], [9].
11
2.4. Server pages
2.4.1. Servlet
De acuerdo a lo descrito en los libros [6], [8] los Servlets son la respuesta de la tecno-
loga Java a la programaci on CGI. Son programas que se ejecutan en un servidor Web
y construyen paginas Web. Construir p aginas Web mediante Servlets o CGIs es util (y
com unmente usado) por ciertas de razones:
a)La pagina Web est a basada en datos enviados por el usuario. Por ejemplo, las p aginas
de resultados de los motores de b usqueda se generan de esta forma, y los programas
que procesan pedidos desde sitios de comercio electronico tambien.
b)Los datos cambian frecuentemente. Por ejemplo, un informe sobre el tiempo o paginas
de cabeceras de noticias podran construir la p agina din amicamente, quiz as devolviendo
una pagina previamente construida y luego actualiz andola.
Las p aginas Web que usan informacion desde bases de datos corporativas u otras fuen-
tes. Por ejemplo, se puede hacer una p agina Web de una tienda en lnea que liste los
precios actuales y el n umero de artculos en almacen [8].
2.5. JSP
Un JSP (Java Server Pages) es una tecnologa que nos permite mezclar HTML est atico
con HTML generado din amicamente. Muchas paginas Web que est an construidas con
programas CGI son casi est aticas, con la parte din amica limitada a muy pocas locali-
zaciones. Pero muchas variaciones CGI, incluyendo los servlets, hacen que generemos
la p agina completa mediante nuestro programa, incluso aunque la mayora de ella sea
siempre lo mismo. JSP nos permite crear dos partes de forma separada [8], [6].
2.5.1. Ventajas Server pages
Por que utilizar Servlet/JSP?
Los Servlets Java son m as ecientes, f aciles de usar, mas poderosos, m as portables,
y mas baratos que el CGI tradicional y otras muchas tecnologas del tipo CGI [8] [9].
Eciencia. Con los Servlets, la m aquina Virtual Java permanece arrancada, y cada
peticion es manejada por un thread Java de peso ligero, no un pesado proceso del sis-
tema operativo. De forma similar, en CGI tradicional, si hay N peticiones simultaneas
12
para el mismo programa CGI, el codigo de este problema se cargara N veces en memoria.
Sin embargo, con los Servlets, hay N threads pero s olo una copia de la clase Servlet.
Los Servlets tambien tienen mas alternativas que los programas normales CGI para
optimizaciones como los caches de calculos previos, mantener abiertas las conexiones
de bases de datos, etc [8].
Conveniencia. Poder utilizar un lenguaje familiar, los Servlets tienen una gran in-
fraestructura para an alisis autom atico y decodicaci on de datos de formularios HTML,
leer y seleccionar cabeceras HTTP, manejar cookies, seguimiento de sesiones, y mu-
chas otras utilidades [8], [9].
Potencia. Los Servlets Java nos permiten facilmente hacer muchas cosas que son difci-
les o imposibles con CGI normal. Por algo, los servlets pueden hablar directamente con
el servidor Web. Esto simplica las operaciones que se necesitan para buscar im age-
nes y otros datos almacenados en situaciones est andares. Los Servlets tambien pueden
compartir los datos entre ellos, haciendo las cosas utiles como almacenes de conexiones
a bases de datos faciles de implementar. Tambien pueden mantener informaci on de soli-
citud en solicitud, simplicando cosas como seguimiento de sesi on y el cache de c alculos
anteriores [8], [9].
Barato. Hay un n umero de servidores Web gratuitos o muy baratos que son bue-
nos para el uso personal.
o
el uso en sitios Web de bajo nivel. Sin embargo, con la
excepci on de Apache, que es gratuito, la mayora de los servidores Web comerciales son
relativamente caros. Una vez que tengamos un servidor Web, no importa el costo de
a nadirle soporte para Servlets (si no viene pre-congurado para soportarlos) es gratuito
o muy barato [9].
2.6. Sistema de Gesti on de Base de Datos (SGBD)
Una base de datos es una colecci on de datos relacionados (no independientes). Modelan
y abstraen los objetos de una parte del mundo real.Sirven de soporte a las aplicacio-
nes. Se debe tener claro que una Base de Datos es independiente de los programas que
la utilizan. Es decir, si modicamos un programa no afecta los datos o la organizaci on
de cierta base de datos, ya que estos datos solo se sirven de esta para realizar una
variedad de consultas, de igual manera las bases de datos se sirven de los programas
para actualizar su contenido lo cual es posible a traves de los SGBD [10].
Los SGBD son aquellos programas que permiten a los usuarios crear y mantener una
base de datos. Tambien proveen procedimientos para la denici on, construccion y ma-
nipulaci on (b usqueda y seleccion) de informacion. Un SGBD se ocupa de organizar la
13
informaci on sobre memorias secundarias. Algo que debe considerarse para que una base
de datos sea de utilidad es que tenga poca redundancia o repetici on de datos, ya que
esto provoca inconsistencias a la hora de hacer consultas [10], [11].
Esta es la raz on principal por la que se utilizan bases de datos, ya que si se pudie-
ra almacenar y recuperar magicamente toda la informaci on que constituye el universo
estara resuelto el problema. Sin embargo, es necesario dar una estructuraci on adecuada
a la informaci on para evitar los problemas de redundancia y duplicidad [10].
Esta estructuracion signica identicar y denir las entidades que constituyen el uni-
verso en el que se va trabajar. Lo anterior se puede establecer antes de crear la base
de datos. Primero comprendiendo las necesidades y problemas de los usuarios nales
(esquema externo), continuando con el dise no de un esquema conceptual (por ejemplo
un diagrama entidad relaci on), despues con la concepcion de un esquema l ogico
(por ejemplo: relaciones 3FN) y nalmente con la implementaci on [10].
2.7. Discusi on
Para esta parte es preciso decir que el sistema a dasarrollar no es tan complejo como los
mencionados al principio y solo es comparable respecto a la funcionalidad para aplicar
ex amenes.
Por otro lado tambien debe mencionarse que este sistema adem as de estar enfocado
en la comunidad estudiantil tambien puede llegar a implementarse en instituciones que
no tengan los recursos para adquirir un sistema complejo y de un precio elevado.
14
Captulo 3
Metodologa
Este proyecto abarca principalmente a los usuarios del ITA (profesores y alumnos),
pretendiendo desarrollar un sistema facil de utilizar para aplicacion de ex amenes va
internet y as mismo, desarrollar un sistema que sea de apoyo a los profesores para la
evaluacion de sus alumnos.
Figura 3.1: Es esta parte del diagrama observamos que es lo que pretende obtener el
sistema
15
Figura 3.2: Esta parte del diagrama se centra en la programacion de la base de datos y
de la interfaz del sistema en general
16
Figura 3.3: Esta ultima parte del diagrama muestra que si se cumplen los requisitos, el
ultimo paso es implementar el sistema y en dado casi, actualizarlo
17
Tipo de investigaci on
El tipo de investigacion realizada para este proyecto es la investigacion aplicada, ya que
esta se enfoca m as a los conocimientos previos implementados en la pr actica y a su vez
este tipo de investigaci on lleva consigo un benecio provechoso para la sociedad.
La metodologa de la investigaci on se considera y se dene como la disciplina que
elabora, sistematiza y eval ua el procedimiento tecnico del que dispone una ciencia e
investigacion realizada.
Figura 3.4: Muestra los puntos principales que nuestra aplicaci on web tiene que tener
en cuanto a calidad se reere
Metodologa WSDM (web site Design Method 1997)
Dene el sistema en base a los grupos de usuarios
18
Su proceso de denici on de requisitos tiene por objetivo el detectar los perles de
usuario mediante dos tareas:
a)Clasicaci on de usuarios mediante el estudio del entorno
b)Descripci on de los grupos de usuarios
1.-Planicaci on
a)Elecci on del tipo web
b)Denici on del problema
c)Denici on del dise no
2.-Producci on
a)Aplicaciones
b)Dise no visual
3.-Mantenimiento y explotaci on
a)Aplicaci on
b)Mantenimiento
Figura 3.5: Elementos que conlleva la investigaci on
Fases del proyecto
El proyecto consta de tres fases generales las cuales son:
Recopilaci on y an alisis de la informacion.
19
Creaci on de base de datos.
Implementaci on de aplicaci on web.
Figura 3.6: Nos muestra las faces del proyecto y que de debe hacer en cada una de ellas
Fase 1:
Recopilaci on y analisis de la informacion
En esta fase en general se hace una recopilacion de la informacion requerida para la
implementaci on del proyecto, una vez recopilada la informacion es analizada y verica-
da, para determinar si la informaci on requerida es correcta y suciente para continuar.
20
Esta fase se puede dividir en tres sub-fases:
Analizar el tipo de servicio.
B asicamente en esta fase se realiza un detallado analisis del tipo de servicio que se
est a pidiendo, mediante este an alisis se pretende determinar cuanta interaccion se tiene
con dicho servicio, para ello se podra apoyar en alguna otra aplicaci on para llevar un
mejor manejo de la informaci on adquirida.
Identicaci on de variables y su tipo
En esta fase lo que se pretende b asicamente es determinar las variables que intervienen
dentro de la aplicaci on y el tipo a que corresponden.
Elecci on de un SGBD
Lo que se pretende mediante esta fase es elegir un SGBD (sistema gestor de base
de datos) que se acople a las necesidades de la aplicaci on, para un manejo correcto de
los datos.
Fase 2:
Creaci on de la base de datos
Esta fase es la encargada de llevar a cabo la implementacion de la base de datos me-
diante postgresql que es un programa dise nado para la creaci on de la misma, para ello
se capturaran los datos previamente recopilados y se le asignan sus diferentes carac-
tersticas, esto permite un r apido acceso a la informaci on que se requiere en un alg un
momento de manera mas r apida. Est a a su vez se puede dividir en dos sub-fases.
Funciones de la BD
Para esta subfase se hace un an alisis de las diferentes funciones que lleva consigo nuestro
SGBD, estas funciones nos permiten tener un mejor y f acil manejo de la informaci on a
traves de comandos sencillos para la realizacion de consultas, esto es posible gracias a
que postgresql ofrece por defecto su propio lenguaje procedural denominado PLPGSQL.
Implementaci on de la BD
En esta subfase b asicamente es la implementacion de la base de datos en postgresql,
dentro de ella se ingresan todos los datos en tablas; esto hace m as f acil el manejo de
ellos y su f acil b usqueda a traves de comandos sencillos.
21
Fase 3:
Implementaci on de la aplicacion
La implementacion de la aplicacion web implica recabar toda la informaci on que sea
necesaria para el manejo y uso de la misma, previamente se deben tener conocimiento
sobre algunos lenguajes de programacion para aplicaciones web y tener en claro las
necesidades del servicio que se ofrece. Dicha fase es la encargada de implementar la
interfaz para la aplicaci on web y darle funcionamiento.
Presentaci on de bocetos de la aplicaci on web
La presentaci on de bocetos es una de las fases m as importantes ya que se tiene que
tomar en cuenta las necesidades que la institucion est a pidiendo para tener una idea
m as clara de como ser a la interfaz de la aplicacion y lo que deber a contener dentro de
ella, esto hace que no se cometa un error a la hora de la implementaci on de la aplicacion.
Programaci on de la interfaz
La programacion de la interfaz implica plasmar los bocetos previamente aceptados
por la instituci on, a traves del sitio web donde se implementara la aplicaci on web, para
ello es necesario enlazar la base de datos con la aplicacion y los diferentes componentes
que la conforman.
Poblaci on y muestra
Benecio
La poblaci on es todo el alumnado y personal de la institucion, estos tienen en com un
varios aspectos lo que pretende la aplicaci on web es, dar conformidad a estos para aho-
rrar tiempo y dinero, ya que muchas veces es molesto y un poco costoso el hecho de
esperar tanto tiempo para realizar alg un tramite personal dentro de la instituci on.
Tecnicas e instrumentos de recoleccion de datos
Para la recolecci on de datos existen diferentes tecnicas las cuales nos ayudaran a con
el manejo de la informacion y la realizacion de dicha aplicaci on ya que esta pretende
satisfacer una necesidad social para todo el alumnado y personal desde la comodidad
22
Figura 3.7: Nos muestra los benecios que el sistema brinda a los alumnos y profesores,
tanto de tiempo como ecacia
de su casa.
Las tecnicas implementadas son:
Encuestas
Las encuestas es una tecnica f acil de aplicar ya que esta tecnica consta de cierto n umero
de preguntas que son realizadas al alumnado y a los maestros para tomar en cuenta las
necesidades de ambos y llevarlas a cabo en la implementacion de la aplicacion web.
Analisis de documentos
La tecnica de analisis de documentos implica recopilar informaci on de libros, artculos,
trabajos relacionados, etc. para adquirir mayor conocimiento sobre algunos puntos im-
portantes de la aplicaci on.
Restricciones
Un aspecto muy importante en la parte del an alisis es darse cuenta de los posibles
23
Figura 3.8: Muestra las tecnicas empleadas para la recolecci on de datos (encuestas y
an alisis de documentos) y a quien o a que se aplican
ex amenes a realizar, debido a que no todas las materias pueden ser evaluadas en lnea
un ejemplo de ello seria matematicas.
Para ello es importante identicar cuales examenes son los m as adecuados para es-
ta aplicacion y para el benecio de la instituci on.
24
Captulo 4
Pruebas y resultados
Nuestra muestra esta enfocada especcamente a los alumnos y profesores del ITA. Las
tecnicas de recolecci on de datos seran las entrevistas y observaciones.
C omo se puede estar seguro de que lo he hecho correctamente?
Aunque nunca se puede estar seguro de que se han llevado todas las pruebas que se
necesitan, puede tenerse la seguridad de que la prueba ha descubierto errores (y de
que estos se han corregido). Ademas, si se ha establecido un plan de prueba, puede
vericarse para asegurar que se han realizado todas las pruebas planeadas.
Etapas
Los participantes del proyecto (desarrolladores, clientes, usuarios nales) toman parte
en el proceso de probar la aplicaci on.
El proceso de prueba comienza en enfocarse sobre aquellos aspectos de esta que son
visibles para el usuario y procede a probar dicha tecnologa e infraestructura. La prueba
consta de siete etapas:
Contenido
Interfaz
Navegacion
Componente
Conguraci on
Desempe no
Seguridad
Prueba de contenido
25
Tiene tres objetivos importantes:
Figura 4.1: La piramide representa las etapas del dise no de la aplicaci on, y en cada
una de estas etapas hay ciertas pruebas que son necesarias para el desempe no de la
aplicaci on
1.- Descubrir errores sint acticos (errores tipogr acos) en los documentos basados en
texto, representaciones gracas y otros medios audiovisuales.
2.- Descubrir errores sem anticos (errores en la precision de la informaci on o que esta
sea incompleta) en cualquier objeto de contenido presentado conforme ocurra la nave-
gaci on.
3.- Descubrir errores en la organizaci on o estructura del contenido que se presenta al
usuario nal.
El primer objetivo se logra empleando vericadores de ortografa y gram atica auto-
matizados.
En los errores semanticos el revisor (examinador) debe responder las siguientes pre-
guntas:
26
La informacion es realmente precisa?
La informacion es concisa y exacta?
En el caso de los errores en la organizaci on o estructura, se debe representar al usua-
rio nal en el orden y relaciones adecuadas (imagen o bot on y su respectiva descripci on).
Prueba de contenido (de la base de datos)
Figura 4.2: Muestra los niveles que se pretenden desarrollar en la base de datos de la
aplicaci on
Las pruebas deben asegurar que:
La informacion v alida pasa entera (el cliente servidor desde el estrato de la interfaz).
La aplicacion procese los guiones correctamente y extraiga o formatee adecuadamente
datos del usuario.
Los datos del usuario pasen correctamente a una funcion de transformacion de da-
tos en el lado del servidor para formatear consultas apropiadas.
27
Las consultas pasen a un estado de gestion de datos que se comunique con rutinas
de acceso a bases de datos potencialmente ubicados en otra m aquina.
Pruebas de la interfaz de usuario
Estrategia de prueba de la interfaz
1.- Descubrir errores relacionados con mecanismos especcos de la interfaz (errores
en los vnculos del men u o la forma en que los datos se ingresan al formulario).
2.- Descubrir los errores en la forma en que la interfaz implementa la semantica de
navegacion (despliegue correcto del contenido).
Pruebas de facilidad de uso
Es similar a la prueba de sem antica de la interfaz en el sentido de que tambien eval ua
el grado en el cual los usuarios pueden interactuar con efectivamente con la aplicaci on.
Se aplica la siguiente secuencia de pasos:
1.- Denir un conjunto de categoras de pruebas de facilidad de uso.
2.- Dise nar pruebas que permitan evaluar cada meta. 3.- Seleccionar los participan-
tes que dirigir an las pruebas.
4.- Instrumentar la interaccion de los participantes mientras se lleva a cabo la prueba.
5.- Desarrollar un mecanismo para valorar la facilidad de uso de la aplicaci on.
El usuario profesor
1.- Activar examen
El usuario hace la peticion de activar el examen, primero buscando los cursos que
este tiene disponibles con el controlador para que este elija con una forma el curso y
parcial del examen que desee activar o desactivar, nalmente utiliza la opci on Activar
Examen para conectar con la base de datos y actualizar la tabla de los examenes ac-
tivos.
2.- Cargar examen
28
Crear examen: b asicamente consiste en permitir que el usuario profesor introduzca
manualmente las preguntar que desee que sean parte de cierto examen.
Figura 4.3: Representacion de la interfaz graca en donde el profesor puede cargar el
examen, as como ver los resultados y activar los ex amenes
3.- Modicar preguntas
En esta modalidad el usuario tiene la opci on de modicar las preguntas existentes
en la base de datos
4.- Subir examen
Esta ultima modalidad el usuario sube las preguntas mediante un archivo generado
y guardado previamente en su PC por el sistema.
5.- Ver resultados
La primera modalidad es visualizar los resultados obtenidos en los ex amenes ya sea
por curso, secci on, en general o por alumno. La segunda modalidad permite a ciertos
usuarios alumnos volver a tomar dichos examenes seg un el criterio del profesor.
29
Figura 4.4: Representaci on de la interfaz gr aca en donde el profesor puede ver los
resultados y elegir si desea dar otra oportunidad a alg un alumno
El usuario alumno
El alumno tiene dos opciones principales en el sistema:
1.- Tomar examen: esta operaci on consiste primero en vericar los ex amenes dispo-
nibles y elegir cual quiere tomar para contestar.
2.- Ver resultado: esta opci on consiste en ver los resultados obtenidos por examen.
Se muestra al usuario la calicacion obtenida y las preguntas que contesto ya sea
bien o mal. Despues de que el alumno ha presentado al menos un examen en el sistema
este podra vericar sus calicaciones obtenidas. Una vez que el alumno elija la opci on
ver resultados se obtendr a la lista de cursos a loas que esta inscrito el alumno.
Pruebas de compatibilidad
Si as se desea la aplicaci on puede operar dentro de ambientes diferentes que dee-
ren uno del otro como diferentes computadoras, dispositivos de despliegue, sistemas
operativos, navegadores, velocidades, etc.
30
Figura 4.5: Interfaz gr aca del alumno en donde se muestra las opciones que se le dan
a elegir
Pruebas de navegaci on
Garantizar que todos los mecanismos que permiten al usuario de la aplicaci on via-
jar a traves de ella sean funcionales.
Validad que cada unidad sem antica de navegaci on pueda ser alcanzada por la cate-
gora de usuario adecuada.
Pruebas de sintaxis de la navegacion
Comienza durante la prueba de la interfaz y los mecanismos de navegaci on se prue-
ban para asegurar que cada uno realiza la funcion que se busca:
-Vnculos de navegacion
-Redirigir
-Bookmarks
-Mapas de sitio
-Motores de b usqueda internos
Pruebas de componentes
31
Tambien llamadas pruebas de funci on, se enfocan sobre un conjunto de pruebas que
intentan descubrir errores en las funciones de la aplicacion. El prop osito es descubrir
errores que ocurren durante el manejo de los errores (por ejemplo manejo de errores
incorrectos o inexistentes, falla de la aplicacion como consecuencia del error).
Pruebas de conguracion
Conictos del lado del servidor
Aqu los casos de prueba de conguracion se dise nan para vericar que la congu-
raci on del servidor sea proyectada (es decir: servidor de la aplicaci on, servidor de la
BD, sistemas operativos, software contrafuegos, aplicaciones concurrentes) puedan so-
portar la aplicaci on sin error.
La aplicacion es totalmente compatible con el SO del servidor?
Las medidas de seguridad del sistema (como contrafuegos) permiten a la aplicaci on
ejecutarse y dar servicio a los usuarios sin interferencia?
La aplicacion est a adecuadamente integrada con el software de BD?
Conictos del lado del cliente
Aqu las pruebas se centran en la compatibilidad de la aplicacion con las congura-
ciones que contiene una o mas permutaciones de los siguientes componentes:
-Hardware (CPU, memoria, etc)
-Sistemas operativos (Windows, linux, macintosh)
-Navegadores web (Internet explorer, Google Chrome)
-Plug-ins (QuickTime, RealPlayer)
Pruebas de desempe no
Se aplican para descubrir problemas de desempe no que se presentan debido a faltas
de recursos en el lado del servidor, ancho de banda de red inapropiado, capacidades
inadecuadas de la BD, funcionalidad mal dise nada de la aplicaci on.
Comprender como responde el sistema a la carga (n umero de usuarios, n umero de
transacciones o volumen de datos global).
Recolectar metricas que conducir an a modicaciones de dise no para mejorar el desem-
32
pe no.
Objetivos de las pruebas de desempe no
Se dise nan con el n de simular situaciones de carga del mundo real. Conforme crece el
n umero de usuarios simultaneos de la aplicacion o aumenta el n umero de transacciones
en lnea, ayudan a responder las siguientes preguntas:
El tiempo de respuesta es aceptable?
En que punto (usuarios, transacciones o carga de datos) el desempe no se vuelve inacep-
table?
Que componentes del sistema son responsables de la reducci on del desempe no?
Est an dise nadas para probar las vulnerabilidades en el ambiente del lado del clien-
te, las comunicaciones de red y el ambiente del lado del servidor.
En el lado del cliente algunas vulnerabilidades pueden ser el acceso no autorizado a
cookies colocadas dentro del navegador, del lado del servidor pueden ser ataques de
negaci on de servicio o el acceso sin autorizacion a la BD.
La protecci on contra estas y muchas otras vulnerabilidades requiere imprentar uno
o mas de los siguientes elementos de seguridad:
1.- Contrafuegos: Mecanismo de ltrado que examina cada paquete de informacion.
2.- Autenticaci on: Mecanismo de vericaci on que valida la identidad de los clientes
y servidores.
3.- Encriptado: Mecanismo de codicacion que protege los datos sensibles.
4.- Autorizaci on: Mecanismo de ltrado que permite el acceso al ambiente del clien-
te o el servidor.
33
Captulo 5
Cronograma de actividades
Figura 5.1: Muestra el proceso de las actividades a desarrollar
34
Captulo 6
Lugar donde se desarrolla el
proyecto
El Instituto Tecnol ogico de Acapulco es una institucion p ublica de educaci on superior
localizada en Acapulco, Guerrero, Mexico. Fue creado el 1 de octubre de1975.
Imparte 6 carreras a nivel licenciatura y 4 a nivel posgrado en las areas de ciencias
sociales y administrativas, e ingeniera. Forma parte de la Direccion General de Educa-
ci on Superior Tecnologica (DGEST), de la Secretara de Educaci on P ublica de Mexico.
El Instituto Tecnol ogico de Acapulco cuenta con siete facultades en el area, las cuales
son:
Facultad de Ingeniera Bioqumica y Biociencias alimentos y bebidas
Facultad de Ingeniera en Sistemas Computacionales
Facultad de Ingeniera Electromecanica
Facultad de Ingeniera en Gesti on Empresarial
Facultad de Arquitectura y Bio-Arquitectura
Facultad de Administraci on
Facultad de Contadura
En este Estado de Guerrero, con una plenitud de herencias, con grandes retos y com-
promisos, con capacidad y conciencia hace m as de veinticinco a nos, se determina que
el lugar id oneo para albergar a las instalaciones de lo que con el tiempo se convertira
35
en el Instituto Tecnol ogico de Acapulco, seran los lmites de los ejidos de La Sabana
y El Cayaco, en el Municipio de Acapulco; tomando en cuenta la situacion geograca,
posicion estrategica y potencialidad escolar.
A iniciativa del Gobierno Estatal, fueron donadas 45 hectareas de terreno, mismas
que en la actualidad se han visto reducidas a unicamente 19 hect areas, persistiendo
la falta de regularizaci on de dicho predio, que cada da se ve mermado por invasiones
precaristas, mas difciles de combatir debido a nuestra situaci on legal.
Aqu se construyen y equipan las instalaciones del Instituto Tecnol ogico de Acapul-
co, que en sus inicios se denomino Instituto Tecnol ogico Regional de Acapulco, siendo
inaugurado el da 19 de Septiembre de 1975, por el C. Ing. Ruben Figueroa Figueroa,
en ese tiempo Gobernador Constitucional del Estado. Las actividades academicas ini-
ciaron el 1
o
. De Octubre de ese mismo a no, siendo Director fundador el Ing. Arq. Ra ul
Roberto Aguilar Rezza.
El Instituto Tecnologico de Acapulco cont o con una poblacion inicial de: 51 alum-
nos de nivel superior y 483 alumnos de nivel medio superior (tecnicos), atendidos por
una planta laboral de 47 empleados entre docentes y administrativos.
6.1. Macrolocalizacion
Acapulco de Ju arez es una ciudad y puerto mexicano ubicado en el estado de Guerrero,
en la costa sur del pas, a 304 kil ometros de la Ciudad de Mexico. Es la mayor ciudad
del estado superando en gran medida a la capital del estado, ademas de que forma
parte de la unica zona metropolitana del estado, concentrado la mayor poblaci on de la
misma. Es cabecera del municipio hom onimo y uno de los principales destinos tursticos
de Mexico. Ademas de ser considerada la decima sexta metropoli m as grande del pas
y la vigesimo primera ciudad m as poblada de Mexico.
6.2. Microlocalizacion
El instituto tecnol ogico de Acapulco se encuentra en Cayaco - Puerto Marquez El
Coloso, Acapulco, Acapulco de Juarez, Guerrero
36
Figura 6.1: Mapa de el puerto de Acapulco, Gro.
Figura 6.2: Croquis de la ubicaci on del Instituto Tecnologico de Acapulco
37
Captulo 7
Conclusi on
Este sistema no pretende remplazar la aplicacion de examenes tradicional sino ser un
apoyo tanto a los profesores como a los estudiantes. Se pretende que el uso de esta
herramienta enriquezca la retroalimentaci on dentro de un curso. Por un lado el profesor
puede aplicar ex amenes sobre ciertas materias de un curso que por la naturaleza de
este no son abordados o evaluados dentro del horario de la materia por lo que con dicha
herramienta se podra realizar de manera remota. Por otro lado el alumno se puede
ayudar de estos ex amenes para mantener activos los conocimientos obtenidos en el cur-
so si es que se diera el caso de que el profesor aplicara un examen por cada tema visto,
por lo que el profesor ser a quien dena el valor que puede o no tomar las calicaciones
de los alumnos dentro de sus cursos.
Considerando la etapa que se vive actualmente en el mundo, estamos viviendo una
era donde la digitalizacion y tecnologas de informacion estan invadiendo la mayora de
las areas de conocimiento. Por lo que este sistema responde a las necesidades tecnol ogi-
cas que se est an presentando da con da. A pesar de que no es el primero ni el m as
importante en su tipo y funcionalidad, este puede ser de gran utilidad para sus usuarios.
Hablando especcamente del sistema actual podemos decir que el sistema desarro-
llado es mucho m as exible, util, agradable y f acil de utilizar.
Flexible porque permite al profesor editar sus propias preguntas en base al ritmo del
curso y lo visto en clase, al alumno le da la opci on de aplicar el examen de manera
remota sin tener que estar necesariamente en un aula.
Es util para el profesor porque por un lado, este no necesita emplear tiempo para
imprimir en papel sus examenes con el riesgo de que no lleve el numero correcto de
ex amenes y por el otro lado tampoco es indispensable que tenga que estar presente en
la aplicacion de dichos ex amenes (siempre y cuando estos no sean de gran relevancia).
Tambien es de gran utilidad tanto para el profesor como alumno ya que les permite
llevar un control sobre las calicaciones obtenidas.
38
Es agradable porque evita que el usuario se pierda en un mar de opciones ya que
se busc o el mayor nivel de simplicidad en la interfaz, adem as de que se trat o de poner
opciones claras, para que el usuario entienda y comprenda que es lo que esta realizando.
Se considera facil de usar en base a las reglas de dise no de interfaces y guas usables
aplicadas al dise no lo que permite al usuario navegar en el sistema con una barra de
navegacion y opcion de salida o retroceso, siempre visibles, de tal modo el usuario no
podra encontrarse en una situaci on incomoda o poco entendible.
De manera m as concreta el sistema que es utilizado actualmente cuenta con deciencias
respecto a este. No lo puede utilizar cualquier profesor para aplicarlo a un curso (s olo
es utilizado para ciertos examenes). A pesar de que los ex amenes pueden ser aplicados
de manera remota son inseguros en el sentido de que estos necesariamente deben ser
aplicados bajo alg un tipo de supervisi on para evitar trampas.
El patr on de dise no MVC al parecer, despues de aplicarlo al dise no y observar su
desempe no, es el patr on de dise no que mejor funciona al desarrollar aplicaciones Web.
Ya que este permite que se mantenga una aplicacion distribuida sin ahogar al servidor
de peticiones.
Tenemos que el sistema actual no se permite aplicar preguntas abiertas ya que esto
implica la programacion de un reconocedor lexico el cual necesariamente debe utilizar
inteligencia articial y/o redes neuronales con esta funcionalidad. Adem as se lograra
un sistema mucho mas robusto. Otro detalle importante es que si no se cuentan con
demasiadas preguntas este sistema no puede generar ex amenes realmente diferentes, ya
que se generan versiones con pocas variantes. Es decir, si cambiara el orden pero no es
tan notoria la diferencia.
Tal vez se podra dise nar una estrategia para generar autom aticamente varios tipos
de preguntas sin que se le especique al sistema el tipo de pregunta. Tambien se puede
tener como trabajo a futuro la implementaci on de un m odulo que permita activar un
examen cierto tiempo.
Para el desarrollo de este proyecto tomamos en cuenta las competencias que conlle-
va la materia, como son las competencias de trabajo en equipo, que esta fue, para
nosotros, la que mas resalto ya que gracias al buen trabajo en equipo logramos el desa-
rrollo completo de dicho proyecto. Las capacidades de an alisis, sntesis y abstracci on
de cada integrante del equipo fueron fundamentales para la concretaci on de cada tema.
La creatividad es otro punto fuerte en el desarrollo de este proyecto, ya que gracias al
trabajo en equipo, se logro una idea unica y general de lo que se pretende realizar.
la propuesta que presentamos se considera un trabajo de investigacion poco te orica
39
y mas pr actica, lo que quiere decir que es un trabajo dirigido para proyectos de Resi-
dencias profesionales.
40
Captulo 8
Referencias
[1] Gudi no, Valeria. Internet. [online]. Argentina: Los TeletrabajadoresBIZ, 2005-2014.
Disponible en: http://www.teletrabajadores.biz/internet.htm
[2] Ceballos, Francisco. Java 2: Curso de programacion. Ed. MADRID: RA-MA, Mayo
2002.
[3] IEEE. IEEE Standard Glossary of Software Engineering Terminology. [online]. DOI:10.1109/IEEESTD.1990.101064.
IEEE Xplore Digital Library , 1990. Disponible en: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=159342
[4] Pressman, Roger S. Ingeniera del software. Un enfoque practico. Ed. Mexico: McGraw-
Hill, 2002.
[5] Freeman, Eric. et al. Head First Desing Patterns. Ed. OReilly Media, October 2004.
[6] Basham Brayant, Sierra Kathy and Bates Bert. Head First Servlets and JSP: Pas-
sing the Sun Certied Web Component Developer Exam (SCWCD). Ed. OReilly Media,
July 2004.
[7] Hightower, Richard. Jakarta Struts Live. Ed. SourceBeat, 2004.
[8] Hall, Marty. More Servlets and JavaServer Pages. Ed. Pearson Education, December
2001.
[9] Hall, Marty. Core Servlets and JavaServer Pages: : Core Technologies. Ed. Prentice
Hall, September 2003.
[10] Silberschatz, Abraham. Fundamentos de Bases de Datos. Ed. McGraw-Hill, Mayo
2002.
[11] Axmark, David. MySQL Reference Manual. Ed. MySQL AB, Copyright 1997-2004
41
J. Jones. (1991, May 10). Networks (2nd ed.)
Extrado de: http://www.atm.com/netwosks1343/345
C. Charles. (2002, Enero 05) Struts Implementaci on del patr on MVC en aplicacio-
nes WEB (Java hispano).
Extrado de: http://java.sun.com/j2ee/1.4/doc.webApp.htmlw23234
S. Khutaina. (2005, Agosto 15). Struts Framework.
Extrado de: http://jakarta.apache.org.struts
M. Harrys. (2005, Abril 20) Patron de arquitectura MVC
Extrado de: http://www.lab.inf.uc3m.es/ a0080802/RAI/mvc.html
Microsoft. (2008, Julio 25) Certicaci on MOS
Extrado de: http://www.microsoft.com/learning/es-mx/mos-certication.aspx
Fundacion Santillana. (2007, Octubre 11). MVC b asico
Extrado de: http://www.fundacionsantillana.com/upload/cheros/noticias/20111
1/documentobsico
P. Patricia Mora (2011, Febrero 02). Examenes departamentales va internet: UNAM
Extrado de: http://www.ejournal.unam.mx/rfm/no48-3/RFM48303.pdf
42