UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FSICAS Y MATEMTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACIN

DESARROLLO DE UN SISTEMA DE APOYO A LA GESTIN DE FONDOS DE INVESTIGACIN UNIVERSITARIOS

MEMORIA PARA OPTAR AL TTULO DE INGENIERO CIVIL EN COMPUTACIN

DIEGO SCHMITT RIVERA

PROFESOR GUA: NELSON BALOIAN TATARYAN Y JOS PINO URTUBIA

MIEMBROS DE LA COMISIN: GONZALO NAVARRO BADINO

SANTIAGO DE CHILE ENERO 2013

ii

Resumen
En el ao 2011 se implement un sitio Web llamado

U-Papers

que se encargaba de alma-

cenar y consultar publicaciones cientcas del Departamento de Ciencias de la Computacin (D.C.C.) de la Universidad de Chile. Con la ayuda de este sitio, la administracin del Departamento asignaba Fondos de Investigacin Individual (FII) a los acdemicos que realizaban publicaciones. Luego los acadmicos podan usar estos fondos para realizar futuras investigaciones. La administracin del D.C.C. percibi la necesidad de administrar correctamente esta asignacin. El mtodo que se usaba sufra problemas de prdida de informacin y ste tena un acceso muy limitado. Adems en la administracin se distribua la informacin en distintos registros y podan tener diferencias entre s. Para solucionar estos problemas se implement un sistema de informacin administrativa. Este sistema se encarg de gestionar los ujos de trabajo (workow) y de centralizar la informacin distribuida. Con la ayuda de la notacin B.P.M.N. (Business Process Management Notation) se denieron dos procesos principales. Tambin ayud a encontrar los casos de uso y los casos excepcionales que se presentaban en los procesos. Como sistema administrador de workow se utiliz una aplicacin llamada Joget Workow. Esta aplicacin es de fuente abierta (open source), cuenta con muchas ventajas de un sistema de workow y con facilidades para adaptar los procesos de negocio. Como resultado nal, se construy un sitio Web llamado

U-Fondos

que pudo funcionar en un servidor del D.C.C. y

distribuir la informacin de forma remota. El desarrollo fue dividido en varias entregas incrementales. En cada una se implementaron prototipos del sitio y se realizaron pruebas de usabilidad para encontrar los principales errores. Tambin se pudo descubrir el inters y la opinin de los usuarios respecto a la distribucin de este tipo de informacin.

iii

iv

Dedicado a mi familia que me apoy desde el principio y mostr ms preocupacin que yo para que terminara este proyecto.

vi

Tabla de contenido
Introduccin
Motivacin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objetivo General Objetivos Especcos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1
2 2 3

1. Marco Conceptual
1.1. 1.2. 1.3. 1.4. 1.5. 1.6. Conceptos Bsicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Desarrollo Incremental Arquitectura Cliente-Servidor

4
4 4 5 6 8 9

Conceptos de Workow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conceptos de Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluacin de Usabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2. Metodologa 3. Anlisis de la Solucin

3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. Entrevistas a los Usuarios Cambios en los Requisitos Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requisitos de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Casos de Uso Expandidos Diagramas de Secuencia Diagramas BPMN Posibles soluciones 3.9.1.

12 14
14 15 17 17 19 20 30 33 35 35

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Opciones de software de workow . . . . . . . . . . . . . . . . . . . .

4. Diseo
4.1. 4.2. 4.3. 4.4. 4.5. 4.6. Sistema Administrador de Workow . . . . . . . . . . . . . . . . . . . . . . . Arquitectura Fsica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquitectura Lgica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Diseo de Navegacin del Sistema . . . . . . . . . . . . . . . . . . . . . . . . Diseo de Interfaz de Usuario 4.6.1. 4.6.2. 4.6.3. . . . . . . . . . . . . . . . . . . . . . . . . . . Pgina de Bienvenida y Login . . . . . . . . . . . . . . . . . . . . . . Pgina de Saldos y Cartolas . . . . . . . . . . . . . . . . . . . . . . . Pgina de Resumen de Saldos . . . . . . . . . . . . . . . . . . . . . .

39
39 40 40 44 47 49 49 49 50

vii

4.6.4. 4.6.5. 4.6.6. 4.6.7. 4.6.8. 4.6.9.

Pgina de Planillas . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pgina de Peticiones de Giros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pgina de Conguracin de Usuario . . . . . . . . . . . . . . . . . . . Pgina para Agregar Nuevos Fondos Pgina para Pedir Giro de Fondos . . . . . . . . . . . . . . . . . . . . Pgina de Procesos Pendientes . . . . . . . . . . . . . . . . . . . . . .

51 52 53 54 55 56 56

4.6.10. Otras Pginas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5. Validacin
5.1. 5.2. 5.3. 5.4. 5.5. Planicacin de las Pruebas Seleccin de los Participantes Preparacin de los Materiales Aplicacin de las Pruebas 5.5.1. 5.5.2. 5.5.3. 5.5.4. 5.5.5. 5.5.6. 5.6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58
58 58 59 60 61 61 63 64 65 66 70 71

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resultados de la Primera Iteracin Discusin de la Primera Iteracin Resultados de la Segunda Iteracin

Discusin de la Segunda Iteracin . . . . . . . . . . . . . . . . . . . . Resultados de la Tercera Iteracin . . . . . . . . . . . . . . . . . . . . Discusin de la Tercera Iteracin . . . . . . . . . . . . . . . . . . . .

Discusin General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conclusin Glosario Bibliografa Anexos

72 75 76 78

viii

ndice de guras
3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. Diagrama de Casos de Uso (volteada) . . . . . . . . . . . . . . . . . . . . . . Diagrama de Secuencia del Caso de Uso CU1 . . . . . . . . . . . . . . . . . . Diagrama de Secuencia del Caso de Uso CU2 (volteada) Diagrama de Secuencia del Caso de Uso CU8 (volteada) . . . . . . . . . . . . . . . . . . . . . . Diagrama de Secuencia del Caso de Uso CU4 . . . . . . . . . . . . . . . . . . Diagrama BPMN del proceso Ingreso de Nuevos Fondos (volteada) . . . . . Diagrama BPMN del proceso Validacin de Giro de Fondos (volteada) . . . Diagrama de la Arquitectura Fsica (volteada) . . . . . . . . . . . . . . . . . Diagrama de Flujo con las tareas de la Jefatura Administrativa . . . . . . . Diagrama de Flujo con las tareas de la Secretaria de Investigacin . . . . . . Diagrama de Flujo con las tareas del Coordinador de Investigacin . . . . . . Diagrama de Flujo con las tareas del Director del Departamento . . . . . . . Diagrama de Flujo con las tareas de Profesor . . . . . . . . . . . . . . . . . . Diagrama de Flujo con las tareas de Administrador Diagrama de Navegacin del Sistema . . . . . . . . . . . . . . Modelo Relacional de la Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 31 32 33 34 37 38 41 42 43 43 44 44 44 45 48 49 50 51 52 53 54 55 55

4.10. Pgina de Bienvenida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11. Vista de una Cartola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12. Vista de un Resumen de Saldos 4.14. Vista de una Lista de Giros . . . . . . . . . . . . . . . . . . . . . . . . . 4.13. Vista de una Planilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.15. Bosquejo de la tabla para agregar fondos (primera iteracin) 4.16. Vista de la tabla para agregar fondos 4.17. Vista del formulario para pedir giros

ix

Introduccin
En el Departamento de Ciencias de la Computacin (D.C.C.) de la Facultad de Ciencias Fsicas y Matemticas de la Universidad de Chile, se percibi la necesidad de un sistema que apoyara la gestin de fondos de investigacin internos. En el Departamento exista una poltica de asignacin de recursos a investigadores para que stos los utilizaran en sus proyectos. Esta asignacin se realizaba basada en la productividad cientca, medida en publicaciones, de los investigadores respectivos. Este proceso de asignacin de recursos contaba con poco apoyo informtico y los usuarios respectivos requeran mejores servicios. En el ao 2011 se desarroll una aplicacin llamada

U-Papers 1 . Esta aplicacin tena por

objetivo otorgar una herramienta web para brindar servicios de almacenamiento y bsqueda de publicaciones cientcas del Departamento [1]. Usando esta herramienta se implementaban los clculos de recursos a asignar para los investigadores segn las reglas vigentes. Estos clculos asignaban puntajes para asignar fondos de investigacin individual (FII). El sitio

U-Papers

funcionaba de la siguiente manera. Cuando un investigador declaraba

una publicacin, ingresaba los datos en la pgina de

U-Papers

y se enviaban a una base de

datos. Mensualmente el Coordinador de Investigacin actualizaba el sistema FII usando la herramienta y enviaba sus decisiones a los respectivos investigadores y a la Secretaria de Investigacin. La pgina de despus de cuatro meses. Despus que la Secretaria de Investigacin reciba los nuevos fondos calculados de los puntajes, agregaba estos cambios en una planilla Excel y la imprima para llevarla a la Jefatura de Administracin. Esta planilla deba ser validada y rmada por el Director del Departamento, por el Coordinador de Investigacin y por la Jefatura Administrativa. Luego, en base a lo validado en la planilla, la Jefatura Administrativa guardaba los fondos FII en una base de datos personal (planillas Excel). Adems se devolva la planilla a la Secretaria de Investigacin para guardarla en un registro histrico. Los profesores que reciban este benecio slo podan vericar el estado de sus fondos a travs de una consulta directa con la Jefatura Administrativa. Tambin podan pedir un giro de fondos FII para pagar gastos relacionados con viajes a conferencias e investigaciones. Haban casos especiales en que un investigador no tena sucientes fondos FII y poda optar por un prstamo que deba ser validado por el Director del Departamento y el Coordinador de Investigacin (segn las publicaciones pendientes del investigador).

U-Papers

tambin permita ver borradores de las publicaciones

1 https://upapers.dcc.uchile.cl/
1

Motivacin
La primera cosa importante era que los datos entregados por

U-Papers

se manejaban con

planillas Excel y la organizacin de stas slo era conocida por la Secretaria de Investigacin y por la Jefatura Administrativa (cada una con sus propias planillas). Esto representaba una carga extra para los coordinadores ya que tenan que mantener la consistencia de los datos de forma manual y la informacin no estaba centralizada. En estos casos era muy comn que se pudiera perder informacin o que sta mostrara diferencias entre los funcionarios. Era importante que esto no ocurriera porque los puntajes del sistema FII se relacionaban directamente con el presupuesto del Departamento. Por otro lado, los profesores no tenan una forma de acceder a la informacin de sus fondos a menos que consultaran directamente con la Jefatura Administrativa. En este caso slo podan consultar el estado actual de sus saldos, ya que el sistema FII supona que cada investigador deba llevar una cartola de forma personal. Para realizar un giro de fondos FII, los profesores deban llenar un formulario y entregarlo a la Jefatura Administrativa. Este formulario slo se poda obtener a travs de la Secretaria de Investigacin (porque guardaba el archivo digital). Adems haban casos en que los formularios se perdan o no eran validados de forma correcta, lo que produca que los fondos no tuvieran el manejo de mxima conabilidad que requeran. Tambin haba otros problemas en la administracin de los fondos. Por un lado estaba la privacidad. La Secretaria de Investigacin no tena permitido entregar ninguna informacin sobre los fondos de los profesores del Departamento. Por otro lado, estaba la posibilidad de que los investigadores presentaran deudas con el Departamento (lo que se podra ver como tener saldos negativos). Estos casos se trataban de forma variable dependiendo si haban publicaciones prometedoras en el futuro. Tambin el registro histrico de la Secretaria de Investigacin deba mantener la consistencia con lo que ocurriera al nal de los periodos determinados como el semestre o el ao. Finalmente haba otros actores que participaban en estos procesos. El Director del Departamento y el Coordinador de Investigacin deban validar las acciones para asignar correctamente los fondos. Adems estaban los funcionarios que hacan adquisiciones con los fondos, una vez que se aceptaba un giro de fondos FII. Por ejemplo, la Secretaria de Investigacin deba comprar pasajes de avin para viajes a presentar artculos a conferencias.

Objetivo General
En vista de que el principal problema era la prdida de la informacin y que sta se encontraba distribuida a lo largo del Departamento, se pretendi mejorar este sistema al construir un sistema de informacin administrativa. Este sistema busc centralizar la informacin de los fondos de tal forma que se mantuviera consistente y segura. Adems esto ayud a reducir la carga de trabajo para la Secretaria de Investigacin y la Jefatura Administrativa ya que se automatiz el manejo de los datos.

Desarrollando este sistema tambin se pudo distribuir la informacin entre los profesores. Esto elimin el cuello de botella que se produca cuando se realizaban consultas sobre los fondos a la Jefatura Administrativa. Para lograrlo, el sistema deba tener una disponibilidad constante que pudiera atender varias consultas. Tambin el sistema deba soportar el proceso de pedir giros de fondos FII al adaptar el formulario de la Secretaria de Investigacin para hacer ms fcil y rpido el acceso. Por otro lado, el sistema a construir tambin deba prometer la seguridad de la informacin. La situacin de los fondos de cada profesor era personal y privada, por lo que haba que controlar los accesos y presentar slo la informacin necesaria a los respectivos usuarios. Fue necesario estudiar cuidadosamente las excepciones. Por ejemplo, estaba el rol de la Jefatura Administrativa que deba mantenerse informada de las validaciones y de las peticiones para invertir correctamente el presupuesto del Departamento.

Objetivos Especcos
Desarrollar un sistema de informacin administrativa que permita: 1. Gestionar los fondos FII de una manera eciente y efectiva, tomando como entrada los datos provistos por el Coordinador de Investigacin al usar la herramienta 2. Mantener la seguridad y la consistencia de la informacin almacenada. 3. Facilitar el acceso de todos los usuarios a la informacin correspondiente segn sus roles. La Jefatura Administrativa debe tener acceso a toda la informacin. 4. Generar un registro que tenga coherencia y pueda ser comparado con el registro histrico que tiene la Secretaria de Investigacin.

U-Papers.

1. Marco Conceptual
1.1. Conceptos Bsicos

Workow (o Flujo de Trabajo): Es la automatizacin de un proceso de negocio, ya sea en parte o completo, durante el cual la informacin, documentos y tareas son traspasados de un participante a otro en busca de una accin, de acuerdo a un grupo de procedimientos reglamentados [2].

B.P.M.N.: Business Process Management Notation. es una notacin grca que representa los pasos en un proceso de negocio. Est especialmente diseada para coordinar la secuencia de procesos y mensajes que uyen entre distintos participantes en un conjunto de actividades relacionadas [3].

Capas de software: Corresponden a los niveles abstractos que separan a los usuarios de los dispositivos fsicos y que separan las funcionalidades de un software para dejar las ms complejas por el lado de las mquinas.

1.2. Desarrollo Incremental

El desarrollo incremental es una metodologa de ingeniera de software. sta consiste en construir una implementacin inicial, mostrarla al usuario y evolucionarla en una serie de entregas hasta que el sistema cumpla con los requisitos y sea adecuado para solucionar el problema [4]. La especicacin de requisitos, la implementacin y la validacin se realizan en cada iteracin y puede que se hagan al mismo tiempo junto con una veloz retroalimentacin entre medio de las actividades. De esta forma, los cambios en la aplicacin son ms fciles y tienen menor costo (en tiempo y esfuerzo). Las principales ventajas de este mtodo son el bajo costo para cambiar requisitos ya que presenta un menor anlisis y documentacin que un desarrollo en cascada. Tambin es ms fcil obtener una retroalimentacin porque los usuarios pueden dar comentarios en cada una de las demostraciones y estar pendientes del progreso de la aplicacin. Los comentarios entregados son ms especcos porque los usuarios pueden interactuar con el sistema y no adivinar errores a travs de un documento de diseo. Por otro lado, en cada entrega se puede entregar un software incompleto (con algunas funciones completas) lo que permite hacer ms exibles las fechas de entrega y las funciones a desarrollar.

Uno de los problemas de este desarrollo es que el proceso no es muy visible porque no presenta mucha documentacin. Tambin se degrada la estructura del sistema al agregar ms incrementos. Por esto, el costo de mejorar el software se vuelve cada vez mayor. Sin embargo, estos problemas se producen generalmente en sistemas grandes y complejos que cuentan con la participacin de ms de un equipo de desarrollo.

1.3. Arquitectura Cliente-Servidor

La arquitectura cliente-servidor es una forma de organizar los componentes donde los usuarios interactan con computadores locales a travs de una aplicacin o un navegador que accede a servicios externos. De esta forma, se puede separar la presentacin de la lgica del sistema. Tambin permite ofrecer software como servicios remotos a travs de Internet. Segn [4] esta arquitectura se puede dividir en cuatro capas:

La capa de presentacin. La capa de administracin lgica. La capa de procesamiento de aplicacin donde se implementa la lgica. La capa de base de datos que almacena informacin y otorga servicios a travs de un administrador de transacciones.

Esta arquitectura se puede aplicar de distintas maneras:

Maestro-Esclavo: Se usa en sistemas de tiempo real que deben garantizar tiempos de respuesta. Hay un proceso maestro que es reponsable de la computacin, comunicacin y coordinacin de los procesos esclavos. stos ltimos realizan acciones especcas como obtener datos del ambiente.

Cliente-Servidor de dos niveles (2-tier): Se usa en sistemas simples y situaciones donde hay que centralizar la informacin del sistema. Est formada por un servidor que maneja la lgica y varios clientes. Se pueden denir dos tipos de clientes:

Cliente liviano: Slo puede interactuar con el sistema a travs de la capa de presentacin. Por esto puede interactuar mejor con el sistema sin agregar mucho software adicional (por ejemplo a travs de un navegador Web). El servidor tiene que manejar toda la lgica de las otras capas y esto puede causar mucha carga en la comunicacin. Aunque se pueden agregar programas simples ( de presentacin para aligerar esta carga.

scripts ) a la capa

Cliente pesado: Puede manejar la capa de presentacin y la capa de administracin lgica. Pero es necesario que instale ms aplicaciones que funcionen de forma local para reducir las comunicaciones con el servidor. Tambin hay un mayor costo al actualizar los cambios que se realicen.

Cliente-Servidor multinivel (multitier): Se usa cuando el servidor procesa muchas transacciones. Separa las capas en distintos procesadores. Mejora las desventajas de usar slo dos niveles, pero debe garantizar una comunicacin segura entre las capas.

Componentes Distribuidos: Consiste en recursos de distintos sistemas y bases de datos

que necesitan combinarse. Tambin sirve como un modelo de implementacin para la arquitectura con multiniveles. El sistema se disea como un conjunto de servicios separados sin ubicacin especca que se comunican a travs de una interfaz o un middleware (con Remote Procedure Call).

Peer to Peer: Consiste en clientes que intercambian informacin almacenada localmente y el servidor se encarga de comunicarlos entre s. Tambin sirve para realizar muchas computaciones independientes.

Otra ventaja de la arquitectura Cliente-Servidor, es que permite utilizar aplicaciones de middleware. Un middleware es una capa de comunicacin entre las aplicaciones y el sistema operativo. Pueden agregar funciones tiles como mejorar la comunicacin con la base de datos y administrar las transacciones. La principal ventaja que tienen es que permiten la interaccin de distintos componentes al convertir parmetros entre distintos lenguajes de programacin. Tambin pueden dar servicios comunes y reutilizables entre los componentes.

1.4. Conceptos de Workow

Segn [5] un workow especica el orden en que se llevan a cabo las actividades que conforman un proceso. Adems dene con qu se llevar a cabo una actividad, las condiciones necesarias para la ejecucin, la sincronizacin del tiempo y la informacin utilizada por cada ujo de trabajo. La tecnologa workow cuenta con ventajas como la informacin referente a tareas y procesos, rutas o servicios tcnicos, datos y polticas. Tambin permite conocer el estado del sistema en cualquier momento. Como esta tecnologa permite manejar procesos manuales dentro del mismo modelamiento, se puede tener una visin global del proceso sin dejar actividades fuera, lo que puede provocar problemas. Otra ventaja es que se puede denir personas y roles especicando en mayor detalle la denicin de entidades del modelo original. Esto ayuda a la incorporacin de reglas de transicin lo que logra un modelo ms completo y autoexplicativo. Con esto y la incorporacin de eventos se pueden denir las actividades con un mayor detalle. Esta tecnologa es parte de la revolucin de Internet, la cual ha tenido un impacto signicativo en el manejo de procesos de negocio. Tambin ha afectado la forma en que los miembros de una organizacin actan coordinadamente, distribuyen tareas y comparten informacin para lograr metas. A continuacin se muestran algunos conceptos clave [2]:

Proceso de negocio: Conjunto de uno o ms procedimientos o actividades encadenadas, que en su conjunto cumplen un cierto objetivo de negocios, en un entorno donde normalmente existe una estructura organizacional que cuenta con roles y responsabilidades.

Tarea: Se puede denir como un conjunto de acciones manejadas como una sola unidad que tienen un propsito especco dentro del desarrollo de un proceso de negocio,

realizadas por un solo individuo.

Sistema Administrador de Workow: Es un sistema que dene, crea y administra la ejecucin de Workow a travs de un conjunto de programas computacionales. Dentro del sistema pueden existir uno o ms motores de workow, que estn encargados de interpretar las deniciones de los procesos, interactuar con los participantes de estos procesos y si es requerido ejecutar ciertas herramientas y programas.

Segn [5] hay distintos tipos de sistemas de workow:

Workow de Produccin: En general automatizan procesos de negocios que tienden a ser repetitivos, bien estructurados y con gran manejo de datos. Las transacciones en una base de datos son consideradas la base del proceso.

Workow de Colaboracin: Se encarga de estructurar o semi-estructurar procesos de negocios con la participacin activa de personas y con el objetivo de lograr una meta en comn. La clave de estos procesos son los documentos que contienen la informacin y sobre los cuales se realiza el seguimiento.

Workow Administrativo: Involucra procesos de administracin en una empresa tales como rdenes de compra, reportes de ventas, etc.

Segn [6] un sistema de workow debe contar con las siguientes caractersticas:

Diseo grco: Debe tener facilidad grca para crear mapas de procesos para denir el ujo de trabajo y las tareas que deben ser realizadas. Roles: Debe ser capaz de asignar tareas a roles, funciones de trabajo o individuos permitiendo que el diseo del mapa se mantenga constante y no requiera re-editarse mucho con cada cambio. Tambin sirve que pueda manejar un organigrama o directorios de usuario.

Reglas: Debe incluir las reglas de la organizacin, las excepciones y la lgica del negocio. Manejo de Excepciones: Este manejo es importante porque las excepciones ocurren a diario, por ejemplo si falta un actor para realizar una tarea. Monitoreo: Debe poder revisar los estados y las etapas de los procesos que maneja. Reportes: Debe generar informes estadsticos para estimar el tiempo y el costo de los procesos. Esto es til para los administradores de negocio porque les proporciona mecanismos para corregir los procesos.

Simulacin: Debe tener la facilidad de realizar pruebas en un slo computador. Esto evita tener que probar con grandes cantidades de usuarios. Pro-activo: Debe informar las tareas nuevas que se presenten y manejar las situaciones en caso de atrasos. Interfaz de Usuario en Navegador: El navegador es usado en forma masiva y es el medio de comunicacin para las organizaciones modernas. Cuenta con fcil acceso, bajo costo, es sencillo de usar y se puede aplicar a grandes cantidades de usuarios.

Anexo de Documentos: Debe proporcionar un medio efectivo para adjuntar documentos en los procesos ya que son el principal objeto que deben administrar varios procesos.

Estas caractersticas otorgan ms ventajas al usar sistemas de workow. La pro-actividad ayuda a aumentar la responsabilidad de los participantes para cumplir sus compromisos.

El monitoreo y los reportes ayudan a obtener ms rpido la informacin con menos costo de administracin. Como un sistema es automtico, se reducen las omisiones y los errores humanos dando consistencia y conabilidad. Se puede reducir la cantidad de papel lo que a su vez reduce los costos y los errores. Tambin se reducen los tiempos de espera porque la transferencia de informacin es casi instantnea. Adems se reduce el tiempo de tareas secuenciales al paralelizar tareas independientes. Este tipo de sistema fuerza a analizar y documentar procesos de negocio revelando redundancias e inecacias. Se pueden integrar con otras aplicaciones como planillas electrnicas, procesadores de texto y bases de datos.

1.5. Conceptos de Usabilidad

Segn [7] la usabilidad es un atributo de calidad que evala la facilidad para usar una interfaz de usuario. Tambin se reere a los mtodos para mejorar esta facilidad de uso durante el proceso de diseo. Principalmente mide la relacin entre las herramientas y los usuarios de tal forma que se puedan cumplir las tareas de la mejor forma posible. La usabilidad est denida por cinco componentes:

Facilidad de aprendizaje: Se reere a la facilidad de completar tareas cuando se ve por primera vez la interfaz. Puede ser difcil de medir dependiendo de la cantidad de salidas que pueda tener una tarea.

Facilidad y Eciencia de Uso: Se reere a la rapidez para terminar una tarea cuando ya se conoce el sistema. Se puede medir al ver cmo los usuarios se desvan del camino ms rpido y cuntas veces tienen que consultar un documento o un usuario ms experto.

Facilidad de recordar cmo funciona: Se reere a la facilidad de volver a completar las tareas despus de un tiempo sin usar el sistema. Frecuencia y gravedad de errores: Se reere a la cantidad, nivel y recuperacin de los errores. Segn [8] hay que diferenciar cuando se comete un error y cuando se resbala. Resbalar es cuando se sabe cmo realizar una tarea, pero accidentalmente se llega a otro resultado. Un error se comete cuando una tarea no se puede completar con el resultado esperado. El nivel de los errores depende de si permiten completar las tareas y de la complejidad que tiene repararlos.

Satisfaccin subjetiva: Se reere a la comodidad de usar la interfaz. Indica lo aceptable que es el producto como medio para completar las tareas. Se puede medir de forma cualitativa y cuantitativa.

Adems en [7] se dene una lista con diez principios recomendados para disear una interfaz de usuario. Estos principios se llaman heursticas y son los siguientes:

Visibilidad del estado del sistema: El sistema debe mantener informado a los usuarios sobre lo que est ocurriendo a travs de retroalimentacin apropiada en tiempo razonable.

Igualdad entre el sistema y el mundo real: El sistema debe usar el lenguaje de los usuarios con palabras, frases y conceptos familiares en vez de trminos tcnicos. Debe mos-

trar la informacin en un orden lgico y natural.

Control y libertad de usuario: Los usuarios frecuentemente eligen funciones del sistema por equivocacin y necesitan una salida de emergencia para dejar ese estado indeseable sin tener que pasar por un extenso dilogo. Hay que soportar las funciones para deshacer y rehacer.

Consistencia y estndares: Los usuarios no deberan preguntarse si palabras, situaciones o acciones distintas tienen un mismo signicado. Hay que usar convenciones de la plataforma.

Prevencin de errores: En vez de buenos mensajes de error, es mejor un cuidadoso diseo que evite los errores. Hay que eliminar condiciones propensas a errores o revisarlas y mostrrselas a los usuarios a travs de una opcin de conrmacin.

Reconocimiento antes que retirar: Hay que minimizar la carga de memoria del usuario con objetos, acciones y opciones visibles. El usuario no debera recordar la informacin entre dos partes de un dilogo. Las instrucciones de uso deben ser visibles o fcilmente recuperables cuando sea apropiado.

Flexibilidad y eciencia de uso: Los aceleradores pueden agilizar la interaccin entre el sistema y un usuario experto. Hay que permitir que los usuarios puedan realizar acciones frecuentes.

Diseo minimalista y esttico: Los dilogos no deberan contener informacin irrelevante. Cada unidad adicional de informacin en un dilogo compiten con las unidades relevantes y disminuyen su visibilidad relativa.

Ayudar a los usuarios a reconocer, diagnosticar y recuperarse de errores: Los mensajes de error deben expresarse en lenguaje regular (sin cdigo), indicar precisamente el problema y sugerir una solucin de forma constructiva.

Ayuda y documentacin: Aunque el sistema no necesite documentacin, sta podra ser necesaria para ofrecer ayuda. Tal informacin debe ser fcil de encontrar, enfocada en las tareas del usuario, con pasos concretos a seguir y no debe ser muy grande.

1.6. Evaluacin de Usabilidad

La evaluacin de la usabilidad implica analizar el entorno y los usuarios que interactan con el sistema. Este anlisis se realiza mediante pruebas con prototipos con una seleccin de usuarios. Los datos para medir deben ser tanto cuantitativos como cualitativos. Los cuantitativos son datos reales que pueden ayudar a juzgar decisiones sobre el diseo. Midiendo el tiempo y la tasa de error se puede medir el desempeo y la eciencia de uso y encontrar varias soluciones. Se puede aproximar la satisfaccin subjetiva a valores reales como una medida de actitud. Mientras que los datos cualitativos permiten diagnosticar fallas en la usabilidad y encontrar soluciones en el diseo. Permite acotar las reas con fallas y diagnosticar los errores como una medida de desempeo. Tambin permite enfocar los aspectos que producen insatisfaccin como una medida de actitud. A continuacin se muestran algunos mtodos para realizar las evaluaciones:

Protocolo de pensamiento en voz alta: En este tipo de evaluaciones, el participante habla sobre lo que hace y piensa al interactuar con un prototipo del sistema. Se le pueden dar tareas especcas para que las realice durante la sesin o puede explorar libremente las aplicaciones con poca intervencin del evaluador. Entregar tareas especcas ayuda a encontrar fallas en el diseo. Mientras que la exploracin libre ayuda a descubrir las funciones ms importantes y frecuentes del sistema. La principal ventaja de este mtodo es que se pueden encontrar soluciones en el diseo ya que se pueden deducir las causas de los errores. Pero la desventaja es que la accin de hablar puede distraer al participante y cambiar su estado de nimo (puede sentir miedo por estar realizando algo mal). Adems hay que balancear la cantidad de intervenciones que realiza el evaluador porque muchas pueden cambiar las opiniones originales del participante y muy pocas pueden impedir que se consiga la informacin adecuada.

Cuestionarios: Consisten en una serie de preguntas escritas para que el participante responda. Si en situaciones similares se presentan respuestas similares entonces se pueden conar en los resultados. Pero para que los cuestionarios sean vlidos, las preguntas deben apuntar a la usabilidad. Esto se puede solucionar usando cuestionarios prediseados. Las preguntas pueden ser abiertas o cerradas. Las abiertas ayudan a identicar problemas sobre el diseo y sirven en las primeras etapas del desarrollo. En cambio las cerradas dan ms informacin cuantitativa y sirven cuando se tienen prototipos funcionales. La principal ventaja de los cuestionarios es que se puede aplicar a muchos participantes sin evaluadores expertos. Pero puede que los participantes no se sientan muy estimulados a participar.

Entrevistas: Consiste en una conversacin oral con el participante. Se pueden dividir en tres tipos segn el tipo de preguntas: desestructurada, semi-estructurada y estructurada. Una entrevista desestructurada est formada por preguntas generales que ayudan a encontrar los problemas ms importantes que hay que tratar en el desarrollo. Una semi-estructurada apunta a conceptos ms fsicos y ayuda a encontrar los problemas de mayor prioridad. Por ltimo, una estructurada consiste en preguntas ms cerradas y tcnicas que ayudan a encontrar los problemas ms especcos. Las ventajas de las entrevistas es que se pueden usar en cualquier etapa del desarrollo, ya sea para capturar requisitos o para tratar partes especcas del diseo. Adems son muy exibles ya que se pueden reformular preguntas (en caso que el participante no entienda) y pueden durar ms tiempo para validar respuestas. Tambin tienen bajo costo en cuanto a la cantidad de participantes, pero sube el costo del tiempo para organizar las sesiones. Por otro lado, es posible que las respuestas obtenidas sean principalmente opiniones y no respuestas concretas por lo que tambin hay un costo en cuanto a estructurar una entrevista.

Anlisis por tareas: Consiste en dar una serie de pasos a un participante para que pruebe un prototipo del sistema. Al disear las pruebas se puede predecir la dicultad y medir la cantidad de pasos en cada tarea. Adems se puede denir la consistencia y compatibilidad del diseo, lo cual sirve para predecir la complejidad de agregar una nueva tarea. Las principales ventajas de este mtodo es que se puede aplicar con pocos participantes y se pueden usar varios monitores (si se dene una secuencia estricta). Adems ayuda a encontrar problemas y soluciones en la interfaz, la cual se puede redisear para reducir la cantidad de pasos. Pero la desventaja es que no se reeja exactamente la usabilidad porque cada paso puede tener una complejidad distinta.

10

Tambin hay que preocuparse de no aumentar la complejidad al disminuir la cantidad de pasos.

Evaluacin heurstica (o experta): Consiste en una inspeccin sistemtica del diseo de una interfaz realizada por un pequeo grupo de evaluadores juzgndola con reconocidos principios de usabilidad (heursticas) [7]. La principal ventaja es que tiene bajo costo al contar con pocos participantes y se cuenta con el conocimiento de expertos. Tambin se pueden predecir los problemas basndose en el diagnstico de una falla particular. Sin embargo, no se puede asegurar que las respuestas obtenidas a travs de este mtodo reejen las opiniones de los usuarios. Es posible que se confundan problemas grandes con problemas que podran parecer triviales a los expertos. Por lo tanto, los resultados deben ser respaldados por datos empricos.

11

2. Metodologa
Durante el primer semestre del ao se enfoc el trabajo principalmente en analizar los problemas detectados. Se realizaron algunas entrevistas a los principales actores para establecer el contexto. Con esto se denieron los casos de uso para establecer los requisitos que tendra el sistema a construir. En base a los requisitos se deni una arquitectura inicial y se buscaron algunas herramientas para construir la solucin. Despus se obtuvo un diseo inicial para la solucin con los requisitos validados. En particular, la informacin de este diseo se concentr en los diagramas que muestran los ujos de informacin en los procesos y las acciones que puede realizar cada actor. En el segundo semestre, durante el curso del ramo CC69F, se realiz la implementacin de la solucin la cual consisti en un desarrollo incremental. El desarrollo tom tres iteraciones, cada una con su propio prototipo funcional. Durante el desarrollo del proyecto se realizaron pruebas para vericar el cumplimiento de los objetivos. A continuacin se describen los mtodos que se realizaron ordenados segn los objetivos especcos: 1. Al recibir los datos de entrada se esperaba que el sistema actualizara automticamente la informacin de la Secretaria de Investigacin y de la Jefatura Administrativa. Esta recepcin deba ser robusta porque haban casos especiales en que los datos deban ser reenviados (como cuando un investigador tena deuda de fondos). Adems esta informacin deba tener un fcil acceso para que pudiera ser revisada por la Secretaria de Investigacin. Para probar esto, se simularon distintas entradas que principalmente se enfocaban en los casos especiales. Algunos de estos casos consistan en saldos que presentaban deudas, saldos que contenan fondos con ms de dos aos de antigedad (que se descontaban) y saldos con fondos que deban ser aplazados para el prximo ao (sobrante del lmite anual). Se veric que los resultados generados coincidieran con las situaciones denidas en los casos de uso. 2. Para mantener la consistencia y la seguridad de la informacin, el sistema tena que contar con una base de datos centralizada. Para probar la consistencia se cargaron algunas peticiones en el sistema que necesitaran validacin (se almacenarn en la base de datos) y se revisaron despus de un lapso de tiempo. Con esto se demostr que el sistema solucionaba la prdida de informacin. Para la seguridad se restringi el acceso a travs de un sistema de identicacin de usuarios y un sistema de contraseas para aquellos procesos que requeran validaciones de varios encargados (como el Director del Departamento, el Coordinador de Investigacin y la Jefatura Administrativa). 3. Cuando la implementacin se encontr en un estado disponible para los usuarios, se realizaron pruebas de usabilidad. Se estim que los profesores no tendran mucha dis-

12

ponibilidad, por lo que se plane realizar una prueba a por lo menos tres profesores. Principalmente se enfoc en el aprendizaje y la eciencia de la interfaz, ya que esta solucin poda ser diferente a lo acostumbrado y los profesores tenan que entender fcilmente la interfaz para usarla. Se estim que sus principales actividades seran consultas para ver los datos que les corresponden en el sistema, por lo que se di un menor nfasis al manejo de errores para la interaccin de los profesores con el sistema. Adems se elabor una herramienta para que la Jefatura Administrativa pudiera comparar los resultados con las planillas Excel que usaba como base de datos. La informacin tambin deba estar disponible para el Director del Departamento y el Coordinador de Investigacin, pero slo de tal forma que pudieran ver los saldos actuales de los investigadores. Estas pruebas se realizaron cerca del nal del ao. 4. Los datos almacenados como registro histrico en el sistema tenan que ser validados por aquellos que rmaban las planillas del registro para establecer la correcta forma de guardar el registro histrico una vez que se implementara esta solucin. Esto tambin implicaba a la Secretaria de Investigacin, ya que el sistema pudo signicar un cambio brusco en la forma en la que se almacenaba el registro histrico. Para probar esto, en cada iteracin del desarrollo (excepto la inicial) se intent simular la autorizacin de un ingreso al registro histrico. En esta prueba se pidi a los actores correspondientes que validaran nuevos fondos y que dieran su opinin sobre la seguridad y la legitimidad del sistema. Tambin se construy una herramienta similar a la del punto anterior para que la Secretaria de Investigacin pudiera comparar los resultados de la simulacin con el registro histrico.

13

3. Anlisis de la Solucin
3.1. Entrevistas a los Usuarios
Para empezar a entender mejor el problema y conocer mejor las acciones que se realizaban en el D.C.C., se realizaron entrevistas con preguntas abiertas a distintas personas. Primero se entrevist a la Jefa Administrativa y a la Secretaria de Investigacin porque ellas manejaban la informacin que se almacenaba en planillas Excel. Las preguntas apuntaban a los siguientes temas:

Uso del sitio

U-Papers.

Informacin sobre el sistema FII/EP. Informacin que reciban. Informacin que enviaban. Informacin almacenada y cmo se manejaba.

La Jefa Administrativa indic que no conoca el sitio

U-Papers.

Sobre el sistema FII/EP

indic que reciba una copia de una planilla Excel donde se mostraban los ingresos de fondos del ao. Despus los agregaba en sus propios archivos donde tena a cada acadmico con cada ingreso, gasto y saldo. Como ella guardaba estos archivos, indic que los profesores realizaban consultas directas sobre esta informacin y que podan llevar las cuentas, pero que resultaba dcil y que la informacin no estaba centralizada. Luego indic que la planilla Excel deba estar rmada por el Coordinador de Investigacin, el Director del Departamento y ella misma. Tambin indic que reciba formularios impresos para que los acadmicos realizaran giros de fondos FII, los cuales tenan que ser revisados por el Director del Departamento y el Coordinador de Investigacin. Sin embargo, haba problemas en este proceso como la prdida de autorizaciones y comisiones acadmicas. La Secretaria de Investigacin indic que conoca el sitio

U-Papers

y que lo usaba pa-

ra conrmar si se haban realizado publicaciones. Ella reciba informacin del Coordinador de Investigacin para imprimir la planilla de fondos y la enviaba para que fuera rmada. Finalmente reciba una copia rmada y la guardaba, jndose que los nmeros estuvieran correctos. La informacin que reciba eran un par de correos electrnicos que indicaban los ingresos del ao actual y los pendientes del ao pasado. Tambin indic que tena que imprimir los formularios para los giros de fondos FII y que tena que realizar algunas acciones cada vez que se autorizaba un giro (reciba correos electrnicos).

14

Con esta informacin se entendi ms sobre los procesos para que los profesores recibieran fondos FII y despus pudieran pedir giros de estos fondos. Se realizaron otras entrevistas con preguntas ms especcas sobre estos procesos. En esta ocasin se entrevist al Director del Departamento, al Coordinador de Investigacin y a la Jefa Administrativa. Las preguntas apuntaban a los siguientes temas:

Uso del sitio

U-Papers

(excepto a la Jefa Administrativa).

Manejo de la informacin cuando se recibe la planilla con ingresos. Manejo de la informacin cuando se recibe una peticin de giro de fondos FII. Manejo de la informacin cuando ocurre un error.

El Director del Departamento indic que no usaba mucho el sitio

U-Papers

para estos

procesos. La planilla de ingresos la usaba para estar actualizado de tal informacin al momento de rmarla. l estaba a cargo de autorizar los giros aunque indic que haban casos especiales en que los profesores no contaban con fondos sucientes y tena que consultar estos casos con el Coordinador de Investigacin. Finalmente dijo que tena que dar una respuesta a los profesores en caso que rechazara una peticin de giro de fondos. El Coordinador de Investigacin indic que tampoco usaba el sitio

U-Papers

para estos

procesos y que usaba un programa propio para calcular los nuevos ingresos y almacenarlos en una base de datos propia. Despus enviaba correos electrnicos a la Secretaria de Investigacin y a los respectivos profesores para avisar sobre estos ingresos. Al revisar la planilla era posible que tuviera que reenviar la informacin por errores en los nmeros. En cuanto a las peticiones de giros, dijo que entregaba datos tcnicos, pero que al nal el Director del Departamento entregaba la autorizacin. Finalmente advirti sobre las reglas adicionales que tenan los ingresos. Primero, que los fondos tenan que ser descontados si no se usaban por ms de dos aos. Y segundo, que haba un lmite mximo anual para recibir ingresos de fondos FII (aunque su programa ya trataba este problema). La Jefa Administrativa indic que la planilla tena que recibirla rmada a menos que estuviera cerca la fecha del ingreso de productividades (entre los meses Enero y Febrero). En este caso, se enviaban correos electrnicos con los ingresos de forma anticipada. Por otro lado, almacenaba las copias de las planillas para tener cerca la informacin. En cuanto a las peticiones de giros, indic que eran autorizadas por el Director del Departamento aunque el Coordinador de Investigacin tambin tomaba parte en casos especiales. Tambin indic que reciba una copia de una comisin acadmica que era un documento que formalizaba estos descuentos de fondos. Esta formalizacin se haca fuera del D.C.C. y a veces tena que informar a la Secretaria de Investigacin por casos como compra de pasajes. Finalmente se quej que este proceso de formalizacin era lento y poda demorar mucho.

3.2. Requisitos de Usuario

Los requisitos principalmente se fueron deduciendo de las entrevistas que se llevaron a cabo. Para empezar, el sistema necesitaba una herramienta para agregar los nuevos fondos calculados por el Coordinador de Investigacin. Los datos ingresados a travs de esta he-

15

rramienta tambin necesitaban correcciones por lo que el sistema deba disponer de esta opcin. Una consulta muy frecuente de algunos usuarios era la informacin de la ltima planilla de fondos vlida. Estos usuarios correspondan a la Secretaria de Investigacin, al Coordinador de Investigacin, al Director del Departamento y a la Jefatura Administrativa. El sistema deba mostrar esta informacin de forma clara y precisa. De la misma forma, el sistema tena que ofrecer la informacin de las nuevas planillas que construyera y ofrecer una forma de agregarle rmas para su validacin. Tambin era necesario que el sistema le avisara a la Jefatura Administrativa cuando se completara la validacin para despus permitir actualizar los fondos de los profesores. Por otro lado, el sistema deba mantener un registro de las planillas vlidas y otorgar el acceso a la Jefatura Administrativa y a la Secretaria de Investigacin. La informacin de los fondos en el sistema deba estar disponible para los profesores correspondientes. Tambin deban tener acceso a las cartolas de sus fondos para ver los cambios en sus cuentas. El sistema deba otorgarle permiso a la Jefatura Administrativa para que pudiera ver los saldos de todos los profesores. El sistema deba tener disponible un formulario para que los profesores pudieran pedir giros de sus fondos. Estas peticiones slo podan ser validadas por el Director del Departamento y podan ser revisadas por el Coordinador de Investigacin si era necesario. El alcance del sistema no inclua la formalizacin de las peticiones, pero una vez realizada, la Jefatura Administrativa poda descontar efectivamente el monto respectivo a travs del sistema. El estado de cada peticin deba estar disponible para el profesor que realizaba la peticin, para la Jefatura Administrativa y para el Director del Departamento. Para mantener la seguridad de la informacin, el sistema deba contar con cuentas para los usuarios y contraseas. Por lo menos deba contar con las funciones para crearlas y congurarlas. No se determin si era necesario borrar las cuentas que no se fueran a usar porque era posible que se quisiera mantener alguna informacin. Se dej como requisito que el sistema pudiera bloquear y reactivar cuentas. Para que el sistema se sintiera familiar fue necesario que las planillas pudieran ser importadas a archivos Excel, ya que se usaban estos archivos para almacenar los datos. Tambin fue necesario que las aplicaciones fueran intuitivas para los usuarios ms importantes que corresponden a los que creaban y validaban las planillas de fondos. Adems para mejorar la eciencia, el sistema deba tratar correctamente el vencimiento de los fondos que tienen ms de dos aos. Como restriccin las aplicaciones del sistema deban ser instaladas en los servidores del D.C.C., ya que se manejaba informacin privada de los profesores y deba ser controlada por el Departamento. Tambin se denieron algunos requisitos que no fueron crticos para la construccin del sistema, pero que podan agregar valor a los procesos. Por ejemplo, para la usabilidad se pens en una forma de comparar las planillas de fondos (la nueva con la ltima) y as mejorar la eciencia. Tambin con el sistema se plane enviar correos electrnicos a los usuarios para dar avisos como cuando se realizaba un giro, cuando se validaba una nueva planilla de fondos

16

o cuando se iban a descontar fondos caducos. Para mejorar la portabilidad, el sistema poda distribuir la informacin a travs de navegadores Web como Internet Explorer y Mozilla Firefox. En caso de errores durante la validacin de una planilla, el sistema poda ofrecer una forma de recibir una planilla creada manualmente por la Secretaria de Investigacin.

3.3. Cambios en los Requisitos

Durante las iteraciones del desarrollo, se fueron encontrando requisitos adicionales a medida que se realizaban las validaciones del sistema. Para empezar, la Jefatura Administrativa necesitaba ver los saldos y cartolas de cada profesor. Pero tambin necesitaba una visin ms global de tal forma que pudiera evaluar los ujos de fondos en un determinado ao. Para esto el sistema deba mostrar un resumen que le indicara el total de ingresos, gastos y saldos de cada profesor en un ao especco. Adems esta informacin tambin era importante para el Director del Departamento (slo el resumen). Otro requisito de este resumen era que permitiera a la Jefatura Administrativa corregir alguno de sus valores en caso que se presentara algn error o irregularidad. En particular, deba permitir corregir el saldo con el que se empieza el ao. Por otro lado, el Coordinador de Investigacin no quera cambiar mucho su forma de trabajo. Prefera mantener su funcin de enviar correos electrnicos y que la Secretaria de Investigacin ingresara los nuevos fondos a travs de la herramienta del sistema. Sin embargo, para mantener la lgica del sistema se consider que el Coordinador de Investigacin deba mantenerse como el actor que deba realizar la tarea de ingresar nuevos fondos en el sistema. Por lo tanto se deni un nuevo requisito en que la herramienta tambin pudiera ser usada por la Secretaria de Investigacin. Otro requisito de menor prioridad que surgi fue el de avisar a los usuarios sobre distintos eventos a travs de correo electrnico. Por ejemplo, los profesores podran recibir uno indicando si una peticin de giro fue rechazada o aceptada. Tambin se podra avisar a la Jefatura Administrativa si se valid una nueva planilla de fondos. Finalmente, un requisito importante era seleccionar el lenguaje que utilizara la interfaz. Este lenguaje deba informar y detallar cmo funcionara el sitio y cules seran los resultados de las operaciones que se realizaran. Adems este lenguaje no poda incluir detalles tcnicos y tena que guiar correctamente a los usuarios a travs de los distintos procesos.

3.4. Actores
Estos son los actores que interactan con el sistema y tambin se muestran los objetivos que deban alcanzar como resultado de estas interacciones.

17

Secretaria de Investigacin: Ocina encargada de organizar los nuevos datos de los fondos para almacenarlos en el registro histrico. Sus objetivos son:

Recibir los nuevos datos de los fondos y agregarlos a una planilla especial con los fondos del ao. Enviar la planilla a la Jefatura de Administracin, al Coordinador de Investigacin y al Director del Departamento para su validacin. Almacenar la planilla validada y rmada en un registro histrico. Obtener informacin sobre el saldo de los profesores y los giros que realizan.

Jefatura Administrativa: Ocina encargada de manejar el presupuesto del Departamento para pagar distintos servicios. stos representan el uso de los fondos que se producen con las publicaciones. Sus objetivos son:

Recibir, rmar y validar la planilla con los nuevos fondos mensuales de la Secretaria de Investigacin. Devolverla una vez rmada. Recibir la planilla validada y almacenar los nuevos datos. Almacenar los saldos y las cartolas de los fondos FII para cada profesor. Recibir comisiones acadmicas para descontarlo de los saldos de los respectivos profesores. Obtener informacin sobre el saldo de los profesores y los giros que realizan. Obtener informacin anual sobre el ujo de fondos FII en el Departamento.

Director del Departamento: Encargado de la direccin del Departamento y de permitir los giros de fondos que realizan los profesores. Sus objetivos son:

Recibir, validar y rmar la planilla con los nuevos fondos mensuales de la Secretaria de Investigacin. Devolverla una vez rmada. Permitir o rechazar peticiones de giros de fondos FII a travs de una comisin acadmica (formalizacin). Consultar con el Coordinador de Investigacin en caso que se presenten casos especiales. Obtener informacin sobre el saldo de los profesores y los giros que realizan. Obtener informacin anual sobre el ujo de fondos FII en el Departamento.

Coordinador de Investigacin: Encargado de organizar las publicaciones de las investigaciones que realizan los profesores. Sus objetivos son:

Calcular los valores de los fondos del mes y enviarlos a la Secretaria de Investigacin. Recibir, validar y rmar la planilla con los nuevos fondos mensuales de la Jefatura Administrativa. Devolverla una vez rmada. Entregar su opinin sobre casos especiales de giros FII. Obtener informacin sobre el saldo de los profesores y los giros que realizan.

Profesor: Corresponde a los usuarios que realizaban publicaciones cientcas para el Departamento. Sus objetivos son:

18

Revisar los saldos de sus fondos y las cartolas histricas correspondientes. Realizar peticiones de giros de fondos FII.

Administrador: Encargado de administrar las cuentas de los usuarios y sus datos. Sus objetivos son:

Almacenar los nombres y las contraseas de los usuarios del sistema. Administrar los permisos de cada usuario segn el rol que tengan.

Hay que notar que el Director del Departamento, el Coordinador de Investigacin y la Jefatura Administrativa compartan la funcin de validar la planilla con los nuevos fondos. Por lo tanto, se deni un nuevo actor llamado Validador del cual los otros tres actores obtendran esta funcin. Por otro lado, estos actores y la Secretaria de Investigacin compartan la funcin de obtener la informacin sobre los saldos de los profesores y los giros que realizaban. Por esto se deni el actor Observador que permita que los actores pudieran compartir este objetivo en comn.

3.5. Casos de Uso

CU1: Calcular Fondos: Corresponde cuando el Coordinador de Investigacin calcula los nuevos fondos del mes. CU2: Validar Nueva Planilla Anual: La Secretaria recibe los nuevos fondos y con ellos genera una nueva planilla de fondos. Luego los validadores le agregan sus rmas y la Secretaria la imprime.

CU3: Revisar Actual Planilla Anual: Es la consulta de la ltima planilla validada para cualquier observador. Tambin se puede importar a una planilla Excel para manejarla e imprimirla.

CU4: Actualizar Fondos: Cuando se valida una nueva planilla, la Jefatura Administrativa actualiza los fondos segn los nuevos datos. CU5: Revisar Saldos y Cartolas: Se da cuando los profesores quieren realizar consultas sobre los saldos de sus fondos. Esto tambin incluye ver las cartolas con los cambios que han tenido en el tiempo. La Jefatura Administrativa puede revisar el saldo de cualquier profesor. La Jefatura Administrativa y el Director del Departamento pueden ver un resumen anual con los ujos de fondos.

CU6: Administrar Giros Personales: Consiste en que los profesores pueden crear peticiones de giros de fondos y ver el estado de cada giro. CU7: Ver Giros: Es la consulta de los observadores para ver las peticiones de giros que han realizado los profesores. CU8: Validar Giros: Cuando el Director del Departamento revisa una peticin de giro, el Coordinador de Investigacin puede agregar un comentario. Entonces el Director enva una comisin acadmica a la Jefatura, que la imprime para almacenarla. Luego la Jefatura descuenta los fondos necesarios del profesor que realiz el giro.

19

CU9: Ver Planillas Pasadas: Es una consulta para la Secretaria de Investigacin y la Jefatura Administrativa donde pueden ver la informacin de cualquier planilla validada. CU10: Actualizar Cuenta: Corresponde al manejo de las cuentas de usuario por parte de un administrador.

3.6. Casos de Uso Expandidos

Caso de Uso: Actores: Propsito: Descripcin: Tipo: Ref. Cruzadas:
CU1: Calcular Fondos Coordinador de Investigacin (I), Secretaria de Investigacin Calcular y enviar los nuevos fondos del mes. El Coordinador actualiza el sistema U-Papers y calcula los puntajes para asignar los nuevos fondos del mes. Luego se envan los resultados a la Secretaria de Investigacin. Primario y Esencial CU2

Curso Normal
Acciones del Sistema 2. El sistema despliega una lista con los nombres de los profesores y unos formularios para ingresar los respectivos montos.

Acciones de los Actores 1. El Coordinador actualiza el sitio de UPapers y calcula los nuevos fondos del mes. Despus ingresa al sistema (con su nombre de usuario y contrasea) e ingresa a la seccin para enviar estos clculos. 3. El Coordinador ingresa los montos e indica cuando termina. 5. El Coordinador conrma que desea enviar la informacin a la Secretaria de Investigacin.

4. El sistema muestra un resumen de los datos ingresados. 6. El sistema indica que la informacin se ha enviado correctamente.

Cursos Alternos
(2a) Si el sistema no despliega correctamente los nombres, puede enviar e-mails con los clculos a la Secretaria de Investigacin para que los usen de forma directa. Tambin tiene que avisar sobre este problema. (4a) Si el resumen no concuerda con los clculos, se puede elegir la opcin de volver al paso 3. (6a) Si la informacin no se envi correctamente, el sistema debe dar las opciones para reintentar el envo y de guardar la informacin para que pueda intentar enviarla en otro momento. (6b) El Coordinador puede volver a enviar la informacin, pero con la advertencia de que esta accin reemplazar la informacin enviada anteriormente. 20

Figura 3.1: Diagrama de Casos de Uso (volteada)

21

Caso de Uso: Actores: Propsito: Descripcin:

CU2: Validar Nueva Planilla Anual Secretaria de Investigacin (I), Validador Generar y validar la nueva planilla anual. La Secretaria recibe los nuevos fondos y con ellos genera una nueva planilla anual. sta se enva a la Jefatura Administrativa, al Director del Departamento y al Coordinador de Investigacin para la validacin (agregar rmas). La Secretaria recibe la nueva planilla validada y la imprime. Al imprimirla correctamente, el sistema asigna la nueva planilla como la actual planilla anual. Primario y Esencial CU1, CU3

Tipo: Ref. Cruzadas:

Curso Normal
Acciones del Sistema 2. El sistema muestra que ha recibido nuevos clculos de fondos. Incluye un resumen de los cambios en la planilla actual. Tambin muestra la opcin de visualizar las planillas nueva y actual.

Acciones de los Actores 1. La Secretaria ingresa al sistema (con su nombre de usuario y contrasea) e ingresa a la seccin para generar la nueva planilla.

3. La Secretaria indica que va a generar y enviar la nueva planilla a la Jefatura, al Director y al Coordinador. 5. Cada validador ingresa al sistema.

4. El sistema indica que la informacin se ha enviado correctamente.

6. El sistema muestra que se ha recibido una nueva planilla.

7. Cada validador indica que va a agregar una rma.

8. El sistema pide una conrmacin. Despus muestra que la planilla ha sido rmada exitosamente y enviada a la Secretaria de Investigacin.

9. La Secretaria ingresa al sistema.

10. El sistema muestra que se ha recibido la planilla rmada.

11. La Secretaria imprime la planilla y la ingresa a su registro histrico. 13. La Secretaria indica que se imprimi correctamente.

12. El sistema pregunta si se imprimi correctamente. 14. El sistema reemplaza la actual planilla anual con la nueva.

22

Cursos Alternos
(2a) Si no se han enviado nuevos fondos a la Secretaria, el sistema debe indicarlo y no mostrar las otras opciones. (2b) Si la Secretaria vuelve a recibir informacin de nuevos fondos puede volver a generar la nueva planilla, pero con la advertencia que se reemplazar la que est en proceso de validacin y que no contendr ninguna rma. (4a) Si el sistema indica que no se pudo generar la nueva planilla o que no se pudo enviar, repetir el caso de uso. Si el problema persiste, se puede imprimir la planilla y rmarla por escrito. Luego, el sistema debe ofrecer una forma de agregar la nueva planilla de forma manual para que reemplace a la actual. (8a) Si todava falta que alguien rme la planilla, el sistema no la enva a la Secretaria y muestra un mensaje indicando que faltan rmas. (8b) Si la planilla no se logr rmar, sta no se enva y se vuelve al paso 6. (12a) Si se necesita imprimir de nuevo la planilla, volver al paso 10. (14a) Si no se reemplaz la planilla actual se puede volver al paso 10, pero sin imprimir de nuevo la planilla nueva.

23

Caso de Uso: Actores: Propsito: Descripcin: Tipo: Ref. Cruzadas:

CU3: Revisar Actual Planilla Anual Observador (I) Mostrar la informacin de los fondos en el ao actual. Cualquier observador puede ingresar al sistema para revisar la actual planilla anual. Tambin se puede importar a una planilla Excel para manejarla e imprimirla. Primario y Esencial

Curso Normal
Acciones del Sistema 2. El sistema muestra la informacin de la planilla y una opcin para importarla a un archivo Excel.

Acciones de los Actores 1. El usuario ingresa al sistema (con su nombre de usuario y contrasea) e ingresa a la seccin para ver la planilla actual.

Cursos Alternos
(2a) Si es el mes de Enero y todava no se han registrado fondos, se debe mostrar la informacin del ao pasado.

Caso de Uso: Actores: Propsito: Descripcin:

CU4: Actualizar Fondos Jefatura Administrativa (I) Ingresar los nuevos fondos generados por las publicaciones en el sistema y almacenarlos para su uso. La Jefatura recibe los nuevos fondos y la nueva planilla generada. Una vez revisada la nueva planilla (con la posibilidad de compararla con la anterior), actualiza el sistema para que ingrese los nuevos puntajes (tanto en los estados de saldos como en las cartolas). Primario y Esencial CU3

Tipo: Ref. Cruzadas:

Curso Normal
Acciones del Sistema 2. El sistema muestra que se ha validado una nueva planilla. 4. El sistema muestra la planilla con las rmas y las opciones de compararla con la planilla anterior y aplicar los cambios en los fondos.

Acciones de los Actores 1. La Jefatura ingresa al sistema (con su nombre de usuario y contrasea). 3. La Jefatura ingresa a la seccin para actualizar los fondos.

5. La Jefatura selecciona aplicar los cambios en los fondos.

6. El sistema muestra que la operacin se ha realizado correctamente.

Cursos Alternos

24

Caso de Uso: Actores: Propsito: Descripcin:

CU5: Revisar Saldos y Cartolas Profesor (I), Jefatura Administrativa (I) Mostrar la informacin de los saldos de los profesores de forma remota. Los profesores pueden entrar en el sistema (ingresando un nombre de usuario y una contrasea) para revisar los saldos de sus respectivos fondos FII. Tambin pueden revisar las cartolas de sus fondos. El sistema permite mostrar estas cartolas segn el mes que elijan los usuarios. La Jefatura tiene acceso a esta informacin para todos los profesores. La Jefatura Administrativa y el Director del Departamento pueden ver un resumen anual con los ujos de fondos. Primario y Esencial

Tipo: Ref. Cruzadas:

Curso Normal
Acciones del Sistema 2. El sistema muestra los fondos FII actuales del usuario. Tambin se muestra la opcin de escoger un ao. 4. El sistema muestra la cartola del usuario en el ao que indic.

Acciones de los Actores 1. El usuario ingresa al sistema (con su nombre de usuario y contrasea) e ingresa a la seccin para ver su saldo. 3. El usuario puede escoger un ao (cuntas veces quiera) o salir de su cuenta.

Cursos Alternos
(2a) La Jefatura Administrativa y el Director del Departamento pueden elegir una opcin para ver un resumen en un determinado ao. Este resumen debe indicar el total de ingresos y gastos de cada profesor (con sus respectivas diferencias).

25

Caso de Uso: Actores: Propsito: Descripcin:

CU6: Administrar Giros Personales Profesor (I), Jefatura Administrativa, Director del Departamento Generar peticiones de giro de fondos FII y enviarlos a la Jefatura Administrativa. Los profesores pueden llenar formularios pidiendo un giro de fondos FII y enviarlos al Director y a la Jefatura Administrativa. Estos formularios deben incluir el nombre completo del usuario, la fecha, el monto y un comentario indicando las razones del giro. Tambin pueden ver los estados de sus respectivos giros. Estos estados corresponden a si el giro fue aceptado, rechazado o se encuentra en proceso de validacin. Cada uno incluye un comentario (principalmente para indicar la razn de rechazo). Tambin se incluye la opcin de borrar las peticiones aceptadas o rechazadas de sus propias listas (hacerlas invisibles). Primario y Esencial

Tipo: Ref. Cruzadas:

Curso Normal
Acciones del Sistema 2. El sistema muestra una lista con las peticiones que ha realizado (segn su conguracin de visibilidad). 4. El sistema muestra un formulario para ingresar un monto y un comentario (el nombre y la fecha se ingresan de forma automtica). Tambin muestra el saldo de fondos FII.

Acciones de los Actores 1. El profesor ingresa al sistema (con su nombre de usuario y contrasea) e ingresa a la seccin de peticiones de giros. 3. El profesor selecciona la opcin de generar una nueva peticin.

5. El profesor llena el formulario y enva la peticin.

6. El sistema indica que la peticin ha sido creada correctamente y que se ha enviado a la Jefatura Administrativa y al Director del Departamento.

Cursos Alternos
(2b) Si el usuario borr una peticin, el sistema puede ofrecer la opcin de recuperar las peticiones ms recientes (hacer visibles las del ltimo mes). (6a) El monto y el comentario son obligatorios, por lo que si estn vacos se vuelve al paso 2. (6b) Si el monto ingresado supera la cantidad de fondos FII actual, el sistema debe pedir una conrmacin por parte del usuario. (6c) Si no se crea correctamente la peticin, se vuelve al paso 2, manteniendo lo llenado en el formulario. (6d) Si no se enva correctamente la peticin, sta se elimina y se vuelve al paso 2 manteniendo lo llenado en el formulario.

26

Caso de Uso: Actores: Propsito: Descripcin:

CU7: Ver Giros Observador (I) Mostrar la informacin de todas las peticiones de giros de fondos FII que han realizado los profesores. Los observadores pueden ver una lista con las peticiones de giro que han realizado los profesores. Tambin tienen la opcin de borrar, de sus propias listas, las que han sido aceptadas o rechazadas (hacerlas invisibles). Primario y Esencial CU6

Tipo: Ref. Cruzadas:

Curso Normal
Acciones del Sistema 2. El sistema muestra una lista con las peticiones que se han realizado (segn su conguracin de visibilidad). Cada tem muestra el estado de la peticin y una opcin para borrarla (si es que el estado es aceptada o rechazada).

Acciones de los Actores 1. El usuario ingresa al sistema (con su nombre de usuario y contrasea) e ingresa a la seccin para ver las peticiones.

3. El usuario puede borrar una peticin (cuntas veces quiera) o salir de su cuenta.

4. El sistema muestra la lista con la peticin borrada.

Cursos Alternos
(3a) Si el usuario borr una peticin accidentalmente, el sistema puede ofrecer una opcin para recuperar las peticiones ms recientes (hacer visibles las del ltimo mes).

27

Caso de Uso: Actores: Propsito: Descripcin:

CU8: Validar Giros Jefatura Administrativa, Director del Departamento (I), Coordinador de Investigacin Validar las peticiones de giros de fondos FII que realizan los profesores. El Director, al revisar una peticin de giro (incluyendo el saldo de fondos FII), puede enviarla al Coordinador de Investigacin. Luego el Coordinador puede agregar un comentario mostrando su aprobacin o rechazo y el Director tiene que aceptar o rechazar la peticin. Entonces el Director enva una comisin acadmica a la Jefatura, que la imprime para almacenarla. Luego la Jefatura descuenta los fondos necesarios del profesor que realiz el giro. Primario y Esencial CU6, CU7

Tipo: Ref. Cruzadas:

Curso Normal
Acciones del Sistema 2. El sistema muestra la informacin de la peticin junto con el saldo actual de fondos FII del usuario. Tambin muestra las opciones de aceptar, rechazar o enviar al Coordinador.

Acciones de los Actores 1. El Director ingresa al sistema (con su nombre de usuario y contrasea) y selecciona una peticin de la lista de peticiones.

3. El Director revisa la informacin y acepta la peticin. 5. El Director comienza el proceso para que crear una formalizacin de la peticin (comisin acadmica), la cual se enva a la Jefatura Administrativa. 6. La Jefatura recibe la formalizacin, ingresa al sistema y selecciona la peticin correspondiente. 8. La Jefatura indica que se ha recibido correctamente la formalizacin.

4. El sistema indica que la operacin se ha realizado correctamente.

7. El sistema muestra la informacin de la peticin y pregunta si se ha recibido correctamente la formalizacin. 9. El sistema descuenta los fondos del saldo del profesor que envo la peticin de giro. Luego indica que la peticin fue aceptada correctamente.

28

Cursos Alternos
(3a) Si se decide rechazar la peticin, el sistema debe mostrar una forma de agregar un comentario para justicar el rechazo. (3b) La peticin se puede enviar al Coordinador de Investigacin. ste tiene que agregarle un comentario. (4a) Si ocurre un error, se vuelve al paso 2. (9a) Si el sistema no realiz correctamente la operacin, se vuelve al paso 7.

Caso de Uso: Actores: Propsito: Descripcin: Tipo: Ref. Cruzadas:

CU9: Ver Planillas Pasadas Jefatura Administrativa (I), Secretaria de Investigacin (I) Consultar las planillas que estn almacenadas en el registro histrico. La Secretaria de Investigacin y la Jefatura Administrativa pueden acceder a cualquier planilla que haya sido validada y guardada en el registro. Primario y Esencial

Curso Normal
Acciones del Sistema 2. El sistema pide que se ingrese un mes y un ao.

Acciones de los Actores 1. El usuario ingresa al sistema (con su nombre de usuario y contrasea) y accede al registro de planillas. 3. El usuario ingresa el mes y el ao que quiere consultar.

4. El sistema muestra la informacin de la planilla que se valid en esa fecha.

Cursos Alternos

29

Caso de Uso: Actores: Propsito: Descripcin:

CU10: Actualizar Cuenta Administrador (I) Congurar las cuentas de los usuarios para que puedan interactuar con el sistema. El Administrador puede crear la cuenta para un usuario al ingresar el nombre de usuario, el nombre completo, el rol y la contrasea. Despus se enva la informacin al usuario. Los usuarios pueden entrar en el sistema para cambiar su contrasea. Slo el administrador puede cambiar nombres de usuario, nombres completos y roles (con la posibilidad de enviar la informacin a los respectivos usuarios). Primario y Esencial

Tipo: Ref. Cruzadas:

Curso Normal
Acciones del Sistema 2. El sistema muestra un formulario para ingresar el nombre de usuario, el nombre completo, el rol y la contrasea. 4. El sistema muestra que la cuenta ha sido creada correctamente y que la informacin se ha enviado al usuario.

Acciones de los Actores 1. El Administrador ingresa al sistema e ingresa a la seccin para administrar las cuentas de usuario. 3. El Administrador ingresa los datos e indica que termin.

Cursos Alternos
(1a) El Administrador tambin puede ver una lista con los usuarios ya registrados para cambiar la conguracin de alguna cuenta. (4a) Los datos son obligatorios por lo que si alguno es vaco, el sistema debe mostrar un mensaje de error y volver al paso 2. (4b) Los roles para la Secretaria de Investigacin, el Coordinador de Investigacin, el Director del Departamento y la Jefatura Administrativa son nicos. Por lo que el sistema debe mostrar un mensaje de error cuando se intenta duplicar alguna de estas cuentas. (4c) Si la informacin no se envi correctamente, el Administrador debe contactar al usuario directamente.

3.7. Diagramas de Secuencia

Considerando cada caso de uso se agregaron distintos diagramas de secuencia para mostrar el orden de los eventos. En todas las secuencias se deni un objeto Portal que representaba la interfaz para interactuar con el sistema. Esto permiti diferenciar las acciones de los actores y de los objetos internos del sistema. En el caso de uso CU1 se deni un objeto llamado Formulario Fondos. Este objeto tena la nalidad de permitir la entrada de los datos al sistema. Estos datos correspondan a los

30

fondos calculados por el Coordinador de Investigacin. La informacin era almacenada en este objeto, pero se agreg la posibilidad de editarla en caso que se quisieran corregir algunos datos.

Figura 3.2: Diagrama de Secuencia del Caso de Uso CU1

En CU2 la Secretaria ve los cambios en Formulario Fondos y crea un nuevo objeto llamado Planilla. ste representaba una nueva planilla de fondos que deba ser validada. La creacin de este objeto tambin borraba cualquier otra planilla que se encontrara en proceso de validacin. Una vez creada, los encargados de validar tenan que agregar sus rmas al objeto. Cuando era completada, la planilla se enviaba a la Secretaria para que la imprimiera y almacenara el objeto en un registro (Registro Planillas). La informacin de Formulario Fondos era borrada despus de esto. En CU3 y CU9 slo se realizaban consultas al registro de planillas por lo que no fueron aagregados sus diagramas. En CU4 la Jefatura realizaba un par de consultas sobre el registro de planillas para ver si haban nuevos fondos. Luego actualizaba los datos de un registro que contena la informacin de los fondos de los profesores (Registro Saldos). En CU5 slo se realizaban consultas sobre este registro pero haba que tomar en cuenta que la Jefatura Administrativa tena el permiso de ver el saldo de cualquier profesor. Adems el Director del Departamento y la Jefatura Administrativa podan ver un resumen global indicando los ujos de fondos del ao. En CU6 y CU7 se hicieron diagramas describiendo el manejo del registro que almacenaba las peticiones de giros de fondos (Registro Peticiones). Principalmente contenan funciones

31

Figura 3.3: Diagrama de Secuencia del Caso de Uso CU2 (volteada)

para manejar una lista personal de datos y la funcin para que los profesores pudieran crear sus peticiones. En el diagrama para CU8 se muestra cmo se validaba cada peticin. Primero, el Director consultaba la informacin necesaria para revisar una peticin. Se poda tomar la alternativa de enviarla al Coordinador de Investigacin para que agregara su opinin. Despus el Director poda rechazar la peticin, pero en caso de aceptarla se empezaba el proceso de formalizacin. Este proceso se consider fuera del alcance del sistema, por lo que la copia de la formalizacin se enviaba directamente a la Jefatura Administrativa. Con esto la Jefatura le indicaba al sistema que descontara la cantidad del giro del registro de fondos al profesor

32

Figura 3.4: Diagrama de Secuencia del Caso de Uso CU4

correspondiente. Finalmente est el caso de uso CU10 que slo indica funciones para manejar un sistema de usuarios. Estas funciones son comunes y ya estn incluidas en varias plataformas, por lo que el diagrama es redundante y no es necesario agregarlo. Pero hay que notar que borrar usuarios en el sistema, se consider como dejarlos inactivos (o invisibles).

3.8. Diagramas BPMN

Como se veric en las entrevistas, se identicaron dos procesos entre los que participaban los actores. Primero fue necesario tratar el manejo de la planilla Excel que contena los ingresos de los fondos FII. A este proceso se le llam Ingreso de Nuevos Fondos. Por otro lado, haba que administrar cada formulario que realizaba cada profesor para pedir un giro de fondos. Por lo tanto, estas tareas fueron juntadas en un proceso llamado Validacin de Giro de Fondos. El primer proceso sigue los pasos de las secuencias descritas en los casos de uso CU1, CU2 y CU4. Primero est la tarea inicial de calcular los nuevos fondos por parte del Coordinador

33

Figura 3.5: Diagrama de Secuencia del Caso de Uso CU8 (volteada)

de Investigacin. Como l contaba con su propio programa, el sistema slo deba encargarse de almacenar la informacin y enviarla a la Secretaria de Investigacin. En caso de error, el sistema podra enviar un correo electrnico con la informacin para que la Secretaria la ingresara de forma manual. Como siguiente tarea, el sistema simula la creacin de la planilla Excel con los ingresos. La planilla tena que incluir tanto la informacin recibida como la informacin anterior del mismo ao. Despus se divide el ujo en tres tareas simultneas que corresponden a validar y rmar la planilla de fondos. Despus siguen las tareas donde la Secre-

34

taria de Investigacin recibe la planilla rmada, la imprime y despus el sistema la almacena en su propia base de datos. En esta etapa se enva una seal a la Jefatura Administrativa para que realice las ltimas tareas donde se actualizan los saldos de los profesores. Haba un caso especial en donde la planilla poda ser corregida. Por lo tanto, se decidi que este proceso se poda cancelar y empezar de nuevo con los valores corregidos. Para hacer ms fcil la correccin se permiti reutilizar la informacin almacenada en las primeras etapas. Entonces era necesario que se mantuviera una instancia de este proceso. Por otro lado, surgi otro problema. El proceso tena que mantenerse bloqueado cuando la planilla se registraba en la base de datos. Esto se deni para mantener un orden correcto al actualizar los saldos de los profesores. El segundo proceso sigue los pasos de las secuencias descritas en los casos de uso CU6 y CU8. Como tarea inicial se deni cuando los profesores piden un giro de fondos. El sistema podra mostrar un formulario parecido al que se entregaba a la Jefatura Administrativa. En la siguiente tarea, el Director del Departamento revisa una peticin y puede decidir si enviarla al Coordinador de Investigacin para que realice las tareas de agregar comentarios y detalles. Despus est la tarea de decidir si se acepta la peticin de giro. Si se rechaza, el sistema slo debe registrarla, pero si se acepta el sistema debe registarla y enviarla a su formalizacin. Como esta ltima tarea se realiza afuera del D.C.C. y no se tiene mucha informacin sobre ella, se consider como un sub-proceso. Finalmente estn las tareas donde se recibe la formalizacin y se registra la peticin como aceptada.

3.9. Posibles soluciones

Como se mencion en los objetivos, se construy un sistema de informacin administrativa. Para este caso, lo ms adecuado era un sistema administrador de workow. Principalmente porque era necesario denir el orden de las actividades de los dos procesos principales mencionados anteriormente. Tambin se poda aprovechar la ventaja de que pueden soportar la denicin de los actores y las secuencias denidas anteriormente. Adems con un sistema utilizando este tipo de software se podan monitorear los procesos sin perder informacin. Entre los distintos tipos de sistemas de workow, result ms recomendable usar un sistema de workow de colaboracin. Varias de las tareas que deban realizar los actores correspondan a revisar y validar documentos. Adems cuenta con la ventaja de que se centra en los documentos y su seguimiento. En este caso los documentos correspondan principalmente a las planillas de fondos FII y a las peticiones de giros de fondos.

3.9.1. Opciones de software de workow

Oracle Workow (Oracle Corporation): Cuenta con varias aplicaciones de Oracle como una herramienta grca para denir los procesos de negocio, servidores para la instalacin y la base de datos de Oracle. Pero parece que no cuenta con un diseador de formularios. Algunas

35

de las ventajas que tiene es que se enfoca en aplicaciones para Internet y en noticaciones de eventos. Adems permite monitorear los procesos [9]. Ultimus Adaptative BPM Suite (Ultimus): Tiene un diseador grco de procesos y para formulario en navegadores. Adems permite conectar con bases de datos a travs del driver ODBC. Permite simular y monitorear procesos. Sin embargo, no funciona con Linux y no permite reutilizar objetos [6]. ActionWorks Metro (Action Technologies): Tiene un diseador grco y un administrador de documentos. Funciona con la base de datos Microsoft SQL Server y tiene herramientas para generar reportes [10]. Joget Open Source Workow (Joget): Tiene diseadores grcos para procesos, formularios y tablas de datos. Funciona en servidores Glasssh y Tomcat. Se puede conectar con las bases de datos Oracle, MySQL y Microsoft SQL Server. El manejo se realiza a travs de una interfaz Web. Adems como es open source, la pgina cuenta con una comunidad para resolver errores [11].

36

Figura 3.6: Diagrama BPMN del proceso Ingreso de Nuevos Fondos (volteada)

37

Figura 3.7: Diagrama BPMN del proceso Validacin de Giro de Fondos (volteada)

38

4. Diseo
4.1. Sistema Administrador de Workow
Para la construccin del sistema se decidi utilizar la plataforma Joget Open Source Workow. Se eligi principalmente porque contaba con las ventajas de un middleware. Esto quiere decir que permita la interaccin entre distintos componentes y la conversin de parmetros entre distintos lenguajes de programacin. Adems en esta plataforma se podan implementar servicios comunes y reusables. Este software estaba diseado para construir aplicaciones Web de tal forma que soportara administracin de procesos y formularios. Su interfaz se utilizaba a travs de un navegador Web por lo que un administrador poda acceder de forma remota sin tener que instalar software adicional. Principalmente estaba basado en los lenguajes de programacin Java y XML, los cuales funcionan en varios sistemas operativos y permitan exportar fcilmente las aplicaciones. Adems poda funcionar en servidores Apache Tomcat y Glasssh. Tambin poda funcionar con varias bases de datos incluyendo MySQL, Oracle y Microsoft SQL Server y contaba con las ventajas de las tecnologas Spring y Hibernate. Para la administracin de procesos contaba con un diseador de workow llamado JPED que se basaba en el modelo BPM (Business Process Management) y un motor de workow Enhydra Shark. Tena un conjunto de aplicaciones para manejar la capa de presentacin de manera exible al usar los lenguajes de programacin HTTP, JavaScript, AJAX y JSON. Esto tambin permiti integrar otras tecnologas Web como los lenguajes PHP y .NET [11]. Finalmente, el software inclua una arquitectura de plugins dinmicos con los que se podan extender y adaptar funcionalidades. Su objetivo era integrar cualquier tipo de informacin como una caracterstica comn sin romper el ncleo fundamental del software. Se podan implementar de dos maneras: como aplicaciones Java estndar o envueltas en un envoltorio OSGi. Esta aplicacin contaba con algunas desventajas que afectaron la implementacin. Su arquitectura de plugins dinmicos fue muy til, pero su cdigo fuente no estaba muy documentado. Por esto crear nuevas funcionalidades pudo ser muy costoso y fue ms recomendable basarse lo que ya estaba implementado. Otro problema era la interfaz porque para crear procesos no contaba con una funcin para duplicar elementos. Es decir que no se podan reutilizar elementos como formularios o tablas y haba que crearlos de nuevo. Por ltimo era posible agregar cdigos de programacin en la interfaz, pero a travs de un cuadro de texto.

39

Esto result muy incmodo y fue mejor trabajar con tales cdigos de forma separada en un ambiente distinto.

4.2. Arquitectura Fsica

El sistema cont con una arquitectura de cliente-servidor. Esta arquitectura permite ofrecer software como servicios a travs de Internet por lo que el sistema poda actuar de forma remota. En particular, la arquitectura del sistema tena dos niveles (2-tier) porque centralizar la informacin formaba parte de la solucin. El primer nivel consisti en varios clientes livianos. Para que el sistema funcionara de forma remota, la capa de presentacin tena que estar formada por aplicaciones que pudieran funcionar en los computadores de los usuarios. Lo ms recomendable era que estas aplicaciones funcionaran en navegadores Web para que los usuarios no tuvieran que instalar nada. El segundo nivel lo form un servidor manejando las dems capas. stas podan compartir la misma mquina ya que la informacin se iba a almacenar de forma centralizada en el Departamento. De esta forma result ms fcil la mantencin del sistema ya que se trata de forma local. Puede que el servidor manejara la mayora de la carga, pero la cantidad de usuarios se consider baja (menos de 35 usuarios como mximo). La capa de presentacin correspondi a la interfaz que manejaban los usuarios. Slo se poda acceder a esta interfaz a travs de un navegador Web como Internet Explorer y Mozilla Firefox. Los navegadores interactuaban con un conjunto de aplicaciones basados en lenguajes de programacin HTTP, JavaScript, AJAX y JSON. Las capas de administracin lgica y procesamiento de aplicacin se establecieron en un servidor que pudiera soportar el software Joget Workow. El servidor deba ser capaz de soportar aplicaciones Java. En este caso se us un servidor Apache Tomcat 6.0.35 instalado en un sistema operativo Linux en el D.C.C. Esta capa tambin incluy los plugins implementados. Estos plugins tuvieron el objetivo de agregar lgica de acceso a la base de datos y otras herramientas para mejorar la capa de presentacin. La capa de base de datos se ubic en el mismo servidor. En este caso se us una base de datos MySQL 5.1.63 (sistema operativo Linux). Se escogi esta base de datos por sus funciones agregadas para calcular sumas, agrupar y ordenar datos. Tambin por sus funciones especiales para actualizar e insertar datos con condiciones.

4.3. Arquitectura Lgica

El sistema deba funcionar de tal forma que se pudieran realizar los procesos y que se pudieran realizar las distintas consultas para un correcto seguimiento. Todas las acciones que

Explorer versin 8 y Mozilla Firefox versin 17.0.1. No se comprob por completo, pero el navegador Google Chrome tambin pareca funcionar correctamente.
40

1 Internet

Figura 4.1: Diagrama de la Arquitectura Fsica (volteada)

41

se realizaban a travs del sitio Web deban consultar o actualizar la base de datos de forma consistente. Cada accin estaba sujeta a los distintos permisos que tenan los actores. Para identicar estos permisos, el sitio us un sistema de identicacin de usuarios que reciba un nombre y una contrasea. En las guras 4.2 a 4.7 se pueden observar los diagramas de ujo que muestran las acciones que poda realizar cada actor. La Jefatura Administrativa tena permiso para ver cualquier planilla de fondos almacenada en la base de datos. Tambin poda imprimirla si era necesario. Para actualizar los saldos de los profesores tena primero que consultar la ltima planilla vlida. En cuanto a las planillas que an no eran vlidas, poda revisarla y rmarla en su debido momento. Adems poda revisar las cartolas de cualquier usuario y corregir su ingreso inicial del ao (esto incluye ver el resumen de los saldos). Por otro lado poda consultar, borrar y recuperar las peticiones de giros de fondos. En este caso, las acciones borrar y recuperar se reeren respectivamente a volver invisible o visible las peticiones ya que un usuario slo controlaba su propia lista. Finalmente, cuando se terminaba la formalizacin de una peticin, se tena el permiso para actualizar el saldo correspondiente.

Figura 4.2: Diagrama de Flujo con las tareas de la Jefatura Administrativa La Secretaria de Investigacin tambin poda consultar e imprimir cualquier planilla de la base de datos. Tambin poda manejar su lista de las peticiones de giro con las mismas funciones de consultar, borrar y recuperar. Pero tena que encargarse de la creacin de las planillas para lo cual primero deba consultar informacin de la base de datos (en Formulario de Fondos se almacena la informacin de los nuevos ingresos). Cuando una planilla de fondos era creada, poda revisarla en cualquier momento. Cuando era validada deba revisarla e imprimirla para despus almacenarla en la base de datos (tambin se vaciaba la informacin de Formulario de Fondos). El Coordinador de Investigacin tena permiso para consultar la ltima planilla vlida.

42

Figura 4.3: Diagrama de Flujo con las tareas de la Secretaria de Investigacin

Tambin poda revisar y rmar la planilla en validacin. Adems tena las mismas funciones para manejar su lista de peticiones de giros. Pero tena la funcin de evaluar las que les eran enviadas. Por otro lado, tena la funcin de agregar o modicar los nuevos ingresos (a travs del objeto Formulario de Fondos).

Figura 4.4: Diagrama de Flujo con las tareas del Coordinador de Investigacin

El Director del Departamento tena los mismos permisos que el Coordinador de Investigacin excepto para modicar los nuevos ingresos. Sin embargo, tena permiso para ver un resumen de los saldos de los profesores. Los profesores tenan las mismas funciones para manejar sus respectivas listas de peticiones de giros. Adems cada profesor poda crear sus propias peticiones con la informacin de sus saldos a la vista. Tambin podan ver sus propias cartolas y no las de otras cuentas. Finalmente, el Administrador slo tena autorizacin para consultar y cambiar la informacin de los usuarios. No se le agregaron funciones para borrarlos porque se almacenaban distintos registros en la base de datos relacionados con sus nombres.

43

Figura 4.5: Diagrama de Flujo con las tareas del Director del Departamento

Figura 4.6: Diagrama de Flujo con las tareas de Profesor

Figura 4.7: Diagrama de Flujo con las tareas de Administrador

4.4. Base de Datos

La base de datos fue una sola y se instal en el mismo servidor. Esta base de datos guarda toda la informacin sobre los procesos y los usuarios que maneja el software Joget Workow. Se agregaron nuevas tablas para adaptar la lgica de los procesos descritos anteriormente. Estas tablas principalmente sirvieron para almacenar los documentos que uan en los procesos y para manejar la lgica de los saldos de los profesores. En la gura 4.8 se muestra un modelo relacional lgico de las tablas (en la implementacin es distinta). Varias tablas estn relacionadas con la informacin o, de forma ms especca, con la tabla Usuario. Esta tabla ya est implementada en el software (bajo otro nombre). Adems de almacenar la informacin de los usuarios, tambin almacena sus contraseas para ingresar al

44

Figura 4.8: Modelo Relacional de la Base de Datos

45

sitio. Tambin guarda un atributo

activo

que sirve para indicar si un profesor todava recibe

fondos del D.C.C.. No se encontr recomendable borrar a los usuarios porque poda ser posible que pudieran tener registros en las otras tablas. El atributo

tipo

est implementado de otra

manera, pero tiene por objetivo indicar el tipo de actor al que corresponde un usuario. La tabla FormularioFondos representa un objeto mencionado anteriormente en los diagramas de secuencia. Sirve en las primeras tareas del proceso Ingreso de Nuevos Fondos. Su funcin es almacenar los nuevos ingresos que el Coordinador de Investigacin enva a la Secretaria. Estos dos actores deben diferenciar los ingresos en dos tipos: ingreso actual y correcciones que no fueron contados el ao pasado. Para esto sirve el atributo puede tener dos valores. Adems el atributo

mes

tipo

que

(enumerados del 0 al 11) sirve para que una

planilla pueda registrar ingresos en ms de un mes como ocurre entre Enero y Febrero. La tabla Planilla almacena cada planilla que se valida. Como el proceso Ingreso de Nuevos Fondos se realiza cada mes, la llave primaria corresponde a los atributos atributos

mes

ao.

Para implementar un servicio Web que permitiera descargar las planillas, se denieron los

archivo, tipo

tamao

que indican respectivamente la informacin en un archivo

Excel, el tipo de archivo (en la implementacin siempre es application/vnd.ms-excel) y el tamao del archivo en

bytes.

La tabla Celda sirve para mostrar rpidamente la informacin de su respectivo archivo Excel. Es posible que se puedan presentar incongruencias, pero consultar esta tabla ahorra ms memoria del servidor que leer directamente el archivo en cada consulta. De la misma forma que en la tabla FormularioFondos, hay un atributo diferenciar ingresos del ao actual o del pasado. El atributo una planilla en comparacin a la anterior. La tabla Firma se usa para almacenar las imgenes de las rmas. Como se describi anteriormente las planillas deben recibir las rmas del Coordinador de Investigacin, del Director del Departamento y de la Jefatura Administrativa. Con las imgenes la creacin de la planilla es automtica y los que la validan slo tienen que indicar su aprobacin. La tabla Planilla_has_Firma sirve slo para registrar los actores que participan en la validacin. Las tablas Cartola y Detalle sirven para almacenar cada ingreso y gasto que tienen los fondos FII. Se podra haber implementado con slo una tabla, pero surgi un requisito inesperado durante el desarrollo. Era posible que algunas cartolas tuvieran que recibir correcciones en aos posteriores. Por ejemplo, era posible que una cartola del ao 2011 tuviera un detalle (o correccin) con fecha del ao 2012. Al principio la tabla Saldo se pens usar como una tabla adicional para no calcular la diferencias entre ingresos y gastos en cada consulta. Pero despus surgi un problema. Haba que considerar el arrastre del ao pasado como un ingreso y ste poda ser distinto a la diferencia entre ingresos y gastos (poda estar sujeto a correcciones). Por lo tanto se deni que el atributo

tipo con el mismo propsito de nuevo (que es un nmero binario)

se usa por razones de presentacin. Sirve para ver cules son los cambios que ocurrieron en

inicial

monto

indicara la diferencia entre ingresos y gastos del ao y el atributo

se guardara como un ingreso inicial del ao. Entonces el saldo total correspondera a

la suma entre los atributos

monto

inicial.

46

La tabla Ingreso_Temporal sirve para llevar la cuenta de los fondos caducos, es decir que se recibieron hace ms de un ao. Por cada ingreso se aumenta el atributo

monto

del

ao correspondiente y por cada gasto se descuentan a los que corresponden a aos menores. Aunque antes de este clculo se descuentan los fondos caducos y se agregan como un gasto ms. La tabla Peticion representa las peticiones de giros de fondos que realizan los profesores. Est tabla es automticamente generada por el software (bajo otro nombre). El atributo

estado

indica en cul etapa del proceso Validacin de Giro de Fondos se encuentra. Este

atributo es importante porque cada profesor iba a tener acceso a sus peticiones y necesitaban realizar un seguimiento. Los valores que puede tener este atributo representan las siguientes situaciones:

VALIDANDO: Signica que la peticin est en las primeras tareas del proceso donde el Director del Departamento y el Coordinador de Investigacin la evalan. FORMALIZANDO: Signica que la peticin entr en el subproceso de formalizacin. RECHAZADO: Signica que la peticin ha terminado el proceso, pero sin agregar gastos a los fondos del profesor. ACEPTADO: Signica que la peticin ha terminado el proceso pasando por el subproceso de formalizacin y agregando gastos a los fondos del profesor.

El software cuenta con una herramienta para visualizar cada peticin de giro que se ha efectuado. Pero segn los requisitos, los usuarios slo quieren ver las peticiones que les interesan. Por esto, se decidi implementar la tabla Visibilidad para mostrar distintas peticiones a distintos usuarios. Esto se maneja con el atributo

visible

que es un nmero binario. Adems resulte 0). Su relacin con la

se pueden borrar automticamente las peticiones que tengan ms de un mes y que no sean visibles por ningn usuario (es decir, que la suma de aceptadas con sus respectivos gastos.

visible

tabla Detalle se hizo slo por razones de implementacin para enlazar las peticiones de giro

4.5. Diseo de Navegacin del Sistema

La navegacin del sitio depende del tipo de usuario que est interactuando con el sistema. Primero se accede a una pgina de bienvenida que explica de qu trata el sitio. Despus se accede a un formulario para ingresar el nombre de usuario y la contrasea (el cuadro Login en la gura 4.9). Luego se muestra un panel de control con las opciones dosponibles segn el tipo de usuario. La Administracin del D.C.C. (los usuarios que no son profesores) pueden ver los procesos pendientes que tienen que revisar. Esta seccin funciona como una bandeja de entrada que muestra las tareas que se deben realizar. De ah se muestra el formulario para realizar la tarea. Estos usuarios tambin pueden consultar las planillas de fondos ingresadas al sistema. Se muestran tanto las planillas almacenadas en la base de datos como las que se encuentran en

47

validacin. Tambin pueden descargar cada planilla en archivos Excel. La Jefatura Administrativa y los profesores pueden consultar los saldos y cartolas. La Jefatura Administrativa puede ver los saldos de cualquier profesor, pero los profesores estn restringidos a ver slo sus respectivos saldos. La Jefatura Administrativa y el Director del Departamento pueden consultar el resumen de saldos. Pueden consultar los resmenes de distintos aos. Todos los usuarios pueden ver una lista con las peticiones de giros de fondos. Los profesores estn restringidos a slo ver sus respectivas peticiones. Adems cada usuario puede borrar (hacer invisibles) peticiones de su propia lista y ordenarla segn sus gustos. Tambin pueden ver los detalles de cada peticin. Adems todos los usuarios pueden ver su conguracin de usuario para cambiar sus respectivas direcciones de correo electrnico y sus contraseas. Los usuarios que rman las planillas de fondos tambin pueden subir una imagen para denir sus respectivas rmas. Para comenzar el proceso Ingreso de Nuevos Fondos, el Coordinador de Investigacin debe acceder a la seccin para agregar nuevos fondos. Por los cambios en los requisitos, la Secretaria de Investigacin tiene el permiso para entrar a esta seccin. Por otro lado, para comenzar el proceso Validacin de Giros de Fondos, los profesores pueden acceder a la seccin para pedir un giro de fondos. La aplicacin Joget Workow cuenta con una interfaz distinta para la administracin de usuarios. Esto no se considera en la gura 4.9. Tampoco se considera que al responder un formulario se muestra un texto de conrmacin (si una tarea se realiz correctamente) y despus se vuelve a la pgina principal.

Figura 4.9: Diagrama de Navegacin del Sistema

48

4.6. Diseo de Interfaz de Usuario

Como base se us el esquema que viene con la aplicacin Joget Workow y se le hicieron pequeas modicaciones. Este esquema consiste en que cada pgina tiene un encabezado, un men principal con enlaces en la parte izquierda y el contenido en la parte central y derecha (tambin se puede agregar un pie de pgina, pero no se us en este caso). El encabezado contiene un ttulo, la fecha actual y un enlace para ingresar el nombre de usuario y la contrasea (login) o salir (logout). El men principal se divide en secciones para mostrar distintos enlaces a distintos usuarios. Este men y el contenido fueron cambiando en cada iteracin de acuerdo a los requisitos y problemas encontrados durante el desarrollo. Las guras se enfocan principalmente en el contenido para mostrar mejor los detalles de la interfaz.

4.6.1. Pgina de Bienvenida y Login

En la primera iteracin se cre una pgina de bienvenida con un texto simple para explicar los objetivos del sitio. Mientras que la pgina de login contena un simple formulario para ingresar el nombre de usuario y la contrasea. Al ingresarlos se volva a la pgina de bienvenida, pero el men principal mostraba los enlaces correspondientes. Pero en las pruebas surgi un problema. No todos los usuarios encontraban el enlace en el encabezado para acceder a la pgina de login. Por lo tanto se decidi implementar un formulario de login en la pgina de bienvenida. De esta forma slo haba que actualizar una pgina en vez de navegar entre dos. Esto mostr mejores resultados en las otras iteraciones. Curiosamente el enlace de logout no caus los mismos problemas a pesar de tener la misma ubicacin.

Figura 4.10: Pgina de Bienvenida

4.6.2. Pgina de Saldos y Cartolas

En la primera iteracin se implement esta pgina con un par de cajas de seleccin (selectbox) para ingresar un nombre de usuario y un ao. Los profesores slo podan seleccionar el ao porque se utilizaron sus propios nombres de usuario para el primer parmetro. Como resultado ms abajo se mostraba una tabla con la cartola correspondiente a los parmetros.

49

Cada la de la tabla tena una fecha, un ttulo y un monto de ingreso o de gasto. Al nal se mostraba el total de ingresos, el total de gastos y la diferencia. Para acceder a esta pgina, el men principal tena un enlace llamado Cartolas de Fondos. Despus de las pruebas se decidieron realizar los siguientes cambios. Era posible que los usuarios pudieran perderse, as que entre el formulario y la tabla se agreg un texto que mostrara los parmetros ingresados. Esto sirvi como una forma de agregar el estado actual de la consulta. Por otro lado, haba que agregar el saldo nal del ao pasado en la tabla como un ingreso. As se calculara bien el saldo del ao. Algunos usuarios no entendan el enlace del men principal porque confundan los trminos planillas y cartolas. As que se cambi el nombre del enlace por Saldos y Cartolas. Despus de probar en la segunda iteracin, se decidi agregar una caracterstica ms a la tabla. Consiste en una columna adicional que detecta si un gasto es un giro aceptado y entrega en enlace para ver directamente sus detalles. Para esto sirve la relacin de las tablas Detalle y Visibilidad en la base de datos.

Figura 4.11: Vista de una Cartola

4.6.3. Pgina de Resumen de Saldos

Esta pgina surgi de un requisito que se deni en la segunda iteracin. Al igual que en la pgina anterior se agreg un selectbox para seleccionar el ao. Ms abajo se mostraba una tabla donde cada la tena un nombre de usuario, el total de ingresos, el total de gastos, el saldo inicial del ao, el saldo nal y la diferencia entre ingresos y gastos. Todas las columnas (excepto la de los nombres) mostraban sus sumas totales abajo de la tabla.

50

Despus de probar esta pgina se encontr una nueva caracterstica. La Jefatura Administrativa lo vea como una oportunidad para ver cada caso en que se sobrepasaba el saldo inicial del ao (segn el lmite de ingresos). Por lo tanto a cada la se agreg un enlace para acceder a una herramienta que corrigiera el saldo inicial. Esta herramienta slo pide que se agregue el nuevo valor que reemplazar el saldo inicial. Por otro lado, el Director del Departamento quera quitar la columna de diferencia y cambiar el orden de las otras columnas. As que se copi la pgina y se le cambi la vista.

Figura 4.12: Vista de un Resumen de Saldos

4.6.4. Pgina de Planillas

En la primera iteracin se deni la planilla de fondos como una tabla donde cada la tena un nombre de usuario y los ingresos de los doce meses. Para mostrar una lista de cambios se agregaba un cuadro de texto con esa informacin. Adems cuando corresponda se agregaba un botn para descargar la planilla en un archivo Excel. En el men principal se podan consultar las planillas a travs de dos enlaces. Uno se llamaba ltimas Planillas y el otro se llamaba Planillas de Fondos. El primer enlace mostraba la ltima planilla vlida y la planilla que se encontraba en validacin (si es que haba). El segundo mostraba dos selectbox para seleccionar un mes y un ao. Ms abajo mostraba la planilla correspondiente. Al probar este formato surgieron muchos problemas. Primero, los usuarios no se jaban mucho en el cuadro de texto que mostraba los cambios. Para esto se decidi marcar los nmeros nuevos de la planilla con color azul. Segundo, una tabla no era suciente porque tambin haba que diferenciar los ingresos del ao actual y los atrasados del ao pasado. Se agreg la nueva tabla, pero este mtodo era propio del Coordinador de Investigacin y de la Secretaria de Investigacin. Por lo tanto la Jefatura Administrativa y el Director del Departamento deban ver la suma de estas dos tablas en una sola. Tercero, todos los usuarios queran ver las sumas de las las y las columnas de las tablas a pesar de estar implementado en los archivos Excel. Cuarto, rara vez se us el enlace ltimas Planillas y el enlace Planillas de Fondos era ms accesado. Entonces se decidi quitar el enlace ltimas Planillas y se

51

agreg un nuevo enlace dentro del contenido de Planillas de Fondos. Este nuevo enlace slo mostrara la planilla en validacin. Por ltimo, al igual que en las pginas de Saldos y Cartolas era posible que el usuario se perdiera y se agreg un texto con los parmetros para indicar el estado actual de la consulta. Adems se agregaron textos en las pginas para explicar varios de estos cambios. Se mostraron mejores resultados al probar en la segunda iteracin, pero hubo algunos inconvenientes. Ningn usuario pudo encontrar el nuevo enlace para acceder a la planilla en validacin. Por lo tanto, se decidi mover este enlace al men principal bajo el nombre Planilla en Validacin. Adems haban algunas frmulas mal hechas en los archivos Excel que fueron arregladas.

Figura 4.13: Vista de una Planilla

4.6.5. Pgina de Peticiones de Giros

En la primera iteracin se us una herramienta de Joget Workow. Esta herramienta consiste en mostrar los datos de las instancias de los procesos en una tabla. En este caso, se us esta herramienta para mostrar los datos de las peticiones de giros de fondos. Cada la de la tabla mostraba una peticin de giro con su nombre de usuario, asunto (o ttulo), monto, fecha y estado. Adems cada la inclua un enlace para ver ms detalles de las peticiones como su descripcin y su respuesta del Director del Departamento. Estos detalles se abran en una nueva ventana. Se us un ltro especial para que los profesores slo pudieran ver sus respectivas peticiones. En las pruebas, los usuarios mostraron inters aunque haban algunos problemas. A nin-

52

guno de los usuarios le gust que se abrieran los detalles en ventanas nuevas. La navegacin se cambi para que se mantuviera en la misma ventana. Adems pocos usuarios entendan la idea de los estados de las peticiones. Por lo que se agreg un texto con la explicacin de estos estados y sobre cmo manejar la tabla. En la siguiente iteracin se mostraron mejores resultados. Sin embargo, haba que implementar la visiblidad de las peticiones para los distintos usuarios. Para esto se implementaron tres plugins: uno para mostrar la informacin, otro que muestra un botn para borrar peticiones (o hacerlas invisibles) y otro que muestra un botn para recuperar las peticiones borradas (o hacerlas visibles) desde hace un mes. Las peticiones aceptadas o rechazadas que no son vistas por ningn usuario y que tienen ms de un mes son borradas automticamente. El botn para borrar utiliza una casilla de marcado (checkbox) en cada la de la tabla para aplicar esta funcin. Tambin se implementaron plugins para dar un mejor formato a los datos. Uno cambia el monto a formato de moneda (smbolo $ y puntos) y otro cambia la fecha a formato de das, meses y aos (antes era ms extenso).

Figura 4.14: Vista de una Lista de Giros

4.6.6. Pgina de Conguracin de Usuario

Esta pgina no se prob en las pruebas de usabilidad porque no afecta directamente los procesos y las consultas. En esta pgina se muestra un formulario para cambiar el nombre, el apellido y la direccin de correo electrnico del usuario. Tambin muestra una seccin para cambiar la contrasea (un par de entradas de contrasea). Sin embargo, hay una seccin adicional para los usuarios que rman planillas de fondos. Esta seccin permite subir un archivo de imagen para denir la rma que aparecer en las planillas. Si no suben una imagen, el sistema no les permitir rmar planillas. En la ltima iteracin, en el men principal se not que el enlace a este formulario deba tener su propia seccin ya que no comparte el mismo objetivo que los otros enlaces. Por esto se puso el enlace en su propia seccin.

53

4.6.7. Pgina para Agregar Nuevos Fondos

En la primera iteracin se implement un formulario que agregaba las de forma dinmica a una tabla (a travs de JavaScript). En el formulario se agregaba un nombre de usuario, un monto y un mes y se inclua la la en la tabla. Si la la repeta el usuario y el mes, el monto se reemplazaba. En cada la haba un botn con una X para borrar la la. Al nal de la tabla haba un botn para guardar los datos. Si haba otra instancia del proceso Ingreso de Nuevos Fondos, apareca un mensaje de conrmacin indicando que se borrara esa instancia. Si haba otra instancia que se encontraba en su ltima etapa (actualizar los saldos), este botn se bloqueaba mostrando un mensaje.

Figura 4.15: Bosquejo de la tabla para agregar fondos (primera iteracin)

Al probarlo con el Coordinador de Investigacin se encontraron muchas caractersticas para la tabla. Poda incluir nmeros negativos en el monto y haba que diferenciar los ingresos actuales y los atrasados del ao pasado. Tambin sugiri agregar un botn para vaciar la tabla (reset) y que esta tabla debera manejarla la Secretaria de Investigacin. Entonces se agreg un nuevo dato al formulario (y una nueva columna enla tabla) para indicar el tipo de ingreso entre Actual y Correccin del Ao Pasado. Tambin se agreg un botn de reset y un texto con las instrucciones para usar la tabla. En la segunda iteracin se encontraron muchos problemas al probar esta pgina con la Secretaria de Investigacin. No entenda muy bien las instrucciones y no entenda muchas funciones. Adems el lenguaje no era el adecuado. Por lo tanto se decidi eliminar el formulario para agregar las y se cambi la tabla para que funcionara de la siguiente manera. Se implement un plugin para que la tabla tuviera un botn para agregar una la. Al apretarlo, se generaba una la en la tabla con cajas de selccin (selectbox) para sus datos, excepto el monto que tiene una entrada de texto. Se mantuvieron los otros botones de la tabla y el plugin automticamente revisaba que los datos fueran correctos (o si no, mostraba un mensaje de error). En la tercera iteracin, estos cambios mostraron tener mejores resultados. Ni siquiera fueron necesarias las instrucciones aunque no se redactaron correctamente las tareas durante la prueba de usabilidad.

54

Figura 4.16: Vista de la tabla para agregar fondos

4.6.8. Pgina para Pedir Giro de Fondos

Esta interfaz slo pudo ser probada en la tercera iteracin. Principalmente consiste en un formulario con entradas para el nombre del usuario, la fecha actual, el monto, un asunto (o ttulo) y una descripcin. El nombre y la fecha podan ser llenados automticamente, por lo que estas entradas fueron bloqueadas. Al nal del formulario tambin se agreg una tabla que mostraba el saldo actual del usuario, la suma de los montos de las peticiones en proceso y la diferencia.

Figura 4.17: Vista del formulario para pedir giros

55

4.6.9. Pgina de Procesos Pendientes

En la primera iteracin se us una caracterstica de la aplicacin Joget Workow. sta consiste en una bandeja de entrada para mostrar las tareas correspondientes de cada usuario en los procesos. Esta bandeja de entrada muestra una tabla donde cada la muestra una tarea (con un enlace), el proceso al que pertenece, la fecha de creacin y otras caractersticas irrelevantes. Al presionar un enlace se acceda al formulario correspondiente. En el men principal se acceda a travs de un enlace llamado Procesos Pendientes. En las pruebas se notaron algunos problemas. Primero, la informacin de cada la en la tabla no era la correcta. Para el proceso Validacin de Giros de Fondos era necesario ver quin cre la peticin y cul era el asunto. Y segundo, cuando se completaba una tarea se volva a esta tabla y los usuarios preferan ver un mensaje indicando las consecuencias de haber realizado la tarea. Por esto se implement un plugin para mostrar las columnas correctas en la tabla y para redireccionar a pginas adicionales que mostraran los mensajes deseados. Al probar la segunda iteracin hubo un pequeo inconveniente con el men principal. A algunos usuarios no les gustaba que los dos procesos principales estuvieran mezclados en una misma tabla. Preferan ver dos tablas distintas. Entonces en el men principal se dividi el enlace en dos para mostrar las distintas tablas. En la tercera iteracin hubo distintas reacciones ante este cambio. Los principales problemas ocurrieron porque los enlaces tenan los nombres de los procesos y los usuarios se confundan. Por lo tanto, se decidi llamar a los enlaces Procesos con Planillas y Procesos con Giros.

4.6.10. Otras Pginas

Aqu se describen las pginas que se usan para continuar los procesos. Se acceden a estas pginas a travs de la pgina de Procesos Pendientes. En el proceso Ingreso de Nuevos Fondos, cuando se crea una nueva planilla se muestra junto a un par de selectbox para indicar el mes y el ao de la planilla. El sistema designa de forma automtica estos valores, pero el usuario debe conrmarlo. Cuando se rma una planilla se muestra la planilla y la imagen de la planilla. Si el usuario no tiene rma, el sistema bloquea el botn para rmar la planilla y muestra un mensaje de error. Al almacenar la planilla en la base de datos se muestra un botn para descargar primero el archivo Excel y despus se muestra el botn para almacenar (en la parte inferior de la pgina). Al actualizar los saldos, slo se muestra la planilla, un texto explicando la situacin y el botn para aceptar. En el proceso Validacin de Giro de Fondos, cuando se muestran los datos de la peticin, un cuadro combinado (combobox) para elegir la direccin del proceso y un cuadro de texto para agregar un mensaje. En el combobox se puede aceptar la peticin, rechazarla o enviarla al Coordinador de Investigacin (si ya la envi no se muestra esta ltima opcin). Al Coordinador de Investigacin slo se le muestra un cuadro de texto para agregar comentarios.

56

Al nal del proceso cuando se descuentan fondos, se muestran los datos de la peticin y un mensaje destacado advirtiendo que slo se contine si se ha recibido correctamente una comisin acadmica (o documento, formalizacin, etc).

57

5. Validacin
5.1. Planicacin de las Pruebas
Para encontrar los problemas de la interfaz, en cada iteracin del desarrollo se organiz una prueba de usabilidad. Esta prueba tambin ayud a encontrar los nuevos requisitos del sistema que no fueron encontrados en las primeras etapas del desarrollo. La prueba consista en realizar una sesin con cada participante y seguir un protocolo de observacin con pensamiento en voz alta mientras interactuaban con un prototipo funcional. En particular, se decidi organizar una serie de pasos en cada sesin para analizar distintas tareas. As se cont con la ventaja de que la prueba se poda aplicar a pocos participantes y se poda aplicar con monitores inexpertos. Tambin estaba la ventaja de poder predecir la complejidad de los pasos para evaluar el aprendizaje. Adems como el objetivo era encontrar los problemas de la interfaz, fue mejor denir tareas especcas que darles libre exploracin a los participantes. Para obtener datos cuantitativos sobre la satisfaccin de los participantes, se organiz un cuestionario para aplicarlo al nal de cada sesin. Como en las sesiones se interactuaba con un prototipo, se decidi disear el cuestionario con preguntas cerradas.

5.2. Seleccin de los Participantes

En cada sesin se seleccion a la Jefa Administrativa, a la Secretaria de Investigacin, al Coordinador de Investigacin y al Director del Departamento como participantes para realizar la prueba. Esta muestra era la ms importante porque realizaban las actividades ms complejas del sistema. Como el sistema tambin estaba dirigido a profesores de jornada completa del D.C.C., se pens tomar una muestra de este grupo. Pero por razones de disponibilidad slo se tom una muestra de tres profesores en la ltima iteracin del desarrollo. Adems esta prueba no se consider muy importante porque cumplan funciones menos complejas.

58

5.3. Preparacin de los Materiales

Antes de cada sesin se prepar el prototipo para que simulara las situaciones en que el participante tena que realizar una accin para que un proceso avanzara. Tambin se agreg informacin en la base de datos para que la interfaz los mostrara como ejemplo. Esta informacin se gener aleatoriamente porque la informacin real era privada y exclusiva del D.C.C.. Se prepararon tarjetas numeradas para indicar la secuencia de tareas a realizar. La primera tarea siempre correspondi a que los participantes ingresaran con su respectivo nombre de usuario y contrasea. Despus se pasaba a tareas donde se consultaba y vea la informacin. Finalmente se pasaba a tareas ms complejas que involucraba tomar parte en los procesos simulados. En este documento se adjuntan las tarjetas que se usaron en la ltima iteracin del desarrollo. En el caso de las sesiones con los profesores, previamente se les entreg un pre-cuestionario con preguntas cerradas. Esto se hizo con el propsito de que entendieran un poco el objetivo del sistema. Adems ayud a saber si tenan problemas con el sistema actual y si mostraban inters en la solucin mostrada por el prototipo. Las preguntas estaban dirigidas a saber cmo los participantes guardaban la informacin de sus fondos FII y cmo interactuaban con la Administracin del D.C.C. para realizar los giros. Se adjunta el contenido de este pre-cuestionario como anexo. Para llevar a cabo las pruebas, se tom como escenario la ocina de cada participante. Se eligi as porque lo ms probable era que revisaran la informacin en su propio lugar de trabajo. Adems permiti simular una situacin de la vida diaria en donde se podran presentar interrupciones o inconvenientes con el computador (ya fuera con problemas con el navegador o con la conexin a Internet). Durante el desarrollo de las sesiones se fueron anotando las observaciones y los errores que cometan los usuarios. Tambin se us una grabadora IC Recorder RR-XS410 de Panasonic para capturar los comentarios de los participantes que no pudieron ser anotados a tiempo. Despus de cada sesin a los participantes se les entreg el cuestionario para evaluar su satisfaccin con el prototipo. El cuestionario fue diseado originalmente por el C5

para

evaluar sitios Web. En este caso, se cambiaron algunas preguntas de tal forma que el cuestionario apuntara al aprendizaje y satisfaccin del participante. Tambin se sacaron algunas caractersticas que no se presentaban en el prototipo (como el uso de imgenes). Se us una escala Likert del 1 al 10 para no tener respuestas indecisas (evitar una mediana). Tambin se agreg una pregunta abierta para que los participantes agregaran observaciones adicionales. El contenido del cuestionario viene adjunto en este documento.

Chile.

1 Centro

de Computacin y Comunicacin para la Construccin del Conocimiento de la Universidad de

59

5.4. Aplicacin de las Pruebas

Para realizar cada sesin se tuvo que organizar previamente con cada participante en persona o a travs de correo electrnico. La anticipacin dependa de la disponibilidad de cada participante (algunos podan realizar la prueba inmediatamente y otros podan encontrarse fuera del pas). La duracin de cada sesin dur aproximadamente 30 minutos y segua una rutina semiestructurada. Primero se saludaba cordialmente al participante y se le explicaba el objetivo de la prueba. Si el participante era un profesor entonces se le peda que completara el precuestionario. Despus el participante se sentaba frente a su computador y el monitor a su lado. Por educacin se preguntaba si no era molestia usar la grabadora. Se le peda al participante que abriera su navegador Web preferido y se le ingresaba la direccin

para acceder

al prototipo. Luego se le entregaban las tarjetas con las tareas a realizar. El monitor dejaba que el participante hiciera slo las tareas hasta que se rindiera o preguntara si haba tenido xito en completar la tarea. Al nal de cada tarea, el monitor tambin explicaba conceptos de los procesos en caso que el participante no entendiera los textos o no entendiera el estado del sistema. Finalmente se le peda al participante que contestara el cuestionario tomando todo el tiempo que necesitara.

2 http://ufondos.dcc.uchile.cl:8080/
60

5.5. Resultados

5.5.1. Resultados de la Primera Iteracin

Resultados de los Cuestionarios:

Pregunta

Jefatura Administrativa
9 9 9 8 8 7 10 10 10 10 10 9 9 8 8

Secretaria de Investigacin
6 10 6 5 5 3 10 6 8 7 6 7 7 5 5

Coordinador Director de Invesdel tigacin Departamento

10 10 8 8 8 1 10 10 10 10 10 10 10 6 1 9 10 8 6 5 No respondi 10 8 10 No respondi 8 10 10 10 10

1.- Me gust el sitio 2.- Volvera a trabajar con el sitio 3.- El sitio Web es fcil de manejar 4.- Es fcil encontrar la informacin deseada 5.- Los enlaces son claramente identicados 6.- Los enlaces funcionan correctamente 7.- Las pginas se cargan rpidamente (menos de 30 segundos) 8.- Los textos son fciles de leer 9.- El uso del color es aceptable 10.- El diseo general del sitio es aceptable 11.- La organizacin de la informacin del sitio es apropiada 12.- El contenido del sitio es relevante 13.- La interfaz del sitio es placentera 14.- El sitio tiene todas las funcionalidades esperadas 15.- Pude realizar las tareas correctamente

61

Participante
Jefatura Administrativa

Observaciones
Faltara agregar los saldos generales del Fondo de Investigacin (todos los ingresos y gastos) y considerar el fondo inicial de cada acadmico de un ao para otro.

Secretaria de Investigacin Coordinador de Investigacin Director del Departamento Los puntos marcados con 1 y 6 se discutieron puntualmente y se mejorarn. Los profesores podran ser informados va email cuando sus peticiones son aceptadas. Resultados de las Observaciones:

Jefatura Administrativa: Le gust la pgina de bienvenida, pero deba referirse especcamente a los fondos FII. No pudo encontrar el enlace para ingresar su nombre y contrasea. No encontr el enlace ltimas Planillas. No entendi para qu serva el botn Descargar Excel. Las planillas Excel no mostraban correctamente las sumas. Encontr rpidamente el enlace Procesos Pendientes. Despus de rmar la planilla de fondos, esperaba un mensaje indicando si se haba rmado correctamente. Deseaba que la bandeja de entrada mostrara los nombres de los usuarios que realizaban giros de fondos (para identicarlos). No entendi la idea de Formalizacin. Preere el trmino Comisin Acadmica. Al aceptar un giro de fondos esperaba un mensaje indicando si se realiz correctamente. Quera ms informacin sobre los procesos. Encontr los detalles de los giros de fondos, pero no le gust que se abriera otra ventana. Entendi los estados de las peticiones de giros. Quera ver las sumas de las las y las columnas de la planilla de fondos en pantalla. Tambin quera un resumen con los saldos, ingresos y gastos del ao e indic que podra serle til al Director del Departamento. Diferenciar el saldo inicial con que se empieza el ao.

Secretaria de Investigacin: No pudo encontrar el enlace para ingresar su nombre y contrasea. No encontr el enlace ltimas Planillas y en vez de eso seleccion Planillas de Fondos. No encontr el enlace Procesos Pendientes. Al crear la planilla de fondos, quera saber de quin venan los datos (del Coordinador) y ms informacin sobre el proceso. Esperaba un mensaje indicando si se cre correctamente la planilla. Quera ver las sumas de las las y las columnas de la planilla de fondos en pantalla. Encontr las peticiones de giros de fondos, pero no entendi los estados. Encontr los detalles de los giros de fondos, pero no le gust que se abriera otra ventana.

Coordinador de Investigacin: Encontr el enlace para ingresar su nombre y contrasea. Encontr el enlace ltimas Planillas. No entendi las planillas de fondos porque no entenda si indicaban saldos o ingresos. Prefera que los cambios de cada planilla fueran indicados con nmeros de colores. Deseaba ms informacin para entender los procesos. Quera ver las sumas de las las y las columnas de la planilla de fondos en pantalla. Quera ver los nmeros con formato de dinero (smbolo $ y puntos). Encontr el enlace Procesos Pendientes. No entendi muy bien cules campos eran editables y cules no. Esperaba un mensaje indicando si se rm correctamente la planilla y a dnde se fue. Encontr la lista de peticiones de giros, pero no entendi para qu serva. Tampoco entendi los estados y no le gust que los detalles se abrieran en una ventana nueva. Estaba interesado en saber si las peticiones se borraban automticamente. Entendi la tabla para agregar nuevos fondos aunque no entendi cmo cambiar las las. Indic en

62

la tabla la posibilidad de agregar nmeros negativos y que la tabla poda mantenerse vaca (para meses donde no hay movimientos). Tambin le interes la idea de agregar un botn para vaciar la tabla (reset) y entendi el mensaje de advertencia. Sobre las planillas, indic que los ingresos podan clasicarse como actuales y del ao pasado por lo que la planilla deba mostrarse en dos tablas (de doce meses cada una). Adems le interes la idea de agregar un mensaje de advertencia en caso que se sobrepasara el lmite de ingresos del ao. Finalmente, indic que la tabla para agregar fondos debera ser usada por la Secretaria de Investigacin y que prefera enviar los correos electrnicos.

Director del Departamento: Encontr el enlace para ingresar su nombre y contrasea. No encontr el enlace ltimas Planillas. Confunda mucho los enlaces Planillas de Fondos y Cartolas de Fondos. Encontr el enlace Procesos Pendientes y rm la planilla de fondos, pero no entendi a dnde se fue. Deseaba que la bandeja de entrada mostrara los nombres de los usuarios que realizaban giros de fondos (para identicarlos). Encontr los detalles de los giros de fondos, pero no le gust que se abriera otra ventana. No le gust el trmino Formalizacin y prefera otros trminos como documento, contrato o comisin acadmica.

5.5.2. Discusin de la Primera Iteracin

Como son pocos usuarios, no fue necesario considerar valores estadsticos como el promedio o la varianza. De los cuestionarios se puede deducir que la satisfaccin de los usuarios fue muy buena. Principalmente resalt la apariencia del sitio en cuanto a los textos, colores y rapidez de carga de las pginas. Adems el contenido y la informacin gener inters en los usuarios, de tal forma que volveran a trabajar con el sitio. Algunos errores en el sitio causaron que los usuarios sintieran que no estaban realizando correctamente las tareas. Tambin sintieron que faltaron ms funcionalidades para que el sitio funcionara adecuadamente. Estaba el asunto de cambiar el enlace de login a la pgina de bienvenida. No result muy til el enlace ltimas Planillas y haba que denir mejor el acceso. Haba que agregar sumas en las planillas y formato de dinero en los nmeros. Todos los usuarios preferan que no se abrieran nuevas ventanas en el navegador. Y adems surgi el nuevo requisito del resumen de saldos. Pero el principal problema result ser el lenguaje que usaba el sitio. ste no slo tena que referenciar elementos, sino que tambin tena que informar y explicar los resultados de los procesos que se estaban manejando. Lo que ms esperaban los usuarios eran mensajes indicando que se haban realizado correctamente las tareas. Estos mensajes deban explicar a dnde se iban los documentos y quines participaban. Adems haba que cambiar otros trminos que no podan usar lenguaje tcnico y que deban ser consistentes.

63

5.5.3. Resultados de la Segunda Iteracin

Resultados de los Cuestionarios:

Pregunta

Jefatura Administrativa
9 9 10 9 8 10 10 10 10 10 10 8 9 10 9

Secretaria de Investigacin
9 10 9 7 6 9 No respondi 9 9 8 8 10 9 7 9

Coordinador Director de Invesdel tigacin Departamento

10 10 10 7 7 10 10 9 10 10 8 10 10 10 10 9 10 10 8 8 10 10 10 10 10 9 10 9 10 10

1.- Me gust el sitio 2.- Volvera a trabajar con el sitio 3.- El sitio Web es fcil de manejar 4.- Es fcil encontrar la informacin deseada 5.- Los enlaces son claramente identicados 6.- Los enlaces funcionan correctamente 7.- Las pginas se cargan rpidamente (menos de 30 segundos) 8.- Los textos son fciles de leer 9.- El uso del color es aceptable 10.- El diseo general del sitio es aceptable 11.- La organizacin de la informacin del sitio es apropiada 12.- El contenido del sitio es relevante 13.- La interfaz del sitio es placentera 14.- El sitio tiene todas las funcionalidades esperadas 15.- Pude realizar las tareas correctamente

Participante
Jefatura Administrativa

Observaciones
Revisar tema del saldo inicial del ao con perl para modicar el monto, en caso de superar el denido para partir el ao.

Secretaria de Investigacin Coordinador de Investigacin Director del Departamento

64

Resultados de las Observaciones:

Jefatura Administrativa: Ingres rpidamente su nombre y contrasea. Encontr el enlace Planillas de Fondos. Accidentalmente encontr la planilla en validacin, pero al pedirle que la buscara no la encontr. Crey que si descargaba la planilla Excel y la cambiaba afectara la base de datos. Le gust la informacin sobre el proceso aunque le gustara saber quines ms participan. Falt cambiar Formalizacin por Comisin Acadmica. Le gust la lista de peticiones de giros y los detalles. Finalmente indic que el lmite de ingresos lo maneja la Ocina de Investigacin, pero que le gustara una herramienta auxiliar para poder tratar cada caso de exceso por separado (en particular para modicar el saldo inicial de un ao.)

Secretaria de Investigacin: Ingres rpidamente su nombre y contrasea. Encontr la tabla para agregar nuevos fondos, pero no entendi muy bien cmo manejarla. No se j en las instrucciones. No le gustaron las advertencias ni los mensajes de conrmacin. Le incomodaban trminos como borrar la planilla para crear una nueva. Prefera trminos como modicar los datos y enviar la planilla. Le gust la forma de mostrar las planillas (con dos tablas de doce meses) aunque indic que le gustara ver una tercera tabla mostrando un resumen con las sumas de las columnas. No pudo encontrar la planilla en validacin. Le gust la lista con las peticiones de giros. Pregunt cules usuarios podan ver esa lista y qe signicaba que una planilla fuera vlida.

Coordinador de Investigacin: Ingres rpidamente su nombre y contrasea. Se jaba en las instrucciones. Le gust la forma de mostrar las planillas de fondos. No encontr la planilla en validacin e indic que prefera el enlace en el men principal. No entendi muy bien cuales campos eran editables y cuales no. Encontr el enlace Procesos Pendientes aunque prefera ver los dos procesos por separado en el men principal. Le gust la lista de peticiones de giros. Sugiri la idea de que los usuarios pudieran revisar los correos electrnicos que enva a la Secretaria, pero por razones de privacidad no se podan agregar con simples enlaces. Finalmente indic que no tena problemas para cambiar el lmite de ingresos en el sistema para cuando el aviso.

Director del Departamento: Ingres rpidamente su nombre y contrasea. Encontr el enlace Procesos Pendientes aunque prefera ver los dos procesos por separado en el men principal. No entendi bien la idea de los nmeros de colores. No se jaba mucho en los mensajes de conrmacin. Le gust la lista de peticiones de giros. No le gust el trmino autorizacin y prefera comisin acadmica o autorizacin de la Escuela. Encontr el resumen de saldos aunque no le gust el orden las columnas. Tard varios clicks en encontrar la planilla en validacin.

5.5.4. Discusin de la Segunda Iteracin

En los resultados de los cuestionario se puede apreciar mejor satisfaccin de los usuarios. Los resultados de la Secretaria de Investigacin son mejores en comparacin a los de la primera iteracin. Adems con las funcionalidades reparadas, el Coordinador de Investigacin sinti ms conanza en realizar las tareas en el sitio. En general resalt la apariencia y la conanza de los usuarios aument porque les gust la organizacin de la informacin y porque sintieron que realizaban bien las tareas.

65

En este caso, el principal problema se puede notar en la bsqueda de la informacin. Los enlaces resultaron difciles de encontrar. En particular, el enlace especial para encontrar la planilla en validacin mostr ms complicaciones. Tambin haba que separar los enlaces de los procesos pendientes. Algunos usuarios se sintieron incmodos con el lenguaje. Estos errores no se consideraron demasiado graves como en la iteracin anterior. Bsicamente eran palabras especcas y la complejidad de cambiarlas era baja. Haba que elegir las palabras correctas para cada caso. Hay que notar que la Secretaria de Investigacin no qued satisfecha con las funcionalidades. Esto se debe a que se le present la herramienta para agregar nuevos fondos. La tabla fue muy difcil de manejar y las instrucciones tampoco ayudaron mucho.

5.5.5. Resultados de la Tercera Iteracin

Resultados de los Pre-cuestionarios:

Pregunta
1. Mantiene una cartola o alguna informacin sobre sus fondos FII? 2. Consulta esta informacin

Profesor 1
S

Profesor 2
S

Profesor 3
S

S Llenar un formulario y enviarlo a la Administracin S No

S Llenar un formulario y enviarlo a la Administracin No No

S Llenar un formulario y enviarlo a la Administracin S S

con la Administracin? 3. Cul de estas acciones realiza primero cuando quiere invertir sus fondos? 4. Alguna vez ha invertido sin tener fondos sucientes? 5. Alguna vez ha invertido sin tener informacin sobre sus fondos? 6. Le interesara tener ms informacin sobre sus inversiones? 7. Ha perdido fondos por haberlos mantenido mucho tiempo (ms de 2 aos)? No No No S S S

66

Resultados de los Cuestionarios:

Pregunta

Jefatura Administrativa
9 9 9 7 8 9 10 9 9 9 8 8 8 8 7

Secretaria de Investigacin
9 10 9 9 8 8 10 10 9 9 9 9 9 8 9

Coordinador Director de Invesdel tigacin Departamento

10 10 9 9 10 10 10 10 10 10 10 10 10 7 10 9 9 10 10 9 10 10 10 9 9 9 10 8 10 10

1.- Me gust el sitio 2.- Volvera a trabajar con el sitio 3.- El sitio Web es fcil de manejar 4.- Es fcil encontrar la informacin deseada 5.- Los enlaces son claramente identicados 6.- Los enlaces funcionan correctamente 7.- Las pginas se cargan rpidamente (menos de 30 segundos) 8.- Los textos son fciles de leer 9.- El uso del color es aceptable 10.- El diseo general del sitio es aceptable 11.- La organizacin de la informacin del sitio es apropiada 12.- El contenido del sitio es relevante 13.- La interfaz del sitio es placentera 14.- El sitio tiene todas las funcionalidades esperadas 15.- Pude realizar las tareas correctamente

67

Pregunta
1.- Me gust el sitio 2.- Volvera a trabajar con el sitio 3.- El sitio Web es fcil de manejar 4.- Es fcil encontrar la informacin deseada 5.- Los enlaces son claramente identicados 6.- Los enlaces funcionan correctamente 7.- Las pginas se cargan rpidamente (menos de 30 segundos) 8.- Los textos son fciles de leer 9.- El uso del color es aceptable 10.- El diseo general del sitio es aceptable 11.- La organizacin de la informacin del sitio es apropiada 12.- El contenido del sitio es relevante 13.- La interfaz del sitio es placentera 14.- El sitio tiene todas las funcionalidades esperadas 15.- Pude realizar las tareas correctamente

Profesor Profesor Profesor 1 2 3

10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 8 8 9 9 9 10 10 9 10 8 8 8 8 7 10 7 10 9 9 7 10 10 7 9 9 9 10 7 6 9

Participante
Jefatura Administrativa Secretaria de Investigacin Coordinador de Investigacin Director del Departamento Profesor 1 Profesor 2

Observaciones
A la espera de las funcionalidades acordadas en la cartola.

Me gusta el sitio. Es simple y fcil de usar. Slo agregara una opcin: poder evisar por separado los ingresos y egresos al FII (ahora se puede revisar dicha informacin, pero en una nica cartola).

Profesor 3

Sera bueno tener un preview de una solicitud (indicando los montos antes y despus) en caso de que fuera aprobada o varias de las pendientes fueran aprobadas. Es poco intuitivo lo de Recuperar Filas. Sera bueno tener un botn deshacer para solicitudes que todava no se aprueban.

Resultados de las Observaciones:

Jefatura Administrativa: Ingres rpidamente su nombre y contrasea. Encontr el enlace Planillas de Fondos y entendi que automticamente se desplegaba la ltima vlida. No ley los textos. Confundi el enlace Validacin de Giro de Fondos con Planilla en Validacin. Le cost encontrar el enlace Ingreso de Nuevos Fondos. Entendi cmo rmar la planilla y cmo aceptar un giro. En los botones de Completar prefera que dijeran Aceptar. Tard en encontrar el enlace Saldos y Cartolas. Al consultar una cartola prefera que en vez de Usuario dijera Profesor. No se j en la caracterstica agregada para ver detalles. Encontr la lista de peticiones de giros aunque los checkbox la distrajeron (crey que servan para ver los detalles). Despus entendi su

68

uso al borrar y recuperar las las aunque no ley los textos de conrmacin. Encontr el enlace Resumen de Saldos y entendi cmo corregir el saldo inicial de un usuario. Entendi cmo actualizar los saldos al recibir una planilla.

Secretaria de Investigacin: Ingres rpidamente su nombre y contrasea. Encontr la tabla para agregar nuevos fondos y entendi cmo manejarla (aunque hubo algunas confusiones con la tarjeta y no la lea entera). No ley las instrucciones. Not que la planilla no estaba ordenada por orden alfabtico. Le gustaron los textos de conrmacin. Encontr los enlaces Planillas de Fondos y Planilla en Validacin. Le gust la lista con las peticiones de giros aunque los checkbox la distraan un poco. Trat de borrar una peticin de la lista, pero por un error no funcionaba esta funcin (se sospecha de la versin del navegador o ste bloque los

scripts ).

No entendi por qu haban

dos enlaces en Procesos Pendientes. Al almacenar la planilla en la base de datos, la descarg correctamente, pero no presion el botn para almacenarla porque no ley las instrucciones.

Coordinador de Investigacin: Ingres rpidamente su nombre y contrasea. Encontr el enlace Planillas de Fondos y entendi que automticamente se desplegaba la ltima vlida. Not un error con las tablas en el archivo Excel. Encontr el enlace Planilla en Validacin. Entendi la separacin de enlaces en la seccin de Procesos Pendientes. Hizo rpido las tareas para comentar una peticin de giro y rmar la planilla. Le gust la lista de peticiones de giros y las funciones para borrar y recuperar las. Preere ver el enlace Conguracin de Usuario en una seccin distinta.

Director del Departamento: Ingres rpidamente su nombre y contrasea. Revis todo el men antes de poder encontrar el enlace Ingreso de Nuevos Fondos. Firm la planilla y ley el texto. Valid bien los giros que se les pidi. Confundi el enlace Giros de Fondos con Validacin de Giros de Fondos. De la lista no pudo recordar cul envi al Coordinador de Investigacin. Entendi cmo borrar las de la lista. No le gust que se recuperaran las las de un mes atrs. Prefera recuperar cada una por separado. Encontr el enlace Planillas de Fondos. Aqu ocurri un error donde el servidor se apag por unos 10 minutos aproximadamente. Despus del error, la sesin expir y apareci la pgina de error de Joget Workow (cambiar tal pgina en el futuro). Encontr el enlace Planilla en Validacin. Le gustaron los archivos Excel y el resumen de saldos.

Profesor 1: Ingres rpidamente su nombre y contrasea. Encontr el enlace para pedir un nuevo giro de fondos. Entendi el formulario aunque dud si el monto se refera a dlares o pesos. Le gust la lista de peticiones de giros y entendi los estados. Entendi las funciones para borrar y recuperar las, pero no las encontr muy tiles. Encontr la cartola y la entendi.

Profesor 2: Ingres rpidamente su nombre y contrasea. Confundi los enlaces Giros de Fondos y Pedir Giro de Fondos. Entendi el formulario al pedir un giro (incluso not que no tena fondos sucientes). Entendi la lista de peticiones de giros y los estados. Entendi cmo borrar las las, pero indic que no lo usara porque prefera ver toda la informacin (como un historial). Ley el texto al recuperar las las. En la cartola no entendi que aparecan los giros aprobados.

Profesor 3: Ingres su nombre y contrasea aunque al principio crey que su contrasea era la misma que la de

U-Papers.

Confundi los enlaces Giros de Fondos y Pedir

Giro de Fondos. Entendi el formulario al pedir un giro, pero no ley el mensaje de conrmacin al terminar. Entendi la lista de peticiones de giros, los detalles y

69

los estados. Al borrar las las no ley el texto y no not que slo se borraban las las con estado ACEPTADO o RECHAZADO. No entendi bien cmo recuperar las. Encontr el enlace Saldos y Cartolas. En la cartola no entendi que aparecan los giros aprobados.

5.5.6. Discusin de la Tercera Iteracin

En los pre-cuestionarios se puede ver que los profesores consultaban la informacin de sus fondos FII con la Jefatura Administrativa. Tambin muestra que la primera tarea para validar los giros debe ser llenar el formulario. Adems se muestra que hay casos en que se realizan giros sin tener informacin o fondos sucientes. La interfaz arregla esto al mostrar el estado actual de los saldos respectivos. Todos mostraron tener inters en la informacin de sus fondos, a pesar de tenerla guardada de forma personal. Este inters tambin se puede ver en que los profesores no han perdido fondos caducos. Esto prueba que el sitio podra satisfacer sus necesidades y ser usado en el futuro. En los cuestionarios se puede notar que el inters de los usuarios de la administracin del D.C.C. se mantiene. Adems mejor la ecacia del sitio porque los enlaces fueron ms fciles de identicar. En la seccin de procesos pendientes hubo algunas dicultades, pero no parece haber empeorado la bsqueda de informacin. Tal vez slo se necesitaban mejores nombres en los enlaces. En cuanto a los profesores, se pueden ver buenos resultados y que la apariencia les pareci aceptable. Pero el principal problema se enfoca en que el sitio no tena todas las funcionalidades esperadas. La separacin de la cartola en ingresos y egresos no se considera necesaria. Por otro lado, es posible que en el futuro sea necesario implementar la vista previa (preview) al pedir un giro. Entre estos cambios el ms importante es la posibilidad de deshacer una peticin. Podra hacerse con una funcin para eliminar el proceso, pero slo si la peticin tiene el estado VALIDANDO. Las nuevas funciones en la lista de peticiones de giros no parecieron impedir realizar las tareas. Aunque distrajeron algunas veces, es posible que se pueda mejorar su rendimiento al compararlo con algunas interfaces de sitios de correos electrnicos. Los profesores no encontraron muy tiles estas funciones y se podran eliminar en su versin de la lista. Puede que la funcin para recuperar no sea la ms adecuada y sea mejor crear una interfaz propia para recuperar las especcas de la lista (como una Papelera de Reciclaje). La Secretaria de Investigacin muestra un mejor aprendizaje del sitio, en especial con la tabla para agregar nuevos fondos. Not algunos inconvenientes, pero en general le gust ms la organizacin de la informacin y la apariencia del sitio. Por otro lado, la Jefatura Administrativa ha perdido algo de conanza en el sitio. Not varios botones que no le parecan correctos y se confundi con algunos enlaces. Puede que sea un inconveniente con el lenguaje y sea necesario elegir las palabras correctas. Adems hubo un error durante la prueba en donde no se mostr un mensaje de conrmacin correctamente, lo que podra explicar este cambio.

70

El Coordinador de Investigacin crey que faltaron algunas funcionalidades las cartolas, pero en verdad falt agregarlas a la prueba. Aunque s faltan algunos detalles que arreglar en los archivos Excel.

5.6. Discusin General

A lo largo del proyecto, los usuarios mostraron un gran inters por la informacin del sitio. Este inters demostr la necesidad que se intenta satisfacer y que los usuarios utilizaran esta interfaz en el futuro. La satisfaccin de los usuarios fue muy buena desde la primera iteracin. La apariencia, los colores y los textos no incomodaron. Mientras que la organizacin de la informacin tampoco entorpeci el uso de las herramientas. Uno de los principales problemas fue el lenguaje que tenan que manejar los textos. Este aspecto inesperadamente se volvi muy crtico. Afect tanto el aprendizaje de los usuarios como la conanza que ellos sentan al interactuar con el sitio. Si se repetan palabras en los enlaces entonces los usuarios confundan fcilmente y tomaban la direccin equivocada. Por ejemplo, se confundan las palabras planillas y cartolas, validacin y formalizacin, actualizar y completar, etc. Por otro lado las palabras equivocadas podan poner nerviosos a los usuarios porque sentan que realizaban mal las tareas. Por ejemplo las palabras crear y borrar sonaban muy crticas y para tareas de fuerte impacto en los procesos. Mientras que las palabras completar y actualizar podan sonar como dos cosas distintas, a pesar de estar en un botn para conrmar un formulario (

submit ).

Los mensajes adicionales (que aparecen despus de cada formulario) resultaron ser vitales para el aprendizaje de los usuarios. A pesar de ser simples textos estticos, aportaron mucha informacin de los procesos sin tener que recurrir al lenguaje tcnico. Adems funcionaron como un refuerzo positivo para que los usuarios sintieran que realizaban correctamente las tareas. La identicacin de los enlaces tambin mostr ser un aspecto crtico de la interfaz. La separacin del men principal y el contenido result ser el principal gua de los usuarios. Como ocurri en la segunda iteracin en la pgina Planillas de Fondos, los usuarios no encontraron el enlace para ver la planilla en validacin. Al mover este enlace del contenido al men se identic inmediatamente. Por este tipo de casos, el contenido deba contener la menor cantidad de enlaces posibles.

71

Conclusin
La aplicacin de un sistema de informacin administrativa demostr ser una solucin adecuada para el problema de la prdida de informacin. Contando con las ventajas de un sistema administrador de workow, el sitio implementado pudo almacenar la informacin de los procesos en una sola base de datos. El Departamento no tendr que buscar papeles porque podr acceder rpidamente a esta informacin. Tambin se podrn transferir las tareas sin tener que preocuparse de pasar o perder documentos. La denicin de los procesos ayud a determinar los escenarios y sus casos especiales. Se tuvo que organizar la lgica para que la informacin se mantuviera consistente y robusta. Tomando como base los datos de entrada del Coordinador de Investigacin, se pudo adaptar la solucin para que mostrara las planillas correctamente a los actores. Despus se tuvo que traducir estas planillas como ingresos y las peticiones de giros como gastos. En el proceso Ingreso de Nuevos Fondos se pudo manejar el caso especial cuando era necesario corregir una planilla de ingresos. Slo se tuvo que automatizar la repeticin de este proceso. Tambin se pudieron descubrir otros casos especiales al probar distintas entradas de datos. Por ejemplo cuando se descuentan fondos caducos o excesos en el ao. Como la informacin qued centralizada, todos los usuarios podrn ver la informacin de forma consistente. No habr ms necesidad de que la Secretaria de Investigacin y la Jefatura Administrativa tengan que sincronizar sus registros. Adems los profesores podrn agilizar sus giros de fondos ya que no tendrn que asistir al D.C.C. para llenar el formulario ni para consultar sus fondos FII. No fue necesario dejar datos por mucho tiempo en la base de datos porque se pudo simular agregando fechas antiguas. Con la caracterstica del manejo de roles, el sistema pudo administrar correctamente la seguridad de la informacin. Al poder denir distintos actores se pudo mostrar la informacin correcta a los usuarios respectivos. Adems se pudo separar algunas pginas en distintas vistas para no tener que preocuparse por observaciones contradictorias. Como la base de datos contena la informacin, no era necesario preocuparse si la informacin variaba entre las vistas. Sin embargo, puede que en un nivel ms tcnico no sea lo ms seguro porque en el diseo no se estableci un protocolo de seguridad para la comunicacin a travs de la red. Las pruebas de usabilidad representaron un factor muy importante en el desarrollo. Principalmente ayudaron a descubrir cul informacin esperaban los usuarios que apareciera. Tambin ayudaron a descubrir los principales errores de los prototipos. No se esperaba que el lenguaje de la interfaz pudiera tener tanto efecto en la conanza de los usuarios. Estas

72

pruebas ayudaron a demostrar el inters que tienen los usuarios en el sitio Web y a justicar los objetivos de este proyecto. Tal vez no se logr implementar una herramienta para comparar las planillas Excel directamente. Pero por lo menos el uso de nmeros con colores permiti denir una forma rpida de ver los cambios en un determinado mes. Por otro lado se pudieron relajar las restricciones para el Director del Departamento y el Coordinador de Investigacin. Despus de las pruebas se decidi que este aspecto no era muy importante y que podan tener acceso a ms informacin. En general, estas pruebas ayudaron a realizar un primer acercamiento entre los usuarios y la interfaz que deberan manejar en el futuro. Al automatizar la creacin de los archivos Excel se pudo denir un estndar para almacenarlas en forma fsica. A la Secretaria de Investigacin le result muy familiar y no present incomodidades respecto a este estndar. Por lo que se podran imprimir estas planillas y guardarlas en el registro histrico sin ningn problema. Es posible que surjan dudas respecto a la seguridad de las rmas, ya que el sistema las almacena como archivos de imgenes en la base de datos. Pero esto depender de la seguridad en la red del sitio. Al nal del desarrollo quedaron algunas caractersticas que se podran agregar en el futuro. En primer lugar, el cdigo fuente de la implementacin no sigui patrones bien denidos. Como la mayora del cdigo usa lenguaje Java, se podra aprovechar su arquitectura orientada a objetos para optimizar las funciones. Despus est el subproceso para recibir comisiones acadmicas. Como se maneja afuera del D.C.C. sera un proyecto ms costoso, pero podra agilizar la formalizacin. La Jefatura Administrativa indic que este proceso poda volverse muy lento y le gustaran oportunidades para mejorar este problema. Luego estn los problemas tcnicos que se presentaron al instalar la aplicacin en el servidor del D.C.C.. Hubo algunos problemas con permisos de administrador (principalmente para subir archivos a travs de la interfaz), codicacin de caracteres (en la base de datos) y fugas de datos (

leaks ).

memory

Adems no se implement la alerta por correo electrnico que avisara a la Jefatura

Administrativa cuando se validaba una planilla. Estas alertas tambin podran avisar a los profesores cuando se les aceptaba o rechazaba una peticin de giro de fondos. El principal cambio podra ser el manejo de los fondos EP (Estmulo a la Publicacin). Se podran agregar estos datos en el proceso Ingreso de Nuevos Fondos al manejarlo con una tabla ms en la planilla. Puede que esto cause algunos problemas en la interfaz porque podra ser necesario implementar un mecanismo para esconder y mostrar las tablas. Podran manejarse como ingresos, pero almacenados en una tabla distinta en la base de datos. La Jefatura Administrativa indic que los profesores tienen distintas tendencias a recibir el pago de sus fondos EP. La interfaz podra otorgar una herramienta para que denieran cuotas (como una lista innita). Sin embargo, el principal problema caera en la lgica para descontar estos fondos. Por ejemplo, qu se hace si no se denen cuotas?, se descuentan todos los fondos EP o no se descuenta nada?, la Jefatura Administrativa tendra que descontar cada caso o todos los del mes al mismo tiempo?, cules seran los casos excepcionales?, etc. La solucin planteada ofrece un sistema de informacin administrativa que permite gestionar los fondos FII de una manera eciente y efectiva. Se contina el ujo de la informacin desde los ingresos de publicaciones del sitio

U-Papers.

Este sistema mantiene la seguridad

y consistencia de la informacin almacenada. Adems facilita el acceso a los usuarios con la administracin de roles. Por ltimo, es familiar con el registro histrico de la Secretaria

73

de Investigacin. Cumpliendo con los objetivos y mostrando posibles cambios en el futuro, este sistema tiene las oportunidades para mejorar y seguir ayudando a la administracin del D.C.C. y a su equipo docente.

74

Glosario

Java: Lenguaje de programacin de alto nivel creado por la empresa Sun Microsystems. OSGi: Open Service Gateway Initiative. Es un conjunto de especicaciones que dene un sistema de componentes dinmicos para el lenguaje de programacin Java. JavaScript: Lenguaje de programacin interpretado por todos los navegadores Web modernos. Usado principalmente para mejorar interfaces de usuario y pginas Web dinmicas.

Maven: Herramienta de compresin y administracin de proyectos de software creado por la fundacin Apache. Tiene la caracterstica de permitir construir complementos (o

plugins ) en lenguaje Java.

AJAX: Asynchronous JavaScript And XML. Es una tcnica de desarrollo Web para crear aplicaciones interactivas. Su principal ventaja es que permite mantener una comunicacin asncrona entre la pgina vista por un cliente y el servidor.

JSON: JavaScript Object Notation. Es un formato de ligero para el intercambio de datos. No depende de los lenguajes de programacin y puede usarse en lenguajes como C, Java, Javascript y muchos otros.

Microsoft Excel: Aplicacin comercial para construir hojas de clculo distribuida por la corporacin Microsoft. Incluye herramientas para calcular, gracar y programar en el lenguaje de programacin Visual Basic.

75

Bibliografa
[1] Chacn Canda, Felipe Ignacio:

Desarrollo de un repositorio de artculos cientcos.

Memoria (Ttulo Ingeniero Civil en Computacin), Departamento de Ciencias de la Computacin, Facultad de Ciencias Fsicas y Matemticas, Universidad de Chile, Santiago, Chile, Marzo 2012. [2] Rozas Muoz, Juan Pablo:

Rediseo de la interfaz cliente/colaborador de la plataforma workow de la Facultad de Ciencias Fsicas y Matemticas de la Universidad de Chile. Memoria (Ttulo Ingeniero Civil en Computacin), Departamento de Ciencias
de la Computacin, Facultad de Ciencias Fsicas y Matemticas, Universidad de Chile, Santiago, Chile, Otoo 2007.

[3] Object Management Group:

BPMN Information Home.

<http://www.bpmn.org/>,

1997-2012. [consulta: 8 de noviembre de 2012]. [4] Sommerville, Ian:

Software Engeneering.

Adison-Weasley, Boston, 9

edicin, 2011. Memoria (Ttulo

[5] Nichel Valenzuela, David Andrs:

Utilizacin de workow en un SOA.

Ingeniero Civil en Computacin), Departamento de Ciencias de la Computacin, Facultad de Ciencias Fsicas y Matemticas, Universidad de Chile, Santiago, Chile, Agosto 2007. [6] Lpez Quitral, Patricio Humberto:

Desarrollo de una solucin de workow del proceso de otorgamiento de crditos hipotecarios. Memoria (Ttulo Ingeniero Civil en Computacin), Departamento de Ciencias de la Computacin, Facultad de Ciencias Fsicas y Matemticas, Universidad de Chile, Santiago, Chile, Octubre 2001.

[7] Nielsen, Jakob:

useit.com/>,

useit.com: Jakob Nielsen on Usability and Web Design.

1995-2012. [consulta: 8 de noviembre de 2012].

<http://www.

[8] Jordan, Patrick:

An introduction to usability.

Taylor & Francis, Londres, 1998.

[9] Oracle Corporation: 2012].

cd/B10501_01/workflow.920/a95265/toc.htm>,
[10] Action Technologies Inc.:

Oracle Workow Guide Release 2.6.2. <http://docs.oracle.com/

Marzo 2002. [consulta: 9 de abril de

actiontech.com/products/process_manager.cfm>.
76

ActionWorks R Business Process Manager.

<http://www.

[consulta: 9 de abril de 2012].

[11] Joget Workow:

workflow-software/>,

Joget Open Source Workow.

<http://www.joget.org/product/

2012. [consulta: 3 de diciembre de 2012].

77

Anexos
A. Tarjetas de las Pruebas de Usabilidad
Aqu se muestra el contenido de las tarjetas que se usaron en las pruebas de usabilidad de la ltima iteracin. Estas tarjetas indicaban las tareas que los usuarios realizaron mientras interactuaban con la interfaz. En este anexo no se muestran los datos reales que se usaron ya que cambiaban de acuerdo a la sesin. Tarjetas para la Jefatura Administrativa: 1. Ingresar al sitio con nombre y contrasea usuario. 2. Consultar y descargar la planilla de fondos FII de Abril de 2012. 3. Consultar y descargar la planilla de fondos FII de Febrero de 2012. 4. Consultar y descargar la planilla de fondos FII que se encuentra en validacin. 5. En los procesos pendientes, rmar la nueva planilla de fondos FII. 6. En los procesos pendientes, aceptar la peticin de giro de fondos del profesor X. 7. Revisar la cartola de fondos FII del profesor X del ao 2012. 8. Revisar las peticiones de giros de fondos de los profesores X, Y y Z. 9. En la lista de giros, borrar un giro y despus recuperarlo. 10. Revisar el resumen de saldos del ao 2012. 11. En el resumen, corregir el saldo inicial del profesor X para que tenga $1.000. 12. Espere un poco.

13. En los procesos pendientes, actualice los saldos de los profesores. 14. Salir del sitio. Tarjetas para la Secretaria de Investigacin: 1. Ingresar al sitio con nombre y contrasea usuario. 2. Agregar nuevos fondos: En la tabla agregar 2 las, cambiar el monto del profesor X y quitar al profesor Y. 3. Crear una nueva planilla de fondos FII con los fondos ingresados. 4. Consultar y descargar la planilla de fondos FII de Abril de 2012.

3 Entremedio

se simulaba que una planilla se almacenaba en la base de datos.

78

5. Consultar y descargar la planilla de fondos FII de Febrero de 2012. 6. Consultar y descargar la planilla de fondos FII que se encuentra en validacin. 7. Revisar la peticin de giro de fondos del profesor X. 8. En la lista de giros, borrar un giro y despus recuperarlo. 9. Espere un poco.

10. Revisar y leer los procesos pendientes. 11. Revisar la planilla de fondos validada y almacenarla en la base de datos. 12. Salir del sitio. Tarjetas para el Coordinador de Investigacin: 1. Ingresar al sitio con nombre y contrasea usuario. 2. Consultar y descargar la planilla de fondos FII de Abril de 2012. 3. Consultar y descargar la planilla de fondos FII que se encuentra en validacin. 4. En los procesos pendientes, seleccionar la peticin de giro del profesor X y agregar un comentario. 5. Revisar la peticin de giro de fondos del profesor X. 6. En la lista de giros, borrar un giro y despus recuperarlo. 7. En los procesos pendientes, rmar la nueva planilla de fondos FII. 8. Cambiar el lmite de ingresos FII a $7.000.000. 9. Salir del sitio. Tarjetas para el Director del Departamento: 1. Ingresar al sitio con nombre y contrasea usuario. 2. En los procesos pendientes, rmar la nueva planilla de fondos FII. 3. En los procesos pendientes, revisar la peticin de giro de fondos del profesor X y aceptarla. 4. En los procesos pendientes, revisar la peticin de giro de fondos del profesor Y y enviarla al Coordinador de Investigacin. 5. En los procesos pendientes, revisar la peticin de giro de fondos del profesor Z y rechazarla. 6. Revisar la lista de giros de fondos y mostrar los detalles de los 3 giros que acaba de cambiar. 7. En la lista de giros, borrar un giro y despus recuperarlo. 8. Consultar y descargar la planilla de fondos FII de Abril de 2012. 9. Consultar y descargar la planilla de fondos FII que se encuentra en validacin. 10. Revisar el resumen de saldos del ao 2012. 11. Salir del sitio.

4 Entremedio

se simulaba que una planilla se rmaba.

79

Tarjetas para un Profesor: 1. Ingresar al sitio con nombre y contrasea usuario. 2. Pedir un nuevo giro de fondos por $1.000 para ir a una conferencia. 3. Ver la lista de giros de fondos y revisar el giro que acaba de crear (mostrar sus detalles). 4. Revisar los giros de la lista e identicar el estado en que se encuentran. 5. En la lista de giros, borrar un giro y despus recuperarlo. 6. Revisar su cartola de fondos del ao 2012. 7. Salir del sitio.

80

B. Pre-cuestionario
Aqu se muestran las preguntas y las opciones de los pre-cuestionarios. stos se usaron al principio de cada sesin con un profesor. 1. Mantiene una cartola o alguna informacin sobre sus fondos FII?

S No

2. Consulta esta informacin con la Administracin? S No

3. Cul de estas acciones realiza primero cuando quiere invertir sus fondos? Llenar un formulario y enviarlo a la Administracin Mandar una carta al Director del D.C.C. Otro. Especicar

4. Alguna vez ha invertido sin tener fondos sucientes? S No

5. Alguna vez ha invertido sin tener informacin sobre sus fondos? S No

6. Le interesara tener ms informacin sobre sus inversiones? S Slo me interesa saber si una inversin es aceptada o rechazada No

7. Ha perdido fondos por haberlos mantenido mucho tiempo (ms de 2 aos)? S No

81

C. Cuestionario
Aqu se muestran las preguntas las preguntas cerradas de los cuestionarios. stos se usaron al nal de cada sesin y no fueron alteradas durante el desarrollo del proyecto. Las preguntas tenan un puntaje en una escala Likert de 1 a 10. Al nal del cuestionario tambin se agreg una seccin titulada Observaciones para agregar comentarios adicionales. 1. Me gust el sitio 2. Volvera a trabajar con el sitio 3. El sitio Web es fcil de manejar 4. Es fcil encontrar la informacin deseada 5. Los enlaces son claramente identicados 6. Los enlaces funcionan correctamente 7. Las pginas se cargan rpidamente (menos de 30 segundos) 8. Los textos son fciles de leer 9. El uso del color es aceptable 10. El diseo general del sitio es aceptable 11. La organizacin de la informacin del sitio es apropiada 12. El contenido del sitio es relevante 13. La interfaz del sitio es placentera 14. El sitio tiene todas las funcionalidades esperadas 15. Pude realizar las tareas correctamente

82