Está en la página 1de 119

Universidad Central de Venezuela

Facultad de Ciencias
Escuela de Computación

Desarrollo del sistema de gestión académica


CONEST para la Coordinación de Postgrado de
la Facultad de Ciencias. Módulos de migración de
datos, administración e inscripción

Trabajo Especial de Grado presentado ante la ilustre


Universidad Central de Venezuela por los bachilleres
Elohina Guevara
Andrés Zúñiga

Tutor:
Prof. Eugenio Scalise

Caracas, Octubre de 2015


Resumen

Los estudios de postgrado de la Facultad de Ciencias de la Universidad Central de Venezuela son


gestionados por la Coordinación de Postgrado. Esta organización lleva a cabo una serie de procesos que
permiten llevar a cabo el manejo de la información académica de los estudiantes, docentes y planes de
estudios de los 14 postgrados que pertenecen a la Coordinación. Este Trabajo Especial de Grado tuvo
como objetivo realizar la implementación de la aplicación Web CONEST en los estudios de postgrado,
con la finalidad de adaptarla y obtener un producto que sirva para su gestión académica y el beneficio de
su comunidad. A partir del modelo de datos y las tecnologías utilizadas por CONEST 3.0, se realizó un
proceso de adaptación del sistema. Este proceso de reusabilidad se realizó utilizando una adaptación de
la metodología Programación Extrema (XP), que facilitó el desarrollo de la aplicación. En este Trabajo
Especial de Grado se presentó la primera versión de CONEST para los estudios de postgrados basada en
reusabilidad de software y que permite la migración de datos automatizada.

Palabras Clave: CONEST, Postgrado, Coordinación de Postgrado, postgrados, Ruby, Rails, Ruby on
Rails, reusabilidad, gestión académica, aplicación web, Programación Extrema.

III
Agradecimientos

A Dios, por siempre darme la fuerza que me impulsa a lograr mis sueños.

A mi madre Carolina, por su constancia y amor, quien me enseñó que lo puedo todo si así lo quiero.
Gracias por creer en mí y darme fortaleza cada día de mi carrera y mi vida.

A mis padres, Maurizio y Oreste, por siempre estar cuando lo necesito. Gracias ayudarme a enfrentar los
retos que se presentaron en mi día a día o cuando así lo necesité.

A mis abuelas, Zoraida y Mima, por guiarme en el proceso de ser la mejor versión de mí misma y
enseñarme a ser guerrera. Gracias por siempre hacerme sentir la más especial.

A mis abuelos, Francisco y Tuto, por sembrar en mí los sueños y las ganas de buscar más allá del
horizonte. Gracias porque por ustedes seguiré logrando más metas.

A mis hermanas Gabi y Franchi, por acompañarme en las noches de desvelo y brindarme momentos de
alegría. Son mi más grande motivación para hacer lo mejor.

A Pedro, por su apoyo durante este trabajo y su amor incondicional. Por siempre estar en los momentos
difíciles brindando una razón para sonreír.

A todos los amigos que estuvieron durante la carrera, gracias por los buenos momentos y el apoyo en los
malos. En especial a Annerys, Daniel y Mayra, por sus palabras de fortaleza y chistes de desvelo.

A todos los amo y les agradezco simplemente estar.

Elohina Guevara

IV
Agradecimientos

A mi padre, madre y hermanos por estar siempre ahí para cualquier cosa. Por comprender cuando decidí
irme a otro país a estudiar. Por andar pendiente de todo.

A Froy, gracias a sus ánimos y apoyo para lograr que esta meta fuese posible.

A las amistades que hice durante el tiempo acá, gracias por las buenas memorias.

Andrés Zúñiga

V
Agradecimientos

Queremos dar gracias muy especiales a:

Nuestro tutor Eugenio Scalise, por guiarnos y estar dispuesto a ayudarnos y hacer posible este trabajo.

A los profesores Jossie Zambrano y Sergio Rivas, por encaminarnos en este proceso de culminación de
nuestra carrera y sus buenos consejos.

Al personal administrativo de la Coordinación de Postgrado, por su colaboración y buena disposición en


el desarrollo de este Trabajo Especial de Grado.

Elohina y Andrés

VI
Tabla de Contenidos

Resumen III

Agradecimientos IV

Introducción XIII

Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV

Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XIV

Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV

Objetivo Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV

Justificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XV

1 Marco Referencial 1

1.1 Gestión Académica Facultad de Ciencias . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Universitas XXI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1.2 Sistema de Gestión para la Coordinación de Postgrado . . . . . . . . . . . . . . 3

1.2 CONEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Tecnologías . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.2 Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.3 Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 Marco Metodológico 11

2.1 Adaptación de la Metodología de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . 11

VII
TABLA DE CONTENIDOS VIII

2.1.1 Planificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.2 Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.3 Codificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.4 Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Reusabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Marco Aplicativo 14

3.1 Análisis del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Historias de usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Plan de Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Iteración 0: Adaptación de la base de datos . . . . . . . . . . . . . . . . . . . . 24

3.2.2 Iteración 1: Oferta académica . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.2.3 Iteración 2: Constancias y listados . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.4 Iteración 3: Tutores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.2.5 Iteración 4: Funcionalidades del Personal Administrativo . . . . . . . . . . . . . 52

3.2.6 Iteración 5: Adaptación de vistas de período académico . . . . . . . . . . . . . . 58

3.2.7 Iteración 6: Inscripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.2.8 Iteración 7: Pagos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.2.9 Iteración 8: Migración de datos . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.2.10 Iteración 9: Adaptación de vistas administrativas . . . . . . . . . . . . . . . . . 86

Conclusiones 90

Recomendaciones y Trabajos Futuros 92

Anexos 93
Índice de figuras

3.1 Ejemplo de documentos proporcionados por la Coordinación de Postgrado de la Facultad


de Ciencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.2 Ejemplo de los nombres de las materias Tópicos Especiales de Postgrado. . . . . . . . . 33

3.3 Vista de las secciones creadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.4 Vista modificada que agrega estudiantes a una sección seleccionada. . . . . . . . . . . . 38

3.5 Coordinación de Postgrado como organización. . . . . . . . . . . . . . . . . . . . . . . 43

3.6 Ejemplo de membrete de documentos generados por CONEST. . . . . . . . . . . . . . . 44

3.7 Vista modificada que agrega el registro del tutor a la creación de estudiante nuevo. . . . . 49

3.8 Vista de estudiante modificada que muestra el tutor asignado. . . . . . . . . . . . . . . . 50

3.9 Vista de docente modificada que muestra los tutorados. . . . . . . . . . . . . . . . . . . 51

3.10 Vista del menu de ADM_SIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.11 Vista de la pagina principal del personal administrativo con tipo de rol PER_POST. . . . 56

3.12 Vista de los datos del estudiante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3.13 Vista de selección de postgrado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.14 Proceso de inscripción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

3.15 Inscripción de especialización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.16 Modificación del modal para agregar materia de Estudios Dirigidos. . . . . . . . . . . . 68

3.17 Modificación de la Oferta Académica para que identifique las materias de Estudios Diri-
gidos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.18 Vista para lista de estudiantes en materia de Estudios Dirigidos. . . . . . . . . . . . . . . 69

IX
ÍNDICE DE FIGURAS X

3.19 Sección de pagos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.20 Modificar pagos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.21 Flujo del proceso de Migración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.22 Vista principal del modulo de migración. . . . . . . . . . . . . . . . . . . . . . . . . . . 79

3.23 Vista de bitácora de migración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.24 Vista de bitácora de migración. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

3.25 Vista de historial académico de estudiante. . . . . . . . . . . . . . . . . . . . . . . . . . 87

3.26 Vista de materias en plan de estudio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88


Índice de tablas

1.1 Base de datos CONEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Formato para las Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2 Formato de Planificación de la Iteración . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Formato de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2 Identificación del Modelo de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.2 Casos de prueba - Iteración 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.3 Casos de prueba - Iteración 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.5 Casos de prueba - Iteración 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5 Casos de prueba - Iteración 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.7 Casos de prueba - Iteración 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.7 Casos de prueba - Iteración 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

3.8 Casos de prueba - Iteración 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.10 Casos de prueba - Iteración 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.11 Casos de prueba - Iteración 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

XI
Índice de códigos

3.1 Query para extraer información de SIGEPOST · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 29

3.2 Modificación de autocompletado de materias · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 34

3.3 Código para buscar los planes a los que pertenece una materia. · · · · · · · · · · · · · · · · · · · · · · 35

3.4 Código para creación de secciones únicas. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 35

3.5 Código para la vista que agrega estudiantes a una sección.· · · · · · · · · · · · · · · · · · · · · · · · · · 38

3.6 Método que verifica la organización del personal administrativo. · · · · · · · · · · · · · · · · · · · · 43

3.7 Código para generar encabezados.· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 43

3.8 Código para buscar y obtener datos del tutor. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 49

3.9 Código para buscar tutores y tutorados.· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 51

3.10 Código del menú principal del personal administrativo de los postgrados. · · · · · · · · · · · · · 55

3.11 Código para agregar nuevos periodos académicos. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 60

3.12 Código para crear registro de pago de inscripción. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 73

3.13 Código seleccionado de upload_estudiante. · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 80

3.14 Código para guardar los datos obtenidos en la base de datos.· · · · · · · · · · · · · · · · · · · · · · · · 81

3.15 Código para guardar en bitácora.· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · 82

XII
Introducción

Desde que se empezaron a crear páginas Web utilizando tecnologías que permiten la interacción
entre ellas y los usuarios, se comenzó a manejar el término aplicación Web. La razón de esto es la
transformación de una colección de páginas estáticas, que se limitan a mostrar contenido, a tener un
mecanismo de interacción con los elementos de la página, dándole un uso más dinámico a la misma. Hoy
en día, las aplicaciones Web son utilizadas en una amplia variedad de soluciones, tales como: la página
informativa de una empresa, la gestión administrativa y académica de una universidad, entre otros. Esto
se debe a que las aplicaciones Web ofrecen numerosas ventajas tanto para las organizaciones como para
los usuarios.

Una de las utilidades que las organizaciones le han dado al uso de aplicaciones Web es la auto-
matización de procesos administrativos, con la finalidad de facilitar la gestión de dichos procesos a las
personas que están inmersas en ellos. Sin embargo, no siempre se logra iniciar o mantener a través del
tiempo estos sistemas. Esto ocurre especialmente cuando la forma en que se maneja la información de
las organizaciones da paso a problemas como redundancia e inconsistencia de los datos.

La Coordinación de Postgrado de la Facultad de Ciencias de la Universidad Central de Venezuela


(UCV), es una organización que se encarga de la gestión académica y administrativa de los programas de
postgrado que se dictan en la facultad. Para mejorar su proceso de trabajo se ha propuesto implementar
un sistema de gestión académica que le permita automatizar actividades administrativas a su personal,
centralizar sus datos y mejorar los procesos que llevan a cabo sus estudiantes, tales como solicitud de
documentos, chequeo de notas, entre otros.

En diversas ocasiones, dicha coordinación se ha propuesto implementar distintas aplicaciones Web


para su gestión académica y administrativa, con las que no obtuvo éxito. Ahora, se propone la reutiliza-
ción de una aplicación Web ya implementada, utilizando su código fuente. Actualmente, esta aplicación
se ha logrado mantener en producción dentro de la misma facultad, ya que fue creada para la División
de Control de Estudios en el año 2006, por lo que se encarga de automatizar la gestión de procesos
académicos de los estudios de pregrado y fue bautizada como CONEST.

En este sentido, el objetivo principal de este Trabajo Especial de Grado es la adaptación del sistema
CONEST para los estudios de postgrado de la Facultad de Ciencias con el fin de gestionar sus procesos
administrativos y académicos. Para llevar a cabo este objetivo, a continuación se describen de forma
general las cuatro partes en las que esta dividida este documento. En la primera parte se describe en qué
consiste un proceso de gestión académica y cómo se ha aplicado en la Facultad de Ciencias, así como su
software principal encargado de la gestión académica de los estudios de pregrado. En la segunda parte,
se describe la adaptación de la metodología de Programación Extrema que fue utilizada durante este
proyecto. En la tercera parte, se describen las historias de usuarios e iteraciones durante el transcurso

XIII
INTRODUCCIÓN XIV

del desarrollo de software realizado. Finalmente, se presentan los objetivos alcanzados, las conclusiones
de la investigación y los trabajos futuros recomendados para seguir desarrollando el nuevo CONEST
Postgrado.

Problema

Actualmente, la información de los postgrados de la Facultad de Ciencias se maneja a través de


distintas herramientas y utilizando distintos estándares en los datos. Además, cada postgrado mantiene
la gestión de sus estudiantes, personal administrativo y docente de forma independiente, a pesar de que
en años anteriores se han desarrollado sistemas para automatizar los procesos de gestión académica y
administrativa.

Entre uno de los sistemas desarrollados se encuentra SIGEPOST. Este sistema sólo se utiliza en el
Postgrado en Ciencias de la Computación para mantener un respaldo de la gestión académica y adminis-
trativa del mismo, utilizando todos los módulos excepto el de inscripción, ya que esta se realiza de manera
manual y luego esta información es vaciada en el sistema por el personal administrativo. Además, no to-
das las funcionalidades de los módulos son utilizadas. Esto sucedió porque no se logró completar la carga
de datos necesaria para poner en producción todos los módulos y algunas funcionalidades, como los for-
mularios que fallaban por incompatibilidades de JavaScript, se hicieron incompatibles con tecnologías
actuales. Además, la falta de mantenimiento representó otro problema, ya que es crucial para cualquier
aplicación en un ambiente donde las actualizaciones de tecnologías son frecuentes.

Otro sistema a considerar es CONEST Postgrado, que fue creado como parte de diferentes Traba-
jos de Grado de estudiantes de la Escuela de Computación. La finalidad de este sistema fue solventar
los problemas existentes en la Coordinación de Postgrado relacionados con el manejo de los procesos
académicos y administrativos llevados a cabo en los diferentes postgrados de la Facultad de Ciencias.
Actualmente, este sistema no se encuentra operativo, ya que solo llegó a ser instalado temporalmente en
una máquina de prueba por el postgrado de la Escuela de Computación. Debido a la falta de administra-
ción de la aplicación y soporte para la migración de los datos el sistema no logró ser exitoso.

En base a lo anterior es posible reflexionar sobre los diferentes intentos de implementar un software
que, debido a la falta de automatización en los procesos de migración de datos y organización, no se
utilizara efectivamente o desde el inicio no fuera implementado.

Objetivos

A continuación, se definen el objetivo general y los objetivos específicos de la presente investigación.


INTRODUCCIÓN XV

Objetivo General

Adaptar la aplicación web de gestión académica CONEST para el ambiente de postgrado de la Fa-
cultad de Ciencias y proveer una solución que automatice la migración de datos de sus planes de estudio.

Objetivos Específicos

Adaptar el sistema CONEST a las necesidades planteadas por la Coordinación de Postgrado.

Estudiar los procesos que intervienen en la migración de los datos de la organización.

Determinar los problemas asociados al proceso de recopilación de datos.

Desarrollar una estrategia para organizar la recolección de los datos

Definir, en base a los problemas encontrados, un formato para los datos a migrar.

Adaptar los componentes del software para incorporar las actividades de migración de datos histó-
ricos.

Desarrollar funcionalidades para el sistema CONEST que permitan instanciar un plan de estudio
de Postgrado.

Desarrollar funcionalidades para el sistema CONEST que permite la inscripción de usuarios en un


periodo académico.

Establecer los lineamientos necesarios para completar correctamente el ingreso de los datos.

Utilizar la metodología ágil XP para desarrollar las funcionalidades y aplicar reusabilidad.

Justificación

El aumento de los datos, causados por el incremento sostenido en el número de estudiantes que ingre-
san a cursar estudios de postgrado, ocasiona que los procesos actuales implementados en la Coordinación
de Postgrado y los postgrados en particular tengan dificultad para mantener actualizada la información de
los estudiantes que van a cursar, están cursando o ya culminaron sus estudios. El problema radica en que
la mayoría de los procesos de gestión académica se hacen de forma manual, y por esta razón es común
encontrarse con repetición de trabajo, pérdida de datos y retraso en los tiempos de respuesta. Esto último
ocasiona que sea más difícil la inicialización de un sistema que automatice dicha gestión. A pesar de
estos inconvenientes, actualmente no existe ningún proceso que siva para llevar a cabo la migración de
los datos a un sistema automatizado de gestión académica.

Los postgrados de la Facultad de Ciencias tienen la responsabilidad de brindar una respuesta rápida
a los estudiantes, y la falta de un proceso definido para la migración de datos ocasiona que los sistemas
automatizados, como SIGEPOST y CONEST Postgrado, fracasaran en su implementación debido a la
descentralización de datos y la falta de la estandarización de los mismos. Hasta ahora, no existe algún
INTRODUCCIÓN XVI

tipo de solución que recopile información o automatice este proceso, el cual debe ser llevado por cada
Postgrado para poder utilizar de manera efectiva los sistemas creados, como SIGEPOST y CONEST
Postgrado, ya que estos sistemas solo resuelven el problema de la gestión pero no presentan ninguna fun-
cionalidad o soporte para instalar o recopilar la información. Cabe destacar que a partir de la recopilación
de datos es que se puede crear una instancia o se ayuda a crear una instanciación del sistema CONEST,
que al final es el que brinda la automatización de la gestión académica y administrativa.

La motivación nace de la importancia de automatizar la migración de los datos y creación de nor-


mativas de instanciación de un sistema, apoyándose en la reusabilidad del software existente. Esto nos
permite brindar un mejor servicio a la comunidad universitaria entregándoles un sistema que reduce los
tiempos de migración por parte de las diferentes entidades responsables de sus datos académicos y ad-
ministrativos. Por ello, es necesario que la aplicación a ser desarrollada facilite el ingreso de los datos
al sistema, posea una interfaz usable, elimine el trabajo redundante y permita una instanciación efec-
tiva, siendo el software el que provea la eficiencia al momento de implementar un sistema de gestión
académica y administrativa en los diferentes postgrados de la Facultad de Ciencias.

Como respuesta a la problemática estudiada en cuanto a la migración de datos e instalación de una


solución de software exitosa, como es el caso del sistema CONEST, se propone la creación de un módulo
para dicho sistema que se encargue de automatizar la migración de los datos, acompañado de una serie
de pasos que le permita a cualquier usuario realizar dicho proceso. Esto implicaría que, a través del pro-
ceso establecido para la instanciación del sistema mencionado, se establezcan los formatos de los datos
que se requieran migrar. El módulo podrá ser accedido por el personal administrativo de cada uno de
los diferentes postgrados, ofreciendo una interfaz fácil de utilizar durante todo el proceso. Como resul-
tado, la Coordinación de Postgrado de la Facultad de Ciencias tendrá la aplicación de gestión académica
CONEST adaptada a sus necesidades incluyendo un módulo que permita la fácil migración de datos e
instanciación de los diferentes postgrados.
Capítulo 1

Marco Referencial

El presente capítulo tiene como finalidad presentar las bases conceptuales que sirvieron para desa-
rrollar el proyecto realizado, así como también describir el sistema de gestión con el que se trabajó. El
capítulo se divide en dos secciones, las cuales se describen a continuación.

En la primera sección se definen las características principales de los sistemas de gestión académi-
ca como introducción para poder describir los sistemas que se han utilizado dentro de la Facultad de
Ciencias UCV, específicamente en la Coordinación de Postgrado. Los sistemas estudiados fueron UXXI,
SIGEPOST y CONEST.

La segunda sección se enfoca en estudiar las características principales de CONEST en su versión


3.0, debido a que es el sistema que será utilizado a lo largo del presente trabajo, y además representa el
producto final.

1.1. Gestión Académica Facultad de Ciencias

La gestión académica es un componente fundamental en las instituciones educativas de cualquier


ámbito, ya que su finalidad es realizar una serie de operaciones destinadas al control de los procesos
académicos de una institución. Cuando se habla de procesos académicos se refiere a actividades como
inscripción, gestión de historiales académicos, generación de constancias, calificación, gestión de seccio-
nes, administración de actos de grado, entre otros. Todos estos procesos conforman en conjunto la gestión
académica, y hoy en día su automatización es un problema clave de cualquier institución académica.

En el presente trabajo se estudiarán los procesos académicos de la Coordinación de Postgrado de la


Facultad de Ciencias de la Universidad Central de Venezuela, la cual se encarga de la gestión académica
y administrativa de los programas de postgrado que se dictan en dicha facultad. Dicha organización ha
utilizado distintos sistemas para gestionar sus procesos, que aunque algunos se encuentran en funcio-
namiento y otros no, sirven como base para evaluar las necesidades y mejoras que se pueden realizar a
cualquier nuevo sistema. Actualmente, la gestión académica en la Facultad de Ciencias está compuesta
por varios sistemas que funcionan para brindar una variedad de servicios a sus estudiantes, docentes y
personal administrativo.

1
CAPÍTULO 1. MARCO REFERENCIAL 2

A continuación, se describen tres sistemas que se han utilizado o se utilizan actualmente en la Facultad
de Ciencias con el fin de entender las necesidades de la organización, especialmente la Coordinación de
Postgrado.

1.1.1. Universitas XXI

Universitas XXI (UXXI) es un sistema de gestión universitaria creado por la Oficina de Cooperación
Universitaria (OCU) conformada por diversas universidades de España. UXXI es un sistema de Plani-
ficación de Recursos Empresariales (ERP) para universidades, que está compuesto por los siguientes
módulos:

Académico: módulo de gestión académica que proporciona a universidades e instituciones de edu-


cación superior automatización de sus procesos administrativos.

Alumni: es una herramienta para egresados de las universidades e instituciones de educación supe-
rior que le permite a ambos actores interactuar con el fin de mantener el vínculo de las universidades
con sus ex-alumnos.

Económico: es el módulo que automatiza los procesos de gestión económica, específicamente para
resolver problemas como la gestión de proyectos, descentralización del gasto y del ingreso y las
demandas de información.

Encuestas: provee una herramienta para captar información y opinión a través de la definición,
distribución y aplicación de encuestas a los universitarios.

Investigación: sistema de gestión de información que permite a las universidades e instituciones de


investigación la automatización de sus procesos de investigación.

Mobile: es un paquete de aplicaciones para dispositivos móviles integrado con UXXI.

Recursos Humanos: es el módulo que facilita la gestión de Recursos Humanos y nómina para
las universidades y otras administraciones públicas. Este cubre las necesidades de administración,
gestión, control e información de todo el personal que labora en las instituciones.

Universidad Digital: permite la gestión de procedimientos y documentos electrónicos de las univer-


sidades a través de tareas como: registro y digitalización de documentos, firma electrónica, consulta
de documentos, procedimiento de solicitudes genéricas y gestión y emisión de certificados electró-
nicos.

UXXI se encuentra implementado en distintas universidades de América y España. Actualmente, en


la UCV, este sistema está siendo utilizado en su versión 51.22.15 que fue adquirida en el año 2003.
Los módulos adquiridos fueron el Académico y Económico, de los que sólo se usan funcionalidades
específicas para el manejo de: Actas, Inscripción, Expediente, Planes de Estudio, Gestión Económica,
Gestión de Recurso Docente, Horarios, Normativas, Sistemas y Listados.
CAPÍTULO 1. MARCO REFERENCIAL 3

Al momento de la implementación, el personal administrativo que se encarga de dicha tarea ha tenido


dificultades para integrar las normativas académicas al sistema, tales como parametrización del tipo de ca-
lificación e implantación de las normativas propias de cada facultad. Además, en su estado de producción
se presentan problemas con la concurrencia que se genera en el momento de la inscripción estudiantil.
Cabe destacar que el principal inconveniente para hacer el uso adecuando de este sistema es que no se
adquieren actualizaciones o versiones desde el año 2003, por lo que no está a la par con el sistema UXXI
del mercado actual y no se adapta a las necesidades de hoy en día de la universidad.

1.1.2. Sistema de Gestión para la Coordinación de Postgrado

El Sistema de Gestión para la Coordinación de Postgrado (SIGESPOST) es un sistema de gestión


académica y administrativa que inició su desarrollo en el año 2002 como un trabajo de grado de la Escuela
de Computación de la Facultad de Ciencias de la UCV. En este trabajo, Soto y Ponte [1] desarrollaron
un sistema que consta de cinco módulos interrelacionados que representan cada unidad de trabajo de
la Coordinación de Postgrado, formando así una aplicación Web que puede ser utilizada tanto por el
personal administrativo, como por las oficinas de cada uno de los postgrados.

Las tecnologías utilizadas para el desarrollo de este sistema se dividen en tecnologías del lado del
servidor y del lado del cliente. Del primero se tiene Active Server Pages (ASP) para la creación de la
aplicación Web, y además utilizaron el servicio Internet Information Server (ISS) para alojar el sistema.
Del lado del cliente se implementó HTML como lenguaje de marcado, CSS para las hojas de estilo y
JavaScript como lenguaje de script. Por último, se utilizó SQL Server 6.0 como manejador de base datos.

Como se mencionó anteriormente, los módulos de SIGEPOST representan las unidades de trabajo
que conforman la Coordinación de Postgrado. A continuación se describen cada una de ellas:

Módulo de Usuarios: lleva a cabo las funcionalidades que controlan el acceso de usuarios al siste-
ma. Tiene un usuario administrador que puede agregar, modificar o eliminar usuarios del mismo,
así como también definir los niveles de acceso de uno de ellos.

Módulo Académico: se encarga de las funcionalidades relacionadas a las inscripciones estudianti-


les. A través de este módulo, los usuarios pueden hacer tareas como: inscripción, retiro y califica-
ción de estudiantes, crear memorándum y minutas, actualizar datos de las autoridades académicas,
generar y buscar oficios, generar constancias de alumnos y profesores.

Módulo de Pre-Inscripciones: se encarga de las funcionalidades relacionadas con la pre-inscripción


estudiantil, es decir la solicitud de ingreso a programas de postgrado. Esto se hace a través de tareas
como agregar y modificar datos de aspirantes a los programas, agregar y modifica los pagos de pre-
inscripción, y por último generar reportes sobre estos procesos.

Módulo de Promociones: se encarga de las funcionalidades que permiten tener un control sobre la
información de los postgrados, trabajos de investigación, planta profesoral y las materias que se
dictan por cada programa. Además, es posible manejar el calendario académico y generar reportes
referentes a los trabajos de investigación.
CAPÍTULO 1. MARCO REFERENCIAL 4

Módulo Administrativo: se encarga de las funcionalidades que llevan a cabo procesos administra-
tivos la coordinación, tales como el manejo de pagos, control sobe ingresos y egresos, y genera
reportes asociados a estos procesos.

Actualmente SIGEPOST sólo se utiliza en el Postgrado en Ciencias de la Computación para llevar la


gestión académica y administrativa del mismo, utilizando todos los módulos excepto el de inscripción,
ya que esta se realiza de manera manual y luego esta información es vaciada en el sistema por el personal
administrativo. Además, no todas las funcionalidades de los módulos son utilizadas. Esto sucedió porque
no se logró completar la carga de datos necesaria para poner en producción todos los módulos.

Los sistemas anteriores no mantienen una gestión administrativa y académica de los estudios actual-
mente, ya que UXXI es utilizado únicamente para integrar la información de los estudiantes que se van
a graduar en cada perodo académico, y SIGEPOST funciona como mecanismo de respaldo de la infor-
mación manejada sobre los postgrados de la Escuela de Computación. Es por esto que surge la necesidad
de utilizar CONEST, un software que actualmente se encuentra en estado de producción en la misma
facultad para los estudios de pregrado. En la siguiente sección se detallarán las características principales
de dicho sistema, ya que la finalidad del presente trabajo es adaptarlo a las necesidades de los estudios
de postgrado de la Facultad de Ciencias.

1.2. CONEST

Es el sistema de gestión académica de la División de Control de Estudios de la Facultad de Ciencias


(DCE), cuyo objetivo principal es automatizar los procesos administrativos de la gestión académica. El
sistema CONEST se encuentra operativo desde el año 2007 y es el encargado de la gestión académica de
los estudios de pregrado de la Facultad de Ciencias de la UCV. Sulbarán y Pedrozo [2] afirman: “surge
a partir de la necesidad de automatizar tareas y procesos académicos de diversos niveles jerárquicos con
diferentes enfoques y alcances”. Ejemplos de estos procesos son inscribir y calificar estudiantes, generar
reportes y documentos, coordinar el proceso de grado de los graduandos, entre otros”, actividades relati-
vas a la DCE; encargada de la gestión administrativa y académica que realiza el personal administrativo
y docente. Además, incluye acceso para los estudiantes de las distintas escuelas de la facultad.

El sistema está conformado por un conjunto de módulos encargados de llevar a cabo los diferentes
procesos que se realizan dentro de la DCE. Algunos de estos módulos son: administrativo, nuevo ingreso,
estudiante, docente, entre otros. Gracias a esta automatización, se ha logrado reducir costos, mejorar los
servicios prestados a los usuarios y economizar tiempo de la DCE en los procesos que realiza habitual-
mente, así como también los procesos que deben ser llevados por parte del personal docente y estudiantil
de la facultad.

CONEST presta servicios las 24 horas del día, los 365 días del año, en los cuales se puede acceder a
todas sus funcionalidades de manera remota sin la instalación de ningún tipo de extensiones o comple-
mentos extras, simplemente utilizando un navegador web como Mozilla Firefox, Opera, Safari, Chrome,
entre otros. Actualmente CONEST está operativo bajo la versión 3.0.0, el cual fue puesto en producción
el 28 de abril de 2014.
CAPÍTULO 1. MARCO REFERENCIAL 5

1.2.1. Tecnologías

Actualmente la aplicación Web CONEST funciona utilizando una combinación de tecnologías de


software libre. El sistema fue implementado con el framework Ruby on Rails siguiendo el patrón de
diseño MVC (Modelo-Vista-Controlador). Además, Ruby es un lenguaje orientado a objetos que com-
parte la flexibilidad de lenguajes como Perl y Python, ya que provee evaluación dinámica del código y
metaprogramación [3].

Como servidor web utiliza Phusion Passenger debido a su alta fiabilidad y escalabilidad, esencial
en un sistema donde las necesidades y la cantidad de usuarios utilizando el sistema están en constante
crecimiento [4]. En cuanto a la base de datos, utiliza el Sistema Manejador de Bases de Datos MySQL,
que mantiene características como la flexibilidad y un alto rendimiento, que permite modificaciones y
adaptaciones a futuro para cualquier otro contexto académico.

1.2.2. Base de Datos

Su modelo de datos cuenta con más de 7 millones de registros, aproximadamente 140 tablas que con-
tienen la información de más de 41.000 estudiantes que cursan y han cursado estudios en la Facultad de
Ciencias. Dicho modelo está diseñado de forma relacional y normalizada. Además, se encuentra dividida
por áreas que permiten relacionar las tablas del modelo según la utilidad que tienen dentro del mismo. Un
ejemplo de dichas áreas es Universidad en donde se encuentran agrupadas las tablas que mantienen la
información de la institución para la que está funcionando el sistema. Para entender mejor la distribución
de las tablas y la información que en ellas se almacena, en la tabla 1.1 se puede observar una descripción
detallada de cada una de ellas.

Área Tablas Descripción


Universidad Mantiene los datos que
universidad representan a la organización
facultad para la que se está utilizando el
dependencia sistema, almacenando la
organizacion información institucional tal
departamento como el nombre de la facultad,
carrera departamentos, carreras, planes
tipo_grado_carrera de estudios, direcciones,
plan teléfonos, entre otros.
plan_activo
CAPÍTULO 1. MARCO REFERENCIAL 6

Materia Contiene a las tablas que


materia mantienen la información de las
opcion_carrera asignaturas impartidas en cada
materia_en_opcion_carrera carrera, así como también la
materia_en_plan relaciones que involucran a las
tipo_materia mismas, tales como prelaciones,
prelacion convalidaciones y las ofertas
convalidacion académicas que se realizan en
convalidacion_estudiante cada período.
oferta_academica
oferta_en_periodo
prelacion_de_tipo_materia
prelacion_de_opcion_carrera
restriccion_oferta_academica
inscripcion_materia_simultanea

Usuario Contiene los datos personales de


usuario los usuarios que hacen uso del
usuario_con_discapacidad sistema sin distinguir que rol
tipo_discapacidad que representan.
usuario_nuevo
tipo_usuario
estudiante_nuevo
tipo_estado_civil
tipo_nacionalidad
tipo_sexo
tipo_foto
usuario_foto

Docente Contiene la información


docente relacionada a los usuarios de
docente_en_cargo tipo docente que dictan materias
tipo_cargo_docente de las carreras que maneja el
tipo_personal sistema.
tipo_dedicacion_docente
tipo_categoria_docente
CAPÍTULO 1. MARCO REFERENCIAL 7

Estudiante Contiene los datos de los


estudiante usuarios de tipo estudiante que
nivel_instruccion pertenecen a las carreras que se
tipo_nivel_instruccion manejan en el sistema.
institucion_academica
tipo_institucion_academica
estado
municipio

Calificación Contiene los parámetros


jurado_examinador necesarios para llevar a cabo las
tipo_jurado funcionalidades de calificación
calificacion_oferta_excepcion de los estudiantes en cuanto a
tipo_status_calificacion las materias, tales como el
usuario que calificó, el status de
la calificación, secciones
calificadas, entre otros.
Inscripción Mantiene la información que se
periodo_academico genera por el módulo de
inscripcion inscripción, tales coomo el
inscripcion_restriccion_tipo_materia período académico, el
impedimento_inscripcion estudiante inscrito, carrera e
tipo_impedimento_inscripcion impedimentos para que realice
el dicho proceso en un periodo
determinado.
Resumen Contiene las tablas que permiten
Académico historial_academico almacenar los historiales
tipo_examen académicos de los estudiantes
examen que registra el sistema.
tipo_nota
grupo_nota
tipo_status_materia
trabajo_especial
materia_inscrita_con_tutor
historial_academico_transaccion
tipo_transaccion_historial_academico
CAPÍTULO 1. MARCO REFERENCIAL 8

Grado Contiene las tablas que llevan el


graduacion la información de las
graduacion_carrera graduaciones que se realizan por
graduacion_foto período, así como también los
requisito_graduacion_opcion_carrera parámetros necesarios para
requisito_graduacion_plan evaluar los requisitos de
estudiante_en_graduacion graduación por plan o carrera.
estudiante_en_graduacion_con_premio
tipo_premio_academico

Status del Representa el conjunto de tablas


Estudiante estudiante_en_carrera que mantienen la información
tipo_ingreso de los diferentes tipos de estatus
estudiante_datos_academico_periodo que puede tener un estudiante
status_estudiante_periodo académicamente dentro del
tipo_status_reglamento sistema, tales como carrera,
tipo_status_estudiante reincorporación, créditos
estudiante_reincorporado aprobados, entre otros.
estudiante_opcion_docente
estudiante_con_empleo
tipo_empleo
estudiante_en_retiro_total

Preinscripción Contiene la información de los


preinscripcion_historial_academico procesos de peroinscripción
preinscripcion realizadas por los estudiantes,
tipo_algoritmo_seleccion_preinscripcion así como también el tipo de
algoritmo utilizado por el
sistema para realizar la
asignación de cupos en dicho
proceso.
Planillas y Representa el conjunto de tablas
solicitudes solicitud que mantienen la información
solicitud_historial_academico de las solicitudes estudiantiles y
tipo_solicitud planillas que se realizan a través
tipo_status_solicitud del sistema, tales como
solicitudes de constancias.
CAPÍTULO 1. MARCO REFERENCIAL 9

Horarios y Representa el conjunto de tablas


aulas horario_asignado que mantienen la información
tipo_hora de las solicitudes estudiantiles y
tipo_dia planillas que se realizan a través
tipo_clase del sistema, tales como
dira_feriado solicitudes de constancias.
reservacion_aula
grupo_horario_materia
horario_materia
aula
aula_foto

Bitacora y Representa el conjunto de tablas


sistema bitacora que sirven para registrar los
tipo_nivel_importancia procesos que se llevan cabo
tipo_modulo dentro de la aplicación. Es decir,
parametro_general_ llevar una bitácora de
tipo_status_sistema actividades realizadas con el
tipo_rol tiempo y usuario que realizó la
personal_administrativo acción a registrar.
personal_administrativo_en_organizacion

Tareas en Tablas que permiten llevar el


segundo plano tarea_en_segundo_plano control de las tareas en segundo
tipo_status_tarea_en_segundo_plano plano que realiza el sistema.
tipo_tarea_en_segundo_plano

Sitio Contiene la información a ser


noticia publicada en la aplicación de
tipo noticia.

Tabla 1.1: Base de datos CONEST

1.2.3. Estructura

CONEST divide sus funcionalidades en una serie de módulos. A continuación se presentan los mó-
dulos más importantes: Administración, Docente, Estudiante, Ingresos y Busconest.

El módulo Administración está encargado de presentar funcionalidades al personal administrativo de


la División de Control de Estudios. Además, es el módulo más amplio debido a la gran cantidad de fun-
cionalidades necesarias para llevar a cabo las tareas administrativas de la facultad. Las funcionalidades se
pueden clasificar según su propósito: administración, grado, aulas y horarios, y calendario de exámenes.

La funcionalidades de administración asisten al personal de la DCE en tareas como la impresión


CAPÍTULO 1. MARCO REFERENCIAL 10

digital de los expedientes curriculares, generación de reportes, modificación de datos, calificaciones es-
tudiantiles, envío de correos a estudiantes y docentes, etc. También, están las funcionalidades de grado,
que permiten mantener un control del proceso de graduación de los estudiantes que cumplieron con los
requisitos para obtener su título de académico. Para este proceso se realiza la verificación de requisitos
de graduandos, digitalización de planillas de solicitud de grado, consulta del CD de grado, entre otros.
Además, se tienen las funcionalidades de aulas y horarios que habilitan el control de los horarios corres-
pondientes a las materias y las aulas de las mimas, con el fin de evitar el solapamiento de los horarios.
Cabe destacar que la asignación de aulas depende de su capacidad y disponibilidad, por lo que propor-
ciona funciones como consultar y modificar horarios tanto de estudiantes como de materias. Por ultimo,
se tienen las funcionalidades para el calendario de exámenes que permiten llevar el control de las fechas
para las evaluaciones de las materias durante un período académico determinado.

El módulo Docente ofrece a todos sus profesores que utilizan la aplicación funcionalidades que les
permiten cargar las calificaciones de una materia, consultar el listado de estudiantes inscritos en su sec-
ción, seleccionar candidatos a preparadores de materias, enviar correos informativos a sus estudiantes,
entre otros. Además, permite a los docentes descargar los listados de sus estudiantes en distintos formatos.

El módulo de Estudiante engloba funcionalidades como consultar el expediente curricular, realizar


inscripción al inicio de cada período académico e imprimir la constancia de inscripción, entre otros.
También permite informar a los estudiantes sobre las fechas de las evaluaciones finales, que son asignadas
por la DCE.

El módulo de Ingresos es utilizado por la Unidad de Pre-Selección y Admisión (UPSA) de la Facul-


tad de Ciencias. Comprende las funcionalidades que permiten automatizar el proceso de inscripción y
selección de los estudiantes aspirantes a ingresar a alguna de las carreras que se ofrecen en la Facultad,
aplicando en la Prueba Interna de la UCV. Los usuarios de este módulo introducen los datos personales
y académicos a través de un formulario para formalizar la inscripción.

Por último, el módulo de Busconest permite realizar búsquedas sobre su repositorio debido a que
cuenta con un motor de búsqueda rápido y eficiente. Además, cuenta con una interfaz simple pero com-
pleta. La búsqueda puede realizarse ingresando como parámetro una parte o la totalidad del titulo, así
como parte del contenido de un documento deseado. También se permite la búsqueda por palabras cla-
ves.
Capítulo 2

Marco Metodológico

Es necesario definir un esquema o metodología de trabajo que permita el desarrollo de software de una
manera estructurada y planificada. En este capitulo se presenta la adaptación de la metodología utilizada,
donde se debe destacar que algunos principios no aplican en el presente Trabajo de Grado, como por
ejemplo el uso de tarjetas CRC y Cliente En-Lugar. Además, se abarca el concepto de Reusabilidad
debido a su importancia durante el desarrollo de software propuesto.

2.1. Adaptación de la Metodología de Desarrollo

La programación extrema o XP (eXtreme Programming) es una metodología de desarrollo ágil enfo-


cado en aumentar la productividad a la hora de desarrollar programas [5]. Este modelo de programación
se concentra en dar prioridad a los trabajos que entregan un resultado directo y poner en segundo plano
aquellas actividades consideradas más burocráticas que engloban la programación.

Así como otras metodologías ágiles, la programación extrema se diferencia de las metodologías tradi-
cionales principalmente en su énfasis a la adaptabilidad. El enfoque de la Programación Extrema se basa
en que los cambios que ocurren en los requisitos son un resultado inevitable en los proyectos de desarro-
llo de software. Lo importante es ser capaz de adaptarse a las cambiantes necesidades en cualquier etapa
durante la vida del proyecto.

La programación extrema define cuatro fases básicas que se realizan dentro del proceso de desarrollo
de software: Planificación, Diseño, Codificación y Pruebas.

2.1.1. Planificación

El primer paso a tomar en cualquier proyecto que siga la metodología XP es la de generar una bitá-
cora de desarrollo basada en los requerimientos. Esta bitácora contiene todas las historias de usuario. El
formato de las historias de usuario contiene un numero, nombre y una breve descripción. (Ver tabla 2.1).

11
CAPÍTULO 2. MARCO METODOLÓGICO 12

Número: # Nombre:
Descripción:
Tabla 2.1: Formato para las Historias de Usuario

Se procede a crear un formato con las historias de usuario donde cada iteración en la fase de planifi-
cación contiene una descripción, las historias de usuario abarcadas en dicha iteración. (Ver Tabla 2.2).

Iteración #
Descripción
Historias de
Usuario
Tabla 2.2: Formato de Planificación de la Iteración

Una vez definidos los requerimientos y el tiempo estimado, el proyecto se divide en iteraciones las
cuales irán cubriendo funcionalidades o características requeridas en cada modificación o creación de los
módulos abarcados.

2.1.2. Diseño

El diseño crea una estructura que organiza la lógica del sistema, un buen diseño permite mantener
el orden a medida que el sistema crece. Los diseños deben ser sencillos, si alguna parte del desarrollo
es complejo, se divide en varias partes. Durante esta fase se proponen soluciones a los requerimientos
abarcados durante la planificación.

Con la documentación del diseño en cada iteración es fácil mantener una organización del código
a implementar. Por esta razón es importante manejar un buen diseño debido a que se puede evitar que
cambios en una parte del sistema afecte otras partes del mismo. Es necesario acotar que el diseño tuvo
mas importancia en la creación de los módulos de migración e inscripción. Esto es debido a que al
reutilizar código existente se contempla mas la adaptación durante el proceso de desarrollo.

2.1.3. Codificación

Esta fase se centra en entregar componentes del software que sean funcionales, donde se muestran
extractos del código mas relevante o el resultado de las vistas resultantes. Después es necesario verificar
su correcto comportamiento realizando las pruebas.

Un principio importante a considerar es el Estándar de Codificación. Se implementa la documenta-


ción de cada cambio realizado dentro del código, así como la agregación de código nuevo. Esta docu-
mentación es realizada en forma de comentario dentro del código de forma simple pero exacta y con una
descripción pequeña de lo realizado. De esta forma el estándar mantiene a los futuros desarrolladores
informados sobre el código.
CAPÍTULO 2. MARCO METODOLÓGICO 13

Siguiendo con la codificación se tiene el principio de Entregas Pequeñas. El proyecto es actualizado


mediante el repositorio central con cada adelanto realizado durante la iteración. Esto podía ser realizado
desde el laboratorio de Postgrado que maneja el repositorio o remotamente, lo que permitía una mayor
productividad. Esto permite aplicar con más facilidad el principio de Programación en Parejas.

2.1.4. Pruebas

Durante esta fase se realizan las pruebas de funcionamiento, asegurando de esta forma, la correcta
funcionalidad del código implementado. El formato a seguir durante esta fase esta compuesto por el
número del caso de prueba, el módulo donde se enfocó la prueba, caso de prueba, resultado esperado y
resultado obtenido.(Ver Tabla 2.3)

No Caso Prueba Módulo Caso de Prueba Resultado Esperado Resultado Obtenido

Tabla 2.3: Formato de Pruebas

Lo esencial es probar cada una de las historias de usuario implementadas en el código. Esto permite
programar y probar rápidamente, de esta forma se invierte menos tiempo en la depuración del código
durante su funcionamiento.

2.2. Reusabilidad

La reusabilidad es un concepto importante dentro del desarrollo de software. Este concepto implica
la creación de una versión separada del original que puede llegar a ser un software completamente nuevo,
compartiendo comportamientos similares a su predecesor [6]. Además, se considera la reusabilidad siste-
mática donde la reusabilidad de recursos se hace de forma planificada, con procesos y ciclos de desarrollo
bien definidos.

La idea principal de la reusabilidad es que partes de un software pueden o deberían ser utilizadas en la
construcción o adaptación de un software con el objetivo de ahorrar tiempo y recursos, así como mejorar
la calidad del código existente. En el caso actual se utiliza el software existente del sistema CONEST
utilizado en los estudios de pregrado de la Facultad de Ciencias. Este es adaptado para cumplir con los
requerimientos de Postgrado. Después de estudiar los diferentes procesos que existen en postgrado y ser
comparados con los procesos en pregrado, se comienza a evidenciar que es posible aplicar reusabilidad
durante el desarrollo de este trabajo especial de grado.
Capítulo 3

Marco Aplicativo

El propósito del presente capítulo es describir el proceso que sirvió para el desarrollo del sistema
CONEST para los estudios de postgrado. Para esto, siguiendo con la metodología XP, se establece un
conjunto de iteraciones que se determinaron a través de las historias de usuarios obtenidas luego del
estudio del problema y reuniones con el cliente.

Para comenzar, la primera iteración se enfoca en la adaptación del modelo de la base de datos, para
luego dar paso a ocho iteraciones concentradas en transformar la aplicación a para que resuelva los
problemas que se manejan en la gestión académica y administrativa de los estudios de postgrado de la
Facultad de Ciencias de la UCV. La última iteración, se enfoca en el desarrollo de un módulo que permite
integrar a los distintos postgrados a la aplicación, ya que les ofrece la facilidad de ingresar los datos de
sus estudiantes, materias, docentes e historiales académicos, a través de la misma aplicación.

3.1. Análisis del sistema

Siguiendo con la metodología XP, inicialmente se realiza un análisis del sistema con el que se va a
trabajar, con el fin de determinar los requerimientos. A partir de ellos, se elaboran las historias de usuario
y se determina el plan de desarrollo del sistema.

3.1.1. Historias de usuarios

Para realizar las historias de usuarios se desarrolló un análisis de los requerimientos solicitados por el
personal de la Coordinación de Postgrado de la Facultad de Ciencias UCV, el Postgrado en Ciencias de la
Computación, que sirvió como piloto en el desarrollo de este trabajo, y de las características funcionales
que presenta el sistema CONEST 3.0. Debido al carácter del Trabajo Especial de Grado enfocado a la
reusabilidad de un software existente, las historias de usuario se definen en base a las actividades a desa-
rrollar para la adaptación del sistema y además en base a requerimientos obtenidos de la comunicación
con el personal de los postgrados.

14
CAPÍTULO 3. MARCO APLICATIVO 15

Número: 1 Nombre: Identificar cambios a realizar en el modelo de la base de datos de CONEST.


Descripción: Determinar los aspectos del modelo de datos que deben ser ajustados en la base de datos
del sistema CONEST.

Número: 2 Nombre: Crear y modificar el modelo de la base de datos de CONEST.


Descripción: Crear la base de datos a utilizar en el nuevo sistema CONEST Postgrado a partir del
modelo utilizado en CONEST 3.0 y realizar las modificaciones identificadas.

Número: 3 Nombre: Migrar datos desde diversas fuentes de datos proporcionadas por la Coordi-
nación de Postgrado.
Descripción: Obtener información a través de documentos proporcionados por la Coordinación de
Postgrado que servirán como fuente de datos y hacer la migración de datos.

Número: 4 Nombre:Migrar datos desde el sistema UXXI.


Descripción: Acceder al sistema Universitas XXI y obtener información académica para la base de
datos.

Número: 5 Nombre: Migrar datos desde el sistema SIGEPOST.


Descripción: Acceder al sistema SIGEPOST utilizado en la Coordinación de Postgrado de la Escuela
de Computación y obtener información académica para la base de datos.

Número: 6 Nombre: Adaptación de la base de datos obtenida.


Descripción: Luego de tener la información académica y administrativa necesaria para que el sistema
CONEST pueda funcionar correctamente, fue necesario realizar adaptaciones sobre los datos y las
tablas de la base de datos.

Número: 7 Nombre: Identificar cambios a realizar en el código de la aplicación.


Descripción: Identificar los ajustes necesarios que se deben realizar a la aplicación para que se ajusten
a los problemas a resolver de los estudios de postgrado.

Número: 8 Nombre: Modificar acción de autocompletado de materias para que realice la búsqueda
según la organización a la que pertenece el usuario.
Descripción: Adaptar la función de autocompletado en la búsqueda de materias para que liste las
materias según la organización a la que pertenece el usuario que está haciendo la consulta.
CAPÍTULO 3. MARCO APLICATIVO 16

Número: 9 Nombre: Crear campo de observación para las materias que se agregan en la oferta
académica.
Descripción: Crear un campo en la oferta académica para almacenar información particular de una
materia.

Número: 10 Nombre: Desarrollar método que permita obtener la lista de los planes académicos a
los que pertenece una materia.
Descripción: Crear método que retorne los planes de estudios a los que pertenece una materia para
cuando se agrega a la oferta académica.

Número: 11 Nombre: Modificar la creación de secciones de la oferta académica.


Descripción: Adaptar el método que realiza la creación de secciones de una materia en la oferta
académica ya que las secciones deben ser únicas.

Número: 12 Nombre: Crear funcionalidad que verifique si un estudiante está inscrito.


Descripción: Crear método que determine si un estudiante está inscrito en un periodo académico
determinado.

Número: 13 Nombre: Crear funcionalidad que permita agregar estudiantes a una sección.
Descripción: Crear método que permita agregar un estudiante a una sección para continuar con la
migración de datos a través de la aplicación y completar los historiales académicos de los estudiantes
actuales.

Número: 14 Nombre: Agregar mensaje en la bitácora cuando se agrega una materia en la oferta
académica.
Descripción: Agregar un registro en la tabla bitacora que permita saber cuándo y quién agregó una
materia a la oferta académica.

Número: 15 Nombre: Determinar las constancias que serán generadas.


Descripción: Determinar, junto al personal administrativo, las constancias que debe generar el sistema.

Número: 16 Nombre: Agregar a la base de datos a la Coordinación de Postgrado como una organi-
zación más en el sistema.
Descripción: Agregar a la base de datos un registro que represente a la Coordinación de Postgrado
como una organización para que el personal administrativo de la misma pueda generar constancias
con la información asociada.
CAPÍTULO 3. MARCO APLICATIVO 17

Número: 17 Nombre: Agregar campos que contenga información institucional a la tabla organiza-
ción.
Descripción: Modificar tabla organización para que almacene información institucional de las distin-
tas coordinaciones que conforman los estudios de postgrado.

Número: 18 Nombre: Crear método para obtener la organización a la que pertenece el usuario en
sesión.
Descripción: Se crea un método necesario para la identificación de la organización a la que pertenece
el usuario en sesión.

Número: 19 Nombre: Modificar métodos que generan los encabezados, pie de páginas, logos y
firmas de las constancias.
Descripción: Adaptar el sistema para que genere los documentos con la información adecuada según
el personal administrativo que los está generando.

Número: 20 Nombre: Modificar estructura del Kardex.


Descripción: Modificar el Kardex que genera la aplicación para adaptarlo a las necesidades de los
estudios de postgrado.

Número: 21 Nombre: Modificar información de la Constancias de Estudios y Notas Aprobadas.


Descripción: Adaptar la Constancia de Estudios y Notas Aprobadas para que se adapten a los reque-
rimientos de los estudios de postgrado.

Número: 22 Nombre: Crear clase que genera la Certificación Pensum.


Descripción: Adaptar el historial de notas, Kardex, para que se ajuste a los estudios de postgrado.
Generar una clase que contenga las funcionalidades necesarias para la creación de la Certificación
Pensum generada por la Coordinación de Postgrado.

Número: 23 Nombre: Crear clase que genera la Constancia de Programas.


Descripción: Generar una clase que contenga las funcionalidades necesarias para la creación de la
Constancia de Programas generada por la Coordinación de Postgrado.

Número: 24 Nombre: Rediseñar estructura de los listados de secciones e inscritos en un periodo


académico.
Descripción: Ajustar los listados de secciones e inscritos en un periodo académico determinado gene-
rados por la aplicación para que muestren la información relacionada a los postgrados.
CAPÍTULO 3. MARCO APLICATIVO 18

Número: 25 Nombre: Modificar métodos en el controlador Estudiante que generan constancias.


Descripción: Adaptar los métodos existentes en el controlador Estudiante para que generen las nuevas
constancias y se ajusten a los cambios realizados.

Número: 26 Nombre: Rediseñar interfaz que presenta las constancias generadas.


Descripción: Modificación de la vista actual, donde son presentadas las constancias generadas, para
adaptarse al ambiente de postgrado.

Número: 27 Nombre: Crear código que agregue los tutores al crear un estudiante.
Descripción: Creación del código necesario para registrar tutores al momento de la creación de un
estudiante en el sistema.

Número: 28 Nombre: Agregar campo de autocompletar al agregar tutores al estudiante.


Descripción: Implementación del código necesario para añadir un campo de autocompletar en la asig-
nación de tutores al estudiante.

Número: 29 Nombre: Crear código para buscar los tutores de un estudiante.


Descripción: Creación del código necesario para buscar los tutores de un estudiante en la base de
datos.

Número: 30 Nombre: Crear código para buscar tutorados de un docente.


Descripción: Creación del código necesario para buscar los tutorados de un docente en la base de
datos.

Número: 31 Nombre: Rediseñar vista del estudiante para visualizar tutores.


Descripción: Adaptación de la vista principal del estudiante para desplegar los tutores asignados en el
sistema.

Número: 32 Nombre: Rediseñar vista del docente para visualizar tutorados.


Descripción: Adaptación de la vista principal del docente para desplegar los tutorados asignados en el
sistema.
CAPÍTULO 3. MARCO APLICATIVO 19

Número: 33 Nombre: Rediseñar vista del personal administrativo para modificar o asignar tutores
al estudiante.
Descripción: Adaptación de la vista del personal administrativo para incluir la opción de modificar o
asignar tutores al estudiante seleccionado.

Número: 34 Nombre: Crear modal que edita los tutores del estudiante.
Descripción: Creación del código necesario para presentar una modal que permite la modificación de
los tutores de un estudiante seleccionado.

Número: 35 Nombre: Rediseñar vistas administrativas.


Descripción: Ajustar las vistas del módulo administrativo.

Número: 36 Nombre: Permitir la edición de estudiantes, docentes, y periodos académicos por parte
del personal administrativo.
Descripción: Implementación de código que permite al usuario en sesión identificado como personal
administrativo la modificación de estudiantes, docentes y periodos académicos en el sistema.

Número: 37 Nombre: Rediseñar tabla en vista de personal administrativo para mostrar postgrados
por su respectiva organización.
Descripción: Modificación de la tabla en la vista del personal administrativo para visualizar los post-
grados por su respectiva organización y permitir una navegación más rápida.

Número: 38 Nombre: Eliminar filtro por semestre en vista de materias.


Descripción: Se elimina el filtro por semestre en la vista de materias por plan de estudio debido a que
no aplica en el ámbito de postgrado.

Número: 39 Nombre: Crear código para permitir agregar nuevos periodos académicos.
Descripción: Creación del código necesario para permitir la agregación de nuevos periodos académi-
cos al sistema.

Número: 40 Nombre: Modificar código para poder inscribir estudiantes nuevos y regulares en un
mismo instante.
Descripción: Modificar los métodos necesarios que permitirán realizar la inscripción de estudiantes
nuevos y regulares.
CAPÍTULO 3. MARCO APLICATIVO 20

Número: 41 Nombre: Agregar validaciones para inscripciones de nuevos y regulares.


Descripción: Implementación de código para validar las inscripciones de nuevos y regulares en el
sistema.

Número: 42 Nombre: Agregar validación de cantidad de créditos en electivas que se pueden inscri-
bir para doctorado y maestría.
Descripción: Implementación de código para validar la cantidad de créditos de materias electivas que
se pueden inscribir para las carreras de doctorado y maestría.

Número: 43 Nombre: Crear método para manejar la inscripción de especializaciones según la oferta
académica.
Descripción: Creación del método para permitir la administración de la inscripción de especializacio-
nes dependiendo de la oferta académica seleccionada.

Número: 44 Nombre: Crear vista del usuario estudiante para aceptar la inscripción en especializa-
ción.
Descripción: Creación del código para la vista que será accedida por el usuario estudiante para permitir
la aceptación de la inscripción en especialización.

Número: 45 Nombre: Crear clase para generar planilla de inscripción.


Descripción: Creación de la clase que genera la planilla de inscripción por medio del sistema.

Número: 46 Nombre: Crear clase para generar constancia de aceptación.


Descripción: Creación de la clase que genera la constancia de aceptación por medio del sistema.

Número: 47 Nombre: Crear tabla en la base de datos para el caso de Estudios Dirigidos.
Descripción: Creación de la tabla que tendrá la información sobre las materias abiertas semestralmente
en la modalidad de Estudios Dirigidos.

Número: 48 Nombre: Modificar vista de oferta académica para mostrar estudiantes con Estudios
Dirigidos.
Descripción: Modificar la vista que muestra la información de la vista académica para mostrar los
casos de Estudios Dirigidos.
CAPÍTULO 3. MARCO APLICATIVO 21

Número: 49 Nombre: Crear métodos para el caso de Estudios Dirigidos.


Descripción: Crear métodos que permita manejar los casos de Estudios Dirigidos.

Número: 50 Nombre: Crear vista de la lista de estudiantes de Estudios Dirigidos de una materia.
Descripción: Crear vista que permita ver y editar la lista de estudiantes que se encuentran optando por
una materia de Estudios Dirigidos.

Número: 51 Nombre: Modificar la vista de selección de materias en el proceso de inscripción para


estudiantes de Estudios Dirigidos.
Descripción: Modificar la vista que permite seleccionar materias en el proceso de inscripción para que
se puedan inscribir materias en la modalidad de Estudios Dirigidos.

Número: 52 Nombre: Crear y modificar tablas de la base de datos que contemplan los pagos de los
estudiantes.
Descripción: Creación y modificación de tablas de la base de datos para implementar los pagos de los
estudiantes en el sistema.

Número: 53 Nombre: Crear métodos que permitan crear y actualizar pagos.


Descripción: Creación de código para permitir la creación y actualización de pagos en el sistema.

Número: 54 Nombre: Rediseñar la vista principal del historial del estudiante.


Descripción: Modificación de la vista principal del historial de estudiante en la aplicación para ser
adaptada al ambiente de postgrado.

Número: 55 Nombre: Actualizar el proceso de inscripción.


Descripción: Actualización del código encargado del proceso de inscripción en el sistema.

Número: 56 Nombre: Determinar los datos a ser migrados para instanciar un postgrado.
Descripción: Escoger los datos necesarios y más relevantes en el proceso de instanciación de un
postgrado mediante el estudio de la información manejada en los postgrados.
CAPÍTULO 3. MARCO APLICATIVO 22

Número: 57 Nombre: Determinar formatos en archivos modelos.


Descripción: Escoger formatos simples y eficientes al momento de expresar las reglas necesarias para
manipular en el archivo modelo, así como estándares a seguir para completar el proceso de ingreso de
información realizado en el archivo.

Número: 58 Nombre: Crear métodos que obtengan, lean y carguen datos de Estudiantes.
Descripción: Creación del código necesario para la obtención del archivo modelo, lectura de los datos
de estudiante dentro del archivo y proceder a guardarlos en la base de datos.

Número: 59 Nombre: Crear métodos que obtengan, lean y carguen datos de Docentes.
Descripción: Creación del código necesario para la obtención del archivo modelo, lectura de los datos
de docente dentro del archivo y proceder a guardarlos en la base de datos.

Número: 60 Nombre: Crear métodos que obtengan, lean y carguen datos de Materias.
Descripción: Creación del código necesario para la obtención del archivo modelo, lectura de los datos
de materia dentro del archivo y proceder a guardarlos en la base de datos.

Número: 61 Nombre: Crear métodos que obtengan, lean y carguen datos de Historiales Académi-
cos.
Descripción: Creación del código necesario para la obtención del archivo modelo, lectura de los datos
de historial académico dentro del archivo y proceder a guardarlos en la base de datos.

Número: 62 Nombre: Determinar validaciones necesarias de los datos a ser migrados.


Descripción: Seleccionar las validaciones necesarias para los datos después de estudiar los posibles
casos dependiendo del tipo de información.

Número: 63 Nombre: Crear tabla migración en base de datos.


Descripción: Creación de la tabla migración necesaria para guardar la información del tipo de migra-
ción realizada en el sistema.

Número: 64 Nombre: Crear vista principal para la migración.


Descripción: Creación de la vista principal en el módulo de migración. Incluye la vista alterna para el
usuario de coordinación donde selecciona la organización a la que va a migrar.
CAPÍTULO 3. MARCO APLICATIVO 23

Número: 65 Nombre: Crear vistas que muestran el resultado de las migraciones.


Descripción: Creación de las diferentes vistas necesarias para desplegar el resultado de cada migración
realizada.

Número: 66 Nombre: Crear bitácora general.


Descripción: Creación de la bitácora general que mantiene un historial de todas las migraciones reali-
zadas.

Número: 67 Nombre: Rediseñar vistas que muestran o crean información de materias.


Descripción: Modificar vistas que permiten la visualización y edición de la información de las mate-
rias.

Número: 68 Nombre: Rediseñar vista de datos académicos.


Descripción: Modificación o eliminación de información y opciones disponibles en la vista de datos
académicos.

Número: 69 Nombre: Rediseñar vista de inicio.


Descripción: Modificación de la vista de inicio para contemplar el ámbito de postgrado.

Número: 70 Nombre: Crear código para visualizar promedio menor a 14.


Descripción: Creación del código que valida la nota del promedio general del estudiante. En el caso
de ser menor a 14 se aplica un estilo diferente en el fondo de la vista que engloba la nota.

Número: 71 Nombre: Crear código para visualizar número de créditos de materia.


Descripción: Creación del código necesario para observar el número de créditos de una materia du-
rante su búsqueda en la vista de materias disponibles en un plan de estudio.

Número: 72 Nombre: Eliminar opciones en vistas que no aplican en postgrado.


Descripción: Eliminar opciones que no aplican en el ámbito de postgrado para diferentes vistas en la
aplicación.
CAPÍTULO 3. MARCO APLICATIVO 24

3.2. Plan de Iteraciones

Al utilizar la metodología XP fue necesaria la definición y desarrollo de distintas iteraciones, las


cuales engloban un conjunto de historias de usuario que van dirigidas a adaptar un aspecto en común del
sistema. La división realizada para establecer las iteraciones se puede observar en la tabla 3.1.

Iteración Aspecto a modificar en CONEST


0 Base de datos
1 Oferta académica
2 Constancias
3 Base de datos
4 Tutor
5 Vistas administrativas
6 Vista de la oferta académica
7 Inscripción
8 Pagos
9 Visualizaciones
10 Migración
Tabla 3.1: Iteraciones

3.2.1. Iteración 0: Adaptación de la base de datos

La primera iteración se utilizó para adaptar el modelo de la base datos del sistema CONEST al pro-
blema presentado en la Coordinación de Postgrado. La misma estará conformada únicamente por pla-
nificación y diseño, debido a que representa procedimientos que se realizaron sin hacer algún tipo de
codificación o pruebas.
CAPÍTULO 3. MARCO APLICATIVO 25

Planificación

Iteración 0
Descripción Adaptación del modelo de la base de datos del sistema CONEST al
problema presentado en la Coordinación de Postgrado de la Facultad
de Ciencias UCV.
Historias de
Usuario
1. Identificar cambios a realizar en el modelo de la base de datos de
CONEST.

2. Crear y modificar modelo de la base de datos de CONEST.

3. Migrar datos desde diversas fuentes de datos proporcionadas por


la Coordinación de Postgrado.

4. Migrar datos desde el sistema UXXI.

5. Migrar datos desde el sistema SIGEPOST.

6. Adaptación de la base de datos obtenida.

7. Identificar cambios a realizar en el código de la aplicación.

Diseño

Luego de realizar el estudio del modelo de datos utilizado en el sistema CONEST, se encontraron
aspectos que deben ser modificados, los mismos se encuentran identificados en la tabla 3.2 donde también
se puede observar la razón y la solución que se propone.

Tabla inicial Aspectos a modificar Tabla final


o crear
No aplica. Crear tabla que
contenga los tipos de • tipo_titulo
títulos académicos que
– id
un docente o estudiante
– descripción
puede tener.
– abreviación
CAPÍTULO 3. MARCO APLICATIVO 26

Para que se manejen un


• docente solo estándar en los • docente
títulos académicos se
– cedula – cedula
utilizará una clave
– organizacion_id – organizacion_id
foránea en el atributo
– tipo_persona_id – tipo_persona_id
“titulo”.
– tipo_dedicacion_docente_id – tipo_dedicacion_docente_id
– tipo_categoria_docente_id – tipo_categoria_docente_id
– telefono_oficina – telefono_oficina
– clave_calificacion – clave_calificacion
– esta_en_permiso – esta_en_permiso
– es_externo – es_externo
– titulo – titulo
– procedencia_titulo – tipo_titulo
– procedencia_titulo

Para que se almacene


• estudiante el título académico de • estudiante
los estudantes.
– cedula – cedula
– municipio_id_vive_actual – municipio_id_vive_actual
– estado_id_origen – estado_id_origen
– direccion_actual – direccion_actual
– telefono_origen – telefono_origen
– direccion_origen – direccion_origen
– cohorte – cohorte
– tipo_titulo

Agregar campos que


• organizacion permitan ingresar • organizacion
información relativa al
– id – id
postgrado en
– facultad_id – facultad_id
documentos generados
– nombre – nombre
por la aplicación.
– nombre_corto – nombre_corto
– observaciones – observaciones
– visible – visible
– ruta_logo – ruta_logo
– direccion
– telefono
– telefono_2
– sitio_web
– correo
CAPÍTULO 3. MARCO APLICATIVO 27

Las tablas relacionas No aplica.


• preinscripcion con la preinscripción
• preinscripcion_historial de materias deben ser
eliminadas ya que
dicho proceso no existe
en los cursos
postgrado.
sice Eliminar tala, ya que No aplica.
no aplica para los
estudios de postgrado.
Se debe eliminar No aplica.
• tipo_algoritmo_seleccion debido a que no aplica
para los cursos de
postgrado.
No aplica. Se agrega la tabla
tipo_pago, debido a • tipo_pago
que en postgrado se
– id
debe mantener un
– descripcion
control de los pagos de
preinscripción,
inscripción y
graduación.
Se eliminan los campos
• materia_en_plan ti- • materia_en_plan
po_algoritmo_seleccion
– carrera_id – carrera_id
_preinscripcion_id,
– plan_nombre – plan_nombre
es_reparable,
– materia_codigo – materia_codigo
se_programa_examen,
– tipo_materia_id – tipo_materia_id
es_de_servicio,
– grupo_nota_id – grupo_nota_id
se_preinscribe, ya que
– nro_creditos – nro_creditos
son términos que no
– nro_horas_teoria – nro_horas_teoria
aplican para los
– nro_horas_practica – nro_horas_practica
estudios de postgrado.
– nro_horas_laboratorio – nro_horas_laboratorio
– ubicacion_carrera – ubicacion_carrera
– requiere_aula – requiere_aula
– requiere_horario – requiere_horario
– creditos_requisito – creditos_requisito
– puede_retirarse – puede_retirarse
– es_reparable
– se_programa_examen
– es_de_servicio
– se_preinscribe

Tabla 3.2: Identificación del Modelo de Datos


CAPÍTULO 3. MARCO APLICATIVO 28

Una vez identificados los aspectos a cambiar, se procede a crear la base de datos utilizando el script
de la base de datos proporcionado por el equipo de desarrollo de CONEST. Luego, se modifica cada
aspecto identificado en cada tabla, se crean la nuevas tablas y se borran las que no se utilizarán. Este
procedimiento se realiza a través de la interfaz que proporciona la herramienta Navicat, la cual sirvió
para crear y administrar la base datos a lo largo de todo el proyecto.

Luego de aplicar los cambios a la base de datos, se procede a determinar las fuentes de datos que
servirán para llenar la base de datos creada. Las fuentes de datos utilizadas se mencionan a continuación:

1. Archivos obtenidos en la Coordinación de Postgrado de la Facultad de Ciencias.

2. Sistemas Universitas XXI (UXXI).

3. Sistema de Gestión de Postgrado (SIGEPOST).

4. Historiales académicos archivados en la Coordinación de Postgrado en Ciencias Computación de


la Facultad de Ciencias UCV.

De los archivos proporcionados por la Coordinación de Postgrado se pudo obtener información sobre
los datos personales del personal administrativo de todos los postgrados de la facultad. Además, también
se pudo obtener datos relacionados a las materias dictadas en los distintos programas, información de
estudiantes graduados en los postgrados, personal docente, entre otros. Cabe destacar que dicha infor-
mación se encontraba en formato Excel y para migrarla a la base de datos se hizo uso de la aplicación
Navicat. Con esta herramienta, luego de limpiar, transformar y organizar la información, se importan los
datos desde las tablas Excel a las tablas de la base de datos. Dicha limpieza de la información se reali-
zaba en los archivos Excel y se basa en quitar información no útil, transformar los datos a los formatos
deseados, colocar encabezados, entre otros. Un ejemplo de este trabajo se puede observar en la figura 3.1.

Figura 3.1: Ejemplo de documentos proporcionados por la Coordinación de Postgrado de la Facultad de Ciencias.
CAPÍTULO 3. MARCO APLICATIVO 29

Además, la Coordinación de Postgrado proporcionó acceso al sistema UXXI del que se pudo extraer
información sobre los estudiantes, docentes y planes académicos de los postgrados. El sistema UXXI
exporta archivos en distintos formatos, tales como Excel, PDF, CSV y RTF. Debido a esto, no siempre
se utilizaron los archivos extraídos. Además, cabe destacar que la información de los estudiantes que se
podía extraer se trataba de estudiantes que ya se encontraban graduados, debido a que la información de
los mismos solo se vacía en UXXI cuando se encuentran en la etapa de culminación del postgrado.

Para este punto se pudo observar que la información actual de los 14 postgrados no se encuentra toda
en la coordinación central, es decir se encuentra en cada una de las coordinaciones de cada postgrado, los
cuales están ubicados físicamente en lugares distintos. Debido a esto, se decidió empezar con un único
postgrado con el que se pueda iniciar el sistema de manera que, luego de ponerlo en producción, los
demás postgrados su fuesen integrando de manera individual. Es por esto que a partir de este punto se
empezó a trabajar únicamente con el postgrado en Ciencias de la Computación.

Para obtener la información del Postgrado en Ciencias de la Computación se obtuvo acceso al sis-
tema SIGEPOST, con el cual se pudo obtener información sobre los estudiantes, materias, docentes e
historiales académicos. Este proceso se realizó mediante la exportación de distintas tablas de la base de
datos del sistema, tales como la tabla estudiante, docente y materia. También, se realizó a través una
consulta que permitía obtener una tabla con la información de los historiales académicos de los estudian-
tes, la misma se puede observar en la codigo 3.1. La consulta mostrada se realizó de tal forma que se
pudiesen llenar distintas tablas de la base de datos de CONEST, estas fueron: materia, materia_en_plan,
materia_en_opcion_carrera, estudiante_en_carrera, oferta_en_periodo, oferta_academica, inscripcion
e historial_academico.

SELECT A.Ci, A.Nombre_p, A.Apellido_p, A.Clase_estudios, P.nombre_pe,


I.nota, M.id_materia, M.nombre_mat, I.estado, PL.ci_pp
FROM Periodo P INNER JOIN
Inscribe I ON P.id_pe = I.id_pe INNER JOIN
Materias M ON I.id_materia = M.id_materia INNER JOIN
Programacion_Docente D ON I.id_pe = D.id_pe AND
I.id_materia = D.id_materia INNER JOIN
Planta_Profesoral PL ON D.ci_pp = PL.id_pp CROSS JOIN
Aspirante_Estudiante_Egresado A
WHERE (I.Nro_planilla = A.Nro_planilla) OR (I.Nro_planilla = A.Ci)
Código 3.1: Query para extraer información de SIGEPOST

En el proceso de inserción de datos en las tablas, era necesario cambiar datos que utiliza la aplica-
ción para generar constancias, para clasificar materias, personal administrativo, entre otras. Las tablas
modificadas fueron:

Carrera: esta tabla representa las carreras gestionadas por el sistema. En el caso de los estudios
de postgrado, representa a cada uno de los postgrados que se dictan en la facultad, por lo que fue
necesario llenar la tabla con la información básica de los mismos.

Facultad: tabla que almacena las facultades de la universidad en donde se desarrolla el sistema. En
CAPÍTULO 3. MARCO APLICATIVO 30

este caso, se agregaron todas la facultades de la Universidad Central de Venezuela.

Grupo nota: tabla que permite clasificar las diferentes maneras que en que se puede clasificar una
materia. Para el caso de postgrado se agregaron dos tipos de notas, la alfanumérica y la numérica.
La primera puede ser Aprobado, Aplazado o Equivalencia. La segunda, representa notas desde 00
a 20.

Organización: tabla que, al poseer información de la las instituciones que harán uso de la aplica-
ción, se actualizó con la información de los postgrados de la Facultad de Ciencias. Información
como dirección, teléfonos, correo electrónico, entre otros, la cual es necesaria para generar los
membretes y pie de páginas para los documentos generados por el sistema.

Período académico: tabla que almacena todos los períodos académicos que el sistema utilizará
para sus funciones normales. Contiene campos como año, período, fecha de inicio, fecha de fin,
es obligatorio, entre otros. Para esta tabla se estudió la información que se tenía de los estudiantes
para determinar desde qué año llenarla, el cual fue 1984. A partir de ese año, se llenó la tabla hasta
el año actual.

Plan: contiene todos los planes de las carreras que se dictan en cada organización, el tipo de ré-
gimen (semestral) y la carrera a la que se le aplica el plan. Dicha tabla se llenó con información
proporcionada con por la Coordinación de Postgrado.

Plan activo: es la tabla que indica cual es el plan activo de cada postgrado en la actualidad en caso
de existir más de uno en cada postgrado.

Tipo cargo docente: tabla que almacena los tipos de cargos que puede tener un docente. Se tuvo
que actualizar con los tipos de cargo que puede tener un docente en los estudios de postgrado.

Tipo categoría docente: tabla que categoriza los docentes según su categoría dentro de la facultad,
es decir indica si un profesor es Agregado, Asociado, Instructor, entre otros.

Tipo dedicación docente: tabla que almacena los tipos de dedicación que tiene un docente dentro
de la facultad.

Tipo materia: tabla que permite almacenar los tipos de materia que existen dentro de los estudios
de postgrado. En este caso se eliminaron algunos que usan los estudios de pregrado y no en los
estudios de postgrado, tales cómo Método y Servicio Comunitario. Además, se agregó el tipo de
materia Tópicos, materias especiales que ven los estudiantes de postgrado.

Tipo nota: representa todas las notas que pueden ser usadas para calificar, se llenó luego de deter-
minar la tablas Grupo Nota.

Tipo personal: contiene los tipos de personal que puede tener la Coordinación de Postgrado, quienes
facilitaron la información con la que se llenó la tabla.

Tipo rol: para esta tabla, que almacena los tipos de rol que puede tener un usuario de tipo admi-
nistrador en el sistema, se reutilizaron los registros del CONEST utilizado en pregrado, pero se
cambió el registro Personal de la Licenciaturas por Personal de los Postgrados. Además se eliminó
el tipo Taquilla.
CAPÍTULO 3. MARCO APLICATIVO 31

Luego, se creó una tabla provisional en donde se almacenó toda la información obtenida. Dicha tabla
sirvió para llenar las tablas de la base de datos de CONEST. Con todo este proceso se logró obtener
la información del Postgrado en Ciencias de la Computación, sin embargo no fue suficiente, ya que el
sistema SIGEPOST no se actualiza constantemente, por lo que fue necesario hacer un último proceso de
carga manual de datos.

Para esta última etapa fue necesario involucrar al personal administrativo de la Coordinación del Post-
grado en Ciencias de la Computación, lo cual incluye a pasantes y secretarias. Dicho proceso se efectuó
a través de las planillas de notas semestrales guardadas en la coordinación, con las que se verificaba
la información ya almacenada en la base de datos o se agregaba la faltante. Para realizar este proceso
se comenzó desde el período 01-2003 para terminar en el período 01-2015 y completar los historiales
académicos de los estudiantes.

Para finalizar, se realizaron una serie de ajustes en el sistema para que el personal asignado para dicha
tarea pudiesen insertar los datos a través de la misma aplicación. Estas modificaciones se explican en la
siguiente iteración.

3.2.2. Iteración 1: Oferta académica

Esta iteración nace de la necesidad de continuar con la migración de los datos académicos de estu-
diantes antiguos y actuales. Para esto se necesitaba incorporar al personal administrativo a dicho proceso,
por lo que se hizo necesario ingresar datos a través de la aplicación. Esto se realizó a partir de la crea-
ción de funcionalidades en el manejo de la oferta académica, así como modificaciones al código que ya
trata con la oferta académica para ser adaptado a la gestión académica en postgrado. Además, se realizan
verificaciones consideradas pertinentes para los procesos y el registro en bitácora al agregar una materia
como medida de control.
CAPÍTULO 3. MARCO APLICATIVO 32

Planificación

Iteración 1
Descripción Desarrollo de funcionalidades relacionadas con la publicación y
modificación de la oferta académica.
Historias de
Usuario
8. Modificar acción de autocompletado de materias para que realice
la búsqueda según la organización a la que pertenece el usuario.

9. Crear campo de observación para las materias que se agregan en


la oferta académica.

10. Desarrollar método que permita obtener la lista de los planes


académicos a los que pertenece una materia.

11. Modificar la creación de secciones de la oferta académica.

12. Crear funcionalidad que verifique si un estudiante está inscrito.

13. Crear funcionalidad que permita agregar estudiantes a una


sección.

14. Agregar mensaje en la bitácora cuando se agrega una materia en


la oferta académica.

Diseño

Para desarrollar la presente iteración se toma en cuenta el estudio previo del código existente y los
procesos involucrados en la oferta académica de pregrado que permiten completar los historiales acadé-
micos de los estudiantes del Postgrado en Ciencias de la Computación a través de la aplicación CONEST.
Para esto, se determina la siguiente serie de pasos:

1. Agregar materia en oferta académica con una sección asociada o verificar su existencia.

2. Agregar estudiantes a la sección o verificar su existencia.

3. Agregar nota de los estudiantes agregados.

El proceso anterior se realiza de forma repetitiva para poder obtener un historial completo de es-
tudiantes a partir de un año predefinido, el cual se escogió el año 2003. Para completar los historiales
desde el 2003 al año actual es necesario agregar las materias de las ofertas académicas a cada periodo.
Se observó que al momento de agregar una materia, el sistema utiliza una búsqueda que autocompleta la
información de la misma a medida de que se escribe el nombre o código de la materia. Es por esta ra-
zón que se modifica el filtro de búsqueda de materia por organización dependiendo de la organización del
CAPÍTULO 3. MARCO APLICATIVO 33

usuario que está utilizando la aplicación y de esta forma evitar que se desplieguen materias pertenecientes
a otros postgrados.

Además, al investigar sobre las materias dictadas en los estudios de postgrado se pudo determinar que
existen materias llamadas Tópicos, de las cuales no todas tienen un código asociado, sino que existe un
materia tópico general que abarca un grupo de tópicos específicos, en la figura 3.2 se puede observar un
ejemplo. Para solucionar este caso se debe crear un campo de observación, el cual puede ser llenado al
momento de agregar la materia a la oferta académica.

Figura 3.2: Ejemplo de los nombres de las materias Tópicos Especiales de Postgrado.

En esta fase de diseño también se lleva a cabo el desarrollo del método para obtener la lista de todos
los planes a los que pertenece una materia, debido a que las materias que se van a dictar en un período
académico se abren para todos los postgrados a los que pertenece. Por lo tanto esta funcionalidad se
utilizará para que ejecute esta tarea de forma automática.

Una vez que se pueden agregar materias a la oferta académica se debe modificar la creación de
secciones. En este caso los estudios de postgrado solo crean secciones únicas por cada materia que se
abre por semestre, por lo que se implementa que la sección por defecto sea “U” y, para los casos en
que pueda hacer falta crear más secciones, se determinó la siguiente denominación U<n>, donde n es
sustituida por un número desde 1 en adelante.
CAPÍTULO 3. MARCO APLICATIVO 34

Luego, para poder completar el proceso antes descrito se debe crear una funcionalidad para ingresar
a un estudiante en una sección de una materia seleccionada previamente por el usuario. Esta función es
iniciada desde la vista de sección, que además permite al usuario observar a los estudiantes ya inscritos,
para facilitar el proceso. Durante este ingreso se tiene la verificación que el estudiante no está actualmente
inscrito y así evitar errores por duplicados.

Finalmente, al implementar estas funcionalidades fue necesario llevar un control de las materias que
son agregadas a la oferta académica mediante el registro en bitácora.

Codificación

Para cumplir los requerimientos planteados en la presente iteración, se estudian los procesos que ya
CONEST realiza, como agregar una materia a la oferta académica. Sin embargo, se pudo observar que
cuando una persona del personal administrativo se encuentra realizando dicho proceso, el autocompletado
del nombre de la materia le muestra materias que no pertenecen a su postgrado, por lo que se modificó la
funcionalidad de autocompletado de materias para que muestre las materias asociadas a la organización
del usuario que se encuentra realizando la acción, esto se puede ver en el código 3.2. Cabe destacar que
cuando el personal administrativo de la Coordinación de Postgrado es quien está usando la aplicación, se
buscarán todas las materias sin importar el postgrado.

def materia
termino = params[:term]
cantidad = termino.strip.split.size
arreglo = []
organizacion = organizacion_de_admin
if cantidad == 1
if organizacion != ’COORD’
objetos = Materia.where(["departamento_id = ’#{organizacion}’ AND
(codigo like ? OR nombre like
?)","#{termino} %"," %#{termino} %"]).take(CANTIDAD_DE_RESULTADOS)
else
objetos = Materia.where(
[ "(codigo like ? OR nombre like ?)",
"#{termino} %"," %#{termino} %"
]).take(CANTIDAD_DE_RESULTADOS)
end
objetos.each{|x| arreglo<<x.nombre_autocomplete}
else
term1, term2 = termino.split
if organizacion != ’COORD’
objetos = Materia.where(
[ "(departamento_id = ’#{organizacion}’ AND (codigo like ? OR
nombre like ?) AND (codigo like ? OR nombre like
?))","#{term1} %"," %#{term1} %","#{term2} %"," %#{term2} %"
]).take(CANTIDAD_DE_RESULTADOS)
else
objetos = Materia.where(
CAPÍTULO 3. MARCO APLICATIVO 35

["((codigo like ? OR nombre like ?) AND (codigo like ? OR nombre


like ?))","#{term1} %"," %#{term1} %","#{term2} %"," %#{term2} %"
]).take(CANTIDAD_DE_RESULTADOS)
end
objetos.each{|x| arreglo<<x.nombre_autocomplete}
end
render text:arreglo.to_json
end
Código 3.2: Modificación de autocompletado de materias

Luego, para poder ver y editar el campo Observación de las materias se agregó el campo observación
a la tabla oferta_academica y a la vista modal que permite agregar materias a una oferta académica.
Además, se realizan las validaciones necesarias para que se pueda ver dicha información en la vista si
existe información en el campo. Al realizar esta modificación las secciones de una materia podrán tener
información que la diferencie de otras secciones, por lo que al agregar una materia tópico que abarque
otras materias que no tengan código, se podrán diferenciar a través de la creación de más secciones en el
sistema.

Debido a que las materias deben ser agregadas a la oferta académica de las carreras en que son im-
partidas, se creó un método en el modelo materia. Este nos permite obtener los planes a los que pertenece
una materia. El resultado es usado para que las materias se creen automáticamente en todos los planes
a los que pertenece sin que el usuario deba hacerlo uno a uno. El código del método creado se puede
observar en el código 3.3.

def materia_en_todos_los_planes
MateriaEnPlan.find(:all, :conditions => [’materia_codigo=?’,
self.codigo])
end
Código 3.3: Código para buscar los planes a los que pertenece una materia.

Una vez que se pueden agregar materias a la oferta de un periodo académico, se debe modificar la
creación de secciones únicas. Para esto, en el momento en que se está agregando la materia, el usuario
debe indicar el número de secciones que se van a abrir. Con esta información, se crean las secciones con
los nombres según la cantidad indicada. Este fragmento del código se puede observar en la código 3.4.

begin
aux_requiere_aula = false
aux_periodo = periodo_id.split(/-/)
aux_periodo = "#{aux_periodo[0]}-#{(aux_periodo[1].to_i-1).to_s}"
if i == 1
nombre_seccion = "U"
oferta_academica = OfertaAcademica.new(materia_codigo: materia_codigo,
nombre_seccion: nombre_seccion, periodo_academico_id: periodo_id,
CAPÍTULO 3. MARCO APLICATIVO 36

docente_cedula_coordinador: ci_coordinador,
tipo_status_calificacion_id: "NC", capacidad: capacidad,
requiere_aula: aux_requiere_aula, estudios_dirigidos:
estudios_dirigidos, observacion: observacion)
oferta_academica.save
if horarios
horarios.each do |k|
ha = HorarioAsignado.new(tipo_dia_id: k.tipo_dia_id, tipo_hora_id:
k.tipo_hora_id, periodo_academico_id: periodo_id,
nombre_seccion: nombre_seccion, materia_codigo: materia_codigo,
tipo_clase_id: k.tipo_clase_id, aula_id: nil, orden: nil)
ha.save
end
end
else
while i <= nro_secciones do
nombre_seccion = "U#{i}"
if i == 1
oferta_academica = OfertaAcademica.new(materia_codigo:
materia_codigo, nombre_seccion: nombre_seccion,
periodo_academico_id: periodo_id,docente_cedula_coordinador:
ci_coordinador, tipo_status_calificacion_id: "NC", capacidad:
capacidad, requiere_aula: aux_requiere_aula, estudios_dirigidos:
estudios_dirigidos, observacion: observacion)
else
oferta_academica = OfertaAcademica.new(materia_codigo:
materia_codigo, nombre_seccion: nombre_seccion,
periodo_academico_id: periodo_id,docente_cedula_coordinador:
ci_coordinador, tipo_status_calificacion_id: "NC", capacidad:
capacidad, requiere_aula: aux_requiere_aula, estudios_dirigidos:
estudios_dirigidos)
end
oferta_academica.save
if horarios
horarios.each do |k|
ha = HorarioAsignado.new(tipo_dia_id: k.tipo_dia_id, tipo_hora_id:
k.tipo_hora_id, periodo_academico_id: periodo_id,
nombre_seccion: nombre_seccion, materia_codigo: materia_codigo,
tipo_clase_id: k.tipo_clase_id, aula_id: nil, orden: nil)
ha.save
end
end
i += 1
end
end
Código 3.4: Código para creación de secciones únicas.
CAPÍTULO 3. MARCO APLICATIVO 37

A partir de que una sección ya se encuentra creada y se puede visualizar como en la figura 3.3, se
procede a agregar estudiantes a las mismas. Para esto, se creó un controlador que se encarga de realizar
dicha tarea. Cabe destacar que esta tarea realiza distintas acciones con el fin de que la migración de datos
se haga de manera rápida. Por ejemplo, una de las acciones que realiza es la inscripción del estudiante
si se está agregando a un periodo en que no aparece inscrito. Para esto, se creó un controlador que se
encarga de realizar de agregar al estudiante al periodo académico y luego a la sección requerida. Cabe
destacar que, para implementar dicho método, es importante tomar en cuenta medidas de seguridad en el
momento en que el sistema se encuentre en producción, estas se basan en la restricción de personal no
autorizado para que realice dicha actividad, por lo que esta acción solo podrá ser ejecutada por personal
administrativo con rol ADMSIS.

Figura 3.3: Vista de las secciones creadas.

Además, se modificó la vista que muestra las secciones para que, al agregar una sección, se pueda
buscar el estudiante con su cédula, nombre o apellido. Esto permite ver la información del estudiante a
través del autocompletado que ya implementa CONEST antes de agregarlo. En el código 3.5 se puede
observar el código que se agregó a la vista y en la figura 3.4 el resultado de la misma.
CAPÍTULO 3. MARCO APLICATIVO 38

#contenido
=form_tag({action: :agregar_estudiante_materia, controller:
:seccion, carrera_id: @carrera_id, materia_codigo:
@materia_codigo, periodo_id: @periodo_id, nombre_seccion:
@nombre_seccion}) do
%fieldset
%legend
Agregar estudiante:
%p
=label_tag :estudiante_cedula, "Nombre, apellido o cedula"
=conest_autocomplete :estudiante, :cedula, :estudiante
=submit_tag "Agregar"
Código 3.5: Código para la vista que agrega estudiantes a una sección.

Figura 3.4: Vista modificada que agrega estudiantes a una sección seleccionada.

Para poder proseguir con el ingreso de un estudiante a una sección es necesario inscribirlo en el
periodo académico de la misma si no se encontraba inscrito. Por lo que fue necesario implementar una
funcionalidad que comprobara si el estudiante se encontraba inscrito en el periodo académico indicado.
Esta validación no se incluía en CONEST original ya que la acción de inscribir un estudiante en un
periodo no actual es una tarea poco común, pero para el presente caso de estudio es fundamental para
poder migrar los historiales de los estudiantes.

Para finalizar con esta iteración se tomó en cuenta que todas las acciones realizadas debían poder ser
auditadas, ya que es necesario saber cuándo y qué usuario realiza cambios sobre las ofertas, materias y
CAPÍTULO 3. MARCO APLICATIVO 39

estudiantes. Para este caso ya muchas acciones estaban siendo documentadas en la bitácora. Sin embargo,
solo faltaba que se almacenara en la bitácora cuando se agrega una materia a la oferta académica, con el
fin de mantener un control sobre los cambios realizados.

Pruebas

Las pruebas funcionales durante esta iteración se basan en realizar el proceso de agregar un estu-
diante, utilizar el autocompletar para observar el filtro por organización, la creación de una sección con
denominación ‘U’ por defecto y ‘U<n>’ al crear más de una, validar que el estudiante está inscrito, vi-
sualizar lista de todos los planes pertenecientes a una materia y observar en bitácora el ingreso de registro
al agregar materia en oferta académica. (Ver tabla 3.2).

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
1 Autocomplete Realizar búsque- Mostrar materias so- Se observaron materias
da de materia lamente del postgrado sólo de la organización
con usuario de del usuario del usuario
Computación
2 Oferta Visualizar campo Visualizar el campo Se puede visualizar el
Académica de “observación” “observación” de las campo de observación
de las materias de materias que tengan de las materias a las
la oferta académi- información en el que se les agrega dicha
ca mismo información
3 Materia Visualizar en Impresión por consola Se imprime por conso-
consola lista de lista de los planes la la lista de los planes
de los planes académicos a los que a los que pertenece la
académicos a los pertenece una materia materia seleccionada
que pertenece seleccionada
una matera
4 Oferta Crear sección en Sección con denomi- Se crea sección y es
Académica la oferta académi- nación ‘U’ para única asignada la denomina-
ca sección y ‘U<n>’ para ción ‘U’ y al agre-
las secciones adiciona- gar más de una sección
les se denominan ‘U<n>’
respectivamente
5 Inscripción Verificar si el es- La aplicación previene La aplicación previene
tudiante se en- que el estudiante sea la inscripción del estu-
cuentra inscrito inscrito nuevamente diante y muestra men-
saje del incidente
6 Oferta Agregar estudian- Agregar el estudiante Se agregó el estudian-
Académica te a una sección a la sección satisfacto- te a la sección con re-
riamente gistro del proceso sa-
tisfactoriamente
CAPÍTULO 3. MARCO APLICATIVO 40

7 Oferta Registrar en bitá- Observar en bitácora Se observa en bitácora


Académica cora el ingreso de el registro relacionado el mensaje de ingreso
una materia a la con el ingreso de una de materia a la oferta
oferta académica materia a la oferta aca- académica
démica

Tabla 3.2: Casos de prueba - Iteración 1

3.2.3. Iteración 2: Constancias y listados

Esta iteración se concentra en la adaptación y elaboración de las constancias que emite el sistema
CONEST. Para poder realizar este proceso se determinaron los principales documentos generados por la
Coordinación de Postgrado y el Postgrado en Ciencias de la Computación. Dicho proceso se realizó en
conjunto con el personal administrativo de los estudios de postgrado. Además, para poder realizar esta
iteración se tuvo que estudiar la manera en que ya el sistema generaba las constancias para los estudios
de pregrado, con el fin de reutilizar los métodos que ya implementa para que al final se modifiquen los
métodos y vistas ya existentes.
CAPÍTULO 3. MARCO APLICATIVO 41

Planificación

Iteración 2
Descripción Adaptación de métodos y vistas que permiten generar las constancias y
listados del sistema.
Historias de
Usuario
15. Determinar las constancias que serán generadas.

16. Agregar a la base de datos a la Coordinación de Postgrado como


una organización más en el sistema.

17. Agregar campos que contenga información institucional a la


tabla organización.

18. Crear método para obtener la organización a la que pertenece el


usuario en sesión.

19. Modificar métodos que generan los encabezados, pie de páginas,


logos y firmas de las constancias.

20. Modificar estructura del Kardex.

21. Modificar información de la Constancias de Estudios y Notas


Aprobadas.

22. Crear clase que genera la Certificación Pensum.

23. Crear clase que genera la Constancia de Programas.

24. Rediseñar estructura de los listados de secciones e inscritos en


un periodo académico.

25. Modificar métodos en el controlador Estudiante que generan


constancias.

26. Rediseñar interfaz que presenta las constancias generadas.

Diseño

Para determinar las constancias que serán generadas fue importante reunirse con el personal admi-
nistrativo con el fin de verificar su requerimientos con respecto a las constancias y listados. Con estas
reuniones se obtuvo una lista de constancias a realizar y además modelos que permitieron realizar las
modificaciones para que el resultado se apegara a lo que ellos vienen manejando. Las constancias a emi-
tir a través de CONEST serían:

1. Kardex.
CAPÍTULO 3. MARCO APLICATIVO 42

2. Constancia de Estudios.

3. Constancia de Notas Aprobadas.

4. Certificación de Pensum.

5. Constancia de Programas.

6. Listado de secciones.

7. Listado de inscritos por semestre.

De los documentos listados existen distintas versiones que dependen del personal administrativo que
lo genere, es decir si una constancia de estudios es generada por la secretaria del postgrado en Ciencias
de la Computación, la misma será firmada por el coordinador de dicho postgrado. Si es generada por
la Coordinación de Postgrado la constancia puede estar firmada por el Coordinador de los Postgrados y
el Decano de la Facultad de Ciencias UCV o únicamente por el primero. Antes que todo, es importante
determinar quién es el usuario que está generando la constancia, para que así se pueda manejar una
medida de seguridad con respecto al tipo de persona administrativo que está emitiendo documentos de
otros postgrado. Para esto se necesita un método que verifique si el usuario es personal administrativo de
la Coordinación de Postgrado o de alguno de los postgrados.

Al estudiar cómo CONEST maneja la emisión de constancias, se pudo observar que la aplicación
tiene una clase en Ruby on Rails por cada una de las constancias que genera y cada una implementa
los métodos que necesita para obtener la información que se coloca en ellas. Además, existe una clase
ConestPdf que contiene los métodos que generan encabezados, pie de páginas, firmas y configuracio-
nes adicionales para la genración del archivo PDF. A través de ConestPdf las clases que generan las
constancias pueden heredar los métodos. Existen clases que podrán ser reutilizadas, tales como constan-
cia_estudios.rb, kardex.rb, notas_aprobadas.rb, listar_seccion.rb y listar_inscritos.rb. Para estos casos
solo se deben modificar la redacción de la constancia y la generación de encabezados y pie de páginas;
para los demás se debe generar la clase que herede de ConestPdf.

Un aspecto importante a modificar es la generación de encabezados y pie de páginas, ya que esta


información cambiaría según el personal administrativo que genere cualquier documento. Esto sucede
porque cada postgrado es una organización independiente, que además se ubican en direcciones diferen-
tes. Para esto, se requiere de un método que permita obtener el identificador de la organización a la que
pertenece el usuario que se encuentra utilizando la aplicación, con el fin de generar la constancia o listado
con el encabezado y pie de página que le corresponde.

Codificación

Inicialmente, fue necesario que la Coordinación de Postgrado, ente que se encarga de coordinar los
postgrados de la Facultad de Ciencias UCV, estuviese representado en el sistema como una organización
más. Esto implica agregar un registro a la tabla organizacion en donde la Coordinación de Postgrado
represente un ente más que hará uso de la aplicación (Ver figura 3.5). A través de esta modificación,
el personal administrativo de dicha coordinación tendrá acceso a la aplicación y se le podrán otorgar
CAPÍTULO 3. MARCO APLICATIVO 43

permisos más amplios que cada uno de los postgrados. Además, las constancias y documentos generados
por ellos tendrán la información de la Coordinación de Postgrado.

Figura 3.5: Coordinación de Postgrado como organización.

Luego, es importante siempre verificar qué tipo de personal administrativo está generando una cons-
tancia, debido a que existe el personal perteneciente a cada uno de los postgrados y el personal que
pertenece a la Coordinación de Postgrado. Este último, debe poder generar cualquier documento de cual-
quier postgrado, ya que es el organismo que administra los postgrados en su totalidad. Para esto, se creó
un método en el controlador ApplicationController (Ver código 3.6).

def organizacion_de_admin
organizacion = PersonalAdministrativoEnOrganizacion.where(
personal_administrativo_cedula: session[:usuario].cedula
).take
if organizacion
return organizacion.organizacion_id
else
return false
end
end
Código 3.6: Método que verifica la organización del personal administrativo.

Ahora, se procede a modificar la clase ConestPdf para que genere encabezados, pie de páginas y
firmas acordes a los estudios de postgrado y la organización que los está generando. En el código 3.7
se puede observar el resultado final de la modificación realizada al método que genera el encabezado de
cualquier documento que haga uso de él. Los encabezados deben llevar el logo de la UCV y además el
logo del postgrado al que pertenezca el personal administrativo que lo está generando. En el caso en que
lo genere personal administrativo de la coordinación, aparecerá el logo de la misma. En la figura 3.6 se
puede observar un ejemplo de encabezados.

def encabezado_pdf(desplazamiento=25,organizacion_id)
organizacion = Organizacion.where(id: organizacion_id).take
logo_UCV_path = "#{Rails.root}/app/assets/images/logo_u2.png"
logo_POST_path =
"#{Rails.root}/app/assets/images/#{organizacion.ruta_logo}"
alto_encabezado = 100
# Area contenedora
font_size 12
CAPÍTULO 3. MARCO APLICATIVO 44

bounding_box([desplazamiento, bounds.top], width: 500, height:


alto_encabezado) do
bounding_box([0, bounds.top], width: 100, height: alto_encabezado) do
image logo_UCV_path, position: :center, scale: 0.30
end
# Texto del encabezado
bounding_box([100,bounds.top], width: 300, height: alto_encabezado) do
move_down 10
if organizacion_id == ’COORD’
text "UNIVERSIDAD CENTRAL DE VENEZUELA\nFACULTAD DE
CIENCIAS\nCOORDINACIÓN DE POSTGRADO", align: :center
else
text "UNIVERSIDAD CENTRAL DE VENEZUELA\nFACULTAD DE
CIENCIAS\nPOSTGRADO EN #{organizacion.nombre}", align: :center
end
#stroke_bounds
end
bounding_box([400, bounds.top], width: 100, height: alto_encabezado)
do
image logo_POST_path, position: :center, scale: 0.30
end
end
end
Código 3.7: Código para generar encabezados.

Figura 3.6: Ejemplo de membrete de documentos generados por CONEST.

Así mismo se realizó con los pie de página, ya que se obtiene la información del postgrado en la tabla
organizacion y se utiliza el método pie_pagina_pdf. Las firmas representan el nombre del director que
certifica la información impresa en la constancia por lo que va a depender de la organización, ya que cada
postgrado tiene un director distinto. Para esto, existe en la tabla departamento que divide cada postgrado
por departamento, es decir por organización y además contiene el campo docente_cedula_jefe almacena
la cedula del coordinador o jefe de cada uno de los postgrados. En esta tabla se consulta la cédula del
docente coordinador del postgrado para obtener sus datos como nombre, apellido y título académico y
usarlos en la firma de las constancias. En el caso de que la constancia esté siendo generada por personal
de la Coordinación de Postgrado, los datos para la firma se obtienen de la tabla parametro_general. Esta
tabla tiene un campo nombre, el cual se refiere al nombre del parámetro que se desea a utilizar, y otro
campo llamado valor que almacena el valor del parámetro consultado. En este caso se quiere obtener el
valor del parámetro DIRECTOR_POSTGRADO, por lo que se hace una consulta a la tabla y se obtiene el
título académico junto con el nombre completo del Coordinador de Postgrado.
CAPÍTULO 3. MARCO APLICATIVO 45

Luego, para comenzar a generar las constancias, se comenzó modificando las que ya el sistema gene-
raba y que se utilzan también para los estudiantes de postgrado. El primer caso es el Kardex del estudiante,
esta constancia no es más que el historial académico del mismo, es decir todo su recorrido en el plan en
que se encuentra inscrito. Inicialmente esta constancia es generada por CONEST, sin embargo hubo que
realizar cambios en su formato para adaptarlo a las necesidades de los postgrado. Algunos de los cambios
realizados fueron:

1. Mostrar únicamente el promedio general, ya que el inicial mostraba el promedio ponderado y la


eficiencia del estudiantes, estos últimos no son parámetros que se toman en cuenta en los estudios
de postgrado.

2. Mostrar el tutor académico del estudiante.

3. Mostrar los datos de encabezado y pie de página acorde a la organización del estudiante si está
siendo generado por él, o del personal administrativo.

Otra constancia que se pudo reutilizar fue la Constancia de Estudios, en este caso se modificaron
algunas diferencias en la redacción del documento. Además, se recrearon los tres tipos de constancias
de estudio que se pueden generar: Constancia de Estudio firmada por el coordinador de alguno de los
postgrados o el coordinador de la Coordinación de Postgrado y la Constancia de Estudios firmada por
el Decano de la Facultad. La última sólo puede ser generada por el personal de la Coordinación de
Postgrado. De la misma manera se realizó la Constancia de Notas Aprobadas, que puede ser generada
por cualquiera de las organizaciones.

Para recrear constancias que no se hicieron anteriormente en el sistema, se crearon nuevas clases que
heredan de la clase ConestPdf. Cada clase representa una constancia distinta. En el caso de la Certifica-
ción de Pensum, constancia que sirve para que la Coordinación de Postgrado certifique la cantidad de
créditos que debe aprobar un estudiante cursante de postgrado según cada tipo de materia, se utilizó la ta-
bla requisito_graduacion_plan ya que permite obtener dicha información. Esta clase utiliza los métodos
heredados de ConestPdf para generar el membrete, el pie de página y la firma del coordinador de post-
grado. Este documento sólo es otorgado por la coordinación por lo que solo es accesible por el personal
que trabaja en ella.

De la misma forma se hizo con la Constancia de Programa, en la que se certifica que un estudiante
perteneciente a algún postgrado de la Facultad de Ciencias, ha cursado materias de un programa, y además
se listan dichas materias. Esta constancia es generada en hoja tamaño oficio, por lo que se usan métodos
de la clase ConestPdf especiales para este tipo de hojas. Además, se agrega la firma del Decano de la
facultad a través de los datos almacenados en la tabla parametro_general.

Un documento muy utilizado por los docentes es el listado de cada una de las secciones a las que le
imparte clases. Estos documentos se generan formato PDF o Excel. Para el primer formato se modifica
la clase ListarSeccionPdf, a la que sólo fue necesario agregarle la verificación de la organización a la que
pertenece quien está generando el listado. Para el formato en Excel de los listados existe un método en el
controlador Estudiante que utiliza una gema de Ruby llamada WriteExcel que genera el documento. En
este caso, únicamente se modificó el método para que generar el encabezado correcto como en los casos
anteriores. De la misma manera, se modificó la nómina de inscritos en un periodo académico.
CAPÍTULO 3. MARCO APLICATIVO 46

Por último, se tuvo que ajustar la vista que permite generar las constancias, haciendo que se verifique
el usuario que accedió a la misma para que le muestre las constancias que puede generar. Así mismo, se
modificó el controlador Estudiante, para que cada vez que un método haga un llamado a una clase que
genera una constancia, le pase por parámetros la organización del usuario, y además agregar los métodos
que generan las nuevas constancias creadas en la presente iteración.

Pruebas

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
1 Administrativo Generar Kardex Descarga de documen- Se obtuvo la constan-
y Estudiante de un estudiante to PDF del Kardex del cia para un estudian-
como usuario estudiante con la in- te usando dos usuarios
del Postgrado de formación académica e distintos, un estudian-
Ciencias de la institucional del Post- te y un personal admi-
Computación. grado de Ciencias de la nistrativo, con la infor-
Computación. mación académica del
primero y los datos del
Postgrado en Ciencias
de la Computación.
2 Administrativo Generar Kardex Descarga del do- Se obtuvo la constan-
de un estudiante cumento PDF del cia de un estudiante
como usuario de Kardex del estudiante usando un usuario per-
la Coordinación con su información teneciente a la Coordi-
de Postgrado. académica y la infor- nación de Postgrado.
mación institucional
de la Coordinación de
Postgrado.
3 Administrativo Generar la Descarga de la Cons- Se obtuvo la Constan-
Constancia de tancia de Estudios de cia de Estudios de un
Estudios de un un estudiante. estudiante usando un
estudiante como usuario perteneciente
usuario de la a la Coordinación de
Coordinación Postgrado y un usua-
de Postgrado y rios perteneciente al
como personal Postgrado en Ciencias
administrativo de la Computación
del Postgrado en con los datos correctos
Ciencias de la según cada uno de
Computación. ellos.
CAPÍTULO 3. MARCO APLICATIVO 47

4 Administrativo Generar la Cons- Descarga de la Cons- Se obtuvo la Constan-


tancia de Notas tancia de Notas Apro- cia de Notas Aproba-
Aprobadas de badas de un estudiante. das de un estudiante
un estudiante usando un usuario per-
como usuario de teneciente a la Coor-
la Coordinación dinación de Postgrado
de Postgrado y y un usuarios pertene-
como personal ciente al Postgrado en
administrativo Ciencias de la Compu-
del Postgrado en tación.
Ciencias de la
Computación.
5 Administrativo Generar Cer- A través de un usua- Se obtuvo la Certifica-
tificación de rio perteneciente a ción de Pénsum de un
Pénsum la Coordinación de estudiante del postgra-
Postgrado, generar una do en Ciencias de la
Certificación de Pén- Computación.
sum de un estudiante
determinado.
6 Administrativo Generar Constan- A través de un usua- Se obtuvo la Constan-
cia de Programas rio perteneciente a cia de Programas de un
la Coordinación de estudiante del postgra-
Postgrado, generar una do en Ciencias de la
Constancia de Progra- Computación.
mas de un estudiante
determinado.
7 Docente y Ad- Generar el lista- Con un usuario tipo Se obtuvo el listado
ministrativo do de estudiantes docente y tipo admi- con los datos persona-
de una sección de nistrativo, generar un les de los estudiantes
una materia en un listado de una sección que cursaron una mate-
período determi- de una materia perte- ria en un período aca-
nado. neciente a un período démico.
académico determina-
do.

Tabla 3.3: Casos de prueba - Iteración 2

3.2.4. Iteración 3: Tutores

La presente iteración se basa en la creación y modificación del sistema para adaptarse al modelo de
estudiante-tutor que se contempla en postgrado. Se desarrollan funcionalidades para permitir la visuali-
zación, asignación o modificación de tutores a un estudiante y los tutorados de un docente. Además, se
aplican las modificaciones a las interfaces pertinentes.
CAPÍTULO 3. MARCO APLICATIVO 48

Planificación

Iteración 3
Descripción Desarrollo de funcionalidades para incluir tutores del estudiante en la
inscripción y migración.
Historias de
Usuario
27. Crear código que agregue los tutores al crear un estudiante.

28. Agregar campo de autocompletar al agregar tutores al estudiante.

29. Crear código para buscar los tutores de un estudiante.

30. Crear código para buscar tutorados de un docente.

31. Rediseñar vista del estudiante para visualizar tutores.

32. Rediseñar vista del docente para visualizar tutorados.

33. Rediseñar vista del personal administrativo para modificar o


asignar tutores al estudiante.

34. Crear modal que edita los tutores del estudiante.

Diseño

Es importante tomar en cuenta el tutor que se le asigna a cada estudiante de postgrado, por esta razón
se diseñan las diferentes partes necesarias para abarcar todo el proceso de forma minuciosa y simple. En
primer lugar se estudian los cambios necesarios a la base de datos y modelos de la aplicación para tratar
con la identificación de los tutores con su estudiante o estudiantes y de igual forma los tutorados del
docente. Además, se tienen las vistas donde cada estudiante puede observar a sus tutores asignados y el
docente puede visualizar cada uno de sus tutorados. Por último es necesario tener seguridad al momento
de asignar uno o dos tutores, de tal manera que sólo es posible por el personal administrativo de cada
organización y es debidamente registrado en la bitácora.

Codificación

Para cumplir los puntos planteados en la presente iteración se crea el código para permitir al usuario
asignar un tutor al momento de crear un estudiante, como se puede observar en la figura 3.7. El código en
el lado del controlador permite la búsqueda del tutor para validar que existe y en caso contrario mostrarle
una alerta al usuario, esto se puede visualizar en el código 3.8.
CAPÍTULO 3. MARCO APLICATIVO 49

Figura 3.7: Vista modificada que agrega el registro del tutor a la creación de estudiante nuevo.

# Agregado para obtener los datos del tutor


@tutor = Docente.where(cedula: params[:estudiante][:tutor_cedula]).take
@tutor = Docente.where(cedula:
params[:autocomplete][:docente__cedula].split[0]).take unless @tutor

unless @tutor
flash[:mensaje] = "Docente no encontrado"
#redirect_to_principal
return
end
Código 3.8: Código para buscar y obtener datos del tutor.

Continuando con la codificación se rediseñan las vistas de la aplicación cuando el estudiante o docente
inicia sesión, mostrando el tutor asignado (Ver figura 3.8) y tutorados respectivamente (Ver figura 3.9).
Esto se completa con el código en el controlador para buscar el docente o los estudiantes en base de datos
tomando en cuenta la cédula del usuario en sesión, cómo se puede observar en el código 3.9.
CAPÍTULO 3. MARCO APLICATIVO 50

Figura 3.8: Vista de estudiante modificada que muestra el tutor asignado.


CAPÍTULO 3. MARCO APLICATIVO 51

Figura 3.9: Vista de docente modificada que muestra los tutorados.

# Se consulta si el estudiante tiene un tutor asignado, para ser mostrado


en la vista
@tutor_asignado = EstudianteEnCarrera.where(
estudiante_cedula: session[:usuario].cedula
).where.not(tutor_cedula: nil).take

if @tutor_asignado
@tutor = Usuario.where(cedula: @tutor_asignado.tutor_cedula).take
end

#Buscar estudiantes de los cuales el docente es tutor (tutorados)


@tutorados_asignados = EstudianteEnCarrera.where(tutor_cedula:
session[:usuario].cedula)
Código 3.9: Código para buscar tutores y tutorados.

Cómo última parte de la codificación de esta iteración se rediseña la vista del usuario identificado
como personal administrativo para incluir la modificación del tutor asignado. Junto a esta modificación
se crea la vista modal para permitir la modificación, cabe acotar que es sólo en caso de ser personal
administrativo que es posible dicha modificación.
CAPÍTULO 3. MARCO APLICATIVO 52

Pruebas

Las pruebas funcionales durante esta iteración se basan en agregar un estudiante y asignarle un tutor
existente, validar que no se pueden agregar tutores inexistentes al momento de agregar un estudiante,
buscar tutor utilizando la funcionalidad de autocompletar, visualizar el tutor de un estudiante, visualizar
los tutorados de un docente y por último asignar y modificar un tutor por medio de un usuario en rol de
personal administrativo. (Ver Tabla 3.5).

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
1 Estudiante Agregar un estu- Registrar estudiante Se registró al estudian-
diante con tutor con tutor en un periodo te con su tutor en el pe-
existente académico riodo académico
2 Estudiante Validar posibili- Arrojar mensaje de Se indicó al usuario
dad de un tutor alerta indicando que que el docente no exis-
no existente el docente no existe y te y no se completo el
negar el registro del registro del estudiante
estudiante
3 Autocomplete Ingresar nombre Mostrar al docente en Se observa resultado de
o cédula del do- el filtro del buscador en la búsqueda al ingresar
cente a buscar caso de que exista sus datos en el busca-
dor
4 Principal Ingresar al siste- La aplicación visualiza Se observa al tutor
Estudiante ma como estu- al tutor del estudiante, asignado del estudiante
diante y observar en caso de tener asig- en la vista principal del
tutor asignado nado un tutor estudiante
5 Principal Ingresar al siste- La aplicación visualiza Se observan los tutora-
Docente ma como docente a los tutorados del do- dos del docente en la
y observar sus tu- cente, en caso de tener vista principal del do-
torados tutorados asignados cente
6 Personal Asignar y modi- Asignar y modificar el Se asigna y modifica el
Administrativo ficar tutor de es- tutor de un estudiante tutor de un estudiante
tudiante en se- por medio de la sesión
sión de personal de personal administra-
administrativo tivo
Tabla 3.5: Casos de prueba - Iteración 3

3.2.5. Iteración 4: Funcionalidades del Personal Administrativo

En esta iteración se estudia e implementa la modificación de vistas presentadas al usuario de admi-


nistración para mejorar su experiencia. Además, se añaden funcionalidades de vital importancia para el
personal administrativo que utilizará la aplicación. Siempre es necesario tomar en cuenta y mejorar la
experiencia del usuario para aumentar la productividad durante cualquier interacción entre el usuario y
CAPÍTULO 3. MARCO APLICATIVO 53

el sistema. Cabe destacar que se toma en cuenta la opinión del personal administrativo al hacer modifica-
ción, así como la experiencia de los desarrolladores al momento de utilizar el sistema.

Planificación

Iteración 4
Descripción Adaptar las funcionalidades utilizadas por el personal administrativo
de los estudios de postgrado.
Historias de
Usuario
35. Rediseñar vistas administrativas.

36. Permitir la edición de estudiantes, docentes, y periodos


académicos por parte del personal administrativo.

Diseño

El personal administrativo representa un tipo de usuario indispensable para le gestión de CONEST,


debido a que es el que se encarga de administrar los demás módulos como Estudiante y Docente, así
como también generar constancias, agregar la oferta académica de cada semestre, enviar correos, entre
otros.

El sistema CONEST maneja distintos roles para un usuario administrador, de estos se tomarán en
cuenta Administrador del Sistema (ADM_SYS) y Personal de Postgrado (PER_POST). El primero le
permite al usuario tener acceso a todas las vistas y funcionalidades contenidas en el sistema. El segundo le
permite al usuario utilizar funcionalidades y ver información relacionada con el postgrado que pertenece,
este rol está diseñado especialmente para personal administrativo como secretarias de los postgrados.

En el CONEST utilizado en los estudios de pregrado, el acceso a las funcionalidades del sistema
por parte del personal administrativo de las licenciaturas se limita a la generación de constancias. Sin
embargo, en los estudios de postgrado, el personal administrativo debe tener un acceso más amplio, ya
que cada postgrado mantiene una gestión propia de sus estudiantes y docentes. Es por esto que esta
iteración se enfoca en adaptar las vistas administrativas y sus funcionalidades para que el personal de los
postgrados pueda efectuar sus tareas diarias a través del sistema.

Las tareas que el personal administrativo de los postgrados debe poder realizar a través de CONEST
y que serán desarrolladas en este trabajo serán:

Gestionar periodos académicos.

Gestionar oferta académica.

Acceder y modificar datos personales y académicos de los estudiantes.

Acceder y modificar datos personales y académicos de los docentes.


CAPÍTULO 3. MARCO APLICATIVO 54

Generar constancias a estudiantes.

Para que el personal administrativo de los postgrados pueda realizar estas tareas, se debe poder pro-
porcionar acceso a dichas funcionalidades el sistema y además agregarlas a las vistas diseñadas para
ello. Sin embargo, antes de comenzar a rediseñar su menú principal, se debe estudiar el menú que uti-
liza el ADM_SIS, quien contiene disponible todas la opciones, con el fin de reutilizar el código que sea
necesario. El menú proporcionado para el ADM_SIS se puede observar en la figura 3.10.

Figura 3.10: Vista del menu de ADM_SIS.

En la figura 3.10 se pueden observar que las siguientes pestañas del menú principal:

Procesos: permite acceder a las opciones relacionadas con la planificación semestral, graduación,
asignación de exámenes y calendario académico.

Usuarios: permite acceder a la búsqueda de estudiantes, docentes y personal administrativo; ade-


más, opciones de contraseñas para acceder al sistema, administrar las fotos del perfil de usuario y
envío de correo.

Solicitudes: permite el acceso a opciones de solicitudes estudiantiles como modificación de ins-


cripción, reincorporación, jurado de trabajo especial de grado, entre otros.

Sistema: permite establecer configuraciones como por ejemplo las fechas de inicio de semestre,
prescripción, reincorporación, calificación, entre otros.
CAPÍTULO 3. MARCO APLICATIVO 55

Social: permite agregar el calendario académico y de eventos mostrado en el sistema.

Por último, luego de haber agregados los campos tipo_titulo a las tablas estudiante y docente, es ne-
cesario proporcionarle al personal administrativo una funcionalidad para que puedan agregar o modificar
información sobre el título de un estudiante o docente.

Codificación

Para comenzar, se modifican las opciones mostradas en el menú principal del personal adminsitrativo
perteneciente a los postgrados, es decir con rol PER_POST. Luego de observar todas la funcionalidades
del menú principal del ADM_SIS se determinó que la pestaña que a ser reutilizada será Usuarios, ya que
a través de ella podrá acceder a los perfiles de los estudiantes y docentes para poder verlos, editarlos
y generar sus constancias. Dicha modificación se puede observar en el código 3.10 dónde se agrega la
pestaña.
#menu-principal
%ul.sf-menu
%li
%a{href:"javascript: return void(0)"} Usuarios
%ul
%li
=link_to_modal "Estudiante", {controller: :principal_admin, action:
:seleccionar_estudiante}, titulo: "Seleccionar Estudiante"
%li
=link_to_modal "Docente", {controller: :principal_admin, action:
:seleccionar_docente}, titulo: "Seleccionar Docente"
%li
%a{href:"javascript: return void(0)"} Solicitudes
%ul
%li
=link_to "Peticiones Estudiantiles"
/ Agregado por Ysabella Carneiro para SMI
%ul
%li
=link_to "Modificación de Inscripción", action:
"consultar_solicitudes", controller:
"solicitud_modificacion_inscripcion"
%li
=link_to "Reincorporación", action: "consultar_solicitudes",
controller: "solicitud_reincorporacion"
%li
=link_to "Solicitud de Jurado TEG"
%ul
%li
=link_to "Consultar Solicitudes", {action: "sec_consultar",
controller: "solicitud_jurado"}
%li
CAPÍTULO 3. MARCO APLICATIVO 56

=link_to "Realizar Nueva Solicitud", action: "formulario",


controller: "solicitud_jurado"
%li
=link_to "Planillas"
=menu_planilla_notas
Código 3.10: Código del menú principal del personal administrativo de los postgrados.

Luego, para que pueda modificar los períodos académicos y la oferta académica lo que se hizo fue que
al iniciar sesión se muestre en la página principal la vista de la oferta académica, esta se puede observar
en la figura 3.11. A través de esta modificación ya el personal administrativos de los postgrados puede
acceder a la oferta académica y hacer uso de todas la funcionalidades que se ofrecen.

Figura 3.11: Vista de la pagina principal del personal administrativo con tipo de rol PER_POST.

Por último, para que el personal administrativo pueda modificar el título académico de estudiantes y
docentes se realizaron cambios en las vistas y controladores de los mismos relacionados con sus datos
personales. En el controlador se genera una lista con los posibles títulos académicos que contiene el
sistema haciendo una consulta a la base de datos. Esta lista se despliega en el área donde se muestran los
datos del estudiante como se observa en la figura 3.12. De la misma manera se hizo con el docente. Con
esto, el personal administrativo del sistema y de los postgrados puede ver y modificar el título académico
de los estudiantes y profesores.
CAPÍTULO 3. MARCO APLICATIVO 57

Figura 3.12: Vista de los datos del estudiante.

Pruebas

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
1 Menú Administrativo Ingresar al sistema Al iniciar sesión se
principal de con un usuario perte- puede visualizar la pes-
personal neciente al personal taña Usuario, la cual
administrativo administrativo del permite buscar a un es-
de los Postgrado en Ciencias tudiantes y ver su ficha,
postgrados. de la de Computación editarla y generar cons-
y a la ficha de un tancias.
estudiante.
CAPÍTULO 3. MARCO APLICATIVO 58

2 Menú Administrativo Ingresar al sistema Al iniciar sesión se


principal de con un usuario perte- puede visualizar la pes-
personal neciente al personal taña Usuario, la cual
administrativo administrativo del permite buscar a un do-
de los Postgrado en Ciencias centes y ver su ficha,
postgrados. de la de Computación editarla y generar cons-
y a la ficha de un tancias.
docente.
3 Oferta Administrativo Ingresar al sistema Al iniciar sesión se
académica. con un usuario perte- puede visualizar ofer-
neciente al personal ta académica y se pue-
administrativo del den acceder a todas la
Postgrado en Ciencias funcionalidad relacio-
de la de Compu- nadas.
tación y visualizar
la oferta académica
de los períodos, así
como también poder
editarlos.
4 Título Administrativo A través de un usua- Al ingresar al perfil de
académico de rio administrativo del estudiantes y docentes
estudiantes y Postgrado en Ciencias se pudo observar el tí-
docentes. de la Computación, se tulo que alcanzaron y
debe poder ver y edi- además seleccionarlo a
tar el título académico través de una lista des-
de los estudiantes y do- plegable.
centes del sistema.

Tabla 3.5: Casos de prueba - Iteración 4

3.2.6. Iteración 5: Adaptación de vistas de período académico

La presente iteración se basa en la modificación de interfaces en la aplicación para adaptarse al am-


biente de postgrado. Se adaptaron vistas del sistema para la correcta visualización de opciones e infor-
mación correspondiente a la selección de materias en una carrera determinada. Además, se modificaron
funcionalidades para permitir la agregación de nuevos periodos académicos en el sistema.
CAPÍTULO 3. MARCO APLICATIVO 59

Planificación

Iteración 5
Descripción Desarrollo de modificaciones en vistas para adaptarse al ambiente de
postgrado y funcionalidades adicionales para añadir períodos
académicos desde la aplicación.
Historias de
Usuario
37. Rediseñar tabla en vista de personal administrativo para mostrar
los postgrados por su respectiva organización.

38. Eliminar filtro por semestre en vista de materias.

39. Crear código para permitir agregar nuevos periodos académicos.

Diseño

Es importante tomar en cuenta la interfaz a la que se expone el usuario durante la utilización de


la aplicación. En esta fase se hacen modificaciones necesarias en diferentes vistas que conciernen a la
búsqueda de materias debido a que no aplica el filtro por semestre en el postgrado. Además, se rediseña la
tabla que despliega los diferentes postgrados para ser agrupados por organización y mejorar el tiempo de
búsqueda que tendrá el usuario al momento de ubicarse en el postgrado requerido. Por último se diseña
la solución para añadir nuevos periodos académicos en el sistema debido a que es necesario contar con
esta opción en el sistema. Se libra de la necesidad de añadir los periodos académicos directamente a la
base de datos.

Codificación

Para completar la fase actual se estudian los cambios necesarios al código existente y la modificación
para contemplar el ambiente de postgrado. Esto abarca tanto código en la vista cómo en el controlador
para evitar posibles riesgos de seguridad al eliminar opciones de la vista pero no en el controlador. En
primera instancia están los cambios a la vista en la selección de postgrado al momento de ingresar en un
periodo académico (Ver figura 3.13).
CAPÍTULO 3. MARCO APLICATIVO 60

Figura 3.13: Vista de selección de postgrado.

Continuando con la codificación se depura la función pertinente al filtro de materias por semestre y
es removido de la aplicación como resultado. Finalmente se trata la adición de la funciona encargada
de agregar nuevos periodos académicos al sistema. En este proceso es necesario aclarar que se inves-
tigó si esta opción estaba disponible en el sistema y al descubrir que no era el caso se procedió a ser
añadida. El código se desarrolla dentro del controlador oferta_academica, identificado por el nombre
nuevo_periodo_academico cómo se observa en el código 3.11. Se crea la validación para revisar si el
periodo académico siendo creado ya existe en el sistema y de ser así se le muestra al usuario un mensaje
indicando esta razón. Se maneja la posibilidad de un error al guardar el nuevo periodo académico y por
último es registrado en bitácora el resultado del proceso.

def nuevo_periodo_academico
#---- Para guardar en el formato A-M-D ----------->
@fecha_inicio = params[:fecha_inicio]
@fecha_fin = params[:fecha_fin]
aux_p = @fecha_inicio.split("/")
ano_inicio = aux_p[2]
@periodo_academico_id =
CAPÍTULO 3. MARCO APLICATIVO 61

"#{params[:datos][:semestre]}-#{ano_inicio}".gsub("P-","")
aplica_reglamento = params[:aplica_reglamento]
obligatorio = params[:obligatorio]
activo = params[:activo]
aplica_reglamento = aplica_reglamento.nil? ? false : true #Si los datos
son null entonces = 0
obligatorio = obligatorio.nil? ? false : true
activo = activo.nil? ? false : true

if @existe_periodo = PeriodoAcademico.exists?(@periodo_academico_id) #
verificar si existe algun periodo_academico
mensaje = "El Período Académico #{@periodo_academico_id} ya existe"
bitacora mensaje
else
periodo_academico = PeriodoAcademico.new(id: @periodo_academico_id,
ano: ano_inicio, periodo: params[:datos][:semestre].gsub("P-",""),
descripcion: @periodo_academico_id, fecha_inicio: @fecha_inicio,
fecha_fin: @fecha_fin, aplica_reglamento: aplica_reglamento,
obligatorio: obligatorio, activo: activo, es_plantilla: false)
begin
periodo_academico.save
Rails.cache.clear
mensaje = "Se agrego el Período #{@periodo_academico_id} y algunas
asignaturas"
bitacora mensaje
rescue Exception => e
#puts e
#sleep 20
mensaje = "No se puede agregar el Período Académico
#{@periodo_academico_id}"
bitacora_error mensaje
end
end
flash[:mensaje] = mensaje
redirect_to action: ’general’
end
Código 3.11: Código para agregar nuevos periodos académicos.

Pruebas

Las pruebas para esta iteración se basan en visualizar la tabla de Postgrados en su respectiva organi-
zación, visualizar la vista de despliegue de materias sin el filtro por semestres, validar la agregación de
un periodo académico existente y agregar un periodo académico nuevo (Ver Tabla 3.7).
CAPÍTULO 3. MARCO APLICATIVO 62

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
1 Oferta Visualizar tabla Visualización de post- Se evidencia que no se
Académica de Postgrados grados en sus respecti- encuentra el filtro por
por organización vas organizaciones semestres en la vista
2 Oferta Validar la agre- No es permitida la El sistema no permite
Académica gación de un pe- agregación de un perio- la agregación del perio-
riodo académico do académico existente do académico repetido
existente y despliega un mensaje
indicando que el perio-
do académico ya existe
3 Oferta Ingresar nombre Mostrar al docente en Se observa resultado de
Académica o cédula del do- el filtro del buscador en la búsqueda al ingresar
cente a buscar caso de que exista sus datos en el busca-
dor
4 Oferta Agregar un pe- Es agregado el perio- Se agrega el perio-
Académica riodo académico do académico nuevo al do académico nuevo al
nuevo al sistema sistema sistema y se despliega
un mensaje indicando
que fue agregado co-
rrectamente
Tabla 3.7: Casos de prueba - Iteración 5

3.2.7. Iteración 6: Inscripción

La presente iteración se enfoca en el proceso de inscripción de los estudiantes de postgrado. Se


estudiarán los procesos de los distintos programas y cómo pueden ser llevados a cabo a través del sistema
CONEST. Además, se crearán métodos y modificarán funcionalidades existentes que se encargan de
realizar la inscripción de los estudiantes y las que generan las constancias que necesitarán para poder
proseguir con el proceso, y además el caso de los estudiantes que desean inscribir Estudios Dirigidos.
CAPÍTULO 3. MARCO APLICATIVO 63

Planificación

Iteración 6
Descripción Adaptación del sistema CONEST para proporcionar las
funcionalidades de inscripción.
Historias de
Usuario
40. Modificar código para poder inscribir estudiantes nuevos y
regulares en un mismo instante.

41. Agregar validaciones para inscripciones de nuevos y regulares.

42. Agregar validación de cantidad de créditos en electivas que se


pueden inscribir para doctorado y maestría.

43. Crear método para manejar la inscripción de especializaciones


según la oferta académica.

44. Crear vista del usuario estudiante para aceptar la inscripción en


especialización.

45. Crear clase para generar planilla de inscripción.

46. Crear clase para generar constancia de aceptación.

47. Crear tabla en la base de datos para el caso de Estudios Dirigidos

48. Modificar vista de oferta académica para mostrar estudiantes con


Estudios Dirigidos.

49. Crear métodos para el caso de Estudios Dirigidos.

50. Crear vista de la lista de estudiantes de Estudios Dirigidos de


una materia.

51. Modificar la vista de selección de materias en el proceso de


inscripción para estudiantes de Estudios Dirigidos.

Diseño

En los estudios de pregrado, CONEST realiza el proceso de inscripción en dos fases, una en la que
se inscriben los estudiantes nuevos y otra en la que se inscriben los estudiantes regulares. Para el ca-
so de postgrado, se debe realizan de igual manera para todos los alumnos. Es por esto que la primera
modificación será permitir que ambas inscripciones de hagan simultáneamente.

Luego, se evalúa cómo es el proceso de inscripción. Tanto los estudiantes regulares y nuevos, única-
mente deben ingresar al sistema e inscribir las materias disponibles y generar la constancia de inscripción
que se generará al finalizar. La diferencia surge entre los distintos tipos de postgrados, es decir para los
CAPÍTULO 3. MARCO APLICATIVO 64

estudiantes de Maestría y Doctorado el proceso es cómo se explicó anteriormente, pero para los estu-
diantes de Especialización el proceso cambia, ya que su programa está definido según el semestre que
van a cursar. Esto quiere decir que un estudiante de Especialización no escoge las materia que va a ver
en un período académico, si no que deberá cursar las materias que el plan de estudio y la oferta acadé-
mica le determine. En este caso, el estudiante solo debe ingresar al sistema y generar el comprobante de
inscripción. Este proceso se encuentra modelado en la figura 3.14.

Figura 3.14: Proceso de inscripción.

Uno de los aspectos que se debe tomar en cuenta para la realización de la inscripción de estudiantes
de postgrado es la validación de créditos aprobados y créditos que el estudiante requiere inscribir, ya que
CAPÍTULO 3. MARCO APLICATIVO 65

se debe controlar que se cumpla con los planes de estudio correspondientes, especialmente el número de
créditos máximo por semestre.

Para finalizar con el proceso de inscripción, se debe crear la clase que genera la planilla de inscrip-
ción, ya que este documento debe ser llevado por los estudiantes a la coordinación respectiva para poder
culminar el proceso luego de ser firmada por su tutor académico. De la misma manera se debe generar
una constancia de aceptación, esta constancia es entregada por el personal administrativo de la respec-
tiva coordinación para certificar que el estudiante fue aceptado para cursar estudios de postgrado en la
Facultad de Ciencias, por lo que es entregada a alumnos nuevos.

Luego, para culminar con el proceso de inscripción se debe tomar en cuenta una modalidad de ins-
cripción de materias utilizada en los postgrados llamada Estudios Dirigidos. Esta modalidad permite que
un estudiante pueda cursar una materia que no haya sido ofertada en un período académico, por lo que
será abierta únicamente para él o alguno otros que deseen verla. Para esto, el tutor del estudiante debe
hacer una solicitud al personal administrativo del postgrado para que le permitan inscribir la materia que
verá en esta modalidad, la cual no será ofertada para otros estudiantes que no sean quienes la solicitaron.

Para poder contemplar el caso de Estudios Dirigidos en el sistema, se debe crear una tabla que al-
macene la información de los estudiante y materias que en esta modalidad en un período académico.
Además, se debe poder editar la oferta académica para que el personal administrativo pueda agregar las
materia a ser dictada como estudios dirigidos y los estudiantes que las cursarán. Un aspecto importante
que se debe tomar en cuenta es que únicamente los estudiantes que hagan la solicitud para ver una ma-
teria en esta modalidad, podrán incluirla en su inscripción. Por lo que es importante que en el momento
en que cualquier estudiante esté realizando el proceso de inscripción, solo pueda ver aquellas materias
que pueda inscribir, es decir que los estudiantes que no solicitaron ver una materia en esta modalidad no
deben poder seleccionarla entre la opciones de la oferta académica. Es por esto que se debe crear una
lista de estudiantes asociada a cada materia dictada como Estudio Dirigido, con la que se podrá permitir
el acceso a la misma sólo a aquellos estudiantes agregados a dicha lista por el personal administrativo.

Codificación

Para comenzar, se modifica el inicio del proceso de inscripción, el cual comienza cuando un estu-
diante ingresa al sistema y oprime el botón inscribir. Al hacer esto se dispuso que para los estudiantes
pertenecientes al Doctorado y la Maestría accedieran a la interfaz en donde deben escoger las materias
que desean ver según las materias ofertadas. Para el caso del postgrado de Especialización, cuando el es-
tudiante ingresa al sistema y comienza el proceso de inscripción, se le muestra directamente las materias
que debe inscribir, según las materias ofertadas para su postgrado. Se debe considerar que para el mo-
mento en que se esta creando la oferta académica , las materias pertenecientes al plan de especialización
que sean ofertadas se le añadirán directamente a la inscripción de los estudiantes de especialización.

Además, se debe verificar que las materias que está inscribiendo el estudiante están correctas de
acuerdo al plan al que pertenece, comprobando el número de créditos de las materias que ya ha inscrito y
que va a inscribir. Para realizar las verificaciones necesarias para completar las inscripción se modifica-
ron lo métodos puede_inscribir_estudiante y estudiante_puede_inscribir_materia. El primero se encarga
de verificar si un estudiante cumple con los requisitos necesarios para poder inscribirse en un período
académico, y el segundo si puede inscribir las materias que han sido seleccionadas. Las modificaciones
CAPÍTULO 3. MARCO APLICATIVO 66

realizadas a dichos métodos se listan a continuación:

Se eliminaron las verificaciones de artículos pertenecientes al reglamento de los estudios de pre-


grado.

Se agregó la verificación sobre deudas de pago de inscripciones anteriores, que le indica al es-
tudiante que no haya pagado que debe dirigirse a su coordinación de postgrado para realizar su
inscripción.

Se valida si el estudiante tiene un promedio menos a 14 puntos, ya que el reglamento de los estudios
de postgrado estipula que "para permanecer en el Programa correspondiente, el estudiante deberá
mantener en cada semestre una calificación promedio ponderado no inferior a 14 puntos"[7].

Se eliminaron las validaciones para inscripción de materias en paralelo, concepto utilizado en pre-
grado y no en postgrado.

Se agregó la verificación de créditos máximos a inscribir por período utilizando la tabla carrera
que almacena el máximo de créditos y asignaturas a cumplir por cada postgrado.

Es importante acotar que las verificaciones de artículos pertenecientes al reglamento están pendientes
por desarrollar pero no son objetivos de este trabajo especial de grado.

Luego, para la inscripción de estudiantes pertenecientes a los programas de especialización, se rea-


lizaron dos métodos que realizan su inscripción de manera automática. Además de los métodos que
realizan la inscripción, se creó la vista que permite al estudiante verificar las materias que va a inscribir
y que luego deberá confirmar para culminar el proceso; esta se puede observar en la figura 3.15.
CAPÍTULO 3. MARCO APLICATIVO 67

Figura 3.15: Inscripción de especialización.

Para terminar con el proceso de inscripción, se debe generar una planilla de inscripción con la infor-
mación de los estudiantes y las materias que han inscrito. La planilla generada por el sistema deberá ser
firmada por su tutor académico y el Coordinador de su Postgrado con la finalidad de culminar el proceso.
Para generar dicho documento se creó una clase que hereda de la clase ConestPdf que proporciona los
métodos necesarios para generar archivos en formato PDF.

El documento generado contiene la siguiente información:

Információn básica del estudiante como apellidos, nombres, cédula, teléfono, correo, postgrado al
que pertenece y título académico.

Profesor tutor.

Fecha de inicio en el programa al que pertenece.

Fecha probable de graduación.

Crédito aprobados, créditos aprobados por convalidación y créditos que desea inscribir.

Financiamiento.
CAPÍTULO 3. MARCO APLICATIVO 68

Asignaturas a inscribir.

Un aspecto importante realizado en la presente iteración fue la constancia de aceptación de estudian-


tes, la cual certifica que una persona fue aceptada a cursar estudios de postgrados en algún plan. Dicha
constancia únicamente podrá ser generada por personal administrativo a través del perfil del estudiante al
que este puede acceder.

Para llevar a cabo la tarea de generar la constacia de aceptación, se repitió el mismo proceso reali-
zado para la creación de la planilla de inscripción con la diferencia de que la constancia de inscripción
únicamente debe indicar los datos personales del estudiante, el plan para el que fue aceptado y el período
en el que comenzará a cursarlo.

Por último, se deben hacer las adaptaciones relacionadas con la modalidad de Estudios Dirigidos.
Para comenzar, se crea la tabla estudios_dirigidos con los campos estudiante_cedula, carrera_id, perio-
do_academico_id, materia_codigo y plan_nombre. Además, se debe modificar la tabla oferta_académica
para que pueda llevar el registro de las abiertas como Estudios Dirigidos, ya que con esto podemos ob-
servar en la vista de la oferta de cada período si una materia está abierta en esta modalidad. Con estos
cambios ya es posible modificar los siguientes aspectos:

Modal que agrega materias a un período, donde se puede indicar si la materia que se está agregando
será un Estudio Dirigido, figura 3.16.

Vista de la oferta académica de un período en donde se debe observar si una materia está abierta
como Estudio Dirigido, y además permita tener acceso a la lista de estudiantes seleccionados a
cursar la materia, figura 3.17

Proceso de inscripción con el fin de que al seleccionar las materias que van a ser mostradas a cada
estudiante, seleccionen las materias de Estudios Dirigidos solo si se encuentra en la lista de la
materia, en caso contrario el estudiante no debe poder tenerla en sus opciones.

Figura 3.16: Modificación del modal para agregar materia de Estudios Dirigidos.
CAPÍTULO 3. MARCO APLICATIVO 69

Figura 3.17: Modificación de la Oferta Académica para que identifique las materias de Estudios Dirigidos.

A parte de las modificaciones, se debió agregar una vista en donde se pueda ver, agregar y eliminar
estudiantes que cursarán una materia de Estudios Dirigidos. Esta vista se puede observar en la figura 3.18.

Figura 3.18: Vista para lista de estudiantes en materia de Estudios Dirigidos.

Además de las modificaciones a las vistas se realizaron los métodos necesarios en el controlador Ofer-
taAcademica que permiten agregar a los estudiantes a la lista de Estudios Dirigidos, así como también
eliminarlos de la misma. Por último, se realizaron modificaciones en el controlador Inscripcion en donde
se le agrega la materia al estudiante que vaya a cursar una materia en Estudios Dirigidos antes de que
pueda ver la oferta académica, es decir que en el momento en que dicho estudiante se va a inscribir podrá
observar la materia ya seleccionada; sin embargo es libre quitarla y no inscribirla. Cabe destacar que esta
ultima modificación hace que los estudiantes que no solicitado cursar una materia en esta modalidad, no
podrá observarla en oferta, por lo que no será posible que la inscriba.

Pruebas

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
CAPÍTULO 3. MARCO APLICATIVO 70

1 Inscribir Estudiantes Ingresar al sistema uti- Se ingresó al sistema y


estudiante lizando un estudiante se realizó el proceso de
nuevo de nuevo perteneciente al inscripción obteniendo
Doctorado en Doctorado en Ciencias la planilla de inscrip-
Ciencias de la de la Computación y ción correspondiente.
Computación realizar el proceso de
inscripción.
2 Inscribir Estudiantes Ingresar al sistema uti- Se ingresó al sistema y
estudiante lizando un estudiante se realizó el proceso de
regular de Es- regular perteneciente a inscripción obteniendo
pecialización la Especialización en la planilla de inscrip-
en Sistemas de Sistemas de Informa- ción correspondiente.
Información. ción y realizar el pro-
ceso de inscripción.
3 Validación de Estudiante Ingresar al sistema con Se obtuvo una notifica-
exceso de un usuario estudiante, ción que indica el exce-
créditos por realizar la inscripción y so de créditos.
semestre exceder el número de
créditos permitidos (15
créditos)
4 Estudiante con Estudiantes Realizar a el proceso El sistema indica que
deuda de inscripción median- no se puede continuar
te el usuario de un es- la inscripción y que se
tudiante que tenga una debe dirigir a la Coor-
deuda de pago de ins- dinación para realizar-
cripción. la.
5 Generar Administrativo Generar constancia de Se obtuvo la constan-
constancia de aceptación de un es- cia de aceptación.
aceptación tudiante utilizando el
usuario del personal
administrativo.
6 Agregar Administrativo Agregar una materia a Se agregó la materia y
materia a la la oferta académica de se puede observar en la
oferta un período en específi- oferta académica con
académica co en la modalidad de el acceso a la lista de
como Estudios Estudios Dirigidos estudiante a cursarla.
Dirigido
7 Agregar un Administrativo Agregar a un estudian- Se agregó a un estu-
estudiante a te a la lista de Estudios diante a la lista de es-
una materia Dirigidos a través de la tudiantes por inscribir
ofertada como interfaz creada. la materia en Estudios
Estudios Dirigidos.
Dirigidos
CAPÍTULO 3. MARCO APLICATIVO 71

8 Eliminar un Administrativo Eliminar a un estudian- Se eliminó a un estu-


estudiante de te de la lista de estu- diante a la lista de estu-
la lista una diantes que desean ins- diantes que desean ins-
materia cribir una materia co- cribir una materia en
ofertada como mo Estudio Dirigido a Estudios Dirigidos.
Estudios través de la interfaz
Dirigidos creada.
9 Inscribir Estudiante Ingresar al sistema con Al ingresar el estudian-
período usuario de tipo Estu- te ya tenia selecciona-
académico diante y realizar una da la materia que había
teniendo una inscripción, luego de solicitado para ver en
materia de haber sido agregado a dicha modalidad, por
Estudios la lista de una mate- lo que únicamente ne-
Dirigidos ria ofertada como Estu- cesitó finalizar la ins-
dios Dirigidos. cripción.
10 Inscribir Estudiante Ingresar al sistema con Al ingresar, el estu-
período usuario de tipo Estu- diante no tiene en la
académico sin diante y realizar una oferta académica la
tener una inscripción y verificar materia ofertada como
materia de que se le oferta la Estudios Dirigidos.
Estudios materia agregada como
Dirigidos Estudios Dirigidos.

Tabla 3.7: Casos de prueba - Iteración 6

3.2.8. Iteración 7: Pagos

En los estudios de postgrado, cada estudiante debe realizar un pago por concepto de cada crédito
que inscribe y además otros aranceles necesario según sea el caso. La presente iteración se enfoca en
la adaptación CONEST para que contemple manejar la información de los pagos por concepto de ins-
cripción semestral por parte de los estudiantes. Para esto, se realizaron cambios a nivel de base de datos,
métodos en los controladores y vista con la finalidad de que el personal administrativo pueda verificar
los pagos realizados por los estudiantes por cada semestre. Además, se retomó el proceso de inscripción
para agregarle la validación de este aspecto.
CAPÍTULO 3. MARCO APLICATIVO 72

Planificación

Iteración 7
Descripción Adaptar el sistema CONEST para que maneje la información sobre
pago por concepto de inscripción.
Historias de
Usuario
52. Crear y modificar tablas de la base de datos que contemplan los
pagos de los estudiantes.

53. Crear métodos que permitan crear y actualizar pagos.

54. Rediseñar la vista principal del historial del estudiante.

55. Actualizar el proceso de inscripción.

Diseño

Inicialmente, el sistema CONEST únicamente manejaba un campo en la tabla inscripcion que indica-
ba el número del depósito relacionado al pago de las inscripción del estudiante en un período académico.
Dicha información no es suficiente para los estudios de postgrado, ya que se debe manejar un historial de
pagos que ha realizado el estudiante junto con los montos y el status. Es por esto que se deben realizar
modificaciones a la base de datos para que se pueda almacenar dicha información.

Luego, se deben realizar modificaciones a la aplicación para que la información de pagos sea accesible
por el personal administrativo. En este caso se debe agregar a la ficha del estudiante una sección en donde
se puede visualizar el historial de pagos del mismo, y además se pueda actualizar la información cada
vez que sea necesario. Es por esto que se deben crear métodos que realicen la creación y modificación de
los pagos en el controlador Estudiante.

Por último, una vez que se pueden gestionar los pagos de inscripción a través de la aplicación, es
importante actualizar el proceso de inscripción de los estudiantes. La razón de esto es que el tener una
deuda de inscripción es un impedimento para el estudiante para poder inscribirse, por lo que el sistema
no debe permitir que siga con el proceso. Además, se debe agregar al proceso de inscripción la creación
de un pago cada vez que un estudiante se inscriba en un período.

Codificación

Para comenzar se crearon tres tablas nuevas. La primera, tipo_pago, almacena los tipos de pagos
que se pueden registrar en el sistema, tales como grado, relacionado al proceso de graduación; inscrip-
ción, relacionado al proceso de inscripción semestral, y postulación, relacionado al proceso de preins-
cripción que deben hacer los estudiantes para ser aceptado en un programa de postgrado. La segunda,
tipo_status_pago, permite almacenar los diferentes estados en que puede estar un tipo de pago, en los
que se encuentra ’PAGADO’ y ’NO PAGADO’. La última tabla creada, pago, almacena el historial de
pagos de los estudiantes, mostrando el monto, la fecha, el monto, el status y el tipo de pago.
CAPÍTULO 3. MARCO APLICATIVO 73

Además, la tabla inscripcion se le elimina el campo nro_deposito y es sustituido por el identificador


del pago que le corresponde, para así mantener el registro de los pagos por cada inscripción realizada en
un período académico.

Luego, se crean los métodos en el controlador Estudiante para crear los pagos y guardarlos en la
tabla correspondiente, estos se pueden observar en código 3.12. Los métodos creados dan paso a las
modificaciones en la interfaz con la que el persona administrativo podrá tener acceso a la información de
deudas de cada estudiante.

pago = Pago.create(tipo_pago_id: TipoPago::INSCRIPCION,


tipo_status_pago_id: TipoStatusPago::NO_PAGADO)
proceso.inscribir_estudiante(
{carrera_id: session[:estudiante_en_carrera].carrera_id,
periodo_academico_id: periodo_academico_id,
estudiante_cedula: estudiante_cedula,
pago_id: pago.id,
entrego_recibo: false,
fecha_hora: Time.now,
ip_origen: ip_origen,
observaciones: "Modulo: #{TipoModulo::ESTUDIANTE}, CONEST3 , NUEVO"},
false
)
Código 3.12: Código para crear registro de pago de inscripción.

En la figura 3.19 se puede observar la sección que se agregó para visualizar la información de los
pagos, y en la figura 3.20 se puede observar la vista que se creó para poder realizar la actualización de un
pago.

Figura 3.19: Sección de pagos.


CAPÍTULO 3. MARCO APLICATIVO 74

Figura 3.20: Modificar pagos.

Por último, se debe actualizar el proceso de inscripción, el cual debe crear un registro de pago cada
vez que un estudiante se inscribe en un período académico. La modificación realizada se puede observar
en el código, que fue agregada a los métodos que realizan la inscripción.

Pruebas

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
1 Realizar Estudiante y Ad- Ingresar al sistema con Se obtuvo la creación
inscripción ministrativo un usuario de tipo estu- del pago que se pudo
que genere el diante, realizar una ins- observar en el perfil del
registro del cripción y luego, con estudiante.
pago. un usuario de tipo ad-
ministrativo, compro-
bar la creación de un
pago.
CAPÍTULO 3. MARCO APLICATIVO 75

2 Realizar Estudiante Ingresar al sistema con El sistema no continuó


inscripción un usuario de tipo es- con la inscripción y le
con pago tudiante que tenga una indicó al usuario que
pendiente. deuda de pago, para debe inscribirse en su
que el sistema impida coordinación de post-
su inscripción. grado.
3 Actualizar Administrativo Ingresar al sistema con Se modificó exi-
pago un usuario de tipo ad- tosamente el pago
ministrativo y modifi- de "NO PAGADO.a
car el pago de un estu- "PAGADO".
diante del Postgrado en
Ciencias de la Compu-
tación.

Tabla 3.8: Casos de prueba - Iteración 7

3.2.9. Iteración 8: Migración de datos

La iteración actual abarca el núcleo de la migración para que sea posible instanciar un postgrado
en el sistema. Se consideran las partes necesarias para completar una migración como son los datos de
docentes, estudiantes, materias e historial académico. Este último es tomado en cuenta especialmente
debido al tipo de información que maneja. Durante la iteración se evalúan las validaciones a implementar
y los registros de todas las migraciones ejecutadas.
CAPÍTULO 3. MARCO APLICATIVO 76

Planificación

Iteración 8
Descripción Desarrollo de vistas y funcionalidades para permitir la migración de
datos en el sistema.
Historias de
Usuario
56. Determinar los datos a ser migrados para instanciar un
postgrado.

57. Determinar formatos en archivos modelo

58. Crear métodos que obtengan, lean y carguen datos de Estudiantes

59. Crear métodos que obtengan, lean y carguen datos de Docentes

60. Crear métodos que obtengan, lean y carguen datos de Materias

61. Crear métodos que obtengan, lean y carguen datos de Historiales


Académicos

62. Determinar validaciones necesarias de los datos a ser migrados

63. Crear tabla migracion en base de datos

64. Crear vista principal para la migración

65. Crear vistas que muestran el resultado de las migraciones

66. Crear bitácora general

Diseño

En la presente iteración se contempla el diseño de la solución para la migración de los datos necesarios
en una instanciación del Postgrado deseado. Durante la iteración 0 se reunió suficiente información para
crear una estructura similar a la migración realizado durante dicha iteración. Al estudiar detalladamente
el proceso se pueden evitar todos los pasos realizados durante dicha iteración y proceder a realizar un
diseño del flujo para aplicar el proceso de manera automática (Ver Figura 3.21).
CAPÍTULO 3. MARCO APLICATIVO 77
CAPÍTULO 3. MARCO APLICATIVO 78

Figure 3.21: Flujo del proceso de Migración.

Cabe resaltar que durante este proceso se descubrió que la Coordinación de Postgrado no contie-
ne toda la información de los 14 postgrados, por esta razón es necesario permitir una migración desde
cualquier lugar. Por esta razón es de vital importancia desarrollar un modulo de migración dentro de la
aplicación Web, a la cual puedan tener acceso todos los usuarios autorizados que hacen parte de los dife-
rentes postgrados. Para mantener la seguridad, cada acción realizada dentro del controlador de migración
es verificada por la permisología de usuario. Esto asegura que cualquier acción no se pueda realizar por
un usuario no autorizado.

Durante esta fase también se estudia detalladamente la información y los pasos necesarios para com-
pletar una migración de manera efectiva. La lógica extraída del estudio es traducida al diseño de las
funciones para determinar los datos a migrar en docente, estudiante, materia e historial académico. Ade-
más, se tiene el formato del archivo modelo que será utilizado por el usuario para insertar los datos a ser
migrados.

Se diseñan funciones para cada tipo de dato migrado: docente, estudiante, materia e historial acadé-
mico. Cada función completa su proceso contemplando validaciones de los datos a ser ingresados. Estas
validaciones son el resultado de estudiar las tablas de la base de datos, el proceso inicial de migración
tratado en la iteración 0 y los tipos de datos utilizados durante el ingreso de datos por el usuario al archivo
modelo.

El proceso de migración es realizado de forma repetitiva hasta completar la carga de datos necesarias
del Postgrado, aunque es posible continuar migrando de ser necesario. Por cada migración hecha se
tienen los ingresos en bitácora automáticamente para los registros que resultaron correctos, repetidos y/o
CAPÍTULO 3. MARCO APLICATIVO 79

erróneos en cada migración. Es necesario tener registrada cada migración realizada por organización y
usuario que la realizó para llevar un control de seguridad.

Codificación

La codificación de la presente iteración completa el proceso de migración. La vista principal está


compuesta por las instrucciones antes de realizar cualquier migración y la selección del postgrado al que
se realizará la migración (Ver Figura 3.22). Es necesario aclarar que esta opción solo esta disponible para
los usuarios de la Coordinación de Postgrado, para que sea posible realizar la migración de cualquier
postgrado disponible en el sistema. Los usuarios de cada postgrado son identificados por el sistema y
llevado directamente a las opciones de migración.

Figura 3.22: Vista principal del modulo de migración.


CAPÍTULO 3. MARCO APLICATIVO 80

El núcleo del código se comienza creando el controlador migración para abarcar todo el código. El
controlador inicia con la obtención de información sobre el usuario en sesión para proceder a mostrar la
vista adecuada dependiendo de la organización a la que pertenece. A continuación se comienzan a crear
los cuatro métodos principales: upload_docente, upload_estudiante, upload_materia y upload_historial.
Cada método inicia con la adquisición del archivo modelo a cargar, la lectura de la primera fila en el
archivo y prosigue a la verificación de los datos por medio de las validaciones (Ver código 3.13).

def upload_estudiante
migration = Spreadsheet.open(params[:file].tempfile)
sheet = migration.worksheet 0
session[:log_mig_est] = Array.new
err = err_log = rep_log = ok_log = 0
# Comienza en la fila 7 a recorrer las filas del archivo de Excel, puede
ser modificado ajustandose a la estructura del archivo
(7..sheet.row_count).each do |i|
# Asigna la informacion de la fila i en ’row’
row = sheet.row(i)
if row.blank?
break
end
# Validaciones
if row[0].blank?
err = 1
session[:log_mig_est] << [Time.now.strftime(" %Y- %m- %d %I: %M %p"),
"Registro #{i-6}", "El campo ’Cedula’ esta vacio",
request.remote_ip]
end
if row[1].blank?
err = 1
session[:log_mig_est] << [Time.now.strftime(" %Y- %m- %d %I: %M %p"),
"Registro #{i-6}", "El campo ’Estado Civil’ esta vacio.",
request.remote_ip]
end
if row[2].blank?
err = 1
session[:log_mig_est] << [Time.now.strftime(" %Y- %m- %d %I: %M %p"),
"Registro #{i-6}", "El campo ’Sexo’ esta vacio.",
request.remote_ip]
end
if row[3].blank?
err = 1
session[:log_mig_est] << [Time.now.strftime(" %Y- %m- %d %I: %M %p"),
"Registro #{i-6}", "El campo ’Nacionalidad’ esta vacio.",
request.remote_ip]
elsif (row[3].upcase.eql? "V") && ((row[0].length > 8) || (false if
Float(row[0]) rescue true))
err = 1
session[:log_mig_est] << [Time.now.strftime(" %Y- %m- %d %I: %M %p"),
"Registro #{i-6}", "El campo ’Cedula’ contiene formato
CAPÍTULO 3. MARCO APLICATIVO 81

incorrecto: #{row[0]}. (Formato aceptado: 12345678)",


request.remote_ip]
end
if (!row[1].blank? && (!["C","S","CO","D","V"].include? row[1].upcase))
err = 1
session[:log_mig_est] << [Time.now.strftime(" %Y- %m- %d %I: %M %p"),
"Registro #{i-6}", "El campo ’Estado civil’ debe ser: S, C, CO, D
o V. (Valor ingresado: #{row[1]})", request.remote_ip]
end
if (!row[2].blank? && (!["F","M"].include? row[2].upcase))
err = 1
session[:log_mig_est] << [Time.now.strftime(" %Y- %m- %d %I: %M %p"),
"Registro #{i-6}", "El campo ’Sexo’ debe ser: F o M. (Valor
ingresado: #{row[2]})", request.remote_ip]
end
Código 3.13: Código seleccionado de upload_estudiante.

Continuando con la ejecución del método se procede con las instrucciones para guardar en base de
datos. Es necesario verificar si el registro ya existe en la base de datos para evitar errores de duplicados en
la llave primaria. Después se ejecuta el código encargado de guardar los datos en el objeto a ser utilizado
para guardar el registro en la tabla determinada (Ver código 3.14).

unless Usuario.exists?(cedula: row[0])


usuario = Usuario.new
usuario.cedula = row[0]
usuario.tipo_estado_civil_id = row[1]
usuario.tipo_sexo_id = row[2]
usuario.tipo_nacionalidad_id = row[3]
usuario.primer_nombre = row[4]
usuario.segundo_nombre = row[5]
usuario.primer_apellido = row[6]
usuario.segundo_apellido = row[7]
usuario.correo = row[8]
usuario.correo_2 = row[9]
usuario.telefono = row[10]
usuario.celular = row[11]
usuario.fecha_nacimiento = row[12]
usuario.clave = Digest::SHA1.hexdigest("1#{usuario.cedula}0")
usuario.save
ok_log += 1
else
session[:log_mig_est] << [Time.now.strftime(" %Y- %m- %d %I: %M %p"),
"Registro #{i-6}", "El usuario ya existe. (Cedula: #{row[0]})",
request.remote_ip]
rep_log += 1
end
Código 3.14: Código para guardar los datos obtenidos en la base de datos.
CAPÍTULO 3. MARCO APLICATIVO 82

Además, en la codificación tenemos que incluir el registro en bitácora para mantener un control de las
migraciones hechas. Estos registros son de suma importancia para poder auditar las migraciones hechas
por cada organización, así como el control dentro de la organización por los usuarios que utilizan la
aplicación. En el código se añade el mensaje en vista para garantizar al usuario la acción que acaba de
realizar. (Ver código 3.15).

# Escribir a bitacora
mensaje = "Organizacion: #{session[:nombre_postgrado]}. Migracion de datos
de estudiante: Se ingresaron #{ok_log} registros correctamente,
#{rep_log} registros repetidos, #{err_log} registros con errores"
flash[:mensaje] = mensaje
Bitacora.agregar(session["usuario"].cedula, session[:periodo_academico],
"ADM", mensaje, request.remote_ip, "INFO-MIG")
redirect_to action: :index, anchor: ’tabs-2’
Código 3.15: Código para guardar en bitácora.

También se puede observar la vista creada para mostrar los mensajes de la bitácora de migración, que
tienen como prioridad hacer saber al usuario la fecha y hora, el registro afectado, la descripción del error
y por ultimo la dirección de IP del usuario en sesión. (Ver Figura 3.23).
CAPÍTULO 3. MARCO APLICATIVO 83

Figura 3.23: Vista de bitácora de migración.

Siguiendo con las bitácoras, se tiene la bitácora general que hace parte de las diferentes formas que
tiene el usuario para mantener un registro de todas sus acciones. Esta bitácora es guardada en la base de
datos y siempre puede ser accedida mediante la opción de "Bitácora". (Ver Figura 3.24).
CAPÍTULO 3. MARCO APLICATIVO 84

Figura 3.24: Vista de bitácora de migración.

Por último en la codificación se utilizan variables de sesión en el controlador para mantener el estado
durante las transiciones entre las diferentes acciones que realiza el usuario a medida que transcurre todo
el proceso de migración.
CAPÍTULO 3. MARCO APLICATIVO 85

Pruebas

En la fase de pruebas se comprueba el proceso de migración imitando a un usuario haciendo uso


del sistema, ejecutando todos los posibles casos de validaciones existentes, validando que el sistema
identifique correctamente al usuario en sesión para desplegar las opciones de migración a su disposición
y comprobar que las migraciones de estudiante, docente y materia fueron ejecutadas antes de permitir la
migración de historial académico. (Ver Tabla 3.10).

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
1 Migración Migrar datos de Ingreso correcto de los Se ingresan correcta-
estudiantes registros de estudiante mente los datos en las
en la base de datos al fi- tablas necesarias man-
nalizar la migración teniendo integridad
2 Migración Migrar datos de Ingreso correcto de los Se ingresan correcta-
docente registros de docentes mente los datos en las
en la base de datos tablas necesarias
3 Migración Migrar datos de Ingreso correcto de los Se ingresan correcta-
materia registros de materias en mente los datos en las
la base de datos tablas necesarias
4 Migración Migrar datos Ingreso correcto de los Se ingresan correcta-
de historial registros de historiales mente los datos en las
académico académicos en la base tablas necesarias
de datos
5 Migración Comprobar vali- Validaciones previenen Se previene la ejecu-
daciones imple- la ejecución de la mi- ción de la migración y
mentadas gración y son registra- se visualizan mensajes
das en bitácora de validaciones en bitá-
cora temporal y la bitá-
cora general para todos
los casos
6 Migración Identificar usua- El sistema identifica al Es identificado el usua-
rio en sesión usuario por organiza- rio en sesión y se des-
ción y despliega las op- pliegan sólo las opcio-
ciones disponibles para nes pertinentes a su
su sesión identificación
7 Migración Comprobar mi- La aplicación com- Se evidencia en conso-
graciones de prueba el estado de la el mensaje de con-
docente, estu- las migraciones para firmación al comprobar
diante y materia el caso de estudiante, correctamente el esta-
fueron ejecutadas docente y materia do de las migraciones
previamente de estudiante, docente
y materia
Tabla 3.10: Casos de prueba - Iteración 8
CAPÍTULO 3. MARCO APLICATIVO 86

3.2.10. Iteración 9: Adaptación de vistas administrativas

La iteración actual desarrolla las modificaciones a las vistas de datos académicos que son presentadas
al usuario para adaptarse al ambiente de Postgrado, así como la creación de código para obtener el número
de créditos de las materias y su visualización en las vistas pertinentes. Además, se rediseña la vista de
inicio y la eliminación de opciones en el plan de estudio que no aplican en Postgrado. Por último se
implementa código para tener una mejor visualización de la nota del estudiante si baja del promedio
deseado.

Planificación

Iteración 9
Descripción Rediseño de vistas para adaptarse al ambiente de Postgrado y
desarrollo de código para visualizar información pertinente.
Historias de
Usuario
67. Rediseñar vistas que muestran o crean información de materias.

68. Rediseñar vista de datos académicos.

69. Rediseñar vista de inicio.

70. Crear código para visualizar promedio menor a 14.

71. Crear código para visualizar número de créditos de materia.

72. Eliminar opciones en vistas que no aplican en Postgrado.

Diseño

El diseño de la presente iteración es el resultado de estudiar las vistas más importantes a tomar en
cuenta durante la utilización de la aplicación. Es necesario mantener un despliegue correcto de informa-
ción y opciones válidas para el usuario. Entre estas modificaciones se encuentra la visualización de una
nota con promedio menor a 14 para que el estudiante se mantenga informado sobre su estado actual. Ade-
más, se eliminan opciones cómo “Modificar Nota de Reparación”, “Correr Algoritmo de Preinscripción”,
“Retiro de Laboratorios”, “Chequeo de Requisitos” y otros que no aplican en Postgrado. Finalmente se
depuran visualizaciones cómo “Nota de Reparación”, “Promedio Ponderado” y “Eficiencia” de la vista
de datos académicos del usuario.

Codificación

En la fase de codificación se depura código con la intención de eliminar o modificar para cumplir
con los objetivos planteados. Para rediseñar las vistas se comenta el código seleccionado previamente
CAPÍTULO 3. MARCO APLICATIVO 87

y se añade una descripción para explicar el propósito de la modificación. En primera instancia se tiene
el código de la vista de datos académicos donde el usuario puede visualizar información del estudiante
como “Promedio Ponderado”, “Nota de Reparación”, entre otros, que no son necesarias en Postgrado.
Además, esta vista cumple con la función de informar al estudiante de su nota, donde el código es añadido
para visualizar un color amarillo si su nota cumple con la condición de ser menor a 14 (Ver figura 3.25).

Figura 3.25: Vista de historial académico de estudiante.

Continuando con las modificaciones realizadas tenemos la vista de materia donde es desarrollado
código sólo en la vista para poder visualizar el número de créditos de dicha materia (Ver figura 3.26).
Esto es posible debido a que en el controlador ya se contaba con el código necesario para obtener esta
información pero no fue implementado en la vista.
CAPÍTULO 3. MARCO APLICATIVO 88

Figura 3.26: Vista de materias en plan de estudio.

Finalmente se eliminan opciones tanto de la vista y el controlador para evitar ser ejecutadas por un
usuario. Entre estas opciones se encuentran: “Chequeo de Requisitos”, “Exámenes”, “Retiro de Labo-
ratorios”, “Asignar Horas de Laboratorio”, “Correr Algoritmo de Preinscripción” y “Modificar Nota de
Reparación”.

Pruebas

Las pruebas durante esta iteración se basan en una visualización correcta de los cambios realizados
al acceder a la aplicación y no poder acceder a las funciones depuradas por medio de métodos alternos
(Ver Tabla 3.11).
CAPÍTULO 3. MARCO APLICATIVO 89

No Caso Módulo Caso de Prueba Resultado Esperado Resultado Obtenido


Prueba
1 Datos Abrir vistas con No se visualiza la in- La información no es
Académicos la información formación eliminada presentada en la vista
eliminada
2 Principal Visualizar color Notar el color de fondo Se visualiza el color
Estudiante amarillo en un amarillo en la nota de amarillo en el fondo de
promedio menor promedio general la nota de promedio ge-
a 14 neral
3 Plan de Visualizar núme- La vista contiene el nú- Se visualiza el número
Estudio ro de créditos de mero de créditos en el de créditos de la mate-
materia área de información de ria
la materia
4 Principal Tratar de acce- El sistema arroja resul- No se ejecutan funcio-
Administrador der a las funcio- tado negativo al tratar nes inexistentes en el
nes depuradas de acceder a las funcio- sistema
nes
Tabla 3.11: Casos de prueba - Iteración 9
Conclusiones

Este Trabajo Especial de Grado se basó en el desarrollo de una versión funcional de CONEST para
los estudios de postgrado, adaptando y reusando la versión de CONEST 3.0 utilizada en la Dirección
de Control de Estudios de la Facultad de Ciencias UCV e integrando una funcionalidad que facilita la
migración de datos para mejorar las posibilidad de una implementación exitosa. El objetivo general y los
objetivos específicos se cumplieron con éxito al finalizar el Trabajo Especial de Grado, ya que se tiene
una versión funcional de CONEST adaptada a un conjunto de necesidades requeridas por la Coordinación
de Postgrado y el Postgrado en Ciencias de la Computación.

Con respecto a los objetivos alcanzados:

Se adaptó el sistema a las necesidades planteadas por la Coordinación de Postgrado, haciendo


énfasis en el módulo de inscripción y administración.

Se logró hacer un estudio de los procesos que intervienen en la migración de los datos de la orga-
nización, y gracias a esto fue posible implementar el módulo de migración.

Se pudieron determinar los problemas asociados al proceso de recopilación de datos gracias al


estudio realizado previamente.

Se llevó a cabo una estrategia para organizar la recolección de los datos. Utilizando el resultado de
esta estrategia se creó la guía de migración.

Se creó un formato para los datos, el cual se encuentra explicado dentro de cada archivo modelo
utilizado para la migración.

Se adaptó la aplicación CONEST para sea capaz de realizar la migración de datos históricos.

Se desarrollaron funcionalidades para el sistema que permiten instanciar un plan de estudio.

Se desarrollaron funcionalidades para el sistema que permiten la inscripción de usuarios en un


período académico.

Se establecieron los lineamientos necesarios para completar correctamente el ingreso de los datos.
Estos se encuentran dentro de los archivos modelos y en la página principal de migración.

Se utilizó la metodología ágil XP adaptada al ambiente de desarrollo y la implementación del


concepto de reusabilidad a lo largo de todo el proyecto.

90
CAPÍTULO 3. MARCO APLICATIVO 91

Entre los resultados obtenidos se obtuvo una base de datos adaptada a la problemática que presentan
los estudios de postgrado, y que además sirve como base para el desarrollo de CONEST en Postgrado.
Además, se adaptaron y desarrollaron distintas funcionalidades en la aplicación Web que le permiten al
personal docente, administrativo y estudiantes hacer uso de la misma. A continuación se describen los
aspectos relevantes que se obtuvieron para adaptarla a los estudios de postgrado:

Funcionalidades que permiten la gestión de la oferta académica.

Funcionalidades que permiten la inserción de datos para poder añadir programas de estudio al sis-
tema, tales como el módulo de migración y la mejora que permite añadir estudiantes a las secciones
ya creadas.

Generación de constancias y documentos utilizados por los usuarios del sistema pertenecientes a
los estudios de postgrado.

Funcionalidades que permiten la integración del tutor académico de los estudiantes en el sistema.

Se adaptaron las interfaces utilizadas por el personal administrativo, docente y estudiantes.

Funcionalidades que permiten el funcionamiento del proceso de inscripción de los estudiantes.

Integración del manejo de información sobre los pagos estudiantiles en el momento de inscripción.

El desarrollo siguió la metodología estipulada y la adaptación aplicada a esta. Aun con estas modifi-
caciones se puede seguir categorizando como una metodología ágil. Esto permitió que los requerimientos
y la modificación de los mismos fuera de manera rápida y sencilla. Además, se pudieron organizar y agru-
par los requerimientos en un conjunto de iteraciones que mantenían el progreso de la aplicación de forma
constante y eficiente. Durante todo el proceso se integraron diferentes usuarios finales que ayudaron al
mejoramiento de la aplicación.

Durante el desarrollo se siguieron utilizando las tecnologías pertenecientes a CONEST 3.0 como es
el lenguaje de programación Ruby y el framework Rails, lo que minimizo el tiempo y esfuerzo durante la
etapa de codificación. Otra tecnología importante fue el uso de Git, que contiene las ventajas de mantener
una colaboración sincronizada, revisión de las modificaciones y administración del código de manera
fácil. También permite la recuperación de versiones previas en caso de cualquier falla.

Finalmente, gracias a este Trabajo Especial de Grado se logro un aporte significativo a la Coordina-
ción de Postgrado y los postgrados de la Facultado de Ciencias de la Universidad Central de Venezuela,
debido a que hasta el momento no se contaba con un sistema que permitiera la migración de datos de
manera automática y sin intervención directa a la base de datos. Este Trabajo Especial de Grado es el
inicio de un desarrollo más a fondo sobre lo que ahora es CONEST Postgrado y de esta forma expandir
los beneficios que trae a la gestión académica de nuestra facultad.
Recomendaciones y Trabajos Futuros

Para dar continuidad a la evolución de este proyecto se listan algunas recomendaciones:

Mantener el uso de las tecnologías utilizadas.

Seguir los estándares de programación utilizadas en esta aplicación.

Mantener una documentación adecuada del código fuente.

Realizar mejoras en las interfaces presentadas al usuario, es decir adaptarlas al ambiente de Post-
grado mediante el feedback de los mismos.

Instalar la aplicación en un sistema de servidores adecuado para los estudios de postgrado.

El alcance de este Trabajo Especial de Grado se extiende de manera que sirve como base para la
realización de futuros trabajos que permitan la consecución del mismo, ya que para poder obtener un
producto de gestión académica completo se deben contemplar aspectos necesario para solventar otras
problemáticas presentes en la Coordinación de Postgrado de la Facultad de Ciencias UCV y los 14 post-
grados que pertenecen a ella. Algunos de los futuros proyectos que complementarían el trabajo realizado
se nombran a continuación:

Desarrollo del módulo de graduación.

Implementación del reglamento de permanencia de forma automatizada.

Desarrollo de un módulo que permita la administración de los documentos de trabajos de grado.

92
Anexos

93
ANEXOS 94

Guía de Migración

Paso 1

Una vez ingresado al sistema, se procede a la pestaña de "Procesos"para desplegar la lista de opciones
y se selecciona "Migración".

Paso 2

Dependiendo del usuario en el sistema, se puede presentar una vista diferente. Es importante leer
todas las instrucciones. A continuación se pueden visualizar las dos presentaciones.

La vista principal de Migración que es presentada si el usuario ingresando pertenece a la Coordinación


de Postgrado, donde el usuario selecciona el postgrado al cual realizará la migración:
ANEXOS 95

Es necesario acotar que el usuario de la Coordinación de Postgrado puede cambiar el postgrado al


que desea migrar en cualquier momento seleccionado la opción "Cambiar Postgrado".
ANEXOS 96

La vista principal de Migración que es presentada si el usuario ingresando pertenece a un postgrado:


ANEXOS 97

Paso 3

Seleccionar el modulo a migrar (Docente, Estudiante o Materias).


ANEXOS 98

Paso 4

Descargar el archivo modelo.

Paso 5

Llenar la información en el archivo modelo.


ANEXOS 99

Paso 6

Una vez seleccionado el archivo se procede a cargar el archivo mediante la opción disponible.
ANEXOS 100

Nota Importantes

Es posible observar el resultado de la migración sobre el modulo seleccionado en la parte superior de


la vista o de forma detallada en la parte inferior.
ANEXOS 101

Además, puede ser visualizado de manera general mediante la pestaña de "Bitácora".


ANEXOS 102
Referencias

[1] I. Soto y B. Ponte, “Desarrollo del módulo académico de sigepost: Sistema de gestión para la coor-
dinación de postgrado de la facultad de ciencias,” Universidad Centra de Venezuela, Venezuela, Rep.
Tec., 2002.

[2] N. Pedrozo y G. Sulbarán, “Desarrollo de un módulo que permita manejar eventos dentro de los
procesos modelados para el prototipo de la aplicación web de gestión de procesos académicos de la
coordinación de postgrado de la facultad de ciencias de la universidad central de venezuela,” Univer-
sidad Centra de Venezuela, Venezuela, Rep. Tec., 2009.

[3] Ruby-doc.org, “Programming ruby: The pragmatic programmer’s guide,” http://ruby-doc.com/docs/


ProgrammingRuby/, 2009, [Online; Accedido el 15-Septiempre-2015].

[4] P. B.V., “Fast web server & app server, ruby python node.js - phusion passenger,” https://www.
phusionpassenger.com/#features, 2015, [Online; Accedido el 15-Septiempre-2015].

[5] K. Beck, Extreme Programming Explained, 2da. ed. Addison-Wesley, 1999.

[6] J. Sametinger, “Software engineering with reusable components,” 1997. [En línea]. Disponible en:
http://www.swe.uni-linz.ac.at/publications/pdf/TR-SE-97.04.pdf

[7] C. de Estudios de Postgrado, “Normativas de los estudios de postgrado de la facultad


de ciencias de la universidad central de venezuela,” 1996, [Online; Accedido el 20-
Septiempre-2015]. [En línea]. Disponible en: http://www.ciens.ucv.ve/postgrado/documentos/
NormativasdellosEstudiosdePostgradodelaFacultaddeCienciasdelaUCV.doc

103

También podría gustarte