ANÁLISIS Y DESARROLLO DE SOLUCIÓN DE SOFTWARE PARA APOYAR EL PROCESO DE GESTIÓN DE NÓMINA EN LA UNIVERSIDAD DISTRITAL, BASADO EN LOS LINEAMIENTOS DEL PROCESO DE DESARROLLO DE LA OAS. AUTORES: INGRID JULIETH CONTRERAS ROJAS CARLOS ANDRES CHUNG SOTO PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS ALEJANDRO PAOLO DAZA DIRECTOR UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2017
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ANÁLISIS Y DESARROLLO DE SOLUCIÓN DE SOFTWARE PARA
APOYAR EL PROCESO DE GESTIÓN DE NÓMINA EN LA UNIVERSIDAD
DISTRITAL, BASADO EN LOS LINEAMIENTOS DEL PROCESO DE
DESARROLLO DE LA OAS.
AUTORES:
INGRID JULIETH CONTRERAS ROJAS
CARLOS ANDRES CHUNG SOTO
PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE
SISTEMAS
ALEJANDRO PAOLO DAZA
DIRECTOR
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C.
2017
2
TABLA DE CONTENIDO
Pág.
CAPITULO 1 INTRODUCCION 7
CAPITULO 2 PLANTEAMIENTO DEL PROBLEMA 8
CAPITULO 3 OBJETIVOS 9
3.1 Objetivo general 9
3.2 Objetivos específicos 9
CAPITULO 4 JUSTIFICACION 10
CAPITULO 5 MARCO TEORICO 11
5.1 El proceso SCRUM/OAS 11
5.1.1 Información general SCRUM 11
5.1.2 Roles 12
5.1.2.1 Product Owner 12
5.1.2.2 Equipo de Desarrollo 13
5.1.2.3 Scrum Master 13
5.2 Elementos de SCRUM 15
5.2.1 Product Backlog 15
5.2.2 Sprint Backlog 17
5.2.3 Sprint (Iteración) 17
5.2.4 Sprint Planning Meeting 18
5.2.5 Scrum diario 19
5.2.6 Revisión de Sprint 20
5.2.7 Feedback 21
5.2.8 Release 22
5.2.9 Identificación de funcionalidades del software 22
3
5.3 Nómina 22
5.3.1 Retribución bruta 23
5.3.2 Descuentos en la nómina 23
5.3.3 Liquidación mesada pensional 24
5.3.3.1 Pensionado 24
5.3.3.2 Pensión de jubilación 24
5.3.3.3 Pensión de invalidez 26
5.3.3.4 Mesada pensional 28
5.3.3.5 Subsidio de libros 29
5.3.3.6 Subsidio familiar 29
5.3.3.7 Incremento cotización salud 30
5.3.4 Sustitutos 31
5.4 REST API 32
5.5 Beego 34
5.6 Prolog 35
5.7 Golog 36
CAPITULO 6 ALCANCE Y LIMITACIONES 37
6.1 Alcances 37
6.2 Limitaciones 37
CAPITULO 7 METODOLOGIA 38
7.1 Valores 38
7.2 Principios 39
7.3 Descripción y desarrollo de tareas 40
7.3.1 Creación y asignación de tareas en TULEAP 41
CAPITULO 8 RECURSOS Y PRESUPUESTO 44
8.1 Fuentes de financiación 44
4
8.2 Análisis costo-beneficio 44
CAPITULO 9 CRONOGRAMA 46
CAPITULO 10 DESARROLLO 48
10.1 Modelo de negocio actual 48
10.2 Arquitectura de información 48
10.2.1 Componentes 50
10.3 Modelo de datos TITAN 51
10.3.1 Descripción al modelo de datos TITAN 53
10.4 Modelo de datos para nomina pensionados 55
10.4.1 Descripción al modelo de datos pensionados 57
10.5 Integración de información y generalización para gestión
de nómina 58
10.6 Interfaces de programación de aplicaciones (API) 62
10.7 Parametrización de obligaciones de ley por medio de reglas de
negocio usando el intérprete Golog 64
10.8 Software 69
CAPITULO 11 ANALISIS Y RESULTADOS 71
11.1 Evaluación y cumplimiento de los objetivos 73
CAPITULO 12 CONCLUSIONES 75
CAPITLO 13 BIBLIOGRAFIA 77
5
INDICE DE ILUSTRACIONES
Figura 1. Visión general de flujo de un Project Scrum 11
Figura 2. Características de los papeles principales de Scrum 15
Figura 3. Arquitectura de Beego 34
Figura 4. Lógica de ejecución Beego 35
Figura 5. Epic de tareas en TULEAP. 41
Figura 6. Tarea análisis de nómina pensionados. 42
Figura 7. Story de comentarios de la tarea. 42
Figura 8. Tarea para creación de reglas 42
Figura 9. Tarea para implementación de reglas de negocio 42
Figura 10. Tarea para realizar pruebas con las reglas de negocio 43
Figura 11. Tarea para generación de CrudApi 43
Figura 12. Cronograma de actividades 46
Figura 13. Diagrama de tareas desarrolladas 47
Figura 14. Arquitectura de información de nómina 49
Figura 15. Modelo de datos TITAN 52
Figura 16. Tabla de concepto de TITAN 53
Figura 17. Tabla concepto por persona de TITAN 53
Figura 18. Tabla de tipo de nómina de TITAN 54
Figura 19. Acercamiento detalle de liquidación y pre liquidación de TITAN 54
Figura 20. Acercamiento liquidación de TITAN 54
Figura 21. Acercamiento pre liquidación de TITAN 55
Figura 22. Modelo de datos nomina pensionados 56
Figura 23. Interfaz de nóminas registradas 58
Figura 24. Interfaz preliquidacion de nómina 58
6
Figura 25. Interfaz de consulta de pensionados 58
Figura 26. Reglas de negocio sustitutos 60
Figura 27. Insert para informacion sustituto 61
Figura 28. Insert para informacion beneficiario 61
Figura 29. Tabla personal.beneficiarios 61
Figura 30. Interfaces de programación de aplicaciones 62
Figura 31. Lista de funciones Golog 63
Figura 32. Lista de controladores 63
Figura 33. Lista de Ruler 64
Figura 34. Vista principal del software 69
Figura 35. Nominas registradas 69
Figura 36. Registro para nuevas nominas 70
Figura 37. Detalle de preliquidacion 70
Figura 38. Resumen conceptos en EXCEL 71
Figura 39. Resumen conceptos en aplicativo 72
Figura 40. Interfaz de selección para preliquidacion 72
Figura 41. Resumen de preliquidacion 73
INDICE DE TABLAS
Tabla 1. Porcentaje salario convención colectiva de trabajo 25
Tabla 2. Porcentaje de liquidación según tiempo en la universidad 26
Tabla 3. Porcentaje por invalidez según porcentaje de disminución 27
Tabla 4. Recursos y su correspondiente presupuesto 44
Tabla 5. Costos para el cálculo de nómina de un mes 45
Tabla 6. Hechos en Prolog 64
Tabla 7. Reglas de negocio en Prolog 66
7
CAPITULO 1. INTRODUCCIÓN
La Universidad Distrital Francisco José de Caldas en su calidad como entidad
de educación superior tiene establecida dentro de su estructura un modelo
financiero como cualquier otro ente público, en el cual debe calcular, generar y
devengar todo tipo de obligaciones con sus empleados de acuerdo a la ley,
para este proceso se debe tener en cuenta diferentes categorías según el tipo
de contrato, estado de vinculación y labor desempeñada dentro de la
universidad, esto hace que sea necesario mes a mes llevar un control para la
liquidación de esas mensualidades definido como nómina.
La liquidación de nómina es un proceso en el cual se tiene en cuenta los
diferentes conceptos como honorarios, prestaciones y aportes varios, es de
carácter muy importante y delicado puesto que no debe generar errores y sus
resultados deben ser exactos ya que la universidad cuenta con recursos
definidos por el gobierno al iniciar el año y estos deben ser empleados para
cubrir los respectivos rubros y obligaciones que correspondan.
Para realizar la gestión de nómina la universidad cuenta con herramientas
como bases de datos y aplicaciones desagregadas, las cuales están definidas
para cada tipo de empleado (docentes de planta, docentes de vinculación
especial, empleados oficiales y administrativos) como también para los
pensionados, la anterior categorización ha generado un problema de
diversificación dentro del sistema, lo cual lleva a que el desarrollo de este
proyecto a cargo de la OAS (Oficina Asesora de Sistemas) se centre en la
construcción de una herramienta que permita realizar todo este proceso de
forma simplificada y efectiva teniendo en cuenta todos los conceptos que
integran la parte financiera de manera que se pueda establecer un modelo
flexible y que se adapte a las necesidades de la universidad en base a unas
reglas predefinidas donde se contempla una mejora constante.
8
CAPITULO 2. PLANTEAMIENTO DEL PROBLEMA
La liquidación de nómina dentro de la Universidad Distrital es un proceso
realizado de forma mensual por el área de tesorería utilizando herramientas
desactualizadas que muchas veces solo tienen en cuenta información antigua
de tablas lo cual hace trae como consecuencia que en ocasiones su gestión
sea propensa a errores en su ejecución y no refleje los resultados esperados a
pesar de ser algo repetitivo, a lo anterior hay que sumar la variedad de
contrataciones y nominas que existen, como lo son docentes, administrativos,
oficiales y pensionados, la cantidad de datos que se maneja respecto al
número de empleados es demasiada, lo cual genera demoras en todos los
procedimientos y afecta de manera significativa el funcionamiento de la
universidad.
El nivel de fiabilidad que da el sistema actual no es del todo confiable teniendo
en cuenta que muchas veces se debe realizar varias pre liquidaciones antes
de tener un informe definitivo para su aprobación, lo cual conlleva a que las
herramientas utilizadas no sean suficientes para llevar a cabo dicha labor, el
principal inconveniente radica en las diferentes características que contiene
cada nómina y la variedad de conceptos que se aplican en la liquidación de
las mismas, se hace necesario tener una sola herramienta que permita
relacionar toda la información de forma eficiente y unificada para así reducir
tiempos y costos, además garantizando la veracidad de los datos mostrados
en el proceso mes a mes.
La mayoría de nóminas tienen datos, conceptos y novedades comunes que
permiten realizar consultas y visualizar la información de forma más
simplificada, aquí es donde aparece la excepción con la nómina de
pensionados, la cual a diferencia de los empleados activos, debe tener en
cuenta datos y consultas únicas de los mismos, además de aplicar novedades
diferentes a las ya registradas, se aplican ciertos cálculos y aparecen otros
beneficios a tener en cuenta para la liquidación mensual, lo cual hace
necesario establecer un modelo donde se detallen las particularidades que
conlleva la categoría de pensionado sin dejar ninguna de lado, para así
garantizar que el proceso se ejecutara con éxito
9
CAPITULO 3. OBJETIVOS
3.1. Objetivo General
Establecer un modelo de datos y reglas que contemple la totalidad de los
conceptos relacionados con la nómina de pensionados de la Universidad
Distrital para apoyar el proceso de la OAS en el desarrollo de una herramienta
flexible y unificada basada en el modelo de desarrollo de la OAS.
3.2. Objetivos específicos
● Identificar los conceptos que caracterizan la categoría de pensionado dentro de la Universidad Distrital junto con los datos relacionados a dicha categorización que permitan integrar la liquidación de nómina.
● Parametrizar de forma asertiva las principales obligaciones establecidas por la ley para la liquidación de la nómina de pensionados lo que permita un mejor entendimiento al momento de su gestión.
● Integrar la información definida por la Universidad Distrital para el proceso de liquidación de nómina de pensionados de manera que la base de datos generada tenga interoperabilidad y sea de fácil acceso garantizando su confiabilidad.
● Realizar un análisis acerca del costo-beneficio que surge al
implementar el producto resultante de software, y así obtener una mejora en el proceso de liquidación de nómina.
10
CAPITULO 4. JUSTIFICACIÓN
La Universidad Distrital Francisco José de caldas en su continua tarea de
formar profesionales para el bien de la sociedad busca la construcción de un
modelo de entidad orientado hacia la calidad no solo académica, sino de todos
los procesos que la conforman, es por tanto que se hace necesario fortalecer
todos los departamentos que la componen, caso tal como lo es área
financiera, la cual como se descrito anteriormente tiene una gran tarea como
lo es la liquidación de nómina de todas las personas que tienen un vínculo
contractual con la institución, debido a esto es primordial proveer de
herramientas útiles que sean funcionales y que permitan la integración de toda
la información que se maneja en dicha área para tener un mayor control sobre
la gestión realizada y se reduzca el margen de errores que se puedan
generar. Debido a que los medios existentes en la actualidad para realizar
este proceso presentan problemas de interoperabilidad, no son adaptables a
las nuevas normas legales que rigen a la nómina y presentan una gran
división por la variedad de vinculaciones con las que cuenta la universidad, es
preciso generar una solución eficiente a las problemáticas descritas
anteriormente.
La OAS en su función como departamento generador de soluciones
tecnológicas e informáticas para la Universidad Distrital y de la mano de los
estudiantes de último semestre de Ingeniería de Sistemas se ha propuesto
desarrollar un proyecto que permita unificar todas las nóminas existentes junto
con la información relacionada a las mismas y que este actualizada con toda
la reglamentación correspondiente, la cual se flexible y adaptable según las
necesidades que se presenten a futuro. Este desarrollo establece una relación
de mutuo beneficio para todos los implicados ya que permite a los estudiantes
aplicar todos los conocimientos adquiridos en su formación y les brinda
experiencia en el ámbito laborar la cual es fundamental hoy en día para el
desarrollo como profesionales; por otra parte la OAS se beneficia al
actualizarse en las nuevas tecnologías y conocimientos de los estudiantes
para el desarrollo de soluciones por medio de software libre que dan como
resultado herramientas más robustas, funcionales y adaptables.
11
CAPITULO 5. MARCO TEORICO
5.1 El proceso SCRUM/OAS
La implementación exitosa de la metodología Scrum se debe a que se puede
aplicar de manera efectiva a cualquier proyecto en cualquier industria desde
proyectos pequeños o equipos con tan sólo seis miembros, hasta proyectos
grandes y complejos con cientos de miembros por equipo1.
5.1.1 Información general SCRUM
Scrum es una de las metodologías ágiles más populares. Es una metodología
de adaptación, iterativa, rápida, flexible y eficaz, diseñada para ofrecer un
valor significativo de forma rápida en todo el proyecto. Scrum garantiza
transparencia en la comunicación y crea un ambiente de responsabilidad
colectiva y de progreso continuo. El marco de Scrum, está estructurado de tal
manera que es compatible con los productos y el desarrollo de servicio en
todo tipo de industrias y en cualquier tipo de proyecto, independientemente de
su complejidad. Una fortaleza clave de Scrum radica en el uso de equipos
multi-funcionales, auto-organizados, y con poder que dividen su trabajo en
ciclos de trabajo cortos y concentrados llamados Sprints2.
Figura 1. Visión general de flujo de un Project Scrum.
1 2 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
12
5.1.2 Roles
Son aquellos papeles que obligatoriamente se requieren para producir el
producto o servicio del proyecto. Las personas a quienes se les asignan roles,
están plenamente comprometidas con el proyecto y son las responsable del
éxito de cada iteración y del resultado final. En un Equipo Scrum se espera
que intervengan tres roles: Product Owner, Equipo de Desarrollo y
ScrumMaster.3
5.1.2.1 Product Owner
El Product Owner es la persona responsable del éxito del producto desde el
punto de vista de los stakeholders. Sus principales responsabilidades son:
● Determinar la visión del producto, hacia dónde va el equipo de desarrollo.
● Gestionar las expectativas de los stakeholders. ● Recolectar los requerimientos. ● Determinar y conocer en detalle las características funcionales de alto y
de bajo nivel. ● Generar y mantener el plan de entregas (release plan): fechas de
entrega y contenidos de cada una. ● Maximizar la rentabilidad del producto. ● Determinar las prioridades de cada una de las características por sobre
el resto. ● Cambiar las prioridades de las características según avanza el
proyecto, acompañando así los cambios en el negocio. ● Aceptar/rechazar el producto construido durante el Sprint y proveer
feedback valioso para su evolución. ● Participar de la revisión del Sprint junto a los miembros del Equipo de
Desarrollo para obtener feedback de los stakeholders. El Product Owner se focaliza en maximizar la rentabilidad del producto. La
principal herramienta con la que cuenta para poder realizar esta tarea es la
priorización. De esta manera puede reordenar la cola de trabajo del equipo de
desarrollo para que éste construya con mayor anticipación las características
o funcionalidades más requeridas por el mercado o la competitividad
comercial4.
Otra responsabilidad importante del Product Owner es la gestión de las
expectativas de los stakeholders, mediante la comprensión completa de la
problemática de negocio y su descomposición, hasta llegar al nivel de
requerimientos funcionales.
3 4 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
13
5.1.2.2 Equipo de Desarrollo
El equipo de desarrollo está formado por todos los individuos necesarios para
la construcción del producto en cuestión. Es el único responsable por la
construcción y calidad del producto. El equipo de desarrollo es auto-
organizado. Es el mismo equipo quien determina la forma en que realizará el
trabajo y cómo resolverá cada problemática que se presente. La
delimitación de esta auto-organización, está dada por el objetivo a cumplir:
transformar las funcionalidades comprometidas en software funcionando y con
calidad productiva, o en otras palabras, producir un incremento funcional
potencialmente entregable.
Es recomendable que un equipo de desarrollo se componga de hasta nueve
(9) personas. Cada una de ellas debe poseer todas las habilidades necesarias
para realizar el trabajo requerido. Esta característica se conoce como multi-
funcionalidad y significa que dentro del equipo de desarrollo no existen
especialistas exclusivos, sino más bien individuos generalistas con
capacidades especiales. Lo que se espera de un miembro de un equipo de
desarrollo es que no solo realice las tareas en las cuales se especializa, sino
también todo lo que esté a su alcance para colaborar con el éxito del equipo.
El equipo de desarrollo tiene tres (3) responsabilidades tan fundamentales
como indelegables. La primera es proveer las estimaciones de cuánto
esfuerzo será requerido para cada una de las características del producto. La
segunda responsabilidad es comprometerse al comienzo de cada Sprint a
construir un conjunto determinado de características en el tiempo que dura el
mismo. Y finalmente, también es responsable por la entrega del producto
terminado al finalizar cada Sprint.5
5.1.2.3 Scrum Master
El Scrum Master, es el Coach del equipo y es quien lo ayuda a alcanzar su
máximo nivel de productividad posible. Es un líder, facilitador, provocador,
detective y soplador de brasas. Líder por ser un ejemplo a seguir, facilitador
por fomentar contextos de apertura y discusión donde todos pueden expresar
sus opiniones y lograr consensos comunes, provocador por desafiar las
estructuras rígidas y las antiguas concepciones sobre cómo deben hacerse las
cosas, detective por involucrarse activamente en la búsqueda e identificación
de indicios y pistas en la narrativa del equipo y los individuos y finalmente,
soplador de brasas, “un socio facilitador del aprendizaje, que acompaña al otro
en una búsqueda de su capacidad de aprender para generar nuevas
respuestas” conectar a las personas con sus pasiones, con sus fuegos,
muchas veces apagados.
5 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
14
Se espera, además, que el Scrum Master acompañe al equipo de trabajo en
su día a día y garantice que todos, incluyendo al Product Owner, comprendan
y utilicen Scrum de forma correcta.
Las responsabilidades principales del Scrum Master son:
● Velar por el correcto empleo y evolución de Scrum. ● Facilitar el uso de Scrum a medida que avanza el tiempo. Esto incluye
la responsabilidad de que todos asistan a tiempo a las daily standup meetings, reviews y feedbacks.
● Asegurar que el equipo de desarrollo sea multi-funcional y eficiente. ● Proteger al equipo de desarrollo de distracciones y trabas externas al
proyecto. ● Detectar, monitorear y facilitar la remoción de los impedimentos que
puedan surgir con respecto al proyecto y a la metodología. ● Asegurar la cooperación y comunicación dentro del equipo.
Además de estas cuestiones, el Scrum Master debe detectar problemas y
conflictos interpersonales dentro del equipo de trabajo. Para respetar la
filosofía auto-organizativa del equipo, lo ideal es que el equipo mismo sea
quien resuelva estas cuestiones. En el caso de no poder hacerlo, deberá
involucrarse al Scrum Master y eventualmente a niveles más altos de la
gerencia.
El Scrum Master es un Líder Facilitador, no es casualidad la aparición de un
nuevo nombre o rol. Este nuevo concepto del enfoque ágil, representa el
cambio respecto de las responsabilidades y el modelo de gestión de los
gerentes de proyectos tradicionales en relación al equipo de trabajo. El Scrum
Master puede ser visto como un Facilitador o Coach, incluso muchas veces se
lo referencia así en lugar de Scrum Master. Su responsabilidad es asegurar
que se cumpla con el proceso de Scrum sin interferir directamente en el
desarrollo del producto final. Es importante establecer que el equipo de Scrum
elige la forma de trabajo que más prefiera, siempre que se cumplan las pautas
básicas de Scrum, por ello mientras lo hagan no existe una forma “errónea” de
trabajar.
El rol del Scrum Master también incluye asegurar que el desarrollo del
producto tenga la mayor probabilidad de ser completado de forma exitosa.
Para lograr este cometido, trabaja de cerca con el Product Owner asegurando
una correcta priorización de los requerimientos, por un lado, y con el equipo
de desarrollo para convertir los requerimientos en un producto funcionando,
por el otro.
Por lo que hemos visto, el Scrum Master tiene un rol más indirecto que un
Gerente de Proyectos tradicional, a pesar de esto es un rol vital para el éxito
de Scrum. Para todo Gerente de Proyectos tradicional, el cambio hacia esta
15
nueva filosofía de gestión es desafiante. Se dice que “Scrum es fácil, hacer
Scrum es difícil”. Esta afirmación tiene sus fundamentos en la idea de que una
cosa es aprender Scrum y otra muy diferente es aplicar Scrum exitosamente.
Emprender este camino significa adoptar una filosofía de liderazgo servil por
sobre el comando y control.
Finalmente, cuando un ScrumMaster logra cubrir exitosamente su rol, la
implementación de Scrum sucede sin sobresaltos. Las responsabilidades del
Scrum Master deberían cubrir la totalidad de su tiempo. Si bien hay casos en
los que el Scrum Master cumple, además de su rol, el rol de desarrollador, no
siempre es la mejor de las situaciones ya que ambas responsabilidades
podrían llegar a exceder la disponibilidad de una sola persona, y así alguno de
ambos roles no estaría siendo cubierto satisfactoriamente.6
Figura 2. Características deseadas de los papeles principales de Scrum.
5.2 Elementos de SCRUM
El proceso de Scrum posee una mínima cantidad necesaria de elementos
formales para poder llevar adelante un proyecto de desarrollo. A continuación
describiremos cada uno de ellos.7
5.2.1 Product Backlog:
El primero de los elementos, y principal de Scrum, es el Product Backlog
también conocido como Pila del Producto.
El Product Backlog es básicamente un listado de ítems o características del
producto a construir, mantenido y priorizado por el Product Owner. Es
6 7 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
16
importante que exista una clara priorización, ya que es esta priorización la que
determinará el orden en el que el equipo de Proyectos Ágiles con Scrum
desarrollo transformará las características en un producto funcional acabado.
Esta prioridad es responsabilidad exclusiva del Product Owner y, aunque el
equipo de desarrollo pueda hacer sugerencias o recomendaciones, es el
Product Owner quién tiene la última palabra sobre la prioridad final de los
ítems del Product Backlog, teniendo en cuenta el contexto de negocio. Una
forma de priorizar los ítems del Product Backlog es según su valor de negocio.
Podemos entender el valor de negocio como la relevancia que un ítem tiene
para el cumplimiento del objetivo de negocio que estamos buscando.
Un enfoque diferente de medir la prioridad de un determinado ítem del
Backlog es calcular el beneficio económico que se obtendrá en función de la
inversión que se deba realizar. Esto, si bien es una simple fórmula
matemática, tiene implícita la problemática de encontrar o conocer el valor
económico ganado por la incorporación de una determinada característica a
un producto. Una vez identificada, el cálculo es relativamente simple:
ROI = valor de negocio/costo
Donde el costo representa el esfuerzo necesario para la construcción de una
determinada característica de un producto y el valor de negocio es el crédito
económico obtenido por su incorporación.
Ya sea que los ítems del Backlog se prioricen por valor de negocio o por ROI,
en cualquier caso llamémosle “priorizar por importancia”, éstos pueden verse
complementariamente afectados por el nivel de riesgo asociado a cada uno de
ellos. De esta manera, se debe realizar una construcción iterativa y evolutiva
de Scrum para mitigar riesgos en forma implícita: construyendo primero
aquellas características con mayor riesgo asociado y dejando las que poseen
menor riesgo para etapas posteriores.
Se recomienda que los Product Backlog Ítems (PBIs) de baja importancia y
alto riesgo sean evitados, por ejemplo, transfiriéndolos o eliminándolos del
alcance.
Un Backlog Eficiente es cuando se obtiene el mayor beneficio con el menor
esfuerzo posible. Este concepto llevado al Product Backlog significa invertir el
esfuerzo de exploración y especificación de la manera más inteligente posible
para evitar re-trabajos y desperdicios.
Por esto, se debe fomentar un Product Backlog donde sus ítems más
prioritarios están expresados con un nivel de detalle mucho mayor que los
ítems de menor prioridad, los cuales están descritos a un nivel más alto, ya
que son los más susceptibles de ser alterados o reemplazados.
17
5.2.2 Sprint Backlog:
Es el conjunto de Product Backlog Ítems (PBIs) que fueron seleccionados para
trabajar en ellos durante un cierto Sprint, conjuntamente con las tareas que el
equipo de desarrollo ha identificado que debe realizar para poder crear un
incremento funcional potencialmente entregable al finalizar el Sprint.
El resultado de cada Sprint debe ser un incremento funcional potencialmente
entregable. Incremento funcional porque es una característica funcional nueva
(o modificada) de un producto que está siendo construido de manera
evolutiva. El producto crece con cada Sprint. Potencialmente entregable
porque cada una de estas características se encuentra lo suficientemente
validada y verificada como para poder ser desplegada en producción (o
entregada a usuarios finales) si así el negocio lo permite o el cliente lo desea.8
5.2.3 Sprint (Iteración)
Las iteraciones en Scrum se conocen como Sprints. Scrum, como todos los
enfoques ágiles, es un proceso de desarrollo incremental e iterativo. Esto
significa que el producto se construye en incrementos funcionales entregados
en periodos cortos para obtener feedback frecuente.
En general, Scrum tiene una duración de Sprint de entre 1 y 2 semanas y el
objetivo será mantener esta duración constante a lo largo del desarrollo del
producto, lo que implicará que la duración de una iteración no cambie una vez
que sea establecida.
Como excepción se pueden presentar aquellas situaciones donde el equipo
mismo decida probar con iteraciones más largas o más cortas, pero siempre
entre 1 y 2 semanas. Esta decisión se basa principalmente en la volatilidad del
contexto: mientras más volátil sea (negocio cambiante, requerimientos
desconocidos, etc.) más corta será la duración del Sprint. Lo importante es
recordar que se logra mayor ritmo y previsibilidad teniendo Sprints de duración
constante.
Se encontrarán situaciones en donde el equipo de desarrollo se atrase o se
adelante. En estos casos, la regla del timeboxing no nos permitirá modificar
(adelantar o postergar) la fecha de entrega o finalización del Sprint. La
variable de ajuste en estos casos será el alcance del Sprint, esto es, en el
caso de adelantarse se deberá incrementar el alcance del Sprint agregando
nuevos Product Backlog Ítems (PBIs) y reducirlo en el caso de retraso. 9
8 9 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
18
5.2.4 Sprint Planning Meeting (Planificación de Sprint)
Al comienzo de cada Sprint se realiza una reunión de planificación del Sprint
donde serán generados los acuerdos y compromisos entre el equipo de
desarrollo y el Product Owner sobre el alcance del Sprint.
Esta reunión de planificación habitualmente se divide en dos partes con
finalidades diferentes: una primera parte estratégica y enfocada en el “qué”, y
una segunda parte táctica cuyo hilo conductor principal es el “cómo”.
Parte uno: ¿Qué trabajo será realizado? El objetivo buscado durante esta
parte de la reunión es identificar “qué” es lo que el equipo de desarrollo va a
realizar durante el Sprint, es decir, todos aquellos Product Backlog Items
(PBIs) que el equipo se comprometerá a transformar en un producto
funcionando y utilizable o en otras palabras: incremento funcional
potencialmente entregable.
El Product Owner y el equipo de desarrollo deben participar de esta parte de
la reunión como protagonistas principales. El Scrum Master, al tiempo que
facilita la reunión, también debe asegurar que cualquier stakeholders del
proyecto que sea requerido para profundizar en detalles esté presente o sea
contactado.
El equipo de desarrollo utiliza su capacidad productiva (también conocida
como Velocidad o Velocity), obtenida de los Sprints pasados, para conocer
hasta cuánto trabajo podría comprometerse a realizar. Esto determinaría en
un principio cuáles serían los Product Backlog Items (PBIs) comprometidos en
este Sprint. La razón es que cada uno de los ítems del Product Backlog debe
ser discutido para entender cuáles son sus criterios de aceptación y así
conocer en detalle qué se esperará de cada uno. De esta manera, el equipo
de desarrollo discutirá con el Product Owner sobre cada Product Backlog
Items (PBIs) y generará un compromiso de entrega para aquellos que
considera suficientemente claros como para comenzar a trabajar y que
además podrían formar parte del alcance del Sprint que está comenzando. A
esto se lo conoce como planificación basada en compromisos o Commitment-
based Planning. Al finalizar esta primera parte de la reunión, los stakeholders
involucrados (si los hubiese) se retirarán, dejando así al producto Owner, al
Scrum Master y al equipo de desarrollo para que den comienzo a la segunda
parte de esta reunión, que se describe a continuación.
Parte dos: ¿Cómo será realizado el trabajo? Durante este espacio de tiempo
el equipo de desarrollo determinará la forma en la que llevará adelante el
trabajo. Esto implica la definición inicial de un diseño de alto nivel, el cual será
refinado durante el Sprint mismo y la identificación de las actividades que el
equipo en su conjunto tendrá que llevar a cabo.
19
Se espera que el diseño sea emergente, es decir, que surja de la necesidad
del equipo de desarrollo a medida que éste avance en el conocimiento del
negocio. Por esta misma razón es que indicamos la no necesidad de realizar
un diseño completo y acabado de lo que será realizado durante el Sprint. En
cambio, se buscará un acuerdo de alto nivel que será bajado a detalle durante
la ejecución de la iteración.
Esto mismo sucede con las actividades del Sprint, es decir que no es
estrictamente necesario enumerar por completo todas las actividades que
serán realizadas durante la iteración ya que muchas aparecerán a medida que
se avanza. Adicionalmente, las actividades deben durar un día. Esto permitirá
detectar bloqueos o retrasos durante las reuniones diarias.
Al finalizar esta reunión, el equipo habrá arribado a un Sprint Backlog o
Commited Backlog que representa el alcance del Sprint en cuestión. Este
Sprint Backlog es el que se coloca en el taskboard (pizarra de actividades) del
equipo. Se dará comienzo al desarrollo del producto para este Sprint.10
5.2.5 Scrum Diario
Uno de los beneficios de Scrum está dado por el incremento de la
comunicación dentro del equipo de proyecto. Esto facilita la coordinación de
acciones entre los miembros del equipo de desarrollo y el conocimiento “en
vivo” de las dependencias de las actividades que realizan.
Por otro lado, se requiere además aumentar y explicitar los compromisos
asumidos entre los miembros del equipo de Proyectos Ágiles con Scrum
desarrollo y dar visibilidad a los impedimentos que surjan del trabajo que está
siendo realizando y que muchas veces nos impiden lograr los objetivos.
Estos tres objetivos: 1) incrementar la comunicación 2) explicitar los
compromisos y 3) dar visibilidad a los impedimentos, son logrados mediante
las reuniones diarias de Scrum (Daily Scrums). Estas reuniones tienen, como
su nombre lo indica, una frecuencia diaria y no deberían llevar más de 10
minutos. Estos 10 minutos son un timebox, es decir, que no se pueden
superar.
A la reunión diaria acude el ScrumMaster y el equipo de trabajo. En el caso de
que sea necesario, se podrá requerir la presencia del Product Owner y de los
stakeholders. De todas maneras, se intenta que sea una reunión abierta
donde cualquier interesado en escuchar lo que sucede pueda participar en
calidad de observador. Se recomienda que los observadores no participen
activamente en la reunión, y mucho menos, que soliciten a los miembros del
equipo justificación del progreso y explicación de los problemas.
10 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
20
Esta reunión es facilitada por el Scrum Master. Todos y cada uno de los
miembros toman turnos para responder las siguientes tres preguntas, y de esa
manera comunicarse entre ellos:
1. ¿Qué hice desde la última reunión diaria hasta ahora?
2. ¿En qué voy a estar trabajando desde ahora hasta la próxima reunión
diaria?
3. ¿Qué problemas o impedimentos tengo?
Es importante destacar que en ningún momento se trata de una reunión de
reporte de avance o status al Scrum Master ni a otras personas. Por el
contrario, es un espacio de estricta comunicación entre los miembros del
equipo de desarrollo. El objetivo de la primera pregunta (¿qué hice?) es
verificar el cumplimiento de los compromisos contraídos por los miembros del
equipo en función del cumplimiento del objetivo del Sprint. La finalidad de la
segunda pregunta (¿qué voy a hacer?) es generar nuevos compromisos hacia
el futuro. Cuando hablamos de compromisos, hacemos referencia a aquéllos
que los miembros del equipo asumen ante sus compañeros.
La última pregunta (¿qué problemas?) apunta a detectar y dar visibilidad a los
impedimentos. Estos impedimentos no se resuelven en esta reunión, sino en
posteriores. Es responsabilidad del ScrumMaster que se resuelvan lo antes
posible, generando las reuniones que sean necesarias e involucrando a las
personas correctas.
En el caso de que los Product Backlog Items (PBIs) del Sprint se hubiesen
podido dividir en actividades de menos de un día: si una de estas actividades
se encuentra en progreso durante dos reuniones diarias seguidas (con 24hs
de separación) claramente se advierte un retraso.
5.2.6 Revisión de Sprint
Al finalizar cada Sprint se realiza una reunión de revisión del Sprint (Sprint
Review), donde se evalúa el incremento funcional potencialmente entregable
construido por el equipo de desarrollo (el “qué”). En esta reunión el Equipo
Scrum y los Stakeholders revisan el resultado del Sprint. Cuando decimos
“resultado” hablamos de “producto utilizable” y “potencialmente entregable”
que el los interesados utilizan y evalúan durante esta misma reunión,
aceptando o rechazando así las funcionalidades construidas.
Los Stakeholders evalúan el producto construido y proveen feedback. Este
feedback puede ser acerca de cambios en la funcionalidad construida o bien
nuevas funcionalidades que surjan al ver el producto en acción.
21
Toda la retroalimentación que los stakeholders aporten debe ser ingresada
como PBIs en el Product Backlog. Para esto, los PBIs nuevos deben ser
priorizados con respecto a todos los ya existentes en el Product Backlog.
También es necesario que estos nuevos PBIs sean estimados antes de
incluirlos como parte del Product Backlog ya que el Product Owner deberá
decidir cuáles de los PBIs existentes cuya estimación de costo es similar a la
de los nuevos PBIs deben ser eliminados para no incurrir en el incremento
desmedido del alcance (Scope Creeping): si se agrega trabajo entonces
debemos quitar trabajo de otro lado. El Product Owner cuenta para esto con la
priorización de los ítems del Backlog como herramienta para la toma de este
tipo de decisiones.
En el caso de que una funcionalidad sea rechazada, el PBI correspondiente
reingresa al Product Backlog con máxima prioridad, para ser tratado en el
siguiente Sprint. La única excepción a esta regla es que el Product Owner, por
decisión propia, prefiera dar mayor prioridad a otros. En este caso, nada debe
salir del Backlog ya que esto no sería considerado como un incremento en el
alcance.
Al finalizar la revisión del producto, es recomendable definir la fecha de la
próxima reunión de revisión, que corresponderá al final del Sprint siguiente.
De este modo ya se tendrán las agendas bloqueadas a tal fin.11
5.2.7 Feedback
En una metodología como Scrum, la retrospección del equipo es el corazón de
la mejora continua y las prácticas emergentes. Mediante el mecanismo de
retrospección, el equipo reflexiona sobre la forma en la que realizó su trabajo y
los acontecimientos que sucedieron en el Sprint que acaba de concluir para
mejorar sus prácticas. Todo esto sucede durante la reunión de feedback.
Esta reunión tiene lugar inmediatamente después de la reunión de revisión.
Mientras que la reunión de revisión se destina a revisar el producto (el “qué”),
la feedback se centra en el proceso (el “cómo”). Este tipo de actividad necesita
un ambiente seguro donde el Equipo Scrum pueda expresarse libremente, sin
censura ni temores, por lo cual se restringe solo al Equipo de Desarrollo, al
ScrumMaster y el Product Owner. En el caso de que se requiera la
participación de stakeholders o gerentes, estos podrán ser convocados.
Valiéndose de técnicas de facilitación y análisis de causas raíces, se buscan
tanto fortalezas como oportunidades de mejora. Luego, el Equipo Scrum
decide por consenso cuáles serán las acciones de mejora a llevar a cabo en el
11 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
22
siguiente Sprint. Estas acciones y sus impactos se revisarán en la próxima
reunión de feedback.12
5.2.8 Release
El release se compone de dos procesos
Envío de entregables: los Accepted Deliverables se les entregan a los
Socios relevantes. Un acuerdo formal llamado Working Deliverables
Agreement documenta la finalización con éxito del Sprint.
Feedback del proyecto: En este proceso, que completa el proyecto, los
socios y miembros principales del Equipo Principal de Scrum se reúnen
para hacer una feedback del proyecto e identificar, documentar e
internalizar las lecciones aprendidas. A menudo, estas lecciones llevan
a la documentación de Agreed Actionable Improvement, que se aplicará
en futuros proyectos.13
5.2.9 Identificación de Funcionalidades del Software
Para realizar la identificación de las funcionalidades se deberá tener en cuenta
todos los roles identificados, efectuando sucesivas “pasadas” por todos los
procesos de negocio y evaluando que cada uno de los roles involucrados en
ellos cuenten con las funcionalidades requeridas para la realización de sus
objetivos. Al igual que la identificación de roles, esta actividad se realiza en
forma colaborativa junto al Product Owner y la mayor cantidad de miembros
del equipo posible.14
5.3 La nómina
La nómina es el sistema contable de la empresa, utilizada para mantener un
registro con el salario, cargo, deducciones, así como otras novedades 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 a dicho salario, bien sea por descuentos obligatorios marcados por
la legislación vigente, 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 básico que se debe respetar en todo
caso. El contenido mínimo de la nómina debe incluir al menos:
Datos identificativos de la empresa, dirección del centro de trabajo y
código cuenta cotización en el que está el trabajador incluido.
12 13 14 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
23
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 saláriales 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, por otro tipo de deducciones que
haya que aplicarle a la nómina, como anticipos o embargos de nómina.
Líquido a percibir, dado que la nómina tiene consideración de
documento acreditado del pago de salarios cerrando los pagos
pendientes al trabajador para el periodo estipulado.
Detalle de las bases de cotización de la nómina.
Lugar de emisión, firma y sello por la empresa y el trabajador.
Hay que remarcar que aunque estos elementos sean básicos, 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
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:
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 ampliación en la empresa.
Percepciones extra salariales: 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 especio como el plus por desgaste
de herramientas.
5.3.2 Descuentos en la nómina
En la nómina podemos encontrar dos tipos de descuento diferentes, bien sean
los descuentos obligatorios por ley o también los descuentos que se deban
aplicar por cualquier otro tipo de normativas.
24
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. La liquidación de nómina, los descuentos y
los diferentes factores que se tienen en cuenta dependen directamente del
tipo de vinculación que tenga la persona natural o jurídica con el empleador, el
particular en la Universidad Distrital es la existencia de varios tipos de
vinculación y de categorías, en el caso de pensionados existen los de tipo
oficial, administrativo y docente.
5.3.3 Liquidación de mesada pensional
5.3.3.1 Pensionado
El concepto que permite nombrar a una persona cuanto esta jubilada: ya no se
encuentra física o mentalmente capacitada para continuar realizando el
trabajo que hasta entonces hacía.14
5.3.3.2 Pensión de jubilación
Es el reconocimiento a los funcionarios administrativos al cumplir la edad y el
tiempo de servicio requerido para tal fin, estipulados en la ley, convenciones
colectivas, laudos arbitrales y demás.
Articulo 10 Convención Colectiva de Trabajo suscrita para 1992 y 1993
PJ=SB+GR+ST+PAL+PT+PAN (HE+RN+PS+PV+V+PN+Q+VI)/12X%*
Dónde:
SB= Salario Básico
GR= Gastos de Representación
ST= Subsidio de transporte
PAL= Prima de Alimentación
PT= Prima Técnica
PAN= Prima de Antigüedad
PV= Prima de Vacaciones
V= Vacaciones
PN= Prima de Navidad
14 Marco normativo y procedimental Nomina Funcionarios y Pensionados UD. OAS. OFICINA ASESORA DE SISTEMAS, (OAS).
25
Q= Quinquenio
HE= Horas Extras
RN= Recargos Nocturnos
PS= Prima de Servicios
VI= Vacaciones individuales
PJ= corresponde a la sumatoria de los valores devengados en cada factor, en
los últimos doce meses anteriores a la fecha de retiro, dividido por doce y el
resultado será el valor del factor con que se liquidará.
Para el caso de las Horas Extras, recargos nocturnos y prima de servicios
corresponde a los recibidos los doce meses anteriores a la fecha de retiro.
Para las Vacaciones Individuales, este corresponde a los recibidos en los
doce meses anteriores a la fecha de retiro, siempre y cuando haya sido por
ciento ochenta (180) días o más dentro de este período.
PORCENTAJE, corresponde al porcentaje de salario de acuerdo con la
siguiente tabla:
TIEMPO
UNIVERSIDAD
TIEMPO OTRAS EDAD PORCENTAJE
20 años Cualquiera 100
19 años 1 año privado Cualquiera 96
18 años 2 años privado Cualquiera 92
17 años 3 años privado Cualquiera 88
16 años 4 años privado Cualquiera 84
15 años 5 años privado Cualquiera 80
10 años 10 años estado Cualquiera 70
Tabla 1. Porcentaje de salario Convención Colectiva de Trabajo
Más 0,3333 por mes después de los 15 años de servicio a la Universidad.
En caso de despido sin justa causa a un trabajador que tenga 15 o más años
de servicio continuo o discontinuo, de tiempo completo, la Universidad lo
pensionará desde la fecha de su despido así:
26
TIEMPO UNIVERSIDAD PORCENTAJE
20 años 100
19 años 96
18 años 92
17 años 88
16 años 84
15 años 80
Tabla 2. Porcentaje de liquidación según tiempo en la universidad.
Las tablas anteriores son basadas en derechos convencionales que poseen
los funcionarios Administrativos de la Universidad, lo cual no excluye que en
casos particulares se apliquen los porcentajes y requisitos que fija la Ley.15
5.3.3.3 Pensión de invalidez
Es una prestación social a que tienen derecho los funcionarios administrativos
de la Universidad que se encuentren en situación de invalidez transitoria o
permanente. Se considera inválido el empleado oficial que ha perdido su
capacidad para continuar ocupándose en la labor que constituye su actividad
habitual o la profesión a que se ha dedicado ordinariamente, en un porcentaje
igual o superior al 75% (Artículo 65 del Decreto 1848 de 1969) y sin tener en
cuenta el tiempo de servicio.
Liquidación:
Para liquidar la pensión de invalidez se procederá así:
PI = (SB+GR+ST+PAL+PT+PAN (HE+RN+PS+PV+V+PN+Q+VI)/12) X % *
SB= Salario Básico
GR= Gastos de Representación
ST= Subsidio de Transporte
PAL= Prima de Alimentación
PT= Prima Técnica
15 Marco normativo y procedimental Nomina Funcionarios y Pensionados UD. OAS. OFICINA ASESORA DE SISTEMAS, (OAS).
27
PAN= Prima de Antigüedad
HE= Horas extras
RN= Recargos nocturnos
PS= Prima de Servicios
PV= Prima de Vacaciones
V= Vacaciones
PN= Prima de Navidad
Q= Quinquenio
VI= Vacaciones Individuales *
PI= corresponde a la sumatoria de los valores devengados en cada factor, en
los últimos doce meses anteriores a la fecha de culminación de los ciento
ochenta (180) días de incapacidad, se dividirá por doce y el resultado será el
valor del factor con que se liquidará.
Para las Horas Extras y Recargos Nocturnos, estos valores corresponden a
los recibidos los doce meses anteriores a la fecha de culminación de los ciento
ochenta (180) días de incapacidad, siempre y cuando haya sido por ciento
ochenta (180) días o más dentro de este período.
En el caso de las Vacaciones Individuales, corresponde a los recibidos en los
doce meses anteriores a la fecha de culminación de los ciento ochenta días de
incapacidad, siempre y cuando haya sido por ciento ochenta (180) días o más
dentro de este período.
% PORCENTAJE, corresponde al porcentaje de salario de acuerdo con la
siguiente tabla:
PORCENTAJE DE DISMINUCION PORCENTAJE
Más del 95% 100
Más de 75% y menos del 95% 75
Igual 75% 50
Tabla 3. Porcentaje de pensión por invalidez según porcentaje de disminución.
PS = Corresponde a la última devengada en los doce (12) meses anteriores a
la fecha de culminación de los ciento ochenta (180) días de incapacidad.
28
PV = Corresponde a la última devengada en los doce (12) meses anteriores a
la fecha de culminación de los ciento ochenta (180) días de incapacidad.
V =Corresponde a la última devengada en los doce (12) meses anteriores a la
fecha de culminación de los ciento ochenta (180) días de incapacidad.
PN = Corresponde a la última devengada en los doce (12) meses anteriores a
la fecha de culminación de los ciento ochenta (180) días de incapacidad.
Q = Corresponde al último devengado en los doce (12) meses anteriores a la
fecha de culminación de los ciento ochenta (180) días de incapacidad.16
5.3.3.4 Mesada Pensional
Definición
Reconocimiento y pago de la pensión de jubilación. De acuerdo al monto de la
liquidación de la pensión de jubilación o pensión de invalidez otorgada
mediante acto administrativo, se realizan los pagos correspondientes. El
registro correspondiente al valor como tal, está generado desde una tabla que
contiene la información correspondiente.
Liquidación
La liquidación de los días está determinada desde la fecha del acto
administrativo de reconocimiento.
Mesada Pensional = Pensión * 30
Tipo de Pensionados
PA: Pensionado Administrativo
PD: Pensionado Docente
PO: Pensionado Oficial
Ajuste Mesada Pensional: de conformidad con los actos administrativos que
ordenen los ajustes correspondientes a las mesadas pensionales, se incluirá
en el mes de reconocimiento los días a que haya lugar para terminar el mes y
posteriormente dicho valor ya serán incluidos en el pago mensual del mes
siguiente.
Ajuste = Pensión /30 * No. Días
16 Marco normativo y procedimental Nomina Funcionarios y Pensionados UD. OAS. OFICINA ASESORA DE SISTEMAS, (OAS).
29
5.3.3.5 Subsidio de libros
Definición
De conformidad con la Convención Colectiva los pensionados tienen derecho
a un subsidio de libros de acuerdo a:
Art. 14 CCT 1990…. “A partir del primero de enero de 1990, la Universidad
Distrital reconoce y paga el auxilio educativo a todos los trabajadores activos y
pensionados e hijos de estos que cursen estudios así:
a) Guardería, preescolar, primaria, secundaria y validación del bachillerato,
una suma equivalente a 1.0 salario mínimo convencional vigente anualmente
b) Técnicos, tecnológicos, carreras intermedias, universitarias, cursos de
especialización, de postgrados, magíster, una suma equivalente a 1.0 salario
mínimo convencional vigente semestralmente……”
Liquidación
Está determinada por el salarios mínimos *
El concepto respectivo está incluido como una novedad 999, de acuerdo a la
certificación o documento soporte que acredita dicho derecho.
PA= Valor subsidio x No. de beneficiarios
5.3.3.6 Subsidio familiar
Definición
Convención Colectiva de 1992, Artículo 2, “....Parágrafo 2. Los pensionados
de la Universidad Distrital que hayan logrado su estatus pensional conforme al
régimen convencional, que reciban mesadas inferiores a cinco salarios
mínimos convencionales vigentes recibirán el subsidio familiar en los términos
en los que se les reconoce a los trabajadores activos” Este subsidio se
encuentra parametrizado para:
1. Padre
2. Madre
3. Hijo
Liquidación
Para la presente vigencia están determinados dos (2) montos diferentes así:
PA= Valor subsidio x No. de beneficiarios
30
Valor subsidio = $65.900 *
PO= Valor subsidio x No. de beneficiarios
Valor Subsidio = (SMLC / 30) * 2.55 *
1.752.652/30*2.55= 148.975
5.3.3.7 Incremento cotización salud
De conformidad con lo establecido en:
Ley 100 de 1993, “....ARTICULO 143. Reajuste pensional para los actuales
pensionados. A quienes con anterioridad al 1o. de enero de 1994 se les
hubiere reconocido la pensión de vejez o jubilación, invalidez o muerte,
tendrán derecho, a partir de dicha fecha, a un reajuste mensual equivalente a
la elevación en la cotización para salud que resulte de la aplicación de la
presente Ley.
La cotización para salud establecida en el Sistema General de Salud para los
pensionados está, en su totalidad, a cargo de éstos, quienes podrán
cancelarla mediante una cotización complementaría durante su período de
vinculación laboral.
El Consejo Nacional de Seguridad Social en Salud podrá reducir el monto de
la cotización de los pensionados en proporción al menor número de
beneficiarios y para pensiones cuyo monto no exceda de tres (3) salarios
mínimos legales
PARAGRAFO TRANSITORIO. Sólo por el año de 1993, los gastos de salud
de los actuales pensionados del ISS se atenderá con cargo al Seguro de IVM
y hasta el monto de la cuota patronal.”
Decreto 692 de 1994…….. “Artículo 42. Reajuste pensional por incremento de
aportes en salud. A quienes con anterioridad al 1° de enero de 1994 se les
hubiere reconocido la pensión de vejez o jubilación, invalidez, o
sobrevivientes, y a quienes sin haberles efectuado el reconocimiento tuvieran
causada la correspondiente pensión con los requisitos formales completos,
tendrán derecho a partir de dicha fecha a que con la mesada mensual se
incluya un reajuste equivalente a la elevación en la cotización para salud
prevista en la Ley 100 de 1993.
En consecuencia, las entidades pagadoras de pensiones procederán a
efectuar el reajuste previsto en este artículo por la diferencia entre la
cotización que venían efectuando los pensionados y la nueva cotización del
8% que rige a partir de abril de 1993, o la que se determine cuando rija la
cobertura familiar, sin exceder del 12%. En el caso del ISS, en donde ya existe
31
la modalidad de medicina familiar para los pensionados, el reajuste se hará
por la diferencia entre el 3.96% que venían aportando los pensionados, y el
12% de la cotización con cobertura familiar.
Las entidades pagadoras deberán descontar la cotización para salud, y
transferirlo a la EPS o entidad a la cual esté afiliado el pensionado en salud.
Igualmente deberán girar un punto porcentual de la cotización al fondo de
solidaridad y garantía en salud”.
Se concluye que aquellos funcionarios que se pensionaron antes del 1° de
enero de 1994, el descuento para salud era del 5% y la diferencia entre ese
porcentaje y el 12% lo debía asumir la correspondiente entidad que pagaba la
mesada pensional.
Teniendo en cuenta lo anterior, la Universidad Distrital mensualmente hace
dicho reintegro por novedad, de acuerdo a la norma, asumiendo en caso
particular el 7%.17
5.3.4 Sustitutos
La pensión sobrevivientes es la prestación que se reconoce a los beneficiarios
cuando fallece el pensionado o afiliado.
Información respecto de los requerimientos que debe cumplir el conyugue o
compañero permanente conyugue y/o compañero permanente
Beneficiario vitalicio: es el conyugue y/o compañero(a) permanente que
a la fecha del fallecimiento del causante, tenga 30 años o más de edad.
Beneficiario temporal: es el cónyuge o el compañero(a) permanente,
siempre y cuando dicho beneficiario, a la fecha del fallecimiento del
causante, tenga menos de 30 años de edad, y no haya procreado hijos
con este. Si tiene hijos con el causante aplicará el párrafo anterior.
Información respecto de los requerimientos que debe cumplir los hijos
beneficiarios de pensión sobreviviente.
Son los hijos mayores de 18 años hasta los 25 años, incapacitados
para trabajar por razón de sus estudios y si dependían
económicamente del causante al momento de su muerte, siempre y
cuando acrediten debidamente su condición de estudiantes”.
17 Marco normativo y procedimental Nomina Funcionarios y Pensionados UD. OAS. OFICINA ASESORA DE SISTEMAS, (OAS).
32
Los hijos inválidos si dependían económicamente del causante, esto
es, que no tienen ingresos adicionales, mientras subsistan las
condiciones de invalidez (artículo 38 de la Ley 100 de 1993).
Información respecto de los requerimientos que debe cumplir los padres
beneficiarios de pensión sobreviviente.
A falta de cónyuge, compañero o compañera permanente e hijos con
derecho, serán beneficiarios los padres del causante si dependían
económicamente de forma total y absoluta de este, al momento del
fallecimiento del causante.
Información respecto de los requerimientos que debe cumplir los hermanos
beneficiarios de pensión sobreviviente en condición de invalidez.
A falta de cónyuge, compañero o compañera permanente, padres e
hijos con derecho, serán beneficiarios los hermanos inválidos del
causante si dependían económicamente de éste, al momento del
fallecimiento del causante.
5.4 REST API
REST es el acrónimo para Transferencia de Estado Representacional (por sus
siglas en inglés REpresentational State Transfer), es un estilo arquitectural
para sistemas de hipermedia distribuidos, fue presentado por primera vez por
Roy Fielding en el año 2000, en su famosa monografía.
REST es un estilo híbrido derivado de muchos de los estilos arquitecturales
basados en red y combinados con limitaciones adicionales que definen una
interfaz de conexión uniforme.18
En realidad, REST se refiere estrictamente a una colección de principios para
el diseño de arquitecturas en red. Estos principios resumen como los recursos
son definidos y diseccionados. El término frecuentemente es utilizado en el
sentido de describir a cualquier interfaz que transmite datos específicos de un
domino sobre HTTP sin una capa adicional, como hace SOAP. Estos dos
significados pueden chocar o incluso solaparse. Es posible diseñar un sistema
software de gran tamaño de acuerdo con la arquitectura propuesta por
Fielding sin utilizar HTTP o sin interactuar con la Web. Así como también es
posible diseñar una simple interfaz XML+HTTP que no sigue los principios
REST, y en cambio seguir un modelo RPC. Cabe destacar que REST no es
un estándar, ya que es tan solo un estilo de arquitectura.
Aunque REST no es un estándar, está basado en estándares:
18 Architectural Styles and the Design of Network-based Software Architectures, Roy Thomas Fielding.
33
• HTTP
• URL
• Representación de los recursos: XML/HTML/GIF/JPEG/…
• Tipos MIME: text/xml, text/html.19
Una REST API no debe depender de ningún protocolo de comunicación único,
aunque el éxito de su mapeo para un protocolo dado puede depender de la
disponibilidad de los metadatos, la elección de métodos, etc. En general,
cualquier elemento de protocolo que utiliza un URI (Uniform Resource
Identifiers, en español Identificadores Uniformes de Recursos) para su
identificación deberá permitir cualquier esquema URI para ser utilizado por el
bien de la identificación.
Un REST API debe enfocar la mayor parte de su esfuerzo en la definición
descriptiva del tipo(s) de lo medio de comunicación utilizados para la
representación de los recursos y la conducción estado de la aplicación, o en la
definición de los nombres de relaciones extendidas y / o hipertexto habilitado
de margen para tipos de papel estándar existente. Cualquier esfuerzo que
describe los métodos a utilizar en el URI de interés debe definirse por
completo dentro del ámbito de aplicación de las normas de tratamiento para
un tipo de medio (y, en la mayoría de los casos, ya definidos por los tipos de
medios existentes).20
Una de las características clave de un servicio web REST es el uso explícito
de los métodos HTTP de una manera que sigue el protocolo tal como se
define en el RFC 2616. HTTP GET, por ejemplo, se define como un método
de producción de datos que está destinado a ser utilizado por una aplicación
cliente para recuperar un recurso, para obtener los datos desde un servidor
web, o para ejecutar una consulta con la expectativa de que el servidor web
buscará y responder con un conjunto de recursos.
REST pide a los desarrolladores utilizar métodos HTTP de forma explícita y de
una manera que es consistente con la definición del protocolo. Este principio
básico de diseño REST establece una correspondencia uno-a-uno entre crear,
leer, actualizar y eliminar (CRUD) las operaciones y métodos HTTP. De
acuerdo con este mapeo:
Para crear un recurso en el servidor, utilice la POST.
Para recuperar un recurso, utilice GET.
19 REST vs Web Services, Rafael Navarro Marset 20 http//:roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven, Roy Thomas Fielding
34
Para cambiar el estado de un recurso o para actualizarlo, utilizar PUT.
Para eliminar o borrar un recurso, utilice DELETE.21
5.5 Beego
Beego es un framework HTTṔ para desarrollo rápido de aplicaciones en GO.
Puede utilizarse para desarrollar de manera ágil APIs, aplicaciones web y
servicios back-end. Es un framework RESTful y tiene integrado a él
características específicas de Go tales como interfaces y estructuras
embebidas.
En la siguiente imagen se explica la arquitectura de Beego, que consta de 8
módulos independientes que están libremente acoplados, esto debido a que
está diseñado para programación modular. Por esto, se pueden utilizar
cualquiera de estos módulos sin trabajar bajo la lógica HTTP de Beego y
dentro de otras aplicaciones como por ejemplo juegos de sockets. Esta fue
una de las razones por las que Beego se volvió popular, dado que estos
módulos son pequeños bloques de construcción que juntos forman robustos
proyectos. De la misma manera, Beego posee una arquitectura típica MVC
(Modelo Vista Controlador).
Figura 3. Arquitectura de Beego
Cabe resaltar que el más utilizado fue ORM, para manejo de base de datos
Postgresql. Igualmente, en la siguiente imagen se puede apreciar la lógica de
ejecución de Beego. En primera instancia, se escucha al puerto de la petición
por medio del archivo main.go y a partir de él se realiza el enrutamiento y el
21 RESTful Web services: The basics, Rodriguez, Alex
35
filtrado de parámetros (normalmente asociados a la ruta solicitada).
Igualmente cada una de estas rutas está asociada a un controlador, que suele
ser creado automáticamente por Beego y se encarga de comunicarse con los
diferentes bloques que gestionan la base de datos y hacen peticiones a la
misma. Una vez hecha, regresa al controlador la respuesta de la misma, en
forma de JSON, disponible para ser utilizada en cualquier tecnología front-
end.22
Figura 4. Lógica de ejecución Beego
5.6 Prolog
Prolog es un lenguaje de programación que fue creado en comienzos de
1970, ha sido elegido por muchos programadores de aplicaciones de
computación simbólica incluyendo algunos como bases de datos relacionales,
lógica matemática, soluciones de problemas matemáticas, diseño de
automatización, solución de ecuaciones simbólicas, análisis de estructuras
bioquímicas y muchas áreas de la inteligencia artificial.
La programación de Prolog se basa en las relaciones formales, la existencia
de objetos y relaciones que son necesarias para dar una solución deseada.
Prolog puede ser visto como un lenguaje descriptivo y también como uno
preceptivo, este lenguaje se encarga más acerca de describir como se utilizan
hechos y relaciones en un problema que de describir la secuencia de pasos
que toma un algoritmo para resolver un problema. Cuando un algoritmo es
programado en Prolog, la forma como este realiza los cálculos es especificada
particularmente por la semántica lógica declarativa de Prolog, particularmente
por los nuevos hechos que Prolog puede inferir por otros especificados y
también por controles específicos de información suministrados por el
programador u otro sistema.23
22 What is Beego?, Beego 23 Programming in Prolog, Clocksin, William F
36
Los más simples tipos de declaraciones en Prolog son llamados hechos, estos
son el significado del estado o la relación que se mantiene entre objetos, un
ejemplo es:
Padre (Abraham, Isaac)
Este hecho describe que Abraham es el padre de Isaac, o la relación padre
entre los individuos Abraham e Isaac, otro nombre para una relación es un
predicado.24
5.7 Golog
Golog es una librería de uso libre que se encuentra en Github, es utilizada
como intérprete para Prolog. Su funcionalidad al ser implementada permite
probar reglas y hechos escritos en sintaxis similar, difiere de la de usada por
Prolog. En primera medida, se crea un objeto de tipo Machine que utiliza el
método Consult para probar la correcta sintaxis de las reglas. Una vez hecho
esto, con ese mismo objeto se procede a probar las reglas y hechos
previamente cargados. Al realizar esto, se obtienen resultados de las mismas,
que son guardados a modo de arreglo dentro de Golang y puede utilizarse
para los propósitos que sean necesarios. Dado que la herramienta es de uso
libre, se pueden realizar modificaciones sobre las funciones, creando nuevas
operaciones para ampliar el intérprete. Estas funciones son programadas en
Golang, por lo que se pueden realizar diversos aportes a esta librería si se
conoce el lenguaje.
24 The Art of Prolog, Sterling, Leo
37
CAPITULO 6. ALCANCES Y LIMITACIONES
6.1 Alcances
● El proyecto abarca la fase de inicio, elaboración y construcción de la
herramienta para la liquidación de nómina del grupo pensionados
según el proceso de desarrollo SCRUM/OAS.
● El equipo de trabajo se organizará por los roles definidos en el proceso
de desarrollo SCRUM/OAS. Los roles que se asumirán en la pasantía
son: Analista y Desarrollador.
● La solución de software estará basada en los lineamientos del software
libre dando respuesta a políticas distritales e institucionales.
● Realizar el análisis de los datos que conforman la nómina de
pensionados.
● Generar, evaluar y finalizar todas las tareas para cada sprint con el
objetivo de dar cumplimiento al proceso de desarrollo del proyecto de
liquidación de nómina.
● Respaldar proceso anteriormente descrito con la generación de los
artefactos (documentos, reglas de negocio, lista de tareas, diagramas y
actas de trabajo) que la metodología del subproceso de “Gestión de
Requerimientos” define, en un plazo de cuatro (4) meses frente a la
gestión de nóminas en la Universidad Distrital y siguiendo los
lineamientos del proceso de desarrollo de software SCRUM/OAS.
● Los artefactos y actividades relacionadas a la gestión de cambios en la
gestión de análisis y requisitos que menciona el proceso SCRUM/OAS
deben llevarse a cabo a lo largo del proyecto.
6.2 Limitaciones
Cualquier actividad o proceso que no se contemple en los alcances no
será tenido en cuentan a lo largo de la ejecución del proyecto.
Se realizara el proceso de gestión de datos y desarrollo de la
herramienta únicamente del proceso de liquidación de nómina de
pensionados.
Las actividades y avances estarán determinados únicamente por las
tareas generadas durante cada Sprint.
El proyecto, como política de la Oficina Asesora de Sistemas se
desarrollara en su totalidad en tecnologías OPEN SOURCE
38
CAPITULO 7. METODOLOGIA
La metodología ágil se compone de 4 valores y 12 principios, los cuales
determinan la importancia de cada integrante, las normas bajo las cuales se
relacionaran los miembros del proyecto junto con sus responsabilidades y las
reglas que rigen el desarrollo del mismo.
7.1 Valores
● Valorar a las personas y las interacciones entre ellas por sobre los procesos y las herramientas: Las personas son el principal factor de éxito de un proyecto de software. Es más importante construir un buen equipo que construir el contexto. Muchas veces se comete el error de construir primero el entorno de trabajo y esperar que el equipo se adapte automáticamente. Por el contrario, la agilidad propone crear el equipo y que este construya su propio entorno y procesos en base a sus necesidades.
● Valorar el software funcionando por sobre la documentación detallada: La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante”. Estos documentos deben ser cortos y centrarse en lo esencial. La documentación (diseño, especificación técnica de un sistema) no es más que un resultado intermedio y su finalidad no es dar valor en forma directa al usuario o cliente del proyecto. Medir alcance en función de resultados intermedios se convierte en una simple “ilusión de progreso”.
● Valorar la colaboración con el cliente por sobre la negociación de contratos: Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta mutua colaboración, será la que dicte la marcha del proyecto y asegure su éxito.
● Valorar la respuesta a los cambios por sobre el seguimiento escrito de los planes: La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también su éxito o fracaso. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.
39
7.2 Principios
Los valores anteriores son los pilares sobre los cuales se construyen los doce
principios de la metodología ágil SCRUM, en la cual está fundamentada
SCRUM/OAS. De estos doce principios, los dos primeros son generales y
resumen gran parte del espíritu ágil del desarrollo de software, mientras que
los siguientes son más específicos y orientados al proceso o al equipo de
desarrollo:25
1. Nuestra mayor prioridad es satisfacer al cliente a través de entregas
tempranas y frecuentes de software con valor.
2. Aceptar el cambio incluso en etapas tardías del desarrollo. Los procesos
ágiles aprovechan los cambios para darle al cliente ventajas competitivas.
3. Entregar software funcionando en forma frecuente, desde un par de
semanas a un par de meses prefiriendo el periodo de tiempo más corto.
4. Expertos del negocio y desarrolladores deben trabajar juntos diariamente
durante la ejecución del proyecto.
5. Construir proyectos entorno a personas motivadas generándoles el
ambiente necesario, atendiendo sus necesidades y confiando en que ellos
van a poder hacer el trabajo.
6. La manera más eficiente y efectiva de compartir la información dentro de
un equipo de desarrollo, es la conversación cara a cara.
7. El software funcionando es la principal métrica de progreso.
8. Los procesos agiles promueven el desarrollo sostenible. Los sponsors,
desarrolladores y usuario deben poder mantener un ritmo constante
indefinidamente.
9. La atención continua a la excelencia técnica y buenos diseños
incrementan la agilidad.
10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado
es esencial.
11. Las mejores arquitecturas, requerimientos y diseños emergen de equipos
auto-organizados.
12. A intervalos regulares, el equipo reflexiona acerca de cómo convertirse en
más efectivos, luego mejora y ajusta su comportamiento adecuadamente.
25 Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016
40
7.3 Descripción y desarrollo de tareas
El desarrollo del proyecto inició con un análisis detallado de toda la
información existente sobre el proceso llevado a cabo por la OAS referente a
las nóminas de la Universidad y la normatividad correspondiente. Para
establecer inicialmente las tareas que se llevaron a cabo, fue necesario
establecer un orden para el desarrollo en conjunto con el proyecto TITAN por
parte de la OAS, donde se tuvo en cuenta el cronograma establecido
previamente y se obtuvo como resultado la siguiente lista de tareas:
• Modelo de datos
• Reglas de negocio.
• API de desarrollo para nomina pensionados.
• Scripts para inserción de datos.
• Base de datos para sustitutos.
• Pre liquidación con las respectivas pruebas para identificar errores.
Cabe destacar que cada una de las tareas mencionadas anteriormente cuenta
con un conjunto de actividades que la conforman, como lo son análisis,
desarrollo y evaluación de resultados previos a la conclusión de dicha tarea,
ya que es necesario determinar si fue cumplida a cabalidad antes de dar inicio
a la siguiente por ser un proceso compuesto de varias etapas. En
consecuencia se realizaron Sprints para llevar el control de las tareas
planeadas.
A continuación se mencionan las características ligadas a cada tarea que se
realizó iterativamente en el desarrollo del proyecto junto con su respectivo
feedback y que fueron responsabilidad explicita de los integrantes:
Tarea 1: Establecer modelo de datos para nomina pensionados
Descripción: Con una previa documentación sobre el proceso y la
normatividad que corresponde a la categoría de pensionados se definieron las
tablas, relaciones y tipo de datos que integraran la aplicación.
Tarea 2: Generar reglas de negocio
Descripción: De acuerdo al modelo de negocio establecido se generaron
reglas en torno a la programación lógica que permiten a la herramienta
realizar el proceso de liquidación de forma autónoma y que contemplan todo
tipo de novedades que puedan surgir con el tiempo.
Tarea 3: Generar API para el desarrollo de nómina pensionados.
41
Descripción: Tomando como base los generadores ya existentes, se
desarrolló un API que integra todos los elementos definidos en el modelo y al
cual se le aplicaron las reglas de negocio.
Tarea 4: Scripts para inserción de datos y consideraciones para sustitutos de
pensionados
Descripción: Teniendo en cuenta que la categoría de pensionado tiene sus
propias particularidades con respecto a las demás nóminas, respecto a
pensión para sustitutos, se realizaron las respectivas reglas de negocio para
los sustitutos activos de cada pensionado.
Tarea 5: Base de datos para sustitutos
Descripción: Como se mencionó anteriormente, la categoría de sustitutos
surge como un nuevo atributo para la nómina, por lo cual se realiza el proceso
de integración de los datos al modelo ya existente para su correspondiente
relación con el proceso de liquidación.
Tarea 6: Pre liquidación con las respectivas pruebas para identificar errores
Descripción: Para garantizar la funcionalidad y la exactitud que caracteriza a
cualquier proceso relacionado con los rubros de una entidad, se realizaron
pruebas con la pre liquidación de la nómina de pensionados para comparar los
resultados reales generados con el método antiguo y los resultados del
aplicativo desarrollado, lo cual permitió identificar posibles fallos y corregirlos.
7.3.1 Creación y asignación de tareas en TULEAP
Para realizar el seguimiento diario de los avances registrados durante la
semana, se utilizó la herramienta de seguimiento TULEAP que permite
administrar los ciclos de vida agiles de un proyecto, por medio de comentarios
diarios sobre las tareas programadas, de esta manera se fue registrando los
avances o inquietudes o retrasos que surgían durante la semana.
Inicialmente se crearon varias Epic y Task dentro del desarrollo del proyecto,
en la imagen se visualizan algunas de estas asociadas a la historia de usuario
respectiva:
Figura 5. Epic de tareas en TULEAP.
Dentro de las primeras tareas a realizar, se encuentra:
42
Figura 6. Tarea analisis de nomina pensionados.
Esta tarea permitió resolver dudas respecto a temas como la pensión
sobreviviente, datos referentes a seguridad social de cada persona, entre
otras cosas.
Una vez estudiado el documento Consolidado modelo de negocio nomina
pensionados, se procedió a generar propuestas de arquitectura de datos para
el modulo pensionados, este fue sometido a un par de revisiones donde se
realizaron las correspondientes.
Figura 7. Story de comentarios de la tarea.
Este modelo se revisó junto con el ingeniero Alejandro Daza, y realizaron
varios cambios, con el fin de ajustar los detalles que no eran eficientes dentro
de la arquitectura de información diseñada. Una vez aprobado esto, se
definieron y realizaron pruebas a la reglas, con el fin de conocer el lenguaje y
lograr resultados, todo por medio de consola.
Figura 8. Tarea para creación de reglas
Figura 9. Tarea para implementacion de reglas de negocio
43
En esta etapa de las reglas de negocio, se crearon adicionalmente Task, que
cubrieran las acciones que se estaban realizado.
Figura 10. Tarea para realizar pruebas con las reglas de negocio
Luego se genera el crud_api, usando el modelo de datos pensionados:
Figura 11. Tarea para generacion de CrudAPI
El resto de tareas que se definieron al inicio del proyecto fueron generadas en
TULEAP de igual forma que las mencionadas anteriormente, todo esto con el
fin de lograr cumplir con el calendario propuesto y así mismo evaluar cada
elemento en detalle que hace parte del software, en todo momento se tuvo en
cuenta el desarrollo en conjunto con los demás integrantes del proyecto
TITAN para realizar las pruebas correspondientes al igual que la comparación
de resultados.
Para más información consulte https://tuleap.udistrital.edu.co/projects/titan, se
necesitan permisos de acceso que deben ser solicitados en la oficina asesora
de sistemas.
44
CAPITULO 8. RECURSOS Y PRESUPUESTO
Los recursos necesarios para la ejecución del proyecto implican un analista,
un desarrollador, el alquiler de dos equipos de cómputo, un repositorio para la
gestión documental, entre otros. En la tabla que se puede observar a
continuación se presentan con más detalle los ya mencionados recursos y el
respectivo costo final para el tiempo que tomó el proyecto según la OAS.
Tipo de
recurso
Recurso Cantidad Valor
unitario
Valor total
Humano Analista 1 2.000.000 6.000.000
Humano Desarrollador 1 2.000.000 6.000.000
Humano Director interno 1 3.100.000 9.300.000
Humano Director externo 1 3.100.000 9.300.000
Infraestructura Computador 2 200.000 800.000
Monetario Gastos varios 2.000.000 2.000.000
Tabla 4. Recursos y su correspondiente presupuesto.
Presupuesto total: $33.400.000
8.1 Fuentes de financiación
El presente proyecto es desarrollado para la oficina asesora de sistemas de la
Universidad Distrital Francisco José de Caldas en modalidad de pasantía, por
lo tanto, las fuentes de financiación para el mismo corresponderán a la
asignada por la oficina.
8.2 Análisis costo-beneficio
Para realizar el proceso de liquidación de nómina la Universidad cuenta con el
apoyo de 3 asesores financieros (1 directamente de la universidad y 2 de
parte de la OAS), dichas personas tardan alrededor de 3 días en realizar todo
el proceso de preliquidacion, inclusión de novedades y ajuste de incrementos
según la normatividad.
Teniendo en cuenta todos los elementos adicionales que se utilizan para la
liquidación de nómina (equipos, servicios, reprocesos por error humano, etc...)
se plantea en la siguiente tabla el costo total del proceso para un mes.
45
Tipo de
recurso
Recurso Cantidad Valor
unitario
Valor total
Humano Asesor
financiero
3 112.333
Por día
1.011.000
Infraestructura Servicios 3 3.000
Por día
27.000
Infraestructura Computador 3 3.300
Por día
29.700
Monetario Reprocesos 343.300
Por día
343.300
Tabla 5. Costos para el cálculo de nómina de un mes
Costo total por un mes: $1.411.000
Teniendo en cuenta que este proceso se debe realizar mes a mes, se realiza
una proyección a 4 años en donde el beneficio alcanzara un total de
$67.728.000 superando así el coste total del proyecto $33.400.000 como se
muestra en el siguiente flujo de caja.
46
CAPITULO 9. CRONOGRAMA
El proyecto de acuerdo a lo mencionado previamente se llevó a cabo bajo el
proceso de desarrollo SCRUM/OAS donde se establecieron diferentes tareas
las cuales se realizaron y presentaron antes de cada Sprint, dentro del
desarrollo de dichas tareas se tuvo en cuenta la fundamentación del proyecto,
el diseño de las reglas de negocio, el análisis e integración de la información
correspondiente a pensionados y la construcción de la solución de software
para la liquidación de nómina. Una vez el anteproyecto fue aprobado se
procedió a dar inicio con la pasantía, cumpliendo exitosamente con el plazo
mínimo de los 3 meses aproximadamente, tiempo en el cual se realizaron a
cabalidad todas las tareas descritas en el capítulo de alcances y limitaciones y
que correspondieron tanto al analista como al desarrollador.
Las actividades que se desarrolladas a lo largo del periodo de la pasantía y las
fases a las cuales pertenecen dentro del proceso de ejecución, se describen a
continuación, es importante destacar que estas actividades tienen un orden
estipulado para la presentación de cada avance, con el fin de construir un
proyecto bien estructurado, funcional y de mejora constante.
El cronograma que se presenta en la siguiente ilustración expone las
actividades y los tiempos estipulados para la ejecución del trabajo, teniendo
en cuenta su correspondiente presentación y feedback, dicho diagrama es fiel
a los Sprints realizados durante los 3 meses durante los cuales se llevó a cabo
la pasantía.
Figura 12. Cronograma de actividades
En el cronograma anterior se muestran los tiempos de desarrollo y entrega
para cada actividad derivada de las tareas principales según el modelo
SCRUM/OAS.
47
Figura 13. Diagrama de actividades desarrolladas
48
CAPITULO 10. DESARROLLO
10.1 Modelo de negocio actual
La gestión y pago de nómina es un hecho fundamental para cualquier
empresa u organización, es un control riguroso de todos los cobros y pagos
que se realizan dentro de un intervalo de tiempo, la Oficina Asesora de
Sistemas en la Universidad Distrital Francisco José de Caldas es actualmente
la encargada de diseñar el aplicativo para la generación y liquidación de
nómina a los diferentes actores como son los funcionarios administrativos,
docentes de planta, hora catedra y a las personas que fueron pensionadas por
la Universidad, para realizar este procedimiento la Oficina Asesora de
Sistemas elaboro una base de datos y es la encargada de administrarla
haciendo uso de querys y funciones, donde se reúnen los datos respectivos a
devengos y descuentos para cada empleado.
La Universidad Distrital Francisco José de Caldas, establece de manera anual
un presupuesto para la nómina de pensionados, el cual según las nóminas
generadas se utiliza para el pago a los mismos, de esta manera la Oficina
Asesora de Sistemas es responsable programar los métodos para consultar
los conceptos de devengos y descuentos asociados a cada pensionado y
generar la nómina que será cobrada bien sea por el pensionado o en caso de
que este fallezca, la nómina será cargada con los respectivos conceptos
referente a pensión sobrevivientes.
10.2 Arquitectura de información
Para visualizar los componentes del sistema que se desarrolló para la gestión
y desarrollo del proyecto de nómina de la Oficina Asesora de Sistemas,
utilizaremos la herramienta de modelado Enterprise Architect que ofrece
múltiples servicios para el diseño.
En el siguiente modelo, podremos visualizar los componentes del sistema y
como se relacionan entre sí, posteriormente explicaremos la función de cada
uno de forma detallada.
49
Figura 14. Arquitectura de información de nomina
Para este sistema se utiliza una considerable cantidad de información, la cual
esta detallada y hace referencia a los diferentes conceptos que hacen parte de
una nómina o bien de los proveedores relacionados con nominas específicas,
toda esta información está contenida en una base de datos creada por la
Oficina Asesora de Sistemas.
Una de las entradas corresponde a los datos de la persona perteneciente a
nómina, como se puede ver en la Figura 14 se cuenta con varias nominas
(pensionados, docentes de planta, docentes de vinculación especial etc).
Todos los datos que se requieren para el proceso de liquidación como es el
caso del proveedor se encuentran en el proyecto Agora (Sistema de terceros y
bando de proveedores) y los datos de contratación de esos proveedores
provienen del proyecto Argo (Sistema de contratación), la información acerca
de los conceptos de nómina provienen del proyecto Nix (Sistema de
presupuesto y tesorería), cada una de estas entradas de datos es fundamental
y de carácter obligatorio, ya que garantiza un óptimo manejo e integridad en la
gestión de la nómina.
A partir de estos datos, se crean objetos de datos puntuales para diseñar un
modelo eficiente y productivo tanto para el resultado final del aplicativo de
nómina, como para la optimización de recursos a nivel de software (Bases de
datos, Api, vistas etc.).
50
10.2.1 Componentes
Concepto: todos los conceptos deben estar registrados en Nix (Sistema
de presupuesto y tesorería), hace referencia a los descuentos y
devengos propios de cada persona involucrada en la nómina, los
devengos suelen ser conceptos que se suman al pago total de una
persona, como el sueldo básico, gastos de representación, pensión etc.
y aquellos descuentos que se restan de ese pago total pueden ser la
salud, o valores específicos adeudados a ciertas entidades.
Detalle: es un objeto que almacena la información de la persona y de
los diferentes conceptos que tenga asociada la misma, permite ser
detallado con la relación concepto-persona, y llevar un histórico de lo
que ha sido pagado o lo que será pagado para la siguiente nómina.
Pre liquidación: es un proceso que se realiza antes de la liquidación de
nómina, puede realizarse sobre una persona especifica o sobre un
grupo de personas a las que se desee calcular los pagos y se realiza
cuantas veces sea necesario, este proceso permite visualizar la
totalidad de descuentos y devengos que se van a efectuar, verificar la
exactitud de los datos o proceder a realizar correcciones en caso de
que haya errores en los cálculos.
Liquidación: la liquidación de la nómina es el estado que sigue a la pre
liquidación, en esta etapa debería estar correcta la información de
descuentos y devengos para las personas involucradas. Esta es la
etapa final del proceso de nómina, una vez efectuada la liquidación no
puede ser regresada.
Nomina: la nómina es el conjunto de datos que encierra a las personas
y la información de devengos y descuentos asociada a cada persona,
se realiza de manera mensual a las diferentes partes como son:
docentes de vinculación especial, docente de planta, pensionados,
contratistas, funcionarios de planta. Cada uno trae datos de los
sistemas Argo y Agora, donde están registrados los datos de
proveedores y datos de contratación respectiva.
Existe información común entre la gestión de cada nómina, por esto, este
modelo nos permite realizar una adecuada integración de componentes para
ellas y de esta manera mejorar la carga de datos y optimizar los cálculos y
vistas de los pagos.
51
10.3 Modelo de datos TITAN
Dentro de la Oficina Asesora de Sistemas existen varias áreas encargadas de
manejar de forma específica grupos de datos y procesos, una de ellas es el
proyecto TITAN, el cual se define como un sistema de nómina creado por la
OAS en donde los participantes de este proyecto se reunieron y diseñaron un
modelo de datos que se caracteriza por ser muy general y que involucra todas
las nóminas, de esta manera se logró un eficiente manejo de la información, lo
cual sirve para garantizar la integridad en cada uno de los procesos para la
liquidación de cada nómina, de forma tal que el resultado final no se vea
afectado, adicionalmente se evita que haya redundancia en la información y
estructura del modelo.
La Oficina Asesora de Sistemas tiene establecido dentro de sus normas para
el desarrollo que las tecnologías usadas sean de código abierto para cualquier
proyecto, por esto el modelo se diseñó con la herramienta PGMODELER que
funciona para las plataformas Linux, Windows y macOS, además se orientan
los archivos necesarios para el sistema de gestión de bases de datos
POSTGRESQL, sistema exigido por la OAS.
52
Figura 15. Modelo de datos TITAN
53
10.3.1 Descripción al modelo de datos TITAN
Las entidades que conforman el modelo de datos TITAN se describen a
continuación:
Concepto: esta tabla reúne los conceptos que se pueden asociar a las
diferentes nóminas, asociando a cada uno una naturaleza de devengo
o descuento, y que de esta manera pueda ser sumado o restado del
valor de liquidación para cada persona dentro de la nómina.
Figura 16. Tabla de concepto de TITAN
Concepto por persona: en esta tabla se relaciona el código de la
persona con los conceptos que tenga asociados, todo concepto tiene
un valor y un número de cuotas relacionado, el campo nomina hace
referencia al dominio con que se encuentra almacenada la nómina y
que la distingue de las demás.
Figura 17. Tabla concepto por persona de TITAN
54
Nómina y tipo de nómina: en el proyecto TITAN se desarrollaron varias
nominas (nomina pensionados, nomina contratistas, nomina
funcionarios de planta, nomina docentes hora catedra, nomina
vinculación especial), cada una con reglas propias de negocio y
conceptos diferentes
Figura 18. Tabla tipo de nomina de TITAN
Detalle de liquidación, detalle pre liquidación
Figura 19. Acercamiento detalle de liquidación y pre liquidación de TITAN
Para una nómina registrada, a la cual se le ha hecho el debido proceso de
datos, estas tablas almacenan un registro de una liquidación o una pre
liquidación, con el valor calculado para las mismas, un tiempo de liquidación o
pre liquidación,
Figura 20. Acercamiento liquidación de TITAN
55
Figura 21. Acercamiento pre liquidación de TITAN
10.4 Modelo de datos para nomina pensionados
El modelo de datos TITAN fue desarrollado de manera generalizada para que
fuera funcional con todas las nóminas, sin embargo, para el caso de la nómina
pensionados, el modelo tuvo que desarrollarse partiendo de la documentación
existente y las diferentes relaciones con las demás tablas de TITAN, teniendo
en cuenta que los pensionados tienen ciertas particularidades tanto en la
liquidación como en la base de datos de sustitutos, se tuvo que adicionar
algunas tablas para su manejo.
Todo el proceso para la creación del modelo de pensionados parte del análisis
realizado al Marco normativo y procedimental Nomina Funcionarios y
Pensionados Universidad Distrital, dicho documento estipula toda la
reglamentación bajo la cual se debe regir el aplicativo para la liquidación de la
nómina. Durante este proceso se mantuvieron constantes reuniones con los
encargados del proyecto para discutir de qué forma se debía estructurar el
modelo sin duplicar información y garantizando que todos los conceptos que
fueran requeridos estuvieran contenidos, una gran ventaja a la hora de
construir toda esta estructura radica en el conocimiento mixto en el tema de
software y la normatividad por parte de los directivos, lo cual ayudó en gran
medida a que este modelo fuera desarrollado en tan poco tiempo y de manera
complemente funcional, por lo cual fue sencillo ajustarlo al modelo general de
TITAN.
56
Figura 22. Modelo de datos nomina pensionados
57
10.4.1 Descripción al modelo de datos pensionados
El modelo de datos permite realizar una correcta gestión a la información
propia para la nómina de pensionados, de forma que las consultas y el
resultado final al liquidar la nómina sea preciso.
Informacion_persona_pensionado: Esta tabla almacena información
referente al pensionado, obtiene toda la información que ya ha sido
almacenada en la tabla Agora.informacion_proveedor, y adicional a
esta, almacena otros datos como son la fecha de nacimiento, el estado
civil, un campo persona fallecido (S ó N, según sea el caso), estado
(Activo e Inactivo), persona en exterior (S ó N, según sea el caso), tipo
pensionado, valor de pensión (valor calculado), estado de la pensión
(Activa ó Inactiva), como se verá más adelante, esta información es
importante para las reglas de negocio.
Beneficiario: Esta tabla almacena información referente a cada
beneficiario de un pensionado, como pueden ser hijos, padres o
hermanos que dependan totalmente de este, estos deben estar
registrados en la tabla agora.informacion proveedor, y adicionalmente
se le asigna una categoría de beneficiario (Esposa, Padre, Madre, Hijo),
y se registran dos campos más: sub_familiar y aux_estudio en los
cuales se asigna una ‘S’ o una ‘N’, dependiendo si le aplica o no le
aplica el subsidio respectivo.
Sustituto: Este término hace referencia a la pensión de sobrevivientes,
la cual se resume en el reconocimiento que se le hace al beneficiario
cuando ha fallecido el pensionado. En esta tabla relacionamos al
pensionado con el beneficiario que pasa a ser su sustituto luego del
fallecimiento, adicionalmente se maneja un campo estado (activo ó
inactivo), y un campo tutor que tiene efecto cuando el beneficiario es
menor de edad.
OTRAS TABLAS: Las demás tablas (Estado_civil, resolución,
categoría_beneficiario, tipo_pensionado, tipo_pension), almacenan
información secundaria sobre cada persona según sea el caso.
58
10.5 Integración de información y generalización para gestión de nomina
Debido a que el proyecto TITAN debe realizar la liquidación de diferentes
categorías (pensionados, funcionarios de planta, contratistas, docentes de
hora catedra etc.), cada nomina cuenta con reglas de negocio propias, por lo
cual surgió la necesidad de generalizar el proceso con el fin de minimizar el
esfuerzo al momento de añadir novedades a cada nómina, de esta manera en
la relación entre el api y la nómina, solo habrá que agregar el respectivo
controlador y administrador de reglas de Golog.
Este proceso comienza con el uso de la interfaz gráfica, las nóminas están
almacenadas en la base de datos con un respectivo ID de dominio, cuando el
usuario selecciona una nómina a liquidar, el api gestiona el id relacionado
Figura 23. Interfaz de nominas registradas
Para seleccionar la nómina que se desea consultar, se selecciona en pre
liquidaciones, en este enlace se mostrara la pre liquidación que está asociada
a dicha nómina, y dentro de la misma se listan las personas que están
registradas en ella.
Figura 24. Interfaz preliquidacion de nomina
Cada persona tiene asociado un numero de resolucion, el cual se usa en un
query que selecciona todas las personas dentro de la preliquidacion mostrada
en la figura anterior
Figura 25. Interfaz de consulta de pensionados
59
Los datos obtenidos de este proceso, son enviados al MidApi el cual, si la
información es enviada correctamente, comienza a realizar los procesos
respectivos de la nómina escogida (verificar el dominio de la nómina, cargar
las reglas para dicho dominio), en este caso: nomina pensionados.
Usando el dominio de la nómina se envía una petición al CrudApi, el cual se
encarga de realizar las diferentes consultas a la base de datos, se hace una
solicitud de los conceptos (devengos, descuentos) relacionados a cada
persona, y de los predicados disponibles para dicha nómina.
La pre liquidación está definida para cada nomina en su respectivo
controlador, es la encargada de procesar la información de cada pensionado
que ha sido cargado en la tabla información_persona_pensionado y de
relacionar las reglas de negocio para cada pensionado. Luego el controlador
genera unos hechos que se necesitan para la correcta operación de las reglas
de negocio, hechos que pueden cambiar dependiendo del pensionado (valor
de la pensión asignada, lugar de residencia nacional o internacional etc.), el
resultado es la construcción de reglas de negocio, donde se incluyen los
hechos, unas reglas estáticas para todos los pensionados y los conceptos de
devengos y descuentos de cada pensionado.
Finalmente, toda la información es guardada y enviada a la tabla
detalle_preliquidacion, una vez los datos son definitivos se crean las
liquidaciones.
Este procedimiento generalizado permite un procesamiento más rápido de la
información, y un método eficiente al momento de adicionar nuevas nóminas,
ya que su procedimiento interno no afectara las demás nóminas, reduciendo la
posibilidad de error en la creación de novedades, liquidación de nóminas e
inserción de información adicional.
Toda la información usada como prueba en cada nomina se extrajo por medio
de diferentes querys, de la base de datos de prueba a la cual se tiene acceso,
esta base de datos contiene información actualizada referente a la base de
datos productiva que tiene en uso la oficina asesora de sistemas, el modelo
diseñado para la nómina de pensionados, permite integrar de la misma
manera los sustitutos (pensión de sobrevivientes), teniendo en cuenta detalles
como un porcentaje sobre el valor de la pensión que le corresponda. Dentro
del api se diseñaron reglas de negocio para manejar los conceptos que
refieren a los sustitutos:
Figura 26. Reglas de negocio sustitutos
60
Para cada registro de pensionados, beneficiarios y sustitutos, se escribieron querys
para realizar las debidas inserciones en la base de datos:
Figura 27. Insert para informacion sustituto
Figura 28. Insert para informacion beneficiario
De esta manera llenamos cada tabla del esquema con la informacion necesaria para
ser trabajada en las reglas de negocio.
Figura 29. Tabla personal.beneficiarios
61
10.6 Interfaces de programación de aplicaciones (API)
Figura 30. Interfaces de programación de aplicaciones
El desarrollo de este proyecto de nómina se rige bajo un patrón de diseño de
software MVC (Modelo-vista-controlador) que propone separar el código de
los programas por sus diferentes responsabilidades, esto permite una mayor
facilidad en el mantenimiento y la reutilización de código.
Modelo: Es la capa que permite trabajar con los datos, contiene funciones que
permiten acceder a la información o actualizar su estado, información
almacenada en bases de datos. En los modelos se tienen las funciones
básicas de bases de datos como son select, update, insert etc
Controlador: contiene el código necesario para la lógica de la aplicación,
mostrar un elemento, realizar una búsqueda de información etc
Vista: contiene la parte fronted del aplicativo (HTML, CSS, JS) que permite
armar una estructura, una interfaz de usuario como salida visible al usuario.
Aplicando este patrón de diseño se crean los siguientes Api’s para el
desarrollo del proyecto “nominas”
Titán crud_api:
Esta capa crud nos permite crear, leer, actualizar o borrar (Create, Read,
Update, Delete) que son las funciones básicas para ser usadas en una base
de datos. Titan_crud_api se encarga de hacer la gestión de las conexiones a
la base de datos según la información que se necesita, realiza consultas a los
esquemas: Argo (Registro de contratos), Ágora (registro de proveedores),
pensiones, ruler (almacena reglas de negocio), extrae la información
necesaria y la envía al Titan_mid_api para ser gestionada allí.
62
Titán mid_api
Contiene un controlador específico para cada nomina e implementa funciones
específicas según el tipo de nómina escogido, hace uso de las reglas de
negocio según los requerimientos de las distintas variaciones de nómina.
Figura 31. Lista de funciones Golog
Titan_mid_api contiene los controladores especificos para la parte de
preliquidacion y liquidacion de cada nomina, informacion que es enviada a
Titan_crud_api para ser almacenada en las tablas correspondientes:
Figura 32. Lista de controladores
63
Ruler Api
El Ruler es donde se insertan las reglas de negocio para cada nomina, cuenta
con tres archivos (dominio.go, predicado.go, tipo_predicado.go), es allí donde
la nómina recibe un dominio asociado y un predicado que se relaciona con el
dominio, así se distribuye que regla en específico le pertenece a una nómina.
Estos datos son procesados y se envía a titan_mid_api que a su vez los envía
a la interfaz para ser consultados por el usuario.
Figura 33. Lista de Ruler
10.7 Parametrización de obligaciones de ley por medio de reglas de
negocio usando el intérprete Golog
Dadas las directrices de la Oficina Asesora de Sistemas para el desarrollo de
este proyecto y teniendo en cuenta que el proceso de liquidación de nómina
es un tema sensible y no debe dejar lugar a errores, se decidió independizar
toda la información relacionada con reglas y cálculos en un esquema aparte
(Ruler), para lograr que los proyectos sean independientes, robustos y que
sea más sencillo agregar novedades sin afectar otras nóminas o reglas
existentes.
Para la nómina de pensionados se escribieron reglas y hechos que fueron
usados y probados para realizar la liquidación correspondiente.
En primera instancia se tienen los siguientes hechos que hacen parte a la
base de conocimiento necesaria para que las regla puedan funcionar
correctamente. Algunos hechos son creados en tiempos de ejecución por
medio del mid_api en el controlador preliquidacionpe, el cual realiza consultas
de los campos en específico necesarios para construir el hecho, según la
persona que es consultada. Otros hechos están previamente insertados y
64
gestionados por el API que maneja las reglas (RULER_API) para ser usados
directamente en las reglas de negocio.
El principal objetivo de los hechos es relacionar porcentajes o valores fijos con
un periodo de tiempo específico, como por ejemplo el valor de SMLV o el valor
del subsidio familiar para el presente año entre otros.
Los hechos para la presente nomina se estructuraron de la siguiente manera:
HECHO DESCRIPCION
salario_minimo_legal(737717,2017). Contiene información respecto al
valor del salario mínimo legal
vigente para Colombia en el año
2017
salario_minimo_conven(2289961,2017). Contiene información respecto al
valor del salario mínimo
convencional vigente para
Colombia en el año 2017
valor_subsido_familiar(77876,2017). Contiene información respecto al
valor del subsidio familiar para
Colombia en el año 2017
valor_subsido_familiar_to(151678,2017). Contiene información respecto al
valor del subsidio familiar para
trabajadores oficiales para
Colombia en el año 2017
valor_incremento_vigencia(0.07,2017). Contiene información respecto al
porcentaje de incremento en la
cotización salud establecida en el
Sistema General de salud , según
ley 100 para Colombia en el año
2017
valor_mesada_pensionado(X,M) Según la persona, se llenara con la
información referente al valor de
pensión ya calculado para dicha
persona
tipo_pensionado(I,U) Según la persona, se llenara con la
información referente al tipo de
pensionado (docente,
administrativo, oficial)
65
porcentaje(I,T) Este hecho hace referencia a la
pensión sobreviviente, y extrae
información sobre el porcentaje que
tiene esa persona sobre el valor de
la pensión original, referido por el
pensionado a quien representa.
residencia(X,R) Según la persona, extrae
información respecto del lugar de
residencia (Nacional o extranjero)
numero_beneficiariosL(X,H) Según la persona, extrae
información referente al número de
beneficiarios hábiles con los que
cuenta le persona.
Tabla 6. Hechos en Prolog
Los hechos extraen información puntual para ser usada luego en las reglas
que realizan el cálculo de los montos para los devengos o los descuentos y de
esta manera generar la liquidación de la nómina pensionados con los
diferentes conceptos asociados a ella.
Las reglas por otra parte, están conformadas por varios hechos los cuales, al
ser procesados obtenemos un resultado, podrían ser comparadas como
funciones que reciben parámetros y retornan en resultado.
En el siguiente enlace, se puede encontrar una pequeña documentación de
cada función de golog
https://godoc.org/github.com/mndrix/golog
Las reglas para la presente nomina se estructuraron de la siguiente manera:
66
REGLA DE NEGOCIO DESCRIPCION
pension_asignada(I,P):-
valor_mesada_pensionado(X,M),tipo_pensionado(I,U),U==1, P is M.
Para obtener el valor de la pensión se usa el hecho valor_mesada y
se tiene presente para otros cálculos.
pension_asignada_sust(I,P):-
valor_mesada_pensionado(X,M),porcentaje(I,T), P is (T/100 * M rnd
0).
Para obtener el valor de pensión asignada a un sustituto se calcula
mediante el hecho valor_mesada, que almacena el valor de pensión
del pensionado, junto con el hecho porcentaje, que extrae el
porcentaje otorgado al sustituto.
aporte_fondoSoli(I,W):-
pension_asignada(I,A),por_diez(D),por_veinte(V),A @>=D, A @=<V,
W is (A*0.01 rnd 0).
aporte_fondoSoli(I,W):-pension_asignada(I,A),por_veinte(V),A @>V,
W is (A*0.02 rnd 0).
Los aportes al fondo de solidaridad de los pensionados se realizan
evaluando si la pensión asignada se encuentra en un rango de cierto
número de SLMV.
aporte_salud(I,C):-pension_asignada(I,A),residencia(X,R),R == 2, C
is (A*0.12 rnd 0).
aporte_salud(I,C):-pension_asignada(I,A),residencia(X,R),R == 1, C
is (A*0.125 rnd 0).
Los aportes a la salud del pensionado equivalen al 12% del valor de
su pensión, adicionalmente se tiene como referencia si reside en el
extranjero o a nivel nacional, ya que esto puede incrementar el valor
del aporte a pagar.
validaMesadaParaSF(V,T):-pension_asignada(I,A),
por_cinco(D),A@<D, T is 1.
Esta regla valida si la pensión que se asigna al pensionado es
menor a 5 SMCV, y que de esta manera tenga acceso o no a un
subsidio familiar.
subsidio_familiar(X,Y):-
validaMesadaParaSF(V,T),tipo_pensionado(X,P),valor_subsido_fami
liar(J,V),numero_beneficiarios(X,H),T==1,P==1, Y is (J*H rnd 0).
El subsidio familiar puede ser solicitado por el pensionado siguiendo
ciertos requerimientos, con los resultados de validaMesadaParaSF,
tipo_pensionado, valor del subsidio para el presente año y el número
67
Tabla 7. Reglas de negocio en Prolog.
La nómina de pensionados obtiene los demás descuentos y devengos del esquema Titan.concepto_por_persona, donde todas las nóminas almacenan información de los conceptos asociados a los proveedores (contratistas, docentes, pensionados etc), ya que en su mayoría se manejan valores fijos propios del individuo, como lo son cuotas de un préstamo, pagos fijos a ciertas entidades, asociaciones de pensionados, entre otros.
subsidio_familiar_to(X,Y):-
validaMesadaParaSF(V,T),tipo_pensionado(X,P),valor_subsido_fami
liar_to(J,V),numero_beneficiarios(X,H),T==1,P==3, Y is (J*H rnd 0).
de beneficiarios por los cuales recibirá ese subsidio se realiza el
cálculo correspondiente para ser agregado, en caso de necesitarlo, a
la liquidación de nómina, siguiendo también algunas condiciones
para que se haga valido el subsidio.
pago_subsidio_libros(X,S):-
tipo_pensionado(X,P),salario_minimo_conven(J,U),numero_benefici
ariosL(X,H),S is (J*H rnd 0).
El subsidio de libros hace referencia a un auxilio de estudio, que
puede ser solicitado por el pensionado siguiendo una serie de
requerimientos.
Se realizar el cálculo para el subsidio mediante la verificación del
tipo_pensionado, SLCV y el número de beneficiarios por los cuales
deberá recibir este subsidio.
aporte_salud_sust(I,C):-pension_asignada_sust(I,A),C is (A*0.12 rnd
0).
aporte_fondoSoli_sust(I,W):-
pension_asignada_sust(I,A),por_diez(D),por_veinte(V),A @>=D, A
@=<V, W is (A*0.01 rnd 0).
aporte_fondoSoli_sust(I,W):-
pension_asignada_sust(I,A),por_veinte(V),A @>V, W is (A*0.02 rnd
0).
Estas reglas hacen referencia al pago de aportes en salud, aporte al
fondo de solidaridad por parte del sustituto del pensionado, ya que
son descuentos que se deben realizar de manera obligatoria y de
acuerdo al porcentaje de pensión que se le asigna según la ley.
68
10.8 Software
El resultado final es un software que permite la gestión de pre liquidación y
liquidación de nómina y el manejo de las novedades que se asocian a ella.
La interfaz inicial para el usuario muestra dos opciones principales (nómina y
novedades), la opción Nominas le permite al usuario crear pre liquidaciones y
liquidaciones, la opción Novedades permite registrar y consultar novedades,
asociarlas a las distintas nóminas.
Figura 34. Vista principal del software
Dentro del módulo Nominas, el usuario puede visualizar las nóminas que tiene
registradas dentro de una tabla que muestra el tipo de vinculación que tiene,
una pequeña descripción, el periodo al que pertenece, y la opción para
generar la preliquidación.
Figura 35. Nominas registradas
El usuario puede añadir una nueva Nomina con la opción “Añadir nomina”,
que genera la siguiente vista:
69
Figura 36. Registro para nuevas nominas
Dentro de la opción “Preliquidacion” se listan las pres liquidaciones que tenga
registrada la nómina, una pre liquidación se puede generar varias veces según
sea necesario, pero solo se podrá liquidar una vez.
Figura 37. Detalle de preliquidacion
Al consultar cualquier usuario dentro de esta interfaz se puede visualizar en la
parte derecha sus pagos totales y un resumen del total entre devengos y
deducciones.
70
CAPITULO 11. ANALISIS Y RESULTADOS
Para evaluar si los valores obtenidos por medio del procesamiento de las
reglas de negocio diseñadas para la nómina pensionados son correctos, se
contó con la colaboración del ordenador de gasto que realiza la nómina en
este momento. Este nos facilita un documento en EXCEL que incluye
información de nómina pensionados para un mes completo, condensando los
conceptos de devengos y descuentos para el mes de febrero. Se realizó una
comparación de resultados entre los datos ofrecidos en la nómina de Excel y
los datos obtenidos en el aplicativo, y se reflejan los mismos resultados,
confirmando de esta manera que los cálculos son correctos.
Tomaremos como ejemplo una de las personas que se encuentran dentro de
la nómina, y mostraremos que los valores expuestos en el documento EXCEL
si concuerdan con los valores que son generados por medio de las reglas de
negocio diseñadas en el intérprete Golog.
Figura 38. Resumen conceptos en EXCEL.
71
Figura 39. Resumen conceptos en aplicativo
Como se puede observar todos los devengos y deducciones establecidos en el
EXCEL de la figura 34 concuerdan con los valores del campo Detalle del empleado
de la figura 35, lo cual se debe al llamado de las reglas de negocio establecidas
previamente, este proceso se puede aplicar a un solo pensionado o a la totalidad de
pensionados de la base de datos sin que surjan diferencias.
Figura 40. Interfaz de selección para preliquidacion
En la figura 36 se observa la opción para seleccionar las personas a las
cuales se les va a realizar el proceso de preliquidacion, este proceso se puede
realizar n cantidad de veces según se requiera para ajustar las novedades y
de esta forma asegurar que los valores de la liquidación final al momento de
cerrar la nómina estén de acuerdo a lo solicitado por la Universidad.
72
Figura 41. Resumen de preliquidacion
La figura 37 muestra la vista que tiene el pensionado de sus conceptos
devengados y descontados para cualquier tipo de consulta que desee realizar,
esta interfaz es única para cada persona ya que las novedades reportadas
están establecidas en función de las reglas mas no el porcentaje o número de
veces que se aplica una regla, ejemplo la cantidad de cuotas de descuento
para un crédito bancario.
Es importante destacar en el análisis realizado que al comparar el proceso
antiguo de nómina se podía tardar días en calcular y realizar el cierre de la
misma dado que toda novedad era insertada de forma manual para cada
pensionado, mientras que con el uso del aplicativo esto solo toma un tiempo
máximo de 15 minutos para cada preliquidacion que se desee hacer.
Adicionalmente este nuevo proceso brinda detalles y mayor claridad en cada
liquidación, lo cual beneficia tanto a la Universidad como a los pensionados.
11.1 Evaluación y cumplimiento de los objetivos
Como resultado adicional del análisis realizado al proyecto podemos evaluar
el cumplimiento de los objetivos planteados inicialmente, de forma que se
obtuvieron los siguientes resultados:
Se estableció el modelo de datos y reglas de negocio correspondientes
a la nómina de pensionados para la creación de la herramienta que
apoya el proceso de la OAS, utilizando la programación lógica lo cual
hace de esta herramienta un software flexible y extensible a cualquier
necesidad que surja en el futuro.
73
Se identificaron y categorizaron todos los conceptos que hacen parte
de la nómina pensionados de forma que están incluidos en el detalle
resultante de la preliquidacion.
Se parametrizo toda la normatividad existente para la nómina
pensionados dentro de las reglas de negocio las cuales formar parte
del Ruler, esta se considera una ventaja con respecto al proceso
anterior ya que se pueden integrar o modificar las reglas de acuerdo a
la normatividad que pueda afectar el proceso en el futuro.
Se integró toda la información correspondiente a los sustitutos a la
base de datos de los pensionados, de forma que las tablas generadas
pueden ser consultadas y relacionadas otros proyectos según sea la
necesidad.
Se realiza un análisis costo-beneficio donde se evidencian mejoras en
los tiempos de liquidación de la nómina, se considera ventaja con
respecto al modelo anterior el poder integrar todas las nóminas y la
información de las mismas en una sola herramienta.
74
CAPITULO 12. CONCLUSIONES
La Oficina Asesora de Sistemas como unidad de desarrollo de soluciones para
la Universidad Distrital se encuentra en un proceso de renovación e
integración de todas las herramientas e información que allí se maneja, todo
este proyecto se realizó con el objetivo de mejorar los diferentes aspectos que
competen al proceso de nómina de pensionados, tanto la creación de un
modelo general que se ajusta al proyecto TITAN, como la integración de las
diferentes características particulares de esta categoría y así estandarizar las
relaciones que hay entre los diferentes componentes del proyecto de forma
que todos los procedimiento que allí se realizan sean claros y eficientes.
Dados los resultados del análisis costo-beneficio realizado se destaca
principalmente las mejoras en los tiempos de cálculo y ejecución de
liquidación para la nómina de pensionados, además de ofrecer acceso desde
cualquier equipo, lo cual no se podía realizar anteriormente si no se tenía
instalada previamente la herramienta, con la integración de todas las nóminas
en un solo proyecto se tiene acceso a la información de las mismas desde una
solución de software libre, lo cual reduce costos y tiempos de respuesta a
cualquier procedimiento que requiera la Universidad Distrital y la OAS en este
campo.
El uso de la metodología SCRUM en la elaboración de este proyecto fue de
gran ayuda para dar un mejor manejo a los tiempos de desarrollo y
evaluación, además de ofrecer una ventaja al realizar constantes
retroalimentaciones que permitieron establecer la estructura más idónea para
el diseño del software sin dejar de lado ningún detalle dado el nivel de control
que se tuvo sobre cada tarea, sumado a lo anterior se destaca la relativa
facilidad para analizar toda la documentación existente con este proceso, lo
cual se dio gracias a la valiosa colaboración y acompañamiento de los
encargados de liderar el proyecto, quienes en todo momento dispusieron de
una actitud amable y respetuosa a la hora de solucionar cualquier tipo de
duda.
La realización de este proyecto deja importantes aportes a todos los
participantes, a la Universidad Distrital y la OAS les ofrece una herramienta
donde puede unificarse toda la gestión de la información que manejan, de
forma tal que cualquier eventualidad emergente pueda ser atendida
efectivamente. Nosotros como estudiantes de Ingeniería de sistemas tuvimos
la oportunidad de aplicar todo el conocimiento brindado por la Universidad a
través del tiempo, además de adquirir experiencia en el campo laboral,
mejorando habilidades como la responsabilidad, el respeto y la puntualidad,
los cuales son claves en el desarrollo personal, por lo cual concluimos con
75
este trabajo que nuestra vida académica fue plena y fructífera, de manera que
estamos preparados para los desafíos que nos esperan.
76
CAPITULO 12. BIBLIOGRAFIA
[1]. OFICINA ASESORA DE SISTEMAS, (OAS). Metodología SCRUM OAS.
Bogotá, 2016.
[2]. OFICINA ASESORA DE SISTEMAS, (OAS). Marco normativo y
procedimental Nomina Funcionarios y Pensionados UD. OAS, Diciembre
2013.
[3]. UNIVERSIDAD DISTRITAL FRANSISCO JOSE DE CALDAS. Guía
Rápida Proceso de Desarrollo OPENUP/OAS. Primera Edición. Bogotá, 2011.
[4]. COLOMBIA. UNIVERSIDAD DISTRITAL FRANSICO JOSE DE CALDAS.
Acuerdo 24 de (14, Enero, 1989). Por el cual se normaliza el procedimiento de
liquidación de prestaciones sociales para los empleados públicos docentes y
se fijan otros derechos salariales.
[5]. COLOMBIA. El PRESIDENTE DE LA REPUBLICA. Decreto 1279 de (19,
Junio, 2002). Por el cual se establece el régimen salarial y prestacional de los
docentes de las Universidades Estatales
[6]. COLOMBIA. El PRESIDENTE DE LA REPUBLICA. Decreto 1003 (21,
Mayo, 2013). Por el cual se dictan disposiciones en materia salarial y
prestacional para los empleados públicos docentes y administrativos de las
Universidades Estatales u Oficiales.
[7]. COLOMBIA. El PRESIDENTE DE LA REPUBLICA. Ley 100 (23,
Diciembre, 1993). Por la cual se crea el sistema de seguridad social integral y
se dictan otras disposiciones.
[8]. COLOMBIA. UNIVERSIDAD DISTRITAL FRANSICO JOSE DE CALDAS.
Acuerdo 003 de (14, Enero, 1973). Por medio del cual se reforma el Estatuto
de Profesores de la Universidad Distrital Francisco José de Caldas.
[9] SCRUM study (2016), 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.
[10] 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.
[11] 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.
77
[12] Roy Thomas Fielding. (2000). Architectural Styles and the Design of
Network-based Software Architectures. 2 de octubre de 2016, de University Of
California Sitio web: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.html.
[13] Rafael Navarro Marset. (2006). REST vs Web Services. 5 de octubre de
2016, de Universidad Politecnica de Valencia Sitio web:
http://users.dsic.upv.es/~rnavarro/NewWeb/docs/RestVsWebServices.pdf.
[14] Roy Thomas Fielding. (2008). http://roy.gbiv.com/untangled/2008/rest-
apis-must-be-hypertext-driven. 4 de octubre de 2016, de Untangled Sitio web:
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven.
[15] Rodriguez, Alex. (2015). RESTful Web services: The basics. 8 de octubre
de 2016, de IBM Sitio web: https://www.ibm.com/developerworks/library/ws-
restful/.
[16] Beego. (2017). What is Beego? 6 de mayo 2017, de Beego Sitio web:
https://beego.me/docs/intro/.
[17] Clocksin, William F. (2003). Programming in Prolog. Nueva York, Estados
Unidos: Springer.
[18] Sterling, Leo. (2000). The Art of Prolog. Boston, Estados Unidos: The Mit
press.
Related Documents
