fabi an s anchez, fadarsaleeing@gmail.com david morales ...repository.udistrital.edu.co ›...
Post on 26-Jun-2020
5 Views
Preview:
TRANSCRIPT
DESARROLLO Y PRUEBAS DE LOS MODULOS DE ESPACIOS
ACADEMICOS DE POSGRADO, ESPACIOS ACADEMICOS DE
PROFUNDIZACION, INNOVACION-INVESTIGACION Y PRODUCCION
ACADEMICA, PARA EL SISTEMA DE GESTION DE PROYECTOS DE
GRADO “POLUX” DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSE
DE CALDAS
Fabian Sanchez, fadarsaleeing@gmail.com
David Morales, davidmym07@gmail.com
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenieirıa, Ingenierıa de Sistemas
Bogota, Colombia
2017
DESARROLLO Y PRUEBAS DE LOS MODULOS DE ESPACIOS
ACADEMICOS DE POSGRADO, ESPACIOS ACADEMICOS DE
PROFUNDIZACION, INNOVACION-INVESTIGACION Y PRODUCCION
ACADEMICA, PARA EL SISTEMA DE GESTION DE PROYECTOS DE
GRADO “POLUX” DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSE
DE CALDAS
Trabajo de grado presentado para optar al tıtulo de:
Ingeniero de Sistemas
Director Interno:
Alejandro Paolo Daza Corredor
Director Externo:
Fausto Puerto
Revisor :
Paulo Cesar Coronado Sanchez
Universidad Distrital Francisco Jose de Caldas
Facultad de Ingenieirıa, Ingenierıa de Sistemas
Bogota, Colombia
2017
Agradecimientos
Durante la construccion de este trabajo se vivieron experiencias y se genero un gran apren-
dizaje, gracias a cada persona que contribuyo directa o indirectamente con horas de trabajo
y esfuerzo para poder materializar estas ideas.
Agradecer tambien a la Oficina Asesora de Sistemas por creer y confiar en nuestras capaci-
dades.
Contenido
Agradecimientos V
1 INTRODUCCION 2
2 PLANTEAMIENTO DEL PROBLEMA 4
3 OBJETIVOS 6
3.1 Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4 JUSTIFICACION 7
5 MARCO TEORICO 8
5.1 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Generator-Angular . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Integracion Continua . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4 Metodologıa de desarrollo agil SCRUM . . . . . . . . . . . . . . . . . . . . . 12
5.4.1 Roles del equipo scrum . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4.2 Proceso de Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.5 Reglamentacion del trabajo de grado para los estudiantes de pregrado segun
Acuerdo 038 de 2015 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5.1 Inscripcion y registro . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.5.2 Espacios academicos de posgrado . . . . . . . . . . . . . . . . . . . . 21
5.5.3 Espacios academicos de profundizacion . . . . . . . . . . . . . . . . . 22
5.5.4 Investigacion – Innovacion . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5.5 Produccion academica . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6 ALCANCES Y LIMITACIONES 23
6.1 Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.2 Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7 ANTECEDENTES 25
7.1 SGPG-UD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2 UDLEARN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Contenido vii
7.3 POLUX VERSION 1.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8 METODOLOGIA 28
8.1 Registro de epicas, historias de usuario y tareas . . . . . . . . . . . . . . . . 28
8.2 Control y actualizacion en el tablero Kanban . . . . . . . . . . . . . . . . . . 29
9 DESARROLLO 31
9.1 Modelo de negocio actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2 Modelo y Notacion de Procesos de Negocio . . . . . . . . . . . . . . . . . . . 31
9.3 Interfaces de Programacion de Aplicaciones . . . . . . . . . . . . . . . . . . . 33
9.3.1 Polux Crud API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.3.2 Polux MID API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.3.3 Ruler API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.4 Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.4.1 Cambios en la ultima version del modelo . . . . . . . . . . . . . . . . 35
9.5 Representacion y uso de reglas utilizando Golog. . . . . . . . . . . . . . . . . 37
9.6 Modulo de Registro de Propuesta de un trabajo de grado . . . . . . . . . . . 40
9.6.1 Submodulo de informacion basica del registro . . . . . . . . . . . . . 41
9.6.2 Submodulo de asignacion de areas de conocimiento y carga del archivo
del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.6.3 Confirmacion del registro y manejo de transacciones . . . . . . . . . . 42
9.7 Modulos de Espacios academicos de Posgrado y Profundizacion . . . . . . . . 44
9.7.1 Submodulo de publicacion de espacios academicos . . . . . . . . . . . 44
9.7.2 Submodulo de solicitud de inscripcion . . . . . . . . . . . . . . . . . . 46
9.7.3 Submodulo de consulta de solicitudes y seleccion de admitidos . . . . 50
9.8 Modulo de Gestion de Formatos . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.8.1 Submodulo de formato consultar formato . . . . . . . . . . . . . . . . 52
9.8.2 Submodulo de formato crear formato . . . . . . . . . . . . . . . . . . 53
9.8.3 Submodulo de asignar Formato a Proyecto Curricular . . . . . . . . . 54
9.8.4 Submodulo de Evaluar Proyecto . . . . . . . . . . . . . . . . . . . . . 54
9.9 Modulo de revision de Documentos . . . . . . . . . . . . . . . . . . . . . . . 55
9.9.1 Vista de Estudiante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.9.2 Vista de Docente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.10 Integracion continua. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.10.1 Integracion Continua en la Oficina Asesora de Sistemas . . . . . . . . 57
9.10.2 Integracion Continua en API CRUD y MID API . . . . . . . . . . . . 57
9.10.3 Integracion Continua en el cliente de Polux . . . . . . . . . . . . . . . 58
10 Generador de aplicaciones de angular generator-oas 59
10.1 Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.2 Construccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
viii Contenido
10.3 Yeoman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.4 Historico de versiones de generator-oas . . . . . . . . . . . . . . . . . . . . . 60
10.5 Instalacion y uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
10.5.1 Librerıas que instala generator-oas . . . . . . . . . . . . . . . . . . . 65
10.5.2 Subgenerador de componentes de generator-oas . . . . . . . . . . . . 66
11 Gestor Documental Nuxeo 67
11.1 Instalacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
11.2 Conexion con angularJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
12 ANALISIS DE RESULTADOS Y TRABAJOS FUTUROS 72
13 CONCLUSIONES 74
Bibliografıa 75
Lista de Figuras
5-1. Flujo de Scrum para un sprint. Tomado de [7] . . . . . . . . . . . . . . . . . 13
5-2. Caracterısticas deseadas de los papeles principales de Scrum. Tomado de [8] 17
7-1. Estructura del aplicativo de SGPG-UD. Tomado de [4] . . . . . . . . . . . . 25
7-2. Consulta del nivel de participacion de los docentes en los trabajos de grado.
Tomado de [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7-3. Formulario de consulta del anteproyecto. Tomado de [3] . . . . . . . . . . . . 27
8-1. Agregar una tarea en una historia de usuario. Autoria Propia . . . . . . . . . 28
8-2. Comentarios y asignacion de tiempos. Autoria propia . . . . . . . . . . . . . 29
8-3. Actualizacion de puntos de historias de usuario. Autoria Propia . . . . . . . 29
8-4. Grafica Burndown Chart para el Sprint de un proyecto. Autoria Propia . . . 30
9-1. BPMN general del proceso del trabajo de grado en documentos. Tomado de [6] 32
9-2. BPMN general del proceso del trabajo de grado en espacios academicos. To-
mado de [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9-3. Diagrama de Componentes de las APIs para Polux Autorıa Propia . . . . . . 34
9-4. Ultima version del Diseno del Modelo de Datos, Oficina Asesora de Sistemas 35
9-5. Diseno del Modelo los Espacios Academicos Oficina Asesora de Sistemas . . 36
9-6. Diseno del Modulo de Evaluaciones Oficina Asesora de Sistemas . . . . . . . 37
9-7. Ejemplo de interaccion con modulo de informacion basica despues de obtener
una respuesta afirmativa. Autorıa Propia . . . . . . . . . . . . . . . . . . . . 41
9-8. Peticion para guardar el registro de un trabajo de grado Autorıa Propia . . . 42
9-9. Transaccion de un registro en la tabla trabajo de grado Autorıa Propia . . . 42
9-10.Peticion para guardar el registro de un trabajo de grado asociado a un estu-
diante Autorıa Propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9-11.Transaccion de un registro en la tabla estudiante trabajo grado. Autorıa Propia 42
9-12.Peticion para guardar el registro de un trabajo de grado asociado a un area
de conocimiento. Autorıa Propia . . . . . . . . . . . . . . . . . . . . . . . . . 43
9-13.Transaccion de un registro en la tabla areas trabajo grado. Autorıa Propia . 43
9-14.Peticion para guardar el registro de un documento asociado a un trabajo de
grado. Autorıa Propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9-15.Transaccion de un registro en la tabla documento. Autorıa Propia . . . . . . 43
x Lista de Figuras
9-16.Transaccion de un registro en la tabla documento asociado a un trabajo de
grado. Autorıa Propia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
9-17.Publicacion de espacios academicos por carrera y pensum Oficina Asesora de
Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9-18.Escenario cuando no cumple la cantidad mınima de espacios academicos Ofi-
cina Asesora de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
9-19.Escenario (1) Estudiante no cumple con los requisitos Oficina Asesora de
Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
9-20.Escenario (2), Estudiante cumple sin solicitudes Oficina Asesora de Sistemas 47
9-21.Escenario (3). Estudiante que tiene dos solicitudes. Oficina Asesora de Sistemas 48
9-22.Escenario (4). Estudiante con solicitudes aprobadas. Oficina Asesora de Sistemas 49
9-23.Modulo de consulta de admitidos por carrera Oficina Asesora de Sistemas . . 50
9-24.BPMN para el proceso de seleccion de admitidos a las modalidades de espacios
academicos. Oficina Asesora de Sistemas . . . . . . . . . . . . . . . . . . . . 51
9-25.SubModulo de seleccion de admitidos Oficina Asesora de Sistemas . . . . . . 51
9-26.Modulo Consultar formato de evaluacion . . . . . . . . . . . . . . . . . . . . 52
9-27.Botones de Accion para formato ver . . . . . . . . . . . . . . . . . . . . . . . 52
9-28.Formato pdf que genera el modelo . . . . . . . . . . . . . . . . . . . . . . . . 53
9-29.Submodulo de nuevo formato . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9-30.Submodulo de asignacion de formatos. Autorıa propia . . . . . . . . . . . . . 54
9-31.Submodulo revision de Documentos Estudiante. Autorıa propia . . . . . . . 55
9-32.Submodulo revision de Documentos Estudiante. Autorıa Propia . . . . . . . 56
9-33.Submodulo revision de Documentos Estudiante. Autorıa propia . . . . . . . 57
10-1.generator-oas, lo que aparece al ejecutar el comando $ yo oas . Autorıa propia 62
10-2.Arbol de directorio. Generador OAS. Autorıa propia . . . . . . . . . . . . . . 63
10-3.generator-oas, app que construye. Autorıa propia. . . . . . . . . . . . . . . . 64
10-4.Arbol de directorio de dist/. Autorıa propia . . . . . . . . . . . . . . . . . . 65
11-1.Esquema rest-api Nuxeo Tomado de [10] . . . . . . . . . . . . . . . . . . . . 68
11-2.Directiva de solicitud propuesta. Autorıa propia . . . . . . . . . . . . . . . . 70
11-3.Workspace de Nuxeo. Tomado de Nuxeo App . . . . . . . . . . . . . . . . . 70
11-4.Vista previa documento subido .Tomado de Nuxeo App . . . . . . . . . . . . 71
Lista de Tablas
5-1. Elementos usados en servicios REST. Tomado de [5] . . . . . . . . . . . . . 11
9-1. Manejo de Hechos en Golog. Parte 1 Autorıa Propia . . . . . . . . . . . . . . 38
9-2. Manejo de Hechos en Golog. Parte 2 Autorıa Propia . . . . . . . . . . . . . . 39
9-3. Manejo de Reglas en Golog . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9-4. Requisitos para solicitar la inscripcion en carreras de Pregrado Oficina Asesora
de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
9-5. Requisitos para solicitar la inscripcion en carreras Tecnologicas Oficina Ase-
sora de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1 INTRODUCCION
Dentro del marco de la Universidad Distrital Francisco Jose de Caldas se realizan distintas
operaciones para la gestion y funcionamiento de los procesos de investigacion, docencia
y extension. Para la adecuada gestion de los procesos se tiene en cuenta estructurar la
informacion en diferentes sistemas que permitan de manera modular almacenar y procesar
los datos fundamentales para cada proyecto.
Como parte de estos procesos se encuentra el trabajo de grado descrito como la elaboracion
de un desarrollo formativo de un estudiante que lo lleva a la obtencion de un resultado
final a presentar para optar por el tıtulo universitario. Para los estudiantes del programa de
pregrado, existen diferentes modalidades para dicho proceso.
Cada modalidad conlleva a utilizar diferentes metodos para su gestion en el sistema depen-
diendo de las condiciones pactadas por el acuerdo 38 que reglamenta la modificacion de las
directrices del trabajo de grado.
Cualquiera que sea la modalidad que escoja el estudiante debe efectuarse un proceso pe-
riodico de gestion proyectos de grado, registro de informes de investigacion o publicacion,
interacciones con plataformas de espacios academicos, asignacion de directores, de los me-
dios de socializacion para la comunidad academica, de las distinciones, y los indicadores de
evaluacion segun sea el caso.
Actualmente la Oficina Asesora de Sistemas cuenta con el proceso de gestion de proyectos
de grado de acuerdo a la modalidad de monografıa. Con el objetivo de realizar mejoras y
agregar modulos de acuerdo a las modalidades en el proceso de gestion de proyectos de grado,
la Oficina Asesora de Sistemas, continuo con el proyecto denominado “Sistema de gestion
de proyectos de grado POLUX”, para ello se realizo un proceso de llamado y seleccion
de estudiantes de ultimos semestres que cursan el programa de ingenierıa de sistemas que
deseen participar en el mismo, donde en el momento se cuentan con 3 integrantes dispuestos
en subproyectos correspondientes a: gestion de requerimientos y desarrollo de software, a
cargo de los roles respectivos de analistas y desarrolladores.
Este proyecto en el que se participa con el rol de desarrollador, tiene como objetivo desarro-
llar, disenar y realizar pruebas a una solucion modular, escalable y mantenible que permita
apoyar los procesos relacionados a las modalidades de grado: espacios academicos de posgra-
do, espacios academicos de profundizacion, innovacion-investigacion y produccion academica
3
para la gestion de proyectos de grado de la Universidad Distrital, soportado en software libre
siguiendo la metodologıa agil de desarrollo SCRUM y de esta manera contar con una unica
herramienta tecnologica que soporte cualquier tipo de modalidad de grado.
2 PLANTEAMIENTO DEL PROBLEMA
Dentro del marco de la Universidad Distrital Francisco Jose de Caldas se realizan distintas
operaciones para la gestion y funcionamiento de los procesos de investigacion, docencia
y extension. Para la adecuada gestion de los procesos se tiene en cuenta estructurar la
informacion en diferentes sistemas que permitan de manera modular almacenar y procesar
los datos fundamentales para cada proyecto. Como parte de estos procesos se encuentra el
trabajo de grado descrito como la elaboracion de un desarrollo formativo de un estudiante que
lo lleva a la obtencion de un resultado final a presentar para optar por el tıtulo universitario.
Para los estudiantes del programa de pregrado, existen diferentes modalidades para dicho
proceso.
Cada modalidad conlleva a utilizar diferentes metodos para su gestion en el sistema depen-
diendo de las condiciones pactadas por el acuerdo 38 que reglamenta la modificacion de las
directrices del trabajo de grado. Cualquiera que sea la modalidad que escoja el estudiante
debe efectuarse un proceso periodico de gestion proyectos de grado, registro de informes de
investigacion o publicacion, interacciones con plataformas de espacios academicos, asignacion
de directores, de los medios de socializacion para la comunidad academica, de las distincio-
nes, y los indicadores de evaluacion segun sea el caso. Actualmente la Oficina Asesora de
Sistemas cuenta con el proceso de gestion de proyectos de grado de acuerdo a la modalidad
de monografıa. Con el objetivo de realizar mejoras y agregar modulos de acuerdo a las mo-
dalidades en el proceso de gestion de proyectos de grado, la Oficina Asesora de Sistemas,
continuara con el proyecto denominado “Sistema de gestion de proyectos de grado POLUX”,
para ello se realizo un proceso de llamado y seleccion de estudiantes de ultimos semestres
que cursan el programa de ingenierıa de sistemas que deseen participar en el mismo, donde
en el momento se cuentan con 3 integrantes dispuestos en subproyectos correspondientes
a: gestion de requerimientos y desarrollo de software, a cargo de los roles respectivos de
analistas y desarrolladores.
Este proyecto en el que se participara con el rol de desarrollador, tiene como objetivo desarro-
llar, disenar y realizar pruebas a una solucion modular, escalable y mantenible que permita
apoyar los procesos relacionados a las modalidades de grado: espacios academicos de posgra-
do, espacios academicos de profundizacion, innovacion-investigacion y produccion academica
para la gestion de proyectos de grado de la Universidad Distrital, siguiendo la metodologıa
agil de desarrollo SCRUM y de esta manera contar con una unica herramienta tecnologica
5
que soporte cualquier tipo de modalidad de grado.
3 OBJETIVOS
3.1. Objetivo general
Desarrollar modulos que permitan dar solucion integral y escalable a los procesos de las
modalidades de proyectos de grado definidas en la reglamentacion de la Universidad Distrital,
basado en el analisis definido de la gestion de los requerimientos, la arquitectura y el diseno
previamente tenido en cuenta, soportados en software libre teniendo en cuenta la metodologıa
de desarrollo SCRUM OAS.
3.2. Objetivos especıficos
• Completar los modulos definidos para el sistema de proyectos de gestion de proyectos
de grado, acordes a los detalles descritos en las historias de usuario y el diseno estable-
cido con el fin de cumplir con los lineamientos de los Sprint definidos tomando como
punto de partida la metodologıa de desarrollo SCRUM/OAS.
• Realizar la documentacion del proceso de cada funcionalidad del desarrollo de los
modulos del producto de software, acorde a los requerimientos y el diseno planteados
en el proceso de desarrollo en curso, con base en la metodologıa de desarrollo acordada.
• Revisar los desarrollos realizados a partir de pruebas funcionales y no funcionales de
cada modulo, con el fin de verificar que los requerimientos de los usuarios se cumplan,
ademas de las especificaciones detalladas por los analistas, a partir de tecnicas definidas
en el grupo de desarrollo y la OAS.(A revision)
• Afinar los requerimientos y la arquitectura, desde el punto de vista del desarrollador,
mediante reuniones de trabajo con los analistas y arquitectos para aportar a la gestion
de modificaciones vitales en el sistema.
4 JUSTIFICACION
Debido al constante cambio de la estructura de los procesos llevados a cabo en las modalida-
des de trabajo de grado, se hace necesario pensar en la construccion de una herramienta que
permita ajustarse a las necesidades de estos cambios. No solo como una herramienta para
la gestion de las actuales modalidades de grado, sino tambien, debe pensarse en las posibles
modalidades que pueden emerger en el transcurso del tiempo.
Actualmente el sistema POLUX cubre un pequeno porcentaje de las necesidades que deman-
da las modalidades de grado descritas por el Acuerdo No. 038 de 2015 del Consejo Academico
de la Universidad Distrital Francisco Jose de Caldas, se pretende
Dar solucion en el proceso de desarrollo de software con el fin de facilitar los procedimientos
necesarios de cada modalidad de grado, teniendo en cuenta los requisitos necesarios para
la modalidad, el registro de informes, reportes y evaluaciones, del seguimiento del trabajo
de grado desarrollado mediante el registro de actas firmadas por parte de los docentes Y/O
directores del proyecto. Del mismo modo al lograr que el sistema consuma servicios web
permitira la interoperabilidad entre distintos sistemas que requieran o sincronicen informa-
cion. Este proyecto, dentro de los principios dentro de la metodologıa de desarrollo, pretende
garantizar transparencia en la comunicacion y crea un ambiente de responsabilidad colectiva
y de progreso continuo.
5 MARCO TEORICO
5.1. REST API
Transferencia de Estado Representacional o REST (significado en ingles Representational
State Transfer), es un estilo arquitectural disenado para sistemas de hipermedia distribuidos,
fue presentado por primera vez por Roy Fielding en el ano 2000, en su monografıa.
La arquitectura REST es Inherentemente sencilla porque se basa en siete propiedades des-
criptivas [9]:
• Performance: La forma en que la interaccion entre componentes afecta el rendimiento.
• Escalabilidad: Ser capaz de soportar un gran numero de componentes.
• Simplicidad: Entre las interfaces que interactuan entre sı.
• Modificable: Componentes que requieran ser cambiados.
• Visibilidad: Limpiar comunicacion entre componentes.
• Portabilidad: Del codigo con informacion almacenada.
• Confiabilidad: Resistencia al fallo al nivel del sistema.
REST es un estilo arquitectural basado en recursos, donde cada recurso se accede por medio
de una interfaz comun, basandose en el estandar de metodos HTTP. Al hacer uso del pro-
tocolo HTTP para el API , establece una relacion entre las operaciones fundamentales de
la persistencia del software CRUD (Create, Retrieve, Update, Delete) y los metodos HTTP
[5]. Teniendo en cuenta esta incidencia se tiene que:
• Para obtener informacion acerca de un recurso, escoja GET (Referido a Retrieve).
• Para agregar nueva informacion de un recurso, escoja POST (Referido a Create).
5.1 REST API 9
• Modificar informacion de un recurso existente, escoja PUT (Referido a Update).
• Eliminar un recurso, escoja DELETE.
Existen otros metodos como los siguientes:
• HEAD: Este metodo a diferencia de la operacion GET, no retorna el cuerpo del men-
saje en la respuesta. Este metodo es usado a menudo para pruebas de validacion,
accesibilidad y modificaciones recientes en los enlaces de hipertexto.
• OPTIONS: Permite al cliente determinar las opciones o requerimientos asociados con
un recurso, o las capacidades de un servidor, sin implicar que una accion de un recurso,
o la recuperacion de este.
El REST API envıa una cabecera y un cuerpo de respuesta en formato JSON con la infor-
macion sobre el exito o fallo de la llamada del REST API [3].
Generalmente la cabecera de respuesta (response header) puede contener la siguiente infor-
macion:
• connection
• content-length
• content-language
• content-type
• date
• description
• errorCode
• logFile
• server
• severity
• transfer-encoding
El cuerpo de la respuesta (response body) puede contener informacion sobre la salida y
enlaces adicionales a otras salidas, desde por ejemplo, la ubicacion de un archivo hasta un
10 5 MARCO TEORICO
valor especıfico. El response body tiene la posibilidad de tener un codigo con estado success
o failure. Si el REST API tiene una llamada exitosa, en su estado SUCCESS puede contener
los siguientes codigos:
• 200: Retorna la informacion.
• 201: La peticion request ha sido creada exitosamente.
De lo contrario si la llamada al servicio falla, puede contener este codigo:
• 400: Nombre del servicio no fue proporcionado.
• 401: No autorizado.
• 404: No encontrado.
• 405: La entrada no es valida.
• 500: Error interno del servidor.
Los anteriores codigos son los que generalmente pueden existir en un REST API, dependiendo
de la arquitectura del API trabajado, pueden cambiar las tipificaciones para cada codigo,
asimismo pueden existir mas codigos de estado. En la tabla 1.0 muestra la estructura de los
elementos usados en REST.
5.2 Generator-Angular 11
Estructura general de un REST Api
Elemento de da-
tos
Descripcion
Recurso Objetivo conceptual de una referencia de hipertexto. Ej:
polux/documento
Identificador del
recurso
Un localizador uniforme de recursos (URL)
identifica un recurso en particular. Ej:
http://10.0.2.10:8090/polux/trabajo-grado/25
Recurso de me-
tadatos
Informacion que describe el recurso. Ej: Autor, enlace
fuente, ubicacion alterna, alias
Peticion / Re-
presentacion
El contenido del recurso. Ej: Mensaje en JSON, Docu-
mento HTML, imagen JPG.
Peticion de me-
tadatos
Informacion que describe como es el proceso de la peti-
cion.Ej: Tipo de medio, hora / fecha de la ultima modi-
ficacion
Control de datos Informacion que muestra como optimizar el procesa-
miento de las respuestas o peticiones response. Ej: Mo-
dificado desde, expiracion del control de cache
Tabla 5-1: Elementos usados en servicios REST. Tomado de [5]
5.2. Generator-Angular
Como herramienta para construir Web Apps se encuentra Generator-angular, caracterizada
por realizar la tecnica de andamiaje (Scaffolding) que consiste en una estructura temporal,
que adicional a ello toma diferentes librerıas y junta para poder usarlas a futuro, utilizada
por el equipo de trabajo mientras prueban, construyen, reparan o limpian el codigo para
sus aplicativos. Permite generar una estructura de carpetas y archivos base que facilita la
construccion de las aplicaciones por medio de ejecucion de comandos desde la terminal.
Desde la documentacion de Yeoman.io se encuentra todos los proyectos que permiten generar
codigo con Scaffolding para diferentes frameworks como Angular, React, Backbone, WebApp,
Node, entre otros [11]
12 5 MARCO TEORICO
5.3. Integracion Continua
La integracion continua es una practica de desarrollo de software mediante la cual los desa-
rrolladores combinan los cambios en el codigo en un repositorio central de forma periodica,
tras lo cual se ejecutan versiones y pruebas automaticas. La integracion continua se refiere en
su mayorıa a la fase de creacion o integracion del proceso de publicacion de software y con-
lleva un componente de automatizacion (p. ej., CI o servicio de versiones) y un componente
cultural (p. ej., aprender a integrar con frecuencia). Los objetivos clave de la integracion
continua consisten en encontrar y arreglar errores con mayor rapidez, mejorar la calidad del
software y reducir el tiempo que se tarda en validar y publicar nuevas actualizaciones de
software.
Anteriormente, era comun que los desarrolladores de un equipo trabajasen aislados durante
un largo periodo de tiempo y combinasen los cambios en la version maestra una vez que
habıan completado el trabajo. Este proceso por lotes hacıa que la combinacion de todos los
cambios en el codigo resultase complicada y llevase mucho tiempo. Esto se agravaba cuando
numerosos errores leves se acumulaban durante mucho tiempo sin que se arreglasen. La
combinacion de estos factores hacıa que resultase mas difıcil proporcionar las actualizaciones
a los clientes con rapidez.
Con la integracion continua, los desarrolladores envıan los cambios de forma periodica a
un repositorio compartido con un sistema de control de versiones como Git. Antes de cada
envıo, el equipo de trabajo pueden elegir ejecutar pruebas de unidad local en el codigo como
medida de verificacion adicional antes de la integracion. El servicio de integracion continua
detecta los envıos al repositorio compartido y crea y ejecuta de forma automatica pruebas
de unidad en los cambios en el codigo para detectar al instante cualquier error funcional o
de integracion. [1].
5.4. Metodologıa de desarrollo agil SCRUM
Scrum es uno de los metodos agiles mas populares. Se trata de un marco adaptativo, itera-
tivo, rapido, flexible y eficaz disenado para entregar un valor significativo de manera rapida
en un proyecto. Scrum asegura la transparencia en la comunicacion y crea un ambiente de
responsabilidad colectiva y progreso continuo. El marco de Scrum, tal como se define en
la Guıa SBOK [7], esta estructurado de tal manera que apoya el desarrollo de productos y
servicios en todo tipo de industrias y en cualquier tipo de proyecto, independientemente de
su complejidad
Un proyecto Scrum implica un esfuerzo de colaboracion para crear un nuevo producto, ser-
5.4 Metodologıa de desarrollo agil SCRUM 13
Figura 5-1: Flujo de Scrum para un sprint. Tomado de [7]
vicio u otro resultado. Los proyectos se ven afectados por limitaciones de tiempo, costo,
alcance, calidad, recursos, capacidades organizacionales y otras limitaciones que les difi-
cultan planificar, ejecutar, administrar y, en ultima instancia, tener exito. Sin embargo, la
implementacion exitosa de los resultados de un proyecto terminado proporciona importantes
beneficios empresariales a una organizacion. Por tanto, es importante que las organizaciones
tengan un enfoque apropiado de gestion de proyectos.
Una fortaleza clave de Scrum radica en el uso de equipos multi-funcionales, auto-organizados,
y con poder que dividen su trabajo en ciclos de trabajo cortos y concentrados llamados
Sprints. La Figura 2 proporciona una vision general del flujo de un proyecto Scrum.
5.4.1. Roles del equipo scrum
Son aquellos papeles que obligatoriamente se requieren para producir el producto o servi-
cio del proyecto [7]. Comprender las funciones y responsabilidades definidas en un proyecto
Scrum es muy importante para asegurar la Implementacion exitosa de Scrum. Los roles
de Scrum se dividen en dos grandes categorıas: Core Roles y Non-Core Roles, la primera
representando las funciones principales, estos roles mas importantes son los roles que son
obligatoriamente necesarios para la produccion del proyecto, producto o servicio. Las perso-
nas a las que se asignan estos roles estan plenamente comprometidas con el proyecto y son
responsables en ultima instancia del exito de cada iteracion del proyecto y del proyecto en
su conjunto.
5.4.1.1. Product Owner
El Dueno del producto es la persona responsable del exito del producto desde el punto de
vista de los stakeholders. Sus principales responsabilidades son:
14 5 MARCO TEORICO
• Determinar la vision del producto, hacia donde va el equipo de desarrollo
• Gestionar las expectativas de los stakeholders
• Recolectar los requerimientos
• Determinar y conocer en detalle las caracterısticas funcionales de alto y de bajo nivel
• Generar y mantener el plan de entregas (release plan): fechas de entrega y contenidos
de cada una
• Maximizar la rentabilidad del producto
• Determinar las prioridades de cada una de las caracterısticas por sobre el resto
• Cambiar las prioridades de las caracterısticas segun avanza el proyecto, acompanando
ası los cambios en el negocio
• Aceptar/rechazar el producto construido durante el Sprint y proveer feedback valioso
para su evolucion
• Participar de la revision del Sprint junto a los miembros del Equipo de
• Desarrollo para obtener feedback de los stakeholders.
El Product Owner se focaliza en maximizar la rentabilidad del producto. La principal herra-
mienta con la que cuenta para poder realizar esta tarea es la priorizacion. De esta manera
puede reordenar la cola de trabajo del equipo de desarrollo para que este construya con
mayor anticipacion las caracterısticas o funcionalidades mas requeridas por el mercado o la
competitividad comercial. El Product Owner es la unica persona responsable de gestionar la
lista del producto (Product Backlog).
Otra responsabilidad importante del Product Owner es la gestion de las expectativas de los
stakeholders, mediante la comprension completa de la problematica de negocio y su descom-
posicion, hasta llegar al nivel de requerimientos funcionales.
5.4.1.2. Equipo de desarrollo
El equipo de desarrollo esta formado por todos los individuos necesarios para la construccion
del producto en cuestion. Es el unico responsable por la construccion y calidad del producto.
El equipo de desarrollo es auto-organizado. Es el mismo equipo quien determina la forma en
que realizara el trabajo y como resolvera cada problematica que se presente. La delimitacion
5.4 Metodologıa de desarrollo agil SCRUM 15
de esta auto-organizacion, esta dada por el objetivo a cumplir: transformar las funcionalida-
des comprometidas en software funcionando y con calidad productiva, o en otras palabras,
producir un incremento funcional potencialmente entregable.
Es recomendable que un equipo de desarrollo se componga de hasta nueve (9) personas. Cada
una de ellas debe poseer todas las habilidades necesarias para realizar el trabajo requerido.
Esta caracterıstica se conoce como multi-funcionalidad y significa que dentro del equipo de
desarrollo no existen especialistas exclusivos, sino mas bien individuos generalistas con ca-
pacidades especiales. Lo que se espera de un miembro de un equipo de desarrollo es que no
solo realice las tareas en las cuales se especializa, sino tambien todo lo que este a su alcance
para colaborar con el exito del equipo.
El equipo de desarrollo tiene tres (3) responsabilidades tan fundamentales como indelegables.
La primera es proveer las estimaciones de cuanto esfuerzo sera requerido para cada una de
las caracterısticas del producto. La segunda responsabilidad es comprometerse al comienzo
de cada Sprint a construir un conjunto determinado de caracterısticas en el tiempo que dura
el mismo. Y finalmente, tambien es responsable por la entrega del producto terminado al
finalizar cada Sprint.
5.4.1.3. Scrum Master
El Scrum Master, es el Coach del equipo y es quien lo ayuda a alcanzar su maximo nivel de
productividad posible. Es un lıder, facilitador, provocador, detective y soplador de brasas.
Lıder por ser un ejemplo a seguir, facilitador por fomentar contextos de apertura y discusion
donde todos pueden expresar sus opiniones y lograr consensos comunes, provocador por
desafiar las estructuras rıgidas y las antiguas concepciones sobre como deben hacerse las
cosas, detective por involucrarse activamente en la busqueda e identificacion de indicios y
pistas en la narrativa del equipo y los individuos y finalmente, soplador de brasas, “un
socio facilitador del aprendizaje, que acompana al otro en una busqueda de su capacidad de
aprender para generar nuevas respuestas” conectar a las personas con sus pasiones, con sus
talentos, muchas veces no aprovechados.
Se espera, ademas, que el Scrum Master acompane al equipo de trabajo en su dıa a dıa y
garantice que todos, incluyendo al Product Owner, comprendan y utilicen Scrum de forma
correcta.
Las responsabilidades principales del Scrum Master son:
• Velar por el correcto empleo y evolucion de Scrum.
• Facilitar el uso de Scrum a medida que avanza el tiempo. Esto incluye la responsabi-
lidad de que todos asistan a tiempo a las daily standup meetings, reviews y feedbacks.
• Asegurar que el equipo de desarrollo sea multi-funcional y eficiente.
16 5 MARCO TEORICO
• Proteger al equipo de desarrollo de distracciones y trabas externas al proyecto.
• Detectar, monitorear y facilitar la remocion de los impedimentos que puedan surgir
con respecto al proyecto y a la metodologıa.
• Asegurar la cooperacion y comunicacion dentro del equipo.
Ademas de estas cuestiones, el Scrum Master debe detectar problemas y conflictos interper-
sonales dentro del equipo de trabajo. Para respetar la filosofıa auto-organizativa del equipo,
lo ideal es que el equipo mismo sea quien resuelva estas cuestiones. En el caso de no poder
hacerlo, debera involucrarse al Scrum Master y eventualmente a niveles mas altos de la ge-
rencia.
El Scrum Master es un Lıder Facilitador, no es casualidad la aparicion de un nuevo nombre
o rol. Este nuevo concepto del enfoque agil, representa el cambio respecto de las responsabi-
lidades y el modelo de gestion de los gerentes de proyectos tradicionales en relacion al equipo
de trabajo. El Scrum Master puede ser visto como un Facilitador o Coach, incluso muchas
veces se lo referencia ası en lugar de Scrum Master. Su responsabilidad es asegurar que se
cumpla con el proceso de Scrum sin interferir directamente en el desarrollo del producto
final. Es importante establecer que el equipo de Scrum elige la forma de trabajo que mas
prefiera, siempre que se cumplan las pautas basicas de Scrum, por ello mientras lo hagan no
existe una forma “erronea” de trabajar.
El rol del Scrum Master tambien incluye asegurar que el desarrollo del producto tenga la
mayor probabilidad de ser completado de forma exitosa. Para lograr este cometido, trabaja
de cerca con el Product Owner asegurando una correcta priorizacion de los requerimientos,
por un lado, y con el equipo de desarrollo para convertir los requerimientos en un producto
funcionando, por el otro.
Finalmente, cuando un ScrumMaster logra cubrir exitosamente su rol, la implementacion
de Scrum sucede sin sobresaltos. Las responsabilidades del Scrum Master deberıan cubrir
la totalidad de su tiempo. Si bien hay casos en los que el Scrum Master cumple, ademas
de su rol, el rol de desarrollador, no siempre es la mejor de las situaciones ya que ambas
responsabilidades podrıan llegar a exceder la disponibilidad de una sola persona, y ası alguno
de ambos roles no estarıa siendo cubierto satisfactoriamente.
5.4.1.4. Non-core Roles
Son los papeles que no son obligatoriamente necesarios para el proyecto Scrum y pueden
incluir miembros de los equipos que estan interesados en el proyecto. No tienen ningun papel
formal en el equipo pero pueden interactuar con este, sin embargo no pueden ser responsables
del exito del proyecto. Las Non-core Roles deben tenerse en cuenta en cualquier proyecto de
Scrum.
5.4 Metodologıa de desarrollo agil SCRUM 17
Figura 5-2: Caracterısticas deseadas de los papeles principales de Scrum.
Tomado de [8]
Non-core roles incluyen los siguientes:
• Socio(s): que es un termino colectivo que incluye a los customers, usuarios y patro-
cinadores, que con frecuencia interactuan con el Equipo Principal de Scrum, e influyen
en el project a lo largo de su desarrollo. Lo mas importante es que el proyecto produzca
beneficios de colaboracion para los socios.
• Cuerpo de asesoramiento de Scrum: es una funcion opcional, que generalmente
consiste en un conjunto de documentos y/o un grupo de expertos que normalmente
estan involucrados en la definicion de objetivos relacionados con la calidad, las regula-
ciones gubernamentales, la seguridad y otros parametros claves de la organizacion. El
guıa el trabajo llevado a cabo por el Propietario del producto, Scrum Master y Equipo
Scrum.
• Jefe Propietario del producto:es un papel en los proyectos mas grandes con Equi-
pos Scrums multiples. Esta funcion se encarga de facilitar el trabajo de los Propietario
del producto y del mantenimiento de Justificacion del negocio para el project mas
grande.
• Jefe Scrum Master:El es el responsable de coordinar las actividades relacionadas
con Scrum en grandes proyectos, las cuales pueden requerir que varios Equipos Scrum
trabajen en paralelo.
18 5 MARCO TEORICO
5.4.2. Proceso de Scrum
5.4.2.1. Inicio
1. Crear la vision del proyecto: En este proceso, se crea una declaracion de la vision
del proyecto que servira de inspiracion y proporcionara un enfoque de todo el proyecto.
2. Crear documento plan general del proyecto: define los parametros para realizar el
direccionamiento y seguimiento al proyecto. Especifica los objetivos. Describe como esta
organizado el proyecto y cuales son los recursos necesarios para su ejecucion (Tiempo,
Tecnologicos, Financieros, Fısicos y Humanos entre otros).
3. Representacion del Modelo relacional: es del diseno del esquema del proyecto,
el cual es practicamente un paso antes del nivel fısico debe ir aprobado por el comite
conformado en la oficina.
4. Identificacion del Scrum Master y de los Stakeholders:En este proceso, el Scrum
Master y los Stakeholder se identifican utilizando criterios de seleccion especıficos.
5. Formacion del equipo Scrum: En este proceso, se identifican a los miembros del
Equipo Scrum. Normalmente, el Product Owner es el responsable principal de la selec-
cion de los miembros del equipo, pero a menudo lo hace en colaboracion con el Scrum
Master.
6. Realizar un cronograma general:Se debe establecer un cronograma sencillo de todo
el proyecto mostrando el tiempo de cada fase.
7. Desarrollo de epicas: En este proceso, el Declaracion de la Vision del Proyecto sirve
como la base para el desarrollo de epicas.
8. Creacion de la lista priorizada de pendientes del producto: En este proceso,
las epicas son refinados, elaborados, y luego priorizados para crear un Backlog del
producto priorizado. Los criterios hechos tambien se establecen en este punto.
9. Realizar el plan de lanzamiento: En este proceso, el Equipo de Scrum revisa las
historias de usuario en el Backlog del producto priorizado para desarrollar un Programa
de planificacion de lanzamientos (Release Planning Schedule), que es esencialmente
un programa de implementacion por fases que se puede compartir con los socios del
proyecto.
5.4.2.2. Planear y estimar
1. Levantamiento del proceso a desarrollar(flujograma, prototipo, arquitectura de
informacion e historia de usuario): El flujograma debe estar en BPMN mediante la he-
5.4 Metodologıa de desarrollo agil SCRUM 19
rramienta Tooling, el prototipo mediante un diseno directamente en html, el diagrama
de arquitectura de informacion debe realizarse mediante el estandar de Archimate en el
programa Archi y la historia de usuario en Tuleap teniendo en cuenta las caracterısti-
cas de esta guıa, de igual manera las historias de usuario deben estar relacionadas con
una epica.
2. Aprobar, estimar y asignar historias de usuarios: En este proceso, el Producto
Owner aprueba las historias de usuario para un Sprint. Luego, el Scrum Master y el
Equipo Scrum estiman el esfuerzo necesario para desarrollar la funcionalidad descrita
en cada historia de usuario, y el Equipo Scrum se compromete a entregar los requisitos
del cliente en forma de: Approved, Estimated, and Committed User Stories.
3. Elaboracion de tareas: En este proceso, los Approved, Estimated, and Committed
User Stories se dividen en tareas especıficas y se compilan en una lista de tareas. Con
frecuencia, una reunion de planificacion de tareas se convocara al efecto.
4. Estimar tareas: En este proceso, el Equipo Principal de Scrum durante reuniones de
Estimacion de las tareas se estima el esfuerzo necesario para realizar cada tarea del
listado. El resultado de este proceso es conocido como un Effort Estimated Task List.
5. Elaboracion de la lista de pendientes del Sprint (Create Sprint Backlog): En
este proceso, el Equipo Principal de Scrum lleva a cabo la reunion de planificacion del
sprint, donde el grupo crea un Sprint Backlog que contiene todas las tareas que deben
completarse en el Sprint.
5.4.2.3. Implementar
1. Crear entregables: En este proceso, el Equipo Scrum trabaja en las tareas del Sprint
Backlog para crear Sprint Deliverables. Se utiliza a menudo el tablero de Scrum para
realizar el seguimiento del trabajo y de actividades que se llevan a cabo, conocido como
Scrum Board. Las cuestiones o problemas que enfrenta el Equipo Scrum podrıan ser
actualizadas en un Impediment Log.
2. Llevar a cabo el Sprint Standup diario: En este proceso, todos los dıas se lleva a
cabo una reunion conocida como Daily Standup Meeting. Es aquı donde los miembros
del Equipo Scrum se actualizan el uno al otro referente a sus progresos y sobre los
Impedimentos que puedan enfrentar.
3. Mantenimiento de la lista priorizada de pendientes del producto: En este
proceso, el Backlog del producto priorizado se actualiza y se mantiene continuamente.
La reunion de revision de este proceso es conocida como Prioritized Product Backlog
Review Meeting, en el que se discute y se incorpora la lista priorizada del producto de
forma apropiada.
20 5 MARCO TEORICO
5.4.2.4. Revision y Feedback
1. Demostracion y validacion del Sprint:En este proceso, el Equipo Scrum le de-
muestra los entregables con el Sprint Deliverable al Propietario del producto y a los
Socios relevantes en un Sprint Review Meeting. El proposito de esta reunion es asegu-
rar la aprobacion y aceptacion del Propietario del producto de los entregables creados
en el Sprint.
2. Feedback de Sprint: En este proceso, el Scrum Master, el Product Owner y el
Equipo Scrum se reunen para discutir las lecciones aprendidas a lo largo del Sprint.
Esta informacion se documenta como las lecciones aprendidas que pueden aplicarse
a los futuros Sprints. Con frecuencia, como resultado de esta discusion, puede haber
recomendaciones actualizadas conocidas como Agreed Actionable Improvements por
parte del Cuerpo de asesoramiento de Scrum.
5.4.2.5. Lanzamiento
1. Envıo de entregables: En este proceso, el Equipo Scrum le demuestra el Sprint de-
liverable al Propietario del producto y a los Socios relevantes en un Sprint Review
Meeting. El proposito de esta reunion es asegurar la aprobacion y aceptacion del Pro-
pietario del producto de los Entregables creados en el Sprint.
2. Feedback del proyecto: En este proceso, que completa el proyecto, los socios, el
propietario del producto y el Equipo Scrum se reunen para hacer una feedback del
proyecto e identificar, documentar e internalizar las lecciones aprendidas. A menudo,
estas lecciones llevan la documentacion del Agreed Actionable Improvement, que se
aplicara en futuros proyectos.
5.5. Reglamentacion del trabajo de grado para los
estudiantes de pregrado segun Acuerdo 038 de 2015
El trabajo de grado es un proceso formativo desarrollado por el estudiante como requisito
para optar al tıtulo profesional, que mediante la integracion y aplicacion teorica o teorico-
practica de conocimientos y habilidades o a traves de la generacion de nuevo conocimiento,
Buscar integrar las distintas competencias obtenidas a lo largo del proceso de formacion y,
de esta manera contribuir al analisis y solucion creativa de un problema relacionado con el
objeto de estudio o en el campo de accion su profesion.
5.5 Reglamentacion del trabajo de grado para los estudiantes de pregrado segun Acuerdo038 de 2015 21
5.5.1. Inscripcion y registro
El grupo o el estudiante presenta la solicitud de inscripcion a la coordinacion del Proyecto
corresponde, haciendo uso del formato determinado por el respectivo Consejo de Facultad
y adjuntando la documentacion solicitada dependiendo de la modalidad seleccionada por
el(los) estudiante(s). La coordinacion una vez recibida la solicitud realizara la verificacion
de los requisitos mınimos para la modalidad escogida con el fin de dar cumplimiento del
presente Acuerdo 038 de Julio 28 de 2015. La fecha maxima para la inscripcion del trabajo
de grado como espacio academico va ser la semana catorce de cada proyecto academico, las
coordinaciones realizaran el registro de los espacios academicos de las modalidades de grado
que hayan sido aprobadas por el Consejo Curricular en el sistema de informacion academico
“Condor”, en las fechas establecidas por el Calendario Academico para la adicion y cance-
lacion de espacios academicos.
5.5.2. Espacios academicos de posgrado
Como modalidad de grado los espacios academicos de postgrado, el estudiante debe cursar
y aprobar entre 8 y 9 creditos del programa de posgrado escogido, ya sea maestrıa o espe-
cializacion, brindados por la Universidad Distrital Francisco Jose de Caldas.
Como requisitos el estudiante debe haber aprobado el 80 por ciento de los creditos academi-
cos del plan de estudios cursado, tener un promedio acumulado de 3.8, ademas de enviar la
solicitud de inscripcion a la coordinacion del proyecto curricular. La eleccion de los estudian-
tes por el consejo curricular del programa de posgrado se definira de acuerdo a los siguientes
criterios:
• Se otorgan cinco (5) cupos por excelencia academica, se tomara como referencia el
promedio acumulado de los estudiantes que solicitaron la inscripcion, seran escogidos
de forma descendente.
• Segun la capacidad admitida del programa de posgrado, se otorgaran maximo 5
cupos para los estudiantes que se encuentren en condiciones economicas y calidades
academicas.
Cada espacio academico debera ser aprobado como mınimo con una calificacion de tres punto
cero (3.0). La modalidad sera aprobada como trabajo de grado si el estudiante obtiene una
calificacion final como mınimo de tres punto cinco (3.5). Esta calificacion se obtendra del
promedio aritmetico de las notas definitivas de cada espacio academico.
22 5 MARCO TEORICO
5.5.3. Espacios academicos de profundizacion
Brinda al estudiante, que se encuentra cursando el nivel profesional tecnologico, la posibilidad
de inscribir espacios academicos de cualquier programa de nivel profesional de la universidad,
ya sea de larga duracion (pregrado) o en los programas organizados por ciclos propedeuticos.
Como requisitos el estudiante debe haber aprobado mınimo el 80 por ciento de los creditos
academicos del plan de estudios que esta cursando, y haber presentado la solicitud a la
coordinacion de pregrado del proyecto curricular en donde se tomaran los espacios academicos
de profundizacion.
El estudiante debe cursar y aprobar 6 creditos como mınimo con una calificacion de tres
punto cero (3.0) para cada espacio academico. La modalidad sera aprobada como trabajo de
grado si el estudiante obtiene una calificacion final como mınimo de tres punto cinco (3.5).
Esta calificacion se obtendra del promedio aritmetico de las notas definitivas de cada espacio
academico.
5.5.4. Investigacion – Innovacion
Implica el vınculo del estudiante a un proyecto que fomente la formacion en investigacion y
en la innovacion, la estructura de investigacion vinculada con el estudiante (instituto, grupo
o semillero de investigacion) debe estar institucionalizado por el Centro de Investigaciones
y Desarrollo Cientıfico (CIDC) de la Universidad Distrital Francisco Jose de Caldas o una
entidad reconocida por COLCIENCIAS, con un mınimo de un ano de creacion. El proyecto
debe conformar un plan de actividades de investigacion avalada por la estructura de inves-
tigacion. La modalidad se calificara cuando se realice el promedio aritmetico entre las notas
dadas por el docente director y el docente evaluador, donde se evaluara el informe de acti-
vidades de investigacion desarrollados en el transcurso del proceso investigativo, ademas de
la socializacion para la comunidad academica pactado en el Acuerdo 38 de 2015.
5.5.5. Produccion academica
En esta modalidad el estudiante da evidencia de publicacion o aceptacion de un (1) artıculo
en revista homologada por el sistema Publindex de COLCIENCIAS, para la publicacion del
artıculo cientıfico, la categorıa mınima es “C”, o que este homologado en el ultimo cuartil
del JCR (Journal CItation Reports). Con el fin de dar cumplimiento a la modalidad de
trabajo de grado, el estudiante presenta una propuesta de publicacion avalada por un docente
adscrito a la entidad de investigacion institucionalizada (institutos, grupos o semilleros de
investigacion). En la evaluacion de la modalidad, el estudiante tendra que entregar evidencia
de la publicacion del artıculo cientıfico o el certificado de aceptacion para la publicacion
expedida de la revista referida.
6 ALCANCES Y LIMITACIONES
6.1. Alcances
El desarrollo de los modulos (espacios academicos de posgrado, espacios academicos de pro-
fundizacion, innovacion-investigacion y produccion academica) cubre los siguientes ambitos:
• El proyecto abarca las etapas de inicio, planeacion, implementacion y revision del
proceso de desarrollo SCRUM/OAS, estara estructurado en 16 Sprints por cada fase.
• Cada Sprint corresponde a una o 3 semanas, dependiendo de la complejidad de las
historias de usuario.
• El equipo de trabajo se organizara por los roles definidos en el proceso de desarrollo
SCRUM/OAS. El rol que se asumira en la pasantıa corresponde a desarrollador.
• Modificar el diseno del modelo de la base de datos con el fin de adaptarlo a las
modalidades a desarrollar.
• Se ejecutaran pruebas funcionales y/o no funcionales de software con el fin de cumplir
con las especificaciones establecidas por el analista, teniendo en cuenta la arquitectura
previamente definida.
• Implementar servicios web para consumir servicios de sistemas cercanos que perte-
nezcan al modelo de negocio.
6.2. Limitaciones
• La solucion de software sera desarrollada unicamente con herramientas de software
libre.
• La solucion de software estara basada en los lineamientos del software libre dando
respuesta a polıticas distritales e institucionales.
24 6 ALCANCES Y LIMITACIONES
• El producto de software esta enfocado solo para los programas academicos de pre-
grado.
7 ANTECEDENTES
7.1. SGPG-UD
El Sistema de Gestion de Proyectos de Grado de la Universidad Distrital (SGPG-UD), es
un prototipo web realizado por Juan Camilo Vargas Jerez, obtenido como resultado de la
tesis de pregrado denominada Analisis, diseno e implementacion de un prototipo web para
la gestion de trabajos de grado bajo las modalidades de monografıa y pasantıa en la facultad
de ingenierıa de la Universidad Distrital [4].
El sistema abarca la gestion de los trabajos de grado en las modalidades de monografıa y pa-
santıa, donde generalizan los procesos dividiendolos por modulos que representan las etapas
de gestion de pre-propuestas, propuestas, anteproyectos, proyectos, la gestion de informes
finales, y el modulo que controla la seguridad del sistema, asignando privilegios dependiendo
del rol de usuario.
Figura 7-1: Estructura del aplicativo de SGPG-UD. Tomado de [4]
Para de la estructura general del prototipo SGPG-UD, se encuentra el sistema core, el
cual esta basado en XML/XSL y ha sido disenado para transformar los documentos XML,
que fueron generados por cada pagina del aplicativo, en otros formatos de texto, como
HTML, XHTML u otro formato XML facilitando la separacion entre logica de negocio y la
presentacion de la informacion [4]
26 7 ANTECEDENTES
7.2. UDLEARN
El sistema UDLEARN fue un modelo de software propuesto para los proyectos curriculares
de la facultad de ingenierıa de la Universidad Distrital Francisco Jose de Caldas, orientados
en tecnicas de minerıa de datos y Learning Analytics para el apoyo de la toma de decisiones
academico-administrativas de la institucion
El sistema cuenta con los modulos de consultas de rendimiento academico, consultas de
practicas academicas con los procesos relacionados a los proyectos de grado, y el modulo que
nos compete relacionado a la gestion de los procesos relacionados con los proyectos de grado,
desde la fase de inicio y creacion de trabajos de grado, asignacion de revisores, jurados
e ingreso hasta la finalizacion de los mismos, ingresando el acta de sustentacion publica.
Asimismo cuenta con estadısticas e informes sobre los trabajos de grado en relacion con las
tematicas de interes y los docentes que participan en este proceso [12]
Figura 7-2: Consulta del nivel de participacion de los docentes en los trabajos de grado.
Tomado de [12]
UDLearn, es una evolucion del prototipo realizado por Juan Camilo Vargas Jerez (SGPG-
UD), adicional a ello, el sistema UDLearn cuenta con una funcionalidad adicional, la gene-
racion de estadısticas sobre los trabajos de grado asignados por docente y por las tematicas
de interes registradas.
7.3. POLUX VERSION 1.0
Es el sistema de gestion de proyectos de grado que se migro del aplicativo UDlearn. Ac-
tualmente el sistema se encuentra en pruebas y es sobre el cual se va a trabajar para las
modalidades de trabajo de grado, los procesos que se encuentran desarrollados son los de la
modalidad de monografıa, donde se encuentra subdivididos en los modulos de anteproyecto,
7.3 POLUX VERSION 1.0 27
proyecto e informe final. La solucion de software esta basada en el framework Sara y utiliza
PostgreSQL como herramienta de administracion de los datos que pertenecen al proyecto.
Figura 7-3: Formulario de consulta del anteproyecto. Tomado de [3]
8 METODOLOGIA
Para este proyecto se trabaja con la metodologıa SCRUM-OAS, en el rol de desarrollador.
Para este rol se tienen en cuenta las siguientes actividades puntuales a describir:
8.1. Registro de epicas, historias de usuario y tareas
La herramienta online para el registro de elementos del proyecto conocida como Tuleap, nos
permite dependiendo de los requerimientos planteados, crear artefactos generales o particula-
res, dependiendo del enfoque que se este trabajando para el determinado sprint del proyecto.
SE realiza a travez de Epicas si una historia de usuario que por su gran tamano, el equipo
descompone en historias con un tamano mas adecuado para ser gestionada con los principios
y tecnicas agiles.
Figura 8-1: Agregar una tarea en una historia de usuario. Autoria Propia
Antes de realizar esta actividad, es imprescindible tener el proyecto previamente creado por
el administrador, ası como la asignacion de permisos necesaria, para poder visualizar y apli-
car las actividades necesarias para el proyecto.
Cuando el equipo de trabajo este asociado al proyecto, se tendra la posibilidad de crear his-
torias de usuario, de estas se podran crear tareas asociadas a cada historia, y de este modo
la plataforma sera utilizada para asignar cada una de las tareas al integrante involucrado
en desarrollar la caracterıstica asociada a esa tarea, realizando una estimacion del tiempo
gastado en desarrollar esa funcionalidad para el proyecto.
8.2 Control y actualizacion en el tablero Kanban 29
8.2. Control y actualizacion en el tablero Kanban
Para llevar a cabo un seguimiento de cada entrega, los involucrados tendran que realizar
comentarios para evidenciar los avances de cada tarea y el proceso que se tuvo en cuenta
para el desarrollo.
Figura 8-2: Comentarios y asignacion de tiempos. Autoria propia
Adicionalmente se tienen que realizar modificaciones en los puntos de cada historia de usua-
rio, dependiendo del avance realizado.
En estas reuniones se revisan los comentarios realizados ası como el estado en el que se
encuentran actualmente las tareas para cada integrante del proyecto.
Figura 8-3: Actualizacion de puntos de historias de usuario. Autoria Propia
El estado de una tarea puede estar en progreso, si ocurrio alguna novedad no contemplada;
en revision, si ya finalizo pero requiere algun cambio necesario para ser totalmente aprobado;
o terminada, si ya fue finalizada y aprobada en su totalidad. Por ultimo se asignan nuevas
30 8 METODOLOGIA
tareas para el siguiente sprint que correspondera a una entrega para la(s) siguiente(s) sema-
na(s) (dependiendo de la complejidad de la tarea).
Semanalmente se realizan reuniones breves con el fin de realizar la revision de las tareas
asignadas en el pasado sprint y revisar el estado de la grafica burndown Chart, donde se
estima el sprint obtenido versus el ideal.
Figura 8-4: Grafica Burndown Chart para el Sprint de un proyecto.
Autoria Propia
Si la grafica tiende a caer hacia el eje x en relacion con los puntos de la historia de usuario(eje
Y) versus el tiempo transcurrido (eje X), significa que obtuvo el rendimiento o la efectividad
ideal para un determinado sprint realizado.
9 DESARROLLO
9.1. Modelo de negocio actual
Actualmente la Oficina Asesora de Sistemas en su meta de crear un aplicativo que maneje
los procesos para las modalidades del trabajo de grado para cada estudiante de pregrado de
la Universidad Distrital, desarrolla el sistema de proyectos de grado Polux para una unica
modalidad la cual es Monografıa. El sistema ahora esta integrado con el modelo de datos
que fue cambiado y se re-adapto para que este modelo funcione con los demas aplicativos
que exige el subsistema.
La idea de haber re-adaptado de lo que ya se tenia desarrollado a nuevas tecnologıas, con-
sistıa en un proyecto de interrelacion de todos los modelos de datos relacionales trabajados
en varios subsistemas(academica, financiera), ası como otros proyectos, Polux busca inte-
grarse con el subsistema de gestion academica con el fin de trabajar con los datos necesarios
de manera que se garantice la integridad referencial a pesar de que exista un cambio en
cualquier proyecto relacionado al subsistema.
Adicional a ello es importante identificar y analizar los diferentes patrones (reglas y hechos)
y metodos (procesos) que exigen las diferentes modalidades del trabajo de grado especifica-
das en el acuerdo N 038 de 2015, con el fin de extender el sistema entendiendo las posibles
diferencias, igualdades o similitudes de las modalidades entre si.
9.2. Modelo y Notacion de Procesos de Negocio
La representacion del modelo de procesos de negocio se basa en un estandar que proporciona
al negocio la capacidad de entender sus procedimientos internos en una notacion grafica y le
brinda a la organizacion la habilidad de comunicar estos procesos de una manera estandar.
Ademas, este grafico facilita la comprension entre las interacciones y cada transaccion de
negocio involucrada entre una o varias organizaciones. Esto nos ayuda a asegurar que el
dueno del producto entienda por si mismo junto a sus participantes a entender las diferentes
operaciones necesarias para ejecutar un procedimiento, teniendo en cuenta una secuencia
cronologica.
32 9 DESARROLLO
Esto asegurara que la entidad involucrada se comprenda a sı misma junto a los participantes
en su negocio y permitira a los diferentes servicios adaptarse a las nuevas circunstancias
que se planteen a futuro. Lo anterior se basa en los flujogramas de tipo BPMN (Business
Process Modeling Notation), estandar que se esta manejando para la arquitectura orientada
a servicios usada en el proyecto.
Figura 9-1: BPMN general del proceso del trabajo de grado en documentos. Tomado de [6]
Dentro del equipo de SCRUM se trabajo con el analista de sistemas para la construccion de
los flujogramas para los procesos de negocio. Con ello se obtuvieron dos diagramas BPMN
especıficos que abarcan las modalidades de espacios academicos de profundizacion y de espa-
cios academicos de postgrado, estos diagramas tienen caracterısticas similares como se puede
observar en los anexos A.1 y A.2.
Figura 9-2: BPMN general del proceso del trabajo de grado en espacios academicos. To-
mado de [6]
Adicional se obtuvo un diagrama de proceso general para abarcar todas las modalidades
diferentes a las anteriores, esto nos permitio reunir todo el conjunto de procedimientos si-
milares en un unico flujograma, para tener un proceso generico como base y de allı, derivar
9.3 Interfaces de Programacion de Aplicaciones 33
sus posibles operaciones para las diferentes modalidades, con el fin de generar un diagrama
BPMN para cada una de estas. La interaccion entre los usuarios junto con la secuencia cro-
nologica de cada uno de los procesos del modelo general se evidencia en el Anexo A.3.
Estas ultimas modalidades caracterizadas generalmente por que requieren de documentos
como la propuesta o anteproyecto, y trabajo o informe final, adicional necesitan de un for-
mato de evaluacion para sustentacion del proyecto de grado en cuestion.
Estos son algunos subprocesos que fueron analizados para cada una de las modalidades
y junto con los procesos individuales de estas, se tendran los diferente modelos de procesos
de negocio para pasantıa para el Anexo A.4, monografıa Anexo A.5 produccion academica
Anexo A.6, creacion o interpretacion Anexo A.7, proyecto de emprendimiento Figura 9.9 e
investigacion-innovacion Anexo A.8.
9.3. Interfaces de Programacion de Aplicaciones
9.3.1. Polux Crud API
Esta aplicacion se encarga de administrar las conexiones hacia los servicios web de SARA
en su primera implementacion de Polux [3].
Esto con el fin de obtener la informacion necesaria para realizar los procesos de inscripcion
al trabajo de grado, al de registro y revisiones de un documento, ası como de los procesos
necesarios para las modalidades que manejan espacios academicos.
Adicional a esto, el API CRUD de Polux se conecta con el MID API con el fin de obtener
respuestas de los parametros enviados requeridos por las reglas de este ultimo.
9.3.2. Polux MID API
El componente MID API recibe los parametros necesarios para procesar las reglas, dichos
parametros pueden venir del API CRUD o directamente de la aplicacion Polux Cliente.
Una vez recibidos estos parametros, el MID API solicita los servicios necesarios al Ruler
API.
9.3.3. Ruler API
El componente Ruler se encarga de ejecutar las reglas teniendo en cuenta los predicados
predefinidos del dominio. Con el fin de brindar una respuesta al componente del MID API.
34 9 DESARROLLO
Figura 9-3: Diagrama de Componentes de las APIs para Polux
Autorıa Propia
9.4. Modelo de datos
Junto con el equipo de desarrolladores y el lıder del proyecto se plantearon reuniones diarias
con el fin de realizar el diseno del modelo para el esquema de datos.
Este modelo esta conformado por 34 entidades, este conjunto de tablas estan planteadas
para mantener la integridad referencial de los datos.
La base de datos de prueba de la Universidad Distrital cuenta con varios esquemas, cada
esquema representa a un diseno de cada proyecto realizado para la entidad.
Para integrar el modelo a la base de datos de la Universidad Distrital, se genero el lenguaje
de definicion de datos (DDL), donde el esquema se nombro como Polux
Por parte de la Oficina Asesora de Sistemas (OAS), se realizo varias revisiones en las reunio-
nes programadas con el administrador de bases de datos (DBA) de la OAS, con el fin de
socializar el modelo disenado e identificar las posibles falencias y corregir el modelo.
En la siguiente ilustracion se podra detallar el modelo, este diseno es la ultima version,
cada seccion es explicada en la version previa [6], lo que se tiene a continuacion son los
cambios realizados del modelo de entidades, que fueron necesarios durante el desarrollo de
cada modulo para la aplicacion.
9.4 Modelo de datos 35
Figura 9-4: Ultima version del Diseno del Modelo de Datos, Oficina Asesora de Sistemas
9.4.1. Cambios en la ultima version del modelo
9.4.1.1. Espacios Academicos
Previamente se diseno junto con el equipo de trabajo un conjunto de entidades que abarcaban
lo relacionado a las modalidades donde se puede acceder a cursos de profundizacion o de
postgrado.
Como en la version previa, el proceso para las dos modalidades es el mismo,la diferencia
esta en las etapas de seleccion y aprobacion que los espacios que seran manejados por la
aplicacion [6].
Se planteo una tabla que maneja las solicitudes hechas por un estudiante, para diferenciar
cada solicitud, se maneja la propiedad id-trabajo-grado, que es la referencia de la tabla
trabajo-grado.
Adicional a ello, se plantearon las propiedades requeridas para la tabla de solicitud-materias
como son el estado de la solicitud, la fecha, el periodo, el ano, entre otros. Ademas cada
solicitud hecha puede tener varias asignaturas inscritas, por lo que se planteo una tabla de
asignatura-inscrita con las propiedades requeridas y la referencia de la solicitud.
Como cada asignatura puede estar en diferentes solicitudes se agrega una referencia a esta
tabla para las asignaturas elegibles llamada id-asignaturas-elegibles.
En la tabla de asignaturas-elegibles no se habıa considerado que esas asignaturas pertenecıan
a una carrera elegible en particular. Por ello se plantea una nueva entidad llamada carrera-
elegible , que me permite agrupar las diferentes carreras por codigo y por pensum, asimismo
36 9 DESARROLLO
se maneja el control de cupos ya sea por excelencia academica o los cupos adicionales que se
abran por carrera.
Figura 9-5: Diseno del Modelo los Espacios Academicos
Oficina Asesora de Sistemas
9.4.1.2. Evaluacion
La gestion de evaluacion del trabajo de grado planteada en la version previa, guarda la
informacion acerca de la revision de los documentos para las modalidades que requieren de
un registro de documentos, donde se persisten elementos como la socializacion y calificacion
por parte del docente revisor y director [6].
Para los espacios academicos, la evaluacion de un trabajo de grado es realizada por un
promedio de las asignaturas vistas.
El diseno para la evaluacion esta modelado para generar formatos de evaluacion para cada
uno de los proyectos curriculares, y ademas podran ser reutilizados o generar duplicados para
cambiar los formatos ya pre-construidos, que servirıan como plantillas para crear nuevos.
9.5 Representacion y uso de reglas utilizando Golog. 37
La diferencia con la version previa radica en que el paquete de respuestas ya no es necesario
tenerlo como tabla, debido a que con las entidades disenadas respuesta-evaluacion y pregunta-
formato cubren la informacion necesaria para interrelacionar las demas tablas que cubren la
evaluacion de un documento.
Figura 9-6: Diseno del Modulo de Evaluaciones
Oficina Asesora de Sistemas
9.5. Representacion y uso de reglas utilizando Golog.
Debido a los requisitos planteados al inicio del proyecto y teniendo en cuenta como punto de
partida el acuerdo 038 que rige los ultimos lineamientos de la reglamentacion de los trabajos
de grado[2], se establece una logica que no va a ser almacenada dentro del modelo de datos.
Esto con el objetivo de que si se genera un nuevo acuerdo que modifique el actual, el cambio
no impacte directamente al diseno de la base de datos, si no que le permita a esta logica
ser independiente, flexible para modificaciones y extensible para agregar nuevo conocimiento
requerido. Dicha logica fue representada como hechos y reglas, con el fin de que pudieran ser
procesados por Golog, este ultimo es un interprete de Prolog para el lenguaje Golang.
38 9 DESARROLLO
Hecho Descripcion
minimo numero creditos posgrado(8).
minimo numero creditos profundizacion(6).
Mınimo numero de creditos para
la solicitud de las modalidades de
materias de posgrado y profundi-
zacion
promedio materias posgrado(3.8). Promedio mınimo para acceder a
la modalidad de materias de pos-
grado
nivel carrera(pregrado). Nivel de la carrera (pregrado, pos-
grado)
estado estudiante tg(activo). Estado del estudiante para acce-
der a una modalidad de trabajo
de grado
porcentaje tg(80). Porcentaje mınimo para acceder a
la modalidad de trabajo de grado
Tabla 9-1: Manejo de Hechos en Golog. Parte 1
Autorıa Propia
A continuacion, se dara una explicacion de las reglas que se construyeron y que fueron
probadas para el desarrollo del aplicativo. A partir del MID-API se tienen en cuenta los
parametros enviados del lado del cliente, y con ello se traen las reglas del api ruler para
ejecutar las peticiones de los servicios del MID-API. En la primeras tablas se definen los
hechos, correspondientes a la base de conocimientos requerido para que las reglas puedan
ser ejecutadas.
9.5 Representacion y uso de reglas utilizando Golog. 39
Hecho Descripcion
inicio semestre(’2017/02/01’). Fecha de Inicio del semestre
fecha inicio proceso seleccion(’2017/04/23’). Fecha de inicio del proceso de se-
leccion de admitidos al posgra-
do en la modalidad de espacios
academicos
segunda fecha proceso seleccion(’2017/05/21’). Segunda fecha para el proceso de
seleccion de admitidos al posgra-
do en la modalidad de espacios
academicos
fecha fin proceso seleccion(’2017/06/23’). Fecha en la que finaliza el proceso
de seleccion de admitidos al pos-
grado en la modalidad de espacios
academicos
max cupos adicionales(5). Cupos adicionales para estudian-
tes que esten en condiciones
economicas y calidades academi-
cas
max cupos excelencia academica(5). Maximo de cupos por excelencia
academica
Tabla 9-2: Manejo de Hechos en Golog. Parte 2
Autorıa Propia
Como se puede evidenciar, los hechos nos brinda informacion que es vital para ejecutar las
posibles restricciones de alguna modalidad. En la siguiente tabla, se describen las reglas,
encargadas de realizar la validacion de los requisitos para cada modalidad.
40 9 DESARROLLO
Reglas Descripcion
validacion requisitos(X):- estado(X,activo),
porcentaje tg(P), nivel carrera(V), cursa-
do(X,C), C @>=P, nivel(X, N), N == V.
Validacion de todos los requisitos
validacion posgrado(X):-
validacion requisitos(X),
promedio materias posgrado(P),
promedio(X,E), E @>=P,
tipo carrera(X, T), T \== tecnologia.
Validacion de requisitos para la
modalidad de materias de posgra-
do
validacion profundizacion(X):-
validacion requisitos(X),
tipo carrera(X, T), T == tecnologia.
Validacion de requisitos para la
modalidad de materias de profun-
dizacion
validacion creacion(X):-
validacion requisitos(X),
tipo carrera(X, T), T == artes.
Validacion de requisitos para la
modalidad de creacion o interpre-
tacion
Tabla 9-3: Manejo de Reglas en Golog
Dentro del esquema ruler de la base de datos se tiene la informacion contemplada de los
hechos y reglas necesarios para cada proyecto dependiendo de su funcionalidad. El tipo
de predicado que puede ser un hecho o una regla tiene su propia tabla, como tambien
todos los registros de los hechos y reglas que se encuentran en la tabla de predicados, cada
predicado esta asociado a un dominio, que representa los diferentes conjuntos asociados a
una funcionalidad en particular.
9.6. Modulo de Registro de Propuesta de un trabajo de
grado
Este sirve como base para implementarlo en diferentes modalidades de grado asociado a un
documento. Asimismo, gracias al modelo de datos planteado anteriormente, nos sirve como
modulo para registrar cualquier tipo de documento asociado al trabajo de grado, ya sea acta,
propuesta, documento final, entre otros.
9.6 Modulo de Registro de Propuesta de un trabajo de grado 41
9.6.1. Submodulo de informacion basica del registro
Para este primer modulo, se recibe como dato principal el codigo del estudiante, seguidamente
se escoge la modalidad por la cual va optar.
Una vez la modalidad fue escogida, se hara una validacion de los requisitos, tomando como
referencia la modalidad y, el codigo del estudiante, donde tendra informacion derivada acerca
del porcentaje cursado de la carrera, el estado del estudiante, la calificacion mınima para
optar por la modalidad, entre otras.
Figura 9-7: Ejemplo de interaccion con modulo de informacion basica despues de obtener
una respuesta afirmativa. Autorıa Propia
Si al ejecutar las reglas correspondientes de la validacion de los requisitos, obtiene una res-
puesta afirmativa por parte del Mid Api, entonces el formulario mostrara opciones adicionales
para continuar con el registro como lo son la entrada para redactar el titulo y la descripcion
del documento.
En caso contrario, si no pasa la validacion de los requisitos para la modalidad, mostrara
un mensaje confirmando que el estudiante no cumple con los requisitos requeridos para la
modalidad. Una vez llenados los campos, se tiene la posibilidad de limpiar la informacion o
de confirmar los datos y continuar con el siguiente submodulo.
9.6.2. Submodulo de asignacion de areas de conocimiento y carga del
archivo del documento
Luego de haber confirmado la informacion basica del documento, el usuario tiene la posibi-
lidad de asociar diferentes areas de conocimiento existentes al trabajo de grado.
Del mismo modo se permite al usuario subir el archivo asociado a la propuesta, la carga
del archivo se realiza por medio de una libreria llamada Nuxeo-Js-Client del lado del clien-
te, que trabaja desde el navegador con NodeJS y un servidor Nuxeo de lado de la parte
Backend, por medio de Javascript. El documento estara alojado en uno de los espacios de
trabajo (Workspaces) del Software de gestion documental escogido por la Oficina Asesora
de Sistemas, conocido como Nuxeo.
42 9 DESARROLLO
9.6.3. Confirmacion del registro y manejo de transacciones
Finalizado el registro , el usuario realiza la confirmacion del proceso, a partir de ello. Comien-
za el flujo de transacciones del cliente hacia el api-crud, este que a su vez tiene sincronizada
la informacion de la base de datos en el esquema Polux. Todos los datos hasta antes de la
ejecucion del proceso de registro estan almacenados en memoria.
El flujo de transacciones comienza realizando un registro en la tabla trabajo grado, donde el
objeto que estaba guardado en memoria hasta el momento se registra mediante una peticion
post para el trabajo de grado.
Figura 9-8: Peticion para guardar el registro de un trabajo de grado
Autorıa Propia
Figura 9-9: Transaccion de un registro en la tabla trabajo de grado
Autorıa Propia
Dicha peticion envıa una respuesta, la cual es el objeto o registro ya guardado en la tabla,
esta respuesta va a ser usada para construir el objeto que relaciona el estudiante con el
trabajo de grado, debido a que este requiere de la referencia del trabajo de grado. Despues
de creado el objeto se ejecuta la siguiente peticion post para la tabla estudiante tg.
Figura 9-10: Peticion para guardar el registro de un trabajo de grado asociado a un estu-
diante
Autorıa Propia
Figura 9-11: Transaccion de un registro en la tabla estudiante trabajo grado. Autorıa Pro-
pia
Seguidamente el identificador del objeto del trabajo de grado se seguira utilizando para
construir el objeto de las areas de conocimiento asociadas a un trabajo de grado, para luego
ejecutar la peticion post al api-crud para la tabla areas trabajo grado.
9.6 Modulo de Registro de Propuesta de un trabajo de grado 43
Figura 9-12: Peticion para guardar el registro de un trabajo de grado asociado a un area
de conocimiento. Autorıa Propia
Figura 9-13: Transaccion de un registro en la tabla areas trabajo grado. Autorıa Propia
Despues de este paso, se ejecuta la funcion que construye el objeto del documento, este
contiene la informacion referida al titulo, la descripcion y el enlace de un documento. Como
en los pasos anteriores se ejecuta la peticion post para la tabla documento.
Figura 9-14: Peticion para guardar el registro de un documento asociado a un trabajo de
grado. Autorıa Propia
Figura 9-15: Transaccion de un registro en la tabla documento. Autorıa Propia
Por ultimo se construye el objeto que comparte la relacion entre el documento y el trabajo
de grado, para ello se requerıa del identificador (llave foranea en terminos de bases de datos)
de cada una de las respuestas de las peticiones realizadas para el documento y el trabajo
de grado; esto con el objetivo de ejecutar la ultima transaccion, garantizando la integridad
referencial de todo el proceso ejecutado anteriormente.
Figura 9-16: Transaccion de un registro en la tabla documento asociado a un trabajo de
grado. Autorıa Propia
44 9 DESARROLLO
9.7. Modulos de Espacios academicos de Posgrado y
Profundizacion
Dentro del acuerdo que rige las diferentes modalidades de grado, existen dos modalidades
que gestionan asignaturas en vez de documentos para un trabajo de grado. A continuacion
se hablara en detalle de cada modulo que gestiona estos procesos.
9.7.1. Submodulo de publicacion de espacios academicos
A partir de este modulo se tiene la posibilidad de escoger la carrera y el pensum, dado el ano
y periodo actual. Y a partir de la informacion filtrada, se despliega la lista de los posibles
espacios academicos a escoger.
Figura 9-17: Publicacion de espacios academicos por carrera y pensum
Oficina Asesora de Sistemas
Cada espacio academico tiene una cantidad de creditos academicos asociada. Una vez es-
cogido los espacios academicos, se consultara por medio de los servicios del MID Api, la
cantidad mınima de espacios academicos de posgrado necesarios para modalidad, ya sea
para las carreras de posgrado, o para las de profundizacion.
9.7 Modulos de Espacios academicos de Posgrado y Profundizacion 45
Figura 9-18: Escenario cuando no cumple la cantidad mınima de espacios academicos
Oficina Asesora de Sistemas
La coordinacion del proyecto curricular de posgrado debera publicar hasta la semana (10)
del calendario academico de pregrado, el listado de espacios academicos elegibles por parte
de un estudiante de pregrado.
46 9 DESARROLLO
9.7.2. Submodulo de solicitud de inscripcion
Los requisitos que un estudiante debe cumplir para un trabajo de grado en la solicitud de
una inscripcion para este tipo de modalidades, son gestionados en este submodulo. Esto con
el fin de que las coordinaciones de los proyectos curriculares de pregrado no tengan que
realizar la verificacion de los requisitos, y que el sistema lo haga. Mediante los parametros y
las reglas asociadas a ellos, la aplicacion realizara la validacion necesaria. Estos parametros
se muestran en la siguiente tabla:
Parametros Valores
Estado Activo
Porcentaje cursado Igual o superior al 80 %
Promedio Igual o superior a 3.8
Nivel de Carrera Pregrado
Tipo de Carrera Diferente a Tecnologıa
Tabla 9-4: Requisitos para solicitar la inscripcion en carreras de Pregrado
Oficina Asesora de Sistemas
Parametros Valores
Estado Activo
Porcentaje cursado >= 80 %
Tipo de Carrera Tecnologıa
Tabla 9-5: Requisitos para solicitar la inscripcion en carreras Tecnologicas
Oficina Asesora de Sistemas
Dependiendo de como varıen los parametros y tambien el estado de la solicitud en el tiempo.
Pueden existir ciertos escenarios:
9.7 Modulos de Espacios academicos de Posgrado y Profundizacion 47
• El estudiante no cumple con los requisitos para la modalidad
Figura 9-19: Escenario (1) Estudiante no cumple con los requisitos
Oficina Asesora de Sistemas
• Estudiante que cumple los requisitos pero no tiene solicitudes en esa modalidad
Figura 9-20: Escenario (2), Estudiante cumple sin solicitudes
Oficina Asesora de Sistemas
48 9 DESARROLLO
• El estudiante con dos solicitudes en la modalidad
Figura 9-21: Escenario (3). Estudiante que tiene dos solicitudes. Oficina Asesora de Siste-
mas
9.7 Modulos de Espacios academicos de Posgrado y Profundizacion 49
• El estudiante que tiene las solicitudes aprobadas: En el caso de que el estudiante es
aceptado en alguno de los posgrados solicitados, debera formalizar la solicitud, esto
para que en caso de que pase a dos posgrados quede oficialmente solo en uno.
Figura 9-22: Escenario (4). Estudiante con solicitudes aprobadas. Oficina Asesora de Sis-
temas
50 9 DESARROLLO
9.7.3. Submodulo de consulta de solicitudes y seleccion de admitidos
En este modulo se muestra las solicitudes de los estudiantes por especializacion o carrera
tomando como referencia el periodo y el ano. Con ello la coordinacion puede revisar como
van las solicitudes de los estudiantes.
Figura 9-23: Modulo de consulta de admitidos por carrera
Oficina Asesora de Sistemas
En caso de empates con el promedio academico, se tiene un segundo factor en cuenta: el
rendimiento academico del estudiante, que calcula el sistema de gestion academica.
Igualmente se tienen en cuenta los procesos descritos del trabajo de grado en el calendario
academico referidos a las fechas estipuladas:
• Solicitud para la aprobacion de la modalidad de trabajo de grado
• Aprobacion de trabajos de grado
• Inscripcion de trabajos de grado
• Fecha Adicional (Opcional)
Para la seleccion de admitidos se propuso el siguiente flujo, donde se tienen las tres primeras
fechas tentativas para el proceso: Distribuidos en tres fases como se detalla a continuacion:
9.7 Modulos de Espacios academicos de Posgrado y Profundizacion 51
Figura 9-24: BPMN para el proceso de seleccion de admitidos a las modalidades de espacios
academicos. Oficina Asesora de Sistemas
Finalmente la coordinacion tendra la opcion de automaticamente realizar el calculo de los
admitidos para esa modalidad y realizar la seleccion, teniendo como entrada dos campos:
• La cantidad de admitidos permitida por excelencia academica y exentos de pago.
• La cantidad de admitidos por condiciones economicas y calidades academicas.
Figura 9-25: SubModulo de seleccion de admitidos
Oficina Asesora de Sistemas
52 9 DESARROLLO
9.8. Modulo de Gestion de Formatos
Este modulo permite gestionar los diferentes formatos de los proyectos de grado que tiene la
universidad, a su vez, permite a los docentes jurados llenar los formatos para que puedan eva-
luar los respectivos proyectos de grado, si el docente no desea llenarlos en linea directamente,
puede generar el formato en pdf para poder imprimirlo y llenarlo en otro momento.
9.8.1. Submodulo de formato consultar formato
En este modulo podemos filtrar el formato por el nombre y podemos ver la vista previa del
formato, adicionalmente, podemos imprimir, descargar o ver el formato en pdf.
Figura 9-26: Modulo Consultar formato de evaluacion
Figura 9-27: Botones de Accion para formato ver
9.8 Modulo de Gestion de Formatos 53
Figura 9-28: Formato pdf que genera el modelo
9.8.2. Submodulo de formato crear formato
Figura 9-29: Submodulo de nuevo formato
En la creacion de un formato de evaluacion tenemos un nombre, una introduccion y posterior
a ello las preguntas, cada pregunta puede tener 3 tipos de pregunta, cerradas, abiertas y
54 9 DESARROLLO
numericas, Las preguntas cerradas pueden ser de respuesta unica o multiple, cada pregunta
puede tener un peso en la evaluacion y a su vez cada respuesta puede tambien tener un peso.
los sub-modulos que componen este modulo son crear formato de evaluacion, editar formato
de evaluacion, ver formatos de evaluacion, y evaluar proyecto de grado.
La edicion de un formato adicional a lo mostrado anteriormente permite seleccionar el for-
mato que queremos editar y cargar solo los formatos editables.
9.8.3. Submodulo de asignar Formato a Proyecto Curricular
En este modulo se puede seleccionar un formato previamente creado y asignarlo a un proyecto
curricular, adicionalmente, seleccionar que modalidad va a evaluar dicho formato.
Figura 9-30: Submodulo de asignacion de formatos. Autorıa propia
9.8.4. Submodulo de Evaluar Proyecto
En este submodulo se puede llenar el formato y asociarlo al proyecto de grado, con la idea
de almacenar la evaluacion y posterior calificacion del proyecto de grado, la interfaz es muy
similar a la vista previa de todos los formatos de evaluacion.
9.9 Modulo de revision de Documentos 55
9.9. Modulo de revision de Documentos
9.9.1. Vista de Estudiante
El estudiante puede subir su documento del proyecto o anteproyecto de grado y solicitar una
nueva revision del proyecto de grado.
Figura 9-31: Submodulo revision de Documentos Estudiante. Autorıa propia
Cuando una revision es finalizada el estudiante puede ver los comentarios del docente y si el
docente asocio la pagina, el estudiante puede dar click en la pagina y ver directamente en el
modulo el documento con el respectivo comentario, a su vez el estudiante puede establecer
una comunicacion con el docente para resolver dudas sobre sus comentarios.
56 9 DESARROLLO
Figura 9-32: Submodulo revision de Documentos Estudiante. Autorıa Propia
9.9.2. Vista de Docente
Adicional a la vista del estudiante, el docente puede ver si tiene revisiones pendientes
9.10 Integracion continua. 57
Figura 9-33: Submodulo revision de Documentos Estudiante. Autorıa propia
9.10. Integracion continua.
9.10.1. Integracion Continua en la Oficina Asesora de Sistemas
En la oficina asesora de sistemas se definieron algunas herramientas que conforman el eco-
sistema de integracion continua tales como: Jenkins, Gogs, github, travis, etc.
Jenkins gestiona todas las tareas que comprenden propiamente la automatizacion de des-
pliegues en los diferentes entornos, por ahora Polux hace sus despliegues en un entorno de
pruebas en una direccion local.
9.10.2. Integracion Continua en API CRUD y MID API
El siguiente codigo muestra las tareas que realiza el servidor de jenkins para gestionar el
despliegue de api crud y el mid api escrito ambos en go, este despliegue es sensible de un
push en la rama develop del repositorio de gogs, en cada push se ejecuta el codigo llevando
al entorno de pruebas automaticamente.
1 DESTFOLD=$PWD
2 rm -rf $GOPATH/src/github.com/udistrital/Polux_API_Crud
3 mkdir -p $GOPATH/src/github.com/udistrital
4 git clone --depth 1 https://github.com/udistrital/Polux_API_Crud.git
5 $GOPATH/src/github.com/udistrital/Polux_API_Crud
6 cd $GOPATH/src/github.com/udistrital/Polux_API_Crud
7 GOOS=linux GOARCH=amd64 go build -x
8 mv Polux_API_Crud $DESTFOLD
58 9 DESARROLLO
9.10.3. Integracion Continua en el cliente de Polux
El siguiente codigo muestra el despliegue del cliente. Esta tarea permite tomar el proyecto,
minificarlo y llevarlo a produccion de una forma ligera , adicional a esto permite tener
actualizadas todas las librerıas que se usan, pues siempre que hay nuevas versiones, estas
son instaladas mediante el bower install y npm install, este despliegue es sensible de un push
en la rama master del repositorio de github, en cada push se ejecuta el codigo llevando al
entorno de pruebas automaticamente.
1 PATH=$PATH:/home/adbius/.jenkins/tools/jenkins.plugins.nodejs.tools.
2 NodeJSInstallation/recent_node/bin
3 echo $PATH
4 bower --version
5 npm install
6 bower install
7 grunt build
10 Generador de aplicaciones de angular
generator-oas
10.1. Inicio
Dada la libertad que tiene la arquitectura orientada a micro-servicios en cuanto a la cons-
truccion del front-end o aplicaciones del lado del cliente, fue complicado al inicio del proyecto
plantear un estandar que siguieramos todos los desarrolladores que estabamos escribiendo
aplicaciones en angularjs, De esta forma surgio la idea de utilizar generator-angular, herra-
mienta que construye un esqueleto inicial de un proyecto en angular. Estos generadores, son
construidos con una herramienta llamada generator-generator de yeoman.
Generator-angular fue una buena herramienta para comenzar con el desarrollo, pero tenıamos
el mismo inconveniente inicial, las aplicaciones que se escribıan ahora tenıan la misma estruc-
tura de directorios, pero, la variedad de colores y de estilos dependıan de la creatividad de
quien las escribıa, entonces la integracion que se pretendıa organizar con todas las otras apli-
caciones no era del todo amigable pues en cuanto a interfaz todas las aplicaciones parecıan
muy distintas.
10.2. Construccion
La idea era construir algo similar a generator-angular, es decir que con un simple comando
en la consola tener esta herramienta, que me permitirıa construir aplicaciones de una forma
mas facil y teniendo una estructura comun a todos los desarrolladores no solo a nivel de di-
rectorio, sino tambien a nivel de estilos, fuentes, librerıas de angular, conformacion de menus,
autenticacion unica, componentes de internacionalizacion, notificaciones, y otros desarrollos
que a futuro fueran el factor comun de todos los proyectos.
60 10 Generador de aplicaciones de angular generator-oas
10.3. Yeoman
Generator-angular fue construido por el equipo de desarrollo de Yeoman, Yeoman es una
iniciativa que tiene como objetivo brindar una gran ayuda a la hora de iniciar un proyecto
en algun lenguaje en particular, para esto emplea generadores de codigo construidos en
node.js y apoyado en varias herramientas como grunt, gulp, bower, npm, karma, etc podemos
automatizar procesos de desarrollo. En la pagina de yeoman podemos encontrar alrededor
de 6.500 generadores de diferentes lenguajes, con diferentes tecnologıas, Tambien nos da las
pautas para construir nuestro propio generador. [11]
10.4. Historico de versiones de generator-oas
Npm es un gestor de librerıas de software libre, la cual maneja el principio de inmutabilidad,
es decir que cuando lanzo una version no puedo anadir mas lıneas de codigo a la misma
version, es necesario construir una nueva version, es por eso que algunas versiones no se
encuentran en la lista y es porque son versiones intermedias que tenıan fallas y por esta
razon no apareceran en la descripcion de las versiones.
generator-oas@0.0.1:
Tuvo una duracion de 12 dıas y se implemento la version inicial del generador, la cual contenıa
a generator-angular con los assets de los estilos basicos desarrollados por el ingeniero Steven.
generator-oas@0.0.2:
Tuvo una duracion de 3 dıas y se realizo la implementacion del menu superior multinivel hasta
5 subniveles y se incluye en comun acuerdo con los desarrolladores la librerıa agregar ui-grid.
para el manejo de tablas, angular-oauth2 para OIDC, angular-material para el datapicker.
generator-oas@0.0.3:
Tuvo una duracion de 8 dıas y se ajustaron las vistas, rutas y directivas acorde a las necesi-
dades de la oas en funcion del desarrollo de los clientes y teniendo en cuenta el documento
de estandares.
generator-oas@0.0.4:
Tuvo una duracion de 12 dıas y se modificaron vistas iniciales, inclusion de autenticacion
unica, pruebas con google y con WSO2.
generator-oas@0.0.5:
Tuvo una duracion de 15 dıas y se edito el mensaje inicial al lanzar el comando + correccion
hash-mode html5 ! de la version de angular 1.5.9, Edicion de menu y adaptacion para oidc
+ footer + edicion de README.md para explicacion del uso del generator-oas.
10.5 Instalacion y uso 61
generator-oas@0.0.9:
Tuvo una duracion de 15 dıas y se realizo fork de generator-oas y merge de repo de fabian-
Leon/oas a udistrital/generator-oas, traslado de package de npm de Fabian Leon a udistrital
e integracion contınua con travis.
generator-oas@0.0.11:
Tuvo una duracion de 14 dıas y se construyo el menu dinamico, miga de pan, e integracion
entre el menu y la miga de pan.
generator-oas@0.0.12:
Tuvo una duracion de 5 dıas y se construyo funcionalidad de grunt-build, componente para
la generacion minimizada de los proyectos.
generator-oas@0.0.13:
Tuvo una duracion de 20 dıas y desarrollo de modulo de notificaciones, instalacion de com-
ponente angular-input-mask, anadir item de readme grunt build, correccion idioma, route
notificaciones y libreria angular-moment
generator-oas@0.0.16:
Tuvo una duracion de 3 dıas y se realizo la correccion de estilo .jshintrc y .jscsrc que genera
errores con la estructura inicial del proyecto
generator-oas@0.1.3:
Mejoramiento del task build de gruntfile para copia de todos los assets provenientes de
librerıas, pues el minificado lo traia dichos assets
10.5. Instalacion y uso
Instalacion en Centos 7 y creacion de mi primer app, La linea 4 y 5 se omiten si no se requiere
configuracion de proxy:
62 10 Generador de aplicaciones de angular generator-oas
1 ## Instalacion
2 sudo yum install epel-release
3 sudo yum install npm
4 sudo npm config set proxy http://127.0.0.1:8080/
5 sudo npm config set https-proxy http://127.0.0.1:8080/
6 sudo npm install -g grunt-cli bower yo generator-karma generator-oas
7 ## Creamos en la ubicacion donde queramos alojar la aplicacion
8 mkdir nombre_app
9 cd nombre_app
10 yo oas
Figura 10-1: generator-oas, lo que aparece al ejecutar el comando $ yo oas . Autorıa propia
Se recomienda dejar los componentes de angular predefinidos (Enter) Si en un momento
llega a quedarse a la espera de algo, solo espera un (Enter)
El arbol de directorios que me genera es el siguiente:
10.5 Instalacion y uso 63
Figura 10-2: Arbol de directorio. Generador OAS. Autorıa propia
Posterior a la creacion del proyecto se tendra un entorno de desarrollo que nos provee herra-
mientas bastante utiles, como lo son npm y bower; que sirven para la instalacion de librerıas
y/o componentes que podemos anadir en cualquier momento, grunt que es una herramien-
ta para automatizar tareas que suelen ser repetitivas como por ejemplo refrescar la pagina
del navegador cada vez que se realiza un cambio, Algunas tareas que vienen prefabricadas
gracias a generator-oas son:
64 10 Generador de aplicaciones de angular generator-oas
• grunt serve:
Con este comando nos abrira en el navegador predeterminado una pestana con el
proyecto corriendo en http://localhost:9000 y nos aparecera
Figura 10-3: generator-oas, app que construye. Autorıa propia.
• grunt build:
Con este comando se construira una version del proyecto lista para llevar a un ambien-
te de produccion, muy importante para integracion contınua, ya que los despliegues
automaticos actuales usan esta tarea de grunt.
10.5 Instalacion y uso 65
Figura 10-4: Arbol de directorio de dist/. Autorıa propia
• grunt test:
Con este comando corremos todas las pruebas unitarias que tengamos programadas e
indexadas en karma
10.5.1. Librerıas que instala generator-oas
Las siguientes son las librerıas que se han socializado y anadido poco a poco a generator-oas.
• ui-grud
• angular-material
• bootstrap 3.2.0
• AngularJS-OAuth2
• angular-tree-control
• assets oas
• pdf-make
• ngstorage
66 10 Generador de aplicaciones de angular generator-oas
• kjur-jsrsasign
• angular-websocket
• angular-input-masks
• angular-moment
• angular-translate
• sweetalert2
10.5.2. Subgenerador de componentes de generator-oas
Cada subgenerador es llamado como oas + el nombre del subgenerador, todos estos subgene-
radores provienen del generador de angular, sin embargo, se realizaron algunas modificaciones
para que construyera interfaces y archivos acordes a los estilos y estandares definidos por la
oficina asesora de sistemas.
• oas:controller
• oas:directive
• oas:filter
• oas:route
• oas:service
• oas:provider
• oas:factory
• oas:value
• oas:constant
• oas:decorator
• oas:view
11 Gestor Documental Nuxeo
Dada la necesidad de centralizar los diferentes documentos, formatos, resoluciones, y otros
documentos de uso constante y tras la revision de varios gestores documentales, la oficina
asesora de sistemas propuso Nuxeo como gestor documental.
Durante el proceso se evaluaron gestores como OPENKM, pero al realizar la integracion
con POLUX se tuvieron inconvenientes a la hora de manipular el documento desde otra
aplicacion.
Nuxeo tiene componentes utiles y de gran provecho como rest-api, autenticacion con oauth1,
oaut2, oidc. Tambien tiene soporte para javascript lo que favorece el alojar documentos
desde el cliente, sin tener que pasar por un agente intermedio en algun lenguaje del lado del
servidor.
68 11 Gestor Documental Nuxeo
Figura 11-1: Esquema rest-api Nuxeo
Tomado de [10]
11.1 Instalacion 69
11.1. Instalacion
Podemos Instalar una version de prueba por 30 dıas.
1 ## Instalacion con Docker
2 $ docker run -ti --name mynuxeo -p 8080:8080 nuxeo/nuxeo:discover-ft
3
4 ## En Centos7
5 ## Descargamos de https://www.nuxeo.com/downloads/ la opcion multiplataforma
6 $ tar -xzvf nuxeo-server-9.2-tomcat.zip
7 $ cd nuxeo-server-9.2-tomcat
8 $ ./Start\ Nuxeo.command
Aparecera una ventana donde podemos correr el servicio de nuxeo y posteriormente podremos
abrir nuxeo en http://127.0.0.1:8080/nuxeo, al entrar por primera vez nos mostrara una
interfaz de configuracion inicial de nuxeo.
Una vez configurado procedemos a parar el servicio de nuxeo y realizaremos unos pasos
posteriores a la instalacion.
1 ## Configuracion de CORS
2 $ nano nuxeo-server-9.2-tomcat/nxserver/config/cors-config.xml
3 ## Escribiremos lo siguiente
4 <component name="org.nuxeo.cors">
5 <extension
6 target="org.nuxeo.ecm.platform.web.common.requestcontroller.service.RequestControllerService"
7 point="corsConfig">
8 <corsConfig name="test-config" supportedMethods="GET,POST,PUT,DELETE,HEAD,OPTIONS"
9 exposedHeaders="accept-ranges, content-disposition, content-length, content-range, etag">
10 <pattern>/nuxeo/.*</pattern>
11 </corsConfig>
12 </extension>
13 </component>
14
15 ## ctrl + o para guardar y ctrl + x para salir
16 ## volvemos a correr el servicio de nuxeo
Con estas Configuraciones los servicios de nuxeo estaran disponibles.
70 11 Gestor Documental Nuxeo
11.2. Conexion con angularJS
Nuxeo provee una libreria para angular llamada nuxeo la cual brinda facilidad para el con-
sumo de las apis.
Para el proyecto POLUX se construyo una factorıa que retorna un objeto nuxeo, el cual
podemos usar para los diferentes procesos de subir archivos.
Figura 11-2: Directiva de solicitud propuesta. Autorıa propia
Esta directiva construye el flujo de trabajo de construir un espacio o documento tipo File
en Nuxeo y posterior a ello sube el archivo. Los cambios se ven reflejados automaticamente
desde la plataforma.
Figura 11-3: Workspace de Nuxeo. Tomado de Nuxeo App
11.2 Conexion con angularJS 71
Figura 11-4: Vista previa documento subido .Tomado de Nuxeo App
12 ANALISIS DE RESULTADOS Y
TRABAJOS FUTUROS
A partir de este proyecto se pueden generar diferentes epicas, historias y tareas, que pueden
derivarse del sistema presentado en este documento.
Esto con el fin de que se puedan agregar funcionalidades y mejorar aspectos de los que se
presentaron en la aplicacion. De esta manera se proponen las siguientes alternativas para
continuar con el proyecto:
• Definicion de roles:
Dentro del proyecto, es necesario para los procesos contemplados establecer roles con
el fin de tener un control de los privilegios de los grupos de usuarios y gestionar con
mayor facilidad lo que puedan realizar dentro de su funcion en el modelo de negocio.
• Autenticacion unica:
Para la autenticacion se propone utilizar WSO2 Identity Server, que permite la auten-
ticacion de cada usuario en base a varios atributos relacionados con su identidad. Del
mismo modo, es importante tener en cuenta la restriccion de vistas dependiendo del
rol obtenido, asociado a dicha identidad.
• API de Notificaciones:
Como medida para controlar novedades en el proyecto, es necesario adaptar una fun-
cionalidad para que consuma el servicio de la API central de notificaciones. Asimismo
considerar anadir un componente de notificaciones para alertar los estados de los pro-
cesos.
• Edicion de formatos de evaluacion:
Del modulo que permite generar formatos de evaluacion dependiendo de la necesidad
del Usuario (por ejemplo el revisor), requiere de una opcion o un modulo adicional
para ser editado luego de ser construido.
• Manejo de procesos flexibles al Calendario academico:
Esto con el fin construir un modulo comun para la oficina compuesto de una estructura
73
que permita establecer un proceso asociado a un acuerdo y asignar diferentes fechas
de caducidad de los estados dicho proceso.
• Replicar procesos a las diferentes modalidades:
Con el fin de cubrir todas las modalidades asociadas al ultimo acuerdo que rige para
el trabajo de grado, es necesario reutilizar los modulos y diferenciar dentro de cada
proceso de negocio que funcionalidades y servicios harıan falta para hacer cumplir estos
procesos.
• Manejo de solicitudes:
Es requerido dentro del modelo de negocio, adaptar el modelo de datos y la aplicacion
para la gestion de solicitudes, con el fin de tener un control de las mismas.
13 CONCLUSIONES
A lo largo del proceso de desarrollo en cuenta se presentaron varias incidencias que nos
llevaron a definir un conjunto de argumentaciones presentadas a continuacion:
• Se obtuvo un manejo efectivo de los procesos de gestion documental como el del
registro de documentos, trayendo consigo servicios que nos ayuda a ejecutar estos
procesos de envio de documentos.
• En vista de la necesidad de recurrir diferentes servicios externos para la interaccion
de la aplicacion, nos permite dar una cierta flexibilidad en la informacion que se trae de
distintos sistemas, ya lo importante serıa organizarla de tal manera que los requisitos
planteados inicialmente se vean reflejados en ella.
• El manejo de reglas y hechos en la aplicacion fue importante, debido a que con ello
el modelo se puede flexibilizar a diferentes acuerdos que se modifiquen a futuro, sin
que esto requiera modificaciones al codigo fuente de la aplicacion, si no que se pueda
tratar directamente a las reglas construidas en el componente de reglas general de la
oficina.
• Como aporte principal para cualquier proyecto a futuro, se cuenta con la posibilidad
de generar un estandar de estilos y scaffolding para cualquier proyecto que se vaya a
trabajar dentro de la Oficina Asesora de sistemas o una entidad cualquiera en general
que requiera la integracion de varios sistemas de informacion.
Bibliografıa
[1] AWS, Amazon. Que es la integracion continua. 2017
[2] de Caldas, Universidad Distrital Francisco J. Acuerdo 038 del 2015
[3] Celi Valero, Avendano Martınez M.: Analisis, Diseno y Desarrollo de un Modulo para
el Sistema de Gestion Academica de la Universidad Distrital, que Apoye los Procesos
Relacionados con la Gestion de Proyectos de Grado, Tomando como Base el Modulo del
Sistema UDLearn. Universidad Distrital Francisco Jose de Caldas, 2016
[4] J.C, Vargas J.: Analisis Diseno e Implementacion de un Prototipo Web para la gestion
de trabajos de grado bajo las modalidades de monografıa y pasantıa en la facultad de
ingenierıa de la Universidad Distrital. Universidad Distrital Francisco Jose de Caldas,
2005
[5] Patni, Sanjay: Pro RESTful APIs: Design, Build and Integrate with REST, JSON,
XML and JAX-RS. Reading, Massachusetts : Apress, 2017
[6] Salcedo Salgado, G. A.: Analisis de Requerimientos y Diseno de la Base de Datos
para el Sistema de Gestion de Proyectos de Grado “Polux” de la Universidad Distrital
Francisco Jose de Caldas. Universidad Distrital Francisco Jose de Caldas, 2016
[7] SCRUMstudy: A Guide to the SCRUM BODY OF KNOWLEDGE (SBOKTM GUI-
DE). SCRUMstudy, 2016. – ISBN 978–0–9899252–0–4
[8] de Sistemas, Oficina A.: Proceso de Desarrollo SCRUM/OAS. 2016
[9] Software, SmartBear. The Beginner’s Guide to Using and Testing RESTful APIs.
2016
[10] Team, The N. Quick Access to Popular Documentation. 2017
[11] Team, The Y. The web’s scaffolding tool for modern webapps. 2017
[12] Y.V, Nieto: UDLearn. Universidad Distrital Francisco Jose de Caldas, 2015
top related