anÁlisis de la soluciÓn de software para apoyar...
TRANSCRIPT
ANÁLISIS DE LA SOLUCIÓN DE SOFTWARE PARA APOYAR EL
PROCESO DE GESTIÓN DE NÓMINA EN LA UNIVERSIDAD
DISTRITAL, SIGUIENDO LOS LINEAMIENTOS DEL PROCESO DE
DESARROLLO OPENUP/OAS EN SU FASES DE INICIO,
ELABORACIÓN Y CONSTRUCCIÓN
AUTORES:
LORENA ANDREA MANZANO GONZALEZ
BRANDON OLIVO TORRES SANCHEZ
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTA, D.C
MAYO 2016
ANÁLISIS DE LA SOLUCIÓN DE SOFTWARE PARA APOYAR EL
PROCESO DE GESTIÓN DE NÓMINA EN LA UNIVERSIDAD
DISTRITAL, SIGUIENDO LOS LINEAMIENTOS DEL PROCESO DE
DESARROLLO OPENUP/OAS EN SU FASES DE INICIO,
ELABORACIÓN Y CONSTRUCCIÓN
AUTORES:
LORENA ANDREA MANZANO GONZALEZ
20102020054
BRANDON OLIVO TORRES SANCHEZ
20102020098
PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO
DE SISTEMAS
DIRECTOR:
Ing. ALEJANDRO PAOLO DAZA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTA, D.C
MAYO 2016
TABLA DE CONTENIDO
CAPÍTULO 1. INTRODUCCIÓN......................................................................................... 3
CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA ...................................................... 5
CAPÍTULO 3. OBJETIVOS .................................................................................................. 6
3.1. Objetivo general .......................................................................................................... 6
3.2. Objetivos específicos ................................................................................................... 6
CAPÍTULO 4. JUSTIFICACIÓN .......................................................................................... 7
CAPÍTULO 5. MARCO DE REFERENCIA ........................................................................ 8
5.1. El Proceso OPENUP/OAS ............................................................................... 8
5.1.1. Generalidades...................................................................................... 8
5.1.2. El Método de Trabajo .......................................................................... 9
5.2. Subproceso: Gestión de requerimientos y requisitos..................................... 13
5.2.1. Los requerimientos y requisitos ........................................................ 13
5.2.2. Técnicas de Captura de Requerimientos y/o Requisitos. .................. 15
5.2.3. Construcción del documento “Visión” ............................................. 15
5.2.4. Construcción de los casos de uso ....................................................... 16
5.2.5. Construcción de los modelos de casos de uso .................................. 16
5.2.6. Construcción del Documento “Especificaciones de requisitos” ....... 16
5.2.7. Construcción del Glosario ................................................................ 17
5.3. La nómina: estructura, partes y elementos básicos. ....................................... 17
5.3.1. Retribución bruta; conceptos que conforman el salario bruto .......... 18
5.3.2. Descuentos en la nómina .................................................................. 19
5.4. Estructura Legal de la Nómina de la Universidad Distrital. ........................... 20
5.4.1. Normatividad General de la Nómina de la Universidad Distrital ...... 20
5.4.2. Funcionarios....................................................................................... 21
CAPÍTULO 6. METODOLOGÍA ....................................................................................... 28
6.1. Artefactos utilizados para la Gestión de Requerimientos y Requisitos en la
Universidad Distrital. ....................................................................................................... 29
CAPÍTULO 7. DESARROLLO DEL PROYECTO ............................................................ 31
7.1. Listado maestro de requerimientos ............................................................................ 31
7.2. Requerimientos no funcionales ................................................................................. 34
7.3. Glosario ..................................................................................................................... 35
7.4. Plan de trabajo general proyecto TITÁN- plan de iteraciones .................................. 40
7.5. Módulos propuestos para Gestión de nómina ........................................................... 41
7.5.1 Gestión persona ................................................................................................... 41
7.5.2 Gestión Parámetros ............................................................................................. 43
7.5.3 Gestión Conceptos ............................................................................................... 52
7.5.4 Gestión de Novedades .......................................................................................... 57
7.5.5 Gestión de Liquidación ........................................................................................ 59
7.5.5.3.2. Diagrama de Caso de Uso ............................................................................. 62
7.5.6 Reportes ............................................................................................................... 63
CAPÍTULO 9. RESULTADOS ........................................................................................... 68
CAPÍTULO 10. CONCLUSIONES..................................................................................... 70
CAPÍTULO 11. BIBLIOGRAFÍA ....................................................................................... 71
Anexos.................................................................................................................................. 72
INDICE DE FIGURAS
Figura 1. Estructura del Equipo de Desarrollo. Basado de: Oficina Asesora de Sistemas [7]. ........... 12
Figura 2.Artefactos OPENUP/OAS. Basado en: Oficina Asesora de Sistemas [5]. ............................. 13
Figura 3. Artefactos de la Gestión de requerimientos y requisitos. Basado de: Oficina Asesora de
Sistemas [8]. ..................................................................................................................................... 13
Figura 4. Normatividad General de la Universidad Distrital. Basado de: Oficina Asesora de Sistemas
[2]. .................................................................................................................................................... 20
Figura 5. Fórmula para Horas Extras. Basado en: [2]........................................................................ 24
Figura 6. Artefactos del Subproceso “Gestión de Requerimientos y requisitos”. Basado en: [7] .... 30
Figura 7. Pasos para el Listado Maestro de Requerimientos ............................................................ 31
Figura 8. Plan de Iteraciones Análisis Proyecto TITÁN...................................................................... 41
Figura 9. Distinción por color del equipo que realizo el análisis del módulo. ................................... 41
Figura 10. Gestión Persona .............................................................................................................. 42
Figura 11. Diagrama de Caso de Uso Gestión Persona ..................................................................... 42
Figura 12.Gestión Parámetros.......................................................................................................... 44
Figura 13. Modelo BPMN Gestión Parámetros. ............................................................................... 44
Figura 14. Diagrama de Caso de Uso Gestión Parámetros. ............................................................. 45
Figura 15. Modelo BPMN Gestión Cargo y nivel de Cargo. .............................................................. 47
Figura 16. Modelo Gestión Conceptos ............................................................................................. 52
Figura 17. Modelo BPMN Gestión Conceptos. ................................................................................. 53
Figura 18. Diagrama de Caso de Uso Conceptos .............................................................................. 53
Figura 19. Diagrama de Caso de Uso Categoría Conceptos .............................................................. 55
Figura 20. Diagrama de caso de Uso Categoría de Parámetros de Liquidación ................................ 56
Figura 21. Módulo Gestión Novedades. .......................................................................................... 57
Figura 22. Modelo BPMN Gestión vinculación persona natural. ...................................................... 58
Figura 23. Modulo Gestión Liquidación............................................................................................ 59
Figura 24. Diagrama de Caso de Uso Preliquidación. ....................................................................... 60
Figura 25. Modelo BPMN Gestión Liquidación. ................................................................................ 61
Figura 26. Diagrama de caso de uso Liquidación de nómina ............................................................ 62
Figura 27. Modulo Gestión Reportes ............................................................................................... 63
Figura 28. Modelo BPMN Gestión plantilla de reportes ................................................................... 63
Figura 29. Diagrama de Caso de Uso Plantilla Reporte. ................................................................... 64
Figura 30. Modelo BPMN Gestión de reportes. ............................................................................... 66
Figura 31. Diagrama de Caso de Uso Gestor Reporte. ..................................................................... 66
INDICE DE TABLAS
Tabla 1. Contenido para cada una de las nóminas de la Universidad Distrital. Basado de: OAS [2]. 20
Tabla 2. Fórmula, Incremento y Reliquidación para Salario Básico. Basado en: [2]. ........................ 22
Tabla 3. Fórmula, Incremento y Reliquidación para los Gastos de Representación. Basado en: [2].23
Tabla 4. Fórmula e Incremento para Prima Técnica. Basado en: [2]. .............................................. 24
Tabla 5. Listado Maestro de Requerimientos Funcionales ............................................................... 34
Tabla 6. Listado Maestro de Requerimientos No Funcionales ......................................................... 34
Tabla 7. Glosario General Proyecto TITÁN. ...................................................................................... 40
Tabla 8. Tabla de Atributos Cargo .................................................................................................... 46
Tabla 9. Atributos EPS ...................................................................................................................... 47
Tabla 10. Atributos Caja de Compensación ...................................................................................... 48
Tabla 11. Atributos ARL .................................................................................................................... 49
Tabla 12. Atributos Leyes, Normas o Decretos ................................................................................ 49
Tabla 13. Atributos Actos Administrativos ....................................................................................... 50
Tabla 14. Atributos Bancos .............................................................................................................. 50
Tabla 15. Atributos Tipo de Vinculación ........................................................................................... 51
Tabla 16. Atributos Parámetros de Liquidación ............................................................................... 52
Tabla 17. Atributos Concepto........................................................................................................... 54
Tabla 18. Atributos Categoría Conceptos ......................................................................................... 55
Tabla 19. Atributos Categoría Parámetros de Liquidación ............................................................... 56
Tabla 20. Atributos Asociación Conceptos ....................................................................................... 57
Tabla 21. Atributos Traslados ........................................................................................................... 58
Tabla 22. Atributos Retiros............................................................................................................... 58
Tabla 23. Atributos Tipo Nómina ..................................................................................................... 59
Tabla 24. Atributos Preliquidación ................................................................................................... 61
Tabla 25. Atributos Liquidación ........................................................................................................ 62
Tabla 26. Atributos Plantilla Reporte ............................................................................................... 65
Tabla 27. Atributos Reportes ........................................................................................................... 67
Tabla 28. Análisis de Resultados Proyecto TITÁN ............................................................................. 69
CAPÍTULO 1. INTRODUCCIÓN
La Universidad Distrital Francisco José de Caldas es un ente autónomo de carácter estatal
cuya misión se centra en formar la persona a partir de la construcción del conocimiento y la
investigación en la búsqueda de resultados socialmente útiles [1]. Para cumplir a cabalidad
con esta función, requiere del apoyo de talento humano como docentes, administrativos y
contratistas, quienes deben tener una vinculación contractual con la Institución para que
puedan ser retribuidos monetariamente por sus servicios.
Cualquiera que sea la vinculación contractual que tenga una persona natural con la
Universidad debe efectuarse un proceso periódico de gestión de nómina integral de
liquidación de salarios, honorarios, prestaciones y aportes patronales, seguridad social,
parafiscales y prestaciones sociales según sea el caso.
Actualmente en la Institución se cuenta con varios procesos de gestión de nómina de
acuerdo al tipo de vinculación contractual existente y consecuentemente con diferentes
herramientas informáticas que soportan dichos procesos, que van desde hojas de cálculos
de Excel hasta soluciones más robustas soportadas en bases de datos Oracle [2], teniendo
como común denominador la baja flexibilidad a nuevos requerimientos legales o tributarios
del entorno externo o institucional, así como la baja interoperabilidad con otros
componentes de software requeridos para efectuar los pagos y causaciones financieras.
Para tal fin la Oficina Asesora de Sistemas (OAS) buscó mejorar y unificar el proceso de
gestión de nómina por medio del proyecto TITÁN el cual tendrá como objetivo ser una
“Solución de software para apoyar el proceso de gestión de nómina en la universidad
distrital, siguiendo los lineamientos del proceso de desarrollo OPENUP/OAS en su fase de
inicio, elaboración y construcción”. Para este proyecto se buscaron estudiantes de la
Universidad Distrital de últimos semestres pertenecientes al proyecto curricular de
Ingeniería de Sistemas, finalmente nueve personas participarán en el proyecto teniendo un
rol como: analista, arquitecto o desarrollador. Por ello, se dividió el proyecto en
subproyectos que se encargaran de:
-Gestión de requerimientos
-Arquitectura de software
-Desarrollo de software
Este proyecto formó parte del proceso de Gestión de requerimientos para plantear una
solución de software modular, integral y escalable que permitiera apoyar los procesos
relacionados a la gestión de nómina para los funcionarios(Administrativos y docentes de
planta) de la Universidad Distrital, soportado en tecnologías libres siguiendo el proceso de
4
desarrollo OPENUP/OAS. Se debe tener en cuenta que la gestión de nómina para docentes
de vinculación especial y contratistas será abordado por otros participantes del proyecto.
Con este proyecto se realizó la lista de requerimientos funcionales y no funcionales,
glosario, documento de visión, actas de trabajo, diagramas BPMN, glosario, diagramas de
casos de uso y 112 especificaciones de uso, de las cuales 42 fueron realizadas por los dos
equipos de análisis y 47 especificaciones analizadas únicamente por este equipo. También
se elaboraron prototipos de pantalla acerca de las principales funcionalidades, se realizaron
las respectivas pruebas y controles de cambios de las funciones desarrolladas y se elaboró
el manual técnico y de usuario acerca del proyecto.
5
CAPÍTULO 2. PLANTEAMIENTO DEL
PROBLEMA
A nivel mundial, las organizaciones hoy en día llevan definida la nómina de los
trabajadores que van a remunerar por la prestación de los servicios que realizan dentro de la
misma, por ello es imprescindible llevar un sistema que les permita agilizar de manera
eficaz los datos o la información que necesitan al momento de realizar el proceso que
implica la cancelación de sueldos y salarios. La nómina en la Universidad Distrital está
regida por diferentes leyes, decretos, acuerdos y resoluciones que definen los factores para
cada tipo de vinculación contractual.
La Oficina Asesora de Sistemas en el año 2013 realiza un levantamiento del proceso de
parametrización y liquidación de nómina identificando que uno de los grandes problemas es
la gran variedad de procesos y herramientas informáticas obsoletas para soportar la
liquidación de nóminas a las personas naturales que tienen algún vínculo contractual,
sumado a la baja interoperabilidad de las herramientas con otros componentes de software
proveedores o destinatarios [2]
Además, la gestión de la nómina en la Universidad para cada uno de los tipos de
vinculación (Funcionarios, docentes de vinculación especial, Contratistas) no está unificado
y se maneja de manera independiente para cada uno, obteniendo muchos tipos de nóminas
las cuales son más difíciles de controlar. Este problema es muy amplio ya que de acuerdo al
tipo de vinculación contractual se realiza el proceso de liquidación, por esto el proyecto se
enfocó en la gestión de nómina para los funcionarios (Administrativos y docentes de
planta).
Las dependencias de la Universidad Distrital manejan diferentes tipos de información que
está relacionada con la nómina y los actuales aplicativos no tienen la suficiente
interoperabilidad para esta gestión, por ende se deben realizar varias actividades de
validación para generar los respectivos informes. Además, existen varios parámetros que
son aplicables para cualquier tipo de nómina como lo son: Salario Mínimo, % de salud, %
de pensión, subsidio de alimentación, tipo de Contrato, tipo de Vinculación y tipos de
cesantía. Lo anterior crea redundancia ya que cada dependencia maneja
independientemente estos parámetros que son los mismos para las nóminas de la
Universidad Distrital.
Este problema afecta a las personas naturales que tiene alguna vinculación contractual
como Funcionario con la Universidad y los procesos de liquidación y pago de nómina,
también afecta al personal a cargo de los procesos de liquidación y pago en las áreas de la
División de Recursos Humanos y la División de Recursos Financieros
6
CAPÍTULO 3. OBJETIVOS
3.1. Objetivo general
Identificar, analizar y caracterizar las especificaciones funcionales y no funcionales
requeridas para el diseño y desarrollo de una solución de software que permitiera apoyar
los procesos relacionados a la gestión de nóminas en la Universidad Distrital, lo anterior
siguiendo los lineamientos propios del proceso de desarrollo OPENUP/OAS.
3.2. Objetivos específicos
● Representar el modelo de operación actual de los procesos relacionados con la
gestión de nóminas en la Universidad Distrital mediante la notación gráfica
estandarizada para el modelo y notación de procesos de negocio BPMN.
●Definir y ajustar las necesidades de los interesados mediante sesiones de trabajo
colaborativo para la elaboración de documentos que permitan continuar con el
desarrollo del proyecto.
●Definir y elaborar especificaciones de caso de uso que permitan esbozar las
necesidades y requerimientos de los interesados para la gestión de nómina de los
funcionarios de la Universidad Distrital.
● Documentar los artefactos propios del análisis del proceso OPENUP/OAS que
sirvan como base para el desarrollo del proyecto y permitan apoyar las siguientes
fases del mismo.
7
CAPÍTULO 4. JUSTIFICACIÓN
La Universidad Distrital no cuenta con un sistema integral, unificado y escalable que
permita soportar el proceso de gestión de nómina en la Institución de las personas naturales
que tiene algún vínculo contractual con la Universidad, es por esta razón que se hace
necesario el análisis, diseño arquitectónico y desarrollo de una solución de software que
permita unificar los diferentes tipos nóminas existentes en una sola herramienta web, cuyas
características sea una alta interoperabilidad con otros componentes de software, adaptable
a los cambios normativos y legales del entorno interno o externo y cumpla requisitos de alta
calidad en capacidades de usabilidad, fiabilidad, rendimiento y mantenimiento del software.
Para tal fin la Oficina Asesora de Sistemas (OAS) y nueve estudiantes de la Universidad
Distrital de últimos semestres pertenecientes al proyecto curricular de Ingeniería de
Sistemas participaron en el desarrollo de esta solución, cada uno ha elegido un rol en el
proyecto teniendo como opción ser analistas, arquitectos o desarrolladores.
Para que esta solución fuera exitosa se partió de identificar, analizar y caracterizar las
especificaciones funcionales y no funcionales requeridas para el diseño y desarrollo de una
solución de software modular, integral y escalable que permitiera apoyar los procesos
relacionados a la gestión de nómina de la Universidad Distrital para cualquier vínculo
contractual. En el equipo de analistas se dividió el proyecto de la gestión de nómina en dos
partes, la primera trabajó el manejo de los Funcionarios (Administrativos y Docentes de
planta) y el otro para Contratistas, y Docentes de vinculación Especial.
La ingeniería de requisitos ha sido una de las áreas de la ingeniería del software en la que
más esfuerzos de investigación se ha realizado durante las últimas décadas, y con motivo,
porque los errores de comprensión cometidos en esta etapa inicial de los proyectos son los
más costosos de resolver. Si no se detectan a tiempo, implican la realización de actividades
erróneas durante todas las fases subsiguientes, hasta llegar a las pruebas. Momento en el
que, a la vista de los defectos detectados en la ejecución de los casos de prueba, se concluye
que la repetición de las actividades erróneas puede ser una manera de resolver la situación
[3].
Los proyectos exitosos comienzan con una buena administración de requerimientos, cuánto
más efectiva sea su ejecución, mayor será el resultado en calidad y satisfacción del cliente,
realizando un acertado desarrollo del proyecto [3], la solución integral de software que se
busca debe reducir el tiempo invertido en el proceso de la liquidación de la nómina en
cualquier tipo de vinculación contractual en la Universidad y consecuentemente pagos
oportunos a los funcionarios, docentes y contratistas de la Institución. Por otro lado y por
ser un sistema altamente interoperable permitirá lograr una sincronización precisa de datos
con otros sistemas proveedores o destinatarios y armonizar la información organizacional.
8
CAPÍTULO 5. MARCO DE REFERENCIA
5.1. El Proceso OPENUP/OAS
En el marco de la resolución 461 de Rectoría del 29 de Julio de 2011, la Universidad
Distrital Francisco José de Caldas avaló el método de desarrollo OPENUP/OAS, como el
marco de trabajo institucional en el análisis, diseño, desarrollo e implementación de
productos de software al interior de la Universidad. A continuación se describen sus
principales directrices y fundamentos [4].
5.1.1. Generalidades
El proceso OPENUP/OAS es un método de trabajo que involucra un conjunto mínimo de
prácticas tendientes a guiar a un equipo de trabajo pequeño en el análisis, diseño, desarrollo
y despliegue de un producto de software. Los objetivos que persiguen son [5]:
● Promover la colaboración y compartir conocimientos alineando intereses del equipo
de trabajo y los usuarios.
● Ayudar al equipo a enfocarse en la arquitectura de forma rápida; de tal forma que se
minimicen los riesgos y se organice el desarrollo.
● Ayudar al equipo a balancear prioridades en conflicto para maximizar el valor
obtenido por los interesados en el proyecto.
● Ayudar al equipo en la evolución continua del producto para obtener
retroalimentación continua y fomentar el mejoramiento.
● Permitir a los administradores del proyecto realizar seguimientos a las avances
basados en metas e indicadores
● Permitir que los integrantes del equipo entiendan rápidamente como realizar el
trabajo para alcanzar los objetivos y metas proyectadas.
Los principios en que se enmarca el método de trabajo OPENUP/OAS son [5]:
a. Conocer a los Interesados
b. Separar el Problema de la Solución
c. Crear un conocimiento compartido del dominio
d. Usar escenarios y casos de uso para capturar requerimientos
e. Establecer y mantener contratos de prioridades
f. Realizar negociaciones que maximicen el beneficio obtenido
g. Gestionar el entorno
h. Conocer cuándo se debe parar
9
i. Mantenga un entendimiento común
j. Aprender continuamente
k. Organice alrededor de la arquitectura
l. Desarrolle su proyecto en iteraciones
m. Gestione los riesgos
n. Adopte y gestione el cambio
o. Mida el progreso objetivamente
5.1.2. El Método de Trabajo
OPENUP es un proceso iterativo con iteraciones distribuidas en cuatro fases: Inicio,
Elaboración, Construcción y Transición. Cada fase puede tener tantas iteraciones como
sean necesarias (dependiendo del grado de novedad, del dominio del negocio, la tecnología
usada, la complejidad de la arquitectura, el tamaño del proyecto y de otros factores) [6].
Así como otros procesos plantean una serie de disciplinas para ordenar flujos de trabajo,
OPENUP plantea seis disciplinas para agrupar las tareas involucradas en el desarrollo.
En la siguiente figura se muestra las disciplinas del proceso OPENUP/OAS [5]:
Figura 5. 1: Disciplinas del proceso OPENUP/OAS. Tomado de: Oficina Asesora de Sistemas. [5].
10
5.1.2.1. Fases del Proceso OPENUP/OAS
OPENUP es un proceso iterativo con iteraciones distribuidas en cuatro fases: Inicio,
Elaboración, Construcción y Transición. Cada fase puede tener tantas iteraciones como
sean necesarias (dependiendo del grado de novedad, del dominio del negocio, la tecnología
usada, la complejidad de la arquitectura, el tamaño del proyecto y de otros factores) [6].
Fase de Inicio: Primera fase del proceso, esta fase busca el alcance del proyecto donde los
interesados (stakeholders) y los integrantes del equipo de desarrollo, colaboran para
determinar el ámbito del proyecto, sus objetivos y determinar si el proyecto es viable.
Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las siguientes actividades y
resultados [5]:
Actividad Resultados
Iniciar el proyecto
Elaborar el documento Visión, el Plan General
del Proyecto y Análisis de riesgo
Planear y gestionar la
iteración
Elaborar el Plan de Iteración, evaluación de la
iteración y valoración de resultados de la
iteración
Identificar y refinar los
requerimientos y requisitos
Elaborar la especificación de casos de uso,
requisitos de soporte y casos de prueba
Llegar a un acuerdo sobre el
enfoque técnico
Elaborar el documento Bloc de Notas de la
Arquitectura
Tabla 5. 1: Fases del Proceso OPENUP/OAS. Tomado de: Oficina Asesora de Sistemas [5].
Al final de esta fase, como mínimo, el proyecto: ● Ha definido el ámbito ● Tiene un estimado inicial de los costos y el cronograma ● Ha definido y priorizado un conjunto inicial de requerimientos funcionales y no funcionales ● Ha identificado un conjunto de riesgos y haya propuesto las estrategias de mitigación. ● Ha identificado un conjunto de interesados. ● Ha creado un bosquejo de arquitectura.
Fase de Elaboración: La segunda fase dentro del ciclo de vida del proyecto. En ella los riesgos
significativos que influyen en la arquitectura son identificados y considerados.
En esta fase:
● Se obtiene un entendimiento más detallado de los requerimientos y requisitos
11
● Se diseña, implementa válida y establece la línea base de la arquitectura. ● Se mitigan los riesgos esenciales. ● Se produce un cronograma detallado. ● Se realiza una mejor estimación de costos.
Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las siguientes actividades y resultados
[5]:
Actividad Tareas/Resultados
Planear y gestionar la
iteración -Elaborar el Plan de Iteración, evaluación de la iteración y valoración de resultados de la iteración
Identificar y refinar los
requerimientos -Actualizar, depurar y aumentar el contenido de la especificación
de casos de uso, Requerimientos de soporte y Casos de prueba
Desarrollar la arquitectura
Agregar las vistas de arquitectura al documento Bloc de Notas de la
Arquitectura
Desarrollar un incremento
en la solución *Actualizar, depurar y aumentar el contenido del documento
Especificación de Diseño, Pruebas efectuadas por el Realizador *Obtener el código fuente que realiza uno o varios elementos de
diseño *Elaboración de una Construcción del Sistema que integre nuevos
elementos (componentes desarrollados, clases, etc.) *Elaborar el artefacto Registro de Pruebas que contenga los
resultados de la ejecución de las pruebas hechas por el realizador.
Probar la Solución
Construida Elaborar el artefacto Script de Prueba, Registro de Pruebas que
contenga los resultados de la ejecución de las pruebas.
Gestionar las
peticiones de cambio Actualizar, depurar y aumentar el contenido del documento Lista de
Unidades de Trabajo.
Tabla 5. 2: Fases de elaboración Proceso OpenUP/OAS. Tomado de: Oficina Asesora de Sistemas [5].
Fase de Construcción: Esta es la tercera fase del proceso, se enfoca en detallar los
requisitos y requerimientos, diseñar, implementar y probar el grueso del software y
completar el desarrollo del sistema basado en la arquitectura.
Se describen los requisitos y requerimientos restantes
Se completan en detalles los diseños, la implementación y las pruebas del software.
Se libera la primera versión operativa del software (beta) del sistema.
Las actividades de esta fase son:
1. Planificación y gestión de la iteración
12
2. Identificar y refinar requisitos y requerimientos
3. Desarrollar un incremento de solución
4. Probar la solución construida.
5.1.2.2. Roles OPENUP/OAS
Los productos de software los crean personas con diferentes intereses y competencias. Un
ambiente de grupo saludable potencia la colaboración efectiva requiriendo una cultura
compartida que fomente la creatividad y el cambio positivo [7].
Los roles son el rostro humano del proceso de desarrollo de software. Dependiendo del
número de personas que conforman el equipo de trabajo y las condiciones del proyecto una
persona puede asumir uno o varios roles.
Estructura del equipo de desarrollo
Figura 1. Estructura del Equipo de Desarrollo. Basado de: Oficina Asesora de Sistemas [7].
5.1.2.3. Artefactos del Proceso OPENUP/OAS
Un artefacto es algo producido, modificado o utilizado por una tarea. Los roles son
responsables de crear y actualizar los artefactos. Los 16 artefactos de OPENUP se
consideran esenciales y son los que debe utilizar un proyecto para capturar información
relacionada con el producto y el proyecto. Los proyectos pueden utilizar los artefactos de
OpenUP o reemplazarlos con los propios [6].
13
Figura 2.Artefactos OPENUP/OAS. Basado en: Oficina Asesora de Sistemas [5].
5.2. Subproceso: Gestión de requerimientos y requisitos.
El rol que asumimos en la pasantía es el de Analista por ello se deben tener en cuenta
ciertas actividades para la gestión de requerimientos y requisitos. En el siguiente cuadro
[10] se podrá tener en cuenta los objetivos y procedimientos para el proceso de Gestión de
requerimientos y requisitos.
El objetivo de la gestión de requerimientos es recolectar, analizar, aprobar y seguir la
evolución de los requerimientos funcionales del cliente o interesado y los requisitos del
software a través de la vida del producto y/o servicio [8].
Figura 3. Artefactos de la Gestión de requerimientos y requisitos. Basado de: Oficina Asesora de Sistemas [8].
5.2.1. Los requerimientos y requisitos
Los “Requerimientos” definen [9]:
• Lo que los grupos de interés (usuarios) necesitan
14
• Lo que el sistema debe incluir para satisfacer las necesidades de los grupos de
interés.
Los Requerimientos son el mecanismo primario para comunicar los objetivos del proyecto
a cualquiera que intervenga en el proyecto. Son la base para capturar y validar las
necesidades, administrar las expectativas, priorizar y asignar el trabajo, verificar y validar
el sistema y administrar el ámbito del proyecto [9].
El sistema debe ser desarrollado de acuerdo al comportamiento que se especifica en los
casos de uso. Sin embargo, existen requerimientos del sistema que representan un
comportamiento específico a estos se les denomina“Requisitos” tales como [9]:
• Requisitos legales o normativos, así como estándares.
• Atributos de calidad incluyendo características de uso e interacción con los usuarios,
confiabilidad, desempeño y requerimiento de soporte.
• Requisitos de interfaz que le dan capacidad al sistema para interaccionar con
sistemas externos.
• Restricciones de diseño tales como sistemas operativos, imagen institucional o de
compatibilidad con otro software.
Los requisitos se capturan de forma estructurada en el documento “Especificaciones de
Requisitos de soporte”
Los requisitos de soporte están clasificados de acuerdo al modelo FURPS+ (Funcional
(Requerimientos), características de uso e interacción con el usuario, confiabilidad,
desempeño, capacidad de soporte + restricciones). Las restricciones incluyen aquellas
relacionadas al diseño, implementación, interfaces y reglas del negocio [9].
-Los requisitos de características de uso e interacción con los usuarios Incluye aquellos
basados en factores humanos e interfaces de usuario tales como la capacidad de acceso,
estética de las interfaces y consistencia.
-Los requisitos de confiabilidad Incluye aspectos tales como la disponibilidad, exactitud,
proyección, frecuencia de fallo o recuperación del sistema en caso de fallo.
-Los requisitos de desempeño incluye requisitos de carga de información del sistema,
tiempos de respuesta del sistema y uso de recursos.
Por otro lado encontramos los requisitos asociados a las restricciones de diseño,
implementación, interfaces, físicas y reglas de negocio [3]:
• Restricciones de diseño
• Restricciones de implementación
• Restricciones de interfaz
• Restricciones físicas
• Reglas del negocio
15
5.2.2. Técnicas de Captura de Requerimientos y/o Requisitos.
Unos buenos requerimientos y requisitos inician cuando se detectan correctamente las
fuentes. Encontrar fuentes de alta calidad es una tarea importante que, afortunadamente,
requiere pocos recursos.
La fuente primaria de requerimientos son los interesados, luego es necesario identificar
otros candidatos [9]:
• Clientes
• Usuarios
• Administradores
• Equipo de Mantenimiento
• Asociados
Preguntar a cada interesado para que ellos mismos propongan a otros interesados. De esta
manera se podrán identificar rápidamente a todos los interesados de tal forma que no se
pierdan perspectivas o requerimientos importantes.
Después de que se identifiquen las fuentes de requerimientos se pueden aplicar diferentes
técnicas que sirven para capturarlos. Sin embargo, hay que tener en cuenta que la captura
de requerimientos es un proceso iterativo y que no existe una técnica única que sea
universalmente aplicable.
Algunos de los métodos de captura de requerimientos son [9]:
• Sesiones de tormentas de ideas.
• Entrevistas
• Trabajar en el ambiente objetivo
• Estudio de sistemas análogos
• Análisis de sugerencias y reportes de problemas y fallos.
• Charlas con los equipos de soporte
• Estudiar las mejoras realizadas por los usuarios
• Búsqueda de usuarios no considerados
• Conducir sesiones de trabajo en grupo y talleres.
• Mostrar los prototipos a los interesados.
5.2.3. Construcción del documento “Visión”
El objetivo de la Visión es proponer una solución de alto nivel a un problema identificado y
aceptado por los interesados. Es necesario que dichos interesados interaccionen con el
equipo de desarrollo, expresando y documentando sus problemas, necesidades y
16
características potenciales y esperadas del sistema; con esto se logra un mejor
entendimiento de que es lo que se va a construir y que problema real se va a solucionar [5].
Este artefacto contiene la definición de la visión que los Interesados (stakeholder) tienen
del producto a ser desarrollado, especificado en términos de las necesidades y
características claves de los Interesados. Contiene los lineamientos de los requerimientos
nucleares visionados del sistema [9].
Este artefacto provee un alto nivel, algunas veces contractual, la base para los requisitos
técnicos más detallados que son visibles para los Interesados (stakeholders). Captura la
esencia del sistema describiendo los requisitos de alto nivel y las restricciones de diseño
que dan al lector una apreciación global del sistema desde una perspectiva de requisitos
funcionales.
5.2.4. Construcción de los casos de uso
Un caso de uso describe la interacción entre uno o más actores y el sistema, de tal forma
que se provea un resultado observable que sea de valor para el actor participante. El
propósito principal de los Casos de Uso es capturar el comportamiento requerido del
sistema desde la perspectiva del usuario final, alcanzar una o más metas. La funcionalidad
del sistema está definida por diferentes casos de uso cada uno representando metas
específicas (obtener un resultado observable y de valor) para un actor en particular [9].
Este artefacto captura la secuencia de acciones que un sistema realiza y que genera un
resultado observable que es de valor para aquellos que interactúan con el sistema.
5.2.5. Construcción de los modelos de casos de uso
Este artefacto captura un modelo de las funciones esperadas de los sistemas así como el
ámbito del mismo. Sirve de contrato entre la institución y los desarrolladores. Este artefacto
presenta una visión del comportamiento esperado del sistema. Es la base para los acuerdos
de desarrollo entre los interesados y el grupo de proyecto. También ayuda a guiar las
diferentes tareas dentro del ciclo de vida del desarrollo de software. Para su representación
se recomiendan los reportes y diagramas generados en herramientas de modelado UML. La
mayoría de la información en el modelo de casos de uso es capturada en las
especificaciones de casos de uso [9].
5.2.6. Construcción del Documento “Especificaciones de requisitos”
Este artefacto captura los requisitos en el ámbito del sistema que no hayan sido capturados
en escenarios o casos de uso, incluye requisitos sobre atributos de calidad y de desempeño
global. Los Requisitos de Soporte pueden ser categorizados de acuerdo al modelo FURPS+
(Funcionalidad, facilidad de Uso, Confiabilidad, Desempeño, Facilidad de mantenimiento +
Restricciones) [9].
17
La meta de este producto de trabajo es asegurarse que todos los tipos de requisitos están
cubiertos, lo cual reduce el riesgo de no considerar alguna faceta importante del sistema.
Los requisitos FURPS+ son globales al sistema e influencian los Mecanismos de
Arquitectura que se crearán, también, guían el desarrollo de los fundamentos del sistema.
Estos requisitos son frecuentemente los elementos de mayor costo, porque estos determinan
las opciones arquitectónicas [9].
5.2.7. Construcción del Glosario
Este artefacto define términos importantes usados en el proyecto. Estos términos son
esenciales para lograr una colaboración efectiva entre los Interesados y otros integrantes del
equipo [9].
El objetivo del Glosario es proporcionar un vocabulario común aceptado por todos los
Interesados. Este puede ayudar a las personas desde diferentes grupos funcionales a
alcanzar un entendimiento mutuo del sistema. La meta no es registrar todos los términos
posibles, sino únicamente aquellos que son inciertos, ambiguos o requieren elaboración.
5.3. La nómina: estructura, partes y elementos básicos.
La nómina es el sistema contable de la empresa para mantener un registro con el salario,
cargo, deducciones, así como otros gastos y rendimientos que genera cada uno de sus
empleados. La nómina es el documento que se entrega mensualmente a todos los
trabajadores en el que aparece el detalle del salario que recibe, junto con las deducciones
que se le practican de dicho salario, bien sea por descuentos obligatorios marcados por la
legislación vigente, bien sea por otro tipo de descuentos como anticipos, o deducciones
para seguros de salud.
El formato estándar de una nómina está regulado por la legislación vigente y se marca una
estructura y contenido mínimo que se debe respetar en todo caso. Este contenido mínimo de
la nómina debe incluir al menos [10]:
■ Datos identificativos de la empresa, dirección del centro de trabajo y
código cuenta cotización en el que está el trabajador incluido.
■ Datos básicos del trabajador, tipo de contrato, categoría, antigüedad en la
empresa.
■ Periodo de liquidación al que corresponde dicha nómina.
■ Detalle de las percepciones salariales y extra salariales que componen la
retribución bruta del trabajador.
■ Detalle de las deducciones que se le practican al salario bruto, bien
marcadas por la legislación vigente, bien por otro tipo de deducciones que
haya que aplicarle a la nómina, como anticipos o, embargos en la nómina.
■ Líquido a percibir, dado que la nómina tiene consideración de documento
acreditativo del pago de salarios cerrando los pagos pendientes al trabajador
para el periodo estipulado.
18
■ Detalle de las bases de cotización de la nómina
■ Lugar de emisión y firma y sello por la empresa y trabajador.
Remarcar que aunque estos elementos sean mínimos, existen algunas excepciones
como el caso de la firma del trabajador. No es necesaria dicha firma si el pago de la
nómina se ha realizado por medios bancarios que puedan demostrar la percepción
salarial por parte del trabajador.
5.3.1. Retribución bruta; conceptos que conforman el salario bruto
La suma total de todos los conceptos que hay que abonar al trabajador dan origen a la
retribución bruta mensual. La nómina tiene por norma general periodos de liquidación
mensuales con las siguientes excepciones [10]:
· Entrada o salida del trabajador de la empresa, sin que estas fechas
correspondan con el mes natural.
· Nóminas de paga extra.
Dentro de las percepciones que se suman para dar lugar al salario bruto tenemos dos
grupos diferenciados:
Percepciones salariales; que lo conforman todos aquellos conceptos que están fijados
por el convenio colectivo de aplicación en la empresa
Percepciones extrasalariales; en el que se incluyen conceptos que no tienen la
consideración pura de salario, como pueden ser dietas, gastos de locomoción o pluses
por retribuciones en especie como el plus por desgaste de herramientas
- Percepciones salariales
Tal y como hemos definido anteriormente, la cantidad de conceptos que se pueden
incluir dentro de las percepciones salariales es muy amplia y no es genérica, porque
cada empresa tiene un convenio colectivo distinto y cada uno de estos textos incluyen
una distribución distinta de los pagos que hay que realizar.
Normalmente, nos podemos encontrar con conceptos como [10]:
· Salario Base, que corresponde al pago mensual mínimo que se tiene que realizar
para un trabajador dentro de la categoría en la que está encuadrado.
Complementos; como cantidades adicionales que complementan al salario base en el caso
de que se cumplan unos determinados requisitos de productividad, cumplimiento horario,
productividad, trabajos penosos, nocturnos en días festivos.
19
Parte proporcional de paga extra. Todos los convenios colectivos regulan el pago de
una o varias pagas extras. Normalmente se abonan entre dos y cuatro pagas extras
anuales y puede darse el caso de que la paga extra se encuentre prorrateada.
- Percepciones extrasalariales
En este apartado se engloban todos aquellos conceptos que no constituyen un pago
directo por el trabajo desempeñado, sino que cubren otro tipo de gastos que se le
puedan originar a un trabajador. Por ejemplo, tienen esta consideración los pagos por
dietas o cantidades indemnizatorias por cambio de centro de trabajo o de localidad
[10].
5.3.2. Descuentos en la nómina
Tal y como hemos explicado anteriormente, en la nómina nos podemos encontrar dos
tipos de descuentos diferentes, bien los descuentos obligatorios por ley o bien los
descuentos que se deban aplicar por cualquier otro tipo de normativas.
En el caso de los descuentos por ley, tenemos dos grupos de deducciones diferentes,
que se destinan al pago de la seguridad social a cargo del trabajador, como los pagos a
cuenta que el propio trabajador tiene que realizar por impuestos u otros conceptos [11].
20
5.4. Estructura Legal de la Nómina de la Universidad Distrital.
5.4.1. Normatividad General de la Nómina de la Universidad Distrital
En la siguiente figura se muestra la normatividad general de la nómina de la Universidad
Distrital [2]
Figura 4. Normatividad General de la Universidad Distrital. Basado de: Oficina Asesora de Sistemas [2].
A continuación se muestra lo que contiene para cada una de las nóminas de la Universidad
en cuanto a Régimen Salarial y Régimen Prestacional según las convenciones (colores) de
la figura anterior:
Tabla 1. Contenido para cada una de las nóminas de la Universidad Distrital. Basado de: OAS [2].
21
5.4.2. Funcionarios
5.4.2.1. Empleados Públicos Administrativos
a. Marco Jurídico Se estipulan las siguientes consideraciones de nómina [2]:
● Ley 4 de 1992 “Mediante la cual se señalan las normas, objetivos y criterios que
debe observar el Gobierno Nacional para la fijación del régimen salarial y
prestacional de los empleados públicos, de los miembros del Congreso Nacional y
De la Fuerza Pública y para la fijación de las prestaciones sociales de los
Trabajadores Oficiales y se dictan otras disposiciones, de conformidad con lo
establecido en el artículo 150, numeral 19, literales e) y f) de la Constitución
Política”.
● Decreto 1042 de 1978 “Por el cual se establece el sistema de nomenclatura y
clasificación de los empleos de los ministerios, departamentos administrativos,
superintendencias, establecimientos públicos y unidades administrativas especiales
del orden nacional, se fijan las escalas de remuneración correspondientes a dichos
empleos y se dictan otras disposiciones”.
● Ley 30 de 1992 “Por el cual se organiza el servicio público de la Educación
Superior”.
● Acuerdo No.003 de 1997 “Por el cual se expide el Estatuto General de la
universidad Distrital Francisco José de Caldas”.
● Acuerdo No.008 de 1983 "Por el cual se determina salarios y otros derechos a los
empleados públicos administrativos".
● Acuerdo 003 de 2003 "Por medio del cual se fija el régimen salarial para los
empleados públicos de la Universidad".
● Resolución 004 de 2003 "Por la cual se establecen las escalas salariales de las
distintas categorías de empleos de la Universidad Distrital Francisco José de Caldas
y se dictan otras disposiciones"
b. Consideraciones Generales
➔ Salario Básico (Acuerdo No.003 de 2003)
22
Es la asignación mensual correspondiente a cada empleo, la cual está determinada por sus
funciones y responsabilidades, así como por los requisitos de conocimiento y experiencia
requeridos para su ejercicio, según la denominación y el grado establecido en la
nomenclatura y escala del respectivo nivel. La asignación básica será fijada por el Consejo
Superior Universitario, de conformidad con los límites máximos que establezca el Gobierno
Nacional [2].
Tabla 2. Fórmula, Incremento y Reliquidación para Salario Básico. Basado en: [2].
➔ Gastos de Representación (Acuerdo No. 003 de 2003)
Para los empleos que pertenezcan al nivel directivo procederá el reconocimiento y pago
mensual de los gastos de representación en el % que para cada grado salarial determine el
consejo superior universitario y se liquidarán sobre la asignación básica que devengue el
funcionario [2].
23
Tabla 3. Fórmula, Incremento y Reliquidación para los Gastos de Representación. Basado en: [2].
➔ Prima Técnica
Constituye un conocimiento económico para atraer o mantener en el servicio del Estado, a
funcionarios altamente calificados. Se reconocerá mensualmente a los empleos que
pertenezcan a los empleos, Directivos, Asesor, Ejecutivo y Profesional, en el porcentaje que
para grado salarial determine el Consejo Superior Universitario y se liquidará sobre la
asignación básica que devengue el funcionario. La prima técnica constituirá factor salarial
para todos los efectos [2].
Fórmula
VP=Valor a pagar
AB=Asignación básica
Donde:
VP = Valor a pagar
GR= Gastos de Representación
No. días = Número de días a liquidar
➔ Auxilio de Transporte
Auxilio que tiene derecho por objeto subsidiar los gastos de transporte que ocasiona el
transporte en desarrollo de la jornada laboral ordinaria. Se reconocerá en los mismos
términos, cuantías y condiciones que por Decreto establezca el Gobierno Nacional para los
trabajadores particulares. No se tendrá derecho a este subsidio, cuando el respectivo
empleado disfrute de vacaciones, se encuentre en uso de licencia suspendido en el ejercicio
de sus funciones o cuando la entidad suministre el servicio. Factor limitado a los funcionarios que devenguen hasta 2 (dos) salarios mínimos legales vigentes. En la
actualidad, al interior de la Universidad los funcionarios administrativos no tienen este
beneficio, solo los trabajadores oficiales [2].
24
Tabla 4. Fórmula e Incremento para Prima Técnica. Basado en: [2].
➔ Horas Extras
Reconocimiento que se hace al empleado cuando por razones del servicio sea necesario
realizar trabajos en horas distintas de la jornada ordinaria de labor. El reconocimiento del
tiempo de trabajo suplementario se liquidará con un recargo del veinticinco por ciento
(25%) sobre la asignación básica, si es diurno y con un recargo del setenta y cinco (75%)
sobre la asignación básica, si es nocturno [2].
Figura 5. Fórmula para Horas Extras. Basado en: [2].
5.4.2.2. Docentes Acuerdo 003 de 1997
a. Marco Jurídico
Para las personas que se rigen por este acuerdo se determina [2]:
● Ley 4 de 1992 “Mediante la cual se señalan las normas, objetivos y criterios que
debe observar el Gobierno Nacional para la fijación del régimen salarial y
prestacional de los empleados públicos, de los miembros del Congreso Nacional y
de la Fuerza Pública y para la fijación de las prestaciones sociales de los
Trabajadores Oficiales y se dictan otras disposiciones, de conformidad con lo
establecido en el artículo 150, numeral 19, literales e) y f) de la Constitución
Política”.
25
● Decreto 1042 de 1978 “Por el cual se establece el sistema de nomenclatura y
clasificación de los empleos de los ministerios, departamentos administrativos,
superintendencias, establecimientos públicos y unidades administrativas especiales
del orden nacional, se fijan las escalas de remuneración correspondientes a dichos
empleos y se dictan otras disposiciones”.
● Ley 30 de 1992 “Por el cual se organiza el servicio público de la Educación
Superior”.
● Acuerdo No.003 de 1997 “Por el cual se expide el Estatuto General de la
universidad Distrital Francisco José de Caldas”.
● Acuerdo No.008 de 1983 "Por el cual se determina salarios y otros derechos a
los empleados públicos administrativos".
● Acuerdo 003 de 2003 "Por medio del cual se fija el régimen salarial para los
empleados públicos de la Universidad".
● Resolución 004 de 2003 "Por la cual se establecen las escalas salariales de las
distintas categorías de empleos de la Universidad Distrital Francisco José de Caldas
y se dictan otras disposiciones" El régimen salarial de los docentes de la
Universidad distrital Francisco José de Caldas está determinada por aquellos que
fueron vinculados en vigencia del Acuerdo No.003 de 1997 (Salario fijo durante el
año) del Consejo Superior Universitario.
b. Consideraciones Generales
➔ Asignación Mensual.
Para el caso de los docentes la asignación mensual está establecida por un conjunto de
criterios y donde cada uno de ellos está valorado en un determinado número de puntos.
Corresponde a la asignación mensual que recibe cada docente y que es fruto de la escala
salarial existente en la universidad que asigna a cada cargo un sueldo dependiendo de la
naturaleza de las funciones, responsabilidades y requisitos para el desempeño del mismo
[2].
La suma de puntos de todos los factores se multiplica el valor dado al punto, obteniéndose
así el sueldo básico estimado.
El valor del punto está dado por el Gobierno Nacional, para la presente vigencia el valor es
de DIEZ MIL CUATROCIENTOS TREINTA Y OCHO PESOS ($10.438.oo) [2]
Fórmula El valor viene determinado del sueldo como tal más un 35% del salario
SB= Salario * 35%
26
Para consulta con RH: De donde sale el valor del salario - Algo que ver con el escalafón y
las horas semanales
De donde sale el % del 35% - MÁXIMO VALOR COMO CATEDRÁTICO
➔ Bonificación por Servicios
La Bonificación por Servicios Prestados a que tienen derecho los empleados públicos
docentes de las universidades estatales u oficiales es equivalente al cincuenta por ciento
(50%) de la remuneración mensual en tiempo completo, cuando ésta no sea superior a
setecientos cincuenta y seis mil cuatrocientos once pesos ($756.411.00). Para los demás
empleados públicos docentes, la Bonificación por Servicios Prestados es equivalente al
treinta y cinco por ciento (35%) de la remuneración mensual en tiempo completo [2].
Fórmula BS = Base Bonificación *35%
5.4.2.3. Docentes Decreto 1279 de 2002
a. Marco Jurídico
Regidos por [2]:
● Ley 4 de 1992 “Mediante la cual se señalan las normas, objetivos y criterios que
debe observar el Gobierno Nacional para la fijación del régimen salarial y
prestacional de los empleados públicos, de los miembros del Congreso Nacional y
de la Fuerza Pública y para la fijación de las prestaciones sociales de los
Trabajadores Oficiales y se dictan otras disposiciones, de conformidad con lo
establecido en el artículo 150, numeral 19, literales e) y f) de la Constitución
Política”.
● Ley 30 de 1992 “Por el cual se organiza el servicio público de la Educación
Superior”.
● Decreto 1279 de 2002 “Por el cual se establece el régimen salarial y prestacional
de los docentes de las Universidades Estatales”
Convenciones Colectivas
● Ley 100 de 1993 “Por la cual se crea el sistema de seguridad social integral y se
dictan otras disposiciones”.
● Concepto No 732 del 3 de octubre de 1995, Sala de Consulta y Servicio Civil del
Consejo de Estado.
Laudos Arbitrales
27
● Decreto 1919 de 2002 “Por el cual se fija el Régimen de prestaciones sociales
para los empleados públicos y se regula el régimen mínimo prestacional de los
trabajadores oficiales del nivel territorial”.
● Ley 1066 de 2006 “Por la cual se dictan normas para la normalización de la cartera
pública y se dictan otras disposiciones”.
28
CAPÍTULO 6. METODOLOGÍA
Inicialmente en el proceso OPENUP/OAS se define la necesidad del interesado, la cual ya
determinó la oficina asesora de sistemas (OAS) que consiste en la solución de software
para apoyar el proceso de gestión de nómina en la Universidad Distrital, este proyecto
contribuirá en la gestión de requerimientos para abordar la solución. A continuación se
explicará la metodología utilizada en cada fase siguiendo el proceso OPENUP/OAS:
a. Fase de inicio
En esta fase se realizaron varias reuniones con la gestora del proyecto, la cual era la
intermediaria entre los usuarios finales y analistas, ella indicaba cuales eran las
funcionalidades deseadas, las cuales se transformaron en los requerimientos y se estableció
el orden en el cual serian abordados. Para la captura de requerimientos se estableció que se
tendría de guía el sistema PERNO, software utilizado en la secretaria de Hacienda de
Bogotá para la gestión de nómina, y otros sistemas de gestión de nómina teniendo en cuenta
los más importante para que el sistema TITÁN tuviera las mejores funcionalidades de otros.
Se estableció la forma en la cual se entregaría el análisis de una funcionalidad, en el cual se
construiría un modelo de dominio, modelo BPMN si se requiere, un diagrama de casos de
uso y las especificaciones de casos de uso teniendo en cuenta la funcionalidad del CRUD
que serían necesarias implementar, además todos los conceptos nuevos o que pudieran
generar ambigüedad se debían registrar en el artefacto Glosario. Las primeras
funcionalidades fueron las encargadas del registro de los sistemas de personas naturales o
personas jurídicas y su respectiva validación de información.
También se analizaron las funcionalidades de algunos parámetros como EPS, ARL, caja de
compensación y bancos. En esta fase se plantean las dudas a la gestora del proyecto las
cuales eran resueltas, además indicaba si el análisis realizado seguía con la dinamicidad del
sistema, es decir que se pudieran agregar o modificar parámetros sin necesidad de depender
del desarrollador. Los artefactos elaborados en esta fase fueron documento de visión, actas
de trabajo, diagramas de casos y especificación de casos de uso.
b. Fase de Elaboración
En esta fase continuaron las reuniones con la gestora de proyecto y los integrantes de las
disciplinas de análisis, arquitectura y desarrollo. En cada reunión se inició mostrando el
modelo del dominio del sistema, los diagramas de casos de uso de las funcionalidades
analizadas con sus respectivas especificaciones, después se mostraban los avances de los
arquitectos y se continuaba con los avances del equipo de desarrollo. Al finalizar la gestora
del proyecto y directores de las disciplinas brindaron su opinión en donde se aceptaban las especificaciones de casos de uso o se brindaban sugerencias para realizar cambios, también
29
se indican las nuevas funcionalidades que se debían analizar, convirtiéndose en nuevos
requerimientos. Para esta fase se inician las pruebas funcionales en donde se buscaba
validar que el sistema realizará correctamente las funcionalidades propuestas.
Para esta fase se terminó la primera versión de análisis del módulo de parámetros (tipo de
vinculación, cargo, actos administrativos), vinculación persona natural y se inició con el
tema más grande y de gran importancia el cual era la liquidación. Para esto se divide el
tema en: tipo de nómina, parámetros de liquidación, conceptos, novedades, preliquidación y
liquidación. Para esta fase se realizó el análisis de los tres primeros subtemas, entregando
sus respectivos diagramas de casos de uso y especificaciones de casos de uso.
c. Fase de Construcción
En esta fase las reuniones y entregas de artefactos se hicieron con mayor intensidad, en
donde se presentaban las necesidades presentadas por la gestora del proyecto y se
convierten en requerimientos los cuales generaban nuevas funcionalidades que se
presentaron en los diagramas y especificaciones de casos de uso. El control de cambios
también tuvo mayor intensidad tanto en el área de análisis como desarrollo, se realizaban
las pruebas y se realizaban los cambios para obtener un buen funcionamiento delsistema. Al
finalizar con todos los casos de uso se revisaba en la implementación en el sistema con el
fin de establecer el estado el cual era Aprobado o No Aprobado. En la última etapa de esta
fase por petición de la gestora del proyecto se realiza el libro TITÁN en donde se presenta
el trabajo realizado por las tres disciplinas, teniendo énfasis en el análisis y en la
arquitectura. También se adelanta el manual de usuario hasta las funcionalidades
desarrolladas.
En esta fase se realizó el análisis correspondiente a las funcionalidades de: asociación de
conceptos, categorías de conceptos y parámetros de liquidación, novedades traslado y
retiros, pre liquidación, liquidación, generador y gestor de reportes.
6.1. Artefactos utilizados para la Gestión de Requerimientos y Requisitos en la
Universidad Distrital.
Para el proceso de gestión de nómina de la Universidad Distrital, se elaborarán los
siguientes artefactos los cuales serán el resultado de las actividades descritas anteriormente,
estos artefactos fueron explicados con mayor detalle en el marco teórico:
30
Figura 6. Artefactos del Subproceso “Gestión de Requerimientos y requisitos”. Basado en: [7]
31
CAPÍTULO 7. DESARROLLO DEL
PROYECTO
7.1. Listado maestro de requerimientos
Para el levantamiento de requerimientos realizamos los siguientes pasos con los cuales se
creó el listado maestro de requerimientos:
Figura 7. Pasos para el Listado Maestro de Requerimientos
Para la identificación de requerimientos se realizaron reuniones con la gestora del proyecto
la cual tenía claras las necesidades del usuario final, se contextualiza con los procesos de
nómina en la Universidad Distrital, el siguiente paso consistió en la comparación de otros
sistemas de gestión de nómina tomando sus mejores y principales características que
deseamos tener en este proyecto, también en la consulta de textos y medios audiovisuales
que brindarán conocimientos sobre los procesos relacionados con nómina. Además se
realizaron pequeñas consultas con personas conocedoras del tema y se presentaron los
prototipos y propuestas a la gestora del proyecto quien aprobaba o realizaba observaciones.
Se continuaba con el último paso en el cual se detalla y documenta el requerimiento. A
continuación se presenta el listado maestro de requerimientos, este artefacto fue
complementado en cada una de las tres fases ya que surgían nuevas necesidades.
Identificar y entender la necesidad del cliente
Contextualización de la necesidad
Consultar fuentes secundarias de información
Consultar fuentes primarias de información
Ratificación del conocimiento
Detallar requerimiento
32
Subsistema Descripción del Requerimiento Solicitante
Gestión
Persona
Debe permitir registrar personas naturales y personas
jurídicas, se debe permitir adjuntar documentos como
fotocopias de cédula y RUT
División de Recursos
Humanos, División de
Recursos Financieros El registro de la información de terceros debe
considerar los reportes exigidos por entes internos y
externos como la DIAN, la Secretaría de Hacienda etc. Debe permitir validar las solicitudes de personas
naturales y jurídicas Debe permitir consultar y modificar las solicitudes
personas naturales y jurídicas. Debe permitir consultar y modificar el estado de
validación sobre las solicitudes de personas naturales y
jurídicas. Debe guardarse un historial respecto a la validación, en
donde se indique la persona que valida, fecha, estado
de la solicitud y un campo de descripción para posibles
recomendaciones
Gestión
Novedades
Debe permitir registrar hoja de vida a una persona
natural que tiene o va a tener una vinculación con la
Universidad Debe permitir consultar y modificar las hoja de vida
personas naturales El sistema debe ser capaz de registrar incapacidades,
prestamos, embargos de sueldo, horas extras,
bonificaciones y cualquier otro tipo de novedad que
afecte la liquidación del sueldo de un empleado Se debe poder crear cualquier tipo de novedad, se debe
poder elegir los campos que contendrá
Gestión de
Parámetros
El sistema debe registrar el parámetro de EPS, ARL,
Cajas de compensación, Fondos de pensiones, estos se
podrán consultar, modificar e inactivar El sistema debe registrar el parámetro de dependencias,
se podrá consultar, modificar e inactivar Se debe poder registrar diferentes niveles de cargo los
cuales se deben poder asociar después al cargo. Un cargo debe tener un nivel, tipo de cargo el cual es el
mismo nombre y un grado. Los tres anteriores
parámetros definen el sueldo de ese cargo El sistema debe registrar el parámetro de Bancos, se
podrá consultar, modificar e inactivar El sistema debe registrar el parámetro de Actos
Administrativos, se podrá consultar, modificar e
inactivar El sistema debe registrar el parámetro de cargos, se
podrá consultar, modificar e inactivar
33
Subsistema Descripción del Requerimiento Solicitante El sistema debe registrar el parámetro de Parámetros
de Liquidación, se podrá consultar, modificar e
inactivar El sistema debe registrar el parámetro de conceptos de
nómina, se podrá consultar, modificar e inactivar El sistema debe registrar el parámetro de tipos de
vinculación, se podrá consultar, modificar e inactivar
Gestión
Vinculación
Persona
El sistema debe registrar la Vinculación Persona y este
debe poder modificar, consultar o Inactivar El sistema debe mostrar los campos respectivos de
acuerdo al tipo de vinculación a la cual persona será
vinculada, si es de planta debe tener un cargo
Gestión de
Novedades - Traslados y
retiros
El sistema debe registrar los traslados de las personas
vinculadas con la universidad distrital entre las
diferentes dependencias, además se debe poder
modificar y consultar este registro El sistema debe registrar los retiros de las personas
vinculadas con la universidad distrital entre las
diferentes dependencias, además se debe poder
modificar y consultar este registro
Gestión de
Conceptos
El sistema debe permitir registrar diferentes conceptos
que puedan ser aplicados a los empleados, se debe
poder ingresar su respectiva fórmula Para cualquier concepto se deben poder realizar las
operaciones de: modificar, consultar e inactivar Se deben poder registrar, modificar y eliminar
condiciones para los conceptos que se definan si este lo
requiere Gestión
Categorías de
Conceptos
Se debe poder registrar, modificar e inactivar
categorías de conceptos Debe poder asociar varios conceptos a una categoría
Gestión de
Liquidación
El sistema debe permitir registrar diferentes
preliquidaciones siempre y cuando no se haya
realizado la Liquidación definitiva, es decir que estén
en Estado "Pagada" El sistema debe permitir consultar y modificar las
Liquidaciones o Preliquidaciones generadas
Gestión de
reportes
El sistemas debe poder crear plantillas de reportes con
el fin de que puedan ser re utilizadas El sistema debe poder crear certificaciones de
empleados de acuerdo a los datos que se necesiten Se deben generar cualquier tipo de reportes respecto a
la información de la nómina y las personas que la
integran Los reportes deben tener la opción de ser visualizadas
en un navegador web o exportar como archivo pdf y
Excel
34
Tabla 5. Listado Maestro de Requerimientos Funcionales
7.2. Requerimientos no funcionales
TIPO DE
REQUERIMIENTO DESCRIPCIÓN
AUDITORÍA Al procesar cada una de las transacciones se deberá dejar un log de
auditoría con la información del usuario que ejecuto la transacción, la
fecha y hora de la misma SEGURIDAD Se debe garantizar que aquellos datos sensibles de la Universidad
Distrital manejen un esquema adecuado y que garantice la
confidencialidad y veracidad de la información. Se debe tener un
control respecto a los permisos y acceso de los usuarios al sistema. DESEMPEÑO Para el desempeño se deberán tener en cuenta las siguientes métricas
Métrica Funcionalidad Registros
procesados La cantidad de registros que se consultan en un
reporte deberá ser igual al total de la demandada, se
podrá mostrar en grupos de registros pero deberá ser
procesada y mostrada toda la información Tiempos de
respuesta El tiempo de respuesta deberá ser de máximo 5
segundos para consultas de datos con poco tamaño.
Para las funcionalidades críticas debido a su
necesidad de procesamiento deberán tener un mayor
tiempo, el cual estará determinado por la cantidad de
registros procesados. DISPONIBILIDAD La disponibilidad de este sistema deberá ser de 24x7, ya que se deben
realizar procesos críticos que pueden ser ejecutados en diferente
horario de acuerdo a conveniencia del administrador. ALMACENAMIENTO
DE INFORMACIÓN La información deberá ser almacenada en el sistema activo durante
18 meses, al llegar un nuevo mes, el mes 18 deberá almacenarse en
una bodega de datos y la información que no sea relevante no será
tenida en cuenta por el sistema activo para la realización de reportes.
Esta duración puede variar de acuerdo al tamaño de información y
disponibilidad de dispositivos. USABILIDAD El sistema debe presentar una interfaz amigable con el usuario,
deberá tener mensajes que ayuden al usuario a navegar por el sistema
para reducir el nivel de error en las operaciones. Tabla 6. Listado Maestro de Requerimientos No Funcionales
35
7.3. Glosario
Área de
dominio Término Definición
Gestión de
Requerimientos
Gestión Acción y efecto de controlar un proceso de ciclo de vida de
un elemento
Ciclo de Vida Pasos por los que transita un elemento, incluye creación,
actualización, consulta, modificación e inactivación
Funcionalidad Conjunto de características y capacidades que tiene el
producto de software
Facilidad de Uso Operaciones que tiene que ver con los factores humanos, la
estética coherencia y documentación del software.
Fiabilidad Data sobre la precisión y el tiempo medio de fallos que
puede presentar el software durante su desarrollo y después
de haberse desplegado
Rendimiento Hace mención sobre la velocidad, la eficiencia, el consumo
de los recursos y el tiempo de respuesta que presenta el
software en su funcionamiento e interacción con el usuario
Soporte Implican la extensibilidad, adaptabilidad, capacidad de
instalación , localización y portabilidad del producto final
de software
Gestión
Persona
Tercero o Persona Son todas aquellas personas ya sean naturales o jurídicas,
con las cuales una organización tiene algún tipo de relación
Persona Natural Es una persona humana que ejerce derechos y cumple
obligaciones a título personal.
Persona Jurídica Es una empresa que ejerce derechos y cumple obligaciones
a nombre de ésta. Al constituir una empresa como Persona
Jurídica, es la empresa (y no el dueño) quien asume todas
las obligaciones de ésta.
Funcionario Es el personal que ingresa de acuerdo al sistema establecido
y desempeña un cargo permanente asignado por ley para el
cual realiza una determinada función
Razón Social Atributo legal que figura en la escritura o documento de
constitución que permite identificar a una persona jurídica y
demostrar su constitución legal.
DV El nombre de este ítem corresponde a la abreviatura de
Dígito de Verificación, este número es calculado por el
sistema en el momento que es digitado el número de
identificación.
Régimen
Tributario Conjunto de leyes, reglas y normas que regulan la
tributación de las actividades. Para este caso se encuentran
36
Área de
dominio Término Definición
los regímenes Común y Simplificado, de acuerdo a la
normatividad vigente.
Régimen Común Pertenecen al régimen común las personas jurídicas y
aquellas personas naturales que no cumplen con cualquiera
de los requisitos exigidos para pertenecer al régimen
simplificado; debiendo declarar y pagar el impuesto ICA
bimestralmente.
Régimen
Simplificado El régimen simplificado es una legislación especial que se
aplica a personas con características particulares,
denominadas “pequeños comerciantes”, para determinar el
pago que éstas deben hacer, por concepto de impuestos, al
Estado. Las personas que se encuentran bajo este régimen
son comerciantes minoristas o detallistas; es decir, personas
que venden, de forma individual o en pequeñas cantidades,
bienes y servicios que están gravados; es decir, que deben
pagar impuestos sobre las ventas.
Gran
Contribuyente La DIAN lo define de la siguiente manera: Persona Natural
o entidad, catalogada como tal por el Director de la DIAN
mediante resolución. Los grandes contribuyentes deben
empezar a cumplir las obligaciones como tal; por ejemplo,
deben presentar las declaraciones virtualmente a través de
los Servicios Informáticos Electrónicos de la DIAN, es
obligatorio.
Autoretenedor La figura de Autoretención consiste en que el agente de
retención se debe abstener de practicar retención en la
fuente por compras a personas catalogadas como auto
retenedores, para que sean ellos mismos quienes respondan
por los valores sujetos a retención.
SAP Sistema Automático de Pagos. Fácil, desde su casa u
oficina, a cualquier hora, desde cualquier lugar (con
conexión a internet), sin importar en que entidad tenga su
cuenta bancaria.
Gestión
Parámetros
Parámetro Son valores constantes que están determinados por las
políticas internas de la empresa y la legislación del país o el
lugar donde labora la empresa, algunos ejemplos, son el
valor del salario mínimo legal vigente, valor del auxilio de
transporte, etc. Cabe aclarar que algunos de estos
parámetros pueden variar anualmente o periódicamente y se
debe llevar control sobre ello.
ARL Administradora de Riesgos Profesionales: Entidades que
tienen como objetivo prevenir, proteger y atender a los
trabajadores contra Accidentes de Trabajo y Enfermedades
Profesionales que puedan ocurrir en el trabajo que
37
Área de
dominio Término Definición
desarrollan.
EPS Los actos Administrativos son un documento suscrito por la
entidad el cual registra la aprobación de acciones solicitadas
por los empleados o determinadas por éste, tales como:
nombramientos, vacaciones, encargos, ascensos,
comisiones, pagos, retiros, entre otros y generalmente se
expiden mediante una Resolución
Actos
Administrativos Es la declaración o manifestación de voluntad, juicio o
conocimiento expresada en forma verbal o escrita o por
cualquier otro medio que, con carácter general o particular,
emitieran los órganos de la Administración Pública y que
produjere o pudiere producir efectos jurídicos.
Comisión La comisión es la cantidad que se cobra por realizar
transacciones comerciales que corresponden a un porcentaje
sobre el importe de la operación.
Actividad
Económica Son los procesos mediante los cuales se crean los bienes y
servicios, a partir de unos factores de producción, que
satisfacen las necesidades de los consumidores y es
alrededor de estas que gira la economía de un país.
Parámetros -
Cargo
Cargo Función de la cual una persona tiene la responsabilidad en
una organización
Nivel Se define como la agrupación de la organización mediante
la representación gráfica de la estructura, las interrelaciones,
obligaciones y autoridad para visualizar la agrupación
detallada dentro de ella. La universidad tiene varios niveles
como por ejemplo, Profesional, Técnico, Tecnólogo,
Docente, etc
Código tipo cargo DI=Director, AS=Asesor, EJ= Ejecutivo, TE= Técnico, AI=
Auxiliar TO= Trabajador Oficial DC=Docente Tiempo
Completo, DP=Docente Parcial
Parámetros - Conceptos de
nómina
Nómina Es un grupo de conceptos que se liquidan con periódica o
esporádicamente, está asociada a un tipo de vinculación y
por ende aplica a todas las personas naturales asociados al
tipo de vinculación en cuestión. Ejemplos Tipo de Nómina:
Nómina de Sueldos, Nómina de Vacaciones, Nomina
Quincenal, Nómina Ejecutiva, etc. Depende directamente.
Periodo de Aplicación: Especifica la fecha o periodo de
tiempo en el cual la nómina se hará efectiva y se llevará a
cabo su liquidación.
Nombre corto Es un el nombre del concepto de manera más corta con el
cual trabaja el liquidador
Reglamentación La reglamentación correspondiente del concepto, la
38
Área de
dominio Término Definición
sustentación jurídica del concepto.
porcentaje máximo
de descuento Nos indica cuando hay un embargo el porcentaje máximo
que sobre el concepto puede ser liquidado.
Gestión
Vinculación
Persona
Vinculación La vinculación puede asociarse a la relación, la asociación o
la unión. Dos personas o cosas están vinculadas cuando
comparten algún tipo de nexo y existe algo en común. En la universidad existen diferentes formas de vinculación
de personal, todas son diferentes y especiales según lo que
requiere el empleador
Tipo de
Vinculación Especifica el tipo de vinculación contractual establecida
entre la persona natural y la institución. Ejemplos:
Vinculación por Honorarios, Vinculación por Hora Cátedra,
Vinculación Funcionario de Planta, etc.
Nombramiento Acto jurídico formal en cuya virtud la administración
pública designa a una persona como empleado o
funcionario y la somete al régimen conocido como función
pública. Entendiendo al nombramiento como el acto final
del procedimiento de designación iniciado con la selección
de candidatos a un cargo público, basados en sistemas que
fijan los requisitos específicos para el buen desempeño
Generador de
Novedades
Novedad Es un hecho reciente (Nuevo) que afecta la liquidación de la
nómina de determinado empleado: Incapacidad, puede
asociarse a uno o más empleados y está respaldada por
información y soportes.
Novedad
Esporádica Una novedad de tipo esporádica es aquella que solo se
liquida una vez, por ejemplo un ausentismo, solo se realiza
la deducción una vez en la nómina del determinado
empleado.
Novedad Periódica Una novedad de tipo periódica es aquella que se liquida
durante cierto periodo de tiempo y a ciertos intervalos, un
ejemplo claro es un préstamo o un fondo de ahorros de
empleados.
Gestión de
Categorías
Categoría de
Concepto Una categoría de conceptos es la denotación de un conjunto
de conceptos que se agrupan ya sea por características
similares o por decisión propia del usuario (facilidad de
reconocimiento).
Categorías de
Parámetros de
Liquidación
Una categoría de parámetros de liquidación es la denotación
de un conjunto de parámetros que se agrupan ya sea por
características similares o por decisión propia del usuario.
Gestión Concepto Razón por la cual se suma o se resta un valor en el proceso
de liquidación de una nómina.
39
Área de
dominio Término Definición
Conceptos Naturaleza del
Conceptos Indica si el concepto se suma o se resta (Devenga o Deduce)
en el proceso de liquidación.
Devenga El devengado corresponde a todos los conceptos por los que
un empleado recibe una remuneración, como son el salario,
horas extras, comisiones, auxilio de transporte, recargos
nocturnos y diurnos, etc. La sumatoria de estos valores
conforman lo que se llama total devengado, que es la
totalidad de los ingresos que recibe el empleado como
remuneración por su trabajo
Deduce Son conceptos que pueden estar a cargo de un trabajador, y
que por consiguiente se debe descontar (deducir) del total
devengado
Símbolo Identificador del concepto de 5 letras y que se mostrará
cuando se requiera en la formulación del concepto
Gestión
Liquidación
Parámetro de
Liquidación Son valores constantes que están determinados por las
políticas internas de la empresa y la legislación del país o el
lugar donde labora la empresa, algunos ejemplos, son el
valor del salario mínimo legal vigente, valor del auxilio de
transporte, etc. Cabe aclarar que algunos de estos
parámetros pueden variar anualmente o periódicamente y se
debe llevar control sobre ello. Conceptos como parámetros: un concepto puede también
ser parámetro para el cálculo de otro concepto por eso en el
modelo de dominio se establece la relación entre parámetro
y concepto. Tipo de parámetro: En consideración con lo previamente
mencionado, cuando se define un parámetro es conveniente
especificar el tipo de parámetro que se está creando, el cual
puede ser de tipo concepto u otros tipos de acuerdo al
modelo de negocio.
Preliquidación La preliquidación es el proceso anterior a la liquidación con
el fin de verificar que los conceptos y todos los procesos de
nómina se estén efectuando de la manera correcta y poder
proceder a Liquidar la nómina correctamente. Si se
encuentran errores en la preliquidación se podrán modificar
con el fin de que a la hora de liquidar no haya fallos.
Liquidación Mensualmente o quincenalmente según sea el periodo de
pago acordado, la empresa debe proceder a liquidar su
respectiva nómina para determinar los diferentes conceptos
que adeuda al trabajador y que debe descontar o deducir.
Fórmula Es el conjunto de pasos que definen el algoritmo que
calcula el valor, ya sea de una unidad, base o valor del
concepto, estos incluyen operadores, operaciones y en
40
Área de
dominio Término Definición
general todos los conceptos aritméticos, semánticos y
sintácticos que implica el cálculo de algún valor. Lo ideal
para la definición de los conceptos es realizar la inserción
de estas fórmulas a través de un analizador sintáctico o
semántico que incluya un lenguaje XML sencillo.
Condición Es una regla que se debe tener en cuenta en el momento de
llevar el cálculo del valor del concepto de la base o de la
unidad y que puede afectar considerablemente el valor de
las variables y la fórmula de cálculo.
Gestión Leyes,
Decretos o
Normas
Ley, Decreto o
Norma Abarcan todas las posibles definiciones que se le puedan
otorgar a los documentos que regulan cualquier
procedimiento o proceso dentro del modelo de nómina
Fecha de emisión y
Fecha de
Vencimiento.
Corresponden a las fechas de emisión de la ley y a la fecha
de vencimiento de la misma en caso de que la segunda esta
exista
Entidad
Legisladora Es el ente estatal, gubernamental, distrital, institucional, etc.
que se encarga de emitir y regular determina ley, decreto o
norma.
Gestión
Reportes
Reporte Un reporte es un informe o una noticia. Este tipo de
documento (que puede ser impreso, digital, audiovisual,
etc.) pretende transmitir una información.
Tabla 7. Glosario General Proyecto TITÁN.
7.4. Plan de trabajo general proyecto TITÁN- plan de iteraciones
El plan general de trabajo en el proyecto TITÁN se manejaba por medio de iteraciones
según la metodología de la Oficina Asesora de Sistemas, por lo tanto cada semana se iban
entregando requerimientos, diagramas y especificaciones de casos de uso y demás
artefactos generales del proyecto. Para este proyecto, para cada módulo que se presenta a continuación se generó, Diagrama
de caso de uso, Especificación de casos de uso, Modelo BPMN para cada módulo y actualización de los artefactos. A continuación se muestra el Plan de iteraciones para el Análisis del proyecto TITÁN,
donde se observa los módulos entregados, los responsables las fechas en las que se
entregaron y su respectivo estado en el que se encuentra:
41
Figura 8. Plan de Iteraciones Análisis Proyecto TITÁN.
7.5. Módulos propuestos para Gestión de nómina
Los módulos propuestos surgen a partir de sub módulos los cuales son el agrupamiento de
los diferentes requerimientos que se necesitan para llevar a cabo una funcionalidad.
Algunos módulos y submódulos fueron abordados de manera compartida por este y otro
equipo de análisis debido a su complejidad, así mismo otros módulos fueron abordados de
manera independiente. Para conocer mejor cuáles equipos de análisis abordaron estos
módulos se realiza una distinción por color de la siguiente manera:
Figura 9. Distinción por color del equipo que realizo el análisis del módulo.
7.5.1 Gestión persona
En la Universidad Distrital antes de iniciar cualquier proceso contractual se debe realizar
una solicitud de registro de persona natural o jurídica, en donde se indica diferente
información que después será validada y se convertirá en parte fundamental al momento de
la vinculación. Este es el primer paso que se debe realizar para tener un proceso
contractual con la Universidad.
Amarillo: Análisis
compartido
Verde: Análisis realizado por este equipo
Naranja: Análisis realizado por otro equipo
42
Figura 10. Gestión Persona
7.5.1.1. Diagrama de casos de uso - Gestión persona
Figura 11. Diagrama de Caso de Uso Gestión Persona
Gestión Persona
Persona natural Persona JurídicaValidación
Persona
43
7.5.1.2 Persona Jurídica
La vinculación contractual de una persona jurídica con la Universidad Distrital se lleva a
cabo si la persona con la cual se establecerá el vínculo se encuentra registrada dentro del
sistema de información y gestión de nóminas. El registro de una persona dentro del sistema
involucra dos actividades fundamentales, realizar la solicitud de creación de persona y
validar esta última con el fin de establecer si la persona cuenta con los requisitos mínimos
para ser incluida o si se debe modificar algo en la solicitud antes de continuar con el
proceso.
7.5.1.3 Validación Persona
En este sub módulo se hará la validación de la información suministrada cuando se hace la
solicitud de una persona natural o jurídica. La validación de una solicitud se hace para
poder verificar la información de los documentos que previamente son diligenciados.
7.5.2 Gestión Parámetros
Los parámetros generales son de vital importancia ya que gracias a ellos se puede obtener y
vincular información pertinente según las necesidades de la empresa que facilitan la
parametrización de información de los usuarios en la aplicación. Los parámetros son
valores constantes que están determinados por las políticas internas de la empresa y la
legislación del país o el lugar donde labora la empresa, algunos ejemplos, son el EPS, ARL,
Leyes, etc.
Cabe aclarar que algunos de estos parámetros pueden variar anualmente o periódicamente y
se debe llevar control sobre ello. Los siguientes fueron los parámetros generales que se
abordaron:
44
Figura 12.Gestión Parámetros.
7.5.2.1. Modelo BPMN Gestión De Parámetros
Figura 13. Modelo BPMN Gestión Parámetros.
Actividades Economicas
Fondo De Pensión ARL EPS
Bancos Cargo Nivel de CargoCaja de
Compensación
Acto Administrativo
Ley y DecretosParametros de
LiquidacionTipo de
Vinculacion
45
7.5.2.2. Diagrama de Caso de Uso Gestión Parámetros
Figura 14. Diagrama de Caso de Uso Gestión Parámetros.
46
A continuación se presenta cada uno de los parámetros analizados en los cuales se tendrá
una descripción acerca de su utilidad y uso para la gestión de nómina. Cada uno tendrá una
tabla en donde se indican los atributos que componen al parámetro, estos atributos son
ingresados en el formulario de registro, se puede observar cuales son requeridos, cual es el
tipo de dato y si son modificables. Estos datos están soportados en la base de datos.
7.5.2.1 Cargo
La universidad tiene varios tipos de vinculaciones como lo son Funcionarios y Docentes de
Planta, Vinculación Especial, Pensionados, entre otros. El cargo hace referencia a la
función de la cual una persona tiene la responsabilidad en una organización, para el caso de
la nómina de la universidad solo se tiene un cargo para el tipo de Vinculación Funcionarios
y Docentes de Planta.
Tabla de atributos Cargo
Atributos Cargo Descripción Requerido Tipo Modificable
Código Cargo
(Identificador)
Código del cargo asignado
automáticamente
Si Numérico No
Nivel de cargo Representa el nivel jerárquico del
cargo en la Universidad
Si Texto-
Lista
Si
Grado El grado es la posición funcional
de cada funcionario
Si Texto-
Lista
Si
Tipo de Cargo El tipo de cargo es el mismo
nombre del cargo
Si Texto Si
Sueldo Dinero que recibe una persona
por ese cargo
Si Numérico Si
Tipo Sueldo Puede ser mensual u hora Si Texto-
Lista
Si
Funciones Funciones propias del cargo No Texto Si Tabla 8. Tabla de Atributos Cargo
Estados Cargo:
Activo:El cargo se encuentra en funcionamiento y es necesario en la Universidad
Distrital
Inactivo:El cargo no se encuentra en funcionamiento en la Universidad Distrital
7.5.2.2 Nivel de Cargo:
La planta de personal está diseñada para ser catalogada por niveles jerárquicos como por
ejemplo director, asesor, profesional, técnico o asistencial, en la nómina se puede
47
identificar el salario para poder proceder al pago, es por esto que este módulo se crea para
poder identificar y registrar los niveles de cargo que se utilizan en la Universidad.
Figura 15. Modelo BPMN Gestión Cargo y nivel de Cargo.
Estados Cargo:
Activo:El nivel de cargo está vigente en la Universidad Distrital
Inactivo:El nivel de cargo no está vigente en la Universidad Distrital
7.5.2.3 EPS
Para la vinculación de una persona en la Universidad, se debe tener registró de una serie de
entidades promotoras de salud, ya que según las Leyes en Colombia los empleados deben
pertenecer a alguna EPS y con esto puedan recibir el servicio de la salud. Las Entidades
Prestadoras de Salud (EPS) son empresas que brindan servicios de seguridad social en
salud privada a los trabajadores que están afiliados a ellas.
Tabla de atributos EPS
Atributos EPS Requerido Tipo Modificable
NIT EPS (identificador) Si Numérico No
Nombre de la EPS Si Texto Si
Dirección Si Texto Si
Teléfono Si Numérico Si
Extensión Teléfono No Numérico Si
Fax No Numérico Si
Extensión Fax No Numérico Si
Lugar Si Texto - Lista (Departamento, Ciudad) Si
Nombre del representante No Texto Si
Email Si Texto Si Tabla 9. Atributos EPS
48
Estados EPS:
Activo: La EPS está activa y presta sus servicios actualmente.
Inactivo: La EPS no está activa y no presta sus servicios actualmente.
7.5.2.4 Cajas de Compensación
De igual manera que las entidades promotoras de salud, la información es de vital
importancia para las personas que se vayan a vincular a la Universidad. Las cajas de
Compensación son las únicas entidades colombianas que de manera integral velan, cuidan y
se preocupan por mejorar el bienestar del trabajador y de su familia a través de los
diferentes programas que desarrollan como educación, Fomento de la Salud,
emprendimiento, créditos, recreación y turismo social, entre otros, incluyendo la cuota
monetaria, y los subsidios de vivienda y de desempleo.
Tabla de atributos Caja de Compensación
Atributo Caja de Compensación Requerido Tipo Modificable
NIT Caja de compensación
(identificador)
Si Numérico No
Nombre de la Caja de
Compensación
Si Texto Si
Dirección Si Texto Si
Teléfono Si Numérico Si
Extensión Teléfono No Numérico Si
Fax No Numérico Si
Extensión Fax No Numérico Si
Lugar Si Texto - Lista (Departamento,
Ciudad)
Si
Nombre del representante No Texto Si
Email Si Texto Si Tabla 10. Atributos Caja de Compensación
Estados Caja de Compensación:
Activo: La Caja de Compensación está activa y presta sus servicios actualmente. Inactivo: La Caja de Compensación no está activa y no presta sus servicios
actualmente.
7.5.2.5ARL (Administradora de Riesgos Profesionales)
Entidades que tienen como objetivo prevenir,proteger y atender a los trabajadores contra
Accidentes de Trabajo y Enfermedades Profesionales que puedan ocurrir en el trabajo que
49
desarrollan. Por esto también son importantes tener información en la gestión de nómina y
vinculación de una persona a la Universidad.
Tabla de atributos ARL
Atributo ARL Requerido Tipo Modificable
NIT ARL (identificador) Si Numérico No
Nombre de la EPS Si Texto Si
Dirección Si Texto Si
Teléfono Si Numérico Si
Extensión Teléfono No Numérico Si
Fax No Numérico Si
Extensión Fax No Numérico Si
Lugar Si Texto - Lista (Departamento, Ciudad) Si
Nombre del representante No Texto Si
Email Si Texto Si Tabla 11. Atributos ARL
Estados ARL:
Activo: La ARL está activa y presta sus servicios actualmente.
Inactivo: La ARL no está activa y no presta sus servicios actualmente.
7.5.2.6 Ley, normas y Decretos
Abarcan todas las posibles definiciones que se le puedan otorgar a los documentos que
regulan cualquier procedimiento o proceso dentro del modelo de nómina.
Tabla de atributos Leyes, Normas y Decretos
Atributo Leyes, Normas y Decretos Requerido Tipo Modificable
Id Leyes, Normas y Decretos (identificador) Si Numérico No
Nombre de la Ley, Norma o Decreto Si Texto Si
Fecha de Expedición Si Date Si
Fecha de Vencimiento No Date Si
Entidad Legisladora Si Texto Si
Departamento Si Texto-Lista Si
Ciudad Si Texto-Lista Si Tabla 12. Atributos Leyes, Normas o Decretos
Estados:
Activo: La Ley, norma o decreto está vigente.
Inactivo: La Ley, norma o decreto no está vigente.
50
7.5.2.7 Actos Administrativos
Es la declaración o manifestación de voluntad, juicio o conocimiento expresada en forma
verbal o escrita o por cualquier otro medio que, con carácter general o particular, emitieran
los órganos de la Administración Pública y que produjere o pudiere producir efectos
jurídicos.
Tabla de atributos Actos Administrativos
Atributo Actos Administrativos Requerido Tipo Modificable
Id Acto Administrativo Si Numérico No
Tipo Acto Si Texto-Lista Si
Fecha Si Date Si
Tipo de Documento Si Texto-Lista Si
Fecha Efectividad No Date Si
Fecha Caducidad No Date Si
Justificación No Texto Si Tabla 13. Atributos Actos Administrativos
Estados:
Activo: El Acto Administrativo está vigente.
Inactivo: El Acto Administrativo no está vigente.
7.5.2.8Bancos
Este módulo en el software de Gestión de Nómina de la Universidad Distrital tiene como
objetivo, el registró, consulta, modificación e inactivación de los bancos que se manejan en
la nómina para el proceso de pagos y transacciones de sus empleados.
Tabla de atributos Bancos
Atributo Bancos Requerido Tipo Modificable
NIT Banco Si Numérico No
Nombre Si Texto Si
Forma de Pago Si Texto-Lista Si
Tipo de Cuenta Si Texto Si
Cuenta Bancaria Si Numérico Si Tabla 14. Atributos Bancos
51
7.5.2.9 Tipos de Vinculación
La Universidad Distrital Francisco José de Caldas, según su normatividad, cuenta con
varios tipos de vinculación, estos hacen referencia a la vinculación contractual entre la
persona y la institución, actualmente la Universidad posee varios tipos de vinculación como
los son: Vinculación por Honorarios, Vinculación por Hora Cátedra, Vinculación
Funcionario de Planta, etc. Cada uno de estas vinculaciones tiene beneficios y parámetros
diferentes, por esto es de gran importancia para la nómina saber qué tipo de vinculación es
el empleador.
Tabla de atributos Tipo Vinculación
Atributo Tipo Vinculación Requerido Tipo Modificable
Id Tipo Vinculación Si Numérico No
Nombre Si Texto Si
Naturaleza Si Texto-Lista Si
Rubro Si Lista- Selección Múltiple Si
Tipo Liquidación Si Texto-Lista Si
Ley Si Lista- Selección Múltiple Si
Descripción No Texto Si Tabla 15. Atributos Tipo de Vinculación
Estados:
Activo: El Tipo de Vinculación está activo en la Universidad Distrital
Inactivo: El Tipo de Vinculación no está activo en la Universidad Distrital
7.5.2.10 Parámetros de Liquidación
Cuando se lleva a cabo el registro de los conceptos de una nómina se hace necesario definir
las fórmulas que determinan el cálculo del valor del concepto, para poder realizar este
procedimiento en todas las ocasiones es necesario definir y utilizar parámetros que se
involucran en el cálculo, por ejemplo el salario mínimo legal vigente, el valor del subsidio
de transporte, el valor del subsidio familiar, etc. El módulo de gestión de parámetros de
liquidación está diseñado para realizar la pertinente gestión de la información ya mencionada.
Tabla de atributos Parámetros de Liquidación
Atributo Parámetros de
Liquidación
Requerido Tipo Modificable
Id Parámetros de Liquidación Si Numérico No
Nombre Si Texto Si
Símbolo Si Texto Si
52
Atributo Parámetros de
Liquidación
Requerido Tipo Modificable
Valor Si Numérico Si
Categoría Si Texto-Lista Si
Ley Si Lista- Selección
Múltiple
Si
Descripción No Texto Si Tabla 16. Atributos Parámetros de Liquidación
Estados:
Activo: El Parámetro de Liquidación está activo para los procesos de liquidación.
Inactivo: El Parámetro de Liquidación no está activo para los procesos de
liquidación.
7.5.3 Gestión Conceptos
Figura 16. Modelo Gestión Conceptos
7.5.3.1 Conceptos
El proceso de liquidación de nómina sobre cualquier tipo de vinculación implica el
agrupamiento y las operaciones sobre los conceptos que dicha vinculación tiene asociados,
entiéndase concepto como el algoritmo de reglas, operaciones, parámetros, condiciones y
demás información que realiza el cálculo del valor de cierto componente dentro del modelo
de liquidación. Un Concepto es un valor que se suma o se resta en el proceso de
liquidación. Gestión Conceptos servirá para registrar los diferentes conceptos que se
puedan presentar en los diferentes tipos de vinculación.
Conceptos
ConceptosAsociación de
conceptosCategorias de
conceptos
Categorias de parámetros de
liquidación
53
Figura 17. Modelo BPMN Gestión Conceptos.
7.5.3.2 Diagrama de casos de uso Conceptos
Figura 18. Diagrama de Caso de Uso Conceptos
54
Tabla de atributos Conceptos
Atributo Conceptos Requerido Tipo Modificable
Información básica
id Concepto Si Numérico No
Nombre Si Texto Si
Símbolo Si Texto Si
Naturaleza Si Texto-Lista Si
Categoría Si Texto-Lista Si
Ley Si Lista- Selección Múltiple Si
Descripción No Texto Si
Fórmula de Concepto
Fórmula Si Texto Si
Categoría de Parámetros No Texto-Lista Si
Valor Parámetro No Numérico Si
Categoría de Conceptos No Texto-Lista SI
Contenido Concepto No Texto Si
Variables No Texto Lista Si
Panel de Condiciones
Condición No Texto Si
Categoría de Parámetros No Texto-Lista Si
Categoría de Conceptos No Texto-Lista SI
Variables No Texto Lista Si Tabla 17. Atributos Concepto
7.5.3.3 Categoría de Conceptos
Los conceptos están definidos de acuerdo a leyes, normas o decretos de acuerdo y pueden
aplicarse de acuerdo a su tipo de vinculación, es por esto que es necesario poder definir
unas categorías de conceptos con el fin de agilizar al usuario la búsqueda de los conceptos y
saber que concepto es el que desea elegir.
55
Figura 19. Diagrama de Caso de Uso Categoría Conceptos
Tabla de atributos Categoría Conceptos
Atributo Categoría Conceptos Requerido Tipo Modificable
Id Categoría Conceptos Si Numérico No
Nombre Categoría Si Texto Si
Ley Si Lista- Selección Múltiple Si
Descripción No Texto Si Tabla 18. Atributos Categoría Conceptos
7.5.3.4 Categorías de Parámetros de Liquidación
Este módulo fue definido ya que hay múltiples parámetros de liquidación y la búsqueda se
vuelve un poco robusta, es por esto que es necesario poder definir unas categorías de
parámetros de liquidación con el fin de agilizar al usuario la búsqueda de los mismos.
56
Figura 20. Diagrama de caso de Uso Categoría de Parámetros de Liquidación
Tabla de atributos Categoría Parámetros de Liquidación
Atributo Categoría Parámetros de
Liquidación
Requerido Tipo Modificable
Id Categoría Parámetros de
Liquidación
Si Numérico No
Nombre Categoría Si Texto Si
Ley Si Lista- Selección
Múltiple
Si
Descripción No Texto Si Tabla 19. Atributos Categoría Parámetros de Liquidación
7.5.3.5 Asociación de Conceptos
Cuando se lleva a cabo el registro de los conceptos de una nómina se hace necesario
asociarlos a los tipos de vinculación y a los tipos de nómina para poder realizar el proceso
de Liquidación de manera eficiente.
57
Tabla de atributos Asociación Conceptos
Atributo Tipo Vinculación Requerido Tipo Modificable
Id Asociación Concepto Si Numérico No
Concepto Si Texto-Lista Si
Tipo Vinculación Si Texto-Lista Si
Tipo Nómina Si Texto-Lista Si Tabla 20. Atributos Asociación Conceptos
7.5.4 Gestión de Novedades
Las novedades también son conceptos como las incapacidades, los ausentismos, las
vacaciones, horas extra, préstamos, etc. que se liquidan a ciertos o incluso solo a un
empleado, por ende estos últimos se modelaron en el sistema TITÁN como novedades. A
través del módulo se define y estructura la novedad, posteriormente para poder asociar las
novedades a los empleados. En este trabajo se realizó el análisis de las novedades de
vinculación persona natural, traslados y retiros.
Figura 21. Módulo Gestión Novedades.
7.5.4.1 Vinculación persona natural
Para la vinculación de una persona natural debe estar registrada en el sistema previamente,
pasando por todo el proceso de solicitud de registro de persona natural y su respectiva
validación. La vinculación tendrá una fecha de inicio, ubicación (sede, dependencia y
ubicación específica) y un tipo, en este caso al ser un funcionario de planta se asociara a un
acto administrativo en el cual se reconoce oficialmente la vinculación, un cargo y
selecciona si la naturaleza es temporal o indefinido, si es temporal se debe ingresar una
fecha de finalización de la vinculación.
Novedades
Retiro funcionario
Traslado funcionario
Vinculación persona natural
Registro Hoja de vida
Generador de novedades
Gestor novedades
58
Figura 22. Modelo BPMN Gestión vinculación persona natural.
7.5.4.2 Traslados
Un empleado con tipo de vinculación de planta como funcionario o docente, puede tener un
traslado. Un traslado es el cambio de la persona a la misma u otra dependencia con otro
cargo. Es importante conocer la fecha efectiva de su traslado para realizar su correcta
liquidación
Tabla de atributos Traslados
Atributos
Traslados
Requerido Tipo Modificable
Persona a
trasladar
Si Persona (tipo ID, numero documento,
nombre persona, fecha ingreso)
Si
Nueva
dependencia
Si Listas (Sede, dependencia, ubicación
específica)
Si
Nuevo Cargo Si Listas (Nivel de cargo, tipo de cargo y
grado)
Si
Fecha Traslado Si Fecha Si Tabla 21. Atributos Traslados
7.5.4.3 Retiros
Un empleado con tipo de vinculación de planta como funcionario o docente, puede pedir
retiro en la Universidad. El retiro es la finalización de la vinculación entre el empleado y la
empresa. Es importante conocer la fecha efectiva de su retiro para realizar su correcta
liquidación.
Tabla de atributos Retiros
Atributos
Retiros
Requerido Tipo Modificable
Persona a
retirar
Si Persona (tipo ID, numero documento, nombre
persona, fecha ingreso)
Si
Motivo del
retiro
Si Texto Si
Fecha retiro Si Fecha Si Tabla 22. Atributos Retiros
59
7.5.5 Gestión de Liquidación
Figura 23. Modulo Gestión Liquidación
7.5.5.1 Tipo Nómina
La nómina de acuerdo al modelo de dominio propuesto, se define como un grupo de
conceptos que se liquidan periódica o esporádicamente, en este módulo se describe el
proceso para registró, consulta, modificación e inactivación de una nómina realizando su
respectiva asociación a un determinado tipo de vinculación y detallando su información
básica.
Tabla de atributos Tipo Nómina
Atributo Tipo Nómina Requerido Tipo Modificable
Id Nómina(Identificador) Si Numérico No
Nombre de la Nómina Si Texto Si
Descripción No Texto Si
Tipo de nómina Si Texto-Lista Si
Ley, Decreto o Norma Si Lista- Selección Múltiple Si
Tipo Nómina- Periódica o Mixta
Mes Si Date Si Tabla 23. Atributos Tipo Nómina
7.5.5.2 Preliquidación
Para poder verificar que el sistema si está realizando los procesos adecuados para liquidar,
primero se debe generar una preliquidación con el fin de confirmar que si se está haciendo
el proceso eficazmente para luego pasar al proceso de Liquidación. Este proceso realiza las
mismas operaciones que la liquidación, su principal diferencia es que se podrá ejecutar en
varias ocasiones hasta comprobar que los datos están correctos y se procederá a la
liquidación.
La preliquidación para funcionarios es muy importante debido a que los valores calculados
a pagar son utilizados para la asignación de rubros, por lo cual al momento de realizar la
Liquidación y nómina
Tipo de nóminaPreliquidación
de nóminaLiquidación de
nómina
60
pre liquidación para empleados de planta se deberá asociar los rubros con los cuales al
momento de hacer la liquidación serán utilizados para realizar el pago a los empleados.
Figura 24. Diagrama de Caso de Uso Preliquidación.
Tabla de atributos Preliquidación
Atributo
Preliquidación
Descripción Requerido Tipo Modificable
Id Preliquidación
(Identificador)
Es el identificador de la pre
liquidación, el cual será
generado automáticamente
Si Numérico No
Nombre de la
Preliquidación
Nombre asignado a la
preliquidación. Ejemplo:
preliquidación primer
quincena de mayo
Si Texto Si
Descripción Descripción de la
preliquidación
No Texto Si
Tipo Vinculación Es el tipo de vinculación al
cual se le va a realizar la pre
liquidación puede ser uno o
varios.
Si Texto-
Lista
Si
Nómina Es el tipo de nómina el cual
está asociado al tipo de
Si Texto-
Lista
Si
61
Atributo
Preliquidación
Descripción Requerido Tipo Modificable
vinculación que se va a
preliquidar
Fecha Inicio Es la fecha de inicio del
periodo que se va a
preliquidar
Si Date Si
Fecha Fin Es la fecha de fin del periodo
que se va a preliquidar
Si Date Si
Tabla 24. Atributos Preliquidación
7.5.5.3 Liquidación
La nómina se debe liquidar según el periodo de pago adoptado por la empresa,
generalmente mensual, y en cada periodo se deben liquidar todos los conceptos
relacionados con la nómina, incluso aquellos que se pagan en un tiempo distinto, o que se
pagan a terceros, caso en el cual se liquidan como provisiones como puede ser el caso de
las cesantías o la prima de servicios.
Para realizar el proceso de liquidación inicialmente se debe haber realizado el proceso de
asociación de conceptos con el tipo de nómina del tipo de vinculación el cual se desea
liquidar, además se debe tener en cuenta las novedades registradas desde la última
preliquidación hasta el momento de realizar la liquidación.
7.5.5.3.1. Modelo BPMN Liquidación
Figura 25. Modelo BPMN Gestión Liquidación.
62
7.5.5.3.2. Diagrama de Caso de Uso
Figura 26. Diagrama de caso de uso Liquidación de nómina
Tabla de atributos Liquidación
Atributo
Liquidación
Descripción Requerido Tipo Modificable
Id Liquidación
(Identificador)
Es el identificador de la
liquidación, el cual será
generado automáticamente
Si Numérico No
Nombre de la
Liquidación
Nombre asignado a la
liquidación. Ejemplo:
liquidación primer quincena de
mayo
Si Texto Si
Preliquidación Selecciona la última pre
liquidación con el fin de no
repetir todos los cálculos
realizados, tomando en cuenta
las novedades desde la pre
liquidación hasta la liquidación
Si Texto -
Lista
Si
Descripción Descripción de la
preliquidación
No Texto Si
Tabla 25. Atributos Liquidación
63
7.5.6 Reportes
Los reportes son de vital importancia para los proyectos de nómina en general, ya que por
medio de ellos se puede informar y tener una bitácora de la información más relevante que
pueda tener la empresa con el fin de verificar y tener historial de las liquidaciones,
certificaciones, etc. Por eso, este módulo está diseñado para que en la gestión de nómina de
la Universidad Distrital se puedan crear reportes de todo tipo, como informes, cartas,
certificaciones, etc.
Figura 27. Modulo Gestión Reportes
7.5.6.1 Plantilla Reportes
El ideal de la generación de reportes, es que puedan generarse todo tipo de informes, cartas
etc, es por eso que en este módulo se decide crear plantillas, para generar los reportes, esto
quiere decir que se pueden generar plantillas para todo tipo de reportes, cartas, certificados,
informes generales, etc.
7.5.6.1.1. Modelo BPMN
Figura 28. Modelo BPMN Gestión plantilla de reportes
7.5.6.1.2. Diagrama de Caso de Uso
Reportes
Generador plantilla de reportes Gestión de reportes
64
Figura 29. Diagrama de Caso de Uso Plantilla Reporte.
Tabla de atributos Plantilla Reporte
Atributo Plantilla Reporte Requerido Tipo Modificable
Id Plantilla
Reporte(Identificador)
Si Numérico No
Información General
Nombre Plantilla Si Texto Si
Descripción No Texto Si
Creación Plantilla
Tipo Plantilla Si Texto-Lista Si
Creación Certificados
Encabezado
Empresa Si Texto Si
Imagen No Selección Imagen Si
Título Si Texto Si
Fecha Si Date Si
Otro No Texto Si
Pie de Página
Título(Nombre de la empresa) Si Texto Si
Dirección Si Texto Si
65
Atributo Plantilla Reporte Requerido Tipo Modificable
Teléfono Si Numérico Si
Email No Texto Si
Otro No Texto Si
Cuerpo
Contenido Si Texto Si
Parámetro Persona No Lista- Selección
Múltiple
Si
Parámetro Vinculación No Lista- Selección
Múltiple
Si
Creación Reporte General
Encabezado
Empresa Si Texto Si
Imagen No Selección Imagen Si
Título Si Texto Si
Fecha Si Date Si
Otro No Texto Si
Pie de Página
Título(Nombre de la empresa) Si Texto Si
Dirección Si Texto Si
Teléfono Si Numérico Si
Email No Texto Si
Otro No Texto Si
Cuerpo
Contenido Si Texto Si
Nómina Si Texto- lista Si
Atributos Persona No Lista- Selección
Múltiple
Si
Atributos Vinculación No Lista- Selección
Múltiple
Si
Novedades No Lista- Selección
Múltiple
Si
Atributos Novedades No Lista- Selección
Múltiple
Si
Conceptos(Devengos) No Lista- Selección
Múltiple
Si
Conceptos(Deducciones) No Lista- Selección
Múltiple
Si
Atributos de Conceptos No Lista- Selección
Múltiple
Si
Tabla 26. Atributos Plantilla Reporte
66
7.5.6.2 Gestión Reportes
Cuando se han creado las plantillas, por medio de la gestión de reportes se elige la plantilla
deseada para poder generar los reportes que desea el usuario, este módulo tiene como
objetivo la generación del reporte en específico.
7.5.6.2.1. Modelo BPMN Gestión de Reportes
Figura 30. Modelo BPMN Gestión de reportes.
7.4.6.2.2. Diagrama de Caso de Uso
Figura 31. Diagrama de Caso de Uso Gestor Reporte.
67
Tabla de atributos Reporte
Atributo Reporte Requerido Tipo Modificable
Código Reporte(Identificador) Si Numérico No
Información Reporte
Tipo Plantilla Si Texto-Lista Si
Preliquidación Si Texto-Lista Si
Reporte Si Texto-Lista Si
Información del Personal
Tipo Reporte Si Texto-Lista
Tipo Documento Si Texto-Lista
Documento Si Texto-Lista Tabla 27. Atributos Reportes
68
CAPÍTULO 9. RESULTADOS
Los resultados sonlas actividades y artefactos realizados para el cumplimiento de los
objetivos planteados en este proyecto. En la siguiente tabla se muestra el objetivo, las
actividades realizadas para lograrlo y el porcentaje de cumplimiento
OBJETIVO ACTIVIDADES PORCENTAJE
DE
CUMPLIMIENTO
Representar el modelo de
operación actual de los procesos
relacionados con la gestión de
nóminas en la Universidad
Distrital mediante la notación
gráfica estandarizada para el
modelo y notación de procesos de
negocio BPMN.
Elaboración de diagramas BPMN
sobre los siguientes procesos:
o Gestión Persona
o Gestión Parámetros
o Gestión de Cargos
o Gestión vinculación persona
natural
o Gestión de conceptos
o Gestión preliquidación
o Gestión Liquidación
o Gestión plantilla de reportes
o Gestión de reportes
100%
Definir y ajustar las necesidades
de los interesados mediante
sesiones de trabajo colaborativo
para la elaboración de
documentos que permitan
continuar con el desarrollo del
proyecto.
Reuniones en donde se definieron
las necesidades de los interesados
y se elaboraron las respectivas
actas de trabajo. Además se realiza
el complemento de los artefactos
de los proyectos como la lista de
requerimientos y glosario.
Lecturas acerca de software
relacionado con el tema de nómina.
Lecturas de los procesos y
conceptos relacionados con la
gestión de nómina de los
funcionarios.
100%
Definir y elaborar
especificaciones de caso de uso
que permitan esbozar las
necesidades y requerimientos de
los interesados para la gestión de
nómina de los funcionarios de la
Universidad Distrital.
Elaboración de 112
especificaciones de casos de uso
entre los dos equipos de análisis. 42
fueron realizadas entre ambos
equipos y 47 realizadas
independientemente por este
100%
Documentar los artefactos
propios del análisis del proceso
OPENUP/OAS que sirvan como
base para el desarrollo del
Elaboración de los artefactos
propios del análisis según
metodología OPENUP/OAS
o Lista de requerimientos
100%
69
OBJETIVO ACTIVIDADES PORCENTAJE
DE
CUMPLIMIENTO proyecto y permitan apoyar las
siguientes fases del mismo. funcionales y no funcionales
o Glosario
o Diagramas y especificaciones de
casos de uso
o Actas de trabajo
o Libro técnico y manual de
usuario de TITÁN hasta
funciones desarrolladas Tabla 28. Análisis de Resultados Proyecto TITÁN
70
CAPÍTULO 10. CONCLUSIONES
La nómina de la Universidad Distrital Francisco José de Caldas cuenta con varios
elementos propios que hacen la diferencia con otras nóminas yque se han tenido en cuenta
al momento de realizar su respectivo análisis como lo son: diferentes tipos de
vinculaciones, diferentes tipos de cargo, la universidad está regida por leyes y resoluciones,
entre otros. Por lo cual, la solución se presentó de tal manera que fuera dinámica, es decir,
si ocurre un cambio respecto a la reglamentación, tipo de vinculación u otro parámetro, el
usuario no tendrá que esperar y podrá hacer el cambio directamente desde el aplicativo. El aplicativo fue dividido y analizado de acuerdo a las principales funcionalidades (Gestión
Persona natural y jurídica, Gestión Parámetros, Gestión Conceptos, Gestión novedades,
Gestión Liquidación y Gestión Reportes). Los anteriores módulos son elementos
principales que componen el Sistema de Gestión de nómina de la Universidad Distrital u
otras entidades. Con este trabajo se logró el análisis de una nómina la cual podría tener diferentes
parámetros, los cuales pueden ser ingresados en el sistema por el usuario. Con el módulo de
conceptos se identificó la composición de un concepto donde este puede tener parámetros
de liquidación u otros conceptos y podría tener condiciones para el momento de su
aplicación, por lo tanto se propuso este módulo de tal manera que se pudiera crear la
fórmula del concepto con un mínimo de error y pueda reutilizar los conceptos
anteriormente creados. A los tipos de vinculación se asocian los tipos de nómina que corresponden, ya que un
contratista no va a tener un tipo de nómina de vacaciones mientras que un funcionario de
planta si la tiene. Con esta relación se asocian los conceptos los cuales son definidos
mediante leyes, decretos o resoluciones. El sistema TITÁN tiene los aspectos más importantes y procesos críticos los cuales han
sido mencionados anteriormente y los cuales son el insumo para la elaboración de la
preliquidación y liquidación de los empleados así como la generación de reportes
necesarios. Debido a la amplitud del tema el sistema TITÁN está sujeto a nuevas versiones
en la cuales se incorporan nuevas funcionalidades que apoyen las analizadas en este
proyecto, además de mejorar el desempeño y funcionamiento. Este proyecto no solo fue analizado y documentado sino que también ha sido materializado,
ya que se diseñaron y desarrollaron la mayoría de funcionalidades, se lograron realizar
pruebas de estas especificaciones y se entrega una versión Alpha del sistema, con el fin de
que a futuro se pueda mejorar el sistema si es necesario.
71
CAPÍTULO 11. BIBLIOGRAFÍA
[1] Consejo Superior Universitario, “Estatuto General de la Universidad,” Universidad Distrital
Francisco José de Caldas, 2007. [2] F. T. Tinjaca, Diana Leonor; Alvarez, Edith Bibiana; Rubiano T, Maria Claudia; Hurtado M,
“Levantamiento de la primera versión del proceso de parametrización y liquidación de
nómina soportado en el aplicativo de nómina de funcionarios y pensionados de la
Universidad Distrital,” Universidad Distrital Francisco José de Caldas, 2013. [3] A. Agrela and C. M. Bounzas, “Herramienta web de código abierto para la gestión de
requerimientos durante el ciclo de vida de desarrollo del software para metodología Open
UP,” Universidad Católica Andrés Bello, 2009. [4] U. D. F. J. de Caldas, Resolución de Rectoría N° 461. Bogotá, 2011. [5] Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo OpenUP/OAS,”
Universidad Distrital Francisco José de Caldas, 2011. [6] L. Gimson, “Metodologías ágiles y desarrollo basado en Conocimiento,” Universidad
Nacional de la Plata, 2012. [7] Oficina Asesora de Sistemas, “Proceso de Desarrollo OPENUP/OAS, Capítulo 3: Roles y
artefactos del proceso.,” Universidad Distrital Francisco José de Caldas. [8] Oficina Asesora de Sistemas, “Proceso de Desarrollo OPENUP/OAS, Plantillas
OPENUP/OAS,” Universidad Distrital Francisco José de Caldas, Bogotá. [9] Oficina Asesora de Sistemas, “OAS. Proceso de Desarrollo OPENUP/OAS, Capítulo 6:
Subproceso: Gestión de Requerimientos y requisitos,” Universidad Distrital Francisco José
de Caldas. [10] “La nómina: estructura, partes y elementos básicos,” Remo, 2012. [Online]. Available:
http://www.actibva.com/magazine/guias-practicas/la-nomina-estructura-partes-y-elementos-
basicos. [11] “Sueldos y Salarios.” [Online]. Available:
http://aducarte.weebly.com/uploads/5/1/2/7/5127290/sueldos_y_salarios.pdf.
72
Anexos
[1]. Prototipos Gestión Conceptos
73
74
[2]. Prototipos Preliquidación
75
76
77
78
[3]. Prototipo Liquidación
79
80
81
[4]. Prototipos Retiro
82
[5]. Prototipos Traslados
83
84
[6]. Prototipo Plantilla Reportes
85
86
[7]. Prototipo Gestión Reportes
87
88
[8]. Especificación de caso de Uso Gestión Reportes
Nombre Registrar/Crear Reporte
Estado Exploración: 01 Código GPL-01
Descripción El sistema debe poder generar todo tipo de reportes que sean útiles para la
nómina de la Universidad, los reportes son de gran importancia ya que
gracias a ellos podemos ver un resumen de lo que se gasta, se invierte y en
general el estado financiero o estado de una persona en específico. En este
caso de uso se especifica la creación y registro de un reporte.
Actor(es) Gestor de Reportes
Precondición ● El actor debe ser un usuario autenticado en el sistema y debe contar con
los privilegios de crear el reporte tanto en la aplicación como en la
persistencia. ● La plantilla Reporte debe haber sido registrada previamente. ● El tipo de vinculación debe haber sido registrada anteriormente. ● El tipo de nómina debe haber sido registrada anteriormente. ● La asociación tipo de vinculación con nómina debe haber sido registrada
anteriormente. ● Las dependencias deben haber sido registradas anteriormente
89
● Los conceptos debe haber sido registrada anteriormente. ● Las personas natural y jurídica debe haber sido registrado anteriormente. ● Las novedades deben haber sido registradas anteriormente. ● La liquidación debe haber sido generada previamente.
Escenario
Básico 1. El Usuario selecciona el módulo Gestión de Reportes. 2. El sistema presenta las opciones del módulo. 3. El actor selecciona la opción de “Gestión Reporte”. 4. A continuación el sistema presenta un formulario con la siguiente
estructura: ○ En la parte superior el título “Gestión Reporte” ○ Debajo del anterior componente se presenta un campo de filtro
que permite sesgar la información de la tabla de reportes que
posteriormente se describe. ○ Debajo de los campos previamente mencionados se presenta una
tabla denominada “Reportes” (Campos de la tabla: Código del
Reporte, Reporte, Tipo Plantilla, Ver detalle), esta tabla contiene
todos los reportes que se han registrado, cada uno de los
registros de esta tabla contiene 1 opción de gestión (ver detalle),
adicionalmente en la parte superior derecha de la tabla se
encuentra un botón “Registrar/Crear Reporte”. 5. El actor selecciona la opción “Registrar/Crear Reporte”. 6. El sistema presenta un formulario con dos pestañas una llamada “Gestión
Reporte” y la otra “Generar Reporte”, donde se presenta la siguiente
información:Ver Prototipo (Los campos con asterisco(*) son campos obligatorios) ○ En la pestaña “Gestión Reporte” se muestra la siguiente
información: i. Tipo Plantilla*: Lista desplegable de los dos tipos de Plantilla
(Certificados, Tabla (Reporte General). ii. Reporte*: Lista desplegable. Cuando el usuario seleccione un
tipo de plantilla, deben aparecer las plantillas asociadas a
ese tipo de plantilla. iii. Luego de este hay un label de título “Información”, debajo de
este se encuentra los siguientes campos: iv. Un Check para seleccionar si Personal o Grupo*, si el actor
selecciona “Personal”, este campo tiene como objetivo
poder seleccionar la persona a la que se le va a generar el
reporte (y poder llenar los campos que se generaron en la
plantilla), en este campo se muestra lo siguiente: 1. Tipo de Documento: Lista con los tipos de
documentos existentes. 2. Número de Documento. Campo para digitar el
número de documento de la persona. v. Si el actor selecciona el check Grupo, este campo tiene como
objetivo poder seleccionar las personas a las que se le va
a generar el reporte (y poder llenar los campos que se
generaron en la plantilla), acá se muestra la siguiente
90
información: 1. Un botón “Seleccionar Personas”. Flujo
Alternativo 1.0. vi. Luego se encuentra un label con título “firmas”. Estos campos
tienen como fin seleccionar las personas que van a
firmar el certificado o el reporte, se podrán agregar las
firmas que se deseen y donde se muestra la siguiente
información: 1. Nombre*: Hace referencia al nombre de la
persona que va a realizar la firma del documento 2. Tipo de Documento*: Lista con los tipos de
documentos existentes. 3. Número de Documento*. Campo para digitar el
número de documento de la persona. 4. Otro: Campo de texto, en dado caso que se
quiera agregar otra información (Ejemplo:
Tel.8695670). vii. Botón “Vista Preliminar”.Ver Consultar Reporte viii. Botón “Siguiente”.
7. El actor selecciona el botón “Siguiente” 8. Lo dirige a la pestaña de “Generar Reporte”, donde se muestra la
siguiente información: i. Podrá encontrar un label, donde se indique en qué tipo de
formato quiere generar el reporte. (Ejemplo: Indique el
formato en el cual debe ser generado el reporte:) ii. Luego aparecen 3 opciones de descarga el cual podrá
seleccionar 1 o varios de ellos para que genere el
reporte. 1. HTML. Podrá descargarlo tipo HTML. 2. Excel. Podrá descargarlo en formato Excel 3. pdf. Podrá descargarlo en formato pdf.
iii. Botón “Imprimir”. Muestra la opción para poder imprimir
directamente el reporte. iv. Botón “Generar Reporte”.
9. El actor selecciona la opción “Generar Reporte”. 10. El sistema valida que todos los campos obligatorios están registrados.
Excepción 1.1. 11. El sistema muestra un mensaje indicando si la transacción fue exitosa.
Excepción 1.2. 12. El sistema redirecciona a la página principal de “Gestión Reporte”. 13. El sistema almacena automáticamente los siguientes campos:
○ Código Reporte: Identificador del reporte, debe contener un
formato específico Si es un certificado, el código se generará así:
Ejemplo: CF-00001, si es Reporte general así: RG-00001. ○ Fecha de creación del reporte*: Fecha y hora en la que se creó el
Reporte. ○ Usuario que creó el Reporte.
91
Escenarios Alternativos
Flujos
Alternativos 1.0 El actor selecciona Grupo y luego el botón “Seleccionar personas”, entonces
se mostrará una ventana con la siguiente información: a. La ventana Mostrará un título de “Selección de Personas”. b. Luego se mostrará en los siguientes campos:
i. Tipo de Vinculación*: Lista desplegable donde podrá seleccionar un
tipo de vinculación en específico o varios tipos de vinculación. ii. Dependencia*: Lista desplegable donde podrá seleccionar la o las
dependencias, también deberá estar la Opción “Todas las
Dependencias” y “Ninguna”. iii. Búsqueda por empleado. Debajo del anterior componente se
presenta un campo de filtro que permite sesgar la información de
la tabla que posteriormente se describe. iv. Luego se muestra una opción para seleccionar todos los empleados
si es necesario. v. Debajo del anterior ítem se muestra una tabla con la siguiente
información (Columnas de la tabla: Ítem de selección (Podrá
seleccionar una o varias personas si es necesario), Cédula,
Nombre, Tipo de Vinculación, Dependencia). vi. Botón “Guardar Selección de Personas”. vii. El sistema redirige a la pestaña “Gestión Reporte”Ver Prototipo
c. (Continuación Punto 7 del escenario básico). Fin 1.0
Excepcione S
1.0 Si el usuario que trata de crear el reporte y no cuenta con los permisos
necesarios el sistema notificará su carencia de privilegios y direccionará al
usuario fuera del módulo de gestión. 1.1 Si uno o más campos requeridos no se encuentran debidamente diligenciados
el sistema debe notificar al usuario cuáles campos y por qué no están
correctamente registrados, posteriormente le permitirá regresar a los formularios
para que la información sea corregida y registrada adecuadamente. 1.2 Si la transacción no fue exitosa se muestra un mensaje indicando que la
transacción no pudo ser realizada, mostrando el código y mensaje del error.
PostCondición ● La creación o registro del reporte debe quedar registrado en la base
datos.
Nombre Consultar Plantilla Reporte
Estado Exploración: 01 Código GPL-02
Descripción El sistema debe poder generar todo tipo de reportes que sean útiles para la nómina de la
Universidad, es por esto que tener plantillas específicas para la generación de un
reporte hace que se reduzca el tiempo de trabajo y se pueda reutilizar si es necesario.
En este caso de uso se especifica la consulta de una plantilla de reporte.
92
Actor(es) Gestor de Reportes
Precondición ● El actor debe ser un usuario autenticado en el sistema y debe contar con los
privilegios de crear la plantilla del reporte tanto en la aplicación como en la
persistencia. ● El reporte que se va a consultar debe estar previamente creada. ● La plantilla debe haber sido registrada previamente. ● El tipo de vinculación debe haber sido registrada anteriormente. ● El tipo de nómina debe haber sido registrada anteriormente. ● La asociación tipo de vinculación con nómina debe haber sido registrada
anteriormente. ● Las dependencias deben haber sido registradas anteriormente ● Los conceptos debe haber sido registrada anteriormente. ● Las personas natural y jurídica debe haber sido registrado anteriormente. ● Las novedades deben haber sido registradas anteriormente. ● La liquidación debe haber sido generada previamente.
Escenario
Básico 1. El Usuario selecciona el módulo Gestión de Reportes. 2. El sistema presenta las opciones del módulo. 3. El actor selecciona la opción de “Gestión Reporte”. 4. A continuación el sistema presenta un formulario con la siguiente estructura:
○ En la parte superior el título “Gestión Reporte” ○ Debajo del anterior componente se presenta un campo de filtro que
permite sesgar la información de la tabla de reportes que
posteriormente se describe. ○ Debajo de los campos previamente mencionados se presenta una
tabla denominada “Reportes” (Campos de la tabla: Código del
Reporte, Reporte, Tipo Plantilla, Ver detalle), esta tabla contiene
todos los reportes que se han registrado, cada uno de los registros de
esta tabla contiene 1 opción de gestión (ver detalle), adicionalmente
en la parte superior derecha de la tabla se encuentra un botón
“Registrar/Crear Reporte”. 5. El actor selecciona la opción “Ver Detalle”. 6. El sistema presenta un formulario con dos pestañas una llamada “Gestión
Reporte” y la otra “Generar Reporte”, donde se presenta la siguiente que se
había diligenciado anteriormente enRegistrar/Crear Reporte: (Ningún campo puede ser modificado, solo puede ser consultado)
(Esta vista se verá en formato HTML, pero podrá ser descargado en los formatos
Excel, pdf o HTML) ○ En la pestaña “Gestión Reporte” se muestra la siguiente información:
i. Usuario: Muestra el usuario que creó el reporte ii. Fecha: Muestra la fecha cuando se generó el reporte. iii. Tipo Plantilla: Muestra alguno de los dos tipos de
Plantilla (Certificados, Tabla (Reporte General). iv. Reporte: Muestra nombre de la plantilla que se utilizó para
generar el reporte. v. Código Reporte: Identificador del reporte, debe contener
un formato específico Si es un certificado, el código se
generará así: Ejemplo: CF-00001, si es Reporte general así:
RG-00001. vi. Luego de este hay un label de título “Información”, debajo
de este se encuentra los siguientes campos: vii. Un Check para seleccionar si Personal o Grupo, si el actor
93
seleccionó “Personal”, este campo tiene como objetivo
poder seleccionar la persona a la que se le va a generar el
reporte (y poder llenar los campos que se generaron en la
plantilla), en este campo se muestra lo siguiente: 1. Tipo de Documento: Muestra el tipo de
documentos que se diligenció anteriormente. 2. Número de Documento. Muestra el número de
documento de la persona. viii. Si el actor seleccionó el check Grupo, este campo tiene
como objetivo poder seleccionar las personas a las que se le
va a generar el reporte (y poder llenar los campos que se
generaron en la plantilla), acá se muestra la siguiente
información: Flujo Alternativo 1.0. ix. Luego se encuentra un label con título “firmas”. Estos
campos tienen como fin seleccionar las personas que van a
firmaron el certificado o el reporte, se muestra la siguiente
información: 1. Nombre: Hace referencia al nombre de la persona
que va a realizar la firma del documento 2. Tipo de Documento: Muestra el tipo de
documentos registrado. 3. Número de Documento. Muestra el número de
documento de la persona. 4. Otro: en dado caso que se haya agregar
información, se mostrará (Ejemplo: Tel.8695670). x. Botón “Siguiente”.
7. El actor selecciona el botón “Siguiente” 8. Lo dirige a la pestaña de “Generar Reporte”, donde se muestra la siguiente
información: i. Podrá encontrar un label, donde se indique en qué tipo de
formato quiere generar el reporte. (Ejemplo: Indique el
formato en el cual debe ser generado el reporte:) ii. Luego aparecen 3 opciones de descarga el cual podrá
seleccionar 1 o varios de ellos para que genere el reporte. 1. HTML. Podrá descargarlo tipo HTML. 2. Excel. Podrá descargarlo en formato Excel 3. pdf. Podrá descargarlo en formato pdf.
a. Botón “Imprimir”. Muestra la opción para
poder imprimir directamente el reporte. b. Botón “Salir Reporte”.
9. El actor selecciona la opción “Salir Reporte”. 10. El sistema redirecciona a la página principal de “Gestión Reporte”.
Escenarios Alternativos
Flujos
Alternativos 1.0 El actor selecciona Grupo y luego el botón “Seleccionar personas”, entonces se
mostrará una ventana con la siguiente información: a. La ventana Mostrará un título de “Selección de Personas”. b. Luego se mostrará en los siguientes campos:
i. Tipo de Vinculación: Muestra el o los tipos de vinculación
seleccionados. ii. Dependencia: Muestra la opción que seleccionó previamente. iii. Muestra una tabla con la siguiente información (Columnas de la
94
tabla: (Cédula, Nombre, Tipo de Vinculación, Dependencia) de las
personas seleccionadas previamente. iv. Botón “Salir Selección de Personas”. v. El sistema redirige a la pestaña “Gestión Reporte”
c. (Continuación Punto 7 del escenario básico). Fin 1.0
Excepciones 1.0 Si el usuario que trata de consultar un reporte y no cuenta con los permisos necesarios
el sistema notificará su carencia de privilegios y direccionará al usuario fuera del módulo
de gestión.
PostCondición
[9]. Pantallazos aplicativo TITAN