“sistema de información para la gestión administrativa
TRANSCRIPT
, Junio 2018
“Sistema de Información para la Gestión Administrativa
Universitaria de la UCLV”
Yoelvys Pérez Cabrera y Ailín García García
Y
Lic. Iasmany Ortega Sanabria
Dr. C. Isel Moreno Montes de Oca
i
Este documento es Propiedad Patrimonial de la Universidad Central “Marta Abreu” de Las Villas,
y se encuentra depositado en los fondos de la Biblioteca Universitaria “Chiqui Gómez Lubian”
subordinada a la Dirección de Información Científico Técnica de la mencionada casa de altos
estudios.
Se autoriza su utilización bajo la licencia siguiente:
Atribución- No Comercial- Compartir Igual
Para cualquier información contacte con:
Dirección de Información Científico Técnica. Universidad Central “Marta Abreu” de Las Villas.
Carretera a Camajuaní. Km 5½. Santa Clara. Villa Clara. Cuba. CP. 54 830
Teléfonos.: +53 01 42281503-1419
SIGAU. Dedicatoria
ii
Dedicatoria
A mis padres, por su incondicional apoyo y por su constante preocupación por mí.
A mi hermano, por creer siempre que sí podía.
A toda mi familia por su apoyo y en especial a mi abuelito Polo que no pudo ver este resultado pero
que sé que si estuviera aquí se sentiría muy orgulloso de mí.
Ailín
Este trabajo está dedicado a mi familia en especial a mis padres, a mi hermano y a mi novia por
haberme brindado su apoyo incondicional.
Yoelvys
SIGAU. Agradecimientos
iii
Agradecimiento
A toda mi familia, en especial a mis padres, mi hermano y mis primas que tanto me han apoyado.
A mis tutores en especial a Iasmany por su dedicación e interés en el trabajo.
A todos mis amigos que me ayudaron a lo largo de toda la carrera para poder llegar hasta aquí, en
especial a Elianis, Anneilis, Virgen, Yanet, Islen, Liliette y a mi compañero de tesis Yoelvys.
Al Dr. Daniel Gálvez Lio por su ayuda brindada.
Ailín
A mis padres Maristel y Faustino por su confianza y dedicación.
A mi hermano Yoandry y a mi novia Keila por estar a mi lado cuando más lo necesité.
A mi familia y mis vecinos por apoyarme tanto.
A mis compañeros de aula en especial a Emilio, Yordan, Leo, Jose Angel y a mi compañera de tesis
Ailín.
A Dr. Daniel Gálvez Lio por ser el profesor que me guió a lo largo de la carrera.
A mis tutores en especial a Lic. Iasmany Ortega Sanabria por su dedicación, apoyo, paciencia e
infinitas horas dedicadas.
Yoelvys
SIGAU. Resumen
iv
Resumen
La administración actualmente juega un papel fundamental en el uso de los fondos públicos. Los
sistemas implementados desde el Ministerio de Educación Superior a las universidades del país son
a través del ASSET, software que requiere el pago de una licencia para cada estación de trabajo y
al cual las diferentes áreas administrativas en facultades y direcciones no tienen acceso como
entidades básicas. Este trabajo es el resultado de la implementación del Sistema de Información
para la Gestión Administrativa Universitaria (SIGAU) para la UCLV, un sistema alternativo que se
encarga de la recolección, acumulación, procesamiento y diseminación de toda la información para
la gestión. Computacionalmente, utiliza el framework Symfony3 como entorno de desarrollo y un
servidor MySQL como gestor de bases de datos, de modo que todo el tráfico de información se
realiza a través de una interfaz web. Esta herramienta le permite gestionar reportes de pago de
profesor a tiempo completo (PTC) como de profesor a tiempo parcial (PTP) y mediante el uso de un
sistema de notificación por correo, le permitirá enviar información relacionada con el pago de
salarios. Además, permite la gestión de activo fijo tangible a través de actas de responsabilidad
material por local, tanto individual como colectivo y gestionar desde cada una de las áreas los
servicios básicos como transporte, alimentación, alojamiento y mantenimiento.
SIGAU. Resumen
v
Abstract
The administration currently plays a fundamental role in the use of public funds. The systems
implemented from the Ministry of Higher Education to the universities of the country are through the
ASSET, software that requires the payment of a license for each work station and to which the
different administrative areas in faculties and addresses do not have access as basic entities. This
work is the result of the implementation of the Information System for University Administrative
Management (SIGAU) for the UCLV, an alternative system that is responsible for the collection,
accumulation, processing and dissemination of all information for management. Computationally, it
uses the Symfony3 framework as a development environment and a MySQL server as a database
manager, so that all information traffic is done through a web interface. This tool permit to manage
reports the full and part-time of teachers pay by using the mail system, it permit to notify information
related to the payment of salaries, allows the management of tangible fixed assets through acts of
material responsibility by local, both individual and collective and manage from each of the areas
basic services such as transportation, food, accommodation and maintenance.
SIGAU. Tabla de Contenidos
vi
Tabla de Contenidos
Introducción ..................................................................................................................................... 1
Capítulo I. Fundamentación teórica ................................................................................................. 4
1.1. Objetivos estratégicos de la organización. ........................................................................ 4
1.2. Objeto de estudio .............................................................................................................. 5
1.2.1. Flujo Actual de Procesos ............................................................................................ 5
1.2.2. Análisis crítico de la ejecución de los procesos .......................................................... 7
1.2.3. Procesos objeto de automatización ............................................................................ 7
1.3. Sistemas automatizados existentes vinculados al campo de acción ................................. 8
1.4. Tendencias y Tecnologías Actuales .................................................................................. 9
1.4.1. Fundamentación de la Metodología utilizada. ............................................................ 9
1.4.2. Fundamentación del Entorno de Desarrollo, Lenguaje, Gestor de Base de Datos y
Tecnología utilizados. ............................................................................................................. 10
1.4. Conclusiones Parciales del Capítulo ............................................................................... 16
Capítulo II. Modelo del Negocio y Requisitos ................................................................................ 18
2.1. Modelo del negocio actual ............................................................................................... 18
2.2. Reglas del negocio a considerar ..................................................................................... 19
2.3. Actores del negocio ......................................................................................................... 20
2.4. Diagrama de casos de uso del negocio ........................................................................... 20
2.5. Trabajadores del negocio ................................................................................................ 23
2.6. Casos de uso del negocio ............................................................................................... 23
2.7. Actores del sistema a automatizar ................................................................................... 25
2.8. Definición de los requisitos funcionales ........................................................................... 27
2.9. Diagrama de Casos de Uso del Sistema ......................................................................... 34
2.10. Descripción de los casos de uso del Sistema (Significativos) ...................................... 39
2.11. Estimación de tiempo y costo ...................................................................................... 48
SIGAU. Tabla de Contenidos
vii
Capítulo III. Descripción de la propuesta de solución .................................................................... 57
1.1. Arquitectura del Sistema ................................................................................................. 57
1.2. Diagrama de clases de diseño (CU Significativos) .......................................................... 58
1.3. Diagrama de secuencia (CU Significativos) ..................................................................... 60
1.4. Tratamiento de errores .................................................................................................... 62
1.5. Diseño de la base de datos ............................................................................................. 63
1.5.1. Modelo conceptual de datos ..................................................................................... 63
1.5.2. Modelo físico de datos ............................................................................................. 66
1.6. Modelo de componentes ................................................................................................. 67
1.7. Diagrama de despliegue ................................................................................................. 69
1.8. Conclusiones parciales del capítulo. ............................................................................... 70
Capítulo IV. Pruebas y análisis de factibilidad ............................................................................... 71
2.12. Casos de Pruebas (caja negra) ................................................................................... 71
2.13. Plan de pruebas de rendimiento .................................................................................. 74
2.14. Conclusiones parciales del capítulo. ............................................................................ 77
Conclusiones ................................................................................................................................. 78
Recomendaciones ......................................................................................................................... 79
Referencias Bibliográficas ............................................................................................................. 80
Anexos .......................................................................................................................................... 84
Manual de Usuario ..................................................................................................................... 84
SIGAU. Lista de Ilustraciones
viii
Lista de Figuras
Figura 1: Representación visual de las nuevas etiquetas de HTML5. 11
Figura 2: Estructura de los archivos de bootstrap 13
Figura 3 Diagrama de Casos de Uso del Negocio 22
Figura 4 Diagrama de Casos de Uso para el Actor Trabajador 35
Figura 5 Diagrama de Casos de Uso para el Actor Jefe de Departamento. 36
Figura 6 Diagrama de Casos de Uso para el Actor Jefe de Departamento Administrativo 37
Figura 7 Diagrama de Casos de Uso para el Actor Administrador 38
Figura 8 Diagrama de Casos de Uso para los Actores Director de Alimentación y Director de
Transporte 38
Figura 9 Diagrama de Casos de Uso para los Actores Decano, Jefe del Grupo de Finanza, Técnico
de Recursos Humanos, Especialista de Nomina y Director de Planificación y Estadística 39
Figura 10: El patrón Modelo Vista Controlador. 57
Figura 11 Diagrama de clases de Gestionar Ausencias. 58
Figura 12 Diagrama de clases de Cargar Trabajador 59
Figura 13 Diagrama de clases de Gestionar Presupuesto CUC 60
Figura 14: Diagrama de Secuencia para el Caso de Uso Gestionar Ausencias (Adicionar). 61
Figura 15: Diagrama de Secuencia para el Caso de Uso Cargar Trabajador. 61
Figura 16: Diagrama de Secuencia para el Caso de Uso Gestionar Presupuesto CUC (Adicionar).
62
Figura 17: Vista de la Aplicación, sección de gestionar sábados laborables. 63
Figura 18: Segmento del modelo conceptual de la base de datos para CU Gestionar Presupuesto
CUC. 64
Figura 19: Segmento del modelo conceptual de la base de datos para CU Cargar Trabajador. 65
Figura 20: Segmento del modelo conceptual de la base de datos para CU Gestionar Ausencias.
65
Figura 21: Modelo físico de la base de datos 66
Figura 22: Diagrama de componentes para CU Gestionar Ausencias. 67
Figura 23: Diagrama de componentes para CU Cargar Trabajador. 68
Figura 24: Diagrama de componente para CU Gestionar Presupuesto CUC. 69
Figura 25: Diagrama de Despliegue 70
Figura 26: Interfaz gráfica para introducir los datos. 72
Figura 27: Resultado de una prueba de carga. 75
SIGAU. Lista de Ilustraciones
ix
Figura 28: Resultado de una prueba de stress. 76
Figura 29: Valores correspondiente a la prueba de resistencia. 77
Figura 30: Página de inicio de sección 86
Figura 31: Pagina de portada para un Jefe de Departamento Administrativo. 87
Figura 32: Pagina de portada para un Jefe de Departamento Docente. 88
Figura 33: Pagina de portada para un Trabajador. 89
Figura 34: Pagina de portada para un Director o Decano. 90
Figura 35: Presupuesto en CUP del centro. 91
Figura 36: Submenú para ver los presupuestos anteriores. 91
Figura 37: Presupuesto en CUC del centro. 92
Figura 38: Formulario para adicionar un gasto al presupuesto CUC. 93
Figura 39: Eliminar un gasto del presupuesto en CUC. 93
Figura 40: Solicitar dieta por anticipo. 94
Figura 41: Desglose de la dieta por anticipo. 94
Figura 42: Solicitar dieta por liquidación. 95
Figura 43: Información de la nómina de pago de cada trabajador. 96
Figura 44: Insertar una ausencia por parte del director o decano. 96
Figura 45: Perfil del trabajador. 97
Figura 46: Gestionar todas las facultades. 98
Figura 47: Adicionar una facultad. 98
Figura 48: Fecha de reporte de incidencia para la confección del reporte RH3 (I10). 99
Figura 49: Gestionar los sábados laborables del año. 100
Figura 50: Nuevo vale de pago a estudiantes. 100
Figura 51: Nuevo vale de pago a trabajadores. 101
Figura 52: Listado de los vales de pagos menores. 102
Figura 53: Modelo de vale de pago menor. 103
Figura 54: Reporte de conciliación de dietas. 103
Figura 55: Reporte de conciliación de trabajadores. 104
Figura 56: Reporte de conciliación de estudiantes. 104
SIGAU. Lista de Tablas
x
Lista de Tablas
Tabla 1: Actores de Negocio 20
Tabla 2: Trabajador del negocio. 23
Tabla 3: Descripción de los casos de uso del negocio 23
Tabla 4: Actores del sistema a automatizar 25
Tabla 5: Descripción del Caso de Uso Gestionar Ausencias. 40
Tabla 6. Descripción del Caso de Uso Cargar Trabajadores 43
Tabla 7: Descripción del Caso de Uso Gestionar Presupuesto CUC 46
Tabla 8: Factor de Peso de los Actores sin ajustar 49
Tabla 9: Factor de Peso de los CU sin ajustar. 50
Tabla 10: Factores de Complejidad Técnica. 51
Tabla 11: Valores asignados a los factores de complejidad técnica. 51
Tabla 12: Factores de Ambiente o Entorno. 53
Tabla 13: Valores asignados a los factores de ambiente. 53
Tabla 14: Distribución del Esfuerzo. 55
Tabla 15: Esfuerzo necesario. 55
Tabla 16: Condiciones de entrada 72
Tabla 17: Casos de prueba para el CU Adicionar Gasto 73
Tabla 18: Descripciones de roles en las facultades. 84
Tabla 19: Descripciones de roles en las direcciones 86
SIGAU. Introducción
1
Introducción
De generación en generación el hombre ha transmitido la necesidad de expresarse, comunicarse y
conocer todo lo que lo rodea cada vez de formas más novedosas. El desarrollo de las tecnologías
de la información y las comunicaciones (TIC), ha contribuido de forma única a la solución de muchos
problemas en diferentes ámbitos y disciplinas, constituyendo hoy en día una fuente de recursos
imprescindibles.
La incorporación de las TIC en el ámbito empresarial resulta un elemento clave para mejorar la
competitividad, impulsar el crecimiento económico y lograr una mayor creación de empleo. El
desarrollo de las TIC ha llegado a la administración, labor que hace referencia al funcionamiento, la
estructura y el rendimiento de las organizaciones (Hernández Castro, 2017).
En el mundo han surgido numerosos softwares especializados en la tarea de la administración de
empresas, ya que esta es una labor difícil y engorrosa de llevar. Entre ellos se encuentra el SAIT
(SAIT, n.d.) sistema administrativo integral descentralizado, Aspel-PROD 3.0 (Aspel-PROD, n.d.)
que controla y administra los procesos de fabricación, desde materias primas hasta productos
terminados. Además existen otros como GestiónPYME (GestiónPYME, n.d.), Kubbos (Kubbos, n.d.),
SAP (SAP, n.d.) y Microsoft Dynamics (Microsoft Dynamics, n.d.).
La Universidad Central “Marta Abreu” de Las Villas como parte del proceso de mejora continua,
comienza a introducir e implementar desde hace varios años, herramientas tecnológicamente más
potentes para el procesamiento de la información proveniente de las diferentes áreas, lo cual
favorecerá la toma decisiones por parte de los directivos, encontrándose en el ámbito universitario
herramientas como el SIGENU y el Sistema de Gestión de Postgrado utilizados para los registros
académicos tanto del pregrado como del postgrado, la herramienta utilizada por la Dirección de
Documentación e Información Científico Tecnológica (DDICT), utilizada para generar el i-10 y el
control de Activo Fijo Tangible (AFT), el ASSET, que segmentado modularmente posee
funcionalidades para la gestión de los recursos humanos, económicos y financieros; con respecto a
este último debemos mencionar que es software propietario y al que las diferentes áreas
administrativas universitarias como fuentes primarias de información no tienen acceso (Assets S.A,
n.d.), entre otros.
En el curso 2016-2017 se desarrolló la herramienta Sistema de Información para la Administración
de Facultades (SIAF). Esta herramienta propicia información a todos los trabajadores sobre la
ejecución del presupuesto en CUP así como visualizar la responsabilidad material por local de todo
SIGAU. Introducción
2
el control de Activo Fijo Tangible (AFT), permite a los trabajadores solicitar dietas por anticipo y
liquidación, además de la confección de reportes de incidencia por parte de los jefes de
departamento docente, la confección del modelo RH3 (i10) y la carta de complemento por el jefe de
departamento administrativo al final del mes. SIAF aunque efectivo para el campo de acción para el
que se desarrolló (las facultades), es insuficiente para una generalización hacia la universidad. La
incorporación al modelo de las direcciones y centros adscriptos como Centros de Estudio e
Investigación hace necesario la creación de una nueva versión. Por lo que se decide implementar el
software SIGAU, que ofrece nuevas posibilidades que harán más óptimo y organizado el trabajo
administrativo en múltiples instancias de la dirección Universitaria.
Problema Investigación
La situación problémica descrita anteriormente, conduce al siguiente PROBLEMA DE
INVESTIGACIÓN: ¿Cómo implementar una nueva versión del sistema informático para la gestión
administrativa de las facultades y direcciones en la UCLV que incluya los módulos de Recursos
Humanos y Economía?
Objetivo general
Implementar una nueva versión de SIAF que incluya los módulos de Recursos Humanos y
Economía para la gestión de los procesos administrativos en la Universidad Central “Marta
Abreu” de Las Villas.
Objetivos específicos
1. Diseñar la base de datos del sistema que incluya la información de los procesos Recursos
Humanos y Economía para su gestión.
2. Implementar una interfaz web para el acceso y manejo de la información contenida en la
base de datos.
3. Realizar pruebas de caja negra y de rendimiento al software.
SIGAU. Introducción
3
Estructura del documento
Este documento está estructurado en 4 capítulos, además de las conclusiones,
recomendaciones, referencias bibliográficas, anexos e ilustraciones.
Capítulo 1. Fundamentación teórica: Se abordan los aspectos teóricos que se deben conocer
para la presente investigación, se analiza el objeto de estudio, sistemas informáticos existentes
vinculados al campo de acción, las tendencias y tecnologías actuales.
Capítulo 2. Modelo de Negocio y Requisitos: En este capítulo se describe el modelo del negocio
partiendo de los procesos más importantes. Se identifican actores, trabajadores, reglas y caso
de uso del negocio, actores y casos de uso del sistema a automatizar, las definiciones de los
requisitos funcionales y no funcionales, la descripción de los casos de uso más significativos.
Por último se realiza la estimación de tiempo y costo del proyecto.
Capítulo 3. Descripción de la propuesta de solución: En este capítulo se expone la propuesta de
solución de la arquitectura del sistema, así como los diagramas de clases del diseño y de
secuencia de los casos de uso significativo, el diseño de la base de datos, tratamiento de errores,
modelo de componente y diagrama de despliegue.
Capítulo 4. Prueba y análisis de factibilidad: En este capítulo se le aplican pruebas al software
como son, pruebas de caja negra y pruebas de rendimiento.
SIGAU. Capítulo I
4
Capítulo I. Fundamentación teórica
En el presente capítulo se abordan aspectos teóricos que se deben conocer para la presente
investigación. Se analizan los objetos de estudios, sistemas automatizados existentes vinculados al
campo de acción y se describen las metodologías, herramientas, tecnologías y lenguajes que serán
utilizadas para el desarrollo de la propuesta de solución.
1.1. Objetivos estratégicos de la organización.
La Universidad Central “Marta Abreu” de Las Villas según (Anon., 2018), cuenta con una matrícula
de 9022 estudiantes y 3520 profesores, ubicados en 12 facultades, en las que se estudian 52
carreras que abarcan las ciencias humanísticas, las técnicas y las naturales. Además, ofrece 29
programas doctorales, 44 programas académicos de Maestría y 4 especialidades. Su objetivo es
formar profesionales competentes en las ciencias técnicas, agropecuarias, pedagógicas,
económicas, sociales, humanísticas, exactas y de la cultura física, mediante la educación de
pregrado, la superación continua y el postgrado, basada en el desarrollo de las ciencias, la
tecnología y la innovación, con calidad, integralidad y patriotismo, en función de satisfacer la
demanda de la región central y el país en general, para lo cual dispone de instalaciones adecuadas
y un capital humano de elevado nivel científico, humanista y con tradición de excelencia en su
trabajo.
Los Departamentos Administrativos atienden toda la actividad de gestión administrativa de una
facultad, es el responsable directo de la gestión económica financiera y de los servicios. Entre sus
funciones incluye la elaboración y tramitación de los reportes de pago (reporte de ausencias e
incidencias) y vinculación de los trabajadores. El control del uso y destino de los recursos y la gestión
de la base de datos del 100% de los activos fijos tangibles y útiles y herramientas, teniendo
actualizados todos los movimientos por altas, bajas y traslados son funciones llevadas por el
departamento administrativo, así como la planificación y ejecución del chequeo del 10% de los
activos fijos tangibles y útiles y herramientas, actualización de las actas de responsabilidad material
individual y colectivas conformando la apertura de expediente de pérdidas, faltantes y sobrantes de
AFT (Activo Fijo Tangible), presentando la documentación establecida para esto. Además el control
y cumplimiento del régimen de horario de trabajo del personal del área y la disciplina laboral en esta.
El control de los certificados médicos, licencias, vacaciones de los trabajadores del área y gestionar
necesidades de ayuda económica a estudiantes. La tramitación de dietas y pagos menores de los
trabajadores, realizando, de ser posible, su pago al trabajador en el área. La coordinación de la
SIGAU. Capítulo I
5
elaboración del plan y presupuesto anual, garantizar la logística de los procesos de evaluación
externa de carrera, maestría, doctorados y la ejecución del pago de estipendio y práctica laboral de
estudiantes y de salario y vacaciones de trabajadores, de ser posible en conjunto con el control de
la ejecución de las cifras presupuestarias asignadas a la facultad, así como de los fondos en CUC
captados y recibidos (asignaciones, donaciones, etc.). La realización de conciliaciones con la
Dirección General de Economía sobre gastos por partidas y disponibilidad, pagos, expedientes en
proceso, pagos menores, ejecución del presupuesto, estado de solicitud de materiales, compras y
extracción de almacenes y medios materiales. Y por último la gestión de las necesidades del área,
realizando las solicitudes a la dirección de logística.
1.2. Objeto de estudio
1.2.1. Flujo Actual de Procesos
Reporte de pago a PTC y PTP
Los procesos de reportes de pagos a PTC y PTP inician mensualmente con la fijación
por plan de trabajo universitario de las fechas para la entrega de los mismos, por parte
de los jefes de departamentos docentes. Estos reportes deben contener un listado con
las ausencias y claves por cada trabajador, así como el tiempo trabajado por horas para
los PTP. Los jefes de departamento confeccionan este reporte y lo entregan. El personal
del departamento administrativo es el encargado de la creación del reporte RH-3 (i-10)
a partir de lo recibido. Confeccionado el i-10 es revisado y aprobado por los directivos
de la facultad y enviado según planificación. El último día del mes se entrega un
complemento de este reporte con los días no contemplados en el i-10, es decir, los días
posteriores a la entrega del mismo. Tanto el reporte de RH-3 (i-10) como el complemento
que se elabora el último día del mes, conforman el reporte de pago de los trabajadores
los cuales no conocen hasta que cobran el salario si le hicieron algún descuento.
Análisis del presupuesto en Peso Cubano (CUP)
El análisis del presupuesto en moneda nacional es una tarea que se lleva de forma
manual en Excel por el departamento administrativo. Una vez por año confirmada la cifra
del presupuesto por el Director de Planificación es desglosado por las partidas que van
hacer controladas por la facultad, direcciones y proyectos que son:
1. Materias Primas y Materiales
2. Combustibles y Lubricantes
SIGAU. Capítulo I
6
3. Energía
4. Gastos de Personal
5. Otros Gastos de la Fuerzas de Trabajo
6. Depreciación y Amortización
7. Otros Gastos
Análisis de presupuesto en Peso Cubano Convertible (CUC)
En cuanto a la administración del fondo en divisas se hace desde el Grupo de Finanzas
en la Dirección General de Economía, grupo que cuenta para esta tarea con otra
herramienta Microsoft Money.
Dietas y Vales de Pagos Menores a trabajadores y estudiantes
El procedimiento estándar para la confección de dietas empleado en prácticamente todo
el campus universitario consta de varios pasos. Inicialmente el trabajador solicita a su
jefe inmediato dado una causa de viaje, un servicio de dieta. Mediante la emisión de una
carta este autoriza un desglose y con esta se confecciona finalmente el modelo oficial
de Anticipo de Pago, modelo que requiere la firma tanto del trabajador como del directivo
del área, una vez cobrada y realizado el viaje, el trabajador tiene tres días a partir de su
regreso, para pasar por el área administrativa y firmar una vez más el documento de
dieta esta vez en liquidación. El vale de pago menor siempre que el trabajador se
acerque al área administrativa con el comprobante de un servicio recibido en función de
su trabajo y además está de acuerdo a las normas establecidas, será reintegrado en su
totalidad con la debida autorización de la dirección de área.
A los estudiantes por ley se les paga mensualmente medio pasaje de ida y regreso a la
provincia o municipio de acurdo a la dirección de procedencia.
Todos los documentos referentes tanto a dietas como a vales de pagos menores se
almacenan en archivos físicos.
Gestión del AFT y comprobación de 10% mensual
Todo la documentación y actualización sobre AFT excepto en la Dirección de
Documentación e Información Científico Tecnológica y el Edificio Rectorado, se hace
utilizando métodos relativamente arcaicos con Word y Excel.
Servicios básicos
SIGAU. Capítulo I
7
La universidad posee como parte de su funcionamiento un grupo de direcciones las
cuales se encargan de su vitalidad. Entre ellas encontramos la dirección de transporte,
de alimentación, residencia de postgrado y mantenimiento. Estas direcciones a pesar de
poseer diferentes modelados tienen como base el mismo sistema de procedimiento, las
diferentes áreas solicitan sus servicios y de acuerdo a las prioridades establecidas por
la dirección universitaria son satisfechas en diversos plazos de tiempo.
1.2.2. Análisis crítico de la ejecución de los procesos
Partiendo del análisis del flujo actual de los procesos, son detectados los siguientes
problemas:
1. La realización de estas tares como Reporte de pago a PTC y PTP, Análisis de
presupuesto (CUP), Análisis de presupuesto (CUC), la gestión de Dietas y Vales de
Pagos Menores a trabajadores y estudiantes, Gestión del AFT y comprobación de
10% mensual y algunos de los Servicios básicos, se realizan con Word y Excel
herramientas que no ofrecen agilidad, lo cual lo hace un proceso poco práctico y
exhaustivo.
2. La incorrecta escritura de algunos campos en los reportes elaborados.
3. No tener los datos en un sistema para posterior análisis y la consecuente toma de
decisiones.
Debido a las deficiencias, agilidad, seguridad y control de las tareas es que se toma la
decisión de elaborar un software para la gestión administrativa en la Universidad Central
“Marta Abreu” de Las Villas.
1.2.3. Procesos objeto de automatización
Teniendo en cuenta el trabajo realizado por el jefe de departamento administrativo de cada
facultad de la Universidad “Marta Abreu” de Las Villas se decide automatizar los siguientes
procesos:
1. Gestionar el control del presupuesto y sus partidas correspondientes.
2. Gestionar el control del presupuesto en divisa y sus gastos.
3. Llevar todo el control del salario de cada trabajador en los últimos 5 años.
4. Solicitar, registrar y liquidar tanto dietas como de vales de pagos menores a
trabajadores y estudiantes.
SIGAU. Capítulo I
8
5. Controlar los Activos Fijos y registrar el 10 y 100 porciento de cada mes.
6. Elaborar reportes de conciliación.
7. Crear reportes de pago y reportes PTP.
8. Solicitar servicios de: Alimentación, Transporte, Alojamiento y Mantenimiento.
1.3. Sistemas automatizados existentes vinculados al campo de acción
Algunos de los softwares vinculados a la tarea de la administración de empresas son los
siguientes:
1. ASSETS NS (Assets S.A, n.d.) es un Sistema de Gestión Integral estándar y parametrizado
que permite el control de los procesos de Compras, Ventas, Producción, Taller, Inventario,
Finanzas, Contabilidad, Presupuesto, Activos Fijos, Útiles y Herramientas y Recursos
Humanos. Como Sistema Integral todos sus módulos trabajan en estrecha relación,
generando, automáticamente, al Módulo de Contabilidad los Comprobantes de Operaciones
por cada una de las transacciones efectuadas. Esto permite que se pueda trabajar bajo el
principio de Contabilidad al Día.
2. Aspel PROD 3.0 (Aspel-PROD, n.d.) es un sistema que controla y administra los procesos
de fabricación, desde materias primas hasta productos terminados. Permite la planeación y
control de los procesos de fabricación de la empresa, asegurando una óptima administración
de inventarios y costos. Proporciona, un eficiente seguimiento a las órdenes de producción,
mejorando los tiempos de entrega. Interactúa con Aspel SAE 7.0 y 6.0 de los que obtiene
información de materia prima y sub-ensambles, para realizar los procesos de producción y
posteriormente actualizar el inventario con los productos terminados.
3. GestiónPYME (GestiónPYME, n.d.) un software que sugiere un método para administrar. De
fácil uso, intuitivo y completo, considerando al máximo el proceso de compras y ventas e
integrando las áreas de almacén y tesorería. Sus principales funcionalidades son: inventario,
ventas - facturación y control de cobros y pagos.
4. Kubbos (Kubbos, n.d.) es un programa de gestión web, que permite a las empresas llevar de
una forma sencilla y rápida la administración de su empresa desde cualquier lugar.
Algunas de sus funcionalidades son: Facturación, Ventas, Compras, Almacén,
Administración y otras.
5. Versat Sarasola (Sosa, 2010). Es un sistema de gestión contable-financiero, que incluye
varios módulos. Control de Activos Fijos e Inventarios, Finanzas y Planificación, son algunos
SIGAU. Capítulo I
9
de ellos. Otros, como Contabilidad General y Facturación. Es un sistema integral, que se
actualiza constantemente en función de nuevas demandas y viabiliza, sin dudas, la
organización y el control en el área económica.
6. SIAF es una herramienta que se encarga de la gestión de los procesos administrativos en
las facultades. La misma propicia información a todos los trabajadores sobre la ejecución del
presupuesto y permite gestionar reportes sobre la base del control del presupuesto, así como
visualizar la responsabilidad material por local de todo el Activo Fijo Tangible (AFT).
1.4. Tendencias y Tecnologías Actuales
En el presente epígrafe se exponen las tendencias y tecnologías actuales que fueron
utilizadas para el desarrollo del sistema como son la metodología, del entorno de desarrollo,
el lenguaje de programación y el gestor de base de datos.
1.4.1. Fundamentación de la Metodología utilizada.
1.4.1.1. AUP (Agile Unified Process)
Según (Torrencilla, 2012) el Proceso Unificado Ágil (AUP, del inglés Agile Unified
Process) es una versión simplificada del Proceso Unificado de Rational (Rational
Unified Process, RUP) desarrollada por Scott Ambler, que describe una
aproximación al desarrollo de aplicaciones que combina conceptos propios del
proceso unificado tradicional con técnicas ágiles, con el objetivo de mejorar la
productividad.
En general, el Proceso Unificado Ágil supone un enfoque intermedio entre XP
(eXtreme Programming) y el Proceso Unificado de Rational, y tiene la ventaja de
ser un proceso ágil que incluye explícitamente actividades y artefactos a los que
la mayoría de desarrolladores ya están, de alguna manera, acostumbrados.
Muchas organizaciones recelan de XP porque les parece demasiado ligero: XP
no específica cómo crear algunos de los artefactos que los gestores necesitan, lo
cual es en cierta manera una contrariedad porque XP se considera, en general,
un buen proceso ágil.
Por otro lado está el Proceso Unificado de Rational, cuya gestión resulta
realmente sencilla pero que los desarrolladores suelen temer debido al gran
número de artefactos que requiere. Esto también resulta desafortunado porque el
SIGAU. Capítulo I
10
Proceso Unificado tiene mucho que ofrecer, y puede ser adaptado y reajustado
hasta conseguir algo más o menos práctico (que es exactamente lo que IBM
Rational recomienda). El Proceso Unificado Ágil, se haya entre ambos, adoptando
algunas de las técnicas ágiles de XP y otros procesos ágiles, pero reteniendo
parte de la formalidad del Proceso Unificado de Rational.
El Proceso Unificado Ágil consta de cuatro fases que el proyecto atraviesa de
forma secuencial. Dichas fases son, al igual que en el Proceso Unificado de
Rational:
Iniciación: El objetivo de esta fase es identificar el alcance inicial del
proyecto, una arquitectura potencial para el sistema y obtener, si procede,
financiación para el proyecto y la aceptación por parte de los promotores
del sistema.
Elaboración: Mediante esta fase se pretende identificar y validar la
arquitectura del sistema.
Construcción: El objetivo de esta fase consiste en construir el software
desde un punto de vista incremental basado en las prioridades de los
participantes.
Transición: En esta fase se valida y despliega el sistema en el entorno de
producción.
1.4.2. Fundamentación del Entorno de Desarrollo, Lenguaje de Programación, Gestor
de Base de Datos y Tecnología utilizados.
1.4.2.1. HTML
Es considerado por (Gauchat, Juan Diego, 2012) como el lenguaje web más
importante siendo su invención crucial en la aparición, desarrollo y expansión de la
World Wide Web (WWW). Es el estándar que se ha impuesto en la visualización de
páginas web y es el que todos los navegadores actuales han adoptado.
HTML5: Es un lenguaje de marcado de hipertexto, el cual se encuentra en la quinta
versión del lenguaje básico de la World Wide Web. Incluye muchos nuevos elementos
para estructurar los contenidos de las páginas sin tener que recurrir siempre a la
etiqueta <div>. El elemento <header> agrupa todos los contenidos de la cabecera de
la página (logotipo, menú principal de navegación, buscador, etc.). El elemento <nav>
SIGAU. Capítulo I
11
se emplea para marcar la navegación del sitio web y suele encontrarse dentro de
<header>. El elemento <footer> encierra todos los contenidos del pie de página. Los
contenidos interiores de cada página se estructuran con los elementos <article> y
<section>, una misma página puede contener tantos <article> como necesite,
aunque resulta común utilizar solamente uno y estructurar su interior con <section>.
El último elemento importante es <aside>, ya que encierra el contenido relacionado
con el contenido principal de la página. Esta relación es en ocasiones tan vaga, que
se puede considerar como un contenido aparte. En la Figura 1 se muestra la
representación de los nuevos elementos de HTML5.
Figura 1: Representación visual de las nuevas etiquetas de HTML5.
SIGAU. Capítulo I
12
1.4.2.2. CSS3
Según (Javier Eguíluz Pérez, 2008) es un lenguaje de hojas de estilos creado para
controlar el aspecto o presentación de los documentos electrónicos definidos con
HTML y XHTML. CSS es la mejor forma de separar los contenidos y su presentación
y es imprescindible para crear páginas web complejas.
Mientras que el lenguaje HTML/XHTML se utiliza para marcar los contenidos, es decir,
para designar lo que es un párrafo, lo que es un titular o lo que es una lista de
elementos, el lenguaje CSS se utiliza para definir el aspecto de todos los contenidos;
es decir, el color, tamaño y tipo de letra de los párrafos de texto, la separación entre
titulares y párrafos, la tabulación con la que se muestran los elementos de una lista,
etc.
Una de las principales características de CSS es su flexibilidad y las diferentes
opciones que ofrece para realizar una misma tarea. De hecho, existen tres opciones
para incluir CSS en un documento HTML.
1. Incluir CSS en el mismo documento HTML
2. Definir CSS en un archivo externo
3. Incluir CSS en los elementos HTML
Algunas características pueden ser:
1. Complementariedad con documentos estructurados.
2. Independencia del vendedor, la plataforma y el dispositivo.
3. Mantenibilidad.
4. Simplicidad.
5. Rendimiento de la red.
6. Flexibilidad.
7. Riqueza.
8. Combinación con lenguajes alternativos.
9. Accesibilidad.
CSS fue toda una revolución en el mundo del diseño web. Entre los beneficios
concretos de CSS se encuentran; el control de la presentación de muchos documentos
SIGAU. Capítulo I
13
desde una única hoja de estilo, el control más preciso de la presentación, la aplicación
de diferentes presentaciones a diferentes tipos de medios (pantalla, impresión, etc.), y
numerosas técnicas avanzadas y sofisticadas.
1.4.2.3. Bootstrap Framework
Bootstrap (Spurlock, 2013) se lanzó en agosto de 2011.Ha evolucionado de ser un
proyecto totalmente basado en CSS para incluir una gran cantidad de complementos
de JavaScript e íconos que van de la mano con formas y botones. En su base, permite
responder a diseño web y presenta una rejilla robusta de 12 columnas y 940px de
ancho. Uno de los aspectos más destacados es la herramienta de compilación en el
sitio web de Bootstrap, donde puede personalizar la construcción para que se adapte
a sus necesidades.
En la Figura 2 se muestra la estructura del archivo Bootstrap:
Figura 2: Estructura de los archivos de bootstrap
1.4.2.4. JAVASCRIPT
Es un lenguaje de programación que se utiliza principalmente para crear páginas web
dinámicas.Una página web dinámica es aquella que incorpora efectos como aparición
y desaparición de texto, animaciones, acciones que se activan al pulsar botones u
otros elementos y ventanas con mensajes de aviso al usuario.
Según (Pérez) JavaScript es un lenguaje de programación interpretado, por lo que no
es necesario compilar los programas para ejecutarlos. En otras palabras, los
programas escritos con JavaScript se pueden probar directamente en cualquier
navegador sin necesidad de procesos intermedios.
SIGAU. Capítulo I
14
A pesar de su nombre, no guarda ninguna relación directa con el lenguaje de
programación Java. Legalmente, JavaScript es una marca registrada de la empresa
Sun Microsystems.
1.4.2.5. PHP
PHP del inglés (Hypertext Preprocessor) es un lenguaje "open source" interpretado
de alto nivel embebido en páginas HTML y ejecutado en el servidor.
En PHP según (Bakken, et al., 1997) se puede hacer cualquier cosa que se pueda
hacer con un script CGI, como procesar la información de formularios, generar
páginas con contenidos dinámicos o mandar y recibir cookies.
PHP también tiene soporte para comunicarse con otros servicios usando protocolos
tales como LDAP, IMAP, SNMP, NNTP, POP3, HTTP, COM (en Windows) y muchos
otros. También se pueden crear sockets. PHP soporta WDDX para intercambio de
datos entre lenguajes de programación en web. PHP puede utilizar objetos Java de
forma transparente como objetos PHP.
Quizás la característica más potente y destacable de PHP es su soporte para una gran
cantidad de bases de datos. Escribir un interfaz vía web para una base de datos es
una tarea simple con PHP. Las siguientes bases de datos están soportadas
actualmente Adabas D, Ingres, Oracle (OCI7 and OCI8), dBase, InterBase, Ovrimos,
Empress, FrontBase, PostgreSQL, FilePro (read-only), mSQL, Solid, Hyperwave
Direct, MS-SQL, Sybase, IBM DB2, MySQL, Velocis, Informix, ODBC y Unix dbm.
1.4.2.6. Symfony
Según (Potencier & Zaninotto, 2012) Symfony es un framework que simplifica el
desarrollo de una aplicación mediante la automatización de algunos de los patrones
utilizados para resolver tareas comunes. Proporciona estructura al código fuente,
forzando al desarrollador a crear código más legible y más fácil de mantener. Facilita
la programación de aplicaciones, ya que encapsula operaciones complejas en
instrucciones sencillas.
Symfony está diseñado para optimizar el desarrollo de las aplicaciones web, gracias a
sus características. Para empezar, separa la lógica de negocio con la lógica de
servidor y la presentación de la aplicación web. Proporciona varias herramientas y
clases encaminadas a reducir el tiempo de desarrollo de una aplicación web compleja.
SIGAU. Capítulo I
15
Además, automatiza las tareas más comunes, permitiendo al desarrollador dedicarse
por completo a los aspectos específicos de cada aplicación. Está desarrollado
completamente con PHP5. Ha sido probado en numerosos proyectos reales y se utiliza
en sitios web de comercio electrónico de primer nivel. Es compatible con la mayoría
de gestores de bases de datos, como MySQL, PostgreSQL, Oracle y SQL Server de
Microsoft. Se puede ejecutar tanto en plataformas Unix, Linux, etc. como en
plataformas Windows.
Otras características a destacar pueden ser según (Potencier & Zaninotto, 2012):
1. Fácil de instalar y configurar en la mayoría de las plataformas
2. Independiente del sistema gestor de bases de datos. Su capa de abstracción
y el uso de ORM permiten cambiar con facilidad de SGBD en cualquier fase
del proyecto.
3. Utiliza programación orientada a objetos y características como los espacios
de nombres.
4. Sencillo de usar en la mayoría de casos, aunque es preferible para el
desarrollo de grandes aplicaciones Web que para pequeños proyectos.
5. Aunque utiliza MVC (Modelo Vista Controlador), tiene su propia forma de
trabajo en este punto, con variantes del MVC clásico como la capa de
abstracción de base de datos, el controlador frontal y las acciones.
6. Código fácil de leer que incluye comentarios de phpDocumentor y que permite
un mantenimiento muy sencillo.
7. Fácil de extender, lo que permite su integración con las bibliotecas de otros
fabricantes.
1.4.2.7. Twig
Twig (SensioLabs Product, n.d.) es un motor de plantillas flexible, rápido y seguro para
PHP. Tiene alguna exposición a otros lenguajes de plantilla basados en texto, como
Smarty, Django o Jinja. Es amigable tanto con los diseñadores como con los
desarrolladores al apegarse a los principios de PHP y agregar funcionalidades útiles
para entornos de plantillas.
Twig es utilizado por muchos proyectos de código abierto como Symfony (Symfony,
n.d.), Drupal8 (Drupal.org, n.d.), eZPublish (eZ Publish, n.d.), phpBB (phpBB, n.d.),
Piwik (Piwik PRO, n.d.), OroCRM (OroCRM, n.d.) y muchos frameworks también lo
SIGAU. Capítulo I
16
soportan, como Slim (Slim Framework, n.d.), Yii (Yii PHP Framework, n.d.), Laravel
(Laravel, n.d.), Codeigniter (EllisLab, n.d.), Kohana (Kohana, n.d.) y otros más.
1.4.2.8. SGBD (Sistema Gestor de Base Datos) MySQL
Según (Gallego Vázquez, 2003) MySQL es, sin duda, la base de datos más popular y
utilizada a la hora de desarrollar páginas Web dinámicas y sitios de comercio
electrónico. Se suele trabajar en combinación con PHP, y comparte con este algunas
de las características que lo convierten en una elección segura. Entre ellas:
Gratuito: También se trata de software libre que puede ser utilizado sin
limitación alguna.
Rapidez: La velocidad de proceso de MySQL es legendaria.
Sencillez: Al utilizar el lenguaje estándar SQL y tener conocimientos de otras
bases de datos.
La base de datos MySQL se puede manejar a través del programa phpMyAdmin. De
manera sencilla e intuitiva, se utiliza para crear, modificar o borrar bases de datos.
Cuando PHP se comunica con MySQL lo hacen en un lenguaje particular, conocido
como SQL (Structured Query Language) el cual es un lenguaje de búsqueda y
estructurado.
1.4.2.9. Unified Modeling Language (UML)
Según (Dharwiyanti & Wahono, 2003) es un lenguaje que se ha convertido en el
estándar dentro de la industria para visualizar, diseñar y documentar sistemas de
software.
Al usar UML, podemos crear modelos para todo tipo de aplicaciones de software,
donde la aplicación se puede ejecutar en cualquier hardware, sistema operativo y red,
así como escrito en cualquier lenguaje de programación. Pero UML también usa clase
y operación en su concepto básico, entonces es más adecuado para la escritura de
software orientado a objetos como C++, Java, C# o VB.NET. Sin embargo, UML se
puede usar para modelar aplicaciones de procedimientos en VB o C.
1.5. Conclusiones Parciales del Capítulo
En este capítulo se realizó un análisis de los objetivos de la Universidad Central “Marta Abreu” de
las Villas, así como los objetivos del departamento administrativo de las facultades y las actividades
SIGAU. Capítulo I
17
a informatizar dentro de este. Se realizó un estudio de la metodología y tecnologías a emplear para
dar solución al problema descrito, decidiéndose utilizar: Bootstrap como framework o biblioteca del
lado del cliente para el uso de tecnologías HTML5, CSS3 y JavaScript; AUP como metodología de
desarrollo de software; UML como lenguaje de modelado; PHP para lenguaje de programación del
lado del servidor utilizando Symfony3 como framework de desarrollo y MySQL como gestor de base
de datos para la herramienta.
SIGAU. Capítulo II
18
Capítulo II. Modelo del Negocio y Requisitos
En el presente capítulo se describen algunos de los procesos administrativos fundamentales
llevados a cabo en la Universidad. El estudio de estos mecanismos a través de los modelos de
negocio, reglas, requisitos, actores y casos de usos del negocio contribuyen a la solución del
problema.
2.1. Modelo del negocio actual
En la Universidad Central “Marta Abreu” de Las Villas en el ámbito de la administración se llevan a
cabo varios procesos:
Creación de reportes de pago mensual: Mensualmente por sistema de trabajo se
establece en la planificación de la Universidad la fecha para cada área en la que se debe
hacer entrega del reporte de pago. Tanto en las facultades como en las direcciones hay
nombrada una persona que se encarga de recopilar la información proveniente de los
diferentes departamentos y con ella confecciona el modelo RH-3 (i-10). Este documento tiene
tres niveles de aprobación, es firmado primariamente por quien lo confecciona; quien lo
revisa, que es el jefe de departamento origen de las infracciones; y finalmente el decano o
director como máxima autoridad en las áreas que lo aprueba. Adicionalmente a este reporte
se confecciona el último día del mes un complemento donde se relacionan las infracciones
posteriores al reporte inicial.
Registro de dietas: El trabajador solicita la dieta a su jefe de departamento. Este la aprueba
y se la envía al jefe de departamento administrativo. Se procede entonces a la impresión del
documento, firma y cobro de la dieta. Dependiendo del tipo de dieta (Anticipo o liquidación)
los procedimientos pueden variar. También es posible, aplicando el método tradicional, con
la carta del jefe de departamento debidamente autorizada, el jefe departamento
administrativo tiene la capacidad de ofrecer este servicio a todos los trabajadores de su área.
Registro de vales de pagos menores: Cuando el profesor se acerca al administrativo del
área con la documentación requerida, se registra y cobra.
Control de activos fijos: Este proceso se divide en varios procesos entre los que se
destacan el registro de un nuevo activo fijo en la facultad, el chequeo periódico del estado
SIGAU. Capítulo II
19
de este en cada uno de los locales, designar uno o varios responsables del activo o el
proceso de baja.
Baja del trabajador: el trabajador le solicita la baja a su jefe de departamento docente o jefe
de departamento en general, este se lo notifica al jefe de departamento administrativo y al
decano. Si el jefe de departamento docente aprueba la tramitación, el trabajador debe
presentar al jefe de departamento administrativo la baja del punto de préstamo de libros, de
economía, de relaciones internacionales en caso de ser un profesor, de la biblioteca y debe
presentar el hago constar de su jefe de departamento. Luego de esto el jefe de departamento
administrativo procede a solicitar la baja a la secretaria del decano o del director, la cual
finalmente confeccionaría la baja del trabajador.
Solicitud de alimentación: El trabajador le hace la solicitud al jefe de departamento
administrativo, este la aprueba, la imprime y es firmada por los directivos. Luego se la envía
al director de alimentación para que la apruebe.
Solicitud de transporte: El trabajador le hace la solicitud al jefe de departamento
administrativo, y además se lo hace saber a su jefe de departamento. Si el jefe de
departamento administrativo la aprueba se la envía al director de transporte, y una vez que
tenga el cheque, el trabajador puede pasar a recogerlo para la compra de su viaje.
Solicitud de mantenimiento: El trabajador le hace la solicitud al jefe de departamento
administrativo, este la aprueba, la imprime y es firmada por los directivos. Luego se la envía
al director de mantenimiento para que el mismo la apruebe.
Solicitud de alojamiento: El trabajador le hace la solicitud al jefe de departamento
administrativo, este la aprueba, la imprime y es firmada por los directivos. Luego se la envía
al director de residencia y postgrado para que la apruebe.
2.2. Reglas del negocio a considerar
Una regla del negocio es una declaración que define o restringe algún aspecto del negocio. Intenta
definir, controlar o influenciar el comportamiento y la estructura del negocio (Hitpass, 2017).
RN1: El jefe de departamento administrativo debe establecer la fecha de entrega del reporte de
incidencias a principios del mes establecido por el plan de trabajo de la institución.
SIGAU. Capítulo II
20
RN2: Los reportes de pago mensuales deben ser creados y entregados al departamento
administrativo a finales de mes en las fechas establecidas inicialmente.
RN3: Todos los activos fijos tienen que tener un responsable.
RN4: La solicitud de una dieta por liquidación tiene que ser bien argumentada en su solicitud.
2.3. Actores del negocio
Representa a una persona o un grupo de personas que tenga relación indirecta con el proceso
empresarial o caso de uso de negocio. La definición del actor externo de negocio depende del
caso de uso de negocio que se esté analizando (Mueras, 2005). En la Tabla 1 se muestra la
descripción de los actores del negocio.
Tabla 1: Actores de Negocio
Actor del Negocio Descripción
Jefe departamento
administrativo
Es quien atiende toda la actividad de gestión administrativa de una
facultad, es el responsable directo de la gestión económica
financiera y de los servicios. Encargado de la elaboración y
tramitación de los reportes de pago, tramitación de dietas y pagos
menores de los trabajadores. Además lleva el control del uso y
destino de los recursos y la gestión del 100% de los activos fijos
tangibles y útiles y herramientas. Realiza conciliaciones con la
Dirección General de Economía sobre gastos por partidas y
disponibilidad, vales de pagos menores y dietas.
Trabajador Es el actor del negocio, que en dependencia de las actividades
planificadas ya sea personalmente o por la institución, solicita los
diversos servicios que se ofrecen en el ámbito laboral.
2.4. Diagrama de casos de uso del negocio
Un modelo de casos de uso del negocio describe los procesos de negocio de una entidad en
términos de casos de uso del negocio y actores del negocio que se corresponden con los procesos
del negocio y los clientes, respectivamente. Al igual que un modelo de casos de uso para un sistema
software, el modelo de casos de uso del negocio presenta un sistema (en este caso, el negocio)
desde la perspectiva de su uso, y esquematiza cómo proporciona valor a sus usuarios (en este caso
SIGAU. Capítulo II
21
sus clientes y socios) (Jacobson, et al., s.f.). En la Figura 3Figura 3 se muestra el diagrama de caso
de uso del negocio.
SIGAU. Capítulo II
22
Figura 3 Diagrama de Casos de Uso del Negocio
SIGAU. Capítulo II
23
2.5. Trabajadores del negocio
Conocido también como actor interno del negocio, representa a una persona o un grupo de
personas que tienen relación directa con el proceso empresarial. Su definición depende al caso
de uso de negocio que se esté analizando (Mueras, 2005). En la Tabla 2 se muestra la descripción
de los trabajadores del negocio.
Tabla 2: Trabajadores del negocio.
Trabajador del Negocio Descripción
Jefe departamento
docente
Es el personal encargado de elaborar el reporte de incidencias
solicitado por el jefe del departamento administrativo.
Jefe departamento
administrativo
Es la persona que busca la información pedida por cada trabajador
para la consulta de vales o dietas registradas. Además se encarga de
aprobar las solicitudes y enviarlas a los directivos correspondientes
para que estos las aprueben. También recibe las solicitudes de baja
de los trabajadores.
2.6. Casos de uso del negocio
Representa a un proceso empresarial, aquel conjunto de actividades continuas, necesarias
para la existencia de la organización. Los casos de uso de negocio empiezan su definición en
verbo (Mueras, 2005). En la Tabla 3 se puede observar la descripción de los casos de uso del
negocio.
Tabla 3: Descripción de los casos de uso del negocio
Caso de uso del negocio Descripción
Gestionar presupuesto El jefe del departamento administrativo inicia el caso de uso una
vez que se le informa desde planificación en la universidad cuál
fue el presupuesto aprobado para la facultad y conforma cada una
de las partidas en las que se desglosa el presupuesto asignado.
Obtener reporte de
incidencias
El jefe del departamento administrativo inicia el caso de uso con
una solicitud del reporte de incidencias a cada jefe de
departamento de la facultad a finales de mes.
SIGAU. Capítulo II
24
Crear reporte I10 Este caso de uso es iniciado por el jefe del departamento
administrativo e incluye la obtención de cada uno de los reportes
de incidencia de los departamentos de la facultad.
Procesar dieta El jefe del departamento administrativo inicia el caso de uso
cuando se le llena el modelo de la dieta a un trabajador de la
facultad.
Procesar vale de pago El jefe del departamento administrativo inicia el caso de uso
cuando llena el modelo de vale de pago a un trabajador de la
facultad.
Gestionar activos fijos Este caso de uso es llevado a cabo por el departamento
administrativo una vez que es necesario registrar nuevos activos
fijos en la facultad, asignar responsable cambiar de local, modificar
los valores con los que fue registrado en la facultad o dar de baja
a este activo.
Consultar incidencias El trabajador inicia este caso de uso una vez que necesita
consultar con su jefe de departamento cuáles son las incidencias
que tiene registrada en el mes antes de que se conforme el reporte
de las mismas.
Consultar dietas Este caso de uso inicia cuando un trabajador necesita consultar
con el jefe del departamento administrativo el estado de una dieta
que fue solicitada por el mismo.
Consultar vales de pago Este caso de inicia cuando un trabajador necesita consultar con el
jefe del departamento administrativo los vales de pago que se les
han otorgado u otros datos de interés para el trabajador como, por
ejemplo, en qué rango de fechas del presente mes puede cobrar
este importe.
Solicitar baja Este caso de uso se inicia cuando un trabajador solicita la baja al
jefe de departamento administrativo donde le tiene que explicar al
mismo las causas para ser aprobada. Además tiene que presentar
la baja del punto de préstamo de libros, de la biblioteca, de
economía y de relaciones internacionales en caso de ser profesor
y el hago constar de su jefe de departamento.
SIGAU. Capítulo II
25
2.7. Actores del sistema a automatizar
Un actor es un conjunto coherente de roles que desempeñan los usuarios de los casos de uso
cuando interactúan con estos. Podríamos dividir a los usuarios del sistema en tipos dependiendo el
uso que le den, dependiendo de los casos de uso en que participen. Un actor representa a un tipo
de usuario cuando éste interacciona con el sistema en un caso de uso (Alonso, et al., 2005). En la
Tabla 4 se muestra una descripción de los actores del sistema a automatizar.
Tabla 4: Actores del sistema a automatizar
Actor del Sistema Descripción
Trabajador Es uno de los usuarios con la capacidad de consultar sus datos y cuál
es el estado del presupuesto en CUC y en CUP de su facultad o de
los proyectos de la misma.
También puede realizar solicitudes de baja, alimentación, transporte,
mantenimiento, alojamiento, dietas por anticipo o liquidación.
Consultar la nómina de pago, los activos fijos, útiles y herramientas.
Solicitar alimentación Este caso de uso se inicia cuando un trabajador solicita
alimentación se lo pide al jefe de departamento administrativo para
que este la apruebe y la envíe a la Dirección de Alimentación.
Solicitar transporte Este caso de uso se inicia cuando un trabajador le solicita a su jefe
de departamento, transporte, ya sea en moneda nacional o en
divisa (Viazul). Luego se le solicita al jefe de departamento
administrativo para que la apruebe y se la envíe a la Dirección de
Transporte.
Solicitar mantenimiento Este caso de uso se inicia cuando un trabajador hace una solicitud
de mantenimiento al jefe de departamento administrativo para que
este la apruebe y la envíe a la Dirección de Mantenimiento.
Solicitar alojamiento
Este caso de uso se inicia cuando un trabajador solicita
alojamiento se lo pide al jefe de departamento administrativo para
que este la apruebe y la envíe a la Dirección de Residencia y
Postgrado.
SIGAU. Capítulo II
26
Jefe departamento Es uno de los usuarios encargados de la creación de los reportes de
incidencias del departamento y de la labor del registro de ausencias
e infracciones de los usuarios y para ello necesita estar autenticado.
Además puede gestionar los locales y los trabajadores de su
departamento.
Jefe del departamento
administrativo
Este actor además de cumplir el rol de jefe de su departamento, es el
encargado de gestionar el presupuesto en CUC del centro al que
pertenece, así como controlar y velar por el nivel de gastos en las
partidas en que este es desglosado. Es el encargado de crear el
reporte I-10 de cada uno de los departamentos y crear la carta
complemento cuando se reporten incidencias después de la fecha de
entrega. También es el responsable de la gestión de dietas y vales de
pago y la creación de reportes de estos a finales de mes. Tendrá la
capacidad de gestionar locales en los departamentos y asignar
activos fijos, útiles y herramientas en los mismos, pudiendo nombrar
responsables de estos en el departamento para llevar el control de
medios materiales de una manera correcta. Es responsable de
establecer la fecha de entrega del reporte de incidencias. Puede
también gestionar los trabajadores de la facultad ya que tiene la
capacidad de actualizar sus datos en el sistema, así como darle baja
del mismo. También puede cargar y actualizar los estudiantes de la
facultad.
Decano Es un usuario que puede poner ausencias a los trabajadores si lo
desea.
Director Planificación
Estadística
Encargado de cargar el presupuesto en CUP.
Jefe Grupo Finanza Encargado de cargar el presupuesto en CUC.
Especialista Nomina Encargado de cargar la nómina de pago.
Técnico de RH Encargado de cargar los trabajadores de la universidad.
SIGAU. Capítulo II
27
2.8. Definición de los requisitos funcionales
Es la declaración de una función o comportamiento del problema, hay otra dificultad en el desarrollo
de software para atender solo a los requisitos funcionales: el cliente puede no tener certeza sobre
lo que él quiere del software. Esta condición es bien conocida por la Ingeniería de Requisitos, que
nos proporciona algunas técnicas para resolverla o enfrentarla (Arias & Durango, 2016).
RF1 Gestionar departamento.
RF1.1 Listar usuarios del departamento.
RF1.2 Listar locales del departamento.
RF1.3 Listar reportes del departamento.
RF1.4 Gestionar local.
RF1.4.1 Adicionar local.
RF1.4.2 Modificar local.
RF1.4.3 Eliminar local.
RF1.7 Adicionar departamento.
RF1.8 Modificar departamento.
RF1.9 Eliminar departamento.
RF2 Crear y publicar reportes RH-3 (I10) del departamento por mes.
RF3 Crear y publicar complemento RH-3 (I10) del departamento.
RF4 Crear y publicar reporte PTP del departamento.
RF5 Crear y publicar reporte PTP Jubilado del departamento.
RF6 Gestionar trabajador.
RF6.1 Ver listado de los trabajadores del centro.
SIGAU. Capítulo II
28
RF6.2 Ver información de cada trabajador.
RF6.2 Modificar información de cada trabajador.
RF6.3 Dar baja.
RF6.4 Modificar estado de misión internacionalista.
RF7 Gestionar presupuesto CUP.
RF7.1 Mostrar presupuesto CUP.
RF7.2 Eliminar presupuesto CUP.
RF7.3 Cargar presupuesto CUP.
RF8 Gestionar presupuesto CUC.
RF8.1 Mostrar presupuesto CUC.
RF8.2 Adicionar gasto al presupuesto CUC.
RF8.3 Eliminar un gasto al presupuesto CUC.
RF9 Gestionar dietas.
RF9.1 Solicitar dieta por anticipo o liquidación.
RF9.2 Modificar el número de anticipo y de liquidación de las dietas.
RF9.3 Eliminar dietas anticipadas.
RF9.4 Adicionar vale de pago a dieta.
RF9.5 Listar dietas del centro.
RF9.6 Crear y publicar modelo de cada dieta.
RF9.7 Crear y publicar reporte de conciliaciones de dietas mensuales del centro.
SIGAU. Capítulo II
29
RF10 Gestionar vales de pago.
RF10.1 Adicionar vales de pagos menores a estudiantes y trabajadores.
RF10.2 Eliminar vales de pago.
RF10.3 Listar vales de pago asociados a dietas del centro.
RF10.4 Listar vales de pago menores del centro.
RF10.5 Crear y publicar modelo de cada vale de pago.
RF10.6 Crear y publicar reporte de conciliaciones de vales de pago menores
mensuales del centro.
RF11 Gestionar activos fijos.
RF11.1 Adicionar activo fijo en cualquier local.
RF11.2 Modificar activo fijo.
RF11.3 Dar baja a un activo fijo.
RF11.4 Listar activos fijos registrados en el centro.
RF11.5 Listar activos fijos de baja en el centro.
RF11.6 Agregar responsable.
RF11.7 Quitar responsable.
RF11.8 Agregar local.
RF11.9 Quitar local.
RF11.10 Cargar 10% de los activos fijos.
RF11.11 Mostrar historial por mes del 10% de los activos fijos.
SIGAU. Capítulo II
30
RF12 Gestionar fechas.
RF12.1 Definir fecha de entrega de los reportes de incidencia y PTP todos los meses.
RF12.2 Definir sábados laborables.
RF13 Gestionar ausencias.
RF13.1 Adicionar ausencias.
RF13.2 Modificar ausencias.
RF13.3 Eliminar ausencias.
RF13.4 Listar ausencias.
RF14 Gestionar infracciones.
RF14.1 Adicionar infracciones.
RF14.2 Eliminar infracciones.
RF14.3 Eliminar infracciones.
RF14.4 Listar infracciones.
RF15 Mostrar reporte de incidencia del mes
RF15.1 Crear reporte de incidencias del mes.
RF16 Cargar Información
RF16.1 Cargar presupuesto CUC.
RF16.2 Cargar nómina de pago.
RF16.3 Cargar trabajadores de la universidad.
RF16.4 Cargar estudiantes del centro.
SIGAU. Capítulo II
31
RF16.5 Cargar activos fijos del centro.
RF16.6 Cargar útiles y herramienta del centro.
RF17 Gestionar Facultad
RF17.1 Adicionar facultad.
RF17.2 Modificar facultad.
RF17.3 Eliminar facultad.
RF17.4 Listar facultades.
RF18 Gestionar Dirección
RF18.1 Adicionar dirección.
RF18.2 Modificar dirección.
RF18.3 Eliminar dirección.
RF18.4 Listar direcciones.
RF19 Gestionar Centro Adscripto
RF19.1 Adicionar centro adscripto.
RF19.2 Modificar centro adscripto.
RF19.3 Eliminar centro adscripto.
RF19.4 Mostrar información de un centro adscripto.
RF19.5 Listar centro adscripto.
RF20 Gestionar Departamento PTP.
RF20.1 Adicionar departamento PTP.
SIGAU. Capítulo II
32
RF20.2 Modificar departamento PTP.
RF20.3 Eliminar departamento PTP.
RF21 Solicitar Baja.
RF22 Gestionar solicitud de alimentación.
RF22.1 Solicitar alimentación
RF23 Gestionar solicitud de transporte.
RF23.1 Solicitar transporte
RF24 Gestionar solicitud de mantenimiento.
RF24.1 Solicitar mantenimiento.
RF25 Gestionar solicitud de alojamiento.
RF25.1 Solicitar alojamiento.
RF26 Gestionar Estudiantes.
RF26.1 Actualizar estudiantes.
RF26.2 Listar estudiantes del curso regular diurno.
RF26.3 Listar estudiantes del curso por encuentro.
Definición de los requisitos no funcionales
Los requisitos no funcionales de un producto, están relacionados con la calidad del software y son
alcanzados por lo que llamamos atributos de calidad. Por lo tanto, cuando existen requisitos en que
el software debe tener algún grado de confiabilidad, correcto nivel de eficiencia, o ser portables a
diversos sistemas operativos, se describe qué atributos de calidad el software debe poseer. (Arias
& Durango, 2016).
SIGAU. Capítulo II
33
Apariencia o interfaz externa.
RNF1 El diseño del sitio debe ser amigable y de fácil acceso a las funcionalidades de
navegación.
RNF2 Los colores y la estructura de los componentes estarán distribuidos para lograr que el
usuario se sienta a gusto y tranquilo durante la navegación.
Usabilidad.
RNF3 El sistema será de fácil acceso y uso para cualquier usuario que acceda a él,
requiriéndose un mínimo proceso de aprendizaje y conocimientos básicos de computación y
trabajo en la Web.
Rendimiento.
RNF4 El sistema deberá ser capaz de gestionar toda la información de los contenidos que
se suban o descarguen del sitio por todos los usuarios que accedan a esta y las demás
funcionalidades.
RNF5 La interacción con la Base de Datos y la carga de las páginas dinámicas debe ser lo
más rápido posible para dar respuesta a las solicitudes de los usuarios.
RNF6 Debe estar disponible las 24 horas del día.
RNF7 Soportará a un amplio número de usuarios conectados simultáneamente en cualquier
momento dado.
Soporte.
RNF8 Fácil para el mantenimiento, de configuración sencilla y factible para los clientes.
Portabilidad.
RNF9 El estar implementado sobre PHP lo hará una aplicación completamente
Multiplataforma y portable, por tanto será accesible tanto desde el Sistema operativo
Windows como desde cualquier distribución de Linux sin afectar su funcionamiento.
Seguridad.
SIGAU. Capítulo II
34
RNF10 La seguridad del sitio se garantizará a través de la implementación de un sistema de
roles de usuario, donde cada uno de ellos tendrá una función definida y acceso a ejecutar
sólo las acciones que le correspondan.
RNF11 La base de datos estará protegida contra intrusiones externas y el contenido del sitio
sólo podrá ser modificado por los administradores.
Confiabilidad.
RNF12 El sitio deberá estar disponible en todo momento y se garantizará la eficiencia de los
procesos de manera rápida y exacta.
Software.
RNF13 En las PC clientes se debe tener instalado Navegador Web: Mozilla Firefox, Ópera o
Internet Explorer. El servidor debe tener Servidor de aplicaciones Apache versión 2.0 con
PHP 5.3 y Sistema Gestor de Base de Datos MySQL.
2.9. Diagrama de Casos de Uso del Sistema
El diagrama de casos de uso es un modelo que compendia los casos de uso, sus actores y sus
relaciones. Constituye la base del acuerdo entre el cliente y los desarrolladores del sistema sobre
qué debe realizar el sistema y cómo debe hacerlo dependiendo de sus usuarios (Alonso, et al.,
2005).
La Figura 4, Figura 5, Figura 6, Figura 7, Figura 8 y la Figura 9 muestran los diagramas de Casos
de Uso (CU) del sistema, ya que está dividido por los distintos actores del sistema.
La Figura 4 muestra los CU del sistema para el actor trabajador. Aquí se muestra las relaciones
entre los actores, donde se observa que el Jefe de Departamento, el Decano, el Administrador, el
Jefe de Grupo de Finanzas, el Director de Estadística, el Especialista de Nómina y el Técnico de
Recursos Humanos heredan del actor Trabajador, además el Jefe de Departamento Administrativo
hereda del Jefe de Departamento y los Directores de Alimentación y Transporte heredan del Decano.
SIGAU. Capítulo II
35
Figura 4 Diagrama de Casos de Uso para el Actor Trabajador
La Figura 5 muestra el diagrama de CU para el actor Jefe de Departamento Docente. Se muestra la
relación que existe entre este y el actor Trabajador; esta es una información redundante pues se
indicó previamente, pero en ocasiones se puede repetir alguna información que se desea tener en
cuenta, siempre y cuando no afecte la comprensión del diagrama. En este caso se desea puntualizar
que además de acceder a estas funcionalidades el actor Jefe de Departamento Docente puede jugar
otro rol y por tanto hace uso de otras funcionalidades.
SIGAU. Capítulo II
36
Figura 5 Diagrama de Casos de Uso para el Actor Jefe de Departamento.
La Figura 6 muestra el diagrama de CU para el actor Jefe de Departamento Administrativo y su
relación de herencia con el actor Jefe de Departamento Docente, así como la generalización del
Jefe de Departamento con el Trabajador.
SIGAU. Capítulo II
37
Figura 6 Diagrama de Casos de Uso para el Actor Jefe de Departamento Administrativo
La Figura 7 muestra el diagrama de CU para el actor administrador.
SIGAU. Capítulo II
38
Figura 7 Diagrama de Casos de Uso para el Actor Administrador
La Figura 8 muestra el diagrama de CU para los actores Director de Alimentación y Director de
Transporte los cuales además cumplen el rol de Decano.
Figura 8 Diagrama de Casos de Uso para los Actores Director de Alimentación y Director de
Transporte
SIGAU. Capítulo II
39
La Figura 9 muestra el diagrama de CU para los actores Decano, Jefe de Grupo de Finanza,
Técnico de Recursos Humanos, Especialista de Nómina y Director de Planificación y Estadística,
observándose la herencia con Trabajador.
Figura 9 Diagrama de Casos de Uso para los Actores Decano, Jefe del Grupo de Finanza, Técnico de
Recursos Humanos, Especialista de Nomina y Director de Planificación y Estadística
2.10. Descripción de los casos de uso del Sistema (Significativos)
Un caso de uso expresa todas las formas de usar un sistema para alcanzar una meta particular para
un usuario. En conjunto, los casos de uso le proporcionan todos los caminos útiles de usar el sistema
e ilustran el valor que este provee (Jacobson, et al., 2013).
En este sistema los Casos de Uso significativos son los siguientes, Gestionar Ausencias, Cargar
Trabajadores y Gestionar Presupuesto CUC. En la Tabla 5 se muestra la descripción para el CU
Gestionar Ausencias.
SIGAU. Capítulo II
40
Tabla 5: Descripción del Caso de Uso Gestionar Ausencias.
Caso de uso del
sistema
Gestionar Ausencias
Actor Jefe de Departamento
Propósito Gestionar las ausencias de los trabajadores.
Resumen El caso de uso se inicia cuando el jefe del departamento
selecciona en la opción “Ausencias” adicionar, modificar o
eliminar una ausencia a un trabajador y finaliza cuando termina
de ejecutar una de estas operaciones.
Responsabilidades Este caso de uso es responsable de la gestión de las ausencias
de los trabajadores.
Casos de uso
asociados
Crear Reporte de Incidencias (Include)
Requisitos especiales No tiene
Precondiciones El actor que inicia el caso de uso debe estar autenticado en el
sistema.
Descripción
SIGAU. Capítulo II
41
Flujo normal de los eventos. Sección A: Adicionar Ausencias
Acción del actor Respuesta del sistema
1. El actor selecciona la
opción Reportes de
Pago / Ausencias.
2. El sistema muestra una ventana con el listado de los
trabajadores del departamento.
3. El actor selecciona la
opción Adicionar
Ausencia al trabajador
que desea.
4. El sistema muestra un formulario con los campos necesarios
para adicionar una ausencia.
5. El actor llena los
campos y selecciona la
opción Adicionar.
6. El sistema verifica que no haya ningún campo obligatorio vacío
y que los datos estén en el formato correcto.
7. El sistema muestra la página con el listado de los trabajadores
del departamento actualizado y notifica que fue adicionada
correctamente la ausencia.
Flujos alternativos 1
1. El actor llena los
campos y selecciona la
opción Adicionar.
2. El sistema muestra un mensaje de error donde se indica que
la fecha no es un sábado laborable.
Flujos alternativos 2
1. El actor llena los
campos y selecciona la
opción Adicionar.
SIGAU. Capítulo II
42
2. El sistema muestra un mensaje de error donde se indica que
la fecha no puede ser un domingo.
Flujo normal de los eventos. Sección B: Modificar Ausencia
Acción del actor Respuesta del sistema
1. El actor selecciona la
opción Reportes de
Pago / Ausencias.
2. El sistema muestra una ventana con el listado de los
trabajadores del departamento.
3. El actor selecciona la
opción Editar Ausencia
al trabajador que
desea.
4. El sistema muestra un formulario con los campos necesarios
para editar la ausencia.
5. El actor llena los
campos que desea
modificar y selecciona
la opción Adicionar.
6. El sistema verifica que no haya ningún campo obligatorio
vacío y que los datos estén en el formato correcto.
7. El sistema muestra la página con el listado de los
trabajadores del departamento actualizado y notifica que fue
adicionada correctamente la ausencia.
Flujos alternativos 1
1. El actor llena los
campos que desea
modificar y selecciona
la opción Adicionar.
2. El sistema muestra un mensaje de error donde se indica que
la fecha no es un sábado laborable.
Flujos alternativos 2
SIGAU. Capítulo II
43
1. El actor llena los
campos que desea
modificar y selecciona
la opción Adicionar.
2. El sistema muestra un mensaje de error donde se indica que
la fecha no puede ser un domingo.
Flujo normal de los eventos. Sección C: Eliminar Ausencia
Acción del actor Respuesta del sistema
1. El actor selecciona
la opción Reportes de
Pago / Ausencias.
2. El sistema muestra una ventana con el listado de los
trabajadores del departamento.
3. El actor selecciona
la opción Eliminar
Ausencia al trabajador
que desea.
4. El sistema muestra un mensaje para saber si está seguro de
eliminar la ausencia al trabajador.
5. El actor selecciona
Aceptar.
6. El sistema elimina la ausencia al trabajador.
Post condiciones La base de datos debe quedar actualizada de acuerdo a las
operaciones realizadas en las secciones A y B.
En la Tabla 6 se muestra la descripción del CU Cargar Trabajador.
Tabla 6. Descripción del Caso de Uso Cargar Trabajadores
Caso de uso del
sistema
Cargar Trabajadores
SIGAU. Capítulo II
44
Actor Técnico en Recursos Humanos
Propósito Cargar a la base de datos todos los trabajadores de la
universidad.
Resumen El caso de uso se inicia cuando el técnico de recursos humanos
selecciona la opción “Cargar Trabajadores”, seguidamente
aparece un formulario para seleccionar el Excel con la
información de los trabajadores. Finaliza cuando el técnico de
recursos termina de ejecutar esta tarea.
Responsabilidades Es el responsable de cargar los trabajadores de la universidad.
Casos de uso
asociados
No tiene
Requisitos especiales No tiene
Precondiciones El actor que inicia el caso de uso debe estar autenticado en el
sistema.
Descripción
Flujo normal de los eventos
Acción del actor Respuesta del sistema
1. El actor selecciona la
opción Cargar
SIGAU. Capítulo II
45
Información / Cargar
Trabajadores.
2. El sistema muestra una ventana con un formulario con un
campo para adicionar un archivo.
3. El actor da clic en el
campo y selecciona el
archivo Excel con los
datos de los
trabajadores o arrastra
el archivo hacia el
campo.
4. El sistema verifica que no haya ningún error.
5. El sistema muestra la página de todos los trabajadores
indicando la cantidad que fue adicionada y la cantidad de
actualizaciones.
Flujos alternativos 1
1. El actor da clic en el
campo y selecciona el
archivo Excel con los
datos de los
trabajadores o arrastra
el archivo hacia el
campo.
2. El sistema muestra un mensaje de error donde se indica que
no ha seleccionado un archivo Excel.
Flujos alternativos 2
1. El actor da clic en el
campo y selecciona el
archivo Excel con los
datos de los
trabajadores o arrastra
el archivo hacia el
campo.
SIGAU. Capítulo II
46
2. El sistema muestra un mensaje de error donde se indica que
el archivo Excel no tiene el formato correcto.
Post condiciones La base de datos debe quedar actualizada de acuerdo a las
operaciones realizadas.
En la Tabla 7 se muestra la descripción del CU Gestionar Presupuesto CUC.
Tabla 7: Descripción del Caso de Uso Gestionar Presupuesto CUC
Caso de uso del
sistema
Gestionar Presupuesto CUC
Actor Jefe Departamento Administrativo
Propósito Gestionar el presupuesto en CUC de un Centro de Costo
Resumen El caso de uso se inicia cuando el jefe del departamento
administrativo selecciona la opción “Presupuesto” y luego
“CUC”. Seguidamente puede ver los gastos, adicionarlos o
eliminarlos. Finaliza cuando el actor termina de ejecutar una de
estas dos operaciones.
Responsabilidades Es responsable de la gestión del presupuesto en CUC de un
centro de costo.
Casos de uso
asociados
No tiene
Requisitos especiales No tiene
Precondiciones El actor que inicia el caso de uso debe estar autenticado en el
sistema.
Descripción
SIGAU. Capítulo II
47
Flujo normal de los eventos. Sección A: Adicionar Gasto
Acción del actor Respuesta del sistema
1. El actor selecciona la
opción Presupuesto /
CUC.
2. El sistema muestra una ventana con el listado de los gastos
del presupuesto en CUC.
3. El actor selecciona el
botón Adicionar.
4. El sistema muestra un formulario con los campos necesarios
para adicionar un gasto.
4. El actor llena los
campos y da clic en
adicionar.
5. El sistema verifica que los campos estén correctos.
6. El sistema muestra el listado actualizado y un mensaje de
éxito.
Flujos alternativos 1
SIGAU. Capítulo II
48
1. El actor llena los
campos y da clic en
adicionar.
2. El sistema muestra un mensaje de error donde se indica que
los campos no están correctos.
Flujo normal de los eventos. Sección B: Eliminar Gasto
Acción del actor Respuesta del sistema
1. El actor selecciona la
opción Presupuesto /
CUC.
2. El sistema muestra una ventana con el listado de los gastos
del presupuesto en CUC.
3. El actor selecciona el
botón Eliminar.
4. El sistema muestra un mensaje de alerta indicando, si está
seguro de eliminar.
5. El actor da clic en el
botón Sí, Eliminar
6. El sistema muestra el listado actualizado y un mensaje de
éxito.
Post condiciones La base de datos debe quedar actualizada de acuerdo a las
operaciones realizadas en las secciones A y B.
2.11. Estimación de tiempo y costo
En este epígrafe se explicará el proceso para el cálculo de costo y tiempo basado en los CU para
las funcionalidades desarrolladas.
2.11.1. Calcular los Puntos de Casos de Uso (PCU)
El primer paso para la estimación consiste en el cálculo de los Puntos de Casos de Uso sin ajustar.
Este valor se calcula a partir de la siguiente ecuación:
SIGAU. Capítulo II
49
PCU = FPA + FPCU
Donde:
PCU: Puntos de Casos de Uso sin ajustar.
FPA: Factor de Peso de los Actores sin ajustar.
FPCU: Factor de Peso de los Casos de Uso sin ajustar.
Factor de Peso de los Actores sin ajustar (FPA)
Este valor se calcula mediante un análisis de la cantidad de Actores presentes en el sistema y la
complejidad de cada uno de ellos. La complejidad de los Actores se establece según se indica en la
Tabla 8:
Tabla 8: Factores de Peso de los Actores sin ajustar
Tipo de Actor Descripción Factor de
Peso
Número
de
Actores
Simple Otro sistema que interactúa con el sistema a
desarrollar mediante una interfaz de aplicación.
1 0
Medio Otro sistema que interactúa con el sistema a
desarrollar mediante un protocolo o una interfaz
basada en texto.
2 0
Complejo Una persona que interactúa con el sistema a
desarrollar mediante una interfaz gráfica.
3 11
FPA = Σ (Actor i * Factor de Peso i)
FPA = (0*1) + (0*2) + (11*3)
FPA = 33
Factor de Peso de los CU sin ajustar (FPCU)
SIGAU. Capítulo II
50
Este valor se calcula mediante un análisis de la cantidad de CU presentes en el sistema y la
complejidad de cada uno de ellos. La complejidad de los CU se establece teniendo en cuenta la
cantidad de transacciones efectuadas en el mismo según muestra la Tabla 9:
Tabla 9: Factor de Peso de los CU sin ajustar.
Tipo de CU Descripción Factor de
Peso
Número
de CU
Simple El CU contiene de 1 a 3 transacciones. 5 22
Medio El CU contiene de 4 a 7 transacciones. 10 12
Complejo El CU contiene 8 o más transacciones. 15 8
Finalmente el FPCU se obtiene mediante la suma de los pesos de todos los CU como se muestra a
continuación:
FPCU = Σ (Caso de Uso i* Factor de Peso i) FPCU = (5*22) + (10*12) + (15*8)
FPCU = 110 + 120 + 120
FCPU = 350
Con los datos de FPA y FPCU obtenidos se puede determinar que:
PCU = 33 + 350 = 383
2.11.2. Calcular los Puntos de Casos de Usos Ajustados (PCUA)
Una vez que se tienen los Puntos de Casos de Uso sin ajustar, se debe ajustar este valor mediante
la siguiente ecuación:
PCUA = PCU x FCT x FA
Donde
PCUA: Puntos de Casos de Uso ajustados
PCU: Puntos de Casos de Uso sin ajustar
FCT: Factor de complejidad técnica
FA: Factor de ambiente
Calcular el Factor de Complejidad Técnica (FCT)
SIGAU. Capítulo II
51
Este coeficiente se calcula mediante la cuantificación de un conjunto de factores que determinan la
complejidad técnica del sistema. Cada uno de los factores se cuantifica con un valor de 0 a 5, donde
0 significa un aporte irrelevante y 5 un aporte muy importante. En la siguiente Tabla 10 se muestran
los factores tenidos en cuenta y el peso de cada uno de estos:
Tabla 10: Factores de Complejidad Técnica.
Factor Descripción Peso
1 Sistema distribuido. 2
2 Objetivos de performance o tiempo de respuesta. 1
3 Eficiencia del usuario final. 1
4 Procesamiento interno complejo. 1
5 El código debe ser reutilizable. 1
6 Facilidad de instalación. 0.5
7 Facilidad de uso. 0.5
8 Portabilidad. 2
9 Facilidad de cambio. 1
10 Concurrencia. 1
11 Incluye objetivos especiales de seguridad. 1
12 Provee acceso directo a terceras partes. 1
13 Se requieren facilidades especiales de entrenamiento a usuarios. 1
El FCT se calcula mediante la siguiente ecuación:
FCT = 0.6 + 0.01 x Σ (Pesoi x Valor asignadoi)
Haciendo un análisis de lo que plantea cada factor a medir y las características del sistema que se
pretende realizar se asignaron los siguientes valores a cada factor (Tabla 11):
Tabla 11: Valores asignados a los factores de complejidad técnica.
Factor Valor asignado Valor asignado * Peso
1 0 (El sistema no es distribuido; es
totalmente centralizado)
0 * 2 = 0
2 3 (El sistema debe responder rápidamente a
los pedidos de los clientes pero no es algo
que sea totalmente importante)
3 * 1 = 3
SIGAU. Capítulo II
52
3 3 (Los clientes no tienen por qué ser
eficientes)
3 * 1 = 3
4 4 (No existe un procesamiento complejo, no
se efectúan operaciones complejas)
4 * 1 = 4
5 5 (Se desea que el código sea lo más
reutilizable posible por las magnitudes que
puede alcanzar el software)
5 * 1 = 5
6 3 (Se desea que el proceso de instalación
no sea tan complejo puesto que una vez
terminado el software pueden aparecer
nuevos compradores)
3 * 0.5 = 1.5
7 4 (El software debe ser muy fácil de usar ya
que los clientes no siempre tienen dominio
sobre el trabajo con sistemas informáticos)
4 * 0.5 = 2
8 4 (A los usuarios del sistema no les interesa
cambiar de sistema operativo)
4 * 2 = 8
9 4 (El sistema debe ser muy fácil de cambiar
ya que pueden aparecer nuevas
funcionalidades)
4 * 1 = 4
10 5 (Puede existir gran cantidad de usuarios
realizando una operación en un instante)
5 * 1 = 5
11 4 (Para la realización de transacciones debe
existir un conjunto especial de medidas de
seguridad)
4 * 1 = 4
12 3 (Provee servicios web a otros sistemas de
información)
3 * 1 = 3
13 3 (Se requieren facilidades especiales de
entrenamiento a usuarios.)
3 * 1 = 3
Una vez obtenidos estos valores, se puede calcular el valor de FCT que viene dado por:
FCT =0.6 + 0.01 * Σ (Pesoi x Valor asignadoi)
FCT = 0.6 + 0.01 * (0 + 3 + 3 + 4 + 5 + 1.5 + 2 + 8 + 4 + 5 + 4 + 3 + 3)
FCT = 0.6 + 0.01 * 45.5
SIGAU. Capítulo II
53
FCT = 0.6 +0.455
FCT = 1.055
Calcular el Factor de Ambiente (FA)
Las habilidades y el entrenamiento del grupo involucrado en el desarrollo tienen un gran
impacto en las estimaciones de tiempo. Estos factores son los que se contemplan en el
cálculo del FA. El cálculo del mismo es similar al cálculo del FCT, es decir, se trata de un
conjunto de factores que se cuantifican con valores de 0 a 5.
En la Tabla 12 se muestra el significado y el peso de cada uno de estos factores:
Tabla 12: Factores de Ambiente o Entorno.
Factor Descripción Peso
1 Familiaridad con el modelo de proyecto utilizado. 1.5
2 Experiencia en la aplicación. 0.5
3 Experiencia en la orientación a objetos. 1
4 Capacidad del analista líder. 0.5
5 Motivación. 1
6 Estabilidad de los requerimientos. 2
7 Personal a tiempo parcial. -1
8 Dificultad del lenguaje de programación. -1
El Factor de ambiente se calcula mediante la siguiente ecuación:
FA =1.4 - 0.03 x Σ (Pesoi x Valor asignadoi)
Haciendo un análisis de lo que plantea cada factor a medir, las características del equipo de
desarrollo y de la solución a desarrollar se asignaron los siguientes valores a cada factor, ver Tabla
13:
Tabla 13: Valores asignados a los factores de ambiente.
Factor Valor asignado Valor asignado * Peso
1 4 4 * 1.5 = 6
2 2 2 * 0.5 = 1
3 4 4 * 1 = 4
SIGAU. Capítulo II
54
4 3 3 * 0.5 = 1.5
5 5 5 * 1 = 5
6 3 3 * 2 = 6
7 0 0 * -1 = 0
8 0 0 * -1 = 0
Una vez obtenidos estos valores, se puede obtener el valor de FCT que viene dado por:
FA = 1.4 + 0.03 * (6 + 1 + 4 + 1.5 + 5 + 6 + 0 + 0)
= 1.4 + 0.705 = 2.105
En estos momentos se cuenta con los valores de PCU, FCT y FA y por tanto se puede calcular el
valor de PCUA el cual viene dado en este caso por:
PCUA = 383 * 1.055 * 2.105 = 1250
2.11.3. Calcular el Esfuerzo de desarrollo (E)
El esfuerzo en horas-hombre viene dado por:
E = PCUA x FC
Donde:
E: esfuerzo estimado en horas-hombre.
PCUA: Puntos de Casos de Uso ajustados.
FC: Factor de conversión. Para el cálculo del FC se siguen los siguientes pasos:
1. Se contabilizan cuántos factores de los que afectan al FA están por debajo del valor medio
(3), para los factores 1 al 6.
2. Se contabilizan cuántos factores de los que afectan al FA están por encima del valor medio
(3), para los factores 7 y 8.
3. Si el total es 2 o menos, se utiliza el factor de conversión 20 horas-hombre/PCU, es decir, un
PCU toma 20 horas-hombre.
4. Si el total es 3 o 4, se utiliza el factor de conversión 28 horas-hombre/PCU, es decir, un PCU
toma 28 horas-hombre.
5. Si el total es mayor o igual que 5, se recomienda efectuar cambios en el proyecto, ya que se
considera que el riesgo de fracaso del mismo es demasiado alto.
SIGAU. Capítulo II
55
Se debe tener en cuenta que este método proporciona una estimación del esfuerzo en horas-hombre
contemplando sólo el desarrollo de la funcionalidad especificada en los casos de uso.
Finalmente, para una estimación más completa de la duración total del proyecto, hay que agregar a
la estimación del esfuerzo obtenida por los Puntos de Casos de Uso, las estimaciones de esfuerzo
de las demás actividades relacionadas con el desarrollo de software.
Para ello se puede tener en cuenta el siguiente criterio, que estadísticamente se considera
aceptable, el cual plantea la distribución del esfuerzo entre las diferentes actividades de un proyecto
como se muestra en la Tabla 14:
Tabla 14: Distribución del Esfuerzo.
Actividad Porcentaje
Análisis 10 %
Diseño 20 %
Implementación 40 %
Pruebas 15 %
Sobrecarga (otras actividades) 15 %
Para este caso, y siguiendo los criterios que existen para el FC se tomó 20 como valor del mismo y
por tanto:
E = 1250* 20 = 25000 Horas-Hombre
Este esfuerzo es el que se requiere para la implementación. Si se tiene en cuenta que este
representa un 40 % del esfuerzo total para desarrollar el software entonces tenemos que el esfuerzo
total es el siguiente:
E (Total) = E / 0.4 = 63500 Horas-Hombre
La Tabla 15 muestra el esfuerzo necesario para cada actividad del proyecto siguiendo los
porcentajes especificados en la tabla anterior:
Tabla 15: Esfuerzo necesario.
Actividad Horas hombre
Análisis 6350
Diseño 12700
Implementación 25400
Pruebas 9525
SIGAU. Capítulo II
56
Sobrecarga (otras actividades) 9525
Total 63500
2.11.4. Estimación del tiempo de desarrollo del proyecto
El tiempo de desarrollo aproximado del proyecto (TDes) se calcula de la siguiente manera:
TDes = E (Total)/CH
Donde:
E (Total): Esfuerzo total
CH: Es la cantidad de hombres que desarrollan el proyecto.
TDes = 63500 HH / 2 Hombres = 31750 Horas
2.11.5. Estimación del costo de desarrollo del proyecto
Una vez estimado el tiempo de desarrollo del proyecto y conociendo la cantidad de desarrolladores
y el pago que recibe cada uno de estos se puede llevar a cabo una estimación del costo total del
proyecto referidos a los recursos humanos. El costo por concepto de desarrolladores viene dado
por:
C = E (Total) * CH * TH
TH: Tarifa Horaria. El salario promedio de las personas que trabajan en el proyecto dividido entre
160 horas.
El salario promedio de los 2 desarrolladores es de $600 y por tanto TH = 600 / 160 = 3.75
Entonces:
C = 63500 * 2 * 3.75 = $476250
SIGAU. Capítulo IV
57
Capítulo III. Descripción de la propuesta de solución
En el presente capítulo se expone la propuesta de solución de la arquitectura del sistema, así como
los diagramas de clases del diseño y de secuencia de los casos de uso significativo. También, se
presenta el diseño de la base de datos con el modelo conceptual y el modelo físico de los datos, el
tratamiento de errores y el diagrama de despliegue con los principales componentes del sistema.
3.1. Arquitectura del Sistema
Según (Potencier & Zaninotto, 2012), symfony está basado en un patrón clásico del diseño web
conocido como arquitectura MVC, que está formado por tres niveles como se muestra en la Figura
10:
1. El modelo representa la información con la que trabaja la aplicación, es decir, su lógica de
negocio.
2. La vista transforma el modelo en una página web que permite al usuario interactuar con ella.
3. El controlador se encarga de procesar las interacciones del usuario y realiza los cambios
apropiados en el modelo o en la vista.
Figura 10: El patrón Modelo Vista Controlador.
SIGAU. Capítulo IV
58
3.2. Diagrama de clases de diseño (CU Significativos)
Un Diagrama de Clases de Diseño muestra la especificación para las clases de una aplicación.
Incluye: clases, asociaciones y atributos, interfaces con sus operaciones y constantes, métodos,
navegabilidad y dependencias. A diferencia del Modelo Conceptual, un Diagrama de Clases de
Diseño muestra definiciones de entidades software más que conceptos del mundo real (Anon.,
2018).
En la Figura 11 se puede ver el diagrama de clases para el CU Gestionar Ausencias. Se observa
que la clase controladora construye la vista del listado de ausencias. Desde esta vista se pueden
hacer link hacia las vistas de adicionar y modificar ausencias, ambas vistas están compuestas por
el formulario de datos el cuál envía su información hacia la controladora. Es la controladora la
encargada de interactuar con la entidad de la base de datos.
Figura 11 Diagrama de clases de Gestionar Ausencias.
En la Figura 12 se muestra el diagrama de clases para el CU Cargar Trabajador, el mismo está
compuesto por la clase controladora que construye la vista de cargar trabajador, esta además está
compuesta por el formulario de datos que envía su información hacia la controladora. La
controladora del trabajador tiene una relación de dependencia con la clase trabajador.
SIGAU. Capítulo IV
59
Figura 12 Diagrama de clases de Cargar Trabajador
En la Figura 13 se observa el diagrama de clases para el CU significativo Gestionar Presupuesto
CUC que tiene un comportamiento similar a los explicados anteriormente.
SIGAU. Capítulo IV
60
Figura 13 Diagrama de clases de Gestionar Presupuesto CUC
3.3. Diagrama de secuencia (CU Significativos)
Un diagrama de secuencias muestra la interacción de un conjunto de objetos de una aplicación a
través del tiempo, en el cual se indicarán los módulos o clases que formarán parte del programa y
las llamadas que se hacen cada uno de ellos para realizar una tarea determinada, por esta razón
permite observar la perspectiva cronológica de las interacciones. Es importante recordar que el
diagrama de secuencias se realiza a partir de la descripción de un caso de uso (MOLINA, 2018).
Gestionar Ausencias: Adicionar
En este CU el actor Jefe de Departamento Docente es quien lo inicia, cuando selecciona la opción
Reporte de Pago/ Ausencias en la pantalla principal lo que provoca un enlace (link) hacia la
controladora. Luego la controladora construye (build) la vista con el listado de las ausencias y es ahí
donde el actor puede seleccionar la opción adicionar y con ello un enlace (link) hacia la vista de
adicionar que está compuesta por el formulario de datos, es ahí donde el actor introduce los datos
que serán enviados (submit) a la controladora. En la controladora está programado el método para
adicionar los datos a la base de datos finalizando el proceso con su inserción satisfactoria. Ver Figura
14.
SIGAU. Capítulo IV
61
Figura 14: Diagrama de Secuencia para el Caso de Uso Gestionar Ausencias (Adicionar).
Cargar Trabajador
Para este CU el actor Técnico en Recursos Humanos es quien lo inicia y se comporta de manera
similar al anterior descrito. Ver Figura 15.
Figura 15: Diagrama de Secuencia para el Caso de Uso Cargar Trabajador.
Gestionar Presupuesto CUC: Adicionar
SIGAU. Capítulo IV
62
En la Figura 16 se muestra el diagrama de secuencia correspondiente al CU Gestionar Presupuesto
CUC el cual es iniciado por el actor Jefe de Departamento Administrativo.
Figura 16: Diagrama de Secuencia para el Caso de Uso Gestionar Presupuesto CUC (Adicionar).
3.4. Tratamiento de errores
La validación de formularios se puede realizar en el lado del servidor y/o en el lado del cliente. La
validación en el servidor es obligatoria para no corromper la base de datos con datos incorrectos.
La validación en el lado del cliente es opcional, pero mejora enormemente la experiencia de usuario.
La validación en el lado del cliente debe realizarse de forma manual con JavaScript. A continuación
se muestra un ejemplo en la Figura 17 de cómo se valida en la aplicación web.
SIGAU. Capítulo IV
63
Figura 17: Vista de la Aplicación, sección de gestionar sábados laborables.
3.5. Diseño de la base de datos
El diseño de una base de datos consiste en definir la estructura de los datos que debe tener un
sistema de información determinado. Para ello se suelen seguir por regla general unas fases en el
proceso de diseño, definiendo para ello el modelo conceptual, el lógico y el físico (KRASIS
CONSULTING, S.L., 2014).
3.5.1. Modelo conceptual de datos
En el diseño conceptual se hace una descripción de alto nivel de la estructura de la base de datos,
independientemente del SGBD (Sistema Gestor de Bases de Datos) que se vaya a utilizar para
manipularla. Su objetivo es describir el contenido de información de la base de datos y no las
estructuras de almacenamiento que se necesitarán para manejar dicha información (KRASIS
CONSULTING, S.L., 2014).
Debido a la complejidad del modelo conceptual de la base de datos se decidió dividir el mismo en
tres segmentos donde se modelan las entidades más significativas como se muestra a continuación.
SIGAU. Capítulo IV
64
En la Figura 18 se puede ver el segmento correspondiente al CU Gestionar Presupuesto CUC.
Figura 18: Segmento del modelo conceptual de la base de datos para CU Gestionar Presupuesto
CUC.
En la Figura 19 se muestra el segmento del modelo para el CU Cargar Trabajador.
SIGAU. Capítulo IV
65
Figura 19: Segmento del modelo conceptual de la base de datos para CU Cargar Trabajador.
La Figura 20 muestra el segmento del modelo conceptual para el CU Gestionar Ausencias
Figura 20: Segmento del modelo conceptual de la base de datos para CU Gestionar Ausencias.
SIGAU. Capítulo IV
66
3.5.2. Modelo físico de datos
El diseño físico parte del lógico y da como resultado una descripción de la implementación de una
base de datos en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados
para tener un acceso eficiente a los datos. Aquí el objetivo es conseguir una mayor eficiencia, y se
tienen en cuenta aspectos concretos del SGBD sobre el que se vaya a implementar. Por regla
general esto es transparente para el usuario, aunque conocer cómo se implementa ayuda a
optimizar el rendimiento y la escalabilidad del sistema (KRASIS CONSULTING, S.L., 2014).
A continuación, la siguiente Figura 21 muestra el modelo físico de los datos:
Figura 21: Modelo físico de la base de datos
SIGAU. Capítulo IV
67
3.6. Modelo de componentes
El modelo de componentes ilustra los componentes de software que se usarán para construir el
sistema. Se pueden construir a partir del modelo de clases y escribir desde cero para el
nuevo sistema o se pueden importar de otros proyectos y de productos de terceros. Los
componentes son agregaciones de alto nivel de las piezas de software más pequeñas y
proveen un enfoque de construcción de bloques de “caja negra” para la elaboración del
software (Sparks, 2001).
El diagrama de componente que muestra la Figura 22 demuestra cómo está dividido el caso de uso
Gestionar Ausencias, Adicionar. Dentro de los componentes físicos están incluidos archivos .js, .ccs
y .php.
Gestionar Ausencias: Adicionar
Figura 22: Diagrama de componentes para CU Gestionar Ausencias.
En la Figura 23 se muestra el modelo de componentes del sistema para el CU Cargar Trabajador.
SIGAU. Capítulo IV
68
Cargar Trabajador
Figura 23: Diagrama de componentes para CU Cargar Trabajador.
En la Figura 24 se muestra el modelo de componentes del sistema para el CU Gestionar
Presupuesto CUC.
Gestionar Presupuesto CUC: Adicionar
SIGAU. Capítulo IV
69
Figura 24: Diagrama de componente para CU Gestionar Presupuesto CUC.
3.7. Diagrama de despliegue
El diagrama de despliegue muestra cómo el sistema se asentará físicamente en el entorno hardware
que lo acompaña. Su propósito es mostrar dónde los componentes del sistema se ejecutarán y cómo
se comunicarán entre ellos (Palomo & Gil, 2014).
La Figura 25 muestra el diagrama de despliegue del sistema el cual cuenta con 5 nodos, el nodo
Servidor que es donde se encuentran los paquetes de componentes del sistema con sus relaciones
de dependencia con el paquete de servicio y con el servidor apache. El nodo PC Usuarios representa
las computadoras clientes que se conectarán mediante HTTP con el servidor y dentro el componente
navegador, este nodo se comunica además con el nodo Impresora a través de un puerto USB. Los
nodos Servidor de Base de Datos (BD) y Servidor Data Center se comunican mediante TCP/IP con
el nodo Servidor.
SIGAU. Capítulo IV
70
Figura 25: Diagrama de Despliegue
3.8. Conclusiones parciales del capítulo.
En este capítulo se definen elementos fundamentales en el proceso de elaboración de la herramienta
partiendo de la arquitectura usada en la aplicación, una descripción de las fundamentales clases del
diseño y el manejo de errores implementado. También se abordan modelos fundamentales como
los modelos del diseño de la base de datos y el de componentes, finalizando con la distribución del
sistema una vez realizada la herramienta como propuesta de solución.
SIGAU. Capítulo IV
71
Capítulo IV. Pruebas y análisis de factibilidad
En el presente capítulo se describe la estrategia de pruebas a realizar y se muestran los resultados
de las mismas aplicadas a la herramienta informática desarrollada con el objetivo de validar sus
funcionalidades.
4.1. Casos de Pruebas (caja negra)
Un caso de prueba según (Jiménez, 2016), en la ingeniería del software, es un conjunto de
condiciones o variables bajo las cuales un probador determina si una aplicación, sistema de software
o una de sus características está funcionando como se estableció originalmente para que lo haga.
La técnica de pruebas de caja negra, consiste en ver el programa que queremos probar como una
caja negra despreocupándonos del comportamiento interno y concentrando el esfuerzo en encontrar
el comportamiento incorrecto, de acuerdo a las especificaciones de dicho programa, teniendo solo
en cuenta las entradas y salidas de dicho programa (Peño, 2015).
En este caso se le va a realizar las pruebas de caja negra al CU Adicionar Gasto, la Figura 26
muestra la interfaz gráfica del sistema para la introducción de datos.
SIGAU. Capítulo IV
72
Figura 26: Interfaz gráfica para introducir los datos.
Tipo: Campo de texto
Concepto: Campo de texto
Importe: Campo numérico
La Tabla 16 muestra las condiciones de entrada, el tipo, las clases válidas y no válidas para cada
una de estas condiciones de entrada.
Tabla 16: Condiciones de entrada
Condición de
entrada
Tipo Clases válidas Clases inválidas
Tipo Valor Específico 1. Cualquier cadena de texto
2. En blanco
Concepto Valor Específico 3. Cualquier cadena de texto
4. En blanco
Importe Valor Específico 5. Cualquier número decimal
6. En blanco 7. Cadena de texto
SIGAU. Capítulo IV
73
8. Cadena con números y texto
A continuación en la Tabla 17 se muestran las pruebas correspondientes al CU Adicionar Gasto.
Tabla 17: Casos de prueba para el CU Adicionar Gasto
Condición de
Entrada
Casos de
Prueba
Clases Resultado
Tipo Comprar
café.
1, 3, 5
Concepto Para una
visita de la
nación.
Importe 35.25
Tipo 2, 4, 6
Concepto
Importe
Tipo Comprar
café.
2,4,7
Concepto Para una
visita de la
nación.
Importe Jkal
Tipo Comprar
café.
2,4,8
SIGAU. Capítulo IV
74
Concepto Para una
visita de la
nación.
Importe 41kah
4.2. Plan de pruebas de rendimiento
Las Pruebas de Rendimiento se ejecutan tanto para determinar como responde un sistema ante una
cierta carga, como para validar otros atributos relacionados con la calidad, como pueden ser la
escalabilidad, la fiabilidad o el uso de recursos entre otros. Existen distintos tipos de pruebas de
rendimiento como son de carga, stress y resistencia.
A continuación se muestran los resultados de tres pruebas realizadas al sistema con la herramienta
JMeter las cuales son carga, stress y resistencia. Se utilizó como Banco de Trabajo un Servidor
Proxy HTTP mediante el puerto 8080 tomando como controlador objetivo un Plan de Pruebas
utilizando un Grupo de Hilos. Para los parámetros de muestra HTTP se seleccionó un cliente tipo
HTTP. Se realizaron en una Laptop con procesador Intel(R) Core(TM) i3-5010U CPU @2.10GHz
teniendo una memoria RAM de 6Gb y sistema operatio Winwos10 de 64bits.
Pruebas de Carga
Según (Medina, 2014) el objetivo de una prueba de carga es evaluar el comportamiento del sistema
bajo una cantidad de peticiones determinadas por segundo. Este número de peticiones, a nivel
básico, puede ser igual que el número de usuarios concurrentes esperados en la aplicación, más
unos márgenes. Los datos a recopilar son principalmente dos: tiempo de respuesta de la aplicación
y respuestas erróneas. La ejecución de una prueba de carga, por tanto, consiste en seleccionar un
número de usuarios simultáneos estimados y medir los parámetros elegidos en una serie de
repeticiones de la prueba, determinando si se mueven en umbrales aceptables de rendimiento.
En la Figura 27 se muestra el resultado de la de carga para el sistema con el Apache JMeter donde
se han estimado 200 usuarios con una petición por segundo. Se puede observar el resultado de la
prueba que en la columna Error el sistema obtuvo un total de 0.00% teniendo un tiempo de
Rendimiento entre 1.2/sec y 1.4/sec, es decir no presenta errores en su funcionamiento y presenta
un tiempo rápido de respuesta.
SIGAU. Capítulo IV
75
Figura 27: Resultado de una prueba de carga.
Pruebas de Stress
Expresa (Medina, 2014) que las pruebas de stress, a diferencia de las pruebas de carga, tienen por
objetivo determinar el punto de ruptura del servicio y analizar sus causas que suelen estar derivadas
de problemas que suceden ante condiciones muy elevadas de carga: mala escalabilidad,
agotamiento de capacidad, fugas de memoria, condiciones de carrera, etc. La prueba de stress se
inicia con un número bajo de usuarios que se duplican ciclo a ciclo hasta que se determina el punto
de ruptura del servicio. Se pueden simular peticiones continuas para aumentar la carga.
En la Figura 28 se muestra el resultado de una prueba de stress para el sistema con el Apache
JMeter donde se ha estimado un usuario con 200 peticiones por segundo. Se puede observar el
resultado de la prueba que en la columna Error el sistema obtuvo resultado total de 0.00% teniendo
un tiempo de Rendimiento de 22.4/min, es decir no presenta errores en su funcionamiento y presenta
un retraso en el tiempo debido a las peticiones por segundo.
SIGAU. Capítulo IV
76
Figura 28: Resultado de una prueba de stress.
Pruebas de Resistencia (SOAK)
Las pruebas de resistencia, también llamadas de estabilidad, son una variante de las pruebas de
carga. Su objetivo es determinar el comportamiento de la aplicación a lo largo del tiempo y evaluar
la degradacion del rendimiento derivada del uso sostenido (Medina, 2014).
En la Figura 29 se muestra el resultado de una prueba de carga para el sistema con el Apache
JMeter donde se han estimado 25 usuarios haciendo 25 peticiones por segundo cada usuario. Se
puede observar el resultado de la prueba que en la columna Error el sistema tuvo un resultado total
de 0.00% teniendo un tiempo de Rendimiento entre 53.0/min y 55.0/min, es decir no presenta errores
en su funcionamiento y presenta un retraso en el tiempo debido a la carga del sistema en usuarios
y en peticiones por segundo.
SIGAU. Capítulo IV
77
Figura 29: Valores correspondiente a la prueba de resistencia.
4.3. Conclusiones parciales del capítulo.
En este capítulo se aplicaron las pruebas de caja negra al sistema, chequeando las diferentes
entradas y los errores que estas pueden causar y la respuesta del sistema ante estos errores.
También se le realizaron pruebas de rendimiento como son las de carga, stress y resistencia
obteniendo en cada una de ellas un error de 0.00% y un tiempo de respuesta pequeño teniendo en
cuenta las características de la Laptop donde se ejecutaron.
SIGAU. Conclusiones
78
Conclusiones
Como resultado de esta investigación se obtuvo una nueva versión del sistema información para la
administración de facultades que incluye los módulos de Recursos Humanos y Economía para la
gestión de los procesos administrativos en la Universidad Central “Marta Abreu” de Las Villas,
cumpliéndose de esta forma los objetivos planteados, ya que:
Se diseñó la base de datos del sistema que incluye la información de los procesos
Recursos Humanos y Economía.
Se implementó una interfaz web utilizando Symfony3, como framework de desarrollo php
y otras librerías, para realizar de forma ágil e interactiva tareas como la solicitud y
liquidación de dietas, solicitudes de transporte y alimentación, el registro de vales de pago
menor, entre otras.
Se realizaron las pruebas de caja negra y de rendimiento a la herramienta, obteniendo
resultados satisfactorios para las entradas seleccionadas.
SIGAU. Conclusiones
79
Recomendaciones
A partir del desarrollo de la herramienta se recomienda:
Revisar las políticas de seguridad relacionadas con el ASSET de manera tal que la
actualización de informaciones como listados de trabajadores y AFT se hagan de manera
automática dado que la necesidad de acceso es solo de lectura.
SIGAU. Bibliografía
80
Referencias Bibliográficas
1. Alonso, F., Martínez, L. & Segovias, F. J., 2005. Introducción a la Ingeniería del
Software: Modelos de desarrollo. s.l.:s.n.
2. Anon., 2002. PostgreSQL 7.3.2 Programmer’s Guide. s.l.:s.n.
3. Anon., 2018. Universidad Nacional Abierta y a Distancia. [En línea]
Available at:
http://stadium.unad.edu.co/ovas/10596_9836/diagrama_de_clases_de_diseo.html
4. Arias, Á. & Durango, A., 2016. Ingeniería y Arquitectura del Software. 2 ed. s.l.:s.n.
5. Aspel-PROD, s.f. Sistema de Control de Producción. [En línea]
Available at: http://www.aspel.com.mx/productos/prod/presentacion.html
[Último acceso: 16 febrero 2018].
6. Assets S.A, s.f. Sistema de Gestión Integral ASSETS. [En línea]
Available at: http://www.assets.co.cu/assets.asp
[Último acceso: 13 Febrero 2018].
7. Bakken, S. S. y otros, 1997. Manual de PHP. s.l.:s.n.
8. Dharwiyanti, S. & Wahono, R. S., 2003. Pengantar Unified Modeling Language
(UML). s.l.:s.n.
9. Drupal.org, s.f. Drupal. [En línea]
Available at: https://www.drupal.org/
[Último acceso: 15 febrero 2018].
10. EllisLab, s.f. CodeIgniter Web Framework. [En línea]
Available at: https://codeigniter.com/
[Último acceso: 15 febrero 2018].
11. eZ Publish, s.f. eZ Publish. [En línea]
Available at: https://ez.no/es
[Último acceso: 15 febrero 2018].
12. Franklin, J. & Devlin, I., 2013. Beginning JQuery. s.l.:Springer.
13. Gallego Vázquez, J. A., 2003. Desarrollo Web con PHP y MyAQL. Madrid: s.n.
14. Gallego Vázquez, J. A., 2003. Desarrollo Web con PHP y MySQL. Madrid: s.n.
SIGAU. Bibliografía
81
15. Gauchat, Juan Diego, 2012. El gran libro de HTML5, CSS3 y Javascript.
s.l.:Marcombo.
16. GestiónPYME, s.f. GestiónPYME. [En línea]
Available at: http://www.gestionpyme.net/
[Último acceso: 16 febrero 2018].
17. Hernández Castro, J. A., 2017. Sistema de Información para la Administración de
Facultades, s.l.: s.n.
18. Hitpass, B., s.f. BPM: Bussines Process Management: Fundamentos y Conceptos de
Implementación. 4 ed. s.l.:s.n.
19. Jacobson, I., Booch, G. & Rumbaugh, J., s.f. El Proceso Unificado de Desarrollo de
Software. s.l.:s.n.
20. Jacobson, I., Spence, I. & Bittner, K., 2013. CASOS DE USO 2.0. La guia para ser
exitoso con los casos de uso. s.l.:s.n.
21. Javier Eguíluz Pérez, 2008. Introducción a CSS. s.l.:s.n.
22. Jiménez, J. L. Á., 2016. El ciclo de vida del desarrollo de aplicaciones. Quinta ed.
s.l.:ELEARNING S.L.
23. Kohana, s.f. Kohana: The Swift PHP Framework. [En línea]
Available at: https://kohanaframework.org/
[Último acceso: 15 febrero 2018].
24. KRASIS CONSULTING, S.L., 2014. Campus MVP. [En línea]
Available at: https://www.campusmvp.es/recursos/post/Disenando-una-base-de-
datos-en-el-modelo-relacional.aspx
[Último acceso: 5 Mayo 2018].
25. Kubbos, s.f. Software de Gestión y facturación. [En línea]
Available at: http://www.kubbos.com/
[Último acceso: 16 febrero 2018].
26. Laravel, s.f. Laravel. [En línea]
Available at: https://laravel.com
[Último acceso: 15 febrero 2018].
27. Medina, J., 2014. Pruebas de Rendimiento TIC. s.l.:[S.l.] : LULU PRESS INC.
SIGAU. Bibliografía
82
28. Microsoft Dynamics, s.f. Software y soluciones comerciales para empresas. [En línea]
Available at: https://www.microsoft.com/es-xl/dynamics365/home
[Último acceso: 16 febrero 2018].
29. MOLINA, K. E. C., 2018. Portafolio Digital ESPAM MFL. [En línea]
Available at: https://ingsotfwarekarlacevallos.wordpress.com/2015/07/07/uml-
diagrama-de-secuencia/
30. Mueras, I. R. M., 2005. Modelo de Negocio y Análisis de Requerimientos Basado en
el Proceso Unificado.. INGENIUM Nª 03.
31. OroCRM, s.f. OroCRM - Open Source CRM Software. [En línea]
Available at: https://oroinc.com/orocrm/
[Último acceso: 15 febrero 2018].
32. Palomo, S. R. G. & Gil, E. M., 2014. Aproximación a la Ingeniería del Software.
s.l.:CENTRO DE ESTUDIOS RAMÓN ARECES. S.A..
33. Peño, J., 2015. Pruebas de Software. Fundamentos y técnicas. s.l.:s.n.
34. Pérez, J. E., s.f. Introducción a JavaScript. s.l.:s.n.
35. phpBB, s.f. phpBB. [En línea]
Available at: https://www.phpbb.com/
[Último acceso: 15 febrero 2018].
36. Piwik PRO, s.f. Piwik PRO: Enterprise Analytics and Customer Data Platform. [En
línea]
Available at: http://www.piwik.pro/
[Último acceso: 15 febrero 2018].
37. Potencier, F. & Zaninotto, F., 2012. symfony. s.l.:s.n.
38. SAIT, s.f. Sistema Administrativo Integrado Descentralizado. [En línea]
Available at: https://www.sait.mx/
[Último acceso: 16 febrero 2018].
39. SAP, s.f. ERP System - Enterprise Resource Planning - SAP. [En línea]
Available at: https://www.sap.com/products/enterprise-management-erp.html
[Último acceso: 16 febrero 2018].
40. SensioLabs Product, s.f. Twig the flexible, fast, and secure template engine for PHP.
[En línea]
SIGAU. Bibliografía
83
Available at: http://twig.sensiolabs.org
[Último acceso: 19 febrero 2018].
41. Slim Framework, s.f. Slim a micro framework for PHP. [En línea]
Available at: https://www.slimframework.com/
[Último acceso: 15 febrero 2018].
42. Sommerville, I., 2006. Ingeniería de Software. Séptima ed. s.l.:s.n.
43. Sosa, L. A., 2010. Contar con informática. Granma, 18 Febrero.
44. Sparks, G., 2001. Introducción al UML. El Modelo de Componentes.. s.l.:s.n.
45. Spurlock, J., 2013. Bootstrap: Responsive Web Development. s.l.:O'Reilly Media,
Inc..
46. Symfony, s.f. Symfony. [En línea]
Available at: http://www.symfony.com
[Último acceso: 15 Febrero 2018].
47. Yii PHP Framework, s.f. Yii PHP Framework: Best for Web 2.0 Development. [En
línea]
Available at: http://www.yiiframework.com/
[Último acceso: 15 febrero 2018].
SIGAU. Anexos
84
Anexos
Manual de Usuario
Sistema de Información para la Gestión Administrativa Universitaria (SIGAU) es un software flexible,
amigable el cual ofrece servicios para la Gestión de los Recursos Humanos y Económica, desde el
punto de vista de los Recursos Humanos permite gestionar trabajadores, estudiantes, procedimiento
de baja de los trabajadores, reportes de pago. Económicamente posee prestaciones para la
visualización de informaciones como el estado del presupuesto en CUP y la gestión del fondo en
divisas de cada área. Ya con una visión más hacia los servicios, permite hacer solicitudes tales como
Alimentación, Alojamiento, Transporte, Mantenimiento, anticipos de pagos (dietas), vales de pagos
menores tanto de estudiantes como de trabajadores, adicionalmente modela y almacena todo lo
relacionado con las conciliaciones mensuales con la dirección económica universitaria. Todos los
servicios antes mencionados funcionan con base en un sistema de notificaciones el cual intenta
mantener al trabajador en todo momento informado del estado de su solicitud y como una de las
importantes, cuenta con la notificación salarial.
Acceso
Para las facultades como se puede observar en ¡Error! No se encuentra el origen de la referencia.
ay diferentes niveles de acceso a funcionalidades.
Tabla 18: Descripciones de roles en las facultades.
Rol Descripción
Jefe de Departamento
Administrativo y Técnicos de
Gestión Administrativa
Se encargan de gestionar el presupuesto en CUP del centro al
que pertenece, así como controlar y velar por el nivel de gastos
en las partidas en que este es desglosado. Son los encargados
de crear el reporte I-10 de cada uno de los departamentos y crear
la carta complemento el último día del mes cuando se reporten
incidencias a partir de la entrega del I-10 mensualmente, también
son los responsables de la gestión de dietas y vales de pago y la
creación de reportes de estos a finales de mes. Tendrán la
capacidad de gestionar locales en los departamentos y asignar
SIGAU. Anexos
85
activos fijos en los mismos, pudiendo nombrar responsables de
estos en el departamento para llevar el control de medios
materiales de una manera correcta. Deben establecer la fecha de
entrega del reporte de incidencias. Pueden también gestionar los
trabajadores de la facultad ya que tiene la capacidad de
actualizar sus datos en el sistema, así como darle baja del mismo.
También pueden cargar y actualizar los estudiantes de la
facultad.
Decano Es un usuario que puede visualizar toda la información de sus
trabajadores y poner ausencias a los mismos cuando así lo
estime conveniente.
Jefe de Departamento Docente Es uno de los usuarios encargados de la creación de los reportes
de incidencias del departamento y de la labor del registro de
ausencias de los trabajadores. Además puede gestionar los
locales y los trabajadores de su departamento.
Trabajador Usuario con capacidad para consultar niveles de ejecución de
presupuesto en CUP y fondos en divisas. También puede realizar
solicitudes de alimentación, transporte, mantenimiento,
alojamiento, dietas por anticipo o liquidación en dependencia de
lo planificado en su plan de trabajo individual y la disponibilidad
de ese momento. Puede consultar la información referente a su
salario a devengar y el activo fijo tangible del cual es responsable
en caso de serlo.
Las diferentes direcciones universitarias juegan un papel fundamental para el correcto
funcionamiento de la aplicación pues se encargan de la subida de informaciones claves como se
muestra en la Tabla 2:
SIGAU. Anexos
86
Tabla 19: Descripciones de roles en las direcciones
Rol Descripción
Director General de Recursos
Humanos y Técnico de Recursos
Humanos
Tienen como tarea cargar y mantener actualizados
los listados de trabajadores del centro.
Especialista Nomina Encargado de cargar la nómina de pago y la
consecuente notificación salarial.
Director de Planificación Encargado de cargar el presupuesto en CUP.
Director de Alimentación,
Residencia de Postgrado,
Transportación y Mantenimiento
Aceptan o deniegan las solicitudes de servicios
provenientes de las diferentes áreas universitarias,
de acuerdo a la disponibilidad en medios y
materiales al momento de la solicitud. Se encargan
además de la administración de las partidas del
presupuesto relacionadas con el campo de acción
en el que se desarrollan.
Funcionalidades
En la pantalla de inicio de sesión como se muestra en la Figura 30 donde cada trabajador utilizando
las credenciales propias del dominio universitario puede acceder a los diferentes servicios que ofrece
la aplicación.
Figura 30: Página de inicio de sección
La aplicación tiene cuatro páginas diferentes de portadas dependiendo del rol con el que se acceda,
la Figura 31 muestra la portada de un Jefe de Departamento Administrativo, la Figura 32 para un
SIGAU. Anexos
87
Jefe de Departamento Docente, la Figura 33 para un trabajador y la Figura 34 para el director o
decano.
En la portada para un Jefe de Departamento Administrativo se muestras los diferentes datos como
el salario neto a cobrar de cada mes vencido, el presupuesto en CUP y fondo en CUC de su centro,
la fecha de reporte de incidencia para la confección del reporte RH3 (I10) para el reporte de Profesor
a Tiempo Parcial (PTP). Además, la cantidad de ausencias e infracciones del mes actual, el salario
de los últimos tres meses, la distribución del tiempo de las ausencias del mes y puede gestionar
todos los departamentos de su centro.
Figura 31: Pagina de portada para un Jefe de Departamento Administrativo.
En la portada para un Jefe de Departamento Docente se muestras los diferentes datos como el
salario neto a cobrar de cada mes vencido, la fecha de reporte de incidencia para la confección del
SIGAU. Anexos
88
reporte RH3 (I10) de PTP. Además, se muestra el total de ausencias e infracciones del mes actual
el salario de los últimos tres meses, la distribución del tiempo de las ausencias del mes y puede
gestionar su departamento.
Figura 32: Pagina de portada para un Jefe de Departamento Docente.
En la portada para un Trabajador se muestras los diferentes datos como el salario neto a cobrar de
cada mes vencido, el presupuesto en CUP y CUC de su centro y la cantidad de solicitudes enviadas.
Además, la cantidad de ausencias e infracciones del mes actual el salario de los últimos tres meses
y la distribución del tiempo de las ausencias del mes.
SIGAU. Anexos
89
Figura 33: Pagina de portada para un Trabajador.
En la portada para un Director o Decano se muestran los diferentes datos como el salario neto a
cobrar de cada mes vencido. Además, la cantidad de ausencias e infracciones del mes actual el
salario de los últimos tres meses, las notificaciones de cumpleaños y la distribución del tiempo de
las ausencias del mes.
SIGAU. Anexos
90
Figura 34: Pagina de portada para un Director o Decano.
En la Figura 35 se muestra como cada usuario del sistema puede consultar las partidas del
presupuesto en CUP de su centro, así como el presupuesto total y sus gastos, además el icono
es un menú como se muestra en la Figura 36 para ver el presupuesto de los años anteriores.
SIGAU. Anexos
91
Figura 35: Presupuesto en CUP del centro.
Figura 36: Submenú para ver los presupuestos anteriores.
SIGAU. Anexos
92
En la Figura 37 los usuarios pueden consultar el presupuesto en CUC de su centro pero solo el Jefe
de Departamento Administrativo puede adicionar gastos en el botón como se muestra en la
Figura 38, teniendo además la posibilidad eliminar con el botón , ver Figura 39.
Figura 37: Presupuesto en CUC del centro.
SIGAU. Anexos
93
Figura 38: Formulario para adicionar un gasto al presupuesto CUC.
Figura 39: Eliminar un gasto del presupuesto en CUC.
SIGAU. Anexos
94
A esta página podrán acceder todos los trabajadores para solicitar dieta por anticipo como se
muestra en la Figura 40, Se tienen que llenar un grupo de campos obligatorios donde la fecha de
salida tiene que ser menor o igual incluida la hora que la de regreso. Luego de adicionar la dieta se
tiene que llenar el desglose como se muestra en la Figura 41.
Figura 40: Solicitar dieta por anticipo.
Figura 41: Desglose de la dieta por anticipo.
En la Figura 42 se muestra como solicitar una dieta por liquidación. Se tienen que llenar un grupo
de campos obligatorios donde la fecha de salida tiene que ser menor o igual incluida la hora que la
SIGAU. Anexos
95
de regreso. Luego de adicionar la dieta se tiene que llenar el desglose como se muestra en la Figura
41.
Figura 42: Solicitar dieta por liquidación.
En la Figura 43 se muestra la información del salario de cada trabajador en los meses de año actual
y un historial del salario neto pagado de los años anteriores.
SIGAU. Anexos
96
Figura 43: Información de la nómina de pago de cada trabajador.
El director o decano de cada centro específico puede adicionar una o varias ausencias a sus
trabajadores por cualquier clave como se muestra en la Figura 44.
Figura 44: Insertar una ausencia por parte del director o decano.
SIGAU. Anexos
97
En la Figura 45 se muestra la información del perfil de cada trabajador, como el historial de las dietas,
vales de pago menores, vales de pago referentes a las dietas y los activos fijos como su
responsabilidad material individual.
Figura 45: Perfil del trabajador.
En la Figura 46 se muestra el listado de todas las facultades, en los botones y se actualiza
y se elimina respectivamente y en el botón se adiciona una nueva facultad como se muestra en
la Figura 47, para adicionar una facultad se tiene que insertar el centro de costo, el nombre y las
siglas de la facultad y adicionalmente el departamento administrativo y el trabajador que es el
responsable del jefe departamento administrativo.
SIGAU. Anexos
98
Figura 46: Gestionar todas las facultades.
Figura 47: Adicionar una facultad.
SIGAU. Anexos
99
Esta página solo podrá acceder el Jefe de Departamento Administrativo para fijar la fecha de la
entrega del reporte de incidencia como se muestra en la Figura 48.
Figura 48: Fecha de reporte de incidencia para la confección del reporte RH3 (I10).
En la Figura 49 se muestra cómo se gestionan los sábados laborables del año por parte del
Administrador del sistema. Los iconos y son para borrar un sábado o todos los
sábados respectivamente.
SIGAU. Anexos
100
Figura 49: Gestionar los sábados laborables del año.
En la Figura 50 e Figura 51 se muestra como adicionar vales de pagos menores a los estudiantes y
trabajadores de cada centro.
Figura 50: Nuevo vale de pago a estudiantes.
SIGAU. Anexos
101
Figura 51: Nuevo vale de pago a trabajadores.
Los administradores de cada centro específico podrá ver todos los vales de pagos menores referente
a las dietas, a los trabajadores y a los estudiantes como se muestra en la Figura 52, además pueden
descargar y eliminar con los botones y respectivamente y en el caso de los vales de dietas
con el botón pueden ser la información de la dieta. En la Figura 53 se muestra el modelo de vale
de pago menor ya descargado.
SIGAU. Anexos
102
Figura 52: Listado de los vales de pagos menores.
SIGAU. Anexos
103
Figura 53: Modelo de vale de pago menor.
Los Jefe de Departamento Administrativos además pueden crear los reportes de conciliaciones
referentes a las dietas, trabajadores y estudiantes como se muestra en la Figura 54, Figura 55 e
Figura 56 respectivamente.
Figura 54: Reporte de conciliación de dietas.
SIGAU. Anexos
104
Figura 55: Reporte de conciliación de trabajadores.
Figura 56: Reporte de conciliación de estudiantes.