proyecto_final base datos

Logística

•

Engenharias

Pedro Sánchez moreno

7/11/2023

¡Este material tiene más páginas!

Entonces, ¿te gustó este material?

Ayude a animar a otros estudiantes a mejorar el contenido

¿Te gustó este material? ¡Compartir! 🧡

Logística

93.784 Materiales compartidos

Descarga la aplicación para disfrutar aún más

Lea materiales sin conexión, sin usar Internet. Además de muchas otras características!

Vista previa del material en texto

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

Universidad Distrital Francisco José de Caldas 1
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 2
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 DEACTORES 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
Universidad Distrital Francisco José de Caldas 3
9.3.1.4. REQUERIMIENTOS MODALIDAD ESPACIOS ACADEMICOS DE
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

Universidad Distrital Francisco José de Caldas 4
Í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

Universidad Distrital Francisco José de Caldas 5
Í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

Universidad Distrital Francisco José de Caldas 6

Universidad Distrital Francisco José de Caldas 7
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
Universidad Distrital Francisco José de Caldas 8
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

Universidad Distrital Francisco José de Caldas 9
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 hacende
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.

Universidad Distrital Francisco José de Caldas 10

Universidad Distrital Francisco José de Caldas 11
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.

Universidad Distrital Francisco José de Caldas 12
 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.

Universidad Distrital Francisco José de Caldas 13
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”.

Universidad Distrital Francisco José de Caldas 14
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.

Universidad Distrital Francisco José de Caldas 15
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.

Universidad Distrital Francisco José de Caldas 16

Universidad Distrital Francisco José de Caldas 17
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)

Universidad Distrital Francisco José de Caldas 18
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.

Universidad Distrital Francisco José de Caldas 19
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”.
Universidad Distrital Francisco José de Caldas 20

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
Universidad Distrital Francisco José de Caldas 21
 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].

Universidad Distrital Francisco José de Caldas 22
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.

Universidad Distrital Francisco José de Caldas 23
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.

Universidad Distrital Francisco José de Caldas 24
 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óndel 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.

Universidad Distrital Francisco José de Caldas 25
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
Universidad Distrital Francisco José de Caldas 26
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.

Universidad Distrital Francisco José de Caldas 27
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.

Universidad Distrital Francisco José de Caldas 28
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].

Universidad Distrital Francisco José de Caldas 29
7.5 HISTORIA DE USUARIO

Las Historias de Usuario surgieron en eXtremme Programming (XP) como una
respuesta a una situación habitual en los proyectosde 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
Universidad Distrital Francisco José de Caldas 30
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.

Universidad Distrital Francisco José de Caldas 31
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
Universidad Distrital Francisco José de Caldas 32
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.

Universidad Distrital Francisco José de Caldas 33
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
Universidad Distrital Francisco José de Caldas 34
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
http://es.wikipedia.org/wiki/ACID
Universidad Distrital Francisco José de Caldas 35
 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].

Universidad Distrital Francisco José de Caldas 36

Universidad Distrital Francisco José de Caldas 37
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
Universidad Distrital Francisco José de Caldas 38
(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
estimar
2.1 Levantamiento de proceso a desarrollar (flujograma,
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
Universidad Distrital Francisco José de Caldas 39
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.
Implementar
3.1 Crear entregables: En este proceso, el Equipo Scrum
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
Universidad Distrital Francisco José de Caldas 40
apropiada.
4. Revisión y
feedback
4.1 Demostración y validación delSprint: En este proceso, el
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.
Lanzamiento
5.1 Envío de entregables: En este proceso, el 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.
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]

Universidad Distrital Francisco José de Caldas 41
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.

Universidad Distrital Francisco José de Caldas 42
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.

Universidad Distrital Francisco José de Caldas 43
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