Anda di halaman 1dari 19

Documento de Pruebas Proyecto Colegio

Bernardo O'higgins

Proyecto Implementacin Sistema de


Gestin colegio Bernardo Ohiggins

Cristian Cofre
Jaime Espnola
Boris Ibsen
Cristian Moreno

Septiembre de 2013
ndice
Introduccin........................................................................................................................................ 3
Anlisis al Modelo de Datos Relacional............................................................................................. 4
Artefacto 01: Pantalla Men Principal................................................................................................9
Artefacto 02: Pantalla Ingreso Principal............................................................................................ 10
Artefacto 03: Pantalla Ingreso Atrasos..............................................................................................11
Artefacto 04: Pantalla Activacin de Mens.....................................................................................12
Artefacto 05: Pantallas Eliminacin.................................................................................................. 13
Artefacto 06: Pantalla Ingreso de Notas........................................................................................... 14
Artefacto 07: Pantalla Ingreso de Asistencia....................................................................................15
Artefacto 08: Informe de Notas......................................................................................................... 16
Anlisis sobre Justificacin plataforma de desarrollo.....................................................................17
Conclusin........................................................................................................................................ 19

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 justificacin del sistema, la integracin del sistema, la
base de datos relacional, el diccionario de datos y el manual de usuarios.
Detallados los objetivos y alcances del sistema, se llev a cabo una revisin completa de
todos aquellos aspectos que se proponen para la utilizacin del software.
Se revisara si las observaciones presentadas en el primer informe, fueron detectadas y
corregidas, adems de contrastar si lo propuesto inicialmente se refleja en la solucin final
entregada con la finalidad de visualizar si todos los requerimientos iniciales fueron
satisfechos.
Se incluye adems un anlisis del modelo de datos, del cual se pueden destacar cambios
realizados con el modelo propuesto en la primera entrega.

Anlisis al Modelo de Datos Relacional

El modelo de datos propuesto presenta las siguientes observaciones:


1) Tabla de Apoderados:
a) Sera ideal poder registrar ms informacin de los apoderados como el correo
electrnico, telfono celular. De esta forma se le podra enviar informacin
referente a su(s) pupilos a su correo electrnico o puede ser ubicable a su
telfono celular.
2) Tabla de Alumnos
a) Sera ideal poder registrar ms informacin de los alumnos como el correo
electrnico, telfono celular. Esto con la finalidad de tener ms herramientas
para comunicarse con el Alumno.
b) Se detecta un error de definicin importante, ya que la relacin AlumnosApoderados es 1 a 1, cuando en la prctica un Alumno podra tener ms de un
Apoderado. Lo correcto sera tener una nueva tabla transaccional de 1 (Alumno)
a N (Apoderados).
3) Tabla de Profesores
a) Sera ideal poder registrar ms informacin de los profesores como el correo
electrnico, telfono celular. Esto con la finalidad de tener ms herramientas
para comunicarse con el Profesor.
b) Se detecta un error de definicin importante, ya que la relacin ProfesoresAsignaturas es 1 a 1, cuando en la prctica un Profesor puede impartir ms de
una Asignatura. Lo correcto sera tener una nueva tabla transaccional de 1
(Profesor) a N (Asignaturas).
4) Tabla de Asignaturas
a) Se requerira agregar ms informacin relacionada, como: Contenido de la
Asignatura o plan de estudio y niveles en donde se impartir (7mo, 8vo Bsico,
etc).
b) Para cubrir lo mencionado en el punto anterior se debera crear una nueva tabla
de niveles (cod_nivel y descripcin) y otra tabla transaccional que tenga la
relacin 1 (Asignatura) a N (Niveles).
5) Tabla Salas:
a) Debera tener ms informacin, por ejemplo: Tipo de Sala (Computacin,
Laboratorio, etc.) De esta manera se podra gestionar mejor la asignacin de
salas a un curso.

b) Para cubrir lo mencionado en el punto anterior se debera crear una nueva tabla
de Tipos de Salas (cod_tipo_sala y descripcin) para crear una relacin 1 (Sala)
a 1 (Tipo de Sala).
6) Tabla Cursos:
a) Si se toma como definicin que un Curso siempre tendr clases en la misma
Sala independiente de la Asignatura, estara correcta la relacin 1 (Curso) a 1
(Sala). De lo contrario se debera realizar un cambio en el modelo de datos que
permita crear la relacin Curso-Asignatura-Sala.
7) Tabla Impartir:
a) Con el cambio mencionado en el punto 3b, la relacin correcta debera ser entre
la tabla transaccional (punto 3b) con la Tabla de Cursos.
8) Tabla Asistencia:
a) No hay claridad si la asistencia es por da o por asignatura. En caso que fuera
por da, el horario en esta tabla estara sobrando. Si fuera por Asignatura, faltara
relacionar la Asignatura-Profesor (punto 3b) con la tabla de Alumnos.
b) En ningn caso es correcta la relacin entre la tabla Impartir-Alumnos ya que
tanto la tabla Alumnos como la Tabla Impartir tienen el campo Curso, lo cual
sera redundante.
9) Tabla Hoja de Vida
a) Sera importante poder registrar la fecha de ingreso del comentario, para una
mejor gestin de la informacin.
b) Faltara asociar la Asignatura, en donde se origino el comentario ingresado por
el profesor (dado que un profesor puede impartir ms de una asignatura).
c) No hay claridad que se ingresara en el campo Tipo y en el caso que fuera
necesario, se necesitara crear una tabla de Tipos (cod_tipo y descripcin) para
realizar la relacin correctamente.
10) Tabla Calificaciones
a) Faltara relacionar la Asignatura-Profesor (punto 3b) con la tabla de Alumnos.
b) En ningn caso es correcta la relacin entre la tabla Impartir-Alumnos ya que
tanto la tabla Alumnos como la Tabla Impartir tienen el campo Curso, lo cual
sera redundante.

c) El modelo propuesto no registrara las notas parciales de los alumnos, lo cual es


un problema importante, ya que se depender de sistemas externos (libros de
notas, Excel, etc.).
d) El modelo propuesto no es flexible en la cantidad y tipo de notas ingresados.
Ejemplo: si se hicieran ms de dos trabajos o ms de dos exmenes, o se
decidiera evaluar a los alumnos en forma trimestral y no semestral. Donde y
como se registrara la informacin?
11) Tabla Administracin
a) Esta tabla en realidad debera ser la tabla de Usuarios, ya que tiene toda la
informacin necesaria de un usuario de sistema.
b) Sera ideal poder registrar ms informacin como el correo electrnico, telfono
celular.
c) Se debera agregar el campo password (que est en tabla usuarios del modelo
propuesto).
12) Tabla de Usuarios
a) Se eliminara esta tabla, ya que no tiene toda la informacin de los usuarios de
sistema (Nombre, correo, Etc) y se reemplazara por la tabla Administracin del
modelo propuesto (ver punto 12).
b) Adems, la relacin con la tabla de Roles no es correcta ya que un usuario
podra tener ms de un rol (Consultas, Transacciones, Reportes, Etc).
c) Lo correcto seria, una nueva tabla transaccional que tenga la relacin 1
(Usuario) a N (Roles)
NOTA: Tabla de Roles y Mens estara correcto.
13) Tabla Privilegios
a) Debera relacionar la tabla de Mens con la de Roles (tabla transaccional 1
Men a N Roles), y no con la tabla de Usuarios, ya que los Roles indicaran los
Usuarios que pueden acceder a esa opcin de men.
b) No es clara la utilidad del campo Estado.
14) De acuerdo a los requerimientos analizados, se determina necesario considerar la
tabla Horarios. Esta tabla no est registrada en el diseo estudiado. Bsicamente se
debe llevar el detalle de Da, Hora, Asignatura, Profesor, recreos, entradas y salidas,
hora de almuerzo, actividades recreativas, etc.
7

15) En todas las Foreign Key (FK) se observa una inconsistencia, ya que en las tablas
maestras la Primary Key (PK) se llama siempre cod y las tablas relacionadas se
cambia el nombre de campo a cod_algo. Ejemplo: En tabla de Apoderados la PK
se llama cod y en la tabla de Alumnos, la FK correspondiente se llama
cod_apoderado.
Se aconseja que todas las PK sean ms descriptivas. Ejemplo: cod_apoderado,
cod_alumno, cod_curso, etc.

Artefacto 01: Pantalla Men Principal

La pantalla principal propone una opcin de Modificar Datos, sin precisar cul ser la
informacin que ser actualizada.

De acuerdo al documento original, se plante la necesidad de operar el sistema a travs de


mdulos, en consecuencia, el men principal, debiera desplegar los Mantenedores
principales de cada mdulo:
Mantenimiento Alumnos
Mantenimiento Apoderados
Mantenimiento Profesores
Otros
Cada uno de los mantenedores debe tener la posibilidad de:

Consultar
Ingresar
Actualizar
Listar

Para un correcto uso y manejo de la informacin.


Se sugiere adems, identificar en la pantalla, el usuario logeado y el perfil con el que se
accedi. Esto con el fin de controlar los accesos y otorgar los permisos correspondientes a
cada usuario.

Artefacto 02: Pantalla Ingreso Principal

La opcin de modificar datos no se adecua a los planteamientos originales en que pueden


asignarse ms de un curso a un profesor. En la imagen se pueden detectar los siguientes
errores e inconsecuencias estructurales:

Asignacin de un solo curso a un cdigo de profesor.


Asignacin de un solo rol a un cdigo de usuario.

En la prctica, este tipo de asociaciones debe ser realizado a travs de un mdulo que
permita la asociacin de N cursos, y/o N Roles a un determinado cdigo.

10

Artefacto 03: Pantalla Ingreso Atrasos

La pantalla de atrasos presenta las siguientes falencias que son importantes analizar para el
proceso de registro de atrasos.

Ingreso manual de hora de atraso.

Todo sistema debe automatizar los procesos de registros de informacin, por lo que el
ingreso manual de los datos de no ser explcitamente validados, permitira el ingreso de
informacin errnea.
La hora de ingreso ser asignada por el propio sistema, y considerar algn mdulo que
permita el ingreso de atrasos con desfase en caso de ser necesario.
De esta forma, se evitaran los problemas de digitacin de horas de atraso.

Fecha del atraso.

El sistema debe asignar la fecha actual del atraso. El anlisis de requerimientos 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.

Identificacin de la clase a la que se le asigna el atraso.

No se identifica en la imagen la hora de clase (por horario) ni el nombre de la asignatura a


la que se est asignando el atraso registrado.
Esta informacin es relevante para las pretensiones de hoja de vida acadmica del alumno
donde se registraran toda la informacin relevante a las actividades acadmicas del alumno.
11

Artefacto 04: Pantalla Activacin de Mens

El modulo presentado en la imagen presenta discrepancias con el modelo de datos. El


Checklist del men no se almacena en ninguna tabla transaccional presentado en el diseo
de base de datos.
En la imagen se presenta la tabla en la que se espera almacenar la activacin de los mens a
travs de este mdulo:

Se considera necesario almacenar la asociacin de activacin de mens en una tabla en la


que permita activar distintos mens, para los distintos tipos de roles ingresados.

12

Artefacto 05: Pantallas Eliminacin


Cuando se quiere eliminar un registro en cualquier mantenedor se debe presionar el
basurero de la grillas, para luego aceptar o cancelar la eliminacin de dicho registro.

Se analizaron 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.
Se sugiere presentar en pantalla claramente dnde se pueden realizar cada una de las
opciones y alternativas de operatividad que tendrn los usuarios.

13

Artefacto 06: Pantalla Ingreso de Notas

El sistema presentado no permite el ingreso de alumnos a los cursos ni la


mantencin de estos.
El sistema limita el nmero de notas a ingresar
El sistema limita el nmero de exmenes a ingresar
El sistema no calcula promedios. Deben 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.

Se sugiere permitir imprimir el listado de notas en la misma opcin en la que el profesor


est ingresando notas, con el objetivo de mejorar la interactividad del usuario con el
sistema, como se propone en el informe inicial.

14

Artefacto 07: 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 parametrizacin, que identifique 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.

15

Artefacto 08: Informe de Notas

Para generar el informe de notas que se propone, el sistema debe adecuar su modelo de
datos de manera tal que permita:
Ingreso de notas por semestre. No se identifican periodos de clase, (semestres, bimestres,
trimestres, etc.)
Los porcentajes de asistencias deben calcularse en base a una planificacin de horas y/o
das, los cuales no se tiene registro. De esta forma se pueden descontar los das de
inasistencias y en consecuencia, calcular los promedios de asistencia por periodo de clase.
No se identifica en el sistema un mdulo que permita la asignacin de profesores jefe a los
distintos cursos.
No se identifica en el sistema un mdulo que permita la asignacin de reas a los distintos
cursos.

16

Anlisis sobre Justificacin plataforma de


desarrollo
La ingeniera de requisitos del software es un proceso de descubrimiento, refinamiento,
modelado y especificacin. Se refinan en detalle los requisitos del sistema y el papel
asignado al software.
El inicio de la justificacin lamentablemente contiene una frase copiada textualmente
de Internet. (http://yaqui.mxl.uabc.mx/~molguin/as/IngReq.htm)
Lamentablemente un detalle como este puede quitarle credibilidad al informe frente a
un cliente, indistintamente que despus, el informe en si, sea excelente. Se aconseja no
realizar este tipo de prctica.
Por lo tanto, en las reuniones con el grupo de trabajo y analizando los objetivos planteados
y ofrecidos al cliente se llego a una solucin de una aplicacin WEB para el sistema para
as acceder desde internet y para el gran flujo de informacin la utilizacin de una Base de
Datos que cumpla con las caractersticas necesarias para dicha solucin.
La solucin web con base de datos es acorde con el informe anterior.
La plataforma utilizada ser una aplicacin web en PHP ya que es open source acompaada
de una Base de datos Sql Server por la capacidad de informacin que se mantendr.
La idea de elegir la aplicacin web PHP fue porque PHP corre en (casi) cualquier
plataforma utilizando el mismo cdigo fuente, pudiendo ser compilado y ejecutado en algo
as como 25 plataformas, incluyendo diferentes versiones de Unix, Windows
(95,98,NT,ME,2000,XP y 7) y Macs. Como en todos los sistemas se utiliza el mismo
cdigo base, los scripts pueden ser ejecutados de manera independiente al OS

17

Aqu se produce un gran problema. Se habla de un desarrollo en PHP porque es


OpenSource, pero la base de datos en SqlServer que es pagado (SqlExpress en
gratuita, pero debe ser montada sobre un servidor Windows licenciado). Adems
indica que PHP funciona en casi cualquier plataforma, lo que es cierto, pero SqlServer
slo puede ser montado en un ambiente Microsoft.
PHP tiene soporte para conexin a una base de datos SqlServer. La arquitectura puede
ser con un servidor Linux o Microsoft con Apache y soporte PHP y otro servidor con
S.O Microsoft y BD Sql Server, o un solo servidor cumpliendo ambas funciones.
La desventaja de esta arquitectura radica principalmente en encontrar un Hosting que
pueda entregar ese tipo de requerimiento tcnico. Por lo general los Hosting trabajan
sobre sobre OpenSource (Linux-Apache- MySql, Linux-Apache PostgreSql) o sobre
ambientes Microsoft (Windows Server- ISS Punto Net + SqlServer).
De encontrase un Hosting, generara un servidor bastante hibrido, ya que debe ser un
Windows Server con Apache y soporte PHP y base de datos SqlServer.
Creemos 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 diversas tecnologas.

En cuanto a la Base de Datos se opto por SQL Server por que proporciona a los usuarios
una excelente plataforma de base de datos para el procesamiento transaccional en lnea a
gran escala siendo una Base de datos robusta para el manejo de los datos. Facilita a los
administradores de base de datos la construccin, manejo y despliegue de aplicaciones para
negocios. Adems, est diseado para recibir un mayor nmero de datos, transacciones y
usuarios con facilidad.
Con respecto a las bondades de trabajar con SqlServer, se vuelve a recalcar que no se
hace mencin a que esta tecnologa posee un costo asociado por licencias, an en su
modelo Gratuito (SqlExpress).
A modo de sugerencia, se recomienda el uso de PostgreSql que es en si, una BD tan
robusta como SqlServer, ya que posee soporte para procedimientos almacenados, cosa
que MySql recin est implementando. Adems posee una interfaz grafica bastante
amigable y similar a la de SqlServer.

18

Conclusin
Si bien la solucin propuesta a los requerimientos es correcta a nuestro juicio, se
detectaron varios errores fundamentales tanto en la concepcin como en el diseo del
software propuesto, que pueden llevar al fracaso del proyecto.
Esto nos lleva a deducir que si no se cuenta con mecanismos idneos para la realizacin de
pruebas, de cualquier tipo, que se deban aplicar a los distintos proyectos informticos, en
xito de cada uno de estos es indudablemente incierto.

19