Desarrollo del módulo de las fuentes de financiamiento para el proyecto KRONOS de la Universidad Distrital Francisco José de Caldas

Texto completo

(1)0. DESARROLLO DEL MODULO DE LAS FUENTES DE FINANCIAMIENTO PARA EL PROYECTO KRONOS DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. AUTOR(ES): JAMINTON EDUARDO RODRIGUEZ GOMEZ JOHAN FABIAN FORNARI RÍOS. ANTEPROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C, 2018.

(2) 1. DESARROLLO DEL MODULO DE LAS FUENTES DE FINANCIAMIENTO PARA EL PROYECTO KRONOS DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS. AUTOR(ES): JAMINTON EDUARDO RODRIGUEZ GOMEZ JOHAN FABIAN FORNARI RÍOS. DIRECTOR: ING. ALEJANDRO DAZA. ANTEPROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE SISTEMAS. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD DE INGENIERÍA INGENIERÍA DE SISTEMAS BOGOTÁ D.C, 2018.

(3) 2. TABLA DE CONTENIDO. Contenido INDICE DE TABLAS. 5. CAPÍTULO 1. INTRODUCCIÓN. 8. CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA. 10. CAPÍTULO 3. OBJETIVOS. 12. 3.1. Objetivo general. 12. 3.2. Objetivos específicos. 12. CAPÍTULO 4. JUSTIFICACIÓN. 13. CAPÍTULO 5. MARCO TEÓRICO. 15. 5.1. INTRODUCCIÓN 5.2. DEFINICIONES. 15 16. 5.2.1. Rubro. 16. 5.2.2. Capital. 16. 5.2.3. Dependencias Administrativas. 16. 5.3. El Plan de Inversiones Públicas. 16. 5.3.1. Proyección de la Inversión. 17. 5.3.1.1. Fuentes de libre destinación. 17. 5.3.1.2. Fuentes de destinación específica. 18. 5.3.1.3. Consolidador de Hacienda e Información Financiera Pública (CHIP). 19. 5.4. Modificación de fuentes de financiamiento en el presupuesto de inversión. 19. 5.4.1. Las modificaciones de fuentes se pueden presentar por efecto de. 20. 5.4.2. Requisitos para efectuar una modificación de fuentes de financiación. 21. 5.4.3. Cambio de montos entre conceptos de gasto. 22. 5.5. Fuentes de Financiamiento a asignar. 24. 5.5.1. Dependencias que tengan proyectos de inversión a las cuales se asignan las fuentes. 25. 5.5.1.1. LA RED DE DATOS UDNET. 25. 5.5.1.2. LA OFICINA ASESORA DE SISTEMAS “OAS”. 25.

(4) 3. 5.5.1.3. EL PLAN ESTRATÉGICO DE INCORPORACIÓN DE MEDIOS Y TECNOLOGÍAS DE LA INFORMACIÓN “PLANESTIC”. 26. 5.5.1.4. LA RED DE INVESTIGACIONES DE TECNOLOGÍA AVANZADA “RITA”. 26. 5.5.1.5. Estructura de Información. 27. CAPITULO 6. ALCANCES Y LIMITACIONES. 29. 6.1 ALCANCES. 29. 6.2. LIMITACIONES. 30. CAPÍTULO 7. METODOLOGÍA. 31. 7.1. METODOLOGÍA DE DESARROLLO DEL PROYECTO. 31. 7.2. METODOLOGÍA DE DESARROLLO DE LA APLICACIÓN. 32. 7.2.1. Fases de SCRUM. 33. 7.2.2. Inicio del proyecto. 33. 7.2.3. Crear la visión del proyecto. 33. 7.2.4. Identificar al Scrum Master y a los Stakeholders. 34. 7.2.5. Formación del equipo Scrum. 34. 7.2.6. Desarrollar Epics. 35. 7.2.7. Crear un Product Backlog priorizado. 35. 7.2.8. Realizar el plan de lanzamiento. 36. 7.2.9. Planificación y estimación. 36. 7.2.10. Creación de historias de usuario. 36. 7.2.11. Aprobación, estimación y asignación de historias de usuario. 37. 7.2.12. Creación de tareas. 37. 7.2.13. Estimación de tareas. 38. 7.2.14. Creación de la lista de pendientes del sprint. 38. 7.2.15. Implementación. 39. 7.2.16. Creación de entregables. 39. 7.2.17. Reuniones diarias de pie. 40. 7.2.18. Mantenimiento de la lista priorizada de pendientes del producto. 40. 7.2.19. Revisión y retrospectiva. 41. 7.2.20. Convocar Scrum de Scrums. 41. 7.2.21. Demostración y validación del Sprint. 42. 7.2.22. Retrospectiva del sprint. 42.

(5) 4. 7.2.23. Lanzamiento. 43. 7.2.24. Registro de tareas y seguimiento de las mismas en herramienta Tuleap. 45. 7.2.25. Sprints semanales que evidencian el progreso de las tareas. 46. 7.3. Sprints (KRONOS). 47. CAPÍTULO 8. RECURSOS. 70. CAPÍTULO 9. PRESUPUESTO. 71. CAPÍTULO 10. CRONOGRAMA. 73. CAPITULO 11. DISEÑO. 74. 11.1. Diagrama BPMN (Fuentes de Financiamiento). 74. 11.1.1. Rol:. 74. 11.1.2. Procesos:. 74. 11.1.3. Registral en el historial la fuente creada con los respectivos datos. 75. 11.2. Subproceso Crear Fuente de financiamiento. 75. 11.3. Subproceso Asignar rubros a la fuente. 76. 11.4. Subproceso Distribuir Rubros en Dependencias. 77. 11.5. Diagrama Arquitectura de la información. 78. 11.5.1. Formulario Fuente Financiamiento. 79. 11.5.2. Fuente Financiamiento. 79. 11.5.3. Dependencia. 79. 11.5.4. Apropiación. 79. 11.5.5 Rubro. 80. 11.5.6. Fuente Financiamiento Data. 80. 11.6. Modelo Relacional. 81. 11.6.1. Registrar fuente de financiamiento:. 82. 11.6.2. Asignar fuente financiamiento:. 82. 11.6.3. Consultas Fuentes de Financiamiento. 84. 11.6.4. DICCIONARIO DE DATOS. 85. 11.7. MOKUPS. 93. CAPITULO 12. ANALISIS E INTERPRETACION DE RESULTADOS. 114. 12.1. CONCLUSIONES. 119. 12.2. BIBLIOGRAFÍA. 120. ANEXOS. 121.

(6) 5. INDICE DE TABLAS Tabla 2.Ejemplo de Cambio de Montos entre Conceptos de Gasto Fuente: Dirección Distrital de Presupuesto .......................... 22 Tabla 3 Código de Rubros .............................................................................................................................................................. 24 Tabla 4a Asignación de fuente por rubro ....................................................................................................................................... 27 Tabla 4b Asignación de fuente por rubro ....................................................................................................................................... 27 Tabla 4c Asignación de fuente por rubro ....................................................................................................................................... 28 Tabla 4d Asignación de fuente por rubro ....................................................................................................................................... 28 Tabla 4e. Asignación de fuente por rubro ..................................................................................................................................... 28 Tabla 5. Recursos necesarios para la realización del proyecto Basado de: Oficina Asesora de Sistemas [5]. .............................. 70 Tabla 6. Presupuesto del proyecto. Basado de: Oficina Asesora de Sistemas [5]. ......................................................................... 72 Tabla 7. Cronograma General del Proyecto. Basado de: Oficina Asesora de Sistemas ................................................................ 73 Tabla 8.Tabla financiera.rubro ...................................................................................................................................................... 85 Tabla 9.Tabla financiera.apropiacion ............................................................................................................................................ 86 Tabla 10.Tabla financiera.fuente financiamiento apropiación ....................................................................................................... 87 Tabla 11.Tabla financiera fuente financiamiento ........................................................................................................................... 88 Tabla 12.Tabla financiera tipo movimiento .................................................................................................................................... 90 Tabla 13. Tabla financiera movimiento fuente financiamiento apropiación .................................................................................. 92.

(7) 6. INDICE DE FIGURAS. Fig 1. Proyectos de Inversión Fuente Dirección Distrital de Presupuesto. .................................................................................... 18 Fig 1. Corrección diagrama arquitectura de la información. ........................................................................................................ 48 Fig 2. Actualización BD fuentes de financiamiento ........................................................................................................................ 49 Fig 3.Reunión de avances ............................................................................................................................................................... 50 Fig 5. Seción de trabajo: revisión procedimiento de solicitud de necesidades ............................................................................... 51 Fig 6.Colaboración en parametrización para ejercicio de procesos financieros ........................................................................... 52 Fig 7.Analisis de fuentes de financiamiento ................................................................................................................................... 53 Fig 8.Asesoria fuentes de financiamiento ....................................................................................................................................... 54 Fig 9.Asesoria para el manejo de transacciones y funciones con beego ........................................................................................ 55 Fig 10.Modificacion modelo fuentes financiamiento ...................................................................................................................... 56 Fig 11. Documento análisis fuentes de financiamiento .................................................................................................................. 57 Fig 12. Ejercicio de prueba de control de fuentes de financiamiento ............................................................................................. 58 Fig 13. Creación servicio fuentes de financiamiento ...................................................................................................................... 59 Fig 14. Ajustes para el registro y consultas de fuentes de financiamiento ..................................................................................... 59 Fig 15.Validacion de commits de los ajustes para el registro y consulta d fuentes de financiamiento........................................... 60 Fig 16.Integracion de las fuentes de financiamiento en servicio fuente de financiamiento ............................................................ 60 Fig 17. Ajustes para el registro y consultas de fuentes de financiamiento ..................................................................................... 61 Fig 18. Integración reglas al servicio fuentes de financiamiento ................................................................................................... 62 Fig 19. Ajustes cliente fuentes de financiamiento para integrar servicios y reglas ........................................................................ 63 Fig 20. Creación tabla paramétrica tipo fuente financiamiento ..................................................................................................... 64 Fig 21. Integración cliente fuentes de financiamiento funcionamiento .......................................................................................... 65 Fig 22.Servicio Ordenes de pago para la consulta fuentes de financiamiento ............................................................................... 66 Fig 23.Integracion control de la fuentes de financiamiento por CDP,CRP Y OP .......................................................................... 67 Fig 24. Validación apropiación inicial en creación fuentes de financiamiento .............................................................................. 68 Fig 25.Servicios CDP Y CRP para consultas fuentes de financiamiento ........................................................................................ 69 Fig 26,Diagrama BPMN para fuentes de financiamiento .............................................................................................................. 74 Fig 27. Subproceso crear fuentes de financiamiento ...................................................................................................................... 75 Fig 28. Subproceso asignar rubros a la fuente ............................................................................................................................... 76 Fig 29. Subproceso distribuir rubros en dependencias .................................................................................................................. 77 Fig 30. Diagrama arquitectura de la información ......................................................................................................................... 78 Fig 31.Modelo relacional para fuentes de financiamiento ............................................................................................................. 81 Fig 32.Consulta de fuentes en especifico ........................................................................................................................................ 93 Fig 33.Consulta de fuente de financiamiento en especifico ............................................................................................................ 94 Fig 34.Consulta fuente de financiamiento general ......................................................................................................................... 95.

(8) 7. Fig 35.Creacion de fuente de financiamiento ................................................................................................................................. 96 Fig 36. Selección de rubro en fuente de financiamiento ................................................................................................................. 97 Fig 37.Vista después de la validación de los datos......................................................................................................................... 98 Fig 38.Modificaciones presupuestales caso traslado ..................................................................................................................... 99 Fig 39.Modificaciones presupuestales caso Adición .................................................................................................................... 100 Fig 40.Modificaciones presupuestales regla de verificación de valor para traslado ................................................................... 102 Fig 41.Modificaciones presupuestales selección de dependencias ............................................................................................... 103 Fig 42.Modificaciones presupuestales caso selección de fuente traslado .................................................................................... 104 Fig 43.Modificaciones presupuestales selección de la dependencia y fuente a la cual se va a adicionar .................................... 105 Fig 44.Modificaciones presupuestales selección de rubro adición y despliega fuentes y valor ................................................... 106 Fig 45.Modificaciones presupuestales selección traslado ............................................................................................................ 107 Fig 46.Modificaciones presupuestales selección tipo ................................................................................................................... 108 Fig 47.Modificaciones presupuestales selección rubro destino y la dependencia ........................................................................ 109 Fig 48.Modificaciones presupuestales caso traslado ................................................................................................................... 110 Fig 49.Modificaciones presupuestales vista después de la validación de la adición .................................................................... 111 Fig 50.Detalle fuente de financiamiento ....................................................................................................................................... 112 Fig 51. Control de las fuentes de financiamiento por CDP,CRP y OP......................................................................................... 113.

(9) 8. CAPÍTULO 1. INTRODUCCIÓN. El sistema “Si capital” es con el que se ha trabajado en la Universidad Distrital Francisco José de Caldas desde hace varios años, es por esta razón que con el fin de mejorar los tiempos de acceso a los procesos de consulta y registros del sistema, se hace necesario crear un nuevo sistema para la gestión y administración de su parte financiera.. El nuevo "Sistema Integral de Información" denominado KRONOS, el cual se encuentra en su primera etapa de desarrollo, nos permitirá la implementación de nuevos módulos, los cuales no están incluidos en el sistema “Si Capital” y se requieren para el año en curso 2017.. Para este proceso es necesario el desarrollo, análisis e implementación de un módulo que permita la distribución y control de las fuentes de financiamiento, las cuales se encargarán de designar el capital que es entregado a la Universidad Distrital Francisco José De Caldas por la secretaría de hacienda.. Este trabajo está pensado en el desarrollo de una aplicación cliente y un API “Application Programming Interface” el cual será integrado al "Sistema Integral de Información" KRONOS que se está desarrollando en la Oficina Asesora de Sistemas OAS, por el equipo de desarrollo, pertenecientes al proyecto de Financiera..

(10) 9. La metodología que se empleará en el desarrollo del proyecto será la de SCRUM “Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto”[1] .. De esta manera, este proyecto apoyará el proceso de desarrollo, de la solución de software y tendrá como resultado una herramienta modular, integral y escalable que apoye y facilite los procesos que se requieran, en específico la creación de las Fuentes de Financiamiento. Igualmente, el despliegue de esta solución estará basado y guiado en los procesos de identificación, análisis y caracterización de especificaciones funcionales y no funcionales realizados en los sub proyectos anteriores y será apoyado por tecnologías libres y por el proceso de desarrollo SCRUM..

(11) 10. CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA. La Oficina Asesora de Sistemas (OAS) propone una solución de software modular, integral y escalable que permita realizar los procesos que realiza “Si Capital”, el cual es una herramienta informática creada por la secretaría de Hacienda, para satisfacer las necesidades de administración de la información en entidades del sector público, de los niveles nacional, territorial y distrital. Está integrada por componentes financieros, tributarios y pensionales.. “Si Capital” es un proyecto clasificado, dentro del grupo de Productos Industriales, en la categoría de Sistemas Integrados de la familia "Sistema Integral de Información" . Para su funcionamiento requiere cuatro elementos que garanticen su operación y su Desarrollo: hardware, Software, conectividad y recurso humano [2].. Este nuevo "Sistema Integral de Información" llamado KRONOS llevará a cabo los procesos realizados hoy por “Si Capital”, partiendo de la creación de las fuentes de financiamiento como función primordial de los procesos generados por el antiguo "Sistema Integral de Información" “Si Capital” en el cual no se tenían en cuenta dichas fuentes.. La creación del módulo de Fuentes de Financiamiento el cual se desarrollará teniendo en cuenta los lineamientos arquitecturales de la OAS, el cual será integrado al "Sistema Integral de Información" KRONOS que se está desarrollando por el equipo de desarrollo pertenecientes al proyecto de Financiera..

(12) 11. ¿Cuál será el modelo de implementación que permita realizar la distribución y el control de los recursos asignados a través de las fuentes de financiamiento en el sistema de información financiero de la Universidad Distrital?.

(13) 12. CAPÍTULO 3. OBJETIVOS. 3.1. Objetivo general. Analizar y desarrollar un módulo que permita la distribución y control de las fuentes de financiamiento en el "Sistema Integral de Información". llamado KRONOS para la. Universidad Distrital Francisco José de Caldas.. 3.2. Objetivos específicos ● Generar el modelo arquitectural que de soporte al manejo y control de las fuentes de financiamiento en la Universidad Distrital Francisco José de Caldas.. ● Desarrollar las APIS que trabajen y den soporte en el back-end para el modelo integrado en KRONOS de las fuentes de financiamiento.. ● Analizar y documentar los requerimientos correspondientes a las fuentes de financiamiento para diseñar el módulo de fuentes de financiamiento para la Universidad Distrital Francisco José de Caldas.. ● Realizar el análisis económico del proyecto para evidenciar la relación costo beneficio del mismo..

(14) 13. CAPÍTULO 4. JUSTIFICACIÓN. Debido a que la Universidad Distrital cuenta con una herramienta informática creada por la secretaria Distrital de Hacienda para satisfacer las necesidades de administración de la información en entidades del sector público, de los niveles nacional, territorial y distrital. Está integrada por componentes administrativos, financieros, tributarios y pensionales. “Si Capital” es un proyecto clasificado, dentro del grupo de productos industriales, en la categoría de sistemas integrados "Sistema Integral de Información" . Para su funcionamiento, requiere cuatro elementos que garanticen su operación y su desarrollo: hardware, software, conectividad y recurso humano.. Se está desarrollando un nuevo "Sistema Integral de Información" llamado KRONOS en el cual se están implementando todos los módulos del sistema actual “Si Capital”, ya que este no posee todos los códigos fuentes, no se tiene un contrato de soporte para nuevas funcionalidades de rendimiento y funcionamiento.. Como se mencionó anteriormente las fuentes de financiamiento se incluyen hasta este año en curso 2017 ya que el sistema anterior “Si Capital” no se tenían en cuenta para una distribución exhaustiva y detallada en todo su proceso..

(15) 14. Por tal razón se hace necesario el desarrollo del módulo de fuentes de financiamiento para su implementación en el sistema KRONOS.. Para tal fin la Oficina Asesora de Sistemas (OAS) de la Universidad Distrital Francisco José de Caldas requiere estudiantes de últimos semestres pertenecientes al proyecto curricular de Ingeniería de Sistemas, que participarán en el desarrollo de módulos correspondientes a cada una de las modalidades de proyecto de grado donde cada uno ha elegido un rol en el proyecto teniendo como opción ser analistas, arquitectos o desarrolladores..

(16) 15. CAPÍTULO 5. MARCO TEÓRICO A lo largo de este capítulo pretendemos mostrar los conceptos básicos que abarcan Las fuentes de financiamiento, así como sus diferentes ítems y casos especiales que se puedan presentar al momento de su creación o designación.. A continuación se hará una breve introducción al tema explicando sus componentes fundamentales y su importancia para el proyecto, posteriormente se mostrara los casos en los cuales se hacen modificaciones a las fuentes de financiamiento.. 5.1. INTRODUCCIÓN. Las fuentes de financiamiento representan el conjunto de capital interno y externo de una organización y es usado para el financiamiento de las aplicaciones y las inversiones que se puedan representar en el transcurso del tiempo. 1 Estas a su vez son parte de un fundamental en la creación y financiación proyecto ya que nos proporcionan información precisa de los recursos económicos con los cuales se van a ejecutar dicho proyecto. Para este caso se tendrán en cuenta el plan de inversiones públicas la proyección de la inversión, los dos tipos de fuentes que son: fuentes de libre destinación y fuentes de destinación específica. Se mostrará en detalle los casos en los que son necesarias las modificaciones en las fuentes de financiamiento.. 1. (definicion.org, 2017).

(17) 16. 5.2. DEFINICIONES 5.2.1. Rubro Se designa a un sector o conjunto de empresas o negocios que se engloban en un área dentro de una actividad económica; Es un título que agrupa a un conjunto de cuentas.2. 5.2.2. Capital El término capital es el que se utiliza para hacer referencia al dinero o al patrimonio monetario que una persona, institución pueda tener.3. 5.2.3. Dependencias Administrativas Se le da este nombre a aquella oficina que depende de otra que ostenta una mayor entidad o importancia.4 5.3. El Plan de Inversiones Públicas. Contendrá los presupuestos plurianuales de los principales proyectos prioritarios acompañados de la estrategia financiera que determinará los recursos financieros y las fuentes de financiamiento que garanticen su ejecución. 5 El Presupuesto Anual coincidirá con las metas del primer año del Plan de Desarrollo; las estimaciones definidas para los años siguientes son de carácter indicativo, y serán consistentes con el presupuesto de la vigencia correspondiente en la medida en que no se den cambios de política fiscal o sectorial, ni se generen cambios en la coyuntura económica o ajustes de tipo 2. (definicionabc, 2017) (definicionabc, 2017) 4 (definicionabc, 2017) 5 (Hacienda, 2014) 3.

(18) 17. técnico que alteren los parámetros de cálculo relevantes.6. 5.3.1. Proyección de la Inversión. Inicialmente la información de los proyectos de inversión se registra en el aplicativo SEGPLAN módulo POAI de la Secretaría Distrital de Planeación y corresponde a los recursos previstos en el Plan de Desarrollo para el año que se está programando, garantizando que la formulación técnica de los proyectos de inversión tenga completa coherencia con las metas planteadas y con los compromisos del Plan de Desarrollo a los cuales se encuentran asociados para la distribución de los recursos se deben tener en cuenta: Identificar los componentes de gasto de los proyectos de inversión con sus respectivas fuentes de financiación, las cuales se clasifican en:. 5.3.1.1. Fuentes de libre destinación. Provienen del recaudo de los ingresos ordinarios de las entidades territoriales cumplen con el Principio de Unidad de Caja y no están atadas a la financiación de gastos predeterminados.7. 6 7. (Hacienda, 2014) (Hacienda, 2014).

(19) 18. 5.3.1.2. Fuentes de destinación específica. Son recursos que corresponden a fuentes externas o exógenas provenientes de la Nación tales como el sistema general de participaciones las regalías y compensaciones y las rentas cedidas entre otras; se manejan en cuentas tesorales y contables en forma separada.8. Fig 1. Proyectos de Inversión Fuente Dirección Distrital de Presupuesto.. 8. (Hacienda, 2014).

(20) 19. 5.3.1.3. Consolidador de Hacienda e Información Financiera Pública (CHIP) Es un sistema de información diseñado y desarrollado por el Ministerio de Hacienda y Crédito Público - Programa FOSIT, para que con la adecuada reglamentación y estructura procedimental, canalice la información financiera, económica y social de los entes públicos hacia los organismos centrales y al público en general bajo la administración y responsabilidad de la Contaduría General de la Nación. Normalizado por la Contraloría General de la República, mediante Resolución 5544 de 2003 y sus modificatorios, Resolución 5993 de 2008 y Resolución 6054 de 2009.9 5.4. Modificación de fuentes de financiamiento en el presupuesto de inversión Es el cambio en los montos de las fuentes de financiación con las cuales se proyectó el pago de las apropiaciones del presupuesto de gastos e inversiones, sin modificar el valor aprobado por el Concejo de Bogotá.. Para que la modificación de fuentes se lleve a cabo, la entidad debe contar con otras fuentes de financiación diferentes a Recursos Distrito.10. 9. (Hacienda, 2014) (Hacienda, 2014). 10.

(21) 20. 5.4.1. Las modificaciones de fuentes se pueden presentar por efecto de ●. Sustituciones de ingresos.. ●. Cambios en las fuentes que financian los proyectos de inversión directa.. ●. Traslados presupuestales controlando que las fuentes de destinación específica de conformidad con la normatividad vigente puedan financiar las nuevas propuestas de gasto.. ●. Cuando se presenta a 31 de diciembre un mayor recaudo (reaforo) por concepto de ingresos corrientes de destinación específica. en este caso, la Administración de acuerdo con las condiciones y variables macroeconómicas que puedan afectar el comportamiento de los ingresos, evalúa la necesidad y de manera directa realiza la modificación de fuentes en el sistema PREDIS, disminuyendo la fuente Recursos Distrito, aumentando las correspondientes partidas por concepto de los recursos de Balance. En este caso, los cambios se comunican a las entidades para efectos del seguimiento y control a la ejecución de las rentas de destinación específica.. En todo caso, los ingresos de destinación específica de la vigencia no pueden financiar compromisos de vigencias anteriores; si quedaron constituidas reservas o pasivos exigibles financiados con estos recursos, mayores a los programados en el presupuesto, se deben disminuir los recursos o aportes del Distrito y realizar las modificaciones de fuentes pertinentes. lo anterior, por cuanto los cambios deben cumplir estrictamente la relación entre fuentes y usos al igual que la relación entre los ingresos percibidos versus los compromisos, giros y reservas o pasivos.

(22) 21. constituidos.11 Se debe tener en cuenta que en el sistema PREDIS las fuentes de financiación se denominan de conformidad con el origen de las mismas y dependiendo de los momentos del recaudo o ejecución. Ejemplo: ●. Vigencia: 1% impuesto de industria y comercio. ●. Pasivos Exigibles: Recursos Pasivos Exigibles 1% impuesto de industria y comercio. ●. Mayor recaudo vigencia anterior: Reaforo 1% impuesto de industria y comercio. ●. Saldos no ejecutados: Recursos del Balance 1% impuesto de industria y comercio. Cuando la modificación de fuentes afecte la distribución al interior del presupuesto de ingreso debe tenerse en cuenta el procedimiento establecido en las distribuciones al interior del plan de cuentas.12. 5.4.2. Requisitos para efectuar una modificación de fuentes de financiación. ●. Solicitud formal suscrita por el Representante Legal de la entidad, en la que se detalle la modificación de las fuentes de financiación de las apropiaciones de inversión y de los conceptos de gasto.. ●. Verificación en el Sistema PREDIS sobre el saldo de apropiación disponible en el concepto de gasto del proyecto respectivo, para analizar la viabilidad de la modificación.. 11 12. (Hacienda, 2014) (Hacienda, 2014).

(23) 22. ●. Oficio de la Dirección Distrital de Presupuesto informando a la entidad sobre el cambio de fuentes para que proceda a la ejecución de las apropiaciones.. ●. Para las entidades de la Administración Central, establecimientos públicos y unidades administrativas especiales que registran diariamente los movimientos presupuestales en el Sistema PREDIS, el cambio de fuentes lo realiza el profesional de la Subdirección de Finanzas Distritales de la Dirección Distrital de Presupuesto.13. 5.4.3. Cambio de montos entre conceptos de gasto Para los cambios entre conceptos de gasto al interior de un rubro presupuestal, se debe tener en cuenta las siguientes situaciones: ●. Si se reduce el valor de un concepto de gasto es una fuente determinada, para adicionarlo en otro, la fuente debe ser la misma.. ●. Los cambios en los conceptos de gasto no modifican los topes de las fuentes de financiamiento, ni el valor del rubro presupuestal.14. Tabla 2.Ejemplo de Cambio de Montos entre Conceptos de Gasto Fuente: Dirección Distrital de Presupuesto. 13 14. (Hacienda, 2014) (Hacienda, 2014).

(24) 23. La responsabilidad en los cambios entre los conceptos de gasto es de la entidad ejecutora; sin embargo, cuando estos varíen el nivel de recurrencia programado en el presupuesto, debe solicitar por escrito concepto a la Dirección Distrital de Presupuesto de la Secretaría Distrital de Hacienda explicando las razones por las cuales es pertinente realizar dicho cambio, quien evaluará y comunicará la decisión por escrito; para lo cual se surtirán los siguientes pasos. La entidad distrital debe enviar solicitud formal a la Dirección Distrital de Presupuesto, firmada por el Representante Legal, ordenador de gasto y/o encargado de la oficina de planeación, requiriendo concepto de viabilidad de cambio de montos entre conceptos de gasto y explicando las razones por las cuales es pertinente realizar dicho cambio. ●. La Dirección Distrital de Presupuesto evaluará la solicitud y comunicará por escrito la decisión.. ●. Cuando la entidad requiera crear un concepto de gasto o modificar la denominación del concepto y/o los códigos FUT y CHIP, se surtirán los siguientes pasos:. ●. La entidad distrital debe enviar solicitud formal a la Dirección Distrital de Presupuesto, firmada por el Representante Legal, ordenador del gasto y/o encargado de la OFICINA ASESORA DE PLANEACIÓN, requiriendo concepto de viabilidad para la creación de un concepto de gasto o la modificación de la denominación concepto y/o los códigos FUT y CHIP del, explicando las razones por las cuales es pertinente realizar dicho cambio.. ●. La Dirección Distrital de Presupuesto evaluará la solicitud y comunicará por escrito la.

(25) 24. decisión. ●. Las modificaciones que en estos casos se radiquen en los últimos dos (2) días hábiles del mes, serán incorporadas al sistema PREDIS en el siguiente mes.15 5.5. Fuentes de Financiamiento a asignar CODIGO RUBRO UD 22103. DESCRIPCIÓN Distribución Punto Adicional CREE. 2215. Estampilla Pro-UNAL y otras universidades. 2414. Estampilla Universidad Distrital Inversión. 2416. Rendimientos Estampilla Universidad Distrital. 2418. Distribución anteriores). Punto. Adicional. 24110. Aportes Distrito (Años Anteriores). 24111. Estampilla Pro-UNAL (Vigencias Anteriores). y. demás. 2433. Rendimiento Punto Adicional CREE. 2434. Rendimiento Estampilla Universidades. 291. Recursos Distrital. del. balance. CREE. universidades. Pro-UNAL Estampilla. (Años. y. demás. Universidad. Tabla 3 Código de Rubros. En la tabla 3 códigos rubros, se visualizan los códigos rubros UD y su descripción, estos códigos serán usados para la creación y asignación de las fuentes de financiamiento.. 15. (Hacienda, 2014).

(26) 25. 5.5.1. Dependencias que tengan proyectos de inversión a las cuales se asignan las fuentes Para aquellas dependencias que tengan proyectos de inversión se les podrá asignar las fuentes de financiamiento; para este caso se tomarán como ejemplo: LA RED DE DATOS UDNET, LA OFICINA ASESORA DE SISTEMAS “OAS”,EL PLAN ESTRATÉGICO DE INCORPORACIÓN DE MEDIOS Y TECNOLOGÍAS DE LA INFORMACIÓN PLANESTIC”, las cuales se especificarán en la tabla 4 especificación de fuente por rubro. y se mostrará en detalle en el capítulo 5.5.1.5. Estructura de Información.. 5.5.1.1. LA RED DE DATOS UDNET. La Red de Datos UDNET garantiza la continua disponibilidad de los recursos y servicios de las tecnologías de la información y las comunicaciones existentes, en beneficio de la comunidad académica y administrativa de la Universidad Distrital Francisco José de Caldas; a través de la gestión, proyección tecnológica, asesoría y soporte técnico especializado.16 5.5.1.2. LA OFICINA ASESORA DE SISTEMAS “OAS” Es la responsable de ejecutar, investigar y desarrollar planes de sistematización y cómputo, para las diferentes áreas académicas y administrativas de la Universidad.17. 16 17. (udistrital, 2017) (udistrital, 2017).

(27) 26. 5.5.1.3. EL PLAN ESTRATÉGICO DE INCORPORACIÓN DE MEDIOS Y TECNOLOGÍAS DE LA INFORMACIÓN “PLANESTIC”. El Plan Estratégico de Incorporación de Medios y Tecnologías de la Información en los Procesos Educativos de la Universidad Distrital Francisco José de Calda se realiza con un enfoque de prospectiva estratégica donde el Proyecto Universitario Institucional, el PED, los escenarios futuros posibles y deseados se convierten en los hilos conductores que permiten definir la visión, los objetivos estratégicos, las estrategias, las líneas de acción y el banco de proyectos del plan estratégico de TIC.18. 5.5.1.4. LA RED DE INVESTIGACIONES DE TECNOLOGÍA AVANZADA “RITA” La Red de Investigaciones de Tecnología Avanzada RITA de la Universidad Distrital Francisco José de Caldas es una red académica que está comprometida con la implementación, mantenimiento y soporte de una plataforma tecnológica de alta velocidad y servicios asociados, con el objetivo de fortalecer la ejecución de proyectos de investigación, la innovación científica, el desarrollo tecnológico, el apoyo a los procesos académicos basados en entornos virtuales y la creación de nuevos protocolos y estándares para intercambio de información entre comunidades académicas, científicas e investigativas de la ciudad, la región y el país.19. 18 19. (udistrital, 2017) (udistrital, 2017).

(28) 27. 5.5.1.5. Estructura de Información A continuación se visualiza un ejemplo de asignación por rubro con una vigencia para el año 2017 como se observa en la tabla 4a Asignación de fuente por rubro, en la tabla 4b Asignación de fuente por rubro muestra la distribución de rubro por fuentes como lo son: RED UNE, OAS, PLANESTIC, RITA, con sus respectivos totales. En las tablas 4c y 4d se muestran los totales y subtotales distribuidos por cada rubro, En la tabla 4e observamos el código fuente asignado para cada rubro, el porcentaje asignado para cada uno de ellos y el valor total asignado.. ASIGNACIÓN RUBRO VIGENCIA 2017 RUBRO SISTEMA INTEGRAL DE INFORMACIÓN 3-3-001-15-01-08-0119-188. $3.531.124.000,00 Tabla 4a Asignación de fuente por rubro. Tabla 4b Asignación de fuente por rubro.

(29) 28. Tabla 4c Asignación de fuente por rubro. Tabla 4d Asignación de fuente por rubro. RUBRO 2017. 188. CÓDIGO FUENTE 2017. %. VALOR ASIGNADO. 483. 66. $2.013.508.000,00. 515. 22. $664.523.000,00. 516. 12. $353.093.000,00. TOTAL. 100. $3.031.124.000,00. Tabla 4e. Asignación de fuente por rubro.

(30) 29. CAPITULO 6. ALCANCES Y LIMITACIONES. 6.1 ALCANCES. ● El proyecto abarca la fase de inicio, elaboración y construcción del proceso de desarrollo Scrum participando en el rol de Analista y desarrollador del desarrollo de las fuentes de financiamiento, en la modalidad de pasantía en la Oficina Asesor de Sistemas OAS de la Universidad Distrital Francisco José de Caldas.. ● Los diagramas a modelar con el estándar UML serán los necesarios para entender y describir en su totalidad el proyecto del desarrollo de fuentes de financiamiento que se realizará en la Oficina Asesor de Sistemas OAS de la Universidad Distrital Francisco José de Caldas.. ● Se realizará la respectiva arquitectura de la base de datos complementando o rediseñando la arquitectura que se tenía planteada por parte del equipo de financiera perteneciente a la Oficina Asesor de Sistemas OAS de la Universidad Distrital Francisco José de Caldas. ..

(31) 30. 6.2. LIMITACIONES. ●. Todos los productos de software que se desarrollaran en el lenguaje de programación Golang en Backend, Angularjs en Frontend y Postgre SQL para el manejo de la persistencia, como se estipula en la Oficina Asesora de Sistemas (OAS).. ●. Para el desarrollo de este proyecto solo se utilizara herramientas de software libre.. ●. El tiempo máximo contemplado para la finalización del proyecto es de 6 meses.. ●. El recurso humano analista y desarrollador será asumido por los autores de este proyecto y su costo será asumido por cuenta propia,.

(32) 31. CAPÍTULO 7. METODOLOGÍA. 7.1. METODOLOGÍA DE DESARROLLO DEL PROYECTO Para la ejecución de este proyecto se desarrollaron una serie de etapas por medio de las cuales se pretende proponer la ejecución de la aplicación, para de esta forma alcanzar los objetivos propuestos en este proyecto.. Las etapas que se plantean son cuatro y están definidas como: ● Revisión del modelo existente: Se pretende hacer una revisión de la base de datos “core” que se encuentra actualmente en el sistema, revisar los procesos y modelos existentes, se creará un documento análisis en el cual se describirán todos los procesos, avances y terminología suficiente en el transcurso del proyecto Kronos. ● Especificación de casos de uso: Se especificarán los diferentes actores y casos de uso para el módulo de fuentes de financiamiento. ● Análisis Modelo Fuentes de Financiamiento: Se realizará un modelo “BPMN” Business Process Model and Notation con el cual modelaremos los procesos de una forma estandarizada, también se desarrollarán los respectivos diagramas UML como lo son los diagramas de actividades, secuencia, despliegue, componentes y paquetes. ● Diseño Base de Datos Fuentes de Financiamiento: En esta etapa diseñaremos el diseño entidad relación, el modelo relacional, se analizará la base de datos para así, proceder a diseñarla..

(33) 32. 7.2. METODOLOGÍA DE DESARROLLO DE LA APLICACIÓN. Scrum es una de las metodologías ágiles más populares diseñada para entregar un valor significativo de manera rápida y durante el transcurso del proyecto. De la misma manera, asegura transparencia en la comunicación y crea un ambiente de responsabilidad colectivo y progreso continuo. Igualmente, Scrum está diseñado de tal manera que soporta el desarrollo de productos y servicios para todo tipo de industrias, sin importar su complejidad [4].. El equipo Scrum está formado por los siguientes Roles:. ● Scrum master: Es la persona que lidera el equipo guiándolo para que cumpla las reglas y procesos de la metodología, también es el encargado de gestionar la reducción de impedimentos del proyecto y trabaja conjuntamente con el Product Owner para maximizar el ROL. ● Product Owner: Es un representante y cliente que usan el software, se focaliza en la parte de negocio y es el responsable del ROL del proyecto. ● Team: Grupo de profesionales con los conocimientos técnicos necesarios y que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada Sprint..

(34) 33. 7.2.1. Fases de SCRUM. En el SBOK (Scrum Body of Knowledge) se definen 19 procesos Scrum, agrupados en cinco fases [5].. 7.2.2. Inicio del proyecto. Comprende el proceso que fija las bases necesarias para dar inicio al proyecto. Como se define en el SBOK (Scrum Body of Knowledge), esta fase de inicio es aplicable para portafolios, programas y/o proyectos pertenecientes a cualquier industria así como para proyectos con cualquier tipo de complejidad. Dentro del inicio del proyecto se identifican seis actividades principales:. 7.2.3. Crear la visión del proyecto. En este proceso, se revisa el proyecto de estudio de negocio para crear una declaración de visión del proyecto que inspire y proporcione un enfoque claro para el mismo. Para realizar esta visión, que es transversal al proyecto, se utilizan aspectos inherentes al negocio como lo son su misión, visión y un estudio de mercado. Igualmente, en este proceso participan el Product Owner, el Scrum Master y los interesados y se realiza por medio de reuniones que permiten identificar el contexto del negocio, los requerimientos y las expectativas de negocio. También suelen utilizarse matrices DOFA y análisis GAP para identificar fortaleza, debilidades, amenazas y oportunidades.

(35) 34. y realizar también una comparación del estado actual del proyecto y el estado deseado del mismo.. 7.2.4. Identificar al Scrum Master y a los Stakeholders. Utilizando criterios de selección, como lo son la capacidad para resolver problemas, la disponibilidad, compromiso y liderazgo, y junto a la propuesta de visión realizada anteriormente, se elige al maestro Scrum. También suele pedirse ayuda al departamento de recursos humanos para determinar qué personal se necesita para un proyecto; también se estudia la disponibilidad y el compromiso de aquellos que puedan ser seleccionados para Scrum Master e interesados. Para los stakeholders debe tenerse en cuenta que son todos aquellos clientes, usuarios y patrocinadores que faciliten la creación de productos del proyecto.. 7.2.5. Formación del equipo Scrum. Se identifican los miembros del equipo Scrum. Normalmente, el encargado de esta responsabilidad es el Product Owner, pero también puede hacerlo junto con el Scrum Master. Los miembros ideales de este equipo son independientes, auto-motivados, responsables y colaborativos. Suele utilizarse ayuda del departamento de recursos humanos para conocer la disponibilidad y compromiso del personal. Igualmente, se tienen en cuenta los costos del personal y del entrenamiento, ya que no todos los miembros del equipo poseen las habilidades requeridas o el conocimiento para las tareas que les serán asignadas. Por esto, el Product Owner.

(36) 35. debe evaluar las necesidades de entrenamiento de los miembros y proveerles capacitaciones donde puedan adquirirlas. A parte de elegir al equipo Scrum, es importante elegir personal de respaldo quienes pueden reemplazar a alguien en el equipo Scrum, dada alguna eventualidad.. 7.2.6. Desarrollar Epics. En este proceso la visión del proyecto es la base para definir los Epics, así como reuniones con los usuarios para discutir cuáles Epics son apropiados. Los Epics, o épicas, se redactan al inicio del proyecto cuando las historias de usuario son funcionalidades de alto nivel por lo que no son más que historias de usuario amplias sin refinar. Se incluyen en la lista priorizada del Produck Backlog para ser terminadas y se convierten posteriormente en historias de usuario más pequeñas. La definición de épicas las realiza el equipo Scrum por medio de reuniones de grupo de usuario donde intervienen en ellas los interesados más relevantes y en ella se aclaran requerimientos para no realizar doble trabajo y esfuerzo; también se utilizan talleres de historia de usuario y entrevistas al usuario o cliente.. 7.2.7. Crear un Product Backlog priorizado. En este proceso se refinan los Epics para crear una lista priorizada de pendientes del producto del proyecto. Para ello, se utilizan métodos de priorización de las historias de usuarios como el esquema de priorización MoSCoW, que utiliza etiquetas en orden de prioridad decreciente que marcan las historias de usuario con características de “debería tener” y “gustaría que tuviera”.

(37) 36. para medir su importancia. También se utiliza la comparación por pares, donde se lista las historias de usuario y se comparan entre sí, eligiendo la que sea más importante entre las dos. Todo esto permitirá entonces que se obtenga un Product Backlog priorizado. 7.2.8. Realizar el plan de lanzamiento. Se revisan las historias de usuario en el Product Backlog priorizado para realizar un cronograma de lanzamiento, determinando también la duración del sprint. Aquí se utilizan sesiones de planificación que definen cuándo se van a entregar conjuntos de funcionalidad o productos utilizables. Para ello, el equipo debe tener clara la visión general de los lanzamientos y el calendario de entrega del producto que se está haciendo para así cumplir con las expectativas.. 7.2.9. Planificación y estimación Comprende cinco procesos y también es aplicable para cualquier área, no solamente para el desarrollo de software.. 7.2.10. Creación de historias de usuario. El Product Owner, gracias a la interacción con socios y su conocimiento del negocio, es quien desarrolla las historias de usuario elaboradas y refinadas que sean aprobadas por el equipo Scrum y que harán parte de la lista inicial de pendientes del producto para el proyecto. También existen.

(38) 37. métodos para la estimación de historias de usuario (específicamente para su aprobación, estimación y asignación). Entre ellas se encuentra la reunión de grupos de usuarios, el póker de planificación y los puntos de estimación de costo. Como resultado de este proceso no solo se obtienen las historias de usuario sino un Product Backlog actualizado junto con criterios de aceptación para dichas historias, para que se obtenga objetividad al decidir cuándo la historia ha sido terminada o no durante la revisión del sprint.. 7.2.11. Aprobación, estimación y asignación de historias de usuario. Se utilizan los métodos descritos anteriormente para realizar la estimación de los tamaños relativos de las historias de usuario o el trabajo necesario para desarrollarlas. También existen otras técnicas de estimación no tan populares como Wideband Delphi, puntos de historia, estimación por afinidad y rango de estimación. Todas estas actividades apuntan al mismo objetivo y necesitan del soporte y experticia de los asesores Scrum, que resolverán los conflictos que puedan aparecer a la hora de las estimaciones sobre ciertas historias de usuario.. 7.2.12. Creación de tareas. El equipo Scrum se reúne para planear el trabajo que se realizará en el sprint. Para ello se utilizan las historias de usuario, las cuales pasarán a hacer parte de la lista priorizada de pendientes del Sprint. En estas reuniones debe estar presente el Product Owner, quien aclara todas las dudas que se presenten sobre las historias y procurará que la reunión no se extienda en temas que no le.

(39) 38. correspondan. El Product Owner presenta qué historias de usuario estarían bien que formarán parte del sprint. Así, el equipo determina cuántas puede realizar, llegando a un consenso entre ambas partes. Luego, el equipo determina cómo convertir las historias de usuario en un incremento del producto al dividirlo en tareas, definiendo luego los entregables.. 7.2.13. Estimación de tareas. Se realizan reuniones para estimar el trabajo necesario para completar una tarea, así como estimar el trabajo laboral y demás recursos para las tareas del sprint. Esto permite que el equipo cuente con una perspectiva de las historias de usuario y los requerimientos para así calcular el esfuerzo necesario; este proceso suele conocerse como las reuniones de planificación de sprint y utilizan mucho el juicio de expertos y cálculos paramétricos para las estimaciones.. 7.2.14. Creación de la lista de pendientes del sprint. Dentro de la reunión de planificación de Sprint también se elabora la lista de pendientes del sprint y la gráfica de pendientes. Igualmente se realiza el seguimiento del sprint y se tiene en cuenta la duración del anterior, para conocer en qué lugar se encuentra el equipo en términos de la finalización de las tareas. Para ello suele usarse un tablero o herramienta que marque las tareas con estados: To Do, In Progress y Done. De esta manera se conoce más fácilmente la lista de pendientes del sprint..

(40) 39. 7.2.15. Implementación. Está relacionada con la ejecución de las tareas que permiten la creación del producto. De esta manera, incluye tres procesos principales:. 7.2.16. Creación de entregables. En este proceso se utiliza el tablero Scrum (Figura 1), donde se realiza el seguimiento de Sprint según los estados de las tareas del mismo (por hacer, en progreso, en revisión o prueba y terminado); puede ser un tablero físico o utilizarse una herramienta electrónica para simularlo. Aquí se utilizan herramientas de software para programar, recopilar información y para la distribución, todo esto con el fin de dar seguimiento a las tareas asignadas y a que éstas se realicen de la manera más ágil posible. Igualmente, es necesaria la experiencia del equipo Scrum para comprender las historias y las tareas de pendientes del sprint para así poder crear entregables finales.. Para los proyectos de software existen dos herramientas de desarrollo que Scrum considera Pueden ser utilizadas y pueden llegar a facilitar este proceso:. ● Refactorización: Consiste en mejorar el mantenimiento del código existente y hacerlo más flexible y sencillo. Esto indica que lo que se desea es realizar optimizaciones sobre código actual y existente, sin cambiar el.

(41) 40. comportamiento del mismo. Así, se busca eliminar código redundante, separar las funciones en métodos más pequeños, definir de forma clara las variables y nombres de métodos y hacer, de manera general, el código más fácil de entender y modificar. ● Patrones de diseño: Proporcionan una manera formal de registrar una solución a un problema de diseño en un campo específico. Estos patrones están hechos para ser aplicados a problemas puntuales y para hacer del código algo más fácil de reutilizar y entender.. 7.2.17. Reuniones diarias de pie. Consiste en reuniones diarias de 15 minutos donde se reporta el progreso del sprint y se planifican las actividades del día. Se busca que todos los miembros estén en esta reunión pero si alguno presenta un impedimento no se cancela ni se retrasa. En la reunión se responde a los interrogantes: ¿que terminé ayer?, ¿qué terminaré hoy? ¿Qué problemas tuve? También suele utilizarse la videoconferencia para las reuniones.. 7.2.18. Mantenimiento de la lista priorizada de pendientes del producto. El propietario del producto puede reunirse con los socios e interesados del proyecto para contar con la información necesaria que le permita actualizar la lista priorizada de pendientes del producto. Esto se realiza para que todos entiendan las historias de usuario y sus criterios de.

(42) 41. aceptación; también se hace para eliminar historias de usuario irrelevantes y que se incorporen solicitudes de cambio. El mantenimiento de esta lista es clave para el desarrollo de las tareas y depende de una buena comunicación entre el equipo Scrum. 7.2.19. Revisión y retrospectiva. En esta fase se desarrollan actividades de corrección de errores de los entregables y del trabajo desarrollado hasta el momento del desarrollo de esta.. 7.2.20. Convocar Scrum de Scrums. Los representantes del equipo Scrum convocan una reunión de Scrum of Scrums (SoS), en la cual los representantes del equipo se reúnen para compartir el estado de los productos y tareas de los grupos correspondientes, se realizan de acuerdo a intervalos de tiempo definidos al principio del proyecto o cuando los representantes o miembros del equipo así lo requieran. Las actualizaciones de cada equipo serán presentadas a la organización a través de cuatro preguntas básicas:. ● ¿En que ha estado trabajando mi equipo desde la última reunión? ● ¿Qué va a hacer mi equipo hasta la próxima reunión? ● ¿Con qué contaban otros equipos que mi equipo hiciera que no se ha hecho? ● ¿Qué piensa hacer nuestro equipo que pueda afectar otros equipos?.

(43) 42. 7.2.21. Demostración y validación del Sprint. En este proceso se le enseña al propietario del proyecto e interesados el Sprint Deliverable del producto en un Sprint Review Meeting, que es una reunión donde participan no solo los miembros del equipo sino que también los stakeholders, en esta se discute la pertinencia del producto entregado, el propietario tiene como función principal aprobar o rechazar dicho producto.. 7.2.22. Retrospectiva del sprint. Este proceso sirve para analizar retrospectivamente y determinar cómo se ha llevado a cabo dicho Sprint para tener en cuenta buenas acciones o para evitar errores los errores que se cometieron. Se debe documentar estas lecciones con el objetivo de usarlas posteriormente y mantener el proceso en una constante mejora. Todos los miembros del equipo asisten a la reunión, no es necesario que el propietario asista, se busca identificar las buenas y malas prácticas y las mejoras que se deben implementar.. Para medir y contrastar el desempeño del sprint comparándolo con Sprints pasados, como lo son el team velocity, que es el número de puntos de historia hechos durante el Sprint, el porcentaje de puntos de historia que han sido terminados, en relación a los que se han llevado a cabo; estimado de eficacia, porcentaje de discrepancia entre el tiempo previsto y el tiempo verdadero que se ha utilizado en las tareas; el o los stakeholder(s) puede(n) solicitar una.

(44) 43. retroalimentación que les permita establecer parámetros cualitativos o cuantitativos para evidenciar el avance del proyecto y finalmente un estimado para la liberación del producto el valor del negocio proporcionado en cada versión, así como el valor representado por el progreso actual hacia una liberación.. 7.2.23. Lanzamiento. En la fase de lanzamiento o reléase está marcada por la entrega de productos aceptados al(los) cliente(s) o usuario(s), la documentación, y análisis del desarrollo de las actividades dentro del proyecto.. ● Envío de entregables: En este proceso los Accept Deliverables se entregan o traslada a los socios, clientes o usuarios pertinentes, un Working Deliverable Agreement, donde se hace un cierre de negocio formal y se documenta la finalización con éxito del Sprint.. ● Retrospectiva del proyecto: En este paso los socios y el equipo para identificar, documentar y analizar las buenas y malas prácticas para utilizarlas y corregirlas en futuros proyectos.. Como puede apreciarse, la metodología Scrum presenta la ventaja de corrección de errores de manera casi inmediata gracias a sus sesiones diarias (Daily Scrum), donde los integrantes.

(45) 44. comparten sus avances y problemas con respecto al proyecto, lo que es esencial cuando se necesita cambiar el producto constantemente debido a los requerimientos variables del mismo. Esta metodología de desarrollo de software permite jerarquizar los requerimientos (Project backlog) para planificarlos de acuerdo a iteraciones que contienen algunos de estos requisitos (Sprint backlog), esto teniendo en cuenta una gráfica de proceso ideal con el que se puede calcular retrasos y adelantos en el trabajo (Burndown char), para finalmente ejecutar estas iteraciones (Sprints)[6]. Antes de ejecutar cada Sprint backlog, se deben definir los cambios que ha tenido el proyecto, teniendo en cuenta los requerimientos iniciales, debido a que no es recomendable efectuar cambios cuando ya haya iniciado esta iteración. Es una metodología que favorece el proyecto en gran medida debido a que, como fundamento principal de esta, se sugiere la entrega de un prototipo con las nuevas funcionalidades adicionadas en la última iteración o sprint, con lo cual se puede evidenciar los avances del proyecto por parte del cliente. Es de aclarar que las iteraciones tienen un objetivo claro sobre el cual debe ser posible medir el avance. El seguimiento exhaustivo del proceso de desarrollo y de la metodología en general aumentará la probabilidad de asemejar el producto a lo especificado en diseños posteriores.. En la Oficina asesora de Sistemas OAS de la Universidad Distrital Francisco José de Caldas se trabaja de la siguiente manera:. ● Se utiliza la herramienta de Tuleup, en donde el Scrum Master que es transversal a toda.

(46) 45. la Oficina, guía todo el proceso en compañía del Product Owner quien es una asesora contratada por la universidad particularmente para el "Sistema Integral de Información" KRONOS.. ● Se hacen las planificaciones del Sprint en las cuales se designan tareas al equipo de desarrollo, las cuales serán revisadas en el Sprint por medio de la herramienta de Tuleup.. ● Se realiza el Sprint cada 8 días según sea requerido para actualizar las tareas programadas en las planificaciones del Sprint. Las cuales se van diligenciando en la plataforma de desarrollo en Tuleup como se mencionó anteriormente.. ● Se hace el respectivo seguimiento del sprint en la reunión con periodicidad de 8 días en las cuales cada participante expone sus resultados en las tareas que le fueron asignadas comentando sus aciertos y desaciertos en la realización de las mismas.. 7.2.24. Registro de tareas y seguimiento de las mismas en herramienta Tuleap. Tuleap es una herramienta online de uso libre que permite la administración de ciclos de vida ágiles, como es SCRUM. Para comenzar a utilizar la herramienta con la metodología de desarrollo ágil, es necesario registrar todos los proyectos que serán trabajados dentro de la Oficina Asesora de Sistemas. Una vez hecho esto, se permite asociar a él el equipo de trabajo.

(47) 46. que intervendrá. De esta manera, se utiliza la plataforma para asignar las diferentes tareas a cada uno de los involucrados, especificando el tiempo para realizar su entrega. Es entonces de vital importancia que dentro de cada tarea asignada se realicen comentarios que permitan evidenciar el trabajo y los avances sobre ellas. De igual forma, se deben modificar los puntos de la historia, que brindan un estimado cuantitativo del avance sobre las tareas del sprint.. 7.2.25. Sprints semanales que evidencian el progreso de las tareas. Esta actividad consiste en reuniones cortas donde se convocan a los interesados en el modelo de negocio junto con el equipo de desarrollo. En estas reuniones se realiza la revisión de las tareas asignadas en el sprint anterior, examinando el progreso de las mismas registrado en la plataforma Tuleap. De esta manera, las tareas son marcadas por alguno de los estados asociadas a ellas (en proceso si ocurre algún inconveniente, en revisión si ya ha sido terminada pero requiere de algún tipo de corrección, o terminada si se finalizó en su totalidad). Finalmente, se asignan las nuevas tareas que serán trabajadas en la semana y cuya entrega corresponderá al siguiente sprint. Se debe tener en cuenta que la finalización de un sprint está marcada por la entrega de un producto parcial funcional..

(48) 47. 7.3. Sprints (KRONOS) En esta sección expondremos los sprints realizados durante el transcurso de la pasantía, es decir las reuniones pertinentes para el desarrollo del proyecto “desarrollo del módulo de las fuentes de financiamiento para el proyecto kronos de la Universidad Distrital Francisco José de caldas”, en cada una de ellas encontraremos las correcciones pertinentes para cada fase del proyecto, la actualización de las bases de datos, la validación procesos y procedimiento en los avances, asesoría para el manejo de transacciones y funciones con beego, los ejercicios de prueba de control de las fuentes de financiamiento, el documento análisis de fuentes de financiamiento, la creación de servicios de fuentes de financiamiento, los ajustes para el registro y consulta de fuentes de financiamiento, la integración de las fuentes de financiamiento el servicio de las fuentes de financiamiento, los ajustes para el registro y consulta de fuentes de financiamiento, la integración de las reglas al servicio fuentes de financiamiento, los ajustes al cliente fuentes de financiamiento para integrar servicios y reglas, la creación de tablas paramétricas tipo_fuente_de_financiamiento, la integración del cliente fuentes de financiamientofuncionamiento, la creación y verificación del servicio órdenes de pago para la consulta fuentes de financiamiento, la integración de las fuentes de financiamiento por CDP,CRP y OP, la validación apropiación inicial en creación de las fuentes de financiamiento, la solicitud de los servicios de CDP y CRP para la consulta de las fuentes de financiamiento. Con la finalidad de explicar a detalle se visualizaran a continuación dichos sprints y se dará una breve descripción de cada uno de ellos..

(49) 48. Fig 1. Corrección diagrama arquitectura de la información.. Se hacen las correcciones pertinentes al diagrama de arquitectura de la información y se deja la referencia en el documento de análisis solicitado por la Oficina Asesora de Sistemas de la Universidad Distrital Francisco José de Caldas que se encuentra en la descripción de la fig 1 Corrección diagrama arquitectura de la información..

(50) 49. Fig 2. Actualización BD fuentes de financiamiento. Se realiza la actualización de la Base de Datos en las tablas relacionadas a las fuentes de financiación, modificando la relación de rubros por apropiación y se extiende a dependencias, se valida la tarea por el ING. Alejandro Daza..

(51) 50. Fig 3.Reunión de avances. Se realiza una reunión de avances con el ING. Jairo ya que fue el encargado del levantamiento de requerimientos y cuenta con esta información de primera mano, de modo que se llega a la conclusión acerca del usuario, el cual pueda subir los documentos de los requisitos en la plataforma..

(52) 51. Fig 5. Seción de trabajo: revisión procedimiento de solicitud de necesidades. Se realiza una sesión de trabajo en la cual se discute sobre el procedimiento de solicitud de necesidades y se llega a un acuerdo para hacer los ajustes necesarios a la funcionalidad..

(53) 52. Fig 6.Colaboración en parametrización para ejercicio de procesos financieros. En este sprint se realiza la colaboración en la parametrización, para el ejercicio de procesos financieros creando dos nuevos conceptos en el aplicativo para el tema de cdps y compra de bienes, incluido mantenimiento, adicional a esto se crean cuatro cuentas contables para el manejo de los conceptos dentro de las fuentes de financiamiento..

(54) 53. Fig 7.Analisis de fuentes de financiamiento. En el sprint se realiza el análisis pertinente al Documento análisis con el ING. Miguel para contextualizarlo en lo que va del proyecto, se aclara el procedimiento a realizar para la creación del registro, asignaciones a las fuentes de financiamiento..

(55) 54. Fig 8.Asesoria fuentes de financiamiento. En este sprint se realiza una asesoría de fuentes de financiamiento se especifican las siguientes reuniones en planeación, teniendo en cuenta los procesos obtenidos durante el estudio de las fuentes de financiamiento, y se prepara el documento que será revisado por la oficina de planeación..

(56) 55. Fig 9.Asesoria para el manejo de transacciones y funciones con beego. Se realiza una asesoría para el manejo de transacciones y funciones con beego, que serán fundamentales en la incorporación y funcionamiento de las fuentes de financiamiento..

(57) 56. Fig 10.Modificacion modelo fuentes financiamiento. Se realizan las modificaciones pertinentes según la reunión con el ING. Alejandro Daza, para el modelo de fuentes de financiamiento y se da la ruta en la cual se puede consultar dichos cambios. Se actualizo el script para el nuevo modelo de datos en el repositorio y se hacen las pruebas pertinentes de forma local, también queda pendiente socializar estos últimos cambios con el equipo de desarrollo para la implementación del nuevo modelo para las fuentes de financiamiento..

(58) 57. Fig 11. Documento análisis fuentes de financiamiento. Se realiza la actualización del documento análisis, resolviendo y complementando las tareas expuestas en el documento de análisis, estableciendo y complementando las tareas expuestas en el documento, se adecua la información de las fuentes de financiamiento. con la última. actualización de la circular no.04 del 20 de abril de 2017 en donde se adiciona la nueva fuente 291 recursos del balance Estampilla Universidad Distrital..

(59) 58. Fig 12. Ejercicio de prueba de control de fuentes de financiamiento. Se realiza una prueba de control a las fuentes de financiamiento, en la cual se procede con la prueba de la creación de la fuente y demás procesos en Kronos de tal forma que se pueda ver la afectación presupuestal..

(60) 59. Fig 13. Creación servicio fuentes de financiamiento. Se crea el servicio de fuentes de financiamiento que permite realizar consultas y comprobaciones para los registros y reportes en las fuentes de financiamiento.. Fig 14. Ajustes para el registro y consultas de fuentes de financiamiento. Se realiza los ajustes para el registro y consultas de las fuentes de financiamiento y se deja en el kanban #18579.

(61) 60. Fig 15.Validacion de commits de los ajustes para el registro y consulta d fuentes de financiamiento. Se hace la validación de commits de los ajustes para el registro y consulta de las fuentes de financiamiento, esta validación se hace por parte del ING. Alejandro Daza.. Fig 16.Integracion de las fuentes de financiamiento en servicio fuente de financiamiento. Se valida la integración de las fuentes de financiamiento en el servicio según el commit referenciado para dicha tarea..

(62) 61. Fig 17. Ajustes para el registro y consultas de fuentes de financiamiento. Se hacen los respectivos ajustes para el registro y consulta de las fuentes de financiamiento, y se hace la validación de 3 commits relacionados en github..

(63) 62. Fig 18. Integración reglas al servicio fuentes de financiamiento. Se realiza la integración de las reglas al servicio fuentes de financiamiento y se validad el commit con el cambio solicitado..

(64) 63. Fig 19. Ajustes cliente fuentes de financiamiento para integrar servicios y reglas. Se hacen los ajustes al cliente para las fuentes de financiamiento para integrar servicios y reglas y se valida el commit por el ING. Alejandro Daza..

(65) 64. Fig 20. Creación tabla paramétrica tipo fuente financiamiento. Se realiza el modelo de acuerdo a las especificaciones del problema y se adjunta el script y los modelos asociados, incluyendo las tablas paramétricas tipo_fuente_financiamiento..

(66) 65. Fig 21. Integración cliente fuentes de financiamiento funcionamiento. Se realiza la integración del cliente a las fuentes de financiamiento, y se vincula el kanban #18862 el cual se refiere a una tarea similar..

(67) 66. Fig 22.Servicio Ordenes de pago para la consulta fuentes de financiamiento. En este kanban se solicita los servicios de órdenes de pago para la consulta de fuentes de financiamiento, se solicita con lo siguiente Fuente, Vigencia, Unidad Ejecutora..

(68) 67. Fig 23.Integracion control de la fuentes de financiamiento por CDP,CRP Y OP. Se realiza la integración control de las fuentes de financiamiento por CDP, CRP, Y OP, se adjunta los commit de los cambios realizados e imágenes de la funcionalidad de la vista para el control de las fuentes de financiamiento..

(69) 68. Fig 24. Validación apropiación inicial en creación fuentes de financiamiento. En este kanban se realiza la validación del valor de los rubros distribuidos en todas las fuentes de financiamiento que se va crear, El valor del rubro distribuido en las fuentes y el valor del nuevo monto del rubro en una fuente de financiamiento nueva no puede superar el valor de la apropiación inicial..