Proyecto Implementacin

Introduccin

El siguiente informe presentara un anlisis detallado de la segunda etapa del sistema de gestin propuesto para el colegio rural Bernardo Ohiggins, en el mbito de revisin y control de anomalas o fallas. El documento Revisado contiene la ustificacin del sistema, la integracin del sistema, la base de datos relacional, el diccionario de datos y el manual de usuarios. !etallados los ob etivos y alcances del sistema, se llev a cabo una revisin completa de todos a"uellos aspectos "ue se proponen para la utili#acin del soft$are. %e revisara si las observaciones presentadas en el primer informe, fueron detectadas y corregidas, adems de contrastar si lo propuesto inicialmente se refle a en la solucin final entregada con la finalidad de visuali#ar si todos los re"uerimientos iniciales fueron satisfechos. %e incluye adems un anlisis del modelo de datos, del cual se pueden destacar cambios reali#ados con el modelo propuesto en la primera entrega.

a& a un 'rofesor puede impartir ms de una (signatura. )o correcto sera tener una nueva tabla transaccional de * +'rofesor& a , +(signaturas&.

*& -abla de (signaturas a& %e re"uerira agregar ms informacin relacionada, como. /ontenido de la (signatura o plan de estudio y niveles en donde se impartir +0mo, 1vo Bsico, etc&. b& 'ara cubrir lo mencionado en el punto anterior se debera crear una nueva tabla de niveles +cod2nivel y descripcin& y otra tabla transaccional "ue tenga la relacin * +(signatura& a , +,iveles&. 3& -abla %alas.

a& !ebera tener ms informacin, por e emplo. -ipo de %ala +/omputacin, )aboratorio, etc.& !e esta manera se podra gestionar me or la asignacin de salas a un curso. b& 'ara cubrir lo mencionado en el punto anterior se debera crear una nueva tabla de -ipos de %alas +cod2tipo2sala y descripcin& para crear una relacin * +%ala& a * +-ipo de %ala&.

4& -abla /ursos. a& %i se toma como definicin "ue un /urso siempre tendr clases en la misma %ala independiente de la (signatura, estara correcta la relacin * +/urso& a * +%ala&. !e lo contrario se debera reali#ar un cambio en el modelo de datos "ue permita crear la relacin /urso5(signatura5%ala.

6& -abla 7mpartir. a& /on el cambio mencionado en el punto 4b, la relacin correcta debera ser entre la tabla transaccional +punto 4b& con la -abla de /ursos.

8& -abla (sistencia. a& ,o hay claridad si la asistencia es por da o por asignatura. En caso "ue fuera por da, el horario en esta tabla estara sobrando. %i fuera por (signatura, faltara relacionar la (signatura5'rofesor +punto 4b& con la tabla de (lumnos. b& En ning9n caso es correcta la relacin entre la tabla 7mpartir5(lumnos ya "ue tanto la tabla (lumnos como la -abla 7mpartir tienen el campo /urso, lo cual sera redundante.

:& -abla ;o a de <ida a& %era importante poder registrar la fecha de ingreso del comentario, para una me or gestin de la informacin. b& =altara asociar la (signatura, en donde se origino el comentario ingresado por el profesor +dado "ue un profesor puede impartir ms de una asignatura&. c& ,o hay claridad "ue se ingresara en el campo -ipo y en el caso "ue fuera necesario, se necesitara crear una tabla de -ipos +cod2tipo y descripcin& para reali#ar la relacin correctamente.

0&

-abla /alificaciones a& =altara relacionar la (signatura5'rofesor +punto 4b& con la tabla de (lumnos. b& En ning9n caso es correcta la relacin entre la tabla 7mpartir5(lumnos ya "ue tanto la tabla (lumnos como la -abla 7mpartir tienen el campo /urso, lo cual sera redundante. c& El modelo propuesto no registrara las notas parciales de los alumnos, lo cual es un problema importante, ya "ue se depender de sistemas e>ternos +libros de notas, E>cel, etc.&. d& El modelo propuesto no es fle>ible en la cantidad y tipo de notas ingresados. E emplo. si se hicieran ms de dos traba os o ms de dos e>menes, o se decidiera evaluar a los alumnos en forma trimestral y no semestral. !onde y como se registrara la informacin?

1& -abla (dministracin

a& Esta tabla en realidad debera ser la tabla de @suarios, ya "ue tiene toda la informacin necesaria de un usuario de sistema. b& %era ideal poder registrar ms informacin como el correo electrnico, telAfono celular. c& %e debera agregar el campo pass$ord +"ue est en tabla usuarios del modelo propuesto&.

B& -abla de @suarios a& %e eliminara esta tabla, ya "ue no tiene toda la informacin de los usuarios de sistema +,ombre, correo, Etc& y se reempla#ara por la tabla (dministracin del modelo propuesto +ver punto *3&. b& (dems, la relacin con la tabla de Roles no es correcta ya "ue un usuario podra tener ms de un rol +/onsultas, -ransacciones, Reportes, Etc&. c& )o correcto seria, una nueva tabla transaccional "ue tenga la relacin * +@suario& a , +Roles& ,O-(. -abla de Roles y Cen9s estara correcto. *D& -abla 'rivilegios a& !ebera relacionar la tabla de Cen9s con la de Roles +tabla transaccional * Cen9 a , Roles&, y no con la tabla de @suarios, ya "ue los Roles indicaran los @suarios "ue pueden acceder a esa opcin de men9. b& ,o es clara la utilidad del campo Estado.

**& !e acuerdo a los re"uerimientos anali#ados, se determina necesario considerar la tabla ;orarios. Esta tabla no est registrada en el diseEo estudiado. Bsicamente se debe llevar el detalle de !a, ;ora, (signatura, 'rofesor, recreos, entradas y salidas, hora de almuer#o, actividades recreativas, etc.

*3& En todas las =oreign Fey +=F& se observa una inconsistencia, ya "ue en las tablas maestras la 'rimary Fey +'F& se llama siempre cod y las tablas relacionadas se cambia el nombre de campo a cod2GalgoG. E emplo. En tabla de (poderados la 'F se llama cod y en la tabla de (lumnos, la =F correspondiente se llama cod2apoderado. %e aconse a "ue todas las 'F sean ms descriptivas. E emplo. cod2apoderado, cod2alumno, cod2curso, etc.

Artefacto 01: Pantalla Men Principal

)a pantalla principal propone una opcin de Codificar !atos, sin precisar cul ser la informacin "ue ser actuali#ada. !e acuerdo al documento original, se plante la necesidad de operar el sistema a travAs de mdulos, en consecuencia, el men9 principal, debiera desplegar los Cantenedores principales de cada mdulo. Cantenimiento (lumnos Cantenimiento (poderados Cantenimiento 'rofesores Otros /ada uno de los mantenedores debe tener la posibilidad de. /onsultar 7ngresar (ctuali#ar )istar

'ara un correcto uso y mane o de la informacin. %e sugiere adems, identificar en la pantalla, el usuario logeado y el perfil con el "ue se accedi. Esto con el fin de controlar los accesos y otorgar los permisos correspondientes a cada usuario.

Artefacto 02: Pantalla Ingreso Principal

)a opcin de modificar datos no se adecua a los planteamientos originales en "ue pueden asignarse ms de un curso a un profesor. En la imagen se pueden detectar los siguientes errores e inconsecuencias estructurales. (signacin de un solo curso a un cdigo de profesor. (signacin de un solo rol a un cdigo de usuario.

En la prctica, este tipo de asociaciones debe ser reali#ado a travAs de un mdulo "ue permita la asociacin de , cursos, yHo , Roles a un determinado cdigo.

Artefacto 03: Pantalla Ingreso Atrasos

)a pantalla de atrasos presenta las siguientes falencias "ue son importantes anali#ar para el proceso de registro de atrasos. 7ngreso manual de hora de atraso.

-odo sistema debe automati#ar los procesos de registros de informacin, por lo "ue el ingreso manual de los datos de no ser e>plcitamente validados, permitira el ingreso de informacin errnea. )a hora de ingreso ser asignada por el propio sistema, y considerar alg9n mdulo "ue permita el ingreso de atrasos con desfase en caso de ser necesario. !e esta forma, se evitaran los problemas de digitacin de horas de atraso. =echa del atraso.

El sistema debe asignar la fecha actual del atraso. El anlisis de re"uerimientos no especifica la necesidad de registrar atrasos de fechas anteriores. En el caso de ser permitida esta modalidad, el campo fecha debe ser capturada en un solo campo, y no en tres como se especifica en la imagen. 7dentificacin de la clase a la "ue se le asigna el atraso.

,o se identifica en la imagen la hora de clase +por horario& ni el nombre de la asignatura a la "ue se est asignando el atraso registrado. Esta informacin es relevante para las pretensiones de ho a de vida acadAmica del alumno donde se registraran toda la informacin relevante a las actividades acadAmicas del alumno.
9

Artefacto 04: Pantalla Activacin de Mens

El modulo presentado en la imagen presenta discrepancias con el modelo de datos. El /hecIlist del men9 no se almacena en ninguna tabla transaccional presentado en el diseEo de base de datos. En la imagen se presenta la tabla en la "ue se espera almacenar la activacin de los men9s a travAs de este mdulo.

%e considera necesario almacenar la asociacin de activacin de men9s en una tabla en la "ue permita activar distintos men9s, para los distintos tipos de roles ingresados.

10

Artefacto 05: Pantallas Eli

inacin

/uando se "uiere eliminar un registro en cual"uier mantenedor se debe presionar el basurero de la grillas, para luego aceptar o cancelar la eliminacin de dicho registro.

%e anali#aron en detalle cada una de las pantallas ofrecidas en el informe, y no se encontraron iconos de basureros ni opciones donde el usuario pueda eliminar datos. %e sugiere presentar en pantalla claramente dnde se pueden reali#ar cada una de las opciones y alternativas de operatividad "ue tendrn los usuarios.

11

Artefacto 0!: Pantalla Ingreso de "otas

El sistema presentado no permite el ingreso de alumnos a los cursos ni la mantencin de estos. El sistema limita el n9mero de notas a ingresar El sistema limita el n9mero de e>menes a ingresar El sistema no calcula promedios. !eben ser ingresados por el profesor. El mdulo de ingreso de notas sugiere la seleccin de cursos, pero el modelo de datos y el mdulo de ingreso de datos acepta un curso a un profesor. El modulo sugiere la seleccin de asignaturas, pero el modelo de datos y el mdulo de ingreso de datos acepta una asignatura a un profesor.

%e sugiere permitir imprimir el listado de notas en la misma opcin en la "ue el profesor est ingresando notas, con el ob etivo de me orar la interactividad del usuario con el sistema, como se propone en el informe inicial.

12

Artefacto 0#: Pantalla Ingreso de Asistencia

El sistema presentado no permite el ingreso de alumnos a los cursos ni la mantencin de estos. El sistema no cuenta con un mdulo de parametri#acin, "ue identifi"ue el calendario escolar, feriados, etc. El mdulo de ingreso de asistencia sugiere la seleccin de cursos, pero el modelo de datos y el mdulo de ingreso de datos acepta un curso a un profesor. El modulo sugiere la seleccin de asignaturas, pero el modelo de datos y el mdulo de ingreso de datos acepta una asignatura a un profesor.

13

Artefacto 0$: Infor

e de "otas

'ara generar el informe de notas "ue se propone, el sistema debe adecuar su modelo de datos de manera tal "ue permita. 7ngreso de notas por semestre. ,o se identifican periodos de clase, +semestres, bimestres, trimestres, etc.& )os porcenta es de asistencias deben calcularse en base a una planificacin de horas yHo das, los cuales no se tiene registro. !e esta forma se pueden descontar los das de inasistencias y en consecuencia, calcular los promedios de asistencia por periodo de clase. ,o se identifica en el sistema un mdulo "ue permita la asignacin de profesores efe a los distintos cursos. ,o se identifica en el sistema un mdulo "ue permita la asignacin de reas a los distintos cursos.

14

An%lisis so&re '(ustificacin platafor desarrollo)

a de

)a ingeniera de re"uisitos del soft$are es un proceso de descubrimiento, refinamiento, modelado y especificacin. %e refinan en detalle los re"uisitos del sistema y el papel asignado al soft$are. El inicio de la justificacin lamentablemente contiene una frase copiada textualmente de Internet. (http://yaqui.mxl.uabc.mx/~molguin/as/Ing eq.htm! "amentablemente un detalle como este puede quitarle credibilidad al informe frente a un cliente# indistintamente que despu$s# el informe en si# sea excelente. %e aconseja no reali&ar este tipo de pr'ctica. 'or lo tanto, en las reuniones con el grupo de traba o y anali#ando los ob etivos planteados y ofrecidos al cliente se llego a una solucin de una aplicacin JEB para el sistema para as acceder desde internet y para el gran flu o de informacin la utili#acin de una Base de !atos "ue cumpla con las caractersticas necesarias para dicha solucin. "a solucin (eb con base de datos es acorde con el informe anterior. )a plataforma utili#ada ser una aplicacin $eb en ';' ya "ue es open source acompaEada de una Base de datos K%"l %erverG por la capacidad de informacin "ue se mantendr. )a idea de elegir la aplicacin $eb ';' fue por"ue ';' corre en +casi& cual"uier plataforma utili#ando el mismo cdigo fuente, pudiendo ser compilado y e ecutado en algo as como 38 plataformas, incluyendo diferentes versiones de @ni>, Jindo$s +B8,B1,,-,CE,3DDD,L' y 0& y Cacs. /omo en todos los sistemas se utili#a el mismo cdigo base, los scripts pueden ser e ecutados de manera independiente al O%

15

)qu* se produce un gran problema. %e habla de un desarrollo en +,+ porque es -pen%ource# pero la base de datos en %ql%er.er que es pagado (%qlExpress en gratuita# pero debe ser montada sobre un ser.idor /indo(s licenciado!. )dem's indica que +,+ funciona en casi cualquier plataforma# lo que es cierto# pero %ql%er.er slo puede ser montado en un ambiente 0icrosoft. +,+ tiene soporte para conexin a una base de datos %ql%er.er. "a arquitectura puede ser con un ser.idor "inux o 0icrosoft con )pache y soporte +,+ y otro ser.idor con %.- 0icrosoft y 12 %ql %er.er# o un solo ser.idor cumpliendo ambas funciones. "a des.entaja de esta arquitectura radica principalmente en encontrar un ,osting que pueda entregar ese tipo de requerimiento t$cnico. +or lo general los ,osting trabajan sobre sobre -pen%ource ("inux3)pache3 0y%ql# "inux3)pache 4+ostgre%ql! o sobre ambientes 0icrosoft (/indo(s %er.er3 I%% +unto 5et 6 %ql%er.er!. 2e encontrase un ,osting# generar*a un ser.idor bastante hibrido# ya que debe ser un /indo(s %er.er con )pache y soporte +,+ y base de datos %ql%er.er. 7reemos que esta configuracin no ayuda al proyecto# en cuanto a costos y simplificacin de arquitectura# y en cuanto a soporte en el caso de producirse problemas de funcionamiento debido a la integracin de di.ersas tecnolog*as. En cuanto a la Base de !atos se opto por %M) %erver por "ue proporciona a los usuarios una e>celente plataforma de base de datos para el procesamiento transaccional en lnea a gran escala siendo una Base de datos robusta para el mane o de los datos. =acilita a los administradores de base de datos la construccin, mane o y despliegue de aplicaciones para negocios. (dems, est diseEado para recibir un mayor n9mero de datos, transacciones y usuarios con facilidad. 7on respecto a las bondades de trabajar con %ql%er.er# se .uel.e a recalcar que no se hace mencin a que esta tecnolog*a posee un costo asociado por licencias# a8n en su modelo 9:ratuito; (%qlExpress!. ) modo de sugerencia# se recomienda el uso de +ostgre%ql que es en si# una 12 tan robusta como %ql%er.er# ya que posee soporte para procedimientos almacenados# cosa que 0y%ql reci$n est' implementando. )dem's posee una interfa& grafica bastante amigable y similar a la de %ql%er.er.

16