SIU-TEHUELCHE

SISTEMA DE GESTION DE BECAS

Especificación funcional

Septiembre de 2006

INTRODUCCION

A.	OBJETIVO DEL DOCUMENTO
Acordar que prestaciones funcionales debe tener la primera versión del software a desarrollar por el SIU para las áreas de Bienestar Estudiantil de las UUNN.

B.	ALCANCE DEL SOFTWARE
El objetivo a largo plazo es construir un sistema informático que permita automatizar el trabajo que realiza la Secretaria, Prosecretaria o Dirección de Bienestar Estudiantil. De un primer censo realizado en el encuentro de Tucumán, se concluyó que los temas que se gestionan son: salud, deportes, comedor, becas, turismo, cultura, orientación Vocacional, residencia, guardería, parque automotor, pasantías, tutorías, trabajo social, articulación con escuelas medias, transporte, bolsa de trabajo, voluntariado, entre otros.

Se acordó que el primer objetivo será la construcción de un sistema informático que permita gestionar el tema Becas. En las UUNN se gestionan distintos tipos de becas: Monetarias, Comedor, Transporte, residencia, Jardín de infantes, Prestación de servicios. Las monetarias son las más numerosas y por lo tanto serán las primeras a resolver por el sistema.

El sistema de Gestión de Becas se llamará SIU-Tehuelche. Para la primera versión del sistema esta previsto básicamente incluir las siguientes prestaciones:

•	Convocatoria: Se define las convocatorias con sus características.
•	Inscripción a becas: Completar los formularios de solicitudes de Becas.
•	Registrar resultados de la selección.

DESCRIPCION GENERAL

C.	DIAGRAMA GENERAL 

SIU-TEHUELCHE

Intranet Universidad

Servicios a los alumnos

Alumno 

(1)

(2)

Personal 

Guaraní

(1) Los Alumnos accederán a un sitio público sin necesidad de usuario y contraseña. Luego definirán una palabra clave para identificar su solicitud.
(2) Dentro de la Universidad existirá una intranet donde cada persona podrá acceder al sistema mediante un usuario y contraseña. Cada usuario tendrá disponible un conjunto de prestaciones funcionales específicas para su perfil de usuario. 

D.	PRINCIPALES PRESTACIONES FUNCIONALES

Personal del Área de becas:

•	Definir una convocatoria de becas.
•	Consultar estadísticas sobre las convocatorias.
•	Consultar por convocatoria el detalle de alumnos por Unidad académicas
•	Redactar preguntas frecuentes de una convocatoria.
•	Crear una solicitud de becas para un Alumno.
•	Cancelar una suscripción de solicitud de beca.
•	Modificar el estado una solicitud de beca otorgada.
•	Envió automático de mails para posibles candidatos.
•	Reabrir una solicitud que estaba cerrada.
•	Registrar recepción de solicitudes + comprobantes.
•	Registrar un pedido particular de documentación realizado a un alumno.
•	Modificar datos de una solicitud cerrada.
•	Cargar el resultado de la selección y evaluación de solicitudes.

Trabajadoras sociales

•	Definir la agenda de entrevistas.
•	Registrar el resultado de una entrevista con un Alumno.
•	Consultar Agenda de entrevistas.

Alumnos:
•	Consultar las convocatorias activas.
•	Obtener palabra clave para cargar solicitudes.
•	Completar el formulario de solicitud de Beca.
•	Imprimir el formulario con los datos ingresados.
•	Consultar Agenda de entrevistas
•	Cerrar el ingreso de datos al formulario.
•	Consultar el resultado de su solicitud.
¿Qué pasa con las solicitudes que aun no han sido cerradas y finaliza la fecha fin de la convocatoria? se las identifica con algún estado?
Administrador del Sistema:
•	Definir usuarios y perfiles de acceso al sistema.
•	Importar datos de Alumnos de Guaraní (Datos Personales / censales y rendimiento académico).
•	¿Exportar datos de Alumnos para Guaraní?.
•	Definir los valores de todas las tablas maestras que deberán existir.

Notación:
•	Prestaciones que ya tienen una especificación en el punto 3.
•	Prestaciones a las que les falta especificar el comportamiento.

E.	USUARIOS DEL SISTEMA
•	Personal del área de Bienestar Estudiantil que gestiona los programas de becas.
•	Alumnos.
•	Trabajadora Social
•	Administrador del Sistema

F.	RESTRICCIONES NO  FUNCIONALES
•	La base de datos a utilizar será Postgresql y la herramienta de desarrollo será PHP
•	Se utilizará el SIU-TOBA como infraestructura de desarrollo.
•	Restricciones de diseño:
o	Modelar los datos que no cambian de una persona separados de los que van cambiando en cada convocatoria.
o	Contar con un mecanismo de log de cambios (determinar cuales datos son mas sensibles).    

Creación de una estructura redundante para guardar la información de las solicitudes

Conceptualmente se definen dos estructuras similares:
•	Solicitud: Contiene siempre los últimos datos actualizados de una solicitud. Esta será la base sobre la cual se realiza el proceso de selección y evaluación de becas.
•	Versiones de solicitudes: Copia completa de la solicitud a un momento determinado. Una versión implica conceptualmente que alguno de los datos han sido modificados respecto a otra versión previa. Cada versión solo podrá crearse en determinados momentos y como producto de determinadas acciones que se detallan a continuación:

Acciones	Entidad: Solicitud	Entidad: Versiones de solicitud	
Alumno inicia solicitud	Genera un registro		
Alumno va completando/ cambiando los datos 	Actualiza los datos		
Alumno cierra solicitud	Guarda los últimos datos + cambia de estado	Genera una copia de los datos de la solicitud a este momento.	
Reabre la solicitud	Solo cambia el estado.		
Personal modifica datos de una solicitud cerrada	Actualiza los datos	Genera una copia de los datos de la solicitud a este momento.	

Nota:
•	Cada versión contiene los datos específicos de la solicitud + Fecha en que se genera la versión + usuario que la genero. Cuando el alumno cierra la solicitud, la versión que se genera debería ser igual a la solicitud que el alumno envía firmada (copia en papel).
•	Se podría implementar esta idea mediante un trigger de update en la tabla solicitud.
•	Se recomienda que el trigger solo grabe una nueva versión si efectivamente se cambio algún dato respecto a la versión anterior.

ESPECIFICACION DE REQUERIMIENTOS
abreviaciones de casos de uso:
CU Pn: significa caso de uso del personal de área número n.
CU In: significa caso de uso del usuario interno que mantiene las tablas maestras, número n
CU An: significa caso de uso del alumno, número n.

Índice de Casos de Uso especificados
CU P1: Personal define una convocatoria de becas
CU P2: Personal consulta estadísticas sobre una convocatoria.
CU P3: Personal consulta por convocatoria el detalle de alumnos por Unidad académicas.
CU P4: Personal Crea una solicitud de beca para un Alumno.
CU P5: Personal Cancela una solicitud de beca.
CU P6: Personal cambia el estado de una solicitud de beca otorgada.
CU P7: Personal reabre una solicitud que estaba cerrada.
CU P8: Personal registra recepción de una solicitud y la documentación requerida.
CU P10: Personal modifica datos de una solicitud cerrada.
CU P11: Personal carga el resultado de la evaluación para una solicitud.
CU P12: Personal Importa datos Censales del SIU-Guaraní
CU P14: Personal Importa datos Académicos del SIU-Guaraní
CU P15 Personal transfiere datos académicos importados a formularios de una convocatoria en particular.
CU P15’ Se transfieren los datos académicos para un alumno en particular.
CU P16: Personal Importa datos de Unidades Académicas y Carreras del SIU-Guaraní.
CU P17: Personal genera un usuario para una persona.
CU P18: Personal define la agenda de entrevistas
CU P19: Personal consulta la agenda de entrevistas
CU P20: Personal cancela la agenda para un entrevistador
CU P21: Personal Consulta la agenda para una solicitud
CU P22: Proceso de incorporación de datos Censales a la solicitud de un alumno
CU P23: Personal recupera nombre de usuario y la palabra clave del alumno
CU A1: Un alumno consulta las convocatorias activas
CU A2: Un alumno crea usuario y palabra clave para cargar solicitudes
CU A3: Un alumno completa el formulario de solicitud de Beca.
CU A4: Alumno cierra la solicitud.
CU A5: Alumno imprime la solicitud.
CU A6: Alumno consulta agenda de entrevistas
CU A7: Alumno consulta novedades sobre su solicitud.
CU A8: Alumno Imprime la solicitud.
CU A9: Alumno ingresa al sistema
CU A10: Alumno recupera usuario y contraseña
CU A11: Alumno modifica la contraseña.
CU A12: Un alumno genera una solicitud para una convocatoria activa.
CU I2: Personal interno selecciona una solicitud.
CU A2: Un alumno crea usuario y palabra clave para cargar solicitudes (modificación)

Operaciones para el Personal del área

CU P1: Personal define una convocatoria de becas
Actores: Personal del Área de becas
Precondición:  
•	No hay.
Descripción:
Alta
•	Nombre de la convocatoria.
•	Fecha inicio y fin de la convocatoria.
•	Destinatarios: Ingresantes a la Universidad / Alumnos regulares / ambos.
•	Requisitos de la convocatoria: Campo de texto libre. 
•	Explicación de los pasos que debe realizar el Alumno para completar todo el proceso. Podría implementarse mediante la redacción de un documento que se guarda en el sistema para que el alumno pueda bajarlo cuando esta consultando por esta convocatoria.
•	Lugar de contacto (a donde puede ir a averiguar mas información)
•	TE de contacto
•	Mail para consultas.
•	Periodo de evaluación: Fecha desde / fechas hasta que debe tomarse en cuenta para informar el rendimiento académico.
•	Activar / desactivar convocatoria
•	Tipo de Becas que incluye la convocatoria. Para cada tipo de beca se deben considerar:
i.	Características de la beca (ejemplo: $ 150 pesos por mes).
ii.	Cantidad de becas estimadas que se darán.
iii.	Presupuesto estimado para esta beca.

Baja:
•	Controlar que no exista ninguna solicitud asociada a la convocatoria 

Modificación
•	Cambiar Tipo de becas y periodo de evaluación cuando la convocatoria esta activa y ya existen solicitudes debería, al menos, advertir al usuario sobre la situación y pedirle una confirmación para guardar los cambios.
(ahora no se puede agregar ni eliminar ningún tipo de beca a una convocatoria con solicitudes asociadas)

CU P2: Personal consulta estadísticas sobre una convocatoria.
Actores: Personal del Área de becas
Precondición:  
•	No hay.
Descripción:
1.	Seleccionar una convocatoria (no necesariamente tiene que estar activa).
2.	Muestro el total de solicitud + cantidad por estado 
3.	Muestro un detalle de cantidad de solicitudes por Unidad Académica.

Ejemplo de consulta por convocatoria:
Filtro:
•	Nombre de la convocatoria.

Resultados posibles:
•	Por convocatoria seleccionada: nombre de convocatoria, cantidad total de solicitudes
Mostrar:
•	Corte por unidad académica: nombre de unidad académica
o	Estado de la solicitud (Fila)
o	Tipo de beca (Columna)
o	Cantidad de solicitudes (Fila:Columna)

Observación: si no selecciona una en particular que liste todas

CU P3: Personal consulta por convocatoria el detalle de alumnos por Unidad académicas.
Actores: Personal del Área de becas
Precondición:  
•	No hay.
Descripción:
1.	Seleccionar una convocatoria (no necesariamente tiene que estar activa).
2.	Muestro la lista de alumnos por Unidad Académica.

Ejemplo por convocatoria por detalle: 
Filtros posibles:
•	Nombre de la convocatoria.
•	Por unidad académica

Resultados posibles: Mostrar
•	Nombre convocatoria
•	Nombre de  unidad académica: cantidad total de solicitudes
Con las columnas del detalle de alumnos:
o	Nombre y apellido
o	Tipo y número de documento
o	Mail
o	Teléfono
o	Estado de la solicitud (pendiente, confirmada, impresa), 
Una fila por solicitud
Observación 1: Si no selecciona una convocatoria, que liste todas las convocatorias
Si solo selecciona la convocatoria, que liste todas las unidades académicas para esa convocatoria
Observación 2: posiblemente esta consulta exportará los datos a una planilla Excel. Se tratará en el comité 

CU P4: Personal Crea una solicitud de beca para un Alumno. 
Precondición:  
•	.
Descripción:
1.	Se selecciona una convocatoria.
2.	Los datos que ingresa para crear una solicitud son: tipo y número de documento, nombre y apellido.
3.	Con estos datos el sistema controla que el alumno para esa convocatoria no tenga otra solicitud asociada.
4.	La solicitud queda asociada al alumno.
5.	Personal puede modificar la solicitud hasta cerrarla

CU P5: Personal Cancela una solicitud de beca. 
Precondición:  
•	El estado de la solicitud puede ser confirmada o pendiente
Descripción:
1.	Personal selecciona una solicitud (Ver CU I2).
2.	El sistema presenta la solicitud seleccionada (como la operación Confirmar).
3.	Personal confirma su Cancelación.
4.	El sistema solicita el ingreso del motivo de cancelación. Se registra la fecha actual.
5.	Personal ingresa el motivo de una lista despleglable de valores (no alcanza los requisitos, abandono de estudios).
6.	Personal confirma el motivo ingresado.
7.	El sistema registra el estado “Cancelada” en el campo estado de la solicitud.

CU P6: Personal cambia el estado de una solicitud de beca otorgada. 
Precondición:  
•	El estado de la solicitud es evaluada
Descripción breve: Esta operación permite modificar el estado del resultado de la evaluación para un tipo de beca de una solicitud en particular. Esto permite al personal realizar el seguimiento de una beca pudiendo indicar que una beca otorgada para un alumno puede suspenderse por un tiempo o cancelarse.
Descripción:
1.	Se selecciona una solicitud (Ver CU I2).
2.	El sistema muestra los tipos de beca de la solicitud, con el resultado de la evaluación. 
3.	Se selecciona un tipo de beca.
4.	El sistema muestra los campos: estado del tipo de beca (los valores son: Activo, Suspendido, Cancelado), motivo de modificación (lista de valores: abandonó los estudios, perdió regularidad), y la fecha.
5.	Se modifica el estado, se selecciona el motivo, y se registra la fecha, para el tipo de beca seleccionada.
6.	Se confirma el cambio de estado para el tipo de beca.

CU P7: Personal reabre una solicitud que estaba cerrada. 
Precondición:  
•	.
Descripción:
6.	Se selecciona una solicitud cerrada que corresponda a una convocatoria vigente.
7.	Se confirma su reapertura.
8.	Muestro la solicitud tal como se encuentra en este momento. (es decir, si fue modificada por personal interno, muestro las modificaciones realizadas).
9.	El estado de la solicitud pasa a “Pendiente”, se actualiza el estado de la solicitud.

CU P8: Personal registra recepción de una solicitud y la documentación requerida.
Descripción breve: Esta operación lleva un registro de información recibida para una solicitud, es un si/no (mediante 1 tilde) con la fecha de recibido. El sistema permitirá desmarcar la opción.
Descripción:
1.	Seleccionar una solicitud. (Ver CU I2).
2.	El sistema muestra el campo check y fecha para la solicitud.
3.	Tilda el check de recibido e ingresa la fecha.
4.	Se registra la operación y el sistema confirma que se ha realizado. 

CU P10: Personal modifica datos de una solicitud cerrada. 
Precondición:  
•	No hay.
Descripción:
1.	Se selecciona una solicitud de una convocatoria o para un alumno en particular (el sistema debe permitir la selección por nombre, apellido, tipo y nro de documento).
2.	Se despliegan todos los datos de la solicitud agrupados en solapas de la misma manera que las completo el Alumno.
3.	Se podrá cambiar cualquiera de los valores de la solicitud.
4.	Al confirmar la grabación de los cambios realizados, el sistema solicita que se seleccione el motivo por el cual se realiza la modificación (motivos que serán tomados de una Tabla).
5.	El sistema alerta sobre el hecho de que se generará una copia de todos los datos de la solicitud.
6.	Grabar los cambios realizados y generar la copia de datos en la estructura paralela.*

* Habría que poner cierta inteligencia de manera que solo genere las copias cuando efectivamente hubo cambios y no cada vez que el usuario presiona “guardar”. Queda pendiente esta característica para ver analizar posteriormente.

CU P11: Personal carga el resultado de la evaluación para una solicitud.
Precondición: 
•	El alumno ya completo la solicitud, la cerró y la imprimió. Es razonable pensar que incluso ya presento los papeles correspondientes.
Descripción:
1.	Filtrar por convocatorias y tipo de beca que se encuentren activas
2.	Seleccionar la convocatoria para cual se realiza la evaluación
3.	Seleccionar la solicitud de un Alumno (podrá ver toda la información cargada por el Alumno más las modificaciones posteriores realizadas internamente y el resultado de las entrevistas, si es que fueron anteriores)
4.	Personal podrá ahora modificar el resultado de una evaluación para cada tipo de beca en particular de la solicitud (cada solicitud tiene asociado uno o más tipo de becas a los que se postula y cada tipo de becas debe tener un valor de resultado para seleccionar), 
5.	Se registra el resultado de la evaluación y actualiza el estado de la solicitud a “Evaluada” Los valores presentados para la evaluación deben tomarse de una tabla.
6.	Se registra por defecto al otorgar el beneficio por tipo de beca el estado del tipo de beca será “Activo”, y la fecha.
 
CU P12: Personal Importa datos Censales del SIU-Guaraní
Precondición: Realizar la exportación de los datos de guaraní. Antes de realizar la importación debe existir en el sistema la unidad académica para la cual se va a realizar la importación.
Descripción:
1.	Personal selecciona los archivos de datos censales y unidades académicas exportados del SIU-Guaraní.
2.	Cada archivo de texto contiene los datos de una unidad académica.
3.	Se verifica que la cantidad de campos por filas contenida en el archivo sea la esperada.
4.	Es posible agregar una descripción a los datos que se están importando.
5.	Se debe seleccionar entre importar un nuevo conjunto de datos, o bien, reemplazar el conjunto de datos importado previamente.
6.	El proceso de importación comienza con la limpieza de las tablas temporales (cargadas con los datos de la importación anterior),  y almacenar la nueva información extraída del archivo de texto.
7.	Luego, los datos son pasados de la tabla temporal, a las tablas definitivas realizando un “insert” en el caso de realizar una importación nueva, o un UPDATE en el caso de seleccionar reemplazar los datos.
8.	Estas tablas definitivas corresponden a un modulo VGA (Vista general de alumnos), de donde se podrá obtener la información de un alumno en particular.
9.	Cada dato almacenado, mantiene una fuente que determina el origen de la información (fecha y unidad académica).
10.	Por lo tanto, para una misma persona pueden existir varios “conjuntos” de datos, cada uno de los cuales, corresponde a importaciones diferentes (distintas unidades académicas).
11.	No existe la necesidad de tener una tabla de correlación o “diccionarios”. La exportación/importación misma se encarga de realizar dicha correspondencia para diferentes códigos.
12.	Luego de finalizada la importación se informa la fecha de importación, junto cantidad de registros procesados y personas agregadas.
13.	Notar que no necesariamente un registro implica la agregación de una persona. Si una persona existe, solo se agrega un nuevo conjunto de datos para esa persona.
14.	La unicidad de un conjunto de datos para una persona esta dada por la fuente.

Alternativa:
5.	Personal selecciona reemplazar datos.
6.	Se selecciona un archivo de texto exportado de Guaraní. 
7.	Se verifica que el conjunto de datos haya sido importado previamente. Para esto se determina que exista la fuente de datos (para esto se toma el nombre del archivo que contiene la información de la unidad académica y fecha de la exportación).
8.	Si es así, se reemplaza el conjunto de datos para esa fuente.
9.	Finalizado el proceso de reemplazo, nuevamente se informa la cantidad de registros y de personas agregadas en las tablas.

CU P14: Personal Importa datos Académicos del SIU-Guaraní 
Precondición: 
Archivos de interfaz generados por el sistema SIU-Guaraní.
Debe existir la unidad académica para la cual se va a realizar la importación.
Descripción:
1.	El sistema solicita al usuario que seleccione el archivo que contiene la información sumarizada de los datos académicos y otro archivo que contiene la historia académica, que ingrese una descripción del conjunto de datos (opcional) y presenta un botón de procesar. 
2.	Personal presiona “Procesar”.
3.	El sistema verifica que los archivos existan y que la estructura de datos de ambos sea la correcta.
4.	El sistema vacía las tablas temporales de interfaz, lee los archivos seleccionados y vuelca su información en las tablas temporales.
5.	Una vez finalizado exitosamente el proceso anterior, los datos son pasados de la tabla temporal a las tablas definitivas generando una nueva fuente de datos (ver Modelo1).
6.	El sistema informa del éxito de la importación, indicando la cantidad de registros procesados.
7.	Fin.
Modelo 1

CU P15 Personal transfiere datos académicos importados a formularios de una convocatoria en particular.
Precondición: 
Importación de datos académicos realizados en el sistema.
Descripción:	
1.	Personal selecciona la convocatoria para la que desea transferir datos académicos. 
2.	El sistema presenta la lista de las importaciones de datos existentes.
3.	Personal selecciona un lote de datos importados a transferir a los formularios de la convocatoria seleccionada.
4.	El sistema indica que se sobrescribirá toda la información de datos académicos existente para los alumnos que se encuentre información en las tablas de importación, y cuyas solicitudes no estén en estado “Cancelada”  ni “Evaluada”.  Y solicita que el usuario confirme continuar con la operación.
5.	Personal confirma.
6.	El sistema, por cada formulario para esa convocatoria que no se encuentre en estado “Cancelado” ni “Evaluada”, verifica si existe esa persona en el lote de información importada y, en ese caso, transfiere la información requerida por el formulario (ver CU P15’). 
7.	El sistema informa la finalización de la operación, la cantidad de alumnos con información actualizada.
8.	Fin.
Alternativa al punto 5:
5.	Personal cancela la importación.
6.	El sistema indica que la transacción ha sido cancelada.
7.	Fin.

CU P15’ Se transfieren los datos académicos para un alumno en particular.
Nota: Este caso de uso no es independiente! Es parte del CU P15.
Precondición: 
La solicitud no se encuentra en estado “Cancelado” ni “Evaluada”.
Descripción:	
1.	El sistema genera una nueva versión de la solicitud.
2.	El sistema toma los campos:
•	Legajo
•	Descripción de la unidad académica
•	Descripción de la carrera
•	El año de ingreso
•	Calcula la cantidad de años de la carrera (cantidad de meses / 12)
•	Total de materias
•	Año que cursa
•	El menor año de las materias aprobada que tenga
•	Cantidad de materias habilitado a cursar
•	Calcula la cantidad total de materias aprobadas (Resultado=A)
•	Calcula la cantidad de materias aprobadas en el periodo de evaluación. Si dicho periodo está en null, este valor es igual al anterior.
•	Calcula el total de materias regularizadas (no aprobadas).
•	Calcula el total de materias regularizdas en el periodo de evaluación. Si dicho periodo está en null, este valor es igual al anterior.
•	 Toma el valor almacenado para el porcentaje de aprobación de la carrera.
•	Toma el valor almacenado para el promedio universitario con aplazos
•	Toma el valor almacenado para el promedio universitario sin aplazos.
y los registra en el formulario del alumno, sobrescribiendo cualquier valor existente en dichos campos. (ver Nota 1)
3.	Fin.
Nota 1:

CU P16: Personal Importa datos de Unidades Académicas y Carreras del SIU-Guaraní.
Precondición: Realizar previamente la exportación de SIU-Guaraní de los datos de unidad académicas y carreras.
Descripción:
4.	Personal selecciona el archivo de UA y Títulos exportados del SIU-Guaraní.
5.	Se importa la información contenida en el archivo seleccionado, actualizando la información existente para esa Unidad Académica en particular e incorporando la nueva.
6.	El Sistema debe considerar que puede existir la posibilidad que se realice una importación de las carreras para cada Unidad Académica.
7.	Se informa la cantidad de registros importados.
8.	Fin.

CU P17: Personal genera un usuario para una persona.
Precondición: 
•	No hay.
Descripción:
1.	El sistema muestra una pantalla para el ingreso de: Tipo y nro de documento, apellido, nombre, dirección de correo electrónico, y una opción de cargar información a la solicitud.
2.	Personal completa los datos y presiona el botón generar.
3.	El sistema genera la entrevista y registra el correo electrónico en la tabla de contactos de la persona.
4.	El Sistema informa que la operación fue realizada con éxito.
5.	Fin.

CU P18: Personal define la agenda de entrevistas
En esta operación las entrevistas tendrán los siguientes estados: 
Pendiente: pautada pero aun no realizada
Realizada: pautada y realizada
Cancelada: pautada y suspendida
Actores: Personal del área. 
Descripción:
Alta
1.	Selecciona una solicitud (ver  CU P21) El sistema mostrará si tiene entrevistas o no.
2.	El menú de alta de entrevista esta compuesto por las filas: alumno, fecha, horario inicio, horario fin, quién es el entrevistador, estado de la entrevista. Se podría pensar que para una solicitud se pueden dar de alta varias entrevistas.
3.	Selecciona  fecha (calendario), entrevistador (lista desplegable) y se ingresa hora inicio, hora fin (formato hh:mm). El sistema controla que el personal que lo entrevistará no tiene entrevistas pendientes para la fecha, hora inicio y hora fin (para el mismo entrevistador y misma fecha la hora de inicio debe ser posterior a la fecha fin de la entrevista anterior)
4.	Registra la fecha, hora de inicio y hora de fin de la entrevista, el personal de área que lo entrevistará.
5.	Se registra la entrevista para esa solicitud como Pendiente.
6.	El sistema informa que la entrevista se registró en tal fecha y horario para ese alumno con el personal que lo entreviste.

Modificación: ingresa el resultado de una entrevista
Precondición: 
•	Que la solicitud tenga entrevistas.
1.	Selecciona una solicitud (ver CU P21). 
2.	El sistema muestra todas las entrevistas asociadas a la solicitud.
3.	Selecciona el detalle de la entrevista en la fecha y hora establecida.
4.	Registra el resultado de la entrevista en las observaciones de la misma. Se lleva el historial de todas las entrevistas para una solicitud.
5.	Se actualiza el estado de la entrevista a Realizada.
6.	El sistema informa que se ha registrado la entrevista para ese alumno.

“En esta instancia no se llevarán los controles que para poder modificar una entrevista el estado debe ser pendiente, por ejemplo. Que las entrevistas realizadas, son solo de lectura., etc “

Variante A para el punto 4 de modificación: cambia fecha, horario o entrevistador para una solicitud. Contempla cuando lo único que se realiza es una corrección de los datos de una entrevista registrada. Modificar una entrevista 
4.	Al desplegar los datos de la entrevista, el sistema mostrará el botón modificar (guarda las modificaciones sobre la modificación de horario y/o entrevistador) 
5.	Se controla que el entrevistador y horario estén disponibles, para los nuevos valores de la modificación.
6.	Se guardan los cambios.

Variante B para el punto 4 de modificación: cambia el estado de la entrevista a Cancelada.
4.	Al desplegar los datos de una entrevista, el sistema mostrará la posibilidad de cancelar la entrevista, mediante el botón cancelar.
5.	Al presionarlo, el sistema informará que se realizará la cancelación de la misma.
6.	Se registra el cambio de estado.
7.	Al cancelar una entrevista pendiente para un alumno, significa que la fecha, horario y entrevistador quedan disponibles para esa fecha y horario. 

Baja: 
Precondición: que la solicitud tenga entrevistas.
1.	Seleccionar una solicitud (ver CU P21)
2.	El resultado es que muestra todas las entrevistas asociadas a la solicitud. 
3.	Selecciona el detalle de la entrevista en la fecha y hora establecida.
4.	El sistema muestra el botón eliminar.
5.	Se confirma el borrado de la entrevista.
6.	Al borrar una entrevista, la fecha, horario y entrevistador quedan disponibles.

CU P19: Personal consulta la agenda de entrevistas
Actores: Personal del área. 
Precondición:  
•	Que por lo menos exista registrada una entrevista
Descripción:
1.	Selecciona los filtros:
a.	Fecha desde y fecha hasta.
b.	Estado de la entrevista.
c.	Personal que entrevista.
2.	El resultado de la consulta, mostrará la/s entrevista/s (las columnas que mostrará serán: alumno, fecha, horario de inicio, horario de fin, quien entrevista, estado de la entrevista, más el botón de detalle). Mostrará una fila por entrevista.
3.	 El sistema permitirá ir al detalle de cada fila con la información disponible de la entrevista. 

CU P20: Personal cancela la agenda para un entrevistador 
Actores: Personal del área. 
Precondición: 
•	Que el entrevistador tenga entrevistas pendientes
Descripción:
1.	Selecciona todas las entrevistas pendientes del entrevistador (ver CU P19).
2.	Esta pantalla muestra la/s entrevista/s, permite seleccionar todas las entrevistas o cada un cada una.
3.	Selecciona la/s entrevista/s y cambia el estado a Cancelada.
4.	Se confirma la cancelación de la/s entrevista/s.
5.	 Al cancelar una entrevista pendiente, significa que la fecha, horario y entrevistador quedan disponibles.

CU P21: Personal Consulta la agenda para una solicitud
Actores: Personal del área. 
Precondición:  
•	Que la solicitud tenga entrevistas(pendientes, realizadas o canceladas)
Descripción:
1.	Selecciona una solicitud (ver CU I2).
2.	Selecciona los filtros:
a.	Fecha desde y fecha hasta. 
b.	Estados de la entrevista (realizada, pendiente, cancelada).
c.	Persona que entrevista.
d.	En caso de no seleccionar ninguno de los filtros anteriores, se tomará por defecto todo el histórico de las entrevistas realizadas, pendientes y canceladas para esa solicitud.
3.	El resultado es un listado de todas las entrevistas con fecha, hora inicio, hora fin, con la persona que entrevista, observaciones y estado de la entrevista. En caso de no tener entrevistas de acuerdo a los filtros seleccionados el sistema informará.

CU P22: Proceso de incorporación de datos Censales a la solicitud de un alumno
Descripción breve: El sistema permitirá incorporar los datos censales del alumno de las tablas provenientes de guaraní o de la convocatoria anterior, a la solicitud de la convocatoria para el alumno que se está inscribiendo. El proceso se activa cuando el alumno ingresa al sistema por primera vez, cuando saca el usuario y password (los datos censales se encuentran vacíos para esa solicitud), todos los campos se actualizarán con la información proveniente de las tablas mencionadas.
Se tomará como válido en primer lugar los datos censales provenientes de guaraní, y en segundo lugar de la convocatoria anterior. 
Cómo decidir qué datos tomar para cada tabla importada de guaraní de un alumno:
De cada tabla para una persona se tomarán los datos más recientemente informados.
Ejemplo: para la persona X, en la tabla datos laborales, existen Y registros con id_fuente_datos distintos, solo tomo el registro de fecha más reciente.
Por esta razón podría pasar que para una misma persona la fecha de importación de datos económicos sea distinta a la de datos de salud.
Precondición: 
•	Datos censales importados al SIU-Tehuelche.
•	Datos generales y actuales del SIU-Tehuelche de la convocatoria anterior.
Descripción:
1.	El alumno ingresa al sistema para obtener el usuario y la contraseña. En esta instancia los datos censales se encuentran vacíos.
2.	Se dispara el proceso de incorporación de datos censales disponibles en las tablas tehuelche.
3.	Se busca el alumno, primero en las tablas provenientes de guaraní (si existe en la tabla personas, se tomarán los datos de cada una de las tablas con la fecha mas reciente), si no se encuentra en la tabla personas, se tomarán los datos de las tablas de tehuelche de la convocatoria pasada.
4.	Se toman los datos censales de ese alumno. 
5.	Se actualizan los datos censales en los campos correspondientes. Quedan disponibles para que el alumno los modifique.
Variante al punto 4
4.	El resultado de la búsqueda es que el alumno no se encuentra ni en las tablas provenientes de guaraní ni en las tablas de tehuelche de la convocatoria pasada.
5.	Los datos censales del alumno no se actualizan, por lo que quedan vacíos para que el alumno los ingrese, cuando ingrese al sistema.
6.	Fin de proceso de incorporación de datos censales.
Observaciones: 
Para los datos provenientes de la convocatoria anterior, no se específica el estado en que debería estar la convocatoria para que sea válido.
Para los datos provenientes de la importación guaraní: podría pasar que el conjunto de datos recabados de distintas importaciones guaraní, no traiga datos de una tabla en particular, por lo que solo se actualizará lo informado en guaraní como válido. No se realizará el proceso de búsqueda de esa tabla sin datos sobre la convocatoria pasada.

CU P23: Personal recupera nombre de usuario y la palabra clave del alumno
Actores: Personal del área. 
Precondición:  
•	Que esté generado para la persona su usuario y contraseña.
Descripción:
1.	Personal selecciona la operación de “recuperación de usuario y clave” del menú
2.	El sistema presenta una pantalla con la posibilidad de filtrar por: nombre, apellido, tipo de documento y número de documento.
3.	Personal ingresa la información que desea y selecciona el botón de búsqueda.
4.	El sistema realiza la búsqueda con los valores ingresados por personal en el filtro. 
5.	El sistema muestra una lista de coincidencias, permitiendo seleccionar a uno de ellos.
6.	Personal selecciona la persona a la cuál le quiere enviar sus datos por mail.
7.	El sistema genera el mail para la cuenta de correo registrada para esa persona.
8.	El sistema realiza el envío del mail.
9.	El sistema informa que se ha realizado la operación con éxito.

Variante al punto 5: No hay personas que coincidan con los patrones especificados.
5.	El sistema informa que no existen coincidencias con el patrón ingresado.
6.	El sistema vuelve a poner la pantalla que permite ingresar los valores para el filtro.

Variante al punto 7: No hay registrado un correo electrónico para esa persona.
6.	El sistema informa que no hay registrado un mail para esa persona.
7.	El sistema vuelve a presentar la pantalla con los resultados de la búsqueda.

Variante al punto 8: Falla el envío del mail.
7.	El sistema informa que ha fallado el envío del mail y que no se pudo enviar.
8.	El sistema vuelve a presentar la pantalla con los resultados de la búsqueda.

Operaciones para el Alumno

CU A1: Un alumno consulta las convocatorias activas
Actores: Alumno 
Precondición:  
•	El alumno accede a un sitio público sin restricción de acceso. 
Descripción:
1.	Muestra toda la información disponible sobre las convocatorias (incluye las preguntas frecuentes definidas).

CU A2: Un alumno crea usuario y palabra clave para cargar solicitudes
Actores: Alumno 
Precondición:  
•	El alumno accede a un sitio público sin restricción de acceso. 
Descripción:
1.	Ingresa al sistema como usuario anónimo.
2.	El sistema muestra los siguientes campos a informar: tipo y numero de documento, Nombre y Apellido, fecha de nacimiento, sexo, dirección de correo electrónico, nombre de usuario y la palabra clave. Se solicitará ingreso y reingreso tanto de clave como de correo electrónico.
3.	El sistema controla que para el tipo y número de documento informado no exista un usuario y palabra clave ingresado con anterioridad.
4.	El sistema controla que la palabra clave ingresada y reingresada sea la misma.
5.	El sistema controla que la dirección de correo electrónico ingresa y la reingresada sea la misma.
6.	En caso que la universidad haya decidido (mecanismo de configuración del sistema) si quiere enviar un mail al alumno con los datos ingresados, incluido la palabra clave. 

Variante al punto 3: Existe un usuario y clave generados para la persona ingresada. 
3.	El sistema informa que ya existe un usuario generado para la persona ingresada.
4.	El sistema vuelve a presentar la pantalla con todos los datos que había ingresado.

Variante al punto 4: La clave ingresada y reingresada no coinciden. 
4.	El sistema informa que los datos ingresados para la clave no coinciden.
5.	El sistema vuelve a presentar la pantalla con los datos que había ingresado, salvo los campos para ingreso y reingreso de palabra clave que los pone en blanco.

Variante al punto 5: La dirección de correo electrónico ingresada y reingresada no coinciden. 
5.	El sistema informa que los datos ingresados para el correo electrónico no coinciden.
6.	El sistema vuelve a presentar la pantalla con los datos que había ingresado, salvo los campos para ingreso y reingreso de correo electrónico que los pone en blanco.

CU A3: Un alumno completa el formulario de solicitud de Beca. 
Actores: Alumno 
Precondición:  
•	Persona logeada en el sistema.
Descripción:
1.	El sistema muestra todas las solicitudes que tiene esa persona.
2.	Alumno selecciona una solicitud a modificar.
3.	El sistema presenta el formulario correspondiente en modo de edición si la solicitud se encuentra en estado “Pendiente”.
4.	El alumno modifica los datos que considere necesarios.
5.	El alumno presiona el botón “Guardar”.
6.	El sistema registra los valores ingresados.
7.	El sistema verifica si cambió la dirección de correo electrónico, en cuyo caso registra esta dirección en la información de contacto de la persona.
8.	El sistema informa que la operación se ha realizado con éxito.

Variante al punto 3: La solicitud no se encuentra en estado pendiente.  
3.	El sistema informa presenta la solicitud pero no permite la modificación de la información.

CU A4: Alumno cierra la solicitud. 
Precondición:  
•	.
Descripción:
1.	Alumno selecciona la solicitud a cerrar.
2.	Alumno confirma que desea cerrar la solicitud.
3.	El sistema controla que estén ingresados todos los datos obligatorios.
4.	El sistema cambia el estado de la solicitud a “Confirmada”.
5.	El sistema genera una copia completa de la solicitud en una estructura paralela que contiene los mismos datos + fecha y usuario (esta pensado que se implemente mediante un trigger en la base). El usuario será “alumno” y esta copia será un equivalente a la declaración jurada que envía el Alumno ya que no se podrá cambiar de ninguna manera.
6.	El sistema informa un número de comprobante con posibilidad de que sea impreso.

CU A5: Alumno imprime la solicitud. 
Precondición:  
•	No hay.
Descripción:
1.	Alumno selecciona una solicitud.
2.	Sistema imprime la solicitud. Si la solicitud esta abierta debe aparecer una leyenda del tipo “impresión borrador” y si ya esta cerrada “declaración jurada”.
3.	Cambiar el estado a “impreso” si la solicitud estaba en estado “cerrada”.
4.	Guardar la fecha de impresión. Cada impresión pisa la fecha anterior ya que solo interesaría conservar la última fecha.

CU A6: Alumno consulta agenda de entrevistas 
Actores: Alumno 
Precondición:  
•	Tener al menos una entrevista registrada.
Descripción:
1.	Selecciona los filtros:
a.	Fecha inicio y fecha fin
b.	Persona que entrevista
c.	Estado de la entrevista(pendientes, realizadas, canceladas)
2.	Si no seleccionó ningún filtro, muestra todas las entrevistas para la solicitud.
3.	El resultado es un listado de todas las entrevistas con fecha, hora inicio, hora fin, con la persona que lo entrevistó/entrevistará y estado de la entrevista. Con la opción de ir al detalle de cada una.
4.	En caso de no tener entrevistas de acuerdo a los filtros seleccionados el sistema informará.

CU A7: Alumno consulta novedades sobre su solicitud. 
Precondición:
•	No hay.
Descripción:
1.	Alumno selecciona una solicitud.
2.	El sistema le informa las novedades registradas para su solicitud. Podría incluir: confirmación de recepción de su solicitud, resultado de la evaluación, pedido de entrega de comprobantes faltantes, etc.

CU A8: Alumno Imprime la solicitud. 
Precondición:
•	No tiene.
Descripción:
1.	El sistema visualiza todas las solicitudes que el alumno tiene.
2.	Alumno selecciona una solicitud.
3.	El sistema realiza la impresión de la solicitud. La impresión tendrá la leyenda al final dependiendo del estado de la solicitud. Como declaración jurada si la solicitud esta en estado confirmada, o indicando que no servirá para presentarla si esta en estado pendiente.

CU A9: Alumno ingresa al sistema
Precondición:
•	Que se haya creado nombre de usuario y palabra clave para ese alumno.
Descripción:
1.	El alumno ingresa nombre de usuario y la palabra clave.
2.	El sistema controla que exista el usuario y que la palabra clave sea la correcta.
3.	Ingresa al sistema.

Variante a 2: Nombre de usuario y/o contraseña incorrectas   
4.	El sistema informa que los datos ingresados son incorrectos
5.	El sistema vuelve a presentar la pantalla para ingreso al sistema

CU A10: Alumno recupera usuario y contraseña
Precondición:
•	Que el alumno haya creado nombre de usuario y contraseña.
Descripción:
1.	El alumno selecciona el botón ¿Olvidó usuario o contraseña?
2.	El sistema muestra nueva pantalla con los campos tipo y número de documento, para que sean completados.   
3.	El alumno ingresa los datos.
4.	El sistema controla que el alumno, por tipo y número de documento haya sido dado de alta.
5.	El sistema genera un mail dirigido el correo electrónico registrado como contacto de esa persona, con el nombre de usuario y la palabra clave.
6.	El sistema envía al mail registrado como contactos de esa persona.
7.	El sistema informa que se ha realizado con éxito el envío.

Variante al punto 4: El tipo y nro de documento no está registrado en el sistema.
4.	El sistema informa que el tipo y nro de documento no corresponden a una persona registrada.
5.	El sistema vuelve a presentar la pantalla para la recuperación del usuario y clave.

Variante al punto 5: No hay registrado un correo electrónico para esa persona.
5.	El sistema informa que no hay registrado un mail para esa persona.
6.	El sistema vuelve a presentar la pantalla para la recuperación del usuario y clave.

Variante al punto 6: Falla el envío del mail.
4.	El sistema informa que ha fallado el envío del mail y que no se pudo enviar.
5.	El sistema vuelve a presentar la pantalla para la recuperación del usuario y clave.

CU A11: Alumno modifica la contraseña.
Precondición:
•	Que el alumno haya creado nombre de usuario y contraseña.
Descripción:
1.	El alumno ingresa a la aplicación ingresando nombre de usuario y palabra clave.
2.	Selecciona la opción modificar palabra clave
3.	El sistema presenta un campo que permita el ingreso de la clave nueva y otro que permita el reingreso de la misma.
4.	El sistema controla que la palabra clave ingresada y la reingresada coincidan.
5.	El sistema guarda los cambios.
6.	El sistema genera un mail para la cuenta de correo registrada para esa persona.
7.	El sistema realiza el envío del mail.
8.	El sistema informa que se ha realizado la operación con éxito y que ha sido enviado un mail a la cuenta registrada.

Variante al punto 4: No coinciden las contraseñas.
4.	El sistema informa que no coincide la contraseña ingresada.
5.	El sistema vuelve a presentar la pantalla para con los campos de ingreso y re-ingreso en blanco.

Variante al punto 6: No hay registrado un correo electrónico para esa persona.
6.	El sistema informa que no hay registrado un mail para esa persona.
7.	El sistema informa que la contraseña se ha modificado con éxito.

Variante al punto 7: Falla el envío del mail.
7.	El sistema informa que ha fallado el envío del mail y que no se pudo enviar.
8.	El sistema informa que la contraseña se ha modificado con éxito.

CU A12: Un alumno genera una solicitud para una convocatoria activa. 
Actores: Alumno 
Precondición:  
•	.
Descripción:
1.	El sistema muestra todas las convocatorias activas.
2.	El Alumno selecciona la convocatoria para la que desea generar el formulario.
3.	El sistema controla que no exista una solicitud generada para esa persona en esa convocatoria.
4.	El sistema genera la solicitud.
5.	El sistema despliega el formulario recién creado.

Variante al punto 3: Existe una solicitud previa.
3.	El sistema informa que ya existe una solicitud previa para ese alumno.
4.	El sistema vuelve a mostrar el listado de convocatorias activas.

Operaciones para el administrador del sistema

CU I1: Administrar las tablas maestras de: Distancia a sede universitaria, Tipo de periodo lectivo, Parentescos, Tipos de documentos, tipos de becas (incluir un campo descriptivo además del nombre), Motivos de modificación de una solicitud cerrada.
Agregar tablas maestras de: motivos de cancelación/suspensión de una beca otorgada, persona que entrevista. 

CU I2: Personal interno selecciona una solicitud.
Descripción:
1.	Personal puede seleccionar: una convocatoria (de una lista desplegable con las convocatorias existentes), o bien ingresar un conjunto de caracteres para el nombre y/o apellido, o bien seleccionar tipo y número de documento, o bien seleccionar el estado de la solicitud.
2.	El sistema realiza la búsqueda tomando aquellos valores que el usuario ingresó. En todos aquellos campos donde no haya ingresado valor, el sistema no considerará esa opción para la búsqueda (tomando todos los valores para esos campos).
3.	El sistema presenta una lista con las solicitudes que cumplen con los criterios de búsqueda permitiendo seleccionar uno.

PLAN DE DESARROLLO

Esta propuesta pone foco en organizar iteraciones cortas (3 a 5 semanas) mediante un plan sencillo de acordar y monitorear. Una operación se debe entender como la unidad básica de programación que representa un conjunto de prestaciones funcionales integras y cohesivas (ejemplo: opción de menú).

Operación	Iteración Origen	Iteración Terminación	Estado	
Alumno completa el formulario de solicitud de Beca 	IT1	IT2	Testeado	
Alumno cierra la solicitud de beca.	IT1	IT3	Testeado	
Personal define una convocatoria de becas	IT2	IT3	Testeado	
Alumno consulta las convocatorias activas	IT2	IT2	Testeado	
Importar datos de guaraní.	IT2		Pendiente	
Personal consulta estadísticas de la convocatoria.	IT2	IT2	Testeado	
Personal consulta por convocatoria el detalle de alumnos por Unidad académicas	IT2	IT2	Testeado	
Alumno imprime la solicitud.	IT2	IT3	Testeado	
Personal modifica datos de una solicitud cerrada. 	IT3	IT3	Testeado	
Personal carga el resultado de la selección y evaluación de solicitudes.	IT3	IT3	Testeado	
Personal reabre una solicitud que estaba cerrada. 	IT3	IT3	Testeado	
Personal Importa datos de Unidades Académicas y Carreras del SIU-Guaraní a las tablas maestras	IT3	IT3	Testeado	
Personal Cancela una suscripción de solicitud de beca.	IT4	IT5	Testeado	
Personal Registra recepción de solicitudes + comprobantes.	IT4	IT5	Testeado	
Personal Define la agenda de entrevistas.	IT5 (IT4)	IT6	Testeado	
Personal Consulta Agenda de entrevistas.	IT5 (IT4)	IT6	Testeado	
Personal Consulta Agenda para una solicitud	IT5 (IT4)	IT6	Testeado	
Personal Cancela Agenda de un entrevistador	IT5 (IT4)		Testeado	
Alumno Consulta Agenda de entrevistas	IT5 (IT4)	IT6	Testeado	
Proceso de incorporación de Datos Censales a la solicitud de un alumno	IT5		Testeado	
Personal Modifica el estado una solicitud de beca otorgada.	IT6	IT7	Testeado	
Personal crea una solicitud de beca 	IT6		Testeado	

CU A10: Alumno recupera usuario y contraseña	IT7	IT7	Testeado	
CU P23: Personal recupera nombre de usuario y la palabra clave del alumno	IT7	IT7	Testeado	
CU A2: Un alumno crea usuario y palabra clave para cargar solicitudes (modificación)
	IT7	IT7	Testeado	

Para cumplimentar exitosamente lo pautado para una iteración, debería existir un documento/ mecanismo complementario que permita armar un cronograma mas detallado de trabajo.

REFERENCIA:

Iteraciones:
IT1: Inicio de programación hasta primer demo en comité de usuarios (10/04/2006 - 05/05/2006) 
IT2: termina el 16/06/2006.
IT3: termina el 23/06/2006
IT4: termina el 04/08/2006
IT5: desde el 07/08/2006 al 18/08/2006 (inclusive).
IT6: desde el 22/08/2006 al 28/08/2006 (inclusive).
IT7: desde el 02/10/2006 al 06/10/2006 (inclusive).

Iteraciones:
•	Origen: Iteración en la que se debe completar el desarrollo de la operación.
•	Terminación: Iteración en la que finalmente se completo el desarrollo. Debería coincidir con la iteración de origen siempre, cuando no pasa esto es que hubo un problema o atraso.

Estados:
•	Pendiente Programación.
•	Programado: Se completo al menos la primera versión de la operación.
•	Testeado: Paso satisfactoriamente todo el proceso de testing.