Informe de Anlisis de Requerimientos SCA (Sistema de Control de Asistencia) 1. Captura de Requerimientos a.

. Implementacin de Reportes Se requiere implementar 3 reportes al Sistema de Control de Asistencia para lograr un mejor manejo y control ms eficiente y preciso de las asistencias del personal de Qnet. Concretamente, los objetivos de implementacin son: Reporte comparativo e historial de rendimiento. Reporte de porcentaje de efectividad por usuario. Reporte General (Informe de asistencia e indicadores) por oficina.

El alcance inicial era justamente trabajar sobre estos 3 reportes; sin embargo, con la implementacin de estos reportes, tambin se requiere lo siguiente: 1. Corregir la funcionalidad de ms del 50% (de los 16 reportes, 9 no funcionan). 2. Los reportes en funcionamiento, presentan deficiencias en cuanto a: 2.1 Tiempo de respuesta. 2.2 Presentar todo lo que se requiere, ya que el usuario del sistema se atribuye la tarea de generar reportes alternos en EXCEL para obtener lo que realmente desea. 2.3 Presentacin de los datos, ya que el sistema actualmente maneja variables de condicin en duro dentro de su misma fuente y esto genera incertidumbre en la veracidad de dichos datos. 2.4 La correcta generacin del mismo reporte, ya que existe personal que en determinada fecha goza de vacaciones, licencia, descanso mdico, etc. Por ello, en tales fechas este personal no debe ser considerado dentro de los reportes de asistencia. 2.5 Manejar las opciones automticas de marcado, ya que todo el personal cuenta con datos de horario de trabajo, de que ahora hasta que hora debe trabajar diariamente (por ejemplo de 8:00 am a 6:30 pm), y en el caso de que alguno del personal no marque su hora de ingreso, el sistema asume la hora de marcado como la hora normal de trabajo obtenido de ese registro (siguiendo el mismo ejemplo, el sistema asume y marcara la hora de ingreso de dicha persona como si hubiese marcado a las 8:00 am). 3. Con los problemas mencionados en el punto anterior, se requiere tener opciones configurables para que el reporte los use como filtros y/o condiciones que afecten el resultado final de los datos. Estos son los siguientes: 3.1 Aadir parmetros de configuracin para penalidades, ya que dado el ejemplo en el punto 2.5, se necesitan establecer una polticas de penalidad, por ejemplo si el usuario no marca su hora de ingreso el sistema debe asumir el marcado como si lo hubiese hecho 2 horas despus, 1 hora despus, etc., de su hora de ingreso. Tal nmero de horas debe estar ligada a configuraciones estipuladas por el usuario.

3.2 Opciones de validacin para personal saliente a vacaciones, descanso mdico, licencias, etc. Como complemento del punto 2.4. 3.3 Actualmente, el personal cuenta con reuniones en horas de la maana en qnet, y en algunas ocasiones reuniones extraordinarias con el cliente, lo cual dificulta marcar su hora de ingreso, y a cuenta del usuario del sistema queda validar todos los mensajes de aviso que se registran en el sistema por parte del personal para justificar ello y se plantea que tal trabajo lo puede hacer cada responsable del proyecto. Para realizar esto se necesita incluir dentro de la base de datos (de la cual se hablara en LA SITUACION ACTUAL DE LAS PLATAFORMAS) actual una tabla de perfiles que diferencie el rol de cada responsable de proyecto. En resumen, para el modulo de reportes se requiere lo siguiente: 1. Reporte Diario: General por da, informe de horario de entrada y salida, minutos de adeudo, minutos a favor y % de trabajo por persona. Por oficina. % de efectividades (9.5 horas diarias como 100%) de Asistencias por persona oficinas.

2. Reporte Semanal: General por semana, informe de horario de entrada y salida, minutos de adeudo, minutos a favor y % de trabajo por persona. Solo por oficina. Por Ranking: - Top (n) Puntuales - Top (n) impuntuales. - Top (n) con mayores horas de trabajo. - Top (n) con menores horas de trabajo. Quienes no estn cumpliendo sus 48 horas semanales. % de efectividades (9 horas diarias como 100%) de Asistencias por oficinas. Comparativo de rendimientos semanales (globales a 1 mes) a partir de la segunda semana. - Por persona. - Por Oficina.

3. Reporte Mensual: General por mes, informe de horario de entrada y salida, minutos de adeudo y minutos a favor. Por Ranking: - Top (n) Puntuales - Top (n) impuntuales. - Top (n) con mayores horas de trabajo. - Top (n) con menores horas de trabajo.

 Quienes no estn cumpliendo sus horas mensuales % de efectividades (9.5 x das del mes excepto sab. y dom. | 8 x das del mes excepto domingo) de Asistencias por oficinas. Comparativo de rendimientos mensuales a partir de febrero

4. Reporte Globalizado de persona por da, semana y mes: Record General de asistencia por el mes. En total 6 reportes (evidenciarlo en los reportes por semana), ya que los dems variaran solo en el lapso de tiempo (diario, semanal y mensual) pero seran los mismos y se est incluyendo un reporte globalizado que sera la combinacin de 5 reportes (excepto el reporte por ranking) para el historial de 1 persona a nivel mensual. b. Corregir el modulo mantenimiento de usuarios. El modulo actual, presenta deficiencias en cuanto a la buena distribucin de los datos del personal, por ejemplo para realizar reporte por reas y ms adelante pensando en la escalabilidad, reportes en cuanto a departamentos, existen usuarios que pertenecen a 2 departamentos (sea un ejemplo, usuarios que pertenecen tanto a SWQF y a Proyectos), el reporte no podra ser manejado ya que las horas distribuidas para ambos departamentos no sera el correcto (para ningn rea aplicara horas al 100%). Adems de esto se requiere una interfaz ms intuitiva y como parte de la solucin 3.3 de la implementacin de reportes, se necesita incluir el mantenimiento de perfiles y permisos. 2. SITUACION ACTUAL DE LAS PLATAFORMAS a. Base de datos Actualmente la base de datos no se le puede considerar como grande, ya que de las 16 tablas que usa el sistema, para el tema de reportes y mantenimiento de usuarios solo se usaran 8 tablas. Hay que implementar la utilizacin de ndices en todas las tablas para que las bsquedas seas ms rpidas, ya que actualmente no se est trabajando con esta opcin. Se debe depurar algunos datos de las tablas que no estn siendo utilizados para aprovecharlos como campos de configuracin y as reutilizar opciones de estas mismas tablas. Se deben incluir nuevas tablas para obtener una mejor distribucin de los datos, y tambin para el cumplimiento de los requerimientos citados. La distribucin actual a nivel de entidades se ve de la siguiente manera, con las mejoras incluidas se debern crear nuevas clases y nuevos atributos a las clases ya involucradas.

Adems de esto se deben normalizar algunas tablas para la optimizacin de bsquedas. b. Sobre el SCA Las fuentes del aplicativo, dan razn de que la programacin realizada no lleva consigo los ltimos estndares de distribucin (Capas, MVC, etc.). No se depende de un controlador, sino de varios. Es posible independizar el front-end del back-end; sin embargo, esto sera no depender de todo cdigo del sistema (no se podra reutilizar mtodos ya establecidos), lo cual afectara la performance del mismo al tener diferentes puntos de proceso, de recoleccin y salida de datos. El programador tendra que conocer de programacin en frameworks de php, lo que a su vez seria desventajoso tanto para el mismo (ya que llevara tiempo comprender todos los objetos a utilizar dentro del cdigo) como para el producto final ya que la escalabilidad del sistema recaera en el mismo programador y en la suciedad de cdigo que entorpecera la agilidad del sistema.

3. RECOMENDACIONES FINALES La base de datos, es manejable y escalable a los requerimientos expuestos, la normalizacin de esta recaera solo en 2 tablas no en toda la base de datos. El Sistema, como se ha expuesto, lleva consigo mucho dificultad adecuarlo a los nuevos requerimientos, ms aun siguiendo la forma antigua en que est programado este sistema, lo cual entorpece muchos procesos y hace ms lento los reportes.

Finalmente, como casi el 100% de los reportes necesitan ser corregidos, y distribuir y agilizar mejor el mantenimiento de clientes, se recomienda realizar un nuevo MODULO DE REPORTES que incluya el mantenimiento del personal y se debe continuar con el uso del SISTEMA DE CONTROL DE ASISTENCIA solo para que el personal marque sus horas, cubriendo e integrando las nuevas funcionalidad que este traer, ya que el tiempo que tome entender toda la distribucin; y peor aun, siguiendo la misma forma para futuras mejoras, se podra emplear para disear un sistema ms robusto, rpido, mejor distribuido, escalable y amigable. De aceptarse la recomendacin, el tiempo estipulado en das en tener el producto sera el siguiente: Actividades a realizar y Documentos a entregar Documento de aprobacin de usuario Anlisis Diagrama de Casos de Uso del Sistema Diagrama de Clases de la Solucin Lista detallada de Funcionalidades del Sistema Lista detallada de Mdulos del Sistema Lista detallada de Opciones del Sistema Prototipos grficos Diseo Lista de Interfaces y especificacin Diagrama de Componentes de la Solucin Modelo Fsico de la BD Modelo Lgico de la BD Estndar de Programacin y Arquitectura del sistema Construccin de Plataforma y distribucin Construccin Estandarizacin de browsers Construccin de Modulo de Reportes Construccin de Modulo de Mantenimiento de Usuarios Pruebas Despliegue No son considerados dentro del tiempo de elaboracin del sistema. Manual del Usuario Capacitacin Tcnica y Funcional Total de das Fase Das

1 1 1 1 6 3 0 1 16

La Fase de pruebas no se est considerando puesto que es incierto el tiempo que tomara, por ello solo se est haciendo mencin al tiempo en que tome elaborar el producto.