Análisis y Desarrollo en la Solución de Software para Apoyar el Proceso de Gestión de Nómina en la Universidad Distrital, Basado en los Lineamientos del Proceso de Desarrollo SCRUM/OAS

Texto completo

(1)ANÁLISIS Y DESARROLLO DE SOLUCIÓN DE SOFTWARE PARA APOYAR EL PROCESO DE GESTIÓN DE NÓMINA EN LA UNIVERSIDAD DISTRITAL, BASADO EN LOS LINEAMIENTOS DEL PROCESO DE DESARROLLO DE LA OAS.. AUTORES: INGRID JULIETH CONTRERAS ROJAS CARLOS ANDRES CHUNG SOTO. PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS. ALEJANDRO PAOLO DAZA DIRECTOR. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C. 2017.

(2) TABLA DE CONTENIDO Pág. CAPITULO 1 INTRODUCCION. 7. CAPITULO 2 PLANTEAMIENTO DEL PROBLEMA. 8. CAPITULO 3 OBJETIVOS. 9. 3.1 Objetivo general. 9. 3.2 Objetivos específicos. 9. CAPITULO 4 JUSTIFICACION. 10. CAPITULO 5 MARCO TEORICO. 11. 5.1 El proceso SCRUM/OAS. 11. 5.1.1 Información general SCRUM. 11. 5.1.2 Roles. 12. 5.1.2.1 Product Owner. 12. 5.1.2.2 Equipo de Desarrollo. 13. 5.1.2.3 Scrum Master. 13. 5.2 Elementos de SCRUM. 15. 5.2.1 Product Backlog. 15. 5.2.2 Sprint Backlog. 17. 5.2.3 Sprint (Iteración). 17. 5.2.4 Sprint Planning Meeting. 18. 5.2.5 Scrum diario. 19. 5.2.6 Revisión de Sprint. 20. 5.2.7 Feedback. 21. 5.2.8 Release. 22. 5.2.9 Identificación de funcionalidades del software. 22. 2.

(3) 5.3 Nómina. 22. 5.3.1 Retribución bruta. 23. 5.3.2 Descuentos en la nómina. 23. 5.3.3 Liquidación mesada pensional. 24. 5.3.3.1 Pensionado. 24. 5.3.3.2 Pensión de jubilación. 24. 5.3.3.3 Pensión de invalidez. 26. 5.3.3.4 Mesada pensional. 28. 5.3.3.5 Subsidio de libros. 29. 5.3.3.6 Subsidio familiar. 29. 5.3.3.7 Incremento cotización salud. 30. 5.3.4 Sustitutos. 31. 5.4 REST API. 32. 5.5 Beego. 34. 5.6 Prolog. 35. 5.7 Golog. 36. CAPITULO 6 ALCANCE Y LIMITACIONES. 37. 6.1 Alcances. 37. 6.2 Limitaciones. 37. CAPITULO 7 METODOLOGIA. 38. 7.1 Valores. 38. 7.2 Principios. 39. 7.3 Descripción y desarrollo de tareas. 40. 7.3.1 Creación y asignación de tareas en TULEAP CAPITULO 8 RECURSOS Y PRESUPUESTO 8.1 Fuentes de financiación. 41 44 44. 3.

(4) 8.2 Análisis costo-beneficio. 44. CAPITULO 9 CRONOGRAMA. 46. CAPITULO 10 DESARROLLO. 48. 10.1 Modelo de negocio actual. 48. 10.2 Arquitectura de información. 48. 10.2.1 Componentes. 50. 10.3 Modelo de datos TITAN. 51. 10.3.1 Descripción al modelo de datos TITAN 10.4 Modelo de datos para nomina pensionados 10.4.1 Descripción al modelo de datos pensionados. 53 55 57. 10.5 Integración de información y generalización para gestión de nómina. 58. 10.6 Interfaces de programación de aplicaciones (API). 62. 10.7 Parametrización de obligaciones de ley por medio de reglas de negocio usando el intérprete Golog. 64. 10.8 Software. 69. CAPITULO 11 ANALISIS Y RESULTADOS 11.1 Evaluación y cumplimiento de los objetivos. 71 73. CAPITULO 12 CONCLUSIONES. 75. CAPITLO 13 BIBLIOGRAFIA. 77. 4.

(5) INDICE DE ILUSTRACIONES. Figura 1. Visión general de flujo de un Project Scrum. 11. Figura 2. Características de los papeles principales de Scrum. 15. Figura 3. Arquitectura de Beego. 34. Figura 4. Lógica de ejecución Beego. 35. Figura 5. Epic de tareas en TULEAP.. 41. Figura 6. Tarea análisis de nómina pensionados.. 42. Figura 7. Story de comentarios de la tarea.. 42. Figura 8. Tarea para creación de reglas. 42. Figura 9. Tarea para implementación de reglas de negocio. 42. Figura 10. Tarea para realizar pruebas con las reglas de negocio. 43. Figura 11. Tarea para generación de CrudApi. 43. Figura 12. Cronograma de actividades. 46. Figura 13. Diagrama de tareas desarrolladas. 47. Figura 14. Arquitectura de información de nómina. 49. Figura 15. Modelo de datos TITAN. 52. Figura 16. Tabla de concepto de TITAN. 53. Figura 17. Tabla concepto por persona de TITAN. 53. Figura 18. Tabla de tipo de nómina de TITAN. 54. Figura 19. Acercamiento detalle de liquidación y pre liquidación de TITAN 54 Figura 20. Acercamiento liquidación de TITAN. 54. Figura 21. Acercamiento pre liquidación de TITAN. 55. Figura 22. Modelo de datos nomina pensionados. 56. Figura 23. Interfaz de nóminas registradas. 58. Figura 24. Interfaz preliquidacion de nómina. 58. 5.

(6) Figura 25. Interfaz de consulta de pensionados. 58. Figura 26. Reglas de negocio sustitutos. 60. Figura 27. Insert para informacion sustituto. 61. Figura 28. Insert para informacion beneficiario. 61. Figura 29. Tabla personal.beneficiarios. 61. Figura 30. Interfaces de programación de aplicaciones. 62. Figura 31. Lista de funciones Golog. 63. Figura 32. Lista de controladores. 63. Figura 33. Lista de Ruler. 64. Figura 34. Vista principal del software. 69. Figura 35. Nominas registradas. 69. Figura 36. Registro para nuevas nominas. 70. Figura 37. Detalle de preliquidacion. 70. Figura 38. Resumen conceptos en EXCEL. 71. Figura 39. Resumen conceptos en aplicativo. 72. Figura 40. Interfaz de selección para preliquidacion. 72. Figura 41. Resumen de preliquidacion. 73. INDICE DE TABLAS Tabla 1. Porcentaje salario convención colectiva de trabajo. 25. Tabla 2. Porcentaje de liquidación según tiempo en la universidad. 26. Tabla 3. Porcentaje por invalidez según porcentaje de disminución. 27. Tabla 4. Recursos y su correspondiente presupuesto. 44. Tabla 5. Costos para el cálculo de nómina de un mes. 45. Tabla 6. Hechos en Prolog. 64. Tabla 7. Reglas de negocio en Prolog. 66. 6.

(7) CAPITULO 1. INTRODUCCIÓN. La Universidad Distrital Francisco José de Caldas en su calidad como entidad de educación superior tiene establecida dentro de su estructura un modelo financiero como cualquier otro ente público, en el cual debe calcular, generar y devengar todo tipo de obligaciones con sus empleados de acuerdo a la ley, para este proceso se debe tener en cuenta diferentes categorías según el tipo de contrato, estado de vinculación y labor desempeñada dentro de la universidad, esto hace que sea necesario mes a mes llevar un control para la liquidación de esas mensualidades definido como nómina. La liquidación de nómina es un proceso en el cual se tiene en cuenta los diferentes conceptos como honorarios, prestaciones y aportes varios, es de carácter muy importante y delicado puesto que no debe generar errores y sus resultados deben ser exactos ya que la universidad cuenta con recursos definidos por el gobierno al iniciar el año y estos deben ser empleados para cubrir los respectivos rubros y obligaciones que correspondan. Para realizar la gestión de nómina la universidad cuenta con herramientas como bases de datos y aplicaciones desagregadas, las cuales están definidas para cada tipo de empleado (docentes de planta, docentes de vinculación especial, empleados oficiales y administrativos) como también para los pensionados, la anterior categorización ha generado un problema de diversificación dentro del sistema, lo cual lleva a que el desarrollo de este proyecto a cargo de la OAS (Oficina Asesora de Sistemas) se centre en la construcción de una herramienta que permita realizar todo este proceso de forma simplificada y efectiva teniendo en cuenta todos los conceptos que integran la parte financiera de manera que se pueda establecer un modelo flexible y que se adapte a las necesidades de la universidad en base a unas reglas predefinidas donde se contempla una mejora constante.. 7.

(8) CAPITULO 2. PLANTEAMIENTO DEL PROBLEMA. La liquidación de nómina dentro de la Universidad Distrital es un proceso realizado de forma mensual por el área de tesorería utilizando herramientas desactualizadas que muchas veces solo tienen en cuenta información antigua de tablas lo cual hace trae como consecuencia que en ocasiones su gestión sea propensa a errores en su ejecución y no refleje los resultados esperados a pesar de ser algo repetitivo, a lo anterior hay que sumar la variedad de contrataciones y nominas que existen, como lo son docentes, administrativos, oficiales y pensionados, la cantidad de datos que se maneja respecto al número de empleados es demasiada, lo cual genera demoras en todos los procedimientos y afecta de manera significativa el funcionamiento de la universidad. El nivel de fiabilidad que da el sistema actual no es del todo confiable teniendo en cuenta que muchas veces se debe realizar varias pre liquidaciones antes de tener un informe definitivo para su aprobación, lo cual conlleva a que las herramientas utilizadas no sean suficientes para llevar a cabo dicha labor, el principal inconveniente radica en las diferentes características que contiene cada nómina y la variedad de conceptos que se aplican en la liquidación de las mismas, se hace necesario tener una sola herramienta que permita relacionar toda la información de forma eficiente y unificada para así reducir tiempos y costos, además garantizando la veracidad de los datos mostrados en el proceso mes a mes. La mayoría de nóminas tienen datos, conceptos y novedades comunes que permiten realizar consultas y visualizar la información de forma más simplificada, aquí es donde aparece la excepción con la nómina de pensionados, la cual a diferencia de los empleados activos, debe tener en cuenta datos y consultas únicas de los mismos, además de aplicar novedades diferentes a las ya registradas, se aplican ciertos cálculos y aparecen otros beneficios a tener en cuenta para la liquidación mensual, lo cual hace necesario establecer un modelo donde se detallen las particularidades que conlleva la categoría de pensionado sin dejar ninguna de lado, para así garantizar que el proceso se ejecutara con éxito. 8.

(9) CAPITULO 3. OBJETIVOS. 3.1. Objetivo General Establecer un modelo de datos y reglas que contemple la totalidad de los conceptos relacionados con la nómina de pensionados de la Universidad Distrital para apoyar el proceso de la OAS en el desarrollo de una herramienta flexible y unificada basada en el modelo de desarrollo de la OAS. 3.2. Objetivos específicos ● Identificar los conceptos que caracterizan la categoría de pensionado dentro de la Universidad Distrital junto con los datos relacionados a dicha categorización que permitan integrar la liquidación de nómina. ● Parametrizar de forma asertiva las principales obligaciones establecidas por la ley para la liquidación de la nómina de pensionados lo que permita un mejor entendimiento al momento de su gestión. ● Integrar la información definida por la Universidad Distrital para el proceso de liquidación de nómina de pensionados de manera que la base de datos generada tenga interoperabilidad y sea de fácil acceso garantizando su confiabilidad. ● Realizar un análisis acerca del costo-beneficio que surge al implementar el producto resultante de software, y así obtener una mejora en el proceso de liquidación de nómina.. 9.

(10) CAPITULO 4. JUSTIFICACIÓN. La Universidad Distrital Francisco José de caldas en su continua tarea de formar profesionales para el bien de la sociedad busca la construcción de un modelo de entidad orientado hacia la calidad no solo académica, sino de todos los procesos que la conforman, es por tanto que se hace necesario fortalecer todos los departamentos que la componen, caso tal como lo es área financiera, la cual como se descrito anteriormente tiene una gran tarea como lo es la liquidación de nómina de todas las personas que tienen un vínculo contractual con la institución, debido a esto es primordial proveer de herramientas útiles que sean funcionales y que permitan la integración de toda la información que se maneja en dicha área para tener un mayor control sobre la gestión realizada y se reduzca el margen de errores que se puedan generar. Debido a que los medios existentes en la actualidad para realizar este proceso presentan problemas de interoperabilidad, no son adaptables a las nuevas normas legales que rigen a la nómina y presentan una gran división por la variedad de vinculaciones con las que cuenta la universidad, es preciso generar una solución eficiente a las problemáticas descritas anteriormente. La OAS en su función como departamento generador de soluciones tecnológicas e informáticas para la Universidad Distrital y de la mano de los estudiantes de último semestre de Ingeniería de Sistemas se ha propuesto desarrollar un proyecto que permita unificar todas las nóminas existentes junto con la información relacionada a las mismas y que este actualizada con toda la reglamentación correspondiente, la cual se flexible y adaptable según las necesidades que se presenten a futuro. Este desarrollo establece una relación de mutuo beneficio para todos los implicados ya que permite a los estudiantes aplicar todos los conocimientos adquiridos en su formación y les brinda experiencia en el ámbito laborar la cual es fundamental hoy en día para el desarrollo como profesionales; por otra parte la OAS se beneficia al actualizarse en las nuevas tecnologías y conocimientos de los estudiantes para el desarrollo de soluciones por medio de software libre que dan como resultado herramientas más robustas, funcionales y adaptables.. 10.

(11) CAPITULO 5. MARCO TEORICO. 5.1 El proceso SCRUM/OAS La implementación exitosa de la metodología Scrum se debe a que se puede aplicar de manera efectiva a cualquier proyecto en cualquier industria desde proyectos pequeños o equipos con tan sólo seis miembros, hasta proyectos grandes y complejos con cientos de miembros por equipo1.. 5.1.1 Información general SCRUM Scrum es una de las metodologías ágiles más populares. Es una metodología de adaptación, iterativa, rápida, flexible y eficaz, diseñada para ofrecer un valor significativo de forma rápida en todo el proyecto. Scrum garantiza transparencia en la comunicación y crea un ambiente de responsabilidad colectiva y de progreso continuo. El marco de Scrum, está estructurado de tal manera que es compatible con los productos y el desarrollo de servicio en todo tipo de industrias y en cualquier tipo de proyecto, independientemente de su complejidad. Una fortaleza clave de Scrum radica en el uso de equipos multi-funcionales, auto-organizados, y con poder que dividen su trabajo en ciclos de trabajo cortos y concentrados llamados Sprints2.. Figura 1. Visión general de flujo de un Project Scrum.. 12. Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016. 11.

(12) 5.1.2 Roles Son aquellos papeles que obligatoriamente se requieren para producir el producto o servicio del proyecto. Las personas a quienes se les asignan roles, están plenamente comprometidas con el proyecto y son las responsable del éxito de cada iteración y del resultado final. En un Equipo Scrum se espera que intervengan tres roles: Product Owner, Equipo de Desarrollo y ScrumMaster.3 5.1.2.1 Product Owner El Product Owner es la persona responsable del éxito del producto desde el punto de vista de los stakeholders. Sus principales responsabilidades son: ● Determinar la visión del producto, hacia dónde va el equipo de desarrollo. ● Gestionar las expectativas de los stakeholders. ● Recolectar los requerimientos. ● Determinar y conocer en detalle las características funcionales de alto y de bajo nivel. ● Generar y mantener el plan de entregas (release plan): fechas de entrega y contenidos de cada una. ● Maximizar la rentabilidad del producto. ● Determinar las prioridades de cada una de las características por sobre el resto. ● Cambiar las prioridades de las características según avanza el proyecto, acompañando así los cambios en el negocio. ● Aceptar/rechazar el producto construido durante el Sprint y proveer feedback valioso para su evolución. ● Participar de la revisión del Sprint junto a los miembros del Equipo de Desarrollo para obtener feedback de los stakeholders. El Product Owner se focaliza en maximizar la rentabilidad del producto. La principal herramienta con la que cuenta para poder realizar esta tarea es la priorización. De esta manera puede reordenar la cola de trabajo del equipo de desarrollo para que éste construya con mayor anticipación las características o funcionalidades más requeridas por el mercado o la competitividad comercial4. Otra responsabilidad importante del Product Owner es la gestión de las expectativas de los stakeholders, mediante la comprensión completa de la problemática de negocio y su descomposición, hasta llegar al nivel de requerimientos funcionales.. 3 4. Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016. 12.

(13) 5.1.2.2 Equipo de Desarrollo El equipo de desarrollo está formado por todos los individuos necesarios para la construcción del producto en cuestión. Es el único responsable por la construcción y calidad del producto. El equipo de desarrollo es autoorganizado. Es el mismo equipo quien determina la forma en que realizará el trabajo y cómo resolverá cada problemática que se presente. La delimitación de esta auto-organización, está dada por el objetivo a cumplir: transformar las funcionalidades comprometidas en software funcionando y con calidad productiva, o en otras palabras, producir un incremento funcional potencialmente entregable. Es recomendable que un equipo de desarrollo se componga de hasta nueve (9) personas. Cada una de ellas debe poseer todas las habilidades necesarias para realizar el trabajo requerido. Esta característica se conoce como multifuncionalidad y significa que dentro del equipo de desarrollo no existen especialistas exclusivos, sino más bien individuos generalistas con capacidades especiales. Lo que se espera de un miembro de un equipo de desarrollo es que no solo realice las tareas en las cuales se especializa, sino también todo lo que esté a su alcance para colaborar con el éxito del equipo. El equipo de desarrollo tiene tres (3) responsabilidades tan fundamentales como indelegables. La primera es proveer las estimaciones de cuánto esfuerzo será requerido para cada una de las características del producto. La segunda responsabilidad es comprometerse al comienzo de cada Sprint a construir un conjunto determinado de características en el tiempo que dura el mismo. Y finalmente, también es responsable por la entrega del producto terminado al finalizar cada Sprint.5 5.1.2.3 Scrum Master El Scrum Master, es el Coach del equipo y es quien lo ayuda a alcanzar su máximo nivel de productividad posible. Es un líder, facilitador, provocador, detective y soplador de brasas. Líder por ser un ejemplo a seguir, facilitador por fomentar contextos de apertura y discusión donde todos pueden expresar sus opiniones y lograr consensos comunes, provocador por desafiar las estructuras rígidas y las antiguas concepciones sobre cómo deben hacerse las cosas, detective por involucrarse activamente en la búsqueda e identificación de indicios y pistas en la narrativa del equipo y los individuos y finalmente, soplador de brasas, “un socio facilitador del aprendizaje, que acompaña al otro en una búsqueda de su capacidad de aprender para generar nuevas respuestas” conectar a las personas con sus pasiones, con sus fuegos, muchas veces apagados.. 5. Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016. 13.

(14) Se espera, además, que el Scrum Master acompañe al equipo de trabajo en su día a día y garantice que todos, incluyendo al Product Owner, comprendan y utilicen Scrum de forma correcta. Las responsabilidades principales del Scrum Master son: ● Velar por el correcto empleo y evolución de Scrum. ● Facilitar el uso de Scrum a medida que avanza el tiempo. Esto incluye la responsabilidad de que todos asistan a tiempo a las daily standup meetings, reviews y feedbacks. ● Asegurar que el equipo de desarrollo sea multi-funcional y eficiente. ● Proteger al equipo de desarrollo de distracciones y trabas externas al proyecto. ● Detectar, monitorear y facilitar la remoción de los impedimentos que puedan surgir con respecto al proyecto y a la metodología. ● Asegurar la cooperación y comunicación dentro del equipo. Además de estas cuestiones, el Scrum Master debe detectar problemas y conflictos interpersonales dentro del equipo de trabajo. Para respetar la filosofía auto-organizativa del equipo, lo ideal es que el equipo mismo sea quien resuelva estas cuestiones. En el caso de no poder hacerlo, deberá involucrarse al Scrum Master y eventualmente a niveles más altos de la gerencia. El Scrum Master es un Líder Facilitador, no es casualidad la aparición de un nuevo nombre o rol. Este nuevo concepto del enfoque ágil, representa el cambio respecto de las responsabilidades y el modelo de gestión de los gerentes de proyectos tradicionales en relación al equipo de trabajo. El Scrum Master puede ser visto como un Facilitador o Coach, incluso muchas veces se lo referencia así en lugar de Scrum Master. Su responsabilidad es asegurar que se cumpla con el proceso de Scrum sin interferir directamente en el desarrollo del producto final. Es importante establecer que el equipo de Scrum elige la forma de trabajo que más prefiera, siempre que se cumplan las pautas básicas de Scrum, por ello mientras lo hagan no existe una forma “errónea” de trabajar. El rol del Scrum Master también incluye asegurar que el desarrollo del producto tenga la mayor probabilidad de ser completado de forma exitosa. Para lograr este cometido, trabaja de cerca con el Product Owner asegurando una correcta priorización de los requerimientos, por un lado, y con el equipo de desarrollo para convertir los requerimientos en un producto funcionando, por el otro. Por lo que hemos visto, el Scrum Master tiene un rol más indirecto que un Gerente de Proyectos tradicional, a pesar de esto es un rol vital para el éxito de Scrum. Para todo Gerente de Proyectos tradicional, el cambio hacia esta 14.

(15) nueva filosofía de gestión es desafiante. Se dice que “Scrum es fácil, hacer Scrum es difícil”. Esta afirmación tiene sus fundamentos en la idea de que una cosa es aprender Scrum y otra muy diferente es aplicar Scrum exitosamente. Emprender este camino significa adoptar una filosofía de liderazgo servil por sobre el comando y control. Finalmente, cuando un ScrumMaster logra cubrir exitosamente su rol, la implementación de Scrum sucede sin sobresaltos. Las responsabilidades del Scrum Master deberían cubrir la totalidad de su tiempo. Si bien hay casos en los que el Scrum Master cumple, además de su rol, el rol de desarrollador, no siempre es la mejor de las situaciones ya que ambas responsabilidades podrían llegar a exceder la disponibilidad de una sola persona, y así alguno de ambos roles no estaría siendo cubierto satisfactoriamente.6. Figura 2. Características deseadas de los papeles principales de Scrum.. 5.2 Elementos de SCRUM El proceso de Scrum posee una mínima cantidad necesaria de elementos formales para poder llevar adelante un proyecto de desarrollo. A continuación describiremos cada uno de ellos.7 5.2.1 Product Backlog: El primero de los elementos, y principal de Scrum, es el Product Backlog también conocido como Pila del Producto. El Product Backlog es básicamente un listado de ítems o características del producto a construir, mantenido y priorizado por el Product Owner. Es 67. Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016. 15.

(16) importante que exista una clara priorización, ya que es esta priorización la que determinará el orden en el que el equipo de Proyectos Ágiles con Scrum desarrollo transformará las características en un producto funcional acabado. Esta prioridad es responsabilidad exclusiva del Product Owner y, aunque el equipo de desarrollo pueda hacer sugerencias o recomendaciones, es el Product Owner quién tiene la última palabra sobre la prioridad final de los ítems del Product Backlog, teniendo en cuenta el contexto de negocio. Una forma de priorizar los ítems del Product Backlog es según su valor de negocio. Podemos entender el valor de negocio como la relevancia que un ítem tiene para el cumplimiento del objetivo de negocio que estamos buscando. Un enfoque diferente de medir la prioridad de un determinado ítem del Backlog es calcular el beneficio económico que se obtendrá en función de la inversión que se deba realizar. Esto, si bien es una simple fórmula matemática, tiene implícita la problemática de encontrar o conocer el valor económico ganado por la incorporación de una determinada característica a un producto. Una vez identificada, el cálculo es relativamente simple: ROI = valor de negocio/costo Donde el costo representa el esfuerzo necesario para la construcción de una determinada característica de un producto y el valor de negocio es el crédito económico obtenido por su incorporación. Ya sea que los ítems del Backlog se prioricen por valor de negocio o por ROI, en cualquier caso llamémosle “priorizar por importancia”, éstos pueden verse complementariamente afectados por el nivel de riesgo asociado a cada uno de ellos. De esta manera, se debe realizar una construcción iterativa y evolutiva de Scrum para mitigar riesgos en forma implícita: construyendo primero aquellas características con mayor riesgo asociado y dejando las que poseen menor riesgo para etapas posteriores. Se recomienda que los Product Backlog Ítems (PBIs) de baja importancia y alto riesgo sean evitados, por ejemplo, transfiriéndolos o eliminándolos del alcance. Un Backlog Eficiente es cuando se obtiene el mayor beneficio con el menor esfuerzo posible. Este concepto llevado al Product Backlog significa invertir el esfuerzo de exploración y especificación de la manera más inteligente posible para evitar re-trabajos y desperdicios. Por esto, se debe fomentar un Product Backlog donde sus ítems más prioritarios están expresados con un nivel de detalle mucho mayor que los ítems de menor prioridad, los cuales están descritos a un nivel más alto, ya que son los más susceptibles de ser alterados o reemplazados. 16.

(17) 5.2.2 Sprint Backlog: Es el conjunto de Product Backlog Ítems (PBIs) que fueron seleccionados para trabajar en ellos durante un cierto Sprint, conjuntamente con las tareas que el equipo de desarrollo ha identificado que debe realizar para poder crear un incremento funcional potencialmente entregable al finalizar el Sprint. El resultado de cada Sprint debe ser un incremento funcional potencialmente entregable. Incremento funcional porque es una característica funcional nueva (o modificada) de un producto que está siendo construido de manera evolutiva. El producto crece con cada Sprint. Potencialmente entregable porque cada una de estas características se encuentra lo suficientemente validada y verificada como para poder ser desplegada en producción (o entregada a usuarios finales) si así el negocio lo permite o el cliente lo desea.8 5.2.3 Sprint (Iteración) Las iteraciones en Scrum se conocen como Sprints. Scrum, como todos los enfoques ágiles, es un proceso de desarrollo incremental e iterativo. Esto significa que el producto se construye en incrementos funcionales entregados en periodos cortos para obtener feedback frecuente. En general, Scrum tiene una duración de Sprint de entre 1 y 2 semanas y el objetivo será mantener esta duración constante a lo largo del desarrollo del producto, lo que implicará que la duración de una iteración no cambie una vez que sea establecida. Como excepción se pueden presentar aquellas situaciones donde el equipo mismo decida probar con iteraciones más largas o más cortas, pero siempre entre 1 y 2 semanas. Esta decisión se basa principalmente en la volatilidad del contexto: mientras más volátil sea (negocio cambiante, requerimientos desconocidos, etc.) más corta será la duración del Sprint. Lo importante es recordar que se logra mayor ritmo y previsibilidad teniendo Sprints de duración constante. Se encontrarán situaciones en donde el equipo de desarrollo se atrase o se adelante. En estos casos, la regla del timeboxing no nos permitirá modificar (adelantar o postergar) la fecha de entrega o finalización del Sprint. La variable de ajuste en estos casos será el alcance del Sprint, esto es, en el caso de adelantarse se deberá incrementar el alcance del Sprint agregando nuevos Product Backlog Ítems (PBIs) y reducirlo en el caso de retraso. 9. 8 9. Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016. 17.

(18) 5.2.4 Sprint Planning Meeting (Planificación de Sprint) Al comienzo de cada Sprint se realiza una reunión de planificación del Sprint donde serán generados los acuerdos y compromisos entre el equipo de desarrollo y el Product Owner sobre el alcance del Sprint. Esta reunión de planificación habitualmente se divide en dos partes con finalidades diferentes: una primera parte estratégica y enfocada en el “qué”, y una segunda parte táctica cuyo hilo conductor principal es el “cómo”. Parte uno: ¿Qué trabajo será realizado? El objetivo buscado durante esta parte de la reunión es identificar “qué” es lo que el equipo de desarrollo va a realizar durante el Sprint, es decir, todos aquellos Product Backlog Items (PBIs) que el equipo se comprometerá a transformar en un producto funcionando y utilizable o en otras palabras: incremento funcional potencialmente entregable. El Product Owner y el equipo de desarrollo deben participar de esta parte de la reunión como protagonistas principales. El Scrum Master, al tiempo que facilita la reunión, también debe asegurar que cualquier stakeholders del proyecto que sea requerido para profundizar en detalles esté presente o sea contactado. El equipo de desarrollo utiliza su capacidad productiva (también conocida como Velocidad o Velocity), obtenida de los Sprints pasados, para conocer hasta cuánto trabajo podría comprometerse a realizar. Esto determinaría en un principio cuáles serían los Product Backlog Items (PBIs) comprometidos en este Sprint. La razón es que cada uno de los ítems del Product Backlog debe ser discutido para entender cuáles son sus criterios de aceptación y así conocer en detalle qué se esperará de cada uno. De esta manera, el equipo de desarrollo discutirá con el Product Owner sobre cada Product Backlog Items (PBIs) y generará un compromiso de entrega para aquellos que considera suficientemente claros como para comenzar a trabajar y que además podrían formar parte del alcance del Sprint que está comenzando. A esto se lo conoce como planificación basada en compromisos o Commitmentbased Planning. Al finalizar esta primera parte de la reunión, los stakeholders involucrados (si los hubiese) se retirarán, dejando así al producto Owner, al Scrum Master y al equipo de desarrollo para que den comienzo a la segunda parte de esta reunión, que se describe a continuación. Parte dos: ¿Cómo será realizado el trabajo? Durante este espacio de tiempo el equipo de desarrollo determinará la forma en la que llevará adelante el trabajo. Esto implica la definición inicial de un diseño de alto nivel, el cual será refinado durante el Sprint mismo y la identificación de las actividades que el equipo en su conjunto tendrá que llevar a cabo. 18.

(19) Se espera que el diseño sea emergente, es decir, que surja de la necesidad del equipo de desarrollo a medida que éste avance en el conocimiento del negocio. Por esta misma razón es que indicamos la no necesidad de realizar un diseño completo y acabado de lo que será realizado durante el Sprint. En cambio, se buscará un acuerdo de alto nivel que será bajado a detalle durante la ejecución de la iteración. Esto mismo sucede con las actividades del Sprint, es decir que no es estrictamente necesario enumerar por completo todas las actividades que serán realizadas durante la iteración ya que muchas aparecerán a medida que se avanza. Adicionalmente, las actividades deben durar un día. Esto permitirá detectar bloqueos o retrasos durante las reuniones diarias. Al finalizar esta reunión, el equipo habrá arribado a un Sprint Backlog o Commited Backlog que representa el alcance del Sprint en cuestión. Este Sprint Backlog es el que se coloca en el taskboard (pizarra de actividades) del equipo. Se dará comienzo al desarrollo del producto para este Sprint. 10 5.2.5 Scrum Diario Uno de los beneficios de Scrum está dado por el incremento de la comunicación dentro del equipo de proyecto. Esto facilita la coordinación de acciones entre los miembros del equipo de desarrollo y el conocimiento “en vivo” de las dependencias de las actividades que realizan. Por otro lado, se requiere además aumentar y explicitar los compromisos asumidos entre los miembros del equipo de Proyectos Ágiles con Scrum desarrollo y dar visibilidad a los impedimentos que surjan del trabajo que está siendo realizando y que muchas veces nos impiden lograr los objetivos. Estos tres objetivos: 1) incrementar la comunicación 2) explicitar los compromisos y 3) dar visibilidad a los impedimentos, son logrados mediante las reuniones diarias de Scrum (Daily Scrums). Estas reuniones tienen, como su nombre lo indica, una frecuencia diaria y no deberían llevar más de 10 minutos. Estos 10 minutos son un timebox, es decir, que no se pueden superar. A la reunión diaria acude el ScrumMaster y el equipo de trabajo. En el caso de que sea necesario, se podrá requerir la presencia del Product Owner y de los stakeholders. De todas maneras, se intenta que sea una reunión abierta donde cualquier interesado en escuchar lo que sucede pueda participar en calidad de observador. Se recomienda que los observadores no participen activamente en la reunión, y mucho menos, que soliciten a los miembros del equipo justificación del progreso y explicación de los problemas. 10. Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016. 19.

(20) Esta reunión es facilitada por el Scrum Master. Todos y cada uno de los miembros toman turnos para responder las siguientes tres preguntas, y de esa manera comunicarse entre ellos: 1. ¿Qué hice desde la última reunión diaria hasta ahora? 2. ¿En qué voy a estar trabajando desde ahora hasta la próxima reunión diaria? 3. ¿Qué problemas o impedimentos tengo? Es importante destacar que en ningún momento se trata de una reunión de reporte de avance o status al Scrum Master ni a otras personas. Por el contrario, es un espacio de estricta comunicación entre los miembros del equipo de desarrollo. El objetivo de la primera pregunta (¿qué hice?) es verificar el cumplimiento de los compromisos contraídos por los miembros del equipo en función del cumplimiento del objetivo del Sprint. La finalidad de la segunda pregunta (¿qué voy a hacer?) es generar nuevos compromisos hacia el futuro. Cuando hablamos de compromisos, hacemos referencia a aquéllos que los miembros del equipo asumen ante sus compañeros. La última pregunta (¿qué problemas?) apunta a detectar y dar visibilidad a los impedimentos. Estos impedimentos no se resuelven en esta reunión, sino en posteriores. Es responsabilidad del ScrumMaster que se resuelvan lo antes posible, generando las reuniones que sean necesarias e involucrando a las personas correctas. En el caso de que los Product Backlog Items (PBIs) del Sprint se hubiesen podido dividir en actividades de menos de un día: si una de estas actividades se encuentra en progreso durante dos reuniones diarias seguidas (con 24hs de separación) claramente se advierte un retraso. 5.2.6 Revisión de Sprint Al finalizar cada Sprint se realiza una reunión de revisión del Sprint (Sprint Review), donde se evalúa el incremento funcional potencialmente entregable construido por el equipo de desarrollo (el “qué”). En esta reunión el Equipo Scrum y los Stakeholders revisan el resultado del Sprint. Cuando decimos “resultado” hablamos de “producto utilizable” y “potencialmente entregable” que el los interesados utilizan y evalúan durante esta misma reunión, aceptando o rechazando así las funcionalidades construidas. Los Stakeholders evalúan el producto construido y proveen feedback. Este feedback puede ser acerca de cambios en la funcionalidad construida o bien nuevas funcionalidades que surjan al ver el producto en acción.. 20.

(21) Toda la retroalimentación que los stakeholders aporten debe ser ingresada como PBIs en el Product Backlog. Para esto, los PBIs nuevos deben ser priorizados con respecto a todos los ya existentes en el Product Backlog. También es necesario que estos nuevos PBIs sean estimados antes de incluirlos como parte del Product Backlog ya que el Product Owner deberá decidir cuáles de los PBIs existentes cuya estimación de costo es similar a la de los nuevos PBIs deben ser eliminados para no incurrir en el incremento desmedido del alcance (Scope Creeping): si se agrega trabajo entonces debemos quitar trabajo de otro lado. El Product Owner cuenta para esto con la priorización de los ítems del Backlog como herramienta para la toma de este tipo de decisiones. En el caso de que una funcionalidad sea rechazada, el PBI correspondiente reingresa al Product Backlog con máxima prioridad, para ser tratado en el siguiente Sprint. La única excepción a esta regla es que el Product Owner, por decisión propia, prefiera dar mayor prioridad a otros. En este caso, nada debe salir del Backlog ya que esto no sería considerado como un incremento en el alcance. Al finalizar la revisión del producto, es recomendable definir la fecha de la próxima reunión de revisión, que corresponderá al final del Sprint siguiente. De este modo ya se tendrán las agendas bloqueadas a tal fin.11 5.2.7 Feedback En una metodología como Scrum, la retrospección del equipo es el corazón de la mejora continua y las prácticas emergentes. Mediante el mecanismo de retrospección, el equipo reflexiona sobre la forma en la que realizó su trabajo y los acontecimientos que sucedieron en el Sprint que acaba de concluir para mejorar sus prácticas. Todo esto sucede durante la reunión de feedback. Esta reunión tiene lugar inmediatamente después de la reunión de revisión. Mientras que la reunión de revisión se destina a revisar el producto (el “qué”), la feedback se centra en el proceso (el “cómo”). Este tipo de actividad necesita un ambiente seguro donde el Equipo Scrum pueda expresarse libremente, sin censura ni temores, por lo cual se restringe solo al Equipo de Desarrollo, al ScrumMaster y el Product Owner. En el caso de que se requiera la participación de stakeholders o gerentes, estos podrán ser convocados. Valiéndose de técnicas de facilitación y análisis de causas raíces, se buscan tanto fortalezas como oportunidades de mejora. Luego, el Equipo Scrum decide por consenso cuáles serán las acciones de mejora a llevar a cabo en el. 11. Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016. 21.

(22) siguiente Sprint. Estas acciones y sus impactos se revisarán en la próxima reunión de feedback.12 5.2.8 Release El release se compone de dos procesos . . Envío de entregables: los Accepted Deliverables se les entregan a los Socios relevantes. Un acuerdo formal llamado Working Deliverables Agreement documenta la finalización con éxito del Sprint. Feedback del proyecto: En este proceso, que completa el proyecto, los socios y miembros principales del Equipo Principal de Scrum se reúnen para hacer una feedback del proyecto e identificar, documentar e internalizar las lecciones aprendidas. A menudo, estas lecciones llevan a la documentación de Agreed Actionable Improvement, que se aplicará en futuros proyectos.13. 5.2.9 Identificación de Funcionalidades del Software Para realizar la identificación de las funcionalidades se deberá tener en cuenta todos los roles identificados, efectuando sucesivas “pasadas” por todos los procesos de negocio y evaluando que cada uno de los roles involucrados en ellos cuenten con las funcionalidades requeridas para la realización de sus objetivos. Al igual que la identificación de roles, esta actividad se realiza en forma colaborativa junto al Product Owner y la mayor cantidad de miembros del equipo posible.14 5.3 La nómina La nómina es el sistema contable de la empresa, utilizada para mantener un registro con el salario, cargo, deducciones, así como otras novedades y rendimientos que genera cada uno de sus empleados. La nómina es el documento que se entrega mensualmente a todos los trabajadores en el que aparece el detalle del salario que recibe, junto con las deducciones que se le practican a dicho salario, bien sea por descuentos obligatorios marcados por la legislación vigente, por otro tipo de descuentos como anticipos, o deducciones para seguros de salud. El formato estándar de una nómina está regulado por la legislación vigente y se marca una estructura y contenido básico que se debe respetar en todo caso. El contenido mínimo de la nómina debe incluir al menos: . 12 13 14. Datos identificativos de la empresa, dirección del centro de trabajo y código cuenta cotización en el que está el trabajador incluido. Metodología SCRUM/OAS, Oficina Asesora de Sistemas,2016. 22.

(23)    . .  . Datos básicos del trabajador, tipo de contrato, categoría, antigüedad en la empresa. Periodo de liquidación al que corresponde dicha nómina. Detalle de las percepciones salariales y extra saláriales que componen la retribución bruta del trabajador. Detalle de las deducciones que se le practican al salario bruto, bien marcadas por la legislación vigente, por otro tipo de deducciones que haya que aplicarle a la nómina, como anticipos o embargos de nómina. Líquido a percibir, dado que la nómina tiene consideración de documento acreditado del pago de salarios cerrando los pagos pendientes al trabajador para el periodo estipulado. Detalle de las bases de cotización de la nómina. Lugar de emisión, firma y sello por la empresa y el trabajador.. Hay que remarcar que aunque estos elementos sean básicos, existen algunas excepciones como el caso de la firma del trabajador. No es necesaria dicha firma si el pago de la nómina se ha realizado por medios bancarios que puedan demostrar la percepción salarial por parte del trabajador. 5.3.1 Retribución bruta La suma total de todos los conceptos que hay que abonar al trabajador dan origen a la retribución bruta mensual. La nómina tiene por norma general periodos de liquidación mensuales con las siguientes excepciones:  . Entrada o salida del trabajador de la empresa, sin que estas fechas correspondan con el mes natural. Nóminas de paga extra.. Dentro de las percepciones que se suman para dar lugar al salario bruto tenemos dos grupos diferenciados: Percepciones salariales: que lo conforman todos aquellos conceptos que están fijados por el convenio colectivo de ampliación en la empresa. Percepciones extra salariales: en el que se incluyen conceptos que no tienen la consideración pura de salario, como pueden ser dietas, gastos de locomoción o pluses por retribuciones en especio como el plus por desgaste de herramientas. 5.3.2 Descuentos en la nómina En la nómina podemos encontrar dos tipos de descuento diferentes, bien sean los descuentos obligatorios por ley o también los descuentos que se deban aplicar por cualquier otro tipo de normativas.. 23.

(24) En el caso de los descuentos por ley, tenemos dos grupos de deducciones diferentes, que se destinan al pago de la seguridad social a cargo del trabajador, como los pagos a cuenta que el propio trabajador tiene que realizar por impuestos u otros conceptos. La liquidación de nómina, los descuentos y los diferentes factores que se tienen en cuenta dependen directamente del tipo de vinculación que tenga la persona natural o jurídica con el empleador, el particular en la Universidad Distrital es la existencia de varios tipos de vinculación y de categorías, en el caso de pensionados existen los de tipo oficial, administrativo y docente. 5.3.3 Liquidación de mesada pensional 5.3.3.1 Pensionado El concepto que permite nombrar a una persona cuanto esta jubilada: ya no se encuentra física o mentalmente capacitada para continuar realizando el trabajo que hasta entonces hacía.14 5.3.3.2 Pensión de jubilación Es el reconocimiento a los funcionarios administrativos al cumplir la edad y el tiempo de servicio requerido para tal fin, estipulados en la ley, convenciones colectivas, laudos arbitrales y demás. Articulo 10 Convención Colectiva de Trabajo suscrita para 1992 y 1993 PJ=SB+GR+ST+PAL+PT+PAN (HE+RN+PS+PV+V+PN+Q+VI)/12X%* Dónde: SB= Salario Básico GR= Gastos de Representación ST= Subsidio de transporte PAL= Prima de Alimentación PT= Prima Técnica PAN= Prima de Antigüedad PV= Prima de Vacaciones V= Vacaciones PN= Prima de Navidad 14. Marco normativo y procedimental Nomina Funcionarios y Pensionados UD. OAS. OFICINA ASESORA DE SISTEMAS, (OAS).. 24.

(25) Q= Quinquenio HE= Horas Extras RN= Recargos Nocturnos PS= Prima de Servicios VI= Vacaciones individuales PJ= corresponde a la sumatoria de los valores devengados en cada factor, en los últimos doce meses anteriores a la fecha de retiro, dividido por doce y el resultado será el valor del factor con que se liquidará. Para el caso de las Horas Extras, recargos nocturnos y prima de servicios corresponde a los recibidos los doce meses anteriores a la fecha de retiro. Para las Vacaciones Individuales, este corresponde a los recibidos en los doce meses anteriores a la fecha de retiro, siempre y cuando haya sido por ciento ochenta (180) días o más dentro de este período. PORCENTAJE, corresponde al porcentaje de salario de acuerdo con la siguiente tabla: TIEMPO UNIVERSIDAD. TIEMPO OTRAS. 20 años. EDAD. PORCENTAJE. Cualquiera. 100. 19 años. 1 año privado. Cualquiera. 96. 18 años. 2 años privado. Cualquiera. 92. 17 años. 3 años privado. Cualquiera. 88. 16 años. 4 años privado. Cualquiera. 84. 15 años. 5 años privado. Cualquiera. 80. 10 años. 10 años estado. Cualquiera. 70. Tabla 1. Porcentaje de salario Convención Colectiva de Trabajo. Más 0,3333 por mes después de los 15 años de servicio a la Universidad. En caso de despido sin justa causa a un trabajador que tenga 15 o más años de servicio continuo o discontinuo, de tiempo completo, la Universidad lo pensionará desde la fecha de su despido así:. 25.

(26) TIEMPO UNIVERSIDAD. PORCENTAJE. 20 años. 100. 19 años. 96. 18 años. 92. 17 años. 88. 16 años. 84. 15 años. 80 Tabla 2. Porcentaje de liquidación según tiempo en la universidad.. Las tablas anteriores son basadas en derechos convencionales que poseen los funcionarios Administrativos de la Universidad, lo cual no excluye que en casos particulares se apliquen los porcentajes y requisitos que fija la Ley. 15 5.3.3.3 Pensión de invalidez Es una prestación social a que tienen derecho los funcionarios administrativos de la Universidad que se encuentren en situación de invalidez transitoria o permanente. Se considera inválido el empleado oficial que ha perdido su capacidad para continuar ocupándose en la labor que constituye su actividad habitual o la profesión a que se ha dedicado ordinariamente, en un porcentaje igual o superior al 75% (Artículo 65 del Decreto 1848 de 1969) y sin tener en cuenta el tiempo de servicio. Liquidación: Para liquidar la pensión de invalidez se procederá así: PI = (SB+GR+ST+PAL+PT+PAN (HE+RN+PS+PV+V+PN+Q+VI)/12) X % * SB= Salario Básico GR= Gastos de Representación ST= Subsidio de Transporte PAL= Prima de Alimentación PT= Prima Técnica 15. Marco normativo y procedimental Nomina Funcionarios y Pensionados UD. OAS. OFICINA ASESORA DE SISTEMAS, (OAS).. 26.

(27) PAN= Prima de Antigüedad HE= Horas extras RN= Recargos nocturnos PS= Prima de Servicios PV= Prima de Vacaciones V= Vacaciones PN= Prima de Navidad Q= Quinquenio VI= Vacaciones Individuales * PI= corresponde a la sumatoria de los valores devengados en cada factor, en los últimos doce meses anteriores a la fecha de culminación de los ciento ochenta (180) días de incapacidad, se dividirá por doce y el resultado será el valor del factor con que se liquidará. Para las Horas Extras y Recargos Nocturnos, estos valores corresponden a los recibidos los doce meses anteriores a la fecha de culminación de los ciento ochenta (180) días de incapacidad, siempre y cuando haya sido por ciento ochenta (180) días o más dentro de este período. En el caso de las Vacaciones Individuales, corresponde a los recibidos en los doce meses anteriores a la fecha de culminación de los ciento ochenta días de incapacidad, siempre y cuando haya sido por ciento ochenta (180) días o más dentro de este período. % PORCENTAJE, corresponde al porcentaje de salario de acuerdo con la siguiente tabla: PORCENTAJE DE DISMINUCION. PORCENTAJE. Más del 95%. 100. Más de 75% y menos del 95%. 75. Igual 75%. 50. Tabla 3. Porcentaje de pensión por invalidez según porcentaje de disminución.. PS = Corresponde a la última devengada en los doce (12) meses anteriores a la fecha de culminación de los ciento ochenta (180) días de incapacidad.. 27.

(28) PV = Corresponde a la última devengada en los doce (12) meses anteriores a la fecha de culminación de los ciento ochenta (180) días de incapacidad. V =Corresponde a la última devengada en los doce (12) meses anteriores a la fecha de culminación de los ciento ochenta (180) días de incapacidad. PN = Corresponde a la última devengada en los doce (12) meses anteriores a la fecha de culminación de los ciento ochenta (180) días de incapacidad. Q = Corresponde al último devengado en los doce (12) meses anteriores a la fecha de culminación de los ciento ochenta (180) días de incapacidad.16 5.3.3.4 Mesada Pensional Definición Reconocimiento y pago de la pensión de jubilación. De acuerdo al monto de la liquidación de la pensión de jubilación o pensión de invalidez otorgada mediante acto administrativo, se realizan los pagos correspondientes. El registro correspondiente al valor como tal, está generado desde una tabla que contiene la información correspondiente. Liquidación La liquidación de los días está determinada desde la fecha del acto administrativo de reconocimiento. Mesada Pensional = Pensión * 30 Tipo de Pensionados PA: Pensionado Administrativo PD: Pensionado Docente PO: Pensionado Oficial Ajuste Mesada Pensional: de conformidad con los actos administrativos que ordenen los ajustes correspondientes a las mesadas pensionales, se incluirá en el mes de reconocimiento los días a que haya lugar para terminar el mes y posteriormente dicho valor ya serán incluidos en el pago mensual del mes siguiente. Ajuste = Pensión /30 * No. Días. 16. Marco normativo y procedimental Nomina Funcionarios y Pensionados UD. OAS. OFICINA ASESORA DE SISTEMAS, (OAS).. 28.

(29) 5.3.3.5 Subsidio de libros Definición De conformidad con la Convención Colectiva los pensionados tienen derecho a un subsidio de libros de acuerdo a: Art. 14 CCT 1990…. “A partir del primero de enero de 1990, la Universidad Distrital reconoce y paga el auxilio educativo a todos los trabajadores activos y pensionados e hijos de estos que cursen estudios así: a) Guardería, preescolar, primaria, secundaria y validación del bachillerato, una suma equivalente a 1.0 salario mínimo convencional vigente anualmente b) Técnicos, tecnológicos, carreras intermedias, universitarias, cursos de especialización, de postgrados, magíster, una suma equivalente a 1.0 salario mínimo convencional vigente semestralmente……” Liquidación Está determinada por el salarios mínimos * El concepto respectivo está incluido como una novedad 999, de acuerdo a la certificación o documento soporte que acredita dicho derecho. PA= Valor subsidio x No. de beneficiarios 5.3.3.6 Subsidio familiar Definición Convención Colectiva de 1992, Artículo 2, “....Parágrafo 2. Los pensionados de la Universidad Distrital que hayan logrado su estatus pensional conforme al régimen convencional, que reciban mesadas inferiores a cinco salarios mínimos convencionales vigentes recibirán el subsidio familiar en los términos en los que se les reconoce a los trabajadores activos” Este subsidio se encuentra parametrizado para: 1. Padre 2. Madre 3. Hijo Liquidación Para la presente vigencia están determinados dos (2) montos diferentes así: PA= Valor subsidio x No. de beneficiarios 29.

(30) Valor subsidio = $65.900 * PO= Valor subsidio x No. de beneficiarios Valor Subsidio = (SMLC / 30) * 2.55 * 1.752.652/30*2.55= 148.975 5.3.3.7 Incremento cotización salud De conformidad con lo establecido en: Ley 100 de 1993, “....ARTICULO 143. Reajuste pensional para los actuales pensionados. A quienes con anterioridad al 1o. de enero de 1994 se les hubiere reconocido la pensión de vejez o jubilación, invalidez o muerte, tendrán derecho, a partir de dicha fecha, a un reajuste mensual equivalente a la elevación en la cotización para salud que resulte de la aplicación de la presente Ley. La cotización para salud establecida en el Sistema General de Salud para los pensionados está, en su totalidad, a cargo de éstos, quienes podrán cancelarla mediante una cotización complementaría durante su período de vinculación laboral. El Consejo Nacional de Seguridad Social en Salud podrá reducir el monto de la cotización de los pensionados en proporción al menor número de beneficiarios y para pensiones cuyo monto no exceda de tres (3) salarios mínimos legales PARAGRAFO TRANSITORIO. Sólo por el año de 1993, los gastos de salud de los actuales pensionados del ISS se atenderá con cargo al Seguro de IVM y hasta el monto de la cuota patronal.” Decreto 692 de 1994…….. “Artículo 42. Reajuste pensional por incremento de aportes en salud. A quienes con anterioridad al 1° de enero de 1994 se les hubiere reconocido la pensión de vejez o jubilación, invalidez, o sobrevivientes, y a quienes sin haberles efectuado el reconocimiento tuvieran causada la correspondiente pensión con los requisitos formales completos, tendrán derecho a partir de dicha fecha a que con la mesada mensual se incluya un reajuste equivalente a la elevación en la cotización para salud prevista en la Ley 100 de 1993. En consecuencia, las entidades pagadoras de pensiones procederán a efectuar el reajuste previsto en este artículo por la diferencia entre la cotización que venían efectuando los pensionados y la nueva cotización del 8% que rige a partir de abril de 1993, o la que se determine cuando rija la cobertura familiar, sin exceder del 12%. En el caso del ISS, en donde ya existe 30.

(31) la modalidad de medicina familiar para los pensionados, el reajuste se hará por la diferencia entre el 3.96% que venían aportando los pensionados, y el 12% de la cotización con cobertura familiar. Las entidades pagadoras deberán descontar la cotización para salud, y transferirlo a la EPS o entidad a la cual esté afiliado el pensionado en salud. Igualmente deberán girar un punto porcentual de la cotización al fondo de solidaridad y garantía en salud”. Se concluye que aquellos funcionarios que se pensionaron antes del 1° de enero de 1994, el descuento para salud era del 5% y la diferencia entre ese porcentaje y el 12% lo debía asumir la correspondiente entidad que pagaba la mesada pensional. Teniendo en cuenta lo anterior, la Universidad Distrital mensualmente hace dicho reintegro por novedad, de acuerdo a la norma, asumiendo en caso particular el 7%.17 5.3.4 Sustitutos La pensión sobrevivientes es la prestación que se reconoce a los beneficiarios cuando fallece el pensionado o afiliado. Información respecto de los requerimientos que debe cumplir el conyugue o compañero permanente conyugue y/o compañero permanente . Beneficiario vitalicio: es el conyugue y/o compañero(a) permanente que a la fecha del fallecimiento del causante, tenga 30 años o más de edad.. . Beneficiario temporal: es el cónyuge o el compañero(a) permanente, siempre y cuando dicho beneficiario, a la fecha del fallecimiento del causante, tenga menos de 30 años de edad, y no haya procreado hijos con este. Si tiene hijos con el causante aplicará el párrafo anterior.. Información respecto de los requerimientos que debe cumplir los hijos beneficiarios de pensión sobreviviente. . Son los hijos mayores de 18 años hasta los 25 años, incapacitados para trabajar por razón de sus estudios y si dependían económicamente del causante al momento de su muerte, siempre y cuando acrediten debidamente su condición de estudiantes”.. 17. Marco normativo y procedimental Nomina Funcionarios y Pensionados UD. OAS. OFICINA ASESORA DE SISTEMAS, (OAS).. 31.

(32) . Los hijos inválidos si dependían económicamente del causante, esto es, que no tienen ingresos adicionales, mientras subsistan las condiciones de invalidez (artículo 38 de la Ley 100 de 1993).. Información respecto de los requerimientos que debe cumplir los padres beneficiarios de pensión sobreviviente. . A falta de cónyuge, compañero o compañera permanente e hijos con derecho, serán beneficiarios los padres del causante si dependían económicamente de forma total y absoluta de este, al momento del fallecimiento del causante.. Información respecto de los requerimientos que debe cumplir los hermanos beneficiarios de pensión sobreviviente en condición de invalidez. . A falta de cónyuge, compañero o compañera permanente, padres e hijos con derecho, serán beneficiarios los hermanos inválidos del causante si dependían económicamente de éste, al momento del fallecimiento del causante.. 5.4 REST API REST es el acrónimo para Transferencia de Estado Representacional (por sus siglas en inglés REpresentational State Transfer), es un estilo arquitectural para sistemas de hipermedia distribuidos, fue presentado por primera vez por Roy Fielding en el año 2000, en su famosa monografía. REST es un estilo híbrido derivado de muchos de los estilos arquitecturales basados en red y combinados con limitaciones adicionales que definen una interfaz de conexión uniforme.18 En realidad, REST se refiere estrictamente a una colección de principios para el diseño de arquitecturas en red. Estos principios resumen como los recursos son definidos y diseccionados. El término frecuentemente es utilizado en el sentido de describir a cualquier interfaz que transmite datos específicos de un domino sobre HTTP sin una capa adicional, como hace SOAP. Estos dos significados pueden chocar o incluso solaparse. Es posible diseñar un sistema software de gran tamaño de acuerdo con la arquitectura propuesta por Fielding sin utilizar HTTP o sin interactuar con la Web. Así como también es posible diseñar una simple interfaz XML+HTTP que no sigue los principios REST, y en cambio seguir un modelo RPC. Cabe destacar que REST no es un estándar, ya que es tan solo un estilo de arquitectura. Aunque REST no es un estándar, está basado en estándares: 18. Architectural Styles and the Design of Network-based Software Architectures, Roy Thomas Fielding.. 32.

(33) • HTTP • URL • Representación de los recursos: XML/HTML/GIF/JPEG/… • Tipos MIME: text/xml, text/html.19 Una REST API no debe depender de ningún protocolo de comunicación único, aunque el éxito de su mapeo para un protocolo dado puede depender de la disponibilidad de los metadatos, la elección de métodos, etc. En general, cualquier elemento de protocolo que utiliza un URI (Uniform Resource Identifiers, en español Identificadores Uniformes de Recursos) para su identificación deberá permitir cualquier esquema URI para ser utilizado por el bien de la identificación. Un REST API debe enfocar la mayor parte de su esfuerzo en la definición descriptiva del tipo(s) de lo medio de comunicación utilizados para la representación de los recursos y la conducción estado de la aplicación, o en la definición de los nombres de relaciones extendidas y / o hipertexto habilitado de margen para tipos de papel estándar existente. Cualquier esfuerzo que describe los métodos a utilizar en el URI de interés debe definirse por completo dentro del ámbito de aplicación de las normas de tratamiento para un tipo de medio (y, en la mayoría de los casos, ya definidos por los tipos de medios existentes).20 Una de las características clave de un servicio web REST es el uso explícito de los métodos HTTP de una manera que sigue el protocolo tal como se define en el RFC 2616. HTTP GET, por ejemplo, se define como un método de producción de datos que está destinado a ser utilizado por una aplicación cliente para recuperar un recurso, para obtener los datos desde un servidor web, o para ejecutar una consulta con la expectativa de que el servidor web buscará y responder con un conjunto de recursos. REST pide a los desarrolladores utilizar métodos HTTP de forma explícita y de una manera que es consistente con la definición del protocolo. Este principio básico de diseño REST establece una correspondencia uno-a-uno entre crear, leer, actualizar y eliminar (CRUD) las operaciones y métodos HTTP. De acuerdo con este mapeo:. 19 20. . Para crear un recurso en el servidor, utilice la POST.. . Para recuperar un recurso, utilice GET.. REST vs Web Services, Rafael Navarro Marset http//:roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven, Roy Thomas Fielding. 33.

(34) . Para cambiar el estado de un recurso o para actualizarlo, utilizar PUT.. . Para eliminar o borrar un recurso, utilice DELETE.21. 5.5 Beego Beego es un framework HTTṔ para desarrollo rápido de aplicaciones en GO. Puede utilizarse para desarrollar de manera ágil APIs, aplicaciones web y servicios back-end. Es un framework RESTful y tiene integrado a él características específicas de Go tales como interfaces y estructuras embebidas. En la siguiente imagen se explica la arquitectura de Beego, que consta de 8 módulos independientes que están libremente acoplados, esto debido a que está diseñado para programación modular. Por esto, se pueden utilizar cualquiera de estos módulos sin trabajar bajo la lógica HTTP de Beego y dentro de otras aplicaciones como por ejemplo juegos de sockets. Esta fue una de las razones por las que Beego se volvió popular, dado que estos módulos son pequeños bloques de construcción que juntos forman robustos proyectos. De la misma manera, Beego posee una arquitectura típica MVC (Modelo Vista Controlador).. Figura 3. Arquitectura de Beego. Cabe resaltar que el más utilizado fue ORM, para manejo de base de datos Postgresql. Igualmente, en la siguiente imagen se puede apreciar la lógica de ejecución de Beego. En primera instancia, se escucha al puerto de la petición por medio del archivo main.go y a partir de él se realiza el enrutamiento y el 21. RESTful Web services: The basics, Rodriguez, Alex. 34.

(35) filtrado de parámetros (normalmente asociados a la ruta solicitada). Igualmente cada una de estas rutas está asociada a un controlador, que suele ser creado automáticamente por Beego y se encarga de comunicarse con los diferentes bloques que gestionan la base de datos y hacen peticiones a la misma. Una vez hecha, regresa al controlador la respuesta de la misma, en forma de JSON, disponible para ser utilizada en cualquier tecnología frontend.22. Figura 4. Lógica de ejecución Beego. 5.6 Prolog Prolog es un lenguaje de programación que fue creado en comienzos de 1970, ha sido elegido por muchos programadores de aplicaciones de computación simbólica incluyendo algunos como bases de datos relacionales, lógica matemática, soluciones de problemas matemáticas, diseño de automatización, solución de ecuaciones simbólicas, análisis de estructuras bioquímicas y muchas áreas de la inteligencia artificial. La programación de Prolog se basa en las relaciones formales, la existencia de objetos y relaciones que son necesarias para dar una solución deseada. Prolog puede ser visto como un lenguaje descriptivo y también como uno preceptivo, este lenguaje se encarga más acerca de describir como se utilizan hechos y relaciones en un problema que de describir la secuencia de pasos que toma un algoritmo para resolver un problema. Cuando un algoritmo es programado en Prolog, la forma como este realiza los cálculos es especificada particularmente por la semántica lógica declarativa de Prolog, particularmente por los nuevos hechos que Prolog puede inferir por otros especificados y también por controles específicos de información suministrados por el programador u otro sistema.23. 22 23. What is Beego?, Beego Programming in Prolog, Clocksin, William F. 35.

(36) Los más simples tipos de declaraciones en Prolog son llamados hechos, estos son el significado del estado o la relación que se mantiene entre objetos, un ejemplo es: Padre (Abraham, Isaac) Este hecho describe que Abraham es el padre de Isaac, o la relación padre entre los individuos Abraham e Isaac, otro nombre para una relación es un predicado.24 5.7 Golog Golog es una librería de uso libre que se encuentra en Github, es utilizada como intérprete para Prolog. Su funcionalidad al ser implementada permite probar reglas y hechos escritos en sintaxis similar, difiere de la de usada por Prolog. En primera medida, se crea un objeto de tipo Machine que utiliza el método Consult para probar la correcta sintaxis de las reglas. Una vez hecho esto, con ese mismo objeto se procede a probar las reglas y hechos previamente cargados. Al realizar esto, se obtienen resultados de las mismas, que son guardados a modo de arreglo dentro de Golang y puede utilizarse para los propósitos que sean necesarios. Dado que la herramienta es de uso libre, se pueden realizar modificaciones sobre las funciones, creando nuevas operaciones para ampliar el intérprete. Estas funciones son programadas en Golang, por lo que se pueden realizar diversos aportes a esta librería si se conoce el lenguaje.. 24. The Art of Prolog, Sterling, Leo. 36.

(37) CAPITULO 6. ALCANCES Y LIMITACIONES. 6.1 Alcances ● El proyecto abarca la fase de inicio, elaboración y construcción de la herramienta para la liquidación de nómina del grupo pensionados según el proceso de desarrollo SCRUM/OAS. ● El equipo de trabajo se organizará por los roles definidos en el proceso de desarrollo SCRUM/OAS. Los roles que se asumirán en la pasantía son: Analista y Desarrollador. ● La solución de software estará basada en los lineamientos del software libre dando respuesta a políticas distritales e institucionales. ● Realizar el análisis de los datos que conforman la nómina de pensionados. ● Generar, evaluar y finalizar todas las tareas para cada sprint con el objetivo de dar cumplimiento al proceso de desarrollo del proyecto de liquidación de nómina. ● Respaldar proceso anteriormente descrito con la generación de los artefactos (documentos, reglas de negocio, lista de tareas, diagramas y actas de trabajo) que la metodología del subproceso de “Gestión de Requerimientos” define, en un plazo de cuatro (4) meses frente a la gestión de nóminas en la Universidad Distrital y siguiendo los lineamientos del proceso de desarrollo de software SCRUM/OAS. ● Los artefactos y actividades relacionadas a la gestión de cambios en la gestión de análisis y requisitos que menciona el proceso SCRUM/OAS deben llevarse a cabo a lo largo del proyecto.. 6.2 Limitaciones  Cualquier actividad o proceso que no se contemple en los alcances no será tenido en cuentan a lo largo de la ejecución del proyecto.  Se realizara el proceso de gestión de datos y desarrollo de la herramienta únicamente del proceso de liquidación de nómina de pensionados.  Las actividades y avances estarán determinados únicamente por las tareas generadas durante cada Sprint.  El proyecto, como política de la Oficina Asesora de Sistemas se desarrollara en su totalidad en tecnologías OPEN SOURCE. 37.

(38) CAPITULO 7. METODOLOGIA. La metodología ágil se compone de 4 valores y 12 principios, los cuales determinan la importancia de cada integrante, las normas bajo las cuales se relacionaran los miembros del proyecto junto con sus responsabilidades y las reglas que rigen el desarrollo del mismo. 7.1 Valores ● Valorar a las personas y las interacciones entre ellas por sobre los procesos y las herramientas: Las personas son el principal factor de éxito de un proyecto de software. Es más importante construir un buen equipo que construir el contexto. Muchas veces se comete el error de construir primero el entorno de trabajo y esperar que el equipo se adapte automáticamente. Por el contrario, la agilidad propone crear el equipo y que este construya su propio entorno y procesos en base a sus necesidades. ● Valorar el software funcionando por sobre la documentación detallada: La regla a seguir es “no producir documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante”. Estos documentos deben ser cortos y centrarse en lo esencial. La documentación (diseño, especificación técnica de un sistema) no es más que un resultado intermedio y su finalidad no es dar valor en forma directa al usuario o cliente del proyecto. Medir alcance en función de resultados intermedios se convierte en una simple “ilusión de progreso”. ● Valorar la colaboración con el cliente por sobre la negociación de contratos: Se propone que exista una interacción constante entre el cliente y el equipo de desarrollo. Esta mutua colaboración, será la que dicte la marcha del proyecto y asegure su éxito. ● Valorar la respuesta a los cambios por sobre el seguimiento escrito de los planes: La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la tecnología, en el equipo, etc.) determina también su éxito o fracaso. Por lo tanto, la planificación no debe ser estricta sino flexible y abierta.. 38.