proyecto_final base datos

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