UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN

Transcripción

1 UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIÓN DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN WEB PARA LA GESTIÓN Y EJECUCIÓN DEL PROCESO DE EVALUACIÓN DE DESEMPEÑO DE UNA UNIVERSIDAD MEMORIA PARA OPTAR AL TÍTULO DE INGENIERO CIVIL EN COMPUTACIÓN MAURICIO DANIEL WITTENBERG NISSIM PROFESOR GUÍA: SERGIO OCHOA DELORENZI MIEMBROS DE LA COMISIÓN: JOSE ALBERTO PINO URTUBIA VALERIA PAZ HERSKOVIC MAIDA SANTIAGO DE CHILE ABRIL 2010

2 Resumen Ejecutivo La Evaluación de Desempeño de la Pontificia Universidad Católica de Chile, es una herramienta que permite medir el estado de la planta profesional-administrativa de dicha institución. Los objetivos principales de esta herramienta son medir la calidad y el potencial humano desempeñando funciones, identificando los recursos humanos como un recurso básico de la Universidad. La correcta aplicación de esta herramienta permite obtener una evaluación del personal relativo a las variables de interés, eliminando subjetividades al momento de calificar. Además permite identificar necesidades técnicas del personal, tales como capacitaciones o pasantías y genera una instancia de análisis y planificación entre el superior y el subordinado, donde se clarifican obligaciones, objetivos, compromisos y/o expectativas de ambas partes. Los resultados de la evaluación de desempeño tienen efecto sobre la distribución de la planta administrativa tales como contrataciones, promociones o despidos teniendo una gran injerencia en la productividad de los recursos humanos de la Universidad. Dada la importancia de la herramienta, el proceso encargado de completar todas las evaluaciones de desempeño debe ser fluido. De no ser así, el proceso utilizado le adhiere complejidad a la herramienta, afectando de manera negativa los resultados de la misma. El objetivo central de este trabajo es rediseñar y actualizar el proceso de ejecución de la Evaluación de Desempeño de la UC utilizando tecnologías actuales que permitan acortar y controlar el tiempo necesario para completar las evaluaciones del los funcionarios de la Universidad. Para lograr este objetivo, se desarrollará una aplicación web en PHP que capture las relaciones jerárquicas entre los funcionarios de la UC y permita que estos completen los formularios de evaluación de acuerdo a las relaciones antes ingresadas y a la lógica impuesta por el Proceso de Evaluación de Desempeño. 1

3 Contenido I. Introducción... 4 A. Motivación... 7 B. Objetivo General... 8 C. Objetivos Específicos... 8 D. Plan de Trabajo... 9 II. Revisión Bibliográfica A. Esquema de una Aplicación Web...11 B. Lenguaje por el Lado del Servidor...12 C. Framework de Desarrollo Web...13 D. Seguridad en una Aplicación Web...13 E. Herramientas para el Desarrollo Web...14 III. Metodología de Trabajo A. Aspectos Generales Situación previa a la implementación de la aplicación: Objetivo del Proyecto - Resultados Esperados...18 B. Ambientes, Restricciones y Requisitos...20 C. Toma de Requisitos Global...23 IV. Módulo Organigrama A. Requisitos del Módulo Requisitos Funcionales Requisitos de Interfaces Requisitos de Restricción:...27 B. Diseño...28 C. Implementación Configuración Inicial Edición Unidades Raíces Opciones Unidad Raíz Validación de un Organigrama Transición entre Periodos...48 V. Módulo Evaluación A. Requisitos del Módulo

4 1. Funcionales Arquitectura Restricción...51 B. Diseño DIMENSIONES PREGUNTA SIMPLE PREGUNTA CHECKBOX PREGUNTA SIMPLE SELECT PREGUNTA SELECT RADIO TITULO SEPARADOR...59 C. Implementación Ingreso al Sistema Interfaz del Evaluado Interfaz del Evaluador Interfaz del Revisor Entrevista Comentarios Formularios Transición entre Periodos...66 VI. Resultados Obtenidos VII. Conclusiones y Trabajo a Futuro VIII. Bibliografía y Referencias IX. Anexos A. Formulario Evaluación...74 B. Formulario de Revisión...77 C. Formulario Entrevista...81 D. Formulario Comentarios

5 I. Introducción La Dirección de Asuntos de Personal (DAP) de la Pontificia Universidad Católica (PUC) de Chile era en sus orígenes un área cuyas funciones principales consistían en pagar los sueldos de los administrativos y académicos y gestionar los trámites legales usuales del personal, como el pago de AFP e Isapres. La PUC está compuesta de 18 facultades o unidades académicas y 30 unidades administrativas. Cada una de estas unidades tiene asociado un organigrama institucional general que detalla las áreas más generales y relevantes dentro de cada unidad. La DAP depende directamente de la Casa Central de la PUC. Por otra parte, la PUC permite que cada una de estas unidades posea un alto grado de libertad en cuanto a la administración y toma de decisiones. Esta política permite que la toma de decisiones sea mucho más fluida y genera unidades más eficientes y activas; esto se da especialmente en las unidades académicas, donde la generación de conocimiento es mucho más rica de lo que sería si cada nuevo proyecto o decisión tuviese que atravesar un flujo burocrático hasta Casa Central y de regreso a la unidad. No obstante lo anterior, existen diversos enlaces de dependencia desde las unidades hacia Casa Central. La primera es que a pesar de la libertad de cada una de las unidades, todas ellas son parte de la Universidad y por ende comparten la misma misión y visión de la Pontificia Universidad Católica. Además, los presupuestos anuales de cada unidad son revisados y aprobados por Casa Central. Cada 5 años las unidades deben presentar un Plan Estratégico de Desarrollo para los siguientes 5 años, donde se explique cuáles serán las estrategias utilizadas para crecer como unidad y así aportar al crecimiento de la PUC. A contar de los años 90 empieza a surgir la noción de que la DAP era una unidad que debía evolucionar de tal forma que entregue valor a la PUC a través de su capital humano, y que tenga la capacidad de generar instrumentos de análisis que le permitan concebir políticas de gestión de personal, tales como contrataciones, despidos, capacitaciones, etc. En resumen, ser capaz de ejecutar las tareas propias de una área a cargo de la gestión de los RR.HH. de la Universidad. En el año 2000, con la llegada del actual rector de la PUC, esta noción se concreta de manera puntual, ya que rectoría precisa que la DAP debía no sólo prestar servicios de RR.HH 4

6 usuales, sino que también aportar al desarrollo organizacional, optimizando la funcionalidad de la planta profesional-administrativa, generando el máximo valor posible a través de la gestión del capital humano, utilizando las técnicas y herramientas profesionales empleadas en el área de Desarrollo Organizativo, propias de un área de RR.HH. moderna. Es por esto que el año 2001 nace el Proceso de Evaluación de Desempeño (PED). Este proceso se aplica año tras año, y permite medir el estado de la planta profesional-administrativa de la PUC. El PED se divide principalmente en tres etapas: planificación, ejecución y análisis. La etapa de planificación determina cuáles serán los roles que ejecutarán los funcionarios de cada una de las unidades: quiénes serán evaluados, quién realizará estas evaluaciones, si alguien se auto-evaluará, quién no puede o no debe ser evaluado, etc. Es importante notar que para la DAP la lógica que permite crear estas reglas de evaluación y asignación de roles es relativamente clara. Aun así, en la etapa de planificación surge un problema quizás poco esperado. El PED necesita evaluar la realidad laboral de las unidades: quién es el jefe de una determinada área, quiénes son sus sub-alternos, cuáles de estos sub-alternos son a su vez jefes de una sub-área, y así sucesivamente. Debido a la libertad que posee cada una de las unidades para gestionar su propio desarrollo, es muy difícil tener un organigrama detallado de cada una de ellas. Si bien es cierto que la DAP es el área encargada del pago de sueldos y por ende es posible saber en qué unidad trabaja cada persona pagada por la PUC, a veces es muy difícil saber exactamente dónde trabaja alguien y quién es su jefe, ya que cualquier jefe de área podría tomar un subconjunto de su área, nombrar como jefe a uno de los miembros de ese sub-conjunto y crear así una nueva sub-área, sin necesidad de informar a la DAP o a Casa Central. Se puede ver que esta realidad no afecta la lógica del pago de sueldos, pero sí destruye la posibilidad de tener de manera simple un organigrama que satisfaga las necesidades del PED. Esto obliga a realizar una continua revisión de los organigramas de cada unidad, retrasando considerablemente la etapa de planificación, que además debe crear los formularios de evaluación y mandarlos a imprimir para poder llevar a cabo la etapa de ejecución. 5

7 En la segunda etapa (de ejecución) se distribuyen los distintos formularios de evaluación entre todas las unidades. En cada una de las unidades existe un Director o Sub-Director de Asuntos Administrativos encargado de distribuir las evaluaciones dentro de la unidad a cada una de las áreas. Los problemas descritos en la etapa anterior impactan sobre esta etapa, ya que es posible que a algunas unidades no lleguen formularios suficientes para llevar a cabo la evaluación, siendo necesario invertir una gran cantidad de tiempo solucionando este tipo de problemas y obligando a extender la duración de esta etapa. Finalmente, cuando dentro de lo posible todas las áreas de todas las unidades han evaluado a su personal, se recolectan todas las evaluaciones y se envían de vuelta a la DAP en Casa Central. Debido a la gran cantidad de formularios que se manejan durante el proceso de evaluación y todas las unidades y áreas involucradas, la recolección también atrasa el proceso, y agrega nuevos problemas, como por ejemplo la pérdida de formularios durante el traslado. Finalmente, la tercera etapa de análisis contempla la digitalización de toda la información recolectada durante el proceso de ejecución. Una vez digitalizados los datos de toda la Universidad, se crea un reporte general de resultados, el cual es enviado a una oficina de estadísticas, donde los resultados de cada persona son corregidos de acuerdo a un análisis de los resultados de toda la PUC. El proceso de análisis presenta dos problemas que retrasan su ejecución. Por una parte, es necesario digitalizar toda la información y la cantidad de gente disponible para realizar esta tarea no es capaz de hacerlo a la velocidad necesaria para agilizar el proceso. Por otra parte, el proceso no se puede dar por finalizado mientras que no se reciban los resultados de la oficina de estadísticas. No se puede pedir el análisis estadístico mientras que no se hayan digitalizado todos los datos. Por lo tanto, todos los retrasos de las etapas anteriores afectan en la duración del proceso, y en particular la digitalización se debe realizar por completo antes de poder llevar a cabo el último paso de análisis estadístico. 6

8 A. Motivación La sección anterior describe la relevancia que posee la evaluación de desempeño, tanto como una herramienta de RR.HH. en sí misma, y en particular debido a la misión y objetivos de la PUC. Específicamente, es parte su plan de desarrollo para el periodo en las áreas de personal administrativo y recursos. Además, se puede ver en detalle las falencias que posee la implementación actual de la evaluación. En cada una de las distintas etapas es posible realizar cambios que permitirían agilizar dicha instancia y como resultado final acortar el tiempo de ejecución total de PED. Además de hacer el proceso más eficiente, es posible crear una herramienta que podrá ser utilizada para generar información acerca del personal, permitiendo a la DAP dictar políticas centrales que mejorarán el ambiente y la calidad laboral de la Universidad. Por todas estas razones es interesante desarrollar una aplicación que permita a la DAP agilizar las distintas etapas del PED, pudiendo así resolver los problemas antes expuestos y finalmente aportar un mayor valor a la Universidad. Cada una de las etapas presenta un desafío en sí misma. En la etapa de planificación, es posible desarrollar una aplicación que asista en la creación y reestructuración de los organigramas de las unidades. Una herramienta de este tipo, en línea y que esté integrada con las bases de datos de personal de la PUC, permite ir a terreno a cualquier unidad y gráficamente movilizar individuos entre las distintas áreas de la unidad. Además una aplicación de este tipo, que posee acceso a la información del personal, tales como el grado profesional y la unidad a la que pertenece, permite generar alertas y manejar condiciones de borde que garanticen la correctitud y completitud del organigrama de acuerdo a las reglas propias del PED. Luego, en la etapa de ejecución el impacto podría ser enorme. Al implementar la ejecución como un módulo en línea, aprovechando la autenticación de usuarios con los sistemas de la PUC se elimina la impresión de formularios en papel, se obvian por completo los tiempos de distribución y recolección de formularios y es posible obtener de manera casi instantánea el estado de la ejecución con cualquier granularidad de detalle deseado, ahorrando así tiempo y recursos. Finalmente en la etapa de análisis se puede ver que hay un profundo impacto en el tiempo que toma llevar a cabo este proceso. En la etapa anterior se distribuyó la responsabilidad de 7

9 digitalizar la información entre los actores, por lo tanto en esta etapa éste es un paso que deja de existir. En vista de que los datos ya se encuentran digitalizados, sólo es necesario generar un informe de resultados que será enviado a la oficina estadística para obtener las correcciones necesarias. La última etapa del proceso se reduce prácticamente a esperar estos resultados. Es claro entonces ver por qué el desarrollo de una aplicación diseñada a medida permitiría a la DAP en primera instancia gestionar de manera eficiente los procesos de la etapa de planificación, mejorar los tiempos y recursos usados en las etapas de ejecución y análisis. También se puede ver la necesidad de desarrollar la aplicación utilizando una arquitectura sobre la web, ya que esto garantiza el acceso a los distintos módulos de la aplicación en cualquier lugar que posea acceso a la red interna de la PUC. B. Objetivo General El objetivo general de este trabajo será diseñar e implementar una aplicación web que por una parte, permita a la DAP llevar a cabo de manera eficiente las distintas etapas del PED y que, por otra parte, traspase la responsabilidad de digitación a cada uno de los actores que participa en la etapa de ejecución del proceso. La aplicación constará principalmente de dos módulos respectivos a cada etapa del proceso. El primero, un módulo para la construcción de organigramas que apoyará la etapa de planificación y el segundo para la creación y aplicación de formularios en línea para la etapa de ejecución. Adicionalmente se creará un reporte general con los resultados de la evaluación. C. Objetivos Específicos Se detallan a continuación los objetivos específicos del trabajo a realizar: Crear una aplicación web que satisfaga las necesidades de la DAP para llevar a cabo el PED de manera on-line. Desarrollar una aplicación que sea capaz funcionar año a año, adecuándose a los cambios de personal. 8

10 Integrar el desarrollo externo con los sistemas de la PUC, tales como la autenticación por LDAP y el acceso a las bases de datos de personal. Entregar las herramientas necesarias que permitan mejorar el proceso de evaluación de desempeño, disminuyendo el tiempo necesario para llevar a cabo el proceso y aumentando el número de administrativos evaluados y autoevaluados. Mejorar la calidad de los resultados entregados por el sistema una vez que ha finalizado la ejecución de proceso, permitiendo a la DAP tomar decisiones y/o generar políticas de personal a nivel universitario. D. Plan de Trabajo Para completar el trabajo propuesto se seguirán los siguientes pasos: 1. Reuniones con los distintos actores del proceso para tener una perspectiva global y aproximada del problema. 2. Determinar cuáles son las restricciones y requisitos más importantes impuestos por la Dirección de Informática (DI) de la UC en cuanto a un desarrollo para la Universidad por un agente externo. 3. Primera instancia de captura de requisitos y lógica del negocio del proceso de evaluación de desempeño en todas sus etapas, dando énfasis a los requisitos de la primera etapa y tomando en cuenta que estos deberán ser revisados una vez que los requisitos sean contrastados con la información disponible en las bases de datos de la PUC. 4. Determinar la arquitectura a utilizar para llevar a cabo el proyecto. 5. Gestionar con la DI un ambiente de desarrollo acorde a las necesidades del proyecto y las decisiones de diseño del punto anterior. Además, obtener acceso a las distintas bases de datos que contengan la información relevante al proceso. 6. Desarrollar la aplicación que permita generar un organigrama laboral de los administrativos y académicos de la PUC, incluyendo la definición de unidades, personas asociadas a cada unidad, y relación evaluador-evaluado-revisor entre los actores de una unidad. 7. Validar la solución funcionalmente con la DAP y técnicamente con la DI. 9

11 8. Análisis en detalles de los requisitos pertinentes a la generación de formularios de evaluación, tomando en cuenta los distintos tipos de formularios y distintos tipos de contenidos necesarios para llevar a cabo la evaluación de un individuo. 9. Desarrollar la aplicación de creación de formularios dinámicos. 10. Crear la interfaces de acceso a la aplicación e integrarlas con los servidores de autenticación LDAP de la Universidad. 11. Crear las interfaces de evaluación, auto-evaluación y revisión que integren las aplicaciones de organigrama y creación de formularios, para llevar a cabo la etapa de ejecución del PED. 12. Separar las funcionalidades de evaluación en función de los roles asignados a cada usuario de la aplicación. 13. Revisar la seguridad general de la aplicación, tomando en cuenta las fallas de seguridad propias de una aplicación web y dimensionando su impacto en la aplicación en caso de ser explotadas. 14. Validar la aplicación funcionalmente con la DAP y técnicamente con la DI realizando pruebas de carga de acuerdo a los requisitos de la DI. 15. Análisis en detalle de los requisitos pertinentes a la generación de reportes y estadísticas en función de los datos recolectados en el proceso anterior. 16. Creación de un reporte general con los resultados de la evaluación. 17. Simular el proceso del próximo año, garantizando así la continuidad funcional de la aplicación para los siguientes periodos del proceso de evaluación. 10

12 II. Revisión Bibliográfica Para llevar a cabo el desarrollo de una aplicación web, se investigaron los siguientes temas: A. Esquema de una Aplicación Web. B. Lenguaje por el Lado del Servidor. C. Framework de Desarrollo Web. D. Seguridad en una Aplicación Web E. Herramientas para el Desarrollo Web. A. Esquema de una Aplicación Web Hoy en día, en general es considerada una buena práctica realizar el desarrollo de una aplicación web a través del esquema Modelo-Vista-Controlador (MVC) [1, 2]. Este esquema permite separar las tres áreas más importantes en la arquitectura de la aplicación web en las tres capas antes descritas, pudiendo así independizar áreas del desarrollo e identificar de manera más simple en qué capa es necesario realizar cambios o en cuál están ocurriendo errores o comportamientos inesperados. El MVC plantea utilizar la capa del modelo para realizar el acceso de la aplicación a los datos, abstrayendo al programador de la implementación particular en la cual los datos son almacenados. La capa del modelo es la encargada de desplegar información al usuario y, en el caso de proveer una interfaz que permita realizar cambios, envía los cambios desde la vista a la aplicación. Finalmente, el controlador es la conexión entre el modelo y la vista. El controlador es en una dirección el encargado de tomar datos del modelo, procesarlos y entregarlos de una manera en el que la vista pueda desplegarlos. En la dirección opuesta, recibe datos de la vista, los procesa según la lógica del negocio de la aplicación y los entrega al modelo para que estos puedan ser almacenados, sin romper las reglas lógicas presentes en el modelo. En una aplicación web, esta dinámica suele darse de la siguiente manera: 11

13 1. El usuario de la aplicación decide acceder a algún contenido particular de la aplicación. 2. Este requisito de acceso es procesado por el controlador. 3. El controlador notifica al modelo, obteniendo así del modelo la información necesaria para satisfacer la petición del usuario. 4. El controlador recibe la información del modelo y la procesa de acuerdo a las condiciones particulares de la petición. 5. Una vez procesada la información, la envía a la vista. 6. La vista despliega la información entregada por el controlador. Una de las grandes ventajas que provee el MVC en el desarrollo de una aplicación web es que existen áreas del desarrollo que pueden ser identificadas con partes específicas del MVC. El modelo y controlador se pueden asociar a todo lo que se ejecuta en el servidor, procesamiento de los datos de acuerdo a la lógica del negocio y el acceso a las bases de datos. En cambio, toda la ejecución de las vistas ocurre por el lado del cliente en su navegador. Por otra parte, esta separación también ocurre a un nivel de habilidades necesarias. Trabajar con el modelo o el controlador en una aplicación web se traduce en conocer los lenguajes que se ejecutan en el servidor -hoy en día, por lo general lenguajes como PHP [3], Java [4] o Python [5] y los lenguajes de consulta de las bases de datos, que suelen tener pequeñas variaciones sobre el estándar de SQL [6, 7, 8, 9]. Por otro lado, al trabajar en las vistas, en necesario saber de HTML [10], CSS [11], Javascript [12], y la interacción entre estos. B. Lenguaje por el Lado del Servidor Al desarrollar una aplicación web, es necesario decidir cuál es el lenguaje en el servidor que se utilizará para procesar las interacciones entre la vista y el modelo. Además, por lo general la implementación del modelo también se basa en un lenguaje utilizado en el servidor, y es vital que este lenguaje soporte el acceso al menos a la base de datos específica que será usada en el desarrollo. Aun cuando existen una gran cantidad de lenguajes de programación utilizados por el lado del servidor, y de éstos, existe un número aún destacable que son considerados populares o de uso masivo, las realidades del proyecto a desarrollar sólo contemplan el uso de PHP o Java dada las restricciones impuestas por la Dirección de Informática. De estos, existe una clara 12

14 inclinación hacia PHP, por lo que se pierde la necesidad de investigar en torno a qué lenguaje utilizar. C. Framework de Desarrollo Web Para llevar a cabo el desarrollo, está demostrado que el uso de un Framework no sólo disminuye los tiempos de desarrollo sino que también, al encapsular las funcionalidades más usadas, se apoya sobre una base de código confiable y probada. Además, en torno a estos Frameworks existe una comunidad de usuarios y desarrolladores que constantemente validan y mejoran el producto. Desarrollados en PHP, los Frameworks OpenSource más populares son los siguientes: CakePHP [13] CodeIgniter [14] Symfony [15] Todas estas alternativas se basan en mayor o menor medida en el paradigma del MVC antes descrito, incluyendo pequeñas funcionalidades adicionales, especies de plug-ins para agilizar el desarrollo, principalmente en la capa de la vista en particular con herramientas que agregan usabilidad a las aplicaciones como AJAX [16] o la posibilidad de integrar con facilidad desarrollos externos al Framework pero escritos en PHP. D. Seguridad en una Aplicación Web Otro punto importante, necesario de considerar en cualquier desarrollo independiente del lenguaje, paradigma o arquitectura, es el de la seguridad de la aplicación. El desarrollo de una aplicación web presenta un desafío no menor en cuanto a la seguridad de la aplicación. Una aplicación web le entrega al usuario final, a través del navegador, una libertad enorme en cuanto a la información que éste le entrega de vuelta al servidor. A diferencia de aplicaciones escritas - por ejemplo- en C++, compiladas que operan directamente con la API del sistema operativo, donde el control que se le da al usuario se puede limitar tanto como uno quiera, una aplicación web le da al usuario completa libertad de ingresar el tipo de datos que quiera en la vista de su 13

15 navegador, pudiendo incluso deshabilitar políticas de validación por el lado del cliente. Es por esto que el principio básico de desarrollo de una aplicación web es que no es posible confiar en primera instancia en ningún dato que venga por el lado del cliente, que este haya podido alterar en su navegador o a través de algún software que le permita enviar solicitudes al servidor como si estas proviniesen de la aplicación web. Para lidiar con lo que en primera instancia se ven como fallas de seguridad propias de una aplicación web, existen organizaciones [17, 18] que definen políticas y buenas prácticas al momento de desarrollarlas, basadas en la experiencia de desarrollo de aplicaciones de las últimas décadas. En particular, se pueden encontrar recomendaciones para evitar que usuarios mal intencionados exploten fallas de seguridad típicas, como la inyección de código SQL [19] o la alteración de campos HTML de tipo hidden [20] para alterar la lógica de la aplicación. E. Herramientas para el Desarrollo Web Para apoyar el desarrollo de una aplicación web, existen diversas herramientas que permiten analizar el desarrollo de la aplicación. Como casi todo lo que se refiere a desarrollo web, nuevamente estas herramientas se pueden dividir en las que apoyan el desarrollo por el lado del servidor y las que lo apoyan por el lado del cliente. Por el lado del servidor, las herramientas son típicamente para detectar errores de programación en el lenguaje utilizado o errores sobre las consultas realizadas sobre el modelo [21, 22, 23]. Por el lado del cliente, se presenta uno de los desafíos más grandes. Todas las herramientas desarrolladas para asistir la programación de interfaces o sub-aplicaciones que aporten a la usabilidad de la aplicación más general están hechas para lidiar con las incompatibilidades de interpretación entre los distintos navegadores. Aun cuando los estándares de HTML, CSS y Javascript son claros y específicos, uno de los grandes problemas en la actualidad es la permisividad e incompatibilidad que existe entre los navegadores [24]. Para esto, hay herramientas que permiten ver exactamente cómo el navegador está interpretando los 14

16 distintos lenguajes [25, 26] y así poder desarrollar una aplicación que en la medida de lo posible funciona de la misma manera en todos los navegadores populares disponibles en el mercado. 15

17 III. Metodología de Trabajo A. Aspectos Generales Antes de poder iniciar el trabajo de diseño y posterior implementación de la aplicación, era necesario comprender el contexto en el cual se debía llevar a cabo el proyecto. Las primeras sesiones de trabajo, por lo tanto, se realizaron junto con la DAP y tenían como objetivo principal el de obtener una visión global del problema a resolver y los resultados que se deseaban obtener con la solución a desarrollar. Producto de estas reuniones, se estableció lo siguiente: 1. Situación previa a la implementación de la aplicación: El proceso de evaluación de desempeño constaba de un flujo de acciones bien definidas y estaba claro cuáles eran los actores que participaban de cada una de estas acciones. Sin embargo, aun cuando el funcionamiento conceptual del proceso no tenía grandes incertidumbres, la metodología de ejecución inducía una serie de problemas en el flujo, afectando principalmente los tiempos necesarios para llevar a cabo el proceso y para obtener información a través de estadísticas o reportes. A grandes rasgos, se comprendió cuáles eran las etapas más importantes del proceso y cuáles eran los problemas que afectaban a cada una de estas etapas, los que están detallados a continuación: a) Entrega de Formularios: El proceso de evaluación requiere que los actores contesten formularios de evaluación y autoevaluación. Estos formularios están en formato impreso y deben ser entregados por la DAP a las distintas unidades que participan del proceso. Así, cuando es necesario evaluar una unidad, se debe enviar desde Casa Central el número exacto de formularios que serán usados para este propósito. Además, existen distintos tipos de formularios, por lo que el evidente problema de distribución no es sólo originado por un asunto de cantidad sino que también de tipo. Más aún, cada unidad posee una jerarquía particular; los jefes de estas unidades tienen subalternos a quienes deben evaluar y existen parámetros propios de cada persona que definen qué tipo de formulario será usado para evaluarla o para ser autoevaluada. Por lo tanto, un único envío de formularios desde la DAP debe coincidir con los requerimientos específicos de tipo y cantidad que cada unidad posea y ser distribuido de forma efectiva. 16

18 Se entiende en estas reuniones que el principal desafío de la DAP en esta etapa del proceso es saber exactamente cuál es el organigrama de cada unidad: Quiénes trabajan en la unidad, a qué sub-unidad pertenecen dentro de la unidad, quién es el jefe de dicha sub-unidad y así sucesivamente hasta completar el organigrama. Uno de los principales problemas que se identifican en esta etapa del proceso tiene que ver con lo voluble de esta información, ya que los funcionarios pueden dejar de trabajar en la unidad de un año a otro, cambiar de sub-unidad o pasar a cumplir un rol de jefatura que antes no poseían. En vista de los problemas anteriores, la distribución de los formularios se realiza en base a una suerte de proceso de ensayo y error. Ya sea por correo electrónico o por teléfono, los distintos jefes de cada subunidad piden a la DAP el reenvío de formularios, ya sea para corregir un error de cantidad o de tipo, con el consiguiente desgaste de tiempo y recursos que esto implica. b) Evaluación: Ya en la instancia propia de la evaluación, ocurren problemas relacionados con la inacción de alguno de los superiores que debe evaluar y no lo hace, provocando que el proceso quede estancado. Además, esta etapa presenta un problema de gestión, ya que una vez entregados los formularios y definidos los plazos de evaluación, no es posible saber cuántas personas han sido evaluadas durante el transcurso del proceso, sino hasta la entrega final de formularios (momento de término de esta etapa). c) Recolección: Una vez finalizada la etapa de evaluación, es necesario recolectar todos los formularios distribuidos entre todas las unidades evaluadas y llevarlos de regreso a Casa Central. En el proceso de recolección hay formularios que pierden hojas o que simplemente se pierden por completo. Como se mencionó en la descripción de la entrega de formularios, al no saber con seguridad cuál es el organigrama de cada unidad, puede que la falta de un formulario no se note ya que no hay un registro exacto de cuántos formularios deberían volver a Casa Central. d) Digitación: Con todos los formularios de vuelta en la DAP se procede a digitar la información contenida en todos ellos. El número de formularios a digitar oscila entre los 2000 y 4000 (dependiendo de la cantidad de gente que es evaluada cada año), por lo que la digitación agrega una cantidad de tiempo considerable al proceso global. Existe una aplicación diseñada 17

19 especialmente para digitar la información contenida en los formularios, la que posteriormente es usada en la generación de reportes. 2. Objetivo del Proyecto - Resultados Esperados Los problemas descritos anteriormente tienen un efecto claro sobre el proceso de evaluación. El tiempo necesario para llevarlo a cabo se va extendiendo inevitablemente para poder así solucionar la gran cantidad de problemas que surgen en el camino. Además, como cada etapa es dependiente de la anterior, si no se resuelve un problema en una etapa determinada, el retraso de las etapas posteriores es inevitable. Es por esto que el principal objetivo del proyecto para la DAP según fue expresado directamente en estas reuniones sería acortar el tiempo necesario para llevar a cabo el proceso global de evaluación y así respetar los tiempos dispuestos para el proceso. Si se consigue este objetivo, se infiere que existiría además como consecuencia de este logro un interés por parte de la DAP para mejorar la calidad de los resultados de su evaluación, pudiendo obtener información adicional del proceso, más allá de la información contenida en los formularios. Dado que para llevar a cabo un proyecto de este tipo sería necesario interactuar con recursos de la UC (tales como bases de datos de funcionarios o sistemas de autenticación) y que el producto final tendría que operar dentro de la red interna de la universidad, era necesario entender en estas reuniones el rol que cumpliría la Dirección de Informática (DI) en el desarrollo del proyecto. Además, ya que la DI está a cargo de los sistemas de información usados por la DAP, se habló en particular con personas de la DI que tienen algún grado de conocimiento de la lógica del negocio de la DAP y del proceso de evaluación de desempeño y los problemas asociados a éste. En una primera reunión con la DI, tomando en cuenta la información obtenida en la DAP, se aclararon a grandes rasgos tres puntos importantes: (1) los sistemas a los cuales se podría tener acceso, (2) la arquitectura sobre la que estos operaban y (3) las facilidades que se entregan a un desarrollador externo a la UC. Con respecto a estos puntos, se obtuvo la siguiente información: La DAP trabaja con un sistema llamado "Muah'dib", que contiene la información de remuneraciones de todos los funcionarios de la UC. De este sistema y en el contexto del problema a resolver, la información relevante que se puede obtener con respecto a un funcionario es el tipo de cargo, el centro de costo que le paga su sueldo y la unidad a la 18

20 que pertenece. Además, es posible acceder a tablas que contienen la estructura de árbol de los centros de costos de la universidad. Las bases de datos del sistema Muah'dib están en ORACLE 10.0 y el desarrollo del proyecto debería también usar este tipo de base de datos. Por la experiencia previa de desarrollos externos, se da especial énfasis a este punto y se aclara que una aplicación en ambiente de producción solo puede consultar a las bases de datos utilizando procedimientos almacenados de ORACLE (PL/SQL). Un desarrollo externo web puede ser llevado a cabo en Apache + PHP o en Java + Tomcat. Todos los funcionarios de la UC cuentan con una contraseña única y la validación se realiza a través de un servidor LDAP. Toda aplicación web desarrollada para la UC debe pasar por una serie de pruebas de carga y seguridad, además de adherirse a los estándares impuestos por la UC, los cuales se encuentran debidamente documentados. Una vez finalizadas estas reuniones informativas se tiene una visión general del proyecto a desarrollar y de la interacción, requisitos y responsabilidades de la DAP y la DI. La DAP es el cliente directo del proyecto. La toma de requisitos, así como la negociación de plazos y funcionalidades se debe llevar a cabo en la DAP con los funcionarios a cargo de la gestión del proceso de evaluación. En tanto, la DI cumple dos roles: (1) proveer los recursos computacionales necesarios para llevar a cabo el desarrollo, es decir, ambientes de desarrollo, accesos a información, bases de datos, etc. y (2) validar que el producto entregado sea de calidad, entendiendo por calidad que la aplicación sea segura, robusta, confiable y que se adhiera a los estándares de la DI. 19

21 B. Ambientes, Restricciones y Requisitos En función de la información obtenida en la DI se decidió programar la aplicación utilizando PHP. Esta decisión se basa principalmente en que existe una mayor experiencia en el desarrollo web utilizando PHP que la otra alternativa disponible, Java. Además, se decidió utilizar el framework CakePHP que permite agilizar el desarrollo del proyecto al utilizar las funcionalidades usuales que se obtienen del uso de un framework MVC. También, dado que se utilizaría PHP por el lado del servidor, fue necesario investigar la factibilidad de conexión entre PHP y las bases de datos en ORACLE, ya que por lo general un desarrollo en PHP suele ir acompañado de una base de datos MySQL o PostgreSQL -todas soluciones de código abiertomientras que ORACLE es una solución propietaria. Investigando en torno a este punto se encontró la librería OCI8 y documentación asociada que provee justamente la funcionalidad deseada. Se consultó entonces con la DI si ya existían desarrollos en PHP que utilizasen esta librería. En efecto, la librería era parte de los recursos que podían ser provistos por la DI. Previo a la petición oficial del ambiente de desarrollo en cuanto a sus características tanto de hardware como de software, la DI hizo entrega de los siguientes manuales de estándares de desarrollo: Normativas y Estándares Bases de Dato Corporativa (1013STD004-03): Este manual explica cuáles son los nombres que pueden ser utilizados para nombrar tablas y columnas. Además, especifica el nombre que deben tener llaves primarias, foráneas, relaciones, índices, secuencias y triggers. También define un estándar de comentarios mínimos que debe incluir cada tabla y el modelo de datos global. Guía para el desarrollo de aplicaciones WEB Seguras (1000STD011-02): Detalla cuáles son los principales fallas de seguridad que suele tener una aplicación web, tales como la inyección de código SQL, el paso de parámetros a través de la URL o el uso de campos de tipo 'hidden' en el código HTML. Además, plantea soluciones tipo a estos problemas y el desempeño que se esperará de una aplicación en torno a estos temas. De estos dos grupos de documentos, es relevante para la toma de decisiones el segundo documento, ya que, aun cuando expone distintas alternativas a la solución de algunos problemas de seguridad propios de una aplicación web, obliga el uso de herramientas y técnicas de programación. Más que una recomendación, obliga un estándar. En particular, se pide que todo 20

22 el diseño del modelo de datos de la aplicación sea hecho usando PowerDesigner de Sybase. También, obliga el uso de procedimientos almacenados (PA) al consultar a la base de datos, explicando que el uso de PA garantiza la seguridad de la aplicación en cuanto a la inyección de código SQL por parte de un usuario mal intencionado. Este último punto implica una pérdida de funcionalidad del framework. Una de las virtudes del framework CakePHP es la manera en la que accede a los datos. Creando clases asociadas a las tablas del modelo y las relaciones que hay entre estos modelos (similares a las relaciones de llaves foráneas a nivel de la base de datos), el framework se encarga de construir las consultas SQL ejecutadas en la base de datos. Esta funcionalidad es particularmente útil cuando se tiene una gran cantidad de modelos (tablas) relacionadas entre sí, ya que todas uniones entre las tablas se calculan automáticamente. La manera en la que son retornados los datos al usar PA invalida por completo esta funcionalidad. Aun cuando esto no invalida el uso del framework, ya que posee otra gran cantidad de funcionalidades, sí implica que será necesario construir las consultas SQL y los procedimientos almacenados asociados a ellas. Es importante notar que la posibilidad de implementar un acceso alternativo a la base de datos dentro del framework es segura, ya que éste en sí no es más que otra aplicación PHP corriendo en el servidor Apache; por ende, siempre se podrá acceder a funcionalidades básicas de PHP o librerías construidas sobre estas funcionalidades básicas. Además de la presentación de estos manuales, durante las reuniones fueron explicados en detalle los recursos a los que se podría tener acceso en un ambiente de desarrollo. Conjuntamente con la base de datos ORACLE donde se podría acceder a la información de funcionarios y crear las tablas de la aplicación a desarrollar, se podría validar el acceso de los usuarios contra el servidor de autenticación LDAP de la UC. En el ambiente de desarrollo toda esta información se encontraba replicada en servidores similares a los que se encontraría en producción. Esto implicaba por ejemplo, que las contraseñas de los usuarios en desarrollo podían ser conocidas y por ende sería factible probar el acceso a la aplicación y la seguridad implícita en esta acción. Se estableció también por parte de la DI su política respecto del uso del librerías externas a PHP, siendo las más comunes las librerías de PEAR. Existe un consenso en la DI con respecto a que si una librería no presenta claras fallas de seguridad, funcionalidad o estabilidad, lo más 21

23 seguro es que su uso será admitido en el desarrollo y por ende su posterior instalación en un ambiente de producción. Finalmente, ante la petición de un acceso SSH al ambiente de desarrollo, se recibió por parte de la DI una tajante negativa, ya fuese dentro o fuera de la red interna de la UC. Según fue explicado, esto era considerado una mala práctica y un potencial problema de seguridad. Esto implicaría que sería necesario trabajar directamente en el servidor de desarrollo o en la red interna donde se encontrase ubicado dicho servidor. Se solicitó entonces que el servidor fuese instalado en las oficinas de la DAP, donde existían las facilidades de trabajo para llevar a cabo el desarrollo. Considerando todos los puntos anteriores, se le pidió a la DI un equipo con las siguientes características: Sistema Operativo Linux. Servidor Apache 2.0 PHP 5.0+ OCI8 Librerías de PHP de uso común tales como PEAR. URLs, usuarios y contraseñas de acceso a los servidores LDAP y a la base de datos en el ambiente de desarrollo. Además se pidió que las versiones de todos los servicios instalados fuesen en la medida de lo posible las mismas que después serían utilizadas en el ambiente de producción. 22

24 C. Toma de Requisitos Global Como se describió anteriormente, de las primeras reuniones con la DAP se estableció un entendimiento global del problema a solucionar y de las distintas etapas que existían durante el proceso de evaluación. Era entonces necesario profundizar en los aspectos del proceso que tendrían que ser desarrollados en la nueva aplicación. Lo primero que se debe comprender para abordar el problema es la lógica de la evaluación. Existen cerca de 40 unidades agrupadoras, entre ellas las distintas facultades y unidades administrativas de la UC. Cada una de estas unidades tiene una estructura de árbol con sub-unidades. Cada sub-unidad tiene funcionarios, un jefe y puede o no tener más sub-unidades. Una persona (funcionario) es evaluada por el jefe y dicha evaluación es revisada por algún superior del mismo funcionario. Por lo tanto, el primer punto importante a resolver era cómo se manejaría y/o obtendría la información de los funcionarios que participarían de la evaluación. Es decir, de todos los funcionarios UC, cuál sería el criterio para decidir si un funcionario participaba del proceso, cómo se obtendría esta información y cómo se sabría a que unidad pertenecía cada funcionario. Luego, sería necesario saber quién era el jefe y quién revisaría la evaluación de cada funcionario. El primer punto tendría una solución simple, ya que la DAP se encargaría de generar el listado de funcionarios que participarían del proceso. Sin embargo, el segundo punto presentaba un desafío mayor. En primera instancia se sugirió utilizar la información de los centros de costo de cada funcionario para generar un organigrama de cada unidad y así resolver el problema de identificación de los roles de los funcionarios. Luego, en función de este organigrama, asignar al jefe de cada funcionario. Sin embargo, se descubrió que esto no solucionaría el problema de identificación de roles necesario para el proceso de evaluación de desempeño. Aun cuando en la UC existe la información de cuál o cuáles son los centros de costo asociados a una persona y la jerarquía que existe entre los centros de costo, pudiendo así generar el árbol de centros de costo de la UC, esto no reflejaba la realidad laboral de la UC, ya que surgían los siguientes problemas: 23

25 Una persona podía ser pagada por más de un centro de costo, por ende no se podía determinar realmente a qué unidad pertenecía. Dos personas que trabajen en la misma sub-unidad podían ser pagadas por centros de costo distintos. Una persona podría desempeñar temporalmente labores en otra unidad agrupadora o subunidad y mantendría su centro de costo original. El jefe de una sub-unidad podría arbitrariamente crear una nueva sub-unidad dentro de su unidad y asignar personas a esta nueva sub-unidad, sin informarle previamente a la DAP y sin alterar los centros de costo de estos funcionarios. En consecuencia, estos problemas invalidan el uso de los centros de costo, ya que uno de los objetivos principales de la evaluación de desempeño es capturar la información relativa a la realidad laboral de los funcionarios UC. Más allá de quién pague el sueldo a una persona y la información administrativa del funcionario, tales como su cargo y descripción de cargo, lo que la DAP realmente busca es evaluar tomando en cuenta parámetros como a quién reconoce el funcionario como su jefe y cuál es la sub-unidad en la que él o ella reconoce que trabaja. Se comprendió finalmente que aunque la DAP entendía bien las necesidades propias del proceso como de la aplicación a diseñar, hasta la fecha no contaba con una manera real y certera de obtener esta información. Se asumió entonces la tarea de idear distintas maneras en las que se podría resolver este problema. En conjunto con la DAP, se idearon las siguientes alternativas para capturar la información necesaria: 1. Crear un sistema que permitiese a un jefe de unidad designar las unidades de las cuales era jefe y las personas que pertenecían a cada una de estas unidades. 2. Diseñar una aplicación gráfica que permitiese a funcionarios de la DAP crear los distintos organigramas de las unidades agrupadoras en terreno, creando unidades agrupadoras, sub-unidades y asignando personas a cada sub-unidad. 3. Delegar la información de la jerarquía a la DAP, esperando obtener para cada persona que participase en el proceso el RUT de su jefe y el RUT de su evaluador. 24

26 La primera alternativa presentaba una dificultad evidente: su avance dependía demasiado de la disposición de los jefes y potencialmente significaba capacitar y dar soporte a un universo de personas que probablemente retrasaría el proyecto. Por otro lado, la última alternativa era una tarea demasiado tediosa para la DAP y no aprovechaba el uso de la información ya disponible. Además, ya que la DAP llevaría a cabo a mano este proceso, sería demasiado propenso a errores e inconsistencias, considerando un universo estimado de 2000 funcionarios. Por consecuencia se escogió la segunda alternativa. La construcción de este organigrama por unidad sería entonces la primera parte y entregable del proyecto. Asumiendo que la información del organigrama se encontraría disponible, sería posible llevar a cabo la evaluación en línea de los funcionarios de la UC. Sería entonces necesario diseñar en una segunda etapa una aplicación que contuviese las distintas interfaces de captura de información del proceso de evaluación junto con la lógica asociada a esta captura de datos. Éste sería el segundo entregable del proyecto. 25

27 IV. Módulo Organigrama A. Requisitos del Módulo Toda persona en la UC posee tres características específicas en cuanto a su identificación en el sistema laboral: Un nivel, que puede ser 0 o un entero positivo; un tipo de cargo, que puede ser académico o administrativo y un contrato, que puede ser de plazo fijo o indefinido. El jefe de una unidad es el evaluador de todas las personas dentro de dicha unidad. Un académico nunca es evaluado pero si puede ser jefe de una unidad y por ende evaluador. Existen 4 tipos de formularios de evaluación: A, AS, B y C. A una persona le corresponde un único tipo de formulario que depende de su nivel, tipo de cargo y rol dentro de una unidad (tiene o no subalternos). Todos los funcionarios administrativos de plazo indefinido deben participar del proceso de evaluación, alguna otra combinación de tipo de cargo y tipo de contrato podría participar del proceso, pero no es obligatorio. Esta es la información relevante para poder iniciar el diseño del módulo organigrama. En función de todo lo anterior, el módulo de organigrama debía permitir modelar la estructura organizacional de las distintas unidades de la UC. Se llegó a la siguiente lista de requisitos que debería cumplir el módulo de creación de organigramas: 1. Requisitos Funcionales a. Crear Unidades Raíces: Ya que la UC se divide en 48 unidades agrupadoras, se deben poder crear estas unidades en el sistema para así estructurar los organigramas de la Universidad de acuerdo a la realidad de ésta. En el sistema, cada una de estas unidades de las que dependía un organigrama fueron llamadas Unidades Raíces. b. Crear sub-unidades dentro de las unidades raíces y luego dentro de las mismas subunidades. Esto permite crear una estructura de árbol propia en cada unidad raíz. c. Asignar funcionarios y/o académicos a las unidades: El sistema debe permitir asignar funcionarios y/o académicos, ya que cada uno de ellos puede cumplir un rol dentro del proceso. d. Elegir a los funcionarios y/o académicos de una lista pre-cargada: Los funcionarios o académicos que pueden ser seleccionados para ser parte de una unidad dentro del organigrama de una Unidad Raíz deben estar acotados por una lista pre-cargada, para así 26

28 poder saber cuál es el universo de personas que podrían participar del proceso y cuántas de ellas falta por asociar a alguna unidad. e. Asignar un jefe cada Unidad Raíz o sub-unidad. f. Asignar un revisor a cada persona evaluada. g. Asignar un tipo de formulario a cada persona evaluada. h. Cada Unidad Raíz debe tener una fecha de inicio y término del periodo de evaluación independiente de las demás Unidades Raíces. 2. Requisitos de Interfaces a. Proveer interfaces gráficas que agilicen el uso de la aplicación: La aplicación debe desplegar gráficamente el organigrama de una unidad, permitiendo así ver rápidamente cuáles son los jefes de las unidades, revisores y tipo de formulario de los evaluados, posibles sub-unidades y sus jefes. b. Desplegar alertas gráficas: Facilitar al usuario la detección de inconsistencias en los organigramas, como por ejemplo unidades sin jefe, evaluados sin revisor, administrativos de plazo indefinido sin asignar, etc. c. Arquitectura: Se debe desarrollar en ambiente web. Esto responde a que al ser una aplicación web, puede ser accedida desde cualquier ubicación de la UC, pudiendo así ir a terreno a la Unidades Raíces a construir los organigramas de manera rápida y precisa. 3. Requisitos de Restricción: a. Sólo puede ser revisor un funcionario que además es jefe: La aplicación debe dar a elegir como potenciales revisores sólo a personas que sean jefe de alguna unidad. b. El revisor de un funcionario debe pertenecer a la misma unidad raíz del funcionario. c. Sólo puede ser jefe de una unidad un funcionario que pertenezca a la unidad padre de dicha unidad: Si la unidad A tiene subunidades A1, A2 y A3, para que un funcionario pueda ser jefe de alguna de estas subunidades debe pertenecer a la unidad A. d. Un académico no es evaluado. e. Un académico no tiene revisor: No se debe generar una alerta producto de un académico sin revisor. 27

29 B. Diseño En la Fig. 1 se pueden ver los componentes principales del módulo de organigrama. Este consta de dos componentes principales. El primero, para el manejo de funcionarios, se utiliza para toda la información de estos, tales como la familia, el nivel, el cargo y los periodos de evaluación a los cuales se encuentran asociados. A través de este módulo se llega a una base consistente de trabajo para luego poder crear los organigramas. Una vez lista la base de funcionarios con la que se trabajará, se utilizan las Funciones de Árbol para llevar a cabo todas las tareas asociadas a la construcción de los organigramas. Principalmente se tiene funciones que recorren la estructura de árbol de manera recursiva, pudiendo así manipular los organigramas de manera simple. Fig. 1: Esquema Módulo Organigrama Se presenta a continuación en la Fig. 2, el modelo de datos del módulo de organigrama cumpliendo con los estándares de nombre de la UC: 28

30 Fig. 2: Modelo de datos módulo organigrama En el modelo de datos del módulo de organigrama se encuentran dos tablas en las que se apoya el resto del modelo. La tabla PERIODO contiene la información de los periodos en los cuales se realiza un proceso de evaluación. Esto quiere decir que un periodo de evaluación, compuesto de un año y un mes, representa la fecha de corte sobre la cual se realiza una evaluación. Por otra parte, la tabla PERS contiene la información corporativa de todas las personas que cumplen algún rol dentro de la UC. Con estas dos tablas como base, la tabla PERS_EVAL_PERIODO contiene a todas las personas que participan en un periodo de evaluación, siendo entonces la tupla (COD_PERS, COD_PERIODO) la llave primaria de la tabla. La persona es identificada por el COD_PERS que hace referencia a la tabla PERS y participa de un periodo de evaluación COD_PERIODO haciendo referencia a la tabla PERIODO. Se hace referencia también a la tabla PERS a través de COD_PERS_REVISOR, registrando el revisor de la persona en el periodo. Además, la tabla PERS_EVAL_PERIODO guarda la información del nivel, familia, cargo, contrato y tipo de cargo a las que pertenece la persona haciendo referencias a las tablas FAMILIA_PERS, CARGO_PERS, CONTRATO_PERS y TIPO_CARGO respectivamente para los últimos 4 atributos. Ya que entre periodos de evaluación estos atributos pueden cambiar para la misma persona, es necesario guardarlos en la aplicación y no se pueden obtener de la tabla corporativa 29

31 PERS. Dentro de la misma tabla PERS_EVAL_PERIODO se registra cuál es el tipo de formulario que usará la persona en el periodo de evaluación. Finalmente, a través del COD_UNIDAD_LABORAL, se registra la unidad laboral a la que pertenece a la persona en un periodo de evaluación. Por otra parte, se tiene la tabla UNIDAD_LABORAL donde se registra el grueso de los organigramas de la UC. Esta tabla tiene una referencia a sí misma a través de COD_UNIDAD_LABORAL_PADRE, permitiendo crear una estructura de árbol. Cada unidad laboral pertenece a un periodo a través de COD_PERIODO y un jefe a través de COD_PERS_JEFE. Además, las unidades laborales pueden ser de distintos tipos, los que se obtienen de TIPO_UNIDAD_LABORAL a través de COD_TIPO_UNIDAD_LABORAL. La tabla UNIDAD_LABORAL_EVAL_PERIODO hace referencia a UNIDAD_LABORAL, guardando la información de fechas del periodo de evaluación de las unidades laborales que además son Unidades Raíces. Finalmente, la tabla USER_DIRECCION_PERSONAL contiene los COD_PERS de las personas que pueden acceder a la aplicación. C. Implementación 1. Configuración Inicial Para poder crear los organigramas de las distintas unidades, es necesario crear un periodo de evaluación y asignar funcionarios a dicho periodo. Los funcionarios poseen un NIVEL, FAMILIA, CARGO, TIPO DE CARGO, TIPO DE CONTRATO. Para crear un nuevo periodo en el sistema, se construyó una interfaz que acepta un archivo de tipo CSV cuyo formato se puede ver en la Fig. 3. Se proporciona una interfaz simple (Fig. 4) para ingresar el archivo al sistema. 30

32 Fig. 3: Formato CSV Fig. 4: Interfaz de Creación de Periodos de Evaluación Como se explicó antes, el COD_PERS es un identificador único de la UC. El NIVEL es un valor numérico. Se fijaron valores para las opciones posibles en TIPO CARGO y TIPO CONTRATO debido a lo invariable de estos atributos y se construyó un administrador de CARGO y FAMILIA como se aprecia en las Fig. 5 y Fig. 6 para los cargos e Fig. 7 y Fig. 8 para las familias. 31

33 Fig. 5: Administrador de Cargos Fig. 6: Ingreso nuevo cargo 32

34 Fig. 7: Administrador de Familias Fig. 8: Ingreso nueva familia 2. Edición Unidades Raíces Una vez creado el nuevo periodo y asociados los funcionarios, es posible crear Unidades Raíces. Cada Unidad Raíz tiene asociadas seis fechas (Fig. 9) que son utilizadas durante el periodo de evaluación. Estas fechas deben ser estrictamente mayores entre sí. Es decir, debe haber al menos un día de diferencia entre cada una de ellas. Una vez creada la Unidad Raíz, se despliega como una carpeta a la que se puede acceder para construir su organigrama (Fig. 10). 33

35 Fig. 9: Interfaz de creación de una Unidad Raíz Fig. 10: Administrador de Unidades Raíces con una nueva unidad Una vez creada una Unidad Raíz como se muestra en la Fig. 11 es posible asignarle un jefe de entre todos los funcionarios asociados al periodo. Fig. 11: Asignación de jefes a Unidades Raíces 34

36 Asociado un jefe, se puede ingresar a la Unidad Raíz y comenzar a construir el organigrama completo de la unidad. Presionando sobre el ícono de la Unidad Raíz, se ingresa a una ventana con distintas funcionalidades, algunas generales a la Unidad Raíz y otras relativas a la subunidad en la cual el usuario se encuentra situado. Dentro de una Unidad Raíz, se presentan los íconos que permiten editar la unidad. Con estos íconos se puede (de izquierda a derecha): a) Editar las fechas de la Unidad Raíz. b) Asociar funcionarios a la una subunidad. c) Crear subunidades. d) Designar al jefe de cada subunidad. e) Asignar el revisor de cada funcionario en una subunidad. f) Editar el tipo de formulario asociado a cada funcionario en una subunidad. g) Ver una representación gráfica de la Unidad Raíz. h) Ver un resumen básico de la Unidad Raíz. i) Eliminar la Unidad Raíz. 3. Opciones Unidad Raíz A continuación se listan y explican las funcionalidades que aparecen en la Fig. 12: Fig. 12: Dentro de una Unidad Raíz. (a)editar Fechas de la Unidad. (b)asociación de Funcionarios. (c)edición de Subunidades. (d)asociación de Jefes. (e) Asignación de Revisores. (f)edición Tipos de Formulario. (g)ver imagen de la Unidad Raíz. (h)descargar Resumen. (i)eliminar la Unidad Raíz 35

37 a. Fechas de la Unidad Raíz: Es posible editar las fechas asociadas a una Unidad Raíz. La edición de las fechas también obliga a que cada fecha sea al menos un día después a la fecha anterior. Esta interfaz es similar a la mostrada en la Fig. 9. b. Creación de Subunidades: Al ingresar a una Unidad Raíz vacía, el usuario se encuentra en la raíz de la estructura de árbol de la unidad. Aquí, puede crear subunidades que dependen directamente de la raíz. La secuencia de figuras Fig. 13, Fig. 14 y Fig. 15 muestra el proceso de creación de subunidades. Fig. 13: Unidad Raíz sin subunidades Fig. 14: Interfaz de edición de subunidades 36

38 Fig. 15: Nuevas subunidades agregadas a la Unidad Raíz Una vez creadas las subunidades, es posible ingresar a una subunidad presionando sobre ésta. Dentro de una subunidad, se pueden crear nuevas subunidades, generando así la estructura de árbol del organigrama de la Unidad Raíz. La misma funcionalidad es usada para eliminar o crear nuevas subunidades dentro de una subunidad. La secuencia de figuras Fig. 16, Fig. 17 y Fig. 18 muestran la creación de subunidades dentro de una subunidad. Fig. 16: Unidad Raíz con subunidades 37

39 Fig. 17: Interfaz de edición de subunidades Fig. 18: Subunidades de primer nivel con subunidades de segundo nivel c. Asociación de Funcionarios: Dentro de una subunidad, es posible asignar funcionarios a ésta. Se puede obtener una lista de todos los funcionarios o bien pueden ser filtrados según tipo de cargos o tipo de contrato. Además, pueden ser ordenados por RUT o por apellido. La misma funcionalidad es usada para eliminar o asociar nuevos funcionarios dentro de una subunidad. Se puede ver el proceso de asociación de funcionarios a una unidad en las figuras Fig. 19, Fig. 20, Fig. 21 y Fig

40 Fig. 19: Subunidades sin funcionarios Fig. 20: Interfaz de asociación y edición de funcionarios en unidad 39

41 Fig. 21: Resumen funcionarios en subunidad Fig. 22: Subunidad con funcionarios asociados d. Jefes de Subunidad: Dentro de una unidad, es posible designar cuáles de sus funcionarios serán jefes de subunidades de la unidad. Esta misma interfaz puede ser utilizada para editar a los jefes de las subunidades. Se puede ver el proceso de asignación de jefes en las figuras Fig. 23, Fig. 24, Fig. 25 y Fig

42 Fig. 23: Subunidad con funcionarios y sin jefes Fig. 24: Interfaz de asignación de jefes Fig. 25: Jefes seleccionados para cada subunidad 41

43 Fig. 26: Unidad con jefes asignados a las subunidades Una vez asignado un jefe a una subunidad, no es posible eliminar de la unidad al funcionario que ahora es jefe, ya que generaría inconsistencias en los datos de la aplicación. e. Asociación de Revisores: Dentro de una subunidad, es posible asignar el revisor de cada funcionario. La lista de revisores (Fig. 27) se obtiene de todos los funcionarios que son jefes dentro de la Unidad Raíz. Fig. 27: Interfaz de asignación de revisores 42

44 Una vez que un funcionario tiene asignado un revisor, dicho funcionario cumple todas las condiciones lógicas impuestas sobre él. Por lo tanto, se remueve la alerta que aparece sobre los funcionarios (o jefes) que no tienen un revisor asignado. Esto se puede apreciar en la Fig. 28. Fig. 28: Funcionarios con Revisores f. Edición de Formularios: Cada funcionario asignado a una unidad tiene por omisión un tipo de formulario que se obtiene en función de su nivel. Si además el funcionario es jefe de una subunidad, internamente el sistema le asigna un tipo de formulario distinto. Este tipo de formulario puede ser editado (Fig. 29) por el creador del organigrama, asignándole a un funcionario y tipo de formulario distinto al que la aplicación le asignó. Fig. 29: Interfaz de asignación de formularios 43

45 g. Organigrama Gráfico: En cualquier momento, el usuario puede obtener una representación gráfica del organigrama. En dicha representación se verá el organigrama como árbol, con todas las subunidades y todas las personas asignadas a cada subunidad. Además, podrá ver quién es el jefe de cada unidad. Fig. 30: Ejemplo de organigrama completo Fig. 31: Representación gráfica de un organigrama Se puede ver en el organigrama gráfico que el jefe de cada subunidad se encuentra en la unidad que contiene a la subunidad. El jefe es replicado, apareciendo por claridad en la subunidad 44

46 de la que es jefe, pero en la realidad éste se encuentra sólo en la unidad superior. La Fig. 31 muestra el organigrama gráfico de la información existente en la Unidad Raíz de la Fig. 30. h. Resumen Básico: El usuario puede obtener un resumen de toda la Unidad Raíz, viendo quién es el jefe y revisor de cada funcionario y el formulario asociado a éste. i. Eliminar Unidad Raíz: Al eliminar una Unidad Raíz, recursivamente todas las personas que se encuentran en ésta son liberadas de sus subunidades, los funcionarios que eran jefes dejan de serlo y todo funcionario deja de tener un revisor asociado a él. 4. Validación de un Organigrama A medida que se va creando un organigrama (agregando subunidades, asociación de funcionarios, jefes y revisores a éstas) la aplicación permite rápidamente visualizar la correctitud del trabajo realizado. Dentro de la lógica del proceso de evaluación, se espera que toda unidad tenga un jefe. Además, las unidades deben tener al menos un funcionario dentro de ellas y los funcionarios deben tener asociados un revisor. Bajo esta lógica, a medida que se van completando los pasos necesarios para obtener unidades con estas características, el color que representa a una unidad va cambiando. Al crear una unidad (Computación), como se puede ver en la Fig. 32, ésta aparece de color rojo, ya que no cumple ninguno de los requisitos anteriores más allá de existir. Fig. 32: Unidad Raíz con funcionarios y una subunidad 45

47 Si a la unidad se le asigna un jefe como en la Fig. 34, o se le asignan funcionarios como en la Fig. 33, ésta se mantiene de color rojo, ya que sigue siendo un estado inválido para la unidad. Si se ejecutan ambas acciones, asignar un jefe y asociar funcionarios a la unidad, pasa a color amarillo como se puede ver en la Fig. 35. Aunque este estado no es completamente correcto, es posible que algunos o todos los funcionarios de la unidad no posean revisor. De esa forma se alerta de alguna manera la situación, distinguiéndola sin embargo del estado anterior donde la unidad es de color rojo. Fig. 33: Subunidad con funcionarios y sin jefe Fig. 34: Subunidad con jefe y sin funcionarios 46

48 Fig. 35: Subunidad con jefe y funcionarios Finalmente, si todos los funcionarios de la unidad tienen un revisor (Fig. 36), la unidad pasa a ser de color verde. Fig. 36: Subunidad sin inconsistencias Raíces. De esta manera es fácil detectar inconsistencias en los organigramas de las Unidades 47

49 5. Transición entre Periodos Al crear un nuevo periodo, se implementó la siguiente lógica para reutilizar la información del periodo anterior. 1. Todos los organigramas que existían en el periodo anterior son replicados. 2. Todos los funcionarios del periodo anterior que se encuentran en el nuevo periodo son asignados a la misma subunidad a la que se encontraban asignados en el periodo anterior. Poseen también el mismo tipo de formulario y poseen el mismo jefe y revisor, siempre y cuando éstos participen del nuevo periodo de evaluación. 3. Todos los funcionarios del periodo anterior que no se encuentran en el nuevo periodo se encuentran disponibles para ser asignados en alguna subunidad. 4. Todos los funcionarios del periodo anterior que no se encuentran en el nuevo periodo son excluidos del proceso. 48

50 V. Módulo Evaluación A. Requisitos del Módulo Los funcionarios que participan del proceso de evaluación pueden cumplir uno de tres roles no excluyentes entre sí: puede ser evaluado, evaluador o revisor. En la Fig. 37 se puede ver el flujo esperado en el sistema a construir para el proceso de evaluación para cada uno de los roles y su interacción entre ellos. Fig. 37: Modelo del Proceso de Evaluación Independientemente de su rol, todo funcionario ingresa al principio al sistema utilizando su correo y contraseña UC. Una vez que la persona es autenticada, se determina cuántos roles cumple. Un funcionario siempre tendrá el rol de evaluado ya que siempre podrá autoevaluarse. El flujo más simple es el de autoevaluación. Un funcionario que desea autoevaluarse ingresa al sistema, llena su autoevaluación y cierra así el flujo de autoevaluación. El flujo más 49

51 completo y que entrega la mayor información a la DAP es el que involucra a los tres roles. Este flujo comienza con el evaluador, quien una vez dentro del sistema escoge a un evaluado. Una vez seleccionado el evaluado, completa la evaluación de éste. Una vez finalizada la evaluación, guarda y notifica al revisor. El revisor es notificado a través de un correo electrónico. El revisor ingresa al sistema y examina la labor realizada por el evaluador. Si está de acuerdo con ésta, firma y acepta la evaluación. De lo contrario, rechaza la evaluación. En ambos casos, el revisor es notificado vía correo electrónico. Si la evaluación no es aceptada, el evaluador debe revisar su evaluación hasta llegar a acuerdo con el revisor. Una vez que el revisor aprueba la evaluación, el evaluador puede realizar una entrevista con el evaluado. Una vez realizada la entrevista, el evaluador es notificado vía correo electrónico. El evaluado puede entonces ingresar comentarios a su evaluación. Al ingresar los comentarios el evaluado puede aceptar o rechazar la labor realizada en su proceso de evaluación. El ingreso de estos comentarios finaliza el proceso de evaluación del evaluado. Tomando en cuenta lo anterior, los requisitos del módulo de evaluación son los siguientes: 1. Funcionales a. Los funcionarios deben poder ingresar al sistema utilizando su usuario y contraseña UC: Todo funcionario UC posee un correo electrónico que es usado para integrar el acceso a todos los sistemas UC. La aplicación debe integrarse con los sistemas de autenticación por LDAP de la Universidad para así evitar replicar y distribuir contraseñas de acceso a los funcionarios. b. Deben existir distintos tipos de formularios: Ya que en el módulo de organigrama se pueden asociar distintos tipos de formularios, deben existir estos tipos al momento de evaluar a un funcionario. c. Los funcionarios deben poder autoevaluarse: Un funcionario debe poder llenar el mismo formulario utilizado para su evaluador durante la evaluación, evaluándose a sí mismo. d. Los jefes deben poder evaluar a sus subalternos: Se debe construir la funcionalidad que permita evaluar a los subalternos de cada jefe, desplegando el tipo de formulario que corresponda a cada funcionario. 50

52 e. Los revisores deben poder revisar a los funcionarios que correspondan: Cada revisor, debe poder ver la evaluación realizada por el un jefe respecto del funcionario a revisar e ingresar comentarios a la evaluación. f. Evaluadores, Revisores y Evaluados deben recibir alertas por correo electrónico: Cada vez que un funcionario pueda completar alguna acción en alguno de los roles que tenga asociado, deberá recibir una alerta por correo electrónico notificando la posibilidad de completar esta acción. g. Los formularios se deben construir dinámicamente: Los formularios se componen de dos partes. La primera, un conjunto de preguntas denominadas 'Preguntas de Competencia' y una segunda parte de preguntas libres de distintos tipos. Los formularios se deben construir de tal manera que sean fáciles de modificar entre periodos de evaluación. 2. Arquitectura a. Se debe desarrollar en ambiente web: Debe ser una aplicación web, accesible desde cualquier ubicación de la UC, facilitando así el uso de la herramienta. 3. Restricción a. Al ingresar al sistema, los usuarios sólo deben poder ingresar a las funcionalidades asociadas a ellos: En el módulo de organigrama, cada funcionario es asociado a distintos roles, tales como revisor y evaluador. Al ingresar al sistema, solo podrán cumplir los roles que tienen asignados, evaluando y/o revisando sólo a los funcionarios que tenga asociados en cada rol en el organigrama que corresponda. b. Un académico no es evaluado. c. Un académico no es revisado. d. Cierre de Formularios: Una vez cerrado un formulario, ya sea de evaluación, autoevaluación, revisión, etc., éste no podrá volver a ser editado. 51

53 B. Diseño El módulo de evaluación se puede separar en dos componentes utilizados por el módulo. Como se puede ver en la Fig. 38, estos componentes se separan en el manejo de formularios y la lógica de evaluación. El módulo, utilizando el componente de la lógica de evaluación, obtiene información respecto del rol que cumple una persona al ingresar al sistema, en función de las variables de tiempo y acciones ya realizadas en el sistema. De esta manera, el módulo central maneja el flujo de acciones realizadas. Una vez obtenida toda la información necesaria respecto de la lógica del proceso, se utiliza el componente de formularios. A través de este componente, dado un tipo de formulario y estado en la evaluación, internamente se realiza la construcción del formulario el cual es posteriormente dibujado en el navegador del usuario. Cuando la información del formulario es enviada de vuelta al servidor, el mismo componente se ocupa de guardar los datos, reusando la funcionalidad de la construcción para validar la correctitud de los datos. Fig. 38: Esquema del Módulo de Evaluación Se muestra a continuación en la Fig. 39 el modelo de datos del módulo de evaluación con las tablas del módulo de organigrama a las que se hace referencia: 52

54 Fig. 39: Modelo de Datos Módulo Evaluación El módulo de evaluación contiene toda la información relativa a los formularios usados en las distintas etapas del proceso de evaluación. Como se vio en el módulo de organigrama, cada persona en PERS_EVAL_PERIODO tiene un tipo de formulario almacenado en la tabla TIPO_FORMULARIO. Cada formulario puede ser construido dinámicamente, almacenando las preguntas que pertenecen a un formulario en un periodo en la tabla FORMULARIO. La tabla FORMULARIO tiene como llave primaria la tupla (COD_TIPO_FORMULARIO, COD_PERIODO, COD_TIPO_PREGUNTA, POS), haciendo referencia respectivamente a las tablas TIPO_FORMULARIO, PERIODO, TIPO_PREGUNTA y la última llave POS sin referencia. Para un tipo de formulario en un periodo y en una posición para las preguntas, puede haber un único tipo de pregunta y por ende una única pregunta en dicha posición. La tabla TIPO_PREGUNTA contiene todas preguntas y marcadores necesarios para construir dinámicamente un formulario. 53

55 Dentro de la tabla TIPO_PREGUNTA se encuentran los siguientes valores: a. DIMENSIONES b. PREGUNTA SIMPLE c. PREGUNTA CHECKBOX d. PREGUNTA SIMPLE SELECT e. PREGUNTA SELECT RADIO f. TITULO g. SEPARADOR Los primeros 5 valores son preguntas, mientras que los últimos 2 son herramientas de formato. Así, cada uno de los valores que representan preguntas tiene un conjunto de tablas asociadas que contienen la información pertinente a ese tipo de pregunta, tanto para el despliegue de éstas como para guardar las respuestas a cada una de ellas en cada formulario. 1. DIMENSIONES Fig. 40: Pregunta de Dimensiones En la tabla PREGUNTA_DIM_COMP se almacenan todas las preguntas de dimensiones. En cada periodo, para cada tipo de formulario existe un único conjunto de preguntas de 54

56 dimensiones. La llave primaria de la tabla es (COD_TIPO_FORMULARIO, COD_PERIODO, COD_COMPETENCIA, COD_DIMENSION, POS), haciendo referencia a las tablas TIPO_FORMULARIO, PERIODO, COMPETENCIA y DIMENSION respectivamente y POS denota el orden de las competencias dentro de una misma dimensión. Cada pregunta de DIMENSION posee un ENUNCIADO y cinco definiciones almacenadas de TEXT_DEF_1 a TEXT_DEF_5. Las tablas DIMENSION y COMPENTECIA son tablas de dominio que guardan todas las dimensiones y competencias disponibles en la aplicación. Finalmente, la tabla RESPUESTA_DIM_COMP guarda las respuestas asociadas a este tipo de pregunta. Para un periodo COD_PERIODO, dimensión COD_DIMENSION y competencia COD_COMPETENCIA, se guarda el resultado VALOR otorgado a un evaluador COD_PERS por un evaluador COD_PERS_EVALUADOR. En el caso de las autoevaluaciones, COD_PERS y COD_PERS_EVALUADOR almacenan el mismo valor. 2. PREGUNTA SIMPLE Fig. 41: Pregunta Simple En la tabla PREGUNTA_SIMPLE se almacenan todas las preguntas que contienen un enunciado y una respuesta de texto libre. Así, PREGUNTA_SIMPLE tiene como llave primaria COD_PREGUNTA_SIMPLE. El enunciado de la pregunta se guarda en ENUNCIADO. En la tabla RESPUESTA_SIMPLE para un evaluado COD_PERS, un evaluador COD_PERS_EVALUADOR registra una respuesta RESPUESTA a una pregunta de este tipo la que se identifica haciendo referencia a PREGUNTA_SIMPLE a través de COD_PREGUNTA_SIMPLE. En el caso de las autoevaluaciones, COD_PERS y COD_PERS_EVALUADOR almacenan el mismo valor. 55

57 3. PREGUNTA CHECKBOX Fig. 42: Pregunta Checkbox En la tabla PREGUNTA_CHECKBOX se almacenan todas las preguntas que contienen un enunciado y un conjunto de alternativas no excluyentes entre sí. Además, la pregunta puede contener un sub-enunciado donde se ingresa una respuesta de texto libre. Cada pregunta es identificada por COD_PREGUNTA_SIMPLE. El campo CANTIDAD denota el número máximo de opciones que se pueden seleccionar como respuesta. ENUNCIADO guarda el enunciado base de la pregunta mientras que ENUNCIADO_OTRO guarda el sub-enunciado que tiene como respuesta texto libre. De haber un valor en ENUNCIADO_OTRO se despliega este sub-enunciado y el área de respuesta. Si el valor de ENUNCIADO_OTRO es nulo, no se despliega esta segunda parte de la pregunta. Finalmente, COLUMNA registra de a cuántas columnas deben ser desplegadas las opciones de la pregunta. Por otra parte, la tabla OPC_CHECKBOX contiene todas las opciones que puede tener asociada una PREGUNTA CHECKBOX. La asociación entre opción y pregunta se hace a través de la referencia COD_PREGUNTA_CHECKBOX a la tabla PREGUNTA_CHECKBOX. 56

58 La tabla RESPUESTA_CHECKBOX guarda todas las opciones COD_OPC_CHECKBOX marcadas en la pregunta COD_PREGUNTA_CHECKBOX por un evaluador COD_PERS_EVALUADOR para un evaluado COD_PERS. En el caso de las autoevaluaciones, COD_PERS y COD_PERS_EVALUADOR almacenan el mismo valor. De existir un enunciado RESPUESTA_OTRO, cualquier respuesta dicho enunciado es almacenada en la tabla RESPUESTA_OTRO. 4. PREGUNTA SIMPLE SELECT Fig. 43: Pregunta Simple Select En la tabla PREGUNTA_SIMPLE_SELECT se almacenan todas las preguntas que contienen un enunciado, un conjunto de alternativas excluyentes entre sí y un campo de respuesta de texto libre. Una pregunta SIMPLE SELECT se identifica por la llave primaria COD_PREGUNTA_SIMPLE_SELECT, posee un enunciado ENUNCIADO y un enunciado ENUNCIADO_SELECT para las opciones excluyentes. Por otra parte la tabla OPC_SIMPLE_SELECT contiene todas las opciones COD_OPC_SIMPLE_SELECT que pueden ir asociadas a una PREGUNTA SIMPLE SELECT. La asociación entre opción y pregunta se hace a través de la referencia COD_PREGUNTA_SIMPLE_SELECT a la tabla PREGUNTA_SIMPLE_SELECT. La tabla RESPUESTA_SIMPLE_SELECT guarda la opción COD_OPC_SIMPLE_SELECT y la respuesta RESPUESTA a la pregunta COD_PREGUNTA_SIMPLE_SELECT asignada por un evaluador COD_PERS_EVALUADOR a un evaluado COD_PERS. En el caso de las autoevaluaciones, COD_PERS y COD_PERS_EVALUADOR almacenan el mismo valor. 57

59 5. PREGUNTA SELECT RADIO Fig. 44: Pregunta Select Radio En la tabla PREGUNTA_SELECT_RADIO se almacenan todas las preguntas que contienen una lista de sub-preguntas compuestas de un conjunto de alternativas excluyentes entre sí y un segundo conjunto de alternativas excluyentes entre sí asociadas al primer conjunto de alternativas. Además, una pregunta SELECT RADIO podría tener un sub-enunciado ENUNCIADO_OTRO, con un comportamiento similar al ENUNCIADO_OTRO de la pregunta CHECKBOX. Las opciones del primer conjunto de alternativas se almacenan en la tabla OPC_SELECT_RADIO_SELECT y la asociación con la pregunta se hace a través de la referencia COD_PREGUNTA_SELECT_RADIO a la tabla PREGUNTA_SELECT_RADIO. Las opciones del segundo conjunto de alternativas se almacenan en la tabla OPC_SELECT_RADIO_RADIO y la asociación con la pregunta se hace a través de la referencia COD_PREGUNTA_SELECT_RADIO a la tabla PREGUNTA_SELECT_RADIO. En la tabla RESPUESTA_SELECT_RADIO se guarda las respuestas a los conjuntos de alternativas en el campo COD_OPC_SELECT_RADIO_SELECT para el primer conjunto de opciones excluyentes y en el campo COD_OPC_SELECT_RADIO_RADIO para el segundo conjunto de opciones excluyentes para un evaluado COD_PERS, asignado por un evaluador COD_PERS_EVALUADOR para una pregunta COD_PREGUNTA_SELECT_RADIO. 58

60 6. TITULO Fig. 45: Títulos La tabla TITULO almacena un texto NOM_TITULO. Además, se almacena un texto ESTILO que debe ser un conjunto valido de opciones de estilo CSS. El texto NOM_TITULO se despliega en el formulario con un estilo en línea ESTILO. 7. SEPARADOR Fig. 46: Separador Al introducir separadores entre las preguntas de un formulario, el formulario se despliega en distintas páginas, obteniendo una navegación a través del formulario con botones que permiten avanzar o retroceder entre las páginas del formulario. 59

61 C. Implementación 1. Ingreso al Sistema El módulo de evaluación se presenta al usuario con una interfaz de acceso al sistema como la de Fig. 47, integrado con los sistemas de autentificación LDAP de la UC. Fig. 47: Ingreso al sistema de evaluación Una vez que el funcionario entra al sistema, se despliega la ventana principal donde se despliegan todos los roles que tiene asignada la persona. La Fig. 48 muestra a un usuario que posee todos los roles disponibles en el sistema. Fig. 48: Roles 2. Interfaz del Evaluado Al ingresar a la interfaz del evaluado, se ven todas las funciones a las cuales éste tiene acceso. Inicialmente, como se muestra en la Fig. 49, el evaluado sólo puede acceder a su autoevaluación, ya que no se han completado todos los pasos necesarios para que el evaluado pueda ingresar comentarios a su evaluación. 60

62 Fig. 49: Interfaz del Evaluado 3. Interfaz del Evaluador Al ingresar con el rol de evaluador, se despliega una lista (Fig. 50) de todas las personas a las que se puede evaluar. En la misma interfaz donde se despliega la lista de funcionarios a evaluar, se obtiene un resumen del estado de cada funcionario, informando con iconos si la evaluación, revisión y entrevista han sido realizadas. Además, en cada funcionario donde se puede efectuar alguna acción, aparece una alerta informativa. Fig. 50: Listado de Evaluados 61

63 Una vez elegido un funcionario a evaluar, se despliega una ventana que entrega información acerca del evaluado, tales como su cargo, nivel y tipo de formulario. Inicialmente el evaluador sólo puede ingresar al Formulario de Evaluación como se muestra en la Fig. 51. Fig. 51: Interfaz del Evaluador Si el evaluador lleva a cabo la evaluación, quedará deshabilitada la opción de Formulario de Evaluación y deberá esperar a que el revisor efectúe la revisión para que la opción de ENTREVISTA se encuentre habilitada. 4. Interfaz del Revisor Al ingresar con el rol de revisor, se despliega una lista de personas (Fig. 52) a revisar, similar a la lista de funcionarios a evaluar del evaluador, informando quiénes de ellos pueden ser revisados y quiénes ya lo fueron. 62

64 Fig. 52: Listado de Evaluados Una vez elegida una persona a revisar, se despliega una ventana (Fig. 53) de resumen con la información del evaluado y la opción de ingresar a la interfaz de revisión, donde se despliega el formulario de evaluación con las respuestas ingresadas por el evaluador. Fig. 53: Interfaz del Revisor 5. Entrevista Una vez que el revisor ha aprobado la evaluación, se habilita en las opciones del evaluador la opción de entrevistar, como se aprecia en la Fig

65 Fig. 54: Interfaz del Evaluador Completada la entrevista, se deshabilita la opción de entrevistar (Fig. 55). El evaluado es notificado vía correo electrónico que puede ingresar comentarios a su evaluación. Fig. 55: Interfaz del Evaluador 64

66 6. Comentarios Finalizada la Entrevista, el evaluado, al ingresar a su interfaz como se muestra en la Fig. 49, tiene habilitada la opción de realizar comentarios a su entrevista con el botón 'Aceptar o Rechazar mi Evaluación' y puede ver su evaluación con 'Ver Mi Evaluación'. Fig. 56: Interfaz del Evaluado Una vez que el evaluado completa su evaluación, la opción queda deshabilitada (Fig. 57), finalizando así el proceso de evaluación de este evaluado en particular. Fig. 57: Interfaz del Evaluado 65

67 7. Formularios Los formularios de Evaluación, Revisión, Entrevista y Comentarios, se presentan en los Anexo A, B, C y D. 8. Transición entre Periodos Al crear un nuevo periodo de evaluación como se explica en el ítem Configuración Inicial, Capítulo IV.C.1, todas las preguntas asociadas a los tipos de formularios en el periodo anterior son copiadas al nuevo periodo recién creado, para así poder reutilizar la información del periodo anterior si no se desea realizar modificación al formato y contenido de las evaluaciones. 66

68 VI. Resultados Obtenidos Esta aplicación ha entregado resultados a sus usuarios en distintos ámbitos. Más allá del simple resultado evidente de la evaluación que son los datos de respuesta de cada uno de los formularios para cada evaluado o autoevaluado, se obtuvieron resultados en los siguientes ámbitos: Definición del Problema: Todo el desarrollo de la aplicación dejó como resultado que todos los gestores del Proceso de Evaluación de Desempeño en la DAP aclararan el correcto funcionamiento del mismo y las relaciones e interacciones entre los distintos actores (Evaluadores, Evaluados y Revisores). También se detectaron fallas ocurridas en ejecuciones anteriores del proceso, independiente del medio en el que se realizaba. Quedó clara también la importancia del organigrama laboral desarrollado en la primera etapa del proyecto, y la utilidad de éste no sólo para esta aplicación, sino también para cualquier proceso de toma de decisiones que requiera constatar la realidad laboral de un funcionario o unidad en la UC. Ahorro de Recursos: El traspaso del Proceso de Evaluación de un formato escrito en papel a interfaces WEB permite ahorrar en todo lo que significa diseñar e imprimir los distintos tipos de formularios asociados a las evaluaciones. Además, dado el diseño propio de la aplicación, efectuar cambios sobre el formato y contenido del proceso es más fácil, lo que permite que menos personas puedan gestionar el mismo proceso que antes involucraba a más funcionarios de la DAP. Tiempo de Ejecución: Dado que la nueva implementación evita la necesidad de digitalizar los datos una vez finalizado el proceso, se reduce considerablemente el tiempo de ejecución del mismo. En el momento en que éste se da por finalizado, todos los datos se encuentran disponibles para ser extraídos y procesados para la generación de reportes, análisis de resultados y toma de decisiones. Gestión: Ya que la totalidad del proceso sucede en línea, la información que ha sido ingresada hasta algún instante de tiempo puede ser accedida y procesada de forma instantánea. Esto permite obtener información del estado del proceso como cantidad de funcionarios evaluados, revisados y/o entrevistados, pudiendo así no sólo obtener la información de evaluación del proceso, sino también información respecto del desarrollo del mismo. La detección de 67

69 anomalías en el proceso, tales como detenciones en el flujo de evaluación de un funcionario o subunidad son una posibilidad real en el transcurso del mismo. Estas situaciones pueden además ser corregidas durante el proceso, ya que la información ahora existe, a diferencia de la implementación anterior donde sólo se obtenía el resultado de los formularios y se perdía la información intrínseca del proceso. Calidad de los Datos: Al ser ingresados de forma digital directamente por los funcionarios, los datos son mucho menos propensos a contener errores. Así, estos datos serán de mejor calidad que los datos digitalizados desde los cuestionarios en papel, ya que no hay errores de transcripción, pérdida de formularios e ilegibilidad de comentarios escritos. Flexibilidad: Ya que la construcción de los formularios es dinámica, no sólo fue posible realizar cambios a los formularios durante el presente periodo de evaluación, también será posible generar cambios que reflejen las conclusiones obtenidas del análisis de los datos del proceso. Resultados del Proceso: Por supuesto, se obtiene como resultado del trabajo las respuestas a los formularios de evaluación para los funcionarios evaluados durante el proceso. 68

70 VII. Conclusiones y Trabajo a Futuro El proceso de evaluación no se ha completado en su totalidad y el funcionamiento de la aplicación en la DAP fue catalogado de excelente. Durante la operación del proceso se obtuvo en su mayor parte felicitaciones por la facilidad de uso de la aplicación en contraste con la implementación en papel. El desarrollo de la aplicación presentó dos grandes desafíos. El primero fue sin duda lograr obtener todos los requisitos necesarios para implementar de manera correcta la aplicación. Muchas veces la toma de decisiones con respecto a lo que se quería o debía hacer no pasaba por toda la jerarquía de la DAP, lo que produjo más de un cambio en lo que se esperaba de la aplicación. Sin duda habría sido provechoso concertar una mayor cantidad de reuniones con los administrativos que ostentaban mayor poder de decisión, para así haber validado los requisitos obtenidos y las decisiones que se iban tomando a medida que surgían dudas en el proyecto. El segundo desafío tuvo relación con el poco dinamismo en cuanto a la toma de decisiones en la Dirección de Informática, ya que toda necesidad o decisión técnica pasa por esta área de la Universidad y no era siempre posible saber qué cosas serían o no posibles de realizar y cuáles serían los tiempos que tomarían tareas que tenían alguna interacción con la DI. Una mejor estrategia habría sido, en conjunto con el punto anterior, haber determinado con anterioridad en el proyecto qué requisitos tendrían que ser satisfechos por la DI, para así resolver estas necesidades con mayor anticipación, eliminando así incertidumbres en el desarrollo del proyecto. A pesar de esto, los objetivos planteados al inicio del proyecto se cumplen a cabalidad. Se completó el desarrollo de la aplicación que permite a los funcionarios asociados al proceso de evaluación completar sus evaluaciones en línea, se redujeron los tiempos necesarios para llevar a cabo este proceso y la información se encontró disponible para su análisis apenas finalizó el proceso. Además, la creación de la aplicación creó nuevas inquietudes y necesidades en torno al Proceso de Evaluación de Desempeño. 69

71 En función del trabajo realizado, se plantean las siguientes extensiones al trabajo realizado que agregarían gran valor a la solución: 1. Sería muy beneficioso si se desarrollase un módulo de reportes que permitiese a los funcionarios de la DAP obtener de manera simple información de los datos obtenidos en cada proceso. Un módulo de reportes que contase con las opciones para que la información entregada pueda ser resumida según filtros relevantes tales como por rangos de fechas, por agrupación por unidades con todas las opciones que permite la estructura de datos de árbol de los organigramas, por jefes, por revisores, etc., permitiría obtener de manera rápida respuestas a preguntas importantes al momento de tomar decisiones o resolver conflictos laborales en las unidades de la Universidad. 2. Después del proceso de desarrollo e implementación de la aplicación, los encargados del Proceso de Evaluación de Desempeño en la DAP han tomando el peso del potencial que posee la aplicación en cuanto a la información que puede entregar con respecto al estado mismo del proceso. La creación, por lo tanto, de una interfaz para administradores que entregase índices e información detallada del funcionamiento del proceso mientras que éste se está llevando a cabo sería altamente relevante. Así, se tendría una herramienta adicional para garantizar que los tiempos en los cuales se debe evaluar, revisar o entrevistar se cumplan a cabalidad, detectando retrasos o problemas con anticipación y encontrando una solución a éstos antes de que finalice el periodo de evaluación. 3. Se debería extender el módulo de organigrama de tal manera que fuese una herramienta UC donde cada funcionario pudiese ingresar a ella y ejecutar acciones de acuerdo al rol que cumple dentro de la Universidad. Así, un funcionario podría ingresar a la herramienta y ver cuál es su realidad laboral ante la DAP y solicitar correcciones de ser necesario; un jefe podría mantener su unidad y la integridad de ésta, designando jefes, creando subunidades cuando sea necesario o ingresando funcionarios que se encontraban en otra unidad. De esta manera, la información manejada por la DAP en cuanto a realidad laboral sería precisa y la labor de mantenerla así estaría distribuida entre muchas personas, alivianando así la carga total en pequeñas tareas desarrolladas por cada jefe. 70

72 4. Se deberían construir mantenedores para los formularios y tipos de preguntas de manera que éstas puedan ser construidas por los funcionarios de la DAP. De esta manera, tendrían un mayor control sobre los tiempos necesarios para organizar el proceso de evaluación al depender un poco menos de la Dirección de Informática. 5. Se debería estudiar qué otros proyectos o flujos de información se complementan con el proceso de evaluación, de manera que éstos puedan ser integrados. 71

73 VIII. Bibliografía y Referencias 1. Using MVC Pattern in Web Interactions. [En línea] Agosto de PHP: Hypertext Preprocesor. [En línea] Agosto de Java. [En línea] Marzo de Python Programming Languaje. [En línea] Agosto de JCC's SQL Standards Page. [En línea] Agosto de MySQL: The world's most popular open source database. [En línea] 2009 de Agosto PostgreSQL: The world's most advanced open source database. [En línea] Agosto de Microsoft SQL Server. [En línea] Agosto de HTML 4.01 Speci. [En línea] Diciembre de Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Speci. [En línea] Abril de ECMAScript Languaje Specication. [En línea] 2009 de Abril CakePHP: the rapid development php framework. [En línea] Julio de CodeIgniter Open Source PHP web application development. [En línea] Agosto de Symfony PHP Web Framework. [En línea] Agosto de Ajax: A New Approach to Web Applications. [En línea] Agosto de Open Web Application Security Project. [En línea] Agosto de Web Application Security Consortium. [En línea] Agosto de SQL Injection Attacks by Example. [En línea] Octubre de Writing Secure Web Applications. [En línea] Marzo de

74 20. Xdebug Debugger and Profiler Tool for PHP. [En línea] Marzo de DGB PHP Debugger and Profiler. [En línea] Agosto de PHP HOW-TO: Debugging PHP. [En línea] Agosto de Acid3 Browser Test. [En línea] Agosto de Firebug. [En línea] Agosto de Web Developer. [En línea] Agosto de PEAR Excel Spread Sheet Writer. [En línea] Junio de Google Trends: PHP Frameworks. [En línea] Agosto de Design Patterns in Web Programming. [En línea] Marzo de

75 IX. Anexos A. Formulario Evaluación Se muestra a continuación el formulario de evaluación llenado por el evaluador: 74

76 75

77 76

78 B. Formulario de Revisión Se muestra a continuación el formulario que ve el revisor junto con las respuestas ingresadas por el evaluador, además de un cuadro de comentarios a llenar por el revisor al final del formulario: 77

79 78

80 79

81 80

82 C. Formulario Entrevista Se muestra a continuación el formulario que ve el evaluador en la entrevista, con las respuestas ingresadas por el mismo en la evaluación, los comentarios del revisor y un cuadro al final del formulario para registrar lo acontecido en la entrevista: 81

83 82

84 83

85 84

86 D. Formulario Comentarios Se muestra a continuación el formulario que ve el evaluado al ingresar comentarios a su evaluación. Se ven las respuestas ingresadas por el evaluador en la evaluación y en la entrevista. Al final de éste se encuentran preguntas de comentarios a ingresar por el evaluado: 85

87 86

88 87

89 88

90 89