Fabi an S anchez, [email protected] David Morales ...repository.udistrital.edu.co ›...

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, [email protected]

David Morales, [email protected]

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


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.


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-


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


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):-


tipo carrera(X, T), T == tecnologia.


modalidad de materias de profun-

dizacion

validacion creacion(X):-


tipo carrera(X, T), T == artes.


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


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


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


Parametros Valores

Estado Activo

Porcentaje cursado >= 80 %

Tipo de Carrera Tecnologıa

Tabla 9-5: Requisitos para solicitar la inscripcion en carreras Tecnologicas


Dependiendo de como varıen los parametros y tambien el estado de la solicitud en el tiempo.

Pueden existir ciertos escenarios:


• El estudiante no cumple con los requisitos para la modalidad

Figura 9-19: Escenario (1) Estudiante no cumple con los requisitos


• Estudiante que cumple los requisitos pero no tiene solicitudes en esa modalidad

Figura 9-20: Escenario (2), Estudiante cumple sin solicitudes


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


• 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


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:


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


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.

[email protected]:

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.

[email protected]:

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.

[email protected]:

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.

[email protected]:

Tuvo una duracion de 12 dıas y se modificaron vistas iniciales, inclusion de autenticacion

unica, pruebas con google y con WSO2.

[email protected]:

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

[email protected]:

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.

[email protected]:

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.

[email protected]:

Tuvo una duracion de 5 dıas y se construyo funcionalidad de grunt-build, componente para

la generacion minimizada de los proyectos.

[email protected]:

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

[email protected]:

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

[email protected]:

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:


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:


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:


• 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.


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


• 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.

http://127.0.0.1:8080/nuxeo

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

Fabi an S anchez, [email protected] David Morales ...repository.udistrital.edu.co ›...

Documents

Transcript of Fabi an S anchez, [email protected] David Morales ...repository.udistrital.edu.co ›...