ANÁLISIS, DISEÑO Y DESARROLLO DE UN MÓDULO PARA EL...

ANÁLISIS, DISEÑO Y DESARROLLO DE UN MÓDULO PARA EL SISTEMA

DE GESTIÓN ACADÉMICA DE LA UNIVERSIDAD DISTRITAL, QUE APOYE

LOS PROCESOS RELACIONADOS CON LA GESTIÓN DE PROYECTOS DE

GRADO, TOMANDO COMO BASE EL MODULO DEL SISTEMA “UDLEARN”

AUTORES:

MARÍA FERNANDA AVENDAÑO MARTÍNEZ

DIEGO FERNANDO CELI VALERO

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTÁ D.C, 2016

ANÁLISIS, DISEÑO Y DESARROLLO DE UN MÓDULO PARA EL SISTEMA

DE GESTIÓN ACADÉMICA DE LA UNIVERSIDAD DISTRITAL, QUE APOYE

LOS PROCESOS RELACIONADOS CON LA GESTIÓN DE PROYECTOS DE

GRADO, TOMANDO COMO BASE EL MODULO DEL SISTEMA “UDLEARN”

AUTORES: MARÍA FERNANDA AVENDAÑO MARTÍNEZ

20102020007 DIEGO FERNANDO CELI VALERO

20101020020

PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE

SISTEMAS

DIRECTOR:

PhD. CARLOS ENRIQUE MONTENEGRO MARÍN

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA

INGENIERÍA DE SISTEMAS

BOGOTÁ D.C, 2016

Universidad Distrital Francisco José de Caldas I

TABLA DE CONTENIDO

CAPÍTULO 1. INTRODUCCIÓN ......................................................................... 1

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA .......................................... 3

CAPÍTULO 3. OBJETIVOS ................................................................................. 5

3.1. OBJETIVO GENERAL .............................................................................. 5

3.2. OBJETIVOS ESPECÍFICOS .................................................................... 5

CAPÍTULO 4. JUSTIFICACIÓN .......................................................................... 7

CAPÍTULO 5. ALCANCES Y LIMITACIONES .................................................... 9

5.1. ALCANCES .............................................................................................. 9

5.2. LIMITACIONES ........................................................................................ 9

CAPÍTULO 6. ANTECEDENTES ...................................................................... 11

6.1 SGPG-UD ................................................................................................ 11

6.2 UDLEARN ............................................................................................... 12

6.3 COMPARACIÓN ENTRE UDLEARN Y SGPG-UD ................................. 13

CAPÍTULO 7. MARCO REFERENCIAL ............................................................ 15

7.1 MARCO TECNOLÓGICO ........................................................................ 15

7.1.1. OPEN SOURCE ............................................................................... 15

7.1.2. PHP .................................................................................................. 15

7.1.3. POSTGRESQL ................................................................................. 15

7.1.4. FRAMEWORK SARA ....................................................................... 16

7.2 MARCO TEÓRICO .................................................................................. 16

7.2.1 MODALIDADES DEL TRABAJO DE GRADO. .................................. 16

7.2.2 SISTEMA DE GESTIÓN ACADÉMICA, UNIVERSIDAD DISTRITAL.

................................................................................................................... 17

CAPÍTULO 8. METODOLOGÍA ........................................................................ 19

8.1 MARCO METODOLÓGICO ..................................................................... 19

8.1.1. EL PROCESO OPENUP/OAS ......................................................... 19

8.1.1.1. GENERALIDADES ..................................................................... 19

8.1.1.2. EL MÉTODO DE TRABAJO ....................................................... 22

8.1.1.2.1. FASES DEL PROCESO OPENUP/OAS .............................. 22

Universidad Distrital Francisco José de Caldas II

8.1.1.2.2. SUBPROCESOS OPENUP/OAS ......................................... 25

8.1.1.2.3. ROLES OPENUP/OAS ........................................................ 28

8.1.1.2.4. ARTEFACTOS DEL PROCESO OPENUP/OAS ................. 29

8.1.1.3. PROCESO DE DESARROLLO .................................................. 31

8.1.1.3.1. FICHA DE CARACTERIZACIÓN DE SUBPROCESO ......... 31

8.1.1.3.2. GUÍAS .................................................................................. 33

8.1.1.3.2.1. INTEGRACIÓN CONTINUA .......................................... 33

8.1.1.3.2.2. RECONSTRUCCIÓN (REFACTORING) ....................... 34

8.1.1.3.2.3. TRANSFORMAR EL DISEÑO EN PUESTA EN

FUNCIONAMIENTO ......................................................................... 35

8.1.1.3.2.4. ELEVAR LOS CAMBIOS AL SIGUIENTE NIVEL DE

OPERACIÓN .................................................................................... 35

8.1.1.3.2.5. REUTILIZACIÓN DE SOFTWARE ................................ 36

8.1.1.3.2.6. ESTÁNDARES PARA LA ESCRITURA DE CÓDIGO ... 36

8.1.1.3.2.7. PUESTA EN FUNCIONAMIENTO ................................. 37

8.2. APLICACIÓN DEL FRAMEWORK SARA ............................................... 38

CAPÍTULO 9. DESARROLLO DE INGENIERIA ............................................... 39

9.1. FASE UNO: MIGRACIÓN MODALIDAD DE MONOGRAFÍA ................. 39

9.1.1. Fase de Inicio ................................................................................... 39

9.1.1.1. Etapa 1: Identificación y descripción de la necesidad ................ 39

9.1.1.2. Etapa 2: Análisis del acuerdo 038 de 2015 para generar la

especificación de requerimientos ............................................................ 41

9.1.2. Fase de elaboración ......................................................................... 41

9.1.2.1. Etapa 1: Modelado BPMN .......................................................... 42

9.1.2.2. Etapa 2: Migración de la Base de Datos .................................... 42

9.1.3. Fase de construcción ....................................................................... 42

9.1.4. Plan General del proyecto ................................................................ 43

9.1.4.1. Plan de Iteración ........................................................................ 43

9.1.4.2. Cierre de iteración ...................................................................... 50

9.1.4.3. Bloc de Notas de la Arquitectura ................................................ 51

9.1.4.4. Código Fuente ............................................................................ 51

9.1.4.5. Control de Cambios ................................................................... 51

9.1.5. ARQUITECTURA DE DATOS .......................................................... 53

Universidad Distrital Francisco José de Caldas III

9.1.5.1. PUBLIC ...................................................................................... 55

9.1.5.2. GENERAL .................................................................................. 56

9.1.5.3. ANTEPROYECTO ..................................................................... 57

9.1.5.4. PROYECTO ............................................................................... 58

9.1.5.5. INFORME FINAL ....................................................................... 59

9.2. FASE DOS: ANÁLISIS Y DISEÑO DE LAS DEMÁS MODALIDADES ... 60

9.2.1. Listado maestro de requerimientos .................................................. 60

9.2.2. Requerimientos no funcionales ........................................................ 63

9.2.3. Glosario ............................................................................................ 63

9.2.4. Plan general del proyecto ................................................................. 66

9.2.4.1. Plan de iteraciones para el análisis ............................................ 66

9.2.4.2. Cierre de iteración ...................................................................... 69

9.2.5. Módulos propuestos ......................................................................... 69

9.2.5.1. Actores ....................................................................................... 70

9.2.5.2. Módulo para Espacios Académicos de Posgrado ...................... 70

9.2.5.3. Módulo para Espacios académicos de Profundización .............. 73

9.2.5.4. Módulo para Producción Académica .......................................... 75

9.2.5.5. Módulo para Innovación-Investigación ....................................... 79

CAPÍTULO 10. RESULTADOS Y DISCUSIÓN................................................. 91

CAPÍTULO 11. TRABAJOS FUTUROS ............................................................ 95

CAPÍTULO 12. CONCLUSIONES .................................................................... 96

CAPÍTULO 13. BIBLIOGRAFÍA ........................................................................ 99

ANEXOS ......................................................................................................... 101

ANEXO A. Diagramas de actividades ...................................................... 101

ANEXO B. Diagramas de secuencia ........................................................ 101

ANEXO C. Bloc de notas de la arquitectura ............................................. 101

ANEXO D. Diccionario de datos ............................................................... 101

ANEXO E. Manual de usuario .................................................................. 101

ANEXO F. Framework SARA ................................................................... 101

Universidad Distrital Francisco José de Caldas IV

Universidad Distrital Francisco José de Caldas V

ÍNDICE DE FIGURAS

FIGURA 1. INICIAR PROPUESTA EN SGPG-UD ....................................................... 11

FIGURA 2. PÁGINA DE INICIO UDLEARN. ................................................................ 12

FIGURA 3. TEMÁTICAS DE INTERÉS POR PROGRAMA CURRICULAR ............................ 13

FIGURA 4. MÉTODO DE TRABAJO........................................................................... 22

FIGURA 5. PROCESO DE DESARROLLO OPENUP/OAS. ........................................... 26

FIGURA 6. ESTRUCTURA DEL EQUIPO DE DESARROLLO OPENUP/OAS. ................... 28

FIGURA 7. SUBPROCESO DE DESARROLLO OPENUP/OAS ...................................... 32

FIGURA 8. MODELO RELACIONAL DE AUTENTICACIÓN EN UDLEARN. ........................ 55

FIGURA 9. MODELO RELACIONAL DE LA GESTIÓN DE USUARIOS EN PÓLUX. ............... 55

FIGURA 10. ESQUEMA PUBLIC DE LA BASE DE DATOS DEL SISTEMA DE GESTIÓN

ACADÉMICA PÓLUX. ...................................................................................... 56

FIGURA 11. TABLAS GENERALES DE LA BASE DE DATOS DEL SISTEMA DE GESTIÓN

ACADÉMICA PÓLUX. ...................................................................................... 57

FIGURA 12. TABLAS PARA ANTEPROYECTO DE LA BASE DE DATOS DEL SISTEMA DE

GESTIÓN ACADÉMICA PÓLUX. ........................................................................ 58

FIGURA 13. TABLAS PARA PROYECTO DE LA BASE DE DATOS DEL SISTEMA DE GESTIÓN

ACADÉMICA PÓLUX ....................................................................................... 59

FIGURA 14. TABLAS PARA INFORME FINAL DE LA BASE DE DATOS DEL SISTEMA DE

GESTIÓN ACADÉMICA PÓLUX ......................................................................... 60

FIGURA 15. PASOS PARA ELABORACIÓN DEL LISTADO MAESTRO DE REQUERIMIENTOS.

................................................................................................................... 60

FIGURA 16. MODALIDADES SELECCIONADAS. ......................................................... 69

FIGURA 17. ACTORES QUE PARTICIPAN EN LAS MODALIDADES. ................................ 70

FIGURA 18. PRIMERA PARTE DEL MODELO BPMN DE ESPACIOS ACADÉMICOS DE

POSGRADO. ................................................................................................. 71

FIGURA 19. SEGUNDA PARTE DEL MODELO BPMN DE ESPACIOS ACADÉMICOS DE

POSGRADO. ................................................................................................. 72

FIGURA 20. CASOS DE USO MODALIDAD ESPACIOS ACADÉMICOS DE POSGRADO. .... 73

FIGURA 21. PRIMERA PARTE DEL MODELO BPMN DE ESPACIOS ACADÉMICOS DE

PROFUNDIZACIÓN. ........................................................................................ 74

FIGURA 22. SEGUNDA PARTE DEL MODELO BPMN DE ESPACIOS ACADÉMICOS DE

PROFUNDIZACIÓN. ........................................................................................ 74

FIGURA 23. CASOS DE USO MODALIDAD ESPACIOS ACADÉMICOS DE PROFUNDIZACIÓN.

................................................................................................................... 75

FIGURA 24. PRIMERA PARTE DEL MODELO BPMN DE PRODUCCIÓN ACADÉMICA. ...... 76

FIGURA 25. SEGUNDA PARTE DEL MODELO BPMN PARA LA MODALIDAD DE

PRODUCCIÓN ACADÉMICA. ............................................................................ 77

FIGURA 26. CASOS DE USO PARA ADMINISTRAR REVISTAS PARA EL MÓDULO DE

PRODUCCIÓN ACADÉMICA. ............................................................................ 78

Universidad Distrital Francisco José de Caldas VI

FIGURA 27. CASOS DE USO PARA EL SUB-MÓDULO DE REGISTRO Y CONSULTA DE

PROPUESTA DE PUBLICACIÓN. ........................................................................ 79

FIGURA 28. PRIMERA PARTE DEL MODELO BPMN DE INNOVACIÓN-INVESTIGACIÓN. .. 80

FIGURA 29. SEGUNDA PARTE DEL MODELO BPMN DE INNOVACIÓN-INVESTIGACIÓN. . 80

FIGURA 30. TERCERA PARTE DEL MODELO BPMN DE INNOVACIÓN-INVESTIGACIÓN. . 81

FIGURA 31. PARTE FINAL DEL MODELO BPMN PARA LA MODALIDAD DE INNOVACIÓN-

INVESTIGACIÓN. ............................................................................................ 81

FIGURA 32. CASOS DE USO GENERALES PARA LA MODALIDAD DE INNOVACIÓN-

INVESTIGACIÓN. ............................................................................................ 82

FIGURA 33. CASOS DE USO PARA EL SUB-MÓDULO DE REGISTRO Y CONSULTA DEL

PLAN DE ACTIVIDADES PARA LA FASE DE ANTEPROYECTO. ................................. 83

FIGURA 34. CASOS DE USO PARA EL SUB-MÓDULO DE ASIGNACIÓN DE REVISORES

PARA EL PLAN DE ACTIVIDADES EN LA FASE DE ANTEPROYECTO. ........................ 84

FIGURA 35. CASOS DE USO PARA EL SUB-MÓDULO DE EVALUACIÓN DEL PLAN DE

ACTIVIDADES PARA LA FASE DE ANTEPROYECTO. .............................................. 85

FIGURA 36. CASOS DE USO PARA EL SUB-MÓDULO DE INICIO Y CONSULTA DEL PLAN DE

ACTIVIDADES PARA LA FASE DE PROYECTO. ..................................................... 86

FIGURA 37. CASOS DE USO PARA EL SUB-MÓDULO DE EVALUACIÓN DEL PLAN DE

ACTIVIDADES PARA LA FASE DE PROYECTO. ..................................................... 87

FIGURA 38. CASOS DE USO PARA EL SUB-MÓDULO DE INICIO Y CONSULTA DEL INFORME

DE ACTIVIDADES, FASE FINAL DEL PROYECTO. .................................................. 88

FIGURA 39. CASOS DE USO PARA EL SUB-MÓDULO DE ASIGNACIÓN DE JURADOS AL

INFORME DE ACTIVIDADES, FASE FINAL DEL PROYECTO. .................................... 89

FIGURA 40. CASOS DE USO PARA EL SUB-MÓDULO DE EVALUACIÓN DEL INFORME DE

ACTIVIDADES, FASE FINAL DEL PROYECTO. ...................................................... 90

Universidad Distrital Francisco José de Caldas VII

ÍNDICE DE TABLAS

TABLA 1. PLANTEAMIENTO DEL PROBLEMA. ............................................................. 4

TABLA 2.COMPARACIÓN ENTRE SGPG-UD Y UDLEARN ........................................ 14

TABLA 3. FASES DEL PROCESO OPENUP/OAS. ..................................................... 23

TABLA 4. FASE DE ELABORACIÓN PROCESO OPENUP/OAS. ................................... 25

TABLA 5. SUBPROCESOS DE DESARROLLO OPENUP/OAS. ..................................... 27

TABLA 6. ROLES EN EL PROCESO OPENUP/OAS. .................................................. 29

TABLA 7. ARTEFACTOS DEL PROCESO OPENUP/OAS. ........................................... 31

TABLA 8. FICHA DESARROLLO DE SOLUCIÓN PROCESO OPENUP/OAS. .................... 32

TABLA 9. ROLES Y SUBPROCESOS PRESENTES EN EL PROYECTO. ........................... 38

TABLA 10. ENLACES REPETIDOS ROL DE COORDINADOR ......................................... 40

TABLA 11. ENLACES REPETIDOS ROL DE ESTUDIANTE ............................................ 40

TABLA 12. ENLACES REPETIDOS ROL DE DOCENTE................................................. 41

TABLA 13. ENLACES REPETIDOS ROL DE ADMINISTRADOR ....................................... 41

TABLA 14. CRONOGRAMA DE DESARROLLO PARA LA PRIMERA ITERACIÓN. ................ 44

TABLA 15. CRONOGRAMA DE DESARROLLO PARA LA SEGUNDA ITERACIÓN. ............... 45

TABLA 16. CRONOGRAMA DE DESARROLLO PARA LA TERCERA ITERACIÓN. ............... 45

TABLA 17. CRONOGRAMA DE DESARROLLO PARA LA CUARTA ITERACIÓN. ................. 46

TABLA 18. CRONOGRAMA DE DESARROLLO PARA LA QUINTA ITERACIÓN. .................. 47

TABLA 19. CRONOGRAMA DE DESARROLLO PARA LA SEXTA ITERACIÓN. .................... 47

TABLA 20. CRONOGRAMA DE DESARROLLO PARA LA SÉPTIMA ITERACIÓN. ................ 48

TABLA 21. CRONOGRAMA DE DESARROLLO PARA LA OCTAVA ITERACIÓN. ................. 49

TABLA 22. CRONOGRAMA DE DESARROLLO PARA LA NOVENA ITERACIÓN. ................. 50

TABLA 23. CRONOGRAMA DE DESARROLLO PARA LA DÉCIMA ITERACIÓN. .................. 50

TABLA 24. TABLAS ELIMINADAS DEL MODELO DE DATOS DE UDLEARN...................... 54

TABLA 25. LISTADO REQUERIMIENTOS FUNCIONALES .............................................. 63

TABLA 26. LISTADO REQUERIMIENTOS NO FUNCIONALES ......................................... 63

TABLA 27. GLOSARIO .......................................................................................... 66

TABLA 28. CRONOGRAMA DE ANÁLISIS, PRIMERA ITERACIÓN. .................................. 67

TABLA 29. CRONOGRAMA DE ANÁLISIS, SEGUNDA ITERACIÓN. ................................. 67

TABLA 30. CRONOGRAMA DE ANÁLISIS, TERCERA ITERACIÓN. .................................. 68

TABLA 31. CRONOGRAMA DE ANÁLISIS, CUARTA ITERACIÓN. .................................... 68

TABLA 32. RESULTADOS ...................................................................................... 93

Universidad Distrital Francisco José de Caldas VIII

Universidad Distrital Francisco José de Caldas 1

CAPÍTULO 1. INTRODUCCIÓN

Actualmente las universidades juegan un papel fundamental en la

transformación de las sociedades, por eso a través de los diferentes trabajos o

proyectos de grado que realizan sus estudiantes para optar por un título

profesional, se busca impactar y contribuir al desarrollo sociocultural de la

sociedad.

El trabajo de grado se ha implementado como una estrategia que contribuye en

la formación integral del estudiante en su preparación para el desempeño

profesional, ampliando las posibilidades de investigación, creación, desarrollo

tecnológico, innovación y proyección social (Universidad Distrital Francisco

José de Caldas, 2015). Es un proceso formativo que hace parte del plan de

estudios desarrollado por el estudiante y conduce a la obtención de un

resultado final que ha de presentar, para optar por un título universitario.

Para tal fin, la Universidad Distrital Francisco José de Caldas, ha orientado sus

esfuerzos en crear diversas alternativas de trabajo de grado, las cuales han

sido establecidas por el Consejo Académico y cuentan con un proceso

debidamente reglamentado en el estatuto estudiantil.

En la actualidad, la Universidad no cuenta con una herramienta que le permita

realizar de forma sistematizada la gestión de la información correspondiente a

las diferentes modalidades de grado ofrecidas, lo cual ha dado lugar a la

generación de posibles soluciones por parte de sus estudiantes, ofreciendo

prototipos de software que podrían solventar este problema.

Entre las propuestas que se han realizado, se encuentra la de Juan Camilo

Vargas, quien implementó como resultado de su tesis de pregrado el sistema

(SGPG-UD), un prototipo para la gestión de los trabajos de grado de la

Universidad Distrital, para las modalidades de monografía y pasantía (Vargas

Jerez, 2013). Este proyecto fue retomado por Yuri Vanessa Nieto, quien creó

una nueva versión del sistema llamado "UDLearn", el cual fue implementado

como resultado de una tesis de maestría, siendo una propuesta para dar

soporte en la toma de decisiones institucionales al interior de la facultad de

Ingeniería de la Universidad FJC (Acevedo Nieto, 2015). A raíz de esto, la

Oficina Asesora de Sistemas (OAS) busca crear un sistema soportado en

tecnologías libres siguiendo el proceso de desarrollo OPENUP/OAS, que acoja

el componente de software encargado de la gestión de trabajos de grado en la


modalidad de monografía de la aplicación mencionada y se integre con una

solución de software que permita la gestión de las modalidades de grado

faltantes. En este proyecto se contemplarán las opciones de grado de:

Espacios Académicos de Posgrado, Investigación-Innovación, Espacios

Académicos de Profundización y Producción Académica.


CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA

A continuación se relaciona una tabla que detalla el ámbito del problema que

afecta el actual anteproyecto.

El problema

Actualmente, en la Universidad Distrital Francisco José

de Caldas, se desarrolló el sistema "UDLearn", como

resultado de una tesis de maestría, el cual permite la

gestión de los proyectos de grado en la modalidad de

Monografía y la realización de algunos análisis de la

información allí almacenada, sin embargo este sistema

no contempla las demás modalidades de trabajo de

grado estipuladas en el Acuerdo 038 (Universidad

Distrital Francisco José de Caldas, 2015). Además,

durante la implementación de UDLearn no se tomó como

referencia la arquitectura de software implementada en

los proyectos de la Oficina Asesora de Sistemas, lo cual

dificulta la integración de esta solución de software al

sistema de gestión académica de la Universidad.

Afecta

- Estudiantes de la Universidad FJC pertenecientes a

cualquiera de las diferentes modalidades de grado reglamentadas.

- Los docentes de planta asignados como directores, revisores o jurados en los distintos procesos pertenecientes a los trabajos de grado.

- Personal a cargo de los procesos de las modalidades de grado en cada proyecto curricular.

El impacto del

problema es

- Demoras innecesarias en los procesos relacionados

con las modalidades de grado. - Desinformación sobre el estado de los proyectos de

grado. - No confiabilidad, disponibilidad e integridad de los

datos. - Duplicidad de las actividades, tareas y registro de

información. - Falta de información oportuna para facilitar la gestión y

toma de decisiones en la Universidad.


Una solución

con éxito

debería ser

Una solución de software modular, integral y escalable

que permita apoyar los procesos relacionados con la

gestión de trabajos de grado de la Universidad Distrital,

siguiendo los lineamientos propios del proceso de

desarrollo OPENUP/OAS y acorde a la legislación que

rige la gestión de las diferentes modalidades de trabajo

de grado. Además esta solución debe de ser compatible

con la arquitectura manejada por la Oficina Asesora de

Sistemas, lo cual facilitará el acoplamiento del módulo al

sistema de gestión académica de la universidad.

Tabla 1. Planteamiento del Problema. Fuente: Autores


CAPÍTULO 3. OBJETIVOS

3.1. OBJETIVO GENERAL

Migrar el módulo de gestión de proyectos de grado en la modalidad de

monografía perteneciente al sistema “UDLearn” y realizar el análisis de las

modalidades de grado de Espacios Académicos de Posgrado, Investigación-

Innovación, Espacios Académicos de Profundización y Producción

Académica, que sirva de base para la creación de un módulo para el sistema

de gestión académica de la Universidad Distrital Francisco José de Caldas,

lo anterior siguiendo los lineamientos propios del proceso de desarrollo

OPENUP/OAS.

3.2. OBJETIVOS ESPECÍFICOS

● Migrar el módulo de gestión de trabajos de grado en la modalidad de

monografía perteneciente a la aplicación UDLearn, de Java a PHP, así

como realizar la migración de la base de datos de Oracle a PostgreSQL

para adaptarlo a la arquitectura manejada por la OAS, haciendo uso del

framework SARA.

● Representar los diferentes procesos y flujos de información para la

modalidad de Espacios Académicos de Posgrado mediante notación de

modelamiento de procesos de negocio BPMN y estándar UML con base

en las normas establecidas en el acuerdo 038 de 2015 (Universidad

Distrital Francisco José de Caldas, 2015).


modalidad de Investigación-Innovación mediante notación de





modalidad de Espacios de Profundización mediante notación de






modalidad de Producción Académica mediante notación de




● Realizar la documentación técnica de la funcionalidad y proceso llevado

a cabo en el desarrollo del software, con base en los requerimientos y en

la arquitectura planteadas en el proceso de desarrollo en curso, para

orientar a posteriores desarrolladores en el complemento del sistema.


CAPÍTULO 4. JUSTIFICACIÓN

Los archivos universitarios son una pieza esencial para la gestión académica y

administrativa, los cuales facilitan la toma de decisiones basadas en

antecedentes y son primordiales para dar respuestas oportunas a las consultas

y solicitudes de la comunidad universitaria (Triana Torres, 2008); es por esto

que surge la necesidad de contar con herramientas que permitan gestionar y

acceder de forma sistematizada a los archivos generados por los diferentes

procesos académicos y administrativos dentro de las instituciones de

educación superior.

La Universidad Distrital Francisco José de Caldas, ha implementado varios

sistemas de información mediante herramientas de software libre, con el fin de

garantizar el fácil acceso y gestión de la información a la comunidad

académica; sin embargo, en la actualidad, no cuenta con un sistema que

permita la gestión de los procesos y procedimientos propios pertenecientes a

las distintas modalidades de grado, es por ello que se hace necesario

complementar el sistema de información académica existente en la

universidad, con un módulo que apoye el proceso de gestión de trabajos de

grado en la institución y una fácil administración, accesible para la comunidad

académica; dicho módulo debe ser integral, unificado y escalable, con el fin de

permitir adaptarlo a la normatividad emitida por la universidad.

Para lograrlo, es necesario realizar el análisis, diseño y desarrollo de una

solución de software que consolide la información y los archivos generados por

cada una de las diferentes modalidades de grado en una sola herramienta web,

la cual tenga interoperabilidad con los diferentes componentes de software

existentes, que sea adaptable a los cambios normativos y legales, al mismo

tiempo que cumpla requisitos de alta calidad en capacidades de usabilidad,

fiabilidad, rendimiento y mantenimiento del software.

Dicho análisis y diseño ya se ha planteado en varias ocasiones por algunos

estudiantes de la universidad (Vargas Jerez, 2013) (Acevedo Nieto, 2015), sin

embargo, estas herramientas no han sido implementadas al interior de la

universidad, debido a que no contemplan la normatividad actual establecida en

el estatuto estudiantil (Universidad Distrital Francisco José de Caldas, 2015) y

además, arquitecturalmente no se acoplan a la metodología de desarrollo

manejada al interior de la institución, por la Oficina Asesora de Sistemas. Sin

embargo, el análisis y diseño ya planteados, pueden ser tomados como base

para la creación de una herramienta que funcione como un módulo del sistema

ya manejado e implementado en la universidad.


Tomando en cuenta lo anterior, se plantea realizar la migración del módulo de

gestión de trabajos de grado para la Universidad Distrital, tomando como base

la aplicación UDLearn (referenciada a lo largo del presente documento), lo cual

permitirá reducir el tiempo de desarrollo, de igual manera ayudará a

estandarizar el modelado para las modalidades de grado no contempladas para

dicho trabajo y poder así en un futuro agregar esas otras modalidades al

sistema.


CAPÍTULO 5. ALCANCES Y LIMITACIONES

5.1. ALCANCES

El desarrollo del módulo para la gestión de proyectos de grado tiene los

siguientes alcances:

De la aplicación "UDLearn" sólo se realizará la migración de uno de los

tres módulos, el principal, llamado Módulo de Gestión de Trabajos de

grado, usando lenguaje PHP e implementando el framework SARA.

Se realizará la migración de la base de datos de Oracle a PostgreSQL

con el fin de realizar las pruebas correspondientes.

El sistema se desarrollará para los programas de pregrado de la

Universidad Distrital Francisco José de Caldas, sin embargo, las

pruebas y demás validaciones del sistema se harán con algunos

programas de la Facultad de Ingeniería.

Una vez se haya realizado la migración del módulo, se realizará el

análisis y diseño para una posterior implementación de las modalidades

de grado de Espacios Académicos de Posgrado, Investigación-

Innovación, Espacios Académicos de Profundización y Producción

Académica con base al acuerdo 038 (Universidad Distrital Francisco

José de Caldas, 2015).

Los diagramas a modelar con el estándar UML para las demás

modalidades de grado serán: diagrama casos de uso, diagrama de

actividades y diagrama de secuencia.

5.2. LIMITACIONES

El desarrollo del Módulo de Gestión de proyectos de grado basado en el

sistema "UDLearn", para ayuda en la toma de decisiones sobre las

modalidades de grado al interior de la Universidad Distrital Francisco José de

Caldas presenta algunas limitaciones que se mencionan a continuación:

● Para el manejo e implementación del framework es necesaria una previa

capacitación, ya que sin esto, el módulo no se podría acoplar al sistema

de gestión académica existente.

● El proyecto únicamente se implementará para las modalidades de grado

que existen actualmente en los programas de pregrado.


● Para el desarrollo del sistema, en lo posible, se utilizarán herramientas

de software libre o gratuitas, prevaleciendo la contribución que éstas

ofrecen para el desarrollo del proyecto.


CAPÍTULO 6. ANTECEDENTES

6.1 SGPG-UD

El Sistema de Gestión 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 Análisis, diseño e

implementación de un prototipo web para la gestión de trabajos de grado bajo

las modalidades de monografía y pasantía en la facultad de ingeniería de la

Universidad Distrital (Vargas Jerez, 2013). Este sistema, contempla la gestión

de los trabajos de grado pertenecientes a las modalidades de monografía y

pasantía, dividiendo el proceso en las etapas de pre propuesta, propuesta,

anteproyecto, proyecto e informe final.

Figura 1. Iniciar propuesta en SGPG-UD

Tomado de (Vargas Jerez, 2013)

Dentro de la estructura general del prototipo SGPG-UD, se encuentra el

sistema core, el cual está basado en XML/XSL y ha sido diseñado para

transformar los documentos XML, generados por cada página del aplicativo, en

otros formatos de texto, como HTML, XHTML u otro formato XML facilitando la

separación entre lógica de negocio y la presentación de la información (Vargas

Jerez, 2013).


6.2 UDLEARN

En la actualidad, en la Universidad Distrital Francisco José de Caldas, se ha

propuesto un sistema de software basado en las técnicas de Learning Analytics

como herramienta de apoyo en la toma de decisiones académico-

administrativas llamado UDLearn.

Entre las funcionalidades de este sistema se encuentra la gestión de los

diferentes procesos que abarca la realización de los trabajos de grado en la

modalidad de monografía, divididos en tres etapas: Anteproyecto, Proyecto e

Informe final.

En la figura 2, se puede observar la página de inicio de la aplicación UDLearn,

la cual se compone por un menú, que varía según el rol del usuario, un panel

de actividades pendientes y un panel que resume las actividades realizadas.

Figura 2. Página de inicio UDLearn. Tomado de (Acevedo Nieto, 2015)

En la pestaña General, se encuentra la opción de regresar a la página de

bienvenida, la pestaña de Trabajos de Grado, contiene todas las opciones

referentes al proceso de realización de un trabajo de grado en cada una de sus

etapas: Anteproyecto, Proyecto e Informe final. Estas opciones varían de

acuerdo al rol que posea el usuario, los cuáles pueden ser los siguientes:

“Coordinador de proyecto curricular”, “Delegado de coordinador de proyecto

curricular”, “Director de trabajo de grado”, “Estudiante”, “Revisor de


anteproyecto” y “Jurado de informe final”. Adicionalmente esta opción contiene

las posibles consultas y reportes que se pueden realizar de dicho proceso. Por

otra parte, la pestaña de Rendimiento académico, contiene las opciones para

generar los reportes y consultas referentes al rendimiento académico. Dichas

opciones varían de acuerdo al rol del usuario. Finalmente en la opción de

Prácticas Académicas, se pueden generar los reportes y consultas referentes a

las prácticas académicas.

Figura 3. Temáticas de interés por programa curricular Tomado de (“UDLearn,” 2015)

6.3 COMPARACIÓN ENTRE UDLEARN Y SGPG-UD

UDLearn, es una evolución del prototipo realizado por Juan Camilo Vargas

Jerez, denominado Sistema de Gestión de Proyectos de Grado de la

Universidad Distrital (SGPG-UD) (Vargas Jerez, 2013), el cual contempla la

gestión de los trabajos de grado pertenecientes a las modalidades de

monografía y pasantía.

Como se puede evidenciar en la Tabla 2, el sistema SGPG-UD contempla el

proceso de gestión de trabajos de grado en la modalidad de monografía

mediante dos procesos adicionales en comparación con los presentes en

UDLearn, la pre-propuesta y la propuesta. Por otra parte, el sistema UDLearn

cuenta con una funcionalidad adicional, la generación de estadísticas sobre los

trabajos de grado asignados por docente y por las temáticas de interés

registradas.


Característica

Sistema de Gestión de

Proyectos de Grado de

la Universidad Distrital

(SGPG-UD)

Sistema de Apoyo en la Toma

de Decisiones

UDLearn

Módulos Pre-propuesta

Propuesta

Anteproyecto

Proyecto

Informes finales

Autenticación de

usuarios

Gestión de trabajos de grado

(Anteproyectos, Proyectos,

Informes Finales, Consultas

de Trabajos de Grado)

Rendimiento académico

Prácticas académicas

Acuerdo 001 de 2010 031 de 2014

Estadísticas e

informes

sobre los

trabajos de

grado

No realiza Trabajos de grado por

temática de interés

Trabajos por docente

Trabajos de grado por

temática de interés y docente

Temáticas de interés por

programa curricular

Docentes por temática de

interés

Nivel de aceptación por

temática de interés

Nivel de participación de

docentes en trabajos de grado

Cobertura de docentes por

temáticas de interés

Técnicas para

el análisis de

datos

Ninguna Learning Analytics

Minería de datos

Tabla 2.Comparación entre SGPG-UD y UDLearn Fuente: Autores.


CAPÍTULO 7. MARCO REFERENCIAL

7.1 MARCO TECNOLÓGICO

7.1.1. OPEN SOURCE

Open Source o código abierto, es la expresión con la que se conoce al software

distribuido y desarrollado libremente. Su premisa es que al compartir el código,

el programa resultante tiende a ser de calidad superior al software propietario,

es una visión técnica. Obviamente para lograr calidad técnica lo ideal es

compartir el código, pero no se está obligado a hacerlo (Andrearrs, 2014).

7.1.2. PHP

PHP es un lenguaje de código abierto interpretado, especialmente adecuado

para el desarrollo web y que puede ser incrustado en HTML (Achour et al.,

2015).Es un lenguaje script que se ejecuta en el lado del servidor Web, de tal

manera que, solamente el resultado de su ejecución es enviado al cliente Web

(navegador)(Capuñay Uceda, 2013). Esto significa que el código fuente escrito

en PHP no aparecerá en el código fuente de la página Web que muestra el

navegador.

Esta tecnología permite realizar páginas web dinámicas cuyo contenido puede

ser completa o parcialmente generado en el momento de la invocación de la

página (Heurtel, 2014), gracias a la información obtenida en un formulario o

extraída de una base de datos.

7.1.3. POSTGRESQL

Como herramienta para la administración de los datos pertenecientes al

proyecto, se usará PostgreSQL. Es un sistema de gestión de bases de datos

objeto-relacional. Es el sistema de gestión de bases de datos de código abierto

más potente del mercado (rafaelma, 2010).

Utiliza la Licencia PostgreSQL, una licencia tipo BSD “permisiva”. Esta licencia

certificada por la OSI es ampliamente apreciada como flexible y amigable para

los negocios, pues no restringe el uso de PostgreSQL para aplicaciones

propietarias y comerciales (PostgreSQL, 2014).


7.1.4. FRAMEWORK SARA

Para el desarrollo del proyecto, se utilizará el framework SARA, un Sistema

para la Articulación Rápida de Aplicaciones (System for Addressing the Rapid

development of Applications), es un marco de trabajo para el desarrollo de

aplicaciones orientadas a la web. Está escrito en lenguaje PHP y propende por

una arquitectura dividida en capas.

Este framework, es una evolución del marco de desarrollo que desde el año

2005 se ha venido trabajando en la Universidad Distrital Francisco José de

Caldas. Desde el año 2008, es dirigido conforme a los lineamientos de la

Oficina Asesora de Sistemas y se distribuye como software libre como muestra

del compromiso institucional con la Política Distrital de Fomento al Software

Libre (Oficina Asesora de Sistemas, 2012).

Géminis ahora SARA es el nombre del código base del proyecto del Sistema

de Gestión Académica en la Universidad Distrital Francisco José de Caldas, el

cual tiene como objetivo: Soportar los procesos académico-administrativos de

entidades relacionadas con el dominio de la prestación de servicios educativos

(Oficina Asesora de Sistemas, 2012).

7.2 MARCO TEÓRICO

7.2.1 MODALIDADES DEL TRABAJO DE GRADO.

El trabajo de grado es un proceso formativo que hace parte del plan de

estudios desarrollado por el estudiante y le conduce a la obtención de un

resultado final que ha de presentar, para optar a un título universitario. Puede

ser desarrollado en una de las diversas modalidades reglamentadas en el

acuerdo número 038 (Universidad Distrital Francisco José de Caldas, 2015),

entre las cuales se encuentra:

● Monografía: en esta modalidad se realiza un ejercicio de aproximación y

solución a un problema de un campo de conocimiento, mediante la

selección de referentes teóricos, la recopilación, análisis crítico y

sistematización de información relevante.

● Espacios Académicos de Posgrado: es una modalidad de Trabajo de

Grado que realiza el estudiante en los programas de posgrado

(especialización o maestría) que ofrece la Universidad Distrital Francisco

José de Caldas, ello posibilita la profundización en campos de

conocimiento relacionados con el perfil profesional y favorece la

formación pos gradual.


● Investigación-Innovación: implica el vínculo del estudiante a un proyecto

de investigación o de innovación, el cual debe estar institucionalizado

por el CIDC o la Unidad de Investigación de la respectiva facultad, cuyo

propósito es garantizar, mediante el cumplimiento de un plan de trabajo,

la formación en investigación del estudiante.

● Producción Académica: el estudiante debe presentar evidencia de la

publicación o aceptación de un (1) artículo en revista indexada en el

Publindex de Colciencias mínimo en categoría “C” u homologadas en el

último cuartil del Journal Citation Reports - JCR.

● Materias de profundización: da la posibilidad al estudiante del nivel

profesional tecnológico de cursar espacios académicos pertenecientes a

cualquier programa de nivel profesional de la Universidad.

7.2.2 SISTEMA DE GESTIÓN ACADÉMICA, UNIVERSIDAD DISTRITAL.

La Universidad Distrital Francisco José de Caldas actualmente cuenta con un

sistema de gestión académica que recibe el nombre de Cóndor, dicho sistema

de gestión académica provee diferentes servicios, los cuales son diferenciados

de acuerdo al grupo de la comunidad académica que los consume (Castro

Ortiz, 2009), estos se pueden resumir en:

Estudiantes: Este tipo de usuario tiene la posibilidad de validar la

información con respecto al registro de pagos de matrícula, impresión

del recibo de matrícula del presente periodo académico, pre-inscripción

por demanda de espacios académicos, inscripción de espacios

académicos, consulta de horarios y consulta de notas parciales e

históricos, acceso a las bases de datos de la universidad y actualización

de datos personales.

Docentes: Ellos pueden realizar el respectivo registro de notas en línea

de los estudiantes que cursan las asignaturas que dictan, consulta de

listados de curso, ponderación de porcentajes de evaluación, listado de

estudiantes a su cargo en la consejería académica, consulta de horario y

verificación de listados de estudiantes por asignatura que dicta.

Administrativos: Se encargan de realizar el cierre de semestre, gestionar

los espacios académicos, consulta del histórico de notas de un

estudiante en particular, consulta y modificación de la carga académica

de estudiantes y docentes.


CAPÍTULO 8. METODOLOGÍA

El método a aplicar en este proyecto es el proceso de desarrollo OpenUp/OAS,

que se encuentra debidamente aprobado en la Universidad Distrital Francisco

José de Caldas, mediante la Resolución de Rectoría número 461 de 2011

(Bahamon Calderón, 2011).

8.1 MARCO METODOLÓGICO

8.1.1. EL PROCESO OPENUP/OAS

En el marco de la resolución 461 de Rectoría del 29 de Julio de 2011, la

Universidad Distrital Francisco José de Caldas avaló el método de desarrollo

OPENUP/OAS, como el marco de trabajo institucional en el análisis, diseño,

desarrollo e implementación de productos de software al interior de la

Universidad (Bahamon Calderón, 2011). A continuación se describen sus

principales directrices y fundamentos.

8.1.1.1. GENERALIDADES

El proceso OpenUP/OAS es un método de trabajo que involucra un conjunto

mínimo de prácticas tendientes a guiar a un equipo de trabajo pequeño en el

análisis, diseño, desarrollo y despliegue de un producto de software. Los

objetivos que persiguen son:

● Promover la colaboración y compartir conocimientos alineando intereses

del equipo de trabajo y los usuarios.

● Ayudar al equipo a enfocarse en la arquitectura de forma rápida; de tal

forma que se minimicen los riesgos y se organice el desarrollo.

● Ayudar al equipo a balancear prioridades en conflicto para maximizar el

valor obtenido por los interesados en el proyecto.

● Ayudar al equipo en la evolución del producto con el fin de obtener

retroalimentación continua y fomentar el mejoramiento.

● Permitir a los administradores del proyecto realizar seguimientos a los

avances basados en metas e indicadores

● Permitir que los integrantes del equipo entiendan rápidamente cómo

realizar el trabajo para alcanzar los objetivos y metas proyectadas.

Los principios en que se enmarca el método de trabajo OPENUP/OAS son

(Oficina Asesora de Sistemas, 2011b):


a. Conocer a los Interesados: Se deben identificar, conocer a los grupos

de interés y trabajar de cerca con ellos para asegurarse que sus

necesidades son claramente definidas e incrementalmente satisfechas a

medida que se evoluciona en el desarrollo de la solución. Debe

mantenerse una comunicación abierta y frecuente además de una

colaboración entre ellos y el equipo de trabajo.

b. Separar el Problema de la Solución: Se debe estar seguro que se

conoce el problema (o una parte de él) antes de definir una solución (o

una parte de ella). Al separar claramente el problema (que necesita el

cliente - no que necesita el equipo de desarrollo) de la solución (el

sistema que tiene que hacer), es fácil mantener un enfoque y encontrar

vías alternativas para solucionar el problema.

c. Crear un conocimiento compartido del dominio: Se debe fomentar

un ambiente de intercambio y trabajo en el que todos los involucrados

puedan obtener constantemente la información adecuada para lograr

tener una visión compartida de lo que se debe hacer, el por qué hacerlo

y cómo se está haciendo.

d. Usar escenarios y casos de uso para capturar requerimientos:

Hacer uso de escenarios y casos de uso para capturar los

requerimientos funcionales del sistema permiten que los interesados

alcancen rápidamente un consenso acerca de sus necesidades e

intereses.

e. Establecer y mantener contratos de prioridades: Se deben priorizar

los requisitos y requerimientos de implementación basados en un trabajo

continuo con los grupos de interés y tomar decisiones que lleven a que

el sistema siempre incremente los beneficios ofrecidos y reduzca los

riesgos.

f. Realizar negociaciones que maximicen el beneficio obtenido: Las

negociaciones costo beneficio dentro del proyecto no pueden ser

independientes de la arquitectura. Los requisitos y requerimientos

establecen los beneficios que se deben alcanzar al implementar el

sistema mientras que la arquitectura es una medida base para calcular

el costo del mismo. El costo asociado con un beneficio puede influenciar

en gran medida la percepción del usuario acerca del valor real obtenido.

g. Gestionar el entorno: El cambio es inevitable y aunque presenta

oportunidades para mejorar los beneficios dados a los grupos de interés,

un entorno incontrolado de cambios fácilmente decantará en sistemas

deficientes, sobredimensionados y que no satisfacen las necesidades

reales de los clientes. Se debe gestionar los cambios manteniendo

contratos específicos con los grupos de interés.

h. Conocer cuándo se debe parar: Sobrecargar de características un

sistema no sólo es una pérdida de tiempo y recursos sino que conduce a


sistemas innecesariamente complejos. El desarrollo debe parar cuando

la calidad esperada del sistema se alcanza.

i. Mantenga un entendimiento común: Sea proactivo comunicando y

compartiendo información con los participantes del proyecto y no asuma

que todos y cada uno encontrarán justo lo que ellos necesitan saber o

que cada persona tiene la misma comprensión del proyecto que todos

los demás.

j. Aprender continuamente: Desarrolle continuamente sus habilidades

técnicas e interpersonales, aprenda de los ejemplos de sus colegas,

aproveche la oportunidad, tanto de ser un estudiante de sus colegas, así

como maestro de ellos. Siempre incremente su habilidad personal para

sobrellevar su propio antagonismo hacia otros miembros del equipo.

k. Organice alrededor de la arquitectura: La comunicación entre los

miembros del equipo empieza a ser compleja incrementalmente. Por

consiguiente, organice el equipo alrededor de la arquitectura, el

vocabulario y el modelo mental compartido del sistema.

l. Desarrolle su proyecto en iteraciones: Divida su proyecto en una

serie de iteraciones encajadas en el tiempo y planee su proyecto

iterativamente. Esta estrategia iterativa lo habilita para entregar

capacidades incrementalmente, como un conjunto ejecutable,

subconjunto utilizable de requisitos y requerimientos probados e

implementados, que pueden ser evaluados por los interesados al final de

cada iteración.

m. Gestione los riesgos: Ataque tempranamente los riesgos que atacarán

el proyecto. Continuamente identifique y priorice los riesgos y entonces

idee estrategias para mitigarlos.

n. Adopte y gestione el cambio: Adoptar los cambios ayuda a construir

un sistema que se encamina a las necesidades de los interesados y

manejar los cambios permite reducir costos y mejorar la predicción de

estos cambios. Los cambios hechos tempranamente en el proyecto se

pueden hacer usualmente a bajo costo. A medida que usted avanza en

el proyecto, los cambios pueden empezar a incrementarse en términos

de costos.

o. Mida el progreso objetivamente: Si no conoce objetivamente cómo su

proyecto está progresando, no sabe si éste falla o tiene éxito. La

incertidumbre y los cambios a un proyecto de software en progreso

dificultan medirlo objetivamente, en tanto que las personas tienen una

habilidad muy asombrosa para creer que todo está bien ante la

catástrofe.


8.1.1.2. EL MÉTODO DE TRABAJO

Figura 4. Método de trabajo.

Tomado de (Oficina Asesora de Sistemas, 2011b)

El OPENUP/OAS es un proceso iterativo e incremental que se distribuyen a

través de cuatro fases: Inicio, Elaboración, Construcción y Transición. En las

cuales se desarrollan transversalmente una serie de subprocesos

entendiéndose estos últimos como un conjunto de actividades, personas

(Roles), prácticas (Guías) y productos de trabajo (Artefactos) que orientan el

desarrollo de software a través del tiempo.

Cada fase puede tener tantas iteraciones como se requiera, dependiendo del

grado de complejidad y desconocimiento del dominio, la tecnología a ser

usada, la complejidad arquitectónica y el tamaño del proyecto, por nombrar

algunos factores.

8.1.1.2.1. FASES DEL PROCESO OPENUP/OAS

Fase de Inicio: Primera fase del proceso, donde los interesados

(Stakeholders) y los integrantes del equipo de desarrollo, colaboran para

determinar el ámbito del proyecto, sus objetivos y determinar si el proyecto es

viable.


Esta fase se aplicará en este proyecto, puesto que, se hace necesario realizar

una reunión con los interesados (Encargados de la Oficina Asesora de

Sistemas), con el fin de determinar qué se desea con el proyecto, cuál va a ser

su enfoque y poder así precisar un plan de trabajo acorde con las necesidades

planteadas.

Con el fin de agilizar el proceso de desarrollo se realizará un análisis de los

servicios que ofrece la aplicación “UDLearn” para unificar los que se consideren

redundantes.

Para la definición de los subprocesos, es necesario hacer una evaluación de la

documentación y código perteneciente al sistema UDLearn, el cual contiene el

módulo de proyecto de grado de la modalidad de monografía que se requiere

migrar.

Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las siguientes

actividades y resultados:

Actividad Resultados

Iniciar el proyecto

- Elaborar el documento Visión.

- Elaborar el Plan General del Proyecto.

- Elaborar el documento de Análisis de Riesgo.

Planear y gestionar la

iteración

- Elaborar el Plan de Iteración.

- Elaborar el documento de evaluación de la

iteración.

- Elaborar el documento de valoración de

resultados de la iteración.

Identificar y refinar los

requerimientos y requisitos

- Elaborar la especificación de casos de uso.

- Elaborar el documento de requisitos de soporte.

- Elaborar el documento casos de prueba.

Llegar a un acuerdo sobre el

enfoque técnico

- Elaborar el documento Bloc de Notas de la

Arquitectura.

Tabla 3. Fases del proceso OpenUP/OAS. Tomado de Oficina Asesora de sistemas

Al final de esta fase, como mínimo, el proyecto:

● Ha definido el ámbito.

● Tiene un estimado inicial de los costos y el cronograma.


● Ha definido y priorizado un conjunto inicial de requerimientos funcionales

y no funcionales.

● Ha identificado un conjunto de riesgos y ha propuesto las estrategias de

mitigación.

● Ha identificado un conjunto de interesados.

● Ha creado un bosquejo de arquitectura.

Fase de Elaboración: La segunda fase dentro del ciclo de vida del proyecto.

En ella los riesgos significativos que influyen en la arquitectura son

identificados y considerados.

En esta fase:

● Se obtiene un entendimiento más detallado de los requerimientos y

requisitos.

● Se diseña, implementa, valida y establece la línea base de la

arquitectura.

● Se mitigan los riesgos esenciales.

● Se produce un cronograma detallado.

● Se realiza una mejor estimación de costos.

Las iteraciones de esta fase enfocan el esfuerzo de trabajo en las siguientes

actividades y resultados:

Actividad Tareas/Resultados

Planear y gestionar la

iteración

- Elaborar el Plan de Iteración.

- Elaborar el documento de evaluación de la

iteración.

- Elaborar el documento de valoración de resultados

de la iteración.

Identificar y refinar los

requerimientos

- Actualizar, depurar y aumentar el contenido de la

especificación de casos de uso.

- Actualizar, depurar y aumentar el contenido del

documento de Requerimientos de soporte.


documento Casos de prueba.

Desarrollar la arquitectura - Agregar las vistas de arquitectura al documento

Bloc de Notas de la Arquitectura.


Desarrollar un incremento

en la solución


documento Especificación de Diseño.


documento Pruebas efectuadas por el Realizador.

- Obtener el código fuente que realiza uno o varios

elementos de diseño.

- Elaboración de una Construcción del Sistema que

integre nuevos elementos (componentes

desarrollados, clases, etc.).

- Elaborar el artefacto Registro de Pruebas que

contenga los resultados de la ejecución de las

pruebas hechas por el realizador.

Probar la solución

construida

- Elaborar el artefacto Script de Prueba.

- Elaborar el artefacto Registro de Pruebas que

contenga los resultados de la ejecución de las

pruebas.

Gestionar las peticiones de

cambio


documento Lista de Unidades de Trabajo.

Tabla 4. Fase de elaboración proceso OpenUP/OAS. Tomado de (Oficina Asesora de Sistemas, 2011b)

Fase de Construcción: Esta es la tercera fase del proceso, se enfoca en

detallar los requisitos y requerimientos, diseñar, implementar y probar el grueso

del software y completar el desarrollo del sistema basado en la arquitectura.

● Se describen los requisitos y requerimientos restantes.

● Se completan en detalles los diseños, la implementación y las pruebas

del software.

● Se libera la primera versión operativa del software (beta) del sistema.

Las actividades de esta fase son:

1. Planificación y gestión de la iteración.

2. Identificar y refinar requisitos y requerimientos.

3. Desarrollar un incremento de solución.

4. Probar la solución construida.

8.1.1.2.2. SUBPROCESOS OPENUP/OAS

Como se había señalado anteriormente, un subproceso es un conjunto de

actividades desarrolladas por personas con unos roles determinados, las

cuales se guían por medio de una serie de prácticas o guías para obtener unos


productos de trabajo denominados Artefactos y que permiten cumplir

direccionar las fases y actividades propuestas en las cuatro fases del proceso

de desarrollo de software OpenUP/OAS. Estos subprocesos se relacionan

entre sí, siendo unas entradas o insumos iniciales para que otros subprocesos

se puedan desarrollar.

Figura 5. Proceso de desarrollo OpenUP/OAS.


Subproceso

Objetivo Artefactos de Salida

Gestión de

Requerimientos

y Requisitos

Recolectar, analizar, aprobar y

seguir la evolución de los

requerimientos funcionales del

Cliente o interesado y los requisitos

del software a través de la vida del

producto y/o servicio.

- Visión.

- Especificaciones de

Casos de Uso.

- Glosario.

- Requisitos de Soporte.

- Actas de Trabajo.

- Listado de

requerimientos funcionales

y no funcionales.

Gestión del

Proyecto

Planear, ejecutar, controlar y

socializar las actividades y

resultados de un proyecto de

software.

Plan General del proyecto.

Plan de Iteración.

Cierre de iteración.

Lista de Unidades de


trabajo.

Gestión del

Riesgo

Identificación, valoración,

relevancia, prevención, mitigación,

control y respuesta a posibles

riesgos que se generen en un

proyecto de software.

Plan y tratamiento de

Riesgos.

Arquitectura y

diseño

Transformar los requerimientos y

requisitos significativos en una

arquitectura que describa su

estructura e identifique los

componentes del software.

Diagramas de Clases.

Diagrama de

componentes.

Diagramas de Secuencia.

Diagramas de

Colaboración.

Arquitectura de Datos.

Bloc de Notas de la

Arquitectura.

Desarrollo Implementar una solución técnica

que cumpla con la arquitectura

definida y soporte los

requerimientos de los grupos

interesados.

Código Fuente.

Gestión de

Pruebas

Diseñar, implementar, ejecutar y

evaluar pruebas en cada uno de los

componentes desarrollados.

Casos de Prueba.

Resultados casos de

prueba.

Gestión de

Cambios

Registrar, revisar y llevar a cabo

solicitudes de cambios generadas

en un proceso de desarrollo de

software.

Control de Cambios.

Implantación

Planificar y llevar a cabo la

producción de una solución de

software mediante el alineamiento

de las necesidades de capacitación

de los usuarios y el desarrollo de

pruebas de funcionamiento.

Plan de despliegue

socialización, capacitación

o acompañamiento.

Tabla 5. Subprocesos de desarrollo OpenUP/OAS. Tomado de (Oficina Asesora de Sistemas, 2011b)

Los autores del presente proyecto, como miembros de un equipo de trabajo de

la Oficina Asesora de Sistemas, estaremos encargados de la realización de los

subprocesos de:

Gestión de Requerimientos y Requisitos


Arquitectura y Diseño

Desarrollo

Lo anterior, teniendo en cuenta la documentación del análisis, diseño y

desarrollo perteneciente al sistema UDLearn. Los subprocesos restantes

estarán a cargo del personal asignado por la Oficina Asesora de Sistemas.

8.1.1.2.3. ROLES OPENUP/OAS

Los productos de software los crean personas con diferentes intereses y

competencias. Un ambiente de grupo saludable potencia la colaboración

efectiva requiriendo una cultura compartida que fomente la creatividad y el

cambio positivo.

Los roles son el rostro humano del proceso de desarrollo de software.

Dependiendo del número de personas que conforman el equipo de trabajo y las

condiciones del proyecto una persona puede asumir uno o varios roles.

Figura 6. Estructura del equipo de desarrollo OpenUP/OAS.


Rol Función Principal

Director del Proyecto Este rol garantiza la continuidad del proyecto al


(Asignado por la OAS) gestionar los recursos necesarios y mantener el

interés institucional en el proyecto.

Jefe de Proyecto

(Asignado por la OAS)

Este rol se encarga de la supervisión y dirección

directa de las actividades y resultados de cada

uno de los miembros del equipo de desarrollo.

Líder del Proyecto


Lidera la planeación del proyecto, coordina

interacciones con los interesados y conserva el

equipo del proyecto enfocado en alcanzar los

objetivos del proyecto.

Analista

(Autores del presente

proyecto)

Realizar tareas de relevamiento, análisis y diseño

de los requerimientos y requisitos en el

proyecto.

Arquitecto


proyecto)

Responsable de diseñar la arquitectura del

software, la cual incluye tomar las principales

decisiones técnicas que condicionan globalmente

el diseño y la implementación del proyecto.

Realizador o

desarrollador


proyecto)

Es responsable de desarrollar una parte del

sistema, incluyendo diseñar esta, para que se

ajuste a la arquitectura

Inspector de Pruebas


Identificar, definir, implementar y dirigir las

pruebas necesarias, así como verificar y analizar

sus resultados.

Tabla 6. Roles en el proceso OpenUP/OAS. Tomado de (Oficina Asesora de Sistemas, 2011b)

Como se observa en la anterior tabla, los subprocesos que tendrán a cargo los

realizadores del presente proyecto, serán de acuerdo a los roles de analista,

arquitecto y desarrollador, los cuales se encuentran enmarcados en el

Equipo de Desarrollo de la metodología OPEN/UP. Los roles restantes serán

asumidos por la Oficina Asesora de Sistemas.

8.1.1.2.4. ARTEFACTOS DEL PROCESO OPENUP/OAS

Nombre Descripción

Plan General del Este artefacto define los parámetros para realizar el


Proyecto direccionamiento y seguimiento al proyecto. Especifica los

objetivos de alto nivel de las iteraciones y sus

correspondientes hitos.

Plan de Iteración Comunica los objetivos, la asignación de tareas y los

criterios de evaluación para una iteración dada.

Unidades de Trabajo

Diarias

Contiene una lista de los trabajos programados diariamente

y que responden a los objetivos definidos en la Iteración y

en el proyecto.

Cierre de iteración Este documento registra los resultados de una iteración.

Visión

Contiene los lineamientos de los requerimientos nucleares

visionados del sistema, especificado las necesidades y

características claves de los Interesados.

Requisitos de soporte Captura requisitos en el ámbito del sistema que no hayan

sido capturados en escenarios o casos de uso, incluye

requisitos sobre atributos de calidad y de desempeño

global.

Especificación de

Casos de Uso

Captura la secuencia de acciones que un sistema realiza y

que genera un resultado observable que es de valor para

aquellos que interactúan con el sistema.

Glosario Este artefacto define términos importantes usados en el

proyecto.

Listado de

requerimientos y

requisitos *

En este documento se registran los requerimientos y

requisitos que surjan a lo largo del proyecto y sirve para

priorizar y organizar las tareas, objetivos y metas del

mismo.

Acta de Trabajo Registra los acuerdos o compromisos definidos entre los

interesados y el equipo de desarrollo.

Plan de Riesgos

Contiene la identificación, valoración, relevancia,

prevención, mitigación, control y respuesta a posibles

riesgos que se generen en un proyecto de software.

Bloc de notas de la

Arquitectura *

Contiene las decisiones, razonamientos, asunciones,

explicaciones e implicaciones sobre la arquitectura en

formación.

Documento de Diseño

*

Artefacto que documenta las especificaciones técnicas en

cuanto al diseño del software y se complementa con

diagramas de clases, diagramas de colaboración,

diagramas de secuencia entre otros.


Control de Cambios

Este artefacto es utilizado para documentar las solicitudes

de cambio de los diferentes subprocesos que surgen al

interior del proyecto por parte de los interesados o

miembros del equipo del proyecto.

Caso de prueba

Son la especificación de un conjunto de pruebas de

entradas, condiciones de ejecución y resultados esperados,

los cuales son identificados para el propósito de realizar

una evaluación de un aspecto particular en un escenario

específico.

Registro de Pruebas

Este artefacto recolecta los resultados de la ejecución de

una o más pruebas en un ciclo completo de pruebas.

Tabla 7. Artefactos del proceso OpenUP/OAS. Tomado de (Oficina Asesora de Sistemas, 2011b)

En la tabla anterior, los artefactos que se entregarán como resultado serán los

que se encuentran señalados por asterisco (*), los demás artefactos para el

desarrollo del proyecto, serán generados por las personas asignadas por la

OAS a cada rol.

8.1.1.3. PROCESO DE DESARROLLO

8.1.1.3.1. FICHA DE CARACTERIZACIÓN DE SUBPROCESO

Se presenta la respectiva ficha de caracterización de subproceso, referente al

desarrollo de la solución:

Caracterización del subproceso

Desarrollo de la solución

Objetivo

Producir una puesta en funcionamiento de una parte de la solución (tal como una clase o componente) o corregir uno o más defectos. El resultado es un código fuente nuevo o modificado.

Subprocesos de entrada Diseño de la solución

Gestión de cambios

Procedimiento Desarrollo de la solución

Artefactos relacionados

Código fuente

Responsables Guías

Desarrollador

Integración continua

Reconstrucción (Refactoring)

Transformar el diseño en puesta en


funcionamiento

Salidas Elevar los cambios al siguiente nivel en

operación

Puesta en funcionamiento de una parte de la solución

Reutilización del software

Estándares para la escritura de código

Puesta en funcionamiento

Tabla 8. Ficha desarrollo de solución proceso OpenUP/OAS. Basado de (Oficina Asesora de Sistemas, 2011a)

Se evidencia de igual manera el subproceso desarrollo de la solución a

continuación:

Figura 7. Subproceso de desarrollo OpenUP/OAS Tomado de (Oficina Asesora de Sistemas, 2011a)

La actividad de identificar oportunidades de reúso del código, es importante

en este proyecto y se utilizará de dos formas, inicialmente, se tomará en cuenta

parte del código de la aplicación original, ya que este no está implementado


totalmente en java, sino que internamente hace uso de funcionalidades de

varios lenguajes como Java Script, lenguajes de marcado como HTML y XML,

librerías pertenecientes a JQuery, Ajax, Json y plantillas CSS, que también se

implementarán en la aplicación ya migrada. Por otra parte en la implementación

de la nueva aplicación, al utilizar el framework SARA se presentará reúso tanto

para la generación de formularios web como para funcionalidades propias del

sistema.

8.1.1.3.2. GUÍAS

8.1.1.3.2.1. INTEGRACIÓN CONTINUA

“La integración continua introduce la práctica de integrar continuamente los

conjuntos de cambios para reducir el esfuerzo requerido para mezclar

desarrollos en paralelo y para encontrar fallos de forma temprana. Con este

concepto se conduce el trabajo colaborativo.

La integración continua es una práctica de puesta en funcionamiento donde los

integrantes del equipo integran su trabajo con los trabajos de otros realizadores

de software y lo prueban de forma local antes de hacer su trabajo disponible.

Esto habilita la detección de errores de integración al determinar errores de

compilación, notificaciones del sistema o fallos reportados por las herramientas

de pruebas. Idealmente la integración se realiza de forma automática antes de

elevar los cambios al siguiente nivel de operación” (Oficina Asesora de

Sistemas, 2011a).

De acuerdo a la documentación para la metodología OPENUP especificada por

Elipse (Eclipse, 2012), la integración continua provee los siguientes beneficios:

1. Mejora la retroalimentación. La integración continua muestra un

progreso constante y demostrable.

2. Mejora la detección de errores. La integración continua permite que los

errores se detecten de forma temprana muchas veces a los pocos

minutos después de que se han inyectado dentro del producto. Para

aumentar la efectividad de la integración se recomienda el uso de

herramientas para la realización de pruebas.

3. Mejora la colaboración. La integración continua facilita que los

integrantes del equipo trabajen colaborativamente de forma segura.

Fomenta la realización de cambios, la integración local y la detección

temprana de conflictos en el código.


4. Mejora la integración del sistema. Cada uno de los realizadores se

cerciora que el sistema puede ser integrado mitigando la posibilidad de

error asociada a esta actividad.

5. Reduce el número de cambios – a partir de trabajos paralelos – que

necesitan ser mezclados y verificados.

6. Reduce el número de errores encontrados durante las pruebas al

sistema ya que todos los conflictos son resueltos antes de hacer

disponible el conjunto de cambios.

7. Reduce los riesgos técnicos. Siempre se podrá contar con un sistema

actualizado frente al cual realizar las pruebas.

8. Reduce la administración del riesgo. La integración continua permite

conocer claramente cuál es la nueva funcionalidad que se está

agregando al sistema limitando el impacto de nuevos cambios.

8.1.1.3.2.2. RECONSTRUCCIÓN (REFACTORING)

Este concepto explica los mecanismos para mejorar el diseño de código

existente de tal forma que no se afecte - si no es necesario - su

comportamiento externo.

La reconstrucción es una vía disciplinada para reestructurar el código cuando

pequeños cambios se han realizado para mejorar el diseño. Un aspecto

importante es que se mejora el diseño pero sin cambiar el comportamiento.

Una reconstrucción no adiciona ni remueve funcionalidad.

La reconstrucción fomenta la evolución del código a través del tiempo con un

enfoque iterativo e incremental hacia la puesta en funcionamiento.

Estos son los tipos de reconstrucción:

1. Reconstrucción de código. Consiste en la reconstrucción del código

fuente fruto de la programación. Algunos ejemplos pueden incluir el

renombrado de métodos, la encapsulación de campos, la extracción de

clases, la introducción de comentarios y la reestructuración de métodos.

2. Reconstrucción de bases de datos. Son cambios a los esquemas de la

base de datos que mejoran el desempeño mientras que mantienen la

semántica en la información y el desempeño. Ejemplos incluyen

renombrar columnas, dividir una tabla, mover algún método,

reestructurar procedimientos almacenados, reemplazar LOB con Table,

agregar restricciones a las columnas y utilizar fuentes de datos oficiales.


3. Reconstrucción de Interfaz de Usuario (IU). La reconstrucción de IU

consiste en realizar cambios simples en la interfaz gráfica mientras se

mantiene su semántica. Ejemplos incluyen la re acomodación de

campos en los formularios, aplicar estilos, etc.

8.1.1.3.2.3. TRANSFORMAR EL DISEÑO EN PUESTA EN

FUNCIONAMIENTO

Transformar el diseño en código que implemente la estructura del sistema

utilizando el lenguaje de programación seleccionado. También hace referencia

a implementar el comportamiento del sistema definido en los requerimientos

funcionales. Implementar el comportamiento del sistema significa escribir el

código fuente que permite que diferentes partes de la aplicación (clases o

componentes) colaboren en la realización del comportamiento esperado del

sistema. Así pues existen varias técnicas para que de forma automática se

transforme el diseño en artefactos de puesta en funcionamiento

8.1.1.3.2.4. ELEVAR LOS CAMBIOS AL SIGUIENTE NIVEL DE OPERACIÓN

Durante el desarrollo iterativo de software los grupos de trabajo crean

numerosos conjuntos de Cambio que son agrupados en una Construcción. Una

construcción se inicia combinando el trabajo completado por uno o más

realizadores y resolviendo los conflictos que pueden existir entre los diversos

cambios. Idealmente, la construcción es después sometida a una completa

batería de pruebas para poder determinar si tiene la calidad suficiente que le

permita moverse al ambiente de producción.

A medida que los cambios progresan desde el desarrollo a la producción es

benéfico conocer en la presente construcción:

Ámbito de pruebas: identificar los elementos y las versiones que deben ser

verificadas.

Qué cambios se tienen (unidades de trabajo completas)

Qué cambios se han implementado parcialmente (unidades de

trabajo que se han implementado parcialmente)

Que cambios no se tienen (unidades de trabajo que no se ven

reflejadas)

Nivel de Verificación: identificar la cantidad de pruebas que se han

completado.

Unidades probadas


Integración probada

Sistema probado

8.1.1.3.2.5. REUTILIZACIÓN DE SOFTWARE

Maximizar la reutilización de software es una meta importante dentro del

desarrollo de software. Es mejor reutilizar código y diseño existente que gastar

tiempo y recursos creando, probando y lanzando nuevo código; con los riesgos

asociados que implican el desarrollo de nuevo software. Los lenguajes de

programación, especialmente aquellos orientados a objetos, han sido

diseñados para facilitar la reutilización. Pero ha de tenerse en cuenta que el

lenguaje por sí solo no es suficiente para lograr una reutilización costo efectiva.

La mayoría del software reutilizable proviene de expertos realizadores de

software y arquitectos quienes han sido capaces de identificar y apalancar las

oportunidades de reutilización. Para dicha reutilización es pertinente tener en

cuenta las siguientes recomendaciones:

Identificar oportunidades de reutilización.

Técnicas de reutilización.

Herencia y agregación.

Encontrar código reutilizable.

Evitar reutilizar todo.

8.1.1.3.2.6. ESTÁNDARES PARA LA ESCRITURA DE CÓDIGO

Son estándares que describen varias convenciones acerca de cómo escribir el

código fuente. Su principal tarea es asegurar la consistencia, calidad y una

puesta en funcionamiento fácil de entender.

Los estándares mencionados pueden cubrir áreas como:

Estándares para asignación de nombres: Esto incluye la forma en

que se le da nombre a todos los elementos dentro del código.

Cuando se cubren elementos de gran escala pueden solapar los

estándares de diseño.

Organización de los archivos: Incluye convenciones para colocar

nombres a los archivos y cómo éstos deben ser organizados dentro

del árbol de directorios del sistema.

Estándares para los comentarios: Poner demasiado énfasis en los

comentarios denota una pérdida de confianza en cuanto la calidad

del software que se está escribiendo. Además, se tendrá siempre


una impresión de que los comentarios estarán desactualizados. La

idea es estandarizar la forma en la cual se comenta el código para

soportar la capacidad de soporte y la capacidad de generar

documentación a partir del código.

Convenciones para la escritura de código: Aplicación de

convenciones específicas a nivel de código.

Espacio en blanco: Aunque algunos autores lo consideran como de

menor impacto es un hecho que el manejo adecuado de los espacios

en blanco, los saltos de línea, las sangrías y las líneas en blanco

facilitan la lectura del código.

8.1.1.3.2.7. PUESTA EN FUNCIONAMIENTO

La puesta en funcionamiento es una versión funcional del sistema o una parte

del sistema que implementa un subconjunto de las capacidades que proveerá

el producto final.

Entregar productos, incrementando cada vez la funcionalidad, con valor para

los usuarios y los clientes. Proveer un artefacto que pueda ser probado.

Las versiones del sistema son el resultado de poner en funcionamiento el

sistema a través de un proceso de construcción (usualmente automatizado por

medio de un script de construcción) que crea una versión ejecutable del

sistema o una versión que pueda ser ejecutada. Esta versión ejecutable tendrá

un conjunto de archivos de soporte que son considerados como parte del

artefacto.

Son los archivos de código, archivos de datos y archivos de soporte - tales

como ayuda en línea – los cuales representan partes específicas del sistema

que pueden ser reconstruidas que representan las partes “físicas” que hacen

que el sistema sea construido y organizado en una forma que sea fácil de

entender y administrar.

Este artefacto es una combinación de uno o más de estos elementos:

Archivos de código fuente.

Archivos de datos.

Scripts de construcción.

Otros archivos que son creados como ejecutables dentro del sistema.


Tomando en cuenta que el proyecto abarca dos objetivos grandes, por una

parte está la migración del sistema UDLearn y por otra el análisis y diseño de

las modalidades de grado de Espacios Académicos de Posgrado,

Investigación-Innovación, Espacios de Profundización y Producción

Académica, los roles a lo largo del desarrollo del trabajo cambiarán de

desarrollador a analista y posteriormente a arquitecto, por ende, en la tabla 9

se especifica el conjunto de actividades a desarrollar por el rol desarrollador,

analista y arquitecto teniendo en cuenta el proceso de desarrollo OpenUp/OAS,

como la respectiva metodología a implementarse.

ROL SUBPROCESO OBJETIVO

Analista Gestión de Requerimientos y

Requisitos

Generar los requerimientos para el desarrollo de las demás modalidades de grado.

Arquitecto Arquitectura y diseño Diseñar y ajustar la arquitectura de datos del sistema migrado.

Desarrollador Desarrollo

Realizar la migración completa del módulo de gestión de trabajos de grado en la modalidad de monografía.

Tabla 9. Roles y Subprocesos presentes en el proyecto. Fuente: Autores.

8.2. APLICACIÓN DEL FRAMEWORK SARA

De acuerdo a los desarrolladores del framework, este permite estandarizar el

desarrollo de un aplicativo, facilitando la integración entre las diferentes partes

de un sistema, simplificando la comunicación entre la aplicación y la base de

datos que la sostiene. Para ello hace uso de los bloques, los cuales especifican

su funcionalidad, interfaz, conexión con la base de datos y la seguridad de la

información que maneja.

Este framework permite la creación y manejo de formularios de una manera

más sencilla, ya que, los genera mediante algunas tablas de la base de datos

que genera automáticamente en la instalación del framework, lo que facilita

reusar los bloques.

Además, en la instalación del framework, esquematiza el proyecto, agrupando

de acuerdo a su funcionalidad, los diferentes componentes del sistema, lo que

ahorra tiempo de desarrollo.


CAPÍTULO 9. DESARROLLO DE INGENIERÍA

Para el desarrollo del proyecto, se optó por realizarlo en dos fases, una primera

fase en la cual se realizó la migración completa del módulo de gestión de

trabajos de grado para la modalidad de monografía; y una segunda fase en la

cual se realizó el análisis de las modalidades de Espacios Académicos de

Posgrado, Espacios Académicos de Profundización, Innovación-Investigación y

Producción Académica. En cada una de las fases se implementaron diferentes

etapas de acuerdo a la metodología seleccionada. Dicho proceso se detalla a

continuación.

9.1. FASE UNO: MIGRACIÓN MODALIDAD DE MONOGRAFÍA

En el presente capítulo se describe detalladamente el proceso utilizado para el

desarrollo del proyecto conforme a las fases propuestas en el marco

metodológico (Inicio, Elaboración y Construcción). Se hace indispensable

indicar, que la ejecución de dichas fases se hicieron de manera que se

ajustaran conforme a las necesidades del proyecto, además de que su proceso

fue iterativo, con el fin de depurar el producto final haciendo que este fuese lo

más estable posible.

9.1.1. Fase de Inicio

El equipo de trabajo junto con los interesados determinó el objetivo del ciclo de

vida del proyecto, ello enmarca el ámbito del proyecto, sus objetivos y la

viabilidad del mismo, así como los costos asociados. Todo lo anterior, se dio

luego de realizar una evaluación de las funcionalidades brindadas por el

sistema UDLearn, producto generado como resultado de una tesis de maestría

en la Universidad; de lo anterior, se determinó, que de la aplicación existente,

se quería una copia exacta del módulo de trabajos de grado para la modalidad

de monografía, mediante el uso del framework SARA y el motor de base de

datos PostgreSQL. Todo esto fue plasmado principalmente en los artefactos de

Visión, Plan General del Proyecto, Glosario, Plan de Riesgo, Bloc de Notas de

la Arquitectura y el plan y cierre de la iteración.

9.1.1.1. Etapa 1: Identificación y descripción de la necesidad

Análisis de servicios de UDLearn: Antes de iniciar la migración de la

aplicación UDLearn, se hizo un análisis de las funcionalidades presentes en el

sistema, para ello, se accedió a la URL donde está desplegada la aplicación a

migrar: http://200.69.103.29:24421/UDLearn/inicio/PageHome.pub. Mediante

un listado con los datos de acceso de los usuarios registrados en el sistema y


el manual de usuario, se hizo un análisis del menú de acuerdo a los roles

existentes, con el fin de determinar si existían funcionalidades duplicadas, o

servicios que no debían considerarse por ser parte de alguno de los módulos

diferentes al de administración y trabajos de grado del sistema original.

Una vez revisadas las funcionalidades de la aplicación UDLearn, se observó

que existen funcionalidades duplicadas, es decir no ofrecen bondades

adicionales a las que ya se encuentran contenidas en otros módulos de la

aplicación, es por esto que en aras de optimizar el proceso de migración se

realizó el análisis mostrado en las siguientes tablas y se concluyó que las

opciones del módulo general correspondiente a bienvenida y a inicio de sesión;

así como el de oficina de pasantías debían ser eliminadas, por lo que su

migración no se llevó a cabo al sistema Pólux.

Rol Coordinador

En la tabla 10 se muestran los sub-módulos del rol de coordinador que se

encuentran repetidos a lo largo del sistema y se señala que el sub-módulo

general se eliminará, esto debido a que se identificó que no aporta

funcionalidades determinantes para el usuario final.

General Sub-módulo Enlace Descripción

X General Bienvenida Muestra el formulario de bienvenida

Inicio de Sesión Redirige a la página inicio de sesión

Profesores

Asignar temáticas de interés

Permite seleccionar un docente para agregarle las áreas de conocimiento con las que tiene relación

Tabla 10. Enlaces repetidos rol de Coordinador Fuente: Autores

Para los demás roles (estudiante, docente y administrador) no se encontraron

sub-módulos repetidos, sin embargo, en todos ellos se encuentra presenta el

sub-módulo general, el cual se determinó que sería eliminado, por ello se

realiza el registro en las tablas 11, 12 y 13.

Rol Estudiante




Tabla 11. Enlaces repetidos rol de Estudiante Fuente: Autores


Rol Docente




Profesores Asignar temáticas de interés

Permite seleccionar un docente para agregarle las áreas de conocimiento con las que tiene relación

Tabla 12. Enlaces repetidos rol de Docente Fuente: Autores

Rol Administrador




Tabla 13. Enlaces repetidos rol de administrador Fuente: Autores

9.1.1.2. Etapa 2: Análisis del acuerdo 038 de 2015 para generar la

especificación de requerimientos

Se hizo una lectura minuciosa del proceso que contemplan las modalidades de

grado seleccionadas para modelar (Espacios Académicos de Posgrado,

Espacios Académicos de Profundización, Producción Académica, Innovación -

Investigación), encontrando varios vacíos en el proceso descrito por el acuerdo

038 (Universidad Distrital Francisco José de Caldas, 2015), que posteriormente

fueron informadas al gestor del proyecto y este a su vez, solicitó información

pertinente a la Vicerrectoría académica y demás dependencias que pudieran

dar solución a las preguntas.

9.1.2. Fase de elaboración

En esta fase el equipo de trabajo obtuvo más detalles de los requerimientos del

sistema, para definir la arquitectura del ciclo de vida del proyecto, para esto se

diseñó, implementó y probó la arquitectura planteada en la fase de inicio, para

mitigar los riesgos potenciales con el fin de generar un calendario preciso y una

estimación de costos. El registro de estos datos se hizo principalmente en los

artefactos del Plan de Riesgo, Bloc de Notas de la Arquitectura, Listado de

Requerimientos y Requisitos, el Plan General del Proyecto y el plan y cierre de

la iteración.


9.1.2.1. Etapa 1: Modelado BPMN

Mediante la lectura del acuerdo 038 (Universidad Distrital Francisco José de

Caldas, 2015), específicamente de las modalidades de grado de Espacios

Académicos de Posgrado, Espacios Académicos de Profundización,

Investigación-Innovación y Producción Académica, se definió mediante

diagramas BPMN, el flujo de trabajo de cada modalidad, dejando como

resultado la primera versión de modelamiento, la cual se fue reestructurando en

las iteraciones siguientes.

9.1.2.2. Etapa 2: Migración de la Base de Datos

Se hizo una evaluación del modelo relacional perteneciente al sistema

UDLearn, de lo cual, dada la complejidad del modelo y teniendo en cuenta que

no todas las tablas del sistema original eran usadas, se define realizar la

migración de acuerdo a las funcionalidades que se fueran desarrollando

mediante el framework SARA.

9.1.3. Fase de construcción

Para la puesta en marcha de esta fase, se partió del análisis anteriormente

realizado a las modalidades de grado seleccionadas al inicio del proyecto, con

el fin de lograr describir los requerimientos faltantes, para ello se hace uso del

Lenguaje de Modelado UML y se representa por medio de los diagramas de

casos de uso, actividades y secuencia.

Esto se realiza con la finalidad de estandarizar el análisis complete del sistema

y así, garantizar que este pueda escalarse hasta el punto, de cubrir todas las

modalidades de grado implementadas al interior de la Universidad Distrital.

En esta fase, además, se complementan detalles del diseño del aplicativo, con

el fin de hacerlo interactuar de una manera más intuitiva, facilitando el uso por

parte de los usuarios del sistema, tales como estudiantes, docentes y demás.

Finalmente se realiza un pequeño manual de uso del aplicativo, con el fin de

que al interior de la Oficina Asesora de Sistemas se puedan realizar las

pruebas correspondientes al sistema. Para ello, se libera la versión beta del

sistema, la cual se encuentra pública al interior de la red de la Universidad

Distrital en los siguientes enlaces:

http://10.20.0.149/polux/

http://www.pruebasoas.udistrital.edu.co/polux

http://10.20.0.127/polux/

http://10.20.0.149/polux/

http://www.pruebasoas.udistrital.edu.co/polux

http://10.20.0.127/polux/


9.1.4. Plan General del proyecto

9.1.4.1. Plan de iteración

En el proceso de la elaboración del Plan de iteración, se determinó, en

consenso con los desarrolladores, la líder de desarrollo interno en la Oficina y

la Directora externa, realizar el proceso semanalmente. Esto tomando en

cuenta las funcionalidades identificadas anteriormente.

Cada iteración se realiza por semana y la cantidad de tareas para la iteración

es determinada de acuerdo con la dificultad que representa cada una de ellas,

cada una de las iteraciones planteadas se observa de manera más detallada a

continuación:

Primera iteración: Para la primera iteración de la migración de UDLearn, se

inicia con las funcionalidades básicas, las cuales, básicamente se encargan de

alimentar la base de datos del sistema con el fin de suministrar la información

requerida para poder realizar el registro de anteproyectos.

Al determinar que la mayoría de las funcionalidades a desarrollar en esta

primera iteración son básicamente formularios, se asignan varias

funcionalidades por desarrollador. Sin embargo, unas de las funcionalidades

son un poco más complejas, al ser necesario la implementación de AJAX, por

lo cual se amplió el plazo para el desarrollo de estas, con el compromiso de no

descuidar las funcionalidades de la siguiente iteración.

Para esta primera iteración se hizo necesario la implementación de las tablas

para el manejo de usuarios: estudiantes, docentes; además las tablas para el

registro de facultades, sus delegados; y programas curriculares; para la

arquitectura de datos.

En la tabla 14 se evidencia como para la primera iteración, se decidió

implementar funcionalidades básicas del sistema original (Creación de

usuarios) y gestión de sesiones de usuario. Además se especifica al módulo al

que pertenece cada funcionalidad desarrollada y a que rol le aplica la misma.

Finalmente se observa el periodo de desarrollo de cada funcionalidad.

No. Módulo Funcionalidad Rol que

aplica

Periodo Desarrollo

Fecha Inicio Fecha Final

0 Gestión Usuario

Sesiones de usuario

Gestión Usuario

27/12/2015 30/12/2015


1 Administrador Crear facultad Administrador 7/12/2015 14/12/2015

2 Administrador Crear delegado facultad

Administrador 7/12/2015 17/12/2015

3 Administrador Crear programa curricular

Administrador 7/12/2015 17/12/2015

4 Administrador Crear estudiante Administrador 7/12/2015 17/12/2015

5 Administrador Crear docente Administrador 7/12/2015 17/12/2015

Tabla 14. Cronograma de desarrollo para la primera iteración. Fuente: Autores

Segunda iteración: Para la siguiente iteración, se completan los formularios

de registro faltantes y se inicia con el desarrollo de funcionalidades

pertenecientes con la modalidad de monografía, por lo cual, el desarrollo

empieza a depender directamente del correcto desempeño de las

funcionalidades contiguas, lo cual implica que en caso de demora en el

desarrollo de una funcionalidad, representará retraso en las siguientes

funcionalidades.

En esta iteración se crean las tablas de secretaría académica, delegado de

secretaría, temática de interés, tabla de relación entre docentes y temática de

interés y todas las tablas de anteproyecto.

En la tabla 15 se muestran las actividades planificadas y llevadas a cabo para

la segunda iteración, aquí se completan las funcionalidades de creación de

usuarios y se inicia con el desarrollo de la primera etapa de la modalidad de

monografía: Anteproyecto.


aplica

Periodo Desarrollo


6 Administrador Crear secretaría académica

Administrador 15/12/2015 21/12/2015

7 Administrador Crear delegado secretaría académica

Administrador 15/12/2015 21/12/2015

8 Administrador Registrar temática de interés

Administrador 15/12/2015 21/12/2015

9 Coordinador Asignar temáticas de interés a cualquier docente

Coordinador 15/12/2015 27/12/2015

10 Docente Asignar temáticas de interés a sí mismo

Docente 15/12/2015 27/12/2015

11 Coordinador Registrar Coordinador 15/12/2015 27/12/2015


anteproyectos

12 Coordinador Anteproyectos sin revisores asignados

Coordinador 15/12/2015 27/12/2015

13 Coordinador Anteproyectos por proyecto curricular

Coordinador 15/12/2015 27/12/2015

Tabla 15. Cronograma de desarrollo para la segunda iteración. Fuente: Autores

Tercera iteración: En esta iteración ya se centra en la primer etapa de un

proyecto de grado en la modalidad de monografía, de igual manera cada

funcionalidad desarrollada debe permitir la interoperabilidad entre roles, debido

a que aunque la funcionalidad es esencialmente la misma, cada rol tiene unos

permisos diferentes y un acceso a demás funcionalidades diferente.

En la tabla 16 se indican las funcionalidades para la tercera iteración y se

observa cómo se llevo a cabo el desarrollo de las funcionalidades propias de la

etapa de anteproyecto para los roles de Estudiante, Docente y Coordinador.


aplica

Periodo Desarrollo


14 Estudiante Anteproyectos por estudiante

Estudiante 28/12/2015 12/01/2016

15 Coordinador Anteproyectos

dirigidos

Coordinador 28/12/2015 12/01/2016

Docente Docente

16 Coordinador Solicitud de Revisión de Anteproyecto

Coordinador 28/12/2015 12/01/2016

17 Coordinador Registrar revisor Coordinador 28/12/2015 12/01/2016

18 Docente Anteproyectos

asignados para revisión

Docente 28/12/2015 12/01/2016

Coordinador Coordinador

19 Coordinador

Consultar Anteproyecto (Anteproyectos dirigidos y Anteproyectos por proyecto curricular)

Coordinador 28/12/2015 12/01/2016

Tabla 16. Cronograma de desarrollo para la tercera iteración. Fuente: Autores

Cuarta iteración: Para la siguiente iteración, se llevan a cabo el desarrollo de

varias de las funcionalidades más importantes en la etapa de anteproyecto,

como el manejo de versiones del documento, consulta de anteproyectos y la


evaluación del mismo, lo que permitirá o no al anteproyecto pasar a la etapa de

proyecto o ser rechazado por parte del revisor.

En la tabla 17 se ven las tareas de la cuarta iteración, en la cual se

complementa la etapa de anteproyecto para registrar en el sistema el histórico,

las diferentes versiones del documento y como realiza la evaluación del

anteproyecto por parte del docente revisor.


aplica

Periodo Desarrollo


20 Docente

Consultar Anteproyecto (Anteproyectos dirigidos)

Docente 19/01/2016 25/01/2016

21 Coordinador Consultar histórico de

anteproyecto

Coordinador 19/01/2016 25/01/2016

Docente Docente

22 Coordinador Descargar versiones

de documento

Coordinador 19/01/2016 25/01/2016

Docente Docente

23 Coordinador Evaluación de

anteproyecto

Coordinador 19/01/2016 25/01/2016

Docente Docente

Tabla 17. Cronograma de desarrollo para la cuarta iteración. Fuente: Autores

Quinta iteración: En la siguiente iteración, se realiza la migración de las

funcionalidades para la siguiente etapa del trabajo, en la modalidad de

monografía, sin embargo la implementación de dicha funcionalidad se retrasa

un poco debido a que para el desarrollo de la misma, es necesario validar

completamente el correcto funcionamiento del sistema para la modalidad de

anteproyecto, debido a que la siguiente etapa comparte varias características

en su proceso.

Aquí se realizó la creación de todas las tablas de proyecto de grado.

En la tabla 18 se enseña el momento en el que se finalizó la etapa de

anteproyecto y se dio inició al desarrollo de la segunda etapa del trabajo de

grado.


aplica

Periodo Desarrollo


24 Estudiante Consultar Evaluación Estudiante 23/01/2016 25/01/2016


Anteproyecto

25 Estudiante Iniciar Proyecto de grado

Estudiante 23/01/2016 25/01/2016

26 Coordinador Proyectos por programa curricular

Coordinador 19/01/2016 25/01/2016

27 Coordinador

Proyectos dirigidos Coordinador

19/01/2016 25/01/2016 Docente Docente

28 Estudiante Proyectos por estudiante

Estudiante 19/01/2016 25/01/2016

Tabla 18. Cronograma de desarrollo para la quinta iteración. Fuente: Autores

Sexta iteración: En esta iteración se finaliza el desarrollo de las

funcionalidades de la etapa de proyecto, en base a las funcionalidades de la

etapa de anteproyecto, por lo cual su implementación fue un poco más sencilla

y rápida. Además se procede a realizar el desarrollo del inicio de la última

etapa del trabajo de grado: Informe final.

En esta iteración se crean las primeras tablas de informe final.

En la tabla 19 se observa el tiempo en el que se termina el desarrollo de la

etapa de proyecto y se inicia con la etapa de informe final.


aplica

Periodo Desarrollo


29

Coordinador

Consultar Proyecto

Coordinador

23/01/2016 3/02/2016 Docente Docente

Estudiante Estudiante

30 Estudiante Crear versiones del documento

Estudiante 26/01/2016 3/02/2016

31 Coordinador Solicitudes Revisión

de Proyecto

Coordinador 23/01/2016 3/02/2016

Docente Docente

32 Coordinador

Evaluación proyecto Coordinador

26/01/2016 3/02/2016 Docente Docente

33 Estudiante Consultar Evaluación del proyecto

Estudiante 26/01/2016 3/02/2016

34 Estudiante iniciar informe final Estudiante 26/01/2016 3/02/2016

Tabla 19. Cronograma de desarrollo para la sexta iteración. Fuente: Autores


Séptima iteración: En la siguiente etapa de desarrollo se realiza la

implementación de las funcionalidades necesarias para el Informe final, lo cual

permite la aparición de la figura de jurado de calificación, el cual se encargará

de suministrar al sistema el concepto final para el proyecto de grado.

Aquí se complementa la arquitectura de datos para la etapa informe final, por lo

cual se crean las tablas faltantes.

Para la séptima iteración se realiza el desarrollo completo y a fondo de la etapa

de informe final, en la cual tiene la mayoría de sus funcionalidades está

disponible únicamente para usuarios con el rol de docente y/o coordinador, sin

embargo, estas funcionalidades son muy parecidas a las de las anteriores

etapas, lo cual agilizó su implementación.


aplica

Periodo Desarrollo


35 Coordinador Asignar jurados (informe final)

Coordinador 4/02/2016 8/02/2016

36 Coordinador Informes finales sin

jurados asignados

Coordinador 4/02/2016 8/02/2016

Docente Docente

37 Coordinador Solicitudes de

Revisión de informe final

Coordinador 4/02/2016 8/02/2016

Docente Docente

38

Coordinador

Consultar Informes Finales

Coordinador

4/02/2016 8/02/2016 Docente Docente

Estudiante Estudiante

39 Coordinador Informes finales por

Programa Curricular

Coordinador 4/02/2016 8/02/2016

Docente Docente

40 Coordinador

Evaluar Informe Final Coordinador

4/02/2016 8/02/2016 Docente Docente

Tabla 20. Cronograma de desarrollo para la séptima iteración. Fuente: Autores

Octava iteración: En la próxima iteración se finaliza la implementación de la

etapa Informe final, permitiendo así completar el proceso que lleva a cabo un

proyecto de grado en el sistema.

En la tabla 21 se muestra como se terminaron de implementar las diferentes

funcionalidades para la etapa de final del trabajo de grado.



aplica

Periodo Desarrollo


41 Estudiante Consulta Evaluación Informe Final

Estudiante 9/02/2016 15/02/2016

42 Coordinador Informes finales

asignados para revisión

Coordinador 9/02/2016 15/02/2016

Docente Docente

43 Coordinador Informes finales

dirigidos

Coordinador 9/02/2016 15/02/2016

Docente Docente

44 Coordinador Informes finales por finalizar

Coordinador 9/02/2016 15/02/2016

45 Estudiante Informes finales por Estudiante

Estudiante 9/02/2016 15/02/2016

Tabla 21. Cronograma de desarrollo para la octava iteración. Fuente: Autores

Novena iteración: Una vez terminado la elaboración de las funcionalidades

para las etapas de anteproyecto, proyecto e informe final, se procede a realizar

la elaboración de los respectivos reportes del aplicativo, para ello se hace uso

de la herramienta libre Reportico, lo cual facilita el proceso, debido a que no

requiere de programación sino simplemente de implementación de la

herramienta, sin embargo, para el inicio de elaboración de los reportes, se

requiere de una previa capacitación en el uso de la herramienta y de su

empalme con el sistema.

En la tabla 22 se evidencia como se realizó el desarrollo del módulo de

reportes del sistema, ajustando cada uno de ellos, de acuerdo con los que

dispone el sistema original.


aplica

Periodo Desarrollo


46 Delegado Trabajos por programa curricular

Delegado 1/03/2016 8/03/2016

47

Delegado

Trabajos por temática de interés

Delegado

1/03/2016 8/03/2016 Coordinador Coordinador

Docente Docente

48

Delegado

Trabajos por docente

Delegado


Docente Docente


49

Delegado

Trabajos por temática de interés y docente

Delegado


Docente Docente

50 Delegado Temáticas de interés

por programa curricular

Delegado 1/03/2016 8/03/2016


51

Estudiante

Docentes por temática de interés

Estudiante

1/03/2016 8/03/2016 Delegado Delegado


Tabla 22. Cronograma de desarrollo para la novena iteración. Fuente: Autores

Décima iteración: Finalmente se plantea la iteración final para el proceso de

migración, completando los reportes del sistema, dichos reportes se dejaron

para el final, debido a que su dificultad era un poco mayor a los primeros.

En la tabla 23 se observa cómo se terminaron de implementar los reportes

faltantes.

No. Módulo Funcionalidad Rol que aplica Periodo Desarrollo


52

Delegado Nivel de aceptación por temática de interés

Delegado


Docente Docente

53

Delegado Facultad Nivel de participación

de docentes en trabajos de grado

Delegado Facultad


Docente Docente

54

Estudiante Cobertura de docentes por temáticas de interés

Estudiante

8/03/2016 15/03/2016 Delegado Delegado

Docente Docente

Tabla 23. Cronograma de desarrollo para la décima iteración. Fuente: Autores

9.1.4.2. Cierre de iteración

Para el proceso de cierre de iteración, se realizó una reunión semanal con la

líder de desarrollo y posteriormente con la directora externa de la pasantía, con


el fin de llevar a cabo un control de lo realizado en la iteración y planear la

siguiente.

Con la líder de desarrollo, la reunión tenía como finalidad la planeación de la

siguiente iteración y, en caso de ser necesario, resolver alguna duda respecto

al uso del framework para la elaboración de las funcionalidades. El resultado de

esta reunión era comunicar los requerimientos y al final determinar las

funcionalidades a migrar en la siguiente iteración.

En la reunión con la directora externa, se realizaba una entrega de las

funcionalidades migradas, con el fin de que ella realizara unas primeras

pruebas funcionales y si era necesario, consultas sobre el funcionamiento de

UDLearn, para tenerlo claro al momento de realizar la migración. El resultado

de esta reunión, era un primer documento con el control de cambios requerido

para las funcionalidades desarrolladas en la iteración.

9.1.4.3. Bloc de Notas de la Arquitectura

En el bloc de notas de arquitectura se registraron los cambios que se realizaron

sobre la arquitectura de datos planteada por UDLearn, debido a que algunas de

las tablas se deben reemplazar por las que maneja el propio framework SARA

y otras no se implementaron porque se identificó que eran necesarias para la

implementación del módulo. Debido a que la migración y cambios sobre la

arquitectura se realizaron de acuerdo con la iteración, las notas allí registradas

se presentan casi que semanalmente.

9.1.4.4. Código Fuente

El manejo del código fuente se realizó de manera colaborativa y el avance fue

de manera iterativa, por lo cual se hizo necesario implementar una herramienta

para el control de versiones, por política de la OAS, esta herramienta fue

GitHub. Se creó el repositorio sobre la cuenta de universidad como master, se

subió la primera versión estable y después cada desarrollador creó su propia

rama, para desde allí realizar el desarrollo de las funcionalidades asignadas,

posteriormente al validar que el código de cada rama era estable y funcionaba

de manera correcta, se unifica todo el código en la rama “master”.

Dicho repositorio con el código fuente se encuentra disponible de manera

pública en la siguiente dirección: https://github.com/udistrital/polux_desarrollo.

9.1.4.5. Control de Cambios

https://github.com/udistrital/polux_desarrollo


El proceso de control de cambios se realizó a varios niveles, inicialmente al

terminar la iteración, se realizaba la entrega de las funcionalidades elaboradas

en el servidor de desarrollo, para que ella realizara unas pruebas sencillas y no

muy elaboradas del sistema y así poder determinar los errores encontrados y

después solucionarlos, las fallas encontradas en estas primeras pruebas se

pueden categorizar de la siguiente manera:

Validación de campos: En algunos formularios hacía falta validar que

los campos sólo permitieran ingresar números, o una cantidad de

caracteres mínima y en caso de ser necesario, que el campo ingresado

fuese un correo electrónico.

Errores de ortografía en mensajes de éxito o error: En algunos

casos, a los mensajes de información le hicieron faltar tildes, o algún

carácter.

Mensajes de validación de registro en la Base de datos: Mientras

cargaban algunas funcionalidades, se podía observar datos de las

variables internas del aplicativo, usadas para en el proceso de desarrollo

de la funcionalidad.

Falta de mensajes de confirmación al realizar registros: Al llenar y

enviar información a través de formularios, no aparecían mensajes de

confirmación de si se quería o no continuar con el registro.

No especificación del porqué del error al realizar un registro: En

algunos casos, después de enviar la información para realizar un

registro, aparecía un mensaje de error, pero no se especificaba el

porqué del mismo.

Para solucionar los errores encontrados, se optó por asignarlos de acuerdo a la

funcionalidad donde se presentaron y en consecuencia, al desarrollador de la

misma, esto con el fin de agilizar el desarrollo de la solución.

Para llevar a cabo el control de cambios, se decidió, desde un comienzo,

dejarlo para el final de la migración, siempre y cuando los errores encontrados

no causarán fallas en el funcionamiento del sistema o dificultara el proceso de

las demás funcionalidades.

Por otra parte, se realizó un segundo control de cambios, al entregar el

producto final y que este pasara a pruebas, las cuales se realizan por personal

interno de la Oficina. Los errores allí encontrados fueron mínimos, gracias a

que ya se habían realizado unas pruebas lo suficientemente completas, antes

de realizar la entrega del aplicativo.


Los pocos errores encontrados, se debieron a fallas por cambios al servidor de

pruebas, tanto del código fuente, como de la base de datos, sin embargo la

solución fue más sencilla.

9.1.5. ARQUITECTURA DE DATOS

Para el proceso de definición de la arquitectura de datos, se partió del hecho de

que la aplicación original (UDLearn) ya tenía definida su propia arquitectura, sin

embargo, como dicha arquitectura establecía la gestión de usuarios y por su

parte, el framework SARA también lo hace, se hizo necesario definir una nueva

arquitectura de datos, combinando lo que establece el framework y lo que se

necesitaba del aplicativo original.

Se había planteado inicialmente realizar la migración completa de toda la base

de datos de UDLearn, antes de comenzar a realizar la migración del código con

el framework SARA, pero dada la complejidad del modelo y teniendo en cuenta

que UDLearn los módulos de Rendimiento académico y Prácticas académicas

de UDLearn no se debían migrar, se decidió ir creando las tablas del modelo de

datos según como se fueran necesitando a medida que se avanzaba de forma

iterativa e incremental en el desarrollo de las funcionalidades contempladas en

cada iteración del proceso.

De igual forma al crear las tablas que se iban necesitando en el desarrollo, se

fueron eliminando los campos que no eran necesarios o que tenían relación

con las tablas de alguno de los módulos que no fueron migrados. Por ejemplo,

para el caso de la tabla de anteproyecto ANT_TANTP, se elimina el campo

ANTP_PROP, que identificaba la propuesta que tenía relación con el

anteproyecto, campo que ya no era necesario debido a que la migración que se

estaba realizando no contemplaba la etapa de propuesta, la cual ni siquiera

estaba incluida en UDLearn, sino que hacía parte del sistema propuesto

SGPG-UD, del cual se basa gran parte del código del sistema UDLearn.

Otros campos eliminados corresponden a las relaciones de las tablas con los

formularios pertenecientes a la aplicación.

Dado que el framework SARA tiene un módulo para la gestión de usuarios con

su propia estructura de datos para el manejo de sesiones y del menú de

acuerdo a los roles de usuario, se eliminan las tablas que constituían el módulo

de autenticación de usuarios en UDLearn (ver Tabla 24) y se acopla la

arquitectura del framework al resto del modelo del sistema UDLearn.


Tabla Descripción

aut_tsurl Tabla que almacena las rutas únicas de localización (URL) de las páginas pertenecientes al SGPG-UD así como su relación con el servicio al que pertenece y si es un archivo de tipo primario o secundario.

aut_tsrol Tabla que relaciona los servicios prestados en el sistema con los roles de usuario que pueden acceder a ellos.

aut_trol Tabla que almacena los roles que pueden desempeñar los usuarios dentro del Sistema de Gestión de Proyectos de Grado de la Universidad Distrital (SGPG-UD)

aut_turol Tabla que relaciona los usuarios del SGPG-UD con los roles establecidos en él

aut_tusua Tabla que almacena el nombre de Usuario y clave que controla el acceso al sistema

aut_tservicio Tabla que almacena los servicios prestados dentro del SGPG-UD, así como los módulos a los que pertenecen

aut_tmodulo Módulos del sistema

Tabla 24. Tablas eliminadas del modelo de datos de UDLearn Fuente: Autores

El modelo de datos de autenticación de usuarios de UDLearn (Figura 8), pasa a

ser reemplazado por el modelo de gestión de usuarios de Pólux (Figura 9). Las

tablas de los tipos de usuarios existentes (estudiantes, docentes, delegados),

que iban relacionados con la tabla aut_tusua, se relacionan ahora con la tabla

polux_usuario del esquema public.


Figura 8. Modelo relacional de autenticación en UDLearn.

Fuente: Autores

Figura 9. Modelo relacional de la Gestión de usuarios en Pólux. Fuente: Autores

La arquitectura completa del sistema Pólux, obtenido después de haber

realizado el análisis explicado anteriormente, es el siguiente:

9.1.5.1. PUBLIC


En este esquema se encuentran las tablas que se utilizan por el framework

SARA para realizar el manejo de páginas, manejo de usuarios,

implementación del menú y almacenamiento del logger del sistema. En

estas tablas se almacenan, entre otras cosas, las páginas del sistema, los

bloques que tienen asociadas dichas páginas, los enlaces que apuntan a

estas páginas, los menús que tienen esos enlaces y los usuarios que de

acuerdo a determinados roles, tienen acceso a los mismos.

Figura 10. Esquema public de la base de datos del Sistema de Gestión Académica Pólux. Fuente: Autores

9.1.5.2. GENERAL

Aquí se encuentran las tablas con los datos más generales que maneja el

sistema para el registro y almacenamiento de los proyectos de monografía,

aquí se encuentran relacionados los docentes con las temáticas de interés, los

estudiantes, docentes, tipo de vinculación de los docentes, programas

curriculares y las facultades a las cuales pertenecen. La mayoría de la


información aquí almacenada, se podría en un futuro obtener directamente de

las base de datos que maneja la universidad para ello.

Figura 11. Tablas generales de la base de datos del Sistema de Gestión Académica Pólux. Fuente: Autores

9.1.5.3. ANTEPROYECTO

En esta parte de la base de datos, se encuentran todas las tablas que se

utilizan en el sistema para realizar el registro, almacenamiento y consulta de

toda la información relacionada con la etapa de anteproyecto. Aquí se registran

toda la información de registro del anteproyecto, además su relación con los

estudiantes, profesor director, profesor revisor, la evaluación del anteproyecto,

las versiones del documento y las temáticas con las cuales se relaciona.


Figura 12. Tablas para anteproyecto de la base de datos del Sistema de

Gestión Académica Pólux. Fuente: Autores

9.1.5.4. PROYECTO

Aquí se almacena toda la información cuando un anteproyecto cambia de

etapa a proyecto y al igual que en la anterior etapa, almacena, entre otras

cosas, la información respecto a la revisión del documento y las versiones

del mismo.


Figura 13. Tablas para proyecto de la base de datos del Sistema de Gestión

Académica Pólux Fuente: Autores

9.1.5.5. INFORME FINAL

Aquí se almacena la información del informe final, pero a diferencia de las

etapas anteriores, se almacena la información relacionada con el jurado del

proyecto.


Figura 14. Tablas para informe final de la base de datos del Sistema de Gestión

Académica Pólux Fuente: Autores

9.2. FASE DOS: ANÁLISIS Y DISEÑO DE LAS DEMÁS MODALIDADES

9.2.1. Listado maestro de requerimientos

Figura 15. Pasos para elaboración del listado maestro de requerimientos.



Para realizar la identificación de requerimientos fue necesario, realizar

inicialmente, un análisis detallado del Acuerdo 038 de 2015 (Universidad

Distrital Francisco José de Caldas, 2015), con el cual, se obtuvo una idea

general del modelo de negocio. Después de esto surgieron varias dudas por lo

cual se realizaron reuniones con el gestor del proyecto, quien, cuando le era

posible, las resolvía y cuando no estaba seguro de la respuesta, registraba las

dudas y las comunicaba directamente al cliente final, quien indicaba qué hacer

en dichos casos. También se realizaron consultas con personal interno de la

Oficina, quienes indican cómo está funcionando el proceso actualmente y cómo

debe funcionar. A partir de esto se realizó el modelo de negocio para cada

modalidad, con ayuda de la notación BPMN. Estos diagramas fueron revisados

y aprobados por el director del proyecto y se dio vía libre para dar un primer

acercamiento a los requerimientos, los cuales son documentados pero no

detallados, debido a que no hace parte de los alcances del proyecto. Los

requerimientos identificados se muestran en la tabla 25.

Módulo Descripción del requerimiento

Espacios Académicos de

Posgrado

Debe permitir realizar la publicación de los espacios académicos elegibles por los estudiantes.

Debe permitir realizar solicitud de la modalidad de grado espacios académicos de posgrado.

Debe permitir aprobar la solicitud de modalidad de espacios académicos de posgrado.

Debe registrar la solicitud para cursar los espacios académicos de posgrado, de acuerdo a los espacios elegibles publicados.

Debe permitir elegir dentro de los estudiantes postulados a aquellos que han sido admitidos para realizar la modalidad de grado.

Debe permitir al estudiante formalizar inscripción de la modalidad de grado.

Debe permitir consultar los espacios académicos cursados y aprobados por el estudiante.

Espacios Académicos de Profundización

Debe permitir realizar la publicación de los espacios académicos elegibles por los estudiantes.

Debe permitir realizar solicitud de la modalidad de grado espacios académicos de profundización.

Debe permitir aprobar la solicitud de modalidad de espacios académicos de profundización.

Debe registrar la solicitud para cursar los espacios académicos de profundización, de acuerdo a los espacios elegibles publicados.

Debe permitir elegir dentro de los estudiantes postulados a aquellos que han sido admitidos para realizar la modalidad de grado.


Debe permitir al estudiante formalizar inscripción de la modalidad de grado.

Debe permitir consultar los espacios académicos cursados y aprobados por el estudiante.

Producción Académica

Debe permitir registrar en el sistema las revistas indexadas en las cuales se realice la publicación de un artículo.

Debe admitir realizar modificaciones sobre un registro de revista, en caso de que esta cambie de categoría o desaparezca.

Debe permitir registrar propuestas de publicación y asociarlas a estudiantes.

Debe ser posible realizar modificaciones en la propuesta, en caso de ser necesario.

Debe permitir que el estudiante realice registros sobre nuevas versiones del documento de la propuesta.

Debe posibilitar realizar búsquedas de propuestas por programa curricular, revista, estudiante y categoría.

Debe permitir registrar evidencia de publicación.

Debe permitir consultar las evidencias de publicación.

Debe permitirle al docente, consultar las propuestas de publicación que dirige.

Innovación e Investigación

Debe permitir verificar vinculación de un grupo de investigación.

Debe permitir realizar gestión sobre un Plan de actividades (Registro, Modificación y Cancelación).

Debe permitir al estudiante realizar un nuevo registro del documento del plan de actividades (Nueva versión).

Debe permitir consultar plan de actividades de investigación.

Debe permitir al estudiante, solicitar revisor del plan de actividades de investigación.

Debe permitir al coordinador del proyecto asignar revisor a un plan de actividades en específico.

Debe permitir consultar solicitudes de revisión para un plan de actividades.

Debe permitir al revisor del plan de actividades realizar la evaluación del mismo.

Debe posibilitar realizar la consulta de la evaluación de un plan de actividades.

Debe permitir registrar informe de actividades de investigación.

Debe admitir que el estudiante pueda registrar una nueva versión del informe final de actividades de investigación.

Debe permitir consultar informe de actividades.


Debe permitir al estudiante solicitar revisión del informe de actividades.

Debe permitir que el coordinador consulte las solicitudes de revisión de un informe de actividades.

Debe permitir evaluar el informe de actividades.

Debe permitir consultar la evaluación de un informe de actividades.

Tabla 25. Listado requerimientos funcionales Fuente: Autores

9.2.2. Requerimientos no funcionales

Tipo de requerimiento Descripción

Auditoría Al realizar alguna transacción, se debe dejar un histórico o un log que indique la acción realizada, quien la realizó, la fecha y la hora del mismo.

Seguridad Se debe garantizar que la información sensible para la Universidad se maneja de una manera que se pueda garantizar su veracidad y respectiva confidencialidad.

Desempeño

Para el desempeño de los nuevos módulos se debe garantizar un buen desempeño, de acuerdo a las siguientes métricas.

Métrica Funcionalidad

Registros procesados

La cantidad de registros consultados para un reporte debe ser equivalente a los requeridos.

Tiempo de respuesta

El tiempo de respuesta debe ser consecuente con la cantidad de registros solicitados, sin embargo, las consultas de pocos registros no debe superar los 7 segundos.

Almacenamiento de información

La información manejada por cada módulo debe guardarse en el tiempo para permitir a los usuarios del sistema, generar reportes y realizar consultas de manera que los datos obtenidos sean lo más completos posibles.

Usabilidad

Los nuevos módulos deben presentar una interfaz amigable con el usuario, con mensajes que ayuden al usuario a navegar por el sistema, además los nuevos módulos deben manejar la misma interfaz que el existente, para mostrar un sistema más compacto.

Tabla 26. Listado requerimientos no funcionales Fuente: Autores

9.2.3. Glosario

Área de dominio (Módulo) Término Definición


General

Pólux

Es el nombre con el cual se bautizó el sistema para la gestión de trabajos de grado, dicho nombre fue otorgado al interior de la Oficina Asesora de Sistemas.

Docente director

Todo Trabajo de Grado deberá tener un director, quien será un Docente de Planta de la Universidad, con idoneidad en el área o será asignado por el Consejo Curricular o quien haga sus veces. El Docente Director debe avalar la propuesta en la modalidad definida por el estudiante, efectuar el seguimiento al Trabajo de grado de acuerdo con la modalidad correspondiente, reportar las notas finales a la Coordinación del Proyecto Curricular respectivo y vigilar el cumplimiento del Acuerdo 004 de 2012 por el cual el CSU expide el Estatuto de Propiedad Intelectual.

Evaluador

EI Consejo Curricular o quien haga sus veces, asignará evaluador(es) a los trabajos de grado a excepción de las modalidades de Espacios Académicos de Posgrado, Espacios Académicos de Profundización y Producción Académica. Como función deberá realizar la evaluación pertinente de los trabajos de grado cuando se consideren finalizados.

Acta de Sustentación

El Director y Evaluador(es) firmarán un Acta de sustentación del trabajo de grado, en la que registrarán la calificación, e informarán al estudiante que hizo la presentación pública sobre la calificación obtenida. El Consejo Curricular procederá a asignar dicha nota al trabajo de grado.


Posgrado

Espacios académicos

Los espacios académicos son Asignaturas, Cátedras y Grupos de Trabajo que en conjunto, configuran los Planes de Estudio. Cada espacio académico considera los contenidos ya sean disciplinares, Interdisciplinares o transdisciplinares y las orientaciones para su enseñanza y aprendizaje y constituyen los Programas de Formación, en este caso se refiere a aquellas que se dictan en las maestrías o especializaciones.

Créditos

Se entiende por crédito académico la unidad que mide la actividad académica del estudiante y que valora equilibradamente los siguientes elementos:


a) Número de horas de trabajo académico. b) Grado de dificultad del trabajo exigido. c) Importancia en el plan de estudios.

Espacios Académicos de Profundización

Espacios académicos

Los espacios académicos son Asignaturas, Cátedras y Grupos de Trabajo que en conjunto, configuran los Planes de Estudio. Cada espacio académico considera los contenidos ya sean disciplinares, interdisciplinares o transdisciplinares y las orientaciones para su enseñanza y aprendizaje y constituyen los Programas de Formación, en este caso, se refiere específicamente a las materias que hacen parte de las líneas de profundización de la carrera profesional.

Créditos

Se entiende por crédito académico la unidad que mide la actividad académica del estudiante y que valora equilibradamente los siguientes elementos: a) Número de horas de trabajo académico. b) Grado de dificultad del trabajo exigido. c) Importancia en el plan de estudios.

Ciclo propedéutico

Los ciclos son unidades interdependientes, complementarias y secuenciales; mientras que el componente propedéutico hace referencia al proceso por el cual se prepara a una persona para continuar en el proceso de formación a lo largo de la vida, en este caso particular, en el pregrado.

Producción Académica

Estructura de investigación

Son entidades reconocidas por algún ente estatal o departamental, en la cual un conjunto de personas se reúnen para realizar investigación científica en una temática dada, formulan uno o varios problemas de su interés, trazan y formalizan un plan estratégico de largo plazo para trabajar en él y producen unos resultados de conocimiento sobre el tema en cuestión.

Informe de actividades de investigación

El informe de Actividades da cuenta de la aplicación de los diferentes conocimientos adquiridos a lo largo de la carrera que son aplicados al momento de elaboración de un artículo de investigación.

Innovación e

Investigación

Revista indexada

La revista indexada es una publicación periódica de investigación que denota alta calidad y ha sido listada en alguna base de datos de consulta mundial, lo que habitualmente trae aparejado que la revista tenga un elevado factor de impacto.


Estructura de investigación

Son entidades reconocidas por algún ente estatal o departamental, en la cual un conjunto de personas se reúnen para realizar investigación científica en una temática dada, formulan uno o varios problemas de su interés, trazan y formalizan un plan estratégico de largo plazo para trabajar en él y producen unos resultados de conocimiento sobre el tema en cuestión.

Tabla 27. Glosario Fuente: Autores

9.2.4. Plan general del proyecto

Una vez terminado el proceso de migración del aplicativo, se realizó un nuevo

plan de iteración, con el fin realizar el análisis para las modalidades de

Espacios Académicos de Posgrado, Espacios Académicos de Profundización,

Innovación e Investigación y finalmente, Producción Académica, esto con el fin

de estandarizar los módulos del sistema, para cuando estos sean

desarrollados, además que establecerá una plantilla para el análisis de las

demás modalidades faltantes, que se encuentran descritas en el Acuerdo No.

38 (Universidad Distrital Francisco José de Caldas, 2015).

9.2.4.1. Plan de iteraciones para el análisis

Las nuevas iteraciones también se establecen por semana, en esta ocasión,

dichas iteraciones son establecidas en consenso, con los analistas y personal

encargado por la Oficina. Para esto, se tomó en cuenta que se debían realizar

4 diferentes diagramas para 4 modalidades de grado, por lo cual, se optó, por

realizar en cada iteración, la elaboración del mismo diagrama para todas las

modalidades de grado. Además, al finalizar cada iteración, se dejaba un día

para realizar la revisión sobre los diagramas y en caso de ser necesario,

realizar algunos ajustes.

Primera iteración: Para la primera iteración, se decidió realizar los modelos

BPMN, esto con el fin de entender más claramente el modelo del negocio y así,

tener una mayor claridad a la hora de realizar los diagramas posteriores. Es

importante resaltar, que en esta primera iteración, se pudo dimensionar las

similitudes entres las modalidades de Espacios Académicos de Posgrado y

Espacios Académicos de Profundización, así como entre la modalidad de

Innovación-Investigación, con la de Monografía; esto permitió acelerar un poco

el proceso de análisis.


En la tabla 28 se evidencian las actividades realizadas para la primera iteración

en la fase de análisis en la cual se realizaron los modelos de proceso de

negocio (BPMN) de las modalidades de grado seleccionadas.

No. Actividad Periodo


1 Modelo BPMN de modalidad Espacios Académicos de Posgrado

17/02/2016 22/02/2016

2 Modelo BPMN de modalidad Espacios Académicos de Profundización

17/02/2016 22/02/2016

3 Modelo BPMN de modalidad Producción Académica

17/02/2016 22/02/2016

4 Modelo BPMN de modalidad Innovación-Investigación

17/02/2016 22/02/2016

Tabla 28. Cronograma de análisis, primera iteración. Fuente: Autores

Segunda iteración: Para la elaboración de los diagramas de casos de uso, se

toma en cuenta, únicamente, las funcionalidades que cumpliría el aplicativo,

debido, a que hay varios procesos que se realizan de manera presencial y no

ingresan al sistema, hasta que se autoriza por parte del Consejo de carrera del

programa curricular.

En la tabla 28 se muestran las actividades de la segunda iteración en la cual se

realizaron las propuestas de los diagramas de caso uso de cada uno de las

modalidades.



5 Diagramas de casos de uso (Propuesta) Espacios Académicos de Posgrado

24/02/2016 29/02/2016

6 Diagramas de casos de uso (Propuesta) Espacios Académicos de Profundización

24/02/2016 29/02/2016

7 Diagramas de casos de uso (Propuesta) Producción Académica

24/02/2016 29/02/2016

8 Diagramas de casos de uso (Propuesta) Innovación-Investigación

24/02/2016 29/02/2016

Tabla 29. Cronograma de análisis, segunda iteración. Fuente: Autores


Tercera iteración: En la tercera iteración, se plantea la elaboración de los

diagramas de actividades, para ello, se parte de los diagramas de casos de

uso, por lo cual, se hizo necesario, verificar que estos estaban completos.

En la tabla 30 se presentan las actividades desarrolladas para la tercera

iteración en la cual se completaron las propuestas de los diferentes diagramas

de actividades para cada modalidad.



9 Diagramas de actividades (Propuesta) Espacios Académicos de Posgrado

2/03/2016 7/03/2016

10 Diagramas de actividades (Propuesta) Innovación-Investigación

2/03/2016 7/03/2016

11 Diagramas de actividades (Propuesta) Producción Académica

2/03/2016 7/03/2016

12 Diagramas de actividades (Propuesta) Espacios Académicos de Profundización

2/03/2016 7/03/2016

Tabla 30. Cronograma de análisis, tercera iteración. Fuente: Autores

Cuarta iteración: Finalmente ya teniendo claro el modelo de negocio y el

funcionamiento de cada una de las modalidades seleccionadas, se procede a

elaborar los diagramas de secuencia en los cuales se especifica el proceso que

se sigue en el sistema para cada modalidad.

En la tabla 31 se observan las actividades de la última iteración de la fase de

análisis, aquí se realizó la elaboración de los diagramas de secuencia.



13 Diagramas de secuencia (Propuesta) Espacios Académicos de Posgrado

9/03/2016 14/03/2016

14 Diagramas de secuencia (Propuesta) Innovación-Investigación

9/03/2016 14/03/2016

15 Diagramas de secuencia (Propuesta) Producción Académica

9/03/2016 14/03/2016

16 Diagramas de secuencia (Propuesta) Espacios Académicos de Profundización

9/03/2016 14/03/2016

Tabla 31. Cronograma de análisis, cuarta iteración. Fuente: Autores


9.2.4.2. Cierre de iteración

En el proceso de cierre de iteración, se realizaba una reunión con el revisor,

encargado por la Oficina, con el cual se revisaban los diagramas resultado, de

la semana.

La elaboración de cada diagrama se hacía conforme al Acuerdo 38, sin

embargo, como el acuerdo no estipula algunos flujos alternos, fue necesario,

realizar comunicaciones con las secretarías de los proyectos curriculares de

Ingeniería, con el fin de verificar, que realizar en dichos casos.

9.2.5. Módulos propuestos

Como se mencionó anteriormente, los módulos propuestos para el desarrollo

de la siguiente versión del aplicativo se obtuvieron de las modalidades de grado

descritas en el Acuerdo 38; las modalidades seleccionadas son: Espacios

Académicos de Posgrado, Espacios Académicos de Profundización,

Producción Académica e Innovación-Investigación.

Figura 16. Modalidades seleccionadas.

Fuente: Autores

Para abordar el análisis de las modalidades mencionadas, se partió del hecho

de que entre ellas comparten varias características por ejemplo: Espacios

Académicos de Posgrado y de Profundización son esencialmente igual, con la

diferencia de que espacios académicos de posgrado aplica para carreras

profesionales, mientras que los de profundización, aplican es para carreras

tecnológicas y en esta modalidad se establece que si el estudiante continúa

con la carrera profesional, no podrá ver las materias de profundización que vio

para graduarse como tecnólogo.


También se identificó, que Innovación-Investigación es básicamente igual a la

modalidad de monografía (La cual se migró para el proyecto, UDLearn al nuevo

sistema, Pólux), con la diferencia, que para la Innovación-Investigación se

requiere que el estudiante se encuentre vinculado a una estructura de

investigación, por lo cual, el proyecto será desarrollado en conjunto entre el

estudiante y la estructura de investigación, la cual por medio de un docente

(designado como docente director) guiará al o los estudiantes en el desarrollo

de la modalidad.

9.2.5.1. Actores

En la figura 17 se muestran los roles que se describen en el acuerdo para las

diferentes modalidades.

Figura 17. Actores que participan en las modalidades. Fuente: Autores

9.2.5.2. Módulo para Espacios Académicos de Posgrado

La Universidad Distrital ofrece como modalidad de trabajo de grado para las

carreras profesionales, cursar y aprobar créditos pertenecientes a espacios

académicos de carreras de posgrado, maestría o especialización propias de la


Universidad, para ello el estudiante debe cumplir con una serie de requisitos,

los cuales implican que el estudiante esté próximo a terminar la carrera y tenga

un promedio alto; dentro de esta modalidad, cada programa de posgrado tiene

la opción de ofertar los espacios académicos de su preferencia para que sean

cursados por los estudiantes de pregrado que sean admitidos a esta modalidad

de trabajo de grado, el proyecto curricular de posgrado establecerá un máximo

de hasta diez (10) cupos, los cuales se otorgarán de acuerdo al promedio

ponderado de los estudiantes. Una vez el estudiante es admitido para cursar

las materias de posgrado, este debe aprobar con una calificación mayor a 3.0

cada una de los espacios académicos seleccionados. Después de terminado el

periodo académico, la coordinación del posgrado será la encargada de reportar

las notas del estudiante al pregrado correspondiente para que estas sean

digitalizadas en el sistema de gestión académico, luego se procede a calcular

el promedio de las materias cursadas, el cual debe ser mayor a 3.5 para que la

modalidad sea válida como trabajo de grado y así el estudiante pueda terminar

su carrera. En la figura 18 se representa el flujo de los procesos involucrados

en esta modalidad de grado, mediante el modelamiento BPMN.

9.2.5.2.1. Modelo BPMN

En las figuras 18 y 19 se detalla el modelo BPMN para la modalidad de

Espacios Académicos de Posgrado, sin embargo, si no se logra detallar con la

suficiente claridad, puede consultar la imagen completa y de alta calidad en el

CD de los anexos.

Figura 18. Primera parte del modelo BPMN de Espacios Académicos de

Posgrado.


Figura 19. Segunda parte del modelo BPMN de Espacios Académicos de

Posgrado. Fuente: Autores

9.2.5.2.2. Diagrama casos de uso

En la figura 20, se muestran los casos de uso generados para la modalidad de

Espacios Académicos de Posgrado, además se muestran los roles de usuario

que tienen acceso a dichos casos de uso, sin embargo, si no se logra detallar

con la suficiente claridad, puede consultar la imagen completa y de alta calidad

en el CD de los anexos.


Figura 20. Casos de Uso Modalidad Espacios Académicos de Posgrado. Fuente: Autores

9.2.5.3. Módulo para Espacios académicos de Profundización

Esta modalidad es similar a la de espacios académicos de profundización, la

diferencia radica en que no se aplica a carreras de pregrado, sino a programas

académicos de nivel tecnológico y las materias que ve el estudiante pertenecen

a programas de nivel profesional, no de posgrado. Por otra parte, no se tiene

en cuenta como requisito el promedio académico ponderado del estudiante.


El flujo de los procesos que componen esta modalidad de grado se representa

en las figuras 21 y 22, sin embargo, si no se logra detallar con la suficiente

claridad, puede consultar la imagen completa y de alta calidad en el CD de los

anexos.


Figura 21. Primera parte del modelo BPMN de Espacios Académicos de

Profundización.

Figura 22. Segunda parte del modelo BPMN de Espacios Académicos de Profundización.



En la figura 23 se muestran los casos de uso generados para la modalidad de

Espacios Académicos de Profundización, sin embargo, si no se logra detallar

con la suficiente claridad, puede consultar la imagen completa y de alta calidad

en el CD de los anexos.

Figura 23. Casos de Uso Modalidad espacios académicos de profundización. Fuente: Autores

9.2.5.4. Módulo para Producción Académica

Para esta modalidad, el estudiante debe elaborar un artículo científico y

conseguir que este sea publicado en una revista indexada, para ello, el

estudiante en conjunto con un docente que pertenezca a alguna estructura de

investigación, elaborará y presentará una propuesta de publicación

(anteproyecto) en la que se explique claramente las características del artículo


que se desea realizar, una vez la propuesta de publicación sea aprobada, el

estudiante, en cualquier momento, podrá presentar una constancia o certificado

de que el artículo fue publicado y a partir de esto se generará la nota final.


En las figuras 24 y 25 se detalla el modelo BPMN elaborado para la modalidad

de Producción Académica, sin embargo, si no se logra detallar con la suficiente


anexos.

Figura 24. Primera parte del modelo BPMN de Producción Académica.


Figura 25. Segunda parte del modelo BPMN para la modalidad de Producción Académica.

Fuente: Autores


En las figuras 26 y 27, se detallan los casos de uso generados para la

modalidad de Producción Académica, sin embargo, si no se logra detallar con

la suficiente claridad, puede consultar la imagen completa y de alta calidad en

el CD de los anexos.


Figura 26. Casos de uso para administrar revistas para el módulo de

Producción Académica. Fuente: Autores

uc Administrar rev istas

Administrar revistas

Directiv o proyecto

curricular

CUPA01 Registrar

rev ista

CUPA02 Modificar

registro rev ista

CUPA03 Consultar

rev ista


Figura 27. Casos de uso para el sub-módulo de registro y consulta de

propuesta de publicación. Fuente: Autores

9.2.5.5. Módulo para Innovación-Investigación

Como se había mencionado anteriormente las características de la modalidad

de Innovación-Investigación son muy parecidas a la modalidad de Monografía,

por lo cual, el proceso de análisis resultó ser un poco más sencillo, al igual que

en la modalidad de Monografía el estudiante debe presentar una propuesta del

trabajo que va a realizar, con la diferencia que en esta modalidad, los temas a

desarrollar a lo largo del trabajo, están determinados por la estructura de

investigación a la cual pertenece el estudiante, además, esta estructura en la

que se encarga de suministrar el docente director para el trabajo; sin embargo,

para el sistema, el proceso que sufre un trabajo de esta modalidad es

equivalente a monografía, debido a que dicho trabajo cuenta con las mismas 3

etapas: anteproyecto, proyecto e informe final.


uc Submódulo de registro y consulta de propuesta de publicación

Directiv o proyecto

curricular

(from

Actores)

Director de proyecto de

grado

(from

Actores)

Estudiante

(from

Actores)

CUPA04 Registrar

propuesta de

publicación

CUPA05 Modificar

propuesta de

publicación

CUPA06 Consultar

propuestas de

publicación por

programa curricular

CUPA07 Consultar

propuesta de

publicación

CUPA08 Registrar

nuev a v ersión de

propuesta de

publicación

CUPA09 Consultar

propuesta de

publicación por

estudiante

CUPA10 Registrar

articulo-ev idencia de

publicación

CUPA11 Consultar

articulo-ev idencia de

publicación

CUPA12 Consultar

articulos dirigidos


En las figuras 28, 29, 30 y 31 se detalla el modelo BPMN elaborado para la

modalidad de Innovación-Investigación, sin embargo, si no se logra detallar con

la suficiente claridad, puede consultar la imagen completa y de alta calidad en

el CD de los anexos.

Figura 28. Primera parte del modelo BPMN de Innovación-Investigación.

Figura 29. Segunda parte del modelo BPMN de Innovación-Investigación.


Figura 30. Tercera parte del modelo BPMN de Innovación-Investigación.

Figura 31. Parte final del modelo BPMN para la modalidad de Innovación-

Investigación. Fuente: Autores


Para la construcción de los diagramas de casos de uso de la modalidad de

Innovación-Investigación, se partió del hecho de que el proceso es similar al de

Monografía, por lo cual se decidió mantener las fases del proyecto de grado,

como lo son anteproyecto, proyecto e informe final, con el fin de estandarizar el

funcionamiento en el sistema y así facilitar su comprensión e implementación.

Teniendo en cuenta esto, se presentan los siguientes casos de uso para cada

fase.

9.2.5.5.2.1. General

En la figura 32 se observan los casos de uso generados para el sub-módulo

general de la modalidad de Innovación-Investigación, sin embargo, si no se


logra detallar con la suficiente claridad, puede consultar la imagen completa y

de alta calidad en el CD de los anexos.

Figura 32. Casos de uso generales para la modalidad de Innovación-Investigación.

Fuente: Autores

9.2.5.5.2.2. Fase inicial, anteproyecto

En las figuras 33 hasta la 35 se muestran los casos de uso establecidos para la

fase de anteproyecto, sin embargo, si no se logra detallar con la suficiente


anexos.

uc Sub-módulo general

Sub-módulo gestión de parámetros

Directiv o proyecto

curricular

Docente

Estudiante

CUIN01 Registrar

estructura de

inv estigación

CUIN02 Modificar

registro estructura

de inv estigación

CUIN03 Consultar

estructuras de

inv estigación

CUIN04 Crear

formulario

ev alución

CUIN05 Modificar

formulario de

ev aluación

CUIN06 Consultar

formulario de

ev aluación


Figura 33. Casos de uso para el Sub-módulo de registro y consulta del plan de

actividades para la fase de anteproyecto. Fuente: Autores

uc Sub-módulo de inicio y consulta anteproyectos

Sub-módulo de registro y consulta de Plan de actividades (Anteproyectos)

Directiv o proyecto

curricular

(from

Actores)

Estudiante

(from

Actores)

Director de proyecto de

grado

(from

Actores)

(from Módulo de Gestión

Innovación-investigación)

CUIN07 Registrar Plan de

activ idades

(Anteproyecto)



CUIN13 Consultar Plan de

activ idades

(Anteproyecto)




activ idades

(Anteproyectos) Por

Estudiante



CUIN08 Registrar nuev a

v ersión de documento de

Plan de activ idades

(Anteproyecto)




activ idades

(Anteproyectos)

Asignados para Rev isión




activ idades (Anteproyectos)

por proyecto curricular




activ idades

(Anteproyectos) Dirigidos

Rev isor de anteproyecto

(from

Actores)





sin rev isores asignados



CUIN14 Consultar

ev aluaciones de documento

de Plan de activ idades

(anteproyecto)



CUIN12 Consultar

Asignación de Rev isor a


«extend»

«extend»


Figura 34. Casos de uso para el Sub-módulo de asignación de revisores para el

plan de actividades en la fase de anteproyecto. Fuente: Autores

uc Sub-módulo de asignación de rev isores de anteproyecto

Sub-módulo de Asignación de Revisores de Plan de actividades (anteproyecto)

Directiv o proyecto

curricular

(from

Actores)

Docente

(from

Actores)

Estudiante

(from

Actores)



CUIN18 Asignar Rev isores

a Plan de activ idades

(Anteproyecto)



CUIN17 Crear Asignación

de Rev isor de Plan de

activ idades (Anteproyecto)



CUIN12 Consultar

Asignación de Rev isor a




CUIN19 Consultar

Solicitudes de Rev ision de


(Anteproyecto) Asignadas




activ idades

(Anteproyectos) sin

rev isores asignados

«include»


Figura 35. Casos de uso para el Sub-módulo de evaluación del plan de

actividades para la fase de anteproyecto. Fuente: Autores

9.2.5.5.2.3. Fase intermedia, proyecto

En las figuras 36 y 37 se muestran los casos de uso establecidos para la fase

de proyecto, en la modalidad de Innovación-Investigación, sin embargo, si no

se logra detallar con la suficiente claridad, puede consultar la imagen completa

y de alta calidad en el CD de los anexos.

uc Sub-módulo de ev aluación de anteproyectos

Sub-módulo de evaluación de Plan de actividades (anteproyectos)

Estudiante

(from

Actores)

Rev isor de anteproyecto

(from

Actores)



CUIN23 Ev aluar documento


(Anteproyecto)



CUIN24 Solicitar ev aluación

de documento de Plan de

activ idades (anteproyecto)



CUIN25 Crear Solicitud de

Ev aluación de Plan de

activ idades (Anteproyecto)



CUIN21 Consultar solicitud

de rev isión de Plan de




CUIN22 Solicitar

modificación de documento


(Anteproyecto)



CUIN20 Consulta de

solicitudes pendientes de

rev isión de Plan de






Asignados para Rev isión



CUIN14 Consultar

ev aluaciones de documento


(anteproyecto)



CUIN08 Registrar nuev a

v ersión de documento de


(Anteproyecto)

«extend»

«include»


Figura 36. Casos de uso para el Sub-módulo de inicio y consulta del plan de

actividades para la fase de proyecto. Fuente: Autores


Figura 37. Casos de uso para el Sub-módulo de evaluación del plan de

actividades para la fase de proyecto. Fuente: Autores

9.2.5.5.2.4. Fase final, Informe de actividades

En las figuras 38, 39 y 40 se establecen los casos de uso que hacen parte de la

fase informe final de actividades para la modalidad de Innovación-

Investigación, sin embargo, si no se logra detallar con la suficiente claridad,

puede consultar la imagen completa y de alta calidad en el CD de los anexos.


Figura 38. Casos de uso para el Sub-módulo de inicio y consulta del informe de

actividades, fase final del proyecto. Fuente: Autores


Figura 39. Casos de uso para el Sub-módulo de asignación de jurados al

informe de actividades, fase final del proyecto. Fuente: Autores


Figura 40. Casos de uso para el Sub-módulo de evaluación del informe de actividades, fase final del proyecto.

Fuente: Autores


CAPÍTULO 10. RESULTADOS Y DISCUSIÓN

Al finalizar el proyecto, se obtiene un sistema base para el manejo y gestión de

los proyectos de grado al interior de la Universidad Distrital, esto gracias a que

la arquitectura implementada es completamente compatible con la que se

maneja al interior de la misma. En la siguiente tabla se muestran las

actividades realizadas para cada objetivo planteado con el fin de obtener el

resultado deseado.

OBJETIVO ACTIVIDADES PORCENTAJE

DE CUMPLIMIENTO

Migrar el módulo de gestión de trabajos de grado en la modalidad de monografía perteneciente a la aplicación UDLearn, de Java a PHP, así como realizar la migración de la base de datos de Oracle a PostgreSQL para adaptarlo a la arquitectura manejada por la OAS, haciendo uso del framework SARA.

Capacitaciones diarias en el framework SARA con la líder de desarrollo de la OAS.

Análisis de las funcionalidades del aplicativo UDLearn.

Análisis de la arquitectura de datos de UDLearn.

Elaboración de listado de funcionalidades a migrar.

Reuniones con la líder de desarrollo y la persona que creó el aplicativo UDLearn con el fin de determinar las iteraciones.

Migración de arquitectura de datos.

Desarrollo del Sistema de Gestión de trabajos de grado Pólux, modulo de monografía.

Control de cambios en desarrollo con la líder del proyecto.

Control de cambios en pruebas con el encargado de la OAS.

100%

Representar los diferentes procesos y flujos de información para la modalidad de Espacios Académicos de Posgrado mediante notación de modelamiento de procesos de negocio BPMN y estándar UML con base en las normas establecidas en el acuerdo 038 de 2015.

Análisis de la modalidad Espacios Académicos de Posgrado de acuerdo con la normatividad.

Consulta sobre flujos alternos en el proceso de la modalidad, con los encargados por la Universidad.

Elaboración de propuesta de BPMN, revisión y control de cambios.

Se determinaron 11 casos de uso

100%


para la modalidad.

Elaboración de propuesta para Diagrama de casos de uso, revisión y control de cambios.

Elaboración de Diagrama de actividades y secuencia para especificar los 11 casos de uso determinados.

Representar los diferentes procesos y flujos de información para la modalidad de Investigación-Innovación mediante notación de modelamiento de procesos de negocio BPMN y estándar UML con base en las normas establecidas en el acuerdo 038 de 2015.

Análisis de la modalidad Investigación-Innovación de acuerdo con la normatividad.

Consulta sobre flujos alternos en el proceso de la modalidad, con los encargados por la Universidad.

Elaboración de propuesta de BPMN, revisión y control de cambios.

Se determinaron 65 casos de uso para la modalidad.

Elaboración de propuesta para Diagrama de casos de uso, revisión y control de cambios.

Elaboración de Diagrama de actividades y secuencia para especificar los casos de uso.

100%

Representar los diferentes procesos y flujos de información para la modalidad de Espacios Académicos de Profundización mediante notación de modelamiento de procesos de negocio BPMN y estándar UML con base en las normas establecidas en el acuerdo 038 de 2015

Análisis de la modalidad


Profundización de acuerdo con la

normatividad.

Consulta sobre flujos alternos en

el proceso de la modalidad, con

los encargados por la

Universidad.

Elaboración de propuesta de

BPMN, revisión y control de

cambios.


Elaboración de propuesta para

Diagrama de casos de uso,

revisión y control de cambios.

Elaboración de Diagrama de actividades y secuencia para especificar casos de uso.

100%


Representar los diferentes procesos y flujos de información para la modalidad de Producción Académica mediante notación de modelamiento de procesos de negocio BPMN y estándar UML con base en las normas establecidas en el acuerdo 038 de 2015.

Análisis de la modalidad

Producción Académica de

acuerdo con la normatividad.

Consulta sobre flujos alternos en

el proceso de la modalidad, con

los encargados por la

Universidad.

Elaboración de propuesta de

BPMN, revisión y control de

cambios.


Elaboración de propuesta para

Diagrama de casos de uso,

revisión y control de cambios.

Elaboración de Diagrama de actividades y secuencia para especificar casos de uso.

100%

Realizar la documentación técnica de la funcionalidad y proceso llevado a cabo en el desarrollo del software, con base en los requerimientos y en la arquitectura planteada en el proceso de desarrollo en curso, para orientar a posteriores desarrolladores en el complemento del sistema.

Elaboración de documentos de funcionalidades elaboradas.

Elaboración de manual de usuario para el aplicativo.

Elaboración diccionario de datos del sistema.

Comentarios en código fuente del sistema.

Versionamiento del aplicativo por medio del repositorio del sistema en GitHub.

100%

Tabla 32. Resultados Fuente: Autores


CAPÍTULO 11. TRABAJOS FUTUROS

El presente trabajo de grado genera nuevas líneas de trabajo que a futuro

permitirían generar mejoras en el sistema o crear funcionalidades adicionales

del mismo. Con el fin de dar continuidad al producto creado, se plantean las

siguientes alternativas de trabajo:

Extensión del sistema: Los diagramas realizados para las modalidades

de grado de Espacios Académicos de Posgrado, Espacios Académicos

de Profundización, Investigación-Innovación y Producción Académica,

serían de gran utilidad como punto de partida para el futuro desarrollo de

estas modalidades y su inclusión dentro del sistema final obtenido

mediante el desarrollo de este trabajo. Así mismo, es importante pensar

en la extensión de la aplicación hacia las modalidades de grado faltantes

contempladas en el acuerdo 038 de 2015.

Ajustes de modalidad monografía a lo estipulado en el acuerdo 038 de

2015: la modalidad migrada (monografía) no fue ajustada a lo que se

dictamina en el acuerdo 038, por lo cual, se hace necesario, hacer las

validaciones correspondientes para realizar el ajuste.

Gestión documental: Dada la importancia de toda la documentación

obtenida mediante los procesos de anteproyecto, proyecto e informe

final, es necesario buscar estrategias que garanticen la apropiada

conservación y el fácil acceso a los documentos generados.

Unificación con el Repositorio Institucional de la Universidad Distrital -

RIUD: para tener de forma centralizada toda la información generada por

la comunidad universitaria.

Unificación con el sistema de gestión académica de la universidad:

buscar una arquitectura que facilite la integración del producto de

software obtenido con el sistema de gestión académica de la

universidad, permitiendo la unificación de los procesos de trabajos de

grado.

Dar continuidad al módulo elaborado para Monografía y hacerlo

extensible para Innovación-Investigación con el fin de reutilizar, lo que

más se pueda de dicho módulo.


CAPÍTULO 12. CONCLUSIONES


El uso de la metodología OpenUP/OAS, fortaleció la comunicación entre los

integrantes del equipo de trabajo y facilitó la gestión del proyecto mediante la

planeación de tareas en iteraciones semanales, con la obtención de artefactos

que permiten evaluar de una manera más sencilla y directa el avance total.

Implementar un framework para desarrollar un sistema desde cero, facilita y

agiliza el avance en sistema, además ayuda a estructurar los módulos del

mismo, también apoya el proceso de entendimiento y reutilización del código, lo

que optimiza el proceso de mantenimiento de los diferentes módulos del

sistema y abre las puertas a que nuevos desarrolladores puedan entender el

código y ampliarlo si el sistema lo necesita.

Utilizar el estándar BPMN para realizar el modelado de negocio a partir de una

normatividad ayuda a simplificar y entender más fácilmente el proceso que allí

se indica, además permite evidenciar de una manera más rápida los posibles

flujos alternos.

La implementación del sistema con las tecnologías que se manejan al interior

de la OAS ayuda a hacer que este sea compatible con los demás sistemas, lo

que permitiría en un futuro anexar las funcionalidades aquí desarrolladas al

Sistema de Gestión Académica de la Universidad Distrital, actualmente Cóndor.

Emplear en lenguaje de modelado unificado UML para especificar y mostrar los

procesos que se llevarán a cabo en los módulos del sistema, ayuda a

estandarizar la forma en la que el sistema debe manejar las diferentes

funcionalidades que tiene que implementar, lo cual ayuda a conservar la idea

inicial del sistema sin importar si cambian o no las personas encargadas de

llevarlo a cabo.

Utilizar un generador de reportes como Reportico permite elaborar plantillas de

reportes de una manera sencilla y ágil, además facilita el proceso de

reutilización lo que contribuye a que el sistema sea extensible de acuerdo a las

nuevas necesidades que surjan por parte del cliente.

Realizar la migración de un sistema permite reutilizar parte de la lógica con la

que se elaboró el mismo, sin embargo, el hecho de que la arquitectura del

sistema inicial sea tan diferente a la que se desea implementar dificulta el

proceso, por lo que en ocasiones es pertinente partir desde cero.

Se migró el módulo de gestión de trabajos de grado para la modalidad de

monografía, para lo cual se creó el sistema Pólux, el cual servirá como base


para la implementación de las demás modalidades de grado que requiera la

Universidad.

La implementación de un sistema para gestionar trabajos de grado, permite

darle seguimiento de una manera más sencilla por parte tanto de los

estudiantes como de los docentes relacionados con el mismo.

La realización de pruebas durante el proceso de desarrollo y el control de

cambios correspondiente, ayudó a que en las pruebas realizadas por el

personal asignado por la OAS, se minimizara la cantidad de errores

encontrados en el sistema, agilizando la aprobación del mismo para su debido

paso a producción.

La curva de aprendizaje del framework SARA es bastante alta, lo que contrasta

con el hecho de que por ser un framework diseñado por la universidad, este no

se encuentre lo suficientemente documentado y la solución de errores tienda a

ser un poco más dispendiosa de lo que sería con un framework más popular.

Para la definición de los diagramas BPMN y los artefactos de análisis de la

modalidad de Espacios Académicos de Profundización, fue posible reutilizar lo

especificado para la modalidad de Espacios Académicos de Posgrado debido a

que el proceso entre estas modalidades es similar; la diferencia radica en que

uno es aplicable por programas de pregrado y el otro para programas de ciclo

propedeútico.


CAPÍTULO 13. BIBLIOGRAFÍA

Acevedo Nieto, Y. V. (2015). Modelo de un sistema de software basado en las técnicas de Learning Analytics como herramienta de apoyo en la toma de decisiones Académico-Administrativas en las Instituciones Públicas de Educación Superior. Universidad Distrital Francisco José de Caldas.

Achour, M., Betz, F., Dovgal, A., Lopes, N., Magnusson, H., Richter, G., … Vrana, J. (2015). PHP: PHP Manual - Manual. Retrieved September 23, 2015, from https://secure.php.net/manual/en/

Andrearrs. (2014). Diferencias entre Software Libre y Open Source. Retrieved September 22, 2015, from http://hipertextual.com/archivo/2014/05/diferencias-software-libre-y-open-source/

Bahamon Calderón, I. (2011). Resolución 461 de 2011. Retrieved from http://sgral.udistrital.edu.co/xdata/rec/res_2011-461.pdf

Capuñay Uceda, O. (2013). Desarrollo Web con PHP (p. 304).

Castro Ortiz, G. E. (2009). No Title. Bogotá. Retrieved from https://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=16&cad=rja&uact=8&ved=0ahUKEwiy0oaqidLJAhUF5yYKHdbYDLw4ChAWCDYwBQ&url=http://www.carlosvicentederoux.org/apc-aa-files/e9ab71a77c828be667b849be2f9b86d8/Respuesta%20U.%20Distri

Eclipse. (2012). OpenUP. Retrieved from http://epf.eclipse.org/wikis/openup/index.htm

Heurtel, O. (2014). PHP y MySQL: domine el desarrollo de un sitio web dinámico e interactivo (ENI). Barcelona.

Oficina Asesora de Sistemas. (2011a). Capítulo 9. Desarrollo de la Solución. Retrieved from http://www.udistrital.edu.co:8080/documents/276352/356568/Cap9Desarrollo.pdf

Oficina Asesora de Sistemas. (2011b). Guía Rápida Proceso de Desarrollo OPENUP / OAS. Retrieved from https://www.udistrital.edu.co/files/dependencias/oas/GuiaRapidaOpenUPOAS.pdf

Oficina Asesora de Sistemas. (2012). Framework SARA. Retrieved September 20, 2015, from https://github.com/frameworksara/sara/blob/master/README


PostgreSQL. (2014). PostgreSQL: Comunicado de Prensa para PostgreSQL 9.4. Retrieved September 20, 2015, from http://www.postgresql.org/about/press/presskit94/es/

rafaelma. (2010). Sobre PostgreSQL | www.postgresql.org.es. Retrieved September 22, 2015, from http://www.postgresql.org.es/sobre_postgresql

Triana Torres, J. W. (2008). El archivo y la gestión documental como apoyo a las funciones sustantivas en la universidad Santo Tomás. Retrieved from http://www.javeriana.edu.co/ciau2008/ponencias/pdf/JORGE WILLIAM TRIANA PONENCIA.pdf

UDLearn. (2015). Retrieved November 3, 2015, from http://200.69.103.29:24421/UDLearn/trabajogrado/consulta/PageConsultarTrabajosGradoAconoPcur.do

Universidad Distrital Francisco José de Caldas. (2015). Acuerdo 038 de 2015 - Trabajos de grado.pdf. Retrieved from http://www.udistrital.edu.co:8080/documents/14198/0/Acuerdo+038+de+2015+-+Trabajos+de+grado

Vargas Jerez, J. C. (2013). Análisis, diseño e implementación de un prototipo web para la gestión 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.


ANEXOS

Los siguientes anexos se encuentran disponibles en el CD adjunto al proyecto:

ANEXO A. Diagramas de actividades

ANEXO B. Diagramas de secuencia

ANEXO C. Bloc de notas de la arquitectura

ANEXO D. Diccionario de datos

ANEXO E. Manual de usuario

ANEXO F. Framework SARA

ANÁLISIS, DISEÑO Y DESARROLLO DE UN MÓDULO PARA EL...

Documents

Transcript of ANÁLISIS, DISEÑO Y DESARROLLO DE UN MÓDULO PARA EL...