Está en la página 1de 6

DESARROLLO DE UN SISTEMA DE GESTIN ACADMICA PARA ESCUELAS PRIMARIAS FISCALES.

CASO DE ESTUDIO: ESCUELA ROSARIO GONZLEZ DE MURILLO


Csar Ivn Len Villegas Hctor Bernardo Moyn Amaya Tutor: Ing. Ral Crdova

Resumen
El proyecto consta de cuatro captulos y anexos en los cuales se describe el proceso de desarrollo de un sistema de gestin acadmica para escuelas primarias fiscales del Ecuador, llamado SGAweb y se cre con el fin de automatizar los procesos que en la actualidad en algunas escuelas se realizan manualmente como: matriculacin, registro de notas, gestin de informacin de los estudiantes y reportes de calificaciones. Dentro del proyecto se describen los procesos de las instituciones educativas de nivel primario del Ecuador, basados en la ley de educacin vigente y su reglamento. Luego se escoge la metodologa y se describen las herramientas que sern utilizadas para el desarrollo de SGAweb. El sistema obtenido es: genrico, personalizable y parametrizable. Para el caso de estudio definido previamente, se describe la institucin y con sus datos se hace un uso real del sistema. Con la automatizacin de los procesos de gestin acadmica, se disminuye la prdida de informacin, adems de aumentar la disponibilidad de datos.

Introduccin
Este artculo tcnico describe el desarrollo del sistema SGAweb (Sistema de Gestin Acadmica) basado en la Ley Orgnica de Educacin Intercultural {1}, su reglamento {2} y en entrevistas realizadas a los usuarios del sistema (Profesores, Autoridades, Estudiantes y Padres de familia). Planteamiento del problema y alternativas de solucin En la actualidad algunas de las instituciones educativas fiscales de nivel bsico en el pas, realizan sus procesos de gestin acadmica de forma manual, lo que ocasiona algunos inconvenientes como falta de seguridad y veracidad de los datos. La informacin tiene una disponibilidad baja, lo cual produce prdida de tiempo para padres y maestros, al momento de realizar consultas de perodos de matrculas o calificaciones. La mayora de las instituciones, no poseen una pgina web de acceso pblico, para informar acerca de las actividades que stas realizan a lo largo del ao lectivo. Segn la Ley Orgnica de Educacin Intercultural, es obligacin de los docentes: Atender y evaluar a los estudiantes, de acuerdo con su diversidad lingstica y las diferencias individuales y comunicarles oportunamente, presentando argumentos pedaggicos, sobre el resultado de las evaluaciones. {1} El sistema actual exige a los profesores tener registros de notas propios y en el mejor de los casos hojas de clculo para entregar en Secretara, en donde se realizan las libretas de calificaciones, e inclusive Csar Len - cesarivanleon@gmail.com Hctor Moyn - hectormoyon@gmail.com en algunas instituciones an se entregan libretas realizadas a mano. Los padres de familia y/o representantes legales tienen derecho a: Recibir informes peridicos, sobre el progreso acadmico de sus representados, as como de todas las situaciones que se presenten en la institucin educativa {1} , adems de solicitar y acceder a la informacin que consideren pertinente y que este en posesin de la institucin educativa. {1} Es obligacin de los padres de familia y/o representantes legales: Apoyar y hacer seguimiento al aprendizaje de sus representados y atender los llamados y requerimientos de las y los profesores y autoridades de los planteles. {1} Cuando los padres de familia desean saber las calificaciones de sus hijos, tienen necesariamente que esperar la libreta de calificaciones, al final de cada perodo o acudir a la escuela, para realizar la respectiva consulta a cada profesor en determinado horario, lo que conlleva prdida de tiempo para los padres de familia y profesores. Adems, segn la Ley de Educacin, otra de las obligaciones de los padres de familia o representantes es: Participar en las actividades extracurriculares que complementen el desarrollo emocional, fsico y psicosocial de sus representados y representadas {1}, lo que actualmente se realiza con algo de dificultad, debido a que los padres no siempre son informados oportunamente, acerca de los eventos que programa la institucin educativa durante el periodo lectivo, ya que para comunicarse con los padres de familia los profesores les envan notificaciones

con los estudiantes, que por diversos motivos pueden no llegar o no entregarse a tiempo. Es obligacin de los estudiantes: Participar en la evaluacin de manera permanente, a travs de procesos internos y externos que validen la calidad de la educacin y el inter aprendizaje. {1} Los estudiantes verifican sus notas con cada docente lo que conlleva dependencia innecesaria, adems las calificaciones estn sujetas a equivocaciones ya que en algunos casos an se realizan clculos de forma manual, adems existe poca disponibilidad de la informacin referente a notas. Caracterizacin de las escuelas fiscales de nivel primario

que tanto el cliente como el desarrollador queden satisfechos porque el producto final tiene una calidad adecuada. En la Tabla 1 se muestra una comparacin entre las metodologas giles y tradicionales, tomando como referencia las principales caractersticas de ambas metodologas. Debido a las razones mostradas en la Tabla 1 y por las caractersticas de las metodologas giles y las caractersticas del proyecto que se va realizar, el desarrollo del presente proyecto se realizar tomando un enfoque gil.
METODOLOGAS GILES METODOLOGAS TRADICIONALES Basadas en heursticas provenientes de prcticas de produccin de cdigo. Basadas en normas provenientes de estndares seguidos por el entorno de desarrollo. Especialmente preparadas para cambios durante el proyecto. Impuestas internamente (por el equipo) Proceso menos controlado, con Proceso mucho ms controlado, con numerosas polticas/normas. No existe contrato tradicional o al menos es bastante flexible. El cliente es parte del equipo de desarrollo. El cliente interacta con el equipo de desarrollo mediante reuniones. Existe un contrato prefijado. Cierta resistencia a los cambios. Impuestas externamente.

El trmino Escuela Fiscal se define como la institucin educativa financiada por los ingresos fiscales de un pas, cuyo principal fin es asegurar la correcta alfabetizacin, es decir, ensear a leer, escribir, clculos bsico y algunos de los conceptos culturales considerados imprescindibles, esto en seis aos establecidos y estructurados, a nios que normalmente oscilan entre los 6 aos hasta aproximadamente los 12 aos de edad. La Educacin Primaria en el Ecuador abarca seis niveles de estudio, desde segundo de bsica hasta completar el sptimo ao. Los jvenes estn preparados, entonces, para continuar los estudios de colegio. Este nivel educativo permite que el estudiantado desarrolle capacidades para comunicarse, para interpretar y resolver problemas, y para comprender la vida natural y social. El sistema realiza la gestin de las escuelas fiscales del Ecuador es decir: Admisin, Matriculacin, Evaluacin y Promocin. Seleccin y justificacin de la metodologa de desarrollo En la actualidad con el auge de la tecnologa, y con el objetivo de agilizar y automatizar los procesos en el desarrollo de software, se observa la necesidad de implantar Metodologas de Desarrollo de Software, que ayuden a entregar un producto de calidad en tiempo y costo estimados, siendo las metodologas giles de desarrollo de software las que han despertado alto inters gracias a que proponen simplicidad y velocidad para crear sistemas. Las metodologas tradicionales no se adaptan a las nuevas necesidades o expectativas que tienen los usuarios hoy en da, en parte debido a que los mtodos usados no son flexibles ante la posibilidad de la exigencia de nuevos requerimientos. Estos cambios generalmente implican altos costos, demanda de tiempo y la restructuracin total del proyecto que se est llevando a cabo. Los mtodos giles permiten un desarrollo iterativo y adaptable que permite la integracin de nuevas funcionalidades a lo largo del desarrollo del proyecto, para 2

pocos principios.

Grupos pequeos (<10 integrantes) y trabajando en el mismo sitio. Pocos artefactos Pocos roles Menos nfasis en la arquitectura del software

Grupos grandes y posiblemente distribuidos.

Ms artefactos Ms roles La arquitectura del software es esencial y se expresa mediante modelos.


{3}

Tabla 1. Metodologas giles vs Metodologas tradicionales

A continuacin se compara las principales metodologas giles en base a tres parmetros: vista del sistema como algo cambiante, colaboracin entre los miembros del equipo y caractersticas ms especficas de la propia metodologa como son simplicidad, excelencia tcnica, resultados, adaptabilidad, etc.

En la Tabla 2 se muestran los puntajes asignados a cada una de las metodologas, para determinar la mxima agilidad entre las opciones, se considera lo siguiente:
CRYSTAL SCRUM

XP

Sistema como algo cambiante Colaboracin

Propone al sistema como algo cambiante, lo cual puede ser utilizado para adaptar el desarrollo a posibles cambios que se presenten durante el proceso de desarrollo. En la fase de programacin XP propone la prctica llamada programacin en parejas lo cual es favorable para los desarrolladores puesto que en el desarrollo del proyecto nicamente se cuenta con dos programadores que pueden ajustarse correctamente a esta prctica de XP.

DSDM

FDD

ASD

LD

Caractersticas Metodologa (CM) Resultados Simplicidad Adaptabilidad Excelencia Tcnica Prcticas de Colaboracin MEDIA CM MEDIA TOTAL 4,4 4,6 4,4 4,4 3,6 3,6 3,8 3,7 3,6 3,7
{4}

5 4 5 3

5 4 5 3

4 3 3 4

4 5 3 4

4 3 4 4

5 5 4 3

5 5 3 4

A continuacin en la figura 1 se muestra el ciclo de vida de un proyecto XP, que consta en seis fases: Exploracin, Planificacin de entregas, Iteraciones, Produccin, Mantenimiento y Muerte del Proyecto.

4,2 4,4

4,4 4,5

Figura 1. Ciclo de vida de un Proyecto XP{5}

Anlisis y Diseo Los requerimientos de los usuarios fueron recopilados mediante reuniones con los mismos, y han sido agrupados en historias de usuario, como especifica XP, dependiendo de la necesidad a satisfacer por los usuarios o cmo mdulos que estarn presentes en el sistema a desarrollarse. En la tabla 3 se muestra la lista de las historias de usuario que se utilizaron para construir el sistema.

Tabla 2. Ranking de agilidad

Una vez terminado el anlisis relacionado a las metodologas giles y tomando en cuenta la Tabla 2 relacionada al ranking de las metodologas giles adems de las caractersticas propias del proyecto, se escoge la metodologa Extreme Programming como determinante para orientar el proyecto, luego de haber llegado a las siguientes conclusiones: Debido al corto tiempo que se dispone para el desarrollo, no se requiere una metodologa tradicional por el hecho que se requiere entregas a corto plazo que cumplan con los requerimientos planteados. El nmero de participantes en el grupo de trabajo es reducido (2 personas) por tal motivo la metodologa escogida (Extreme Programming) es adecuada debido a que el nmero de roles que abarca puede ser bastante reducido, adems se presenta la necesidad de realizar retroalimentacin con l o los clientes mediante reuniones de corto tiempo de duracin. Debido a ser una metodologa gil se plantea la reduccin de tiempos de desarrollo, basndose para esto en un diseo exacto y conciso, adems de brindar la oportunidad para agilitar los cambios que se presenten en el proyecto. Mantiene una alta calidad en el producto y en el proceso de ingeniera a pesar de la simplificacin en el diseo. 3

Tabla 3. Plan de Entregas

El diseo arquitectnico utilizado en la realizacin del proyecto consiste en una arquitectura cliente-servidor (diseo en tres niveles o en tres capas) ya que es un sistema web. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algn cambio, slo se ataca al nivel requerido sin tener que revisar entre cdigo mezclado. Las 3 capas pueden residir en un nico ordenador, si bien lo ms usual es que haya una multitud de ordenadores en donde reside la capa de presentacin (son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo aconseja se pueden separar en dos o ms ordenadores. En la Figura 2 se muestra un esquema que ilustra la arquitectura de 3 capas que ser utilizada en el desarrollo del proyecto.

En la Figura 3 se muestra la informacin que debe contener una tarjeta CRC para poder ser implementada segn Kent Beck.

Figura 3. Tarjeta CRC

Como derivacin de las tarjetas CRC podemos obtener un diagrama de clases en el cual se observan las clases, responsabilidades y colaboradores representado de forma grfica mediante clases, relaciones y atributos. Y a partir del diagrama de clases se obtuvo el diagrama Entidad Relacin y el modelo fsico de la base de datos. Dentro del desarrollo del sistema encontramos los estndares de buenas prcticas de codificacin para HTML, PHP y hojas de estilo CSS, sobre los cuales fue realizado SGAweb. Pruebas de Aceptacin El objetivo de las pruebas de aceptacin es validar que el sistema desarrollado cumple con el funcionamiento esperado y tambin permitir que los usuarios de nuestro sistema determinen su aceptacin, desde el punto de vista de su funcionalidad y rendimiento. Las pruebas de aceptacin son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecucin y aprobacin final corresponden al usuario, para las pruebas de aceptacin se utilizar la tabla mostrada en la Figura 4.

Figura 2. Modelo Arquitectnico de tres capas

En el proceso de desarrollo se utilizaron tarjetas CRC (clase, responsabilidad y colaboracin) son utilizadas para el diseo de software orientado por objetos y fueron creadas por Kent Beck y Ward Cunningham. Contienen la informacin sobre el nombre de la clase, sus responsabilidades y sus colaboradores, permitiendo al programador apreciar el desarrollo orientado a objetos cuando sea necesario.
Figura 2. Prueba de aceptacin

Aparte de las pruebas de aceptacin el equipo de desarrollo decidi realizar unas encuestas a varios miembros de la institucin. 4

Como resultado de las encuestas realizadas en la Institucin a 2 profesores, 2 padres de familia y 2 autoridades se pudo concluir que el sistema satisface los requerimientos del cliente, por lo tanto el sistema se considera apto para poder ser usado en las instituciones de educacin primaria en el Ecuador. Para el equipo de desarrollo fue un desafo llevar a cabo este proyecto debido al cambio en la Ley Orgnica de Educacin intercultural y su Reglamento, por lo cual debi cambiarse varias reglas del negocio e implementarlas en el sistema. El sistema fue corregido varias veces en base a las recomendaciones realizadas por las personas que colaboraron en las pruebas de los prototipos entregados. Las funcionalidades corregidas fueron las siguientes: Implementacin de quimestres para llevar el control de notas finales y parciales, esto se debe al cambio de la Ley Orgnica de Educacin Intercultural en el Ecuador. Implementacin de calificaciones cualitativas sobre la conducta, esto se debe al cambio de la Ley Orgnica de Educacin Intercultural en el Ecuador.

Las funcionalidades cambiadas debido a las recomendaciones obtenidas durante el proceso de desarrollo y en las encuestas fueron: Implementacin de impresiones sobre los reportes de notas, horarios, listados de estudiantes, etc. Implementacin sobre las calificaciones para que las notas aun no asignadas sean mostradas con un espacio en blanco y no con un cero. Implementacin de creacin de usuario y creacin de estudiante o profesor en un mismo formulario. Implementacin para poder habilitar y deshabilitar usuarios dependiendo el perfil.

Conclusiones
Segn la encuesta se concluye que el sistema ayudar a mejorar los procesos de Gestin acadmica dentro de la Institucin, debido a que facilita la matriculacin del alumnado, mejora la gestin de calificaciones y ayuda a mantener disponible la informacin de la Institucin, sus profesores y alumnos. Con la automatizacin de los procesos de gestin acadmica brindados en el sistema, se puede disminuir la prdida de informacin de los estudiantes, adems de evitar falta de disponibilidad de datos, centralizando la informacin en una base de datos. Con la posterior implementacin del sistema, se lograr optimizar el uso de recursos de la 5

Institucin, puesto que el sistema disminuye el uso de personal administrativo, que puede encargarse de otras actividades de mayor importancia, adems de disminuir el costo de implementos de papelera y el costo de mantener un archivo fsico. Los reportes de calificaciones que podrn ser revisados en el sistema por los estudiantes o padres de familia, ofrecer un mejor servicio a los mismos, adems que los padres de familia podrn tener un mejor control sobre sus representados y su rendimiento acadmico. El haber desarrollado un producto parametrizable y genrico ayuda a que la implementacin del sistema pueda hacerse en un sistema educativo tan cambiante como el de nuestro pas, y el que sea customizable ayuda a que el sistema pueda ser adaptado a condiciones especficas de cada institucin. La Metodologa seleccionada, XP, permite poder desarrollar prototipos del sistema, para posteriormente poder cumplir con las expectativas del usuario, sin que este prototipo requiera una extensa documentacin para poder ser presentado al usuario. La Metodologa XP se ajusta a las condiciones bajo las cuales se desarroll el presente proyecto, puesto que se tiene un equipo de desarrollo pequeo y adems se pudo contar con los clientes a lo largo de todo el proyecto, es decir el cliente fue parte del equipo de desarrollo. La metodologa XP recomienda usar pocos modelos para el diseo del sistema. En el presente proyecto se utiliza el diagrama de clases como una derivacin de las tarjetas CRC. Se comprob que la metodologa XP es adaptable, debido a que durante el desarrollo se presentaron cambios en los requerimientos, conforme a la publicacin del Reglamento de la Nueva Ley Orgnica de Educacin Intercultural, en febrero del 2012. El desarrollo del sistema, es basado en software libre, por lo cual se logra disminuir los costos para su implementacin.

Referencias
{1} Registro oficial No 417. Ley orgnica de educacin intercultural. Ecuador. 31/03/2011. {2} Registro oficial No 754. Reglamento general a la Ley Orgnica de Educacin Intercultural. Ecuador. 26/07/2012. Artculo 146. {3} AMARO C, V. (2007). Metodologas giles. Disponible en: http://www.seccperu.org/files/Metodologias%20A giles.pdf

{4} LETELIER P. (2006) Mtodologas giles para el desarrollo de software: eXtreme Programming (XP) Disponible en: http://www.willydev.net/descargas/masyxp.pdf {5} Tomado del material didctico utilizado por el Ing. Bolvar Paln.

Biografa
Nac en Quito, Ecuador el 11 de diciembre de 1987. Estudi en la Escuela Fiscal Mixta Fernando Pons, en el Colegio Juan Montalvo, gradundome en el ao 2005 como bachiller especializacin Fsico Matemtico. Ingres a la Escuela Politcnica Nacional y debido a la gran evolucin y avance de la tecnologa y la computacin me decid por estudiar una carrera del futuro como Ingeniera en Sistemas Informticos y de Computacin. En el futuro espero cumplir ms metas acadmicas y profesionales.

Biografa
Nac en Quito, Ecuador el 10 de septiembre de 1989. Estudi en la Escuela Municipal Eugenio Espejo, en el Colegio San Gabriel, gradundome en el ao 2006 como bachiller especializacin Fsico Matemtico. Ingres a la Escuela Politcnica Nacional y debido a mi gran apego por la tecnologa y los computadores me decid por estudiar la carrera de Ingeniera en Sistemas Informticos y Ciencias de la Computacin. En el futuro espero continuar creciendo personal y profesionalmente.

___________________________________ Tutor: Ing. Ral Cordova