desarrollo de la soluciÓn de software para...
TRANSCRIPT
1
DESARROLLO DE LA SOLUCIÓN DE SOFTWARE PARA APOYAR EL
PROCESO DE GESTIÓN DE NÓMINA DE CONTRATISTAS EN LA
UNIVERSIDAD DISTRITAL, SIGUIENDO LOS LINEAMIENTOS DEL PROCESO
DE DESARROLLO SCRUM EN SU FASE IMPLEMENTACIÓN, REVISIÓN Y
LANZAMIENTO.
DIEGO ORLANDO CASTILLO GONZALEZ
MARIA ALEJANDRA ORTIZ MORA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ, D.C
MAYO, 2017
2
DESARROLLO DE LA SOLUCIÓN DE SOFTWARE PARA APOYAR EL
PROCESO DE GESTIÓN DE NÓMINA DE CONTRATISTAS EN LA
UNIVERSIDAD DISTRITAL, SIGUIENDO LOS LINEAMIENTOS DEL PROCESO
DE DESARROLLO SCRUM EN SU FASE IMPLEMENTACIÓN, REVISIÓN Y
LANZAMIENTO.
AUTORES:
DIEGO ORLANDO CASTILLO GONZALEZ
MARIA ALEJANDRA ORTIZ MORA
TRABAJO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE
SISTEMAS
DIRECTOR:
ING. ALEJANDRO PAOLO DAZA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ, D.C
MAYO, 2017
3
CONTENIDO
CAPÍTULO 1. INTRODUCCIÓN ................................................................................................ 6
CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA ................................................................ 8
CAPÍTULO 3. OBJETIVOS...................................................................................................... 10
3.1. Objetivo general ................................................................................................................ 10
3.2. Objetivos específicos .................................................................................................... 10
CAPÍTULO 4. JUSTIFICACIÓN .............................................................................................. 11
CAPÍTULO 5. MARCO TEÓRICO ........................................................................................... 12
5.1. Metodología de desarrollo ágil SCRUM ....................................................................... 12
5.2. REST API ...................................................................................................................... 22
5.3. Beego ............................................................................................................................ 24
5.4. Programación lógica y prolog ....................................................................................... 25
5.5. Golog ............................................................................................................................. 26
5.6. Reglamentación para nómina de contratistas dentro de la Universidad Distrital ........ 26
5.7 Reglamentación para cálculo de descuentos sobre pago a contratistas ..................... 29
CAPÍTULO 6. ALCANCES Y LIMITACIONES ........................................................................ 31
6.1. Alcances ........................................................................................................................ 31
6.2. Limitaciones .................................................................................................................. 31
CAPÍTULO 7. METODOLOGÍA ............................................................................................... 33
CAPÍTULO 8. RECURSOS ..................................................................................................... 40
CAPÍTULO 9. PRESUPUESTO .............................................................................................. 41
CAPÍTULO 10. CRONOGRAMA ............................................................................................. 43
CAPÍTULO 11. DESARROLLO ............................................................................................... 44
11.1. Modelo de negocio actual ........................................................................................... 44
11.2. Diagrama de arquitectura de alto nivel ....................................................................... 45
11.3. Diagrama de procesos ................................................................................................ 46
11.4. Arquitectura de datos .................................................................................................. 47
11.5. Modelo de datos .......................................................................................................... 49
11.6. Generalización de la liquidación de la nómina ........................................................... 56
11.7. Interfaces de programación de aplicaciones (api) ..................................................... 58
11. 8 Manejo de reglas utilizando Golog ............................................................................. 59
11.9 Software ....................................................................................................................... 63
CAPÍTULO 12. RESULTADOS Y DISCUSIÓN ...................................................................... 69
CAPÍTULO 13. TRABAJOS FUTUROS .................................................................................. 71
CAPÍTULO 14. CONCLUSIONES ........................................................................................... 73
CAPÍTULO 15. REFERENCIAS .............................................................................................. 75
4
Índice de Figuras
Figura 1: Tablero Scrum. ......................................................................................................... 19
Figura 2. Arquitectura de Beego.............................................................................................. 24
Figura 3. Lógica de ejecución de Beego ................................................................................. 25
Figura 4. Composición de los Epics ........................................................................................ 34
Figura 5. Creación de un Epic ................................................................................................. 34
Figura 6. Vista principal de una historia de usuario ................................................................ 35
Figura 7. Vista principal de una historia de usuario ................................................................ 36
Figura 8. Vista principal de una historia de usuario ................................................................ 37
Figura 9: Cronograma de desarrollo del proyecto .................................................................. 43
Figura 10: Diagrama de arquitectura de alto nivel .................................................................. 45
Figura 11: Diagrama de procesos ........................................................................................... 46
Figura 12. Diagrama de arquitectura de información .............................................................. 47
Figura 13. Diagrama relacional de sistema de nómina Titán (Realizada por autores) .......... 50
Figura 14. Tablas para manejo de nómina (Realizada por autores) ...................................... 51
Figura 15. Tablas para manejo de preliquidaciones (Realizada por autores) ........................ 52
Figura 16. Tabla para manejo de conceptos y novedades (Realizada por autores) ............. 54
Figura 17. Tabla para manejo de liquidaciones ...................................................................... 55
Figura 18. Diagrama de componentes .................................................................................... 58
Figura 19. Vista inicial del software de nómina ....................................................................... 63
Figura 20. Nominas registradas .............................................................................................. 64
Figura 21. Vista de registro de nuevas nóminas ..................................................................... 64
Figura 22. Listado de preliquidaciones .................................................................................... 65
Figura 23. Registro de preliquidación nueva ........................................................................... 65
Figura 24. Listado de personas a preliquidar .......................................................................... 66
Figura 25. Resultado de proceso de preliquidación ................................................................ 66
Figura 26. Resumen de preliquidación .................................................................................... 67
Figura 27. Resultado de liquidación ........................................................................................ 67
Figura 28. Resumen de liquidación ......................................................................................... 67
Figura 29. Excel con resultados de liquidación de contratistas del mes de octubre .............. 69
Figura 30. Resultados de liquidación para persona N° 1, generados por Titán..................... 70
Figura 31. Resultados de liquidación para persona N° 2, generados por Titán..................... 70
.................................................................................................................................................. 70
5
Índice de Tablas
Tabla 1: Perfiles aptos para contratación por prestación de servicios. 26
Tabla 2: Remuneración por prestación de servicios según perfiles. 27
Tabla 3: Recursos del proyecto 33
Tabla 4: Presupuesto del proyecto 34
Tabla 5. Manejo de hechos en Golog. 54
Tabla 6. Manejo de reglas en Golog 57
6
CAPÍTULO 1. INTRODUCCIÓN
La Universidad Distrital Francisco José de Caldas es un ente autónomo de carácter estatal cuya
misión se centra en formar la persona a partir de la construcción del conocimiento y la
investigación en la búsqueda de resultados socialmente útiles [1]. Para cumplir a cabalidad con
esta función, requiere del apoyo de talento humano como docentes, administrativos y
contratistas, quienes deben tener una vinculación contractual con la Institución para que puedan
ser retribuidos monetariamente por sus servicios. Cualquiera que sea la vinculación contractual
que tenga una persona natural con la Universidad debe efectuarse un proceso periódico de
gestión de nómina integral de liquidación de salarios, honorarios, prestaciones y aportes
patronales, seguridad social, parafiscales y prestaciones sociales según sea el caso.
Actualmente en la institución se cuenta con varios procesos de gestión de nómina de acuerdo
al tipo de vinculación contractual existente y consecuentemente con diferentes herramientas
informáticas que soportan dichos procesos, que van desde hojas de cálculos de Excel hasta
soluciones más robustas soportadas en bases de datos Oracle, teniendo como común
denominador la baja flexibilidad a nuevos requerimientos legales o tributarios del entorno
externo o institucional, así como la baja interoperabilidad con otros componentes de software
requeridos para efectuar los pagos y causaciones financieras.
Para tal fin, la Oficina Asesora de Sistemas (OAS) emprendió un proceso de mejora y
unificación de la gestión de nómina por medio del proyecto “Solución de software para apoyar
el proceso de gestión de nómina en la Universidad Distrital, siguiendo los lineamientos del
proceso de desarrollo SCRUM en su fase de inicio, planificación y estimación e
implementación”, donde reunió estudiantes de últimos semestres del proyecto curricular de
Ingeniería de Sistemas de la Universidad Distrital. Este grupo de alumnos realizó subproyectos
encargados de procesos de gestión de requerimientos, arquitectura y desarrollo de software.
De esta manera, este proyecto apoyará el proceso de desarrollo de la solución de software y
tendrá como resultado una herramienta modular, integral y escalable que apoye y facilite los
procesos relacionados con la gestión de nómina, específicamente de los contratistas.
Igualmente, el despliegue de esta solución estará basado y guiado en los procesos de
identificación, análisis y caracterización de especificaciones funcionales y no funcionales
7
realizados en los subproyectos anteriores y será apoyado por tecnologías libres y por el proceso
de desarrollo SCRUM.
8
CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA
Para llevar a cabo diversas ideas y lograr determinados fines, las organizaciones requieren de
talento humano que brinde sus habilidades y conocimientos para volver sus proyectos realidad.
Así, la prestación de estos servicios a la organización se verá remunerada a sus trabajadores,
generando un sistema de nómina que, entre más robusta sea la organización, más complejo será
el proceso de realizar los pagos. Es por esto que surge una necesidad y un problema a solucionar
a nivel global y nacional, donde se tenga un sistema que reúna de manera eficaz y ágil la
información necesaria para la cancelación de sueldos y salarios. De la misma manera, y a nivel
de la Universidad Distrital, el proceso de liquidación de cada funcionario está regido por
diferentes leyes, acuerdos y resoluciones, lo que implica que el sistema de nómina deba tener
en cuenta diferentes factores para realizar este proceso no solo de manera ágil sino también
correcta.
Dado que la Universidad Distrital es una organización autónoma que cuenta con diversos
procesos contractuales, la Oficina Asesora de Sistemas detectó que en ella comenzaban a surgir
inconvenientes en la parametrización y liquidación de nómina, los cuales parecían originarse
gracias a la robustez del proceso de vinculación de los funcionarios. Dicha vinculación es de
diferentes tipos y han sido trabajados de manera independiente, por lo que se ha hecho más
difícil su tratamiento y control a la hora de realizar el proceso de liquidación. Dada esta
necesidad, se acudió a diversas herramientas tecnológicas con el fin de ayudar en dicha labor,
pero las utilizadas actualmente son obsoletas y no soportan la liquidación a personas naturales
que tienen algún tipo de contrato por prestación de servicios; además, dichas herramientas
cuentan con una baja interoperabilidad con otros componentes de software proveedores o
destinatarios necesarios para el correcto funcionamiento del proceso. Esta inexistente
interoperabilidad obliga a que se deban realizar varias actividades de validación para generar
los respectivos informes, debido a que las dependencias de la Universidad Distrital manejan
diferentes tipos de información relacionada a la nómina y necesaria para esta importante tarea.
Además, existen varios parámetros que son aplicables para cualquier tipo de nómina y al ser
trabajados como actualmente se hace se generan redundancias, pues cada dependencia los
maneja independientemente, y estos resultan ser iguales para las nóminas de la Universidad
Distrital.
9
Estos inconvenientes generan poca confiabilidad e integridad en los datos, además de
duplicidad en los mismos. Igualmente, las herramientas utilizadas dan vía libre a demoras
innecesarias en la liquidación y el pago de sueldos a los funcionarios además de un manejo
incorrecto de la información financiera. Todo esto afecta los procesos de liquidación y pago y
a las personas naturales con vinculación contractual con la Universidad Distrital, como lo son
los funcionarios, docentes y contratistas, o aquellos a cargo de procesos de liquidación y pago
en áreas de recursos humanos y financieros.
10
CAPÍTULO 3. OBJETIVOS
3.1. Objetivo general
Desarrollar un software modular, integral y escalable que permita apoyar los procesos
relacionados a la gestión de nóminas de los contratistas vinculados en la Universidad
Distrital Francisco José de Caldas, siguiendo los lineamientos propios del proceso de
desarrollo Scrum.
3.2. Objetivos específicos
● Desarrollar entregas parciales y funcionales del producto las cuales sean realizadas
según su prioridad y permitan evidenciar avances concretos en la realización de la
solución de software final, para cumplir así con los objetivos de cada una de las
iteraciones que componen el proceso de desarrollo SCRUM
● Aplicar pruebas a cada una de las entregas parciales desarrolladas a través del proceso,
determinando si se están cumpliendo o no los requerimientos y especificaciones
determinadas en los procesos de análisis y diseño, para realizar las correcciones
pertinentes a tiempo y así obtener un producto de software que esté acorde a las
peticiones de usuarios e interesados en el modelo de negocio de sistema de nómina de
contratistas.
● Realizar la documentación del proceso de desarrollo basada en los requerimientos y la
arquitectura planteadas por subproyectos anteriores, para llevar registros completos de
lo que está siendo realizado y que estos sirvan como referencia para futuros equipos de
desarrollo que necesiten entender y utilizar el producto de software resultante.
● Complementar los procesos de análisis, levantamiento de requerimientos y arquitectura
realizados en subproyectos anteriores desde el punto de vista del desarrollador para
generar cambios pertinentes que mejoren y aporte a la más completa construcción del
producto de software resultante.
11
CAPÍTULO 4. JUSTIFICACIÓN
Actualmente la Universidad Distrital Francisco José de Caldas carece de un sistema integral
que permita administrar la liquidación de contratistas vinculados de una manera rápida y
sencilla para las personas que desean modificar o consultar dichos datos. Esto ha llevado a
administrativos y afines con el sistema de liquidación de contratistas a que lleven un sistema
tecnológicamente atrasado, que por dicha razón está expuesto a problemas de integridad y de
seguridad que pueden en un futuro convertirse en un problema administrativo que afectaría la
universidad monetaria y administrativamente.
Es por esa razón que la Universidad Distrital prioriza los procesos de sistematización de
diferentes nóminas para generar una interoperabilidad entre los diferentes componentes de
software que intervienen con la liquidación de contratistas, así mismo, el desarrollo de dicho
sistema tiene en cuenta la documentación generada anteriormente por los arquitectos de
software.
Durante el desarrollo se tiene enfoque en fortalecer las características que los arquitectos han
especificado, como adaptabilidad dependiendo de los cambios legales y normativos externos o
internos, alta calidad de usabilidad, fiabilidad y que tenga documentación adecuada para
facilitar el futuro mantenimiento e integración.
La Oficina Asesora de Sistemas de la Universidad Distrital Francisco José de Caldas (OAS)
está utilizando la metodología ágil Scrum, donde el rol a tomar por parte de los autores de este
anteproyecto es el de desarrolladores que, además de generar los artefactos de software
necesarios para el proyecto, también analizan y adaptan los documentos generados
anteriormente por los arquitectos, todo esto debido a los requerimientos cambiantes del
proyecto y de algunos detalles de la implementación.
12
CAPÍTULO 5. MARCO TEÓRICO
5.1. Metodología de desarrollo ágil SCRUM
A mediados de los 80, Hirotaka Takeuchi y Nonaka Ikujiro definieron una estrategia de
desarrollo de productos flexibles y todo incluido en el que el equipo de desarrollo trabajara
como una unidad para alcanzar un objetivo común. Describieron un enfoque innovador para el
desarrollo de productos que ellos llamaron un enfoque holístico o "rugby", "donde un equipo
intenta llegar hasta el final como una unidad, pasando el balón de atrás hacia adelante." Ellos
basaron su enfoque en la fabricación de los estudios de casos de diversas industrias. Takeuchi
y Nonaka propusieron que el desarrollo de productos no debería ser como una carrera de
relevos secuencial, sino que más bien debería ser análogo al partido de rugby en el que el
equipo trabaja en conjunto, pasando la pelota hacia atrás y adelante mientras se mueven como
una unidad por el campo [2].
El concepto de rugby de un "Scrum" (donde un grupo de jugadores forma juntos para reiniciar
el juego) se introdujo para describir la propuesta de los autores de que el desarrollo de productos
debe involucrar el "mover el Scrum campo abajo". Ken Schwaber y Jeff Sutherland ampliaron
el concepto Scrum y su aplicabilidad en la conferencia “Object-Oriented Programming,
Systems, Languages & Applications (OOPSLA) “que se llevó a cabo en 1995 en Austin, Texas.
Desde entonces, varios practicantes de Scrum, expertos y autores han seguido perfeccionando
la conceptualización y metodología Scrum. En los últimos años, Scrum ha aumentado en
popularidad y ahora es la metodología de desarrollo de proyectos preferido para muchas
organizaciones a nivel mundial
Scrum es una de las metodologías ágiles más populares diseñada para entregar un valor
significativo de manera rápida y durante el transcurso del proyecto. De la misma manera,
asegura transparencia en la comunicación y crea un ambiente de responsabilidad colectivo y
progreso continuo. Igualmente, Scrum está diseñado de tal manera que soporta el desarrollo
de productos y servicios para todo tipo de industrias, sin importar su complejidad.
Una de las claves de la metodología Scrum radica en uso de equipos multi-funcionales, auto-
organizados y empoderados que dividen su trabajo en ciclos de trabajo cortos llamados Sprints.
13
El ciclo de Scrum comienza con una reunión de los interesados, durante la cual se crea la visión
del proyecto. Luego el Product Owner crea un Product Backlog priorizado que contiene una
lista de requerimientos de negocio y del proyecto priorizados escritos en forma de historias de
usuario. Cada Sprint comienza con una reunión de planificación de Sprint donde se consideran
las historias de usuario con mayor prioridad, para que sean incluidas en él. Generalmente, un
Sprint dura entre una a seis semanas y consiste en el Scrum Team trabajando para crear
entregables o incrementos sobre el producto.
Durante el Sprint se conducen reuniones diarias cortas y muy centradas, donde los miembros
del equipo discuten el progreso diario. Hacia el final del Sprint, se realiza una reunión de
revisión del Sprint durante la cual el Product Owner y los interesados más importantes pueden
ver una demostración de los entregables. El Product Owner acepta los entregables solamente
si estos cumplen con los criterios preestablecidos. El ciclo del Sprint termina con una reunión
de retrospectiva del Sprint, donde el equipo discute maneras de mejorar los procesos y el
rendimiento a medida que se avanza al siguiente Sprint.
Scrum y la mayoría de los métodos de manejo de proyectos tradicionales definen el riesgo
como ‘eventos inciertos que pueden llegar a afectar positiva o negativamente el logro de los
objetivos del proyecto’. En los modelos de manejo de proyectos tradicionales, hay énfasis en
identificar y determinar de antemano las respuestas a los diferentes riesgos del proyecto.
Durante la ejecución del proyecto, cualquier miembro del equipo puede identificar riesgos y el
líder del proyecto puede colocar estos nuevos riesgos dentro de la lista de los ya anteriormente
identificados. El líder de proyecto, entonces, monitorea y controla regularmente todos los
riesgos y suele identificar individuos específicos del equipo para que se responsabilicen de los
diferentes aspectos del riesgo. En Scrum, por su parte, cualquier miembro del equipo puede
identificar riesgos y el Product Owner puede actualizar los riesgos identificados en el Product
Backlog priorizado de los riesgos. Así, dentro del proceso Scrum se mantiene una constante
identificación de los riesgos, los cuales se van añadiendo a Product Backlog priorizado, donde
también se priorizan junto con otras historias de usuario, para así ser mitigados en los Sprint
siguientes; el equipo Scrum tiene la responsabilidad colectiva de manejar todos los riesgos para
el Sprint.
14
5.1.1 Roles dentro de la metodología SCRUM
Dentro del equipo Scrum se distinguen los siguientes roles:
· Producto Owner: Corresponde al dueño del producto y es el responsable de maximizar el
valor del producto y del trabajo del equipo de desarrollo [3]. Él es el único encargado de
gestionar y administrar el Product Backlog donde expresa claramente los elementos que la
componen, los organiza de manera que sea posible alcanzar objetivos y se asegura de que sea
clara y entendible para todo el resto del equipo; es quien toma las decisiones sobre este artefacto
de Scrum. Igualmente, es un rol cumplido por una única persona, no un grupo de personas.
· Development Team: El equipo de desarrollo está conformado de aquellos profesionales que
se encargan de entregar un producto terminado o funcional, al final de cada Sprint. Es un equipo
auto-organizado y multifuncionales ya que nadie les indica qué actividades deben realizar para
entregar productos funcionales y cuentan con las habilidades para hacer esto posible.
Igualmente, no se conocen títulos dentro de la metodología SCRUM, esto quiere decir que
todos son vistos como desarrolladores; a pesar de que alguien posea habilidades especializadas,
la responsabilidad de las entregas recaerá siempre en el equipo de desarrollo como un todo.
Suelen ser de 5 a 9 personas. [4]
· Scrum Master: El maestro Scrum ayuda al equipo, al dueño del producto y a la organización
a aprender y aplicar Scrum, esto con el fin de obtener valor de negocio. [5] Debe tenerse en
cuenta que él no es el jefe del proyecto ni tampoco del equipo. Su misión principal radica en
servir al equipo en el uso de la metodología ágil. Lo ideal es que sea un rol de una sola persona
y que se dedique 100% a ello; sin embargo, pueden existir equipos pequeños donde un miembro
de este ejerza el rol, excepto el dueño del producto, ya que al hacerlo él se pierde el valor de
auto-gestión que caracteriza a SCRUM.
Puede distinguirse, entonces, de estos roles, que no existe el de jefe de proyecto en Scrum. La
metodología argumenta que no es necesario ya que las responsabilidades de dicho rol están
divididas entre los tres anteriores. De igual manera, y a pesar de no ser parte del proceso Scrum,
existen otros roles como lo son el de los usuarios (destinatarios finales del producto), los
interesados (a quienes el proyecto les implicará algún tipo de beneficio y participan en los
15
Sprint para la revisión de los productos en ellos entregados) y los managers (que toman las
decisiones finales y en el levantamiento de requerimientos).
5.1.2. Fases de SCRUM
En el SBOK (Scrum Body of Knowledge) se definen 19 procesos Scrum, agrupados en cinco
fases [2].
1. Inicio del proyecto: Comprende el proceso que fija las bases necesarias para dar inicio al
proyecto. Como se define en el SBOK (Scrum Body of Knowledge), esta fase de inicio es
aplicable para portafolios, programas y/o proyectos pertenecientes a cualquier industria, así
como para proyectos con cualquier tipo de complejidad. Dentro del inicio del proyecto se
identifican seis actividades principales:
- Crear la visión del proyecto: En este proceso, se revisa el proyecto de estudio de negocio
para crear una declaración de visión del proyecto que inspire y proporcione un enfoque claro
para el mismo. Para realizar esta visión, que es transversal al proyecto, se utilizan aspectos
inherentes al negocio como lo son su misión, visión y un estudio de mercado. Igualmente, en
este proceso participan el Producto Owner, el Scrum Master y los interesados y se realiza por
medio de reuniones que permiten identificar el contexto del negocio, los requerimientos y las
expectativas de negocio. También suelen utilizarse matrices DOFA y análisis GAP para
identificar fortaleza, debilidades, amenazas y oportunidades y realizar también una
comparación del estado actual del proyecto y el estado deseado del mismo. [6]
- Identificar al Scrum Master y a los Stakeholders: Utilizando criterios de selección, como
lo son la capacidad para resolver problemas, la disponibilidad, compromiso y liderazgo, y junto
a la propuesta de visión realizada anteriormente, se elige al maestro Scrum. También suele
pedirse ayuda al departamento de recursos humanos para determinar qué personal se necesita
para un proyecto; también se estudia la disponibilidad y el compromiso de aquellos que puedan
ser seleccionados para Scrum Master e interesados. Para los stakeholders debe tenerse en
cuenta que son todos aquellos clientes, usuarios y patrocinadores que faciliten la creación de
productos del proyecto.
16
- Formación del equipo Scrum: Se identifican los miembros del equipo Scrum. Normalmente,
el encargado de esta responsabilidad es el Product Owner, pero también puede hacerlo junto
con el Scrum Master. Los miembros ideales de este equipo son independientes, auto-
motivados, responsables y colaborativos. Suele utilizarse ayuda del departamento de recursos
humanos para conocer la disponibilidad y compromiso del personal. Igualmente, se tienen en
cuenta los costos del personal y del entrenamiento, ya que no todos los miembros del equipo
poseen las habilidades requeridas o el conocimiento para las tareas que les serán asignadas. Por
esto, el Product Owner debe evaluar las necesidades de entrenamiento de los miembros y
proveerles capacitaciones donde puedan adquirirlas. A parte de elegir al equipo Scrum, es
importante elegir personal de respaldo quienes pueden reemplazar a alguien en el equipo
Scrum, dada alguna eventualidad. [7]
- Desarrollar Epics: En este proceso la visión del proyecto es la base para definir los Epics,
así como reuniones con los usuarios para discutir cuáles Epics son apropiados. Los Epics, o
épicas, se redactan al inicio del proyecto cuando las historias de usuario son funcionalidades
de alto nivel por lo que no son más que historias de usuario amplias sin refinar. Se incluyen en
la lista priorizada del Product Backlog para ser terminadas y se convierten posteriormente en
historias de usuario más pequeñas. La definición de épicas las realiza el equipo Scrum por
medio de reuniones de grupo de usuario donde intervienen en ellas los interesados más
relevantes y en ella se aclaran requerimientos para no realizar doble trabajo y esfuerzo; también
se utilizan talleres de historia de usuario y entrevistas al usuario o cliente.
- Crear un Product Backlog priorizado: En este proceso se refinan los Epics para crear una
lista priorizada de pendientes del producto del proyecto. Para ello, se utilizan métodos de
priorización de las historias de usuarios como el esquema de priorización MoSCoW, que utiliza
etiquetas en orden de prioridad decreciente que marcan las historias de usuario con
características de “debería tener” y “gustaría que tuviera” para medir su importancia. También
se utiliza la comparación por pares, donde se lista las historias de usuario y se comparan entre
sí, eligiendo la que sea más importante entre las dos. Todo esto permitirá entonces que se
obtenga un Product Backlog priorizado. [8]
-Realizar el plan de lanzamiento: Se revisan las historias de usuario en el Product Backlog
priorizado para realizar un cronograma de lanzamiento, determinando también la duración del
sprint. Aquí se utilizan sesiones de planificación que definen cuándo se van a entregar
17
conjuntos de funcionalidad o productos utilizables. Para ello, el equipo debe tener clara la
visión general de los lanzamientos y el calendario de entrega del producto que se está haciendo
para así cumplir con las expectativas.
2. Planificación y estimación: Comprende cinco procesos y también es aplicable para cualquier
área, no solamente para el desarrollo de software.
- Creación de historias de usuario: El Product Owner, gracias a la interacción con socios y su
conocimiento del negocio, es quien desarrolla las historias de usuario elaboradas y refinadas
que sean aprobadas por el equipo Scrum y que harán parte de la lista inicial de pendientes del
producto para el proyecto. También existen métodos para la estimación de historias de usuario
(específicamente para su aprobación, estimación y asignación). Entre ellas se encuentra la
reunión de grupos de usuarios, el póker de planificación y los puntos de estimación de costo.
Como resultado de este proceso no solo se obtienen las historias de usuario sino un Product
Backlog actualizado junto con criterios de aceptación para dichas historias, para que se obtenga
objetividad al decidir cuándo la historia ha sido terminada o no durante la revisión del sprint.
[9]
- Aprobación, estimación y asignación de historias de usuario: Se utilizan los métodos
descritos anteriormente para realizar la estimación de los tamaños relativos de las historias de
usuario o el trabajo necesario para desarrollarlas. También existen otras técnicas de estimación
no tan populares como Wideband Delphi, puntos de historia, estimación por afinidad y rango
de estimación. Todas estas actividades apuntan al mismo objetivo y necesitan del soporte y
experticia de los asesores Scrum, que resolverán los conflictos que puedan aparecer a la hora
de las estimaciones sobre ciertas historias de usuario.
- Creación de tareas: El equipo Scrum se reúne para planear el trabajo que se realizará en el
sprint. Para ello se utilizan las historias de usuario, las cuales pasarán a hacer parte de la lista
priorizada de pendientes del Sprint. En estas reuniones debe estar presente el Product Owner,
quien aclarará todas las dudas que se presenten sobre las historias y procurará que la reunión
no se extienda en temas que no le correspondan. El Product Owner presenta qué historias de
usuario estarían bien que formaran parte del sprint. Así, el equipo determina cuántas puede
realizar, llegando a un consenso entre ambas partes. Luego, el equipo determina cómo convertir
18
las historias de usuario en un incremento del producto al dividirlo en tareas, definiendo luego
los entregables.
- Estimación de tareas: Se realizan reuniones para estimar el trabajo necesario para completar
una tarea, así como estimar el trabajo laboral y demás recursos para las tareas del sprint. Esto
permite que el equipo cuente con una perspectiva de las historias de usuario y los
requerimientos para así calcular el esfuerzo necesario; este proceso suele conocerse como las
reuniones de planificación de sprint y utilizan mucho el juicio de expertos y cálculos
paramétricos para las estimaciones.
- Creación de la lista de pendientes del sprint: Dentro de la reunión de planificación de Sprint
también se elabora la lista de pendientes del sprint y la gráfica de pendientes. Igualmente se
realiza el seguimiento del sprint y se tiene en cuenta la duración del anterior, para conocer en
qué lugar se encuentra el equipo en términos de la finalización de las tareas. Para ello suele
usarse un tablero o herramienta que marque las tareas con estados: To Do, In Progress y Done.
De esta manera se conoce más fácilmente la lista de pendientes del sprint.
3. Implementación: Está relacionada con la ejecución de las tareas que permiten la creación del
producto. De esta manera, incluye tres procesos principales:
- Creación de entregables: En este proceso se utiliza el tablero Scrum (Figura 1), donde se
realiza el seguimiento de Sprint según los estados de las tareas del mismo (por hacer, en
progreso, en revisión o prueba y terminado); puede ser un tablero físico o utilizarse una
herramienta electrónica para simularlo. Aquí se utilizan herramientas de software para
programar, recopilar información y para la distribución, todo esto con el fin de dar seguimiento
a las tareas asignadas y a que éstas se realicen de la manera más ágil posible. Igualmente, es
necesaria la experiencia del equipo Scrum para comprender las historias y las tareas de
pendientes del sprint para así poder crear entregables finales.
19
Figura 1: Tablero Scrum.
Fuente: SCRUMstudy™ (2018), A Guide to the Scrum Body of Knowledge (SBOK™ Guide).
Para los proyectos de software existen dos herramientas de desarrollo que Scrum considera se
pueden ser utilizadas y pueden llegar a facilitar este proceso:
1. Refactorización: Consiste en mejorar el mantenimiento del código existente y
hacerlo más flexible y sencillo. Esto indica que lo que se desea es realizar
optimizaciones sobre código actual y existente, sin cambiar el comportamiento del
mismo. Así, se busca eliminar código redundante, separar las funciones en métodos
más pequeños, definir de forma clara las variables y nombres de métodos y hacer,
de manera general, el código más fácil de entender y modificar.
2. Patrones de diseño: Proporcionan una manera formal de registrar una solución a
un problema de diseño en un campo específico. Estos patrones están hechos para
ser aplicados a problemas puntuales y para hacer del código algo más fácil de
reutilizar y entender. [10]
- Reuniones diarias de pie: Consiste en reuniones diarias de 15 minutos donde se reporta el
progreso del sprint y se planifican las actividades del día. Se busca que todos los miembros
estén en esta reunión pero si alguno presenta un impedimento no se cancela ni se retrasa. En la
20
reunión se responde a los interrogantes: ¿qué terminé ayer?, ¿qué terminaré hoy? ¿qué
problemas tuve? También suele utilizarse la videoconferencia para las reuniones.
- Mantenimiento de la lista priorizada de pendientes del producto: El propietario del
producto puede reunirse con los socios e interesados del proyecto para contar con la
información necesaria que le permita actualizar la lista priorizada de pendientes del producto.
Esto se realiza para que todos entiendan las historias de usuario y sus criterios de aceptación;
también se hace para eliminar historias de usuario irrelevantes y que se incorporen solicitudes
de cambio. El mantenimiento de esta lista es clave para el desarrollo de las tareas y depende de
una buena comunicación entre el equipo Scrum
4. Revisión y retrospectiva
En esta fase se desarrollan actividades de corrección de errores de los entregables y del trabajo
desarrollado hasta el momento del desarrollo de esta.
- Convocar Scrum de Scrums: Los representantes del equipo Scrum convocan una reunión de
Scrum of Scrums (SoS), en la cual los representantes del equipo se reúnen para compartir el
estado de los productos y tareas de los grupos correspondientes, se realizan de acuerdo a
intervalos de tiempo definidos al principio del proyecto o cuando los representantes o
miembros del equipo así lo requieran. Las actualizaciones de cada equipo serán presentadas a
la organización a través de cuatro preguntas básicas:
1- ¿En que ha estado trabajando mi equipo desde la última reunión?
2- ¿Qué va a hacer mi equipo hasta la próxima reunión?
3- ¿Con qué contaban otros equipos que mi equipo hiciera que no se ha hecho?
4- ¿Qué piensa hacer nuestro equipo que pueda afectar otros equipos? [11]
- Demostración y validación del Sprint: En este proceso se le enseña al propietario del
proyecto e interesados el Sprint Deliverable del producto en un Sprint Review Meeting, que es
una reunión donde participan no solo los miembros del equipo sino que también los
stakeholders, en esta se discute la pertinencia del producto entregado, el propietario tiene como
función principal aprobar o rechazar dicho producto.
21
- Retrospectiva del sprint: Este proceso sirve para analizar retrospectivamente y determinar
cómo se ha llevado a cabo dicho Sprint para tener en cuenta buenas acciones o para evitar
errores los errores que se cometieron. Se debe documentar estas lecciones con el objetivo de
usarlas posteriormente y mantener el proceso en una constante mejora. Todos los miembros
del equipo asisten a la reunión, no es necesario que el propietario asista, se busca identificar
las buenas y malas prácticas y las mejoras que se deben implementar.
Para medir y contrastar el desempeño del sprint comparándolo con Sprints pasados, como lo
son el team velocity, que es el número de puntos de historia hechos durante el Sprint, el
porcentaje de puntos de historia que han sido terminados, en relación a los que se han llevado
a cabo; estimado de eficacia, porcentaje de discrepancia entre el tiempo previsto y el tiempo
verdadero que se ha utilizado en las tareas; el o los stakeholder(s) puede(n) solicitar una
retroalimentación que les permita establecer parámetros cualitativos o cuantitativos para
evidenciar el avance del proyecto y finalmente un estimado para la liberación del producto el
valor del negocio proporcionado en cada versión, así como el valor representado por el
progreso actual hacia una liberación. [12]
5. Lanzamiento
En la fase de lanzamiento o release está marcada por la entrega de productos aceptados al(los)
cliente(s) o usuario(s), la documentación, y análisis del desarrollo de las actividades dentro del
proyecto.
-Envío de entregables: En este proceso los Accept Deliverables se entregan o traslada a los
socios, clientes o usuarios pertinentes, un Working Deliverable Agreement, donde se hace un
cierre de negocio formal y se documenta la finalización con éxito del Sprint.
-Retrospectiva del proyecto: En este paso los socios y el equipo para identificar, documentar
y analizar las buenas y malas prácticas para utilizarlas y corregirlas en futuros proyectos.
Como puede apreciarse, la metodología Scrum presenta la ventaja de corrección de errores de
manera casi inmediata gracias a sus sesiones diarias (Daily Scrum), donde los integrantes
comparten sus avances y problemas con respecto al proyecto, lo que es esencial cuando se
22
necesita cambiar el producto constantemente debido a los requerimientos variables del mismo.
Esta metodología de desarrollo de software permite jerarquizar los requerimientos (Project
backlog) para planificarlos de acuerdo a iteraciones que contienen algunos de estos requisitos
(Sprint backlog), esto teniendo en cuenta una gráfica de proceso ideal con el que se puede
calcular retrasos y adelantos en el trabajo (Burndown char), para finalmente ejecutar estas
iteraciones (Sprints) [13]. Antes de ejecutar cada Sprint backlog, se deben definir los cambios
que ha tenido el proyecto, teniendo en cuenta los requerimientos iniciales, debido a que no es
recomendable ejecutar cambios cuando ya haya iniciado esta iteración. Es una metodología
que favorece el proyecto en gran medida debido a que, como fundamento principal de esta, se
sugiere la entrega del software con las nuevas funcionalidades adicionadas en la última
iteración o sprint, con lo cual se puede evidenciar los avances del proyecto por parte del cliente.
Es de aclarar que las iteraciones tienen un objetivo claro sobre el cual debe ser posible medir
el avance. El seguimiento exhaustivo del proceso de desarrollo y de la mitología en general
aumentará la probabilidad de asemejar el producto a lo especificado en diseños posteriores.
5.2. 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. [14]
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
23
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:
• HTTP
• URL
• Representación de los recursos: XML/HTML/GIF/JPEG/…
• Tipos MIME: text/xml, text/html. [15]
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). [16]
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
24
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.
Para cambiar el estado de un recurso o para actualizarlo, utilizar PUT.
Para eliminar o borrar un recurso, utilice DELETE. [17]
5.3. 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, ésto 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 2. Arquitectura de Beego
Fuente: https://beego.me/docs/intro/0
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
25
de él se realiza el enrutamiento y el 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. [18]
Figura 3. Lógica de ejecución de Beego
Fuente: https://beego.me/docs/intro/
5.4. Programación lógica y 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 comó 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
26
puede inferir por otros especificados y también por controles específicos de información
suministrados por el programador u otro sistema. [19]
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. [20]
5.5. Golog
Golog es una librería disponible para descargar en Github y de uso libre que es utilizada como
intérprete del lenguaje de programación de Prolog. Esto quiere decir que al ser implementada,
permite probar reglas y hechos escritos en sintaxis similar, no igual, a 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 prueban 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. De la misma manera, al ser 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.
5.6. Reglamentación para nómina de contratistas dentro de la Universidad Distrital
Por medio de la resolución 003 del 15 de enero de 2016, el rector de la Universidad Distrital
reglamentó la contratación por prestación de servicios [21]. El primer aspecto que se tuvo en
cuenta dentro de la resolución consistió en los perfiles aptos para ser vinculados a la
Universidad mediante un contrato de prestación de servicios. Dentro de estos se encuentran:
· Perfil de servicios asistenciales: Corresponde a todas aquellas actividades de apoyo y
complementarias de tareas propias de otros perfiles. Suelen corresponder a actividades
manuales o tareas de simple ejecución. Algunos ejemplos son: secretariales, mensajería,
mantenimiento.
27
· Perfil de servicios técnicos y tecnológicos: Corresponde al desarrollo de procesos y
procedimientos de carácter operativo, relacionados con la aplicación de ciencia, tecnología y
gestión.
· Perfil de servicios profesionales: Agrupa actividades cuya naturaleza demanda
ejecución de conocimientos propios de los programas profesionales reconocidos por la ley
· Perfil de servicios profesionales especializados: Reúne aquellas actividades que por su
característica de especificidad requieren un grado de especialización complementario a los
programas profesionales.
· Perfil Asesor I: Reúne actividades de asesoría o consejería a las dependencias del nivel
directivo y asesor de la universidad, las cuales requieren alto grado de experticia.
· Perfil Asesor II: Agrupa actividades de asesoría o consejería a la rectoría de la
universidad, las cuales requieren alto grado de experticia y conocimiento profesional.
De esta manera, para cada uno de los perfiles anteriores se tienen requisitos mínimos para llevar
a cabo la celebración del contrato:
Tabla 1: Perfiles aptos para contratación por prestación de servicios.
Perfil Requisitos mínimos
Servicios asistenciales Título de educación media o experiencia
relacionada de mínimo 5 años.
Servicios técnicos o tecnológicos Título de formación en programa
académico técnico, o la aprobación de
mínimo seis semestres en programa
académico de formación profesional
Servicios profesionales Título en programa académico profesional
Servicios profesionales especializados Título en programa académico profesional
y título en programa académico de
especialización y título en programa
académico de especialización.
28
Asesor I Título en programa académico profesional,
título en programa académico de
especialización y experiencia relacionada
de mínimo 5 años.
Asesor II Título en programa académico profesional,
título en programa académico de
especialización y experiencia relacionada
de mínimo 8 años.
Fuente: Sistema de información de Secretaría General, “Resolución 003 de 2016,”
Universidad Distrital Francisco José de Caldas, 2016.
Entonces, la escala de honorarios de los contratos de prestación de servicios profesionales
también está relacionada con dichos perfiles y se detalla como sigue:
Tabla 2: Remuneración por prestación de servicios según perfiles.
Perfil Requisitos mínimos
Servicios asistenciales 2.3 S.M.L.M.V.
Servicios técnicos o tecnológicos 3.0 S.M.L.M.V.
Servicios profesionales 4.6 S.M.L.M.V.
Servicios profesionales especializados 6.0 S.M.L.M.V.
Asesor I Hasta 8.0 S.M.L.M.V.
Asesor II Hasta 9.8 S.M.L.M.V.
Fuente: Sistema de información de Secretaría General, “Resolución 003 de 2016,”
Universidad Distrital Francisco José de Caldas, 2016.
Igualmente, dentro de la resolución, se realizan las siguientes claridades:
· Los encargados de la etapa precontractual deben verificar que se cumplan los requisitos
mínimos nombrados y según el perfil a contratar.
29
· Los supervisores de los contratos de prestación de servicios han de verificar el
cumplimiento del objeto contractual, así como el pago de aportes al Sistema Integral de
Seguridad Social. Esto se hará de manera mensual y según los porcentajes que estipulan la ley;
de esta manera se autorizará el pago de los honorarios.
· El pago de los honorarios se hará luego de la aprobación del supervisor, donde él
realizará la revisión del informe del contratista y el cumplimiento de los trámites
administrativos y según el Manual de Supervisión e Interventoría de la Universidad Distrital.
· A todos los contratos se les debe adjuntar una póliza de seguro de cumplimiento a favor
de la entidad estala, donde se incluye la obligación del contratista de amparar el cumplimiento
de las obligaciones a su cargo.
· La escala de honorarios aquí presente contiene todos los impuestos, tasas y
contribuciones a que haya lugar.
· Para las profesiones reguladas legalmente, deberá adjuntarse tarjeta o matrícula
profesional
· Nadie puede celebrar, en condición de contratista, más de un contrato de prestación de
servicios profesionales con cargo al presupuesto de la Universidad Distrital.
· Dentro de esta resolución NO se tienen en cuenta los perfiles y honorarios por
prestación de servicios en los proyectos de extensión e investigación.
5.7 Reglamentación para cálculo de descuentos sobre pago a contratistas
A las personas que cuenten con un vínculo contractual de tipo prestación de servicios se les
serán descontados cuatro conceptos: Retención de Industria y Comercio (ICA), Estampilla
Universidad Distrital, Adulto Mayor y Estampilla ProCultura. Cada uno de estos cuenta con
un marco legal que lo autoriza y define el porcentaje que será descontado al pago de cada uno
de los contratistas.
Estampilla ProCultura de Bogotá: En el acuerdo 187 de 2005 se ordenó la emisión de la
Estampilla de Pro Cultura de Bogotá. El Concejo de Bogotá ordenó su emisión de conformidad
con lo autorizado en la Ley 397 de 1997 y la Ley 666 de 2001. De esta manera, en el artículo
cuatro se identifican como sujetos pasivos a “todas las personas naturales y jurídicas que
suscriban contratos con las entidades que conforman el Presupuesto Anual del Distrito Capital
de Bogotá”, lo que implica que serán agentes de retención y se les será descontado, al momento
30
de los pagos y de los pagos anticipados de los contratos y adiciones que suscriban, el 0,5% de
cada valor pagado, sin incluir el impuesto a las ventas. [22]
Estampilla Universidad Distrital Francisco José de Caldas 50 años: En el Decreto 93 de
2003, que considera que en la Ley 648 de 2001 se autorizó al Concejo de Bogotá para ordenar
la emisión de una estampilla de la Universidad Distrital (dentro del Acuerdo 53 de 2002), se
tiene en cuenta que el responsable del recaudo será este mismo ente junto con los
establecimientos públicos del Distrito Capital de Bogotá. Además, se estipulan que
descontarán, al momento de los pagos y los anticipos, el 1% del valor bruto de los contratos
escritos que se suscriban y las adiciones de los mismos. Igualmente, en este decreto se aclara
(Artículo 1, parágrafo primero) que el valor bruto ha de ser entendido como el valor a girar por
cada orden de pago sin incluir el impuesto al valor agregado. [23]
Estampilla “Pro adulto mayor”: El Acuerdo 188 de 2005 ordenó que se emitiera la estampilla
‘Pro-dotación, funcionamiento y desarrollo de programas de prevención y promoción de los
centros de bienestar, instituciones y centros de vida para personas mayores’. De esta manera,
las entidades que conforman el presupuesto anual del Distrito Capital descontarán el 2% de
cada valor pagado al momento de los pagos y pagos anticipados de los contratos. [24]
31
CAPÍTULO 6. ALCANCES Y LIMITACIONES
6.1. Alcances
● El proyecto lleva a cabo las fases de implementación, revisión y lanzamiento de la
metodología ágil de desarrollo SCRUM.
● Las iteraciones (Sprints) comprenden una semana de desarrollo.
● El equipo de trabajo se definirá de acuerdo a los roles propuestos por la metodología
ágil de desarrollo SCRUM, el rol de los pasantes será el de desarrollador.
● Se realizarán pruebas funcionales y no funcionales de software con el fin de cumplir
con las especificaciones establecidas por el grupo analista y el grupo de arquitectura.
Dichas pruebas se realizan finalizando cada iteración (Sprint), ya que la finalización de
estas culmina con un producto funcional.
● El proyecto estará estructurado en 4 release, compuestos cada uno de 4 sprints,
iteraciones, donde en primera medida se detalla el modelo de negocio junto con la
documentación de análisis y diseño construida anteriormente; los restantes serán para
la elaboración, construcción y pruebas del producto de software.
● Documentar y llevar a cabo los respectivos cambios en los componentes del software
que cambien las especificaciones, de acuerdo con las características de la metodología
ágil de desarrollo SCRUM.
6.2. Limitaciones
● La solución de software estará basada en componentes de software libre dando respuesta
a políticas distritales e institucionales.
● Los productos de software se desarrollarán en el lenguaje de programación Golang para
su backend, PostgreSQL para la persistencia y angularjs para el frontend, herramientas
elegidas por la Oficina Asesora de Sistemas para llevar a cabo la realización de sus
productos.
32
● Realizar y documentar el número de componentes de software de acuerdo a la
arquitectura y diseño pertinentemente comunicada y establecida en el proyecto 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
33
CAPÍTULO 7. METODOLOGÍA
La metodología que se aplicó en este proyecto fue el proceso de desarrollo SCRUM,
implementado por la Oficina Asesora de Sistemas. En primera medida, los entregables y
avances funcionales sobre el proyecto fueron revisados y discutidos de manera interna dentro
de la Oficina Asesora de Sistemas, labor realizada por los ingenieros a cargo del proceso de
liquidación de nómina actual. Éstos fueron los clientes principales dentro de este desarrollo y
quienes realizaron retroalimentaciones sobre el proceso iterativo incremental de la elaboración
del software. Los ingenieros Francisco Hurtado, Carlos Rojas, María Claudia Rubiano y
Alejandro Daza eran los encargados de recibir los entregables y de llevar a cabo el proceso de
seguimiento del proyecto. Francisco Hurtado y María Claudia Rubiano han trabajado durante
aproximadamente 15 años sobre el proceso de generación de las distintas nóminas, por lo que
su experiencia y disponibilidad para atender las dudas permitió que cada entregable se
corrigiera o mejorará rápidamente, sin depender de usuarios finales que en muchos casos no
contaban con la disposición y tiempo para realizar pruebas sobre los mismos.
La metodología SCRUM permite hacer seguimiento diario y semanal de las tareas, para esto
se usó el software Tuleap, que es una herramienta online de uso libre que permite la
administración de ciclos de vida ágiles. Para comenzar a hacer uso de ella, es necesario registrar
todos los proyectos que serán trabajados dentro de la Oficina Asesora de Sistemas. Una vez
hecho esto, se permite asociar a él el equipo de trabajo que intervendrá en su puesta en marcha
(tanto interesados en el negocio como desarrolladores).
El primer paso consistió en generar un Epic, por medio de la herramienta, para trabajar la
arquitectura (definición de aspectos de análisis) y otro para la nómina de contratistas (en su
fase de desarrollo). En la figura número 2 se visualiza la creación de los Epics referentes a la
Arquitectura de Titan y la Nómina Contratistas dentro de Tuleap, se puede ver en esta como
los Epics están compuestos por historias de usuario.
34
Figura 4. Composición de los Epics
Fuente: Tomada de Tuleap
De la misma manera, en la figura 3 se puede apreciar cómo se realiza la creación de un Epic
en la herramienta. Basta con especificar su nombre y el progreso respectivo (to do, on going,
review y done), así como las historias asociadas a él; estas pueden crearse posteriormente.
Figura 5. Creación de un Epic
Fuente: Tomada de Tuleap
Así mismo, estos se descomponen en historias de usuario, que son definidas por el equipo
Scrum junto con los interesados en el proyecto y se especifican los requerimientos a trabajar
por los desarrolladores. Las historias de usuario describen de manera general estas exigencias
a desarrollar y tienen puntos asociados, que representan cuantitativamente el esfuerzo que
implica la realización de dicha actividad; los puntos son asignados por el líder del proyecto o
el líder SCRUM. En la historia de usuario se pueden apreciar los puntos estimados de esta, es
decir, los que se espera sean disminuidos por el desarrollador y los puntos restantes para
35
terminar la tarea. Conforme se va avanzando en el desarrollo de la historia, los puntos se
reducen hasta alcanzar el 0, que indica la finalización de la historia; es el desarrollador quien
modifica dichos puntos. De la misma manera, esta historia de usuario posee un atributo de
estado, que puede ser “to do”, “on going”, “review” y “done”. La historia de usuario se moverá
por estos estados según el avance que presenten las tareas asociadas a ella y esto es evaluado
por el líder de proyecto. En la figura 4 puede observarse la historia de usuario 7936 “Realizar
la generalización del midApi para las distintas nóminas” donde se aprecian los aspectos
anteriormente descritos. Uno de los campos de la historia de usuario es el de puntos estimados
(Estimated story points), es la estimación empírica total de puntos de una historia que es
determinada por el desarrollador, para estimar la duración de la tarea en puntos que pueden ser
determinados por la duración o dificultad de la tarea, teniendo como punto de referencia
historias o tareas similares. El segmento de en orden a (In order to) define el proyecto al cual
está asociado la historia de usuario, en este caso Titán; La segunda parte de la historia de
usuario ilustra el progreso de la misma, el estado (status) muestra la etapa del proceso que se
está llevando a cabo actualmente (to do, on going, review y done, es decir para hacer, en
ejecución, en revisión y terminado respectivamente); además, se aprecia la parte de puntos
restantes de historia (Remaining story points), que establece el porcentaje en que se ha
desarrollado esta.
Figura 6. Vista principal de una historia de usuario
Fuente: Tomada de Tuleap
36
De esta manera, partiendo de la historia de usuario como un requerimiento concreto de un Epic,
se llega a la creación de tasks asociadas a ella. Estas tasks son las labores específicas y atómicas
que debe realizar el desarrollador para cumplir con el requerimiento que le indica la historia de
usuario; igualmente, para la creación de estas los encargados del proyecto deben dar la
aceptación para empezar con el desarrollo de esta. El task tiene un apartado donde se debe
asignar el desarrollador encargado de esta, además, tienen estados iguales que los de las
historias de usuario. En la figura 5 se ve la task 7969 “Modificación del midApi para
generalización del proceso de nómina”, la cual hace parte de la historia de usuario 7936 que se
muestra en la figura 5. Puede apreciarse también que el task está compuesto por su identificador
(N°), fecha de la última modificación (Last modified on) y fecha de creación (Submited on)
además, especificar el desarrollador que creó dicha tarea (Submitted by). En el apartado de
detalles se puede agregar una descripción de la tarea (Task description) y detalles (Details)
adicionales de esta. Finalmente, la parte de estado del progreso especifica la fecha de
inicio,final y previsto (Start date , End date y Due date), a quién fue asignada dicha tarea para
ser desarrollada (Assigned to), el esfuerzo estimado (Remaining effort (hours)) en horas y el
estado, que corresponde a los mismos trabajados en las historias de usuario.
Figura 7. Vista principal de una historia de usuario
Fuente: Tomada de Tuleap
37
Debido a la disponibilidad de tiempo, las reuniones diarias realizadas por SCRUM fueron
reemplazadas por el reporte de progreso diario dentro de cada task asignada en Tuleap; de esta
manera, el SCRUM master realizaba el seguimiento constante sobre las actividades a realizar
y se resolvían las dudas de manera pertinente. En la figura 6 se aprecia un ejemplo del
seguimiento realizado sobre una tarea por medio de comentarios; igualmente, estos
comentarios deben estar acompañados de commits sobre los repositorios de Git
Figura 8. Vista principal de una historia de usuario
Fuente: Tomada de Tuleap
Sprints semanales que evidencian el progreso de las tareas: Esta actividad consiste en
reuniones cortas donde se convocan a los interesados en el modelo de negocio junto con el
equipo de desarrollo. En estas reuniones se realiza la revisión de las tareas asignadas en el
sprint anterior, examinando el progreso de las mismas registrado en la plataforma Tuleap. De
38
esta manera, las tareas son marcadas por alguno de los estados asociadas a ellas (en proceso si
sucedía algún inconveniente en revisión y está ya ha sido terminada, pero requiere de algún
tipo de corrección, o terminada si se finalizó en su totalidad). Finalmente, se asignan las nuevas
tareas que serán trabajadas en la semana y cuya entrega corresponderá al siguiente sprint. Se
debe tener en cuenta que la finalización de un sprint está marcada por la entrega de un producto
parcial funcional. Durante el desarrollo del software a entregar se realizaron 4 entregas
parciales marcadas por el final de cada Release, las cuales fueron probadas por los clientes
encargados de la generación de la nómina de contratistas; también fueron involucrados en las
entregas los encargados del proyecto, DBA,Scrum master, líder del proyecto, líder del
desarrollo y el jefe de la oficina. Estos entregables fueron:
1- Versión estable con liquidación de salario básico: En este entregable se desarrolló una
versión estable que calcula el salario básico de los contratistas, esta versión debía contar con
interfaces de usuario que le permitieran al usuario verificar dichos valores y al sistema el
cálculo general de la nómina.Historias relacionadas: #7111
2- Versión estable con liquidación de descuentos: Este entregable se enfocó en el cálculo de
los descuentos para los contratistas, el cual debía tener en cuenta la liquidación de salario básico
para establecer el sueldo neto de cada contratista, además, establecer la sumatoria de
descuentos discriminados por concepto. Historias relacionadas: #9235 y #9695
3- Software con funcionalidades finalizadas: Se realizaron las correcciones y observaciones
producto de los entregables 1 y 2 especificadas por los encargados del proyecto. Historias
relacionadas: #7359 y #9107
4- Resultados de pruebas unitarias: Se realizaron pruebas sobre la función que carga las
reglas y realiza los cálculos tanto de salarios básicos como de descuentos. Basados en los
ejemplos de EXCEL que fueron facilitados por la dependencia encargada de la liquidación
actual, se utilizó librería de Golang para comparar los resultados arrojados por el nuevo
desarrollo con los esperados. Las pruebas unitarias fueron documentadas en su respectiva tarea,
acompañada de los commits a Git. Historia relacionada: #10101
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.
39
40
CAPÍTULO 8. RECURSOS
Se contempla en la Tabla 3, los recursos que se estiman serán necesarios en el proceso de
desarrollo a la solución de software.
Tabla 3: Recursos del proyecto
Tipo de Recurso Recurso Cantidad
Humano Desarrollador 2
Infraestructura Computador 2
Infraestructura Control de versiones y
avance del proyecto en
Tuleap.
1
Infraestructura Servidor de aplicaciones
para pruebas y servidor de
bases de datos
Infraestructura Almacenamiento disponible
en google drive para guardar
documentación
1 Giga
Tiempo Meses 6
Fuente: Realizado por los autores
41
CAPÍTULO 9. PRESUPUESTO
El presupuesto que se contempla desde el punto de vista del grupo desarrollador se evidencia en la tabla 4, expresada de la siguiente manera:
Tabla 4: Presupuesto del proyecto
Tipo de
Recurso
Recurso Cantida
d
Tiempo Valor
mensual
unitario
%
dedicación
Valor mensual unitario
según dedicación
Valor
cuatrimestral
unitario
Valor total
Humano Desarrollador 2 4 meses 2.000.000 100% 2.000.000 8.000.000 16.000.000
Humano DBA 1 4 meses 4.000.000 20% 800.000 3.200.000 3.200.000
Humano Scrum master 1 4 meses 4.100.000 30% 1.230.000 4.920.000 4.920.000
Humano Líder proyecto 1 4 meses 3.100.000 40% 1.240.000 4.960.000 4.960.000
Humano Líder
desarrollo
1 4 meses 4.100.000 40% 1.640.000 6.560.000 6.560.000
Infraestruct
ura
Servicio de
internet
2 4 meses 100.000 - - 400.000 800.000
42
Infraestruct
ura
Alquiler de
computadores
2 4 meses 200.000 - - 800.000 1.600.000
Infraestruct
ura
Servicio de luz 2 4 meses 40.000 - - 160.000 320.000
Infraestruct
ura
Servicio de
agua
2 4 meses 30.000 - - 90.000 180.000
Transporte Transporte 2 4 meses 20.000 - - 80.000 160.000
Varios Imprevistos,
Fotocopias.
2 4 meses 1'250 000 - - 1'250 000 5’000.000
Presupuesto Total: 43.540.000
Fuente: realizado por autores.
Los porcentajes de dedicación fueron calculados teniendo en cuenta el número de proyectos en los que estaban involucrados los diferentes
actores en este desarrollo.
43
CAPÍTULO 10. CRONOGRAMA
El proyecto está organizado por release, es decir, entregas de productos funcionales, los cuales
están compuestos de sprints, periodos de tiempo de 1 semana donde se realizan las tareas
necesarias para llevar a la realidad el producto propuesto.
Fuente: realizado por autores. En la figura 2 se aprecia el cronograma propuesto para el
proyecto
Figura 9: Cronograma de desarrollo del proyecto
Fuente: Realizado por autores
44
CAPÍTULO 11. DESARROLLO
11.1. Modelo de negocio actual
Actualmente, y aproximadamente por 20 años, la Oficina Asesora de Sistemas ha sido el ente
encargado dentro de la Universidad Distrital de llevar los procesos de generación y liquidación
de los pagos realizados a los funcionarios administrativos, docentes de planta y pensionados.
Esto se está realizando por medio de una base de datos elaborada y administrada por esta
dependencia donde, a través de procedimientos y funciones, se generan los valores que serán
devengados y descontados a cada empleado. Así, estos resultados son cargados a SICAPITAL,
una herramienta informática creada por la Secretaría Distrital de Hacienda que dentro de sus
funciones tiene encargado el pago de estos conceptos. De esta manera, y en lo que concierne a
personal de planta y pensionados, la Oficina tiene la responsabilidad completa de sobre la
liquidación de dichos pagos.
Sin embargo, para los casos de docentes de hora cátedra (salarios y honorarios) y contratistas,
el papel de la Oficina Asesora de Sistemas es diferente, ya que sólo se encarga de la revisión y
corrección de archivos de Excel, elaborados en otras dependencias de la universidad. Cuando
éstos son verificados por el personal de la OAS, son cargados a SICAPITAL que realiza el
procedimiento correspondiente al pago. Esto ha hecho que se caiga en dos errores respecto al
proceso de liquidación de las nóminas: en primera medida, las nóminas de planta y las que no
lo son se están realizando de manera aislada, cuando son procesos que deberían estar unificados
en un mismo sistema que facilite el proceso a los usuarios; en segunda medida, estos usuarios
no deberían tener la responsabilidad de la elaboración de la nómina, como se realiza
actualmente por medio de los archivos de EXCEL, sino deberían tener un rol de generación de
la misma, donde el sistema integrado sea el encargado y responsable de todo el proceso.
De esta manera, dado el modelo de negocio actual que se maneja para las distintas nóminas, lo
primero que tuvo que ser desarrollado fue una arquitectura y modelo de datos conjunto que
permita la asociación de todas las nóminas en un mismo sistema, y que a su vez tenga
interacción constante con otros sistemas ya desarrollados en la Oficina Asesora de Sistemas y
que son necesarios para el correcto funcionamiento de los nuevos a desarrollar, conservando
45
no solo la integración entre las nóminas sino entre los sistemas desarrollados para la
Universidad Distrital.
11.2. Diagrama de arquitectura de alto nivel
Figura 10: Diagrama de arquitectura de alto nivel
Fuente: Realizado por autores
46
11.3. Diagrama de procesos
Figura 11: Diagrama de procesos
Fuente: Realizado por autores
47
11.4. Arquitectura de datos
Para realizar un primer acercamiento al nuevo sistema planteado para la nómina, se utilizó el
punto de vista de estructura de información ofrecido por Archimate, donde se muestra la
información a utilizar en la empresa, proceso de negocio o aplicación en términos de tipos de
datos o estructura de clases. Además, puede mostrar cómo se representa la información a nivel
del negocio en la aplicación por medio de las estructuras de datos usadas. [15]
Figura 12. Diagrama de arquitectura de información
Fuente: Realizado por autores
En el diagrama anterior pueden apreciarse las entradas de datos (representadas por medio de
objetos de datos) que alimentarán al sistema de nóminas. Entre ellos se encuentran los datos de
proveedores y de contratación, provenientes de los sistemas Argo (sistema de contratación) y
Ágora (sistema de terceros y bando de proveedores), así como los datos de conceptos de
nómina, provenientes de Nix (Sistema de presupuesto y tesorería). A partir de estos datos, se
crean objetos de negocio propios del sistema de nómina Titán, los cuales serán explicados a
continuación:
Conceptos: Corresponden a todo aquello que le es devengado o descontado a los
empleados. Son una especialización de los conceptos provenientes de tesorería, es
decir, todos los conceptos utilizados en la nómina deben estar registrados en el sistema
de presupuesto y tesorería.
48
Detalle: Compuesto de los conceptos, el detalle permite desagregar y especificar cada
uno de los valores que le han sido o serán pagados a cada persona; es una asociación
entre la persona y sus conceptos aplicados.
Preliquidación: Corresponde a un proceso que puede realizarse cuantas veces sea
necesario y sobre las personas a las que se les desean realizar sus pagos. En ella se
calculan los valores (traducidos en conceptos) que se les serán pagados y descontados,
además de permitir realizar correcciones sobre ellos si no han sido calculados de manera
correcta. Esta preliquidación tendrá un estado relacionado a si ya fue liquidada o no.
Liquidación: Es el proceso posterior a la preliquidación, luego de que todo sea
corregido y verificado. Esta no puede ser corregida ni reversada pues sobre ella se
realizarán los pagos correspondientes.
Nómina: Es el proceso mensual realizado para cada uno de los empleados de la
Universidad Distrital, ya sean contratistas, funcionarios y docentes de planta,
pensionados y docentes de vinculación especial.
Gracias a este punto de vista de arquitectura se aprecia que existen procesos comunes para
todas las nóminas y que es posible trabajarlas como un conjunto y un sistema unificado. De la
misma manera, esta abstracción permite apreciar qué datos deben ser tenidos en cuenta y de
dónde provienen.
49
11.5. Modelo de datos
A continuación, y a partir del punto de vista de arquitectura de información, se propuso un
modelo de datos que permitiera integrar los procesos de todas las nóminas, incluida la de
contratistas. Este modelo fue plasmado en el software PGmodeler y está orientado hacia el
motor PostgreSQL, el trabajado y exigido por la Oficina Asesora de Sistemas. El modelo fue
revisado y avalado para su despliegue y posterior desarrollo dentro de la aplicación TITAN
(sistema de nómina) por los arquitectos y DBAs de la Oficina Asesora de Sistemas.
Cabe destacar que el modelo fue elaborado en conjunto con todos los involucrados en el
proyecto de nóminas, con el fin de que fuera general y válido para todas y pudiera conservarse
la integridad entre las mismas.
50
Figura 13. Diagrama relacional de sistema de nómina Titán (Realizada por autores)
Fuente: Realizado por autores
51
Figura 14. Tablas para manejo de nómina (Realizada por autores)
Fuente: Realizado por autores
La nómina dentro del modelo de datos propuesto hace referencia a cada uno de los grupos sobre
los cuales se pueden realizar preliquidaciones y liquidaciones, por ejemplo, nómina de
funcionarios de planta, nómina de contratistas o de pensionados, entre otras. Esta restricción
de grupo está dada por el campo ‘tipo_nomina’, referencia a la tabla tipo_nomina, donde se
almacenarán los grupos anteriormente mencionados. De esta manera, se puede registrar una
nómina de cualquier tipo, añadiendo a qué periodo pertenece y a qué grupo afectará. De igual
manera, se especifica dentro de esta nomina a qué tipo de vinculación pertenece, referenciando
a la tabla tipo_vinculación, que especifica si dicha nómina es de planta o de vinculación
especial.
52
Figura 15. Tablas para manejo de preliquidaciones (Realizada por autores)
Fuente: Realizado por autores
Dada una nómina registrada, a ella puede asociarse una preliquidación, que corresponde al
proceso de calcular los valores a descontar y devengar para cada persona perteneciente al grupo
definido por su nómina. Esta preliquidación tiene atributos como una descripción, una fecha
de inicio y fecha final (estos parámetros comprenden 30 días, por medidas institucionales, pero
se conserva esta opción debido a posibles cambios futuros), si ya fue liquidada o no (es decir,
si de todas aquellas preliquidaciones realizadas, alguna fue elegida para ser definitiva) y la
fecha en la que fue realizada. De esta manera, una nómina puede tener varias preliquidaciones,
pero solo una de ellas será tomada en cuenta como liquidación. Continuando con el modelo, se
encuentra el detalle de la liquidación, donde se especifica a cada persona qué conceptos le serán
pagados o descontados. Por este motivo, en esta tabla se tienen referencias a la preliquidación
a la cual pertenece, a qué persona pertenece y qué concepto tiene asociada a él. Esta persona
que se está referenciando en este detalle debe estar registrada en la tabla
información_proveedor, que se encuentra en el sistema Ágora, donde se registran todas las
personas que tengan un vínculo contractual con la Universidad Distrital. Se ha respetado esta
referencia ya que no era correcto repetir información básica de las personas dado que existe un
53
sistema en producción encargado de esta labor. Igualmente, en la tabla concepto se registran
todos aquellos valores que pueden descontarse o sumarse a un funcionario o contratista. Por
ejemplo, en esta tabla concepto deben estar la salud, la pensión, el sueldo básico, las distintas
primas o incentivos, así como las novedades que tenga cada persona sobre sus devengos, como
lo son préstamos, aportes a fondos de empleados, a fondos de pensiones voluntarias, entre
otros. Así mismo, los conceptos pueden ser devengos (suman al salario básico) o descuentos
(son restados del salario básico) en un principio, pues pueden existir otros tipos de conceptos
en un futuro. Unos ejemplos de datos registrados en esta sección del modelo pueden ser:
Tabla nómina:
ID Vinculación Nombre Descripción Estado Periodo Tipo nómina
1 1 CT Contratistas Activo 2017 6
Tabla preliquidación:
ID Nombre Nomina Fecha Descripción Fecha Inicio Fecha fin liquidada
1 PruebaCT 1 2000/0/0 Ejemplo 2017-01-01 2017-01-
28
No
Este ejemplo de preliquidación está relacionada a la nómina 1, es decir la de contratistas, y no
se encuentra aún liquidada.
Tabla preliquidación:
ID Nombre Nomina Fecha Descripción Fecha Inicio Fecha Fin liquidada
1 PruebaCT 1 2000/0/0 Ejemplo 2017-01-01 2017-01-
28
No
Tabla concepto:
Id nombre_concepto Naturaleza Alias_concepto
1 SueldoBasico devengo Sueldo Básico
2 PrestamoVivienda Descuento Préstamo Vivienda
54
Tabla detalle_preliquidacion:
Id Valor
calculado
Preliquidacion Persona Concepto Numero Contrato
1 10000 1 55 1 6
2 5000 1 55 2 6
De esta manera, la persona con id 55 tiene relacionada a ella un concepto 1 (sueldo básico) por
un valor de 10000, perteneciente a la preliquidación 1, que corresponde a la nómina de
contratistas. Igualmente tiene relacionada a ella otro concepto, el 2, que corresponde a un
descuento.
Figura 16. Tabla para manejo de conceptos y novedades (Realizada por autores)
Fuente: Realizada por autores
Las novedades anteriormente nombradas son específicas por cada persona, por lo que se
registrarán en la tabla concepto_por_persona, ya que corresponde a conceptos registrados en
su respectiva tabla pero que son especiales para cada proveedor. De la misma manera que en
el detalle de la preliquidación, se tiene una referencia a la información de proveedor del sistema
Ágora para las personas a las que se les hará la preliquidación, así como una referencia a la
tabla conceptos, para saber a qué corresponde dicho valor calculado. Las novedades, como
extensión de los conceptos, tienen más características asociadas a ellas, como por ejemplo el
número de cuotas (aplicable a créditos, préstamos, entre otros), la fecha en la que fue registrada,
el valor al que corresponde y de qué tipo son. Este último campo explica si la novedad es fija
o porcentual, dado que algunos valores no son estáticos, sino que son calculados sobre el salario
básico o el total devengado. Igualmente, los conceptos por persona deben tener una nómina
55
asociada, ya que existen personas en varias nóminas y los conceptos no son descontados de
varias nóminas sino de las que sean elegidas. Un ejemplo de datos registrados allí puede ser:
Valor Novedad Num Cuotas Persona Concepto Nomina Id Tipo Estado fecha
5000 20 55 2 1 1 Fijo Activo 2017-01-
01
Así, la persona 55 tiene una novedad asociada a ella, que corresponde al número 2 (préstamo
de vivienda) y es de la nómina 1 (control realizado por si la persona está dentro de varias
nóminas). Esta nómina es fija y está registrada por un valor de 5000.
Figura 17. Tabla para manejo de liquidaciones
Fuente: Realizada por autores
Finalmente, dentro del modelo se debe tener en cuenta la liquidación, es decir, tablas que
permitan la persistencia de aquellas preliquidaciones que han sido revisadas y elegidas como
definitivas, para ellos se utilizan las siguientes dos tablas: detalle_liquidacion y liquidación.
Puede notarse que son similares a las de preliquidacion y detalle_liquidacion, pues el objetivo
de estas es guardar la misma información que estas dos para que sean consultadas en un futuro
por los sistemas que realizan las órdenes de pago.
56
11.6. Generalización de la liquidación de la nómina
La generalización del proceso de nómina fue desarrollada con la finalidad de simplificar el
esfuerzo al momento de añadir nuevos procesos de nómina diferentes. Actualmente la
universidad cuenta con nómina de contratistas, hora cátedra honorarios y salarios, funcionarios
y docentes de planta y pensionados, en caso de requerir un nuevo tipo de nómina sólo se debe
agregar el controlador y el administrador de reglas de Golog.
El proceso de uso de la generalización comienza en la interfaz gráfica cuando el usuario
selecciona la nómina que desea liquidar, las nóminas se encuentran almacenadas en la base de
datos asignando a cada una un identificador de dominio.
Después de seleccionar la nómina deseada se listan las preliquidaciones de dicha nómina, al
seleccionar generar se asociará la preliquidación a la nómina. En la siguiente vista se mostrarán
las personas que se encuentran en la nómina seleccionada y se enviarán los datos de la
preliquidación y de las personas para que el MidApi los procese.
Si la información es enviada correctamente desde la interfaz gráfica hasta el MidApi este lleva
a cabo varios procesos, cargar las reglas para dicho dominio, verificar a qué nomina pertenece
la información para llevar a cabo la preliquidación y generar la información que posteriormente
se mostrara en la interfaz.
Para cargar las reglas de dicho dominio debe especificarse un número de dominio, con este se
hace una petición al CrudApi, que es el encargado de administrar las peticiones que solicitan
información de la base de datos. En la primera petición se solicitan los conceptos pertinentes y
en la segunda los predicados disponibles en la base de datos de la nómina seleccionada.
La preliquidación está definida en todas las nóminas respectivamente, esta se encarga de
procesar cada uno de los contratistas que han sido cargados de la base de datos de proveedores
(disponible en el sistema Ágora) y de operar las reglas de esta nómina con estos datos.
Se itera sobre los contratistas cargados utilizando las actas de inicio de estas, para poder
calcular la fecha de inicio de contrato, fecha de fin de contrato y la fecha de preliquidación de
57
la nómina, con estas es posible calcular el sueldo correspondiente para el contratista, si es un
mes en el que este contratista no trabaja los 30 días se debe calcular el número de días
trabajados para saber cuánto se le debe pagar, en caso contrario, simplemente se utiliza el pago
de 30 días.
En la siguiente parte del controlador se hace una inyección de reglas (es decir se adicionan
reglas o hechos que no son estáticas, sino que cambian dependiendo del contratista), se puede
ver la inyección de los días liquidados, el valor total del contrato y la duración del mismo.
Además, se agregan las novedades pertenecientes al contratista, siguiente a esto se dirigen las
reglas base junto con las inyectadas y novedades, llamadas simplemente reglas al archivo de
procesamiento de Golog.
Finalmente se guardan los conceptos calculados en la nómina y se envía dichos datos a la ruta
detalle_preliquidacion la cual se encarga de guardar estos conceptos en la base de datos,
exactamente en la tabla de igual nombre, posteriormente la interfaz se encargará de leer los
registros de esta tabla para cargarlos en la vista necesaria.
La generalización permite un mantenimiento más económico comparado con un sistema
desarrollado sin dicha generalización; se asegura un nivel de escalabilidad aceptable ya que el
sistema puede tener un crecimiento continuo de trabajo de manera fluida asegurando que
nuevos desarrolladores pueden agregar componentes y se evite una capacitación del código
compleja.
58
11.7. Interfaces de programación de aplicaciones (api)
Figura 18. Diagrama de componentes
Fuente: realizada por autores
Titán crud api
Ya que este se encarga de gestionar las conexiones hacia las bases de datos existen conexiones
hacia servicios de los sistemas Argo (Registro de contratos) y Ágora (registro de proveedores)
para obtener los datos necesarios para ejecutar la nómina de dichos contratistas, además tiene
una conexión local con la base de datos de reglas. Este se conecta con el mid api para proveer
los contratistas y reglas filtradas.
Titán mid api
Controlador específico es una subclase que hereda los métodos de controlador general para
implementar funcionalidades de manera específica dependiendo del tipo de nómina.
Existe una relación entre la preliquidacion y la liquidación ya que el tiempo de vida de la
preliquidación no depende del tiempo de vida de la liquidación, el tiempo de vida de la
preliquidacion termina cuando el usuario selecciona las personas y selecciona liquidar, a su vez
59
preliquidacion y liquidación utiliza una conexión directa a la base de datos de cada uno de sus
procesos para guardar los resultados.
Ruler Api
El ruler se encarga de procesar las reglas y contratistas y de entregar dicha respuesta al mid api
para que este se lo envíe a la interfaz y los resultados sean tangibles para el usuario.
11. 8 Manejo de reglas utilizando Golog
Dadas las directrices de la Oficina Asesora de Sistemas, y debido a que el proyecto Titán
implica realizar cálculos matemáticos, se decidió no almacenar fórmulas dentro del modelo de
datos descrito anteriormente; esto con el fin de lograr que los proyectos fueran independientes
del motor de base de datos y que fuera más sencilla la modificación y agregación de nuevas
fórmulas. De esta manera, los cálculos fueron traducidos en reglas y hechos que pudieran ser
procesados en Golog, un intérprete en Golog para el lenguaje de programación lógico prolog.
A continuación, se explicarán las reglas que fueron construidas y probadas y que permiten
realizar la liquidación de la nómina de contratistas.
En primera medida se tienen los hechos, que corresponden a la base de conocimiento necesaria
para que las reglas sean ejecutadas. Algunos hechos se crean en tiempo de ejecución, por medio
del controlador PreliquidacionCt, pero otros son cargados al hacer peticiones al API que
maneja las reglas. El principal objetivo de los hechos es relacionar porcentajes a distintas
vigencias, donde estos porcentajes corresponden a descuentos a realizar y se asocia a ellos un
año, debido a los cambios que puedan tener las diversas legislaciones. De forma general, los
hechos se estructuran de la siguiente manera
nombre_legislacion(vigencia, porcentaje)
En caso de que la legislación cuente con mayor información, basta con separarla por comas
para agregarla
60
Tabla 5. Ejemplo de algunos hechos en Golog
Hecho Descripción
reteica(2016, 9.66). Consiste en un hecho que tiene la vigencia
para la cual se aplicará el porcentaje de
retención de Industria y Comercio. Para
2016 este porcentaje fue de 9.66%
estampilla(2016, 0.01) Contiene información de qué porcentaje
debe ser descontado para Estampilla
Universidad Distrital en el año 2016. Para
esta vigencia es de 0.01
procultura(2016,0.005). Para el descuento de ProCultura en el año
2016, se tiene en cuenta para los cálculos un
porcentaje del 0.005
adulto_mayor(2016, 0.02). Para el descuento de adulto mayor en el año
2016, se tendrá en cuenta para las reglas un
porcentaje del 0.02
salud (2016,12.5).
pension(2016,16).
Para el cálculo de los descuentos
anteriormente descritos, y a pesar de que no
se realizan descuentos de salud y pensión a
contratistas, se deben realizar cálculos de
salud y pensión que sirven de base para los
cuatro descuentos obligatorios sobre esta
nómina. Por esto, se tienen hechos que
guardan el porcentaje de salud y pensión
para el año 2016.
salario_minimo(2016, 689454). Igualmente, para calcular salud y pensión,
es necesario tener en cuenta el valor del
salario mínimo, acompañado de la vigencia
a la cual pertenece, dado que cambia cada
año.
arl(2016,1,0.522). Para los cálculos de los descuentos también
debe tenerse en cuenta el valor de la ARL
pagada por el contratista, a pesar de no ser
61
descontada directamente, por esto se tienen
en cuenta su vigencia, el número de riesgo y
su porcentaje correspondiente
Como puede notarse, los hechos contienen la información necesaria para realizar los cálculos
que implican la nómina de contratistas.
Para poder sacar provecho de la base de conocimiento proporcionada por los hechos, se debe
hacer uso de las reglas. Estan puede verse como funciones que reciben parámetros y arrojan un
resultado. De manera general se construye una regla de la siguiente manera
nombre_regla(n parámetros de entrada separados por comas, n parámetros de salida separados
por comas) :- hecho1(información, hechos), hecho2 (información, hechos), … ,
operaciones_ariméticas.
De manera general, las reglas consultan los diferentes hechos registrados y traen información
pertinente, que puede ser operada y retornada como salida dentro de los parámetros definidos.
Por ejemplo, valor_pago(X,V,P):-valor_contrato(X,Y), duracion_contrato(X,D,V), R is Y / D,
dias_liquidados(X,DL),P is (DL * R). Esta regla calcula el valor que se debe pagar a cada
persona a liquidar, teniendo en cuenta el número de días del mismo y los días a liquidar. Se
recibe como parámetro el ID de la persona a liquidar y la vigencia (X, V), y P retornará el
resultado. En primera medida, se consultan los hechos de valor contrato y duración del contrato,
para así hallar en R el costo del día trabajado. Una vez con este valor, se consultan los días a
liquidar y se multiplican por el valor del día, retornando en P el resultado. Este valor se debe
tener en cuenta para los próximos cálculos, por lo que será parámetro de entrada para algunas
de las siguientes reglas.
62
Tabla 6. Ejemplo de algunas reglas en Golog
Regla Descripción
calcular_salud(B,V,VS) :- salud(V,PS), X is
(B * (PS/100) rnd 0), Y is ((X+50) / 100 int
0), VS is Y * 100.
Para el cálculo de salud se utiliza el valor
obtenido por la regla valor_pago y la
vigencia, retornando en VS el resultado.
Esta regla utiliza el hecho de salud para
obtener el porcentaje correspondiente según
la vigencia. Luego, en X, se guarda el valor
entero de multiplicar el salario por dicho
porcentaje. En Y se guarda la aproximación
de X a la centena más cercana (debido a que
los cálculos de salud deben ser presentados
de dicha manera) y finalmente en VS se
retorna el valor de salud luego de este
redondeo.
calcular_ARL(B,V,VARL) :-
arl(V,1,PARL), X is ((PARL/100)* (B *
0.40) rnd 0), Y is ((X + 50)/ 100 int 0),
VARL is Y * 100.
Para el cálculo de ARL se realiza algo
similar a los dos anteriores. Sobre el valor
calculado en valor_pago, se consulta el
porcentaje de ARL para la vigencia
entregada. Una vez se tiene este valor, se
multipica por el 40% del valor a pagar. De
la misma manera que en reglas anteriores, se
debe redondear a la centena más cercana;
luego de hacerlo, VARL retorna el valor
deseado.
calcular_reteica(B,V,R):-
base_retencion(B,V,X), reteica(V,RI), R is
((RI * X) / 1000 rnd 0).
Para calcular la retención de Industria y
Comercio se utiliza la base de retención
anteriormente explicada, multiplicándola
con el porcentaje de reteica que indique el
hecho según su vigencia.
calcular_estampilla(B,V,R) :-
base_retencion(B,V,X) , estampilla(V, RE)
, R is ((RE * X) rnd 0).
Para calcular el descuento de estampilla se
utiliza la base de retención anteriormente
explicada, multiplicándola con el porcentaje
63
de estampilla que indique el hecho según su
vigencia.
calcular_procultura(B,V,R) :-
base_retencion(B,V,X) , procultura(V, RP)
, R is ((RP * X) rnd 0).
Para calcular el descuento de Procultura se
utiliza la base de retención anteriormente
explicada, multiplicándola con el porcentaje
de Procultura que indique el hecho según su
vigencia.
calcular_adulto_mayor(B,V,R) :-
base_retencion(B,V,X) , adulto_mayor(V,
RA) , R is ((RA * X) rnd 0).
Para calcular el descuento de adulto mayor
se utiliza la base de retención anteriormente
explicada, multiplicándola con el porcentaje
de adulto mayor que indique el hecho según
su vigencia.
11.9 Software
Dentro del software elaborado, lo primero con lo que el usuario se encontrará es con una
interfaz que cuenta con dos opciones para él, las nóminas y las novedades. Dentro de las
nóminas podrá realizar preliquidaciones y liquidaciones, y por el lado de las novedades podrán
asociar conceptos por nómina a diferentes personas.
Figura 19. Vista inicial del software de nómina
Fuente: Realizado por autores
Dentro del módulo de nóminas, cuando el usuario accede a él, se puede observar todas las
nóminas registradas, su descripción, tipo, estado y periodo, así como una opción de acceder a
sus preliquidaciones.
64
Figura 20. Nominas registradas
Fuente: Realizado por autores
Igualmente se pueden registrar nuevas nóminas de ser necesario, señalando su nombre,
descripción, tipo de nómina y vinculación (que se listan según la información alojada en la
base de datos), su estado y periodo:
Figura 21. Vista de registro de nuevas nóminas
Fuente: Realizado por autores
Siguiendo, al elegir las preliquidaciones de una nómina especifica se acude a la siguiente
interfaz, donde se listan las preliquidaciones relacionadas a la nómina y se permiten agregar
nuevas.
65
Figura 22. Listado de preliquidaciones
Fuente: Realizado por autores
A la hora de registrar una preliquidación, basta con introducir su nombre, su descripción, su
estado (Activo-Inactivo) y su tipo, que corresponde a si se desea liquidar mensualmente (30
días), la primera quincena del mes o la segunda quincena del mes.
Figura 23. Registro de preliquidación nueva
Fuente: Realizado por autores
Si la preliquidación aún no ha sido generada, se puede realizar su generación. Al hacer esto, se
listarán las personas pertenecientes a la nómina de contratistas y se permitirá al usuario elegir
a cuáles de estas desea liquidar; también puede elegir a toda la lista generada si lo desea.
66
Figura 24. Listado de personas a preliquidar
Fuente: Realizado por autores
Una vez seleccionados, se generará automáticamente la preliquidación para cada uno de los
seleccionados.
En esta nueva interfaz se pueden observar las personas elegidas para la preliquidación,
desglosando por número de contrato cada uno de los devengos y descuentos que le
corresponden:
Figura 25. Resultado de proceso de preliquidación
Fuente: Realizado por autores
Puede observarse que al seleccionar el contrato número 8, en la derecha se observan sus pagos
totales. Igualmente, se añadió un resumen de preliquidación que condensa el total a pagar y
descontar para el conjunto de personas liquidadas.
67
Figura 26. Resumen de preliquidación
Fuente: Realizado por autores
De la misma manera, cuando estos cálculos sean revisados y el usuario esté seguro de que todo
ha sido preliquidado de la manera correcta, se permite desde esta interfaz seleccionar a qué
personas se liquidarán (teniendo en cuenta que el proceso de liquidación es el definitivo e
irreversible). Una vez hecho esto, se acude a una interfaz similar a la anterior, pero que contiene
los detalles de liquidación para este mes de ejemplo
Figura 27. Resultado de liquidación
Fuente: Realizado por autores
Figura 28. Resumen de liquidación
Fuente: Realizado por autores
68
Así, a partir de esta liquidación pueden generarse las órdenes de pago para cada una de las
personas seleccionadas en dicho proceso.
69
CAPÍTULO 12. RESULTADOS Y DISCUSIÓN
Para comprobar que las reglas utilizadas a la hora de realizar los cálculos arrojaban los cálculos
correctos y que el software presentado preliquidaba y liquidaba correctamente, se contó con la
colaboración del ordenador del gasto que realiza la nómina en este momento. Ésta nos facilitó
el documento de EXCEL que condensa los resultados de devengos y descuentos para el mes
de octubre de 2016 para 9 contratistas. De este se pudo obtener los datos de contratos para
ellos, como lo son la fecha de inicio, la fecha final y el valor de contrato, así como los resultados
para poder compararlos con el nuevo desarrollo. Dentro del Excel, en la parte de liquidación,
se tienen las siguientes personas y el valor a pagar sin descuentos. Cada una de ellas cuenta
con los siguientes descuentos: Reteica, EstampillaUD, Procultura y adulto mayor, arrojando al
final del documento el valor neto a pagar para cada uno de ellos.
Figura 29. Excel con resultados de liquidación de contratistas del mes de octubre
Fuente: ordenador del gasto
De esta manera, para la primera persona liquidada, se obtuvieron los mismos valores que se
muestran en el EXCEL, un pago bruto de $827.346, y un total a pagar de $806.273, luego de
aplicar los cuatro descuentos correspondientes, que también coinciden en valor.
70
Figura 30. Resultados de liquidación para persona N° 1, generados por Titán
Fuente: Realizada por autores
Figura 31. Resultados de liquidación para persona N° 2, generados por Titán
Fuente: Realizada por autores
El EXCEL facilitado correspondía a un mes donde los contratistas no habían laborado la
totalidad del mismo, por lo que permitió tener en cuenta esta excepción típica en la nómina
para así corregir lo planteado y poder obtener correctamente los valores. Igualmente, se
recibieron archivos de la dependencia que correspondían a otros meses de liquidación y se
obtuvieron los mismos resultados que en ellos.
v
v
v
v
71
CAPÍTULO 13. TRABAJOS FUTUROS
Sobre este proyecto de grado pueden generarse nuevos proyectos, que pueden partir del
desarrollo y el software aquí presentado. De esta manera no sólo podrán mejorarse aspectos
acá propuestos, sino podrá ampliarse la funcionalidad presentada en el módulo de manejo de
liquidación de nómina. Con el fin de continuar sobre el producto aquí creado, se plantean las
siguientes alternativas:
Integración con sistemas en producción: La Oficina Asesora de Sistemas ha puesto en
marcha los sistemas de terceros (Ágora) y de contratación (Argo), fundamentales para
alimentar con información real el sistema de nómina de contratistas. Es por esto que la
información aquí utilizada no debe solamente ser diferenciada a nivel de esquemas,
como se realizó en el software presentado, sino que debe provenir directamente de los
sistemas que la tienen a su cargo. El proyecto aquí presentado tuvo en cuenta la
estructura de estos sistemas y cómo estos disponen de los datos, pero no fueron
utilizados los servicios que estos proveen para consultar la información necesaria,
debido a que no han sido desarrollados. Por esto mismo, una mejora y trabajo futuro
necesario para el correcto funcionamiento y puesta en marcha del proyecto de nómina
es utilizar dichos servicios para que la información obtenida sea real y se permita la
liquidación de las personas registradas en ambos sistemas.
Órdenes de pago: El paso siguiente a la liquidación realizada en el sistema acá
desarrollado corresponde a las órdenes de pago, que deben tomar los valores aquí
calculados para que la Universidad Distrital pueda llevar a cabo los pagos a cada uno
de los contratistas vinculados a ella. Esta labor no es responsabilidad del sistema de
nómina, pero sí es una extensión del mismo, ya que debe tener en cuenta su esquema y
los servicios generados sobre él para poder realizarse.
Disponibilidad presupuestal: Dentro del funcionamiento de tesorería de la Universidad
Distrital y dada la asignación de presupuesto con la que cuenta este ente, es de vital
importancia que el sistema de nómina tenga en cuenta para su liquidación los dineros
con los que cuenta para llevar a cabo los pago. Por esta razón, un trabajo futuro sobre
este proyecto debe estar relacionado con la verificación de la disponibilidad de los
72
dineros con los que cuenta cada contratista para que le sea efectuado su pago, haciendo
del sistema no sólo aquel que calcule los valores, sino que automatice esta labor. Esta
no ha de ser responsabilidad completa del sistema de nómina, pero éste si debe utilizar
servicios que le permitan consultar dicha disponibilidad
Con el fin de implementar un sistema eficaz de auditoría, se necesitará un sistema que
pueda registrar las acciones de los usuarios en un registro visible para el auditor,
además, se debe establecer los límites de los roles para la ejecución del sistema, ya que
un usuario no debería llevar a cabo todo este proceso y mucho menos conocer los
aspectos fuera de sus responsabilidades, para evitar problemas legales y de ejecución.
73
CAPÍTULO 14. CONCLUSIONES
La Oficina Asesora de Sistemas se encuentra implementando procesos que permitan asegurar
la calidad de los productos que allí se generan. Por esta razón, y dentro del plan de
mejoramiento, se buscan desarrollar un ecosistema de aplicaciones que se encuentren
interrelacionadas, ya que los procesos de cada dependencia de la universidad no son
independientes, sino que se relacionan y dependen unos de otros. Así, el sistema de nómina de
contratistas aquí presentado hace parte de dicho conjunto de desarrollo que buscan reducir
costos y tiempos dentro de la universidad, además de posicionarla como una entidad que cuente
con un sistema de información seguro, ágil y efectivo.
Dados los resultados y la discusión realizada, el proceso de liquidación de nómina actual tarda
tardar de 2 a 3 días en realizarse de manera correcta. Sin existir sistemas de notificación y
validación no era extraño que la ejecución de la nómina tuviera que hacerse varias veces, lo
cual retrasa el proceso de pago para los contratistas y daba paso a errores que debían ser
intervenidos por el recurso humano de la universidad. Así, el nuevo sistema ejecuta la nómina
de una forma sencilla, además, permite que los encargados de la generación de esta noten
posibles errores en etapas tempranas de este proceso, lo cual mejora notablemente la velocidad
y veracidad liquidación de los contratistas vinculados a la entidad; este nuevo proceso no tarda
más de 20 segundos para el listado de contratista de prueba que fue mostrado en los resultados,
y puede tardar máximo 5 minutos para una lista de 800 contratistas.
Igualmente, la metodología utilizada actualmente en la Oficina Asesora de Sistemas (SCRUM)
emplea seguimiento continuo de los procesos y del desarrollo. Así, a diario y semanalmente se
realizaron reuniones de control, que permitieron a todo el equipo de desarrollo conocer cómo
se encontraba el proyecto en aspectos específicos y generales. Además, esto permitió una
comunicación inmediata en el equipo de desarrollo y análisis, lo que daba lugar a resolución
de problemas grupalmente y aceleró la elaboración e implementación del software aquí
presentado. SCRUM, entonces, presenta grandes ventajas respecto a las metodologías de
desarrollo tradicionales, donde la documentación es extensa y la comunicación del equipo se
lleva a cabo en periodos más largos, ya que el desarrollo de fracciones del sistema general
permite evidenciar problemas que pueden obviarse en etapas de análisis, pero gracias a las
74
metodologías agiles, como la aquí usada, dichos inconvenientes se superan fácilmente. Así
mismo, una vez eran desarrolladas las entregas parciales del producto, se realizaron pruebas al
realizar comparaciones con el proceso realizado actualmente y el nuevo desarrollo, lo que
permitió que se corrigieran errores de los cálculos realizados y se obtuvieran los mismos
resultados a la hora de realizar un proceso de liquidación. Esto se realizó a tiempo y permitió
que el software elaborado cumpliera con lo pactado en los procesos de análisis y diseño y
pudiera ser mostrado al usuario final como un software útil que facilitará el cálculo de la
nómina de contratistas.
Igualmente, y teniendo en cuenta una versión anterior del sistema Titán, se pudo evidenciar
deficiencias en dicho desarrollo en aspectos como la preliquidación de la nómina, además,
aspectos externos como la no existencia del sistema de proveedores. La utilización del entorno
de desarrollo fue vital para acoplarse a los estándares de la oficina y poder conectarse con los
demás sistemas, requerimientos que la versión anterior de Titán no poseía.
75
CAPÍTULO 15. REFERENCIAS
[1] Secretaría General de la Alcaldía Mayor de Bogotá D.C. (2008). Acuerdo 5 de 2008
Universidad Distrital Francisco José de Caldas. Octubre 27 de 2016, de Alcaldía Mayor de
Bogotá Sitio web: http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=37249#0
[2] 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
[3] Ken Schwaber. Jeff Sutherland. (2013). the Scrum Guide. 13 de octubre de 2016, de Scrum
Alliance Sitio web: https://www.scrumalliance.org/why-scrum/scrum-guide
[4] Juan Palacio. Claudia Ruata. (2014). Gestión de proyectos con Scrum Manager. 13 de
octubre de 2016, de Scrum Manager® Sitio web:
http://www.scrummanager.net/files/sm_proyecto.pdf
[5] Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde. (2012). Scrum Primer. 13 de
octubre de 2016, de InfoQ Sitio web: http://scrumprimer.org/primers/es_scrumprimer20.pdf
[6] Tridibesh Satpathy. (2016). Crear la visión del proyecto. En Una guía para el CUERPO DE
CONOCIMIENTO DE SCRUM (pp. 134-141). Phoenix, Arizona: SCRUMstudy.
[7] Tridibesh Satpathy. (2016). Formación del equipo de Scrum. En Una guía para el CUERPO
DE CONOCIMIENTO DE SCRUM (pp. 148-152). Phoenix, Arizona: SCRUMstudy.
[8] Tridibesh Satpathy. (2016). Creación de la lista priorizada de pendientes del producto. En
Una guía para el CUERPO DE CONOCIMIENTO DE SCRUM (pp. 163-174). Phoenix,
Arizona: SCRUMstudy.
[9] Tridibesh Satpathy. (2016). Creación de historias. En Una guía para el CUERPO DE
CONOCIMIENTO DE SCRUM (pp. 180-185). Phoenix, Arizona: SCRUMstudy.
76
[10] Tridibesh Satpathy. (2016). Creación de entregables. En Una guía para el CUERPO DE
CONOCIMIENTO DE SCRUM (pp. 210-215). Phoenix, Arizona: SCRUMstudy.
[11] Tridibesh Satpathy. (2016). Convocar Scrum de Scrums. En Una guía para el CUERPO
DE CONOCIMIENTO DE SCRUM (pp. 232-235). Phoenix, Arizona: SCRUMstudy.
[12] Tridibesh Satpathy. (2016). Retrospectiva Sprint. En Una guía para el CUERPO DE
CONOCIMIENTO DE SCRUM (pp. 242-245). Phoenix, Arizona: SCRUMstudy.
[13] Guillermo Pantaleo. (2015). Metodologías ágiles. En Ingeniería de Software (92-93).
Buenos Aires, Argentina: Alfaomega.
[14] 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
[15] 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
[16] 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
[17] 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/
[18] Beego. (2017). What is Beego? 6 de mayo 2017, de Beego Sitio web:
https://beego.me/docs/intro/
[19] Clocksin, William F. (2003). Programming in Prolog. Nueva York, Estados Unidos:
Springer.
[20] Sterling, Leo. (2000). The Art of Prolog. Boston, Estados Unidos: The Mit press.
77
[21] Secretaria General. (2016). Acuerdo 003 de 2016. Octubre 27 de 2016, de Universidad
Distrital Sitio web: http://sgral.udistrital.edu.co/xdata/rec/res_2016-003.pdf
[22] Secretaría General de la Alcaldía Mayor de Bogotá D.C. (2005). Acuerdo 187 de 2005
Concejo de Bogotá D.C. Marzo 24 de 2017, de Secretaría General de la Alcaldía Mayor de
Bogotá D.C Sitio web: http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=18545
[23] Secretaría General de la Alcaldía Mayor de Bogotá D.C. (2001). LEY 648 DE 2001.
Marzo 24 de 2017, de Secretaría General de la Alcaldía Mayor de Bogotá D.C Sitio web:
http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=4156
[24] Secretaría General de la Alcaldía Mayor de Bogotá D.C. (2005). ACUERDO 188 DE
2005. Marzo 24 de 2017, de Secretaría General de la Alcaldía Mayor de Bogotá D.C Sitio web:
http://www.alcaldiabogota.gov.co/sisjur/normas/Norma1.jsp?i=18546
[25] The Open Group. (2013). ArchiMate 2.1 Specification. Marzo 24 de 2017, de The Open
Group Sitio web: http://pubs.opengroup.org/architecture/archimate2-
doc/chap08.html#_Toc371945245