Sistema para optimizar asignaci´
on
de aulas UNICEN
Trabajo final de la carrera de grado de
Ingenier´ıa de Sistemas de la
Universidad Nacional del Centro de la Prov. de Bs. As.
Por Matias Antonio Antunez
Director: Dr. Marcelo V´
enere
Co-Director: Ing. Javier Dottori
Agradecimientos
Quiero agradecer a todas las personas que han posibilitado la realizaci´on de este trabajo, tanto directa como indirectamente. A los directores de este proyecto, Marcelo V´enere y Javier Dottori que me han ayudado brind´andome su apoyo y conocimiento durante el desarrollo del mismo. Al instituto PLADEMA que me permiti´o tener un gran lugar de trabajo y donde me sent´ı c´omodo en todo momento.
A mis amigos y grupos de estudio, que me acompa˜naron durante el transcurso de toda la carrera y de quienes me llevo grandes aprendizajes.
Quiero agradecer a toda mi familia, quienes me dieron su apoyo siempre. Todo el esfuerzo dedicado en este trabajo va dedicado a todos ellos.
Por ´ultimo a todos los directivos y personal de UNICEN que estuvieron relaciona-dos con el trabajo realizado ayudando con la mejor predisposici´on y a las instituciones participantes. Este proyecto comenz´o gracias a una beca de las Facultades de Cien-cias Econ´omicas y Exactas, continuando luego como un proyecto de la Secretaria Acad´emica de la UNICEN. Sin esta iniciativa este proyecto no habr´ıa sido posible.
Mat´ıas Antonio Antunez
´
Indice general
Agradecimientos 2
1. Introducci´on 8
1.1. Objetivo . . . 9
1.2. Motivaci´on. . . 10
1.3. Objetivo de la tesis . . . 11
1.4. Organizaci´on de la Tesis . . . 11
2. Caso de estudio 13 2.1. Descripci´on del caso de estudio . . . 13
2.2. Relevamiento de requerimientos . . . 14
2.2.1. Requirimientos particulares . . . 15
2.3. Alternativas para el sistema . . . 15
2.4. Requerimientos a resolver . . . 16
3. Proceso de desarrollo 19 3.1. Ciclo de vida del proyecto . . . 19
3.2. Metodolog´ıa implementada . . . 21
3.2.1. Incremento del producto . . . 22
3.3. Etapas del proyecto . . . 22
3.3.1. Etapa 1 . . . 23
3.3.2. Etapa 2 . . . 24
3.3.3. Esquema de tiempos . . . 25
´
Indice general 4
4. Descripci´on del sistema 27
4.1. Arquitectura del sistema . . . 27
4.1.1. Modelo Cliente-Servidor . . . 27
4.1.2. MVP . . . 28
4.2. Caracter´ısticas del sistema . . . 30
4.2.1. Usuarios, recursos y grupos . . . 31
4.2.2. Roles de usuarios . . . 31
4.2.3. Sistema de Permisos . . . 32
4.3. Ambiente de desarrollo . . . 34
5. Funcionalidades 36 5.1. Proceso de responsables de asignaci´on de aulas . . . 36
5.2. Funcionalidades . . . 37
5.2.1. Exportaci´on de horarios a Excel . . . 37
5.2.2. Planificaci´on cuatrimestral . . . 39
5.2.3. Recomendador de aulas . . . 42
5.2.4. Mejoras de uso . . . 43
6. Roles adoptados 45 6.1. Roles para desarrollo de software . . . 45
6.2. Roles llevados a cabo . . . 46
7. Asignaci´on autom´atica de aulas 50 7.1. Algoritmos Gen´eticos . . . 50
7.2. Aplicaci´on al problema . . . 52
7.2.1. Representaci´on . . . 52
7.2.2. Funci´on de fitness . . . 54
7.2.3. Operador de cruce . . . 58
7.2.4. Operador de mutaci´on . . . 59
7.2.5. Selecci´on de padres y probabilidad de mutaci´on . . . 60
7.2.6. Selecci´on de sobrevivientes . . . 61
´
Indice general 5
8. Validaci´on e impacto del sistema 65
8.1. Resultados sobre vistas . . . 65
8.2. Optimizaci´on de aulas por parte del sistema . . . 72
9. Conclusiones 81 9.1. Conclusiones generales . . . 81
9.2. Roles adoptados . . . 81
9.3. Conocimientos adquiridos . . . 82
9.4. Trabajo a futuro . . . 82
A. Manual de Usuario 87
B. Lista de Participantes 97
C. Esquema de base de datos 101
´
Indice de figuras
3.1. Ciclo de vida . . . 20
3.2. Desarrollo de producto . . . 22
3.3. Diagrama de tiempos de actividades a lo largo del desarrollo . . . 25
4.1. Modelo cliente-servidor . . . 28
4.2. MVP . . . 29
4.3. Arquitectura de la aplicaci´on. . . 30
4.4. Permisos de los usuarios sobre recursos (sistema original). . . 32
4.5. Usuarios que pueden aprobar una reserva. . . 33
4.6. Sistema de permisos final. . . 34
4.7. Versionado del sistema en GIT . . . 35
5.1. Reserva con participantes asociados . . . 38
5.2. Exportaci´on Excel en formato de horario . . . 38
5.3. Exportaci´on Excel en formato de tabla . . . 39
5.4. Vista de planificaci´on semanal . . . 40
5.5. Vista de reservas. . . 42
5.6. Aulas disponibles en horario seleccionado . . . 43
7.1. Ejemplo de evaluaci´on de fitness para desperdicio de espacios. . . 56
7.2. Ejemplo de evaluaci´on de fitness para espacios entre actividades. . . . 57
7.3. Ejemplo de evaluaci´on de funci´on de fitness para minimizaci´on de cambios. . . 57
7.4. Operador de cruce . . . 59
7.5. Operador de mutaci´on de cambio de actividades.. . . 59
´
Indice de figuras 7
7.6. Operador de mutaci´on de corrimiento. . . 60
7.7. Resultado de las ejecuciones. . . 62
7.8. Resultado de las ejecuciones. . . 63
7.9. Resultado de las ejecuciones. . . 63
8.1. Cantidad de entradas a cada vista del sistema. . . 66
8.2. Cantidad de entradas a cada vista del sistema por tipos de usuario. . 67
8.3. Entradas a cada interfaz y b´usquedas dentro de la misma . . . 68
8.4. Uso de cada vista por grupos . . . 69
8.5. Cantidad de actividades planificadas para cada unidad acad´emica . . 70
8.6. Tiempos de uso de cada interfaz . . . 71
8.7. Cantidad de nuevas horas disponibles por aulas cada d´ıa . . . 73
8.8. Promedio de nuevas horas disponibles por d´ıa . . . 73
8.9. Promedio de nuevas horas disponibles por aula . . . 74
8.10. Utilizaci´on real de la cantidad de horas asignadas mediante la pol´ıtica de bandas horarias . . . 75
8.11. Distribuci´on de las aulas por facultades con ambas pol´ıticas. . . 76
8.12. Porcentaje de utilizaci´on de bandas horarias. . . 77
8.13. Ocupaci´on de las aulas comunes por horarios. . . 78
8.14. Utilizaci´on de las aulas en las horas finales del d´ıa. . . 79
Cap´ıtulo 1
Introducci´
on
Es sabido que la asignaci´on de recursos finitos a necesidades que cambian din´ ami-camente es un problema dif´ıcil de tratar. Si a esto se le suma la necesidad de optimizar varios objetivos a la vez de manera descentralizada, las alternativas que puedan ser implementadas son escasas [9] [10].
En este contexto, se realiz´o como proyecto final de la carrera de Ingenier´ıa de Sistemas el desarrollo de un sistema inform´atico que optimice el uso de las aulas de la UNICEN. El proyecto surgi´o desde la iniciativa de las facultades, quienes buscaron el desarrollo de una aplicaci´on que ayude a realizar una mejor utilizaci´on de los espacios acad´emicos y facilitar las tareas de los responsables de las aulas de cada unidad acad´emica (usuarios finales del sistema).
Es clara la importancia de optimizar los recursos disponibles en la UNICEN para no desperdiciar el uso de los mismos. No obstante, el problema de la asignaci´on de au-las requiere no s´olo de un algoritmo de optimizaci´on, sino tambi´en la implementaci´on de facilidades para la carga de solicitudes, an´alisis de factibilidades, visualizaci´on de estados y otra serie de herramientas que lo hagan atractivo para los usuarios finales.
Dentro del desarrollo del sistema, se debieron realizar diferentes tareas para una correcta aplicaci´on de la metodolog´ıa adecuada y sus etapas. Varios roles fueron ejecutados durante el ciclo de vida completo del proyecto. Estos roles implican ac-tividades como captura de requerimientos con los usuarios, desarrollo del sistema, testeo, capacitaci´on, mantenimiento, etc. El caso de estudio, involucra un situaci´on real, por lo cual, su desarrollo present´o un importante desaf´ıo y experiencia. El
Cap´ıtulo 1. Introducci´on 9
tema, adem´as, requiri´o el aprendizaje de cualidades y tecnolog´ıas no aprendidas durante la carrera. Los diferentes roles ejecutados y conocimientos aplicados permi-tieron tener la visi´on del sistema desde diferentes ´angulos, conduciendo a un excelente complemento a la formaci´on profesional
La aplicaci´on, hoy en d´ıa est´a en uso y en un estado estable. No obstante, es factible poder agregarle comportamiento y funcionalidades que ayuden y faciliten a´un m´as las tareas de los usuarios finales.
Establecida la carga de las actividades y contando con los datos necesarios reales, se puede realizar una optimizaci´on de la programaci´on de los eventos. La misma se deber´a realizar buscando criterios puntuales, por lo que tambi´en se debe establecer un objetivo a optimizar o incluso, varios permitiendo que estos compitan para establecer un equilibrio general y llegar a un conjunto de soluciones factibles en forma ´agil, eficaz y eficiente.
1.1.
Objetivo
El objetivo central fue el desarrollo de una herramienta que permita optimizar el uso de los espacios y aulas de todas las unidades acad´emicas en la UNCPBA.
El sistema administra las reservas y planificaci´on de actividades correspondientes al dictado de clases y usos de aulas. esto implic´o realizar un relevamiento de la situaci´on de asignaci´on de aulas de cada unidad acad´emica para su posterior an´alisis y, a partir de esto, su implementaci´on y soporte.
Cap´ıtulo 1. Introducci´on 10
proceso realizado por los encargados del manejo de aulas de las unidades acad´emicas.
Por ´ultimo, como objetivo adicional, se realiz´o la implementaci´on de los m´etodos necesarios para realizar una optimizaci´on de la distribuci´on de los eventos en los espacios acad´emicos de acuerdo a las necesidades y restricciones planteadas.
1.2.
Motivaci´
on
El proceso de planificaci´on y reservas de aulas para los espacios acad´emicos de la UNICEN puede ser acelerado y mejorado con la ayuda de un sistema adecuado.
Originalmente, para la administraci´on de las actividades de los recursos acad´ emi-cos se utilizaba un sistema llamado phpScheduleIt[1]. Al analizarlo, se encontraron cualidades deficientes del mismo que no favorecen al proceso llevado a cabo para la planificaci´on y reservas de eventos. Adem´as, en cuanto a los permisos sobre los espacios comunes, el proceso pactaba una divisi´on de franjas horarias para las dife-rentes facultades, lo que llevaba a una subutilizaci´on de los mismos y rigidez frente a cambios en el proceso.
Dentro de este contexto, inicialmente dos facultades lanzaron un proyecto con-junto para la implementaci´on de un sistema para ayudar a las unidades acad´emicas a realizar estas tareas. Luego el proyecto se extendi´o a todas las unidades acad´emicas del campus de Tandil de la UNICEN. El proyecto contempl´o becas para desarrollar el mismo.
El desarrollo de los sistemas requiere de un proceso a llevar a cabo para realizar su implementaci´on de manera adecuada. Esta pr´actica ayuda al desarrollo profesional. Una buena metodolog´ıa para aplicar es la de un proceso ´agil, donde el mismo es plasmado sobre el constante contacto con el usuario, d´andole entregas r´apidas. Estos conceptos fueron puestos en pr´actica a lo largo del desarrollo del proyecto.
Cap´ıtulo 1. Introducci´on 11
1.3.
Objetivo de la tesis
El objetivo espec´ıfico de la tesis radic´o en el desarrollo completo de un sistema que ayude a optimizar el uso de las aulas y mejorar el proceso realizado por los usuarios del mismo aplicando una correcta metodolog´ıa. Dicha metas deben ser validadas mediante el an´alisis del uso del mismo, una vez puesta en marcha su utilizaci´on.
M´as espec´ıficamente, entre los objetivos que se buscaron alcanzar a lo largo del desarrollo de la tesis se puede nombrar:
Llevar adelante un proyecto completo dej´andolo operativo en su totalidad, encontrando la mejor soluci´on ante los requerimientos capturados.
Poder lograr los objetivos principales de optimizaci´on de recursos a trav´es del uso del sistema desarrollado.
Obtener experiencia en el desarrollo de soluciones orientadas a aplicaciones reales.
Investigar y aplicar las tecnolog´ıas vinculadas a aplicaciones Web.
Participar activamente en varios roles en el proyecto seleccionado.
Llevar a cabo activamente en el desarrollo del sistema respetando la metodo-log´ıa seleccionada, siendo proactivo para entender las tecnometodo-log´ıas utilizadas.
Ensayar la puesta en producci´on de las distintas versiones de una aplicaci´on Web con desarrollo iterativo incremental.
1.4.
Organizaci´
on de la Tesis
EL informe cuenta con la siguiente estructura:
Cap´ıtulo 1. Introducci´on 12
Proceso de desarrollo: Explicaci´on de la metodolog´ıa utilizada para el desa-rrollo del sistema, las tareas realizadas en cada etapa del mismo y c´omo se dio el incremento del producto.
Descripci´on del sistema: Explicaci´on del modelo, la arquitectura, los m´ odu-los software del sistema. Adem´as, se nombran las tecnolog´ıas utilizadas a lo largo del desarrollo de la aplicaci´on.
Funcionalidades: Desarrollo de los m´odulos implementados para la soluci´on de la problem´atica dentro del sistema. Estos fueron desarrollados en base a los requerimientos dados por los usuarios finales.
Roles adoptados: Descripci´on de los diferentes roles por los que se pas´o a lo largo del desarrollo del proyecto.
Asignaci´on autom´atica de aulas: Explicaci´on de t´ecnicas implementadas para realizar una asignaci´on inteligente de aulas en base a datos reales utili-zando algoritmos gen´eticos. An´alisis de los resultados obtenidos.
Validaci´on e impacto del sistema: An´alisis del uso del sistema y del impacto del mismo en cuanto a la optimizaci´on de los recursos.
Conclusiones: Se detallan las caracter´ısticas concluidas con la realizaci´on del sistema y los posibles trabajos a futuro sobre el mismo.
Cap´ıtulo 2
Caso de estudio
En este cap´ıtulo se dar´a una breve introducci´on al caso de estudio, indicando las diferencias con sistemas de similares caracter´ısticas, al finalizar su lectura se deber´a lograr una idea general del contexto del proyecto a trabajar.
2.1.
Descripci´
on del caso de estudio
La planificaci´on de clases y reservas de aulas en la UNICEN son tareas vitales para mejorar la utilizaci´on y disponibilidad de recursos. Estas, puedes ser mejoradas con la ayuda de un sistema adecuado.
En este caso, el sistema ayudar´a a agilizar dicho proceso, coordinar la tarea en-tre los responsables de asignaci´on o reservas de aulas y, as´ı, posibilitar una mejor distribuci´on de espacios, maximizando su utilizaci´on comparado con las pr´acticas an-teriormente utilizadas. Adem´as, se disminuyen las posibilidades de errores humanos, como por ejemplo utilizar un aula que ya esta ocupada.
Para el caso puntual, la utilizaci´on del sistema adecuado ayuda a la administra-ci´on de los espacios propios de cada unidad acad´emica y la coordinaci´on de las aulas comunes. Sin necesidad de un estudio de los requerimientos espec´ıficos de UNICEN, los puntos nombrados ser´ıan de gran importancia.
Un an´alisis del proceso llevado a cabo por los usuarios finales marc´o dos m´odulos que el sistema debe contemplar, una de programaci´on de clases y otra de uso coti-diano, con reservas eventuales. Estos dos casos fueron la base de los requerimientos
Cap´ıtulo 2. Caso de estudio 14
para desarrollar la aplicaci´on adecuada.
2.2.
Relevamiento de requerimientos
El objetivo principal del sistema es realizar una optimizaci´on de los espacios acad´emicos del campus. Sin perder el foco en esta meta, se debe dar ayuda al pro-ceso de administraci´on de las aulas. As´ı, como primer paso para el desarrollo del sistema, se realiz´o una captura de requerimiento con los usuarios finales del mismo. Esto se produjo a trav´es de reuniones con los responsables de aulas de cada unidad acad´emica en las cuales se capt´o la forma y tiempos de trabajo de cada uno. Adem´as, se analizaron las herramientas y tecnolog´ıas utilizadas el momento.
Si bien cada facultad maneja de manera diferente sus clases y, por lo tanto, ubicaci´on de las mismas, como as´ı tambi´en sus espacios, se encontraron muchas similitudes en cuanto a los requerimientos que el sistema debe satisfacer. Se vieron 3 etapas marcadas que se realizaba ante cada per´ıodo lectivo:
Planificaci´on: Se realiza una programaci´on base del cuatrimestre en la cual se hace una distribuci´on de las clases diarias de cada curso de las carreras.
Reservas: Realizaci´on de reservas de un espacio, ya sea propio o com´un a todas las facultades.
Publicaci´on de horarios: Una vez establecidos los horarios y espacios de cada curso, se debe realizar una publicaci´on de los mismos para los alumnos y utilizaci´on interna.
Cada unidad acad´emica realizaba un seguimiento de la distribuci´on de aulas por cursos de una manera diferente, a trav´es de plantillas de Excel o manuales sin intervenci´on de sistemas inform´aticos adecuados. Para el uso de las aulas propias, se manejaban de manera interna por cada facultad.
En cuanto a los espacios comunes, hist´oricamente, la UNICEN establec´ıa un acuerdo de bandas horarias 1 en los espacios comunes, que cada facultad deb´ıa
res-petar para utilizar dichos recursos. Para la coordinaci´on de este proceso entre las
Cap´ıtulo 2. Caso de estudio 15
facultades, se utilizaba un sistema llamado PhpScheduleIt [1]. El pacto de bandas horarias era respetado a trav´es de una plantilla dada todos los a˜nos en la cual figuraba la delimitaci´on de los usos de cada facultad en cada aula.
La metodolog´ıa de bandas horarias llevaba a una sub-utilizaci´on de los recursos ya que a estos no se le daba un completo uso, y exist´ıan aulas que quedaban libres. Adem´as, en el sistema, no se ten´ıa un detalle puntual del uso real del aula, en cuanto a qu´e actividad (por ejemplo, qu´e clase) se est´a desarrollando.
2.2.1.
Requirimientos particulares
As´ı como se pudieron detectar requerimientos comunes a todas las unidades acad´emicas, cada facultad cuenta con un manera diferente de organizar sus carreras y eventos y, por lo tanto, la asignaci´on de sus actividades en las aulas.
Entre las particularidades m´as destacadas se puede nombrar:
Formato de reportes de horarios para carteleras. Las diferentes maneras de ver los horarios en las publicaciones.
Manejo de comisiones. Depende el uso que le daba cada facultad, un mismo curso pod´ıa tener o no superposiciones de horarios entre diferentes comisiones.
Periodos de clases. De acuerdo a la facultad y las c´atedras, se pueden dar materas anuales, cuatrimestrales, bimestrales, cada 2 semanas, etc.
2.3.
Alternativas para el sistema
Existen muchos alternativas de sistemas que ayudan a llevar a cabo la adminis-traci´on de recursos y reservas de los mismos para tener como base. Entre ellas se pueden nombrar:
Cap´ıtulo 2. Caso de estudio 16
Classroom Scheduler: Permite una visualizaci´on bastante clara de la distri-buci´on de los salones de clase. Es Open Source, por lo que se dispone el c´odigo fuente y puede ser modificado y adaptado seg´un necesidades espec´ıficas de cada instituci´on.
phpScheduleIt: Alternativa Open Source. Es utilizada para la adminsitraci´on de reservas de espacios comunes en UNICEN.
Softaula: En sus 4 tipos de licencia ofrece desde la administraci´on de la ins-cripci´on de alumnos a materias hasta la b´usqueda de aulas libres para asignar nuevos alumnos a trav´es de procesos autom´aticos.
[11]
Algunas caracter´ısticas particulares buscadas para satisfacer las demandas de la administraci´on de aulas de UNICEN gener´o la necesidad de desarrollar su propio software. Las alternativas encontradas pueden ser varias, pero analiz´andolas se vio necesario hacer adaptaciones para satisfacer las necesidades requeridas.
Se opt´o por utilizarphpScheduleIt como base, dado que era un sistema ya conocido por los usuarios y contaba con caracter´ısticas b´asicas ya implementadas como log-in, sistema de permisos, visualizaci´on de reservas, entre otras. Si bien el sistema estaba en uso, no contaba con todas las prestaciones para satisfacer los requisitos captados. Por eso, fue necesario adaptarlo.
En cuanto a la posibilidad de incorporarle dichas modificaciones, el sistema cuenta con una buena modularizaci´on que posibilita realizar estas incorporaciones de manera sencilla reusando sus m´odulos. Sin embargo, la curva de aprendizaje para entender el funcionamiento del sistema fue pronunciada.
Cualquiera de los sistemas nombrados anteriormente son considerados una buena alternativa para establecer una proceso para una buena administraci´on de aulas, sin embargo, ninguno cuenta con m´odulos inteligentes que realizan una buena distribu-ci´on autom´atica de las clases o los eventos. Esta etapa fue estudiada por separado.
2.4.
Requerimientos a resolver
Cap´ıtulo 2. Caso de estudio 17
desarrollarlos.
Se detalla brevemente el proceso realizado de forma manual a informatizar. Previo al sistema, cada coordinador de aulas tenia planillas (digitales o en papel seg´un preferencia personal) donde cada hoja era el horario de un aula o de cada curso. De esta manera las b´usquedas de recursos para ser asignados a eventos implicaba recorrer cada hoja y analizar huecos superpuestos en m´ultiples hojas de manera manual. Luego actualizar dos o m´as hojas. Incluso a veces generando una tercer copia de la informaci´on para publicar en cartelera. Esta tarea se vuelve muy tediosa y dif´ıcil si el volumen de informaci´on es grande.
Por todo esto se prioriz´o en este trabajo la informatizaci´on del proceso, mediante una herramienta que permita reflejar este flujo de trabajo. Entre lo m´as marcado se puede destacar:
Evitar la r´eplica de informaci´on: M´as all´a de que los datos son los mismos para todas las etapas del proceso de trabajo, los usuarios realizan copias de infor-maci´on para las diferentes etapas (publicaci´on en cartelera, carga al sistema, etc). Se maneja mucha cantidad de plantillas o sistemas que tornan engorrosas las tareas.
Automatizaci´on del proceso: Como los datos est´an en muchos lugares a la vez, se requiere gran cantidad de tiempo en cargar y mantener los mismos consistentes.
Facilitar la repetici´on de tareas: A˜no a a˜no, se realizan los mismos pasos para planificar periodos lectivos y realizar las correspondientes reservas. Muchas veces, los datos son parecidos (o incluso iguales) al a˜no anterior.
Eliminaci´on de bandas horarias para los espacios comunes: El proceso pactado para los espacios comunes implica que cada facultad use los mismos en un horarios acordados a principio del periodo como bandas horarias. Esto implica que muchas veces se use menos que lo acordado y se sub-utilicen los recursos.
Control de la asignaci´on de los espacios por parte de los coorinadores de aulas.
Cap´ıtulo 2. Caso de estudio 18
Adem´as, es fundamental que se garantice la existencia de los atributos de calidad que del sistema. El mismo debe estar a disposici´on para evitar inconvenientes con el uso de las aulas. Adem´as, debe ser utilizable en cuanto a superformance y facilidad de uso para que no se deje de usar.
Cap´ıtulo 3
Proceso de desarrollo
A lo largo de este capitulo se busca describir la metodolog´ıa utilizada que se llev´o a cabo para el desarrollo del sistema, teniendo en cuenta los posibles cambios que se presentaron en el transcurso del tiempo. Se pretende lograr que el lector tenga una idea del proyecto y su desarrollo pudiendo ubicar en el tiempo la dedicaci´on a cada etapa y el ciclo seguido en cada una de ellas.
3.1.
Ciclo de vida del proyecto
El proyecto comenz´o a partir de que dos facultades lanzaron un iniciativa en conjunto para la implementaci´on de un sistema cuyo fin sea optimizar el uso de aulas y ayudar a las unidades acad´emicas a realizar el proceso de planificaci´on y reservas para sus espacios, teniendo as´ı una distribuci´on ´optima.
En todo momento se busc´o resolver profesionalmente la problem´atica planteada y, por lo tanto, se debi´o optar por una metodolog´ıa correcta para llevar a cabo el proceso de desarrollo. Esta consiste es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de informaci´on [4].
El ciclo de vida de un sistema consiste en un conjunto de fases por las que este pasa desde que nace la idea inicial hasta que el software es retirado o remplazado. Existen diferentes tipos de modelos de ciclos de vida dependiendo de:
Su alcance, hasta d´onde llegue el proyecto correspondiente. Pudiendo ser des-de un simple estudio des-de viabilidad des-del des-desarrollo des-de un producto, hasta un
Cap´ıtulo 3. Proceso de desarrollo 20
desarrollo completo
Las caracter´ısticas de las etapas en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto, o de la organizaci´on.
La estructura y la sucesi´on de las etapas, si hay re-alimentaci´on entre ellas, y si tenemos libertad de iterarlas [7].
En nuestro caso, y como en la mayor´ıa de los sistemas, el primer eslab´on del ciclo consisti´o en una captura de requerimientos y se finaliz´o con el constante manteni-miento del producto. En ellos se bas´o el desarrollo mismo de la aplicaci´on.
Dado que una de las caracter´ısticas del proyecto era soportar m´ultiples requeri-mientos que surjan incluso durante el desarrollo del mismo, el ciclo de vida seleccio-nado consisti´o en un esquema de desarrollo basado en espiral. Esta clase de ciclo de vida permite flexibilidad para la realizaci´on de cada etapa. Un esquema general se puede ver en la Figura 3.1.
Figura 3.1: Ciclo de vida
Como se ve, el desarrollo se dividi´o en varias etapas. Las principales fueron:
Determinaci´on de objetivos: Se determinan y priorizan los requerimientos a satisfacer a partir de reuniones con los usuarios finales.
An´alisis: Se estudian posibles soluciones que resuelvan los requerimientos ele-gidos.
Cap´ıtulo 3. Proceso de desarrollo 21
Desarrollo y test: Se implementan y prueban las funcionalidades para des-plegar en el producto final.
Estas etapas fueron repetidas tantas veces como fue necesario para poder cumplir con todos los requerimientos planteados. En cada iteraci´on se volvi´o a pasar por cada una de ellas, que implicaban el incremento del producto. El ciclo de vida en espiral permite cambiar de etapa f´acilmente, lo que da flexibilidad ante los posibles cambios.
3.2.
Metodolog´ıa implementada
Una vez definido el ciclo de vida, hubo que optar por una metodolog´ıa a aplicar. Una metodolog´ıa es un conjunto integrado de t´ecnicas y m´etodos que permite abordar de forma homog´enea y abierta cada una de las actividades del ciclo de vida de un proyecto de desarrollo. Es un proceso de software detallado y completo [7].
En nuestro caso, se opt´o por tener una constante interacci´on con el usuario, rea-lizando entregas continuas sobre los requerimientos que se fueron dando. El proceso se adapt´o a las buenas pr´acticas de los m´etodos ´agiles.
...is used as an Agile practice that delivers software to end users faster, better, and cooler.
...Agile development is used globally as the best way to develop, maintain, and support software systems [6].
Una de las ventajas de la metodolog´ıa planteada, fue la versatilidad y f´acil adap-taci´on ante los cambios de requerimientos. Esta variable, es natural en los desarrollos de sistemas y tuvo que ser debidamente soportada desde el momento en que todas las facultades se unieron al proyecto como usuarios finales, incorporando necesidades de las nuevas Unidades Acad´emicas participantes. Los m´etodos ´agiles, por sus cons-tantes entregas e interacci´on con el usuario, permiten ser flexible ante estos cambios.
Por ´ultimo, dado que el proceso de trabajo de asignaci´on de aulas se realizar´a a trav´es del nuevo sistema, se requiri´o efectuar las necesarias capacitaciones a los usuarios para que aprendan su correcta utilizaci´on, como as´ı tambi´en darle soporte y monitorear su uso para que este se ejecute correctamente. Esto forma parte de las ´
Cap´ıtulo 3. Proceso de desarrollo 22
3.2.1.
Incremento del producto
Como se dijo anteriormente, se eligi´o utilizar una proceso de desarrollo ´agil, con constante interacci´on con el usuario. Para esto, fue necesario tomar los requerimientos que surgieron de las reuniones con los mismos.
Se podr´ıa tomar la Figura 3.2 como un esquema general de la serie de pasos realizados para la incorporaci´on de las funcionalidades.
Figura 3.2: Desarrollo de producto
Se puede ver que, en cada iteraci´on, se tomaron un conjunto de requerimientos planteados, para los cuales se desarrollaron la funcionalidad necesaria en el sistema. Una vez terminados y testeados, fueron incorporados al producto final (en servidor de producci´on) como parte de la etapa de deploy. Cada uno de estas iteraciones pueden ser definidas como un Sprint Los requerimientos pueden ser modificados o incorporados, ya sea por nuevos usuarios, pol´ıticas de uso, etc. En cada sprint se pueden redefinir dichos requerimientos. Al producto final se le tiene que hacer el correspondiente mantenimiento para que el sistema no cuente con errores funcionales.
3.3.
Etapas del proyecto
Cap´ıtulo 3. Proceso de desarrollo 23
(usuarios finales). El desarrollo del proyecto se dividi´o en 2 etapas, comenzando la segunda con la incorporaci´on de todas las unidades acad´emicas como usuarios del sistema.
3.3.1.
Etapa 1
En la primera etapa del proyecto se realiz´o el estudio del estado actual del proceso de trabajo de los usuarios y, en consecuencia, el relevamiento principal de requeri-mientos. Esta captura se efectu´o con los usuarios participantes del proyecto para esta primer etapa (Facultades de Cs. Exactas y Cs. Econ´omicas).
El relevamiento sirvi´o para analizar formas de trabajo y herramientas utilizadas para el mismo. Si bien, cada facultad tiene algunas particularidades, el esquema de trabajo de ambas unidades acad´emicas compart´ıa etapas bien marcadas que fueron atacadas al momento de desarrollar el producto. La principal decisi´on en esta etapa fue la de implementar un sistema para informatizar el proceso, m´as que hacerlo de forma totalmente autom´atica. Esto se debe en parte al etapas naturales que deben seguir los cambios, as´ı como las restricciones de proceso de cada facultad que lo impiden actualmente. De todas formas decidimos incorporar un primer acercamiento de asignaci´on autom´atica inteligente.
Una vez terminada y documentada la captura de requerimientos, se comenzaron a investigar posibles herramientas de software que puedan ayudar a las tareas plan-teadas. Se determin´o que, dentro de las posibilidades, el mejor esquema fue trabajar sobre una herramienta que era utilizada, ya que los usuarios estaban familiarizados con ella. Este sistema era elPHPScheduleIt [1]. El trabajo sobre este requiri´o de una etapa de aprendizaje pronunciada, ya que es un sistema grande, pero al contar con una buena modularizaci´on, fue posible incorporarle funcionalidades f´acilmente.
En este contexto, se sigui´o por determinar posibles caracter´ısticas para incorporar al sistema y establecer soluciones a los usuarios. Tambi´en fue importante priorizar estas funcionalidades a implementar. Se comenz´o con una etapa de incepci´on al sistema y su arquitectura, comenzando con el desarrollo de m´odulos externos que se incorporaron manteniendo la arquitectura de software original.
El desarrollo comenz´o con el siguiente camino de funcionalidades:
Cap´ıtulo 3. Proceso de desarrollo 24
2. Recomendador de aulas.
3. M´odulo de Planificaci´on cuatrimestral.
El primer m´odulo se realiz´o utilizando una librer´ıa externa a la aplicaci´on (PH-PExcel[23]) pero con datos de ella. As´ı, fue posible ir entendiendo el sistema original. Adem´as, se tuvieron que aprender conceptos de programaci´on WEB no vistas du-rante la carrera.
El desarrollo de siguientes funcionalidades ya contaban con un mejor conocimien-to del sistema por lo que se realizaron de manera m´as ´agil. El m´odulo de planificaci´on cuatrimestral fue de gran volumen, por lo que llev´o un tiempo de implementaci´on prolongado.
Una vez desarrolladas, testeadas y desplegadas las funcionalidades en el producto final (servidor de producci´on), se tuvieron que realizar las respectivas capacitaciones con los usuarios, para que estos hagan un correcto uso del sistema.
3.3.2.
Etapa 2
La segunda etapa se determin´o con la incorporaci´on de todas las unidades acad´ emi-cas como usuarios del sistema. Esta integraci´on produjo algunos cambios en los re-querimientos, proveniente de los nuevos usuarios de las Facultades de Humanas y Veterinarias.
Ante esta situaci´on, se realizaron reuniones con los responsables de aulas de las nuevas unidades acad´emicas participantes para identificar su esquema de trabajo y cu´anto difiere de lo que ya fue capturado en la etapa anterior. Estos nuevos requeri-mientos demandaron adaptaciones al sistema para poder soportar funcionalidades o caracter´ısticas nuevas.
M´as precisamente, las nuevas incorporaciones se reflejaron en las particularidades para programar las clases de los ciclos lectivos y las formas de exportaci´on de reportes (Excel):
Cap´ıtulo 3. Proceso de desarrollo 25
tuvieron que asociar un per´ıodo a las actividades de planificaci´on. Este per´ıodo de tiempo soportar´a cada posible esquema de clases.
Nuevos formatos de exportaci´on:Si bien las facultades contaban con ma-neras particulares de generar sus reportes para cartelera, estos fueron f´acilmente adaptables a los ya realizados en la etapa anterior. Simplemente incorporando datos nuevos a los formatos existentes se pudo satisfacer este requerimiento.
Adem´as, la incorporaci´on de nuevos usuarios requiri´o una capacitaci´on general del producto. El esquema final de trabajo cuenta con cualidades para satisfacer com-pletamente a todos los usuarios, por lo que las unidades acad´emicas deben respetar todas las caracter´ısticas para poder utilizar correctamente el sistema.
La utilizaci´on de una metodolog´ıa ´agil facilit´o la adaptaci´on a los nuevos reque-rimientos. El comienzo de esta nueva etapa se dio con un desarrollo de las funciona-lidades principales en una fase avanzada. La planificaci´on desprints cortos permiti´o que los nuevos requerimientos se incorporen f´acilmente.
3.3.3.
Esquema de tiempos
En las secciones anteriores se explicaron las 2 etapas que caracterizaron el desa-rrollo del sistema. En la Figura3.3puede ver un esquema de los tiempos del proyecto.
Figura 3.3: Diagrama de tiempos de actividades a lo largo del desarrollo
Cap´ıtulo 3. Proceso de desarrollo 26
Cap´ıtulo 4
Descripci´
on del sistema
En este capitulo se detallar´a una descripci´on del sistema en cuanto a su imple-mentaci´on, partiendo de una vista de la arquitectura del mismo y desarrollando los diferentes m´odulos de inter´es.
4.1.
Arquitectura del sistema
Como primera medida, se explicar´a la visi´on arquitect´onica de la implementaci´on del sistema. Como el sistema requiri´o ser distribuido y accesible a todos los usuarios, se implement´o como una aplicaci´on WEB. Esto implica la utilizaci´on de un modelo Cliente-Servidor. A continuaci´on se explicar´a dicho modelo y la instanciaci´on del mismo que se hizo en la arquitectura del sistema.
4.1.1.
Modelo Cliente-Servidor
El Modelo Cliente-Servidor aloja una aplicaci´on distribuida en la que los clientes pueden ser vistos como m´odulos que realizan peticiones a un programa servidor. En la Figura 4.1 puede verse un esquema general de este modelo. Los clientes son los usuarios finales que a trav´es de Internet mandan peticiones al servidor.
Cap´ıtulo 4. Descripci´on del sistema 28
Figura 4.1: Modelo cliente-servidor
El servidor aloja la base de datos y la l´ogica del negocio, enviando su resultado a los clientes. El resultado se env´ıa en formato HTML, y es interpretada por los navegadores de los usuarios finales. Este esquema es inherente a cualquier sistema web, y necesario para ser accesible a todos los usuarios. F´ısicamente, el servidor (de producci´on) aloja su procesamiento en los equipos del DataCenter del Campus de UNICEN.
4.1.2.
MVP
Como arquitectura del sistema se opt´o por utilizar un MVP (Model-View-Presenter). Esta elecci´on se dio para mantener la estructura planteada por el sistema de base phpScheduleIt.
”...The Model-View-Presenter (MVP) pattern is used to keep a clear separation between application logic and presentation logic[1].”
MVP es una derivaci´on del patr´on MVC 1, el cu´al es usado para una correcta
separaci´on de m´odulos seg´un sus responsabilidades. Aqu´ı, se reconocen 3 elementos que guiar´an el desarrollo de la aplicaci´on:
View: M´odulo que aloja la representaci´on visual de los datos en el sistema. Compuesto por todo lo que tenga que ver con la interfaz gr´afica.
Cap´ıtulo 4. Descripci´on del sistema 29
Presenter: Act´ua como intermediario entre Model y View. Baja el acopla-miento entre ambos.
Model: Puede ser visto como la interfaz a los datos. Cualquier parte del pro-grama que necesita datos para trabajar debe pasar por la interfaz o funciones definidas para acceder.
Un diagrama de estos componentes y sus interrelaciones puede verse en la Figura
4.2.
Figura 4.2: MVP
Cap´ıtulo 4. Descripci´on del sistema 30
Figura 4.3: Arquitectura de la aplicaci´on
Al ser una sistema web, se puede ver que la interfaz con el usuario final es a trav´es de un navegador (browser). Desde el mismo, el usuario manda requests al servidor mediante el protocolo correspondiente (HTTP). Del lado del servidor, se instancian objetos de los m´odulos de Presenter y Page. Estos se encargar´an de cargar datos desde el Model para luego procesarlos y mostrarlos desde la Vista.
”...Page objects act as thin abstraction to the template engine and typically have no other logic. Presenter objects orchestrate interactions between underlying appli-cation logic objects and the page. This typically includes fetching and transforming data and minimal application logic[1].”
4.2.
Caracter´ısticas del sistema
Cap´ıtulo 4. Descripci´on del sistema 31
4.2.1.
Usuarios, recursos y grupos
El sistema cuenta con usuarios y recursos sobre los cuales se basar´an todas las funcionalidades.Los usuarios son registrados al mismo para poder realizar reservas sobre los recursos (aulas) creados. Este es el esquema de funcionalidad b´asico de la aplicaci´on.
El sistema en un principio era independiente, pero luego se vincul´o con el Servicio de Autenticaci´on Central (CAS) de la UNICEN 2. Por esto, cada usuario debe estar
registrado con cuenta en el mismo y acceder al sistema a trav´es de la p´agina central del CAS. Esta vinculaci´on fue f´acilmente ejecutada, debido a que la misma aplicaci´on contaba con m´odulos para la integraci´on de sistemas externos.
Tanto los usuarios como los recursos registrados pueden ser agrupados en conjun-tos de acuerdo a las necesidades. En nuestro caso, esconjun-tos grupos fueron definidos por unidad acad´emica para poder realizar una buena separaci´on de los elementos para una mejor y ordenada funcionalidad.
4.2.2.
Roles de usuarios
El sistema cuenta con la posibilidad de darle diferentes roles a los usuarios del mismo dependiendo del uso que se le da desde cada uno. As´ı, determinados usuarios puede acceder a las funcionalidades que les son alcanzables desde su rol.
A nivel m´as detallado del funcionamiento del sistema, los usuarios pertenecen a grupos, y estos tienen diferentes tipos de roles. Los roles con los que cuenta la aplicaci´on son 3, teniendo cada uno de estos diferentes accesos a funcionalidades del sistema o posibilidades dentro del mismo:
Administrador de aplicaci´on.
Administrador de recurso.
Administrador de schedule.
Cap´ıtulo 4. Descripci´on del sistema 32
Los administradores de la aplicaci´on pueden crear recursos, usuarios y grupos de estos, como as´ı tambi´en modificarlos. Los administradores de recursos, pueden reali-zar reservas sobre las aulas que gestiona, como as´ı tambi´en aprobar las reservas sobre sus aulas cuando se requiera. Losschedules en el sistema, son conjuntos de recursos. Los administradores de estos, est´an permitidos a realizar las acciones mencionadas anteriormente sobre los recursos pertenecientes al grupo que administra.
4.2.3.
Sistema de Permisos
Una de las razones por la cual se eligi´o trabajar sobre el sistema que se esta-ba usando, fue que este ya contaesta-ba con un m´odulo de permisos de usuarios sobre los recursos existentes. Esto incluye permisos tanto de lectura (para ver) como de escritura o edici´on (realizaci´on o modificaci´on) de reservas en el sistema.
A partir de esto, y una vez estudiado su funcionamiento, se pudo tambi´en agregar un comportamiento m´as adecuado a las necesidades y los requerimientos planteados. Por ello, se estudi´o la forma en quephpScheduleIt maneja los recursos para introducir los cambios necesarios. As´ı, se construy´o un ´arbol de decisiones que diagrama las cuestiones a tener en cuenta en cuanto a cada permisos de cada usuario sobre tal recurso.
Cap´ıtulo 4. Descripci´on del sistema 33
Figura 4.5: Usuarios que pueden aprobar una reserva.
En las Figuras 4.4 y 4.5 se observa dicha l´ogica. En la Figura 4.4 se muestra el ´arbol de decisiones para hacer o modificar una reserva. Se observa que existe un m´odulo que decide si un usuario tiene acceso ante a un recurso (Es Accesible). El permiso para ver las reservas sobre un aula s´olo llama a este m´odulo. En cambio, para poder realizar o modificar reservas (m´odulo ”Puede Editar”), se tiene en cuen-ta algunos conceptos m´as para decidir. A su vez, algunos recursos requieren que las reservas que son realizadas sobre ellos sean aprobadas. Dicha aprobaci´on ser´a realizada por determinadas personas que tengan los permisos adecuados. En cuanto a la aprobaci´on (Figura 4.5) primero la reserva debe ser aprobable. Luego, siendo administrador de la aplicaci´on, administrador de quien cre´o la reserva, o del recurso en el cual se realiz´o, se podr´a aprobar la misma.
En una primera etapa, no hubo mayores modificaciones al sistema original, ya que los usuarios se correspond´ıan con cada unidad acad´emica. La vinculaci´on con el CAS llev´o a una modificaci´on de la cantidad de usuarios por cada facultad. As´ı, existe la posibilidad de que varias personas manejen las aulas de una misma unidad acad´emica. Esto requiri´o que se modifique el sistema de permisos en cuanto a qui´en puede realizar, modificar o dar de baja las reservas sobre determinado recurso. La limitaci´on que surgi´o fue que las reservas creadas por un usuario deber´ıan poder editarse y eliminarse por otro colega de su misma unidad acad´emica (caso que no se permit´ıa en las aulas de Universidad de las que no eran administradores).
Cap´ıtulo 4. Descripci´on del sistema 34
reservas creadas por otro usuario de la misma unidad acad´emica. M´as precisamente, en el m´odulo Es Accesible se agreg´o la condici´on que establece si el creador de la reserva pertenece a la misma unidad acad´emica (mismo grupo) de quien quiere modificar dicha reserva. El diagrama final puede verse en la Figura 4.6.
Figura 4.6: Sistema de permisos final.
4.3.
Ambiente de desarrollo
El ambiente planteado para el desarrollo del sistema consta de todas las partes que requiere cualquier aplicaci´on Web.
Dichas aplicaciones se establecen bajo un modelo Cliente-Servidor. Para esto, se utilizaron diferentes tecnolog´ıas:
Cliente:
• HTML5.
• JavaScript.
• CSS.
Servidor:
• PHP [19].
• MySql [20].3
Cap´ıtulo 4. Descripci´on del sistema 35
Se utilizaron diferentes tecnolog´ıas, frameworks y bibliotecas que ayudaron a un desarrollo m´as ´agil y brindar mejores prestaciones para el producto final, entre ellos:
Jquery, Bootstrap: Modelado de interfaz gr´afica[21] [22].
Ajax: Peticiones asincr´onicas al servidor sin recargar la p´agina. Agiliza la navegaci´on.
Smarty: Motor de templates para PHP[24].
PHPExcel: Para generaci´on y manipulaci´on de plantillas Excel con PHP[23].
Los m´odulos del servidor corren bajo Apache en m´aquinas virtuales ubicadas en el Centro de Datos de UNICEN.
Para manejo de versiones durante el desarrollo del sistema se utiliz´o SVN [25] y sobre el final del proyecto se realiz´o una migraci´on a GIT [26]. Aprovechando la caracter´ıstica de GIT de ser distribuido, se dej´o planteado un versionado de c´odigo en el Centro de Datos de la Universidad, el cual incluye dos ramificaciones4. Las
mismas contienen el desarrollo realizado en el sistema original (branch master) y el realizado en este proyecto (branch unicen). El punto de la ramificaci´on se defini´o desde la versi´on instalada originalmente en UNICEN (versi´on del a˜no 2012). En la Figura 4.7 se muestra c´omo qued´o el versionado de c´odigo final.
Figura 4.7: Versionado del sistema en GIT
Cap´ıtulo 5
Funcionalidades
En este capitulo se mostrar´a el conjunto de funcionalidades incorporadas al sis-tema. Estas ayudan a llevar a cabo el proceso de asignaci´on de aulas y las tareas realizadas por los responsables de la misma.
5.1.
Proceso de responsables de asignaci´
on de
au-las
Los usuarios del sistema son los encargados de la administraci´on de las aulas de las Unidades Acad´emicas participantes. Entre las tareas m´as relevantes, deben coordinar los diferentes cursos y asignarles espacios para las clases y los eventos en que estos participan. Adem´as, deben manejar el usos de los mismos espacios para actividades eventuales, como parciales, defensas de tesis, cursos extracurriculares, entre otras.
Desde las diferentes reuniones con los usuarios se captaron 3 etapas en las que se basa el proceso de trabajo:
Planificaci´on: se arma la distribuci´on de aulas para los cursos de las carreras pertenecientes a cada facultad. Esta ser´a para la clases de per´ıodos lectivos cuatrimestrales o anuales.
Reservas: se realizan las reservas reales de las aulas, para que cada evento sea asignado a un espacio y quede notificado ante todos los usuarios.
Cap´ıtulo 5. Funcionalidades 37
Publicaci´on de horarios: de acuerdo al armado de los horarios para las clases o eventos en las aulas, es necesario una publicaci´on de las actividades, ya sea por aulas o por cursos.
5.2.
Funcionalidades
A continuaci´on se detallar´an las diferentes funcionalidades incorporadas al siste-ma.
5.2.1.
Exportaci´
on de horarios a Excel
Esta funcionalidad fue la primera incorporada, por lo tanto, ayud´o a tener un mejor entendimiento del sistema que se tom´o como base. La finalidad de esta fun-cionalidad es poder exportar reportes de los eventos que tengan cada curso de cada carrera y cada aula para poder publicarlos. Esto servir´a para los alumnos y la admi-nistraci´on interna de cada Unidad Acad´emica.
Para poder lograr esto se tuvo la necesidad de incorporar el concepto de Partici-pantes a las reservas. Cada participante es un usuario en el sistema que representar´a un curso de una carrera de cada facultad. As´ı, se realiz´o un listado de todas las carre-ras y a˜nos de cada facultad y se crearon los correspondientes usuarios. Las diferentes comisiones de cada curso tambi´en fueron consideradas. En el Ap´endice B se lista la totalidad de participantes incorporados indicando de qu´e facultad es.
Cap´ıtulo 5. Funcionalidades 38
Figura 5.1: Reserva con participantes asociados
Se implementaron dos formatos de exportaciones. Estos surgieron de los reque-rimientos planteados por los usuarios (coordinadores de aulas) de las facultades du-rante la captura de requerimientos:
Horario:
Figura 5.2: Exportaci´on Excel en formato de horario
Cap´ıtulo 5. Funcionalidades 39
Figura 5.3: Exportaci´on Excel en formato de tabla
Anteriormente, esta tarea era realizada de forma manual, replicando informaci´on ya existente. Esto llevaba a que sea una actividad tediosa y demandaba mucho tiempo.
5.2.2.
Planificaci´
on cuatrimestral
Una de las principales funcionalidades en la cual se centr´o el sistema es la posi-bilidad de armar una distribuci´on de horarios y aulas para un periodo lectivo base de los cursos de cada unidad acad´emica.
As´ı, los responsables de cada facultad armar´an colaborativamente la asignaci´on de aulas para las actividades cuatrimestrales. Se asume libertad de aulas y se realiza la planificaci´on de una semana tipo para un periodo particular (1er cuatrimestre, por ejemplo). El mismo sistema va controlando la colisiones que se pueden presentar e impidiendo que dos eventos se programen en el mismo espacio y aula.
Cap´ıtulo 5. Funcionalidades 40
en la Figura 5.4 un ejemplo de esta vista. En la misma se muestran actividades del participante FCEX 1ero LCF (primer a˜no de Licenciado en Ciencias F´ısicas, de la Facultad de Exactas) y el Aula 1 del pabell´on de la Facultad de Exactas.
Figura 5.4: Vista de planificaci´on semanal
La interfaz permite agregar y sacar recursos y participantes de manera r´apida a la vista, para poder buscar las actividades f´acilmente y superponerlas, como se dijo anteriormente.
Pasaje a reservas
Una vez armada la planificaci´on, el sistema da la posibilidad de pasarla a reservas reales para un rango de tiempo dado. El fin de esta funcionalidad, es armar una base para las reservas de todo un periodo. Esta etapa, anteriormente se hac´ıa cada reali-zando cada reserva individualmente, y por bandas horarias, en lugar de actividades puntuales. Esto generaba una sub-utilizaci´on de los espacios, ya que no se hac´ıa un uso total de la banda horaria reservada en los recursos.
siste-Cap´ıtulo 5. Funcionalidades 41
ma, mostrando un resumen de las superposiciones y dando la posibilidad de ignorar las actividades que no se pueden dar de alta. As´ı, se podr´an pasar las reservas que no presentan conflictos.
La vista de la planificaci´on cuenta con un formulario, al que se le da una fecha de inicio y de fin de un periodo, para poder dar de alta las reservas necesarias.
Cada usuario, haciendo uso de esta funcionalidad, pasar´a a reservas las activi-dades pertenecientes a los recursos de la facultad que administra. Este proceso se requirio que sea descentralizado para que cada usuario tenga mayor control sobre las aulas que admministra. As´ı, tiene la posibilidad de verificar la planificaci´on antes de aplicarla sobre sus espacios.
Una vez hecho este proceso, se podr´an modificar las reservas normalmente. Even-tualmente, puede surgir la cancelaci´on o cambio de alg´un evento en una fecha pun-tual, esto se podr´a manejar desde las funcionalidades originales de phpScheduleIt.
Tambi´en se da la posibilidad de poder borrar las reservas que fueron creadas por este medio. Esto puede darse en el caso que se quieran borrar porque hubo cambios en la planificaci´on y las reservas requieran ser actualizadas.
Vista de reservas y planificaci´on
Dado que la interfaz creada para armar la planificaci´on cuatrimestral fue hecha en base a los requerimientos captados, se decidi´o dar la posibilidad de usar la misma como vista de reservas, como opci´on alternativa a la original del sistema. Para esto se tuvieron que crear los m´odulos necesarios para adaptar dicha interfaz para poder visualizar reservas con la misma metodolog´ıa que las actividades de planificaci´on.
Cap´ıtulo 5. Funcionalidades 42
para poder manejar las entradas de los datos a visualizar. Se muestra en 5.5 un ejemplo de la interfaz.
Figura 5.5: Vista de reservas.
Se puede ver que en esta vista hay una fecha en cada columna que indica que es un d´ıa puntual y no uno gen´erico. Se puede navegar las diferentes semanas de manera r´apida con las flechas y el almanaque. Para poder diferenciar visualmente esta vista de reservas y la de planificaci´on, se cambiaron el color de los fondos ya que se podr´ıan presentar confusiones por el parecido.
5.2.3.
Recomendador de aulas
Una de las limitaciones que llevaba originalmente el sistema base era la dificultad presentada a la hora de buscar un aula para determinada actividad. La vista origi-nal con la que contaba daba un buen panorama de la distribuci´on de eventos pero dificultaba la b´usqueda de recursos disponibles.
Una de las funcionalidades agregadas fue la posibilidad de realizar un resumen de las aulas sin uso para un determinado d´ıa y horario, como as´ı tambi´en pidiendo determinada capacidad de la misma. Este m´odulo agiliza tanto el armado de plani-ficaci´on, como la b´usqueda de un recurso ante un evento que surja y requiera una reserva alg´un d´ıa puntual.
Cap´ıtulo 5. Funcionalidades 43
(d´ıa, hora y periodo) y la capacidad dada en el formulario. Se muestra en 5.6 un ejemplo de recomendaci´on en la vista de planificaci´on. Los recursos mostrados son filtrados seg´un los permisos sobre los recursos con los que cuenta el usuario.
Figura 5.6: Aulas disponibles en horario seleccionado
5.2.4.
Mejoras de uso
A lo largo del desarrollo, uso y capacitaci´on a los usuarios, surgieron requerimien-tos no funcionales que mejoraban la usabilidad del sistema.
Entre ellos, se pueden destacar:
Diferenciaci´on entre la Vista de Planificacion y Vista de Reservas (nueva) a trav´es de colores de fondo en cada una.
Separaci´on de funciones en el formulario de la interfaz. Se realiz´o una divisi´on visual m´as marcada entre el filtro de actividades y los datos para dar de alta un nuevo evento.
Usar Ajax para agilizar la b´usqueda en vista nueva, as´ı no es necesario recargar la p´agina en la navegaci´on entre semanas (limitaci´on de la vista original del sistema).
Cap´ıtulo 5. Funcionalidades 44
utiliz´andose. Ejemplos de este tipo de procesos son el pasaje de las activida-des planificadas a reservas o la eliminaci´on de reservas provenientes desde la planificaci´on.
Cap´ıtulo 6
Roles adoptados
Una vez instanciado cada componente del ciclo de desarrollo del producto, este debe ser aplicado llevando a cabo diferentes roles. A continuaci´on se describir´a cada rol adoptado para dicho desarrollo.
6.1.
Roles para desarrollo de software
..A development team may be just one person, or 42, but in any team a number of roles can be identified. In a small team, one person may have multiple roles, whereas in larger teams, it is more common to have dedicated roles. Regardless, identifying the roles in a team will help bring structure to the team, and will help create awareness of responsibilities; if, for example, nobody feels responsible for testing the software, bugs in the final release are inevitable [2].
A lo largo del desarrollo del sistema se tuvo que pasar por diferentes roles para cada etapa del mismo. Todos los roles son importantes para producir el sistema adecuado sin errores.
Depende de las caracter´ısticas de cada proyecto, la cantidad de roles que deben existir, pero en cualquier caso es necesario que cada integrante conozca claramente las actividades que debe realizar. Puede ser tambi´en que una ´unica persona tenga a su cargo distintos roles, como por ejemplo: Un integrante al que le corresponda testear, adem´as tenga que verificar la calidad del producto.
Cap´ıtulo 6. Roles adoptados 46
6.2.
Roles llevados a cabo
En cuanto al sistema de aulas desarrollado se vio necesario asumir varios roles. Esto llev´o a una buena formaci´on profesional teniendo diferentes visiones sobre el proyecto. A continuaci´on se har´a una descripci´on de las actividades pertenecientes a los diferentes roles adoptados a lo largo del ciclo de vida.
Captura de requerimientos
Todo proceso de desarrollo de software comienza con la captura de los requeri-mientos del cliente (usuario final). Como el proyecto cont´o con 2 etapas, en las cuales, primero estuvieron como unidades acad´emicas participantes s´olo 2 facultades (Fac. de Cs. Exactas y Fac. de Cs. Econ´omicas) y otra en la que se unieron las facultades restantes, se tuvieron que realizar el relevamiento de requerimientos en momentos diferentes. Cabe aclarar que al contar con un proceso de desarrollo iterativo, se tiene posibilidad de incorporar y refinar continuamente estos requerimientos f´acilmente (ver Secci´on 3.2.1).
En primer instancia, se realizaron reuniones con los responsables de la asignaci´on y reservas de aulas de las facultades correspondientes a la primer etapa. El objetivo de estas reuniones fue confeccionar un documento que defina las tareas a realizar por los mismos y captar las deficiencias en dicho proceso que pueda agilizar el sistema a desarrollar. Estos requerimientos, fueron el punto de partida para dicho desarrollo.
En cuanto a la segunda etapa, tambi´en se realiz´o las correspondientes reuniones con los usuarios que se incorporaron al uso del sistema (Fac. de Cs Humanas, Fac. de Cs Veterinarias, Biblioteca, responsables de aulas de Rectorado). Se analizaron sus proceso de trabajo buscando similitudes y diferencias con los ya entrevistados en la etapa anterior y, a diferencia de esta, se busc´o tambi´en adaptar las necesidades encontradas al sistema ya desarrollado.
Cap´ıtulo 6. Roles adoptados 47
Desarrollo
El desarrollo se realiz´o en su totalidad por los alumnos acreedores de la beca de contraprestaci´on. En un principio, no se realiz´o una divisi´on de tareas puntual por m´odulos a implementar por cada desarrollador, pero luego se fueron adoptando especialidades de cada uno teniendo en cuenta sus habilidades. As´ı, un desarrollador se dedic´o m´as al front-end y otro al back-end. Sin embargo, se necesit´o un previo conocimiento en ambas ´areas para poder mantener una correcta comunicaci´on y funcionamiento.
En todo momento, se busc´o mantener la arquitectura establecida en el sistema y una buena calidad de codigo. Esta tarea requiri´o el correspondiente refactoring 1 en muchas etapas del desarrollo.
Para poder establecer un progreso colaborativo del producto se uso un versionado de c´odigo utilizando herramientas que lo permiten (SVN)[25]. Se busco establecer cada commit con su correcto comentario para poder llevar un mejor control de ca-da versi´on. Fue necesario establecer un constante contacto y buena comunicaci´on entre los programadores para poder mantener la consistencia del sistema y el correc-to avance de la producci´on de las funcionalidades. Esta tarea no present´o muchos inconvenientes dado que fueron pocas las personas dedicadas a esta etapa.
La idea del incremento del producto fue resolver las funcionalidades a realizar prioritariamente y establecer r´apidas entregas respetando metodolog´ıas ´agiles.[3]
Test
Una vez desarrollada una funcionalidad y previo a realizar su despliegue, es ne-cesario generar casos de test para verificar el correcto funcionamiento de la misma. Estos se realizaron sobre el server de desarrollo, ya que contaba con las mismas caracter´ısticas que el de producci´on, con lo que su funcionamiento, en teor´ıa, ser´ıa id´entico.
Para llevarlos a cabo, se probaron ejemplos de uso, utilizando diferentes tipos de usuarios con sus permisos correspondientes y verificando que el sistema siga consis-tente y sin errores. Tambi´en se tuvieron en cuenta en el uso los atributos de calidad
Cap´ıtulo 6. Roles adoptados 48
del sistema como la disponibilidad del mismo, o una adecuada performance. El uso de un usuario no debiera dejar saturado el sistema para el resto de los usuarios.
Despliegue
La etapa de despliegue (odeploy) consiste en la puesta en producci´on del sistema. Los servidores que corren el sistema est´an f´ısicamente ubicados en el DataCenter del campus universitario. El sistema se aloja y ejecuta en una de las m´aquinas virtuales que se encuentran sobre los mismos.
La virtualizaci´on ofrece varias ventajas, hace m´as f´acil la administraci´on y mante-nimiento de hardware al tener en pocas m´aquinas f´ısicas y es posible la generaci´on de m´aquinas con similares caracter´ısticas para poder realizar pruebas. Para virtualizar, el DataCenter utiliza Xen [27]. Como la m´aquina virtual utilizada corr´ıa con Unix, la tarea de despliegue requiri´o mucho aprendizaje este tipo de sistemas operativos.
Se tuvieron que tener en cuenta muchas cuestiones para dejar el sistema funcio-nando de manera correcta, como la consistencia de la base de datos, sin que esta pierda informaci´on o compatibilidad de versiones utilizadas con las instaladas.
Mantenimiento
El proceso de desarrollo de un sistema que cumpla con los objetivos planteados implica el correcto y constante mantenimiento del mismo. Nuevos requerimientos son obtenidos a partir de su uso. Durante esta etapa se propuso una continua interacci´on con el usuario con el objetivo de obtener el feedback correspondiente y realizar las posibles mejoras o arreglos en base al mismo. Peri´odicamente se realizaron reuniones con los usuarios para verificar el correcto uso del sistema y si se encontr´o alg´un tipo de cr´ıtica que ayude a mejorarlo, como as´ı tambi´en para establecer soporte para el correcto uso de la aplicaci´on.
Capacitaci´on
Cap´ıtulo 6. Roles adoptados 49
Cap´ıtulo 7
Asignaci´
on autom´
atica de aulas
En este cap´ıtulo se dar´a explicaci´on de algunas t´ecnicas investigadas para poder realizar una distribuci´on de aulas autom´atica, realizando una b´usqueda eficiente de objetivos. Esta etapa, se desarroll´o de manera independiente al sistema. Una vez en uso el sistema, fue posible contar con datos reales para poder aplicar algunas t´ecnicas de distribuci´on ´optima de aulas.
7.1.
Algoritmos Gen´
eticos
Existen varios algoritmos o variantes de los mismos para poder realizar una buena optimizaci´on de los usos de los recursos de los espacios institucionales. Los algoritmos gen´eticos han demostrado ser una herramienta muy eficiente para resolver este tipo de problemas[9][10]. Estos consisten en una t´ecnica de programaci´on que imita a la evoluci´on biol´ogica como estrategia para resolver problemas.
Dado un problema espec´ıfico, la t´ecnica parte desde soluciones potenciales llama-das individuos. Estos individuos son codificados o representados de alguna manera para que pueda ser posible medirle su calidad como soluci´on. El algoritmo selecciona desde un conjunto de individuos (poblaci´on), aquellos que son m´as capacitados para luego generar otros (reproducirlos) y realizar mutaciones, con el fin de generar nuevas soluciones que estar´an mejoradas con respecto a la anterior generaci´on.
El proceso planteado se realiza de forma reiterada hasta el cumplimiento de alg´un criterio de convergencia o llegar a una cierta cantidad de iteraciones.
Cap´ıtulo 7. Asignaci´on autom´atica de aulas 51
A partir del esquema planteado, es necesario definir los siguiente elementos para poder utilizarlos a lo largo del proceso del algoritmo:
1. Individuo: Representa una soluci´on potencial del problema planteado.
2. Poblaci´on: Conjunto de individuos pertenecientes a una de las iteraciones (generaci´on).
3. Representaci´on: Codificaci´on de una soluci´on para poder aplicarle cambios a lo largo del algoritmo.
4. Funci´on de fitness: Le asigna un valor real num´erico que, se supone, refleja el nivel de adaptaci´on al problema de una soluci´on.
5. Operador de cruce: Genera una soluci´on descendiente a partir de dos (o m´as) soluciones padres.
6. Operador de mutaci´on: Genera una soluci´on a partir de otra modificando sus valores de representaci´on.
Realizada la descripci´on y nombrados los elementos, se puede plantear un pseudo-c´odigo de un algoritmo gen´etico simple de la siguiente manera:
while (NOTConverge) do
for (Tama˜no de poblaci´on) do
Seleccionar individuos de la poblaci´on con cierta probabilidad proporcional a la funci´on de fitness de cada uno.
Cruzar los individuos obtenidos para generar descendientes.
Mutar los descendientes con cierta probabilidad.
Computarla funci´on de fitness de los descendientes mutados.
Insertar los descendientes mutados en la nueva generaci´on.
Elegir sobrevivientes para siguiente iteraci´on.
Cap´ıtulo 7. Asignaci´on autom´atica de aulas 52
7.2.
Aplicaci´
on al problema
Buscando resolver la problem´atica planteada de optimizaci´on de aulas, se realiz´o una implementaci´on de un algoritmo gen´etico que maximice la utilizaci´on de los recursos de UNICEN. El mismo busca obtener una aproximaci´on a una soluci´on de distribuci´on de los eventos cargados desde el m´odulo de planificaci´on cuatrimestral del sistema en uso. Se opt´o por la planificaci´on cuatrimestral ya que refleja un caso real de clases programadas.
Para ellos fue necesario identificar los elementos y m´odulos propios de los algo-ritmos de este tipo en el dominio aplicado. A continuaci´on se explicar´a cada uno [13].
7.2.1.
Representaci´
on
Como primer paso para llevar a cabo el algoritmo, se tiene que tomar uninput en formato fenot´ıpico y transformarlo en una representaci´on genot´ıpica. Es decir, tomar una soluci´on representada en el dominio real y poder codificarla de una manera con la cual el algoritmo pueda manipular f´acilmente sus datos. Esta etapa permite generar los cromosomas necesarios a partir de los datos de entrada para poder llevar a cabo los pasos del algoritmo. Se entiende por cromosoma a cada dato que contiene una soluci´on.
Cap´ıtulo 7. Asignaci´on autom´atica de aulas 53
Una vez definida como ser´a una actividad, se concluy´o que la representaci´on fenot´ıpica de una planificaci´on ser´a una lista de ´estas por cada d´ıa de la semana. Cabe destacar que se tiene la restricci´on de que no pueden haber dos actividades en el mismo lugar y a la misma hora:
Obtenidos los datos que forman parte de una planificaci´on semanal, se defini´o la representaci´on genot´ıpica equivalente para poder realizar un manejo de los mismos dentro del algoritmo. Estos datos internos de cada representaci´on se denominan cromosomas. Como genotipo, entonces, una planificaci´on ser´a dispuesta sobre un arreglo unidimensional de tama˜no HxDxR, donde H es la cantidad de slots de tiempos en los que se miden las actividades,D es la cantidad de d´ıas por semana en los que hay actividades y R es la cantidad de recursos (aulas) que se disponen. En el trabajo realizado:
H=28 (slots de media hora entre las 8 y 22 hs).
D=6 (de lunes a s´abados).
Cap´ıtulo 7. Asignaci´on autom´atica de aulas 54
As´ı, cada elemento del arreglo ser´a un 0 en caso que no haya ninguna actividad asignada a la hora, el d´ıa, en el aula correspondiente, y un n´umero entero referente al ID de la actividad que se llevar´a a cabo en el horario del aula que le toca a la posici´on del arreglo. Estos elementos (enteros o 0s) son llamados alelos del cromosoma. Vale aclarar que una actividad no puede empezar un d´ıa en ´ultimo horario y seguir al d´ıa siguiente, ni tampoco darse en 2 aulas diferentes, por lo que estas son restricciones a verificar al momento de generar nuevas soluciones por medio de cruces o mutaciones [13].
7.2.2.
Funci´
on de fitness
El objetivo del algoritmo desarrollado es maximizar la utilizaci´on de los recursos. Por lo tanto, es necesario definir un criterio que defina que tan buena es una soluci´on. Muchas veces, este criterio es subjetivo y depende de las necesidades de d´onde se lo aplique.
El problema de optimizaci´on de usos de aulas depende de cada instituci´on. Por lo tanto, de acuerdo a los objetivos planteados se buscaron b´asicamente 3 metas:
Bajo desperdicio de lugares en las aulas: A cada actividad programada se le tiene que asignar una cantidad de personas que asistan (por ejemplo, alumnos de una clase). Si esa cantidad de personas esta muy alejada de la capacidad del aula, la soluci´on empeora.