MIGRACIÓN A NUEVAS TECNOLOGÍAS DE LOS MÓDULOS DE PARAMETRIZACIÓN Y DE GESTIÓN DE INFORMACIÓN DEL SISTEMA ACTUAL PARA EL APOYO EN EL

PROCESO DE GESTIÓN DE LAS CUOTAS PARTES DE PENSIONADOS DE LA UNIVERSIDAD DISTRITAL (TEMIS) BASADO EN LOS LINEAMIENTOS DEL PROCESO DE

DESARROLLO DE LA OFICINA ASESORA DE SISTEMAS (OAS)

Proyecto de grado para optar al título de Ingeniero de Sistemas

Realizado por: Cristian Andrey Sossa Tamara

20112020134

Bajo la dirección de: Alejandro Paolo Daza Corredor

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS

Bogotá D.C, 2019

RESUMEN

El actual trabajo presenta el planteamiento del proyecto de grado para optar al título de Ingeniero de Sistemas para el estudiante Cristian Andrey Sossa Tamara de la Universidad Distrital Francisco José de Caldas.

En este documento se expone la justificación e importancia que conlleva la migración a las nuevas tecnologías que se emplean actualmente en la Oficina Asesora de Sistemas (OAS); en este ámbito, encontramos el desarrollo del sistema de gestión de cuotas partes de los pensionados dentro de la Universidad Distrital Francisco José de Caldas, el cual ha quedado con el pasar del tiempo desfasado respecto a los nuevos aplicativos desarrollados en la OAS. Se presentarán las diferencias del modelo que se encuentra aplicado actualmente, con el fin de mostrar un contraste con el nuevo desarrollo que servirá como base para realizar la migración de los demás módulos del sistema de cuotas partes y las ventajas y beneficios que se han logrado obtener con la migración de los módulos de parametrización y gestión de información a las nuevas tecnologías implementadas actualmente en la OAS, las cuales garantizan en parte generar un modelo óptimo que se ajuste a las necesidades globales en el desarrollo que presentan los demás software presentados en la OAS, permitiendo una mayor integridad en la información que se implementa.

También se presentarán algunos conceptos básicos que se han implementado en el proyecto, tal como lo es el modelo implementado en los módulos de parametrización y gestión de información actuales en el sistema de cuotas partes de la universidad, además de la descripción de la metodología propuesta para el proyecto (SCRUM - OAS) y las herramientas que se proponen para el desarrollo de la migración de las nuevas tecnologías, entre otros, los cuales permitan contextualizar y ayuden a justificar la ejecución del proyecto.

Finalmente, se exponen las herramientas de hardware y software, los recursos humanos, técnicos, tecnológicos e institucionales necesarios que han sido planteados para la visualización del presupuesto necesario, el cronograma de actividades necesarias para la ejecución del proyecto en los tiempos inicialmente determinados (4 meses).

La realización del proyecto se desarrolla, además, con el fin de generar nuevos conocimientos y habilidades para el crecimiento tanto profesional como personal, las cuales ayuden en el desarrollo de experiencias como ingeniero de sistemas.

1

TABLA DE CONTENIDO

RESUMEN 1

CAPÍTULO 1. INTRODUCCIÓN 7

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA 9

CAPÍTULO 3. OBJETIVOS 11 3.1. Objetivo general 11 3.2. Objetivos específicos 11

CAPÍTULO 4. JUSTIFICACIÓN 12

CAPÍTULO 5. MARCO TEÓRICO 13 5.1. Las cuotas partes 13

5.1.1. Normatividad 13 5.1.2. Pensión Legal Sector Público 14

5.1.2.1. Requisitos 14 5.1.2.2. Beneficios 14

5.1.3. Reajustes de las pensiones legales 14 5.1.4. De las pensiones 19 5.1.5. Normatividad vigente para el cobro de cuotas partes pensionales 22 5.1.6. Preinscripción de las cuotas partes pensionales 23 5.1.7. Conformación de la cuenta de cobro por parte de las entidades territoriales 24

5.2. Estatuto tributario 24 5.3. Conformación de las cuotas de cobro por parte de las entidades cuotapartistas 25 5.4. Compensacion 26 5.5. Ley 1066 - Cobro coactivo, reglamento interno de recuperación de cartera 26

CAPÍTULO 6. ALCANCES Y LIMITACIONES 27 6.1. Alcances 27 6.2. Limitaciones 27

CAPÍTULO 7. METODOLOGÍA 29 7.1. SCRUM 29

7.1.1. Fases del ciclo de desarrollo ágil 30 7.1.2. Componentes de SCRUM 31

7.1.2.1. Reuniones 31 7.1.2.2. Roles 32 7.1.2.3. Elementos del SCRUM 32

7.2. SCRUM OAS 32 7.2.1. Tuleap 33

2

7.2.2. Proceso de SCRUM/OAS 34

CAPÍTULO 8. RECURSOS 38 8.1. Recursos humanos 38 8.1. Recursos técnicos y tecnológicos 39 8.1.1. Recursos de Software 39 8.1.2. Recursos Institucionales 39

CAPÍTULO 9. PRESUPUESTO 40 9.1. Fuentes de financiamiento 41 9.2. Analisis costo - beneficio 41

CAPÍTULO 10. DESARROLLO 43 10.1. Modelo de negocio actual del sistema de cuotas partes 43 10.2. Software 46 10.2. Arquitectura de datos 49

10.2.1. Modelo de datos 49 10.2.1.1. Módulo paramétrico 51 10.2.1.2. Módulo de gestión de información 52 10.2.1.3. Modelo de datos externos utilizados 54

10.3. Desarrollo de la aplicación 56 10.3.1. Autenticación 62 10.3.2. Seguridad 64 10.3.3. Módulo paramétrico 66

10.3.3.1. Organización 67 10.3.3.1. IPC 67 10.3.3.1. DTF 69 10.3.3.1. Salario mínimo legal 71

10.3.4. Módulo de gestión de información 72 10.3.4.1. Pensionados 72 10.3.4.2. Experiencia Laboral 73 10.3.4.3. Monto aceptado 75 10.3.4.4. Cobro registrado 78

10.4. Pruebas 80

11. Conclusiones 86

12. Trabajos futuros 87

CAPÍTULO 13. BIBLIOGRAFÍA 88

3

ÍNDICE DE FIGURAS

Figura 1. Ciclo de desarrollo ágil. Imagen tomada de [5] pág. 34 Figura 2. Flujo de un proyecto desarrollado bajo la metodología SCRUM. Metodología SCRUM/OAS, Oficina Asesora de Sistemas, 2016. Figura 3. Lógica de ejecución del framework REST API Beego. Figura 4. Cronograma de actividades. Figura 5. Diagrama de Gantt con las actividades propuestas. Figura 6. Estructura del sistema de cuotas partes del módulo de gestión de información y parametrización. Figura 7. Modelo de datos inicial. Figura 8. Modelo de tres capas C/S del sistema de cuotas partes planteado. Figura 9. Modelo de datos en módulos paramétricos y de gestión de datos. Figura 10. Diagrama de componentes para el sistema de gestión de cuotas partes TEMIS de la Universidad Distrital. Figura 11. WSO2 API Store. Figura 12. Schema monto_aceptado que gestiona el servicio temis_monto_aceptado_crud Figura 13. Modelos del servicio temis_monto_aceptado_crud. Figura 14. Configuración básica del temis_cliente dentro del app.conf.js. Figura 15. Parámetros enviados para la autenticación por el servicio oauth2 WSO2. Figura 16. Cabecera de la petición al servicio de autenticación. Figura 17. LocalStorage generado según los datos otorgados por el servicio de autenticación. Figura 18. JWT token decodificado con la información del usuario. Figura 19. Configuración de los permisos dentro del componente NbSecuriy de Nebular. Figura 20. Resultado obtenido de la vista de organizaciones. Figura 21. Resultado obtenido de la vista de índice de precio de consumo (IPC). Figura 22. Resultado obtenido para el formulario de registro de IPC. Figura 23. Resultado de la vista de listado de registros de tasa de interés (DTF). Figura 24. Resultado obtenido para el formulario de registro de DTF. Figura 25. Resultado obtenido de la vista de listado de salario mínimo legal (SML). Figura 26. Resultado obtenido para la vista del formulario de registro de SML. Figura 27. Resultado obtenido para la vista del listado de pensionados. Figura 28. Resultado obtenido para la vista del listado de experiencia laboral asociada a un pensionado. Figura 29. Resultado obtenido para la vista del formulario de experiencia laboral asociada al pensionado. Figura 30. Resultado obtenido para la vista del listado de monto aceptado por concepto de la cuota parte asociada a la experiencia laboral de un pensionado. Figura 31. Resultado para la vista del formulario del registro de un monto aceptado. Figura 32. Diagrama de secuencia para el registro de un nuevo monto aceptado. Figura 33. Resultado obtenido para la vista del listado de cobros registrados según el monto aceptado. Figura 34. Diagrama de secuencia para el registro de un nuevo cobro registrado en el sistema.

4

Figura 35. Instalación y ejecución en consola del docker de sonarqube. Figura 36. Resultado obtenido al ejecutar el servicio de sonarqube localmente. Figura 37. Instalación por medio de npm de las dependencias para ejecutar sonar dentro del proyecto. Figura 38. Configuración del karma.config.js para la ejecución del sonar. Figura 39. Configuración del angular.js para la ejecución del sonar. Figura 40. Creación del script para la ejecución del sonar por medio de npm. Figura 41. Configuración del archivo sonar-project.properties para la ejecución del sonar. Figura 42. Resultado obtenido al ejecutar el npm run sonar dentro del proyecto temis_cliente. Figura 43. Resultados obtenidos por la inspección sobre el código fuente de temis_cliente. Figura 44. Resultados obtenidos visualizados por las carpetas que componen el proyecto dentro de app/pages. Figura 45. Ejemplo de resultado obtenido según la inspección del código fuente. Figura 46. Ejemplo de resultado de code smell obtenido en la inspección de código. Figura 47. Ejemplo de resultados de bugs dentro del código obtenido en la inspección. Figura 48. Ejemplo de bug resaltado por el servicio de SonarQube. Figura 49. Ejemplo de vulnerabilidades que el sonar encontró en la inspección del código fuente. Figura 50. Ejemplo de los code smell encontrados después de la inspección del código fuente.

5

ÍNDICE DE TABLAS

Tabla 1. Reajuste realizado por año según se dicta en la Ley 4 de 1976 Tabla 2. Reajuste realizado por año según la Ley 71 de 1988 Tabla 3. Reajuste realizado por año según el Decreto 2018 de 1992 Tabla 4. Reajuste realizado por año según la Ley 100 de 1993 Tabla 5. Recursos humanos del proyecto. Tabla 6. Recursos técnicos y tecnológicos del proyecto. Tabla 7. Descripción del presupuesto del proyecto. Tabla 8. Análisis de costos generados por la versión actual del sistema de cuotas partes por concepto de su posicionamiento anacrónico con respecto a los nuevos desarrollos en la Oficina Asesora de Sistemas. Tabla 9. Modelo de datos inicial. Tabla 10. Requerimiento de arquitectura en el desarrollo del sistema de cuotas partes. Tabla 11. Requerimiento inicial del sistema cuotas partes, mantenimiento y facilidad de uso. Tabla 12. Requerimiento inicial del sistema cuotas partes, neutralidad del lenguaje y la plataforma. Tabla 13. Descripción de la tabla indice_precio_consumidor. Tabla 14. Descripción de la tabla dtf. Tabla 15. Modelo de datos tabla registrar_monto_aceptado_por_cobrar del schema monto_aceptado. Tabla 16. Descripción de la tabla registrar recaudo. Tabla 17. Descripción del API persona_crud del API Store. Tabla 18. Descripción del API ente_crud del API Store. Tabla 19. Descripción del API organizacion_crud del API Store. Tabla 20. Descripción del API experiencia_laboral_crud del API Store. Tabla 21. Descripción del API temis_monto_aceptado_crud.

6

CAPÍTULO 1. INTRODUCCIÓN

La Universidad Distrital Francisco José de Caldas es un ente autónomo de Educación Superior del Distrito Capital de Bogotá y de la Región Central de la República de Colombia fundada en el año 1948, cuya misión se centra en las funciones básicas de docencia, investigación y extensión; para cumplir a cabalidad con estas funciones, requiere del apoyo de talento humano como docentes, administrativos y contratistas, quienes deben tener una vinculación contractual según lo establecido en la ley colombiana. Según se expresa en el Artículo 4 de la Ley 797 de 2003:

"Durante la vigencia de la relación laboral y del contrato de prestación de servicios, deberán efectuarse cotizaciones obligatorias a los regímenes del sistema general de pensiones por parte de los afiliados, los empleadores y contratistas con base en el salario o ingresos por

prestación de servicios que aquellos devenguen."

Por consiguiente, todo empleado vinculado a la entidad gozará de los beneficios pensionales que la ley colombiana establece para quienes apliquen en el régimen de transición (Artículo 36 de la ley 100 de 1993). Con respecto a lo anterior, se debe de tener en cuenta que Colombia desde mediados del siglo XX se introdujeron varias reformas tendientes a configurar un nuevo régimen de seguridad social en pensiones, en efecto para este caso, el permitir que el tiempo laborado en diferentes entidades se pudiera acumular para efecto del reconocimiento de la pensión de jubilación, estableciendo la obligación correlativa de cada entidad de contribuir proporcionalmente al pago de las mesadas respectivas. En consecuencia, el Decreto 2709 de 1994, reglamentario de la Ley 71 de 1988 en el Artículos 11 dicta lo siguiente:

“Todas las entidades de previsión social a las que un empleado haya efectuado aportes para obtener esta pensión, tienen la obligación de contribuir a la entidad de previsión pagadora de la

pensión con la cuota parte correspondiente.” Justamente por lo anterior, la Universidad Distrital se ve en la necesidad de realizar los cobros pertinentes a las entidades previsoras donde los empleados pensionados por la entidad han acumulado tiempo laborado para efecto del reconocimiento de la pensión.

7

Actualmente en la institución se cuenta con el desarrollo para llevar el registro de las acciones que tengan efecto sobre las cuotas partes generadas por la cantidad de pensiones que se han reconocido por las entidades involucradas; esta tiene como objetivos servir como una herramienta de comunicación entre los interesados, mantener un registro único sobre las captaciones de dinero realizadas por la Universidad por medio de las cuotas partes y llevar un registro de constancia de los cobros y pagos entre las entidades involucradas y la Universidad. Con el fin de realizar mejoras y congruencias de unificación con los diferentes sistemas de información con los cuales se cuentan, la oficina asesora de sistemas (OAS), en su posición de crear, apoyar y generar soluciones de software para la Universidad Distrital, pretende realizar la migración a nuevas tecnologías del módulo de cuotas partes que se está manejando actualmente (TEMIS), con el fin de acoplarlo a las necesidades y estándares recientes, lo cual permite unificar la gran cantidad de datos que se manejan por medio de los procesos involucrados (registro de datos parametrizables según lo establece la ley colombiana, tal como el SLM o los impuestos que tengan efecto sobre el cálculo de las cuotas partes, entre otros), con el fin de llevar un registro único de estos, los cuales puedan ser manejados por los distintos módulos que se manejan en la Universidad, dejando la información disponible a cualquier proceso que la requiera.

8

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA

Todo colombiano según dicta la ley, tiene el derecho a una pensión de jubilación correspondiente, la cual será reconocida y pagada por la entidad de previsión social a la cual estuviera afiliado al tiempo de cumplir el tiempo de servicios requeridos por la ley y demás disposiciones; por consiguiente, la entidad encargada de reconocer y pagar la pensión, se ve en la obligación de responderle al empleado por la su pensión. De esta manera, la Universidad Distrital en sus deberes como entidad pública, se vió en la obligación de realizar el pago respectivo de la pensión, a cualquier persona que por cumplimiento de los requisitos establecidos en la ley colombiana, fuese válida para acceder a este derecho. Por consiguiente: según lo establecido en el Decreto 2709 de 1994:

Todas las entidades de previsión social a las que un empleado haya efectuado aportes para obtener esta pensión, tienen la obligación de contribuir a la entidad de previsión pagadora de la

pensión con la cuota parte correspondiente. (Ley 71 de 1988, Artículo 11)

De lo anterior, se asume que la Universidad Distrital en su rol de entidad previsora, está en derecho de realizar el cobro de las cuotas partes correspondientes a las demás entidades involucradas por efecto del pago de pensiones. Dadas las condiciones que anteceden, b ajo el estudio realizado por la Oficina Asesora de Sistemas (OAS) en el año 2013, se identificó cierta problemática con el registro ordenado de las entradas de dinero a la Universidad, por concepto de las cuotas partes, además de la falta de un debido manejo al tema concerniente, por tal motivo, diseñó el proyecto para la realización de un módulo que de manera correcta realizará el control del registro consecutivo del cobro y pago de las entidades involucradas en la pensión de los empleados, además de llevar un registro de los datos de los pensionados por la Universidad Distrital y sus beneficiarios a la pensión. Actualmente, el sistema de cuotas partes, se encuentra aislado, sin la práctica de los estándares actuales de la Oficina Asesora de Sistemas, por consiguiente, con el fin de resolver estos inconvenientes y otros, tal como la gran cantidad de datos que se maneja con disposición de realizar el registro de las cuotas partes generadas por la Universidad Distrital, los cuales no se integran realmente a las necesidades que está supliendo la Oficina Asesora de Sistemas (OAS) en la actualidad, se requiere la migración a nuevas tecnologías del módulo de manejo de cuotas partes (TEMIS), con el fin de terminar con la gran variedad de procesos y datos obsoletos, la falta de interoperabilidad del módulo en cuestión con las variables existentes en el

9

sistema (empleados, entidades, SML, entre otros), que pueden ser reutilizados o en consecución, que se pueden también implementar en este módulo, evitando redundancia de datos existentes para la OAS, por lo cual, se realizará el inicio de la migración de los módulos paramétricos descritos anteriormente que pertenecen al actual sistema de cuotas partes (TEMIS) a las nuevas tecnologías.

10

CAPÍTULO 3. OBJETIVOS

3.1. Objetivo general

Llevar a cabo la migración a nuevas tecnologías de los actuales módulos paramétricos relacionados con el sistema de cuotas partes (TEMIS) de la Oficina Asesora de Sistemas (OAS), la gestión de datos contemplados en el contexto pensional de la Universidad Distrital, con el fin de permitir la unificación integra de datos a nivel global del sistema de cuotas partes con los demás módulos trabajados en la OAS, haciendo uso de las tecnologías actuales, la metodología de desarrollo establecidas y siguiendo los lineamientos propios del proceso de desarrollo implementado.

3.2. Objetivos específicos

● Construir el módulo paramétrico de Gestión de información y Gestión de datos del pensionado perteneciente al sistema de cuotas partes (TEMIS).

● Realizar y registrar la documentación del proceso de desarrollo de la migración de nuevas tecnologías basada en los requerimientos y la arquitectura planteadas, para llevar registros completos de lo que se está actualmente implementando y cuales se implementarán, con el fin de que sirva de referencia para el futuro.

● Llevar a cabo la validación del código fuente con el fin de identificar los posibles problemas de ambigüedad que puedan surgir, además de cumplir con los lineamientos de cada iteración en las etapas del proceso de desarrollo implementado en la Oficina Asesora de Sistemas (OAS).

11

CAPÍTULO 4. JUSTIFICACIÓN

La Oficina de Asesoría de Sistemas (OAS), en su tarea de mejoramiento continuo de los sistemas de información de la Universidad Distrital Francisco José de Caldas, con el fin de brindar las herramientas necesarias para la solución de diversos problemas, con el pasar del tiempo ha implementado tecnologías para el desarrollo óptimo de soluciones a la medida para la Universidad, pues son un gran número de problemas que la acogían en el pasado, pero se ha realizado cierta escalabilidad con el fin de terminarlos, y en virtud de lo anterior, las soluciones realizadas se han ido acoplando a las nuevas tecnologías que se logran encontrar en el mercado, para mantener el nivel competitivo frente a otras soluciones y brindar resultados importantes, requeridos por los diferentes entes que construyen la presente institución pública. De lo anterior, en la Universidad Distrital, la Oficina de Asesoría de Sistemas (OAS), ha decidido realizar migraciones de los antiguos módulos desarrollados a tecnologías actuales, con el fin de seguir brindando las mejores soluciones a la Universidad, además, de poder realizar un eficiente uso a los recursos y gran cantidad de datos que se debe de manejar en las innumerable cantidades de procesos que se efectúan dia a dia en la Universidad. Por consiguiente, el presente módulo de cuotas partes (TEMIS), realizado en el año 2013, se ha venido quedando estancado, presentando ciertas falencias en ciertos aspectos frente a las nuevas tecnologías, además de un ineficiente control y uso de datos y recursos de la Universidad, por tanto que se ha pretendido realizar la respectiva migración a las tecnologías que se están implementando en la OAS, además de hacer un respectivo control y correcto uso de los datos y recursos que se requieren para el funcionamiento adecuado del mismo, esto último, gracias a la integración de los datos que se maneja en el módulo con los demás sistemas generados, los cuales, puedan contener la misma información, o por otro lado, la generación de nuevos datos que a futuro se puedan implementar en otros módulos, evitando la redundancia y promoviendo la reutilización de los datos, según las necesidades en otros sistemas, lo cual resulta en herramientas más robustas, funcionales y adaptables.

12

CAPÍTULO 5. MARCO TEÓRICO

5.1. Las cuotas partes

5.1.1. Normatividad Nace esta figura de las cuotas partes pensionales en la reforma introducida por la Ley 6 de 1945, en cuanto que para reunir el tiempo necesario para la pensión de jubilación permitió que se pudieran acumular todos los tiempos servidos a distintas entidades públicas. El artículo 29 así lo dispuso: “ARTÍCULO 29. Los servicios prestados o alternativamente a distintas entidades de derecho público, se acumularan para el computo del tiempo en relación con la jubilación, y el monto de la pensión correspondiente se distribuirá en proporción al tiempo servido y al salario o remuneración devengados en cada una de aquellas. Los trabajadores cuyos salarios o remuneraciones se paguen con cargo a fondos especiales que se formen con aporte de varias entidades de derecho público, gozan de las prestaciones más favorables que estas reconozcan a sus propios trabajadores, con cargo al mismo fondo especial.” (Ley 6 de 1945) La anterior norma fue adicionada por el artículo 1° de la Ley 24 de 1947, ratificado tanto la posibilidad de la acumulación de tiempos de servicio a distintas entidades públicas como la facultad de distribución del pago entre las mismas. Corresponde al financiamiento entre entidades públicas de una pensión después de 1988 entre el ISS y Cajas de previsión que recibían aportes. A la última entidad pública en la que haya laborado el trabajador le corresponde el reconocimiento y pago de la jubilación (Ley 33 de 1985); en la medida que el pensionado hubiere laborado en otras entidades del sector público, la entidad jubilante tiene derecho a repetir contra dichas entidades en el valor proporcional referido al tiempo laborado en otra entidad pública sobre el total del tiempo laborado con el sector público. Únicamente aplica para personas por tiempos laborados en el sector público. Tope de pensión Se fijó para el sector público una mensual máxima equivalente a veintidós (22) veces el elevado de los salarios mínimos vigentes en el país, salvo lo dispuesto en el artículo 113 de la Constitución Nacional, y en aquellas otras normas legales que fijen regímenes especiales para la materia (Artículo 2, decreto 435 de 1971).

13

5.1.2. Pensión Legal Sector Público

5.1.2.1. Requisitos Para quienes apliquen el régimen de transición señalado en el Artículo 36 de la ley 100 de 1993, el reconocimiento debe efectuarse bajo los parámetros de la normatividad anterior Ley 33 de 1985 (55 años de edad (mujeres) – 60 años de edad (hombres) y con 20 años de servicio a entidades del sector público). En caso de reconocer una pensión en términos convencionales, para aquellos que además reúnen tiempo de servicio con entidades del sector oficial, tendrán derecho a una pensión legal incluida en la que les reconozca la entidad pública, habilitando así la posibilidad de cobrar cuotas partes pensionales sobre la pensión legal.

5.1.2.2. Beneficios Un monto equivalente al 75% del ingreso base de liquidación en los términos del Artículo 36 de la ley 100 de 1993, es decir, sobre el tiempo que le hacía falta a la entrada en vigencia de la ley 100 -1° de abril de 1994- hasta el cumplimiento de los requisitos mínimos o hasta el momento del retiro si éste es posterior.

5.1.3. Reajustes de las pensiones legales Consiste en la actualización del valor de la mesada pensional aplicando a ésta el índice porcentual establecido por la misma, con el fin de garantizar el poder adquisitivo constante de la misma.

● Ley 6 de 1945 Fijo en $200.oo el tope máximo para las pensiones oficiales y particulares que se causen con posterioridad.

● Ley 77 de 1959 Aplicable a las pensiones de jubilación oficiales, semioficiales y particulares y las de invalidez, elevó el tope a partir del 1° de enero de 1960 a $1.275.oo y ordenó un reajuste de las pensiones antiguas sin reliquidación. Es decir, a la cuantía original debía sumarse únicamente la cuota fija del reajuste hasta llegar al nuevo tope.

● Ley 171 de 1961 Aplicó a las pensiones oficiales, semioficiales y particulares y fijo para las pensiones nuevas un tope de $3.000.oo. Establece que ninguna pensión de jubilación o invalidez podía ser inferior al 75 % del respectivo salario mínimo regional.

● Ley 1° de 1963 Aplicable al personal civil de la administración pública, a los establecimientos públicos descentralizados y al sector privado con efectos a partir del 1° de enero de 1963, aumentó la suma de $3.120.oo a partir del 23 de abril de 1966: Las pensiones de jubilación o de invalidez reconocidas con anterioridad a la vigencia de esta ley (23 de abril de 1966), serán aumentadas, por una sola vez, hasta llegar al 75 % de la asignación actual del cargo o cargos que sirvieron de base para la liquidación, pagaderos seis meses después de dicha vigencia.

14

● Decreto 435 de 1971 Se aplicó para los años de 1966 al 1970, a partir del 1° de abril de 1971 a quien tuviere el status de pensionado en 31 de diciembre de 1970 se le reajuste de oficio, su pensión de jubilación en $100.oo mensuales; a esta suma se le agregaba la cuantía resultante de aplicar a la pensión al 31 de diciembre de 1970, un porcentaje equivalente al cuatro por ciento (4 %) multiplicado por el número de años transcurridos entre el cual se reajusto por última vez la pensión y aquella fecha. Las pensiones causadas con anterioridad al 1° de enero de 1966 para efectos de reajuste, se entenderán causadas a partir de dicha fecha. En consecuencia, la pensión reajustada (P.R.) resultará de aplicar la siguiente fórmula:

P.R. = P.A. + $100.oo + (1970 - X) * 4 % P.A.

Donde: P.R. = Valor de la pensión reajustada P.A. = Valor de la pensión a 31 de diciembre de 1970 X = Año en que se caus´o o reajuste por última vez la pensión.

● Decreto 1221 de 1975 Determinó que las entidades oficiales y semioficiales de previsión social de carácter nacional (Artículo 2), reajustan las pensiones de jubilación, invalidez y retiro por vejez y las sustituciones pensionales del sector público en un treinta y tres por ciento (33 %) a partir del 1° de julio de 1975.

● Ley 4 de 1976, Decreto Reglamentario 732 Implementaron un nuevo sistema en los reajustes de las pensiones de jubilación, invalidez, vejez y sobrevivientes de los sectores públicos, oficial y semioficial en todos los órdenes y en el sector privado, así como las del ISS, con la sola excepción de las pensiones por incapacidad permanente parcial. Se tiene en cuenta los aumentos del máximo salario mínimo legal durante el año inmediatamente anterior. Las citadas pensiones se reajustan de oficio cada año, en la siguiente forma:

Cuando se eleve el salario mínimo legal más alto, se procederá así: Con una suma fija igual a la mitad de la diferencia entre el antiguo y nuevo salario mínimo mensual legal más alto, más una suma equivalente a la mitad del porcentaje que represente el incremento entre el antiguo y el nuevo salario mínimo mensual legal más alto, este último aplicado a la correspondiente pensión.

Los reajustes antes indicados se harán efectivos a quienes hayan tenido el estado o “status” de pensionado con un año de anticipación a cada reajuste.

En ningún caso el reajuste será inferior al 15% de la respectiva mesada pensional para las pensiones equivalentes hasta un valor de cinco (5) veces el salario minimo legal mas alto; las pensiones no podrán ser inferiores al salario mínimo legal mensual más alto, ni superior a 22 veces este mismo salario.

15

De acuerdo a lo anterior, los reajustes que en virtud de la Ley 4 de 1976 se deben aplicar son los siguientes:

AÑO REAJUSTE

1976 15 % + $180

1977 15 % + $180

1978 25 % + $390

1979 15 % (para pensiones equivalentes hasta $12.900) o 5.13 % + $120.oo (para pensiones superiores a $12.900)

1980 16.86 % + $435

1981 15.22 % + $525

1982 13.33 % + $600

1983 15 % + $855

1984 12.49 % + $925.50 ó 15 % (para pensiones entre $36.872.50 y $46.305.)

1985 11 % + $1.028.50 ó 15 % (para pensiones entre $25.462.50 y $56.490.)

1986 10 % + $1.129.80 ó 15 % (entre $22.590.oo y $67.788.oo)

1987 12 % + $1.626.90 ó 15 % (entre $54.231.15 y $84.057.oo)

1988 11 % + $1.849.20 ó 15 % (entre $46.230.oo y $102.549.oo) Tabla 1. Reajuste realizado por año según se dicta en la Ley 4 de 1976

● Ley 71 de 1988 Aplicable desde el año 1989, según la cual las pensiones a que se refiere el Artículo 1 de la Ley 4 de 1976, y las de incapacidad permanente parcial y las compartidas, serán reajustadas de oficio cada vez y con el mismo porcentaje en que sea incrementado por el Gobierno el salario mínimo legal mensual. Reajuste que tendría vigencia simultánea al del salario.

Por su parte el artículo 2 señaló que ninguna pensión podrá ser inferior al salario mínimo legal mensual, ni exceder de quince (15) veces dicho salario; salvo lo previsto en convenciones colectivas, pactos colectivos y laudos arbitrales, normas que surtieron efectos hasta la entrada en vigencia de la Ley 100 de 1994. Teniendo en cuenta el índice sobre el cual se ha incrementado el salario mínimo legal a partir del 1o de enero

16

de 1989, los reajustes que deben ser aplicados después de esa fecha son los siguientes:

AÑO REAJUSTE

1989 27%

1990 26%

1991 26.06 %

1992 26.044 %

1993 25.0345 %

1994 21.09 % Tabla 2. Reajuste realizado por año según la Ley 71 de 1988

● Decreto 2108 de 1992, reglamentario de la Ley 6 de 1992 Ordenó un reajuste especial para quienes se pensionaron entre los años 82 y 88, en un 7%. Para las pensiones jubilación del sector público del orden nacional, reconocidas con anterioridad al 1o de enero de 1989, se ordenó un reajuste del 12%. La finalidad de este decreto fue actualizar el valor de la pensión, para aquellas personas que se vieron perjudicadas con la pérdida del poder adquisitivo de sus pensiones durante esos años.

Es esta la razón por la cual el Decreto 2108 ordenó reajustes adicionales para aquellos pensionados con anterioridad a diciembre 31 de 1988, dentro de la filosofía de actualizar el valor de la pensión para que aquellas personas que se vieron perjudicadas con la pérdida del poder adquisitivo como producto de los bajos reajustes ordenados por Ley 4 de 1976 frente a las normas posteriores.

Año causación DERECHO PENSIÓN

% REAJUSTE % Dist. por Años A partir de

1981 y anteriores 28 12 12 4

1-1-93 1-1-94 1-1-95

1982 hasta 1988 12 7 7

1-1-93 1-1-94

Tabla 3. Reajuste realizado por año según el Decreto 2018 de 1992

Estos reajustes pensionales fueron compatibles con los incrementos decretados por el Gobierno Nacional en desarrollo de la Ley 71 de 1988.

17

● Ley 100 de 1993 Con el fin de mantener el poder adquisitivo de las pensiones de vejez, invalidez y de sustitución o sobrevivientes, en el Sistema General de Pensiones y en el Sistema General de Riesgos Profesionales, se dispuso que su reajuste será anualmente de oficio el 1o de enero de cada año, según la variación porcentual del índice de precios al consumidor total nacional, certificado por el DANE para el año inmediatamente anterior; no obstante, las pensiones cuyo monto mensual sea igual al salario mínimo legal mensual vigente, serán reajustadas de oficio cada vez y con el mismo porcentaje en que sea incrementado dicho salario, siempre y cuando el mencionado reajuste resulte superior al de la variación del IPC antes previsto, pues de lo contrario, se deberá reajustar en este último porcentaje.

En consecuencia, para cada año proceden los siguientes reajustes:

AÑO REAJUSTE

1995 22.59%

1996 19.46%

1997 21.63%

1998 17.68%

1999 16.70%

2000 9.23%

2001 8.75%

2002 7.65%

2003 6.99%

2004 6.49%

2005 5.5%

2006 4.85%

2007 4.48%

2008 5.69%

2009 7.67% Tabla 4. Reajuste realizado por año según la Ley 100 de 1993

● La Ley 100 de 1993 Decreto un reajuste pensional para pensionados con anterioridad al 1° de enero de 1994 (Artículo 143) se le hubiere reconocido la pensión de vejez o

18

jubilación, invalidez o sobrevivientes, y a quienes sin haberles efectuado el reconocimiento tuvieren causada la correspondiente pensión con los requisitos formales completos, consistente en que con su mesada a partir de dicha 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 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 1993 o a la que se determine cuando rija la cobertura familiar, sin exceder del 12%.

● Con posterioridad a la Ley 100 de 1993 , el legislador profirió la Ley 445 de 1998 y el Gobierno Nacional el Decreto Reglamentario 236 Reconociendo a pensiones del sector público del orden nacional, financiadas con recursos del presupuesto nacional, del Instituto de Seguros Sociales, así como de los pensionados de las Fuerzas Militares y de la Policía Nacional, conservando estos últimos su régimen especial, tres incrementos realizables el 1 de enero de los años 1999, 2000 y 2001 para aquellas pensiones que arrojaran una diferencia positiva al restar del ingreso inicial de la pensión el ingreso actual de pensión.

Los factores salariales que deben tenerse en cuenta para la liquidación de la pensión legal son: la asignación básica, los gastos de representación, las primas de antigüedad, técnica, ascensional y de capacitación, los dominicales y feriados, las horas extras, la bonificación por servicios prestados, el valor del trabajo suplementario o realizado en jornada nocturna en el dia de descanso obligatorio y en todo caso, los demás factores que hayan servido de base para calcular los aportes.

5.1.4. De las pensiones

● Acuerdo 224 de 1966 aprobado por el decreto 3041 de 1966 Están sujetos al seguro social obligatorio: b) Los trabajadores que presten servicio a entidades o empresas de derecho público, semioficiales o descentralizadas, cuando no estén excluidos por disposición legal expresa; c) Los trabajadores que mediante contrato de trabajo presten servicios a entidades de derecho público en la construcción y conservación de las obras públicas y en las empresas o institutos comerciales, industriales, agrícolas, ganaderos o forestales, que aquellas entidades exploten directa o indirectamente o de los cuales sean accionistas o coopartícipes.

● Decreto ley 433 de 1971 La Nación, los departamentos, municipios y los establecimientos públicos, empresas industriales y comerciales del Estado y sociedades de economía mixta, en su caso, contribuirán con las cotizaciones patronales a que haya lugar cuando actúen analógicamente como patronos, en los eventos contemplados en el Artículo 2° de este Decreto.

19

● Acuerdo 029 de 1983, Artículo 1 Se modifica el requisito del tiempo de servicio en el sentido de acreditar un mínimo de 500 semanas de cotización, pagadas durante los últimos 20 años anteriores a la fecha de la solicitud, o haber completado mínimo 1000 semanas de cotización sufragadas en cualquier tiempo.

● Decreto 758 de 1990 Están sujetos al seguro en forma facultativa los servidores de las entidades oficiales del orden estatal que a la fecha del 17 de julio de 1977 se encontraban registradas como patronos ante el ISS.

● Artículo 12 Requisitos de la pensión de vejez. Tendrán derecho a la pensión de vejez las personas que reúnan los siguientes requisitos:

○ Sesenta años o más de edad si es varón o cincuenta y cinco o más de edad, si es mujer.

○ Un mínimo de quinientas semanas cotizadas pagadas durante los últimos veinte años posteriores al cumplimiento de las edades mínimas, o haber cotizado un número de un mil semanas, sufragadas en cualquier tiempo.

● Ley 47 de 1947, Artículo 1°, Artículo 29 Ley 6 de 1945 Los servicios prestados sucesiva o alternativamente para distintas entidades de derecho público, se acumularan para el computo de tiempo en relación con la jubilación, y el monto de la pensión correspondiente se distribuirá en proporción al tiempo servicio y al salario o remuneración devengados en cada una de aquellas.

● Ley 72 de 1947 Los empleados nacionales, departamentales o municipales que al tiempo de cumplir su servicio estén afiliados a una Caja de Previsión Social tendrán derecho a exigirle el pago de la totalidad de la pensión de jubilación. La Caja pagadora repetirá de las entidades obligadas el reembolso de la cantidad proporcional que les corresponda, habida consideración del tiempo de servicio del empleado en cada una de las entidades oficiales.

● Ley 3135, Artículo 28 La entidad de previsión obligada al pago de la pensión de jubilación tendrá derecho a repetir contra los organismos no afiliados a ella, a prorrata del tiempo que el pensionado hubiere servido en ellos. El proyecto de liquidación se ha notificado a los organismos deudores, los que dispondrán del término de quince días para objetarlo.

● Decreto reglamentario 1848 de 1969, Artículo 72 y 75, numeral 3 Los servicios prestados sucesiva o alternativamente a distintas entidades de derecho público, establecimientos públicos, empresas oficiales y sociedades de economía mixta, se acumularan para el cómputo del tiempo requerido para la pensión de jubilación. En este caso, el monto de la pensión correspondiente se distribuirá en proporción al tiempo servido en cada una de aquellas entidades, establecimientos, empresas o sociedades de economía mixta.

20

La pensión de jubilación correspondiente se reconocerá y pagará al empleado oficial por la entidad de prevision social a la cual estuvo afiliado al tiempo de cumplir el tiempo de servicios requeridos por la ley, si para entonces se hubiere retirado del servicio oficial sin tener la edad exigida para tal fin, o por la entidad de previsión a que se esté afiliado al tiempo de retiro, si entonces cumple los requisitos de tiempo de servicios y edad señalados para el goce de la pensión.

● Ley 33 de 1985 Las cajas de previsión las entidades del orden nacional, departamental, intendencial, comisarial, municipal o distrital que por ley, reglamento o estatutos tuvieran, entre otras, la función de pagar pensiones a empleados oficiales de cualquiera de dichos órdenes; la caja de previsión social obligada al pago de pensión de jubilación, tendrá derecho a repetir contra los organismos no afiliados a ella, o contra las respectivas cajas de previsión, a prorrata del tiempo que el pensionado hubiere servido o aportado a las correspondientes cajas u organismos.

El Ministerio de Hacienda y Crédito Público efectuará anualmente las compensaciones a que haya lugar, con cargo a los giros que les correspondan a los organismos o cajas, por concepto de aportes al Presupuesto Nacional; cuando se trate de entidades del orden departamental, intendencial, comisarial, municipal o del Distrito Especial de Bogotá, la compensación anual se efectuará con cargo a las correspondientes transferencias de impuestos nacionales.

● Ley 490, Articulo 4 en 1998 Las entidades públicas del orden nacional, que de acuerdo con lo establecido en las respectivas normas, estén obligadas a concurrir con el pago de las pensiones causadas con anterioridad al primero de abril de 1994, suprimen las obligaciones recíprocas que por concepto de cuotas partes hayan asumido, efectuando en sus estados financieros los registros contables correspondientes.

Las obligaciones pensionales causadas a partir de tal fecha, se financiarán además de los recursos previstos en la ley, con el bono pensional o cuota parte que para el efecto deberá expedir la entidad que esté en la obligación de concurrir en el pago de la respectiva pensión, o la que haga sus veces, emitido a favor de la entidad encargada del pago de dicha prestación

● Decreto 1404 de 1999, reglamentario de la ley 490, Artículo 4 Para efectos de suprimir las obligaciones recíprocas que existen entre entidades públicas del orden nacional por concepto de cuotas partes por pensiones, causadas con anterioridad al 1° de abril de 1994, dichas entidades procederán así:

○ Eliminaran las obligaciones que existían por pagar y a favor de entidades públicas del orden nacional por concepto de pensiones causadas antes del 1° de abril de 1994.

21

○ Eliminaran los derechos que existían por cobrar a otras entidades públicas del orden nacional por concepto de las pensiones causadas antes del 1° de abril de 1994 .

En lo sucesivo no se registraron en la contabilidad de las entidades públicas del orden nacional, obligaciones o derechos por concepto de cuotas partes por pensiones causadas con anterioridad al 1° de abril de 1994, a favor o a cargo de otras entidades públicas del orden nacional. Por consiguiente a la entidad que reconoció la pensión asumir la totalidad del pasivo correspondiente.

● Ley 1066 de 2006, Artículo 4 Las obligaciones por concepto de cuotas partes pensionales causarán un interés del DTF (Depósito a Término Fijo) entre la fecha de pago de la mesada pensional y la fecha de reembolso por parte de la entidad concurrente. El derecho al recobro de las cuotas partes pensionales prescribirá a los tres (3) años siguientes al pago de la mesada pensional respectiva. La liquidación se efectuará con la DTF aplicable para cada mes de mora.

5.1.5. Normatividad vigente para el cobro de cuotas partes pensionales El aludido Decreto 4810 de 2010 previo en el Artículo 3° que los Ministerios de Hacienda y Crédito Público y de la Protección Social son los encargados de expedir las instrucciones operativas que permitan definir, conforme a las disposiciones vigentes, las obligaciones por cuotas partes pensionales a cargo de cada entidad; las condiciones en que se acrediten tales obligaciones; los requisitos para su compensación y la forma en que se acreditará el saldo a favor de las entidades acreedoras.

El Artículo 2 de la Ley 33 de 1985, recogió por lo señalado por el Decreto 2921 de 1048, que establece el procedimiento para el reconocimiento y pago de pensiones donde concurren en el pago una o varias entidades a prorrata del tiempo cotizado o servicio, para lo cual la Caja de Previsión obligada al pago de una pensión, en ejercicio de su derecho de recobro, repetir´a contra los organismos no afiliados a ella, o contra las demás entidades de previsión, a prorrata del tiempo que el pensionado hubiere servido o aportado a ellas.

Con fundamento en la anterior disposición, la entidad llamada a reconocer y pagar la prestación debe cumplir con el procedimiento establecido para tal fin, como es entre otros remitir a la(s) entidad(es) concurrente(s) en el pago de la prestación un proyecto de resolución mediante el cual se concede la pensión solicitada, a efectos de que en el término de quince (15) días manifiesten) si acepta(n) u objeta(n) la cuota parte asignada.

El proyecto de resolución que se debe remitir a las entidades que concurrirán en el pago de la prestación debe estar soportado por los documentos que acrediten el derecho e identifique al beneficiario de la prestación, como son entre otros: Documentos de Identificación bien sea la cédula de ciudadanía o cédula de extranjería, la partida de bautismo o el registro civil de nacimiento según corresponda, las certificaciones expedidas por el funcionario competente de las entidades donde prestó sus servicios donde conste: tiempos de servicios, factores salariales

22

y la entidad de previsión a la cual fueron afectados los aportes correspondientes; de tal manera que la entidad llamada a reconocer y pagar la cuota parte pueda verificar la veracidad de este derecho.

Una vez, reconocida la prestación, copia del acto administrativo se remitirá a las entidades concurrentes.

El procedimiento descrito en el Decreto 2921 de 1948 y en el Artículo 2 de la Ley 33 de 1985, debe haberse cumplido ante la entidad obligada para que proceda el cobro de cualquier cuota parte.

La exigibilidad de las cuotas partes pensionales se da a partir del pago de la correspondiente mesada pensional, como está dispuesto desde la vigencia del Decreto 2921 de 1948 cuya norma establece claramente la necesidad de acreditar el pago de las mesadas pensionales frente a las cuales se esté efectuando el cobro de cuotas partes pensionales, por lo cual es este un requisito sine qua non para que proceda la presentación de la correspondiente cuenta de cobro ante la entidad que debe concurrir en el pago de la obligación.

Sin embargo, como lo que se pretende es buscar las entidades territoriales salden de manera definitiva las obligaciones recíprocas por la totalidad del valor actuarial de la deuda por concepto de cuotas partes pensionales y excepcionalmente de manera parcial, se abre la posibilidad de efectuar un pago único por la totalidad de lo que corresponde al valor actuarial de la cuota parte pensional.

5.1.6. Preinscripción de las cuotas partes pensionales La obligación de concurrencia no se extingue por la prescripción en la medida que su v´ınculo es directo con el derecho mismo a la pensión que también es imprescriptible. Pero el derecho al recobro de cada una de las cuotas partes pensionales, que es un derecho crediticio a favor de la entidad que ha reconocido y pagado la pensión, si es susceptible de prescribir de manera individual en los términos del Artículo 4 de la Ley 1066 de 2006 “por la cual se dictan normas para la normalización de la cartera pública y se dictan otras disposiciones” que establece:

“Cobro de intereses por concepto de obligaciones pensionales y prescripción de la acción de cobro. Las obligaciones por concepto de cuotas partes pensionales causarán un interés del DTF entre la fecha de pago de la mesada pensional y la fecha de reembolso por parte de la entidad concurrente. El derecho al recobro de las cuotas partes pensionales prescribirá a los tres (3) años siguientes al pago de la mesada pensional respectiva. La liquidación se efectuará con la DTF aplicable para cada mes de mora” (Artículo 4 de la Ley 1066 de 2006)

De acuerdo a la norma citada, las cuotas partes pensionales que no hayan sido cobradas dentro de los tres (3) años siguientes a su pago prescriben.

23

Como la cuota parte pensional es legalmente exigible a partir del pago de la correspondiente mesada pensional, la prescripción ocurre tres (3) años después de este momento y puede interrumpirse por una sola vez, con la presentación de la correspondiente cuenta de cobro, pero solo por un término igual, es decir hasta por tres (3) años adicionales contados a partir de la interrupción.

5.1.7. Conformación de la cuenta de cobro por parte de las entidades territoriales Si la cuota parte pensional fue aceptada, o si se hubiera configurado el silencio administrativo positivo, se debe presentar la cuenta de cobro ante la entidad correspondiente, cuenta que debe estar debidamente diligenciada y con el lleno de los requisitos establecidos por la ley, así:

● Que se haya surtido el procedimiento de consulta de la cuota parte. ● Que las cuotas partes cobradas no se encuentren prescritas.

La cuenta de cobro debe integrarse con los siguientes documentos:

● Cuenta de cobro firmada por el representante legal de la entidad territorial. ● Certificación del ente territorial, firmada por el funcionario competente encargado de

avalar las cuotas partes indicando:

Que el procedimiento de consulta de las cuotas partes se haya realizado en los términos del Decreto 2921 de 1948 y la Ley 33 de 1985, es decir que haya sido comunicado el proyecto a la entidad o entidades territoriales concurrentes, que haya sido aceptado por estas últimas o en caso de objeción se haya corregido si eso hubiere tenido lugar, o que se haya producido el fenómeno del silencio administrativo positivo.

● Los Actos Administrativos de reconocimiento de las prestaciones donde se haya aplicado la figura de la cuota parte pensional.

● Acto Administrativo emitido por la entidad concurrente donde acepte la obligación impuesta, o del que objeta la cuota parte, o constancia o prueba del acaecimiento del silencio positivo.

● Constancia de pago de las mesadas objeto de las cuotas partes que se cobran, donde se indique la fecha de efectividad de la pensión y el valor inicial de la mesada, la fecha de inclusión en la nómina de pagos y el valor de la mesada a la fecha de presentación de la cuenta.

5.2. Estatuto tributario Interrupción y suspensorio del término de prescripción (Artículo modificado por el artículo 81 de la Ley 6 de 1992) .El término de la prescripción de la acción de cobro se interrumpe por la notificación del mandamiento de pago. (Artículo 818).

24

5.3. Conformación de las cuotas de cobro por parte de las entidades cuotapartistas Si la cuota parte pensional fue aceptada, o si se hubiere configurado el silencio administrativo positivo, se debe presentar la cuenta de cobro ante la entidad correspondiente, cuenta que debe estar debidamente diligenciada y con el lleno de los requisitos establecidos por la ley, así:

● Que se haya surtido el procedimiento de consulta de la cuota parte, señalado anteriormente.

● Que las cuotas partes cobradas no se encuentren prescritas. La cuenta de cobro debe integrarse con los siguientes documentos:

○ Cuenta de cobro firmada por el representante legal de la entidad territorial.

○ Certificación del ente territorial, firmada por el funcionario competente encargado de avalar las cuotas partes indicando: Que el procedimiento de consulta de las cuotas partes se haya realizado en los términos del Decreto 2921 de 1948 y la Ley 33 de 1985, es decir que haya sido comunicado el proyecto a la entidad o entidades territoriales concurrentes, que haya sido aceptado por estas últimas o en caso de objeción se haya corregido si eso hubiere tenido lugar, o que se haya producido el fenómeno del silencio administrativo positivo.

Los Actos Administrativos de reconocimiento de la prestación donde se haya aplicado la figura de la cuota parte pensional.

Acto administrativo emitido por la entidad concurrente donde acepte la obligación impuesta, o del que objeta la cuota parte, o constancia o prueba del acaecimiento del silencio positivo.

Constancia de pago de las mesadas objeto de las cuotas partes que se cobran, donde se indique la fecha de efectividad de la pensión y el valor inicial de la mesada, la fecha de inclusión en la nómina de pagos y el valor de la mesada a la fecha de presentación de la cuenta.

En caso de cobrarse cuota parte por pensión de sobreviviente, indicar además lo siguiente:

● Fecha del fallecimiento del pensionado. ● Tipo y número del documento de identificación de los beneficiarios. ● Nombres y apellidos de los beneficiarios. ● Calidad de beneficiario. (Cónyuge, compañero (a) permanente, hijos menores, hijos

inválidos, hijos mayores incapacitados en razón de estudios). ● Proporción correspondiente al beneficiario de la prestación.

25

● Acto Administrativo del reconocimiento. ● Valor mesada pensional ● Fecha de efectividad. ● Fecha de pago.

5.4. Compensacion El ejercicio de cruce de cuentas por pagar y por cobrar que realicen los entes territoriales conduce a establecer los valores que quedan compensados y a definir el saldo resultante de la compensación, el cual será cubierto por el ente territorial deudor con los recursos de que pueda disponer en su cuenta del FONPET, en los términos del Decreto 4810 de 2010.

La compensación deberá realizarse con base en los artículos 1714 y 1715 del Código Civil, verificando la concurrencia y la coexistencia de débitos y créditos, y teniendo en cuenta, se reitera, el término de prescripción de las cuotas partes pensionales y el régimen legal aplicable en cada caso.

Las entidades territoriales procederán a autorizar al FONPET la afectación del saldo que posean en la Subcuenta de Recursos de Propósito General como resultado del proceso de compensación y cruce de cuentas, dependiendo del resultado de ese proceso.

5.5. Ley 1066 - Cobro coactivo, reglamento interno de recuperación de cartera Amplía a todas las entidades públicas la facultad para adelantar el cobro coactivo de las obligaciones a su favor.

Las entidades territoriales ya tenían dicha facultad en virtud del artículo 59 de la ley 788 de 2003, y materia tributaria desde la ley 383 de 1997.

El procedimiento de cobro aplicable es el establecido en el Estatuto Tributario Nacional. Se modifican y adicionan normas del Estatuto Tributario Nacional que son aplicables a las entidades territoriales por la remisión que hace la ley 788 de 2002:

● Se precisa que la prescripción se decreta por la administración, de oficio o a solicitud de parte.

● Se establecen nuevos límites a la inembargabilidad de recursos de cuentas corrientes.

26

CAPÍTULO 6. ALCANCES Y LIMITACIONES

6.1. Alcances

● El proyecto se enfocará en la fase de fase de inicio, elaboración y construcción para la migración a nuevas tecnologías (Golang implementando el Framework de Beego y Angular empleando Postgresql) del sistema de cuotas partes (TEMIS), de los módulos de parametrización, según la metodología de SCRUM/OAS.

● Realizar la validación de código empleando la herramienta de Sonarqube al finalizar cada una de las iteraciones (sprint) realizadas, para la elaboración y construcción del sistema de cuotas partes con el fin de seguir los lineamientos y especificaciones de la OAS.

● Documentar el proceso migración a las tecnologías (Golang implementando el Framework de Beego y Angular empleando Postgresql) de los módulos paramétricos del sistema de cuotas partes.

● Realizar la respectiva arquitectura de la base de datos complementando la arquitectura realizada por la OAS en los demás sistemas existentes, para garantizar una integración de los datos.

● El equipo de trabajo se organizará por los roles definidos en el proceso de desarrollo OPENUP/OAS. El rol que se asumirán en la pasantía corresponde a Desarrollador.

6.2. Limitaciones

● La solución del software será desarrollada con base en el framework “Beego”, implementando el lenguaje de programación Go definido e implementado en la Oficina Asesora de Sistemas.

● La solución de software estará basada en componentes de software libre dando respuesta a políticas distritales e institucionales.

● Las actividades a realizar estarán determinados únicamente por las tareas generados durante cada una de las iteraciones contempladas en el proceso de desarrollo SCRUM/OAS.

● Los costos del presente proyecto desarrollado para la Oficina Asesora de Sistemas de la Universidad Distrital Francisco José de Caldas, en modalidad de pasantía, serán asumidos por el autor del presente proyecto.

27

● El director interno, será un docente de la institución proporcionado por la misma; el director externo, será quien seguirá la pasantía por parte de la Oficina Asesora de Sistemas, proporcionado por la misma.

28

CAPÍTULO 7. METODOLOGÍA

El software es un producto empírico, por lo que es un error adoptar procesos prescriptivos rígidos en proyectos de software, en cambio las metodologías ágiles reconocen la naturaleza empírica del software y están preparadas para acoger los cambios frecuentes, ofrecen rapidez para realizar los cambios idóneos a partir del feedback de los usuarios y se presentan con metodologías leves, enfocadas al software funcional en vez del formalismo y la documentación extensa [10].

A partir de lo anterior, el aplicar una metodología ágil dentro del desarrollo del presente proyecto proporciona ventajas que se verán reflejadas en el producto final, dada la gran flexibilidad que se proporciona frente a los cambios que puedan surgir durante la vida del proyecto, lo cual se refleja en la omisión en gastos innecesarios de recursos, además de la participación activa en la planificación dentro del proyecto por parte del equipo de desarrollo; basándose en la metodología SCRUM, pues permite aplicarse de una manera efectiva a cualquier proyecto de desarrollo sin importar el tamaño o la complejidad de estos, además de otros factores a considerar como el número de integrantes del equipo de desarrollo; también es una buena opción a considerar, dada la adaptación que presenta, lo cual le otorga la rapidez, flexibilidad y eficacia a causa de las iteraciones que presenta, pues está diseñada para ofrecer un valor significativo en todo el proyecto.

7.1. SCRUM Scrum es un modelo de desarrollo ágil caracterizado por:

1) Adoptar una estrategia de desarrollo incremental, en lugar de la planificación y ejecución completa del producto.

2) Basar la calidad del resultado más en el conocimiento tácito de las personas en equipos autoorganizados, que en la calidad de los procesos empleados.

3) Solapamiento de las diferentes fases del desarrollo, en lugar de realizarlas una tras otra en un ciclo secuencial o de cascada [4].

Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi a principios de los 80, al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986) [4].

Scrum es adecuado para el desarrollo de productos bajo un entorno caracterizado por:

1) Incertidumbre : Sobre esta variable se plantea el objetivo que se quiere alcanzar sin proporcionar un plan detallado del producto.

29

2) Auto-organización: Los equipos son capaces de organizarse por sí solos, no necesitan roles para la gestión pero tienen que reunir las siguientes características:

a) Autonomía : Son los encargados de encontrar la solución usando la estrategia que encuentren adecuada.

b) Autosuperación: Las soluciones iniciales sufrirán mejoras. c) Auto-enriquecimiento: Al ser equipos multidisciplinares se ven enriquecidos de

forma mutua, aportando soluciones que puedan complementarse.

3) Control moderado: Se establecerá un control suficiente para evitar descontroles. Se basa en crear un escenario de "autocontrol entre iguales" para no impedir la creatividad y espontaneidad de los miembros del equipo.

4) Transmisión del conocimiento: Todo el mundo aprende de todo el mundo. Las personas pasan de unos proyectos a otros y así comparten sus conocimientos a lo largo de la organización.

SCRUM al ser una metodología de desarrollo ágil tiene como base la idea de creación de ciclos breves para el desarrollo, que comúnmente se llaman iteraciones y que en SCRUM se llamarán "Sprints" [5].

7.1.1. Fases del ciclo de desarrollo ágil 1) Concepto: Se define de forma general las características del producto y se asigna el

equipo que se encargará de su desarrollo.

2) Especulación: En esta fase se hacen disposiciones con la información obtenida y se establecen los límites que marcarán el desarrollo del producto, tales como costes y agendas. Se construirá el producto a partir de las ideas principales y se comprueban las partes realizadas y su impacto en el entorno. Esta fase se repite en cada iteración y consiste, en rasgos generales, en:

a) Desarrollar y revisar los requisitos generales. b) Mantener la lista de funcionalidades que se esperan. c) Plan de entrega. Se establecen las fechas de la versiones, hitos e iteraciones.

Medirá el esfuerzo realizado en el proyecto.

3) Exploración: Se incrementa el producto en el que se añaden las funcionalidades de la fase de especulación.

4) Revisión: El equipo revisa todo lo que se ha construido y se contrata con el objetivo deseado.

30

5) Cierre: Se entregará en la fecha acordada una versión del producto deseado. Al tratarse de una versión, el cierre no significa que se ha finalizado el proyecto, sino que seguirá habiendo cambios, denominados "mantenimiento", que hará que el producto final se acerque al producto final deseado.

Figura 1. Ciclo de desarrollo ágil. Imagen tomada de [5] pág. 34

SCRUM gestiona estas iteraciones a través de reuniones diarias,uno de los elementos fundamentales de esta metodología [5].

7.1.2. Componentes de SCRUM SCRUM se puede dividir de forma general en 3 fases, que podemos entender como reuniones. Las reuniones forman parte de los artefactos de esta metodología junto con los roles y los elementos que lo forman.

7.1.2.1. Reuniones 1) Planificación del Backlog: Se definirá un documento en el que se reflejaran los

requisitos del sistema por prioridades. En esta fase se definirá también la planeación del Sprint 0, en la que se decidirá cuales van a ser los objetivos y el trabajo que hay que realizar para esa iteración. Se obtendrá además en esta reunión un Sprint Backlog, que es la lista de tareas y que es el objetivo más importante del Sprint.

2) Seguimiento del Sprint: En esta fase se hacen reuniones diarias en las que las 3 preguntas principales para evaluar el avance de las tareas serán:

a) ¿Que trabajo se realizó desde la reunión anterior? b) ¿Que trabajo se hará hasta una nueva reunión?

31

c) ¿Inconvenientes que han surgido y que hay que solucionar para poder continuar?

3) Revisión del Sprint: Cuando se finaliza el Sprint se realizará una revisión del incremento que se ha generado. Se presentarán los resultados finales y una demo o versión, esto ayudará a mejorar el feedback con el cliente.

7.1.2.2. Roles 1) Product Owner : Es la persona que toma las decisiones, y es la que realmente conoce

el negocio del cliente y su visión del producto.

2) ScrumMaster: Es el encargado de comprobar que el modelo y la metodología funciona.

3) Equipo de desarrollo: Suele ser un equipo pequeño de unas 5-9 personas y tienen autoridad para organizar y tomar decisiones para conseguir su objetivo.

4) Usuario: Es el destinatario final del producto.

5) Stakeholders: Las personas a las que el proyecto les producirá un beneficio.

6) Managers: Toma las decisiones finales participando en la selección de los objetivos y de los requisitos.

7.1.2.3. Elementos del SCRUM 1) Product Backlog: Lista de necesidades del cliente.

2) Sprint Backlog: Lista de tareas que se realizan en un Sprint.

3) Incremento: Parte añadida o desarrollada en un Sprint, es un parte terminada y totalmente operativa.

7.2. SCRUM OAS La metodología a aplicar en este proyecto es el modelo SCRUM, teniendo en consideración los diferentes roles, iteraciones (Sprints) y documentos propios de esta metodología ágil. SCRUM trabaja sobre la base del manejo de buenas prácticas para trabajar en equipo, y por ello consta de varios elementos organizacionales, documentales, etc.

32

Figura 2. Flujo de un proyecto desarrollado bajo la metodología SCRUM. Metodología SCRUM/OAS,

Oficina Asesora de Sistemas, 2016.

Las actividades globales deben realizarse en un cierto intervalo de tiempo, durante el cual se realizan algunos documentos y el desarrollo propio del trabajo de implementación. También existen ciertas reuniones especiales de SCRUM enfocadas a mejorar la productividad del equipo de trabajo haciendo de hitos de éste para controlar y/o corregir el desarrollo del mismo de acuerdo a lo planeado.

Para poder realizar una mejor gestión con esta metodología se plantea utilizar una herramienta de manejo de proyectos llamada Tuleap.

7.2.1. Tuleap Es la herramienta escogida por la Oficina Asesora de Sistemas para llevar el registro y realizar seguimiento a los proyectos que se están trabajando, utilizando la metodología SCRUM/OAS. Este software, que es de código abierto, tiene gran versatilidad de características propias de la metodología SCRUM como la documentación, la planeación de los sprints, entre otras. Este proyecto requiere indudablemente de un seguimiento que sea fácil de llevar debido a su tiempo de realización y al trabajo en sí que se pretende hacer, y Tuleap facilita esto al tener acciones “drag and drop”.

Este es un software que incluso grandes compañías utilizan y que está a disposición para una cantidad ilimitada de usuarios, proyectos y tiempo. Tuleap permitirá que el proyecto en sí pueda ser resuelto con la cantidad mínima de errores teniendo una excelente planeación, detallada hasta en lo más pequeño, con una buena documentación plasmada en los diferentes backlogs y con una carga de trabajo acorde al ritmo del equipo.

33

7.2.2. Proceso de SCRUM/OAS 1. Iniciar

1.1 Crear la visión del proyecto: En este proceso, crear un Declaración de la Visión del Proyecto que servirá de inspiración y proporcionará un enfoque de todo el proyecto.

1.2 Crear documento plan general del proyecto: define los parámetros para realizar el direccionamiento y seguimiento al proyecto. Especifica los objetivos. Describe cómo está organizado el proyecto y cuales son los recursos requeridos para su consecución (Tiempo, Tecnológicos, Financieros, Físicos y Humanos entre otros).

1.3 Modelo relacional: es la representación en tablas (esquema) del proyecto, el cual es prácticamente un paso antes del nivel físico debe ir aprobado por el comité conformado en la oficina, este se realizará por medio de la app dBeaver.

1.4. Identificar al Scrum Master y al Stakeholder(s)): En este proceso, el Scrum Master y el Stakeholder se identifican utilizando criterios de selección específicos.

1.5 Formación de un equipo Scrum: En este proceso, se identifican a los miembros del Equipo Scrum. Normalmente, el Product Owner es el responsable principal de la selección de los miembros del equipo, pero a menudo lo hace en Colaboración con el Scrum Master.

1.6 Realizar un cronograma general: Se debe establecer un cronograma sencillo de todo el proyecto mostrando el tiempo de cada fase.

1.7 Desarrollo de Epics: En este proceso, el Declaración de la Visión del Proyecto sirve como la base para el desarrollo de Epics.

1.8 Creación de la lista priorizada de pendientes del producto. En este proceso, Epic(s) son refinados, elaborados, y luego priorizados para crear un Prioritized Product Backlog . Los Criterios de aceptación también se establecen en este punto.

1.9 Realizar el plan de lanzamiento: En este proceso, el Equipo de Scrum revisa los Historias de Usuario en el Prioritized Product Backlog para desarrollar un Release Planning Schedule , que es esencialmente un programa de implementación por fases que se puede compartir con los socios del proyecto.

2. Planear y estimar

2.1 Levantamiento de proceso a desarrollar (flujograma, prototipo e historia de usuario): El flujograma debe estar en jbpm, el prototipo en pencil y la historia de usuario en Tuleap teniendo en cuenta las características de esta guía, de igual manera las historias de usuario deben estar relacionadas con un epic.

34

2.2 Aprobar, estimar y asignar historias de usuarios: En este proceso, el Producto Owner aprueba los User Stories para un Sprint. Luego, el Scrum Master y el Equipo Scrum estiman el esfuerzo necesario para desarrollar la funcionalidad descrita en cada historia de usuario, y el Equipo Scrum se compromete a entregar los requisitos del customer en forma de Approved, Estimated, and Committed User Stories. 2.3 Elaboración de tareas: En este proceso, los Approved, Estimated, and Committed User Stories se dividen en tareas específicas y se compilan en un Task List. A menudo, un Task Planning Meeting se convocará al efecto.

2.4 Estimar tareas: En este proceso, el Equipo Principal de Scrum durante reuniones de Estimación del Labor estima el esfuerzo necesario para realizar cada tarea del listado de tareas. El resultado de este proceso es un Effort Estimated Task List. 2.5 Elaboración de la lista de pendientes del Sprint (Create Sprint Backlog): En este proceso, el Equipo Principal de Scrum lleva a cabo un Sprint Planning Meeting donde el grupo crea un Sprint Backlog que contiene todas las tareas que deben completarse en el Sprint.

3. Implementar

3.1 Crear entregables: En este proceso, el Equipo Scrum trabaja en las tareas del Sprint Backlog para crear Sprint Deliverables. Se utiliza a menudo un Scrumboard para realizar el seguimiento del trabajo y de actividades que se llevan a cabo. Las cuestiones o problemas que enfrenta el Equipo Scrum podrían ser actualizadas en un Impediment Log.

3.2 Llevar a cabo el Sprint Standup diario: En este proceso, todos los días se lleva a cabo una reunión que es Time-box altamente concentrada que se refiere como Daily Standup Meeting . Es aquí donde los miembros del Equipo Scrum se actualizan el uno al otro referente a sus progresos y sobre los Impedimentos que puedan enfrentar.

3.3 Mantenimiento de la lista priorizada de pendientes del producto: En este proceso, el Prioritized Product Backlog se actualiza y se mantiene continuamente. Un Prioritized Product Backlog Review Meeting puede ser considerado, en el que se discute y se incorpora el Prioritized Product Backlog de forma apropiada.

4. Revisión y feedback

4.1 Demostración y validación del Sprint: En este proceso, el Equipo Scrum le demuestra el Sprint Deliverable al Propietario del producto y a los Socios relevantes en un Sprint Review Meeting . El propósito de esta reunión es asegurar la aprobación y aceptación del Propietario del producto de los Entregables creados en el Sprint.

4.2 feedback de Sprint: este proceso, el Scrum Master, el product owner y el Equipo Scrum se reúnen para discutir las lecciones aprendidas a lo largo del Sprint. Esta

35

información se documenta como las lecciones aprendidas que pueden aplicarse a los futuros Sprints. A menudo, como resultado de esta discusión, puede haber Agreed Actionable Improvements o recomendaciones actualizadas por parte del Cuerpo de asesoramiento de Scrum.

5. Lanzamiento

5.1 Envío de entregables: En este proceso, el Equipo Scrum le demuestra el Sprint deliverable al Propietario del producto y a los Socios relevantes en un Sprint Review Meeting. El propósito de esta reunión es asegurar la aprobación y aceptación del Propietario del producto de los Entregables creados en el Sprint.

5.2 feedback del proyecto: En este proceso, que completa el proyecto, los socios, el product owner y el Equipo 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.

Siguiente la metodología SCRUM, el periodo para realizar cada uno de los sprints será de una semana, y se realizará los días miércoles o jueves en caso de presentarse cualquier eventualidad extraordinaria para alguno de los participantes con una duración de una (1) hora aproximadamente, donde se revisarán los avances realizados sobre el desarrollo de cada una de las fases contempladas en el proyecto.

Como se hace mención de manera anterior, el equipo de desarrollo para el actual proyecto fue de un estudiante de ingeniería de sistemas, el cual se encargará de realizar el análisis y desarrollo del mismo.

Los roles con los cuales se conformará el equipo de trabajo cuenta con un director interno del proyecto, el cual asumirá el rol de Scrum Master, el mismo será proporcionado por la Oficina Asesora de Sistemas (OAS) dado que cuenta con el conocimiento necesario para validar las diferentes actividades que se establecen en cada una de las semanas con las cuales cuenta el desarrollo del proyecto; de igual manera, el director externo, encargado de revisar que las actividades desarrolladas durante los diferentes sprints se realicen de una manera correcta.

Finalmente, el desarrollo del presente proyecto se construirá implementando las tecnologías planteadas en los estándares de desarrollo implementados en la Oficina Asesora de Sistemas (OAS) con el fin de continuar con los lineamientos implementados en los diferentes sistemas; tal como el uso del template ngx-admin construido en el framework de Javascript, Angular en su versión 6.

36

Figura 3. Lógica de ejecución del framework REST API Beego

Lo anterior por la parte del cliente, para el desarrollo de los mid , el desarrollo se realizará por medio del framework de Golang, Beego , el cual es un framework API REST, lo cual se traduce en la posibilidad de generar interfaces que implementan HTTP para la obtención de datos o generar operaciones sobre datos con formatos diferentes formatos, tal como XML o JSON, siendo una óptima opción para el rápido desarrollo de aplicaciones Go incluyendo APIs, Web Apps y servicios de backend con características específicas a la integración con Go; este último, empleado para realizar los APIs que se emplean en la Oficina Asesora de Sistemas (OAS) para el desarrollo de las operaciones CRUD sobre la base de datos.

37

CAPÍTULO 8. RECURSOS

8.1. Recursos humanos Se contempla en la siguiente tabla (Tabla 5 ) los recursos humanos que se estiman como necesarios para el desarrollo y ejecución del presente proyecto de forma detallada, mediante el rol de desarrollador en FrontEnd:

1. Desarrollador en FrontEnd: Encargado en desarrollo del FrontEnd de la aplicación, el cual tenga conocimientos básicos en Angular, HTML5 y SASS.

2. Arquitecto en Base de Datos: Encargado en la administración de las soluciones de bases de datos y gestión del modelo empleado.

3. Director Interno: Docente de planta que presta su apoyo para la guía en la construcción y desarrollo del proyecto.

4. Director Externo: Representante de la empresa en la cual se está realizando el presente proyecto el cual gestionará las tareas a realizar durante el desarrollo.

Recurso Cantidad

Desarrollador en FrontEnd 1

Arquitecto en Base de Datos 1

Director Interno 1

Director Externo 1 Tabla 5: Recursos humanos del proyecto.

Fuente Realizado por autor

38

8.1. Recursos técnicos y tecnológicos Se contempla en la siguiente tabla (Tabla 6 ) los recursos técnicos y tecnológicos, los cuales representan recursos tal como los equipos y sistemas de almacenamiento necesarios para el desarrollo y ejecución del presente proyecto:

Recurso Cantidad

Equipos de computo 1

Almacenamiento disponible en google drive para guardar documentación

1 GB

Servicios de internet y energía 4 meses

Repositorio para el desarrollo por medio de versionamiento (GitHub)

1

Tabla 6: Recursos técnicos y tecnológicos del proyecto. Fuente Realizado por autor

8.1.1. Recursos de Software

Se contemplan los recursos de software, los cuales representan los programas, S.O., entre otros, necesarios para el entorno de desarrollo del proyecto:

● Linux Mint 16 Cinnamon ● Visual Basic Editor ● Go > v1.8 ● Beego Framework > v1.7 ● Motor de bases de datos PostgreSQL > v9.4 ● PgAdmin ● PgModeler ● Google Chrome

8.1.2. Recursos Institucionales

● Biblioteca de la Universidad Distrital Francisco José de Caldas ● Sala de reuniones de la OAS

39

CAPÍTULO 9. PRESUPUESTO

Como base para el presupuesto, se toman los recursos mínimos para el desarrollo del presente proyecto expuestos anteriormente, donde se presentan los valores unitarios presentados por cada mes y su total, representado por el tiempo máximo de ejecución de la pasantía (4 meses).

Tipo de recurso Recurso Cantidad Valor unitario (mensual)

Valor total

Humano Desarrollador en FrontEnd

1 2.000.000 8.000.000

Humano Director Interno 1 1.800.000 7.200.000

Humano Director Externo 1 1.800.000 7.200.000

Infraestructura Computador 1 100.000 400.000

Infraestructura Entorno de desarrollo Angular/GO

1 0 0

Infraestructura Almacenamiento disponible en google drive para guardar documentación

1 Giga 0 0

Infraestructura Internet 4 meses 75.000 300.000

Infraestructura Luz 4 meses 45.000 180.000

Monetarios Costos por imprevistos

- - 2.328.000

Presupuesto Final $25.608.000 Tabla 7: Descripción del presupuesto del proyecto.

Fuente Realizado por autor

Presupuesto final será de $25.608.000

40

9.1. Fuentes de financiamiento El proyecto a desarrollar se realiza para la Oficina Asesora de Sistemas de la Universidad Distrital Francisco José de Caldas como modalidad de pasantía, por lo cual las fuentes de financiamiento corresponden a la asignada por esta.

9.2. Analisis costo - beneficio La migración de tecnologías nuevas para el sistema de cuotas partes de la Universidad Distrital se plantea los siguientes costos totales por concepto del mantenimiento de los servidores locales los cuales son los que se encarga del proceso de la distribución de la información a los cuales se encuentren en la red local; además, las implicaciones que conllevan la adaptación de servicios implementados actualmente en la nube para la centralización de la información y mejora en el rendimiento del sistema, lo cual se traduce como reducción en los tiempos de manejo, una mejor eficacia en las actividades realizadas.

Recurso Valor mensual

Espacio físico 140.000

Costos de funcionamiento 265.000

Mantenimiento 180.000

Personal exclusivo 400.000

Acceso 250.000

Seguridad física 150.000

Seguridad informática 60.000

Total $1.445.000 Tabla 8: Análisis de costos generados por la versión actual del sistema de cuotas partes por concepto de su

posicionamiento anacrónico con respecto a los nuevos desarrollos en la Oficina Asesora de Sistemas. Fuente Realizado por autor

Costos por concepto de mantenimiento local mensual de la infraestructura del sistema de cuotas partes de la Universidad Distrital: $1.445.000

Lo anterior debe de ser un costo fijo mensual, dado que la información que posee el sistema en su mayoría se encuentra independiente de los demás desarrollos generados actualmente, lo cual se traduce en costos que se deben de mantener.

41

Sobre el análisis propuesto anterior realizado se genera una proyección a 5 años, los cuales son considerados como la vida útil del sistema debido a que en la Oficina Asesora de Sistemas se asigna ese periodo como vida útil, dados los cambios en tecnologías que pueda existir.

42

CAPÍTULO 10. DESARROLLO

10.1. Modelo de negocio actual del sistema de cuotas partes

El sistema de cuotas partes en su versión actual v1.0 (openEVA) es presentado como una solución web para gestionar cálculos, registros y reportes correspondientes a las cuotas partes pensionales de la Universidad Distrital Francisco José de Caldas, este sistema contiene los módulos de gestión de información del sistema, gestión de liquidación, gestión de datos básicos del pensionado y el módulo de consulta.

De lo anterior, se debe de comprender el funcionamiento inicial de los módulos que en el presente proyecto se desarrollan con el fin de actualizarlo a las nuevas tecnologías implementadas actualmente en la Oficina Asesora de Sistemas, dado que el sistema de cuotas partes de pensionados de la Universidad Distrital Francisco José de Caldas se encuentra actualmente en su versión 1.0 desde el año 2013, lo cual crea conflictos con los estándares de calidad de la Oficina Asesora de Sistemas (OAS), dado que el tiempo de vida útil que se asigna a los distintos sistemas desarrollados es de no más de 5 años; cabe resaltar que actualmente se está buscando centralizar de una mejor manera la información que se encuentra para los diferentes sistemas desarrollados, con el fin de evitar redundancia en esta, lo cual se traduce en beneficios tangibles, tal como la reducción en costos de almacenamiento y mantenimiento, donde también se ve implicado los servicios en la nube que se están implementando para este fin, lo cual contrasta con el desarrollo del sistema actual de cuotas partes (openEVA), donde se la información aún se encuentra en la red local de la Oficina Asesora de Sistemas (OAS).

Figura 6. Estructura del sistema de cuotas partes del módulo de gestión de información y parametrización.

Fuente Documentación de TEMIS, 2013 Oficina Asesora de Sistemas

43

A continuación se describirán los submódulos que pertenecen a los módulos correspondientes de al paramétrico y gestión de información en los cuales se ve enfocado el desarrollo del actual proyecto, donde el autor se encontró involucrado con el rol de desarrollador.

Gestión de información del sistema

Este módulo cuenta con la información básica que emplean los demás módulos del sistemas para realizar los cálculos oportunos como en el caso del módulo de liquidación; en este se ve representados el Índice de Precio al Consumo (IPC), la Tasa de Interés (DTF), el Salario Mínimo Legal (SML) con las sumas fijas según corresponda a las fechas comprendidas en la ley y las entidades previsoras y empleadoras.

Consulta de entidades

La funcionalidad relacionada con las entidades de previsión muestra los registros realizados con anterioridad para su uso en otras funcionalidades del sistema (como la asignación del dato en la historia laboral del pensionado).

Registro y consulta del Índice de Precio del Consumidor (IPC)

La funcionalidad relacionada al registro de Índice de Precios al Consumidor despliega la información de los IPC registrados con anterioridad. Si se desea agregar un nuevo índice, el formulario de registro está disponible para efectuarlo.

Registro y consulta de la Tasa de Interés (DTF)

La funcionalidad relacionada al registro de Tasa de Interés despliega la información de los DTF registrados con anterioridad. Si se desea agregar un nuevo índice, el formulario de registro está disponible para efectuarlo.

Registro y consulta de la Salario Mínimo Legal

La funcionalidad relacionada al registro de Salarios Mínimos despliega la información de los Salarios Mínimos registrados con anterioridad. Si se desea agregar un nuevo registro, el formulario está disponible para efectuarlo.

Gestión de datos básicos del pensionado

Este módulo gestiona la información necesaria para el cálculo de la cuota parte, tal como la información de los días laborados en cada una de las instituciones, el porcentaje de cuota parte de acuerdo a los días laborados en cada una de las organizaciones, el valor de las mesadas, entre otros, todo esto de acuerdo a los lineamientos legales correspondientes a Colombia. Además, también proporciona la opción de ingresar el registro de cuentas de cobro de manera manual, con el fin de tener la información de manera actualizada con respecto a la deuda junto a la opción de registrar los pagos correspondientes.

44

Formulario Registro Interrupción Laboral

Para cada uno de los pensionados, se debe registrar la historia laboral de acuerdo a lo requerimientos del sistema, para ello, se utiliza el Formulario de Registro de Historia Laboral; éste formulario se diligencia una por una las historias laborales, teniendo especial diligencia en las fechas de ingreso y salida de la entidad externa.

Formulario Registro y Consulta de Recaudos/Cuentas de Cobro Registrados

El aplicativo muestra los cobros generados y por pagar con información básica del cobro, adicionalmente, despliega un registro de los pagos realizados con anterioridad y a que cuenta están asignados.

Formulario Registro Concurrencia Aceptada Cuota Parte

Esta funcionalidad está íntimamente vinculada con el Registro de Historial Laboral, ya que define la participación de la entidad dentro de la mesada pensional.

Tabla 9. Modelo de datos inicial Fuente Documentación sistema de cuotas partes TEMIS, Oficina Asesora de Sistemas, 2013.

En la Tabla 9 se puede observar una breve descripción de cada uno de los submódulos que comprende el desarrollo del presente proyecto, por lo cual se debe de tener en especial cuidado que las funcionalidades no se vean alteradas a excepción que se contemplen cambios sobre estos.

En la Figura 7 se muestra el modelo de datos donde se ve las entidades involucradas en la construcción de los módulos anteriormente descritos; a partir de esta base se empieza a desarrollar un análisis, con ayuda del Arquitecto de Base de Datos de la Oficina Asesora de Sistemas (OAS), se observan particularidades en ciertas entidades, las cuales pueden ser adaptadas a los modelos creados para otros esquemas presentes en diferentes sistemas desarrollados, en su mayoría, los que conllevan datos de carácter paramétrico, tal como el consumo de usuarios, organizaciones, entre otros; esto se realiza a partir de la necesidad de centralizar la información existente a nivel de datos y evitar redundancia en la misma.

45

Figura 7. Modelo de datos inicial Fuente Realizado por autor

10.2. Software Dada la baja documentación existente con el cual establecer las bases para realizar únicamente la migración del sistema de cuotas partes de la Universidad Distrital (TEMIS), además del desconocimiento por una gran parte de los miembros de la Oficina Asesora de Sistemas, se vió en la necesidad de realizar un análisis previo con el fin de establecer y validar ciertos aspectos necesarios para generar los módulos paramétricos y de gestión de información (los cuales serán inicialmente los que en este proyecto se migrarán a las tecnologías nuevas en las cuales se desarrollan los sistemas en la OAS) basándose en la documentación existente del sistema de cuotas partes anterior.

Los requerimientos son declaraciones que identifican atributos, capacidades, características y/o cualidades que necesita cumplir un sistema (o un sistema de software) para que tenga valor y utilidad para el usuario. Un análisis adecuado de requerimientos no debe ser visto como una pérdida de tiempo y esfuerzo sino por el contrario es un factor decisivo a la hora de tener proyecto exitoso definido por tiempo y cumplimiento de las expectativas del usuario.

El desarrollo del sistema de cuotas partes anterior, en su versión 1.0, según la documentación existente por cerca del año 2013 nos especifica las partes por las cuales se componen los

46

módulos necesarios que se migrarán en el presente proyecto, por lo cual, se identifican las diferentes entidades y procesos que se requieren mantener y en algunos casos adaptar para implementar la integración de los servicios de las diferentes APIs que se generan en la Oficina Asesora de Sistemas (OAS) con el fin de centralizar la información existente.

Flexibilidad El patrón arquitectónico principal empleado para el sistema es el de cliente - servidor orientado a ambientes Web. Sin embargo, esto no indica que otros tipos de estilos arquitecturales pueden ser utilizados.

La arquitectura debe estar distribuida en capas diferenciadas cuyos elementos sean modulares, o basados en componentes. De tal forma que se encapsulan adecuadamente a los detalles de la puesta en funcionamiento en elementos separados casi independientes.

Tabla 10. Requerimiento de arquitectura en el desarrollo del sistema de cuotas partes. Fuente Documentación sistema de cuotas partes TEMIS, Oficina Asesora de Sistemas, 2013.

El modelo a emplear es de tres capas, siguiendo el patrón que se establece anteriormente, el cual será el cliente-servidor orientado a ambientes Web, dada las ventajas que presentan, tal como lo es la centralización del control (los accesos, recursos) y la integridad de los datos al ser controlados por el servidor, la facilidad de la escalabilidad y el fácil mantenimiento en las diferentes funciones y responsabilidades que se implementan desde cada uno de los diferentes servicios que se implementen sobre el sistema; también se debe tener en cuenta que según los estándares que actualmente se están implementando en la Oficina Asesora de Sistemas, este modelo de diseño de software se acopla según los resultados esperados.

Figura 8. Modelo de tres capas C/S del sistema de cuotas partes planteado.

Fuente realizado por autor.

Como puede observarse en la Figura 8 , el modelo de tres capas se compone de una capa de presentación (donde se presenta la interacción del usuario final), la capa de aplicación (procesa

47

los datos para presentarlos al usuario final o generar las validaciones necesarias antes de almacenarlos) y la capa de datos (almacenan los datos para los servidores de aplicación).

Mantenimiento y facilidad de uso

La arquitectura debe tener en consideración que la solución sea fácil de utilizar y que las tareas asociadas al mantenimiento no sean complejas.

La arquitectura debe de estar distribuida en capas diferenciadas cuyos elementos sean modulares, o basados en componentes, y se deben seguir los estándares de programación impartidos por la Oficina Asesora de Sistemas, lo que permitirá un mantenimiento más rápido y eficiente.

Tabla 11. Requerimiento inicial del sistema cuotas partes, mantenimiento y facilidad de uso. Fuente Documentación sistema de cuotas partes TEMIS, Oficina Asesora de Sistemas, 2013.

Neutralidad del lenguaje y la plataforma

Maximizar la neutralidad de la solución en cuanto al lenguaje de programación y la plataforma de despliegue.

La utilización de estándares abiertos (Servicios Web, Javascript, Golang) son la opción para la construcciones de soluciones.

Tabla 12. Requerimiento inicial del sistema cuotas partes, neutralidad del lenguaje y la plataforma. Fuente Documentación sistema de cuotas partes TEMIS, Oficina Asesora de Sistemas, 2013.

Siguiendo lo anterior, las herramientas a emplear para el desarrollo de la migración a tecnologías nuevas del sistema de cuotas partes comprende el uso de soluciones libre, tal como lo es Angular para el desarrollo de la capa de presentación ( frontend) , Golang para el manejo de la información, la consulta y validación de esta, esencialmente del framework Beego , el cual ofrece una facilidad para la generación de APIs CRUD como se hará mención más adelante y Jenkins como herramienta de despliegue.

● El cliente se basa en la tecnología que proporciona Angular, el cual es un framework para aplicaciones web desarrollado en TypeScript, de código abierto, mantenido por Google, que se utiliza para crear y mantener aplicaciones web de una sola página.

El desarrollo de aplicaciones en Angular para nuevos sistemas en la Oficina Asesora de Sistemas ha realizado múltiples avances, basándose en su mayoría en soluciones rápidas y prácticas que ofrezcan una mayor eficiencia al momento de crear las múltiples soluciones de las cuales se encuentra encargada, como por ejemplo el uso de generadores de códigos basados en angular-generator, el cual se basa en la tecnología anterior de Angular. Para el caso del desarrollo de Angular en versiones posteriores, implementando el lenguaje Typescript se tomó como base el proyecto de Github de akveo/ngx-admin, el cual es una plantilla de un dashboard administrativo para frontend basado en Angular 6+, Bootstrap 4+ y Nebular, el cual proporciona herramientas útiles

48

como distintos mockups de tablas o gráficos para exponer la información al usuario final según se requiera.

Además, la implementación de Nebular, la cual es una librería Angular UI personalizable basada en las especificaciones Eva Design System la cual posee una gran variedad de componentes, como por ejemplo el NbSecurityModule , el cual nos proporciona de una manera ágil la administración de permisos dentro de la aplicación de una manera sencilla como se mostrará más adelante.

● La creación de los APIs requeridos para la generación de los CRUD necesarios en los módulos a migrar del sistema de cuotas partes se basan en el framework BeeGo, el cual como se menciona anteriormente, proporciona una solución ágil y eficaz para el desarrollo de estas.

● La herramienta de despliegue Jenkins es un servidor de automatización open source el cual se encuentra desarrollado en Java; este se encuentra basado en el proyecto Hudson . Esta permite la integración continua además del uso de herramientas de control de versiones, la cual en este caso se emplea Git.

10.2. Arquitectura de datos

Según los nuevos lineamientos que se han establecido para el desarrollo de nuevas aplicaciones por parte de la Oficina Asesora de Sistemas (OAS) dentro de la Universidad Distrital Francisco José de Caldas, se ha buscado la centralización de la información que pueda ser posible, con el fin de eliminar la redundancia de datos presentes en los diferentes sistemas que maneja, por lo cual se han creado múltiples repositorios de consulta con la información de cada uno de los servicios que componen distintos modelos de datos que se han creado a disposición de los diferentes grupos de trabajo que se encuentren en la oficina, con el cual se busca un trabajo cooperativo entre los integrantes de los diferentes grupos de trabajo.

10.2.1. Modelo de datos

Para el desarrollo del siguiente proyecto se utiliza un modelo de datos relacional.

49

Figura 9. Modelo de datos en módulos paramétricos y de gestión de datos.

Fuente Realizado por autor

50

A continuación se describen las características que componen cada una de las tablas empleadas dentro del modelo de datos, para el almacenamiento y gestión de información referente a los módulos de parametrización y gestión de información referentes al sistema de cuotas partes TEMIS de la Universidad Distrital Francisco José de Caldas; cabe resaltar que en su mayoría la gestión de la información de los módulos a migrar ya existen, por lo cual no se expondrá los modelos de datos que se han creado para el consumo de servicios hacia otros sistemas generados en la Oficina Asesora de Sistemas, sino únicamente los que se han creado para el desarrollo del siguiente proyecto.

10.2.1.1. Módulo paramétrico

A. indice_precio_consumidor

Esquema: Core Descripción: Esta funcionalidad permite la gestión de información de los datos relacionados al Índice de Precio al Consumidor (IPC), donde se lleva el registro cronológico de los datos.

Columna Tipo pk fk uk null

Descripcción

id integer x Llave primaria de la tabla indice_precio_consumidor

ano_vigencia date Fecha de vigencia en el cual hace efecto el valor IPC.

indice_ipc double precision

(Factor) Valor otorgado al IPC en la fecha descrita anteriormente.

Tabla 13. Descripción de la tabla indice_precio_consumidor. Fuente Realizado por autor

B. dtf

Esquema: Core Descripción: Esta funcionalidad permite la gestión de información de los datos relacionados a la Tasa de Interés (DTF), donde se lleva el registro cronológico de los datos.

Columna Tipo pk fk uk null

Descripcción

id integer x Llave primaria de la tabla registrar_monto_aceptado_por_cobrar

51

norma text Tipo de norma por la cual se establece para las fechas dadas el índice de tasa de interés.

numero_norma text Número del registro de la norma realizada.

fecha_inicio_vigencia date Fecha desde la cual se aplica el DTF descrito.

fecha_finalizacion_vigencia date Fecha hasta la cual se aplica el DTF descrito.

tasa_interes double precision

(Factor) Valor otorgado al DTF en la fecha descrita anteriormente.

Tabla 14. Descripción de la tabla dtf. Fuente Realizado por autor

10.2.1.2. Módulo de gestión de información

C. registrar_monto_aceptado_por_cobrar

Esquema: Monto_aceptado Descripción: Esta funcionalidad está relacionada con el registro de la historia laboral del pensionado, ya que define la participación de la organización dentro de la mesada pensional.

Columna Tipo pk fk uk null

Descripcción

id integer x Llave primaria de la tabla registrar_monto_aceptado_por_cobrar

experiencia_laboral_id integer x Identificador de la relación con la tabla experiencia laboral a la cual hace referencia el monto aceptado por la organización

fecha_pension date Fecha desde donde empieza a efectuarse el cobro de pensión.

fecha_resolucion_pension date Fecha de generación del soporte de vigencia de la pensión.

52

valor_mesada_pension integer Monto a pagar por concepto de la pensión.

cuota_aceptada_organizacion integer Mesada pensional aceptada a cubrir por parte de la organización.

tipo_acto_administrativo text Soporte de la mesada pensional aceptada con la Universidad frente a la organización.

fecha_acto_administrativo date Fecha de generación del soporte.

Tabla 15. Modelo de datos tabla registrar_monto_aceptado_por_cobrar del schema monto_aceptado. Fuente Realizado por autor

D. registrar_recaudo

Esquema: Monto_aceptado Descripción: Esta funcionalidad genera el registro de los cobros efectuados a la organización frente a su participación en la mesada pensional.organización frente a su participación en la mesada pensional.organización frente a su participación en la mesada pensional.

Columna Tipo pk fk uk null

Descripcción

id integer x Llave primaria de la tabla registrar_recaudo

resolucion_orden_pago text Soporte de la orden de pago generada por concepto a la cuota parte del monto aceptado.

fecha_resolucion_orden_pago date Fecha de generación del soporte de la orden de pago.

consecutivo_cuenta_cobro text Número de registro de la cuenta de cobro generada por concepto de la cuota parte.

valor_cuenta_cobro integer Monto a pagar por parte de la organización por concepto de la cuota parte.

53

fecha_desde_pago date Fecha inicial del pago oportuno de la cuota parte.

fecha_hasta_pago date Fecha máxima del pago oportuno de la cuota parte.

observaciones_pago text Comentarios sobre el pago de la cuota parte.

registrar_monto_aceptado_por_cobrar_id

integer x Identificador de la relación con la tabla registrar_monto_aceptado_por_cobrar

Tabla 16. Descripción de la tabla registrar recaudo. Fuente Realizado por autor

10.2.1.3. Modelo de datos externos utilizados

Para el desarrollo del presente proyecto, se empleados diferentes tablas del modelo de base de datos generados para el desarrollo de diferentes sistemas por parte de la Oficina Asesora de Sistemas (OAS); a continuación se exponen de manera breve las entidades existentes empleadas.

● cargo Esquema: Core Descripción: Esta tabla permite almacenar los diferentes cargos almacenados para el uso en la experiencia laboral de una persona.

● dato_adicional_experiencia_laboral Esquema: Core Descripción: Relaciona datos adicionales que puedan ser relevantes para la experiencia laboral de una persona.

● ente Esquema: Core Descripción: Esta tabla relaciona las tablas de personas y organización, con datos más específicos, propios de estos elementos, tal como la identificación, contacto, género, entre otros.

● experiencia_laboral Esquema: Agora Descripción: Esta tabla permite el registro de las historias laborales asociadas a una persona, donde relaciona diferentes organizaciones con una persona.

● identificacion Esquema: Core

54

Descripción: Permite obtener la información relacionada a la identificación de un ente.

● organizacion Esquema: Agora Descripción: Esta tabla permite el registro de una organización, además de relacionarlo con un ente para añadir las características de esta.

● persona Esquema: Agora Descripción: Esta tabla permite el registro de una persona, además de relacionarlo con un ente para añadir las características de esta.

● relacion_organizaciones Esquema: Core Descripción: Permite generar una relación entre dos diferentes organizaciones, una organización padre - hijo.

● salario_minimo_legal Esquema: Core Descripción: Permite obtener la información relacionada al salario mínimo legal almacenados cronológicamente.

● tipo_dedicacion Esquema: Core Descripción: Permite obtener la información de los tipos de dedicación válidos para el registro en la experiencia laboral.

● tipo_ente Esquema: Core Descripción: Permite discriminar por un tipo a los diferentes entes que se registran en el sistema.

● tipo_identificacion Esquema: Core Descripción: Permite discriminar por un tipo las diferentes identificaciones asociadas a un ente.

● tipo_organizacion Esquema: Core Descripción: Permite discriminar por un tipo las diferentes organizaciones registradas en el sistema.

● tipo_relacion_organizaciones Descripción: Permite discriminar por un tipo las diferentes relaciones que asocian a dos organizaciones.

55

● tipo_vinculacion Esquema: Core Descripción: Permite obtener la información de los tipos de vinculación que puede tener asociados una persona en el registro de la experiencia laboral.

10.3. Desarrollo de la aplicación

Figura 10. Diagrama de componentes para el sistema de gestión de cuotas partes TEMIS de la Universidad Distrital.

Fuente Realizado por autor

La Figura 10 expone el diagrama de componentes del sistema de gestión de cuotas partes TEMIS para los módulos de parametrización y gestión de información elaborados en el siguiente proyecto, donde se representa la división que se expone en el sistema por medio de componentes, tal como la base de datos o el cliente del usuario, y grafica las dependencia que existen entre estos.

56

Por lo anterior, se puede ver una representación gráfica de la relación que existe entre lo diferentes componentes que construyen la agrupación del módulo paramétrico, el cual contiene los diferentes servicios de crud que consume el sistema inicialmente para obtener información con la cual se construirán los diferentes módulos del sistema, en este caso, la relación va directamente con la agrupación del módulo de gestión de información.

Figura 11. WSO2 API Store. Fuente Realizado por autor

Cada uno de los servicios que se consumen se localizan en el API Manager Store WSO2, la cual es una aplicación Web que aloja API publicadas, esta proporciona un GUI estructurada, diseñada para que los usuarios de API puedan realizar búsquedas y evaluar los recursos disponibles; todo esto se realiza a través del API Manager WSO2 el cual es una solución de código abierto para el desarrollo, la integración y la gestión completa del ciclo de vida de una API, la cual permite su extensibilidad y personalización; además aprovecha los componentes probados de la plataforma WSO2 para asegurar, integrar y administrar las API.

A continuación se exponen los servicios que publicados actualmente en el API Manager Store WSO2 que se utilizarán para el desarrollo del presente proyecto:

A. persona_crud

Permite gestionar servicios de funciones básicas ( create, read, update y delete ) sobre los datos de la aplicación que conciernen a los usuarios empleados en diferentes sistemas desarrollados en la OAS, tal como agora o argo, donde se gestionan como por ejemplo datos de contratos. Dentro de este servicio se encuentra alojados los microservicios que permiten la gestión de los siguientes datos de las personas:

57

Servicio Descripción

estado_civil Contiene la información descriptiva de los posibles valores que puede tomar un estado civil asociado a una persona.

genero Contiene la información descriptiva de los posibles valores que puede tomar el género asociado a una persona.

persona Contiene la información básica que se encuentra asociada a una persona registrada en el sistema, tal como sus nombres, apellidos y fecha de nacimiento.

persona_estado_civil Contiene la información de la relaciones que existen entre un estado civil y una persona, con el fin de crear un registro para esta.

persona_genero Contiene la información de la relaciones que existen entre un género y una persona, con el fin de crear un registro para esta.

Tabla 17. Descripción del API persona_crud del API Store. Fuente Realizado por autor

B. ente_crud

Permite gestionar servicios de funciones básicas ( create, read, update y delete ) sobre los datos de la aplicación que conciernen a un ente, lo cual representa una abstracción de las entidades (personas u organizaciones) que se pueden encontrar dentro de los diferentes sistemas, los cuales pueden compartir semánticamente algunos tipos de información (ej. Una persona y organización pueden contener un número de contacto). Dentro de este servicio se encuentra alojados los microservicios que permiten la gestión de los siguientes datos de las personas:

Servicio Descripción

ente Contiene la información descriptiva de los posibles valores que puede tomar un ente.

identificacion Contiene la información de la relaciones que existen entre un tipo de identificación y un ente, con el fin de crear un registro para esta, además incluye el valor que será asignado.

tipo_identificacion Contiene la información descriptiva de los posibles valores que puede tomar una identificación asociado a

58

un ente.

Tabla 18. Descripción del API ente_crud del API Store. Fuente Realizado por autor

C. organizacion_crud

Permite gestionar servicios de funciones básicas ( create, read, update y delete ) sobre los datos de la aplicación que conciernen a las organizaciones que se pueden encontrar dentro de los diferentes sistemas. Dentro de este servicio se encuentra alojados los microservicios que permiten la gestión de los siguientes datos de las organizaciones:

Servicio Descripción

tipo_organizacion Contiene la información descriptiva de la tipificación que puede ser asignada a una organización.

tipo_relacion_organizaciones Contiene la información descriptiva la tipificación creada para la relación que puede existir entre dos organizaciones diferentes.

relacion_organizaciones Contiene la información de la asociación de una organización padre-hijo, además de añadir un tipo de relación.

organizacion Contiene la información básica de la organización como el nombre y el tipo, además del ente al cual se encuentra asociado.

Tabla 19. Descripción del API organizacion_crud del API Store. Fuente Realizado por autor

D. experiencia_laboral_crud

Permite gestionar servicios de funciones básicas ( create, read, update y delete ) sobre los datos de la aplicación que conciernen a la diferentes interacciones que se han presentado entre una persona y organizaciones, más específicamente representa una abstracción de lo que es la historia laboral de un usuario. Dentro de este servicio se encuentra alojados los microservicios que permiten la gestión de los siguientes datos de la historia laboral de las personas:

Servicio Descripción

tipo_dedicacion Contiene la información descriptiva de los posibles valores que puede tomar una dedicación asociada a una experiencia laboral.

cargo Contiene la información descriptiva de los posibles

59

valores que puede tomar un cargo asociado a una experiencia laboral.

dato_adicional_experiencia_laboral Contiene la información adicional que se desee registrar a una experiencia laboral.

tipo_vinculacion Contiene la información descriptiva de los posibles valores que puede tomar una vinculación asociada a una experiencia laboral.

experiencia_laboral Contiene la información básica que se encuentra asociada a la experiencia laboral registrada en el sistema, tal como sus la organización, la persona, las fechas de inicio y finalización, el cargo y tipo de vinculación.

Tabla 20. Descripción del API experiencia_laboral_crud del API Store. Fuente Realizado por autor

E. temis_monto_aceptado_crud

Permite gestionar servicios de funciones básicas ( create, read, update y delete ) sobre los datos de la aplicación que conciernen al registro de los diferentes montos aceptados por las organizaciones a cuestión de las cuotas partes generadas, además también del registro de los recaudos que se generaron a favor de la Universidad Distrital por concepto de estas. Dentro de este servicio se encuentra alojados los microservicios que permiten la gestión la información básica del registro de las cuotas partes:

Servicio Descripción

registrar_monto_aceptado_por_cobrar Contiene la información de los montos aceptados por concepto de la cuota parte aceptada por la organización asociada al periodo comprendido dentro de la experiencia laboral de la persona asociada.

registrar_recaudo Contiene la información de los múltiples registros por concepto de los diferentes pagos realizados a causa de la cuota parte aceptada.

Tabla 21. Descripción del API temis_monto_aceptado_crud. Fuente Realizado por autor

60

Figura 12. Schema monto_aceptado que gestiona el servicio temis_monto_aceptado_crud.

Fuente Realizado por autor

En la Figura 12 se puede observar el schema de la base de datos creado para representar el microservicio generado para la gestión del monto aceptado por concepto de la cuota parte.

Figura 13. Modelos del servicio temis_monto_aceptado_crud.

Fuente Realizado por autor

En la Figura 13 se encuentra los modelos que comprenden el servicio de temis_monto_aceptado_crud , el cual se genera para la gestión del monto aceptado por concepto de la cuota parte.

Este servicio se debió de crear desde su inicio a causa de que no existe para ninguno de los sistemas creados en la Oficina Asesora de Sistemas, lo cual conllevo a realizar un análisis para adaptar la información que se requiere con los demás servicios que se podían adaptar de manera óptima en la migración; cabe resaltar que lo anterior se realiza con el fin centralizar la

61

información que existe entre los diversos sistemas creados, con el fin de evitar la redundancia de datos en diferentes sistemas.

10.3.1. Autenticación El aplicativo maneja un sistema de autenticación como se ha hecho mención anteriormente, este valida los datos del usuario para habilitar ciertas acciones, actualmente se posee dos tipos de usuarios: Invitado y Administrador, para el primer caso, el usuario podrá realizar la navegación normal dentro del sistema pero no tendrá acceso a los formularios de edición ni a las opciones de eliminar registros; el usuario Administrador podrá acceder tanto a las vistas como realizar las acciones que considere sobre cada uno de los registros en las diferentes vistas que puede encontrar dentro del sistema (crear, editar, eliminar).

Figura 14. Configuración básica del temis_cliente dentro del app.conf.js.

Fuente Realizado por autor

62

La configuración de todo el sistema se da en el archivo app-config , en este se encontrará los endpoint de todos los servicios los cuales son necesarios para realizar cada una de las acciones, por lo tanto es de gran importancia la correcta configuración dado el ambiente que se esté ejecutando; además también se encontrará con la configuración e información necesaria para realizar la autenticación por medio del oauth2 WSO2 , el cual requiere parámetros necesarios dentro de la cabecera y la ruta enviada para comprobar inicialmente que se realizará la validación desde alguno de los sistemas desarrollados por la Oficina Asesora de Sistemas que implementen este tipo de autenticación.

Figura 15. Parámetros enviados para la autenticación por el servicio oauth2 WSO2 . Fuente Realizado por autor

Como se puede observar en la Figura 15 , existen parámetros que se envían al servicio de autenticación desarrollado, entre los cuales el cliente_id , response_type, scope, redirect_url pertenecen a la configuración dentro del campo TOKEN en la configuración dentro del app-config .

Figura 16. Cabecera de la petición al servicio de autenticación. Fuente Realizado por autor

63

Además, según la Figura 16 también se puede observar como dentro de la cabecera también se incluye información que se debe de configurar de manera adecuada dentro del app-config .

Figura 17. LocalStorage generado según los datos otorgados por el servicio de autenticación. Fuente Realizado por autor

Si la autenticación es exitosa, se redirige el sistema a la página que se haya configurado en el app-config en la propiedad TOKEN.REDIRECT_URL, dato que se pasa en los parámetros de la petición al momento de ingresar al formulario de autenticación; además, el sistema guardará dentro del localStorage del navegador la información que se retorna, tal como se puede observar en la Figura 17 . Se debe tener en cuenta que el localStorage es una propiedad que accede al objeto Storage donde se almacena información hasta que se limpien los datos del navegador; en el caso del localStorage, estos datos se mantienen durante el tiempo de que dure la conexión, por lo tanto, esta información presenta persistencia entre diferentes tabs o ventanas que se abran del navegador donde se realizó la conexión.

10.3.2. Seguridad Como se menciona anteriormente, el template ngx-admin implementa Nebular, el cual nos proporciona un componente básico que permite la administración del control de acceso a las diferentes funcionalidades o vistas que se puedan crear dentro del sistema; NbSecurityModule nos proporciona las siguientes opciones:

● Configuración de roles / permisos / recursos de ACL. ● RoleProvider - Determina el rol del usuario, autenticación independiente. ● NbAccessChecker - Servicio que verifica si se concede o no el acceso. ● * nbIsGranted - Directiva condicional para la administrar la visibilidad del contenido.

Este componente viene de manera predeterminada incluida dentro de la plantilla de ngx-admin por lo cual basta con importar el módulo desde alguno de los archivos de configuración dentro del sistema donde se vaya a generar los permisos por roles.

Los roles del usuario se encuentran por medio de la información que nos retorna la autenticación y se encuentra guardado en el localStorage dentro del id_token, donde encontraremos el JWT ( Json Web Token ); este es un estándar abierto basado en JSON para la creación de tokens de acceso que permiten la propagación de identidad y privilegios, los JWT

64

están diseñados para poder enviarse a través de URLs y ser utilizados en escenarios de Single Sign-On (SSO).

Figura 18. JWT token decodificado con la información del usuario. Fuente Realizado por autor

En la Figura 18 se puede observar la información que se encuentra codificada dentro del JSON WEB TOKEN (JWT) que retorna el servicio de autenticación, el cual contiene la información de los roles asociados al usuario (en este caso se emplea un usuario de prueba genérico en los sistemas desarrollados en la Oficina Asesora de Sistemas), además de información única de la sesión como el tiempo de conexión dentro del campo exp.

Con la información de los roles asociados al usuario, dentro del archivo core.module, se crea la configuración del ACL (Access Control List), donde se configura el permiso para por defecto para view, create, delete y edit (las cuales son las acciones que se presentan en la mayoría de vistas) para el usuario con rol Admin y en caso de ser un Invitado (guest), podrá acceder a la información de los listados.

65

Figura 19. Configuración de los permisos dentro del componente NbSecuriy de Nebular.

Fuente Realizado por autor

La configuración que se visualiza en la Figura 19, es la que se menciona anteriormente, pero para aplicar funcionalmente los permisos otorgados, Nebular ACL nos proporciona dos opciones de realizarlas, la primera es por medio de la directiva propia isGranted , la cual basta con proporcionarle el rol actual para que evalúe si el usuario tiene los permisos para realizar la acción en cuestión o el acceso a la vista, por último, también lo permite evaluar por medio del servicio NbAccessChecker , el cual funciona de una manera similar a la directiva.

Con lo anterior se genera los permisos básicos que se aplicarán a los módulos de gestión de información y paramétricos para los roles Admin y guest, sobre las acciones que un usuario puede realizar en las vistas de listados de información.

10.3.3. Módulo paramétrico El módulo paramétrico en su mayoría reutiliza información que se ha empleado en diferentes sistemas desarrollados en la Oficina Asesora de Sistemas, por lo cual no se requiere más que realizar la consulta para la visualización de la información que se encuentra almacenada.

El módulo paramétrico se compone de la siguiente información:

66

10.3.3.1. Organización

Figura 20. Resultado obtenido de la vista de organizaciones.

Fuente Realizado por autor

En la Figura 20 se visualiza el listado de las organizaciones que se encuentran dentro del API organizacion_crud el cual proporciona como se explica más arriba los diferentes servicios que componen la información asociada a las organizaciones empleadas en los sistemas desarrollados por la Oficina Asesora de Sistemas, además, como se puede ver dentro de la Figura x cada organización contiene una tipificación dada en el tipo de organización, donde el sistema de cuotas partes TEMIS solo hará uso de las organizaciones que posean el tipo de organización de sucesora o previsora.

Dado que los datos se encuentran considerado dentro de los diferentes sistemas generados en la Oficina Asesora de Sistemas, no se requiere la generación de formularios de creación.

10.3.3.1. IPC

En la Figura 21 se visualiza el histórico del índice de precio al consumidor (IPC) que se encuentran registrados en el sistema (el cual se explica más arriba el cómo se compone); además, cada uno de los registros permite la ejecución de acciones como editar y eliminar, los cuales solo podrá realizar un usuario autenticado con el rol Admin , de lo contrario no aparecerá ninguna de las acciones sobre los registros.

67

Figura 21. Resultado obtenido de la vista de índice de precio de consumo (IPC).

Fuente Realizado por autor

También permite la creación de un nuevo registro, para el caso de esta opción se redirige al usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.

Figura 22. Resultado obtenido para el formulario de registro de IPC.

Fuente Realizado por autor

En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.

Finalmente la acción de eliminar permitirá borrar el registro seleccionado.

68

10.3.3.1. DTF

En la Figura 23 se visualiza el histórico de la tasa de interés (DTF) que se encuentran registrados en el sistema (el cual se explica más arriba el cómo se compone); además, cada uno de los registros permite la ejecución de acciones como editar y eliminar, los cuales solo podrá realizar un usuario autenticado con el rol Admin , de lo contrario no aparecerá ninguna de las acciones sobre los registros.

Figura 23. Resultado de la vista de listado de registros de tasa de interés (DTF).

Fuente Realizado por autor

También permite la creación de un nuevo registro, para el caso de esta opción se redirige al usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.

69

Figura 24. Resultado obtenido para el formulario de registro de DTF.

Fuente Realizado por autor

En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.

Finalmente la acción de eliminar permitirá borrar el registro seleccionado.

70

10.3.3.1. Salario mínimo legal

Figura 25. Resultado obtenido de la vista de listado de salario mínimo legal (SML).

Fuente Realizado por autor

En la Figura 25 se visualiza el histórico de los salarios mínimos legales que se encuentran registrados en el sistema (el cual se explica más arriba el cómo se compone); además, cada uno de los registros permite la ejecución de acciones como editar y eliminar, los cuales solo podrá realizar un usuario autenticado con el rol Admin , de lo contrario no aparecerá ninguna de las acciones sobre los registros.

También permite la creación de un nuevo registro, para el caso de esta opción se redirige al usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.

71

Figura 26. Resultado obtenido para la vista del formulario de registro de SML.

Fuente Realizado por autor

En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.

Finalmente la acción de eliminar permitirá borrar el registro seleccionado.

10.3.4. Módulo de gestión de información El módulo de gestión de información se compone de la siguiente información:

10.3.4.1. Pensionados

72

Figura 27. Resultado obtenido para la vista del listado de pensionados. Fuente Realizado por autor

En la Figura 27 se visualiza el listado de usuarios registrados en el sistema tipificados como pensionados (el cual se explica más arriba el cómo se compone); además, cada uno de los registros permite la ejecución de la acción de Experiencia Laboral, la cual redirecciona al usuario a la información registrada de la historia laboral que contempla el usuario dentro del sistema.

10.3.4.2. Experiencia Laboral

Figura 28. Resultado obtenido para la vista del listado de experiencia laboral asociada a un pensionado.

Fuente Realizado por autor

En la Figura 28 se visualiza el listado de la historia laboral registrados en el sistema asociados al pensionado seleccionado (el cual se explica más arriba el cómo se compone), la información del mismo como nombres y apellidos se muestra en la parte superior de la tabla, con el fin de que el usuario realice de manera adecuada el seguimiento a la visualización de la historia laboral; además, cada uno de los registros permite la ejecución de la acción de Experiencia Laboral, la cual redirecciona al usuario a la información registrada de la historia laboral que contempla el usuario dentro del sistema.

73

Figura 29. Resultado obtenido para la vista del formulario de experiencia laboral asociada al pensionado.

Fuente Realizado por autor

También permite la creación de un nuevo registro, para el caso de esta opción se redirige al usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.

En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.

74

La acción de eliminar permitirá borrar el registro seleccionado.

Finalmente la acción de monto a cobrar redirigirá al usuario al listado registrado que pertenece al monto aceptado por la organización por concepto de la cuota parte generada a causa de la pensión de la persona asociada.

10.3.4.3. Monto aceptado

Figura 30. Resultado obtenido para la vista del listado de monto aceptado por concepto de la cuota parte asociada a

la experiencia laboral de un pensionado.. Fuente Realizado por autor

En la Figura 30 se visualiza el listado de los diferentes montos aceptados que puedan presentarse en el sistema asociados al pensionado seleccionado y la organización en cuestión teniendo en cuenta el periodo comprendido en las fechas (el cual se explica más arriba el cómo se compone), la información del mismo como nombres y apellidos se muestra en la parte superior de la tabla, con el fin de que el usuario realice de manera adecuada el seguimiento a la visualización de la historia laboral; además, cada uno de los registros permite la ejecución de la acción de Experiencia Laboral, la cual redirecciona al usuario a la información registrada de la historia laboral que contempla el usuario dentro del sistema.

75

Figura 31. Resultado para la vista del formulario del registro de un monto aceptado. Fuente Realizado por autor

También permite la creación de un nuevo registro, para el caso de esta opción se redirige al usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.

En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.

76

Figura 32. Diagrama de secuencia para el registro de un nuevo monto aceptado.

Fuente Realizado por autor

La acción de eliminar permitirá borrar el registro seleccionado.

Finalmente la acción de monto a cobrar redirigirá al usuario al listado registrado que pertenece al monto aceptado por la organización por concepto de la cuota parte generada a causa de la pensión de la persona asociada.

77

10.3.4.4. Cobro registrado

Figura 33. Resultado obtenido para la vista del listado de cobros registrados según el monto aceptado.

Fuente Realizado por autor

En la Figura 33 se visualiza el listado de la historia laboral registrados en el sistema asociados al pensionado seleccionado (el cual se explica más arriba el cómo se compone), la información del mismo como nombres y apellidos se muestra en la parte superior de la tabla, con el fin de que el usuario realice de manera adecuada el seguimiento a la visualización de la historia laboral; además, cada uno de los registros permite la ejecución de la acción de Experiencia Laboral, la cual redirecciona al usuario a la información registrada de la historia laboral que contempla el usuario dentro del sistema.

También permite la creación de un nuevo registro, para el caso de esta opción se redirige al usuario al formulario de edición, donde se deberá de completar los campos requeridos por el sistema con el fin de que se pueda guardar el registro.

78

Figura 34. Diagrama de secuencia para el registro de un nuevo cobro registrado en el sistema.

Fuente Realizado por autor

En el caso de editar un registro, se redirigirá al usuario al formulario correspondiente (el cual es el mismo de creación) donde se cargaran los datos del mismo, con el fin de cambiarlos en caso de que el usuario así lo desee.

La acción de eliminar permitirá borrar el registro seleccionado.

Finalmente la acción de monto a cobrar redirigirá al usuario al listado registrado que pertenece al monto aceptado por la organización por concepto de la cuota parte generada a causa de la pensión de la persona asociada.

79

10.4. Pruebas

Con el fin de validar el funcionamiento adecuado del presente desarrollo realizado en este proyecto, se realizaron pruebas a nivel local con una herramienta de inspección de código, para este caso se empleó el uso de SonarQube, el cual es una herramienta automatizada para evaluar código fuente, la cual detecta bugs, vulnerabilidades y code smells (indican      deficiencias en el diseño que puede ralentizar el desarrollo o aumentan el riesgo de errores                             o fallos en el futuro). Es software libre y usa diversas herramientas de análisis estático de        código fuente como Checkstyle, PMD o FindBugs para obtener métricas que pueden ayudar a mejorar la calidad del código de un programa.

Para la instalación del entorno de SonarQube se emplea un docker, el cual es una tecnología de código abierto de creación de contenedores que automatiza el despliegue de aplicaciones de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones en múltiples sistemas operativos; para realizar la instalación básica de docker basta con dirigirse a la página principal https://www.docker.com/get-started donde se encuentra el link de descarga del archivo ejecutable con la instalación.

Figura 35. Instalación y ejecución en consola del docker de sonarqube.

Fuente Realizado por autor

En la Figura 35 se puede observar la línea de comando que debe de ejecutarse después de verificar que la instalación de docker se realizó correctamente; estas líneas permiten descargar el contenedor con el entorno de SonarQube de una manera práctica, además de su ejecución en el puerto 0.0.0.0:9000 donde podremos acceder por medio de nuestro navegador.

Figura 36. Resultado obtenido al ejecutar el servicio de sonarqube localmente.

Fuente Realizado por autor

Para el caso de encontrarse el contenedor con sonarqube descargado de manera previa en nuestro sistema, docker le informará al usuario que no puede ejecutarse la última línea dado que ya existe un daemon con el mismo nombre, con lo cual bastará con ejecutar el nombre de

80

nuestro daemon del contenedor de nuestro sonarqube el cual permitirá ejecutarlo e iniciará el proceso como se puede observar en la Figura 36, donde al finalizar la ejecución, nos informará que el contenedor se encuentra arriba ( SonarQube is up ). Desde nuestro proyecto (temis_cliente) se debe de configurar el script para poder realizar la inspección de nuestro código, donde inicialmente debemos de instalar por medio de npm las librerías correspondientes como se visualiza en la Figura 37 o simplemente desde nuestro package.json el cual se encontrará en el root del proyecto añadir las librerías y ejecutar el comando npm install desde la consola en la carpeta del proyecto.

Figura 37. Instalación por medio de npm de las dependencias para ejecutar sonar dentro del proyecto.

Fuente Realizado por autor

A continuación se debe de configurar el karma.conf.js desde el root del proyecto, añadiendo las siguientes líneas como se puede ver en la siguiente imagen:

Figura 38. Configuración del karma.config.js para la ejecución del sonar.

Fuente Realizado por autor

Y desde nuestro angular.json se debe de añadir desde el atributo options lo siguiente:

Figura 39. Configuración del angular.js para la ejecución del sonar.

Fuente Realizado por autor

Además, desde nuestro package.json debe de añadirse el script que se ejecutará para realizar el análisis de nuestro código añadiendo desde el atributo scripts del mismo lo siguiente:

Figura 40. Creación del script para la ejecución del sonar por medio de npm.

Fuente Realizado por autor

81

Finalmente, basta con configurar nuestro archivo de propiedades del sonar, el cual debe de crearse en el root del proyecto con el nombre de sonar-project.properties, el cual será el archivo que buscará de manera automática el script configurado, proporcionando la información necesaria que requiere para ejecutarse el inspector de código, tal como se ve a continuación:

Figura 41. Configuración del archivo sonar-project.properties para la ejecución del sonar.

Fuente Realizado por autor

Donde se puede observar que se excluye la carpeta que contiene las librerías instaladas por medio del npm (node_modules), además de generar un nombre con el cual podremos realizar la consulta en el servicio de SonarQube desde el puerto configurado (9000 por defecto) y la carpeta de nuestro proyecto (para este caso se examina la **app/pages/** ). Con la anterior configuración realizada sobre nuestro proyecto podremos proceder a ejecutar nuestro script configurado: npm run sonar.

Figura 42. Resultado obtenido al ejecutar el npm run sonar dentro del proyecto temis_cliente.

Fuente Realizado por autor

Se ejecutará la inspección del código como se puede observar en la Figura 42 , el cual generará un archivo al finalizar el proceso, el cual podremos consultar previamente desde el servicio en nuestro contenedor con los resultados obtenidos de la inspección.

82

Figura 43. Resultados obtenidos por la inspección sobre el código fuente de temis_cliente.

Fuente Realizado por autor

Los resultados que nos proporciona esta herramienta son bastante gráficos, donde nos permite la visualización de los diferentes resultados obtenidos de cada una de los parámetros que inspecciona de manera automática sobre nuestro código.

Figura 44. Resultados obtenidos visualizados por las carpetas que componen el proyecto dentro de app/pages. Fuente Realizado por autor

83

Figura 45. Ejemplo de resultado obtenido según la inspección del código fuente.

Fuente Realizado por autor

Los detalles que nos proporciona el SonarQube son bastante específicos, indicandonos la línea de código que presenta la molestia como se observa en la Figura x, además de indicarnos cual es el tipo de error que puede identificar como se observa a continuación:

Figura 46. Ejemplo de resultado de code smell obtenido en la inspección de código.

Fuente Realizado por autor

Figura 47. Ejemplo de resultados de bugs dentro del código obtenido en la inspección.

84

Fuente Realizado por autor

Figura 48. Ejemplo de bug resaltado por el servicio de SonarQube.

Fuente Realizado por autor

Figura 49. Ejemplo de vulnerabilidades que el sonar encontró en la inspección del código fuente.

Fuente Realizado por autor

Figura 50. Ejemplo de los code smell encontrados después de la inspección del código fuente.

Fuente Realizado por autor

85

11. Conclusiones

Implementación de los servicios que se presentan en los nuevos desarrollos que se generan en la Oficina Asesora de Sistemas, entre los más relevantes se hace el uso de un servicio genérico para la autenticación de usuarios dentro del sistema, lo cual combinado con los componentes de seguridad que proporciona la librería de Nebular , la cual permite una gestión sobre las funcionalidades del sistema sobre los diferentes usuarios que puedan ingresar..

Se destaca que dentro del desarrollo generado dentro del actual proyecto se implementa el consumo de servicios que se implementan en diferentes sistemas, dada que la información es genérica, lo cual permite hacer una centralización de datos, todo por medio del consumo de servicios de las APIs que se encuentran en el repositorio de WSO2 API Store, tal como los datos de personas, registros de experiencias laborales y datos paramétricos como lo son el IPC, DTF, organizaciones e históricos del salario mínimo legal, que son implementados dentro del sistema de cuotas partes pero que son necesarios también para algunos sistemas e incluso nuevos posibles desarrollos que puedan existir dentro de la dependencia.

La implementación del inspector de código de SonarQube para generar informes del estado del código fuente, además, de ser sencillo de implementar, presenta resultados sobre diferentes errores que pueden presentarse y pasarse por alto durante el desarrollo, los cuales, al prevenirse desde cada una de las etapas del desarrollo (sprints) genera un código amigable para la implementación de los otros módulos que componen este sistema y sirven como prevención de posibles errores o inconsistencias que se puedan presentar más adelante. Finalmente, la implementación de diferentes conceptos durante el desarrollo del presente proyecto proporcionaron conocimientos en diferentes campos, tal como el uso de metodologías ágiles, el modelado de datos, el uso de bases de datos relacionales (PG), el uso de frameworks de libre uso como lo son Beego y Angular, además de la plantilla de administración ngx-admin y el manejo de autenticación de usuarios por medio del uso del framework AuthO2 por medio de token con JWT, implementando el LocalStorage para guardar los datos de sesión del usuario.

86

12. Trabajos futuros

Basándose en el presente proyecto se obtiene la base inicial para poder migrar todo el sistema de cuotas partes ( TEMIS) a las nuevas tecnologías que se han implementado en la Oficina Asesora de Sistemas , dado que existen aún diferentes módulos a los cuales no se han realizado este proceso actualmente, aparte de ser de importancia, pues este sistema es uno de los cuales se encuentra separado actualmente de todos los sistemas generados. También se incluye la posibilidad de extender algunas funcionalidades dada las posibilidades que permiten las nuevas tecnologías implementadas, tal como la implementación global dentro de los diferentes módulos del componente de seguridad que proporciona Nebular, el cual puede bloquear vistas o funcionalidades según el rol obtenido por medio del JWT generado al momento de iniciar sesión dentro del sistema, lo cual existen las bases ya dentro del presente proyecto.

87

CAPÍTULO 13. BIBLIOGRAFÍA

[1] Ley 6 de 1945 de febrero 19, Congreso de Colombia. Disponible en http://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=1167

[2] Ley 100 de 1993, Diario Oficial No. 41.148 del 23 de diciembre de 1993. Artículo 36, régimen de transición. Disponible en http://www.secretariasenado.gov.co/senado/basedoc/ley_0100_1993.html

[3] Ley 797 de 2003 de enero de 2003, Diario Oficial No. 45.079. Artículo 11, cuotas partes . Disponible en http://www.secretariasenado.gov.co/senado/basedoc/ley_0797_2003.html

[4] Ley 33 de 1985 de enero 29, Congreso de Colombia. Disponible en http://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=248

[5] Ley 24 de 1947 de noviembre 14, Diario Oficial No. 26.590, del 28 de diciembre de 1947. Artículo 1. Disponible en https://www.lexbase.co/lexdocs/indice/1947/l0024de1947

[6] Decreto 435 de 1971 de marzo 27, capítulo I reajuste de Pensiones en el Sector Público, Artículo 2. Disponible en http://www.suin-juriscol.gov.co/viewDocument.asp?id=1096921

[7] Ley 171 de 1961, reforma de la ley 77 de 1959. Disponible en https://www.ugpp.gov.co/doc_download/241-ley-171-de-1961

[8] Ley 77 de 1959 de noviembre 19, Diario Oficial No. 30.108, del 26 de noviembre de 1959. Disponible en https://normativa.colpensiones.gov.co/colpens/docs/ley_0077_1959.htm

[9] Ley 1 de 1963 de febrero 01. Disponible en http://www.suin-juriscol.gov.co/viewDocument.asp?ruta=Leyes/1556008

[10] Decreto 1221 de 1975 de junio 20, Diario Oficial No 34.357, del 15 de julio de 1975. Ministerio del trabajo. Disponible en https://normativa.colpensiones.gov.co/colpens/docs/decreto_1221_1975.htm

88

[11] Ley 4 de 1976, Decreto Reglamentario 732 de abril 22, Diario Oficial No 34.544, de 5 de mayo de 1976. Disponible en https://normativa.colpensiones.gov.co/colpens/docs/decreto_0732_1976.htm

[12] Decreto 2108 de 1992 de diciembre 29, Diario Oficial No 40.703, del 31 de diciembre de 1992. Disponible en https://normativa.colpensiones.gov.co/colpens/docs/decreto_2108_1992.htm

[13] Ley 4 de 1976 de enero 21, Artículo 1 de las pensiones de jubilación, invalidez, vejez y sobrevivientes del sector público. Disponible en http://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=1165

[14] Reajuste Ley de 1992, Pensión de jubilación, Decreto 2108 de 1992. Disponible en https://normativa.colpensiones.gov.co/colpens/docs/25000-23-25-000-2001-08133-01(4759-05).htm

[15] Ley 71 de 1988 de diciembre 19, Diario Oficial No 38.624 del 22 de diciembre de 1988. Disponible en https://normativa.colpensiones.gov.co/colpens/docs/ley_0071_1988.htm

[16] Decreto 3041 de 1966 de diciembre 19, Diario Oficial No 32.126, del 14 de enero de 1967. Disponible en https://normativa.colpensiones.gov.co/colpens/docs/decreto_3041_1966.htm

[17] Decreto 1848 de 1969 de noviembre 4, derogado parcialmente por el Decreto 1083 de 2015. Disponible en http://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=1291

[18] Ley 788 de 2002 de diciembre 27, Diario Oficial No 45.046 de 27 de diciembre de 2002. Disponible en http://www.secretariasenado.gov.co/senado/basedoc/ley_0788_2002.html

[19] MINISTERIO DE HACIENDA Y CRÉDITO PÚBLICO. Instrucciones operativas sobre el procedimiento de cuotas partes pensionales a cargo de entidades territoriales con cuenta en el fondo nacional de pensiones de las entidades territoriales, Artículo 3, Decreto 4810. (2010). Disponible en http://wsp.presidencia.gov.co/Normativa/Decretos/2010/Documents/Diciembre/29/dec481029122010.pdf

[20] Boletin jurídico. Cuota parte pensional, régimen de transición, Instituto de Seguros Sociales (ISS). 12 de octubre de 2006. Disponible en

89

https://www.superfinanciera.gov.co/jsp/loader.jsf?lServicio=Publicaciones&lTipo=publicaciones&lFuncion=loadContenidoPublicacion&id=15630&dPrint=1

[21] CUOTAS PARTES PENSIONALES, Configuración Normativa y normatividad. Oficina Asesora de Sistemas (OAS).

[22] Juan Palacio. Claudia Ruata. (2014). Gestión de proyectos con Scrum Manager. 13 de octubre de 2016, de Scrum Manager®. Disponible en http://www.scrummanager.net/files/sm_proyecto.pdf.

[23] Manuel Trigas Gallego. (2012). Gestión de proyectos informáticos, metodología SCRUM. Disponible en http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612memoria.pdf

[24] Desarrollo de Software Ágil: Extremme Programming y Scrum. 2° Edición. Página 3. Disponible en https://books.google.com.co/books?id=TxRpCwAAQBAJ&printsec=frontcover&dq=metodologias+agiles&hl=es&sa=X&ved=0ahUKEwiqn97K4a_jAhUNpFkKHfi4APYQ6AEIKTAA#v=onepage&q&f=false

[25] Proceso de SCRUM, Tuleap. Disponible en https://tuleap.udistrital.edu.co/plugins/mediawiki/wiki/gestion/index.php?title=PROCESO_DE_SCRUM

[26] Herramientas de gestión, Tuleap. Disponible en https://tuleap.udistrital.edu.co/plugins/mediawiki/wiki/gestion/index.php?title=Main_Page#Herramientas_de_Gesti.C3.B3n

[27] Oficina Asesora de Sistemas. Manual de uso módulo asistente nómina cuotas partes, versión 3.1. OpenEVA. Universidad Distrital Francisco José de Caldas. (2014).

[28] OFICINA ASESORA DE SISTEMAS, (OAS). Metodología SCRUM OAS.

90