Análisis, Diseño y Desarrollo de una Aplicación Web para el Módulo de Gestión del Sistema Contractual de Docentes por Vinculación Especial

Texto completo

(1)Análisis, diseño y desarrollo de una aplicación web para el módulo de gestión del sistema contractual de docentes por vinculación especial Proyecto de grado para optar al tı́tulo de Ingeniero de Sistemas. Realizado por:. Mauricio Rincón Curaca & Marco Stiven Sastoque Mahecha. Bajo la dirección de Alejandro Paolo Daza Corredor. Universidad Distrital Francisco José de Caldas Facultad de Ingenierı́a Bogotá 2017.

(2) Resumen El presente trabajo describe el proyecto de grado para optar al tı́tulo de Ingeniero de Sistemas para los estudiantes Mauricio Rincón Curaca y Marco Stiven Sastoque Mahecha de la Universidad Distrital Francisco José de Caldas, dentro del documento se define el problema a resolver representado por la creación de un módulo para la gestión de contratación de docentes por vinculación especial, para la justificación de la necesidad e importancia de la implementación del proyecto se describen las deficiencias del modelo actual del proceso de contratación, y se determinan las ventajas y beneficios obtenidos del desarrollo de un sistema de software que permita garantizar un nuevo modelo optimizado y con una mayor integridad en el flujo de la información. En el trabajo se definen también algunos conceptos básicos para el desarrollo del proyecto relacionados a distintos elementos referenciales, teóricos y conceptuales como el modelo de contratación usado actualmente por la universidad, la descripción de la metodologı́a propuesta para la realización del proyecto (SCRUM), las principales caracterı́sticas de las herramientas visualizadas a utilizar durante el proceso de desarrollo entre otros elementos que permiten contextualizar la situación de partida para la posterior ejecución del proyecto. En el trabajo se plantean las herramientas de hardware y software definidas para la realización exitosa del proyecto, además se determinan los recursos humanos, técnicos, tecnológicos e institucionales necesarios, los recursos económicos del proyecto se plantean en una visualización del presupuesto necesario, finalmente se determina el cronograma de las actividades necesarias para la ejecución del proyecto en los tiempos inicialmente determinados (5 meses). El proyecto representa un importante beneficio para la Universidad Distrital Francisco José de Caldas, debido a que actualmente no existe ninguna aplicación que permita gestionar la contratación de docentes por vinculación especial, mediante el proyecto de software planteado en este proyecto se busca simplificar el proceso de contratación, añadiendo una serie de caracterı́sticas que permitan garantizar la integridad del proceso y optimizar los recursos utilizados para el mismo..

(3) Durante la fase de desarrollo del proyecto, se documentan los principales componentes, entre ellos la arquitectura de datos, el modelo de datos, la implementación de las reglas del modelo de negocio, la fase de pruebas funcionales del sistema y la implementación de los servicios web y la interacción entre ellos. Finalmente los resultados obtenidos comprueban la optimización del modelo de negocio a partir del software implementado, permitiendo determinar el cumplimiento de los objetivos planteados de acuerdo con el conjunto de pruebas realizadas. Con la realización del proyecto se busca la adquisición de una experiencia fructı́fera para el crecimiento personal y profesional, permitiendo adquirir un extenso conjunto de nuevas habilidades de gran importancia para nuestro desarrollo como ingenieros de sistemas.. 2.

(4) Agradecimientos Al docente y directordel proyecto Alejandro Paolo Daza Corredor por su acompañamiento y ayuda durante la realización de este proyecto de grado, además de habernos provisto de capacitaciones para el conocimiento las herramientas utilizadas para el diseño y desarrollo de la aplicación base del proyecto, prmiteindo de esta manera abordar la ejecución del mismo con mayor facilidad e incrementando nuestros recursos en la formación como ingenieros de sistemas, reconociendo de esta manera su aporte el gran impulso que ha dado durante nuestra carrera universitaria. Por otro lado agradecemos a la oficina asesora de sistemas perteneciente a la universidad distrital Francisco José de Caldas por habernos permitido el uso de las herramientas necesarias durante el transcurso delaplaneación y ejecución del proyecto.. i.

(5) Indice general 1. Introducción. 1. 2. Planteamiento del problema 2.1. Descripción del problema . . . . . . . . . . . . . . . . . . . . . 2.2. Formulación del problema . . . . . . . . . . . . . . . . . . . .. 2 2 3. 3. Objetivos 3.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . 3.2. Objetivos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . .. 4 4 4. 4. Justificación. 5. 5. Alcances y Lı́mites 5.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 6 6 6. 6. Marco teórico 6.1. Docentes por Vinculación Especial . . . . . . . . . . . . . . . 6.1.1. Dedicación Docentes Vinculación Especial . . . . . . . 6.1.1.1. Ocasionales . . . . . . . . . . . . . . . . . . . 6.1.1.2. Hora cátedra . . . . . . . . . . . . . . . . . . 6.1.1.3. Visitantes . . . . . . . . . . . . . . . . . . . . 6.1.1.4. Expertos . . . . . . . . . . . . . . . . . . . . 6.1.2. Clasificación Docentes Vinculación Especial . . . . . . 6.1.2.1. Auxiliar . . . . . . . . . . . . . . . . . . . . . 6.1.2.2. Asistente . . . . . . . . . . . . . . . . . . . . 6.1.2.3. Asociado . . . . . . . . . . . . . . . . . . . . 6.1.2.4. Titular . . . . . . . . . . . . . . . . . . . . . 6.2. Gestión de contratación y compras de la Universidad Distrital 6.2.1. Proyecto Argo/OAS . . . . . . . . . . . . . . . . . . . 6.2.2. Proceso contractual (DVE) . . . . . . . . . . . . . . . .. 7 7 7 7 8 8 8 8 8 9 9 10 10 10 10. ii.

(6) 6.3. Régimen Salarial y prestacional de docentes . . . . . . . . . . 6.4. Metodologı́a Scrum . . . . . . . . . . . . . . . . . . . . . . . . 6.4.1. Manifiesto ágil . . . . . . . . . . . . . . . . . . . . . . 6.4.2. ¿Qué es Scrum? . . . . . . . . . . . . . . . . . . . . . . 6.4.3. Roles Scrum . . . . . . . . . . . . . . . . . . . . . . . . 6.4.3.1. Dueño del producto . . . . . . . . . . . . . . 6.4.3.2. Equipo de desarrollo . . . . . . . . . . . . . . 6.4.3.3. ScrumMaster . . . . . . . . . . . . . . . . . . 6.4.4. Elementos Scrum . . . . . . . . . . . . . . . . . . . . . 6.4.4.1. Product Backlog . . . . . . . . . . . . . . . . 6.4.4.2. Sprint Backlog . . . . . . . . . . . . . . . . . 6.4.4.3. Incremento . . . . . . . . . . . . . . . . . . . 6.4.5. Dinámica . . . . . . . . . . . . . . . . . . . . . . . . . 6.4.5.1. Iteraciones . . . . . . . . . . . . . . . . . . . 6.4.5.2. Reunión de Planificación de Sprint . . . . . . 6.5. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1. AngularJS . . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1.1. ¿Por qué utilizar AngularJS en el proyecto? . 6.5.2. Go (Lenguaje de programación) . . . . . . . . . . . . . 6.5.2.1. Beego . . . . . . . . . . . . . . . . . . . . . . 6.5.2.2. ¿Por qué utilizar Go en el proyecto? . . . . . 6.5.3. PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . 6.5.3.1. Caracterı́sticas de PostgreSQL . . . . . . . . 6.5.3.2. Limitaciones del PostgreSQL . . . . . . . . . 6.5.3.3. ¿Por qué utilizar PostgreSQL en el proyecto? 6.5.4. Lenguaje unificado de modelado (UML) e Ingenierı́a de Software . . . . . . . . . . . . . . . . . . . . . . . . 6.5.4.1. Herramientas CASE . . . . . . . . . . . . . . 6.5.4.2. ¿Por qué utilizar UML en el proyecto? . . . . 6.5.5. Web service (Servicios web) . . . . . . . . . . . . . . .. 11 13 13 14 14 14 14 15 15 15 16 16 16 16 16 17 17 18 18 19 19 20 21 22 22 23 23 24 25. 7. Metodologı́a 26 7.1. Definición de la metodologı́a . . . . . . . . . . . . . . . . . . . 26 7.1.1. Metodologı́a SCRUM . . . . . . . . . . . . . . . . . . . 26 8. Recursos 8.1. Recursos humanos . . . . . . . 8.2. Recurso técnicos y tecnológicos 8.2.1. Recursos de Software . . 8.3. Recursos institucionales . . . .. iii. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. . . . .. 30 30 31 31 31.

(7) 9. Presupuesto. 32. 10.Cronograma. 34. 11.Desarrollo 11.1. Modelo actual del proceso de vinculación especial 11.1.1. Diagrama de procesos . . . . . . . . . . . 11.1.2. Diagrama de arquitectura de alto nivel . . 11.2. Arquitectura de datos . . . . . . . . . . . . . . . 11.3. Modelo de datos . . . . . . . . . . . . . . . . . . . 11.3.1. Tablas . . . . . . . . . . . . . . . . . . . . 11.3.1.1. vinculacion docente . . . . . . . . 11.3.1.2. resolucion . . . . . . . . . . . . . 11.3.1.3. tipo resolucion . . . . . . . . . . 11.3.1.4. componente resolucion . . . . . . 11.3.1.5. resolucion estado . . . . . . . . . 11.3.1.6. estado resolucion . . . . . . . . . 11.3.1.7. resolución vinculacion docente . . 11.3.1.8. dedicacion . . . . . . . . . . . . . 11.3.1.9. punto salarial . . . . . . . . . . . 11.3.2. Tablas utilizadas del modelo previo . . . . 11.3.2.1. contrato general . . . . . . . . . 11.3.2.2. estado contrato . . . . . . . . . . 11.3.2.3. contrato estado . . . . . . . . . . 11.3.2.4. parametros . . . . . . . . . . . . 11.3.2.5. unidad ejecucion . . . . . . . . . 11.3.2.6. informacion persona natural . . . 11.3.2.7. informacion proveedor . . . . . . 11.3.2.8. ordenador gasto . . . . . . . . . . 11.3.2.9. salario minimo . . . . . . . . . . 11.3.2.10.unidad ejecutora . . . . . . . . . 11.3.2.11.dependencia . . . . . . . . . . . . 11.3.2.12.dependencia padre . . . . . . . . 11.3.2.13.tipo dependencia . . . . . . . . . 11.3.2.14.dependencia tipo dependencia . . 11.3.2.15.tipo categora . . . . . . . . . . . 11.3.2.16.categoria persona . . . . . . . . . 11.3.2.17.trabajos investigacion . . . . . . 11.3.2.18.investgacion . . . . . . . . . . . . 11.3.2.19.formacion academica . . . . . . . 11.3.2.20.nivel formacion . . . . . . . . . . iv. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39 39 39 41 41 41 43 43 43 43 43 44 44 44 44 45 45 45 45 45 46 46 46 46 46 46 46 47 47 47 47 47 47 48 48 48 48.

(8) 11.3.2.21.titulo . . . . . . . . . . . . . . . 11.3.2.22.experiencia docente . . . . . . . . 11.3.2.23.cursos . . . . . . . . . . . . . . . 11.4. Interfaces de programación de aplicaciones (api) . 11.4.1. Administrativa crud api . . . . . . . . . . 11.4.2. Administrativa mid api . . . . . . . . . . . 11.4.3. Ruler api . . . . . . . . . . . . . . . . . . 11.4.4. Kyron crud api . . . . . . . . . . . . . . . 11.5. Reglas de negocio Golog (Go) . . . . . . . . . . . 11.6. Software . . . . . . . . . . . . . . . . . . . . . . . 11.6.1. Gestión de resoluciones . . . . . . . . . . . 11.6.1.1. Visualización de la resolución . . 11.6.1.2. Adición de docentes . . . . . . . 11.6.1.3. Edición de la resolución . . . . . 11.6.2. Administración de resoluciones . . . . . . 11.6.2.1. Expedición de la resolución . . . 11.6.3. Cancelación y restauración de resoluciones 11.7. Pruebas . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. 48 48 48 49 49 50 50 50 50 57 57 59 60 65 70 70 73 75. 12.Resultados. 76. 13.Trabajos futuros. 78. 14.Conclusiones. 80. Referencias. 82. v.

(9) Indice de figuras 7.1. Tarea inscrita en Tuleap. . . . . . . . . . . . . . . . . . . . . . 27 7.2. Encargados de la tarea y los archivos adjuntos. . . . . . . . . . 28 7.3. Comentarios del progreso de la tarea. . . . . . . . . . . . . . . 29 10.1. Cronograma 10.2. Cronograma 10.3. Cronograma 10.4. Cronograma. de de de de. actividades actividades actividades actividades. del del del del. . . . .. . . . .. 35 36 37 38. 11.1. Proceso de contratación de docentes por vinculación especial. 11.2. Diagrama de arquitectura de alto nivel . . . . . . . . . . . . 11.3. Modelo de base de datos (tablas especı́ficas del proyecto) . . 11.4. Diagrama de componentes . . . . . . . . . . . . . . . . . . . 11.5. Lista de resoluciones (Vista: Gestión de resoluciones). . . . . 11.6. Generación de la resolución. . . . . . . . . . . . . . . . . . . 11.7. Nueva resolución . . . . . . . . . . . . . . . . . . . . . . . . 11.8. Visualización de la resolución. . . . . . . . . . . . . . . . . . 11.9. Panel de hojas de vida. . . . . . . . . . . . . . . . . . . . . . 11.10.Información básica del contrato. . . . . . . . . . . . . . . . . 11.11.Horas semanales para las dedicaciones. . . . . . . . . . . . . 11.12.Número de vinculaciones. . . . . . . . . . . . . . . . . . . . . 11.13.Valor del contrato para el docente seleccionado. . . . . . . . 11.14.Desvinculación de un docente. . . . . . . . . . . . . . . . . . 11.15.Información personal del docente. . . . . . . . . . . . . . . . 11.16.Formación académica del docente . . . . . . . . . . . . . . . 11.17.Experiencia laboral del docente . . . . . . . . . . . . . . . . 11.18.Trabajos de investigación del docente . . . . . . . . . . . . . 11.19.Formato de la resolución. . . . . . . . . . . . . . . . . . . . . 11.20.Vista de la resolución. . . . . . . . . . . . . . . . . . . . . . 11.21.Artı́culos y parágrafos de la resolución . . . . . . . . . . . . 11.22.Nuevo artı́culo . . . . . . . . . . . . . . . . . . . . . . . . . . 11.23.Nuevo parágrafo . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . .. 40 41 42 49 58 58 59 59 60 60 61 61 62 63 63 64 64 65 66 67 68 68 69. vi. proyecto proyecto proyecto proyecto. -. Mes Mes Mes Mes. 1 2 3 4. . . . .. . . . .. . . . .. . . . .. . . . .. . . . ..

(10) 11.24.Edición de los artı́culos y parágrafos. . . . . . . . . . . . 11.25.Cambios guardados con éxito. . . . . . . . . . . . . . . . 11.26.Administración de la resolución. . . . . . . . . . . . . . . 11.27.Información del contrato en el momento de la expedición. 11.28.Información básica del contrato. . . . . . . . . . . . . . . 11.29.Disponibilidad de la resolución. . . . . . . . . . . . . . . 11.30.Justificación y observaciones de la resolución. . . . . . . 11.31.Expedición de la resolución. . . . . . . . . . . . . . . . . 11.32.Expedición realizada con éxito. . . . . . . . . . . . . . . 11.33.Lista de resoluciones en administración de resoluciones. . 11.34.Cancelación de la resolución. . . . . . . . . . . . . . . . . 11.35.Restaurar la resolución . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 69 70 70 71 71 71 72 72 73 73 74 74. 12.1. Hoja de cálculo para los docentes . . . . . . . . . . . . . . . . 76 12.2. Resultado de la vista de la resolución . . . . . . . . . . . . . . 77. vii.

(11) Indice de Tablas 6.1. Limitaciones de PostgreSQL . . . . . . . . . . . . . . . . . . . 22 8.1. Recursos humanos del proyecto . . . . . . . . . . . . . . . . . 30 8.2. Recursos técnicos y tecnológicos del proyecto . . . . . . . . . . 31 9.1. Presupuesto para el proyecto . . . . . . . . . . . . . . . . . . . 33 14.1. Descripción tabla vinculacion docente . . . . . . 14.2. Descripción tabla resolucion . . . . . . . . . . . 14.3. Descripción tabla tipo resolucion . . . . . . . . 14.4. Dscripción tabla componente resolucion . . . . . 14.5. Descripción tabla resolucion estado . . . . . . . 14.6. Descripción tabla estado resolucion . . . . . . . 14.7. Descripción tabla resolucion vinculacion docente 14.8. Descripción tabla dedicacion . . . . . . . . . . . 14.9. Descripción tabla punto salarial . . . . . . . . .. viii. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. 85 86 86 87 87 87 88 88 89.

(12) Capı́tulo 1 Introducción La Universidad Distrital Francisco José de Caldas cuenta en la actualidad con un sistema de contratación para docentes de vinculación especial eficaz, el proceso de contratación termina con los docentes que van a ser contratados los cuales pasan a ser incluidos en la nueva resolución que se genera para cada semestre académico; Para la realización de dicha resolución es necesario contar con cierta información del docente para ası́ poder generar un valor para su contrato, además de su respectiva clasificación entre los tipos de docentes de la universidad, el problema está en el manejo de toda la información necesaria, puesto que los volúmenes de dicha información son grandes. Para realizar la consulta de alguna resolución referente a la contratación de docentes se necesita buscar entre grandes cantidades de papeles con distinta variedad de información con el fin de encontrarla, esto provoca que el procedimiento de contratación o consulta se vea seriamente ralentizado. Actualmente a través del uso de técnicas modernas como los servicios web se pueden obtener varias y distintas herramientas para solucionar los procesos de consulta o creación de elementos de documentación como en el caso de una resolución, y las tecnologı́as que actualmente se usan permiten que el tráfico de datos sea más rápido y eficiente, junto con la optimización de distintos recursos, además permiten una utilización en una amplia gama de plataformas por lo que se puede adaptar a diferentes sistemas. El propósito del presente documento es exponer el sistema basado en servicios web para el proceso de contractual de los docentes de vinculación especial de la Universidad Distrital ”Francisco José de Caldas, que permite mediante el desarrollo optimizar la creación y consulta de las resoluciones necesarias para dicho proceso, mejorando sustancialmente el modelo actual agregando nuevas caracterı́sticas que simplifican el proceso total realizado. 1.

(13) Capı́tulo 2 Planteamiento del problema 2.1.. Descripción del problema. Dentro de la Universidad Distrital Francisco José de Caldas (Bogotá, Colombia), se pueden entender dos tipos de docentes a partir del artı́culo sexto del Estatuto Docente: “Clasificación. Los docentes de la Universidad Distrital Francisco José de Caldas según el tipo de vinculación, se clasifican de la siguiente manera: Docentes de carrera Docentes de vinculación especial” El modelo para el proceso de contratación varı́a dependiendo de la clasificación especı́fica dentro de la cual se realiza la vinculación de los docentes a la universidad. Actualmente el proceso de contratación de docentes de vinculación especial cuenta con un tratamiento y flujo de la información ineficiente, disponiendo además una alta independencia en la metodologı́a utilizada por cada una de las facultades que conforman la institución para la realización del proceso, con base en este conjunto de problemas se pueden determinar diversas dificultades que impiden un control adecuado de vinculación de docentes dentro de la universidad, el objetivo es definir concretamente los elementos del proceso de negocio que deben ser sistematizados y auditados para el mejoramiento y optimización del modelo actual, las principales dificultades y deficiencias identificadas del proceso se enumeran a continuación. 2.

(14) 1. El proceso actual no cuenta con un sistema que permita garantizar la integridad del proceso a partir de unas reglas definidas y verificadas. 2. La metodologı́a utilizada para la vinculación de docentes varı́a en algunos subprocesos dependiendo de la facultad donde se realiza la contratación. 3. Los datos del proceso de vinculación no se almacenan de forma sistematizada, lo que dificulta el análisis y supervisión de la información.. 2.2.. Formulación del problema. Ante las problemáticas descritas anteriormente para el proceso contractual de docentes por vinculación especial en la Universidad Distrital “Francisco José de Caldas”, ¿Cómo se puede sistematizar la información necesaria para el proceso de contratación y obtener la generación automática de la resolución expedida semestralmente?. 3.

(15) Capı́tulo 3 Objetivos 3.1.. Objetivo General. Realizar el análisis, diseño y desarrollo de un sistema para la gestión y control del proceso de contratación de docentes mediante la modalidad de vinculación especial dentro de la Universidad Distrital “Francisco José de Caldas”.. 3.2.. Objetivos Especı́ficos. Diseñar una arquitectura de la información para el proceso de contratación de docentes por vinculación especial. Desarrollar una base de reglas que permitan el control del modelo de negocio. Diseñar y desarrollar las vistas del sistema para los distintos usuarios del aplicativo. Desarrollar un sistema para el almacenamiento y consumo de información mediante servicios web. Desarrollar una plantilla para la resolución por la cual se vinculan docentes en la modalidad de vinculación especial.. 4.

(16) Capı́tulo 4 Justificación El desarrollo del aplicativo para la sistematización del proceso de contratación de docentes de vinculación especial dentro de la universidad Distrital requiere de un proceso de mejoramiento urgente, debido a que el modelo utilizado actualmente a pesar de funcionar eficazmente, cuenta con varias deficiencias en el tratamiento y flujo de la información, además dispone de una alta independencia en la metodologı́a utilizada por cada una de las facultades que conforman la institución para la realización del proceso, con base en este conjunto de problemas se pueden determinar diversas dificultades que impiden un control adecuado de contratación dentro de la universidad, problemas que buscan ser minimizados mediante la ejecución del proyecto realizado en el presente documento. Con la sistematización de la información se pueden prevenir un importante conjunto de fallos y se puede optimizar los procesos de contratación en diversos aspectos además de la implementación de reglas que permitan asegurar la cohesión e integridad de los subprocesos que conforman el modelo de negocio del proceso contractual.. 5.

(17) Capı́tulo 5 Alcances y Lı́mites 5.1.. Alcances. En este proyecto se pretende diseñar y desarrollar un sistema para la Universidad Distrital Francisco José de Caldas en la tarea de gestionar el proceso de contratación de docentes por vinculación especial en sus diferentes categorı́as, mediante la implementación de reglas acogidas por la legislación Colombiana y del Ministerio de Educación. Algunos elementos que se plantea añadir y mejorar con el nuevo sistema dentro del modelo actual del proceso de contratación de docentes por vinculación especial se basan en el desarrollo de un sistema de reglas que permita garantizar la integridad del proceso. El código fuente del proyecto y los recursos adicionales utilizados serán debidamente documentados para facilitar posteriores modificaciones al sistema desarrollado.. 5.2.. Limitaciones. En el proceso de análisis del proyecto se realizara la documentación respectiva, se debe tener en cuenta que el plazo máximo es de cuatro (4) meses. El software se realizará siguiendo la metodologı́a ágil Scrum, se realizarán pruebas de funcionamiento aunque no se llegará a la implantación final por parte del equipo desarrollador, entregando el software terminado para su posterior implantación a cargo de la Oficina Asesora de Sistemas (OAS).. 6.

(18) Capı́tulo 6 Marco teórico 6.1. 6.1.1.. Docentes por Vinculación Especial Dedicación Docentes Vinculación Especial. Según el estatuto del profesor de la Universidad Distrital Francisco José de Caldas, en el artı́culo 13 se establece que los docentes de vinculación especial pueden ser [1]: Ocasionales: Tiempo completo y medio tiempo De hora cátedra Visitantes Expertos. A continuación se presenta la definición de los distintos tipos de docentes en base al estatuto del profesor de la Universidad Distrital: 6.1.1.1.. Ocasionales. Los docentes ocasionales no son empleados públicos docentes de régimen, ni pertenecen a la carrera docente y su dedicación podrá ser de tiempo completo (40 horas semanales) o medio tiempo (20 horas semanales), hasta por un periodo inferior a un (1) año, cuando la Universidad lo requiera. Sus servicios son reconocidos de conformidad con la Ley (artı́culo 15).. 7.

(19) 6.1.1.2.. Hora cátedra. Los docentes de Hora cátedra vinculados a la Universidad Distrital “Francisco José de Caldas” no son empleados públicos docentes del régimen especial, no pertenecen a la carrera docente y su vinculación se hará de conformidad con la Ley (artı́culo 14). 6.1.1.3.. Visitantes. Son docentes visitantes aquellos de reconocida idoneidad y que colaboran en la Universidad Distrital ”Francisco José de Caldas” en virtud de convenios con instituciones nacionales o extranjeras de carácter cultural, artı́stico, filosófico, cientı́fico, humanı́stico, tecnológico o técnico en los campos propios de su especialidad (artı́culo 16). 6.1.1.4.. Expertos. Son docentes expertos aquellas personas sin tı́tulo universitario, pero de reconocida idoneidad en un área o campo determinado del saber o de la cultura, vinculados a la universidad para la enseñanza de las artes, la técnica o las humanidades. El Consejo Académico recomienda al Consejo Superior Universitario, la vinculación de estos docentes (artı́culo 17).. 6.1.2.. Clasificación Docentes Vinculación Especial. La resolución 317 de 2006 de la Universidad Distrital Francisco José de Caldas establece en el artı́culo 1 que los docentes que prestan servicios dentro de la universidad se clasifican en cuatro categorı́as [2]: Auxiliar Asistente Asociado Titular Los requisitos necesarios para pertenecer a cada una de estas categorı́as se expresan en el artı́culo 2 de la resolución 317 de 2006 como se describe a continuación: 6.1.2.1.. Auxiliar. Para ser docente auxiliar se requiere acreditar tı́tulo profesional universitario de Pregrado. 8.

(20) 6.1.2.2.. Asistente. Para ser docente asistente se requiere: 1. Acreditar tı́tulo profesional de Pregrado. 2. Acreditar estudios de postgrado en los niveles de especialización, maestrı́a o doctorado. 3. Acreditar dos (2) años de experiencia universitaria calificada en dedicación de tiempo completo, o su equivalente según este estatuto, en instituciones reconocidas por el Gobierno Nacional. 4. Presentar y sustentar ante un jurado designado por el decano, un trabajo que signifique aporte al área o disciplina académica en que se desempeñe o concurse, o en su lugar, presentar un tı́tulo de postgrado en la misma área del saber. 5. Tener resultados de la evaluación docente como mı́nimo en el rango de aceptable. 6.1.2.3.. Asociado. Para ser docente asociado se requiere: Acreditar tı́tulo profesional universitario de Pregrado. Acreditar tı́tulo de maestrı́a o doctorado, en el área del saber en el cual se desempeña. Acreditar seis (6) años de experiencia universitaria calificada en dedicación de tiempo completo, o su equivalente según este estatuto, en instituciones reconocidas por el Gobierno Nacional. Presentar y sustentar ante un jurado conformado por dos pares externos, un trabajo diferente a su tesis de grado, que constituya un aporte significativo a la docencia, a la ciencia, el arte o las humanidades en el área del saber o disciplina académica en que se desempeña. Obtener como mı́nimo el rango de aceptable en la evaluación docente de la Universidad.. 9.

(21) 6.1.2.4.. Titular. Para ser docente titular se requiere: Tener tı́tulo profesional universitario de Pregrado. Tener tı́tulo de maestrı́a o doctorado. Acreditar diez (10) años de experiencia universitaria calificada en dedicación de tiempo completo, o su equivalente según este estatuto, en instituciones reconocidas por el Gobierno Nacional. Presentar y sustentar ante un jurado conformado por dos pares externos, un trabajo diferente a su tesis de grado, que constituya un aporte significativo a la docencia, a la ciencia, el arte o las humanidades en el área del saber o disciplina académica en que se desempeña. Obtener como mı́nimo el rango de aceptable en la evaluación docente de la Universidad.. 6.2. 6.2.1.. Gestión de contratación y compras de la Universidad Distrital Proyecto Argo/OAS. El proyecto Argo es un sistema de gestión de gestión de contratación y compras para la Universidad Distrital ”Francisco José de Caldas”, una aplicación que permite mantener un registro de los contratos realizados por la Universidad elaborados entre las dependencias de la Sección de Compras, Oficina Asesora Jurı́dica e idexud. Con el fin de llevar un único consecutivo y reporte de dichos registros [5]. Actualmente el proyecto es el encargado de los procesos contractuales de la universidad.. 6.2.2.. Proceso contractual (DVE). En el proceso de contratación de docentes por vinculación especial dentro de la Universidad Distrital Francisco José de Caldas participan principalmente seis (6) áreas funcionales de la institución:. 10.

(22) Consejo superior: Es el máximo órgano de dirección y gobierno de la Universidad, está conformado por miembros como el alcalde mayor de la ciudad, el ministro de educación, representante del presidente, representante de las directivas académicas, ex rector de la Universidad, egresado graduado de la Universidad, representante del sector productivo y rector de la universidad. Decanatura: Es la máxima dependencia de cada facultad correspondiente a la universidad, Cumple con varias funciones que permiten asegurar la administración y el buen funcionamiento de todos los proyectos curriculares de la facultad especı́fica. Coordinación: Es el comité que tiene como función principal asegurar la calidad de los proyectos curriculares y de la institución, buscando el mejoramiento continuo de los componentes de la universidad. Consejo de facultad: Es la máxima dirección de cada Facultad perteneciente a la universidad, entre sus funciones está contribuir como un órgano permanente con capacidad decisoria sobre los elementos relacionados al desarrollo funcional de la facultad especı́fica. Recursos humanos: Es la dependencia de la universidad encargada de asegurar la adecuada administración y desarrollo del talento humano dentro de la institución. Docencia: Es la dependencia de la universidad encargada de garantizar el desarrollo de las actividades académicas y administrativas relacionadas con los docentes vinculados a la universidad, bajo las diferentes modalidades.. 6.3.. Régimen Salarial y prestacional de docentes. El decreto 1279 de Junio 19 de 2002, el gobierno Nacional estableció un nuevo régimen salarial y prestacional para los docentes de las Universidades estatales u oficiales del Orden Nacional, Departamental, Municipal y Distrital (Artı́culos 3 y 4). Dentro del decreto 1279 de Junio 19 de 2002 en el artı́culo 3 se establece “Los profesores ocasionales no son empleados públicos docentes de régimen 11.

(23) especial ni pertenecen a la carrera profesoral y, por consiguiente, sus condiciones salariales y prestacionales no están regidas por el presente Decreto. No obstante, su vinculación se hace conforme a las reglas que define cada Universidad, con sujeción a lo dispuesto por la ley 30 de 1992 y demás disposiciones constitucionales y legales vigentes.”, además el artı́culo 4 establece “La remuneración de los empleados públicos docentes de medio tiempo será proporcional a su dedicación”[3]. El artı́culo 4 1279 de Junio 19 de 2002 establece también: “Los profesores de hora-cátedra de las Universidades estatales u oficiales distintas a la Universidad Nacional de Colombia no son empleados públicos docentes de régimen especial ni pertenecen a la carrera profesoral y, por consiguiente, sus condiciones salariales y prestacionales no están regidas por el presente Decreto, sino por las reglas contractuales que en cada caso se convengan, conforme a las normas internas de cada Universidad, con sujeción a lo dispuesto en las disposiciones constitucionales y legales.” El acuerdo 005 de Julio 27 de 2001 fija el valor de la hora cátedra, para los docentes que prestarán sus servicios en los Posgrados de la Universidad Distrital Francisco José de Caldas, teniendo como base de liquidación el salario mı́nimo mensual legal vigente. Por su parte el acuerdo 006 de 2002 establece las reglas del valor de los contratos a las que se ven sujetos a los pagos de los docentes de planta que dictan clases de posgrado dentro de la Universidad Distrital. Respecto a la sección de docentes de vinculación especial de pregrado, el acuerdo 002 de 2003 establece factores de pago para docentes con dedicación de medio tiempo ocasional y tiempo completo ocasional. Finalmente para los docentes de hora cátedra honorarios y hora cátedra prestaciones en pregrado el acuerdo 012 de 2002 establece las reglas para el cálculo del valor del salario en base al valor del punto vigente. Siguiendo el marco legal descrito, se puede calcular el valor del contrato, teniendo en cuenta la adición de prestaciones, la cual aplica para todas las contrataciones, excepto para las vinculación bajo la dedicación de hora cátedra honorarios, el valor total de las prestaciones se estima en un 25,03703 % sobre el valor del contrato.. 12.

(24) 6.4. 6.4.1.. Metodologı́a Scrum Manifiesto ágil. Las metodologı́as agiles surgieron como una alternativa para el modelo de capacidad y madurez (CMMI), un modelo de gestión clásico considerado como rı́gido. En el modelo ágil el desarrollo del software se va realizando dinámicamente y van cambiando las necesidades con iteración en el ciclo de vida de la metodologı́a. Se tienen en cuenta 4 valores: Valorar a las personas y las interacciones entre ellas por sobre los procesos y las herramientas El principal factor para que el proyecto de software se desarrolle con éxito son las personas, puesto que son ellas las que llevaran a cabo el proceso de desarrollo. Scrum propone que las personas del equipo de desarrollo construyan su propio entorno y procesos en base a sus necesidades.. Valorar el software funcionando por sobre la documentación detallada La documentación en los proyectos es un resultado intermedio y en realidad no dan valor al usuario o cliente, se convierten en una ilusión de progreso. Por lo que en Scrum se tiene como regla no producir documentos a menos que sean necesarios para alguna decisión importante.. Valorar la colaboración con el cliente por sobre la negociación de contratos Se propone que el cliente este en constate comunicación con el equipo de desarrollo, esta colaboración asegura el éxito del proyecto.. Valorar la respuesta a los cambios por sobre el seguimiento estricto de los planes La planificación del proyecto debe ser abierta y flexible, esto supondrá que el proyecto pueda responder mejor a los cambios a lo largo del proyecto, ya sean de tecnologı́a o de requisitos, etc[6, pág 7].. 13.

(25) 6.4.2.. ¿Qué es Scrum?. En Scrum en lugar de proporcionar descripciones completas y detalladas de cómo se va a hacer el proyecto, en lugar de eso el equipo de desarrollo toma sus decisiones puesto que ellos son los que saben cómo resolver mejor el problema. Es por esto que en el desarrollo de Scrum, en cada reunión de planificación o sprint se describen el conjunto de caracterı́sticas que se desarrollaran en el próximo sprint, a diferencia de la mayorı́a de metodologı́as en donde se presenta los criterios de salida y de entrada. En Scrum no existe un lı́der global que decida que hará cada persona o como resolverá un problema, en lugar de eso cada equipo de auto-organiza y decide que tareas resolverá. En Scrum un equipo es cruz funcional, lo que significa que todo el mundo es necesario para llevar una idea a la implementación[7].. 6.4.3.. Roles Scrum. En Scrum existen 3 roles principales: 6.4.3.1.. Dueño del producto. El Dueño del Producto es el responsable de identificar las funcionalidades del producto, decidiendo cuales deberı́an ir al principio para el siguiente Sprint y priorizando en una lista. En algunas ocasiones el DP y el cliente son la misma persona; esto es muy común en aplicaciones internas. En otras, el cliente podrı́a ser muchas personas con diferentes necesidades en este caso el Dueño del producto Seri a el jefe de producto. Es importante resaltar que en Scrum existe una única persona que tiene la autoridad final de Dueño de producto. 6.4.3.2.. Equipo de desarrollo. El equipo construye el producto que va a usar el cliente, por ejemplo un sitio web. El equipo es multi-funciona ya que tiene todas las habilidades necesarias para entregar un producto en cada sprint y además es auto-organizado, puesto que cuenta con un alto nivel de autonomı́a y responsabilidad. El equipo en Scrum para un producto de software podrı́a incluir analistas, desarrolladores, diseñadores de interface, y testers. El equipo desarrolla el producto y da ideas al Dueño del Producto de cómo hacer el producto.. 14.

(26) En Scrum, el equipo deberı́a estar dedicado al 100 % al trabajo en el producto durante el Sprint; intentando evitar hacer varias tareas en diferentes productos o proyectos. Dado que el equipo hace todo el trabajo (planificación, análisis, programación y pruebas) para una funcionalidad completa centrada en el cliente, a los equipos de Scrum también se les llama equipos por funcionalidades. 6.4.3.3.. ScrumMaster. El Scrum Master hace lo que sea necesario para ayudar a que el equipo de desarrollo para que tenga éxito. El Scrum Master no es el jefe del equipo o jefe de proyecto. El Scrum Master se asegura de que todo el mundo en el equipo incluyendo al Dueño del producto, entienda y siga las prácticas de Scrum, y ayuda a llevar a la organización, a través de los cambios necesarios y frecuentemente difı́ciles, a conseguir el éxito con el desarrollo ágil[8, pág 6].. 6.4.4.. Elementos Scrum. Los elementos que forman el Scrum son: Product Backlog: lista de necesidades del cliente. Sprint Backlog: lista de tareas que se realizan en un Sprint. Incremento: parte añadida o desarrollada en un Sprint, es una parte terminada y totalmente operativa. 6.4.4.1.. Product Backlog. Aquı́ se almacenan en forma de lista todos los requisitos y funcionalidades en orden de prioridad. Estos requisitos o funcionalidades serán los que tendrá el producto final o los irán adquiriendo en las sucesivas iteraciones. Las tres caracterı́sticas principales de la lista de objetivos serán: En la lista se indican las posibles iteraciones y los releases(lanzamientos) que se han indicado al cliente. La lista ha de incluir los posibles riesgos e incluir las tareas necesarias para solventarlos. Contendrá los objetivos del producto, y el valor que le da el cliente y el coste estimado, priorizando por valor y coste. 15.

(27) En el primer sprint es necesario que se definan cuáles van a ser los objetivos del producto y tener la lista de requisitos ya definida. Después de definidos los requisitos se tiene que acordar cuando un objetivos esta completado. Se entiende que el producto está terminado cuando se asegura que se puede entregar una demostración de los requisitos que ya se han cumplido y se incluye que se está realizando todo lo que el cliente desea[9, pág 37]. 6.4.4.2.. Sprint Backlog. Durante la planificación de un sprint se elabora una lista de tareas que desarrollara cada equipo ası́ como el tiempo para terminarlas. De esta manera el proyecto se descompone en pequeñas tareas y revisar si se está avanzado, y en caso contrario determinar porque no se avanza e intentar eliminar el problema. Generalmente para llevar el control de las tareas se usan pizarras, hojas de cálculo o herramientas colaborativas, a cada objetivo se le asignan tareas y se van moviendo de una columna a otra para cambiar el estado. Se debe incluir la lista de tareas, la persona responsable de cada tarea, el estado en el que se encuentra y el tiempo restante para completarla[9, pág 40]. 6.4.4.3.. Incremento. Aquı́ se muestran los requisitos que se han completado en cada iteración y que son operativos. Según esto el cliente puede hacer cambios y replantear el proyecto[9, pág 41].. 6.4.5.. Dinámica. 6.4.5.1.. Iteraciones. Son conocidas como Sprints, y como toda metodologı́a ágil es incremental e iterativo. Esto significa que el producto se construye en incrementos funcionales que se entregan en periodos cortos. En general se recomienda que cada sprint sea entre 1 o 4 semanas, siendo lo más habitual 2 o 4 semanas [6, pág 27]. 6.4.5.2.. Reunión de Planificación de Sprint. En cada sprint se realiza una reunión en donde se generan los acuerdos y compromisos del equipo de desarrollo y el Dueño del Producto sobre el alcance del sprint. Normalmente la reunión se divide en dos partes, el ”que”se 16.

(28) va a realizar y el çomo”se hará. En la parte del ”qué”, básicamente el Dueño del Producto expone todos los Product Backlogs que podrı́an formar parte del sprint, y el equipo de desarrollo realiza todas las preguntas para hacer los ajustes a sus estimaciones. Durante el çómo.el equipo de desarrollo determina la forma en la que llevara a cabo el trabajo. Esto implica el diseño que se irán modificando durante los Sprints y la identificación de las actividades que el equipo llevara a cabo[6, pág 28].. 6.5. 6.5.1.. Herramientas AngularJS. AngularJS es un framework openSource basado en JavaScript que permite el desarrollo del lado del cliente, fue desarrollado por Google con el objetivo principal de la creación de aplicaciones web en una sola página, permite el desarrollo de aplicaciones web con mayor facilidad, simplificando los procesos y optimizando el tiempo de ejecución de proyectos de software. El código fuente de AngularJS está disponible gratuitamente en Github bajo la licencia MIT, motivo por el cual cualquier persona puede contribuir y ayudar en su desarrollo. El framework funciona actualmente con las tecnologı́as de mayor aplicación en la actualidad como HTML, CSS y JavaScript [10, pág 21]. AngularJS es compatible actualmente con todos los navegadores de última generación (Chrome, Firefox, Safari, Opera, Webkits, IE9+), el framework permite construir aplicaciones modernas extendiendo el lenguaje HTML tradicional mediante nuevas etiquetas propias conocida como directivas. Otras funciones avanzadas permitidas por AngularJS se describen a continuación: Separación de la lógica de la aplicación, los modelos de datos y las vistas Servicios de AJAX Inyección de dependencias 17.

(29) Historial de navegación Testing etc. Una de las principales caracterı́sticas ofrecidas por el framework AngularJS es el hecho de poder separa la lógica de las aplicaciones de JavaScript de la manipulación del modelo en objetos para la representación de documentos (DOM)[11, pág 8], elemento que facilita ampliamente el desarrollo del código mediante buenas prácticas de programación. 6.5.1.1.. ¿Por qué utilizar AngularJS en el proyecto?. La elección del framework AngularJS para el desarrollo del lado del cliente se debe a las ventajas basadas en el hecho de permitir hacer uso de una programación más estructurada, separando la lógica de la aplicación de la manipulación de los datos, dando como resultado una mejora en la calidad del código y los hábitos de programación. AngularJS provee distintas ventajas con respecto a otros frameworks, entre ellos la posibilidad de desarrollar mediante menos código, además cuenta con un gran apoyo de distintas comunidades, lo que permite una evolución continua y una gran cantidad de documentación y componentes de otros desarrolladores. AngularJS también permite un fácil consumo de API’s, lo que simplifica bastante el proceso de desarrollo, y conlleva grandes beneficios en la manipulación de los datos.. 6.5.2.. Go (Lenguaje de programación). Go es un lenguaje relativamente nuevo (fue anunciado públicamente en el 2009) creado e impulsado por un grupo de desarrolladores de la empresa Google. Busca ser un lenguaje de sistema simple pero incorpora facilidades que tı́picamente no se incluı́an en lenguajes de sistema, como manejo automático de memoria (usando un garbage collector) y soporte para programación concurrente (introduciendo el concepto de goroutines). Se aparta de la sintaxis y las estructuras de control propuestas por el lenguaje C, proponiendo alternativas más simples y potentes. Soporta programación orientada a objetos pero no utiliza el concepto de clases y herencia común en otros lenguajes de 18.

(30) programación [12]. Según la página oficial de Go, “Es un lenguaje de código abierto que hace simple la construcción de código sencillo, confiable y eficiente. Este lenguaje lleva relativamente poco tiempo en el mercado, por lo que aún carece de una gran cantidad de frameworks y librerı́as que otros lenguajes poseen”[13]. Go es un lenguaje que funciona del lado del servidor, lo que permite crear aplicaciones web de gran utilidad y con buenos resultados, en pruebas realizadas con un servidor web Golang contra un servidor web Python se pudo determinar el buen funcionamiento del lenguaje, aportando resultados significativamente superiores en comparación a los de su competidor [14]. Otro ejemplo práctico del buen funcionamiento de GO ocurrió en la empresa Iron.io, a principios del año 2013. Su aplicación IronWorker pasó de usar 30 servidores a solamente 2. Después de que se puso en marcha su nueva versión de GO [15, pág 33]. 6.5.2.1.. Beego. Beego es un framework web (HTTP) desarrollado para el lenguaje Go, puede ser usado para el desarrollo de API’s, aplicaciones web y servicios de backend de manera rápida y eficaz, está inspirado en distintos frameworks desarrollados para otros lenguajes de programación como Sinatra (Ruby), Tornado y Flask (Python) [16]. 6.5.2.2.. ¿Por qué utilizar Go en el proyecto?. Para la realización del desarrollo del lado del servidor, Go provee un conjunto de significativos beneficios, entre ellos un significativo rendimiento en la respuesta de solicitudes, y una amplia gama de opciones que permiten un desarrollo rápido y con un alto performance, además es un lenguaje sencillo de leer y escribir, es conocido como .El C del siglo XXI”gracias a los atributos con los que cuenta. Go es un lenguaje fuertemente tipificado, sin embargo al momento de ser utilizado presenta caracterı́sticas altamente dinámicas que permiten un desarrollo ágil optimizado por una gran cantidad de librerı́as útiles que permiten un desarrollo eficiente.. 19.

(31) Entre las principales caracterı́sticas de Go está la creación optimizada de API’s REST, siendo un elemento fundamental para el lenguaje, el cual está diseñado para la programación Web concurrente.. 6.5.3.. PostgreSQL. PostgreSQL es un Sistema Gestor de Bases de Datos (SGBD) ObjetoRelacional, Es considerado como el sistema de base de datos de código abierto más avanzada y experimentado de todo el mundo [17, pág 5]. El desarrollo de PostgreSQL es realizado por un equipo conformado en su mayorı́a por desarrolladores voluntarios esparcidos por todo el mundo, que se comunican vı́a Internet. Es un proyecto de comunidad y no está controlado por ninguna compañı́a [18]. PostgreSQL cuenta con una funcionalidad distinguible de otros sistemas gestores, la cual es el control de concurrencia multiversión (MVCC), que permite hacer transacciones consistentes, con lo cual se incrementa el rendimiento del sistema. Esto es porque PostgreSQL permite que mientras un proceso se escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos y ası́ cada usuario tiene una visión consistente de la base de datos y de las tablas a partir del último commit [19]. Las principales ventajas [20, pág 7] del sistema gestor de bases de datos PostgreSQL se describen a continuación: Estabilidad y confiabilidad legendarias: En contraste a muchos sistemas de bases de datos comerciales, es extremadamente común que compañı́as reporten que PostgreSQL nunca ha presentado caı́das en varios años de operación de alta actividad. Ni una sola vez. Simplemente funciona. Extensible: El código fuente está disponible para todos sin costo. Si su equipo necesita extender o personalizar PostgreSQL de alguna manera, pueden hacerlo con un mı́nimo esfuerzo, sin costos adicionales. Esto es complementado por la comunidad de profesionales y entusiastas de PostgreSQL alrededor del mundo que también extienden PostgreSQL todos los dı́as. Multiplataforma: PostgreSQL está disponible en casi cualquier Unix (34 plataformas en la última versión estable), y una versión nativa de Windows está actualmente en estado beta de pruebas.. 20.

(32) Diseñado para ambientes de alto volumen: PostgreSQL usa una estrategia de almacenamiento de filas llamada MVCC para conseguir una mucha mejor respuesta en ambientes de grandes volúmenes. Los principales proveedores de sistemas de bases de datos comerciales usan también esta tecnologı́a, por las mismas razones. 6.5.3.1.. Caracterı́sticas de PostgreSQL. PostgreSQL cuenta con varias caracterı́sticas a distintos niveles que son soportadas por el motor de bases de datos, que la hacen una de las bases de datos más potentes y robustas del mercado, elementos como estabilidad, potencia, robustez, facilidad de administración e implementación de estándares han sido las caracterı́sticas que más se han tenido en cuenta a lo largo de su desarrollo, las caracterı́sticas de PostgreSQL se representan en 3 niveles principales [21]. 1. Nivel general 2. Nivel de programación/desarrollo 3. Nivel SQL Nivel general: En este nivel se destacan caracterı́sticas como el soporte de las caracterı́sticas ACID (atomicidad, consistencia, aislamiento y durabilidad), integridad referencial, copias de seguridad, soporte para LINUX, UNIX Windows de 32 y 64 bits, funciones de COMMIT Y ROLLBACK entre otros elementos básicos de sistemas gestores de bases de datos relacionales. Nivel de programación/desarrollo: En este nivel existen caracterı́sticas que facilitan el desarrollo de software como funciones/procedimientos almacenados en numerosos lenguajes de programación, numerosos tipos de datos y posibilidad de definir nuevos tipos, almacenamiento de objetos binarios grandes, y API’s para programar en distintos lenguajes de programación. Nivel SQL: En este nivel se describen las caracterı́sticas básicas del lenguaje de consulta donde se destaca la manipulación de elementos como los definidos en la siguiente lista. Llaves primarias (primary keys) y foráneas (foreign keys) Check, Unique y Not null constraints 21.

(33) Restricciones de unicidad postergables (deferrable constraints) Índices compuestos, únicos, parciales y funcionales en cualquiera de los métodos de almacenamiento disponibles, B-tree, R-tree, hash ó GiST Joins Vistas (views) Disparadores (triggers) comunes, por columna, condicionales. Reglas (Rules) 6.5.3.2.. Limitaciones del PostgreSQL. Las limitaciones del sistema gestor de bases de datos PostgreSQL se definen en la siguiente tabla [22, pág 4]: Lı́mite Máximo Máximo Máximo Máximo Máximo Máximo Máximo. tamaño tamaño tamaño tamaño número número número. base de dato de tabla de fila de campo de filas por tabla de columnas por tabla de ı́ndices por tabla. Valor Ilimitado 32 TB 1.6 TB 1 GB Ilimitado 250 - 1600 (dependiendo del tipo) Ilimitado. Tabla 6.1: Limitaciones de PostgreSQL 6.5.3.3.. ¿Por qué utilizar PostgreSQL en el proyecto?. El sistema gestor de bases de datos PostgreSQL proporciona distintas ventajas que lo perfilan como un motor ideal para la realización del proyecto planteado, según su página web está diseñado para entornos con altos volúmenes de tráfico y cuenta con un excelente desempeño a través de un código fuente libre y de alta calidad, ofreciendo soporte profesional tanto de la comunidad como de empresas especializadas, elementos que resultan claves para la realización eficaz del proyecto planteado [23]. PostgreSQL ofrece un rendimiento excelente y herramientas que permiten la creación adecuada de bases de datos transaccionales, ofreciendo elementos tradicionales de otros motores, en muchos casos optimizados para funcionar 22.

(34) con un mayor rendimiento y ofreciendo beneficios económicos incomparables respecto a otras opciones.. 6.5.4.. Lenguaje unificado de modelado (UML) e Ingenierı́a de Software. El lenguaje de modelado UML es el estándar más utilizado para especificar y documentar cualquier sistema de forma precisa, es un lenguaje gráfico para especificar, construir y documentar los artefactos que modelan un sistema. UML fue diseñado para ser un lenguaje de modelado de propósito general, por lo que puede utilizarse para especificar la mayorı́a de los sistemas basados en objetos o en componentes, y para modelar aplicaciones de muy diversos dominios de aplicación (telecomunicaciones, comercio, sanidad, etc.) y plataformas de objetos distribuidos [24]. Desde su lanzamiento el lenguaje UML ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc. El uso de UML para el diseño de un sistema conlleva una serie de beneficios a partir del conjunto de diagramas que permiten el modelamiento de los sistemas mediante un análisis contextualizado de los requisitos del sistema implementado, los diagramas más comunes [25] del UML son: Diagrama de Clases Diagrama de Objetos Diagrama de Casos de Uso Diagrama de Estados Diagrama de Secuencias Diagrama de Actividades 6.5.4.1.. Herramientas CASE. Un CASE (Computer-Aided Software Engineering) es una herramienta que ayuda al ingeniero de software a desarrollar y mantener software. A continuación se presentan algunas definiciones dadas para el término CASE.. 23.

(35) “Herramientas individuales para ayudar al desarrollador de software o administrador de proyecto durante una o más fases del desarrollo de software (o mantenimiento).” [26]. “Una combinación de herramientas de software y metodologı́as de desarrollo” [27]. El propósito de una herramienta CASE es dar soporte automatizado para la aplicación de todas o algunas técnicas usadas por una o varias metodologı́as. Los principales beneficios aportados por las herramientas CASE se pueden representar en el siguiente conjunto de aspectos[28, pág 1]: Facilita la verificación y mantenimiento de la consistencia de la información del proyecto. Facilita el establecimiento de estándares en el procesos de desarrollo y documentación. Facilita el mantenimiento del sistema y las actualizaciones de su documentación. Facilita la aplicación de las técnicas de una metodologı́a. Disponibilidad de funciones automatizadas tales como: obtención de prototipos, generación de código, generación de pantallas e informes, generación de diseños fı́sicos de bases de datos, verificadores automáticos de consistencia. Facilita la aplicación de técnicas de reutilización y reingenierı́a. Facilita la planificación y gestión del proyecto informático. 6.5.4.2.. ¿Por qué utilizar UML en el proyecto?. Las herramientas ofrecidas por UML permiten desarrollar de manera estructurada la ejecución de proyectos informáticos, dando espacio a una correcta descripción de los requerimientos de software necesarios, fase clave para la implementación eficaz del proyecto propuesto en este trabajo.. 24.

(36) 6.5.5.. Web service (Servicios web). Los Web Services (Servicios Web) son un conjunto de tecnologı́as y aplicaciones que tienen la capacidad de operar en la web. Los usuarios de Internet pueden solicitar en la red un servicio que sea provisto por alguna persona o compañı́a. Por ello se han establecido mecanismos de comunicación estándares entre aplicaciones web, con la finalidad de presentar información dinámica al usuario [29]. Un desarrollador puede incluir en un sitio web las llamadas soluciones sentencias, estas consisten en instrucciones que consumen Web Services de terceros o propios. Un Web Service puede ser registrado para poder dejarlo a disposición de otros usuarios y para que los mismos puedan localizarlo. Un mecanismo para registrar estos servicios es por medio de UDDI (Universal Description, Discovery and Integration), es decir un repositorio de Web Services [30]. La arquitectura básica del modelo de web services describe a un consumidor, un proveedor y ocasionalmente un corredor (broker). Relacionados con estos agentes están las operaciones de publicar, encontrar y enlazar. La idea básica consiste en que un proveedor publica su servicios en un corredor, luego un consumidor se conecta el corredor para encontrar los servicios deseados y una vez que lo hace se realiza un lazo entre el consumidor y él [31]. Un web service no es más que un uso moderno de las herramientas que ya existı́an para conseguir que los servicios informáticos puedan abrir su abanico de clientes, su facilidad y versatilidad de implantación. “Un web service es una interfaz, accesible por protocolos (estándar o no) usados en Internet, que permite acceder a las funcionalidades de un objeto concreto, sin importar las tecnologı́as ni plataformas implicadas en la petición”[32].. 25.

(37) Capı́tulo 7 Metodologı́a 7.1. 7.1.1.. Definición de la metodologı́a Metodologı́a SCRUM. La metodologı́a que se seguirá en el proyecto es Scrum, cuenta con su correspondiente lista de necesidades del cliente, las iteraciones o Sprints y el incremento por cada iteración. Siguiendo la metodologı́a Scrum el periodo para hacer los sprints será de una semana, y se realizara los dı́as miércoles la reunión en la que se analiza el progreso de la tarea. El equipo de desarrollo está conformado por dos personas, dos estudiantes de ingenierı́a de sistemas que realizaran el análisis y desarrollo del proyecto. Con respecto a los roles, se cuenta con un director interno del proyecto, que es el Scrum Master y que se encarga de seguir el buen desarrollo del proyecto ası́ mismo el director externo que se encarga de revisar que las actividades para cada sprint se hallan llevado a cabo. Gracias a que Scrum es una metodologı́a ágil, se cuenta con gran libertad en el desarrollo y se maneja un ambiente de tranquilidad y buena convivencia entre los integrantes del proyecto. El control de las tareas se realiza mediante una herramienta de apoyo, conocida como Tuleap, un gestor de proyectos que maneja la metodologı́a Scrum, permitiendo ası́ registrar las actividades y seguir el desarrollo de las misma mediante comentarios y revisar los incrementos con el Git con que cuenta la plataforma, aunque también se maneja GitHub como apoyo. Ası́, cada semana se registran las tareas que se realizan con los respectivos comentarios de 26.

(38) Figura 7.1: Tarea inscrita en Tuleap. los progresos, finalizando por último con el incremento que se subirá en un sistema de almacenamiento web (GitHub). Gracias al uso de esta herramienta se puede seguir el proceso de desarrollo, permitiendo ası́, la solución de cualquier error con mayor facilidad y también realizar el Product Backlog llevando con exito el registro de las tareas realizadas a lo largo del proyecto. La Figura 7.1 muestra una de las tareas que se asignan semanalmente en la plataforma, y que se pueden en dado casi desglosar en múltiples tareas y abarcan pequeñas subtareas de la tarea principal asignada inicialmente. Se puede observar también la descripción de la tarea, el proyecto al que pertenece en este caso Argo, que es el responsable del módulo de contratación y la etapa 27.

(39) Figura 7.2: Encargados de la tarea y los archivos adjuntos. en la que se encuentra la tarea. En la siguiente figura, la figura 7.2, se pueden ver los desarrolladores encargados de la tareas y los archivos adjuntos a la tarea, que para este caso son las capturas de pantalla del desarrollo del módulo. Por último la sección de comentarios(Figura 7.3), en donde se van documentando el avance del proyecto, por parte del Scrum master y los desarrolladores, en él se documentan el progreso de las tareas realizadas y por último la finalización de la misma, después de evaluar la tarea y aprobarla para cierre o finalización.. 28.

(40) Figura 7.3: Comentarios del progreso de la tarea.. 29.

(41) Capı́tulo 8 Recursos A continuación se describen los diferentes recursos humanos, técnicos, tecnológicos e institucionales necesarios para la ejecución del proyecto descrito a lo largo de este trabajo, junto con la cantidad requerida (por cada recurso) para obtener la obtención del producto en los plazos definidos y con los requerimientos especificados.. 8.1.. Recursos humanos. Los recursos humanos necesarios para la realización del proyecto se basan en tres roles principales fundamentados plenamente en la implementación del software proyectado: 1. Analista 2. Diseñador 3. Desarrollador En la siguiente tabla se plantea la cantidad prevista requerida por cada rol para la realización efectiva del proyecto. Recurso humano Analista Diseñador Desarrollador. Cantidad (personas) 2 2 2. Tabla 8.1: Recursos humanos del proyecto. 30.

(42) 8.2.. Recurso técnicos y tecnológicos. Los recursos técnicos y tecnológicos necesarios para la realización del proyecto se basan en sistemas de almacenamiento y equipos de cómputo, además de servicios generales que permitan la realización efectiva del producto a entregar, en la siguiente tabla se puede observar la especificación de cada recurso: Recurso Almacenamiento (Google Drive, GitHub) Equipos de cómputo Servicios eléctricos y de Internet. Cantidad 2 2 5. Tipo GigaBytes Computadores Meses. Tabla 8.2: Recursos técnicos y tecnológicos del proyecto. 8.2.1.. Recursos de Software. Los recursos de software necesarios se basan en programas que permitan el desarrollo del sistema con las herramientas especificadas. CentOS 7 Atom (editor de texto) Golang 1.7.4 Beego Framework 1.7.1 Motor de bases de datos PostgreSQL 9.5 PgAdmin III PgModeler 0.8.2 Google Chrome, Mozilla Firefox, Microsoft Internet Explorer (navegadores web). 8.3.. Recursos institucionales. Biblioteca de la Universidad Distrital Francisco José de Caldas Resoluciones de Contratación de Docentes por Vinculación Especial Espacio para reuniones y ejecución de sprints 31.

(43) Capı́tulo 9 Presupuesto El presupuesto empleado en el desarrollo del proyecto se explica en la siguiente tabla, además se ha de tener en cuenta que para el proyecto se cuenta con dos desarrollares y con dos directores, uno interno y otro externo. El presupuesto para los 5 meses es de $46’750.000 con un presupuesto mensual de $9’350.000, más el 15 % de imprevistos lo que da un presupuesto total de $53’762.500. El análisis financiero realizado para el proyecto se puede observar en la tabla 9.1 donde se toman en cuenta los siguientes recursos: Desarrolladores Directores Computadores Transporte y viáticos Papelerı́a Tecnologı́a Varios e imprevistos. 32.

(44) 33. Varios e imprevistos. Tecnologı́a $1’402.500. -. $30.000. $140.000. -. $5’000.000. $4’000.000. Mes 2. $1’402.500. -. $30.000. $140.000. -. $5’000.000. $4’000.000. Mes 3. $1’402.500. -. $30.000. $140.000. -. $5’000.000. $4’000.000. Mes 4. Tabla 9.1: Presupuesto para el proyecto. $1’402.500. -. $30.000. $140.000. Transporte y viáticos. Papelerı́a. $150.000. $5’000.000. Directores. Computadores. $4’000.000. Mes 1. Desarrolladores. Recursos. $1’402.500. -. $30.000. $140.000. -. $5’000.000. $4’000.000. Mes 5. $7’012.500. $0. $150.000. $700.000. $900.000. $25’000.000. $20’000.000. Total.

(45) Capı́tulo 10 Cronograma De acuerdo con la metodologı́a escogida el proyecto se trabaja por semanas, en cada semana se presenta un incremento del proyecto hasta que las actividades necesarias para hacer los requerimientos sean concluidas. En la primera actividad se hace la recolección de datos y las entrevistas que hacen parte del proceso de análisis y diseño, luego de esto se comienza con el desarrollo que es la actividad que más semanas necesitara para ser concluida, finalizada la misma se realizaran las respectivas pruebas para luego pasar a la siguiente actividad, de ser necesario, que significara la corrección de los resultados obtenidos en las pruebas. Por último se hará una revisión del software realizado que significara el comienzo del proceso de entrega final del proyecto. El proyecto está pensado para que tenga una duración de 4 meses desde la aprobación del mismo. El cronograma de actividades planteado con la estimación de tiempos definidos se puede observar en la Figura 10.4.. 34.

(46) 35 Figura 10.1: Cronograma de actividades del proyecto - Mes 1.




(50) Capı́tulo 11 Desarrollo 11.1.. Modelo actual del proceso de vinculación especial. El área funcional con una mayor participación dentro del proceso de contratación es el de Consejo de facultad, área donde también se finaliza el proceso de vinculación de los docentes. El proceso contractual para docentes de vinculación especial de la Universidad Distrital Francisco José de Caldas está formado por un conjunto de etapas diferentes. La primera etapa es la solicitud de una necesidad que tiene la universidad dentro de alguna de sus dependencias, la solicitud puede ser aprobada o no mediante uno de los ordenadores de gastos de la universidad, si el ordenador aprueba la necesidad se realiza otra solicitud, el Certificado de Disponibilidad Presupuestal (CDP), con el que se busca la destinación de recursos para suplir la necesidad, el flujo de procesos actualmente utilizados para la contratación de docentes se encuentra especificado en la Figura 11.1.. 11.1.1.. Diagrama de procesos. Una vez aprobado el presupuesto para la vinculación de los docentes, se realiza la proyección por facultades de los docentes que se contrataran, la proyección se envı́a al consejo de facultad que realizara la aprobación de la misma. Una vez aprobada la proyección se realiza el concurso con el que se busca encontrar docentes aptos para las vacantes de docentes proyectadas en los proyectos curriculares, en caso de no encontrar un docente que reúna las caracterı́sticas de la vacante, el concurso se considera desierto y se realiza nuevamente hasta encontrar un docente apto. 39.

(51) Figura 11.1: Proceso de contratación de docentes por vinculación especial. Las hojas de vida de los nuevos docentes se envı́an decanatura, que es la encargada de enviarlas a docencia para su clasificación, o en caso de que los docentes ya estén vinculados a la universidad, para su reclasificación. Una vez asignada la categorı́a del docente, se asigna la carga académica y se envı́an los documentos de los docentes a recursos humanos, por último, se entrega en el proyecto curricular el visto bueno de las hojas de vida y posteriormente se emite la resolución con los nuevos docentes ya sea de posgrado o pregrado. Cada paso del proceso conlleva a un sin número de papeleo, que es necesario para llevar a buen término el proceso de vinculación de los docentes, y en el que se hace uso de plantillas en Excel para calcular los salarios y registrar la información personal y académica de los docentes.. 40.

(52) 11.1.2.. Diagrama de arquitectura de alto nivel. Figura 11.2: Diagrama de arquitectura de alto nivel. 11.2.. Arquitectura de datos. 11.3.. Modelo de datos. A continuación se describen los atributos y elementos de las tablas utilizadas dentro de la base de datos para el almacenamiento y manejo de la información referente a la contratación de docentes de vinculación especial dentro de la universidad Distrital Francisco José de Caldas, para esta des41.

(53) cripción se toman en cuenta las tablas aportadas únicamente en la ejecución de este proyecto, las tablas existentes previamente dentro del modelo total del sistema de base de datos no son descritas, aunque son utilizadas dentro del proyecto. El modelo de las tablas de autorı́a propia creadas especı́ficamente para el proyecto planteado se puede observar en la Figura 11.3, donde no se toman en cuenta las tablas utilizadas existentes en el modelo previamente, ya que no corresponden a un diseño planteado por autorı́a propia.. Figura 11.3: Modelo de base de datos (tablas especı́ficas del proyecto). 42.

(54) 11.3.1.. Tablas. A continuación se presentan las tablas utilizadas y creadas para la oficina asesora de sistemas, el dicionario de datos con la descripción de los atributos de cada tabla se encuentra en el capitulo de Anexos. 11.3.1.1.. vinculacion docente. Esquema: administrativa Descripción: Esta tabla permite almacenar los principales datos y parámetros utilizados para el cálculo del valor del contrato y asociados a la contratación de los docentes de vinculación especial, a partir de esta tabla se obtienen los datos básicos utilizados para la expedición de resoluciones con datos de docentes vinculados. 11.3.1.2.. resolucion. Esquema: administrativa Descripción: Permite almacenar los datos básicos de las resoluciones expedidas dentro de la universidad, ası́ como parte de su contenido, se encuentra enfocada principalmente a las resoluciones de vinculación especial, sin embargo es una tabla de objetivo general. 11.3.1.3.. tipo resolucion. Esquema: administrativa Descripción: Tabla donde se registran los tipos u objetivos de las resoluciones creadas, en el caso de este trabajo utilizada para permitir identificar las resoluciones de vinculación especial de docentes expedidas dentro de la universidad.. 11.3.1.4.. componente resolucion. Esquema: administrativa Descripción: Permite almacenar información del contenido de las resoluciones expedidas dentro de la universidad, especialmente utilizada para el. 43.

(55) almacenamiento de artı́culos y parágrafos de la resolución.. 11.3.1.5.. resolucion estado. Esquema: administrativa Descripción: Tabla de rompimiento de las tablas resolución y estado resolucion, permite mantener el registro de los cambios realizados, dando la posibilidad de que una resolución pueda recibir varios cambios de estado a partir de su creación.. 11.3.1.6.. estado resolucion. Esquema: administrativa Descripción: Tabla encargada de almacenar los diferentes estados por los que puede pasar una resolución a partir de su creación, permitiendo abordar las diferentes opciones a partir del estado actual de una resolución.. 11.3.1.7.. resolución vinculacion docente. Esquema: administrativa Descripción: Tabla encargada de almacenar información referente únicamente a las resoluciones de contratación de docentes por vinculación especial, tiene como objetivo principal almacenar datos excluyentes de otro tipo de resoluciones.. 11.3.1.8.. dedicacion. Esquema: administrativa Descripción: Tabla encargada de almacenar las dedicaciones horarias por las cuales se puede hacer la vinculación de un docente a la universidad (hora cátedra honorarios, hora cátedra prestaciones, medio tiempo ocasional, tiempo completo ocasional).. 44.

(56) 11.3.1.9.. punto salarial. Esquema: core Descripción: Tabla donde se almacenan los puntos salariales decretados anualmente utilizados para el cálculo del valor del contrato para los docentes en la modalidad de vinculación especial para el nivel académico de pregrado.. 11.3.2.. Tablas utilizadas del modelo previo. Dentro del desarrollo del trabajo, se hizo uso de algunas tablas del modelo de base de datos de la universidad que habı́an sido previamente validadas previamente, el uso de varias de estas tablas permite llevar a cabo la ejecución completa del modelo del aplicativo planteado y el correcto almacenamiento de los datos, a continuación se describen brevemente las tablas existentes previamente dentro de la base de datos utilizadas para la realización del proyecto. 11.3.2.1.. contrato general. Esquema: argo Descripción: Dentro de esta tabla se guardan los registros de los contratos realizados al momento de la expedición de una resolución, permite almacenar datos básicos del contrato como el valor del mismo, y los parámetros a los cuales se ve sujeto. 11.3.2.2.. estado contrato. Esquema: argo Descripción: Permite almacenar los estados de los contratos, haciendo posible manejarlos al mismo tiempo que se realiza un cambio en el estado de una resolución. 11.3.2.3.. contrato estado. Esquema: argo Descripción: Funciona como tabla de rompimiento entre contrato general y estado contrato, permitiendo que un contrato pueda pasar a través de varios estados.. 45.

(57) 11.3.2.4.. parametros. Esquema: argo Descripción: Esta tabla permite almacenar elementos con atributos comunes asociados a los registros de la tabla contrato general. 11.3.2.5.. unidad ejecucion. Esquema: argo Descripción: Representa la unidad encargada de llevar a cabo los contratos registrados dentro de la tabla contrato general. 11.3.2.6.. informacion persona natural. Esquema: agora Descripción: Dentro de esta tabla se almacenan los datos básicos de las personas asociadas a la universidad, para el caso concreto de la aplicación almacena los datos de los docentes a ser vinculados con la universidad. 11.3.2.7.. informacion proveedor. Esquema: agora Descripción: Esta tabla almacena información tanto de personas naturales como personas jurı́dicas con las cuales se asocia la realización de un contrato. 11.3.2.8.. ordenador gasto. Esquema: core Descripción: Representa la entidad encargada de realizar la petición formal para la vinculación de los docentes a la universidad. 11.3.2.9.. salario minimo. Esquema: core Descripción: Almacena los registros anuales del salario mı́nimo para una vigencia dada, tiene como objetivo permitir calcular el valor del contrato de los docentes de posgrado. 11.3.2.10.. unidad ejecutora. Esquema: financiera Descripción: Permite representar la unidad dentro de la universidad en-. 46.