1

DESARROLLO DE UNA SOLUCIÓN DE SOFTWARE PARA EL PROCESO DE

GESTIÓN DE NÓMINA DE DOCENTES DE PLANTA EN LA UNIVERSIDAD

DISTRITAL

JOSE JAVIER SASTOQUE SANCHEZ

JULIAN SEBASTIAN PEÑA CASTELLANOS

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTA, D.C

2017

2

DESARROLLO DE UNA SOLUCIÓN DE SOFTWARE PARA EL PROCESO DE

GESTIÓN DE NÓMINA DE DOCENTES DE PLANTA EN LA UNIVERSIDAD

DISTRITAL

AUTORES:

JOSE JAVIER SASTOQUE SANCHEZ

JULIAN SEBASTIAN PEÑA CASTELLANOS

TRABAJO 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

2017

3

CONTENIDO

CAPÍTULO 1. INTRODUCCIÓN .............................................................................................. 5

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA ........................................................... 7

CAPITULO 3. OBJETIVOS ....................................................................................................... 9

3.1. OBJETIVO GENERAL .................................................................................................... 9

3.2. OBJETIVOS ESPECÍFICOS ............................................................................................ 9

CAPÍTULO 4. JUSTIFICACIÓN ............................................................................................. 11

CAPÍTULO 5. MARCO TEÓRICO .......................................................................................... 13

CAPÍTULO 6. ALCANCES Y LIMITACIONES .................................................................... 17

6.1. ALCANCES .................................................................................................................... 17

6.2. LIMITACIONES ............................................................................................................. 17

CAPÍTULO 7. ANALISIS......................................................................................................... 19

7.1. MODELO DE NEGOCIO ACTUAL ............................................................................. 19

7.2. ARQUITECTURA DE DATOS ..................................................................................... 21

7.3. MODELO DE DATOS ................................................................................................... 23

CAPÍTULO 8. DISEÑO ............................................................................................................ 30

8.1. GENERALIZACIÓN DE LA LIQUIDACIÓN DE LA NÓMINA................................ 30

8.2. INTERFACES DE PROGRAMACIÓN DE APLICACIONES (API)........................... 35

9.3 MANEJO DE REGLAS UTILIZANDO GOLOG .......................................................... 36

8.4 PROTOTIPO .................................................................................................................... 39

CAPITULO 9. RESULTADOS Y DISCUSIÓN....................................................................... 44

CAPÍTULO 10. TRABAJOS FUTUROS ................................................................................. 47

CAPITULO 11. CONCLUSIONES .......................................................................................... 49

CAPÍTULO 12. BIBLIOGRAFÍA............................................................................................. 51

4

Lista de Figuras

Ilustración 1. Vista principal de una historia de usuario ..........................................................................15 Ilustración 2. Vista de los comentarios y avances de la historia de usuario .............................................15 Ilustración 3. Modelo de Negocio actual .................................................................................................20 Ilustración 4. Tablas manejo de nómina ..................................................................................................23 Ilustración 5. Tablas manejo de preliquidaciones ....................................................................................24 Ilustración 6. Tabla para manejo de conceptos y novedades ....................................................................27 Ilustración 7. Tabla para manejo de liquidaciones ...................................................................................29 Ilustración 8. Ejemplo interfaz nominas registradas ................................................................................30 Ilustración 9. Ejemplo interfaz preliquidaciones nomina docentes de planta ...........................................31 Ilustración 10. Interfaz personas asociadas nominas docentes de planta ..................................................31 Ilustración 11. Detalle preliquidacion personas asociadas nomina docentes de planta ............................32 Ilustración 12. Función CargarReglasBase CrudApi ...............................................................................32 Ilustración 13. Controlador preliquidacion_db ........................................................................................33 Ilustración 14. Detalle resultado controlador preliquidacion_db..............................................................34 Ilustración 15. Interfaces de programación de TITAN.............................................................................35 Ilustración 16. Interfaz inicial prototipo funcional ...................................................................................39 Ilustración 17. Interfaz modulo nominas .................................................................................................40 Ilustración 18. Interfaz preliquidaciones asociadas nomina .....................................................................40 Ilustración 19. Interfaz docentes de planta asociados a la preliquidación ................................................41 Ilustración 20. Interfaz detalle de preliquidación nomina docentes de planta ..........................................42 Ilustración 21. Interfaz detalle de preliquidacion nomina docentes de planta ..........................................42 Ilustración 22. Interfaz detalle de la liquidación nomina docentes de planta ...........................................43 Ilustración 23. Interfaz detalle de la liquidación nomina docentes de planta ...........................................43 Ilustración 24. Personas asociadas nomina docentes de planta ................................................................44 Ilustración 25. Detalle persona Excel nomina docentes de planta ............................................................45 Ilustración 26. Detalle devengos y descuentos empleado ........................................................................46

Lista de Tablas

Tabla 1. Tabla Nomina docentes de planta ..............................................................................................25 Tabla 2. Tabla Preliquidación docentes de planta ....................................................................................26 Tabla 3. Tabla preliquidación nomina docentes de planta .......................................................................26 Tabla 4. Tabla concepto nomina docentes de planta ................................................................................26 Tabla 5. Tabla detalle preliquidacion nomina 1 .......................................................................................26 Tabla 6. Tabla información novedades nomina docentes de planta .........................................................28 Tabla 7. Hechos nomina docentes de planta ............................................................................................37 Tabla 8. Reglas nomina docentes de planta .............................................................................................39

5

CAPÍTULO 1. INTRODUCCIÓN

La Universidad Distrital Francisco José de Caldas, fundamentada en sus principios, fomenta y

propicia el desarrollo cultural, filosófico, científico, tecnológico, artístico, pedagógico y ético

en los diferentes campos del saber cómo factor de modernidad y cambio en la sociedad

colombiana [1]. Por lo anterior, se requiere el uso de talento humano para obtener a cabalidad

estos principios, refiriéndose a docentes, administrativos y contratistas, los cuales, tienen una

vinculación contractual con la Institución para que puedan ser retribuidos monetariamente por

los servicios prestados.

Todo esto, implica que sin importar el tipo de vinculación que tenga una persona natural con

la Universidad Distrital Francisco José de Caldas se debe efectuar un proceso periódico y

controlado de la gestión de nómina integral con respecto a liquidación de salarios,

prestaciones, honorarios, y aportes, seguridad social, parafiscales y prestaciones sociales,

dependiendo del tipo de contrato.

De acuerdo al tipo de vinculación se poseen diversos procesos de gestión de nómina,

realizados con diferentes herramientas informáticas que soportan dichos procesos, desde

hojas de cálculos de Excel hasta soluciones más robustas soportadas en bases de datos Oracle,

los cuales presentan una baja flexibilidad al desarrollo de nuevos requerimientos ya sean de

tipo legal o tributario afectados por el entorno externo o institucional.

Por todo lo anterior, la Universidad Distrital Francisco José de Caldas, con la Oficina Asesora

de Sistemas (OAS) emprende un proceso de mejora y unificación de la gestión de nómina,

por lo cual, este proyecto apoyará el proceso de desarrollo de la solución de software y

pretende como resultado la implementación de una herramienta modular, integral y escalable

que facilite los procesos relacionados con la gestión de nómina, en nuestro caso los docentes

6

de planta. El despliegue de esta solución estará apoyado por tecnologías de desarrollo libre y

fundamentado por SCRUM, comprendiendo procesos de identificación, análisis y

caracterización de especificaciones funcionales y no funcionales en proyectos realizados

anteriormente.

7

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA

Para el funcionamiento normal y adecuado de una empresa u organización se requiere

tener mano de obra o personal (recursos humanos), que cumplan actividades o tareas

específicas, de acuerdo a las necesidades en la organización. A su vez, la prestación de

estos servicios por parte de los trabajadores es remunerada económicamente, generando

un sistema de nómina, que requiere atención adecuada, debido a que implica llevar un

control adecuado de los procesos o actividades a tener en cuenta para el pago de los

salarios correspondientes, y que entre más grande o robusta sea la organización más

complejo es el sistema.

De aquí, surge la necesidad de tener un sistema que reúna de forma ágil y eficaz

información requerida para el desembolso de sueldos y salarios, teniendo en cuenta que el

proceso de liquidación de cada funcionario, está regido por diversos acuerdos,

resoluciones o leyes, propicios por ser una universidad pública y distrital, lo que implica

que el sistema nómina debe contemplar diferentes factores para realizar este proceso de

manera adecuada.

Debido a que la Universidad Distrital Francisco José de Caldas es una entidad autónoma

que cuenta con una alta cantidad de personal o trabajadores, la Oficina asesora de

sistemas, detectó que se presentaban problemas en la parametrización y liquidación de las

nóminas, gracias a la robustez del manejo del personal, debido a que existen varios tipos

de vinculación que se trabajan en sistemas independientes, lo que dificulta el tratamiento

de la respectiva información. Para realizar el pago de estas nóminas, se utilizan

herramientas tecnológicas que presentan problemas en su funcionamiento, como la

independencia total de cada tipo de nómina, así como de la baja interoperabilidad con

otros componentes de software, destinatarios necesarios o proveedores, indispensables

para el funcionamiento adecuado del proceso de liquidación.

8

Lo anterior, implica realizar varios procesos de validación de información para generar los

informes finales respectivos, debido a que las dependencias de la Universidad Distrital

manejan y proveen diferente tipo de información relacionadas a cada nómina, lo que las

convierte en necesarias para el pago correspondiente. Por último, otro factor importante

que afecta el uso, de las herramientas utilizadas es la redundancia que se presenta al

manejar algunos parámetros que son aplicables a cualquier tipo de nómina pero que por el

momento se manejan por cada dependencia de manera individual o independiente.

Con esto, podemos definir la raíz del problema: las herramientas que se manejan

actualmente en la universidad para el pago de nóminas, conducen a tener poca

confiabilidad e integridad de los datos, además de duplicidad en los mismos, de igual

manera, generan un retardo en cuanto a tiempos para realizar la liquidación y el pago de

sueldos del personal que trabaja en la universidad, además de un manejo inadecuado de la

información financiera.

9

CAPITULO 3. OBJETIVOS

3.1. Objetivo general

Desarrollar una solución de software que permita la gestión de los procesos relacionados

con la nómina de docentes de planta vinculados en la Universidad Distrital Francisco José

de Caldas, siguiendo los lineamientos de desarrollo establecidos por la oficina y basado

en la metodología Scrum.

3.2. Objetivos específicos

• Realizar entregas funcionales del producto a desarrollar, según prioridad y necesidad

establecida, permitiendo de esta forma tener avances específicos en el desarrollo de la

solución del software final, además de cumplir los objetivos de cada una de las

iteraciones del proyecto.

• Llevar a cabo pruebas pertinentes, según entregas parciales desarrolladas a través del

proceso de la metodología de SCRUM, determinando si cumplen los requerimientos y

especificaciones establecidos en procesos de análisis y diseño, realizando

correcciones oportunas en tiempos determinados y lograr alcanzar un producto de

software conforme a las necesidades y peticiones de los usuarios directos e

interesados en el modelo de negocio de sistema de nómina docentes de planta.

• Documentar el proceso de desarrollo en base a la arquitectura y requerimientos

establecidos por los proyectos preliminares, obteniendo registros completos del ciclo

de vida que ha tenido el proyecto en general, y que esto funcione como referencia

para futuros trabajos y equipos de desarrollo a los cuales sea útil la información del

producto de software final.

• Efectuar y complementar los procesos de análisis, arquitectura y levantamiento de

10

requerimientos elaborados en proyectos preliminares, teniendo en cuenta el enfoque

de los desarrolladores, con la intención de obtener modificaciones oportunas que

optimicen y aporten a la construcción del producto de software final.

11

CAPÍTULO 4. JUSTIFICACIÓN

La Universidad Distrital Francisco José de Caldas cuenta con un sistema de gestión de

nómina el cual no satisface las necesidades de un sistema integral que permita la debida

eficacia en los procesos de administración y liquidación de profesores con tipo de vinculación

de docentes de planta.

Debido a estos inconvenientes en la utilización y consulta de los datos de este sistema, la

seguridad de los mismos es un tema que puede verse afectado no solo con la información sino

además con la parte financiera, al tener que recurrir a cálculos manuales y que pueden

incurrir en un factor que perjudique a ambos lados, es un sistema que está expuesto a

problemas de integridad, y es por esta razón que es necesario el desarrollo de una solución

que supla los defectos de este sistema.

La Universidad Distrital en los diferentes procesos de sistematización de las nóminas según el

tipo de vinculación, producen una alta relación entre los diferentes componentes de software,

teniendo como base unos procesos de liquidación que serán importantes para su reutilización

en el desarrollo de otro tipo de vinculación.

Para las distintas necesidades que se tendrán en el desarrollo del sistema, es

fundamentalmente en dar el correcto enfoque fortaleciendo las especificaciones dadas por los

arquitectos, teniendo en cuenta características tales como la usabilidad, la escalabilidad, la

fiabilidad su integración y su posterior consistencia en la tolerancia a fallos.

La Metodología ágil de SCRUM es utilizada por la Oficina Asesora de Sistemas (OAS) de la

Universidad Distrital Francisco José de Caldas, donde la función principal que se llevará a

cabo para su ejecución será la de desarrolladores, teniendo en cuenta la documentación

realizada en versiones anteriores, será de vital importancia su análisis para generar los

12

módulos necesarios en la implementación y su producto final como herramienta para la

gestión de la nómina de docentes de planta.

13

CAPÍTULO 5. MARCO TEÓRICO

Metodología de desarrollo ágil scrum

El concepto de Scrum tiene su origen en un estudio de 1986 [6] sobre los nuevos procesos de

desarrollo utilizados en productos exitosos en Japón y los Estados Unidos (cámaras de fotos

de Canon, fotocopiadoras de Xerox, automóviles de Honda, ordenadores de HP y otros). Los

equipos que desarrollaron estos productos partían de requisitos muy generales, así como

novedosos, y debían salir al mercado en mucho menos del tiempo del que se tardó en lanzar

productos anteriores. Estos equipos seguían patrones de ejecución de proyecto muy similares.

En este estudio se comparaba la forma de trabajo de estos equipos altamente productivos y

multidisciplinares con la colaboración entre los jugadores de Rugby y su formación de

Scrum.

En 1993 se realizó el primer Scrum para desarrollo de software [7] y en 1995 el proceso fue

formalizado. En 2001 un grupo de personas muy relevantes en lo que empezaba a ser el

desarrollo ágil escribieron los valores fundamentales de los procesos ágiles.

Metodología Scrum proyecto Titan OAS

La metodología utilizada para este proyecto en su desarrollo fue el de SCRUM, en la Oficina

asesora de sistemas (OAS). Se tienen avances y entregables funcionales semanales, revisados

por los ingenieros a cargo del proyecto de manera interna, los cuales tienen conocimientos y

están a cargo de los procesos de liquidación de nómina de docentes de planta de la

universidad. Estos, tienen el rol de clientes en el desarrollo, así como de product owner, y son

quienes a cada entrega realizan retroalimentación del proceso de construcción del software.

Los encargados de recibir los entregables y llevar a cabo el proceso de seguimiento, así como

de retroalimentación del desarrollo del sistema TITAN son: Los ingenieros Francisco

Hurtado, y María Claudia Rubiano quienes han trabajado sobre el proceso de generación

14

nóminas en la universidad) Carlos Rojas, y Alejandro Daza.

Registro de tareas y seguimiento diario en la herramienta Tuleap: La metodología

SCRUM permite hacer seguimiento diario y semanal de las tareas, para esto se usó el

software Tuleap, Plataforma Libre y Abierta como fuente para el desarrollo de software y

gestión ágil del mismo, para su utilización es necesario la creación de un Proyecto, el cual

tendrá diferentes módulos para su trabajo, además de poder asociar al grupo que estará

involucrado en su desarrollo, una vez realizadas estas tareas se crearán las historias de usuario

según el avance que se tenga en cada semana, asociadas a estas historias de usuario estarán

las tareas relacionadas con cada uno de los integrantes en el proyecto, estas tareas deberán ser

comentadas diariamente en su progreso al igual en la disminución de los puntos según su

avance, de esta forma se podrá evidenciar el trabajo que cada uno tenga y los esfuerzos en su

desarrollo, esta plataforma también nos dará la opción de tener como repositorio los avances

que se tengan a medida de su evolución, también habrá un módulo en el que estará soportada

toda la documentación necesaria para su ejecución.

En la siguiente ilustración se aprecia un ejemplo del seguimiento realizado sobre una tarea por

medio de comentarios; igualmente, estos comentarios deben estar acompañados de commits

sobre los repositorios de Git.

15

Ilustración 1. Vista principal de una historia de usuario

Fuente: Tomada de Tuleap

Ilustración 2. Vista de los comentarios y avances de la historia de usuario

Fuente: Tomada de Tuleap

Sprints semanales con los avances del proyecto: Esta actividad consiste en reuniones que

se realizan cada semana teniendo en cuenta un periodo de dos (2) horas para socializar los

avances con respecto a las tareas asignadas en las historias de usuario, allí se realiza una

revisión con la plataforma de Tuleap, para evidenciar los comentarios y las preguntas que

surgieron en su desarrollo, es importante que ante cualquier percance este sea avisado con

anterioridad para evitar un retraso en las entregas funcionales, una vez realizadas las tareas se

16

harán corrección de las mismas, por último se asignan nuevas tareas según las necesidades

planteadas y las prioridades que se tengan para las entregas que se hagan como presentación.

17

CAPÍTULO 6. ALCANCES Y LIMITACIONES

6.1. Alcances

● El proyecto se desarrolla bajo la metodología de SCRUM, con cada una de sus fases

implementación, revisión, lanzamiento.

● Las iteraciones (Sprints) comprenden una semana de desarrollo.

● El rol de los pasantes es desarrollador, el equipo de trabajo en general, se definirá de

acuerdo a los roles propuestos por la metodología SCRUM.

● El proyecto estará estructurado en 4 release, compuestos cada uno de 4 sprints o

iteraciones.

● El proceso a seguir comprende estructurar el modelo de negocio, elaboración,

construcción y pruebas del producto de software.

● Se realizarán pruebas funcionales y no funcionales de software con el fin de cumplir

con las especificaciones establecidas por el grupo analista y el grupo de arquitectura.

● Cada iteración (Sprint), finaliza con un producto funcional.

● El software comprende los lineamientos funcionales de los sistemas actuales, estos

son la guía principal para el producto al cual se quiere llegar.

6.2. Limitaciones

● Documentar el proceso del sistema junto con la realización de los lineamientos

necesarios del software con respecto a los requerimientos planteados en su

arquitectura estableciendo un periodo de cuatro (4) meses como plazo para su

culminación, teniendo en cuenta la metodología ágil de desarrollo SCRUM.

18

● Definición exhaustiva de las tareas y de los plazos para su desarrollo teniendo como

metodología de desarrollo SCRUM.

● Debido a las alternativas que se tienen como planteamiento y su ejecución en

determinado tiempo se necesita de un mayor esfuerzo para su culminación.

● Dadas las herramientas para su implementación y el lenguaje para su desarrollo en

Golang los plazos contemplados para su comprensión deben ser justos para

alcanzar con las iteraciones de desarrollo.

19

CAPÍTULO 7. ANALISIS

7.1. MODELO DE NEGOCIO ACTUAL

La Oficina Asesora de Sistemas gestiona recursos institucionales con miras a constituir un

Sistema Integrado de Información que apoye a la comunidad en la consecución de los objetivos

misionales, cuenta con un grupo de profesionales que investiga, apropia e implementa día a día

los adelantos en los métodos, procesos, herramientas y demás elementos relacionados con el

desarrollo de Sistemas de Información en un ambiente de mejora continua.

En la actualidad, esta dependencia de la universidad, es encargada de realizar procesos de

generación y liquidación de pagos de nómina, realizados a los funcionarios administrativos,

docentes de planta y pensionados, estos procesos se desarrollan por medio de diversas

funciones y procedimientos, que manejan los devengos y descuentos a cada docente de planta

para su liquidación, dados estos valores se generan los pagos a través de la herramienta

SICAPITAL, asociada a la Secretaria Distrital de hacienda que tiene como función principal la

liquidación de estos conceptos.

Para las diversas nóminas que existen en la universidad los procesos que se llevan a cabo para

su liquidación están muy aislados o se manejan de manera diferente, por ejemplo, para hora

catedra y contratistas se basan en la corrección y verificación de hojas de Excel, que una vez

revisadas son enviadas para su pago por medio de SICAPITAL, por otro lado para la

liquidación de la nómina de docentes de planta, este pago se realiza por medio de una base de

datos en Oracle la cual contiene información de nómina verificada, con procedimientos en

PL/SQL (lenguaje de programación incrustado en Oracle) y que a través de un DBLink (tipo de

objeto que permite realizar una conexión desde una base de datos a otra), son enviadas para su

pago a SICAPITAL. Es allí en donde se pueden o se suelen cometer algunos errores, debido a

20

que las nóminas en la gestión para liquidar, deberían estar parametrizadas y desarrolladas en

conjunto como un solo sistema y no en ambientes separados, otros de los errores que se pueden

observar, están ligados en las herramientas en las cuales se llevan a cabo la gestión de las

nóminas, ya que nos es recomendable hacer estos procesos manualmente, por el contrario, son

procesos que el sistema tiene que realizar y generar para la optimización en las preliquidaciones

y liquidaciones respectivamente.

Dados los inconvenientes expuestos anteriormente, junto con el modelo de negocio actual, lo

que se planteó y desarrolló fue una arquitectura que involucra e integra todos los tipos de

nóminas existentes, de igual manera, un modelo de datos que permitirá la asociación completa

de cada una de las nóminas. El sistema permitirá trabajar en conjunto con otros sistemas de la

Oficina Asesora de Sistemas, puesto que, si se habla de integración, está también debe tener en

cuenta el funcionamiento de los procesos que se manejan alternos a los de la gestión de las

nóminas.

Ilustración 3. Modelo de Negocio actual

Fuente: Realizada por autores

21

7.2. ARQUITECTURA DE DATOS

Se toma como base el punto de vista de estructura de información ofrecido por Archimate, para

realizar un acercamiento al nuevo sistema que se plantea para el manejo de nóminas en la

universidad. En este punto de vista, se visualiza la información a utilizar en la organización, el

proceso de negocio o aplicación en cuanto a tipos de datos o estructura de clases.

Adicionalmente, se puede evidenciar como se representa la información a nivel de negocio en la

aplicación por medio de las estructuras de datos que se utilizan.

En el siguiente diagrama se tienen las entradas de datos (representadas por medio de objetos de

datos) los cuales, alimentan al sistema de nóminas. Se encuentran datos de proveedores, de

contratación y conceptos de nómina, que provienen de los sistemas de Agora (sistema de

terceros y bando de proveedores), Argo (sistema de contratación) y de Nix (sistema de

presupuesto y tesorería).

Ilustración 3. Diagrama de arquitectura de información.

Fuente: Realizada por autores

Se realiza la creación de objeto de negocio a partir de los datos anteriormente mencionados

22

propios del sistema de nómina Titan, explicados a continuación:

• Nómina: Se refiere al registro periódico, en este caso mensual, que se realiza sobre los

salarios de cada uno de los empleados en la Universidad Distrital, teniendo en cuenta

bonificaciones y deducciones, y dependiendo del tipo de contrato del empleado: contratista,

docente de planta, funcionario, pensionado o vinculación especial.

• Preliquidación: Corresponde a un estado previo del pago final que se tiene que realizar

sobre las personas de nómina a las que se desean realizar los pagos. En este estado del

proceso de pago de nómina se calculan los valores (conceptos) que serán devengados y

descontados, desde aquí se permiten realizar correcciones y modificaciones sobre los datos

o los cálculos si así se requiere.

• Liquidación: Es el estado del pago de nómina posterior al de preliquidación, una vez se

verifica el estado correcto de los cálculos y de los datos correspondientes. En este estado se

proceden a realizar los pagos que corresponden de acuerdo a la información.

• Conceptos: Se refieren a los valores que son devengados y descontados a los empleados de

una nómina. Los conceptos utilizados en el pago de nómina, están registrados en el sistema

de presupuesto y tesorería.

• Detalle: Es un componente de los conceptos, el cual hace referencia a la asociación entre la

persona y sus conceptos aplicados, en este, s0e tiene la especificación de cada uno de los

valores que son tenidos en cuenta para el pago de nómina de cada una de las personas

correspondientes.

Este punto de vista de arquitectura permite apreciar que hay procesos comunes para las

nóminas, lo cual permite que se trabajen en conjunto, en un sistema unificado, lo cual permite

23

apreciar qué datos deben ser tenidos en cuenta y de dónde provienen.

7.3. MODELO DE DATOS

Teniendo en cuenta la arquitectura planteada anteriormente, se propuso un modelo de datos

cuyo objetivo se basa en integrar los sistemas de cada nómina, incluida la de docentes de planta,

para su desarrollo se utilizó el software PGmodeler, el cual está orientado al motor de

PostgresSQL, este es el manejado por la Oficina Asesora de Sistemas y es requerido para el

proyecto asignado, el modelo fue avalado para su desarrollo en la aplicación de TITAN por los

arquitectos encargados en la OAS.

En común acuerdo y para el desarrollo de la integración de cada una de las nóminas interesadas,

el modelo creado y utilizado tuvo como autores todos los involucrados del proyecto TITAN,

puesto que de esta forma será válido para todas las nóminas y facilitará su ejecución.

Ilustración 4. Tablas manejo de nómina

Fuente: Realizada por autores

Dentro del modelo de datos planteado, la nómina hace referencia a los distintos grupos sobre

los cuales se pueden realizar preliquidaciones y liquidaciones, entre estos, nómina de

24

funcionarios de planta, nómina de contratistas o de pensionados. Esta condición de grupo está

dada por el campo ‘tipo_nomina’, referencia a la tabla tipo_nomina donde se encontrarán los

grupos ya dichos anteriormente, de esta forma se podrán hacer los registros de cualquier tipo de

nómina, añadiendo información sobre esta, como por ejemplo el periodo al que pertenece y qué

grupo afectará, por otro lado se encuentra la tabla tipo_vinculacion, donde se podrá referenciar

a qué tipo de vinculación pertenece, especificando si es de planta o de vinculación especial.

Ilustración 5. Tablas manejo de preliquidaciones

Fuente: Realizada por autores

Teniendo ya una nómina registrada con las especificaciones anteriores, se puede asociar a esta

una preliquidación donde se calculan los valores que se le van a descontar al docente de planta

y respectivamente lo que va a devengar en este caso escogiendo el grupo de nómina.

La preliquidación asociada tiene atributos como una descripción, una fecha de inicio y una

fecha final, un estado de si ya fue liquidada o no, y la fecha en la que fue realizada, de esta

forma, una nómina puede tener varias preliquidaciones asociadas a ella, pero teniendo en cuenta

que solo una de ellas será tomada como una liquidación.

25

En el modelo también se encuentra el detalle de la liquidación, donde se pueden observar los

conceptos que serán pagados o descontados dependiendo de cada persona, en esta tabla se

hallan las referencias de la preliquidacion, a que persona pertenece y el concepto asociado que

tiene esa preliquidacion. La persona a la que referencia en este detalle debe estar registrada en

la tabla información_proveedor, que se encuentra en el sistema Ágora, donde se pueden

encontrar las personas que están registradas y que tienen un vínculo contractual con la

Universidad Distrital. Una de las cosas a destacar es que se ha respetado esta referencia ya que

no era correcto repetir información básica de las personas dado que existe un sistema en

producción encargado de esta labor.

En la tabla concepto se registran todos aquellos valores que pueden descontarse o sumarse a un

docente de planta. Por ejemplo, en esta tabla concepto deben estar la salud, la pensión, el sueldo

básico, las distintas primas o incentivos, así como las novedades que tenga cada persona sobre

sus devengos, como lo son préstamos, aportes a fondos de empleados, a fondos de pensiones

voluntarias, entre otros. Así mismo, los conceptos pueden ser devengos (suman al salario

básico) o descuentos (son restados del salario básico) en un principio, pues pueden crearse otros

tipos de conceptos en un futuro.

A continuación, se presentan diversos ejemplos de datos registrados en esta sección del modelo:

Tabla nómina:

ID Vinculación Nombre Descripción Estado Periodo Tipo nómina

1 1 DP DocentesPlanta Activo 2017 6

Tabla 1. Tabla Nomina docentes de planta

Fuente: Realizado por autores.

26

Tabla preliquidación:

ID Nombre Nomina Fecha Descripción Fecha_Inicio Fecha_fin liquidada

1 PruebaDP 1 2000/0/0 Ejemplo 2017-01-01 2017-01-28 No

Tabla 2. Tabla Preliquidación docentes de planta

Fuente: Realizado por autores.

Este ejemplo de preliquidación está relacionada a la nómina 1, es decir la de docentes de planta,

y no se encuentra aún liquidada.

Tabla preliquidación:

ID Nombre Nomina Fecha Descripción Fecha_Inicio Fecha_fin Liquidada

1 PruebaDP 1 2000/0/0 Ejemplo 2017-01-01 2017-01-28 No

Tabla 3:

Tabla 3. Tabla preliquidación nomina docentes de planta

Fuente: Realizado por autores.

Tabla concepto:

Id nombre_concepto Naturaleza Alias_concepto

1 SueldoBasico Devengo Sueldo Básico

2 PrestamoVivienda Descuento Préstamo Vivienda

Tabla 4. Tabla concepto nomina docentes de planta

Fuente: Realizado por autores.

Tabla detalle_preliquidacion:

Id Valor calculado Preliquidación Persona Concepto Numero_contrato

1 15000 1 56 1 6

2 7000 1 56 2 6

Tabla 5. Tabla detalle preliquidacion nomina 1

27

Fuente: Realizado por autores.

De esta manera, la persona con id 56 tiene relacionada a ella un concepto 1 (sueldo básico) por

un valor de 15000, perteneciente a la preliquidacion 1, que corresponde a la nómina de docentes

de planta. Igualmente tiene relacionada a ella otro concepto, el 2, que corresponde a un

descuento.

Ilustración 6. Tabla para manejo de conceptos y novedades

Fuente: Realizada por autores

Las novedades anteriormente nombradas son específicas por cada persona, por lo que se

registrarán en la tabla concepto_por_persona, ya que corresponde a conceptos registrados en su

respectiva tabla pero que son especiales para cada proveedor.

El detalle de la preliquidación, tiene una referencia a la información de proveedor del sistema

Agora para las personas a las que se les hará la preliquidación, así como una referencia a la

tabla conceptos, para saber a qué corresponde dicho valor calculado. Las novedades, como

28

extensión de los conceptos, tienen más características asociadas a ellas, como por ejemplo el

número de cuotas (aplicable a créditos, préstamos, entre otros), la fecha en la que fue registrada,

el valor al que corresponde y de qué tipo son. Este último campo explica si la novedad es fija o

porcentual, dado que algunos valores no son estáticos, sino que son calculados sobre el salario

básico o el total devengado. Igualmente, los conceptos por persona deben tener una nómina

asociada, ya que existen personas en varias nóminas y los conceptos no son descontados de

varias nóminas sino de las que sean elegidas. Un ejemplo de datos registrados allí puede ser:

Valor_novedad Num_cuotas Persona Concepto Nomina Id Tipo Estado Fecha

6000 20 56 2 1 1 Fijo Activo 2017-

01-01

Tabla 6. Tabla información novedades nomina docentes de planta

Fuente: Realizado por autores.

Así, la persona 56 tiene una novedad asociada a ella, que corresponde al número 2 (préstamo de

vivienda) y es de la nómina 1 (control realizado por si la persona está dentro de varias

nóminas). Esta nómina es fija y está registrada por un valor de 6000.

29

Ilustración 7. Tabla para manejo de liquidaciones

Fuente: Realizada por autores

Finalmente, dentro del modelo se debe tener en cuenta la liquidación, es decir, tablas que

permitan la persistencia de aquellas preliquidaciones que han sido revisadas y elegidas como

definitivas, para ellos se utilizan las siguientes dos tablas: detalle_liquidacion y liquidación. Se

puede evidenciar que son similares a las de preliquidacion y detalle_liquidacion, pues el

objetivo de estas es guardar la misma información que estas dos para que sean consultadas en

un futuro por los sistemas que realizan las órdenes de pago.

30

CAPÍTULO 8. DISEÑO

8.1. GENERALIZACIÓN DE LA LIQUIDACIÓN DE LA NÓMINA

En la Universidad Distrital Francisco José de Caldas se realiza la liquidación y pago de diversos

tipos de nóminas, de acuerdo al tipo de contrato del trabajador (contratistas, pensionados, hora

cátedra, honorarios y salarios, funcionarios y docentes de planta), por lo cual, se desarrolla una

generalización del proceso de pago de nóminas, lo cual permite, realizar una simplificación en

cuanto a la dificultad, tiempo y demás, al momento de añadir nuevas nominas o sub procesos de

las mismas. En caso de tener el requerimiento de agregar un nuevo tipo de nómina, basta solo

con añadir controlador y actualizar el administrador de reglas de golog.

Lo primero a tener en cuenta en la generalización se encuentra en la interfaz gráfica, cuando el

usuario puede visualizar las nóminas existentes (almacenadas en base de datos, cada una con

identificador de dominio), y selecciona la nómina que desea liquidar.

Ilustración 8. Ejemplo interfaz nominas registradas

Fuente: Realizada por autores

31

Posterior a seleccionar una nómina en específico, se listan las preliquidaciones de esa nómina,

paso siguiente, al seleccionar una preliquidación se asociará a dicha nómina.

Ilustración 9. Ejemplo interfaz preliquidaciones nomina docentes de planta

Fuente: Realizada por autores

Siguiente interfaz se listan las personas relacionadas a la nómina de selección, se realiza envió

de un json con los datos tanto de las personas como de los datos relacionados de la

preliquidación para que el MidApi realice los procesos pertinentes.

Ilustración 10. Interfaz personas asociadas nominas docentes de planta

Fuente: Realizada por autores

Cuando los datos pertinentes son remitidos desde la vista hasta el MidApi, se cargan las reglas

para el dominio, se verifica a que nómina pertenecen la información, se crea un controlador

32

relacionado a la nómina, se devuelve un Json con la información de la preliquidación a la vista.

Ilustración 11. Detalle preliquidacion personas asociadas nomina docentes de planta

Fuente: Realizada por autores

La función CargarReglasBase, permite cargar las reglas del dominio, con un número de

dominio identificador, con el cual se hace una petición al CrudApi, encargado de administrar

las peticiones que solicitan información de la base de datos. En primer lugar, se realiza solicitud

de los conceptos y posteriormente de los predicados disponibles para la nómina de selección.

Ilustración 12. Función CargarReglasBase CrudApi

Fuente: Realizada por autores

33

La función preliquidar, definida en cada nómina respectivamente, se encarga de procesar cada

uno de los docentes que han sido llamados desde la base de datos y operar las reglas cargadas

con la función anteriormente descrita.

Se realizan iteraciones para recorrer cada una de las personas pertenecientes a la nómina,

cargando los datos correspondientes y necesarios, para poder calcular los valores devengados y

descontados en la preliquidación, con estos valores se calcula el total a pagar para cada persona.

Ilustración 13. Controlador preliquidacion_db

Fuente: Realizada por autores

En la siguiente parte del controlador se inyectan reglas o hechos que no son estáticos si no que

cambian dependiendo del docente de planta. Paso posterior se dirigen las reglas base junto con

las inyectadas.

Por último, se almacenan los conceptos calculados en la nómina, en este caso docentes de

planta y se envía este json a detalle_preliquidación, ruta encargada de guardar estos conceptos

en base de datos, para posteriormente pasarlos a la interfaz quien lee los registros de esta tabla

34

para ser visualizados por el usuario.

Ilustración 14. Detalle resultado controlador preliquidacion_db

Fuente: Realizada por autores

Generalizar el manejo de todos los tipos de nómina existentes en la universidad, en el sistema

TITAN, permitirá introducir nuevas funcionalidades eficientemente y a menor costo, así como

modificar y automatizar los procesos de negocio de manera sencilla. Se asegura un nivel de

escalabilidad aceptable, permitiendo una mejora continua de trabajo de manera secuencial, que

permite a cualquier desarrollador agregar código o funcionalidades sin alta complejidad.

35

8.2. INTERFACES DE PROGRAMACIÓN DE APLICACIONES (API)

Ilustración 15. Interfaces de programación de TITAN

Fuente: Realizada por autores

Titan Crud API

El Titan Crud API se encarga de gestionar las conexiones hacia las bases de datos, existen

conexiones los sistemas Argo (Registro de contratos) y Agora (registro de proveedores) que

mediante los servicios se obtienen los datos necesarios para ejecutar la nómina de docentes de

planta, tiene una conexión local con la base de datos de reglas. El Titan Crud API se conecta

con el Mid api para que este le supla los docentes de planta y las reglas ya filtradas para su

posterior ejecución.

Titan Mid api

El Titan Mid Api hereda los métodos de controlador general para implementar funcionalidades

de manera específica dependiendo del tipo de nómina, existe una relación entre la

preliquidación y la liquidación ya que el tiempo de vida de la preliquidación no depende del

tiempo de vida de la liquidación, el tiempo de vida de la preliquidación termina cuando el

36

usuario selecciona las personas y selecciona liquidar, a su vez la preliquidación y la liquidación

utilizan una conexión directa a la base de datos de cada uno de sus procesos para poder guardar

los resultados.

Ruler Api

El Ruler Api se encarga de procesar las reglas y los docentes de planta y de entregar dicha

respuesta al Mid api para que este se lo envíe a la interfaz y los resultados sean tangibles para el

usuario en su ejecución.

9.3 MANEJO DE REGLAS UTILIZANDO GOLOG

Realizar la generalización del sistema implica que todos los factores que comprenden el

desarrollo de las aplicaciones puedan ser trabajadas y modificadas en conjunto. Dado que el

manejo pagos de nóminas tiene como principal trabajo el cálculo de fórmulas matemáticas, se

busca que los proyectos sean independientes del motor de base de datos. Por esta razón, las

fórmulas son traducidas en reglas y hechas procesados en golog, interprete para el lenguaje de

programación prolog.

Los hechos son la base de conocimiento o descripción para que las reglas sean procesadas y

ejecutadas.

37

Tabla 7. Hechos nomina docentes de planta

Fuente: Realizado por autores.

Los hechos contienen información básica necesaria para los cálculos implícitos para el pago de

nómina de docentes de planta. Es importante que exista asociación con una vigencia, si así lo

requiere.

Las reglas son las encargadas de realizar los cálculos de devengos y descuentos en la nómina

docentes de planta.

38

REGLA DESCRIPCIÓN

sueldoSemestralViejo(S,T,VT):-

salarioBasicoViejo(S,SV),

bonificacionViejo(SV,BV),primaViejo(S

V,T,PS), VT is SV+BV+PS.

Regla para calcular el sueldo semestral

salud(V,S) :- S is V*0.04. Regla para calcular aporte a salud

pension(V,S) :- S is V*0.04. Regla para calcular aporte a pensión

info_concepto(X,T,P,N,R):-

concepto(X,T,Y,N,Z,P), ((Y==fijo)->(R

is Z)).

Regla para calcular novedades fijas

bonificacionServicios(V,S) :- (V/2 @<

756411 -> S is V*0.50; S is V*0.35).

Regla para calcular bonificación por servicios

primaServicios(S,T,P) :- (T @>= 12 -> P

is S;P is S/12).

Regla para calcular prima por servicios

salarioBasicoViejo(S,C,T,X) :-

dias_liquidacion(T,D), (C = 1 -> X is

(S+S*0.35) *(D/30); X is S * (D /30)).

Regla para hallar salario de docentes viejos

info_concepto(X,T,P,N,R) :-

concepto(X,T,Y,N,Z,P),((Y==porcentaje

)->(valor_pago(X,P,V),R is V * Z)).

Regla para novedades porcentuales

valor_pago(X,V,P):- P is X*V/100. Regla para novedades porcentuales (calcular

valor)

concepto(prueba, devengo, porcentaje,

salud,0.5 , 2016).

Regla de prueba para conceptos.

devengo(0, prueba). Regla de prueba para los devengos que deben

ser tomados en cuenta en pagos de salud y

pension

novedades_devengos(X):- devengo(V,N),

conceptos_ibc(N), X is V.

Regla que verifica si la novedad de devengo

debe ser tenida en cuenta para pagos de salud

y pension

39

Tabla 8. Reglas nomina docentes de planta

Fuente: Realizado por autores.

8.4 PROTOTIPO

Una vez el usuario ingrese al prototipo funcional, en la interfaz podrá observar dos módulos con

los cuales podrá interactuar, el primero de ellos es el módulo de Nominas en el que el usuario

podrá realizar preliquidaciones y liquidaciones, el segundo módulo será el de Novedades, en

este tendrá la opción de asociar conceptos por nómina a distintas personas.

Ilustración 16. Interfaz inicial prototipo funcional

Fuente: Realizada por autores

Dentro del primer módulo de Nominas, el usuario podrá visualizar las nóminas registradas, en

donde encontrará información acerca de su descripción, la vinculación, el tipo, el estado, el

periodo, y por último la opción de visualizar las preliquidaciones de la nómina respectiva.

REGLA DESCRIPCIÓN

sueldoSemestralViejo(S,T,VT):-

salarioBasicoViejo(S,SV),

bonificacionViejo(SV,BV),primaViejo(SV,T

,PS), VT is SV+BV+PS.

Regla para calcular el sueldo semestral

salud(V,S) :- S is V*0.04. Regla para calcular aporte a salud

pension(V,S) :- S is V*0.04. Regla para calcular aporte a pensión

info_concepto(X,T,P,N,R):-

concepto(X,T,Y,N,Z,P), ((Y==fijo)->(R is

Z)).

Regla para calcular novedades fijas

bonificacionServicios(V,S) :- (V/2 @<

756411 -> S is V*0.50; S is V*0.35).

Regla para calcular bonificación por

servicios

primaServicios(S,T,P) :- (T @>= 12 -> P is

S;P is S/12).

Regla para calcular prima por servicios

salarioBasicoViejo(S,C,T,X) :-

dias_liquidacion(T,D), (C = 1 -> X is

(S+S*0.35) *(D/30); X is S * (D /30)).

Regla para hallar salario de docentes

viejos

info_concepto(X,T,P,N,R) :-

concepto(X,T,Y,N,Z,P),((Y==porcentaje)-

>(valor_pago(X,P,V),R is V * Z)).

Regla para novedades porcentuales

valor_pago(X,V,P):- P is X*V/100. Regla para novedades porcentuales

(calcular valor)

concepto(prueba, devengo, porcentaje,

salud,0.5 , 2016).

Regla de prueba para conceptos.

liquidar(R,P,V,T,C,L):- (R == 1 ->

salarioBasicoNuevo(P,V,T,S), L is S;R == 2 -

> salarioBasicoViejo(V,C,T,X), L is X; L is

0).

Regla para liquidar docentes.

40

Ilustración 17. Interfaz modulo nominas

Fuente: Realizada por autores

Dentro de la opción de las preliquidaciones según la nómina seleccionada, se listan las

preliquidaciones con su descripción, la fecha de su registro, el estado, el tipo y con las opciones

de poder generarla e ingresar al detalle.

Ilustración 18. Interfaz preliquidaciones asociadas nomina

Fuente: Realizada por autores

Dentro de la opción de Generar, habrá un listado con todas las personas relacionadas a la

nómina seleccionada, en este caso una nómina de docentes de planta, se visualizará el número

41

de contrato y el número del documento, se podrá seleccionar las personas deseadas para generar

la preliquidación.

Ilustración 19. Interfaz docentes de planta asociados a la preliquidación

Fuente: Realizada por autores

En esta nueva interfaz, se puede apreciar el detalle de la preliquidación de la nómina

seleccionada, mostrando en un recuadro las personas seleccionadas anteriormente, habrá la

opción de cancelar la selección ya hecha, al lado derecho se mostrará un detalle de la persona

que queramos obtener información específica acerca del devengado, los descuentos y el total a

pagar. Finalmente, en la parte de abajo nos saldrá un resumen de la preliquidación con los

conceptos de los sueldos netos y el sueldo básico de las personas seleccionadas.

42

Ilustración 20. Interfaz detalle de preliquidación nomina docentes de planta

Fuente: Realizada por autores

Además de los datos anteriores mencionados se podrá acceder a otros datos con la opción de

realizar la liquidación.

Ilustración 21. Interfaz detalle de preliquidacion nomina docentes de planta

Fuente: Realizada por autores

43

Al realizar la liquidación se mostrará una interfaz con el detalle de la liquidación realizada,

junto con el resumen de la liquidación presentando los datos obtenidos a través de la

preliquidación.

Ilustración 22. Interfaz detalle de la liquidación nomina docentes de planta

Fuente: Realizada por autores

Entre los datos mostrados en el resumen de la liquidación se encuentran los campos del

concepto, el sueldo neto, y el sueldo básico, ya una vez realizado este proceso, se podrán

generar las órdenes de pago para finalizar los pagos de los docentes de planta.

Ilustración 23. Interfaz detalle de la liquidación nomina docentes de planta

44

Fuente: Realizada por autores

CAPITULO 9. RESULTADOS Y DISCUSIÓN

Para verificar los resultados de las reglas y del sistema de gestión de nómina docentes de planta

en general, se comparan los cálculos y las operaciones realizadas en preliquidación y

liquidación, contrastando con el Excel con el cual se realizaba el pago de nómina anteriormente.

Es este proceso se tienen en cuenta los resultados finales teniendo en cuenta los devengos y los

descuentos correspondientes, para la nómina de noviembre de 2016.

Lo primero a tener en cuenta son las personas que hacen parte del pago de nómina docentes de

planta correspondiente.

Ilustración 24. Personas asociadas nomina docentes de planta

Fuente: Realizada por autores

En esta primera comparación se detallan los nombres de los empleados, el número de

documento y el número de contrato, así mismo la fecha de vigencia.

45

Ilustración 25. Detalle persona Excel nomina docentes de planta

Fuente: Realizada por autores

Paso posterior se pasan los datos a estado de liquidación, esto para visualizar los conceptos y el

detalle de los mismos, aplicados a las personas seleccionadas.

Ilustración 6. Detalle preliquidacion nomina docentes de planta

Fuente: Realizada por autores

Al visualizar los valores devengados, junto con los conceptos aplicados para el pago, se

obtienen los mismos valores aplicados en el Excel.

El valor total devengado, el valor total de descuentos y el valor total a pagar corresponden a los

cálculos realizados para la persona seleccionada.

46

Ilustración 26. Detalle devengos y descuentos empleado

Fuente: Realizada por autores

De igual manera, se tiene en cuenta el resumen de la preliquidación, en donde se toman los

datos de dos personas para visualizar si la suma de los conceptos y valores finales de ambos

registros arrojan los mismos resultados si se tuvieran en cuenta solo esos dos datos en el Excel

correspondiente. Se comparan los cálculos y se obtienen los mismos resultados.

47

CAPÍTULO 10. TRABAJOS FUTUROS

Con respecto al proyecto presente, y al prototipo funcional mencionado anteriormente, se

podrán generar nuevas funcionalidades en el módulo de nóminas que permitan la mejora del

sistema para optimizar el proceso con el que se generan las liquidaciones además de la

generación de nuevos proyectos que puedan partir de la base de este prototipo y de su

desarrollo. Con el fin de dar continuidad al producto creado, se plantean las siguientes

alternativas de trabajo:

• Roles y permisos: Dada la importancia de la ejecución de cada uno de los procesos que

se dan durante la gestión de la nómina de docentes de planta y la generación de la

misma, es fundamental que las acciones que los usuarios registren en el sistema sea

establecido por roles y por controles que se puedan registrar, por esta razón un trabajo

futuro sería la implementación de la funcionalidad de roles, a través de permisos se

podrán establecer las funciones de cada usuario para poder consolidar la integridad en

la gestión de la información.

• Integración con sistemas en producción: Uno de los trabajos a futuro se fundamenta en

la incorporación de este sistema con otros sistemas que adelanta la Oficina Asesora de

Sistemas en este caso de terceros (Ágora) y de contratación (Argo), que con datos reales

se podría manejar el prototipo funcional creado, por esta razón y no solo a través de

esquemas cómo se maneja en la arquitectura de este sistema, la información que lo

alimenta también debe ser por medio de estos sistemas que nos ayudan a tener una

mejor visión del producto creado y su funcionalidad ya en ambientes reales, en la

estructura del sistema inicial se tuvieron en cuenta este tipos de sistemas pero los

servicios que traen la información real no se han generado, por lo cual un trabajo a

48

futuro sería su implementación y puesta en marcha con el sistema de nóminas para

docentes de planta creado y que permita su correcta liquidación.

• Órdenes de pago: Uno de los procesos seguidos después de la liquidación es el

correspondiente a la generación de las órdenes de pago, ya con los datos registrados y

calculados, la Universidad Distrital pueda efectuar estos pagos tomando estos datos para

cada uno de los docentes de planta, y aunque esta labor no es responsabilidad del

sistema de la gestión de la nómina, si es un proceso que se maneja alterno y que debe de

realizarse teniendo en cuenta su esquema.

• Disponibilidad en los presupuestos: Dado el prototipo funcional desarrollado que

calcula los valores de los pagos para cada docente de planta es necesario tener una

verificación sobre el presupuesto asignado en la nómina, dentro del sistema no es

responsabilidad tener información acerca de su disponibilidad, pero si haría más eficaz

su automatización para la realización de dichos pagos, por esta razón un trabajo futuro

para el sistema desarrollado sería un módulo que pueda llamar estos servicios y

consultar en tiempo real el presupuesto, un dato que sería de vital importancia conocer

antes de generar las liquidaciones realizadas en la plataforma.

49

CAPITULO 11. CONCLUSIONES

La correlación de aplicaciones en una organización permite generar agilidad de los procesos a

trabajar, así como mejorar la calidad y rendimiento de los mismos. De igual manera, permite el

fácil intercambio de información, útil en el momento de despliegue y producción del software.

El plan de mejoramiento de la Universidad Distrital, más exactamente la Oficina Asesora de

Sistemas, con miras a construir un sistema integrado de información, que brinde apoyo a la

comunidad institucional en el alcance de los objetivos misionales, busca desarrollar un sistema

de aplicaciones de software con una correlación directa, que permita que los procesos de la

universidad se lleven a cabo teniendo en cuenta la relación y la dependencia de unos a otros.

Por lo cual, el sistema de nómina que se presenta (docentes de planta), hace parte del sistema

integrado de información planteado por la Oficina Asesora de sistemas y busca reducir costos

de ejecución y de rendimiento en la universidad, en el pago de nóminas y liquidación

correspondientes.

La metodología SCRUM, utilizada en la Oficina Asesora de Sistemas, permitió realizar

entregas parciales y regulares del producto final, lo cual llevó a un control constante del avance

del proyecto, así evidenciar errores y buenas prácticas realizadas, logrando corrección y mejora

constante del desarrollo. Adicionalmente, se presentó como una buena práctica para trabajar

colaborativamente, lo que convierte al equipo de trabajo en altamente productivo. Esta

metodología fue favorable en el desarrollo de TITAN y en el proceso de nómina de docentes de

planta, permitió desplegar exitosamente el producto final esperado y obteniendo constante

mejora en cada entrega parcial.

El desarrollo e implementación de este sistema permitirá introducir nuevas aplicaciones

50

eficientemente y a menor costo, modificar y automatizar los procesos de negocio de manera

más sencilla cumpliendo con nuevos requisitos propuestos, entre otros. En la Universidad

Distrital, la metodología anterior para realizar la liquidación y pago de nómina puede

describirse como poco eficiente, al manejar los tipos de nóminas en procesos completamente

separados y utilizando Excel como plataforma de trabajo, lo que aumentaba considerablemente

el tiempo para realizar el pago de una nómina. Sistematizar el proceso de pago de nóminas es

considerablemente una gran mejora que contribuye al rendimiento de producción y ejecución de

la universidad.

51

CAPÍTULO 12. BIBLIOGRAFÍA

[1] Secretaría General de la Alcaldía Mayor de Bogotá D.C. (2008). Acuerdo 5 de 2008

Universidad Distrital Francisco Jose de Caldas. Octubre 27 de 2016, de Alcaldía Mayor de

Bogotá Sitio web: http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=37249#0

[2] SCRUMstudy™(2018) , A Guide to the Scrum Body of Knowledge (SBOK™ Guide). 13

de octubre de 2016, VMEdu, Inc. Sitio web:

http://www.scrumstudy.com/SBOK/SCRUMstudy-SBOK-Guide-2016.pdf

[3] Ken Schwaber. Jeff Sutherland. (2013). The Scrum Guide. 13 de octubre de 2016, de

Scrum Alliance Sitio web: https://www.scrumalliance.org/why-scrum/scrum-guide

[4] Juan Palacio. Claudia Ruata. (2014). Gestión de proyectos con Scrum Manager. 13 de

octubre de 2016, de Scrum Manager® Sitio web:

http://www.scrummanager.net/files/sm_proyecto.pdf

[5] Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde. (2012). Scrum Primer. 13

de octubre de 2016, de InfoQ Sitio web:

http://scrumprimer.org/primers/es_scrumprimer20.pdf

[6] Guillermo Pantaleo. (2015). Metodologías ágiles. En Ingeniería de Software (92-93).

Buenos Aires, Argentina: Alfaomega.

[7] The New New Product Developement Game, por Hirotaka Takeuchi (Hitotsubashi

University) y Ikujiro Nonaka. Harvard Business Review, Enero-Febrero de 1986.

[8] Jeff Sutherland, John Scumniotales y Jeff McKenna concibieron, ejecutaron y

documentaron el primer Scrum para desarrollo ágil de software en 1993, utilizando el estudio

de gestión de equipos de Takeuchi y Nonaka como base.