anÁlisis, diseÑo y desarrollo de un mÓdulo para el...
TRANSCRIPT
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 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 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
Universidad Distrital Francisco José de Caldas 2
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.
Universidad Distrital Francisco José de Caldas 3
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.
Universidad Distrital Francisco José de Caldas 4
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
Universidad Distrital Francisco José de Caldas 5
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).
● 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 (Universidad
Distrital Francisco José de Caldas, 2015).
● Representar los diferentes procesos y flujos de información para la
modalidad de Espacios 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 (Universidad
Distrital Francisco José de Caldas, 2015).
Universidad Distrital Francisco José de Caldas 6
● 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 (Universidad
Distrital Francisco José de Caldas, 2015).
● 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.
Universidad Distrital Francisco José de Caldas 7
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.
Universidad Distrital Francisco José de Caldas 8
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.
Universidad Distrital Francisco José de Caldas 9
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.
Universidad Distrital Francisco José de Caldas 10
● 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.
Universidad Distrital Francisco José de Caldas 11
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).
Universidad Distrital Francisco José de Caldas 12
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
Universidad Distrital Francisco José de Caldas 13
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.
Universidad Distrital Francisco José de Caldas 14
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.
Universidad Distrital Francisco José de Caldas 15
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).
Universidad Distrital Francisco José de Caldas 16
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.
Universidad Distrital Francisco José de Caldas 17
● 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.
Universidad Distrital Francisco José de Caldas 19
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):
Universidad Distrital Francisco José de Caldas 20
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
Universidad Distrital Francisco José de Caldas 21
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.
Universidad Distrital Francisco José de Caldas 22
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.
Universidad Distrital Francisco José de Caldas 23
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.
Universidad Distrital Francisco José de Caldas 24
● 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.
- Actualizar, depurar y aumentar el contenido del
documento Casos de prueba.
Desarrollar la arquitectura - Agregar las vistas de arquitectura al documento
Bloc de Notas de la Arquitectura.
Universidad Distrital Francisco José de Caldas 25
Desarrollar un incremento
en la solución
- Actualizar, depurar y aumentar el contenido del
documento Especificación de Diseño.
- Actualizar, depurar y aumentar el contenido del
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
- Actualizar, depurar y aumentar el contenido del
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
Universidad Distrital Francisco José de Caldas 26
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.
Tomado de (Oficina Asesora de Sistemas, 2011b)
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
Universidad Distrital Francisco José de Caldas 27
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
Universidad Distrital Francisco José de Caldas 28
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.
Tomado de (Oficina Asesora de Sistemas, 2011b)
Rol Función Principal
Director del Proyecto Este rol garantiza la continuidad del proyecto al
Universidad Distrital Francisco José de Caldas 29
(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
(Asignado por la OAS)
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
(Autores del presente
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
(Autores del presente
proyecto)
Es responsable de desarrollar una parte del
sistema, incluyendo diseñar esta, para que se
ajuste a la arquitectura
Inspector de Pruebas
(Asignado por la OAS)
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
Universidad Distrital Francisco José de Caldas 30
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.
Universidad Distrital Francisco José de Caldas 31
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
Universidad Distrital Francisco José de Caldas 32
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
Universidad Distrital Francisco José de Caldas 33
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.
Universidad Distrital Francisco José de Caldas 34
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.
Universidad Distrital Francisco José de Caldas 35
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
Universidad Distrital Francisco José de Caldas 36
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
Universidad Distrital Francisco José de Caldas 37
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.
Universidad Distrital Francisco José de Caldas 38
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.
Universidad Distrital Francisco José de Caldas 39
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
Universidad Distrital Francisco José de Caldas 40
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
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
Tabla 11. Enlaces repetidos rol de Estudiante Fuente: Autores
Universidad Distrital Francisco José de Caldas 41
Rol Docente
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 12. Enlaces repetidos rol de Docente Fuente: Autores
Rol Administrador
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
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.
Universidad Distrital Francisco José de Caldas 42
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/
Universidad Distrital Francisco José de Caldas 43
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
Universidad Distrital Francisco José de Caldas 44
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.
No. Módulo Funcionalidad Rol que
aplica
Periodo Desarrollo
Fecha Inicio Fecha Final
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
Universidad Distrital Francisco José de Caldas 45
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.
No. Módulo Funcionalidad Rol que
aplica
Periodo Desarrollo
Fecha Inicio Fecha Final
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
Universidad Distrital Francisco José de Caldas 46
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.
No. Módulo Funcionalidad Rol que
aplica
Periodo Desarrollo
Fecha Inicio Fecha Final
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.
No. Módulo Funcionalidad Rol que
aplica
Periodo Desarrollo
Fecha Inicio Fecha Final
24 Estudiante Consultar Evaluación Estudiante 23/01/2016 25/01/2016
Universidad Distrital Francisco José de Caldas 47
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.
No. Módulo Funcionalidad Rol que
aplica
Periodo Desarrollo
Fecha Inicio Fecha Final
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
Universidad Distrital Francisco José de Caldas 48
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.
No. Módulo Funcionalidad Rol que
aplica
Periodo Desarrollo
Fecha Inicio Fecha Final
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.
Universidad Distrital Francisco José de Caldas 49
No. Módulo Funcionalidad Rol que
aplica
Periodo Desarrollo
Fecha Inicio Fecha Final
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.
No. Módulo Funcionalidad Rol que
aplica
Periodo Desarrollo
Fecha Inicio Fecha Final
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
1/03/2016 8/03/2016 Coordinador Coordinador
Docente Docente
Universidad Distrital Francisco José de Caldas 50
49
Delegado
Trabajos por temática de interés y docente
Delegado
1/03/2016 8/03/2016 Coordinador Coordinador
Docente Docente
50 Delegado Temáticas de interés
por programa curricular
Delegado 1/03/2016 8/03/2016
Coordinador Coordinador
51
Estudiante
Docentes por temática de interés
Estudiante
1/03/2016 8/03/2016 Delegado Delegado
Coordinador Coordinador
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
Fecha Inicio Fecha Final
52
Delegado Nivel de aceptación por temática de interés
Delegado
8/03/2016 15/03/2016 Coordinador Coordinador
Docente Docente
53
Delegado Facultad Nivel de participación
de docentes en trabajos de grado
Delegado Facultad
8/03/2016 15/03/2016 Coordinador Coordinador
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
Universidad Distrital Francisco José de Caldas 51
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
Universidad Distrital Francisco José de Caldas 52
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.
Universidad Distrital Francisco José de Caldas 53
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.
Universidad Distrital Francisco José de Caldas 54
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.
Universidad Distrital Francisco José de Caldas 55
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
Universidad Distrital Francisco José de Caldas 56
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
Universidad Distrital Francisco José de Caldas 57
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.
Universidad Distrital Francisco José de Caldas 58
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.
Universidad Distrital Francisco José de Caldas 59
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.
Universidad Distrital Francisco José de Caldas 60
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.
Tomado de (Oficina Asesora de Sistemas, 2011b)
Universidad Distrital Francisco José de Caldas 61
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.
Universidad Distrital Francisco José de Caldas 62
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.
Universidad Distrital Francisco José de Caldas 63
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
Universidad Distrital Francisco José de Caldas 64
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.
Espacios Académicos de
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:
Universidad Distrital Francisco José de Caldas 65
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.
Universidad Distrital Francisco José de Caldas 66
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.
Universidad Distrital Francisco José de Caldas 67
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
Fecha Inicio Fecha Final
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.
No. Actividad Periodo
Fecha Inicio Fecha Final
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
Universidad Distrital Francisco José de Caldas 68
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.
No. Actividad Periodo
Fecha Inicio Fecha Final
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.
No. Actividad Periodo
Fecha Inicio Fecha Final
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
Universidad Distrital Francisco José de Caldas 69
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.
Universidad Distrital Francisco José de Caldas 70
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 Distrital Francisco José de Caldas 71
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.
Universidad Distrital Francisco José de Caldas 72
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.
Universidad Distrital Francisco José de Caldas 73
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.
9.2.5.3.1. Modelo BPMN
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.
Universidad Distrital Francisco José de Caldas 74
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.
Universidad Distrital Francisco José de Caldas 75
9.2.5.3.2. Diagrama casos de uso
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
Universidad Distrital Francisco José de Caldas 76
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.
9.2.5.4.1. Modelo BPMN
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
claridad, puede consultar la imagen completa y de alta calidad en el CD de los
anexos.
Figura 24. Primera parte del modelo BPMN de Producción Académica.
Universidad Distrital Francisco José de Caldas 77
Figura 25. Segunda parte del modelo BPMN para la modalidad de Producción Académica.
Fuente: Autores
9.2.5.4.2. Diagrama casos de uso
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.
Universidad Distrital Francisco José de Caldas 78
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
Universidad Distrital Francisco José de Caldas 79
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.
9.2.5.5.1. Modelo BPMN
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
Universidad Distrital Francisco José de Caldas 80
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.
Universidad Distrital Francisco José de Caldas 81
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
9.2.5.5.2. Diagrama casos de uso
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
Universidad Distrital Francisco José de Caldas 82
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
claridad, puede consultar la imagen completa y de alta calidad en el CD de los
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
Universidad Distrital Francisco José de Caldas 83
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)
(from Módulo de Gestión
Innovación-investigación)
CUIN13 Consultar Plan de
activ idades
(Anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN11 Consultar Plan de
activ idades
(Anteproyectos) Por
Estudiante
(from Módulo de Gestión
Innovación-investigación)
CUIN08 Registrar nuev a
v ersión de documento de
Plan de activ idades
(Anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN15 Consultar Plan de
activ idades
(Anteproyectos)
Asignados para Rev isión
(from Módulo de Gestión
Innovación-investigación)
CUIN10 Consultar Plan de
activ idades (Anteproyectos)
por proyecto curricular
(from Módulo de Gestión
Innovación-investigación)
CUIN16 Consultar Plan de
activ idades
(Anteproyectos) Dirigidos
Rev isor de anteproyecto
(from
Actores)
(from Módulo de Gestión
Innovación-investigación)
CUIN09 Consultar Plan de
activ idades (Anteproyectos)
sin rev isores asignados
(from Módulo de Gestión
Innovación-investigación)
CUIN14 Consultar
ev aluaciones de documento
de Plan de activ idades
(anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN12 Consultar
Asignación de Rev isor a
Plan de activ idades
«extend»
«extend»
Universidad Distrital Francisco José de Caldas 84
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)
(from Módulo de Gestión
Innovación-investigación)
CUIN18 Asignar Rev isores
a Plan de activ idades
(Anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN17 Crear Asignación
de Rev isor de Plan de
activ idades (Anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN12 Consultar
Asignación de Rev isor a
Plan de activ idades
(from Módulo de Gestión
Innovación-investigación)
CUIN19 Consultar
Solicitudes de Rev ision de
Plan de activ idades
(Anteproyecto) Asignadas
(from Módulo de Gestión
Innovación-investigación)
CUIN09 Consultar Plan de
activ idades
(Anteproyectos) sin
rev isores asignados
«include»
Universidad Distrital Francisco José de Caldas 85
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)
(from Módulo de Gestión
Innovación-investigación)
CUIN23 Ev aluar documento
de Plan de activ idades
(Anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN24 Solicitar ev aluación
de documento de Plan de
activ idades (anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN25 Crear Solicitud de
Ev aluación de Plan de
activ idades (Anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN21 Consultar solicitud
de rev isión de Plan de
activ idades (anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN22 Solicitar
modificación de documento
de Plan de activ idades
(Anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN20 Consulta de
solicitudes pendientes de
rev isión de Plan de
activ idades (anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN15 Consultar Plan de
activ idades (Anteproyectos)
Asignados para Rev isión
(from Módulo de Gestión
Innovación-investigación)
CUIN14 Consultar
ev aluaciones de documento
de Plan de activ idades
(anteproyecto)
(from Módulo de Gestión
Innovación-investigación)
CUIN08 Registrar nuev a
v ersión de documento de
Plan de activ idades
(Anteproyecto)
«extend»
«include»
Universidad Distrital Francisco José de Caldas 86
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
Universidad Distrital Francisco José de Caldas 87
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.
Universidad Distrital Francisco José de Caldas 88
Figura 38. Casos de uso para el Sub-módulo de inicio y consulta del informe de
actividades, fase final del proyecto. Fuente: Autores
Universidad Distrital Francisco José de Caldas 89
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
Universidad Distrital Francisco José de Caldas 90
Figura 40. Casos de uso para el Sub-módulo de evaluación del informe de actividades, fase final del proyecto.
Fuente: Autores
Universidad Distrital Francisco José de Caldas 91
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%
Universidad Distrital Francisco José de Caldas 92
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
Espacios Académicos de
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.
Se determinaron 11 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 casos de uso.
100%
Universidad Distrital Francisco José de Caldas 93
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.
Se determinaron 11 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 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
Universidad Distrital Francisco José de Caldas 95
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.
Universidad Distrital Francisco José de Caldas 97
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
Universidad Distrital Francisco José de Caldas 98
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.
Universidad Distrital Francisco José de Caldas 99
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
Universidad Distrital Francisco José de Caldas 100
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.
Universidad Distrital Francisco José de Caldas 101
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