Prototipo de apoyo a la gestión de proyectos de desarrollo de software

Texto completo

(1)UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS ESPECIALIZACIÓN EN PROYECTOS INFORMÁTICOS. ANTEPROYECTO DE TRABAJO DE GRADO. PROTOTIPO DE APOYO A LA GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE. SABRINA SUAREZ ARRIETA. DIRECTOR: JUAN MANUEL SANCHEZ. BOGOTÁ, 2019 1.

(2) SUMMARY This project proposes the development of a software prototype to improve the monitoring and management of software development projects whose methodology is based on a hybrid between Scrum and Kanban, based on the fact that there are multiple tools on the market that allow tracking of tasks for each one of those involved in the development of the software (quality analysts, developers, project managers, Scrum masters, etc.), however, none of them gives global diagnoses of the project. The result will be the implementation of a prototype that enables the centralization of the information of the tasks of the actors of the software product development process for the optimization of the tasks, better visualization of the status of the project at any time and strengthening of the roles in the teams. KEY WORDS: Prototype, Scrum, Kanban, agile methodologies, software development.. 2.

(3) AGRADECIMIENTOS. A mi familia, en especial a mis padres por ser mi apoyo constante en cada decisión y cada paso que di en el camino, ellos me dieron la fuerza y la inspiración para terminar este proyecto que con tanto amor me ayudaron a comenzar. A mis profesores los cuales me poyaron en la construcción de este producto, brindándome sus conocimientos y guía durante el proceso, y siempre motivándome a realizarlo con excelencia.. 3.

(4) CONTENIDO. SUMMARY AGRADECIMIENTOS RESUMEN PARTE I. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN 1.1. Planteamiento/ Identificación del problema 1.2. Objetivos 1.2.1. Objetivo general 1.2.2. Objetivos específicos 1.3. Justificación del trabajo de investigación 1.4. Hipótesis 1.5. Metodología de la investigación 1.5.1. Tipo de investigación 1.5.2. Metodología a aplicar 1.5.3. Método a aplicar CAPÍTULO II FUNDAMENTACIÓN TEÓRICA 2.1. Marco teórico 2.2. Marco conceptual 2.3. Estudio de sistemas previos PARTE II. DESARROLLO DE LA INVESTIGACIÓN CAPÍTULO III LEVANTAMIENTO DE INFORMACIÓN Y ANÁLISIS DE SITUACIÓN ACTUAL 3.1. Análisis actual del modelo de negocio. 3.2. Levantamiento de requerimiento y especificación de casos de usos. 3.3. Definición de la arquitectura del desarrollo. CAPÍTULO IV DESARROLLO 4.1. Diagrama entidades de la base de datos. 4.2. Diagrama de arquitectura del backend. PARTE III. CIERRE Y RESULTADOS DE LA INVESTIGACIÓN CAPÍTULO V. FUNCIONAMIENTO DEL PROTOTIPO CAPITULO VI. RESULTADOS Y DISCUSIÓN 4.

(5) CAPITULO VII. CONCLUSIONES 7.1. Verificación, contraste y evaluación de los objetivos 7.2. Síntesis del modelo propuesto 7.3. Aportes originales 7.4. Líneas de investigación futuras REFERENCIAS BIBLIOGRAFICAS. 5.

(6) RESUMEN Este proyecto plantea la elaboración un prototipo de software para mejorar el seguimiento y la gestión de los proyectos de desarrollo de software cuya metodología este basado en un hibrido entre Scrum y Kanban, partiendo del hecho que existen múltiples herramientas en el mercado que permiten realizar el seguimiento de tareas para cada uno de los involucrados en la elaboración del software (analistas de calidad, desarrolladores, directores de proyectos, Scrum masters, etc.), sin embargo, ninguna da diagnósticos globales del proyecto. Como resultado se dará la implementación de un prototipo que posibilite la centralización de la información de las tareas de los actores del proceso de desarrollo del producto de software para la optimización de las tareas, mejor visualización del estado del proyecto en cualquier momento y fortalecimiento de los roles en los equipos. PALABRAS CLAVE: Prototipo, Scrum, Kanban, metodologías agiles, desarrollo de software.. 6.

(7) PARTE I. CONTEXTUALIZACIÓN DE LA INVESTIGACIÓN CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN 1.1. Planteamiento/ Identificación del problema En la actualidad, la mayoría de las compañías están buscando crecer y volverse más competitivas en el mercado, esto se busca a través de distintas estrategias, pero una de las más comunes por la evolución y crecimiento de las TI (tecnologías de la información) es la optimización de los procesos de la compañía a través de la creación de aplicaciones que le brinden un valor agregado al negocio. Por otra parte, a pesar de lo populares que son las soluciones tecnológicas hoy en día, la mayoría de los proyectos fracasan y son abandonados, o son realizados, pero costando mucho más de lo planeado tanto en esfuerzo (tiempo) como en precios [1], por esta razón se realizan metodologías, procesos y herramientas que ayuden a contrarrestar o por lo menos mitigar las razones por las cuales se generan estos fallos. Sin embargo, a pesar de la existencia de estos modelos, y que son muchos los proyectos que los adopten, estos siguen fallando, aunque en un menor volumen, esto da a entender que, aunque las metodologías tengan excelentes propuestas al final el resultado dependerá de la implementación de estas.. 1.2. Objetivos Los objetivos por cumplir en este proyecto se presentan a continuación:. 1.2.1. Objetivo general Desarrollar un prototipo para la implementación de las metodologías agiles (Scrum y Kanban) permitiendo a los equipos de trabajo adaptar sus procesos de desarrollo a la metodología.. 1.2.2. Objetivos específicos ∙. Integrar la información que proviene de distintos procesos del desarrollo diseñada y construida con una de las últimas tecnologías en frontend Angular 7.. ∙. Realizar seguimiento a las actividades no planeadas y los retrasos de los tiempos de las actividades asignadas definidas en los sprint de la metodología Scrum. 7.

(8) ∙. Visualizar de manera detallada el porqué de los cambios en los cronogramas establecidos a través de un tablero Kanban digitalizado.. ∙. Retroalimentar con base en la data obtenida durante el sprint a cada uno de los colaboradores.. 1.3. Justificación del trabajo de investigación Los equipos de desarrollo y mantenimiento de software tienen como misión entregar a los clientes soluciones tecnológicas que les permitan crecer a través de la optimización de sus procesos como compañía, esto supone una gran responsabilidad en el cumplimiento de la calidad, tiempos de fabricación y costes del producto tecnológico. Dada la importancia de cumplir con estos estándares este proyecto encuentra una justificación de tipo practico, ya que requiere el desarrollo de un prototipo que se enfoque principalmente en: ∙. Realizar una traza de las actividades de cada uno de los miembros del equipo.. ∙. Integrar la información de los múltiples procesos que se llevan a cabo durante la construcción del software.. ∙. Validar los tiempos y los desfases sufridos dentro de cada uno de los periodos de desarrollo de entregables a través del control de las actividades no planeadas.. ∙. Apoyar los procesos de la toma de decisiones del rumbo que debe tomar el proyecto con el fin de cumplir los estándares con los que debe desarrollar el producto.. 1.4. Hipótesis Con base en el planteamiento del problema descrito anteriormente, se define la siguiente hipótesis: “La implementación de un prototipo de metodologías ágiles en los equipos de trabajo en una organización, mejora la visualización de la información de los procesos de construcción de software y facilita la gestión de los proyectos a lo largo de sus ciclos de trabajo.”. 8.

(9) 1.5. Metodología de la investigación A continuación, se describen las herramientas metodológicas que se utilizaron, el tipo de investigación y las herramientas de recolección de información a usar en el desarrollo del proyecto.. 1.5.1. Tipo de investigación Para el proyecto que se desarrolló, se identifica un tipo de investigación de carácter “Explicativa”, la cual busca responder a una necesidad o problemática de implementación de metodologías ágiles en compañías colombianas. Esta es complementada con una investigación de tipo “Aplicada”, ya que se está desarrollando un prototipo de software para apoyar la solución de la problemática.. 1.5.2. Metodología a aplicar Se utilizó el marco de trabajo Scrum, dando prioriza a las entregas funcionales, valorando las personas y las interacciones obteniendo la mayor cantidad de retroalimentación del producto y dándole una mayor respuesta al cambio; logrando la finalización exitosa del proyecto.. 1.5.3. Método a aplicar Para conocer y elegir correctamente el modelo aplicable al área de gestión de proyectos de software se utilizará el método “análisis-síntesis”, se fragmenta el tema en conceptos más pequeños para después unirlos en un todo y de esta forma entender mejor el concepto y la aplicación de los diferentes modelos propuestos.. CAPÍTULO II FUNDAMENTACIÓN TEÓRICA A continuación, se dará estructura al marco referencial enfocado en marco teórico para fundamentar el objetivo principal de esta propuesta.. 2.1. Marco teórico Las bases teóricas del presente anteproyecto consisten en hacer revisión de la forma como han evolucionado las metodologías para el desarrollo de proyectos de software y algunos trabajos realizados en el mercado sobre el tema. 9.

(10) Evolución de las metodologías ágiles Para contextualizar sobre cómo las metodologías ágiles, han venido evolucionando, hasta lo que hoy comprende el objeto de este documento, es importante definir una metodología ágil como un enfoque iterativo a la planificación y desarrollo de los proyectos de software [2], Desde 1930 como sociedad empezamos a trabajar en el desarrollo de proyectos de manera ágil e iterativa, sin embargo, no es sino hasta 1975 que es lanzada una guía con la definición y explicación de esta práctica para el desarrollo de software [3], Desde ese momento fueron múltiples los autores que se enfocaron en ampliar el conocimiento sobre esta metodología de creación de software, pero no fue sino hasta el 2001 que se lanza el manifiesto ágil, que reúne los principios y valores bajo los cuales trabajan los equipos [4]. Sin embargo, desde hacía años se estaban diseñando distintas metodologías agiles, con diferentes elementos y funcionamiento, pero que mantenían en esencia la idea de liberar entregables funcionales y la realización de desarrollos de software de manera eficiente, sin concentrarse demasiado en la documentación para invertir los recursos en la atención oportuna de las necesidades del cliente [5]. Entre las metodologías ágiles más famosas encontramos: ∙. Programación extrema: Creada por Kent Beck en 1996 establece un marco de trabajo que empodera a los desarrolladores de software a responder ante los constates cambios de requerimientos solicitados por el cliente, aunque se den en etapas tardías del ciclo de vida del producto, a través de un ciclo de vida organizado (ver Figura1) que contempla los errores y los cambios del producto [6].. 10.

(11) Figura 1. Fases del ciclo de vida programación extrema [7]. ∙. Kanban: es un término japonés, literalmente significa "tarjeta visual", " cartelera" o "letrero". Toyota originalmente fue el primero en utilizar tarjetas kanban para limitar la cantidad de inventario utilizado en "Work in progres (WIP)". Este concepto fue desarrollado por primera vez por Taiichi Ohno a finales de la década de 1940 y actualmente es utilizado en el proceso de desarrollo de software para el mejoramiento de la visibilidad de las etapas en las cuales se encuentran las tareas de acuerdo a la Figura 2 [8].. Figura 2. Tablero Kanban para el desarrollo de software [8] 11.

(12) ∙. Scrum: es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo de productos complejos desde su creación en 1993, el marco de trabajo consiste en los Equipos Scrum, roles, eventos, artefactos y reglas asociadas (ver Figura 3); y está sustentado en 3 pilares: transparencia, inspección y adaptación para la realización de los productos, la idea es que al finalizar cada sprint se logre realizar un entregable funcional, con requerimientos que desee el cliente en su producto y que le permita la evaluación del mismo mientras el producto se sigue construyendo [9].. Figura 3. Marco de trabajo scrum [10].. 2.2. Marco conceptual Para la fundamentación del presente anteproyecto y tener un contexto en la concepción de la metodología en la que nos enfocaremos Scrum, se darán algunas definiciones necesarias para el correcto entendimiento del anteproyecto. 12.

(13) ∙. SPRINT: es el corazón del Scrum, es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “Terminado”, utilizable y potencialmente desplegable. Es más conveniente si la duración de los Sprint es consistente a lo largo del esfuerzo de desarrollo. Cada nuevo Sprint comienza inmediatamente después de la finalización del Sprint previo. Los Sprint contienen y consisten de la Reunión de Planificación del Sprint (Sprint Planning Meeting), los Scrums Diarios (Daily Scrums), el trabajo de desarrollo, la Revisión del Sprint (Sprint Review), y la Retrospectiva del Sprint (Sprint Retrospective). Durante el Sprint: ∙ No se realizan cambios que puedan afectar al Objetivo del Sprint ∙ Los objetivos de calidad no disminuyen ∙ El alcance puede ser clarificado y renegociado entre el Dueño de Producto y el. Equipo de Desarrollo a medida que se va aprendiendo más. ∙. SCRUM MASTER: es el responsable de asegurar que Scrum es entendido y adoptado. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no [9].. ∙. KANBAN: Cartelera o letrero que soporta la metodología Kanban, diseñado para la realización de los seguimientos a las tareas [8].. ∙. HISTORIAS DE USUARIO: Describe la funcionalidad que será evaluada por un usuario de un sistema o software y se compone de 3 aspectos básicos y fundamentales: -. Un título de la historia o funcionalidad que deberá dar una breve introducción del requerimiento.. -. Una descripción o detalle que busca enriquecer el título de la historia y proveer información para la construcción del requerimiento.. -. Documentos o test que permitan determinar cuando la historia se ha finalizado de manera exitosa [17].. 13.

(14) En resumen, las historias de usuario representan los requerimientos del cliente más allá de documentarlos Para la construcción del prototipo se utilizaron 2 tecnologías fundamentales para el desarrollo de las funcionalidades, esto con el objetivo de delimitar el backend (servicios api rest en .Net C#) del frontend (Angular 7), a continuación, se realizará una introducción a la definición de las tecnologías. -. .NET C#: Es un lenguaje orientado a objetos que permite a los desarrolladores construir una variedad de aplicaciones seguras y robustas que se ejecutan en .NET Framework. Permite utilizar C # o VB para crear aplicaciones cliente de Windows, servicios web XML, componentes distribuidos, aplicaciones cliente-servidor, aplicaciones de base de datos, aplicaciones nativas para iOS, Android y Windows [19]. Visual C # proporciona un editor de código avanzado, diseñadores de interfaz de usuario convenientes, depurador integrado y muchas otras herramientas para facilitar el desarrollo de aplicaciones basadas en el lenguaje C # y el Framework .NET [18]. Los programas escritos en C # se compilan en un lenguaje intermedio llamado "MSIL", el equivalente a Bytecode de Java o p-code de Visual Basic. Cualquier lenguaje que se pueda compilar a MSIL puede tomar ventaja de las características de CLR, tales como recolección de basura, reflexión, metadatos, control de versiones, eventos y seguridad, para nombrar unos pocos. Además, una clase escrita en un idioma puede heredar de una clase escrita en otro idioma y anular sus métodos [20].. -. ANGULAR 7: Angular es una plataforma que facilita la creación de aplicaciones web. Angular combina plantillas declarativas, inyección de dependencia, herramientas end to end y mejores prácticas integradas para resolver los desafíos de desarrollo. Angular permite a los desarrolladores crear aplicaciones que viven en la web, el móvil o el escritorio [21]. Angular es una de las soluciones más conocidas para el desarrollo de SPA (single page application), además de React y Vue.js. Ha existido por 10 años y ha pasado por innumerables ajustes desde entonces. La primera versión del marco, AngularJS, comenzó en 2009 (soportada y versionada por Google) [21] y sentó las bases del desarrollo actual de aplicaciones frontend. 14.

(15) 2.3. Estudio de sistemas previos Actualmente la mayoría de empresas que deciden adoptar una metodología ágil, prefieren la utilización de metodologías híbridas, que utilicen características de 2 o más metodologías para realiza un modelo personalizado, una de estas híbridas, comprenden la unión de las metodologías Scrum y Kanban [10]. Con base en esta unión de metodologías vemos numerosas herramientas en el mercado que apoyan el proceso de implementación de las mismas como: Trello [11], ScrumDo [12], Jira [13]. Todas estas a pesar de poseer el módulo de seguimiento de tareas, no permiten realizar seguimientos completos al proyecto como el prototipo propuesto en este proyecto de grado.. PARTE II. DESARROLLO DE LA INVESTIGACIÓN CAPÍTULO III LEVANTAMIENTO DE INFORMACIÓN Y ANÁLISIS DE SITUACIÓN ACTUAL En este capítulo se estudian y describen a fondo las necesidades encontradas que a través del prototipo se buscan resolver, aunque si bien es cierto que este prototipo podría ser utilizado en cualquier empresa, para la creación de nuestro análisis de la situación a especificar nos centraremos en las problemáticas encontradas concretamente en una compañía.. 3.1. Análisis actual del modelo de negocio. Actualmente la empresa de desarrollo de tecnología para sus procesos de desarrollo de software se apoya en el marco de trabajo que brinda SCRUM para el seguimiento y control de las actividades de planeación de requerimientos, desarrollo, pruebas y documentación; de los artefactos que provee SCRUM los que se utilizan actualmente de manera activa en la compañía por los miembros de los equipos son: -. Retrospective meeting. -. Daily meeting 15.

(16) -. Kanban board. Sin embargo, no queda la almacenada la información recolectada de la aplicación de las herramientas de la tecnología, es decir, no queda la bitácora de los sucesos que llevaron al resultado del sprint cuando este es finalizado, por lo cual se pierde la oportunidad de retroalimentar de manera oportuna a los colaboradores, estimando cuáles fueron las verdaderas causas del cumplimiento o incumplimiento de los objetivos del sprint.. 3.2. Levantamiento de requerimiento y especificación de casos de usos. Se realiza la actividad de levantamiento de requerimientos, utilizando un recurso de SCRUM (nuestra metodología de trabajo) llamado “las historias de usuario”, estas se originaron con Extreme Programming, su primera descripción fue escrita en 1998 y está solo afirma que los clientes definen el alcance del proyecto "con historias de usuario, que son como casos de uso". En lugar de ofrecerse como una práctica distinta, se describen como una de las "piezas de juego" utilizadas en el "juego de planificación"[23]. El formato actual de historias de usuario busca que de manera sencilla se logre explicar una funcionalidad completa reemplazando en los equipos Scrum los documentos de definición de requerimientos, estos suelen ser mucho más extensos y se corre el riesgo de representar mal una definición de la necesidad del usuario, el formato estándar extendido para la creación de historias de usuario se compone de -. Identificador de la historia de usuario. -. Usuario que desea tener disponible la funcionalidad. -. Nombre descriptivo para la historia. -. Una prioridad dentro del negocio (Alta, media o baja). -. Riesgo de retrasos o incumplimientos en esta actividad por desconocimiento (Alto, media, baja). -. Puntos estimados de scrum, estos puntos por lo general implican de manera directa la cantidad de horas que se estiman la fórmula es: Horas = puntos estimados X 2. -. Iteración asignada, esta se refiere directamente a la etapa del proyecto en la cual se atenderá esta solicitud.. -. Descripción 16.

(17) -. Validación de las acciones que debe cumplir la historia de usuario para que se considere que se finaliza de manera correcta la historia, también es conocido este punto como criterios de aceptación.. De las figuras 4 a la 11 se observan las historias de usuario creadas para el desarrollo del prototipo, estas quedan priorizadas según la iteración en la que es asignada y el riesgo en desarrollo, se organizan los sprint según los que contengan las actividades de mayor riesgo y prioridad alta para el negocio.. Historia de usuario Número 1 Usuario Administrador Nombre de historia Creación de colaboradores Prioridad en Riesgo en negocio Alta desarrollo Media Puntos estimados 8 Iteración asignada 1 Descripción Como administrador me debe permitir la creación de usuarios a los cuales se les debe poder asignar una capacidad Validación El administrador debe estar en capacidad de crear nuevos miembros del equipo (usuarios) con una capacidad definida Figura 4. Historia de usuario creación de colaboradores.. Historia de usuario Número 2 Usuario Administrador Nombre de historia Creación de tareas Prioridad en Riesgo en negocio Alta desarrollo Media Puntos estimados 8 Iteración asignada 2 Descripción Como administrador me debe permitir la creación de actividades y el poder asignarlas a los miembros del equipo Validación El administrador debe estar en capacidad de crear nuevas tareas y asignarlas a los miembros del equipo teniendo como restricción la capacidad de puntos de cada uno Figura 5. Historia de usuario creación de tareas. 17.

(18) Historia de usuario Número 3 Usuario Administrador Nombre de historia Creación de sprint Prioridad en Riesgo en negocio Alta desarrollo Media Puntos estimados 8 Iteración asignada 1 Descripción Como administrador me debe permitir la creación de los distintos sprint y el poder de asignar miembros del equipo y capacidad del sprint Validación El administrador debe estar en capacidad de crear sprint y asignar tareas dentro de estos Figura 6. Historia de usuario creación del sprint.. Historia de usuario Número 4 Usuario Administrador Nombre de historia Asignación de actividades a un sprint Prioridad en Riesgo en negocio Alta desarrollo Media Puntos estimados 16 Iteración asignada 2 Descripción Como administrador el aplicativo debe permitir asignarles las actividades a un sprint de acuerdo a las condiciones de negocio de que no puede superar la capacidad del sprint Validación El administrador debe poder asignar actividades a un sprint respetando las reglas del negocio Figura 7. Historia de usuario asignación de actividades.. Historia de usuario Número 5 Usuario Administrador Nombre de historia Cambio de estado de una actividad Prioridad en Riesgo en negocio Alta desarrollo Alta Puntos estimados 8 Iteración asignada 3 Descripción 18.

(19) Como administrador el aplicativo me debe permitir cambiar el estado de una actividad (Backlog, en desarrollo, en calidad, terminado) Validación El administrador debe poder cambiar de estado las actividades en el momento que se requiera Figura 8. Historia de usuario cambio de estado de actividades.. Historia de usuario Número 6 Usuario Administrador Nombre de historia Seguimiento de sprint Prioridad en Riesgo en negocio Medio desarrollo Bajo Puntos estimados 8 Iteración asignada 3 Descripción Como administrador el aplicativo debe permitir observar el estado del sprint de mi proyecto, observar el porcentaje de la capacidad del sprint que se ha copado y mi fecha de terminación de actividades Validación El administrador debe poder cambiar de estado las actividades en el momento que se requiera Figura 9. Historia de usuario seguimiento del sprint.. Historia de usuario Número 8 Usuario Administrador Nombre de historia Estimación de medidas de progreso Prioridad en Riesgo en negocio Medio desarrollo Medio Puntos estimados 8 Iteración asignada 3 Descripción Como administrador el aplicativo debe permitir observar en una barra de progreso el estado de las actividades del sprint Validación La barra de progreso debe modificar su color dependiendo de la cantidad de actividades cuyas fechas de entrega están vencidas Figura 10. Historia de usuario estimación de medidas de progreso.. 19.

(20) Historia de usuario Número 9 Usuario Administrador Nombre de historia Realización de evaluaciones de desempeño Prioridad en Riesgo en negocio Medio desarrollo Medio Puntos estimados 8 Iteración asignada 3 Descripción Como líder de equipo el aplicativo debe permitir al dar por finalizado el sprint escribir observaciones del desempeño de los colaboradores Validación Una vez se terminan de escribir las observaciones se enviarán correos electrónicos a los colaboradores con los resultados de su desempeño durante el sprint. Figura 11. Historia de usuario realización de evaluaciones de desempeño. 3.3. Definición de la arquitectura del desarrollo. Una arquitectura es el conjunto de decisiones importantes sobre la organización de un sistema de software, la selección de elementos estructurales y sus interfaces mediante las cuales se compone el sistema, junto con su comportamiento, tal como se especifica en las colaboraciones entre esos elementos, la composición de estos elementos en Subsistemas cada vez más grandes y el estilo arquitectónico que guía a esta organización: estos elementos y sus interfaces, sus colaboraciones y su composición [23]. Con base en la definición de arquitectura presentada por Philippe Kruchten, en la figura 12 podemos observar cuales son los elementos utilizados para el desarrollo de nuestro prototipo, esta arquitectura se basa en un modelo n-capas o n-niveles, los objetos de aplicación se distribuyen en múltiples niveles lógicos, generalmente tres o cuatro, que a su vez pueden contener dentro de cada uno de estos, otros múltiples niveles. En una arquitectura de tres niveles como es en nuestro caso, el servidor de bases de datos no comparte una máquina servidor con el servidor de aplicaciones web. El cliente está en el primer nivel, ya que está en una arquitectura de dos niveles. En el tercer nivel, el servidor de base de datos sirve los datos. Por motivos de rendimiento, el servidor de la base de datos generalmente utiliza procedimientos almacenados para manejar parte de la lógica empresarial. El servidor de aplicaciones reside en el segundo nivel. El servidor de aplicaciones maneja la parte de la lógica empresarial que no requiere la funcionalidad que 20.

(21) proporciona el servidor de base de datos. En este enfoque, los componentes de hardware y software de los niveles segundo y tercero comparten la responsabilidad por la disponibilidad, escalabilidad y características de rendimiento del entorno web [24].. Figura 12. Arquitectura de la aplicación Para la creación de este prototipo nos basaremos en una arquitectura 3 capas que nos permite dividir de manera adecuada la lógica del negocio en los servicios del back, la capa de presentación y la capa de repositorio o base de datos, esto permite cumplir con las buenas prácticas en desarrollo de software como los principios SOLID, la apropiación de estos nos permiten crear una aplicación web con escalabilidad, mantenibilidad, fiabilidad, extensibilidad, rendimiento, gestionabilidad, y seguridad por ser multicapa.. 21.

(22) CAPÍTULO IV DESARROLLO En este capítulo se especifica el diseño arquitectónico de la solución en cada una de sus capas, esto con el fin de ofrecer detalles técnicos de la creación del prototipo y una explicación clara de los beneficios que ofrecen las decisiones arquitectónicas que se tomaron.. 4.1. Diagrama entidades de la base de datos. Para la definición del modelo de base de datos en primera instancia siempre se suele recurrir al recurso de diagramas de entidad- relación, estos diagramas permiten la representación de las entidades, sus atributos y las relaciones que tienen entre sí, en este caso se representan en la figura 13 las entidades que conviven en nuestro sistema y cómo interactúan entre sí.. 22.

(23) Figura 13. Diagrama de entidad-relación. Para la mayor comprensión del diagrama se aclara las convenciones representadas en la figura 14.. Figura 14. Convenciones del diagrama de entidad-relación 23.

(24) A continuación, encontramos en el diagrama de entidades identificadas cuales son las fundamentales para la primera entrega funcional de nuestra aplicación PROJECT TRACKER -. Colaboradores. -. Sprint. -. Tareas. El resto de entidades son creadas por la necesidad de especificar dentro del modelo todas las relaciones que se presentan entre las entidades principales, algunas como la tabla HostoricoCambioEstado permite llevar un registro del histórico de cada cambio de estado realizado a cada una de las tareas, por otra parte, tablas como Estados y Tipo son diseñadas para almacenar elementos de parametrización.. 4.2. Diagrama de arquitectura del backend. Como se mencionaba en la definición de la arquitectura general del sistema, se utilizó un modelo multicapa para todo el sistema, una de las capas era la que definía la comunicación entre el frontend y la base de datos, esta capa llamada la capa de backend, será la encargada de definir los servicios que serán consumidos por el frontend, con el fin de almacenar toda la información recolectada por este a través de formularios, transacciones en el panel principal, entre otros. Esta información será almacenada en la base de datos con la finalidad de que posteriormente sea consumida para la generación de gráficos y reportes, estas funcionalidades están soportadas por la arquitectura de backend 3-capas planteada en la figura 15. 24.

(25) Figura 15. Arquitectura de los servicios backend Este modelo de arquitectura se basa en el Doman Oriented N-Layered architecture desarrollado por Microsoft donde divide de manera explícita las funciones de cada una de las capas a las que se hace referencia esto para lograr la mantenibilidad y escalabilidad en nuestra aplicación construida. Capa de aplicación La capa de aplicación incluye principalmente los Servicios de aplicación que utilizan la capa de dominio y los objetos de dominio (Servicios de dominio, Entidades ...) para realizar las funcionalidades de aplicación solicitadas. Utiliza los objetos de transferencia de datos (DTO) para obtener datos y devolverlos a la presentación o la capa de servicio distribuida.. 25.

(26) Capa de dominio Esta es la capa principal que implementa nuestra lógica de dominio. Incluye Entidades, Objetos de valor y Servicios de dominio para realizar la lógica de negocios / dominio. Define las Interfaces de Repositorio para leer y conservar entidades del origen de datos (un DBMS). Capa de Repositorio La capa de infraestructura hace que otras capas funcionen: implementa las interfaces del repositorio (utilizando Entity Framework Core, por ejemplo) para trabajar con la base de datos real. También puede incluye la integración a un proveedor para enviar correos electrónicos. Esta no es una capa estricta debajo de todas las capas, pero en realidad admite otras capas implementando los conceptos abstractos de las mismas.. PARTE III. CIERRE Y RESULTADOS DE LA INVESTIGACIÓN CAPÍTULO V. FUNCIONAMIENTO DEL PROTOTIPO A continuación, se presentan las imágenes del funcionamiento del prototipo, este permite la creación de colaboradores y la visualización de todos elementos listándolos cuando se requiere desde el panel principal.. Figura 16. Pantalla principal. 26.

(27) Para la creación del colaborador se requiere un correo electrónico de la persona para el envío de notificaciones en caso de que el colaborador sea asignado a un sprint, en ese caso informar cual es la capacidad que se le fue asignada, también la asignación de actividades y los tiempos y fechas máximas estipuladas para las actividades, así mismo los cambios de estado en cada una de ellas y por último un correo de retroalimentación del rendimiento del colaborador al final del sprint.. Figura 17. Creación de colaborador En la creación del sprint permite a través de una pagina asignar cuales son los colaboradores que estarán trabajando en el sprint y de esta manera por cada colaborador preguntar la disponibilidad de días por semanas y de horas por día que este puede trabajar en el proyecto, es importante para el momento de asignar las actividades a los colaboradores cuando se estén creando en el board ya que no permite asignar las actividades a un colaborador si ha excedido su capacidad.. 27.

(28) Figura 18. Creación de sprint El board permite la creación de todas las actividades y llevar el seguimiento de los estados en los que se encuentran, estas se dividen en 4 categorías: -. Pendientes: Son todas aquellas actividades que se han reportado para la realización por parte del equipo, sin embargo, todavía no han sido asignadas para la realización del sprint. -. To do: Son las actividades que han sido incluidas dentro del sprint y que aún no se han comenzado a desarrollar.. -. Doing: Son todas las actividades que se están ejecutando en este momento por parte del equipo.. -. Tested: Son las actividades que el equipo de desarrollo ha finalizado y que el equipo de QA está en el proceso de revisión del entregable.. -. Done: Todas las actividades que han superado los criterios de aceptación definidos en las historias de usuario y que se convierten en productos viables para su entrega.. 28.

(29) Figura 19. Tablero Kanban Adicional de la rápida inspección de los estados de las actividades encontramos en el board las fechas de inicio y finalización del sprint, podemos obtener una gran cantidad de reportes al seleccionar la opción de Ver Reportes (Figura 20) y podemos asociar nuevos colaboradores a nuestro sprint en la opción Agregar Colaborador, indicándole a cada uno su disponibilidad (Figura 21).. Figura 20. Reportes generales y por desempeño de colaborador. 29.

(30) Figura 21. Asociación de colaborador al sprint Una vez se tengan asociados colaboradores se puede proceder a la creación de las actividades a seleccionar la opción Crear Actividad, esta opción nos permite ingresar la información de cada una de las actividades como los son el nombre, el responsable, el peso de la actividad (una unidad de peso significa 2 horas de esfuerzo), la fecha de finalización máxima y a el tipo de proceso al que corresponde (Figura 22).. Figura 21. Creación de actividades Con el objetivo de la realización de retroalimentaciones constantes, al final del sprint el usuario administrador tiene la obligación de escribir observaciones del desempeño de cada colaborador y esta información le será enviada para que tenga el conocimiento de su desempeño durante el sprint, los comentarios positivos o negativos por parte de su líder de equipo y los aspectos a mejorar en su rendimiento (Figura 22).. 30.

(31) Figura 22. Retroalimentación continua. CAPITULO VI. SATISFACCIÓN DE LOS POSIBLES USUARIOS FINALES Con el objetivo de validar el nivel de aceptación de los usuarios con respecto a las funcionalidades que equipan el prototipo, se realiza una encuesta entre los integrantes de un grupo de trabajo en la empresa de desarrollo para la cual se ha pensado el desarrollo, las respuestas dadas están visualizadas en las figuras desde la 20 a la 26, a continuación, se presentan los resultados de la encuesta:. Figura 23. Justificación de encuesta. 31.

(32) Figura 24. Resumen de respuestas primera pregunta de la encuesta. Figura 25. Resumen de respuestas segunda pregunta de la encuesta. 32.

(33) Figura 26. Resumen de respuestas tercera pregunta de la encuesta. Figura 27. Resumen de respuestas cuarta pregunta de la encuesta. 33.

(34) Figura 28. Resumen de respuestas quinta pregunta de la encuesta. Figura 29. Resumen de respuestas sexta pregunta de la encuesta Como conclusiones de la encuesta, podemos obtener que todos los miembros del equipo seleccionado para tener el primer acercamiento con el prototipo realmente consideran necesario utilizar algún tipo de herramienta para la gestión de sus actividades, y que si bien este no es un producto completamente distinto a los que están actualmente en el mercado, tiene características diferenciadoras que como miembros de equipo realmente valoran y sienten que hacían falta dentro de las herramientas del mercado.. 34.

(35) Sobre todo, esta encuesta demuestra la acogida del prototipo entre los miembros del equipo, y que se sienten cómodos en el manejo además de pensar que es realmente un apoyo en la detección temprana de desfases en el proyecto y como promotor de la retroalimentación continua. También a través de la encuesta realizada se llega a la conclusión de que se podría mejorar la experiencia de usuario, de modo que los colaboradores sientan que el prototipo es completamente amigable en su uso constante dentro del proyecto.. CAPITULO VII. CONCLUSIONES 7.1. Verificación, contraste y evaluación de los objetivos Como premisa del proyecto se estableció que la meta era “desarrollar un prototipo para la implementación de las metodologías agiles (Scrum y Kanban) permitiendo a los equipos de trabajo adaptar sus procesos de desarrollo a la metodología”, a través del prototipo se logró crear una herramienta que permite la implementación un hibrido entre ambas metodologías, a través del uso de tecnologías de vanguardia en el desarrollo de Frontend web como lo es Angular 7. Adicional nuestro prototipo asegura un seguimiento continuo al estado del sprint, y permite la visualización de los atrasos en los tiempos de una manera que es transparente para el líder de equipo y le permite tomar decisiones para el mejoramiento del estado general del proyecto, a través de la visualización del desempeño de los miembros del equipo y el reasignar cargas dependiendo de la capacidad de cada colaborador y su desempeño durante el sprint, de esta manera mejorando las posibilidades de terminar el sprint de forma exitosa. Finalizando para lograr el seguimiento de las actividades no planeadas, estas son categorizados según su tipo (mejora, error - bug) en cuanto este tipo de actividades entran al sprint se puede tener un seguimiento constante a esas actividades, gracias a la facilidad de filtrarlas.. 35.

(36) 7.2. Síntesis del modelo propuesto El modelo tiene como propósito principal permitir a los equipos de trabajo adaptar sus procesos de desarrollo a la metodología hibrida entre Scrum y Kanban, plasmar el proceso de avance de las actividades y almacenar esa información para a través del seguimiento continuo, facilitar la toma de decisiones sobre la dirección que debe tomar el proyecto para el complimiento de los objetivos planteados durante los rangos de las fechas esperadas. Para cumplir con lo anterior este prototipo cuenta con 3 módulos principales: . Administración de actividades. . Reportes continuos. . Notificaciones. El módulo de administración de actividades nos permite llevar el seguimiento sobre todas las acciones que se realizan sobre las actividades dentro de un sprint, a su vez le apoya al líder de equipo en su control de creación de actividades, notificándole si ha excedido su capacidad de horas de trabajo para la asignación de las cargas laborales entre los colaboradores, a su vez permite que estas cargas laborales estén definidas por sprint y por colaborador de esta manera es muy fácil identificar cuáles son los miembros de equipo que se encuentran más saturados. El módulo de reportes continuos permite tener en tiempo real graficas que informan sobre el estado de las actividades como, que porcentaje general de actividades para el sprint se han completado, cual porcentaje de las actividades fueron terminadas antes de su fecha propuesta, que porcentaje de las actividades fueron finalizadas posterior a su fecha propuesta y cuál es el nivel de avance de cada uno de los colaboradores del sprint. Por último, el módulo de notificaciones le permite al responsable del equipo informar a sus colaboradores sus opiniones sobre el desempeño que tuvieron cada uno de ellos durante en el sprint basándose en las métricas, esto permite no solo registrar los correctivos de los que se le informa al colaborador, sino también de sus logros y reconocimientos, esta modulo podría incluso ser representativo dentro de la política organizacional para la toma de decisiones con respecto a un colaborador en conjunto con la evaluación de desempeño, de manera que esta sea complementada.. 36.

(37) 7.3. Aportes originales Se propone un modelo que busca integrar de una manera más cohesiva el desarrollo de actividades con los colaboradores, notificando constantemente, permitiendo establecer la capacidad de cada uno y evaluando de manera individual en todo momento el rendimiento con respecto a las tareas, las fechas de vencimiento para cada uno y permite llevar una retroalimentación continúa permitiendo enviar constantemente las observaciones del trabajo realizado en cada uno de los sprint realizados. A nivel de proyecto también tiene un aporte único ya que permite en todo momento evaluar que tan efectivo está siendo la gestión de las actividades para la fase de un proyecto (Sprint), de una manera que permite rápidos análisis sobre el estado del proyecto, facilitando la toma de decisiones para los líderes de equipos.. 7.4. Líneas de investigación futuras Como futuras líneas de investigación posibles se sugiere escalar la versión entregada en este trabajo de grado para incluir dentro de la aplicación a los usuarios colaboradores, esto con el fin de que ellos sean capaces de compartir los avances realizados en tiempo real y no recaiga sobre el líder del equipo la responsabilidad de suministrar la información, adicional la posibilidad de agregar nuevas funcionalidades a nivel de notificaciones, como al pasar una actividad a testing poder elegir el colaborador de QA a quien se deberá informar que es el encargado de realizar las pruebas de la actividad, también agregar la opción de adjuntar evidencia en la actividad en cada una de sus etapas de verificación, esto para facilitar la integración entre las fases de las actividades. Es de recalcar que el principal impacto de esta herramienta se verá al estudiar cómo interactúan los equipos con ella, y como principal línea de investigación se propone una observación periódica de aspectos como -. El rendimiento del equipo alcanzado por sprint.. -. La satisfacción del líder de equipo con el trabajo realizado.. -. La satisfacción de los colaboradores con respecto a la transparencia en sus evaluaciones de desempeño.. 37.

(38) Esto para medir el cumplimiento de los objetivos en el contexto de una compañía para la que fue diseñada esta solución con las características de que sea una empresa que desea adoptar metodologías agiles en su proceso de construcción de software aun teniendo productos en mantenimiento los cuales están en producción y deben ser no solo corregidos los incidentes que se presenten, sino también creadas nuevas funcionalidades para actualizar y mejorar producto para que este no se vuelva obsoleto.. REFERENCIAS BIBLIOGRAFICAS [1] The Standish Group, "Chaos Report," 2016. [Online]. Available: https://www.projectsmart.co.uk/white-papers/chaos-report.pdf. [2] j. Flahiff, Being Agile in a Waterfall World: A guide for complex organizations, Createspace Independent Pub, 2014. [3] A. J. T. Victor R. Basil, «Iterative enhancement: A practical technique for,» IEEE, 1975. [4] microsoft, «https://msdn.microsoft.com,» 2013. [En línea]. Available: https://msdn.microsoft.com/es-es/library/dd997578(v=vs.120).aspx. [5] L. Jiang y A. Eberlein, «An Analysis of the History of Classical Software,» IEEE, 2009. [6] UKESSAYS, «UKESSAYS,» 2015. [En línea]. Available: https://www.ukessays.com/essays/information-technology/the-history-of-extremeprogramming-information-technology-essay.php#citethis. [7] Extreme Programming, «http://www.extremeprogramming.org,» 2000. [En línea]. Available: http://www.extremeprogramming.org/map/project.html. [8] H. Raju y Y. Krishnegowda, «KANBAN PULL AND FLOW – A TRANSPARENT WORKFLOW FOR IMPROVED QUALITY AND PRODUCTIVITY IN SOFTWARE DEVELOPMENT,» IEEE, 2013. [9]. K. Schwaber y J. Sutherland, «La Guía Definitiva de Scrum,» 2013.. [10] S. É. R. Ferrão y E. D. Canedo, «A study of the applicability of an Agile Methodology,» 2015. [11]. Trello, «trello,» [En línea]. Available: https://trello.com/.. [12]. ScrumDo, «ScrumDo,» [En línea]. Available: https://www.scrumdo.com/.. [13]. Atlassian, «Jira,» [En línea]. Available: https://es.atlassian.com/software/jira. 38.

(39) [14]. G. Booch, «The history of software engineering,» IEEE, 2018.. [15] L. Jiang y A. Eberlein, «An Analysis of the History of Classical Software Development and Agile Development,» IEEE, 2009. [16] K. Beck, M. Beedle, K. Schwaber, J. Sutherland, D. Thomas, A. v. Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. C. Martin y S. Mellor, «agilemanifesto,» 2001. [En línea]. Available: http://agilemanifesto.org/iso/es/principles.html. [17] Mike Cohn, «User Stories Applied: For Agile Software Development,» Addison Wesley, 2004. [18] Microsoft, [En línea]. Available: https://docs.microsoft.com/enus/dotnet/csharp/getting-started/introduction-to-the-csharp-language-and-the-netframework [19] Visual Studio [En línea]. Available: https://visualstudio.microsoft.com/es/vs/features/net-development/ [20] Marc Eaddy, «C# Versus Java,» 2001. [En línea]. Available: http://oberon2005.oberoncore.ru/paper/me2001.pdf [21]. Angular [En línea]. Available: https://angular.io/docs. [22] Agilealliance [En línea] «User stories» 2016. Available: https://www.agilealliance.org/glossary/userstories/#q=~(infinite~false~filters~(postType~(~'page~'post~'aa_book~'aa_event_session~ 'aa_experience_report~'aa_glossary~'aa_research_paper~'aa_video)~tags~(~'user*20stor ies))~searchTerm~'~sort~false~sortDirection~'asc~page~1) [23] Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition. Addison-Wesley Professional 2003. [24] IBM [En linea] «Architectural characteristics of web-based applications». Available: https://www.ibm.com/support/knowledgecenter/en/SSEPEK_12.0.0/intro/src/tpc/db2z_arch itectureofwebapplications.html. 39.

(40)

Figure

Figura 2. Tablero Kanban para el desarrollo de software [8]

Figura 2.

Tablero Kanban para el desarrollo de software [8] p.11
Figura 3. Marco de trabajo scrum [10].

Figura 3.

Marco de trabajo scrum [10]. p.12
Figura 5. Historia de usuario creación de tareas.

Figura 5.

Historia de usuario creación de tareas. p.17
Figura 4. Historia de usuario creación de colaboradores.

Figura 4.

Historia de usuario creación de colaboradores. p.17
Figura 6. Historia de usuario creación del sprint.

Figura 6.

Historia de usuario creación del sprint. p.18
Figura 7. Historia de usuario asignación de actividades.

Figura 7.

Historia de usuario asignación de actividades. p.18
Figura 8. Historia de usuario cambio de estado de actividades.

Figura 8.

Historia de usuario cambio de estado de actividades. p.19
Figura 9. Historia de usuario seguimiento del sprint.

Figura 9.

Historia de usuario seguimiento del sprint. p.19
Figura 11. Historia de usuario realización de evaluaciones de desempeño

Figura 11.

Historia de usuario realización de evaluaciones de desempeño p.20
Figura 12. Arquitectura de la aplicación

Figura 12.

Arquitectura de la aplicación p.21
Figura 14. Convenciones del diagrama de entidad-relación

Figura 14.

Convenciones del diagrama de entidad-relación p.23
Figura 17. Creación de colaborador

Figura 17.

Creación de colaborador p.27
Figura 20. Reportes generales y por desempeño de colaborador

Figura 20.

Reportes generales y por desempeño de colaborador p.29
Figura 21. Creación de actividades

Figura 21.

Creación de actividades p.30
Figura 25. Resumen de respuestas segunda pregunta de la encuesta

Figura 25.

Resumen de respuestas segunda pregunta de la encuesta p.32
Figura 27. Resumen de respuestas cuarta pregunta de la encuesta

Figura 27.

Resumen de respuestas cuarta pregunta de la encuesta p.33
Figura 29. Resumen de respuestas sexta pregunta de la encuesta

Figura 29.

Resumen de respuestas sexta pregunta de la encuesta p.34

Referencias

Actualización...