Proyecto Final

ANÁLISIS DE REQUERIMIENTOS Y DISEÑO DE LA BASE DE DATOS
PARA EL SISTEMA DE GESTIÓN DE PROYECTOS DE GRADO “POLUX”

DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
AUTOR:
GEINER ALEXIS SALCEDO SALGADO
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C, 2016
ANÁLISIS DE REQUERIMIENTOS Y DISEÑO DE LA BASE DE DATOS
PARA EL SISTEMA DE GESTIÓN DE PROYECTOS DE GRADO “POLUX”
DE LA UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
AUTOR:
GEINER ALEXIS SALCEDO SALGADO
20102020086
PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE INGENIERO DE

SISTEMAS
DIRECTOR:
Ing. ALEJANDRO PAOLO DAZA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
BOGOTÁ D.C, 2016
TABLA DE CONTENIDO
CAPÍTULO 1. INTRODUCCIÓN ...................................................................................... 7

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA ..................................................... 9
CAPÍTULO 3. OBJETIVOS ............................................................................................ 11
3.1. OBJETIVO GENERAL ......................................................................................... 11
3.2. OBJETIVOS ESPECÍFICOS ................................................................................ 11
CAPÍTULO 4. JUSTIFICACIÓN ..................................................................................... 13
CAPÍTULO 5. ALCANCES Y LIMITACIONES .............................................................. 15
5.1. ALCANCES .......................................................................................................... 15
5.2. LIMITACIONES .................................................................................................... 15
CAPÍTULO 6. ANTECEDENTES ................................................................................... 17
6.1 SGPG-UD .............................................................................................................. 17
6.2 UDLEARN ............................................................................................................. 18
CAPÍTULO 7. MARCO TEORICO ................................................................................. 19
7.1 EL PROCESO DE DESARROLLO SCRUM ........................................................ 19
7.2 GENERALIDADES ................................................................................................ 19
7.2.1. TRANSPARENCIA ........................................................................................ 19
7.2.2. INSPECCIÓN ................................................................................................ 20
7.2.3. ADAPTACIÓN ............................................................................................... 20
7.3 ROLES................................................................................................................... 20
7.3.1 PRODUCT OWNER. ...................................................................................... 20
7.3.2 EQUIPO DE DESARROLLO. ......................................................................... 21
7.3.3 SCRUM MASTER. ......................................................................................... 22
7.3.4 NON-CORE ROLES. ...................................................................................... 23
7.4 ELEMENTOS DE SCRUM. ................................................................................... 25
7.4.1 PRODUCT BACKLOG. .................................................................................. 25
7.4.2 SPRINT BACKLOG. ....................................................................................... 25
7.4.3 SPRINT. .......................................................................................................... 25
7.4.4 SPRINT PLANNING MEETING. .................................................................... 26
7.4.5 SCRUM DIARIO. ............................................................................................ 26
7.4.6 REVISIÓN DE SPRINT. ................................................................................. 27
7.4.7 FEEDBACK. ................................................................................................... 27
Universidad Distrital Francisco José de Caldas 1

7.4.8 RELEASE ....................................................................................................... 27
7.4.9 IDENTIFICACIÓN DE FUNCIONALIDADES DEL SOFTWARE ................... 28
7.5 HISTORIA DE USUARIO ...................................................................................... 29
7.5.1 COMPONENTES............................................................................................ 29
7.5.2 REDACCIÓN .................................................................................................. 29
7.5.3 DEFINICIÓN DE TERMINADO ...................................................................... 30
7.6 DIAGRAMA BPMN ................................................................................................ 31
7.6.1 CARACTERÍSTICAS ...................................................................................... 31
7.6.2 ELEMENTOS.................................................................................................. 31
7.7 POSTGRESQL ...................................................................................................... 33
7.7.1 CARACTERÍSTICAS ...................................................................................... 34
CAPÍTULO 8. METODOLOGÍA ..................................................................................... 37
8.1 MARCO METODOLÓGICO .................................................................................. 37
8.1.1. PROCESO SCRUM ...................................................................................... 37
8.1.1.1. GENERALIDADES ................................................................................. 41
8. 2 EL MÉTODO DE TRABAJO ................................................................................ 44
8.2.1. FASES DEL PROYECTO ............................................................................. 44
8.2.1.1 FASE INICIAL ......................................................................................... 44
8.2.1.2 FASE INTERMEDIA ................................................................................ 45
8.2.1.2 FASE FINAL ............................................................................................ 45
CAPÍTULO 9. INGENIERIA DEL PROYECTO.............................................................. 47
9.1. PLAN GENERAL ................................................................................................. 47
9.1.1. RECURSOS .................................................................................................. 50
9.1.2. PRESUPUESTO ........................................................................................... 51
9.2. MODELAMIENTO DEL NEGOCIO ..................................................................... 53
9.2.1. ASPECTOS DE TRABAJO DE GRADO ..................................................... 53
9.2.2. MODALIDADES DE TRABAJO DE GRADO .............................................. 53
9.3. REQUERIMIENTOS............................................................................................. 57
9.3.1. DEFINICIÓN DE ACTORES Y ROLES. ....................................................... 57
9.3.2. REQUERIMIENTOS FUNCIONALES. ......................................................... 60
9.3.1.1. REQUERIMIENTOS DE PROCEDIMIENTOS GENERALES ............... 60
9.3.1.2. REQUERIMIENTOS MODALIDAD PASANTIA .................................... 62
9.3.1.3. REQUERIMIENTOS MODALIDAD ESPACIOS ACADEMICOS DE
POSTGRADO ...................................................................................................... 64

PROFUNDIZACION............................................................................................. 65
9.3.1.5. REQUERIMIENTOS MODALIDAD MONOGRAFIA ............................. 65
9.3.1.6. REQUERIMIENTOS MODALIDAD INVESTIGACIÓN-INNOVACIÓN . 66
9.3.1.7. REQUERIMIENTOS MODALIDAD CREACIÓN O INTERPRETACIÓN
.............................................................................................................................. 68
9.3.1.8. REQUERIMIENTOS MODALIDAD PROYECTO EMPRENDIMIENTO 68
9.3.1.9. REQUERIMIENTOS MODALIDAD PRODUCCIÓN ACADÉMICA ...... 70
9.3.1.10. REQUERIMIENTOS DE PLATAFORMA ............................................ 70
9.3.3. REQUERIMIENTOS NO FUNCIONALES. ................................................... 72
9.4. ANÁLISIS ............................................................................................................. 73
9.4.1. GENERALIZACIÓN DE PROCESOS. ......................................................... 73
9.4.2. MODELAMIENTO PROCESOS DE NEGOCIO. .......................................... 83
9.5. DISEÑO ................................................................................................................ 95
9.5.1. CONSTRUCCION DE PROTOTIPOS .......................................................... 95
9.5.2. DISEÑO DE LA BASE DE DATOS ............................................................ 106
CAPÍTULO 10. RESULTADOS Y DISCUSIÓN ........................................................... 119
CAPÍTULO 11. TRABAJOS FUTUROS ...................................................................... 123
CAPÍTULO 12. CONCLUSIONES ............................................................................... 125
CAPÍTULO 13. BIBLIOGRAFÍA .................................................................................. 127
ANEXOS ....................................................................................................................... 129

ÍNDICE DE FIGURAS
FIGURA 1. PROTOTIPO EN SGPG-UD ..............................................................................................................17

FIGURA 2. MÓDULO UDLEARN. .....................................................................................................................18
FIGURA 3 COMPONENTE DEL SISTEMA POSTGRESQL ...........................................................................................33
FIGURA 4. FASES DEL PLAN GENERAL................................................................................................................47
FIGURA 5. DIAGRAMA BPMN MODALIDAD ESPACIOS ACADÉMICOS DE POSTGRADO AUTORÍA PROPIA.............................85
FIGURA 6. DIAGRAMA BPMN MODALIDAD ESPACIOS ACADÉMICOS DE PROFUNDIZACIÓN AUTORÍA PROPIA......................86
FIGURA 7. DIAGRAMA DE FLUJO BPMN PROCESO GENERAL AUTORÍA PROPIA ...........................................................87
FIGURA 8. DIAGRAMA DE FLUJO BPMN MODALIDAD PASANTÍA AUTORÍA PROPIA ......................................................88
FIGURA 9. DIAGRAMA DE FLUJO BPMN MODALIDAD MONOGRAFÍA AUTORÍA PROPIA .................................................89
FIGURA 10. DIAGRAMA DE FLUJO BPMN MODALIDAD PRODUCCIÓN ACADÉMICA AUTORÍA PROPIA ...............................90
FIGURA 11. DIAGRAMA DE FLUJO BPMN MODALIDAD CREACIÓN O INTERPRETACIÓN AUTORÍA PROPIA ..........................91
FIGURA 12. DIAGRAMA DE FLUJO BPMN MODALIDAD PROYECTO DE EMPRENDIMIENTO AUTORÍA PROPIA.......................92
FIGURA 13. DIAGRAMA DE FLUJO BPMN MODALIDAD INVESTIGACIÓN-INNOVACIÓN AUTORÍA PROPIA ...........................93
FIGURA 14, PROTOTIPO DE REGISTRO DE PROPUESTA AUTORÍA PROPIA .................................................................... 96
FIGURA 15. PROTOTIPO VINCULACIÓN DE ESTUDIANTES AUTORÍA PROPIA ................................................................97
FIGURA 16. PROTOTIPO NOTIFICACIÓN A VINCULACIÓN DE PROPUESTA AUTORÍA PROPIA .............................................98
FIGURA 17. PROTOTIPO INFORMACIÓN GENERAL DE PROPUESTA PARA VINCULACIÓN DE ESTUDIANTE AUTORÍA PROPIA .......99
FIGURA 18. PROTOTIPO LISTADO DE PETICIONES DE TRABAJO DE GRADO PARA AVALAR AUTORÍA PROPIA .........................99
FIGURA 19. PROTOTIPO PARA LA REVISIÓN DE UN DOCUMENTO DE TRABAJO DE GRADO AUTORÍA PROPIA ...................... 100
FIGURA 20. PROTOTIPO ESTADO DE PROPUESTA DE TRABAJO DE GRADO AUTORÍA PROPIA .......................................... 100
FIGURA 21. PROTOTIPO LISTADO DE PROPUESTAS SOLICITADAS AL CONCEJO AUTORÍA PROPIA ..................................... 101
FIGURA 22. PROTOTIPO SOLICITUD CONCEJO CURRICULAR REGISTRO DE TRABAJO DE GRADO TOMADO DE [13] ............... 101
FIGURA 23. PROTOTIPO ASIGNACIÓN DE EVALUADORES Y DIRECTOR AUTORÍA PROPIA ............................................... 102
FIGURA 24. PROTOTIPO PARA FORMATO DE EVALUACIÓN AUTORÍA PROPIA ............................................................ 103
FIGURA 25. PROTOTIPO ESTADO DE TRABAJO DE GRADO AUTORÍA PROPIA .............................................................. 104
FIGURA 26. PROTOTIPO PARA VER INFORMACIÓN DE TRABAJO DE GRADO TOMADO DE [13] ....................................... 104
FIGURA 27. PROTOTIPO REGISTRO DE VERSIONES DE DOCUMENTO DE TRABAJO DE GRADO AUTORÍA PROPIA .................. 104
FIGURA 28. PROTOTIPO PROGRAMACIÓN SOCIALIZACIÓN AUTORÍA PROPIA ............................................................ 105
FIGURA 29. PROTOTIPO INFORME DE CALIFICACIÓN FINAL TOMADO DE [13] ........................................................... 106
FIGURA 30. MODELO DE LA BASE DE DATOS AUTORÍA PROPIA ............................................................................ 109
FIGURA 31. MODELADO - RELACIÓN TG - MODALIDAD – ESTUDIANTE AUTORÍA PROPIA ........................................... 111
FIGURA 32. MODELADO ESPACIOS ACADÉMICOS AUTORÍA PROPIA ....................................................................... 112
FIGURA 33. MODELADO GESTIÓN DOCUMENTOS DE TRABAJO DE GRADO AUTORÍA PROPIA ...................................... 113
FIGURA 34. MODELADO EVALUACIÓN, FORMATO Y SOCIALIZACIÓN AUTORÍA PROPIA ............................................... 116
FIGURA 35. MODELADO VINCULACIONES EXTERNAS AUTORÍA PROPIA ................................................................... 118
FIGURA 36. MODELADO ÁREAS CONOCIMIENTO AUTORÍA PROPIA ....................................................................... 118

ÍNDICE DE TABLAS
TABLA 1PROCESO METODOLÓGICO SCRUM..................................................................................................... 40

TABLA 2. CRONOGRAMA DE SPRINTS EN SCRUM PARA EL DESARROLLO DEL PROYECTO, AUTORÍA PROPIA .......................49
TABLA 3. RECURSOS NECESARIOS PARA LA REALIZACIÓN DEL PROYECTO .................................................................... 50
TABLA 4. PRESUPUESTO DEL PROYECTO. ...........................................................................................................51
TABLA 5. ACTOR Y ROLES DE ESTUDIANTE AUTORÍA PROPIA ..................................................................................58
TABLA 6. ACTOR Y ROLES DE DOCENTE AUTORÍA PROPIA ......................................................................................59
TABLA 7. ACTOR Y ROLES DE CONCEJO DE CARRERA AUTORÍA PROPIA ..................................................................... 59
TABLA 8. ACTOR Y ROLES DE PROYECTO CURRICULAR AUTORÍA PROPIA ...................................................................60
TABLA 9. ACTOR Y ROLES DE UNIDAD DE EXTENSIÓN AUTORÍA PROPIA .................................................................... 60
TABLA 10. MACRO PROCESO GENERALIZADO PARA INSCRIPCIÓN DE ESPACIOS ACADÉMICOS ..........................................75
TABLA 11. SUBPROCESO GENERAL PARA SOLICITUD DEL ESPACIO DE TRABAJO DE GRADO ..............................................76
TABLA 12. SUB PROCESO GENERAL REGISTRO DE ANTEPROYECTO AUTORÍA PROPIA .....................................................77
TABLA 13. SUB PROCESO GENERAL VINCULACIÓN DE ESTUDIANTES AUTORÍA PROPIA ...................................................77
TABLA 14. SUB PROCESO GENERAL VINCULACIÓN DOCENTE AUTORÍA PROPIA ...........................................................78
TABLA 15. SUB PROCESO GENERAL REVISIÓN DE DOCUMENTO AUTORÍA PROPIA ........................................................78
TABLA 16. SUB PROCESO REGISTRO PROYECTO FINAL AUTORÍA PROPIA .................................................................... 79
TABLA 17. SUB PROCESO GENERAL ASIGNACIÓN DE REVISORES Y EVALUADORES AUTORÍA PROPIA ..................................80
TABLA 18. SUB PROCESO GENERAL SOCIALIZACIÓN AUTORÍA PROPIA .......................................................................80
TABLA 19.SUB PROCESO GENERAL EVALUACIÓN AUTORÍA PROPIA...........................................................................81
TABLA 20. RESULTADOS AUTORÍA PROPIA....................................................................................................... 121

CAPÍTULO 1. INTRODUCCIÓN
La Universidad Distrital Francisco José de Caldas es una institución autónoma

de educación superior, de carácter público, constituida esencialmente por
procesos y relaciones que generan estudiantes y profesores identificados en la
búsqueda libre del saber, es un ente de carácter estatal cuya misión se centra
en formar la persona a partir de la construcción del conocimiento y la
investigación en la búsqueda de resultados socialmente útiles[1]. Su misión es
la democratización del acceso al conocimiento para garantizar, a nombre de la
sociedad y con participación de Estado, el derecho social a una educación
superior con criterio de excelencia, equidad y competitividad mediante la
generación y difusión de saberes y conocimientos con autonomía y vocación
hacia el desarrollo sociocultural para contribuir fundamentalmente al progreso
de la Ciudad – Región de Bogotá y el país.
Para cumplir a cabalidad con este objetivo es fundamental generar egresados

con capacidad de actuar como protagonistas del cambio social y de sí mismo,
en la formación del espíritu científico aplicado a la indagación, interpretación y
modificación de la realidad y en la contribución a forjar ciudadanos idóneos
para promover el progreso de la sociedad.
La Universidad Distrital Francisco José de Caldas, al centrarse en uno de sus

pilares en la generación de egresados de alta calidad, cuenta con diversas
modalidades de trabajo de grado, lo cual se estipula en el acuerdo N° 038 del
28 de julio de 2015 como 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, en
cumplimiento del artículo 70 del Acuerdo 027 de 1993 del consejo superior
universitario.
Actualmente las modalidades de trabajo de grado definidas para optar al título

de pregrado en cualquier proyecto curricular de la Universidad Distrital
Francisco José de Caldas son pasantía, espacios académicos de postgrado,
espacios académicos de profundización, monografía, investigación-innovación,
creación o interpretación, proyecto de emprendimiento y producción
académica.
Relacionados a este proyecto existen propuestas como la de Juan Camilo

Vargas, quien implementó 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) como tesis de pregrado. 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 Distrital Francisco José de Caldas (Acevedo Nieto, 2015). A raíz
de esto, la Oficina Asesora de Sistemas (OAS) crea un sistema soportado en
tecnologías libres siguiendo el proceso de desarrollo OPENUP/OAS, sobre el
cual se viene trabajando el desarrollo de las diferentes modalidades antes
contempladas basados en lo que se estipula en el acuerdo N° 038 del 28 de
julio de 2015 por la Universidad Distrital Francisco José de Caldas.
Con el fin de realizar una automatización, unificación y mejora en el proceso de

presentación de todas las modalidades de trabajo de grado que la Universidad
Distrital le ofrece a sus estudiantes para la obtención de un título universitario
de pregrado, la oficina asesora de sistema (OAS), en su autoridad de crear
nuevas soluciones a nivel de software para la institución educativa, crea el
proyecto denominado “sistema de gestión de proyectos de grado “POLUX” de
la Universidad Distrital”, realizando un proceso de selección de estudiantes de
últimos semestres del proyecto curricular de ingeniería de sistemas que deseen
vincularse en el proyecto.
El proyecto “Análisis y diseño de la base de datos para los módulos de

modalidades de proyecto de grado para el sistema de gestión de proyectos de
grado “Polux” de la Universidad Distrital Francisco José De Caldas” formará
parte del proceso de Gestión de requerimientos, identificando, analizando y
caracterizando las especificaciones funcionales y no funcionales requeridas
para la posterior realización del diseño de la base de datos que asegurará la
integridad y seguridad de la información manejada en cada una de las diversas
modalidades de trabajo de grado con que cuenta actualmente la institución
académica para el sistema de gestión de proyectos de grado “POLUX” de la
Universidad Distrital Francisco José de Caldas, con el objetivo de dar paso al
desarrollo de una solución de software modular, integral y escalable,
desarrollado en herramientas como pencil y eclipse junto a la base de datos
postgreSQL, siguiendo con el proceso de desarrollo definido por la OAS y de
esta manera contar con una única herramienta tecnológica que soporte el
proceso de cualquier modalidad de trabajo de grado que realicen los
estudiantes con la Institución

CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA
En la actualidad, la Universidad Distrital Francisco José de Caldas hace el

proceso de control a los trabajos de grado realizado por los estudiantes de
forma manual, esto es debido a que no existen sistemas de control
automatizado que faciliten de manera eficiente la asignación, organización,
acceso, disposición y evaluación de estos trabajos.
Dado que los procesos realizados para el registro del documento del proyecto
de grado en las diferentes modalidades establecidas en el acuerdo 038 de
2015 (Universidad Distrital Francisco José de Caldas, 2015) no se hacen de
manera virtual ni automatizada, no hay un control unificado sobre los cambios
realizados por parte del estudiante sobre cada entrega a revisión del
documento del proyecto de grado, lo cual dificulta la evaluación conjunta por
parte de los evaluadores encargados. La consulta concurrente de los
documentos registrados implica copias físicas del mismo, lo que ocasiona
problemas e inconsistencias en las versiones de los documentos consultados,
pues no es posible el acceso de manera inmediata a las observaciones y/o
modificaciones que se hayan generado al documento una vez se haya
solicitado la copia. No hay control automatizado sobre los tiempos en que el
documento debe permanecer en una determinada fase del proceso, lo que
conlleva a realizar seguimiento manual por parte del estudiante en conjunto con
el proyecto curricular [2]. No existe un lugar virtual donde el estudiante pueda
consultar el estado en el que se encuentra su documento sin necesidad de ir a
consultarlo directamente en la universidad en horarios de atención. No hay un
canal de comunicación virtual por donde se le facilite la comunicación al
estudiante con sus respectivos evaluadores o directores.
La oficina Asesora de Sistemas (OAS) plantea 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, 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 que en la
actualidad se encuentra en desarrollo.

CAPÍTULO 3. OBJETIVOS
3.1. OBJETIVO GENERAL
Identificar, analizar y caracterizar las especificaciones funcionales y no

funcionales requeridas junto con el diseño de la base de datos, para el
desarrollo de una solución de software que permita automatizar todos los
procesos afines con la presentación de cualquiera de las modalidades de
trabajo de grado para optar por un título universitario por parte de la
Universidad Distrital, basado en el acuerdo N° 038 del 28 de julio de 2015 del
Consejo Superior Universitario.
3.2. OBJETIVOS ESPECÍFICOS
 Revisar, ajustar y complementar el análisis de requerimientos

correspondientes a las modalidades de espacios académicos de
postgrado, investigación-innovación, espacios de profundización y
producción académica, contempladas en el proyecto “sistema de gestión
de proyectos de grado “POLUX” de la Universidad Distrital” de la Oficina
Asesora de Sistemas (OAS).
 Identificar los requerimientos del sistema de gestión de proyectos de

grado “POLUX” de la Universidad Distrital Francisco José de Caldas
para las modalidades de monografía, pasantías, proyecto de
emprendimiento y creación o interpretación establecidas en el acuerdo
038 de 2015 (Universidad Distrital Francisco José de Caldas, 2015).
 Definir y ajustar las necesidades de los interesados mediante sesiones

de trabajo colaborativo para la elaboración de documentos que permitan
continuar con el desarrollo del proyecto.
 Documentar los artefactos propios del análisis del proceso de desarrollo

definido por la OAS que sirvan como base para el desarrollo del
proyecto y permitan apoyar las siguientes fases del mismo.

 Analizar y realizar el diseño de la base de datos sobre el sistema
“POLUX” de las modalidades de trabajo de grado de espacios
académicos de postgrado, pasantía, investigación-innovación, espacios
de profundización, producción académica, proyecto de emprendimiento
y creación o interpretación.

CAPÍTULO 4. JUSTIFICACIÓN
Debido a que la Universidad Distrital no cuenta con un sistema integral,

unificado y escalable que permita apoyar los procesos relacionados con la
presentación del trabajo de grado en sus diferentes modalidades para optar por
un título universitario por parte de la Universidad Distrital, se hace necesario el
análisis y diseño arquitectónico de una solución de software que permita
unificar las diferentes modalidades de trabajo de grado existentes y enunciadas
en el acuerdo N°038 del 28 de julio de 2015 del consejo superior universitario
por medio de una solución software, en cuyas características se tenga en
cuenta la eficiente operatividad en cada una de las modalidades de trabajo de
grado, adaptabilidad a los cambios normativos y legales del entorno interno o
externo y que cumpla requisitos de alta calidad en capacidades de usabilidad,
fiabilidad, rendimiento y mantenimiento del software.
Para tal fin la Oficina Asesora de Sistemas (OAS) y tres estudiantes de la

Universidad Distrital de últimos semestres pertenecientes al proyecto curricular
de Ingeniería de Sistemas participarán en el desarrollo de módulos
correspondientes a cada una de las modalidades de proyecto de grado donde
cada uno ha elegido un rol dentro del equipo teniendo como opción ser
analistas, arquitectos o desarrolladores.
La ingeniería de requisitos ha sido una de las áreas de la ingeniería del

software en la que más esfuerzos de investigación se ha realizado durante las
últimas décadas, y con motivo, porque los errores de comprensión cometidos
en esta etapa inicial de los proyectos son los más costosos de resolver. Si no
se detectan a tiempo, implican la realización de actividades erróneas durante
todas las fases subsiguientes, hasta llegar a las pruebas. Momento en el que, a
la vista de los defectos detectados en la ejecución de los casos de prueba, se
concluye que la repetición de las actividades erróneas puede ser una manera
de resolver la situación [3].
Para el desarrollo de la solución software es importante inicialmente partir de

identificar, analizar y caracterizar las especificaciones requeridas sobre cada
modalidad de proyecto de grado para el posterior diseño y desarrollo de la
solución de software modular, integral y escalable que permita apoyar los
procesos relacionados a la gestión de modalidades de trabajo de grado
“POLUX”.

Los proyectos exitosos comienzan con una buena administración de
requerimientos, cuánto más efectiva sea su ejecución, mayor será el resultado
en calidad y satisfacción del cliente, por eso si realiza un acertado desarrollo
del proyecto [3], la solución integral de software que se desea permitirá el
mejoramiento del proceso llevado a cabo en la actualidad al reducir tareas
administrativas como archivo y recuperación de documentos, tratamiento de la
información (obtención de copias, recuperación de datos incluidos en el
documento, envío de documentación a las personas interesadas) y ahorro en
espacio. Se evitan pérdidas de documentos, se reduce el deterioro de los
documentos por la degradación del papel y se limita el uso excesivo del mismo.
Se favorece la calidad del proceso educativo, pues facilita la integración de
procesos internos y externos ya que al automatizar la recepción, control y
evaluación de los proyectos se simplifican tareas y se acortan los tiempos, se
comparten tanto cargas de trabajo como documentos en varios entornos, se
centraliza la gestión de todos los documentos y se facilita el trabajo conjunto.
La solución integral de software permitirá reducir el tiempo invertido en todo el

proceso que conlleva optar por cualquier modalidad de trabajo de grado desde
su selección, pasando por la producción del anteproyecto, la aprobación del
mismo, el desarrollo y evaluación del trabajo de grado en la Universidad. Por
otro lado, y por ser un sistema con altamente operatividad permitirá que todos
los implicados en el proceso de presentación de las modalidades de trabajo de
grado interactúen en el sistema de información.
Para el proceso de desarrollo se aplicará el método sugerido por la OAS,

haciendo parte del equipo de desarrollo, con el fin de identificar, analizar y
caracterizar las especificaciones del sistema, los resultados son requeridos y
serán el insumo para el diseño del proyecto, en el cual se tomará parte en la
realización del modelo de la base de datos para la integridad de la información
y así poder continuar con el desarrollo de la solución de software.

CAPÍTULO 5. ALCANCES Y LIMITACIONES
5.1. ALCANCES
 El proyecto abarca la fase de inicio, elaboración y construcción del proceso

de gestión de requerimientos y diseño de la base de datos, participando en
el rol de Analista y arquitecto de la base de datos sobre las modalidades de
espacios académicos de postgrado, pasantía, investigación-innovación,
espacios de profundización, producción académica, proyecto de
emprendimiento y creación o interpretación.
 La entrega de artefactos sobre el análisis y diseño de la base de datos

sobre las modalidades de espacios académicos de postgrado, pasantía,
investigación-innovación, espacios de profundización, producción
académica, proyecto de emprendimiento y creación o interpretación estará
sujeta al proceso de desarrollo sugerido por la OAS.
 Para los módulos de espacios académicos de postgrado, espacios

académicos de profundización, innovación-investigación y producción
académica solo se realizará la revisión y el proceso de especificación de
casos de uso sobre el trabajo anteriormente realizado por la OAS, en
cuanto al análisis.
 Se realizará la respectiva arquitectura de la base de datos complementando

o rediseñando la arquitectura realizada por la OAS en el trabajo existente
del proyecto, para garantizar la integridad y seguridad de la base de datos
realizada a las modalidades de proyecto de grado.
5.2. LIMITACIONES
 Los procesos que no se contemplan en los alcances no serán tenidos en

cuenta para el proyecto.
 Para el desarrollo de este proyecto solo se utilizará herramientas de

software libre.
 El acuerdo N° 038 del 28 de julio de 2015 por la Universidad Distrital

Francisco José de Caldas no contempla flujos alternos en las modalidades
con lo cual no serán contemplados en este proyecto.

CAPÍTULO 6. ANTECEDENTES
6.1 SGPG-UD
El proyecto de grado 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 realizado por
Juan Camilo Vargas Jerez en el año 2013, en el cual se hace el desarrollo de
un prototipo web SGPG-UD que permite gestionar los proyectos de grado de la
facultad de ingeniería, contemplándose las diferentes etapas realizadas en este
proceso para las modalidades de monografía y pasantía [2].
El proceso de cualquier modalidad en el sistema de divide en las etapas de pre

propuesta, propuesta, anteproyecto, proyecto e Informe final alineándose a lo
establecido en el acuerdo 001 del 2010 de la Universidad Distrital Francisco
José de Caldas.
Figura 1. Prototipo en SGPG-UD

Tomado de [2]. (Vargas Jerez, 2013)

6.2 UDLEARN
El proyecto de maestría llamado 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, Realizado por Yuri Vanessa Nieto Acevedo realizado
en el año 2015, propuso 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 [13].
El módulo facilita la gestión documental de trabajos de grado, la asignación de

evaluadores/jurados a los trabajos de grado, así como el seguimiento y el
cumplimento establecido para la evaluación de los mismos.
Figura 2. Módulo UDLearn.

Tomado de [13] (Acevedo Nieto, 2015)
UDLearn, es una evolución del prototipo realizado por Juan Camilo Vargas
Jerez,
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.

CAPÍTULO 7. MARCO TEORICO
7.1 EL PROCESO DE DESARROLLO SCRUM
Scrum es una de las metodologías ágiles más populares. Es una metodología

de adaptación, iterativa, rápida, flexible y eficaz, diseñada para ofrecer un valor
significativo de forma rápida en todo el proyecto. Scrum garantiza transparencia
en la comunicación y crea un ambiente de responsabilidad colectiva y de
progreso continuo. El marco de Scrum, está estructurado de tal manera que es
compatible con los productos y el desarrollo de servicio en todo tipo de
industrias y en cualquier tipo de proyecto, independientemente de su
complejidad [7].
El marco de trabajo Scrum consiste en los Equipos Scrum, roles, eventos,

artefactos y reglas asociadas. Cada componente dentro del marco de trabajo
sirve a un propósito específico y es esencial para el éxito de Scrum y para su
uso. Las reglas de Scrum relacionan los eventos, roles y artefactos,
gobernando las relaciones e interacciones entre ellos. Las reglas de Scrum se
describen en el presente documento.
7.2 GENERALIDADES
Scrum emplea un enfoque iterativo e incremental para optimizar la

predictibilidad y el control del riesgo, involucrando aspectos que son
significativos para el debido desarrollo de un proyecto son definidos tres pilares
soportan toda la implementación del control de procesos empírico:
transparencia, inspección y adaptación [7].
7.2.1. TRANSPARENCIA
Los aspectos significativos del proceso deben ser visibles para aquellos que
son responsables del resultado. La transparencia requiere que dichos aspectos
sean definidos por un estándar común, de tal modo que los observadores
compartan un entendimiento común de lo que se está viendo. Por ejemplo:
 Todos los participantes deben compartir un lenguaje común para

referirse al proceso; y,
 Aquellos que desempeñan el trabajo y aquellos que aceptan el producto

de dicho trabajo deben compartir una definición común de “Terminado”.

7.2.2. INSPECCIÓN
Los usuarios de Scrum deben inspeccionar frecuentemente los artefactos de

Scrum y el progreso hacia un objetivo, para detectar variaciones. Su inspección
no debe ser tan frecuente como para que interfiera en el trabajo. Las
inspecciones son más beneficiosas cuando se realizan de forma diligente por
inspectores expertos, en el mismo lugar de trabajo.
7.2.3. ADAPTACIÓN
Si un inspector determina que uno o más aspectos de un proceso se desvían

de límites aceptables, y que el producto resultante no será aceptable, el
proceso o el material que está siendo procesado deben ser ajustados. Dicho
ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.
Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la
inspección y adaptación, tal y como se describen en la sección Eventos de
Scrum del presente documento [7].
 Reunión de Planificación del Sprint (Sprint Planning Meeting)

 Scrum Diario (Daily Scrum)
 Revisión del Sprint (Sprint Review)
 Retrospectiva del Sprint (Sprint Retrospective)
7.3 ROLES
Son aquellos papeles que se requieren para producir el producto o servicio del
proyecto. Las personas a quienes se les asignan roles, están plenamente
comprometidas con el proyecto y son las responsables del éxito de cada
iteración y del resultado final.
En un Equipo Scrum se espera que intervengan tres roles: Product Owner,

Equipo de Desarrollo y ScrumMaster [7].
7.3.1 PRODUCT OWNER.
El Product Owner es la persona responsable del éxito del producto desde el

punto de vista de los stakeholders. Sus principales responsabilidades son:
 Determinar la visión del producto, hacia dónde va el equipo de desarrollo

 Gestionar las expectativas de los stakeholders
 Recolectar los requerimientos

 Determinar y conocer en detalle las características funcionales de alto y
de bajo nivel
 Generar y mantener el plan de entregas (release plan): fechas de
entrega y contenidos de cada una
 Maximizar la rentabilidad del producto
 Determinar las prioridades de cada una de las características por sobre
el resto
 Cambiar las prioridades de las características según avanza el proyecto,
acompañando así los cambios en el negocio
 Aceptar/rechazar el producto construido durante el Sprint y proveer
feedback valioso para su evolución
 Participar de la revisión del Sprint junto a los miembros del Equipo de
Desarrollo para obtener feedback de los stakeholders.
El Product Owner se focaliza en maximizar la rentabilidad del producto. La

principal herramienta con la que cuenta para poder realizar esta tarea es la
priorización. De esta manera puede reordenar la cola de trabajo del equipo de
desarrollo para que éste construya con mayor anticipación las características o
funcionalidades más requeridas por el mercado o la competitividad comercial
[7].
7.3.2 EQUIPO DE DESARROLLO.
El equipo de desarrollo está formado por todos los individuos necesarios para
la construcción del producto en cuestión. Es el único responsable por la
construcción y calidad del producto. El equipo de desarrollo es auto-
organizado. Es el mismo equipo quien determina la forma en que realizará el
trabajo y cómo resolverá cada problemática que se presente. La delimitación
de esta auto-organización, está dada por el objetivo a cumplir: transformar las
funcionalidades comprometidas en software funcionando y con calidad
productiva, o en otras palabras, producir un incremento funcional
potencialmente entregable.
Es recomendable que un equipo de desarrollo se componga de hasta nueve (9)

personas. Cada una de ellas debe poseer todas las habilidades necesarias
para realizar el trabajo requerido. Esta característica se conoce como multi-
funcionalidad y significa que dentro del equipo de desarrollo no existen
especialistas exclusivos, sino más bien individuos generalistas con
capacidades especiales. Lo que se espera de un miembro de un equipo de
desarrollo es que no solo realice las tareas en las cuales se especializa, sino
también todo lo que esté a su alcance para colaborar con el éxito del equipo [9].

El equipo de desarrollo tiene tres (3) responsabilidades tan fundamentales
como indelegables. La primera es proveer las estimaciones de cuánto esfuerzo
será requerido para cada una de las características del producto. La segunda
responsabilidad es comprometerse al comienzo de cada Sprint a construir un
conjunto determinado de características en el tiempo que dura el mismo. Y
finalmente, también es responsable por la entrega del producto terminado al
finalizar cada Sprint.
7.3.3 SCRUM MASTER.
El Scrum Master, es el Coach del equipo y es quien lo ayuda a alcanzar su

máximo nivel de productividad posible. Es un líder, facilitador, provocador,
detective y soplador de brasas. Líder por ser un ejemplo a seguir, facilitador por
fomentar contextos de apertura y discusión donde todos pueden expresar sus
opiniones y lograr consensos comunes, provocador por desafiar las estructuras
rígidas y las antiguas concepciones sobre cómo deben hacerse las cosas,
detective por involucrarse activamente en la búsqueda e identificación de
indicios y pistas en la narrativa del equipo y los individuos y finalmente,
soplador de brasas, “un socio facilitador del aprendizaje, que acompaña al otro
en una búsqueda de su capacidad de aprender para generar nuevas
respuestas” conectar a las personas con sus pasiones, con sus fuegos,
muchas veces apagados [7].
Las responsabilidades principales del Scrum Master son:
 Velar por el correcto empleo y evolución de Scrum.
 Facilitar el uso de Scrum a medida que avanza el tiempo. Esto incluye la

responsabilidad de que todos asistan a tiempo a las daily standup
meetings, reviews y feedbacks.
 Asegurar que el equipo de desarrollo sea multi-funcional y eficiente.
 Proteger al equipo de desarrollo de distracciones y trabas externas al

proyecto.
 Detectar, monitorear y facilitar la remoción de los impedimentos que

puedan surgir con respecto al proyecto y a la metodología.
 Asegurar la cooperación y comunicación dentro del equipo.

El Scrum Master es un Líder Facilitador, no es casualidad la aparición de un
nuevo nombre o rol. Este nuevo concepto del enfoque ágil, representa el
cambio respecto de las responsabilidades y el modelo de gestión de los
gerentes de proyectos tradicionales en relación al equipo de trabajo. El Scrum
Master puede ser visto como un Facilitador o Coach, incluso muchas veces se
lo referencia así en lugar de Scrum Master. Su responsabilidad es asegurar
que se cumpla con el proceso de Scrum sin interferir directamente en el
desarrollo del producto final. Es importante establecer que el equipo de Scrum
elige la forma de trabajo que más prefiera, siempre que se cumplan las pautas
básicas de Scrum, por ello mientras lo hagan no existe una forma “errónea” de
trabajar.
El rol del Scrum Master también incluye asegurar que el desarrollo del producto
tenga la mayor probabilidad de ser completado de forma exitosa. Para lograr
este cometido, trabaja de cerca con el Product Owner asegurando una correcta
priorización de los requerimientos, por un lado, y con el equipo de desarrollo
para convertir los requerimientos en un producto funcionando, por el otro.
7.3.4 NON-CORE ROLES.
Son los papeles que no son obligatoriamente necesarios para el proyecto

Scrum y pueden incluir miembros de los equipos que están interesados en el
proyecto. No tienen ningún papel formal en el equipo, pero pueden interactuar
con este, sin embargo, no pueden ser responsables del éxito del proyecto. Las
Non-core Roles deben tenerse en cuenta en cualquier proyecto de Scrum [7].
Non-core roles incluyen los siguientes:
 Socio(s): que es un término colectivo que incluye a los customers,

usuarios y patrocinadores, que con frecuencia interactúan con el Equipo
Principal de Scrum, e influyen en el project a lo largo de su desarrollo. Lo
más importante es que el proyecto produzca beneficios de colaboración
para los socios.
 Cuerpo de asesoramiento de Scrum: es una función opcional, que

generalmente consiste en un conjunto de documentos y/o un grupo de
expertos que normalmente están involucrados en la definición de
objetivos relacionados con la calidad, las regulaciones gubernamentales,
la seguridad y otros parámetros claves de la organización. El guía el
trabajo llevado a cabo por el Propietario del producto, Scrum Master y
Equipo Scrum.

 Jefe Propietario del producto: es un papel en los proyectos más grandes
con Equipos Scrums múltiples. Esta función se encarga de facilitar el
trabajo de los Propietario del producto y del mantenimiento de
Justificación del negocio para el project más grande.
 El Jefe Scrum Master es el responsable de coordinar las actividades

relacionadas con Scrum en grandes proyectos, las cuales pueden
requerir que varios Equipos Scrum trabajen en paralelo.

7.4 ELEMENTOS DE SCRUM.
El proceso de Scrum posee una mínima cantidad necesaria de elementos

formales para poder llevar adelante un proyecto de desarrollo. A continuación,
describiremos cada uno de ellos.
7.4.1 PRODUCT BACKLOG.
También conocido como Pila del Producto, es básicamente un listado de ítems

o características del producto a construir, mantenido y priorizado por el Product
Owner. Es importante que exista una clara priorización, ya que es esta
priorización la que determinará el orden en el que el equipo de Proyectos
Ágiles con Scrum desarrollo transformará las características en un producto
funcional acabado.
Esta prioridad es responsabilidad exclusiva del Product Owner y, aunque el

equipo de desarrollo pueda hacer sugerencias o recomendaciones, es el
Product Owner quién tiene la última palabra sobre la prioridad final de los ítems
del Product Backlog, teniendo en cuenta el contexto de negocio. Una forma de
priorizar los ítems del Product Backlog es según su valor de negocio. Podemos
entender el valor de negocio como la relevancia que un ítem tiene para el
cumplimiento del objetivo de negocio que estamos buscando [9].
7.4.2 SPRINT BACKLOG.
Es el conjunto de Product Backlog Items (PBIs) que fueron seleccionados para

trabajar en ellos durante un cierto Sprint, conjuntamente con las tareas que el
equipo de desarrollo ha identificado que debe realizar para poder crear un
incremento funcional potencialmente entregable al finalizar el Sprint.
El resultado de cada Sprint debe ser un incremento funcional potencialmente

entregable. Incremento funcional porque es una característica funcional nueva
(o modificada) de un producto que está siendo construido de manera evolutiva.
El producto crece con cada Sprint. Potencialmente entregable porque cada una
de estas características se encuentra lo suficientemente validada y verificada
como para poder ser desplegada en producción (o entregada a usuarios
finales) si así el negocio lo permite o el cliente lo desea [9].
7.4.3 SPRINT.
Las iteraciones en Scrum se conocen como Sprints. Scrum, como todos los
enfoques ágiles, es un proceso de desarrollo incremental e iterativo. Esto

significa que el producto se construye en incrementos funcionales entregados
en periodos cortos para obtener feedback frecuente.
En general, Scrum tiene una duración de Sprint de entre 1 y 2 semanas y el

objetivo será mantener esta duración constante a lo largo del desarrollo del
producto, lo que implicará que la duración de una iteración no cambie una vez
que sea establecida.
7.4.4 SPRINT PLANNING MEETING.
La planificación de Sprint se da al comienzo de cada Sprint se realiza una

reunión de planificación del Sprint donde serán generados los acuerdos y
compromisos entre el equipo de desarrollo y el Product Owner sobre el alcance
del Sprint.
Esta reunión de planificación habitualmente se divide en dos partes con

finalidades diferentes: una primera parte estratégica y enfocada en el “qué”, y
una segunda parte táctica cuyo hilo conductor principal es el “cómo”.
7.4.5 SCRUM DIARIO.
Uno de los beneficios de Scrum está dado por el incremento de la

comunicación dentro del equipo de proyecto. Esto facilita la coordinación de
acciones entre los miembros del equipo de desarrollo y el conocimiento “en
vivo” de las dependencias de las actividades que realizan.
Por otro lado, se requiere además aumentar y explicitar los compromisos

asumidos entre los miembros del equipo de Proyectos Ágiles con Scrum
desarrollo y dar visibilidad a los impedimentos que surjan del trabajo que está
siendo realizando y que muchas veces nos impiden lograr los objetivos,
mediante las reuniones diarias de Scrum (Daily Scrums) se pretende lograr los
siguientes objetivos:
1. Incrementar la comunicación
2. Explicitar los compromisos
3. Dar visibilidad a los impedimentos
Estas reuniones tienen, como su nombre lo indica, una frecuencia diaria y no

deberían llevar más de 10 minutos. Estos 10 minutos son un timebox, es decir,
que no se pueden superar.

7.4.6 REVISIÓN DE SPRINT.
Al finalizar cada Sprint se realiza una reunión de revisión del Sprint (Sprint
Review), donde se evalúa el incremento funcional potencialmente entregable
construido por el equipo de desarrollo (el “qué”). En esta reunión el Equipo
Scrum y los Stakeholders revisan el resultado del Sprint. Cuando decimos
“resultado” hablamos de “producto utilizable” y “potencialmente entregable” que
el los interesados utilizan y evalúan durante esta misma reunión, aceptando o
rechazando así las funcionalidades construidas [7].
Los Stakeholders evalúan el producto construido y proveen feedback. Este

feedback puede ser acerca de cambios en la funcionalidad construida o bien
nuevas funcionalidades que surjan al ver el producto en acción.
Toda la retroalimentación que los stakeholders aporten debe ser ingresada

como PBIs en el Product Backlog. Para esto, los PBIs nuevos deben ser
priorizados con respecto a todos los ya existentes en el Product Backlog.
También es necesario que estos nuevos PBIs sean estimados antes de
incluirlos como parte del Product Backlog ya que el Product Owner deberá
decidir cuáles de los PBIs existentes cuya estimación de costo es similar a la
de los nuevos PBIs deben ser eliminados para no incurrir en el incremento
desmedido del alcance (Scope Creeping): si se agrega trabajo entonces
debemos quitar trabajo de otro lado. El Product Owner cuenta para esto con la
priorización de los ítems del Backlog como herramienta para la toma de este
tipo de decisiones [9].
7.4.7 FEEDBACK.
En una metodología como Scrum, la retrospección del equipo es el corazón de

la mejora continua y las prácticas emergentes. Mediante el mecanismo de
retrospección, el equipo reflexiona sobre la forma en la que realizó su trabajo y
los acontecimientos que sucedieron en el Sprint que acaba de concluir para
mejorar sus prácticas. Todo esto sucede durante la reunión de feedback.
7.4.8 RELEASE
El release se compone de dos procesos
 Envío de entregables: los Accepted Deliverables se les entregan a los

Socios relevantes. Un acuerdo formal llamado Working Deliverables
Agreement documenta la finalización con éxito del Sprint.

feedback del proyecto: En este proceso, que completa el proyecto, los socios y
miembros principales del del Equipo Principal de Scrum se reúnen para hacer
una feedback del proyecto e identificar, documentar e internalizar las lecciones
aprendidas. A menudo, estas lecciones llevan a la documentación de Agreed
Actionable Improvement, que se aplicará en futuros proyectos.
7.4.9 IDENTIFICACIÓN DE FUNCIONALIDADES DEL SOFTWARE
Para realizar la identificación de las funcionalidades se deberá tener en cuenta

todos los roles identificados, efectuando sucesivas “pasadas” por todos los
procesos de negocio y evaluando que cada uno de los roles involucrados en
ellos cuenten con las funcionalidades requeridas para la realización de sus
objetivos. Al igual que la identificación de roles, esta actividad se realiza en
forma colaborativa junto al Product Owner y la mayor cantidad de miembros del
equipo posible [7].

7.5 HISTORIA DE USUARIO
Las Historias de Usuario surgieron en eXtremme Programming (XP) como una

respuesta a una situación habitual en los proyectos de desarrollo de software:
los clientes o especialistas de negocio se comunican con los equipos de
desarrollo a través de extensos documentos conocidos como especificaciones
funcionales. A su vez, las especificaciones funcionales son la documentación
de supuestos y están sujetas a interpretaciones, lo que causa malos
entendidos y que finalmente el software construido no se corresponda con la
realidad esperada [9].
7.5.1 COMPONENTES
Una Historia de Usuario se compone de 3 elementos, también conocidos como

“las tres Cs” de las Historias de Usuario:
 Card (Ficha): Toda historia de usuario debe poder describirse de manera

corta en una ficha. Si una Historia de Usuario no puede describirse en
ese tamaño, es una señal de que estamos traspasando las fronteras y
comunicando demasiada información que debería compartirse cara a
cara.
 Conversación: Toda historia de usuario debe tener una conversación

con el Product Owner. Una comunicación cara a cara que intercambia
no solo información sino también pensamientos, opiniones y
sentimientos.
 Confirmación: Toda historia de usuario debe estar lo suficientemente

explicada para que el equipo de desarrollo sepa qué es lo que debe
construir y qué es lo que el Product Owner espera. Esto se conoce
también como Criterios de Aceptación.
7.5.2 REDACCIÓN
La redacción para una historia de usuario debe cumplir los siguientes criterios:
 Primera Persona: La redacción en primera persona de la Historia de

Usuario invita a quien la lee a ponerse en el lugar del usuario.
 Priorización: Tener esta estructura para redactar la Historia de Usuario

ayuda al Product Owner a priorizar. Si el Product Backlog es un conjunto
de ítems como “Permitir crear un evento tentativo”, “Confirmar un evento

tentativo”, “Notificar al responsable de logística”, “Ver el estado de
inscripciones”, etc. el Product Owner debe trabajar más para
comprender cuál es la funcionalidad, quién se beneficia y cuál es el valor
de la misma.
 Propósito. Conocer el propósito de una funcionalidad permite al equipo

de desarrollo plantear alternativas que cumplan con el mismo propósito
en el caso de que el costo de la funcionalidad solicitada sea alto o su
construcción no sea viable.
7.5.3 DEFINICIÓN DE TERMINADO
También conocido como Definition of Done, es el conjunto de características

que una Historia de Usuario debe cumplir para que el equipo de desarrollo
pueda determinar si ha terminado de trabajar en ella. Un típico criterio de
“Terminado” podría ser [7]:
 Todos los criterios de aceptación funcionan correctamente

 Todos los archivos fuentes están en el repositorio de código fuente y el
build se ejecutó exitosamente.
 El Product Owner da su visto bueno de la funcionalidad construida antes
de llegar a la Review Meeting.

7.6 DIAGRAMA BPMN
Es la captura de una secuencia de actividades de negocio, y de la información

de soporte. Los procesos de negocio describen la manera cómo una empresa
alcanza sus objetivos, BPMN (Business Process Modeling Notation) es el
nuevo estándar para el modelado de procesos de negocio y servicios web, es
una notación a través de la cual se expresan los procesos de negocio en un
diagrama de procesos de negocio (BPD) Este estándar agrupa la planificación
y gestión del flujo de trabajo, así como el modelado y la arquitectura [12].
7.6.1 CARACTERÍSTICAS
 Proporciona un lenguaje gráfico común, con el fin de facilitar su

comprensión a los usuarios de negocios.
 Integra las funciones empresariales.
 Utiliza una Arquitectura Orientada por Servicios (SOA), con el objetivo

de adaptarse rápidamente a los cambios y oportunidades del negocio.
 Combina las capacidades del software y la experiencia de negocio para

optimizar los procesos y facilitar la innovación del negocio.
7.6.2 ELEMENTOS
La función del BPMN es crear un mecanismo simple para realizar modelos de

procesos de negocio, con todos sus elementos gráficos, y que al mismo tiempo
sea posible gestionar la complejidad. El método elegido para manejar estos dos
conflictivos requisitos es organizar los aspectos gráficos de la notación en
categorías específicas [12]. Las cuatro categorías básicas de elementos son:
 Tarea: Una tarea es una actividad atómica que está incluida dentro de
un proceso. Se habla de tarea cuando el trabajo que representa en el
proceso no puede desglosarse en un nivel mayor de detalle.
 Subproceso: Un subproceso es un conjunto de actividades incluidas

dentro de un proceso. Puede desglosarse en diferentes niveles de
detalle denominadas tareas.
 Gateway (compuerta): Se representa con un diamante, y se emplea para

controlar la divergencia o convergencia de la secuencia de flujo. Éstas

determinan ramificaciones, bifurcaciones, combinaciones y fusiones del
proceso.
 Objetos conectores: Conectan los objetos de flujo de un proceso, y

definen el orden de ejecución de las actividades.
 Swimlanes (canales): Son un mecanismo empleado para organizar

actividades en categorías separadas visualmente, con el fin de ilustrar
diferentes capacidades funcionales o responsabilidades.
 Artefactos: Son objetos gráficos que proveen información adicional de

los elementos dentro de un proceso, sin afectar el flujo del proceso.

7.7 POSTGRESQL
PostgreSQL es un sistema de gestión de bases de datos objeto-relacional,

distribuido bajo licencia BSD y con su código fuente disponible libremente. Es
el sistema de gestión de bases de datos de código abierto más potente del
mercado y en sus últimas versiones no tiene nada que envidiar a otras bases
de datos comerciales.
PostgreSQL utiliza un modelo cliente/servidor y usa multiprocesos en vez de

multihilos para garantizar la estabilidad del sistema. Un fallo en uno de los
procesos no afectará el resto y el sistema continuará funcionando [11].
Figura 3 Componente del sistema postgreSQL

tomado de [14]
 Aplicación cliente: Esta es la aplicación cliente que utiliza PostgreSQL

como administrador de bases de datos. La conexión puede ocurrir via
TCP/IP ó sockets locales.
 Demonio postmaster: Este es el proceso principal de PostgreSQL. Es el

encargado de escuchar por un puerto/socket por conexiones entrantes
de clientes. Tambien es el encargado de crear los procesos hijos que se

encargaran de autentificar estas peticiones, gestionar las consultas y
mandar los resultados a las aplicaciones clientes
 Ficheros de configuracion: Los 3 ficheros principales de configuración

utilizados por PostgreSQL, postgresql.conf, pg_hba.conf y pg_ident.conf
 Procesos hijos postgres: Procesos hijos que se encargan de autentificar

a los clientes, de gestionar las consultas y mandar los resultados a las
aplicaciones clientes
 PostgreSQL share buffer cache: Memoria compartida usada por

POstgreSQL para almacenar datos en caché.
 Write-Ahead Log (WAL): Componente del sistema encargado de

asegurar la integridad de los datos (recuperación de tipo REDO)
 Kernel disk buffer cache: Caché de disco del sistema operativo
 Disco: Disco físico donde se almacenan los datos y toda la información

necesaria para que PostgreSQL funcione.
7.7.1 CARACTERÍSTICAS
Sus características técnicas la hacen una de las bases de datos más potentes
y robustas del mercado. Su desarrollo comenzo hace más de 16 años, y
durante este tiempo, estabilidad, potencia, robustez, facilidad de administración
e implementación de estándares han sido las características que más se han
tenido en cuenta durante su desarrollo. PostgreSQL funciona muy bien con
grandes cantidades de datos y una alta concurrencia de usuarios accediendo a
la vez al sistema [11].
Generales
 Es una base de datos 100% ACID

 Integridad referencial
 Tablespaces
 Nested transactions (savepoints)
 Replicación asincrónica/sincrónica / Streaming replication - Hot Standby
 PITR - point in time recovery
 Copias de seguridad en caliente (Online/hot backups)
 Unicode
 Juegos de caracteres internacionales

 Multi-Version Concurrency Control (MVCC)
 Multiples métodos de autentificación
 Acceso encriptado via SSL
 Actualización in-situ integrada (pg_upgrade)
 SE-postgres
 Licencia BSD
Programación / Desarrollo
 Funciones/procedimientos almacenados (stored procedures) en

numerosos lenguajes de programacion, entre otros PL/pgSQL (similar al
PL/SQL de oracle), PL/Perl, PL/Python y PL/Tcl
 Bloques anónimos de código de procedimientos (sentencias DO)
 Soporta el almacenamiento de objetos binarios grandes (gráficos,
videos, sonido, ...)
 APIs para programar en C/C++, Java, .Net, Perl, Python, Ruby, Tcl,
ODBC, PHP, Lisp, Scheme, Qt y muchos otros.
SQL
 Llaves primarias (primary keys) y foráneas (foreign keys)

 Check, Unique y Not null constraints
 Restricciones de unicidad postergables (deferrable constraints)
 Columnas auto-incrementales
 Indices compuestos, únicos, parciales y funcionales en cualquiera de los
metodos de almacenamiento disponibles, B-tree, R-tree, hash ó GiST
 Sub-selects
 Consultas recursivas
 Joins
 Vistas (views)
 Disparadores (triggers) comunes, por columna, condicionales.
 Reglas (Rules)
 Herencia de tablas (Inheritance)
 Eventos LISTEN/NOTIFY
Tomado de [11].

CAPÍTULO 8. METODOLOGÍA
La Oficina Asesora de Sistemas ha trabajado con el proceso de desarrollo

OPENUP/OAS pero se ha planteado un cambio al proceso de desarrollo al de
SCRUM, Que fue el proceso base sobre el cual se desarrolló la metodología de
este proyecto para lograr los objetivos antes planteados.
8.1 MARCO METODOLÓGICO
En el marco metodológico se indican los procesos y fases llevados a cabo por

SCRUM, en cada uno de estos se indican las actividades y herramientas a
utilizarse para el ágil desarrollo del proyecto.
8.1.1. PROCESO SCRUM
Es un proceso en el que se aplican de manera regular un conjunto de buenas

prácticas para trabajar colaborativamente, en equipo, y obtener el mejor
resultado posible de un proyecto. Estas prácticas se apoyan unas a otras y su
selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos, a continuación, se presenta una tabla que resalta los
subprocesos planteados por SCRUM de manera general definidos por cinco
fases que son: inicio, planteamiento y estimación, implementación, Revision y
feedback y lanzamiento.
FASE PROCESOS
1. Inicial 1.1 Crear la visión del proyecto: En este proceso se pretende

crear una Declaración de la Visión del Proyecto que servirá de
inspiración y proporcionará un enfoque de todo el proyecto.
1.2 Crear documento plan general del proyecto:

Define los parámetros para realizar el direccionamiento y
seguimiento al proyecto.
Especifica los objetivos.
Describe cómo está organizado el proyecto cuales
son los recursos requeridos para su consecución
(Tiempo, Tecnológicos, Financieros, Físicos y Humanos entre
otros).
1.3 Modelo relacional: es la representación en tablas

(esquema) del proyecto, el cual es prácticamente un paso
antes del nivel físico debe ir aprobado por el comité
conformado en la oficina, este se realizará por medio de la app
schemaspy.
1.4. Identificar al Scrum Master y al Stakeholder(s)): En este

proceso, el Scrum Master y el Stakeholder se identifican
utilizando criterios de selección específicos.
1.5 Formación de un equipo Scrum: En este proceso, se

identifican a los miembros del Equipo Scrum. Normalmente, el
Product Owner es el responsable principal de la selección de
los miembros del equipo, pero a menudo lo hace en
Colaboración con el Scrum Master.
1.6 Realizar un cronograma general: Se debe establecer un

cronograma sencillo de todo el proyecto mostrando el tiempo
de cada fase
1.6 Desarrollo de Epics: En este proceso, el Declaración de la

Visión del Proyecto sirve como la base para el desarrollo de
Epics.
1.7 Creación de la lista priorizada de pendientes del producto.

En este proceso, Epic(s) son refinados, elaborados, y luego
priorizados para crear un Prioritized Product Backlog. Los Done
Criteria también se establecen en este punto.
1.8. Realizar el plan de lanzamiento: En este proceso, el

Equipo de Scrum revisa los User Stories en el Prioritized
Product Backlog para desarrollar un Release Planning
Schedule, que es esencialmente un programa de
implementación por fases que se puede compartir con los
socios del project.
2. Planear y 2.1 Levantamiento de proceso a desarrollar (flujograma,

estimar prototipo e historia de usuario): El flujograma debe estar en
jbpm, el prototipo en pencil y la historia de usuario en Tuleap
teniendo en cuenta las características de esta guía, de igual
manera las historias de usuario deben estar relacionadas con
un epic.
2.2 Aprobar, estimar y asignar historias de usuarios: En este

proceso, el Producto Owner aprueba los User Stories para un
Sprint. Luego, el Scrum Master y el Equipo Scrum estiman el
esfuerzo necesario para desarrollar la funcionalidad descrita en
cada historia de usuario, y el Equipo Scrum se compromete a
entregar los requisitos del customer en forma de Approved,
Estimated, and Committed User Stories.
2.3 Elaboración de tareas: En este proceso, los Approved,

Estimated, and Committed User Stories se dividen en tareas
específicas y se compilan en un Task List. A menudo, un Task
Planning Meeting se convocará al efecto.
2.4 Estimar tareas: En este proceso, el Equipo Principal de

Scrum durante reuniones de Estimación del Labor estima el
esfuerzo necesario para realizar cada tarea del listado de
tareas. El resultado de este proceso es un Effort Estimated
Task List.
2.5 Elaboración de la lista de pendientes del Sprint (Create

Sprint Backlog): En este proceso, el Equipo Principal de Scrum
lleva a cabo un Sprint Planning Meeting donde el grupo crea un
Sprint Backlog que contiene todas las tareas que deben
completarse en el Sprint.
3. 3.1 Crear entregables: En este proceso, el Equipo Scrum

Implementar trabaja en las tareas del Sprint Backlog para crear Sprint
Deliverables. Se utiliza a menudo un Scrumboard para realizar
el seguimiento del trabajo y de actividades que se llevan a
cabo. Las cuestiones o problemas que enfrenta el Equipo
Scrum podrían ser actualizadas en un Impediment Log.
3.2 Llevar a cabo el Sprint Standup diario: En este proceso,

todos los días se lleva a cabo una reunión que es Time-box
altamente concentrada que se refiere como Daily Standup
Meeting. Es aquí donde los miembros del Equipo Scrum se
actualizan el uno al otro referente a sus progresos y sobre los
Impedimentos que puedan enfrentar.
3.3 Mantenimiento de la lista priorizada de pendientes del

producto: En este proceso, el Prioritized Product Backlog se
actualiza y se mantiene continuamente. Un Prioritized Product
Backlog Review Meeting puede ser considerado, en el que se
discute y se incorpora el Prioritized Product Backlog de forma

apropiada.
4. Revisión y 4.1 Demostración y validación del Sprint: En este proceso, el

feedback Equipo Scrum le demuestra el Sprint Deliverable al Propietario
del producto y a los Socios relevantes en un Sprint Review
Meeting. El propósito de esta reunión es asegurar la
aprobación y aceptación del Propietario del producto de los
Entregables creados en el Sprint.
4.2 feedback de Sprint: este proceso, el Scrum Master, el

product owner y el Equipo Scrum se reúnen para discutir las
lecciones aprendidas a lo largo del Sprint. Esta información se
documenta como las lecciones aprendidas que pueden
aplicarse a los futuros Sprints. A menudo, como resultado de
esta discusión, puede haber Agreed Actionable Improvements
o recomendaciones actualizadas por parte del Cuerpo de
asesoramiento de Scrum.
5. 5.1 Envío de entregables: En este proceso, el Equipo Scrum le

Lanzamiento demuestra el Sprint deliverable al Propietario del producto y a
los Socios relevantes en un Sprint Review Meeting. El
propósito de esta reunión es asegurar la aprobación y
aceptación del Propietario del producto de los Entregables
creados en el Sprint.
5.2 feedback del proyecto: En este proceso, que completa el

proyecto, los socios, el product owner y el Equipo Scrum se
reúnen para hacer una feedback del proyecto e identificar,
documentar e internalizar las lecciones aprendidas. A menudo,
estas lecciones llevan a la documentación de Agreed
Actionable Improvement, que se aplicará en futuros proyectos.
Tabla 1Proceso Metodológico SCRUM
Tomado de [7]

8.1.1.1. GENERALIDADES
En busca de optimizar el trabajo se decidió tener a consideración el conjunto de

buenas prácticas en el desarrollo de un producto propuestas por el proceso
OpenUP/OAS 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 [5]. 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 continua del producto para 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 como

realizar el trabajo para alcanzar los objetivos y metas proyectadas.
Los principios en que se enmarca el método de trabajo OPENUP/OAS son:
a. Conocer a los Interesados: Se deben identificar, conocer a los grupos de

interés y trabajar de cerca con ellos para asegurarse que sus
necesidades son claramente definidas e incrementalmente satisfechas a
medida que se evoluciona en el desarrollo de la solución. Debe
mantenerse una comunicación abierta y frecuente además de una
colaboración entre ellos y el equipo de trabajo.
b. Separar el Problema de la Solución: Se debe estar seguro que se

conoce el problema (o una parte de él) antes de definir una solución (o
una parte de ella). Al separar claramente el problema (que necesita el
cliente - no que necesita el equipo de desarrollo) de la solución (el
sistema que tiene que hacer), es fácil mantener un enfoque y encontrar
vías alternativas para solucionar el problema.

c. Crear un conocimiento compartido del dominio: Se debe fomentar un
ambiente de intercambio y trabajo en el que todos los involucrados
puedan obtener constantemente la información adecuada para lograr
tener una visión compartida de lo que se debe hacer, el por qué hacerlo
y cómo se está haciendo.
d. Usar escenarios y casos de uso para capturar requerimientos: Hacer uso

de escenarios y casos de uso para capturar los requerimientos
funcionales del sistema permiten que los interesados alcancen
rápidamente un consenso acerca de sus necesidades e intereses.
e. Establecer y mantener contratos de prioridades: Se deben priorizar los
requisitos y requerimientos de implementación basados en un trabajo
continuo con los grupos de interés y tomar decisiones que lleven a que
el sistema siempre incremente los beneficios ofrecidos y reduzca los
riesgos.
f. Realizar negociaciones que maximicen el beneficio obtenido: Las

negociaciones costo beneficio dentro del proyecto no pueden ser
independientes de la arquitectura. Los requisitos y requerimientos
establecen los beneficios que se deben alcanzar al implementar el
sistema mientras que la arquitectura es una medida base para calcular
el costo del mismo. El costo asociado con un beneficio puede influenciar
en gran medida la percepción del usuario acerca del valor real obtenido.
g. Gestionar el entorno: El cambio es inevitable, y aunque presenta

oportunidades para mejorar los beneficios dados a los grupos de interés,
un entorno incontrolado de cambios fácilmente decantará en sistemas
deficientes, sobredimensionados y que no satisfacen las necesidades
reales de los clientes. Se debe gestionar los cambios manteniendo
contratos específicos con los grupos de interés.
h. Conocer cuándo se debe parar: Sobrecargar de características un

sistema no sólo es una pérdida de tiempo y recursos, sino que conduce
a sistemas innecesariamente complejos. El desarrollo debe parar
cuando la calidad esperada del sistema se alcanza.
i. Mantenga un entendimiento común: Sea proactivo comunicando y

compartiendo información con los participantes del proyecto y no asuma
que todos y cada uno encontrarán justo lo que ellos necesitan saber o
que cada persona tiene la misma comprensión del proyecto que todos
los demás.

j. Aprender continuamente: Desarrolle continuamente sus habilidades
técnicas e interpersonales, aprenda de los ejemplos de sus colegas,
aproveche la oportunidad, tanto de ser un estudiante de sus colegas, así
como maestro de ellos. Siempre incremente su habilidad personal para
sobrellevar su propio antagonismo hacia otros miembros del equipo.
k. Organice alrededor de la arquitectura: La comunicación entre los

miembros del equipo empieza a ser compleja incrementalmente. Por
consiguiente, organice el equipo alrededor de la arquitectura, el
vocabulario y el modelo mental compartido del sistema.
l. Desarrolle su proyecto en iteraciones: Divida su proyecto en una serie

de iteraciones encajadas en el tiempo y planee su proyecto
iterativamente. Esta estrategia iterativa lo habilita para entregar
capacidades incrementalmente, como un conjunto ejecutable,
subconjunto utilizable de requisitos y requerimientos probados e
implementados, que pueden ser evaluados por los interesados al final de
cada iteración.
m. Gestione los riesgos: Ataque tempranamente los riesgos que atacarán el

proyecto. Continuamente identifique y priorice los riesgos y entonces
idee estrategias para mitigarlos.
n. Adopte y gestione el cambio: Adoptar los cambios ayuda a construir un

sistema que se encamina a las necesidades de los interesados y
manejar los cambios permite reducir costos y mejorar la predicción de
estos cambios. Los cambios hechos tempranamente en el proyecto se
pueden hacer usualmente a bajo costo. A medida que usted avanza en
el proyecto, los cambios pueden empezar a incrementarse en términos
de costos.
o. Mida el progreso objetivamente: Si no conoce objetivamente cómo su

proyecto está progresando, no sabe si éste falla o tiene éxito. La
incertidumbre y los cambios a un proyecto de software en progreso
dificultan medirlo objetivamente, en tanto que las personas tienen una
habilidad muy asombrosa para creer que todo está bien ante la
catástrofe.

8. 2 EL MÉTODO DE TRABAJO
SCRUM como método, enfatiza valores y prácticas de gestión, sin pronunciarse

sobre requerimientos, prácticas de desarrollo, implementación y demás
cuestiones técnicas. Este delega completamente al equipo la responsabilidad
de decidir la mejor manera de trabajar, y de esta manera ofrece comodidad y
rendimiento para ser lo más productivo posible; por esta característica se
complementó durante la ejecución del proyecto métodos, procedimientos y
herramientas utilizados en otras metodologías como por ejemplo
OpenUP/OAS.
8.2.1. FASES DEL PROYECTO
El rol planteado dentro de este proyecto hace parte del equipo de desarrollo,
realizando las funciones de analista y arquitecto de la base de datos sobre las
modalidades antes contempladas, también se contempla colaborar en las
etapas de desarrollo y pruebas que no serán presentadas en este proyecto,
debido a que el proceso se trabajara por fases a continuación presentamos las
practicas que se realizarán sobre cada fase en el proyecto teniendo en cuenta
que en cada una de estas se seguirá la metodología de SCRUM.
8.2.1.1 FASE INICIAL
En esta fase es necesario realizar una colaboración entre los integrantes del
equipo de desarrollo y el product owner o los interesados (Stakeholders) para
determinar los objetivos y la viabilidad del proyecto a realizarse.
Se realiza un primer sprint el cual tiene como objetivo realizar plan general
(ítem 1.2 de la tabla del proceso metodológico SCRUM), en la cual se plantean
los parámetros para realizar el direccionamiento y seguimiento al
proyecto, define cada uno de los sprints a realizarse y su duración para la
elaboración del proyecto, y describe cómo está organizado el proyecto, cuales
son los recursos requeridos para su consecución (Tiempo,
Tecnológicos, Financieros, Físicos y Humanos entre otros).
Se realiza un análisis sobre el sistema a implementarse con el fin de

comprender y describir de forma simplificada la totalidad del negocio.

8.2.1.2 FASE INTERMEDIA
En esta fase se realiza el proceso de comprensión y manejo del sistema, donde

se analiza de manera más precisa los requerimientos a tener en cuenta para la
funcionalidad del sistema en su totalidad, partiendo del análisis de cada uno de
sus componentes.
Se utilizan mecanismos para el levantamiento de requerimientos que permiten

una mejor comprensión del negocio por parte del cliente y del equipo de
trabajo, de esta manera es posible tener en cuenta situaciones que podrían
presentarse y que no se hallan tenido en cuenta con anterioridad. Se hace uso
de representación en flujogramas de BPMN utilizando la herramienta de
Eclipse Modeling Framework jbpm, y se crean prototipos no funcionales cuyo
objetivo sea la visualización de posibles interfaces para el desarrollo, por
ejemplo, formularios, menús, logins, etc., estos prototipos serán realizados en
pencil.
Se realizarán reuniones con el product owner e interesados para discutir acerca

del levantamiento de requerimientos, el análisis de los flujogramas y la creación
de prototipos, de esta manera conseguir una buena retroalimentación para ser
más exactos en lo que se requiere en la construcción del producto a
implementarse.
A partir de los requerimientos se definen todos los posibles roles que estarán
presentes en el sistema, y cada uno de estos con sus respectivas
funcionalidades en el sistema.
8.2.1.2 FASE FINAL
En esta fase se construye el modelo de datos en base a los requerimientos

antes completados, se realiza el modelo relacional que se encargue de
mantener la integridad de la información para todas las modalidades de
trabajos de grado estipuladas en el acuerdo N° 038 del 28 de julio de 2015 de
manera óptima y ordenada, en este modelo se debe contemplar la integración
con otras bases de datos cuando sea necesario.
Se realizan reuniones con el experto DBA delegado por la oficina (OAS) para
cumplir con los requerimientos de diseños implementados en la oficina y para
corregir aspectos que no se hallan tenido en cuenta.

Se analizan y crean los permisos para cada uno de los diferentes roles
existentes en el sistema sobre las tablas implementadas en el modelo de la
base de datos.

CAPÍTULO 9. INGENIERIA DEL PROYECTO
El desarrollo del proyecto se realizó siguiendo los lineamientos de la

metodología de SCRUM y acoplándose a las fases antes mencionadas,
partiendo de la construcción del plan general, hasta la creación del modelo de
datos óptimo para el sistema.
Al hacer el análisis sobre el sistema a realizarse y los requerimientos a

solucionar se encontró que era posible para el negocio generalizar varios
aspectos que atañen a las modalidades de grado, de esta forma se listaron los
aspectos en común y se trazó un flujo general del negocio y para las demás
características propias de cada modalidad se realizó un análisis individual
sobre cada modalidad fusionando el flujo general y las características propias o
extras de la modalidad, de esta forma fue posible la creación de un modelo
soporte la integridad de los datos para todas las modalidades.
9.1. PLAN GENERAL
Para la construcción del plan general se tomaron en cuenta aspectos como la

duración de la pasantía, la complejidad del negocio, el manejo de herramientas
a utilizarse, los recursos y el presupuesto para realizarse, se construyó un
modelo en el cual se muestra cada iteración o sprint del proyecto en cada una
se repite un proceso de trabajo iterativo, para de esta manera proporcionar un
resultado completo sobre el producto final.
 Comprensión del Negocio

 Planeación del proyecto
Modelado del  Traza de objetivos
negocio  Análisis de modalidades
 Definición de roles
Requerimientos
 Especificación de requerimientos
 Análisis de requerimientos
 Generalización de procesos
Analisis  Modelamiento procesos de
negocio.
 Construcción de prototipos
 Diseño base de datos Diseño
 Diccionario de datos
Figura 4. Fases del plan general

Autoría propia

Modelado del negocio:
El modelado del negocio tiene como objetivo el análisis y la comprensión

simple general de la realidad y funcionalidad del negocio. En esta fase se
plantea un marco de trabajo base para el desarrollo del proyecto, basado en la
complejidad del mismo, se socializan aspectos con el prodct owner para
determinar el posible encaminamiento del proyecto.
Requerimientos:
Se realiza el análisis de los requerimientos con el propósito de especificar

detalladamente las funcionalidades que deberán ser soportadas por el sistema
a realizarse, una vez obtenidos los requerimientos se construyen historias de
usuario generales y se crean los respectivos prototipos.
Análisis:
En el análisis se toman los requerimientos antes especificados y se propone la

forma de tratarlos, aquí se definen las características que deberá presentar el
diseño para el soporte de la implementación de los requerimientos de manera
efectiva, también se representan los procesos del sistema mediante el uso de
flujogramas que dan un mejor entendimiento del negocio.
Diseño:
En esta fase se construye en base a lo antes analizado el diseño de la base de

datos, definiendo inicialmente el rol de los entes que interactúan en el sistema,
los controles que se llevaran a cabo en la base de datos, y la interacción que
esta tendrá con otros esquemas manejados por la oficina.
A continuación se muestra en la tabla 2. Las actividades y duración de cada

sprint contemplado en el plan general; Las historias de usuario pueden ser
consultadas en el anexo 1.

Sprint Duración Actividades
Comprensión del 1 Semana Reunión con el Product Owner.
Negocio Lectura y comprensión del acuerdo 038 de
2015.
Reunión con el equipo de desarrollo.
Planeación del 1 Semana y Establecer recursos
proyecto y Traza 3 días Calcular presupuesto
de objetivos Reunión con Scrum Master
Realizar plan general
Análisis del negocio
Objetivos, alcances y limitaciones
Análisis de 1 Semana Reunión Product Owner
modalidades Análisis Acuerdo 038 de 2015
Definición de modalidades
Definición de roles 3 Días Reunión Product Owner
Reunión Scrum Master
Especificación de actores y roles
Especificación de 2 Semanas Reunión Product Owner
requerimientos Listar requerimientos funcionales
Listar requerimientos no funcionales
Análisis de 4 Días Reunión equipo de desarrollo.
requerimientos Análisis y descarte de procesos no
contemplados para el Acuerdo 038 de 2015
Generalización de 2 Semanas Comparación de procesos
procesos Planteamiento de procesos generales
Comparación de procesos en modalidades
Modelamiento 1 Semana Construcción de BPMN general
procesos de Construcción de BPMN por modalidad
negocio Reunión equipo de desarrollo.
Construcción de 2 Semanas Diseño de prototipos o mockups propuestos
prototipos para la fase de desarrollo.
Reunión equipo de desarrollo.
Reunión con Product Owner
Diseño base de 5 Semanas Diseño del modelo de la base de datos
datos y diccionario Reunión con arquitecto
de datos Reunión con DBA
Documentación del modelo de la base de datos
Tabla 2. Cronograma de Sprints en SCRUM para el desarrollo del proyecto, Autoría propia

9.1.1. RECURSOS
Para la realización de este proyecto fueron necesarios recurso humano,

infraestructura y tiempo como se muestra en la “Tabla 8.1”:
Tipo de Recurso Recurso Cantidad
Humano Analista y arquitecto 1
Humano Director Interno 1
Humano Director Externo 1
Infraestructura Alquiler de Computador 1
Infraestructura Almacenamiento disponible en google drive 2 Gigas

para guardar documentación
Infraestructura Internet 6 meses
Infraestructura Luz 6 meses
Transporte Transporte (Transmilenio, SITP, etc) 6 meses
Varios Fotocopias, CD’s, otros 6 meses

Tabla 3. Recursos necesarios para la realización del proyecto
Basado de: Oficina Asesora de Sistemas [5].
Los recursos antes mencionados son los mínimos considerados únicamente

para la realización de este proyecto, el recurso analista y arquitecto es el rol
con el que se desarrolló el proyecto, el director interno es el docente asignado
por la universidad y el director externo es el asignado por la oficia asesora de
sistemas para el seguimiento de la pasantía, los recursos como equipos,
almacenamiento y servicios fueron dados por la oficina.

9.1.2. PRESUPUESTO
El presupuesto fue calculado principalmente con los recursos mínimos para la

realización del proyecto ya antes definidos, el cálculo realizado se realiza sobre
la cantidad del recurso, el valor unitario y el valor total de cada tipo de recurso
como se indica en la siguiente tabla:
Tipo de Recurso Cantidad Valor Valor Total

Recurso Unitario
Humano Analista 1(6 meses) $2.000.000 $ 12.000.000
Humano Director Interno 1(6 meses) $1.800.000 $10.800.000
Humano Director Externo 1(6 meses) $1.800.000 $10.800.000
Infraestructura Alquiler de 2(6 meses) $100.000 $ 1.200.000

Computador
Infraestructura Internet 6 meses $80.000 $ 480.000
Infraestructura Luz 6 meses $20.000 $ 120.000
Transporte Transporte 6 meses $240.000 $ 1.440.000

(Transmilenio,
SITP)
Varios Fotocopias, 6 meses $959.000 $5.754.000

CD’s,
Otros
Imprevistos y Daños, 6 meses $1274850 $4.259.000

Otros Perdidas,
Otros
Tabla 4. Presupuesto del proyecto.
Basado de: Oficina Asesora de Sistemas [5].
Presupuesto Total: $ 46.853.400
El recurso humano analista, será asumido por los autores de este proyecto y su
costo será asumido por cuenta propia, se reconoce que la oportunidad de
pasantía brindada por la OAS es una experiencia para crecer, aplicar y
fortalecer los conocimientos obtenidos en la academia.

El director interno y externo, asumirán su costo brindando su apoyo y
conocimientos para el desarrollo de este proyecto. Los costos de los demás
recursos serán asumidos por los autores de este proyecto.

9.2. MODELAMIENTO DEL NEGOCIO
El modelamiento del negocio es la etapa inicial más importante en todo

proyecto, debido a que es necesario tener entendimiento en gran medida del
funcionamiento, procesos y reglas del sistema, en este caso es importante
conocer las directrices dictadas por la Universidad Distrital Francisco José de
Caldas en el acuerdo N 038 de 2015 que especifican lo relacionado al proceso
de realización de trabajos de grado.
9.2.1. ASPECTOS DE 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, en
cumplimiento en el artículo 70° del acuerdo 027 de 1993 del Consejo Superior
Universitario. Contribuye en la formación integral del estudiante de pregrado a
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
[14].
Un trabajo de grado puede ser desarrollado en una de las distintas

modalidades reglamentadas por la universidad, dependiendo de los requisitos
mínimos que cada una de estas necesite un estudiante podrá o no optar a la
modalidad.
9.2.2. MODALIDADES DE TRABAJO DE GRADO
Las modalidades de trabajo de grado son definidas para optar por un título de
pregrado en cualquier proyecto curricular de la Universidad Francisco José de
Caldas [14] y estas son:
 Pasantía:
La pasantía es una modalidad de trabajo de grado que realiza el

estudiante en un entidad nacional o internacional ( entiéndase: empresa,
organización, comunidad, institución, organismo especializado en
regiones o localidades o dependencia de la Universidad distrital
Francisco José de Caldas), asumiendo el carácter de practica social,
cultural, empresarial o de introducción a su quehacer profesional,
mediante la elaboración de un trabajo teórico-práctico, relacionado con
el área del conocimiento, del proyecto curricular un estudiante se
encuentra inscrito.

 Espacios Académicos de Postgrado:
Son espacios académicos ofrecidos por un proyecto curricular de

postgrado que realiza el estudiante en los programas de especialización
o maestría que oferta la universidad; Para esta modalidad, el estudiante
debe cursar y aprobar de ocho a nueve (8-9) créditos conforme a la
escala de calificaciones dispuesta para los estudiantes de postgrado.
 Espacios Académicos de Profundización:
El objetivo principal de esta modalidad de trabajo de grado es posibilitar

al estudiante del nivel profesional tecnológico, ahondar en los
conocimientos propios del área de formación profesional que desee
desarrollar; Para esta modalidad, el estudiante debe cursar y aprobar
mínimo seis (6) créditos en los espacios académicos definidos como
obligatorios básicos y electivos intrínsecos que ofrece cualquier
programa de nivel profesional, tanto en los programas de larga duración,
como en el segundo nivel profesional de los programas organizados por
ciclos propedéuticos.
 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; Dentro de esta modalidad se pueden desarrollar
trabajos de grado donde se aplican los conocimientos adquiridos a
través de su proceso de formación, para solucionar problemas
específicos de la comunidad, región o país.
 Investigación-Innovación:
Esta implica el vínculo del estudiante a una estructura de investigación

que sea ésta un instituto, grupo o semillero de investigación
institucionalizado en la universidad o por una entidad reconocida por
COLCIENCIAS, con un mínimo de un (1) año de creación, cuyo
propósito de garantizar, mediante el cumplimiento de un plan de
actividades de investigación, la formación en investigación del
estudiante.

 Creación o Interpretación:
Esta modalidad de trabajo de grado recoge elementos inherentes al

campo del arte y otros afines, que permiten la producción de una obra
artística, el desarrollo de sus medios, de sus recursos y otras formas de
expresión artística.
 Proyecto de Emprendimiento
Esta modalidad tiene como finalidad proyectar la constitución formal de

una empresa u organización a través de la construcción de un modelo
de negocios o la estructuración de un plan de negocios.
 Producción Académica:
En esta modalidad el estudiante presenta evidencia de la publicación o

aceptación de un (1) artículo científico en revista indexada u
homologada por el sistema de indexación nacional publindex de
Colciencias o el vigente para la fecha de solicitud de la propuesta de
trabajo de grado.
Cada una de las antes mencionadas modalidades de trabajo de grado cuentan

con requisitos mínimos para su realización que serán estudiados en la sección
de requerimientos.

9.3. REQUERIMIENTOS
En esta etapa se establecieron el conjunto de requerimientos básicos

impuestos para la realización de cada una de las modalidades de trabajo de
grado según se indican en el Acuerdo N° 038 del 28 de julio de 2015 por la
Universidad Distrital Francisco José de Caldas y los requerimientos
relacionados a procesos generales que se llevan a cabo para el control, tutoría,
socialización y evaluación del trabajo de grado realizado por el estudiante. Los
requerimientos fueron organizados en requerimientos funcionales y no
funcionales, lo cual permite proponer una solución que tenga en cuenta la
funcionalidad, infraestructura y calidad del sistema.
La captura y especificación de requerimientos se realizaron partiendo de

reuniones con el equipo de desarrollo, product owner e interesados en el
desarrollo del proyecto, además de mantener lo reglamentado en el Acuerdo N°
038 del 28 de julio de 2015 por la Universidad Distrital Francisco José de
Caldas que es la base principal para el desarrollo de este proyecto y de los
proyectos realizados en años anteriores [2, 4, 13, 14].
9.3.1. DEFINICIÓN DE ACTORES Y ROLES.
Partiendo del trabajo realizado en el análisis del negocio es importante la

definición de todos los actores y roles que estos desempeñen en el sistema, los
actores descritos a continuación son únicamente los que de una u otra manera
hacen contacto con el proceso de la realización de cualquiera de las
modalidades de trabajo de grado que ofrece la universidad, el análisis de estos
fue realizado a partir de los procesos que se llevan actualmente para la gestión
de los trabajos de grado, consultas con el product owner y basados en el
Acuerdo N° 038 del 28 de julio de 2015.
A continuación, se muestran los actores y sobre estos se definen los diferentes

roles que puedan tener en el sistema, cada uno de estos con su respectiva
descripción y el nivel de interacción que este tendrá con el sistema, este será
medido de 1 a 10.
Estudiante Se trata de aquel miembro que como parte de la

comunidad universitaria se encuentra cursando
alguno de los programas de pregrado ofrecidos
por la universidad
Rol Descripción Nivel

Estudiante Activo Rol de aquellos estudiantes que se 8
encuentran activos y por lo tanto
pueden interactuar con las
funcionalidades de registro, evaluación
y seguimiento de trabajos de grado que
tendrá el sistema.
Estudiante Inactivo Rol para estudiantes que se encuentran 1
inactivos, y pese a ello se les negara el
acceso a algunas funcionalidades, solo
si ya se encontraban registrados en el
sistema, de lo contrario no se les
permitirá.
Estudiante en Rol para estudiantes que se encuentran 3
Vacaciones activos y están en vacaciones. Estos
tienen acceso a algunas
funcionalidades del sistema, se
desactivarán las funcionalidades de
procesos para validaciones del trabajo
de grado.
Tabla 5. Actor y Roles de Estudiante Autoría propia
Docente Se trata de aquel miembro que tiene un vínculo

con la universidad y se encarga de investigar,
orientar y dictar asignaturas de los programas de
pregrado que ofrece la universidad
Docente Rol dado a los docentes que aún no 4
están vinculados a ningún trabajo de
grado, tienen acceso al sistema y ver
los trabajos de grado que requieren de
docentes.
Director Rol para docentes que han sido 7
vinculados a un proyecto de grado
como directores internos, pueden
realizar revisiones sobre anteproyectos
y proyectos y realizar un seguimiento a
estos entre otras funcionalidades, según
lo requiera la modalidad.

Evaluador Rol para docentes que son vinculados 7
con el fin de realizar la revisión sobre
proyectos y propuestas de estudiantes,
tienen casi las mismas funcionalidades
que un docente director, pero su
aprobación es requerida para la
continuación de un proceso para el
trabajo de grado.
También son los docentes encargados
de evaluar un proyecto de grado,
emitiendo un concepto y una calificación
la cual dependiendo de la modalidad
será tomada en cuenta para la
calificación de un trabajo de grado.
Tabla 6. Actor y Roles de Docente Autoría propia
Concejo de carrera Son todos aquellos que como parte del concejo
de carrera se encargan de gestionar las etapas
por las que pasa un trabajo de grado.
Delegado de concejo de Rol dado a aquellas personas que como 6
carrera parte del concejo se encargan de
interactuar con el sistema y hacer uso
de las funcionalidades concernientes a
la revisión y aprobación de solicitudes
de trabajos de grado
Tabla 7. Actor y Roles de Concejo de Carrera Autoría propia
Proyecto curricular Son los relacionados directamente con una de las

carreras que ofrece la universidad y se encargan
de gestionar los procesos que sigue el estudiante
en la realización del trabajo de grado.
Coordinador de proyecto Rol dado a quien se encarga de la 6
gestión durante todo el proceso de un
trabajo de grado, dentro de sus
actividades regulares están: la
aceptación o rechazo de los proyectos
de grado radicados en el proyecto
curricular, la asignación de los
directores y evaluadores, entre otras.

Delegado de Proyecto Rol dado a los encargados de gestionar 6
curricular de postgrado o los procedimientos acordes a las
pregrado modalidades de espacios académicos
de postgrado y de profundización
Tabla 8. Actor y Roles de Proyecto Curricular Autoría propia
Unidad de extensión Son los encargados de manejar entre otras cosas

los convenios entre la universidad y entidades
externas.
Delegado de pasantías Rol dado a las personas encargadas de 5
gestionar el proceso de comunicación
entre un estudiante y una empresa a la
que se aplique para la modalidad de
pasantías, en las diferentes sedes de la
universidad existe una unidad de
extensión encargada de esto, no
obstante, esta responsabilidad puede
ser delegada a una oficina de
pasantías.
Tabla 9. Actor y Roles de Unidad de Extensión Autoría propia
9.3.2. REQUERIMIENTOS FUNCIONALES.
Los requerimientos funcionales definen funcionalidades específicas que el

sistema deberá cumplir, los listados a continuación están distribuidos por los
procedimientos generales, por modalidad y por funcionalidades extras del
sistema, estos fueron concluidos a través de reuniones con el product owner y
del Acuerdo N° 038 del 28 de julio de 2015 por la Universidad Distrital
Francisco José de Caldas.
9.3.1.1. REQUERIMIENTOS DE PROCEDIMIENTOS GENERALES
 RF-01 Registro y manejo de solicitudes de inscripción de trabajo de

grado: Todo estudiante debe poder registrar una solicitud de inscripción
del trabajo de grado a la respectiva coordinación de proyecto curricular
adjuntando la documentación requerida dependiendo de la modalidad
seleccionada, para ello se requiere tener en cuenta los siguientes
aspectos:

 La fecha máxima para la inscripción del trabajo de grado será la
semana 14 de cada periodo académico, según el calendario que
sea establecido por el consejo académico.
 El estudiante en el momento de la inscripción manifestara en

solicitud si desea la inscripción simultanea de os espacios
académicos de trabajo de grado I y trabajo de grado II.
 Cuando el número de créditos del semestre académico, en el cual

el estudiante inscriba el(los) espacio(s) académicos
correspondientes al desarrollo del trabajo de grado, exceda los 18
créditos académicos, deberá cursar solicitud al consejo de
conformidad con lo establecido en el Acuerdo No. 9 de 2006 del
consejo académico.
 RF-02 Revisión y verificación de los requisitos mínimos

establecidos para cada modalidad: El sistema debe permitir a cada
coordinación realizar la verificación de los requisitos mínimos de las
solicitudes realizadas por los estudiantes o realizarla automáticamente si
así se requiere.
 RF-03 Registro de espacios Académicos en cóndor: Las

coordinaciones deberán poder realizar el registro de los espacios
académicos de las modalidades de trabajo de grado que hayan sido
aprobadas por el concejo curricular en el sistema de información
“condor” como en el sistema a desarrollarse “polux”.
 RF-04 Socialización del trabajo de grado: El sistema deberá permitir

el registro de la fecha, lugar y evaluación de la socialización para los
trabajos de grado bajo las modalidades de pasantía, monografía,
investigación-innovación, creación o interpretación, proyecto de
emprendimiento y producción académica, estas serán establecidas por
la coordinación del proyecto curricular correspondiente.
 RF-05 Evaluación del trabajo de grado: El sistema debe permitir que

se pueda realizar una evaluación del proceso integral del desarrollo
alcanzado en el proyecto de grado, dando una valoración a los
resultados alcanzados, socializados y presentados mediante un
documento escrito.
 RF-06 Distinciones: El sistema podrá otorgar o incluir distinciones

dadas por el consejo de facultad a los trabajos de grado que destaquen

por los resultados obtenidos, en virtud a su originalidad, creatividad,
resultados, creación o invención a solicitud del docente director.
 Se establece que las modalidades de trabajo de grado pasantía,

espacios académicos de postgrado y profundización, y proyecto
de emprendimiento no optaran por distinción alguna.
 Para evaluar el otorgamiento de la respectiva distinción, el

consejo de facultad designara un docente idóneo en la temática
central del trabajo de grado.
 RF-07 Verificar porcentaje de créditos aprobados necesarios para

aplicar a la modalidad: el sistema deberá verificar que el estudiante
que quiera optar por una modalidad haya aprobado el porcentaje mínimo
de los créditos académicos de su plan de estudios requeridos por la
modalidad.
9.3.1.2. REQUERIMIENTOS MODALIDAD PASANTIA
 RF-08 Verificar la entidad donde se desarrolle la pasantía: El sistema

debe tener un módulo donde se pueda ver la información de la entidad y
que en esta se pueda certificar su existencia, reconocimiento o que este
legalmente constituida.
 RF-09 Número de estudiantes que pueden realizar una misma

pasantía: El sistema debe permitir la realización de una pasantía por
máximo dos (2) estudiantes. En este caso, cada pasante deberá
certificar el cumplimiento de las horas definidas que serán de mínimo
384 horas en un tiempo no mayor a (6) meses.
 RF-10 Propuesta de pasantía: EL sistema permitirá al estudiante el

registro de una propuesta de pasantía la cual será avalada por un
docente de la universidad, para el registro del espacio académico; dicha
propuesta deberá contener como mínimo:
 Título y autor(es)
 Resumen ejecutivo
 Objetivos
 Plan de trabajo
 Resultados esperados
 Cronograma

 RF-11 Registro de documentos anexos: El sistema debe permitir el
registro de documentos anexos requeridos por la unidad de extensión o
división encargada del manejo de estas junto a la propuesta de pasantía,
estos deberán ser:
 Carta de solicitud de aprobación de la pasantía y designación de

director y evaluador (puede ser manejado por el sistema, en cuyo caso
se tendrá el registro de la solicitud realizada)
 Carta de aceptación de la dirección interna (un docente de planta de la
Facultad) esta puede ser manejada por un módulo de gestión del
sistema, en dado caso se tendrá el registro de aceptación por parte del
docente
 Carta de aceptación de la dirección externa (un profesional de la
empresa)
 Hoja de vida del director externo
 Registro en Cámara de Comercio de la empresa (si es privada) con
fecha no mayor a 6 meses de expedido
 Si existe Convenio, copia del mismo
 Si ya firmó contrato, copia del mismo
 Acta de Compromiso de la empresa donde se especifiquen las
actividades ingenieriles a desarrollar por el estudiante en el marco de su
Pasantía, condiciones y contraprestaciones del trabajo a realizar.
 RF-12 Docente director y profesional externo: El sistema permitirá al

consejo curricular designar al docente director el cual será quien avale la
propuesta de pasantía del estudiante y realizará, el correspondiente
seguimiento al desarrollo de la pasantía; el concejo también avalará al
profesional designado por la entidad respectiva como evaluador.
 RF-13 Informe final: Se debe permitir el registro de un informe final de

las actividades realizadas en la pasantía que deberá contener como
mínimo, los siguientes aspectos:
 Objetivos de la pasantía
 Descripción de cada uno de los resultados alcanzados en el
desarrollo de la pasantía debidamente ordenados y expuestos en
forma coherente
 Análisis de resultados, productos, alcances e impactos del
trabajo de grado, de acuerdo con el plan de trabajo
 Evaluación y cumplimiento de los objetivos de la pasantía
 Conclusiones y recomendaciones

 Anexar el concepto entregado por el profesional designado por la
entidad en donde se realizó el trabajo de grado.
 RF-14 Evaluación pasantía: El sistema deberá tener los registros de

las evaluaciones realizadas por el docente director y el profesional
responsable, la calificación final será el promedio de ambas
calificaciones y este será registrado en cóndor.

POSTGRADO
 RF-15 Publicación de los espacios académicos: El sistema debe

permitir que los proyectos curriculares de postgrado puedan publicar,
hasta la semana diez (10) del calendario académico de pregrado, el
listado de espacios académicos elegibles por parte de un estudiante de
pregrado.
 RF-16 Solicitudes de modalidad de espacios de postgrado: El

sistema debe permitir al estudiante realizar la solicitud de inscripción a
los espacios académicos de postgrado donde especificara la carrera y
las asignaturas a cursar en el periodo académico solo si el estudiante
tiene un promedio mayor a 3.8 y a cursado mínimo el 80% del plan de
estudios.
 RF-17 Atención a solicitudes: Se deberá permitir a los proyectos

curriculares de postgrado atender a las solicitudes de los estudiantes de
pregrado estableciendo sus propios procedimientos para atenderlas, en
todo caso serán los coordinadores de postgrados los que certificarán a
las coordinaciones de pregrado, la aceptación de la solicitud del
estudiante.
 RF-18 Formalización de inscripción: El estudiante podrá formalizar su

inscripción del espacio académico que sea solicitado, en dado caso el
sistema registrará la formalización.
 RF-19 Consulta: Se podrá consultar por medio del sistema los espacios
académicos inscritos, así como su calificación final.
 RF-20 Evaluación espacios académicos de postgrado: El sistema

generará la calificación del trabajo de grado sacando un promedio de las
calificaciones obtenidas por el estudiante de cada espacio académico
cursado y esta será registrada en cóndor, para ello se debe tener en

cuenta que la calificación mínima aprobatoria para cada espacio
académico cursado bajo esta modalidad debe ser tres punto cero (3.0), y
esta modalidad será aprobada como trabajo de grado con una
calificación final de tres punto cinco (3.5).

PROFUNDIZACION
 RF-21 Publicación de espacios académicos de profundización: El

sistema debe permitir a los proyectos curriculares ofertar y publicar
durante la semana diez (10) de cada periodo académico.
 RF-22 Solicitud de inscripción de espacios académicos de

profundización: El sistema debe permitir al estudiante realizar la
solicitud de inscripción a los espacios académicos de profundización
donde especificaran las asignaturas a cursar en el periodo académico, el
estudiante debe tener mínimo el 80% de créditos cursados del plan de
estudios.
 RF-23 Atención a solicitudes de espacios académicos de

profundización: Se deberá permitir a los proyectos curriculares de
pregrado atender a las solicitudes de los estudiantes de pregrado
solicitando la certificación del proyecto de pregrado y la sabana de
notas.
 RF-24 Formalización de inscripción de espacios académicos de

profundización: El estudiante podrá formalizar su inscripción del
espacio académico que sea solicitado, en dado caso el sistema
registrará la formalización.
 RF-25 Consulta de espacios académicos de profundización: Se

podrá consultar por medio del sistema los espacios académicos
inscritos, así como su calificación final.
 RF-26 Evaluación de espacios académicos de profundización: La

calificación final es el promedio aritmético de las calificaciones obtenidas
en los respectivos espacios académicos y será registrada en el sistema
de información académico “cóndor”, el sistema deberá poder mostrar la
calificación de cada uno de los espacios como la calificación del trabajo
de grado.
9.3.1.5. REQUERIMIENTOS MODALIDAD MONOGRAFIA

 RF-27 Número de estudiantes en una monografía: Esta modalidad
puede ser realizada por máximo dos (2) estudiantes, por lo tanto, el
sistema deberá permitirlo.
 RF-28 Propuesta de monografía: El sistema deberá permitir el registro

de una propuesta de monografía realizada por el o los estudiantes, dicha
propuesta deberá poder ser avalada por un docente de la universidad y
presentada ante el consejo curricular para su aprobación.
 RF-29 Inscripción de monografía: El concejo curricular realizará la

inscripción del espacio académico y asignará el docente director y el
docente evaluador, preferiblemente será el docente director quien halla
avalado la propuesta.
 RF-30 Proyecto de Monografía: En el sistema se podrá registrar el

proyecto de monografía el cual es un documento escrito que debe
contener información que permita evidenciar el cumplimiento de los
objetivos y que como mínimo deberá contener los siguientes aspectos:
 Antecedentes y Justificación
 Problema o pregunta de investigación
 Objetivos
 Marco teórico conceptual
 Metodología
 Desarrollo de la propuesta
 Bibliografía
 RF-31 Evaluación de la monografía: Se debe poder registrar en el

sistema las calificaciones dadas por el docente evaluador y el docente
director. La calificación final será el promedio aritmético de las
calificaciones dadas por el docente director y el docente evaluador y
esta será registrada en cóndor.
9.3.1.6. REQUERIMIENTOS MODALIDAD INVESTIGACIÓN-INNOVACIÓN
 RF-32 Número de estudiantes en investigación-innovación: Esta

modalidad puede ser realizada por máximo dos (2) estudiantes, por lo
tanto, el sistema deberá permitirlo.

 RF-33 Plan de actividades: El sistema deberá permitir el registro de un
plan de actividades de investigación que será avalado por un docente
que haga parte de una estructura de investigación para la solicitud de
trabajo de grado ante el proyecto curricular, la propuesta deberá tener
como mínimo:
 Descripción del problema
 Estado del arte
 Objetivos: general y específicos
 Metodología
 Cronograma
 RF-34 Vinculo a una estructura de investigación: Se requiere que por

medio del sistema se pueda verificar el vínculo del estudiante y del
docente con una estructura de investigación ya sea esta un instituto,
grupo o semillero y que este institucionalizada por la universidad distrital
Francisco José de Caldas, o una entidad reconocida por Colciencias con
un mínimo de 1 año de creación.
 RF-35 Informe de actividades de investigación: Se requiere que el

sistema permita el registro de un informe de actividades de investigación
para su posterior evaluación, el informe deberá contener los siguientes
aspectos:
 Objetivos
 Descripción de cada uno de los resultados alcanzados en el plan
de desarrollo de actividades debidamente ordenados y expuestos
de forma coherente
 Análisis de resultados, productos, alcances e impactos del trabajo
de grado, de acuerdo con el plan de trabajo
 Evaluación y cumplimiento de los objetivos del plan de
actividades
 RF-36 Evaluación modalidad: Para la evaluación de la modalidad se

realizará una socialización en donde se exponga lo realizado en el
proyecto, la calificación final será el promedio aritmético de las
calificaciones dadas por el docente director y el docente evaluador, y
registrada en cóndor por el respectivo coordinador.

9.3.1.7. REQUERIMIENTOS MODALIDAD CREACIÓN O INTERPRETACIÓN
 RF-37 Número de estudiantes en presentar la modalidad: esta

modalidad puede ser realizada de forma individual o colectiva, el consejo
curricular será quien apruebe la solicitud realizada por los estudiantes
por medio del sistema o de forma manual.
 RF-38 Propuesta de creación o interpretación: El sistema deberá

poder registrar una propuesta de creación o interpretación que será avalada
por un docente quien será el docente director.
 RF-39 Registro de modalidad: El sistema debe gestionar la solicitud de

registro de la modalidad realizada por los estudiantes que será
presentada ante el concejo curricular para su aprobación y autorización
del espacio académico en el sistema.
 RF-40 Informe de actividades: El sistema deberá permitir el registro de

un informe de actividades que debe contener información que permita
evidenciar el cumplimiento de los objetivos., este tendrá como aspectos
mínimos:
 Objetivos de la propuesta
 metodología o procedimientos de la propuesta
 Descripción de cada uno de los resultados alcanzados en el
desarrollo de la propuesta debidamente ordenados y expuestos
de forma coherente.
 Análisis de resultados, productos, alcances e impactos del trabajo
de grado, de acuerdo con la propuesta.
 Evaluación y cumplimento de los objetivos
 conclusiones y recomendaciones
 RF-41 Evaluación de la modalidad creación o interpretación: Se

debe socializar el desarrollo de la propuesta de acuerdo a los
lineamientos establecidos por el proyecto curricular, la calificación final
será registrada según sea el promedio dado por la calificación del
docente director y dos docentes evaluadores y se registrará por el
respectivo proyecto académico.
9.3.1.8. REQUERIMIENTOS MODALIDAD PROYECTO EMPRENDIMIENTO

 RF-42 Número de estudiantes para proyecto emprendimiento: Esta
modalidad puede ser realizada por máximo 2 estudiantes que serán
registrados por medio del sistema.
 RF-43 Modelo o plan de negocio: El sistema deberá poder registrar la

propuesta para el modelo o plan de negocio, según corresponda, y esta
deberá estar avalada por un docente, se deberá verificar que el plan de
actividades tenga como mínimo (Para Tecnológico)
 Descripción de la estrategia a implementar
 Descripción de la organización (Procesos y sistemas)
(Para Profesional)
 Resumen Ejecutivo
 Descripción de negocio que se desarrollará
 Objetivos
 Matriz DOFA propuesta (preliminar)
 RF-44 Registro de modalidad: El sistema debe gestionar la solicitud de

registro de la modalidad realizada por los estudiantes que será
presentada ante el concejo curricular para su aprobación y autorización
del espacio académico en el sistema.
 RF-45 Registro de plan o modelo de negocio: El sistema deberá

poder registrar (Para Tecnológico)
 Modelo de negocios
(Para Profesional)
 Plan de negocios
 Estudio de Factibilidad
 RF-46 Evaluación: Se debe registrar calificaciones dadas por el

docente evaluador y el docente director. La calificación final será el
promedio aritmético de las calificaciones dadas por el docente director y
el docente evaluador

9.3.1.9. REQUERIMIENTOS MODALIDAD PRODUCCIÓN ACADÉMICA
 RF-47 Número de estudiantes para producción académica: Esta

modalidad puede ser realizada por máximo 2 estudiantes que serán
registrados por medio del sistema.
 RF-48 propuesta de publicación: El sistema debe poder registrar una

propuesta de publicación avalada por un docente adscrito a una estructura de
investigación, La propuesta debe tener mínimo:
 título y autores
 tipo de artículo científico a publicar definidos por el sistema de
indexación nacional publindex:
o Artículo de investigación, científico o tecnológico
o Artículo de reflexión
o Artículo de revisión
o Artículo corto
 Objetivos generales y específicos
 Temáticas a tratar
 Metodología
 Cronograma
 RF-49 Vinculo a una estructura de investigación: Se requiere que por

medio del sistema se pueda verificar el vínculo del estudiante y del
docente con una estructura de investigación ya sea esta un instituto,
grupo o semillero y que este institucionalizada por la universidad distrital
Francisco José de Caldas
 RF-50 Evaluación: Se requiere verificar fecha de aceptación del artículo

por parte del comité editorial de la revista. En la eventualidad que la
revista pierda la indexación se considerará la fecha de postulación del
artículo científico y la clasificación de la revista en ese momento. El
docente director realiza la evaluación de la modalidad y será registrada
al sistema de información por el respectivo coordinador.
9.3.1.10. REQUERIMIENTOS DE PLATAFORMA
 RF-51 Sesión: Se debe soportar la autenticación del sistema a través de

un usuario y una contraseña que permitan además de restringir el
ingreso al sistema, identificar el rol y el usuario reflejando las tareas o
actividades que tenga pendientes o a cargo. La sesión iniciada debe
poderse cerrar en el momento que el usuario lo requiera.

 RF-52 Acceso a reglamentación: El sistema debe permitirle a usuarios
registrados y no registrados, el acceso al documento en el que se detalle
la reglamentación actual para trabajos de grado, así como al boletín de
pasantías. Los formatos de evaluación y demás formatos presentados
por el sistema, estos deben ser los actualmente utilizados dentro de la
universidad para proyectos de grado.
 RF-53 Consulta trabajo grado: El sistema debe permitir la consulta de

los trabajos de grado en cualquiera de las etapas en que se encuentren
únicamente por las personas que se encuentren relacionadas con este.
 RF-54 Asignación de director o evaluador: El sistema debe permitir la

solicitud y nombramiento de uno o varios directores o evaluadores para
un trabajo de grado quiénes acompañarán el proyecto durante todo el
proceso. El profesor de planta asignado debe poder aceptar o rechazar
la dirección del proyecto de grado.
 RF-55 Gestión de documentos trabajo de grado: El sistema debe

permitir el almacenamiento de documentos de proyecto de grado
dependiendo de la etapa en que se encuentre. Los autores deben tener
la posibilidad de cargar nuevos documentos presentando modificaciones
o evoluciones del mismo, estos pueden ser versionados por el sistema y
permitir consultarlos digitalmente por las personas involucradas con el
trabajo de grado.
 RF-56 Gestión de evaluaciones del trabajo de grado: El sistema debe

permitir realizar revisiones a los documentos del trabajo de grado que
hayan sido presentados por el autor, las evaluaciones estarán a cargo
de diferentes actores (Director Interno, Evaluador) dependiendo de la
etapa en que se encuentre el proyecto de grado.
 RF-57 Control de solicitudes: El sistema debe controlar todas las

solicitudes que hayan sido realizadas dentro del proceso, almacenando
la fecha de emisión y calculando el número de días disponibles que tiene
el receptor de la solicitud para dar respuesta a la misma. Así mismo se
podrá observar el historial de las acciones efectuadas sobre la solicitud.
 RF-58 Actividades de sustentación: El sistema debe permitir la

programación de la sustentación de un trabajo de grado que se
encuentre con todos sus conceptos como aprobado y listo para
sustentar, debe notificarse dicha programación indicando fecha, hora y
lugar, de igual manera el sistema debe permitir ingresar el acta de

sustentación donde se muestre la nota cuantitativa y el carácter obtenido
para el proyecto, indicando si existe algún tipo de mención.
9.3.3. REQUERIMIENTOS NO FUNCIONALES.
los requerimientos no funcionales describen aspectos del sistema que son

visibles por el usuario y que no incluyen una relación directa con el
comportamiento funcional esperado, pero si con su calidad, rendimiento y
características a la hora de utilizarse.
 RNF-01 Desempeño: Debido a su naturaleza pública el sistema debe

tener la capacidad de realizar toda consulta dentro de un tiempo
moderado, permitiendo un flujo eficiente de eventos.
 RNF-02 Interfaz de usuario: Debido al amplio espectro de potenciales

usuarios del sistema este debe permitir un ingreso de datos sencillo y
amable promoviendo una interfaz gráfica intuitiva en ambientes WEB.
Ningún mensaje en el contenido de la interfaz tendrá un idioma diferente
al español. Permitir el uso de listas de valores para diligenciar
formularios de información. Estandarización de colores e iconos para las
funcionalidades solicitadas.
 RNF-03 Mantenimiento: El sistema debe estar debidamente

documentado para permitir su escalabilidad o algún cambio en su
estructura interna. Los módulos deben tener alta cohesión y bajo
acoplamiento ofreciendo independencia en su implementación
posibilitando una adición o supresión compatible de los mismos. La
lectura de los datos debe realizarse de forma dinámica para permitir la
modificación de los mismos minimizando integración de éstos al código
fuente.
 RNF-04 Seguridad: Ingreso de usuarios a través de solicitud de usuario

y contraseña con su respectiva validación. Almacenamiento cifrado de
contraseñas y datos de sesión.

9.4. ANÁLISIS
Una vez listados los requerimientos fue realizado un análisis comparativo de

las modalidades, en donde se buscó principalmente encontrar procesos
similares, para ello se definieron unos macro procesos y dentro de cada uno
estos se etiquetaron las modalidades que los ejecutaban para de esta manera
hallar un flujo general de procesos, esto realizado a partir de los requerimientos
y con esto facilitar la etapa de diseño y desarrollo del presente proyecto.
Es importante aclarar que los procesos aquí contemplados se basan

únicamente en lo estipulado por el Acuerdo N° 038 del 28 de julio de 2015 de la
Universidad Distrital Francisco José de Caldas, procesos alternos que son
llevados en la actualidad no serán tenidos en cuenta a petición del product
owner, y para la aclaración de puntos abiertos a interpretación presentados en
el acuerdo se realizaron reuniones aclaratorias de dudas con el product owner
concluyendo que no existen actualmente acuerdos de las facultades que
especifiquen la aplicación del Acuerdo 038 de 2015. Los acuerdos o actas que
se habían creado por parte de los diferentes proyectos curriculares para la
aplicación de los acuerdos anteriores al 038 de 2015 quedan derogables. No se
deben tener en cuenta los anteriores acuerdos de trabajo de grado expedidos
por el consejo académico, solo el 038 de 2015.
9.4.1. GENERALIZACIÓN DE PROCESOS.
Sobre la generalización de procesos fueron tomados en cuenta dos macro-

procesos o fases diferentes que son generales para la mayoría de las
modalidades de trabajo de grado que ofrece la universidad, la que tiene que ver
con el proceso de aplicar para cursar espacios académicos en la cual se
pueden agrupar las modalidades de espacios académicos de postgrado y
espacios académicos de profundización, el otro macro-proceso consiste en la
generalización de procesos de las modalidades en donde se realiza un
documento para la inscripción de la modalidad y otro que es presentado para la
generación de la nota final, en este proceso se unifican las modalidades de
pasantía, monografía, investigación-innovación, creación o interpretación,
proyecto de emprendimiento y producción académica.
Para el primer macro proceso que involucra las actividades realizadas por los
estudiantes para aplicar a las modalidades que ofrecen espacios académicos
como opción de trabajo de grado se realiza una tabla comparativa de procesos
y se indican las diferencias e igualdades de las modalidades aquí analizadas.

Modalidad Espacios Académicos De Espacios Académicos De
Procesos Postgrado Profundización
Publicación de Se realiza una publicación de Se realiza una publicación
espacios espacios académicos de espacios académicos
académicos elegibles por parte de los elegibles por parte de los
proyectos curriculares de proyectos curriculares de
posgrado pregrado
Solicitud para Se solicita ante el Se solicita ante el
aplicar a coordinador del proyecto coordinador del proyecto
modalidad curricular de pregrado curricular de pregrado que
especificando máximo dos certifique el cumplimiento de
(2) programas de postgrado a requisitos de la modalidad
los que desea presentarse para cursar los espacios
para que la coordinación académicos.
certifique el cumplimiento de
los requisitos establecidos
para esta modalidad, y luego
se solicite ante el proyecto
curricular de posgrado para
cursar los espacios
académicos.
Selección de Se ofertan máximo diez (10) Se expide la carta de
admitidos en cupos por semestre que aceptación de la
modalidad serán otorgados de la coordinación del proyecto
siguiente manera: curricular de pregrado en
Cinco (5) cupos por donde se listan los espacios
excelencia académica y académicos que el
exentos de pagos, que serán estudiante va a cursar.
asignados de forma
descendente con base en el
promedio acumulado de los
estudiantes.
Hasta cinco cupos, para
estudiantes que estén en
condiciones económicas y
calidades académicas.
Formalización El estudiante formaliza su El estudiante formaliza su
inscripción ante la inscripción ante la
coordinación del proyecto coordinación del proyecto
curricular de pregrado quien curricular de pregrado quien
realiza la inscripción del realiza la inscripción del
espacio académico que sea espacio académico que sea

solicitad por el estudiante solicitad por el estudiante
Evaluación La calificación mínima El estudiante debe aprobar
aprobatoria para cada mínimo seis (6) créditos en
espacio académico cursado los espacios académicos
bajo esta modalidad debe ser definidos como obligatorios
tres punto cero (3.0), esta básicos y electivos
modalidad será aprobada intrínsecos, la calificación
como trabajo de grado con final será calculada del
una calificación final de tres promedio aritmético de las
punto cinco (3.5) que será el calificaciones obtenidas en
promedio delas calificaciones los respectivos espacios
obtenidas en los respectivos académicos
espacios académicos
Tabla 10. macro proceso generalizado para inscripción de espacios académicos
Dado los procesos anteriormente descrito y una vez realizado el análisis sobre
las modalidades se realiza la tarea de plantear flujos alternos que no hayan
sido contemplados dentro de los mismos procesos, y para la solución de estos
debido a que en el acuerdo no se especifican se aclaran con el product owner.
 ¿Qué pasa si existen empates en cuanto al promedio, cuáles otros

criterios se deben tener en cuenta para la selección de los estudiantes
en la modalidad de espacios académicos de postgrado?
Rta: en caso de empates, tener en cuenta la historia académica del
estudiante, el concejo de carrera puede definir los siguientes parámetros
en caso de que se siga dando un empate.
 “El costo de la matrícula corresponde a los derechos pecuniarios como

estudiante de pregrado en el respectivo periodo académico” ¿el costo
sería el valor asignado para el período académico en el recibo de
matrícula de pregrado?
Rta: El estudiante debe pagar lo correspondiente a los créditos de
posgrado y de pregrado, para los estudiantes que son exentos de pago
se les cobra el valor de la matrícula de pregrado.
 Los programas de postgrado aceptarán máximo 10 estudiantes, ¿qué

pasa si uno de ellos no formaliza la inscripción?
Rta: El proyecto curricular decide que hacer en estos casos, se puede
plantear un listado de opcionados o simplemente perder el cupo.
 ¿Los espacios académicos son homologables?

Rta: solo si la nota final de estos es mayor a 3.5 en espacios
académicos de postgrado y mayor a 3 en espacios académicos de
profundización.
Para la realización del siguiente macro-proceso en el que se agrupan la

mayoría de las modalidades se realiza una tabla comparativa por subprocesos
generales y se describe la manera en la que cada modalidad lo maneja, en
este caso debido a que la mayoría de procesos como fueron vistos en la etapa
de comprensión del negocio y de requisitos son realizados de manera manual,
los procesos aquí descritos serán orientados en el funcionamiento que tendrá
el sistema.
Proceso Solicitud del espacio académico de trabajo de grado

Modalidad
Pasantía
Monografía
Investigación-
innovación Se realiza la solicitud ante el concejo curricular para
Creación o su aprobación y autorización de inscripción del
interpretación espacio académico.
Proyecto de
emprendimiento
Producción académica
Tabla 11. subproceso general para solicitud del espacio de trabajo de grado
Como se observa el proceso de solicitud del espacio académico de trabajo de

grado es igual para todas las modalidades contempladas anteriormente, este
proceso se sigue según lo estipulado en el acuerdo, esta solicitud podría ser
realizada mediante el sistema o por medios presenciales.
Proceso Registro de anteproyecto

Modalidad
Pasantía Se registra una propuesta de pasantía junto al
acuerdo de voluntad, convenio o contrato y demás
documentos solicitados por la unidad de extensión
para dar aval a la pasantía.
Monografía Se registra una propuesta de monografía.
Investigación- Se registra un plan de actividades avalada por una
innovación estructura de investigación institucionalizada
Creación o Se registra una propuesta de creación o
interpretación interpretación

Proyecto de Se registra el modelo o plan de negocios, según
emprendimiento corresponda
Producción académica Se registra propuesta de publicación
Tabla 12. Sub proceso general registro de anteproyecto Autoría propia
Para llevar a cabo el segundo sub proceso general se plantea el registro de un

“anteproyecto” que no es más que el primer documento propuesto para todas
las modalidades aquí contempladas, en cada una de las modalidades se
solicita que los anteproyectos tengan como mínimo ciertas características y
dado que estas son diferentes para cada modalidad, dentro del proceso
general no es necesario describirlas.
En el registro del anteproyecto es importante pedir el título del proyecto, un

resumen de lo que trata y si este aplica en un campo de interés.
Proceso Vinculación de estudiantes

Modalidad
Pasantía Se puede vincular máximo un estudiante al trabajo
de grado
Monografía Se puede vincular máximo un estudiante al trabajo
de grado
Investigación- Se puede vincular máximo un estudiante al trabajo
innovación de grado
Creación o Se puede vincular cualquier número de estudiantes
interpretación al trabajo de grado
Proyecto de Se puede vincular máximo un estudiante al trabajo
emprendimiento de grado
Producción académica Se puede vincular máximo un estudiante al trabajo
de grado
Tabla 13. Sub proceso general vinculación de estudiantes Autoría propia
La mayoría de las modalidades pueden ser realizada por un máximo de dos (2)
estudiantes según se contempla en el acuerdo 038 de 2015, a excepción de la
modalidad de creación o interpretación, en la cual es posible la vinculación de
cualquier número de estudiantes sobre un proyecto, la validación de este
número será realizada por el respectivo proyecto curricular al que se solicite
esta modalidad.
La vinculación será realizada por medio del sistema, enviando una solicitud a
otro estudiante, el cual decidirá si acepta o no la solicitud para la realización del
trabajo de grado conjunto.

Proceso Vinculación docente
Modalidad
Pasantía Cualquier docente
Monografía Cualquier docente
Investigación- Debe ser un docente adscrito a una estructura de
innovación investigación.
Creación o Cualquier docente
interpretación
Proyecto de Cualquier docente
emprendimiento
Producción académica Debe ser un docente adscrito a una estructura de
investigación.
Tabla 14. Sub proceso general vinculación docente Autoría propia
Todas las modalidades solicitan que el anteproyecto esté vinculado y avalado

por un docente de la universidad distrital, por medio del sistema se podrá
realizar una solicitud a un docente, depende del docente si acepta o no la
vinculación con el trabajo de grado como el dar aval al documento de
anteproyecto, las modalidades de investigación-innovación y producción
académica se les filtraran únicamente los docentes que hagan parte de la
estructura de investigación tal y como se especifica en el acuerdo.
Proceso Revisión de Documento

Modalidad
Pasantía El proceso de revisión de un documento inicia con
Monografía la solicitud realizada por un estudiante a un docente
Investigación- vinculado al trabajo de grado, el docente al que se
innovación le realiza la solicitud puede ser un docente
Creación o vinculado, director o evaluador, el proceso consiste
interpretación en que al darse la solicitud el docente está en el
Proyecto de deber de ver el documento y en base a este generar
emprendimiento un concepto, este consiste en dar aval a el
Producción académica documento, rechazarlo o sugerir modificaciones, al
sugerir modificaciones se deben indicar en el
sistema para que el estudiante identifique donde o a
que se debe realizar la corrección.
Tabla 15. Sub proceso general revisión de documento Autoría propia
El proceso de revisión de documento se da en distintas etapas de la realización

de un trabajo de grado, y en cada una de las etapas se puede plantear de la
misma manera, pues el objetivo de este proceso no es otro que el de la
comunicación entre el docente y el estudiante para revisar el documento

asociado al trabajo de grado, y a partir de esto verificar si este cumple o no con
lo requerido y si sobre este se pueden realizar modificaciones para ser avalado
y continuar con las siguientes fases del proceso, este proceso puede repetirse
varias veces en una fase en el caso que a un documento sea necesario
realizársele varias modificaciones.
El proceso de revisión se da con el anteproyecto como con el proyecto final

(proceso que se verá a continuación).
Proceso Registro de proyecto final

Modalidad
Pasantía Se registra un informe final de las actividades
realizadas en la pasantía
Monografía Se registra documento escrito que contenga
información que permita evidenciar el cumplimiento
de los objetivos
Investigación- Se registra un informe de actividades de
innovación investigación desarrolladas.
Creación o Se registra un informe de actividades y productos
interpretación
Proyecto de Se registra el (Para Tecnológico) Modelo de
emprendimiento negocios, (Para Profesional) Plan de negocios y
Estudio de Factibilidad
Producción académica Se registra articulo y evidencia de su publicación o
la certificación de aceptación para publicación
expedida por el editor general de la respectiva
revista.
Tabla 16. Sub proceso registro proyecto final Autoría propia
La funcionalidad de este proceso es similar a la de registro de anteproyecto,

solo que se da en una de las últimas fases del proceso de un trabajo de grado
y por lo tanto lo único que se verifica es que el contenido cumpla con las
expectativas especificadas en el acuerdo, en el caso de producción académica
es necesario realizar la verificación de la evidencia.
Proceso Asignación de director y evaluador

Modalidad
Pasantía El concejo curricular designa el docente director y
avalará al profesional designado por la entidad
respectiva como evaluador.
Monografía El concejo curricular designa el docente director y
docente evaluador.

Investigación- El concejo curricular avala al docente designado en
innovación la estructura de investigación como el docente
director y asigna un docente evaluador.
Creación o El concejo curricular designa el docente director y
interpretación dos (2) docentes evaluadores.
Proyecto de El concejo curricular designa el docente director y
emprendimiento docente evaluador.
Producción académica El concejo curricular designa el docente director
quien preferiblemente sea quien avale la propuesta
Tabla 17. Sub proceso general Asignación de revisores y evaluadores Autoría propia
Este proceso siempre es llevado a cabo por el concejo curricular y se realiza en

la inscripción del trabajo de grado, la asignación de los docentes podrá ser
realizada mediante el sistema, en este se buscará a algún docente que cumpla
con los requerimientos definidos por el concejo y se asignará, al docente le
llegará una notificación de la novedad y el proceso con el trabajo de grado
continuará.
Proceso Socialización
Modalidad
Pasantía
Monografía
Investigación-
Se estipula una hora, fecha y lugar para la
innovación
socialización de lo realizado en el trabajo de grado
Creación o
con los respectivos docentes director y evaluador
interpretación
que se tenga asignados en el momento.
Proyecto de
emprendimiento
Tabla 18. Sub proceso general socialización Autoría propia
En este proceso en el sistema se habilita la opción para que el concejo

curricular establezca la fecha y el lugar de la socialización, que realiza el
estudiante a el respectivo director y evaluador(es).
Proceso Evaluación
Modalidad
Pasantía Se realiza la evaluación de los trabajos de grado en
Monografía base a unos formatos pre establecidos por cada
Investigación- proyecto curricular y en base a la socialización
innovación realizada anteriormente por el o los estudiantes que
Creación o desarrollaron el trabajo de grado, la nota es

interpretación generada y promediada de acuerdo al número de
Proyecto de evaluaciones que se hayan realizado.
emprendimiento
Tabla 19.Sub proceso general evaluación Autoría propia
La evaluación puede ser realizada desde el sistema, el cual contara con un

formato realizado por cada proyecto curricular y en el cual se toman en cuenta
los criterios de evaluación definidos por estos, la evaluación y cada una de las
respuestas provistas por los evaluadores se guardaran en el sistema y en base
a estas se generara una nota del trabajo de grado, la cual podrá ser
promediada automáticamente por el sistema con las demás evaluaciones y
generar la nota final del trabajo, el coordinador del proyecto curricular será
quien se encargue de verificar esta nota y ponerla en el sistema cóndor.
Como en el anterior proceso en la realización del análisis del presente proceso

surgieron dudas y se descubrieron posibles flujos alternos que no son
contemplados en el acuerdo 038 de 2015, por lo tanto, de igual manera se optó
por resolver estas dudas directamente con el product owner en reuniones y
consultas sobre el proceso.
 “La pasantía tendrá una duración mínima de 384 horas que deben
cumplirse en un tiempo no mayor a (6) meses”, ¿Qué pasa si la pasantía
sobrepasa los 6 meses establecidos
Rta: Se puede solicitar una prórroga de hasta 6 meses con el respectivo
concejo de carrera.
 “El Consejo Curricular designará al docente director y avalará al

profesional designado por la entidad respectiva como evaluador”,
¿significa que en ningún momento la pasantía tendrá asignado un
docente evaluador?
Rta: En caso que la persona designada por la entidad se declare
impedida para realizar la evaluación, será el proyecto curricular quien
decida si se asigna un docente evaluador o se toma en cuenta
únicamente la calificación del docente director.
 El docente investigador que da el aval a la propuesta de trabajo de

grado de investigación-innovación y producción académica, debe
pertenecer obligatoriamente al mismo grupo de investigación al que
pertenece el estudiante en el que se realiza el trabajo de grado

 ¿Cómo se verifica que el estudiante y el docente pertenezcan al grupo
de investigación?
Rta: consultando la base de datos del CIDC: base de datos de los
grupos e investigadores.
 ¿En la modalidad producción académica se puede presentar el artículo a

varias revistas?
Rta: Si, lo que interesa para trabajo de grado 1 es que sea aceptado, y
para trabajo de grado 2 que sea publicado.
 No se puede presentar un artículo ya publicado sin que antes se haya

realizado la solicitud de inscripción de la modalidad de trabajo de grado.
 Solo para la facultad de artes se aplica la modalidad de trabajo de grado

creación o interpretación, aunque en un futuro puede ser aplicable a
todas las facultades
 ¿Cuál es el proceso que debe seguir un estudiante para la cancelación

de una modalidad de trabajo de grado?
Rta: Se le notificara al concejo de carrera mediante una carta o solicitud
realizada por el sistema.
La anterior generalización de procesos de trabajo de grado permite al presente

proyecto tratar el problema de manera global y generalizada, gracias a esto es
posible facilitar las siguientes etapas de diseño y desarrollo tratando la
perspectiva del negocio principalmente de manera generalizada y luego
complementando con los detalles individuales de cada modalidad.

9.4.2. MODELAMIENTO PROCESOS DE NEGOCIO.
El modelamiento de procesos de negocio consiste en representar gráficamente

hechos, situaciones, procesos, movimientos o relaciones de todo tipo, por
medio de una forma simbólica, básicamente, es un diagrama que expresa
gráficamente las distintas operaciones que componen un procedimiento o parte
de este, estableciendo su secuencia cronológica.
Para el presente proyecto como se había estipulado antes para la realización

de los flujogramas se tomará como base los de tipo BPMN (Business Process
Modeling Notation) que es el nuevo estándar para el modelado de procesos de
negocio y servicios web.
Los flujogramas serán realizados de acuerdo a la anterior sección de la

generalización de procesos, de esta manera se podrá observar el flujo que
tienen cada una de las modalidades y como se estructuran cada uno de los
procesos individuales con el proceso general.
Para el primer proceso general no se realizó un flujograma propio debido a que

este representa la mayoría del proceso realizado por ambas modalidades, se
modelo entonces el diagrama BPMN de las modalidades de espacios
académicos de profundización y de espacios académicos de postgrado, en
este se puede ver de manera más sencilla la similitud que existirá entre estas
dos modalidades en el sistema y como se manejan los procesos propios de
estas véanse en Figuras 5 y 6.
Para el segundo proceso general en el que se involucran la mayoría de

modalidades que hacen un manejo de documentos, se realizó un BPMN propio
con el objetivo de mostrar el flujo que existe entre cada uno de los subprocesos
analizados en la anterior sección, mostrando de manera gráfica y cronológica la
funcionalidad y la interacción entre los usuarios en el sistema Figura 7.
Una vez realizado el flujo general este será acoplado a el flujo realizado para
cada una de las modalidades y complementado con los procesos individuales
de estas, esto con el fin de diferenciar y priorizar, según sea el caso, los
procesos individuales para pasantía Figura 8, monografía Figura 9, producción
académica Figura 10, creación o interpretación Figura 11, proyecto de
emprendimiento Figura 12 e investigación-innovación Figura 13.

Figura 5. Diagrama BPMN modalidad espacios académicos de postgrado Autoría propia

Figura 6. Diagrama BPMN modalidad espacios académicos de profundización Autoría propia

Figura 7. Diagrama de flujo BPMN proceso general Autoría propia

Figura 8. Diagrama de flujo BPMN modalidad pasantía Autoría propia

Figura 9. Diagrama de flujo BPMN modalidad monografía Autoría propia

Figura 10. Diagrama de flujo BPMN modalidad producción académica Autoría propia

Figura 11. Diagrama de flujo BPMN modalidad creación o interpretación Autoría propia

Figura 12. Diagrama de flujo BPMN modalidad proyecto de emprendimiento Autoría propia

Figura 13. Diagrama de flujo BPMN modalidad investigación-innovación Autoría propia

9.5. DISEÑO
En la fase de diseño se realiza la construcción de prototipos y el modelo de la

base de datos, para ello fue necesario haber finiquitado la fase de análisis, y de
esa manera continuar con el desarrollo del proyecto basándose en lo
estipulado anteriormente.
9.5.1. CONSTRUCCION DE PROTOTIPOS
Para el diseño de prototipos se planteó una línea base, la cual es el proceso

general antes definido en el que se incluyen la mayoría de las modalidades, el
trabajo aquí realizado no es más que una representación de cómo podrían
quedar algunos de los módulos en la etapa de desarrollo, basados en los
requerimientos y la generalización de procesos.
Se tomaron también como referencia diseños realizados por los trabajos

planteados antes que este, como lo son los referenciados en [2 y 13], ya que en
estos se pueden observar similitud en algunos de los procesos aquí planteados
Registro de propuesta o anteproyecto
El registro de la propuesta es uno de los primeros procesos importantes que se

presenta en el sistema, por supuesto para hacerlo es necesario haber
verificado antes que el estudiante cumpla a cabalidad con los requerimientos
estipulados por la modalidad, esto anterior será verificado cada vez que se
realice un registro y un login a el sistema.

Figura 14, prototipo de registro de propuesta Autoría propia
El objetivo de este prototipo es en base a un formulario y datos extraídos de la

sesión capturar los parámetros necesarios para el registro de la propuesta de
trabajo de grado realizado a una modalidad en específico. El sistema debe
capturar los datos de sesión (nombre, código, fecha, etc.) para ser utilizados en
los formularios
 Modalidad de trabajo de grado: Indica la modalidad a la cual se está

registrando la propuesta, esta se carga por el sistema dependiendo
desde que modulo se realice el registro de la propuesta.
 Autores: Indica la información de los estudiantes que están realizando la

propuesta de trabajo de grado.
 Invitar estudiante: Funcionalidad que permite vincular a mas estudiantes

a la propuesta realizada para un trabajo de grado.

 Título: Campo en el que se debe registrar el título de la propuesta de
trabajo de grado con el que será identificado en el sistema.
 Archivo: Funcionalidad que permite adjuntar el documento de la

propuesta para el trabajo de grado preferiblemente en formato pdf.
 Temáticas de interés: Funcionalidad que permite relacionar la propuesta

que se está registrando a unas temáticas de interés generales con las
que podrá ser buscado o referenciado después.
 Vinculación docente para Avalación de propuesta: Como se indica en los

requerimientos toda propuesta de trabajo de grado tiene que tener un
docente vinculado que de aval a la misma, por esto, la funcionalidad de
vinculación docente permite buscar y vincular a la propuesta un docente.
 Inscripción trabajo de grado I y II: En este campo se le pide indicar al

estudiante si desea realizar la inscripción de los espacios académicos I y
II tal y como dice el acuerdo 038 de 2015.
Vinculación de Estudiantes
La vinculación de estudiantes es un proceso en donde si una propuesta es

realizada por más de un estudiante, se les permitirá vincularse a la misma
propuesta por medio de este módulo, inicialmente se contempla que es
necesario que uno de los estudiantes registre la propuesta al sistema y en el
registro realice la vinculación de los demás estudiantes restringiendo el número
de estudiantes a lo permitido para cada modalidad.
Figura 15. Prototipo vinculación de estudiantes Autoría propia

El prototipo permitirá la búsqueda de estudiantes activos y que se encuentren
registrados en el sistema para realizar la vinculación a la propuesta.
 Programa: Campo que indica de forma automática la carrera sobre la

cual se realizara la propuesta.
 Modalidad: Campo que indica la modalidad de trabajo de grado de la

propuesta a cuál será vinculado otro estudiante.
 Estudiante: Funcionalidad del sistema que permite desplegar y filtrar los

estudiantes activos en el sistema para ser vinculados en la propuesta de
trabajo de grado.
 Invitar estudiante de otra facultad: Funcionalidad que permite filtrar

estudiantes de otras facultades para vincularlos a la propuesta del
trabajo de grado.
 Enviar invitación: Se envía la invitación a el estudiante seleccionado,

para que este decida si la acepta o la rechaza.
Notificación de solicitud de vinculación a trabajo de grado
Al realizarse una invitación a otro estudiante en el registro de una propuesta de

trabajo de grado es necesario notificarle de alguna manera a ese estudiante
que ha sido invitado, y darle la posibilidad de aceptar o rechazar dicha
invitación a la vinculación.
Figura 16. Prototipo notificación a vinculación de propuesta Autoría propia
Se propone como prototipo que para los estudiantes que han sido vinculados a
una propuesta de trabajo de grado se cree una lista de solicitudes en la cual se
pueda observar la información concerniente a la propuesta, como el estudiante
solicitante, la modalidad, el título de la propuesta, la fecha y el estado.

Figura 17. Prototipo información general de propuesta para vinculación de estudiante Autoría
propia
En esta ventana simplemente se le muestra la información de manera más

completa y ordenada y se le da la opción de aceptar o rechazar dicha solicitud.
Revisión y aval de propuesta
Al igual que con los estudiantes la vinculación del docente se realiza de manera
parecida, buscando los docentes disponibles mediante un listado y
seleccionando al docente que se requiera, el docente luego será quien decida
si acepta o no la vinculación a la propuesta de trabajo de grado. En caso que
un docente esté vinculado al trabajo de grado es necesario solicitarle el aval
para pasar la propuesta a concejo curricular y para ello se plantea que el
estudiante sea quien solicite el aval de la propuesta una vez el docente esté
vinculado al trabajo de grado.
Figura 18. Prototipo listado de peticiones de trabajo de grado para avalar Autoría propia
Para este caso como se muestra en el prototipo, al docente se le desplegara

una lista con las propuestas de trabajo de grado que requieren ser avaladas
con la información concerniente a la propuesta, de este listado el docente
podrá elegir un registro y realizar su respectiva revisión para dar un aval o pedir
modificaciones sobre el documento presentado por el o los estudiantes.

Figura 19. Prototipo para la revisión de un documento de trabajo de grado Autoría propia
En el prototipo se planteó una visualización del documento en la parte izquierda

de la ventana, y en la parte derecha el modulo para indicar modificaciones al
documento, en caso de que no hallan modificaciones se avala la propuesta
mediante la funcionalidad de avalar propuesta, por lo contrario, si se exigen
modificaciones al documento se envían las observaciones y la propuesta queda
pendiente a modificaciones.
Figura 20. Prototipo estado de propuesta de trabajo de grado Autoría propia
La propuesta de trabajo de grado se actualizará al estado pendiente de modificación,

el estudiante deberá corregir el documento dependiendo de las observaciones
realizadas por el docente vinculado y volver a realizar la solicitud de aval por parte del
docente, si el docente emite otra modificación el estudiante deber realizar el mismo
procedimiento.
Registro y asignación de evaluadores al trabajo de grado

Todo el anterior proceso es realizado con el fin de realizar la solicitud al concejo de
carrera para la inscripción del espacio académico de trabajo de grado en cóndor, una
vez la propuesta este avalada por un docente se realizara la solicitud al concejo de
carrera quienes serán los que asignen al docente director y a los evaluadores,
dependiendo de la modalidad.
Figura 21. Prototipo listado de propuestas solicitadas al concejo Autoría propia
Mediante un listado que es cargado en el módulo de solicitudes para el registro

de trabajo de grado del concejo curricular se podrán ver todas las solicitudes
realizadas por los estudiantes de un mismo proyecto curricular que solicitan ser
inscritas a la modalidad de grado.
Figura 22. Prototipo solicitud concejo curricular registro de trabajo de grado tomado de [13]
El concejo curricular podrá ver toda la información concerniente a la propuesta

de trabajo de grado, de esta manera se podrá realizar la verificación de los
requerimientos mínimos dados para una modalidad de trabajo de grado, según

este estipulado en el acuerdo 038 de 2015 y asignar los respectivos
evaluadores (revisor) y director a el trabajo de grado.
Figura 23. Prototipo asignación de evaluadores y director Autoría propia
Una de las funciones del concejo curricular es la asignación al trabajo de grado

de un docente director y docentes evaluadores dependiendo de la modalidad y
esta podrá ser realizada como se muestra en el prototipo.
 N° Acta: campo en el que se indica el acta realizado en la reunión del

concejo para la verificación y asignación de docentes a trabajos de
grado.
 Fecha Acta: Campo que indica la fecha de creación y validación del acta
ante el concejo curricular.
 Director (sugerido): Funcionalidad que permite buscar entre un listado de

docentes disponibles para asignar al director del proyecto, el prototipo
sugiere una funcionalidad extra la cual es recomendar como director al
mismo docente que da el aval del documento.
 Evaluador: Funcionalidad que permite seleccionar a uno o varios

docentes para ser evaluadores de un trabajo de grado dependiendo la
modalidad.
A los docentes seleccionados como evaluadores por el concejo curricular se les

notificara la novedad y se les vinculara directamente al trabajo de grado.
En este punto el estudiante o directamente después de la asignación del

concejo curricular se le solicitara al docente evaluador realizar una revisión o

evaluación sobre la propuesta de trabajo de grado y emitir un concepto para el
seguimiento de la realización del trabajo de grado, este concepto podrá ser
rechazado, modificable o viable.
Figura 24. Prototipo para formato de evaluación Autoría propia
Para la revisión realizada por el docente evaluador se puede plantear el

anterior prototipo de la revisión de un documento de trabajo de grado y como
opción si así lo requiere el docente manejar un formato más específico y
generalizado para cada proyecto curricular. El formato podrá diseñarse por
medio del sistema y los encargados de esto podrán ser el director de proyecto
o el concejo curricular.
Realización de trabajo de grado
Una vez es aprobado el trabajo de grado la siguiente fase seria la del desarrollo
del mismo, el inicio del trabajo de grado está planteado desde que se realiza el
registro por parte del concejo curricular.

Figura 25. Prototipo estado de trabajo de grado Autoría propia
El prototipo muestra siempre la información del trabajo de grado que se está

desarrollando por parte de los estudiantes, al dar click este será redireccionado
a una vista que contendrá información más detallada acerca del trabajo de
grado.
Figura 26. Prototipo para ver información de trabajo de grado tomado de [13]
Figura 27. Prototipo Registro de versiones de documento de trabajo de grado Autoría propia

Según se necesite se pueden subir nuevas versiones de un documento al ser
modificado, esto con el fin de que el docente pueda ver los cambios en el
documento y en base a ello aprobar el documento o solicitar más
modificaciones.
Para la revisión de estos documentos se utilizara el mismo prototipo antes

planteado.
Socialización
La socialización de lo realizado en el trabajo de grado es un requerimiento

obligatorio para la calificación final que tendrá este, para ello es necesario
haber acordado con los docentes evaluador y director lugar, fecha y hora de la
sustentación del proyecto, Generación del Acta de sustentación y asignación
de calificación para el trabajo de grado
Figura 28. Prototipo Programación socialización Autoría propia
El sistema a de brindar una funcionalidad que le permita a la secretaría

académica de la facultad finalizar los informes finales para los cuales se haya
efectuado la sustentación pública. La información a diligenciar para la
finalización de un trabajo de grado es: Calificación cualitativa (número decimal
entre cero y cinco) y el carácter (no aprobado, aprobado, meritorio o laureado)

Figura 29. Prototipo Informe de calificación final tomado de [13]
9.5.2. DISEÑO DE LA BASE DE DATOS
El diseño de la base de datos es la estructura encargada en asegurar que la

información ingresada en el sistema pueda estar siempre disponible a la vista
de quien la disponga y tenga permisos para ello, para el modelo realizado en
este proyecto se tomaron en cuenta aspectos muy importantes para una base
de datos optima y funcional [15].
 Independencia lógica y física de los datos: Se refiere a la capacidad de

modificar una definición de esquema en un nivel de la arquitectura sin
que esta modificación afecte al nivel inmediatamente superior.
El conjunto de datos contenidos en la base debe ser única y estar
integrada por los mismos datos.
 Redundancia mínima: Debe ser controlada, de forma que no exista

duplicidad innecesaria, y que las redundancias físicas, convenientes
muchas veces a fin de responder a objetivos de eficiencia, sean tratadas
por el mismo sistema, de modo que no puedan producirse
inconsistencias.
Se trata de usar la base de datos como repositorio común de datos para
distintas aplicaciones.
Un dato se actualizará lógicamente por el usuario en forma única, y el
sistema se preocupará de cambiar físicamente todos aquellos campos

en los que el dato estuviese repetido en caso de existir redundancia
física (redundancia controlada).
 Acceso concurrente por parte de múltiples usuarios: Las bases de datos

pretenden servir al conjunto de la organización, manejando los datos
como otro recurso. Por lo tanto, las bases de datos han de atender a
múltiples usuarios y a diferentes aplicaciones. En contraposición a los
sistemas de ficheros, en donde cada fichero atiende a determinada
aplicación.
 Distribución espacial de los datos: Los datos pueden encontrarse en otra

habitación, otro edificio e incluso otro país, el usuario no tiene por qué
preocuparse de la localización espacial de los datos a los que accede.
 Integridad de los datos: Se refiere a las medidas de seguridad que

impiden que se introduzcan datos erróneos.
Esto puede suceder tanto por motivos físicos (defectos de hardware,

actualización incompleta debido a causas externas), como de operación
(introducción de datos incoherentes).
 Consultas complejas optimizadas: permite la rápida y ejecución de las

mismas.
 Seguridad de acceso y auditoría: Se refiere al derecho de acceso a los

datos contenidos en la base por parte de personas y organismos.
El sistema de auditoría mantiene el control de acceso a la base, con el
objeto de saber qué o quién realizó una determinada modificación y en
qué momento.
 Respaldo y recuperación: Se refiere a la capacidad de un sistema de

base de datos de recuperar su estado en un momento previo a la
pérdida de datos.
 Acceso a través de lenguajes de programación estándar: Se refiere a la

posibilidad ya mencionada de acceder a los datos de una base mediante
lenguajes de programación ajenos al sistema de base de datos. en
pocas palabras son los programas o software con los que se mandarán
llamar y diseñar los datos que aparecerán en la pantalla.
Para diseñar la base de datos para el sistema se tomaron cada uno de los
procesos y relaciones entre estos, diferenciar los que no tenían procesos en

común, agrupar los que sí y en base a lo anterior diseñar la base de datos,
partiendo desde lo más esencial del modelo y complementándolo con lo
subsecuente del mismo.
A la realización del modelo se le hizo un seguimiento por parte de la oficina, en

donde se programaban reuniones con el experto DBA de la oficina para
socializar el modelo que se estaba desarrollando, en dichas reuniones se
explicó los avances del modelo y cada una de sus funcionalidades, en base a
esto se logró hacer una buena corrección al modelo basado en las
recomendaciones del DBA y entregar un diseño con el visto bueno de la
oficina.
El modelo también contempla la integración con otros sistemas de información

manejados por la universidad y de esta manera tener una base única de
información disponible para las diferentes aplicaciones que se manejen en la
universidad, por ejemplo, la base de datos de estudiantes y docentes.
El modelo de la base de datos realizado en el presente proyecta cuenta con su

debida documentación en el Anexo 2 Diccionario de datos.

Figura 30. Modelo De la Base de Datos Autoría propia

El modelo construido consta de 34 tablas o entidades encargadas de mantener
la integridad de los datos y la relación entre estos, a continuación, se explicará
por partes funcionales el modelo de la base de datos, en esta sección se verá
reflejado todo el anterior trabajo de análisis y por lo tanto lo hace el producto
más importante de este proyecto; El modelo aquí representado es la última
versión que fue avalada por la oficina asesora de sistemas para su despliegue
y posterior desarrollo de la aplicación para ello el modelo será construido sobre
el esquema de la base de datos de la universidad distrital y será llamado Pólux.
Trabajo de grado
Entiéndase el trabajo de grado como el macro proceso esencial del sistema

sobre el cual se relacionarán bastantes elementos que dependiendo de la
modalidad serán válidos o no, por ello de concluye que el trabajo de grado es
necesariamente de un tipo de modalidad y lógicamente este es desarrollado
por uno o varios estudiantes, el trabajo de grado según dicta el acuerdo 038 de
2015 podrá ser realizado en dos partes trabajo de grado I y trabajo de grado II
si así lo requiere el estudiante.
Figura 31. Modelado - Relación TG - Modalidad – Estudiante Autoría propia
La tabla trabajo_grado referencia el campo de id_modalidad de la tabla

modalidad y la mantiene como no nula para asegurar que al crearse un trabajo
de grado sea específicamente de una modalidad de las que existan registradas
en el sistema. Para la tabla estudiante_tg se referencia ese trabajo de grado

creado y se asocia a un estudiante proveniente de la base de datos de cóndor,
este será referenciado mediante el campo llamado código_estudante, de la
misma forma sucede con asignatura_tg que se refiere a la de trabajo de grado I
y II.
Espacios Académicos
Como se indicó anteriormente existen dos modalidades en las cuales se es

posible cursar materias de profundización o de postgrado según sea el caso,
para ello el proceso es el mismo, la única diferencia estaría en las etapas de
selección y aprobación de los espacios que serán manejados por aplicación.
Figura 32. Modelado Espacios Académicos Autoría propia
Se plantea una tabla que manejara las solicitudes realizadas por un estudiante
para aplicar a una de estas modalidades de trabajo de grado, estas serán
diferenciadas gracias al parámetro id_trabajo_grado que referencia la tabla
trabajo_grado antes mencionada, en solicitud_materias se plantean los
parámetros básicos para una solicitud, como la fecha, periodo, año y aparte se
plantea una tabla intermedia de asignatura_inscrita en la cual se listan las
materias seleccionadas para verse en el transcurso del periodo en esta se

referencias por medio del parámetro id_asugnaturas_elegibles la tabla en la
que se registran las materias ofertadas por los proyectos curriculares de
postgrado y pregrado en un periodo específico y para una carrera en
específico, en ella se realiza un control con el parámetro booleano que indica si
el espacio está activo.
Gestión de Documentos Trabajos de Grado
La mayoría de modalidades de trabajo de grado hacen un manejo de

documentos para la aprobación, seguimiento y constancia del trabajo realizado
por el o los estudiantes, en el manejo de los documentos es importante que
estos se asocien al trabajo de grado realizado por el estudiante y también la
gestión que se realice sobre estos, como las revisiones y correcciones
realizadas por un docente; y contemplar otros tipos de documentos como
anexos que también se relacionan con la base de datos.
Figura 33. Modelado Gestión Documentos De Trabajo De Grado Autoría propia
Se implementan un modelo para el gestor documental cuyas tabas están

compuestas por documento, tipo y categoría, creadas de esta manera con la
idea de tener una clasificación de hasta 2 niveles para los documentos

guardados en el sistema, en estas tres tablas estará la información
concerniente a todo tipo de documentos que existan en el sistema; Siendo
categoría la tabla que ubica una familia de documentos, Tipo la tabla que tipo
de documento es al que se refiere dentro de esa familia y finalmente
Documento que contiene la información propia del documento.
En el caso que se trate de un documento relacionado a algún trabajo de grado,

se implementa la tabla documento_tg, en dicha tabla se tiene en cuenta las
relaciones entre el documento y el trabajo de grado, y aparte de esto se
implementan funcionalidades como la referenciada a la tabla
estado_documento, que no busca otra cosa que dar un control sobre
documentos que necesiten de una verificación de estados en el sistema, y por
último, la relación reflexiva que se evidencia en el modelo que es para tener
una referenciación entre documentos para el manejo ya sea de versiones o
correcciones dispuestas ara la aplicación.
El manejo de revisiones sobre un documento de un trabajo de grado fue

implementado involucrando la existencia de un docente que se encuentra
vinculado a un trabajo de grado con anterioridad, es decir, para poder realizar
una revisión sobre un documento de algún trabajo degrado se tiene que ser
docente y estar de alguna manera vinculado al trabajo de grado, la tabla
vinculación_docente referencia la tabla de trabajo_grado y tipo_vinculacion
dando así la relación entre un docente y el trabajo de grado y asociándolos a
un tipo de vinculación en específico, el parámetro identificación_docente
referencia al docente en la base de datos académica en donde se encuentra su
información.
Teniendo ya un documento y un docente vinculado a un trabajo de grado es

posible realizar una revisión, para ello se implementaron las tablas revisión,
corrección y comentario, que cumplen con la funcionalidad dada a sus nombres
de llevar el manejo de las revisiones asignadas a un docente, en la tabla
revisión se indican los parámetros estado (puede ser pendiente, en borrad o
finalizada, estos estados están dados para el manejo del docente en el tiempo
que se demore en realizarla), fecha_recepcion (que indica la fecha en la que se
realizó la solicitud y según las normas a partir de esta fecha se tienen hasta 15
días hábiles para realizarse) y fecha revisión (que indica la fecha en la que el
docente da la revisión por finalizada). Al ser creada una revisión es posible
agregar, corregir o eliminar n cantidad de correcciones mientras el estado de la
revisión este en pendiente o borrador no se permitirá si este llegase a estar en
finalizada, por lo contrario, al estar una revisión finalizada será posible realizar
comentarios sobre cada una de las correcciones realizadas por el docente.

Este modelo será manejado en la mayoría de etapas para las modalidades
documentales, ya que es necesario que el docente lleve un control sobre lo
realizado por el estudiante, y será requerido el visto bueno en etapas como la
de propuesta de trabajo de grado, la cual necesita un aval por parte del
docente y este podrá darlo una vez revisado el documento, podrá ser revisado
por el evaluador una vez este sea asignado para dar vial a la realización del
proyecto (esto solo si el concejo de carrera lo requiere), en la etapa de
realización se desarrolla un nuevo documento final al cual se le realizara el
mismo control. De esta manera con todas las modalidades se tendrá presente
el uso de este modelo que como se ha visto es esencial para el sistema.
Evaluación
La evaluación de un trabajo de grado es realizada en el caso de espacios

académicos, por un promedio dado entre las materias vistas que esta
soportado en el modelo expuesto al inicio, en este modelo se soporta la
evaluación que se realiza a las demás modalidades de trabajo de grado que
necesitan de una socialización y notas de los docentes directores y/o
evaluadores.

Figura 34. Modelado Evaluación, Formato y Socialización Autoría propia
Se modeló una propuesta que pretende mediante un formato de evaluación

que pueda ser creado por cada uno de los proyectos curriculares, se pueda
evaluar los proyectos de trabajo de grado por los docentes, los formatos podrán
ser reutilizados por otros proyectos si así se requiere, o simplemente utilizados
como plantillas para la realización de otros. En este modelo se plantea también
que se puedan realizar formatos para otro tipo de transacciones, por ejemplo,
formularios para solicitudes, encuestas, etc.
La tabla formato es la que identifica a un formato de los demás, en esta se

puede asignar un nombre y una introducción al mismo, un formato está
compuesto por preguntas que pueden ser de tipo abiertas, cerradas,
opcionales, calificables, etc. Y a su vez estas están compuestas de respuestas
u opciones de respuestas que dependiendo del tipo de pregunta serán unas u
otras, en el modelo las tablas que soportan este proceso en la construcción del
formato son pregunta_formato (en la que se relacionan el tipo y las preguntas
que se mostraran en el formato sacadas de un banco de preguntas soportado
por la tabla pregunta), y respuesta_formato (en donde a cada pregunta del

formato se asocia una o varias posibles respuestas dependiendo el tipo, en
esta tabla se pueden construir paquetes de respuestas para el formato y
relacionarlas a un banco de respuestas dadas por la tabla respuesta).
Para la realización de una evaluación de una socialización echa a partir de un

formato se construyen las tablas socialización que es donde se registra la
ubicación, fecha y trabajo de grado que se socializara, la tabla evaluación en
donde se relaciona la socialización, el docente ya vinculado a un trabajo de
grado que será quien realice la evaluación y por último la referencia al formato
utilizado para la evaluación de la tabla formato_evaluacion_carrera, y para
conocer lo evaluado por el docente en el formato esta la tabla
respuesta_evaluacion en la que se referencian las respuestas dentro del
formato seleccionadas por el docente junto a una justificación realizada por el
mismo.
Vinculación externa
Existen modalidades como la de pasantía que para su realización se necesita

de interferencia por parte de entidades externas a la universidad en las que se
lleva a cabo su desarrollo, para ello se planteó la utilización de uno de los
esquemas utilizados por la oficina llamado agora, en este es manejado la
gestión de entidades y por ello en nuestro modelo solo referenciaremos el
parámetro que referencia a este sistema código_entidad, la tabla entidad tiene
una relación reflexiva debido a que en esta también se referencian las
personas miembro de empresas externas y de esta manera se asocia la
persona con la empresa, como en el caso de pasantía se adopta como director
externo un miembro de la entidad en la que se realiza la pasantía por medio de
la tabla vinculación_externa en la que se referencia el trabajo de grado y el tipo
de vinculación que este tiene, además de las fechas de inicio y fin de la
vinculación, y como son necesarios documentos requeridos por pasantías se
crea una tabla intermedia con el gestor documental del esquema llamada
documento_entidad.

Figura 35. Modelado Vinculaciones externas Autoría propia
Áreas de Conocimiento
El trabajo de grado como los docentes están asociados en el sistema por un

listado de áreas de conocimiento el cual es común en el esquema y se maneja
a partir de la tabla área_conocimiento, que es el compendio de todas las áreas
existentes, a esta se relacionan el trabajo de grado con la tabla
áreas_trabajo_grado y el docente con áreas docente.
Figura 36. Modelado Áreas Conocimiento Autoría propia

CAPÍTULO 10. RESULTADOS Y DISCUSIÓN
Al finalizar el proyecto, se obtiene un modelo óptimo para la integridad de los

datos y el manejo de las modalidades de trabajo de grado de la Universidad
Distrital estipuladas en el Acuerdo 038 de 2015, cubriendo los lineamientos
inicialmente establecidos y un documento base con el análisis desarrollado
para su posterior desarrollo. En la siguiente tabla se muestran las actividades
realizadas para cada objetivo planteado con el fin de obtener el resultado
deseado.
OBJETIVO ACTIVIDADES %
Revisar, ajustar y  Lectura y comprensión del Acuerdo 38

complementar el análisis De 201 De La Universidad Francisco
de requerimientos José De Caldas
correspondientes a las  Análisis de las funcionalidades del
modalidades de espacios aplicativo UDLearn.
académicos de postgrado,  Reuniones con el product owner
investigación-innovación,  Investigación de los procesos para la
espacios de gestión de las modalidades en 100%
profundización y diferentes proyectos.
producción académica,  Listar requerimientos de todas las
contempladas en el modalidades de grado y de procesos
proyecto “sistema de externos a estas.
gestión de proyectos de
grado “POLUX” de la
Universidad Distrital” de la
Oficina Asesora de
Sistemas (OAS).
Identificar los  Lectura y comprensión del Acuerdo 38

requerimientos del sistema De 201 De La Universidad Francisco
de gestión de proyectos de José De Caldas
grado “POLUX” de la  Análisis de las modalidades de
100%
Universidad Distrital monografía, pasantías, proyecto de
Francisco José de Caldas emprendimiento y creación o
para las modalidades de interpretación.
monografía, pasantías,  Consulta sobre flujos alternos en el
proyecto de proceso de la modalidad, con los

emprendimiento y creación encargados por la Universidad.
o interpretación
establecidas en el acuerdo
038 de 2015 (Universidad
Distrital Francisco José de
Caldas, 2015).
Definir y ajustar las  Reuniones de trabajo colaborativo con
necesidades de los el equipo de trabajo
interesados mediante  Socialización de modelos creados con
sesiones de trabajo el DBA de la oficina
colaborativo para la  Creación de historias de usuario y 100%
elaboración de realización de tareas definidas por la
documentos que permitan scrum master
continuar con el desarrollo  Sprints semanales
del proyecto
 Realización de Diagramas de flujo
BPMN para procesos generales y de
cada una de las modalidades
presentes en el acuerdo 038 de 2015.
 Realización de Tablas comparativas
Documentar los artefactos para la generalización de procesos en
propios del análisis del el sistema y desarrollo de una
proceso de desarrollo modalidad de trabajo de grado
definido por la OAS que  Realización de Modelo de la base de
sirvan como base para el datos realizado en pgmodeler 100%
desarrollo del proyecto y totalmente comentario
permitan apoyar las  Realización de Diccionario de datos.
siguientes fases del  Realización de Documento de análisis
mismo. de requerimientos.
 Realización de Plan general de
elaboración del análisis
 Realización de Prototipos propuestos
en fase de análisis para su posterior
desarrollo
Analizar y realizar el
diseño de la base de datos  Realización de Modelo de la base de
sobre el sistema “POLUX” datos
de las modalidades de  Realización de Diccionario de datos 100%
trabajo de grado de  Realización de Documento de análisis
espacios académicos de de las modalidades
postgrado, pasantía,  Análisis y pruebas sobre la base de

investigación-innovación, datos montada en un servidor de
espacios de pruebas
profundización, producción
académica, proyecto de
emprendimiento y creación
o interpretación
Tabla 20. Resultados Autoría propia

CAPÍTULO 11. TRABAJOS FUTUROS
Sobre el presente trabajo de grado se pueden generar nuevos proyectos

además del desarrollo del mismo, al ser este un tema que trata varios aspectos
de cómo realizar un trabajo de grado da paso a poderse enfocar ya sea en
procesos, funcionalidades o modalidades en específico y optimizar cada uno de
estos. Co el fin de dar continuidad al producto creado, se plantean las
siguientes alternativas de trabajo:
 Diseño de prototipos: Los prototipos realizados fueron principalmente

para el flujo general del proceso en el que la mayoría de modalidades de
trabajo de grado se podían implementar, por lo tanto escenarios como el
de inscripción de espacios académicos o incluso procesos concernientes
a cada una de las modalidades no fueron representados de esta
manera, como punto de partida para el inicio del desarrollo del aplicativo
web que gestionara los procesos llevados a cabo en los trabajos de
grado se puede plantear la realización de los prototipos faltantes y de
esa manera tener una visión más clara del producto finalizado con
antelación.
 Desarrollo del sistema: El desarrollo del sistema es el trabajo

inmediatamente futuro a este proyecto, donde se realizó un análisis en
profundidad sobre el funcionamiento del negocio y en base a esto se
implementó el diseño optimo que soportará la integridad de la
información que se transportará a través de la aplicación, la cual si toma
el mismo rumbo de procesos generalizados podría realizarse con mayor
facilidad.
 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.
 Integración con las bases de datos agora, argo, academica, otras: El

diseño planteado en este proyecto a petición de la oficina Asesora de
Sistemas de la Universidad Distrital Francisco José de Caldas fue
orientado a la integración con otras bases de datos especializadas con
las que se contaría para el manejo de ciertos procesos necesarios en el
proyecto desarrollado, para ello dentro del modelo se referenciaron
como llaves foráneas las tablas que se necesitarían en caso de la

integración, el trabajo futuro simplemente consistirá en unir la base de
datos referenciando las demás, por ejemplo la Unificación con el sistema
de gestión académica de la universidad la cual tendrá como fin 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.
 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 en cuanto a trabajos de grado.

CAPÍTULO 12. CONCLUSIONES
Gracias a que en el uso de la metodología SCRUM se establece una constante

comunicación con el cliente el cual comprueba de manera periódica el estado
del producto y que gracias a esto se pueden realizar correcciones, aportes,
aclaraciones por su parte el desarrollo del producto se agilizaba en tanto se
optimizaba a la vez, y debido a que el trabajo que se realizaba implicaba
procesos implementados por la misma universidad, la comunicación y la
búsqueda de información se agilizaron.
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 o representar procesos de un sistema a desarrollarse.
La implementación de un sistema de información que guarde y asegure la

integridad de los datos relacionados a los trabajos de grado realizados en la
universidad no solo facilita el acceso y modificación de estos, también provee
un lugar en donde se mantengan los trabajos de grados a disponibilidad de la
comunidad académica, un modelo sobre el cual se puede realizar inteligencia
de negocio, y un sitio web donde referenciar conocimientos por parte de
docentes y estudiantes.
Gracias al trabajo en equipo con los miembros de la oficina asesora de

sistemas se logró aprender nuevas tecnologías, tener más experiencia,
conocer los puntos de vista de expertos en el tema, todo para crecer como
profesional.

CAPÍTULO 13. BIBLIOGRAFÍA
[1] Consejo Superior Universitario, “Estatuto General de la Universidad,”

Universidad Distrital Francisco José de Caldas, 2007.
[2] Juan C. Vargas, “Analisis Diseño e Implementacion de un Prototipo Web para la
gestion de trabajos de grado bajo las modalidades de monografia y pasantia en
la facultad de ingenieria de la universidad distrital.” Universidad Distrital
Francisco José de Caldas, 2004.
[3] A. Agrela and C. M. Bounzas, “Herramienta web de código abierto para la
gestión de requerimientos durante el ciclo de vida de desarrollo del software
para metodología Open UP,” Universidad Católica Andrés Bello, 2009.
[4] U. D. F. J. de Caldas, Resolución de Rectoría N° 461. Bogotá, 2011.
[5] Oficina Asesora de Sistemas, “Guía rápida proceso de desarrollo
OpenUP/OAS,” Universidad Distrital Francisco José de Caldas, 2011.
[6] L. Gimson, “Metodologías ágiles y desarrollo basado en Conocimiento,”
Universidad Nacional de la Plata, 2012.
[7] Ken Schwaber y Jeff Sutherland, "La Guía Definitiva de Scrum: Las Reglas del
Juego". Guia de SCRUM Julio de 2013
[9] Manuel Trigas Gallego, “Desarrollo detallado de la fase de aprobación
de un proyecto informático mediante el uso de metodologías ágiles.”
Metodología Scrum TFC.
[10] U. D. F. J. de Caldas, artículo 70 del Acuerdo 027 de 1993 del consejo Superior
Universitario.
[11] PostgreSQL, Informacion general sobre postgresql, Disponible en
http://www.postgresql.org.es/sobre_postgresql, consultado en agosto 25 de
2016
[12] Diagrama BPMN, Manual de diagramación de procesos bajo estándar BPMN,
Disponible en http://www.analitica.com.co/, consultado en septiembre 25 de
2016
[13] Yuri Vanessa Nieto, "UDLearn", Tesis de Maestria, Universidad Distrital
Francisco jose de Caldas, 2015
[14] Acuerdo N° 038 del 28 de julio de 2015 por la Universidad Distrital Francisco
José de Caldas.
[15] María del Carmen Gómez, “Bases de Datos”, Universidad Autónoma
Metropolitana Unidad Cuajimalpa, México 2013

ANEXOS
1. CD: Anexos/Historias de usuario
2. CD: Anexos/Diccionario de datos

Proyecto Final

Cargado por

Información del documentohacer clic para expandir la información del documento

Copyright:

Formatos disponibles

Proyecto Final

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Proyecto Final

Cargado por

Copyright:

Formatos disponibles

ANÁLISIS DE REQUERIMIENTOS Y DISEÑO DE LA BASE DE DATOS

PARA EL SISTEMA DE GESTIÓN DE PROYECTOS DE GRADO “POLUX”

GEINER ALEXIS SALCEDO SALGADO

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

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

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS

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

Universidad Distrital Francisco José de Caldas 1

Universidad Distrital Francisco José de Caldas 2

Universidad Distrital Francisco José de Caldas 3

FIGURA 1. PROTOTIPO EN SGPG-UD ..............................................................................................................17

Universidad Distrital Francisco José de Caldas 4

TABLA 1PROCESO METODOLÓGICO SCRUM..................................................................................................... 40

Universidad Distrital Francisco José de Caldas 5

La Universidad Distrital Francisco José de Caldas es una institución autónoma

Para cumplir a cabalidad con este objetivo es fundamental generar egresados

La Universidad Distrital Francisco José de Caldas, al centrarse en uno de sus

Actualmente las modalidades de trabajo de grado definidas para optar al título

Relacionados a este proyecto existen propuestas como la de Juan Camilo

Universidad Distrital Francisco José de Caldas 7

Con el fin de realizar una automatización, unificación y mejora en el proceso de

El proyecto “Análisis y diseño de la base de datos para los módulos de

Universidad Distrital Francisco José de Caldas 8

En la actualidad, la Universidad Distrital Francisco José de Caldas hace el

La oficina Asesora de Sistemas (OAS) plantea una solución de software

Universidad Distrital Francisco José de Caldas 9

3.1. OBJETIVO GENERAL

Identificar, analizar y caracterizar las especificaciones funcionales y no

3.2. OBJETIVOS ESPECÍFICOS

 Revisar, ajustar y complementar el análisis de requerimientos

 Identificar los requerimientos del sistema de gestión de proyectos de

 Definir y ajustar las necesidades de los interesados mediante sesiones

 Documentar los artefactos propios del análisis del proceso de desarrollo

Universidad Distrital Francisco José de Caldas 11

Universidad Distrital Francisco José de Caldas 12

Debido a que la Universidad Distrital no cuenta con un sistema integral,

Para tal fin la Oficina Asesora de Sistemas (OAS) y tres estudiantes de la

La ingeniería de requisitos ha sido una de las áreas de la ingeniería del

Para el desarrollo de la solución software es importante inicialmente partir de

Universidad Distrital Francisco José de Caldas 13

La solución integral de software permitirá reducir el tiempo invertido en todo el

Para el proceso de desarrollo se aplicará el método sugerido por la OAS,

Universidad Distrital Francisco José de Caldas 14

 El proyecto abarca la fase de inicio, elaboración y construcción del proceso

 La entrega de artefactos sobre el análisis y diseño de la base de datos

 Para los módulos de espacios académicos de postgrado, espacios

 Se realizará la respectiva arquitectura de la base de datos complementando

 Los procesos que no se contemplan en los alcances no serán tenidos en

 Para el desarrollo de este proyecto solo se utilizará herramientas de

 El acuerdo N° 038 del 28 de julio de 2015 por la Universidad Distrital

Universidad Distrital Francisco José de Caldas 15

El proyecto de grado Análisis, diseño e implementación de un prototipo web

El proceso de cualquier modalidad en el sistema de divide en las etapas de pre

Figura 1. Prototipo en SGPG-UD

Universidad Distrital Francisco José de Caldas 17

El proyecto de maestría llamado Modelo De Un Sistema De Software Basado

El módulo facilita la gestión documental de trabajos de grado, la asignación de

Figura 2. Módulo UDLearn.