Castillo González Diego Orlando 2017

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
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.
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
2
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
3
Í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 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
4
Í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
5
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
6
realizados en los subproyectos anteriores y será apoyado por tecnologías libres y por el proceso
de desarrollo SCRUM.
7
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.
8
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.
9
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.
10
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.
11
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
12
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
15
los
16
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.
17
- 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
18
entregar
19
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
20
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.
21
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
22
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.
23
- 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
24
comparten sus avances y problemas con respecto al proyecto, lo que es esencial cuando se
25
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
26
Fielding sin utilizar HTTP o sin interactuar con la Web. Así como también es posible
diseñar una simple
27
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
28
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
29
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
30
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.
31
· 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.
32
Asesor I Título en programa académico
profesional, título en programa académico
de especialización y experiencia
Asesor II Título en programa académico

profesional, título en programa académico
de especialización y experiencia
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.
33
· 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
34
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]
35
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.
36
● 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
37
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.
38
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
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
39
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
4
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.
Fuente: Tomada de
4
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
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
4
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.
4
4
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 1

avance del proyecto en
Tuleap.
Infraestructura Servidor de aplicaciones

para pruebas y servidor
de bases de datos
Infraestructura Almacenamiento disponible 1 Giga

en google drive para guardar
documentación
Tiempo Meses 6
Fuente: Realizado por los autores
4
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 Cantida Tiempo Valor % Valor mensual unitario Valor Valor total
Recurso d mensual dedicación según dedicación cuatrimestral
unitario unitario
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 1 4 meses 4.100.000 40% 1.640.000 6.560.000 6.560.000

desarrollo
Infraestruct Servicio de 2 4 meses 100.000 - - 400.000 800.000

ura internet
4
Infraestruct Alquiler de 2 4 meses 200.000 - - 800.000 1.600.000
ura computadores
Infraestruct Servicio de luz 2 4 meses 40.000 - - 160.000 320.000

ura
Infraestruct Servicio de 2 4 meses 30.000 - - 90.000 180.000

ura agua
Transporte Transporte 2 4 meses 20.000 - - 80.000 160.000
Varios Imprevistos, 2 4 meses 1'250 000 - - 1'250 000 5’000.000

Fotocopias.
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.
4
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
4
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
4
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
5
11.3. Diagrama de procesos
Figura 11: Diagrama de procesos

4
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
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.
4
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.
4
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.
4
Figura 13. Diagrama relacional de sistema de nómina Titán (Realizada por autores)
5
Figura 14. Tablas para manejo de nómina (Realizada 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.
5
Figura 15. Tablas para manejo de preliquidaciones (Realizada 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
5
dado que existe un
5
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- No
28
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- No
28
Tabla concepto:
Id nombre_concepto Naturaleza Alias_concepto
1 SueldoBasico devengo Sueldo Básico
2 PrestamoVivienda Descuento Préstamo Vivienda
5
Tabla detalle_preliquidacion:
Id Valor Preliquidacion Persona Concepto Numero Contrato
calculado
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
5
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
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.
5
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
5
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.
5
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
5
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
6
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). Para el cálculo de los descuentos
pension(2016,16). 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.
6
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
6
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.
6
Tabla 6. Ejemplo de algunas reglas en Golog
Regla Descripción
calcular_salud(B,V,VS) :- salud(V,PS), X Para el cálculo de salud se utiliza el valor
is (B * (PS/100) rnd 0), Y is ((X+50) / 100 obtenido por la regla valor_pago y la
int 0), VS is Y * 100. 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) :- Para el cálculo de ARL se realiza algo
arl(V,1,PARL), X is ((PARL/100)* (B * similar a los dos anteriores. Sobre el valor
0.40) rnd 0), Y is ((X + 50)/ 100 int 0), calculado en valor_pago, se consulta el
VARL is Y * 100. 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):- Para calcular la retención de Industria y
base_retencion(B,V,X), reteica(V,RI), R is Comercio se utiliza la base de retención
((RI * X) / 1000 rnd 0). anteriormente explicada, multiplicándola
con el porcentaje de reteica que indique el
hecho según su vigencia.
calcular_estampilla(B,V,R) :- Para calcular el descuento de estampilla se
base_retencion(B,V,X) , estampilla(V, RE) utiliza la base de retención anteriormente
, R is ((RE * X) rnd 0). explicada, multiplicándola con el
6
porcentaje
6
de estampilla que indique el hecho según su
vigencia.
calcular_procultura(B,V,R) :- Para calcular el descuento de Procultura se
base_retencion(B,V,X) , procultura(V, RP) utiliza la base de retención anteriormente
, R is ((RP * X) rnd 0). explicada, multiplicándola con el
porcentaje de Procultura que indique el
hecho según su
vigencia.
calcular_adulto_mayor(B,V,R) :- Para calcular el descuento de adulto mayor
base_retencion(B,V,X) , adulto_mayor(V, se utiliza la base de retención
RA) , R is ((RA * X) rnd 0). 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
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.
6
Figura 20. Nominas registradas
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
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.
6
Figura 22. Listado de preliquidaciones
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
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
6
desea.
6
Figura 24. Listado de personas a preliquidar
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
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.
7
Figura 26. Resumen de preliquidación
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
Figura 28. Resumen de liquidación
7
Así, a partir de esta liquidación pueden generarse las órdenes de pago para cada una de las
personas seleccionadas en dicho proceso.
7
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.
7
Figura 30. Resultados de liquidación para persona N° 1, generados por Titán
Figura 31. Resultados de liquidación para persona N° 2, generados por Titán
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.
7
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
7
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.
7
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
7
de análisis, pero gracias a las
7
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.
7
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.
8
[10] Tridibesh Satpathy. (2016). Creación de entregables. En Una guía para el CUERPO DE
[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
[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.
8
[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

Castillo González Diego Orlando 2017

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Castillo González Diego Orlando 2017

Cargado por

Copyright:

Formatos disponibles

DESARROLLO DE LA SOLUCIÓN DE SOFTWARE PARA APOYAR EL

PROCESO DE GESTIÓN DE NÓMINA DE CONTRATISTAS EN LA

DIEGO ORLANDO CASTILLO GONZALEZ

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

DIEGO ORLANDO CASTILLO GONZALEZ

TRABAJO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

Figura 1: Tablero Scrum........................................................................................................................19

Tabla 1: Perfiles aptos para contratación por prestación de servicios. 26

La Universidad Distrital Francisco José de Caldas es un ente autónomo de carácter estatal

Actualmente en la institución se cuenta con varios procesos de gestión de nómina de acuerdo

De esta manera, este proyecto apoyará el proceso de desarrollo de la solución de software y

3.1. Objetivo general

3.2. Objetivos específicos

● Realizar la documentación del proceso de desarrollo basada en los requerimientos y la

● Complementar los procesos de análisis, levantamiento de requerimientos y

Actualmente la Universidad Distrital Francisco José de Caldas carece de un sistema integral

La Oficina Asesora de Sistemas de la Universidad Distrital Francisco José de Caldas (OAS)

5.1. Metodología de desarrollo ágil SCRUM

El concepto de rugby de un "Scrum" (donde un grupo de jugadores forma juntos para

Scrum y la mayoría de los métodos de manejo de proyectos tradicionales definen el riesgo

Dentro del equipo Scrum se distinguen los siguientes roles:

· Producto Owner: Corresponde al dueño del producto y es el responsable de maximizar el

· Development Team: El equipo de desarrollo está conformado de aquellos profesionales que

5.1.2. Fases de SCRUM

En el SBOK (Scrum Body of Knowledge) se definen 19 procesos Scrum, agrupados en cinco

- Identificar al Scrum Master y a los Stakeholders: Utilizando criterios de selección, como

-Realizar el plan de lanzamiento: Se revisan las historias de usuario en el Product Backlog

2. Planificación y estimación: Comprende cinco procesos y también es aplicable para

- Creación de historias de usuario: El Product Owner, gracias a la interacción con socios y su

- Aprobación, estimación y asignación de historias de usuario: Se utilizan los métodos

- Creación de la lista de pendientes del sprint: Dentro de la reunión de planificación de

1. Refactorización: Consiste en mejorar el mantenimiento del código existente y

- Reuniones diarias de pie: Consiste en reuniones diarias de 15 minutos donde se reporta el

- Mantenimiento de la lista priorizada de pendientes del producto: El propietario del

1- ¿En que ha estado trabajando mi equipo desde la última reunión?

- Demostración y validación del Sprint: En este proceso se le enseña al propietario del

En la fase de lanzamiento o release está marcada por la entrega de productos aceptados

Como puede apreciarse, la metodología Scrum presenta la ventaja de corrección de errores de

5.2. REST API

En realidad, REST se refiere estrictamente a una colección de principios para el diseño de

Aunque REST no es un estándar, está basado en estándares:

En la siguiente imagen se explica la arquitectura de Beego, que consta de 8 módulos

Figura 2. Arquitectura de Beego

Figura 3. Lógica de ejecución de Beego

5.4. Programación lógica y prolog

La programación de Prolog se basa en las relaciones formales, la existencia de objetos y

5.6. Reglamentación para nómina de contratistas dentro de la Universidad Distrital

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

Servicios técnicos o tecnológicos Título de formación en programa

Servicios profesionales Título en programa académico profesional

Servicios profesionales especializados Título en programa académico profesional

Asesor II Título en programa académico

Fuente: Sistema de información de Secretaría General, “Resolución 003 de 2016,”

Entonces, la escala de honorarios de los contratos de prestación de servicios profesionales

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.