GOADI

Control de utilización de los
ordenadores de las aulas de informática
del IES Beniaján

2º Administración de Sistemas Informáticos en Red
Curso 2011/2012

Marta Cárceles Martínez

Tutor: José Manuel Rubira Miranda

Murcia, Junio 2012

A mi familia, amigos y compañeros

por aguantar largas conversaciones a altas horas de la noche.

A María y a Peter por alegrarme los sábados de proyecto.

A Jesús Ibáñez por sus trucos, siempre funcionan.

A José Manuel por su paciencia

y sobre todo

por esos correos que me quitaban el sueño.

2 Marta Cárceles Martínez 48402356-Y

Índice

1. Introducción.................................................................................................... 4

2. Objetivos generales y específicos ............................................................ 4

3. Aplicaciones .................................................................................................... 5

4. Plan de trabajo ............................................................................................... 7

5. Recursos utilizados..................................................................................... 12

6. Base de datos y tablas. Diagrama de bloques. ................................... 14

7. Implementación ........................................................................................... 16

8. Manual de instalación ................................................................................ 19

9. Manual de los usuarios .............................................................................. 25

10. Conclusiones............................................................................................... 42

11. Bibliografía ................................................................................................. 44

12. Anexos .......................................................................................................... 45

i. Script SQL .................................................................................................... 45

ii. Manual del programador ..................................................................... 48


1. Introducción

El proyecto que presento ha sido realizado durante el transcurso del 2º
Curso del Ciclo Superior en Administración de Sistemas Informáticos en
Red (ASIR) en su periodo de realización de la Formación en Centros de Trabajo
(FCT).

A priori su desarrollo pertenece al módulo de Implantación de
Aplicaciones Web (IAW), aunque a la hora de implementarlo he necesitado
algunas de las capacidades y/o habilidades adquiridas en otros módulos tanto
del presente curso como del curso anterior. Esto me ha dado una idea global
del conocimiento adquirido a lo largo de estos 2 años.

Este proyecto es de tipo ejecución/realización pues está pensado para que
se implemente en el Instituto de Educación Secundaria de Beniaján y pueda ser
usado por los profesores que utilicen las aulas de informática.

La idea de realizar este proyecto proviene del tutor del mismo, José Manuel
Rubira Miranda, y de su papel en el centro como Responsable de Medios
Informáticos (RMI).

El periodo de realización del mismo en un principio constaba de 30 horas
en total, pero como se verá en el apartado “4. Plan de trabajo”, se han
superado dichas horas.

2. Objetivos generales y específicos

El objetivo principal que se perseguía era desarrollar una aplicación que
permitiera el control, por parte de los profesores, de la utilización de los
ordenadores en las aulas de informática.

En la realización del mismo se consiguieron otros objetivos como la
investigación o/y ampliación de conocimientos específicos, la capacidad de
organización, el cumplimientos de “plazos” de entrega, y otras muchas que son
necesarias a la hora de incorporarse al mundo laboral.


3. Aplicaciones

Como se ha comentado anteriormente el proyecto consiste en el desarrollo
de una aplicación que pudiera utilizar el profesor para poder conseguir un
cierto control de los ordenadores que tienen en el aula.

La situación que se tiene es la siguiente:
Ordenador profesor: este dispositivo actuará como servidor donde el
alumno tendrá que registrarse previa habilitación por parte del
profesor de la sesión de trabajo. Destacar que por cada aula
encontraremos un dispositivo como este que trabajará como servidor
para alojar la aplicación.
Ordenador del alumno: el alumno accede a la aplicación, a través de
un navegador, y completa un formulario de registro donde plasma el
estado del puesto que ocupa.
Servidor central: este dispositivo tendrá alojada la aplicación desde la
cual el profesor informará de posibles incidencias con los
dispositivos (ordenador que no arranca, no hay teclado, ratón
averiado, etc.)

Dada esta situación se han desarrollado las siguientes aplicaciones.

Aplicación del Profesor

El profesor deberá habilitar/abrir una sesión donde los alumnos deben
registrarse antes de poder utilizar el ordenador del puesto ocupado. Dicha
sesión/entrada permanecerá abierta hasta que el profesor opte por cerrarla.

Para abrir dicha sesión deberá cumplimentar un formulario donde se
recogen datos como: nombre, apellido, correo electrónico, aula ocupada,
grupo/curso de trabajo.

Desde la aplicación el profesor podrá ver los puestos de trabajo y sus
usuarios. También podrá poner incidencias sobre el estado de los mismos.
Esta parte de la aplicación enlaza con la que se aloja en el servidor central. El


profesor usará los datos que el alumno ha introducido sobre el estado del PC o
las observaciones si las hubiera, y podrá añadir otros comentarios extra a los
que introdujo el alumno. La incidencia consta, además, de los campos que el
profesor ha rellenado en el formulario.

En la aplicación cuenta con un apartado llamado “Histórico” desde el cual el
profesor podrá buscar sesiones anteriores y ver el estado de las mismas.
Encontrará una pantalla con un filtro por fecha y hora lectiva (según horario
centro). También podrá visualizar a los alumnos que se conectaron a la sesión.
Este apartado es el más importante ya que nos permite conocer la
identidad de la persona que ocupaba un determinado puesto de trabajo con un
determinado profesor y en una determinada fecha y hora.

Al acabar la sesión de trabajo el profesor deberá cerrar la sesión. Esto es
importante ya que el control del número de puestos ocupados está
relacionado con el estado de la sesión, si la sesión está abierta se le mostrará
al alumno los ordenadores que están libres. Esto se comprenderá mejor en el
apartado “6. Base de datos y tablas. Diagrama de bloques”.

Aplicación del alumno

El alumno/usuario al arrancar el PC encontrará el navegador abierto con
página de inicio la aplicación desarrollada. En esta página encontrará un
listado de sesiones abiertas (en este caso concreto será una única sesión
debido a que por cada aula tenemos un servidor) previa habilitación por parte
del profesor.
Podrá unirse a la sesión y deberá rellenar un formulario donde indicará su
nombre, apellido, puesto de trabajo que ocupa y estado del mismo.
Una vez unido a la sesión abierta, el PC del alumno podrá ser utilizado de
forma normal.

Aplicación del servidor central

En este dispositivo se encuentra la aplicación de gestión de
incidencias del RMI. La aplicación tiene por objetivo recibir e insertar en la
base de datos los campos de una incidencia. Como se ha comentado en la
aplicación del profesor, recoge los datos de la sesión del profesor junto con

el estado y observaciones que el alumno ha facilitado cuando ha rellenado
el formulario.
Esta aplicación convive con otra, que ha sido realizada por José
Manuel Rubira Miranda, que tiene por objetivo la gestión de incidencias del
centro.

4. Plan de trabajo

Como en todo proyecto/trabajo se debe realizar una temporización
pre y post trabajo. El hecho de controlar los tiempos es importante tanto
para pequeños proyectos como este, como para grandes proyectos que se
realizan en empresas.

El periodo de realización del mismo englobaba desde el día 28 de
Marzo al 25 de Junio del 2012, día de la exposición/defensa.

Para la elaboración del mismo realicé un “Plan de trabajo previo” con
el objetivo de obtener un control en los plazos de entrega y el ritmo de
trabajo.

De la misma forma, mientras desarrollaba el proyecto realicé un
documento con los pasos que daba y las dificultades que encontraba.

A continuación se presentan las tablas con los datos comentados.


Tareas a realizar:
Semana Trabajo a realizar Tiempo a emplear (horas)

28/03/2012-01/04/2012 Asignación del proyecto

02/04/2012-08/04/2012 Periodo Vacaciones Periodo Vacaciones


16/04/2012-22/04/2012 Lectura y establecimiento de 2
los pasos a seguir. Estructura
BD y tablas.

23/04/2012-29/04/2012 Creación de la máquina del 3
profesor. Instalación del
servidor profesor. Creación
de la BD y tablas.

30/04/2012-06/05/2012 Realización del index.php y 2
preparación “esqueleto” de
las páginas. Creación favicon
y logo.

07/05/2012-13/05/2012 Formulario profesor. Cerrar 3
sesión.

14/05/2012-20/05/2012 Formulario alumno. 4

21/05/2012-27/05/2012 Formulario profesor 4
incidencias.

28/05/2012-03/06/2012 Comunicación de incidencias. 4
Creación máquina servidor
central.

04/06/2012-10/06/2012 Cambios finales. Revisión y 3
reconstrucción.

11/06/2012-17/06/2012 Redacción del documento a 3
presentar.

18/06/2012-24/06/2012 Realización del PowerPoint 2
para exposición.

Total de horas 30


Tareas realizadas a posteriori:
Semana Trabajo realizado Tiempo empleado

28/03/2012-01/04/2012 Asignación del proyecto


09/04/2012-15/04/2012 Lectura comprensiva del proyecto. 3
Planificación de las tareas a realizar.
Escritura de las mismas. Diseño de las
diversas partes de las aplicaciones.

16/04/2012-22/04/2012 Reescritura de las tablas y bd. Buscando 5
e instalando servidores web con
modulo php y mysl: XAMP,SERVERAPP,
WAMP.

23/04/2012-29/04/2012 Revisión tutor. Remodelación de lo 4
previsto sobre papel. Diseño de las
tablas de datos. Documentación
WAMPSERVER. Instalación versión 2.2.
30/04/2012-06/05/2012 Arreglos archivos php.ini y configuración 2
de phpmyadmin. Creación BD e inserción
valores en las tablas ordenadores y
aulas.

07/05/2012-13/05/2012 Implementación de la primera parte de 4
la aplicación del profesor.
Implementación del formulario alumno.
Revisión de los formularios. Buscando
funciones php necesarias.

14/05/2012-20/05/2012 Formulario alumno: control de errores 5
con php, validación de campos en
ambos formularios. Creación tabla
sesion_abierta. Cambio de títulos en el
menú profesor. Arreglos formulario
alumno. Gestión_v4

21/05/2012-27/05/2012 Validación de campos en ambos casos
Implementación de los php ver alumnos
online, cerrar sesión en la aplicación del
profesor.

REVISION TUTOR. Corrección errores 15


encontrados en ambas aplicaciones.

Gestion_v5. Arreglos checkbox en
formulario alumno. Problemas con la
tabla listado alumno. Corrección de
warning por uso variables get. Creación
cabecera, funciones errores, etc.

Repaso proyecto para implementar
comunicación con RMI.

Reestructuración de las tablas y
consultas a la BD de los formularios.

Control sesiones en alumno y profesor.
Corrección errores alumnos. Dudas de
estructura de los apartado “estados del
pc” y “listado de alumnos”

28/05/2012-03/06/2012 REVISION TUTOR. Corrección salir.php,
corrección errores, la tabla registros se
queda para realizar el historial.

Gestión_v9. Desarrollo de los php
incidencias, botones con enlaces al
servidor central, desarrollo del php del
servidor central, envió parámetros vía 8
GET, corrección funciones auxiliares de
los checkbox, cambio opciones de inicio
del profesor.

04/06/2012-10/06/2012 Gestion_v11. Corrección envío mail al
RMI. Inserción de un input que permita
al profesor añadir incidencias.
Quitando etiquetas html para que no se
inserten en la BD. Corrección
problemas en el campo observaciones e 10
inserción de datos en la BD. Añadir
cabecera la aplicación del servidor
central, intento errores de duplicidad
(Es el RMI el que lo controla).
Maquetación.

11/06/2012-17/06/2012 Redacción del documento a presentar.
Resolución arranque aplicación alumno.


De la misma forma para el profesor.

REVISION TUTOR. Añadir apartado
histórico de sesiones. Gestión_v12.
9
Revisión de las aplicaciones,
comprobación de funcionamiento.
Realización de documento a presentar.

18/06/2012-24/06/2012 Gestion_v13. Añadir en el apartado
histórico de sesiones la opción alumnos
que se registraron. Continuación con el
documento. Retoques de forma a las 12
aplicaciones. Realización de los
manuales de los usuarios. Corrección
error a la hora de habilitar un PC, se
duplicaba la ocupación.

Reconstrucción manuales, documento.
Creación tablas en DIA.

Gestion_v14

Finalización del documento a presentar
y creación del PowerPoint. Preparación
exposición

Total de horas empleadas 77

Como indico al comienzo de este texto, el número de horas es más del doble
del que en un principio se debía de emplear, y esto sin hacer un recuento
sumamente exhaustivo de las horas empleadas.


5. Recursos utilizados

A la hora de desarrollar las aplicaciones y realizar las pruebas de
funcionamiento tuve que utilizar varios entornos de desarrollo,
implementados sobre máquinas virtuales empleando el software Virtual Box.
Tanto para el ordenador del profesor como para el servidor central tuve que
montar un servidor web, un gestor de bases de datos y un (módulo)
intérprete del lenguaje PHP.

Entornos de desarrollo
Servidor del aula o PC del profesor:
- Sistema Operativo: Microsoft Windows XP, Service Pack 3.
- WAMP Server 2.2: es un entorno de desarrollo Web, que permite crear
aplicaciones web y ejecutarlas con Apache, PHP 5.3.10 y la base de datos
MySQL 5.5.20. Esta versión también lleva en su ejecutable PHPMyAdmin
3.4.10.1 para administrar las bases de datos. Y otras aplicaciones como
sqlBuddy 1.3.3 símil a PHPMyAdmin y XDebug 2.1.2 que es una
extensión para PHP que proporciona un soporte para la depuración de
scripts.

Servidor Central:
- Debian GNU/Linux 6.0.3 (squeeze)
- PHP 5.3.3
- MySQL 5.1.49
- Apache/2.2.16

Ordenador del alumno:
- Microsoft Windows XP, Service Pack 3.
- Navegador FireFox o Internet Explorer

Entornos de producción

Las aplicaciones se han instalado y se ha verificado su
funcionamiento en los dispositivos siguientes.


Servidor del aula o PC del profesor:
- Sistema Operativo: Microsoft Windows XP Professional y Debian GNU.
- PHP 5.3.9
- MySQL 5.5.20
- Apache/2.2.21 VC9

Servidor Central:
- Debian GNU/Linux 5 (lenny)
- PHP 5.3.3
- MySQL 5.1.49
- Apache/2.2.16

- Microsoft Windows XP Profesional, Service Pack 3.
- Navegador FireFox, Internet Explorer, Google Chrome,…

Además, para la instalación y configuración de los entornos de
desarrollo y para la realización del presente documento y del documento
utilizado en la exposición/defensa he usado los programas que se
relacionan a continuación:

o Programa DIA. Diseño de BD y tablas. V0.97.2
o Microsoft Office Word 2007
o Microsoft Office PowerPoint 2007
o Virtual Box 4.1.8
o BlueFish 2.2.1


6. Base de datos y tablas. Diagrama de bloques.

Para dar soporte a los datos que se van a recoger he creado en MySQL una
base datos que tiene por nombre gestion (ver Anexo Script SQL). En esta base
de datos he creado las tablas necesarias previo análisis de la situación
planteada.

Diagrama de bloques

Necesitamos de un registro de aulas y ordenadores.

En este registro se deben completar los datos con los valores de las aulas
que dispone el centro y el nombre de los ordenadores que hay en cada aula. Si se


elimina un aula se eliminan todos los ordenadores que incluía. (Ver Anexo Script
SQL)

De la misma forma necesitamos las tablas que registren las sesiones y los
alumnos que se unen a las mismas.

Si queremos eliminar una sesión se eliminarán todos los alumnos asociados
a ella. (Ver Anexo Script SQL)

He de comentar que los grupos se están recogiendo de un archivo “.txt”.
Aunque la opción más completa habría sido implementar una tabla para
almacenar estos datos, se ha optado por esta solución para probar diferentes
técnicas en el acceso a los datos.

Para la comunicación con el RMI tenía una base de datos (cirmi) y una tabla
(INCIDENCIAS) que pertenecía a la aplicación que se aloja en el servidor central
(CIRMI).


Algunos campos de esta tabla son para el uso interno del RMI en la aplicación
CIRMI.

7. Implementación

Cómo la RAE nos dice implementar es “poner en funcionamiento,
aplicar métodos, medidas, etc., para llevar algo a cabo.”

Todas las aplicaciones se apoyan en unos scripts PHP genéricos
(/includes):
- cabecera.php  código HTML que incluye una imagen.
- config.php variables globales para la conexión a MySQL y al servidor
central.
- funciones.php  código PHP para la conexión a MySQL.
- validar.php  función que comprueba si el email cumple los requisitos
típicos: lleva @, caracteres y números.

Para llevar a cabo las aplicaciones tuve que ir construyendo poco a
poco cada PHP que las componen.

Comenzaremos con la aplicación del profesor (/profesor), consta de
los siguientes archivos:
- index.php  es la página principal y lleva un listado de opciones. Todo
en HTML.
- grupos.txt  listado de cursos/grupos del centro.


- habilitar.php  es el formulario para dar de alta la sesión, se asignan
unas variables de sesión que nos regula el acceso al resto de opciones y
se usan en posteriores documentos php. Se insertan los datos en la tabla
sesión_abierta., con estado (s_abierta) 1 por defecto.
- listado_alumnos.php  se muestra una tabla, que proviene de una
consulta a la BD, que contiene datos sobre las sesiones que hay abiertas
en ese momento. Se selecciona una y se pasa por GET la id al php
siguiente.
- listado_alu.php  recoge la variable GET para realizar la consulta en la
BD y muestra los resultados (alumnos con la id de sesión igual a la id
recogida) en formato tabla.
- poner_incidencia.php  se muestra un listado de los ordenadores y sus
ocupantes, para ello se usan las variables definidas en la sección
“habilitar.php” junto con varias consultas a las tablas. Desde este archivo
se llama al archivo poner_incidencia_cirmi.php que se encuentra en el
servidor central. Se le pasan los parámetros por GET.
- historico.php  Se muestra un filtro de fecha y hora para mostrar las
sesiones. Una vez mostradas las sesiones podemos elegir la opción de
“ver alumnos”, que es un mini-formulario que pasa por GET la id de
sesión al documento siguiente.
- ver_alumnos.php  recoge esta variable y realiza la consulta a la BD.
Muestra los resultados en una tabla.
- deshabilitar.php  nos muestra las sesiones abiertas. Se elige una y por
GET se envía la id de la sesión a cerrar al siguiente php.
- cerrar.php  Cambia el valor de s_abierta a 0 y s_cerrada a 1 en el
registro de la tabla sesión_abierta. Además pone a 0 el valor del campo
estado_pc de la tabla ordenadores con id de aula igual al del aula que
donde se cierra la sesión.
- salir.php  destruye las variables de sesión, las sesiones de mysql y las
cookies.

La aplicación del alumno (/alumno), consta de los siguientes
archivos:
- index.php  se muestran las sesiones abiertas en ése momento. Se
realiza con una consulta a la tabla sesión_abierta con valor 1 en el campo
s_abierta.


- formulario_alumno.php  se le asigna una id de sesión con un número
aleatorio, tendrá que rellenar un formulario, que serán los datos que se
inserten en la tabla registro_alumnos. Se inserta el registro en la tabla
residtro_alumnos. En este paso se cambia el estado del pc que usa el
usuario a ocupado (estado_pc ahora vale 1) con id aula el de la sesión a
la que se ha unido.
- salir.php  destruye las variables de sesión, las sesiones de mysql y las
cookies.

La aplicación del CIRMI es básicamente un archivo php
(poner_incidencia_cirmi.php) que recoge las variables pasadas por GET
y realiza una inserción de los valores en la tabla INCIDENCIAS que hay
en la BD de cirmi.

Todos estos archivos están validados con PHP y/o JAVASCRIPT. Se ha
implementado el control de sesiones para que nadie pueda acceder a
ciertas partes de las aplicaciones sin previa unión/habilitación.


8. Manual de instalación

Debemos realizar los pasos siguientes para que la aplicación quede
instalada y funcione correctamente.

Respecto al software empleado, no existe posibilidad de elegir entre
distintas posibilidades para el caso del SGBD (tiene que ser
obligatoriamente MySQL) y del lenguaje de script del lado del servidor
(PHP).

Servidor del aula:

- Sistema Operativo:
o Windows XP o superior, Linux (Debian/Ubuntu)
o Servidor Web: Apache, IIS, etc.
o Módulo de PHP 5.3.10 o superior
o SGBD MySQL 5.5.2.0 o superior

- Creación de una carpeta en el directorio público del servidor Web. En este
caso: gestión_v14.
- Copiado de los scripts de PHP en dicha carpeta.
- Creación de la BBDD. Usar las dos primeras líneas del script
base_de_datos_tabla.sql
- Creación del usuario del SGBD. Se puede usar phpmyadmin para realizar la
importación del script usuario.sql.
- Creación de las tablas. Usar el resto de líneas del script
base_de_datos_tabla.sql.
- Carga de los datos. Se puede usar phpmyadmin para realizar la importación
de los script datos.sql.
- Configuración de variables globales: Dirección IP del servidor central.
Tenemos que abrir el archivo que está en el directorio …/gestion/includes
llamado config.php


Debemos poner la IP del servidor en la que está la aplicación CIRMI.


- Configurar la dirección del script del servidor del aula en el navegador.
o Para el caso de Windows XP, se podría configurar la ejecución inicial
del navegador para que al iniciar sesión del usuario de Windows se
abra el navegador con página de inicio la aplicación del alumno. Esto
se puede conseguir abriendo la consola de comandos (Icono
Windows+R) escribiendo “gpedit.msc” y pulsamos “Aceptar”


Nos vamos a “Configuración de usuario”

“Configuración de Windows”

“Secuencia de comandos(inicio/apagado de sesión)”


Doble clic en “Iniciar sesión” y nos aparece lo siguiente:

Agregamos reglas clic en “Agregar”

Y ya según el navegador ponemos:


La mejor opción es con Google Chrome porque la ventana se abriría
completamente.

Otras opciones sería añadir la siguiente línea al archivo hosts:
192.168.22.101/gestion_v14/alumno GOADI

Así le indicaríamos al alumno que escribiese directamente en el navegador
GOADI y se encontraría con la aplicación pero desconociendo, a priori,
donde está la aplicación.

o Para el caso de un LINUX, por ejemplo Ubuntu.

Nos vamos a Sistema - Preferencias - Aplicaciones al inicio - Añadir


De la misma forma se puede hacer para Debian.

Servidor Central de Incidencia:

- Subir el script poner_incidencia_cirmi.php al servidor en el directorio
público cirmi, para grabar las incidencias.


9. Manual de los usuarios

Manual del profesor
¿Qué es GOADI?
GOADI es un acrónimo de Gestión de Ordenadores en el Aula de Informática.
Es una aplicación, que como su nombre indica, nos ayuda a llevar un control
sobre los ordenadores que hay en el aula y sus usuarios en tiempo real.
Utilización de GOADI
Una vez arrancado el ordenador el usuario encontrará la siguiente pantalla de
inicio.

Tenemos los siguientes enlaces:
- Abrir sesión. Habilitar registros alumnos.
- Datos de los alumnos registrados
- Poner incidencia. RMI
- Histórico de sesiones.
- Cerrar sesión.

Sólo se podrá comenzar a usar los cuatro últimos ítems cuando hayamos abierto
la sesión de trabajo. Si intentamos acceder nos aparece lo siguiente:


¿Cómo habilitar/abrir una sesión?
Para abrir una sesión pinchamos/cliqueamos sobre la opción “Abrir sesión.
Habilitar registros alumnos”:

Debemos completar el formulario y pinchar en “Habilitar registro”.
Descripción de los campos
1. Nombre: este campo es obligatorio. Debe indicar su nombre, en caso
contrario encontrará el siguiente mensaje:

2. Apellido: también es obligatorio. Igual que antes encontrará un mensaje de
error si no es completado.


3. Email: ídem que los anteriores. Debe ser un email válido.

4. Fecha y Hora: no son editables. Se autogenerar automáticamente.
5. Aula: debe seleccionar el aula donde está trabajando.

6. Grupo: debe indicar con qué grupo/curso se va a desarrollar la sesión de
trabajo.

Si elige la opción “OTROS” encontrará un campo para indicar el nombre del
grupo con el que trabaja.

Una vez completados los campos tenemos:


Pichamos sobre el botón “Habilitar registro” y nos aparece la siguiente pantalla:

Clic en “volver” y entraremos en inicio. Recuerde no cerrar el navegador o
perderá la sesión.
Ahora los alumnos/usuarios de los ordenadores del aula podrán registrarse en la
sesión.


¿Quién hay conectado?
Para ver los usuarios que se han unido a la sesión hacemos clic en “Datos de los
alumnos registrados”.

Clic en “Ver alumno” y encontramos:

¿Cómo poner una incidencia?
Nos vamos al apartado “Poner incidencia. RMI”.


Los ordenadores que están en blanco indican que no hay usuarios o que el
ordenador no arranca.
Podemos poner la incidencia que el alumno “José Perez” que ocupa el PC2 nos ha
indicado.

Nota: ahora estamos conectado con el servidor central.

Podemos añadir más observaciones haciendo clic en el botón que nos indica:

Le damos a “Insertar” y obtenemos.

Clic en “SI” para enviar la incidencia.

Y nos sale lo siguiente:

Clic en volver y podemos seguir insertando incidencias:

Por ejemplo en el PC5 en el caso de que no arranque:


¿Cómo ver las sesiones anteriores y los alumnos conectados?
En el inicio clic en “Histórico de sesiones” y nos aparece lo siguiente:

Tenemos las sesiones filtradas por fecha y hora. Vamos a realizar una consulta y
veremos si hay sesiones abiertas o no.


Para ver los alumnos hacemos clic en “Ver alumno”.

Otra consulta:

Veamos los alumnos de la sesión de Mariano Cárceles:


Si no hay resultados aparecerá lo siguiente:

¿Cómo cerrar la sesión?

Desde inicio clic en “Cerrar sesión”:

Clic en “Cerrar”.

Manual del alumno
¿Qué es GOADI?
GOADI es un acrónimo de Gestión de Ordenadores en el Aula de Informática.
Es una aplicación, que como su nombre indica, nos ayuda a llevar un control
sobre los ordenadores que hay en el aula y sus usuarios en tiempo real.
Utilización de GOADI
Una vez arrancado el ordenador y previa habilitación de sesión por parte del
profesor, el usuario encontrará la siguiente pantalla de inicio.


En el caso de que el profesor no haya habilitado la sesión encontrarás lo
siguiente:

Continuamos en la situación anterior, hacemos clic en “Unirme” y encontramos la
siguiente pantalla:


Debemos completar el formulario y pinchar en “Validar”.
Descripción de los campos
1. Nombre: este campo es obligatorio. Debe indicar su nombre, en caso
contrario encontrará el siguiente mensaje:

2. Apellido: también es obligatorio. Igual que antes encontrará un mensaje de
error si no es completado.

3. Ordenador: elegir el puesto ocupado. En el caso que no existan puesto de
trabajo libre te aparecerá el siguiente mensaje:


4. Estado del material: debes elegir la opción que se adapate a tus
condiciones. Este campo no se puede dejar vacío, sino tendrás el siguiente
mensaje de error:

- Si eliges “Verificado y Correcto” el resto de opciones no puedes elegirlas.
- Si tienes un problema no especificado en la lista puede elegir “Otras
incidencias” y encontrarás un campo de texto para indicar el problema
que hayas encontrado.

Una vez completados los campos tenemos:


Clic en “Validar”.

Clic en “salir”.


Ya puedes cerrar el navegador y comenzar a trabajar.

Otro ejemplo de formulario completado.


10. Conclusiones

Cómo primera conclusión resaltaría el hecho de que “siempre se
puede hacer mejor”. Puesto que a la hora de desarrollar el proyecto iba
encontrando ideas bastante buenas sobre el control a los ordenadores y la
seguridad que podría haber usado, como por ejemplo un acceso a usuarios
con una tabla de alumnos del centro por cursos y otra con profesores. Pero
el proyecto constaba de 30 horas, que en este caso han sido 77, y no había
tiempo para desarrollar estas ideas.

Como propuestas de mejora para la próxima versión Gestion_v2.0
propongo las siguientes:
- Validación de usuarios.
- Añadir campo a la tabla ordenadores donde se registre la IP del cliente.
Verificación de la misma red con la IP del servidor.
- Inserción de datos en MySQL con codificación UTF-8.
- Reestructuración de la base de datos y tablas para un mejor acceso y
salida de los datos.
- Desarrollo de una aplicación JAVA que se utilice en los clientes para que
al arrancar el PC aparezca una ventana modal que no permita su cierre
hasta que el alumno no complete el formulario.
- Envío de datos históricos a un servidor central. Esta tarea se puede
realizar cada vez que se cierre una sesión, o al iniciar la aplicación para
el caso de que se interrumpa la conexión de forma temporal.

Creo que los objetivos que se perseguían se han conseguido incluso
superado, puesto que he sido capaz de desarrollar estas aplicaciones y
poder profundizar en contenidos como PHP, JAVASCRIPT, MySQL, que eran
el principal pilar de la asignatura a la que pertenece este proyecto.

También me gustaría resaltar el hecho de que el periodo de
realización no es el idóneo, pues la realización de la FCT requiere un
horario de 40 horas semanales lo que me obligó a usar parte de mi tiempo
de descanso para desarrollarlo. Por no decir de la gente que trabajábamos
después de las prácticas.

Para terminar esta conclusión hacer hincapié en el beneficio que me
ha reportado, debido a que he podido comprobar los conocimientos
adquiridos a lo largo del Ciclo Superior de Administración de Sistemas
Informáticos en Red.


11. Bibliografía

1. Apuntes de la asignatura IAW. José Manuel Rubira Miranda 2011/2012.
2. Apuntes de la asignatura LMSGI. Antonio José Sandoval 2011/2012.
3. Manual PHP (http://www.php.net/).
4. Apuntes de la asignatura ISO. Jesús Ibáñez. Curso 2010/2011.
5. Apuntes de la asignatura ASO. Juan Manuel Beltrán. Curso 2011/2012.
6. Apuntes de la asignatura SAD. Juan Antonio Alegría Pellicer. Curso
2011/2012.
7. Apuntes de la asignatura SRI. Francisco Huertas. Curso 2011/2012.
8. Descarga de WAMP: www.wampserver.com/en/
9. Lanzar FireFox Ubuntu/Debian al iniciar PC: http://www.ubuntu-
es.org/node/125421
10. Consultas varias en foros de Internet sobre PHP, JAVASCRIPT, HTML,
etc.


12. Anexos

i. Script SQL

/*Creacion usuario*/

GRANT select,insert,delete,update ON gestion.* TO usuweb@localhost identified by
'usuweb';

/* Creacion BD y tablas */

create database gestion;

use gestion;

create table sesion_abierta

(id int(7) auto_increment,

nombre varchar(30) not null,

apellido varchar(30) not null,

email varchar(30) not null,

aula varchar(30) not null,

grupo varchar(30) not null,

fecha date,

hora time,

s_abierta bool default 1,

s_cerrada bool default 0,

primary key(id)) engine= InnoDB;

create table aulas


(id_aula int primary key auto_increment,

nombre_aula varchar(40) not null

)engine = InnoDB;

create table ordenadores

(id_pc int primary key auto_increment ,

id_aula int not null,

nombre_pc varchar(30) not null,

estado_pc bool default 0,

constraint foreign key fk_id_aula (id_aula)

references aulas (id_aula) on delete cascade

)engine = InnoDB;

CREATE TABLE registro_alumnos

( id_alu INT auto_increment,

nombre_alu varchar(30) not null,

apellido_alu varchar(30) not null,

id_pc int(11) not null,

estado varchar(200) not null,

observaciones varchar(300) not null,

id_sesion INT not null,

primary key(id_alu),

constraint foreign key fk_id_pc (id_pc)

references ordenadores (id_pc),

constraint foreign key fk_id_sesion (id_sesion)

references sesion_abierta (id) on delete cascade


) engine = InnoDB;

/*DATOS*/

/*aulas*/

insert into aulas values('','Aula Milano');

insert into aulas values('','Aula Perez');

insert into aulas values('','Aula Cano');

/*ordenadores*/

insert into ordenadores values('','1','PC1',0);


















ii. Manual del programador

En este manual encontrará todo lo referente a funciones y variables
globales usadas en los archivos de Gestion_v14. De esta forma le será más fácil la
edición de los archivos para próximas versiones.

A continuación encontrará un listado de los archivos que componen las
aplicaciones y las funciones/variables más importantes o que necesiten de una
aclaración.

PHP genéricos (/includes):
config.php

Son las funciones globales que va a utilizar la función que a continuación
describo.
La variable global $ruta es utilizada por el archivo poner_incidencia.php.


funciones.php

Función que usa las variables globales descritas anteriormente para
realizar la conexión a la base de datos.
validar.php

Función que a partir de un parámetro, en este caso una cadena ($email),
realiza la comprobación de sintaxis en una dirección de correo electrónico. Esto
es, comprueba que no tenga una longitud inferior a 6 caracteres, que se incluya el
carácter @, etc.


Aplicación del alumno (/alumno)
index.php

Con esta función de php asignamos un valor de sesión para tener un control
de acceso sobre el resto de archivos.
formulario_alumno.php


Estas dos funciones son las que se encargan del control sobre los checkox,
que sean mutuamente excluyentes respecto a la opción “Verificado y Correcto” de
uno de los checkox.

Aplicación del profesor (/profesor)
habilitar.php

Función que nos habilita un textarea donde el profesor pueda especificar el
grupo de trabajo.

El resto de documentos contienes consultas SQL enlazadas.

Aplicación servidor central (/cirmi)
poner_incidencia_cirmi.php


Carga inicial de los valores del “td” donde se escriben las “Observaciones”.

Cambiando los valores del elemento “td” al “vuelo”, osea en tiempo real.

Con estas funciones quitamos las etiquetas HTML y los espacios en blanco a la
hora de insertar los valores en la tabla de la BD.


GOADI

Más contenido relacionado

La actualidad más candente (19)

Similar a GOADI (20)

Último (20)

GOADI