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
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
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
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
CAPÍTULO 9. INGENIERIA DEL PROYECTO... 47
9.1. PLAN GENERAL ... 47
9.1.1. RECURSOS ... 50
9.1.2. PRESUPUESTO ... 51
9.2. MODELAMIENTO DEL NEGOCIO ... 53
9.2.1. ASPECTOS DE TRABAJO DE GRADO ... 53
9.2.2. MODALIDADES DE TRABAJO DE GRADO ... 53
9.3. REQUERIMIENTOS... 57
9.3.1. DEFINICIÓN DE ACTORES Y ROLES. ... 57
9.3.2. REQUERIMIENTOS FUNCIONALES. ... 60
9.3.1.1. REQUERIMIENTOS DE PROCEDIMIENTOS GENERALES ... 60
9.3.1.2. REQUERIMIENTOS MODALIDAD PASANTIA ... 62
9.3.1.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
Universidad Distrital Francisco José de Caldas 4
ÍNDICE DE FIGURAS
FIGURA 1.PROTOTIPO EN SGPG-UD ... 17
FIGURA 2.MÓDULO UDLEARN. ... 18
FIGURA 3COMPONENTE 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
Í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
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
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.
Universidad Distrital Francisco José de Caldas 8 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.
CAPÍTULO 2. PLANTEAMIENTO DEL PROBLEMA
En la actualidad, la Universidad Distrital Francisco José de Caldas hace el proceso de control a los trabajos de grado realizado por los estudiantes de forma manual, esto es debido a que no existen sistemas de control automatizado que faciliten de manera eficiente la asignación, organización, acceso, disposición y evaluación de estos trabajos.
Dado que los procesos realizados para el registro del documento del proyecto de grado en las diferentes modalidades establecidas en el acuerdo 038 de 2015 (Universidad Distrital Francisco José de Caldas, 2015) no se hacen de manera virtual ni automatizada, no hay un control unificado sobre los cambios realizados por parte del estudiante sobre cada entrega a revisión del documento del proyecto de grado, lo cual dificulta la evaluación conjunta por parte de los evaluadores encargados. La consulta concurrente de los documentos registrados implica copias físicas del mismo, lo que ocasiona problemas e inconsistencias en las versiones de los documentos consultados, pues no es posible el acceso de manera inmediata a las observaciones y/o modificaciones que se hayan generado al documento una vez se haya solicitado la copia. No hay control automatizado sobre los tiempos en que el documento debe permanecer en una determinada fase del proceso, lo que conlleva a realizar seguimiento manual por parte del estudiante en conjunto con el proyecto curricular [2]. No existe un lugar virtual donde el estudiante pueda consultar el estado en el que se encuentra su documento sin necesidad de ir a consultarlo directamente en la universidad en horarios de atención. No hay un canal de comunicación virtual por donde se le facilite la comunicación al estudiante con sus respectivos evaluadores o directores.
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.
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].
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.
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.
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.
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,
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,
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
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.
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.
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.
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ón del negocio para el project más grande.
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.
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
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 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
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
7.5 HISTORIA DE USUARIO
Las Historias de Usuario surgieron en eXtremme Programming (XP) como una respuesta a una situación habitual en los proyectos de desarrollo de software: los clientes o especialistas de negocio se comunican con los equipos de desarrollo a través de extensos documentos conocidos como especificaciones funcionales. A su vez, las especificaciones funcionales son la documentación de supuestos y están sujetas a interpretaciones, lo que causa malos entendidos y que finalmente el software construido no se corresponda con la realidad esperada [9].
7.5.1 COMPONENTES
Una Historia de Usuario se compone de 3 elementos, también conocidos como “las tres Cs” de las Historias de Usuario:
Card (Ficha): Toda historia de usuario debe poder describirse de manera corta en una ficha. Si una Historia de Usuario no puede describirse en ese tamaño, es una señal de que estamos traspasando las fronteras y comunicando demasiada información que debería compartirse cara a cara.
Conversación: Toda historia de usuario debe tener una conversación con el Product Owner. Una comunicación cara a cara que intercambia no solo información sino también pensamientos, opiniones y sentimientos.
Confirmación: Toda historia de usuario debe estar lo suficientemente explicada para que el equipo de desarrollo sepa qué es lo que debe construir y qué es lo que el Product Owner espera. Esto se conoce también como Criterios de Aceptación.
7.5.2 REDACCIÓN
La redacción para una historia de usuario debe cumplir los siguientes criterios:
Primera Persona: La redacción en primera persona de la Historia de Usuario invita a quien la lee a ponerse en el lugar del usuario.
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.
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.
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.
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.
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].
Replicación asincrónica/sincrónica / Streaming replication - Hot Standby
PITR - point in time recovery
Copias de seguridad en caliente (Online/hot backups)
Unicode
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
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).
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
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 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 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.
Universidad Distrital Francisco José de Caldas 40 apropiada.
4. Revisión y feedback
4.1 Demostración y validación del Sprint: En este proceso, el Equipo Scrum le demuestra el Sprint Deliverable al Propietario del producto y a los Socios relevantes en un Sprint Review 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.
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.
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.
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.
Universidad Distrital Francisco José de Caldas 44 8. 2 EL MÉTODO DE TRABAJO
SCRUM como método, enfatiza valores y prácticas de gestión, sin pronunciarse sobre requerimientos, prácticas de desarrollo, implementación y demás cuestiones técnicas. Este delega completamente al equipo la responsabilidad de decidir la mejor manera de trabajar, y de esta manera ofrece comodidad y rendimiento para ser lo más productivo posible; por esta característica se complementó durante la ejecución del proyecto métodos, procedimientos y herramientas utilizados en otras metodologías como por ejemplo OpenUP/OAS.
8.2.1. FASES DEL PROYECTO
El rol planteado dentro de este proyecto hace parte del equipo de desarrollo, realizando las funciones de analista y arquitecto de la base de datos sobre las modalidades antes contempladas, también se contempla colaborar en las etapas de desarrollo y pruebas que no serán presentadas en este proyecto, debido a que el proceso se trabajara por fases a continuación presentamos las practicas que se realizarán sobre cada fase en el proyecto teniendo en cuenta que en cada una de estas se seguirá la metodología de SCRUM.
8.2.1.1 FASE INICIAL
En esta fase es necesario realizar una colaboración entre los integrantes del equipo de desarrollo y el product owner o los interesados (Stakeholders) para determinar los objetivos y la viabilidad del proyecto a realizarse.
Se realiza un primer sprint el cual tiene como objetivo realizar plan general (ítem 1.2 de la tabla del proceso metodológico SCRUM), en la cual se plantean los parámetros para realizar el direccionamiento y seguimiento al proyecto, define cada uno de los sprints a realizarse y su duración para la elaboración del proyecto, y describe cómo está organizado el proyecto, cuales son los recursos requeridos para su consecución (Tiempo, Tecnológicos, Financieros, Físicos y Humanos entre otros).
8.2.1.2 FASE INTERMEDIA
En esta fase se realiza el proceso de comprensión y manejo del sistema, donde se analiza de manera más precisa los requerimientos a tener en cuenta para la funcionalidad del sistema en su totalidad, partiendo del análisis de cada uno de sus componentes.
Se utilizan mecanismos para el levantamiento de requerimientos que permiten una mejor comprensión del negocio por parte del cliente y del equipo de trabajo, de esta manera es posible tener en cuenta situaciones que podrían presentarse y que no se hallan tenido en cuenta con anterioridad. Se hace uso de representación en flujogramas de BPMN utilizando la herramienta de Eclipse Modeling Framework jbpm, y se crean prototipos no funcionales cuyo objetivo sea la visualización de posibles interfaces para el desarrollo, por ejemplo, formularios, menús, logins, etc., estos prototipos serán realizados en pencil.
Se realizarán reuniones con el product owner e interesados para discutir acerca del levantamiento de requerimientos, el análisis de los flujogramas y la creación de prototipos, de esta manera conseguir una buena retroalimentación para ser más exactos en lo que se requiere en la construcción del producto a implementarse.
A partir de los requerimientos se definen todos los posibles roles que estarán presentes en el sistema, y cada uno de estos con sus respectivas funcionalidades en el sistema.
8.2.1.2 FASE FINAL
En esta fase se construye el modelo de datos en base a los requerimientos antes completados, se realiza el modelo relacional que se encargue de mantener la integridad de la información para todas las modalidades de trabajos de grado estipuladas en el acuerdo N° 038 del 28 de julio de 2015 de manera óptima y ordenada, en este modelo se debe contemplar la integración con otras bases de datos cuando sea necesario.
CAPÍTULO 9. INGENIERIA DEL PROYECTO
El desarrollo del proyecto se realizó siguiendo los lineamientos de la metodología de SCRUM y acoplándose a las fases antes mencionadas, partiendo de la construcción del plan general, hasta la creación del modelo de datos óptimo para el sistema.
Al hacer el análisis sobre el sistema a realizarse y los requerimientos a solucionar se encontró que era posible para el negocio generalizar varios aspectos que atañen a las modalidades de grado, de esta forma se listaron los aspectos en común y se trazó un flujo general del negocio y para las demás características propias de cada modalidad se realizó un análisis individual sobre cada modalidad fusionando el flujo general y las características propias o extras de la modalidad, de esta forma fue posible la creación de un modelo soporte la integridad de los datos para todas las modalidades.
9.1. PLAN GENERAL
Para la construcción del plan general se tomaron en cuenta aspectos como la duración de la pasantía, la complejidad del negocio, el manejo de herramientas a utilizarse, los recursos y el presupuesto para realizarse, se construyó un modelo en el cual se muestra cada iteración o sprint del proyecto en cada una se repite un proceso de trabajo iterativo, para de esta manera proporcionar un resultado completo sobre el producto final.
Universidad Distrital Francisco José de Caldas 48 Modelado del negocio:
El modelado del negocio tiene como objetivo el análisis y la comprensión simple general de la realidad y funcionalidad del negocio. En esta fase se plantea un marco de trabajo base para el desarrollo del proyecto, basado en la complejidad del mismo, se socializan aspectos con el prodct owner para determinar el posible encaminamiento del proyecto.
Requerimientos:
Se realiza el análisis de los requerimientos con el propósito de especificar detalladamente las funcionalidades que deberán ser soportadas por el sistema a realizarse, una vez obtenidos los requerimientos se construyen historias de usuario generales y se crean los respectivos prototipos.
Análisis:
En el análisis se toman los requerimientos antes especificados y se propone la forma de tratarlos, aquí se definen las características que deberá presentar el diseño para el soporte de la implementación de los requerimientos de manera efectiva, también se representan los procesos del sistema mediante el uso de flujogramas que dan un mejor entendimiento del negocio.
Diseño:
En esta fase se construye en base a lo antes analizado el diseño de la base de datos, definiendo inicialmente el rol de los entes que interactúan en el sistema, los controles que se llevaran a cabo en la base de datos, y la interacción que esta tendrá con otros esquemas manejados por la oficina.
Sprint Duración Actividades Comprensión del
Negocio
1 Semana Reunión con el Product Owner.
Lectura y comprensión del acuerdo 038 de 2015.
Reunión con el equipo de desarrollo. Planeación del
1 Semana Reunión Product Owner Análisis Acuerdo 038 de 2015 Definición de modalidades Definición de roles 3 Días Reunión Product Owner
Reunión Scrum Master
Especificación de actores y roles Especificación de
requerimientos
2 Semanas Reunión Product Owner
Listar requerimientos funcionales Listar requerimientos no funcionales Análisis de
requerimientos
4 Días Reunión equipo de desarrollo.
Análisis y descarte de procesos no contemplados para el Acuerdo 038 de 2015 Generalización de
procesos
2 Semanas Comparación de procesos
Planteamiento de procesos generales Comparación de procesos en modalidades Modelamiento
procesos de negocio
1 Semana Construcción de BPMN general Construcción de BPMN por modalidad
5 Semanas Diseño del modelo de la base de datos Reunión con arquitecto
Reunión con DBA
Universidad Distrital Francisco José de Caldas 50 9.1.1. RECURSOS
Para la realización de este proyecto fueron necesarios recurso humano, infraestructura y tiempo como se muestra en la “Tabla 8.1”:
Tipo de Recurso Recurso Cantidad
Humano Analista y arquitecto 1
Humano Director Interno 1
Humano Director Externo 1
Infraestructura Alquiler de Computador 1
Infraestructura Almacenamiento disponible en google drive para guardar documentación
2 Gigas
Infraestructura Internet 6 meses
Infraestructura Luz 6 meses
Transporte Transporte (Transmilenio, SITP, etc) 6 meses
Varios Fotocopias, CD’s, otros 6 meses Tabla 3. Recursos necesarios para la realización del proyecto
Basado de: Oficina Asesora de Sistemas [5].
9.1.2. PRESUPUESTO
El presupuesto fue calculado principalmente con los recursos mínimos para la realización del proyecto ya antes definidos, el cálculo realizado se realiza sobre la cantidad del recurso, el valor unitario y el valor total de cada tipo de recurso como se indica en la siguiente tabla:
Tipo de Recurso
Recurso Cantidad Valor
Unitario
Valor Total
Humano Analista 1(6 meses) $2.000.000 $ 12.000.000
Humano Director Interno 1(6 meses) $1.800.000 $10.800.000 Humano Director Externo 1(6 meses) $1.800.000 $10.800.000 Infraestructura Alquiler de
Computador
2(6 meses) $100.000 $ 1.200.000
Infraestructura Internet 6 meses $80.000 $ 480.000
Infraestructura Luz 6 meses $20.000 $ 120.000
Basado de: Oficina Asesora de Sistemas [5].
