1 Desarrollo de una aplicación con la metodología SCRUM basado en las 5W y 2H para las carreras de Software e ITIN del DCCO Duy Hurtado, Kevin Joseph y Galarza Cruz, Jorge Luis Departamento de Ciencias de la Computación Carrera de Software Trabajo de titulación, previo a la obtención del título de Ingeniero de Software Msc. Ruiz Robalino, Jenny Alexandra 10 de febrero del 2023 2 3 4 5 6 Dedicatoria A mis padres, César Galarza y Cinthya Cruz, y a mi hermano Christian Galarza, quienes han sido mi fuente de amor y motivación incansable durante toda mi vida. Gracias por ser mi hogar seguro y mi apoyo constante en todo momento. Este logro es también suyo. Los quiero con todo mi corazón. Jorge Luis Galarza Cruz Le dedico el resultado de este trabajo a toda mi familia. Principalmente, a mi mamá y papá que me apoyaron en los buenos, malos y peores momentos, por enseñarme a afrontar las dificultades y ser una persona positiva, por instruirme a ser la persona que soy hoy, por tenerme paciencia, comprensión, darme fuerzas y ánimos cuando más lo necesitaba y sobre todo por educarme con buenos principios, valores, perseverancia y empeño. Kevin Joseph Duy Hurtado 7 Agradecimiento A mis queridos padres César y Cinthya, les expreso mi profundo agradecimiento por hacer un hogar lleno de amor y seguridad que siempre ha apoyado mi educación y crecimiento personal. A lo largo de los años, han estado a mi lado en cada etapa de mi vida, brindándome su amor incondicional y apoyo incansable. Gracias por haber sido mi soporte y mi hogar, y por haber hecho posible este logro importante en mi vida. A mi hermano Christian, quien ha sido una fuente constante de apoyo y motivación en mi vida. Su dedicación y ética de trabajo son un ejemplo a seguir para mí. No solo es un hermano maravilloso, sino también un mentor y un amigo leal. Gracias por siempre estar ahí para mí y por ser mi modelo a seguir Mis tíos Flavio, Elsy y Rodrigo también tienen un lugar especial en mi corazón. Les agradezco de todo corazón por abrir sus puertas y brindarme un hogar durante mi camino hacia la culminación de mis estudios. Su amor y apoyo han sido fundamentales para mi éxito. A mi compañero de tesis y gran amigo Kevin, estoy profundamente agradecido por haberte conocido durante mis primeros días en la universidad. Tu dedicación y pasión han sido inspiradores, y es un honor haberte tenido a mi lado en este viaje. Estoy emocionado de poder compartir este logro contigo y seguir fortaleciendo nuestra amistad a lo largo del tiempo. Finalmente, quiero agradecer a la universidad y a mi tutora de tesis la ingeniera Jenny Ruiz, por su guía constante y motivación para alcanzar nuestro máximo potencial. Gracias por estar pendientes de nuestro trabajo y por brindarnos las herramientas y recursos necesarios para completar esta tesis con éxito. Sin su apoyo y dedicación, no habría sido posible alcanzar este logro. Jorge Luis Galarza Cruz 8 Le agradezco a Dios por ser mi fortaleza en los momentos de debilidad y por brindarme paz, tranquilidad y sobre todo felicidad por haberme dado una hermosa familia que siempre está apoyándome en todas mis decisiones. Le agradezco a mi mamá y mi papá que siempre me han brindado su apoyo incondicional para cumplir todos mis objetivos académicos, gracias por impulsarme siempre a perseguir mis metas y nunca abandonarlas frente a las adversidades, por brindarme el soporte material y económico para concentrarme en los estudios, pues realmente me ayudaron a alcanzar el objetivo de graduarme y ser un profesional, por eso nunca dejaré de estar agradecido con ustedes. También a mi hermano por apoyarme incondicionalmente, por ser un ejemplo de superación personal y profesional gracias por siempre estar a mi lado cuando más te he necesitado. Le agradezco a mi tutora de tesis, la Msc. Jenny Ruiz por su dedicación y paciencia, sin su apoyo no hubiese podido llegar a esta instancia tan anhelada, gracias por su guía y por siempre estar dispuesta a ayudar con ideas y material que fue muy importante para el desarrollo de la tesis. Le agradezco a mi compañero de tesis, Jorge Galarza a quien considero un gran amigo porque a lo largo de todos estos años hemos compartido muchas horas de estudio, trabajos realizados, y que gracias a su dedicación y esfuerzo hemos logrado culminar una etapa de nuestras vidas obteniendo nuestro título universitario, pues su apoyo y ayuda fue fundamental todos los años de carrera. Por último, le agradezco a esta hermosa y prestigiosa Universidad de las Fuerzas Armadas ESPE, por ser ese centro de conocimiento y aprendizaje donde pude formarme profesionalmente y obtener mi tan ansiado título. Kevin Joseph Duy Hurtado 9 Índice de Contenido Resumen ........................................................................................................................... 20 Abstract ............................................................................................................................. 21 Capítulo I ........................................................................................................................... 22 Introducción ................................................................................................................... 22 Antecedentes ............................................................................................................. 22 Problemática .............................................................................................................. 23 Justificación ............................................................................................................... 27 Objetivos .................................................................................................................... 28 Objetivo General. ................................................................................................... 28 Objetivo Específico. ............................................................................................... 28 Alcance ...................................................................................................................... 28 Hipótesis .................................................................................................................... 30 Capítulo II .......................................................................................................................... 31 Estado del arte .............................................................................................................. 31 Diseñar la estrategia de búsqueda ........................................................................... 32 Palabras clave. ...................................................................................................... 32 Catálogos y bases de datos. ................................................................................. 32 Criterios de inclusión. ............................................................................................ 33 Identificar y seleccionar la literatura relevante .......................................................... 33 Criterios de exclusión y selección. ........................................................................ 33 10 Control de calidad de los resultados. .................................................................... 35 Almacenar y registrar los datos de búsqueda .......................................................... 39 Almacenamiento de las referencias. ..................................................................... 40 Registro y resumen de las referencias seleccionadas. ........................................ 40 Modelar y organizar las referencias seleccionadas .................................................. 44 Analizar e interpretar los resultados de los artículos seleccionados ........................ 46 Metodología ............................................................................................................... 47 Identificación de la problemática y motivación. ..................................................... 48 Definición de los objetivos de la solución. ............................................................. 48 Diseño y desarrollo. ............................................................................................... 48 Demostración. ........................................................................................................ 48 Evaluación. ............................................................................................................. 48 Comunicación. ....................................................................................................... 49 Marco Teórico ............................................................................................................... 49 Conceptos de Gestión de Proyectos ........................................................................ 49 Proyecto. ................................................................................................................ 49 Programa. .............................................................................................................. 50 Portafolios. ............................................................................................................. 50 Relación entre proyectos, programa y portafolios en una organización. ............. 51 Ciclo de vida del proyecto...................................................................................... 52 Estructura de Desglose del Trabajo (EDT). .......................................................... 53 11 Ingeniería de Requisitos (IR)..................................................................................... 56 ¿Qué es un requisito? ........................................................................................... 56 Las cuatro actividades principales de la Ingeniería de Requisitos (IR). ............... 56 Requisitos funcionales. .......................................................................................... 57 Requisitos no funcionales. ..................................................................................... 57 Requisitos de Calidad. ........................................................................................... 58 Obtención de requisitos. ........................................................................................ 59 Documentación de requisitos. ............................................................................... 61 Documentación basada en modelos. .................................................................... 62 Validación de requisitos. ........................................................................................ 62 Gestión de requisitos. ............................................................................................ 63 Metodologías Ágiles .................................................................................................. 63 Características de proyectos gestionados con metodologías ágiles. ................... 63 Prácticas usadas en proyectos gestionados con metodologías ágiles. ............... 64 Metodología Scrum. ............................................................................................... 66 Ciclo de Vida de Scrum. ........................................................................................ 68 Historias de Usuario............................................................................................... 68 Técnica de las 5W+2H........................................................................................... 69 Capítulo III ......................................................................................................................... 71 Herramientas ................................................................................................................. 71 Modelado de datos .................................................................................................... 71 12 Power Designer. .................................................................................................... 71 Base de datos (BD) ................................................................................................... 71 MySQL. .................................................................................................................. 71 Backend ..................................................................................................................... 72 Python. ................................................................................................................... 72 Flask. ...................................................................................................................... 72 Control de Acceso HTTP (CORS). ........................................................................ 72 SQLAlchemy. ......................................................................................................... 72 Frontend..................................................................................................................... 73 Javascript (JS). ...................................................................................................... 73 Lenguaje de Marcado de Hipertexto (HTML). ....................................................... 73 React. ..................................................................................................................... 73 Styled-components. ............................................................................................... 74 Material UI (MUI). ................................................................................................... 74 Servicio de alojamiento en la nube ........................................................................... 74 PythonAnywhere. ................................................................................................... 74 Vercel. .................................................................................................................... 74 Sistema de control de versiones ............................................................................... 75 GitHub. ................................................................................................................... 75 Arquitectura ................................................................................................................... 75 Diagrama de Entrada, Proceso y Salida (EPS) ............................................................ 79 13 Diagrama EPS a nivel macro .................................................................................... 80 Diagramas EPS a nivel micro.................................................................................... 83 Diagrama EPS de los usuarios. ............................................................................. 83 Diagrama EPS de las HU. ..................................................................................... 84 Implementación ............................................................................................................. 86 Modelo de datos ........................................................................................................ 86 Tabla Usuario. ........................................................................................................ 89 Tabla Perfil de Proyecto. ....................................................................................... 89 Tabla Versión. ........................................................................................................ 90 Tabla HU. ............................................................................................................... 90 Tabla Trabajo del Proyecto. .................................................................................. 90 Base de datos ............................................................................................................ 90 Backend ..................................................................................................................... 91 Frontend..................................................................................................................... 92 Inicio de sesión y registro de usuarios. ................................................................. 94 Perfiles de proyectos. ............................................................................................ 95 Matriz de identificación de requisitos funcionales. ................................................ 95 Reporte de historias de usuario............................................................................. 96 Calendario. ............................................................................................................. 97 Backlog. ................................................................................................................. 98 Ajustes. ................................................................................................................ 100 14 Ayuda. .................................................................................................................. 100 Requisitos no funcionales. ................................................................................... 101 Capítulo IV ...................................................................................................................... 103 Diseño de la evaluación .............................................................................................. 103 Auditoría de la aplicación web ................................................................................ 103 Funcionalidad de la aplicación web ........................................................................ 103 Escenarios ................................................................................................................... 104 Auditoría de la aplicación web ................................................................................ 104 Funcionalidad de la aplicación web ........................................................................ 105 Métricas ....................................................................................................................... 109 Auditoría de la aplicación web ................................................................................ 109 Rendimiento. ........................................................................................................ 109 Accesibilidad. ....................................................................................................... 110 Buenas Prácticas. ................................................................................................ 111 Funcionalidad de la aplicación web ........................................................................ 112 Opinión de la aplicación. ...................................................................................... 112 Utilidad de la aplicación en la identificación de requisitos funcionales. ............. 112 Tiempo de demora en elaborar las HU mediante la forma manual (matriz de Excel). .............................................................................................................................. 112 Tiempo de demora en elaborar las HU mediante la aplicación web. ................. 113 Facilidad para devolverse a los requisitos en la aplicación. ............................... 113 15 Comparación en base a la experiencia en el uso de Ingeniería de Requisitos y de la aplicación web de HU/5W+2H. .................................................................................... 114 Información acerca de la No Funcionalidad. ....................................................... 114 Preferencia a futuro entre el proceso tradicional de la Ingeniería de Requisitos con el uso de la aplicación web HU/5W+2H. .................................................................. 114 Resultados................................................................................................................... 115 Auditoría de aplicación web .................................................................................... 115 Resultados de auditoría de rendimiento.............................................................. 115 Resultados de auditoría de accesibilidad ............................................................ 116 Resultados de auditoría de buenas prácticas ..................................................... 120 Funcionalidad de la aplicación web (Primera encuesta) ........................................ 122 Opinión de la aplicación. ...................................................................................... 122 Utilidad de la aplicación en la identificación de requisitos funcionales. ............. 123 Tiempo de demora en elaborar las HU mediante la forma manual (matriz de Excel). .............................................................................................................................. 124 Tiempo de demora en elaborar las HU mediante la aplicación web. ................. 125 Facilidad para devolverse a los requisitos en la aplicación. ............................... 126 Funcionalidad de la aplicación web (Segunda encuesta) ...................................... 127 Comparación en base a la experiencia en el uso de Ingeniería de Requisitos y de la aplicación web de HU/5W+2H. .................................................................................... 127 Información acerca de la No Funcionalidad. ....................................................... 131 16 Preferencia a futuro entre el proceso tradicional de la Ingeniería de Requisitos con el uso de la aplicación web HU/5W+2H. .................................................................. 132 Capítulo V ....................................................................................................................... 134 Conclusiones ............................................................................................................... 134 Recomendaciones ...................................................................................................... 136 Trabajos Futuros ......................................................................................................... 137 Bibliografía ...................................................................................................................... 139 Apéndices ....................................................................................................................... 145 17 Índice de Tablas Tabla 1 Número de estudiantes por carrera que han desarrollado software .................. 24 Tabla 2 Número de estudiantes por nivel de carrera que han desarrollo software ........ 25 Tabla 3 Preguntas de investigación para los objetivos específicos ................................ 28 Tabla 4 Número de artículos encontrados en cada base de datos................................. 36 Tabla 5 Lista de comprobación CASP aplicada .............................................................. 38 Tabla 6 Artículos primarios (AP) ...................................................................................... 40 Tabla 7 Ejemplo de una estructura de lista de interesados en la fuente de requisitos .. 59 Tabla 8 Prácticas usadas en proyectos agile .................................................................. 64 Tabla 9 Equipo de Scrum y sus roles dentro de un proyecto.......................................... 67 Tabla 10 Descripción de escenarios propuestos ........................................................... 105 Tabla 11 Métricas de Rendimiento ................................................................................ 109 Tabla 12 Métricas de Accesibilidad ............................................................................... 110 Tabla 13 Métricas de Buenas Prácticas ........................................................................ 111 Tabla 14 Resultados de auditoría de rendimiento ......................................................... 115 Tabla 15 Resultados de auditoría de accesibilidad mediante WCAG 2.1 .................... 116 Tabla 16 Resultados de auditoría de accesibilidad de componentes ........................... 117 Tabla 17 Resultados de auditoría de problemas de accesibilidad ................................ 119 Tabla 18 Resultados de auditoría de buenas prácticas ................................................ 121 18 Índice de Figuras Figura 1 Estudiantes por carrera que trabajaron en el desarrollo de un producto software ............................................................................................................................. 24 Figura 2 Estudiantes por carrera y nivel de carrera que han desarrollado software ...... 26 Figura 3 Diagrama de Flujo de PRISMA ......................................................................... 34 Figura 4 Diagrama de Flujo de Prisma aplicado ............................................................. 36 Figura 5 Ejemplo del mapa de literatura.......................................................................... 44 Figura 6 Mapa conceptual de la literatura aplicado ........................................................ 45 Figura 7 Fases de la metodología DSR .......................................................................... 47 Figura 8 Proceso de establecimiento de un sistema de gestión de portafolios ............. 50 Figura 9 Diagrama de relación entre proyectos, portafolio y programas en una organización ...................................................................................................................... 52 Figura 10 Secuencia de fases típica en un ciclo de vida del proyecto ........................... 52 Figura 11 Ejemplo de Estructura de Desglose del Trabajo ............................................ 54 Figura 12 Ejemplo de Estructura de Desglose del Trabajo (EDT) de un proyecto de software ............................................................................................................................. 55 Figura 13 Clasificación de requisitos no funcionales en un proyecto de software. ........ 58 Figura 14 Estructura de documento de la IEEE 830 -1998 ............................................ 61 Figura 15 Ciclo de vida Scrum ......................................................................................... 68 Figura 16 Descripción de los componentes del marco de trabajo .................................. 70 Figura 17 Arquitectura en capas...................................................................................... 76 Figura 18 Comunicación entre capas .............................................................................. 77 Figura 19 Diagrama de arquitectura de la aplicación web .............................................. 77 Figura 20 Diagrama EPS ................................................................................................. 80 Figura 21 Diagrama EPS de toda la aplicación web ....................................................... 80 Figura 22 Diagrama EPS de usuarios ............................................................................. 83 19 Figura 23 Diagrama EPS de HU...................................................................................... 84 Figura 24 Modelo de datos conceptual (CDM)................................................................ 86 Figura 25 Modelo de datos lógico (LDM) ........................................................................ 87 Figura 26 Modelo físico de datos (PDM) ......................................................................... 88 Figura 27 Estructura de carpetas de la aplicación frontend............................................ 92 Figura 28 Pantallas de inicio de sesión y registro. .......................................................... 94 Figura 29 Pantalla de perfiles de proyectos .................................................................... 95 Figura 30 Pantalla de matriz de identificación de requisitos funcionales ....................... 95 Figura 31 Pantalla de reporte de historias de usuario .................................................... 96 Figura 32 Pantalla de Calendario .................................................................................... 97 Figura 33 Pantalla de Backlog ......................................................................................... 98 Figura 34 Gráfico de líneas horas estimadas vs horas estimadas restantes ................. 99 Figura 35 Pantalla de Ajustes ........................................................................................ 100 Figura 36 Pantalla de Ayuda ......................................................................................... 100 Figura 37 Pantalla de Requisitos no funcionales .......................................................... 101 Figura 38 Resultados de la opinión de la aplicación ..................................................... 123 Figura 39 Resultados acerca de la utilidad de la aplicación ......................................... 124 Figura 40 Tiempo de demora en elaborar las HU de forma manual ............................ 124 Figura 41 Tiempo de demora en elaborar la matriz de HU con la aplicación web ....... 125 Figura 42 Resultados acerca de la facilidad para devolverse a los requisitos ............. 126 Figura 43 Ingeniería de requisitos vs aplicación web, aspecto: Ágil y engorroso ........ 128 Figura 44 Ingeniería de requisitos vs aplicación web, aspecto: Fácil y difícil .............. 128 Figura 45 Ingeniería de requisitos vs aplicación web, aspecto: Rápido y lento ........... 129 Figura 46 Ingeniería de requisitos vs aplicación web, aspecto: Todos y uno .............. 130 Figura 47 Comprensión de los estudiantes acerca de la No Funcionalidad ................ 131 Figura 48 Preferencia para desarrollar trabajos académicos en el futuro .................... 132 20 Resumen La técnica 5W+2H es una técnica de resolución de problemas eficiente, básica y simple de utilizar, esto permite que el proceso de elicitación de requerimientos sea rápido y ágil. Para lograr este objetivo se trabaja con metodologías ágiles, una de las tantas que existen es Scrum, el cual es un marco ligero que ayuda a los individuos, conjuntos y empresas a producir software por medio de soluciones adaptables para sistemas complejos. En este contexto, el trabajo de tesis presenta una aplicación web desarrollada con la metodología Scrum que tiene como objetivo ofrecer una herramienta útil y eficiente a los estudiantes del DCCO para la gestión y manejo de versiones de requisitos funcionales a través de historias de usuario con la técnica 5W+2H y a comprender la no funcionalidad a través de ISO/IEC 25010 en los perfiles de proyectos de software. Los resultados de las encuestas realizadas a los estudiantes respaldan la hipótesis y demuestran que la aplicación es considerada ágil, fácil de usar y optimiza el tiempo de identificación de requisitos en comparación con la matriz realizada de forma manual. Además, la aplicación fue evaluada en términos de rendimiento, accesibilidad y buenas prácticas, aprobando en la mayoría de las métricas con espacio para mejoras en algunas. La aplicación web desarrollada en esta tesis contribuye a la mejora de la eficiencia y efectividad en el proceso de identificación de requisitos y ayuda a los estudiantes a comprender y aplicar la técnica 5W+2H en sus perfiles de proyectos de software, lo cual puede tener un impacto positivo en su calidad. Palabras clave: Técnica 5W+2H, SCRUM, aplicación web, elicitación de requisitos, historias de usuario, perfiles de proyectos de software. 21 Abstract The 5W+2H technique is an efficient, basic, and simple to use problem-solving technique, allowing the requirement elicitation process to be fast and agile. To achieve this goal, agile methodologies are used, one of which is Scrum, a lightweight framework that helps individuals, teams, and businesses to produce software through adaptable solutions for complex systems. In this context, the thesis presents a web application developed using the Scrum methodology, with the objective of offering a useful and efficient tool to DCCO students for managing and handling versions of functional requirements through user stories with the 5W+2H technique and understanding the non-functional requirements through ISO/IEC 25010 in software project profiles. The results of the surveys conducted with the students support the hypothesis and demonstrate that the application is considered agile, easy to use, and optimizes the time for identifying requirements compared to the matrix performed manually. Additionally, the application was evaluated in terms of performance, accessibility, and best practices, passing in most metrics with room for improvement in some. The web application developed in this thesis contributes to the improvement of efficiency and effectiveness in the requirement identification process and helps students understand and apply the 5W+2H technique in their software project profiles, which can have a positive impact on their quality. Keywords: 5W+2H technique, SCRUM, web application, requirement elicitation, user stories, software project profiles. 22 Capítulo I Introducción Antecedentes La técnica 5W+2H es un instrumento de administración de las más eficientes que hay y curiosamente, una de las más básicas y simples de utilizar. No es nada más que una estrategia de acción cualificado y estructurado en fases prácticas y bien definidas. En un mundo dinámico y enormemente competitivo como el sector empresarial, el proceso de elicitación de requerimientos debe ser rápido y ágil, y los errores en la transmisión de determinada información tienen la posibilidad de crear varias pérdidas. Y con el objetivo de que no ocurra aquello ha sido creada esta técnica, puesto que esclarece plenamente cada una de las probables dudas que logren surgir en cualquier proceso de elicitación de requerimientos implementado en la organización. Al inicio puede parecer difícil, sin embargo, es todo lo opuesto. Esta técnica se denomina de esta forma para simplificar las directrices que intervienen en cada fase del proyecto de acción que se ofrece (Serna, 2021). Como se mencionó previamente, el proceso de elicitación de requerimientos debe ser rápido y ágil, para lograr este objetivo se trabaja con metodologías ágiles, una de las tantas que existen es Scrum, el cual es un marco ligero que ayuda a los individuos, conjuntos y empresas a producir software por medio de soluciones adaptables para sistemas complejos. Scrum es fácil, se debe aplicar como se determina en su filosofía, teoría y composición, puesto que, si se aplica de forma correcta se puede conseguir metas y producir software con valor. El marco de Scrum es deliberadamente inconcluso, solo define las piezas correctas para llevar a cabo la teoría de Scrum. Scrum se fundamenta en la sabiduría colectiva de los individuos que lo usan. En vez de conceder a los individuos indicaciones detalladas, las normas de Scrum guían sus relaciones e interacciones (Schwaber & Sutherland, 2020). 23 Ahora bien, es importante conocer ambos términos, puesto que serán recurrentes a lo largo del trabajo, debido a que los estudiantes pertenecientes a las carreras del DCCO (Departamento de Ciencias de la Computación) ya sea de Software o ITIN (Ingeniería en Tecnologías de la Información) se forman profesionalmente desarrollando aplicaciones de software mediante metodologías ágiles y técnicas como las 5W+2H. Por lo tanto, en la actualidad usan una matriz manual para poder aplicar la técnica, y a pesar de que sirve para fines didácticos se han detectado varios problemas entre los que destacan, los problemas de tener actualizada la matriz si se realiza algún cambio en la matriz original, si se pierde el archivo original volver a crearlo sería un proceso demoroso, y no se puede realizar de forma adecuada un sistema de gestión de versiones. Debido a esas desventajas se ha visto necesario automatizar este proceso desarrollando una aplicación web que permita desarrollar la técnica de las 5W+2H de forma más rápida y poder crear distintas versiones para tener un almacenamiento de todo el proceso durante el desarrollo de un proyecto de software con una metodología ágil como Scrum. Problemática El problema nace a partir de la no automatización de la matriz de las 5W+2H, puesto que, a lo largo de los años 2017 – actualidad (año de aprobación de la carrera de Ingeniería de Software en la sede Matriz Sangolquí) (CES, 2017) los estudiantes pertenecientes a las carreras de Software e ITIN del DCCO de diferentes niveles han aprendido sobre esta técnica mediante una matriz de historias de usuario (HU) manual, que si bien no está mal, este proceso puede ser automatizado completamente con el objetivo que todos los estudiantes puedan acceder y aprender más sobre su uso y respectiva aplicación, ya sea con fines didácticos, es decir, únicamente de aprendizaje o con el objetivo de desarrollar proyectos de software con una metodología ágil como Scrum, ya que, en esta metodología se debe realizar HU y para su redacción la matriz de las 5W+2H se acopla perfectamente. Sin embargo, nace una pregunta: 24 ¿Los estudiantes de las carreras del DCCO actualmente se encuentran desarrollando algún producto software? Es importante conocer la respuesta a esta pregunta, puesto que, indica si es realmente necesario implementar una automatización de la matriz de las 5W+2H, para responder esta pregunta, se realizó encuestas entre los años 2021 – 2022 para conocer la situación actual de los estudiantes. Tabla 1. Número de estudiantes por carrera que han desarrollado software Número de estudiantes por carrera que han desarrollado software Carrera No Sí Total Software 8 1 9 ITIN en línea 13 5 18 ITIN presencial 22 56 78 Total 43 62 105 Porcentaje 40,95% 59,05% 100% Nota. Esta tabla muestra la cantidad de estudiantes pertenecientes a carreras del DCCO que han desarrollado un producto de software. Figura 1. Estudiantes por carrera que trabajaron en el desarrollo de un producto software Estudiantes por carrera que trabajaron en el desarrollo de un producto software 25 Nota. Esta figura muestra la representación gráfica de la Tabla 1 Como se puede observar en la Tabla 1, el porcentaje de estudiantes que han desarrollado algún producto software es del 59,05% lo que significa que es importante una herramienta con la cuál puedan identificar los requisitos funcionales a partir de las HU de forma más rápida, fácil e intuitiva, por lo tanto, se respalda la idea de que los estudiantes deben tener a su disposición una aplicación web que permite aplicar la matriz de las 5W+2H y a su vez realizar un control de versiones de cómo van cambiando los requisitos a lo largo del desarrollo del proyecto. A pesar que el porcentaje de estudiantes que sí han realizado algún producto software es mayor, queda ese 40,95 % que dice que no lo ha realizado, por tal motivo, nace una nueva incógnita que es: ¿El 40,95% de estudiantes, realmente no va a necesitar una aplicación web que automatice la matriz de las 5W+2H? Afortunadamente, la respuesta la encontramos en la misma pregunta, pero aplicando un filtro para conocer a qué nivel de la carrera pertenecen. Tabla 2. Número de estudiantes por nivel de carrera que han desarrollo software Número de estudiantes por nivel de carrera que han desarrollo software 0 10 20 30 40 50 60 Ingeniería en Software ITIN en línea ITIN presencial ¿Ha trabajado en el desarrollo de un producto software? No - Recuento de Carrera: Sí - Recuento de Carrera: Valores: No Sí 26 Nivel de carrera No Sí Total Inicial/Unidad básica (1ero - 3ero) 20 44 64 Profesional/Unidad Profesional (4to - 7mo) 23 18 41 Total 43 62 105 Porcentaje 40,95% 59,05% 100% Nota. Esta tabla muestra la cantidad de estudiantes según su nivel de carrera que han desarrollado un producto de software. Figura 2. Estudiantes por carrera y nivel de carrera que han desarrollado software Estudiantes por carrera y nivel de carrera que han desarrollado software Nota. Esta figura muestra la representación gráfica de la unión de la Tabla 1 y Tabla 2 Como se puede observar en la Figura 2, los estudiantes que más respondieron que no han desarrollado un producto software son los pertenecientes a la carrera de ITIN presencial en la Unidad básica de primer a tercer semestre, por lo tanto, esto explicaría el motivo de su 0 5 10 15 20 25 30 35 40 45 50 In ic ia l/ U n id ad b ás ic a (1 e ro - 3 er o ) P ro fe si o n al /U n id ad P ro fe si o n al ( 4 to - 7 m o ) P ro fe si o n al /U n id ad P ro fe si o n al ( 4 to - 7 m o ) In ic ia l/ U n id ad b ás ic a (1 e ro - 3 er o ) P ro fe si o n al /U n id ad P ro fe si o n al ( 4 to - 7 m o ) Ingeniería en Software ITIN en línea ITIN presencial ¿Ha trabajado en el desarrollo de un producto software? No - Recuento de Carrera: Sí - Recuento de Carrera: Valores: No Sí 27 respuesta, debido a que en estos semestres se acostumbra a adquirir las bases de los conocimientos que servirán a futuro en la Unidad Profesional, en donde lo más seguro es que desarrollen algún producto software. Por lo tanto, necesitarán de la aplicación de la matriz de las 5W+2H para poder identificar los requisitos funcionales a partir de las HU y tener un control de versiones para diferentes proyectos que desarrollen bajo la metodología Scrum. Justificación En base a la problemática detallada anteriormente es fundamental desarrollar una aplicación web que permita a los estudiantes de las carreras del DCCO, ya sean de la Unidad básica o Unidad Profesional, tener a su disposición ya no sólo una matriz elaborada manual, sino una aplicación web automatizada a la cual puedan acceder en cualquier lugar y en cualquier momento de forma totalmente segura, asegurando así la triada CID (Confidencialidad, Integridad y Disponibilidad) (ESET, 2019). Todo esto con el objetivo de que los estudiantes puedan irse adaptando a las metodologías con las cuales las empresas trabajan actualmente, es decir, con metodologías ágiles como Scrum en donde dentro de su proceso es necesario la elaboración de HU para lo cual la matriz de las 5W+2H les será de mucha ayuda. Además, la aplicación web les servirá para empezar a desarrollar buenas prácticas de documentación, puesto que, las HU se van a almacenar y a su vez se va a poder realizar un control de versiones óptimo e ideal. El objetivo de tener las versiones es para analizar y visualizar cuánto han cambiado los requerimientos desde su inicio hasta su final y a su vez justificar el incremento de costo o tiempo en el desarrollo del proyecto (Wong, 2017). Además, de esta forma los estudiantes pueden tener un mejor conocimiento del EDT (Estructura del Desglose de Trabajo), puesto que, una de las primeras labores en el proceso de construcción de un plan es la definición de su alcance, delimitando los trabajos a hacer para poder lograr las metas planteadas en el plan, y desarrollar los entregables que van a conformar parte del mismo (Silvela, 2016). 28 Objetivos Objetivo General. Desarrollar una aplicación web basado en las técnicas de las 5W+2H para la identificación de los requisitos funcionales y no funcionales. Objetivo Específico. i. Elaborar una encuesta para conocer la situación actual de los estudiantes con relación a la técnica de las 5W+2H. ii. Realizar reportes de la información basada en las técnicas de las 5W+2H que permita el control de versiones al usuario. iii. Comparar y contrastar la técnica de las 5W+2H con el proceso de elicitación de requisitos en la identificación de los requisitos funcionales y no funcionales. Alcance Este proyecto tiene como alcance implementar una aplicación con la metodología SCRUM basado en la técnica de las 5W+2H capaz de generar reportes automatizados de los requisitos funcionales y no funcionales, contribuyendo a que los estudiantes las carreras de Software e ITIN del DCCO adquieran la habilidad de identificar y distinguir entre requisitos funcionales y no funcionales. Además, realizar una comparativa de la identificación de requisitos entre la aplicación y el proceso tradicional de elicitación de requisitos funcionales y no funcionales. A continuación, se muestra la matriz de congruencia metodológica que se aplicó para determinar la revisión de literatura del proyecto. En esta se muestran los objetivos específicos con sus respectivas preguntas de investigación. Tabla 3. Preguntas de investigación para los objetivos específicos Preguntas de investigación para los objetivos específicos 29 Objetivo Específico Preguntas de Investigación i. Elaborar una encuesta para conocer la situación actual de los estudiantes con relación a la técnica de las 5W+2H. RQ1. ¿Cuál es el posible impacto de la generación de HU mediante la técnica de las 5W+2H en los aspectos prácticos del entorno de trabajo/estudio de los estudiantes? RQ2. ¿Qué efecto tiene la identificación de requisitos funcionales y no funcionales mediante HU usando la técnica de las 5W+2H en el proceso de desarrollo de proyectos de software de los estudiantes? RQ3. ¿Cómo el procesamiento del lenguaje natural es aplicado a la construcción de HU con la técnica de las 5W+2H? ii. Realizar reportes de la información basada en las técnicas de las 5W+2H que permita el control de versiones del usuario. RQ4: ¿Cuáles son las características de las HU en la fase de obtención de requerimientos al aplicarlo al marco de trabajo ágil SCRUM? RQ5: ¿Cómo se puede asegurar la efectividad del proceso de obtención de HU aplicando la técnica de las 5W+2H en el marco de trabajo ágil SCRUM? RQ6: ¿Cuáles son los factores que permiten reducir la complejidad en la escritura de HU en el marco de trabajo ágil SCRUM? 30 Objetivo Específico Preguntas de Investigación iii. Comparar y contrastar la técnica de las 5W+2H con el proceso de elicitación de requisitos en la identificación de requisitos funcionales y no funcionales. RQ7: ¿Cuál es la evaluación de los estudiantes con respecto a la eficacia de la técnica de las 5W+2H en la identificación de requisitos funcionales y no funcionales? RQ8: ¿Qué beneficios aporta la generación de HU en la identificación de requisitos funcionales y no funcionales con la técnica de las 5W+2H con respecto a métodos tradicionales de elicitación de requisitos? RQ9: ¿Qué directrices de calidad son necesarias para complementar la identificación de requisitos funcionales y no funcionales con la técnica de las 5W+2H en un ciclo de vida SCRUM? Nota. Esta tabla muestra preguntas de investigación definidas para el proyecto. Hipótesis La aplicación web es una herramienta ágil, fácil y rápida que permite a los estudiantes de las carreras de Software e ITIN del DCCO, gestionar y versionar requisitos funcionales y comprender la no funcionalidad mediante HU con la técnica de las 5W+2H en un marco de trabajo ágil SCRUM. 31 Capítulo II Estado del arte El estado del arte es una modalidad de estudio documental que posibilita el análisis del entendimiento en un área específica. Sus inicios se remontan a los años ochenta, etapa en la que se empleaba como instrumento para compilar y sistematizar información en especial el sector de ciencias sociales, no obstante, en el tamaño en que dichos estudios se han realizado con la intención de hacer balances sobre las tendencias de indagación y como punto de inicio para la toma de elecciones, el estado del arte se posicionó como una modalidad de estudio de la investigación (Molina, 2005). Para este trabajo se utiliza la técnica de la revisión de la literatura con el objetivo de encontrar estudios relacionados con la técnica de las 5W+2H, puesto que es el tema central del estudio. Las principales fuentes para encontrar trabajos relacionados serán IEEE Xplore y ACM Digital Library debido a que estas librerías virtuales contienen gran cantidad de artículos científicos relacionados a la ingeniería y al tema propuesto. La revisión de la literatura es una etapa indispensable en cualquier trabajo de indagación, pues ayuda a poner en contexto la investigación y a sustentarla teórica y conceptualmente desde el punto de vista de otros estudiosos e investigadores que han escrito anteriormente sobre la temática. Los pasos fundamentales a tener en cuenta en el proceso de revisión de la literatura son: i) Diseñar la estrategia de búsqueda ii) Identificar y seleccionar la literatura relevante iii) Almacenar y registrar los resultados de búsqueda iv) Modelar y organizar las referencias seleccionadas v) Analizar e interpretar los resultados de los artículos seleccionados (Arnau & Josefina, 2020) 32 Diseñar la estrategia de búsqueda Dentro de esta fase un primer paso importante es detectar las palabras clave o conocido en inglés como keywords. Una vez definidas las keywords, el siguiente paso es precisar las fuentes de información o bases de datos más pertinentes en funcionalidad del entorno disciplinar. Finalmente, un tercer aspecto a tener en cuenta es la necesidad de precisar criterios de indagación y la utilización de filtros para delimitar los resultados (Arnau & Josefina, 2020). Palabras clave. Dado que el tema está enfocado en técnicas, metodologías y aplicaciones las principales palabras clave serían: i) Aplicación web (web application) ii) Metodología ágil (agile methodology) iii) Scrum iv) 5W+2H (5W2H) v) HU (user stories) vi) Gestión de versiones (version management) vii) Ingeniería de software (software engineering) Catálogos y bases de datos. Como se mencionó anteriormente las principales fuentes de información para obtener artículos científicos serán IEEE Xplore la cual es una base de datos de indagación académica que permite ver documentos completos como artículos y trabajos sobre Ciencias de la Computación, Ingeniería Eléctrica y Electrónica (IEEE, 2005) y la otra es ACM Digital Library que es la más grande base de datos que existe especializada en informática y tecnologías de la información (ACM, 2010). 33 Criterios de inclusión. Para seleccionar los mejores artículos y los que más relación tengan con el tema propuesto se basa en los siguientes criterios, cabe destacar que desde ahora los criterios de inclusión son nombrados como CI: i) CI1: Estudios que hayan desarrollado aplicaciones web con la metodología ágil Scrum. ii) CI2: Estudios que hayan desarrollado aplicaciones web aplicando la técnica de las 5W+2H iii) CI3: Estudios que hayan desarrollado aplicaciones web para realizar la gestión de versiones de HU iv) CI4: Estudios que profundicen en el tema del aprendizaje basado en proyectos (PBL) aplicando la técnica de las 5W+2H. v) CI5: Estudios que profundicen en el tema de documentación mediante HU para un sistema de software. vi) CI6: Estudios a partir del año 2014 hasta la actualidad en la que se realiza el trabajo del tema propuesto. Identificar y seleccionar la literatura relevante Dentro de esta fase se deben seleccionar los criterios de exclusión los cuales tienen la posibilidad de ser geográficos, temáticos, poblacionales, metodológicos, entre otros, según se requiera, además al tratarse de una revisión de literatura, se necesita describir el proceso de selección de resultados hasta llegar a la muestra final de artículos. Finalmente, es fundamental examinar los artículos seleccionados mediante una evaluación o control de la calidad (Arnau & Josefina, 2020). Criterios de exclusión y selección. Para garantizar que los artículos que no hayan sido seleccionados fueron descartados por una razón válida, se basa en los siguientes criterios, cabe mencionar que desde ahora los criterios de exclusión son nombrados como CE: 34 i) CE1: Estudios en donde su tema central no sea la ingeniería de software y se enfoque en otros ámbitos. ii) CE2: Estudios que no sean extraídos de las bases de datos mencionadas previamente. iii) CE3: Documentos que no sean artículos científicos como libros, revistas, tesis, entre otros. iv) CE4: Estudios que no estén disponibles de forma gratuita, es decir, que sean de paga para acceder a su contenido. v) CE5: Estudios que hayan sido publicados o redactados cuyo año sean iguales o menores al 2013. vi) CE6: Estudios que se encuentren en ambas bases de datos, es decir, que sean duplicados. En base a los criterios de inclusión y exclusión mencionados anteriormente, se realiza un proceso de selección en base al diagrama de Flujo de PRISMA (Moher, Liberati, Tetzlaff, Altman, & The PRISMA Group, 2009) Figura 3. Diagrama de Flujo de PRISMA Diagrama de Flujo de PRISMA 35 Nota. Este gráfico muestra cómo se realiza el proceso de selección de los artículos científicos. Adaptado de Preferred Reporting Items for Systematic Reviews and Meta-Analyses: The PRISMA Statement. PLoS Med 6(7): e1000097 por Moher D, Liberati A, Tetzlaff J, Altman DG, The PRISMA Group, 2009. doi:10.1371/journal.pmed1000097 Control de calidad de los resultados. Ahora bien, además de los criterios de inclusión, exclusión y selección se debe añadir una capa más de confianza para garantizar que los artículos seleccionados sean los más apropiados y eso se lo realiza mediante una lista de 36 comprobación que propone el programa Critical Appraisal Skills Programme (CASP) que es específico para la revisión de la literatura, dicha lista de comprobación consta de 10 preguntas (CASP, 2016) y serán asignados únicamente a los artículos que hayan sido seleccionados mediante el Diagrama de Flujo de PRISMA. La cadena de búsqueda que se utiliza para buscar los artículos científicos en base a las palabras clave definidas anteriormente que tengan más relación con el tema a desarrollar es la siguiente: ((web application OR website OR software) AND (methodology OR agile methodology OR scrum methodology OR user story) AND (5W2H OR management technique) AND (management content OR version control) AND (software engineering OR computing)) Tabla 4. Número de artículos encontrados en cada base de datos Número de artículos encontrados en cada base de datos Base de datos Número de artículos encontrados IEEE Xplore 75 ACM 29 Total 104 Nota. Esta tabla presenta el total de artículos encontrados mediante la cadena de búsqueda Como se puede observar en la Tabla 4 se obtuvo 104 artículos, de los cuales 75 pertenecen a IEEE Xplore y 29 a ACM. Lo siguiente a realizar es aplicar el diagrama de flujo de PRISMA detallado anteriormente para seleccionar los mejores artículos. Figura 4. Diagrama de Flujo de Prisma aplicado Diagrama de Flujo de Prisma aplicado 37 Nota. Esta figura muestra la aplicación del diagrama de Flujo de Prisma aplicando los criterios de inclusión y exclusión de los artículos encontrados. Una vez seleccionado los artículos se debe aplicar la lista de comprobación CASP para garantizar que los estudios seleccionados fueron los mejores y los que más relación con el tema propuesto tienen. 38 Tabla 5. Lista de comprobación CASP aplicada Lista de comprobación CASP aplicada Preguntas Sí No No puedo decir Comentarios ¿La revisión abordó una pregunta claramente enfocada? X La revisión se enfocó en el tema propuesto y no en como tal en una pregunta. ¿Los autores buscaron el tipo correcto de artículos? X Esto fue gracias a las palabras clave y la cadena de búsqueda realizada para buscar artículos. ¿Cree que se incluyeron todos los estudios importantes y relevantes? X Si bien se realizó una buena búsqueda con la cadena, CI y CE, esto no es garantía que uno o más artículos de relevancia hayan sido descartados. ¿Los autores de la revisión hicieron lo suficiente para evaluar la calidad de los estudios incluidos? X Esto fue gracias al uso del diagrama de flujo de PRISMA que permitió seleccionar los artículos de mejor forma aplicando conjuntamente los CI y los CE a través de las distintas fases de este diagrama. Si se combinaron los resultados de la revisión, ¿era razonable hacerlo? X No aplica porque no se combinaron los resultados de la revisión 39 Preguntas Sí No No puedo decir Comentarios ¿Cuáles son los resultados generales de la revisión? Los resultados fueron muy buenos, ya que de los 104 artículos se logró escoger únicamente 5 que más relación tenían con el tema propuesto. ¿Qué tan precisos son los resultados? En base a cada artículo y su relación con el tema propuesto se puede decir que los resultados son altamente precisos. ¿Se pueden aplicar los resultados a la población local? X Si bien es posible, los artículos abordan temas que son de desarrollo y no se relacionan con la población. ¿Se consideraron todos los resultados importantes? X Sí, porque todos los artículos encontrados están relacionados con las palabras claves definidas. ¿Valen los beneficios los daños y los costos? X No aplica, puesto que uno para evitar pagar por los artículos se tiene el CE4, así solo se tiene artículos gratuitos. Nota. Esta tabla presenta la aplicación de la lista CASP para la revisión de literatura realizada Como se observa en la Tabla 5 la mayoría de respuestas obtenidas son positivas, por lo que se puede garantizar que los artículos seleccionados fueron los ideales y los más relacionados con el trabajo en desarrollo, además deja en evidencia que la cadena de búsqueda, CI, CE y la aplicación del diagrama de flujo de PRISMA para la selección de artículos se lo realizo correctamente. Almacenar y registrar los datos de búsqueda Los artículos importantes para el análisis deben almacenarse en un gestor de referencias bibliográficas, llevando a cabo de esta forma una librería virtual personal conforme 40 con el asunto de análisis. Además, es bastante aconsejable en un primer instante, ordenar las referencias y hacer un registro con un diminuto resumen de todas ellas, se puede usar una tabla, y expandir el resumen inicial con otras informaciones o notas que sean importantes para el análisis e inclusive elegir las referencias por temas (Arnau & Josefina, 2020). Almacenamiento de las referencias. Para almacenar los artículos encontrados en la revisión de la literatura se usará el gestor de referencias bibliográfica de Microsoft Word, puesto que es simple de utilizar y además viene integrado con la aplicación, facilitando de esta forma la creación de citas bibliográficas cuando se requiera citar a un autor específico sin olvidar que permite crear una tabla con toda la bibliografía utilizada. Registro y resumen de las referencias seleccionadas. A continuación, se presenta una tabla que servirá para presentar el título de cada artículo junto con su cita, con el objetivo de poder conocer cuáles estudios fueron seleccionados. Tabla 6. Artículos primarios (AP) Artículos Primarios (AP) Artículo Título Cita AP1 xPBL: a Methodology for Managing PBL when Teaching Computing (dos Santos, Furtado, & Lins, 2014) AP2 Towards a Secure SCRUM Process for Agile Web Application Development (Maier, Ma, & Bloem, 2017) AP3 Project based on Agile Methodologies by DMAIC (Salvadori, Magnano, & Dutra, 2021) AP4 Framework Study for Agile Software Development Via Scrum and Kanban (Zayat & Senvar, 2020) 41 Artículo Título Cita AP5 The Impact of Agile Development Practices on Project Outcomes (Ghimire & Charters, 2022) Nota. La Tabla 6 muestra los Artículos Primarios (AP) seleccionados después del haber aplicado la cadena de búsqueda, CI, CE y el diagrama de flujo de PRISMA. Con los Artículos Primarios (AP) seleccionados, es momento de hacer un resumen de la investigación de cada uno para saber por qué fueron elegidos y además conocer cómo pueden aportar al desarrollo del tema propuesto. i) AP1: xPBL: a Methodology for Managing PBL when Teaching Computing. Este artículo tiene la intención de explotar las ventajas del PBL (Aprendizaje basado en proyectos) y disminuir el peligro de fracaso al implementarlo, este estudio está centrado en procedimientos y herramientas dirigidos y aplicados al software. En este contexto, este artículo ofrece una metodología de educación y aprendizaje basada en el PBL, llamada xPBL, compuesta por: inconvenientes reales e importantes; un ámbito cómodo; un currículo innovador y flexible; un auténtico proceso de evaluación; seguimiento estrecho por tutores técnicos y tutores de proceso y, al final expertos en ejercicio como maestros y tutores. Basado en dichos recursos, el estudio explica el diseño de un enfoque PBL, con base en el razonamiento adquirido del contenido y vivencias pasadas en cursos de Ingeniería de Software. Este enfoque otorga una guía descriptiva para llevar a cabo PBL a partir de la metodología xPBL y da herramientas basadas en técnicas de administración como 5W+2H y la producción de materiales para ayudar en el proceso de concepción de conocimiento (dos Santos, Furtado, & Lins, 2014). 42 ii) AP2: Towards a Secure SCRUM Process for Agile Web Application Development. Este artículo trata sobre el desarrollo ágil, como Scrum y Extreme Programming, en donde mediante iteraciones cortas se produce una respuesta inmediata a los requisitos y cambios del mercado. No obstante, las metodologías de desarrollo de software seguras, se fundamentan primordialmente en modelos lineales como cascada y modelo V, lo cual los hace inadecuados para la aplicación directa en un ámbito ágil. Este estudio muestra una iniciativa para integrar ocupaciones de seguridad en el proceso Scrum para desarrollar aplicaciones web seguras. Se identifica brechas en las metodologías existentes para garantizar el desarrollo ágil seguro. Después se adapta estas ocupaciones en el proceso de desarrollo de Scrum para poder tener seguridad y velocidad. La iniciativa es evaluada por un equipo Scrum que lleva a cabo aplicaciones comerciales con JAVA EE en una encuesta de crítica (Maier, Ma, & Bloem, 2017). iii) AP3: Project based on Agile Methodologies by DMAIC. Este artículo trata sobre la demanda por la integración de Metodologías Ágiles en productos y servicios de tecnología, especialmente en el desarrollo de software, el cual se ha vuelto cada vez más frecuente. Su aplicación asegura entregas ordinarias, sin embargo, no precisamente la calidad deseada, en especial una vez que se trata del reto técnico del retrabajo y la conducta de los empleados. Dichos son retos conocidos en el desempeño de las metodologías ágiles. Con base en el procedimiento DMAIC (Definir, Medir, Analizar, Mejorar y Controlar), se analiza un plan de desarrollo de software personalizado para un comprador usando Metodologías Ágiles. El propósito postulado cumple su funcionalidad de examinar el proceso en el periodo de desarrollo. Esto se hace por medio del diagnóstico de brechas en los procesos relacionados en el procedimiento de 61 errores determinados, la colección de datos, la retroalimentación de las piezas relacionadas y el mapeo de oportunidades de optimización, 43 como la utilización de FDD (Desarrollo de unidades de función), para poder hacer actividades de contorno (Salvadori, Magnano, & Dutra, 2021). iv) AP4: Framework Study for Agile Software Development Via Scrum and Kanban. Este artículo otorga una comparación sistemática entre 2 metodologías ágiles bien conocidas: Scrum, que es un marco para hacer proyectos por medio de la asignación de labores en pequeñas fases denominadas sprints, y Kanban, que es un sistema de programación para gestionar el flujo de trabajo mediante señales visuales. En este sentido, se revisan las dos metodologías para explorar similitudes y diferencias entre ellas. Después, se hace una encuesta de conjunto focal para especificar la metodología preferible para el desarrollo de productos según con diversos límites en el ámbito del plan, incluida la dificultad del plan, el grado de incertidumbre y la magnitud del trabajo, teniendo presente componentes de salida como la calidad, la productividad y la entrega. Los resultados presentan la flexibilidad de las dos metodologías para abordar fines ágiles, donde Scrum enfatiza la corporación del comprador y los grupos de desarrollo con un enfoque en capacidades particulares como la planeación, organización, presentación y revisión, lo cual lo hace ideal para proyectos nuevos y complicados donde hace falta una colaboración regular del comprador, mientras tanto que Kanban es más operativo en ámbitos de flujo constante con un enfoque constante hacia la optimización del sistema (Zayat & Senvar, 2020). v) AP5: The Impact of Agile Development Practices on Project Outcomes Este artículo presenta métodos ágiles de desarrollo de software para minimizar los problemas que se enfrentan al utilizar los enfoques tradicionales. Hay varios enfoques ágiles utilizados en el desarrollo de proyectos de software, estos incluyen Scrum, Extreme Programming y Kanban. Un enfoque ágil se centra en la colaboración entre clientes y 44 desarrolladores y anima a los equipos de desarrollo a organizarse por sí mismos. Para lograr esto, existen diferentes prácticas ágiles que los equipos eligen usar en sus proyectos. Algunos equipos solo usan una práctica mientras que otros usan una combinación de prácticas. Las prácticas más comunes utilizadas son stand-ups, HU, Burndown chart/Burnup chart y pair programming. Este estudio informa sobre el análisis de los datos recopilados de personas involucradas en equipos de desarrollo de software ágil e identifica que la combinación de prácticas en el desarrollo tiene un impacto en la comunicación en el equipo, los requisitos del proyecto y sus prioridades, y se adoptan más prácticas correlacionándose con mejores resultados del proyecto (Ghimire & Charters, 2022). Modelar y organizar las referencias seleccionadas Una vez recopiladas y registradas las referencias seleccionadas, se necesita ordenarlas según ciertos criterios para llevar a cabo o edificar el marco teórico del trabajo a ser desarrollado (Arnau & Josefina, 2020). Para organizar de forma correcta las referencias, se utiliza la técnica del mapa conceptual de la literatura el cual da un retrato visual de los clústeres de literatura asociados al asunto de análisis (Janovec, 2001). En la Figura 5, se muestra un ejemplo de cómo se debe realizar mapa conceptual de la literatura. Figura 5. Ejemplo del mapa de literatura Ejemplo del mapa de literatura 45 Nota. La figura 5 muestra cómo se realiza un mapa de literatura acerca de las preocupaciones de los empleados sobre la equidad y la toma de decisiones gerenciales. Adaptado de Procedural justice in organizations: A literature map. Unpublished manuscript, University of Nebraska-Lincoln. por Janovec, T, 2001. En base a la Figura 5, se crea el mapa conceptual de la literatura propio (Ver Figura 6) con los AP de la Tabla 6 para poder tener una visión clara de lo que va a contener el marco teórico del trabajo. Figura 6. Mapa conceptual de la literatura aplicado Mapa conceptual de la literatura aplicado 46 Nota. La Figura 6 muestra el mapa conceptual de literatura realizado en base a los AP de la Tabla 6 para la elaboración del marco teórico Si bien la Figura 6 no representa a exactitud todo el marco teórico que se puede desarrollar, da una idea de las principales secciones que va a tener, así como sus respectivos subtemas y de dónde se obtendrá la información para poder realizar las respectivas citas. Analizar e interpretar los resultados de los artículos seleccionados Después de haber analizado cada artículo y haber interpretado de la mejor forma los resultados de cada uno, se llega a la conclusión de que el tema propuesto para el desarrollo del trabajo es innovador, puesto que, si bien se ha encontrado información relacionada como las metodologías ágiles, HU, desarrollo de aplicaciones web y la técnica de las 5W+2H no existe como tal una propuesta en que se desee automatizar este proceso e integrarlo dentro de Scrum almacenando versiones y que sirve como una herramienta para un ambiente pedagógico o incluso ya profesional. Por tal motivo, los artículos seleccionados van a ser de mucha ayuda para la elaboración del marco teórico y para tener las principales bases de conocimiento para el desarrollo de la aplicación web. 47 Metodología La metodología que va a guiar el desarrollo de la aplicación web es la conocida como Design Science Research (DSR), en donde el principio fundamental de la investigación de la ciencia del diseño es que el conocimiento y la comprensión de un problema de diseño y su solución se adquieren en la construcción y aplicación de un artefacto (Hevner, March, & Park, 2004). Por tal motivo, es la metodología ideal para lo que se pretende hacer, puesto que, se tiene un problema que se ha detallado en el capítulo I y la solución que se plantea es desarrollar una aplicación web para automatizar el proceso de las 5W+2H, entonces como se ve cumple con el principio fundamental del DSR, lo que significa que se puede usar esta metodología. Figura 7. Fases de la metodología DSR Fases de la metodología Design Science Research (DSR) Nota. La Figura 7 muestra todas las fases de la metodología de Design Science Research DSR. Adaptado de Introduction to Design Science Research (p. 6), por J. Brocke, A. Maedche y A. Hevner, 2020, Design Science Research Cases. 48 Identificación de la problemática y motivación. Esta actividad define el problema de un trabajo específico y justifica el costo de una solución (Brocke, Hevner, & Maedche, 2020). Esta primera fase ya se ha desarrollado a mayor profundidad en el Capítulo I en donde se puede evidenciar la problemática identificada mediante encuestas realizadas a los estudiantes, para mayor información Ver Tabla 1 – 2 y Ver Figura 1 – 2. Asimismo, se puede ver la justificación del por qué es necesario desarrollar una aplicación web para solucionar el problema encontrado en los estudiantes pertenecientes a las carreras del DCCO. Definición de los objetivos de la solución. Se describe esta actividad como la posibilidad de intuir la explicación del problema y del conocimiento sobre los objetivos, de manera que sea posible y factible. (Brocke, Hevner, & Maedche, 2020). Para el desarrollo de esta fase se realizó una matriz de congruencia metodológica Ver Tabla 3. Así, se pudo decretar los objetivos específicos y las preguntas de investigación para cada objetivo Diseño y desarrollo. En esta fase se diseñará y desarrollará la solución a la problemática observada en el capítulo 1 y se lo llamará como artefacto (Brocke, Hevner, & Maedche, 2020). El artefacto será capaz de gestionar las historias de usuario con la técnica de las 5W+2H en un marco de trabajo SCRUM. Demostración. En esta etapa se pone a prueba el artefacto y se verifica que su funcionamiento sea el deseado con el objetivo de resolver una o más instancias de la problemática. (Brocke, Hevner, & Maedche, 2020). En este caso, se requiere demostrar que el aplicativo web cumpla con las expectativas de los usuarios, este proceso se realizará mediante encuestas. Evaluación. La evaluación mide ya sea con métricas cualitativas o cuantitativas cuán efectivo es el artefacto sobre la problemática (Brocke, Hevner, & Maedche, 2020). En esta 49 etapa se pondrá a prueba el artefacto con métricas de evaluación tales como eficiencia, usabilidad, rendimiento, entre otras. Comunicación. Los resultados de la reacción del artefacto sobre la problemática son comunicados a las partes interesadas (Brocke, Hevner, & Maedche, 2020). Se manifiesta si el artefacto comprueba la hipótesis planteada en el capítulo 1 y junto a estudiantes de distintos cursos del periodo PAO202251 del DDCO, se realizará la contrastación de la técnica de las 5W+2H con el proceso de elicitación de requisitos en la identificación de requisitos funcionales y no funcionales. Marco Teórico Conceptos de Gestión de Proyectos Proyecto. Un proyecto es un esfuerzo temporal emprendido para crear un producto, servicio o resultado único y según (Project Management Institute, 2021) tiene varias características que lo identifican. i) Temporal: Cada proyecto tiene una fecha de inicio y fecha de final definidos y estos se deben identificar en la planificación del proyecto. El final del proyecto (también conocido como deadline), es cuando se ha logrado los objetivos del proyecto o cuando se ha decidido que no se llegará a cumplir los objetivos, resultando en un proyecto cancelado. ii) Productos, servicios o resultados únicos: El resultado final de todos los proyectos, es un producto, servicio o resultado entregable. En el caso de producto, puede ser cuantificable o un componente. Los servicios se distinguen por ser prestados por un personal asignado y es un aporte al usuario, finalmente el resultado puede ser un documento aplicado al conocimiento. iii) Elaboración gradual: Significa que un proyecto empieza una temprana fase de desarrollo (no necesariamente desde cero), continúa en pasos y aumentando 50 mediante incrementos. Su importancia influye el concepto de temporal, ya que sirve para la planificación de fechas de inicio y de fin de un proyecto. Todo proyecto tiene partes interesadas en torno al producto final y puede ser el personal que trabaja o está implicada en el proyecto, siendo ellos un elemento clave para el éxito del proyecto, ya que se considera exitoso si logra o supera las expectativas de las partes. Programa. Un programa dentro del contexto de la dirección de proyectos, es un conjunto de proyectos relacionados entre sí que se gestionan en grupo para la obtención de beneficios adicionales, a diferencia de manejarlos individualmente. Normalmente se puede identificar un programa si sus proyectos tienen relación y al ejecutarlos de forma coordinada se logra los objetivos de las partes interesadas, beneficiando a todos los proyectos del programa. (Project Management Institute, 2021). Portafolios. Un portafolio, por su lado, es un grupo de programas o proyectos, que se manejan en conjunto para facilitar la gestión de los proyectos y con la meta de cumplir los objetivos específicos y condiciones de la organización. (Project Management Institute, 2021). Dentro del contexto de la Ingeniería de Software, la gestión de portafolios implica la estrategia, coordinación y administración de los distintos proyectos de software de una organización. Figura 8 Proceso de establecimiento de un sistema de gestión de portafolios Proceso de establecimiento de un sistema de gestión de portafolios Nota. La Figura 8 muestra los 5 pasos a realizar para el correcto proceso de establecimiento de un sistema de gestión de portafolios. Adaptado de Project Portfolio Management System, 51 concepts and approach foundations (p. 4), por M. Dezhkam, S. Xue y A. Liu, 2019, IOP Conference Series Earth and Environmental Science Según (Dezhkam, 2019), el proceso involucra un total de cinco pasos con el objetivo de clarificar cómo un sistema de gestión de portafolios es correctamente establecido. El primer paso es explicar el estado de los proyectos, este proceso involucra recopilar información sobre el estado más reciente de estos, se lo realiza con el objetivo de destinar fondos, priorizar y analizarlos. En el segundo paso se determina la organización de los criterios de evaluación de cada proyecto de manera que puedan ser analizados y evaluados de forma correcta. El tercer paso consiste en un análisis para identificar la prioridad de cada proyecto, este proceso se lo realiza mediante ponderaciones para juzgar el valor de estos a través de criterios como las partes interesadas, dirección, gestión, entre otros. El cuarto paso involucra a los recursos de la organización, tales como el presupuesto y el factor humano, para mantener el portafolio de proyectos se realiza un análisis de restricciones que dificulten la gestión de proyectos Finalmente, el quinto paso es la recopilación de los cuatro anteriores, en donde se confirma el estado y el valor de los proyectos, además de los riesgos y el presupuesto. Este proceso permite a la organización gestionar los portafolios de una forma organizada, correcta y acertada, además permite conocer cuales proyectos son prioritarios y cuales pueden llegar a ser suspendidos, optimizando los recursos de la organización. Relación entre proyectos, programa y portafolios en una organización. Como observamos previamente, los proyectos, programas y portafolios se relacionan entre sí para cumplir con las expectativas del cliente y los objetivos específicos. Estas definiciones nos 52 sirven para gestionar los proyectos de una forma más ordenada y siguiendo un plan estratégico. La figura 9 nos indica la relación que existe entre ellos; el proyecto que puede ser dirigido a tres escenarios: como un proyecto independiente (fuera de programa o portafolio), dentro de un programa o dentro de un portafolio. (Guerrero, 2019). Figura 9 Diagrama de relación entre proyectos, portafolio y programas en una organización Diagrama de relación entre proyectos, portafolio y programas en una organización Nota. La Figura 9 muestra un diagrama de relación entre proyectos, portafolio y programas en la gestión de proyectos dentro de una organización, indicando los tres escenarios de un proyecto. Adaptado de Proyectos, portafolios y programas y la PMO (p. 2), por D. Guerrero, 2018, Repositorio Institucional PIRHUA. Ciclo de vida del proyecto. Es una serie de etapas por las que pasa un proyecto desde su inicio hasta su final y la secuencia de estas fases típicas según (Project Management Institute, 2021) son las siguientes: Figura 10 Secuencia de fases típica en un ciclo de vida del proyecto 53 Secuencia de fases típica en un ciclo de vida del proyecto Nota. La Figura 10 muestra la secuencia de las fases típicas en un ciclo de vida de un proyecto desde su fase inicial hasta la final. Adaptado de Guía de los fundamentos para la dirección de proyectos (p. 23), por Project Management Institute, 2021, NISO (National Information Standards Organization). Fase inicial: Tiene como entrada la idea y el equipo de dirección del proyecto, normalmente la salida de esta fase suele ser un acta de constitución que autoriza el comienzo de un proyecto con las especificaciones y el enunciado del alcance. Fase intermedia: Es todo el proceso del proyecto (desarrollo de los productos, servicios o resultados únicos), las salidas de esta fase es un plan, línea base, avance y aceptación de los interesados. Fase final: En esta etapa se realiza la aprobación del proyecto por parte de los interesados y la entrega del producto, servicio o resultado único. Estructura de Desglose del Trabajo (EDT). Una Estructura de Desglose del Trabajo (EDT) dentro de un proyecto es una representación gráfica del plan de manera bastante detallada. Se van organizando las actividades a varios niveles con el objetivo de alcanzar un 54 nivel de detalle suficiente para planificar y mantener el control de manera correcta del proyecto. (EALDE, 2020) El proceso de la creación de una Estructura de Desglose del Trabajo (EDT) es un proceso dentro de la gestión del alcance del proyecto, de manera que se pueda subdividir entregables del proyecto en componentes que faciliten el manejo y que sean compactos (Project Management Institute, 2021), esto se lo realiza en forma de árbol tal como se muestra en la figura 11. Figura 11 Ejemplo de Estructura de Desglose del Trabajo Ejemplo de Estructura de Desglose del Trabajo Nota. La Figura 11 muestra un ejemplo de una Estructura de Desglose del Trabajo (EDT), que se descompone en diferentes ramas hasta llegar al nivel de cada paquete de trabajo. Adaptado 55 de Guía de los fundamentos para la dirección de proyectos (p. 114), por Project Management Institute, 2021, NISO (National Information Standards Organization). Todo proyecto dentro de su gestión requiere de una Estructura de Desglose del Trabajo (EDT) en la que se puedan definir cada paquete de trabajo, asignarlo al personal correspondiente, establecer un cronograma y definir el presupuesto que será asignado por la organización para el desarrollo adecuado del producto (EALDE, 2020). Dentro del campo de desarrollo de software, se puede realizar un EDT con las diferentes etapas del desarrollo de software asignadas en el proyecto. Se lo realiza normalmente en la gestión del alcance del proyecto. Figura 12 Ejemplo de Estructura de Desglose del Trabajo (EDT) de un proyecto de software Ejemplo de Estructura de Desglose del Trabajo (EDT) de un proyecto de software Nota. La Figura 12 muestra un ejemplo de una Estructura de Desglose del Trabajo (EDT) en un proyecto de desarrollo de software en donde se realiza el diseño y la implementación de una página web y app móvil para el Ministerio de Agricultura en Bogotá. Adaptado de DISEÑO E IMPLEMENTACIÓN DE UNA PAGINA WEB Y APP MOVIL PARA EL MINISTERIO DE AGRICULTURA (p. 11), por J. Guerra, G. Hernandez, O. Hernandez, 2016, Universidad Santo Tomas. 56 Ingeniería de Requisitos (IR) La Ingeniería de Requisitos es una de las etapas más importantes dentro de la ingeniería de software. Ya que marca el punto de partida para otras actividades del proyecto de software y la correcta elicitación de estos permiten verificar si los objetivos propuestos son alcanzables y óptimos para conseguir la satisfacción de las partes interesadas (Alvarez, y otros, 2021). ¿Qué es un requisito? La definición de un requisito puede variar dependiendo del autor, según la Real Academia Española de la Lengua, un requisito es “circunstancia o condición necesaria para algo” (Real Academia Española, 2014). Para (IEEE, 2008), un requisito debe ser una condición que el usuario necesita para lograr un objetivo en específico. Además, esta condición debe tener un sistema o un componente y representada en un documento formal. Las cuatro actividades principales de la Ingeniería de Requisitos (IR). Según (IREB, 2015), la Ingeniería de Requisitos tiene cuatro principales actividades: i) Elicitar: Es la actividad en la que se extrae la información, es decir los requisitos mediante diferentes técnicas y las refina. ii) Documentar: En esta etapa se define la forma de documentar la especificación, normalmente de lo realiza en lenguaje natural. iii) Verificar y ajustar: Se asegura la calidad del producto en una fase temprana del desarrollo. iv) Administrar: Se prioriza a los interesados del proyecto a través de la estructuración y organización de los requerimientos. Los interesados suelen cambiar de opiniones y en esta etapa es donde se modifica los requerimientos para implementarlos en el proyecto. 57 Requisitos funcionales. Los requisitos funcionales son aquellos requerimientos que están involucrados en el resultado del comportamiento del sistema (IREB, 2015). Además, están inmersos en los servicios que un sistema de software debe suministrar y cómo estos afectan al comportamiento del sistema en situaciones en específico. Estos dependen del tipo de software que se vaya a desarrollar y de las necesidades del cliente (Sommerville, 2011). En la especificación de los requisitos funcionales deben definirse todos los servicios que se van a proveer y son requeridos por el cliente (Sommerville, 2011). Algunos ejemplos de requisitos funcionales puede ser la búsqueda de ciertos datos que proveen la información al personal que lo necesita, registrar miembros a la base de datos, autenticación, etc. Requisitos no funcionales. Son aquellos requisitos que no se relacionan directamente con el servicio que va a proveer el proyecto de software a desarrollarse y se relaciona con propiedades que están intrínsecas en el sistema y mejora la satisfacción del usuario con el software (Sommerville, 2011). Según (IEEE, 2008), los requisitos no funcionales, a diferencia de los requisitos funcionales, no especifica qué es lo que hará el software, sino, cómo lo hará. Según (Sommerville, 2011), existe tres tipos de requisitos no funcionales: Requisitos del producto: Se especifica o restringe el cómo debe comportarse el software. Alberga características como el rendimiento, memoria, fiabilidad, seguridad y usabilidad de un software. Requisitos de la organización: Son aquellos que se definen entre el cliente y el desarrollador dependiendo de las políticas y procesos que se ocupen en la organización del cliente. En estos incluyen cómo llegará a usarse el sistema, lenguajes de programación, estándares, y requisitos ambientales. 58 Requisitos externos: Alberga todos aquellos requisitos que son externos al sistema y a su proceso de desarrollo, esto quiere decir, que dependen de organizaciones externas como entes reguladores, legislativos, éticos, etc. En la figura 13 se muestra un árbol de los requisitos no funcionales y su clasificación, además de qué métricas y procedimientos involucra en cada uno de ellos para realizar un sistema fiable. Figura 13 Clasificación de requisitos no funcionales en un proyecto de software. Clasificación de requisitos no funcionales en un proyecto de software. Nota. La Figura 13 muestra cómo está clasificado los requisitos no funcionales dentro de un proyecto de software. Adaptado de Ingeniería de Software (p. 88), por I. Sommerville, 2011, Pearson Education, Inc. Requisitos de Calidad. Los requisitos de calidad definen la o las características que un sistema debe tener, en algunas ocasiones afecta a la arquitectura del sistema (IREB, 2015). Por ejemplo (Organización Internacional de Normalización, 1991) define que la especificación 59 de la funcionalidad de los requisitos de calidad es, entre otros, la fiabilidad, usabilidad, portabilidad, eficiencia y mantenibilidad, siendo meticas medibles cualitativas o cuantitativas. Obtención de requisitos. Toda obtención de requisitos, tiene distintas fuentes para extraerlos, usualmente comienza con un análisis del contexto del sistema y de varias fuentes de requisitos, algunos ejemplos de fuentes de requisitos son: las partes interesadas del proyecto (también conocidos como stackholders), documentos de la organización que toma el papel de cliente y los sistemas de operación (IREB, 2015). También, se menciona que el ingeniero de requisitos, es aquella persona que debe identificar todas las fuentes de los requisitos. Una vez identificadas, estas deben ser accesibles y debe llevar una o varias listas de comprobación, por el lado contrario, si no han sido identificadas, este problema conduce a la falta de conocimiento del personal a lo largo del proyecto. Las partes interesadas en el proyecto es la fuente de requisitos más importante y confiable para el ingeniero de los requisitos (IREB, 2015), es por ello que se debe realizar una lista de interesados, un ejemplo se muestra en la figura 14 que se analiza a cada interesado dentro del proyecto. Tabla 7 Ejemplo de una estructura de lista de interesados en la fuente de requisitos Ejemplo de una estructura de lista de interesados en la fuente de requisitos 60 Nota. La Tabla 7 muestra cómo está estructurado una lista de interesados dentro de un proyecto de software. Adaptado de Profesional Certificado en Ingeniería de Requisitos de IREB (p. 12), por IREB, 2015, IREB. Existen varias técnicas para el levantamiento de requisitos, estos pueden ser: técnicas de interrogatorio como entrevistas o entrevistas; técnicas creativas como lluvia de ideas o recopilación de ideas, técnicas basadas en la documentación tales como arqueología de Interesados Descripción Represe ntante Información de contacto Disponibil idad Competencia Gestión de producto Interlocutor con el cliente. Responsable del éxito del negocio. H. Schmidt Teléfono … Correo … Vacacione s CW13 Conoce al cliente desde hace 4 años. R. Schuize Teléfono … Correo … Inmediata Conocimiento de los productos de la competencia. Cliente Fuente de recursos económicos. Usuario del sistema. J Doe Teléfono … Correo … 11:00- 14:00 horas Excelente conocimiento del mercado. M Smith Teléfono … Correo … Inmediata Sólo conoce su área de trabajo, responsable de pruebas de aceptación. 61 sistema, lectura basada en la perspectiva, reutilización de requisitos, entre otros. Últimamente se ha popularizado las técnicas de observación como observación de campo, aprendizaje u otros (IREB, 2015). Documentación de requisitos. Los documentos de requisitos es un conjunto de requisitos sistemáticamente representado, generalmente para un sistema o componente, que se ajusta a un estándar determinado y según (IREB, 2015) tiene varios propósitos: Sentar las bases para las actividades de desarrollo, identificar las cuestiones relevantes desde el punto de vista jurídico, reflejar la complejidad del tema/problema que se está abordando y aclarar los requisitos a todos los involucrados. Además, en (IREB, 2015), se detalla tres formas de documentar los requisitos: En forma de lenguaje natural: Es muy versátil y (por supuesto) fácil de entender para cualquier persona, se aplica a cualquier perspectiva y estas pueden combinarse, haciendo que los requisitos sean inexactos. Mediante modelos conceptuales: Es preciso y fácil de entender gracias a una sintaxis familiar (mediante el formalismo), es separado para cada perspectiva, pero no es aplicable en todas partes porque se requiere conocimiento de la notación. Combinaciones de ambos: Al combinar el poder de los lenguajes naturales y los modelos conceptuales, se pueden reducir sus limitaciones. Por ejemplo, descripciones verbales de modelos esquemáticos Existe algunos ejemplos de estructura de documentos que facilitan la documentación de requisitos, uno de los más conocidos es IEEE 830, que su estructura se puede observar en la figura 14. Figura 14 Estructura de documento de la IEEE 830 -1998 62 Estructura de documento de la IEEE 830 -1998 Nota. La Figura 14 muestra cómo está estructurado un documento de requisitos IEEE 830. Adaptado de Profesional Certificado en Ingeniería de Requisitos de IREB (p. 15), por IREB, 2015, IREB. Documentación basada en modelos. Las ventajas del lenguaje natural (prosa) y los modelos de requisitos basados en documentación a menudo se combinan. Las descripciones visuales lo ayudan a comprender problemas complejos. Usando, por ejemplo: el modelo de destino (árboles), los diagramas de caso de uso, diagramas ER y diagramas de clases (perspectiva estructural), diagramas de flujo de datos UML y diagramas de actividad (punto de vista funcional), diagramas de estado UML y gráficos de estado (perspectiva de comportamiento) (IREB, 2015). Validación de requisitos. El objetivo principal de la validación de los requisitos es determinar si cumplen con los criterios de calidad predefinidos para detectar y corregir cualquier anomalía lo antes posible. Dado que los documentos de requisitos forman la base de todo el desarrollo posterior, cada tipo de error de requisito no detectado afecta a todas las 63 operaciones posteriores de tal manera que no se intenta el esfuerzo de depuración requerido (IREB, 2015). Gestión de requisitos. El propósito de la gestión de requisitos es garantizar que se cumplan los objetivos de desarrollo del producto. Es un conjunto de métodos para documentar, analizar, priorizar y negociar requisitos, asegurando que los equipos de ingeniería siempre tengan los requisitos actualizados y aprobados. La gestión de requisitos ayuda a prevenir errores al realizar un seguimiento de los cambios en los requisitos y facilitar la comunicación con las partes interesadas en las primeras etapas del proyecto durante todo el ciclo de desarrollo (IBM, 2021). Metodologías Ágiles Las metodologías ágiles son una forma de gestionar los proyectos, no necesariamente de software, sino de cualquier tipo de proyecto que suelen requerir constante colaboración con las partes interesadas. Las metodologías ágiles de desarrollo de software son desarrollos iterativos e incrementales donde los requisitos van en un cambio constante según las necesidades del cliente o de los interesados del proyecto. Ayuda con la planificación de un proyecto de software, el desarrollo iterativo y las limitaciones de tiempo. Es un marco de trabajo que impulsa la interacción esperada a lo largo del ciclo de desarrollo del producto de software (Sharma, Sarkar, & Gupta, 2012). Características de proyectos gestionados con metodologías ágiles. El proceso de las metodologías ágiles requiere menos planificación y divide las tareas en pequeños incrementos. Las metodologías ágiles están pensadas para proyectos a corto plazo con un esfuerzo de trabajo en equipo que sigue el ciclo de vida del desarrollo de software que observamos previamente. En el proceso ágil se pueden añadir fácilmente nuevas características mediante el uso de múltiples iteraciones. Las características más importantes de un proyecto gestionado con metodología ágil, son: iterativo, modularidad, gestión de tiempo, 64 incremental, adaptivo, convergente, colaborativo y orientado a las personas (Sharma, Sarkar, & Gupta, 2012). Algunas prácticas que afectan la comunicación incluyen espacios de oficina abiertos, acumulación de productos (backlog), planificación de sprint, reuniones de planificación de sprint, revisiones de sprint, reuniones diarias y retrospectiva de cada iteración (Ghimire & Charters, 2022). Prácticas usadas en proyectos gestionados con metodologías ágiles. Los diferentes tipos de metodologías ágiles usan varias prácticas comunes, que permiten cumplir con todos los objetivos que hacen que un proyecto sea ágil. Los autores (Ghimire & Charters, 2022) realizaron una tabla que recopila estas prácticas tras realizar un análisis sistemático de la literatura, esta se muestra en la tabla 8. Tabla 8. Prácticas usadas en proyectos agile Prácticas usadas en proyectos agile Práctica Descripción Stand-ups Reunión permanente de 15 minutos en la que el equipo proporciona información sobre el progreso del proyecto y si surge algún problema Integración continua Proceso de reunir el trabajo realizado por los desarrolladores cuando se realizan cambios Backlog La lista de entregables priorizados que se van a implementar en un proyecto, se suelen realizar con historias de usuario, que serán detalladas más adelante. 65 Práctica Descripción Pair Programming (programación en pareja) Técnica en la que dos desarrolladores trabajan juntos en un mismo puesto de trabajo Burndown chart/Burnup chart (Gráfico de avance) Registro visual del trabajo realizado o por realizar en un proyecto Definition of Done (Definición de hecho) Cuando todos los criterios de aceptación que debe cumplir cada entregable se cumplen y están listos para ser entregados al cliente Refactoring (Refactorización) El proceso de mejorar la estructura del código existente mientras se conserva el comportamiento externo. Scrum board (Tablero de SCRUM) Este tablero es la muestra visual del estado/progreso del trabajo en cada sprint. Kanban board (Tablero de Kanban) Herramienta de visualización que proporciona un progreso visual de la tarea del proyecto, los flujos de trabajo y las comunicaciones. Retrospectiva Es una reunión en la que el equipo reflexiona sobre lo que ha funcionado, lo que no ha funcionado y por qué Épica Un cuerpo de trabajo en el que el trabajo se puede desglosar en historias de usuario. Sprint/Time box Periodo de tiempo en el que un equipo trabaja para completar una cantidad de trabajo determinada 66 Práctica Descripción Planning Poker Technique (Técnica de plan de poker) Técnica que utilizan los desarrolladores para estimar el esfuerzo de una tarea Automated Test (Pruebas automatizadas) Se crean casos de prueba que se ejecutan automáticamente cuando el nuevo código se introduce en el repositorio Definition of Ready (Definición de listo) Técnica utilizada para determinar si el trabajo en una tarea está listo para comenzar. Unit Test (Pruebas unitarias) Es un tipo de prueba de software en la que se prueban unidades/componentes individuales del software. Continuous development (Desarrollo continuo) Es una práctica de integración rutinaria de los cambios de código en el repositorio principal del sistema. Nota. Esta tabla es una recopilación de las prácticas junto a su descripción que son más usadas dentro de proyectos gestionados con metodologías ágiles. Adaptado de The Impact of Agile Development Practices on Project Outcomes (p. 266, 267), por D. Ghimire y A. Charters, 2022, MDPI. Metodología Scrum. Scrum es otro método popular de desarrollo ágil que puede ser muy productivo. Se basa básicamente en un proceso de desarrollo de software incremental. En la metodología Scrum, un ciclo de desarrollo completo se divide en una serie de iteraciones, cada iteración se denomina sprint. La duración máxima de un sprint es de 30 días (Sharma, Sarkar, & Gupta, 2012). Cada equipo de Scrum tiene un dueño del producto (Product Owner), un maestro de Scrum (Scrum Master) y un equipo de desarrollo. Los equipos Scrum son multifuncionales y 67 autoorganizados. Los equipos son flexibles y están diseñados para trabajar con creatividad y productividad (Zayat & Senvar, 2020). A continuación, en la tabla 9, se presenta los distintos actores de Scrum junto a su rol dentro de un proyecto. Tabla 9 Equipo de Scrum y sus roles dentro de un proyecto Equipo de Scrum y sus roles dentro de un proyecto Miembro Rol Dueño del producto (Product Owner) Su principal rol dentro de la organización es asegurarse que el producto tenga valor y sea de calidad, además es el encargado de la gestión del product backlog como la identificación de los elementos, ordenarlos según su importancia, aclarar el backlog a su equipo, entre otros. Scrum master Es una persona encargada de asegurar que la gestión del proyecto se la realiza como dicta la guía de SCRUM, aumenta la eficacia del proyecto y da las pautas de cómo realizarlo. Equipo de desarrollo de Scrum Son los encargados de desarrollar el producto, al final de cada sprint, presenta el producto según cada incremento, siguen las especificaciones del backlog para construir el producto. Algunas de sus características son: autoorganizados, interfuncionales y flexibles. Nota. Esta tabla es un resumen de los miembros de un equipo dentro de un proyecto con la metodología ágil Scrum y los roles que cumplen. Adaptado de Framework Study for Agile 68 Software Development Via Scrum and Kanban (p. 8, 9), por W. Zayat y O. Senvar, 2020, International Journal of Innovation and Technology Management. Ciclo de Vida de Scrum. El comienzo de un proyecto con metodología ágil Scrum, es la organización del Product Backlog, este proceso se maneja bajo la supervisión del Scrum Master. Después, inicia la planificación de los sprints y su posterior ejecución, pasada el sprint se muestra un producto potencial para el cliente, luego el ciclo se repite una y otra vez (Zayat & Senvar, 2020). La figura 15 muestra un marco de trabajo ágil Scrum con todos los pasos. Figura 15 Ciclo de vida Scrum Ciclo de vida Scrum Nota. La Figura 15 muestra cómo está estructurado normalmente un ciclo de vida Scrum en un proyecto de software. Adaptado de Framework Study for Agile Software Development Via Scrum and Kanban (p. 8, 9), por W. Zayat y O. Senvar, 2020, International Journal of Innovation and Technology Management. Historias de Usuario. Las historias de usuarios son una forma común de expresar los requisitos, a menudo con modelos simples como: "como (roles), quiero (objetivos), [de esa manera (beneficios)]". La adopción de historias de usuarios está creciendo, especialmente en 69 el contexto del desarrollo ágil de software. Las historias de usuario se utilizan principalmente junto con metodologías ágiles. En particular, Scrum es utilizado por la mayoría de los profesionales que participan en este tipo de proyectos. (Lucassen, Dalpiaz, van der Werf, & Brinkkemper, 2016). Un conjunto de historias de usuarios forma los componentes básicos para describir los requisitos o funciones de un sistema de información desarrollado en un proyecto gestionado con metodologías ágiles. Son utilizados al comienzo del primer sprint y el conjunto priorizado de historias de usuarios se almacenan en el producto backlog y esta se actualiza con nuevas historias de usuario después de cada Sprint a medida que se identifican nuevos requisitos (Bolloju, Alter, Gupta, Gupta, & Jain, 2017). Técnica de las 5W+2H. La herramienta 5W+2H es esencialmente una técnica para comprender los requisitos y permitir la creación de historias de usuario. La técnica de las 5W+2H se considera una herramienta de planificación muy utilizada en la gestión empresarial. Esta es una lista de verificación que contiene las actividades específicas que los empleados de su organización deben realizar con la mayor claridad. Juega un papel importante en la resolución de problemas ya que elimina por completo las dudas que puedan surgir sobre el proceso o actividad (da Silva & Gonçalves, s.f). A continuación, se puede observar ver cada uno de ellos y lo que representan: • ¿Qué? – ¿Qué se hará (pasos)? • ¿Por qué? – ¿Por qué se hará (justificación)? • ¿Dónde? – Dónde se hará (ubicación)? • ¿Cuándo? – ¿Cuándo se hará (tiempo)? • ¿Quién? – ¿Por quién se hará (responsabilidad)? • ¿Cómo? – ¿Cómo se hará (método)? 70 • ¿Cuánto? – ¿Cuánto costará hacer (coste)? La técnica de las 5W+2H se puede adaptar para diseñar requisitos de manera eficiente, facilitar la compilación de historias de usuarios que pueden crear criterios de aceptación y definir escenarios de prueba para ejecutar. Al diseñar los requisitos, debe aplicar preguntas y recopilar información. Las historias de usuario se pueden crear completamente utilizando los datos disponibles (da Silva & Gonçalves, s.f). Al aplicar esta técnica a un marco de trabajo para la obtención de historias de usuario, se parte desde un problema, el que debe ser analizado, coordinado y documentando en lenguaje natural que permita su fácil comprensión, posteriormente se aplica la técnica de las 5W+2H para conocer más acerca del problema para su resolución, se documenta y enlista de acuerdo a su prioridad (alta, media o baja) y surge la historia de usuario (Ruiz, 2020). Figura 16 Descripción de los componentes del marco de trabajo Descripción de los componentes del marco de trabajo Nota. La Figura 16 muestra cómo beneficia la técnica de las 5W+2H a un marco de trabajo ágil para la resolución de problemas y generación de historias de usuario. Adaptado de Planteamiento de un marco de trabajo para levantar requisitos de software con estudiantes del primer nivel de la carrera de software de la Universidad de las Fuerzas Armadas-ESPE (p. 4), por J. Ruiz, 2020, Curso Internacional en Cultura de la Investigación UNIR. 71 Capítulo III Herramientas Para la elaboración de la aplicación web se ocupan varias herramientas entre lenguajes de programación, servicios de alojamiento, librerías, frameworks y repositorio para poder almacenar todo el código que se va realizando, Las principales herramientas que se han utilizado son las siguientes. Modelado de datos Power Designer. Es la herramienta que se encarga de dirigir la modelización de datos y fue publicada por SAP. Posibilita a las organizaciones visualizar, examinar y manipular de forma más simple los metadatos para tener una arquitectura de información de compañía eficaz (SAP, 2016). Esta herramienta se utiliza para realizar el modelado de la BD y de esta forma obtener un modelo conceptual (CDM), un modelo lógico (LDM) y un modelo físico (PDM) de la cual se va a implementar, con el objetivo de realizar el almacenamiento de toda la información, además con esta herramienta se va a generar el script para la misma. Para el desarrollo de la aplicación se usa la versión 16.7. Base de datos (BD) MySQL. Es BD de código abierto más conocido de todo el mundo. Es ideal para aplicaciones web de veloz aumento, un ISV (Proveedor de software independiente) de tecnología o una gigantesca compañía, MySQL puede ayudar de forma rentable a dar aplicaciones de BD escalables y de elevado rendimiento (Oracle, 2022). Se seleccionó esta BD puesto que, otra herramienta llamada PythonAnywhere, de la cual se hablará más adelante, venía integrada de forma gratuita, además era necesario ocupar una BD relacional dado que, dentro de la aplicación existen varias relaciones entre las diferentes entidades. Para el desarrollo de la aplicación se usa la versión 8.0.31. 72 Backend Python. Es un lenguaje de programación que posibilita laborar inmediatamente e integrar sistemas de forma más eficaz y efectiva (Python, 1996). Se utiliza este lenguaje de programación porque en conjunto con el framework Flask sirve para crear API Rest de forma rápida, además siguiendo buenas prácticas de código limpio, el código se puede volver totalmente mantenible y simple de entender para los desarrolladores que deseen estudiarlo. Para el desarrollo de la aplicación se usa la versión 3.11.0. Flask. Es un marco de aplicación web WSGI ligero. Está creado para que comenzar sea veloz y simple, con la función de escalar a aplicaciones complicadas. Inició como un sencillo envoltorio de Werkzeug y Jinja y se convirtió en uno de los marcos de aplicaciones web de Python más famosas (Flask, 2022). Se utiliza este framework debido a que se acopla perfectamente con Python, además existe mucha documentación en la página oficial de Flask de cómo realizar su instalación, crear API Rest, entre otras que facilitan el desarrollo. Para el desarrollo de la aplicación se usa la versión 2.2.2. Control de Acceso HTTP (CORS). Es un mecanismo que usa cabeceras HTTP extras para permitir que un agente de usuario obtenga permiso para entrar a recursos seleccionados a partir de un servidor, en un origen diferente al que pertenece. Un agente crea una petición HTTP de procedencia cruzada una vez que solicita un recurso a partir de un dominio diferente, un protocolo o un puerto distinto al del archivo que lo generó (MDN, 2022). Esta librería se ocupa para poder realizar peticiones al API Rest y que puede ser consumida por el usuario sin mayor problema. Para el desarrollo de la aplicación se usa la versión 3.0.10. SQLAlchemy. Es el kit de herramientas SQL de Python y el asignador relacional de objetos que ofrece a los desarrolladores de aplicaciones todo el poder y la flexibilidad de SQL (SQLAlchemy, 2005). Como ya se mencionó anteriormente, se va a utilizar la BD MySQL razón por la cual el uso de SQLAlchemy es de vital importancia para poder crear los modelos que van 73 a ser similares a las tablas de la BD y de esta forma establecer las propiedades y relaciones entre los modelos. Para el desarrollo de la aplicación se usa la versión 2.0. Frontend Javascript (JS). Es un lenguaje de programación ligero, interpretado, o compilado (just- in-time) con funcionalidades de primera clase. Si bien es más habitual como un lenguaje de scripting para páginas web, y es utilizado en varios espacios fuera del navegador, además es un lenguaje de programación basada en prototipos, multiparadigma, de un solo hilo, dinámico, con soporte para programación dirigida a objetos, imperativa y declarativa (MDN, 2022). Se utiliza este lenguaje puesto que el objetivo es crear una aplicación web dinámica y no sólo una página web estática. Para el desarrollo de la aplicación se usa la versión ES2022. Lenguaje de Marcado de Hipertexto (HTML). es el componente más básico de la Web. Define el significado y la estructura del contenido web. Además de HTML, generalmente se utilizan otras tecnologías para describir la apariencia/presentación de una página web o la funcionalidad/comportamiento (MDN, 2022). Si bien la mayor parte de la página web está desarrollada con el framework React, cabe mencionar a HTML, puesto que todas las páginas se renderizan y se convierten en HTML para que los navegadores puedan entender dichas páginas y así ser presentadas al usuario. Para el desarrollo de la aplicación se usa la versión HTML5. React. Es una librería de JavaScript para desarrollar interfaces de cliente (Meta, 2022). Como se mencionó previamente, este framework se utiliza principalmente para crear las interfaces de usuario y hacer que estas sean interactivas, es decir, que no se limiten únicamente a mostrar información, sino que el usuario pueda interactuar con ellas de forma sencilla mediante vistas atractivas y fáciles de usar y entender. Para el desarrollo de la aplicación se usa la versión 18.2.0. 74 Styled-components. Son primitivas visuales para los componentes de la aplicación web. Usa las versiones de (Ecmascript) ES6 y (Hojas de estilo en cascada) CSS para diseñar las aplicaciones (Maddern, Stoiber, Pluckthun, Jacobs, & Contributors, 2016). Esta librería de React sirve para poder dar estilos a los componentes propios que se van creando y de esta forma dar un mejor apartado visual a la aplicación web y que el usuario vea una interfaz más amigable y con la cual pueda interactuar sin mayor dificultad. Material UI (MUI). Es un grupo integral de herramientas de interfaz de cliente para mandar novedosas funcionalidades de forma más veloz. También es considerada una librería de elementos enteramente cargada (Material UI SAS, 1998). Esta librería se utiliza para evitar perder tiempo creando componentes ya existentes, por lo tanto, esta librería ahorra tiempo de programación y sirve para agilizar el desarrollo. Para el desarrollo de la aplicación se usa la versión Material UI V5. Servicio de alojamiento en la nube PythonAnywhere. Sirve para alojar, ejecutar y programar Python en la nube (Anaconda, 2011). Se ocupa este servicio dado que es gratuito y como se mencionó anteriormente viene incluida con una BD gratuita que es MySQL, además al desarrollar el API Rest en el lenguaje de programación Python es ideal para poder subir la aplicación, dado que este servicio de alojamiento cuenta con una terminal de comandos en donde se puede instalar librerías necesarias para hacer correr la aplicación. Vercel. Es la plataforma para desarrolladores frontend, que ofrece la rapidez y la fiabilidad que los desarrolladores requieren para subir aplicaciones web (Vercel Inc, 2001). Se ocupa este alojamiento dado que, es gratuito y además su configuración para subirlo a la nube es realmente fácil y sencillo de llevar a cabo, en adición como se realiza cambios constantes en el código, y el servicio de alojamiento en la nube debe estar actualizado con la última versión 75 del código fuente que se tenga, Vercel lo facilita y no es muy complicado de mantenerlo actualizado con la última versión subida a GitHub. Sistema de control de versiones GitHub. Permite administrar repositorios de código, los cuales pueden ser públicos o privados (GitHub, 2008). Para tener una mejor organización en el código se crea dos repositorios diferentes, uno para el desarrollo del Backend con la conexión a la base de datos y el otro para el desarrollo del Frontend para programar las interfaces gráficas del usuario y el consumo del API Rest del Backend. Para almacenar el código de la aplicación se usa la versión 3.7.0. Arquitectura Para el desarrollo de la aplicación se lo hizo bajo la Arquitectura en Capas, la cual consta en dividir el sistema a desarrollar en diferentes capas, a fin de que cada una tenga un papel bastante determinado, como puede ser, una capa de presentación (UI), una capa de normas de comercio (servicios) y una capa de ingreso a datos (DAO), no obstante, este estilo arquitectónico no define cuantas capas debería de tener la aplicación, sino más bien, se enfoca en la división de la aplicación (Blancarte, 2020). En la práctica, la mayor parte de las veces este estilo arquitectónico es implementado en 4 capas (Ver Figura 17), presentación, negocio, persistencia y base de datos, no obstante, es usual ver que la capa de negocio y persistencia se combinan en una solo capa, más que nada una vez que la lógica de persistencia está incrustada en dicha capa (Blancarte, 2020). Sin embargo, como se mencionó previamente, no existe ni un mínimo y máximo de capas que se deban realizar, razón por la cual, este estilo arquitectónico se adapta a las necesidades de los desarrolladores ya que pueden usar diferentes capaz según crean conveniente y no se pierda la esencia de dicha arquitectura. 76 Figura 17. Arquitectura en capas Arquitectura en capas Nota. La figura 17 muestra la clásica implementación de la arquitectura en capas. Adaptado de Arquitectura en Capas. 2020, por Blancarte. Cabe destacar que, en una arquitectura en capas, cada una de las capas se colocan de manera horizontal, de tal forma que cada capa solo puede comunicarse con la capa que está rápidamente por abajo, por lo cual, si una capa desea comunicarse con otras que permanecen muchísimo más debajo, van a tener que realizarlo por medio de la capa que está rápidamente por abajo (Blancarte, 2020). 77 Figura 18. Comunicación entre capas Comunicación entre capas Nota. La figura 18 muestra la forma en la que se comunican las diferentes capas de la aplicación. Adaptado de Arquitectura en Capas. 2020, por Blancarte. Una vez conocido la arquitectura empleada en la aplicación, es momento de mostrar cómo se integran y cómo se ubican cada uno de los materiales mencionados en las diferentes capas de esta arquitectura. Cabe mencionar que la elección de esta arquitectura fue en gran medida a que se optó por desarrollar una aplicación web y el modelo se acoplaba a las necesidades de la aplicación a desarrollar. Figura 19. Diagrama de arquitectura de la aplicación web Diagrama de arquitectura de la aplicación web 78 Nota. La Figura 19 representa el modelo de arquitectura usado en la aplicación. Como se puede observar la Figura 19 es un poco distinta al modelo tradicional de arquitectura de capas, sin embargo, como se mencionó anteriormente, la esencia de la arquitectura se mantiene y se tiene dos servicios distintos colocados en servidores de alojamiento en la nube, como ya se mencionó en la sección de materiales dicho alojamientos son Vercel y PythonAnywhere para el Frontend y Backend respectivamente. 79 Ahora bien, como se puede ver en la Figura 19 todo empieza por la solicitud que puede ser GET (recoger uno o más datos), POST (crear un nuevo dato), PUT (actualizar un dato) o DELETE (borrar un dato), en donde los estudiantes pueden acceder a la aplicación mediante el protocolo HTTP, una vez que haya accedido a la aplicación se realiza una petición de algún recurso y es ahí en donde mediante la librería CORS pueden obtener el permiso para entrar y obtener lo que hayan solicitado, pero antes de eso la solicitud pasa a través de la capa de negocio en donde, por ejemplo, si un estudiante quiere crearse una cuenta para poder acceder a la aplicación web, es necesario acceder al endpoint de registrar, el cual se encuentra en la capa anteriormente mencionada. Si no hubo algún problema, se puede acceder a la capa de persistencia y a través del ORM SQLAlchemy transforma la solicitud de lenguaje Python en lenguaje SQL para poder acceder a la última capa que es la de la base de datos, en donde puede realizar distintas instrucciones DML (Data Manipulation Language) que se pueden definir en su mayoría como un CRUD (Create - INSERT, Read - SELECT, Update - UPDATE, Delete - DELETE) para que dependiente de la acción realizada pueda obtener la respuesta deseada, es decir, ya sea un código 200 (Todo ha salido bien), un código 404 (No se ha encontrado) o incluso un código 500 (Error en el servidor), entre otros. Luego, la información solicitada es devuelta al usuario para que pueda interactuar con la aplicación a su gusto y en caso de haber errores, que estos sean lo más claro posibles para que el usuario esté tranquilo y sepa cómo reaccionar y solucionar (si fuera el caso) el problema ocurrido durante su petición. Diagrama de Entrada, Proceso y Salida (EPS) El diagrama EPS es un diagrama de flujo donde se observa la entrada, el proceso y la salida de una cierta operación, todas las etapas tienen una funcionalidad (Corporación ADSI SENA, 2014): 80 i) Entrada: se apoya en todos los datos que se hallan accesibles para procesar la información. ii) Proceso: se apoya en cada una de las operaciones que se tienen que hacer para obtener los resultados esperados o para resolver el problema que se ha propuesto. iii) Salida: esta parte hace referencia al resultado obtenido o la solución al problema. Figura 20. Diagrama EPS Diagrama EPS Nota. La Figura 20 muestra la conexión entre la Entrada, Proceso y Salida con su respectiva retroalimentación de un contexto específico. Adaptado de ¿Qué es un diagrama de entrada- proceso-salida?, por Corporación ADSI SENA, 2014, Blogspot. Diagrama EPS a nivel macro En base a la Figura 20 se elabora el diagrama EPS de toda la aplicación web realizada, con el objetivo de conocer cuáles son las entradas que tiene la aplicación, cuál es el proceso que realiza con ellas, cuáles son las diferentes salidas que se obtiene y finalmente conocer cómo se retroalimenta a la entrada inicial que se tuvo. Figura 21. Diagrama EPS de toda la aplicación web 81 Diagrama EPS de toda la aplicación web Nota. La Figura 21 muestra el diagrama EPS de toda la aplicación web desarrollada. Como se observa en la Figura 21 se tiene 4 diferentes entradas que son los usuarios, los perfiles de proyecto, las versiones y las HU, toda esta información es procesada mediante CRUDs y reglas de negocio individuales como puede ser validar usuario, generar días y horas de trabajo por cada HU realizada en base a la duración del sprint, entre otras. Una vez que se tenga toda esta información se pueden obtener las distintas salidas mencionadas. Para el calendario de actividades, es necesario conocer los usuarios que van a realizar las HU, en qué perfil de proyecto y con qué versión van a trabajar para poder tener calendarizado las actividades y el tiempo máximo de entrega, cabe destacar que este calendario será accesible por todos los usuarios de la aplicación, tanto del líder del proyecto como de los demás miembros del equipo. Para la segunda salida que es el backlog, es necesario saber el total de las HU y los usuarios que están trabajando en cada una de ellas ya que, el backlog va de la mano con la tercera salida que es el cálculo de las horas estimadas y reales trabajadas por día, y es de vital 82 importancia conocer esta información, sin olvidar mencionar que a estos datos únicamente podrá acceder el líder del proyecto puesto que, será el encargado de verificar el número de horas trabajadas de cada integrante del equipo para poder obtener datos verídicos y evitar que los miembros del equipo alteren información valiosa. Finalmente, como retroalimentación para las futuras entradas serán las cuatro que se puede observar en la Figura 21. La primera consiste en conocer cuántas HU han sido completadas con éxito, esto gracias a que cada HU va a tener un status y únicamente se analizará aquellas que estén terminadas, por lo tanto, si existen HU que no tengan este status se debe conocer el programador responsable y preguntarle que ha sucedido con dicha HU y volver a ser asignada en una segunda versión del mismo perfil del proyecto. La segunda retroalimentación consiste en saber si el perfil del proyecto ha sido cambiado a baja escala, por ejemplo, si tuvo un pequeño cambio en las ideas a defender o en el alcance, si es así únicamente se debe realizar una actualización, pero si el perfil del proyecto tuvo un cambio drástico, por ejemplo, cambia totalmente el alcance, los objetivos, entre otros, se debe generar otro perfil de proyecto. En referencia a la tercera, esta sirve para conocer si todas las HU han sido completadas con éxito y si no existe ninguna otra se daría por terminado el perfil del proyecto, caso contrario se debe crear nuevas versiones con las HU que no se han podido completar por diferentes motivos y con nuevas que se han identificado la cual tiene una relación con la cuarta retroalimentación. Si bien tanto el perfil del proyecto como el de las versiones es información realmente importante, su uso se limita a lo anteriormente mencionado y no existe algún otro tipo de salida que pueda obtener, a diferencia de los usuarios y las HU las cuales si son analizadas 83 individualmente en un nivel micro se puede obtener otras salidas las cuales se pueden observar a continuación. Diagramas EPS a nivel micro Diagrama EPS de los usuarios. Dado que los usuarios son la parte fundamental de esta aplicación web y en general de cualquiera aplicación, se empieza por detallar el diagrama EPS de esta entidad para conocer que otras salidas e importancia tienen además de lo ya mencionado en el nivel macro. Figura 22. Diagrama EPS de usuarios Diagrama EPS de usuarios Nota. La Figura 22 muestra el diagrama EPS únicamente de los usuarios Como se puede observar en la Figura 22, se recibe dos datos como entrada que son la contraseña y el correo electrónico, estos datos van a servir para poder realizar el registro del usuario para ser almacenado en la BD y el otro proceso sería la validación, para saber si las credenciales ingresadas son iguales a las almacenadas en la BD y que de esta forma puede ser autenticado y tenga acceso a la aplicación web. 84 En cuanto a las salidas existen dos principalmente, la primera consiste en si el usuario creado va a ser el líder del perfil del proyecto tendría un rol superior en comparación a los demás y por ende tendría los accesos de editar y eliminar perfiles de proyectos, versiones e HU y acceder al backlog para registrar las horas de trabajo reales de los demás miembros del equipo de desarrollo que está gestionando. Por otro lado, si es únicamente un miembro del equipo será asignado a un perfil del proyecto en donde podrá ver la información y principalmente saber las HU asignadas para que las desarrolle en el tiempo estimado según la duración del sprint. Como retroalimentación, se puede realizar reuniones diarias (Daily Scrums) para saber cómo ha sido el desempeño de todo el equipo de trabajo, si el equipo está organizado de forma correcta, todos se encuentran trabajando en su HU asignada y esta a su vez no tiene ningún bloqueo se puede intuir que el líder del equipo está realizando un buen trabajo y por ende puede mantenerse en su mismo rol. Caso contrario si se ve que el estudiante líder está presentando problemas en gestionar el equipo se puede realizar un cambio de rol para que otra persona sea el líder y según la duración del sprint se vea los resultados y hacer esa comparación entre ambos líderes y saber si realmente fue un problema del líder al momento de gestionar el equipo de trabajo o por el contrario fue un problema en general del equipo de desarrollo que no supo cumplir con los plazos establecidos en el cronograma que se puede acceder desde la propia aplicación. Diagrama EPS de las HU. Otro aspecto importante dentro de la aplicación son las HU las cuales son de vital importancia puesto que son el resultado de la aplicación de la técnica de las 5W+2H, por lo tanto, es fundamental conocer las salidas específicas que tiene esta entidad dentro de la aplicación web. Figura 23. Diagrama EPS de HU 85 Diagrama EPS de HU Nota. La Figura 23 muestra el diagrama EPS únicamente de las HU. Como se puede observar en la Figura 23, tiene varias entradas, entre las que están los comentarios, las 5 preguntas W (What, Where, When, Who y Why) y las 2 preguntas H (How much, How), la prioridad, las pruebas de cómo se va a verificar si se cumplió con las expectativas, el status y el nombre de la HU. Una vez se tenga todos estos datos, se puede procesarlos para consultar una HU, crear una nueva, editar o inclusive borrar dependiendo de lo que se desee realizar dentro de la aplicación. En referencia a las salidas se tiene dos posibles situaciones, la primera es poder ver desde la aplicación web la HU con un formato para que sea más agradable a la vista y que resuma ficha de la HU. Y como segunda salida se tiene la posibilidad de exportar una o varias HU a PDF para poder almacenarlas en nuestra computadora creando un respaldo para no tenerlas únicamente en la aplicación web. Como retroalimentación se puede saber si el programador asignado ha cumplido con la HU en el tiempo establecido y conocer si se logra lo que realmente se esperaba, si este fuera el 86 caso la HU se daría por terminado y podría trabajar en una nueva, sin embargo, si por algún motivo el estudiante no ha podido cumplir con lo deseado en el tiempo establecido se puede indagar al programador responsable de por qué no lo ha terminado para saber si pueden conseguir alguna ayuda o identificar si existe algún problema. Además, como segunda y tercera retroalimentación se tiene que cada HU se puede almacenar por versiones, lo cual va a permitir analizar si el tiempo de entrega del proyecto se va a ver afectado, puesto que, si existen varias HU que no han podido ser terminadas con éxito, lo más probable es que el tiempo de entrega del proyecto se demore más de lo planificado, y si son pocas HU las que se han visto retrasadas, se tendría que hacer un esfuerzo para poder cumplir con el trabajo que ha quedado pendiente en un nuevo sprint. Implementación Modelo de datos Todo comienza con el modelado de datos que se lo realiza mediante la herramienta Power Designer, la cual se detalló en la sección de materiales. Primero fue necesario realizar el modelo conceptual (CDM) el cual sirve para identificar las interacciones de máximo grado entre las diversas entidades (Tecnologías Información, 2019). A continuación, se presenta el modelo realizado que sirve como primer paso para elaborar la BD. Figura 24. Modelo de datos conceptual (CDM) Modelo de datos conceptual (CDM) 87 Nota. La Figura 24 muestra el CDM de la BD. Una vez obtenido el CDM mediante el uso de la herramienta Power Designer se puede generar de forma automática el modelo lógico (LDM) el cual sirve para explicar los datos con el más grande detalle posible, independientemente de cómo se implementa físicamente en la BD (Tecnologías Información, 2019). A continuación, se presenta el modelo obtenido en base a la Figura 24. Figura 25. Modelo de datos lógico (LDM) Modelo de datos lógico (LDM) 88 Nota. La Figura 25 muestra el LDM generado a partir de la Figura 24 Finalmente, cuando se haya obtenido tanto el CDM y el LDM se puede generar el modelo físico de datos (PDM) el cual representa cómo se construye el modelo en la base de datos (Tecnologías Información, 2019). A continuación, se presenta el modelo obtenido. Figura 26. Modelo físico de datos (PDM) Modelo físico de datos (PDM) 89 Nota. La Figura 26 muestra el PDM que sirve para generar la BD. Una vez obtenido el modelo físico de datos, se puede generar el script para obtener las tablas con todos los atributos que contiene la BD, es decir, la herramienta Power Designer genera lo que en inglés se conoce como el Data Definition Language (DDL). Cabe mencionar que los tres modelos tanto el CDM, LDM y PDM se generaron en inglés, puesto que es una buena práctica trabajar en este idioma porque es el idioma universal. Tabla Usuario. Esta tabla sirve para almacenar el correo y contraseña de los usuarios que se vayan a registrar en la aplicación. Tabla Perfil de Proyecto. Esta tabla va a contener la información resumida de los perfiles de proyectos de cada estudiante, un punto a destacar son los miembros, debido a que 90 únicamente el líder del equipo de trabajo va a tener acceso a funcionalidades extras como edición, borrado y acceso al Product Backlog, mientras que, los demás van a poder acceder a la información de cada HU y poder ver mediante un calendario hasta qué fecha tienen plazo de terminar el desarrollo de dicho requerimiento. Tabla Versión. Esta tabla sirve para almacenar las versiones de cada perfil del proyecto, un punto importante, es la duración del sprint que va a contener dicha versión, debido a que, la metodología Scrum recomienda tener un máximo de 4 semanas de sprint y dentro de el tiempo establecido se debe terminar con lo solicitado. Una vez terminado el tiempo del sprint, se procede a crear otra versión con igual, menor o mayor tiempo al sprint definido anteriormente. Tabla HU. Esta tabla va a contener toda la información necesaria para elaborar la HU en base a las preguntas de la técnica de las 5W+2H. Además, cabe mencionar que es de las tablas más importantes del sistema, debido a que almacena toda la información que se requiere y con la cual se va a poder obtener algunas de las salidas más importantes ya expuestas en el Diagrama EPS a nivel macro. Tabla Trabajo del Proyecto. Esta tabla sirve para almacenar la información de las horas reales trabajas por día, cabe destacar que esta funcionalidad se encuentra dentro del Product Backlog, por lo tanto, sólo tendrá acceso el líder quien se encarga de gestionar a todo el equipo de desarrollo. Además, se puso el nombre en base al gráfico que se obtiene llamado Burndown Chart, el cual es un diagrama de la representación gráfica del trabajo por hacer. Base de datos En base al script generado, se accede al servicio en la nube PythonAnywhere para acceder a la BD MySQL, puesto que, como se mencionó, este servicio de alojamiento contiene la BD en la nube para poder accederla de cualquier lugar y no únicamente de forma local, ya 91 que, provee de forma gratuita la dirección de host de la BD. Por lo que sólo fue necesario crear el nombre de la BD, la cual se denominó como user-stories, y también crear una contraseña, para el administrador de la BD conocido como DBA. Con la BD creada en la nube, únicamente se selecciona todo el script que genera la herramienta Power Designer para tener la misma estructura de tablas, propiedades y relaciones con el objetivo de tener lista la BD y poder empezar a almacenar los datos de los usuarios, perfiles de proyecto, versiones, HU y el trabajo realizado. Backend Finalmente, para el desarrollo de los servicios API REST que va a consumir la aplicación web desde el frontend, se implementar el backend el cual va a contener los modelos de las tablas de la BD, con el objetivo de poder establecer rutas (endpoints) y poder realizar distintas operaciones como GET, POST, PUT o DELETE, accediendo a la BD para hacer consultas, creaciones, ediciones o eliminaciones de los datos que se encuentran almacenados. Por lo tanto, el código fue desarrollado en el IDE VS Code, y se optó por una estructura de carpetas propia de los proyectos de Python, es decir, una carpeta para los modelos, otra para las rutas y finalmente una para los métodos específicos como obtener la fecha actual, obtener el rango de semanas del sprint para las horas de trabajo, entre otras. Luego se hace uso de las herramientas ya mencionadas en la sección de Backend para implementar los servicios API REST y una vez haya sido codificado, se procede a acceder al servicio de alojamiento en la nube Python Anywhere para subir todo el proyecto, cabe mencionar que se debe realizar algunas configuraciones extras para que el proyecto corra sin mayor problema. Entre las configuraciones principales se tiene que crear un ambiente virtual, dado que se hace uso de librerías que no vienen instaladas por defecto en PythonAnywhere, por lo tanto, se debe generar un archivo de requerimientos el mismo que servirá para instalar dichas 92 librerías y que la aplicación pueda funcionar sin mayor problema. De esta forma, estaría levantada tanto la BD como los servicios de la API REST en la nube y listos para ser consumidos por los usuarios a través del frontend. Frontend Para el desarrollo del frontend del aplicativo web se hizo uso de la aplicación de una Arquitectura Limpia enfocada a React (Vasconcelos, 2022). De esta manera, nos aseguramos el orden correcto en la división de carpetas según las funcionalidades que contiene la aplicación tal como se muestra en la figura 27. De igual manera, se aplicó la implementación de funciones y componentes en la capa correspondiente y se realizó la conexión en una capa de presentación que une las diferentes funcionalidades que permite que todas las solicitudes al backend funcionen de la manera esperada. Figura 27 Estructura de carpetas de la aplicación frontend Estructura de carpetas de la aplicación frontend 93 Nota. La Figura 27 muestra la composición de la aplicación web cliente donde se encuentran los archivos necesarios y ordenados para el funcionamiento de la aplicación. Como bien se mencionó en las herramientas, se utilizó styled-components para dar estilos a los componentes. Esta herramienta fue de gran ayuda ya que nos permite crear componentes separados estilizados y en la estructura de carpetas, se ha creado para cada característica, un archivo que contiene los componentes estilizados que se harán uso a posterior mediante importaciones. El uso de Material UI como kit de interfaces de usuario, fue de gran ayuda para contar con componentes ya realizados que facilita el trabajo de crear componentes desde cero. Además, nos permite estilizar de manera responsive y crear un tema de estilos que puede variar según la paleta de colores a elegir. 94 A continuación, se visualizará las diferentes rutas que contiene la aplicación. Inicio de sesión y registro de usuarios. Contiene las características principales de autenticación y validación de usuarios. Además, contiene funcionalidades extras para visualizar la contraseña digitada, validación de contraseña fuerte, validación de usuarios existentes, entre otros. Figura 28 Pantallas de inicio de sesión y registro. Pantallas de inicio de sesión y registro. Nota. La Figura 28 muestra las rutas /login, /registros, que proveen los servicios de autenticación de usuarios para acceder a la aplicación. 95 Perfiles de proyectos. Contiene una tabla dinámica extensible para hacer el CRUD de perfiles de proyectos y versiones, mostrar versiones para cada perfil de proyecto y navegar a sus versiones. Figura 29 Pantalla de perfiles de proyectos Pantalla de perfiles de proyectos Nota. La Figura 29 muestra la ruta /perfiles-proyectos, que proveen al usuario la gestión de perfiles de proyecto y sus versiones. Matriz de identificación de requisitos funcionales. Contiene una tabla dinámica y extensible que permite hacer el CRUD, buscar y generar historias de usuario. En esta tabla nos encargamos de escribir la historia de usuario basándonos en la técnica de las 5W+2H. Figura 30 Pantalla de matriz de identificación de requisitos funcionales Pantalla de matriz de identificación de requisitos funcionales 96 Nota. La Figura 30 muestra la ruta /uh-matriz en donde encontramos la gestión de requisitos funcionales a través de historias de usuario basadas en la técnica de las 5W+2H. Reporte de historias de usuario. Contiene un gráfico en forma de tabla que resume la información de cada historia de usuario escrita. En este apartado se puede exportar una o todas las historias de usuario en un documento PDF. Figura 31 Pantalla de reporte de historias de usuario Pantalla de reporte de historias de usuario 97 Nota. La Figura 31 muestra la ruta /uh-reporte, en donde encontramos la historia de usuario resumida y exportable a documento PDF. Calendario. Contiene un calendario en el que se encuentran los requisitos funcionales asociados a la última versión de al perfil de proyecto seleccionado. En esta pantalla se puede navegar a las historias de usuario de una manera directa. Figura 32 Pantalla de Calendario Pantalla de Calendario 98 Nota. La Figura 32 muestra la ruta /calendario que contiene los requisitos funcionales digitados asociados a su fecha de creación y fecha de entrega. Backlog. Contiene un backlog editable asociado a las historias de usuario de un perfil de proyecto seleccionado. Esta pantalla solo es accesible al líder del perfil de proyecto y podrá gestionar el tiempo que se ha tomado cada colaborador para realizar una tarea del requisito asignado, tal como se muestra en la figura 33. De igual manera se muestra un gráfico de líneas que permite visualizar las horas estimadas vs las horas estimadas restantes del proyecto tal como se muestra en la figura 34. Figura 33 Pantalla de Backlog Pantalla de Backlog 99 Nota. La Figura 33 muestra la ruta /backlog, en la que el líder de proyecto puede gestionar el tiempo que toma realizar los requisitos y el tiempo estimado calculado. Figura 34 Gráfico de líneas horas estimadas vs horas estimadas restantes Gráfico de líneas horas estimadas vs horas estimadas restantes 100 Nota. La Figura 34 muestra el gráfico de líneas calculado entre las horas estimadas y las horas estimadas restantes. El líder del perfil de proyecto puede visualizar datos del tiempo que le está tomando realizar una tarea y el tiempo estimado calculado. Ajustes. Contiene configuraciones, en esta sección el usuario es capaz de seleccionar una foto de perfil, actualizar nombres y apellidos y cambiar la contraseña en caso de olvido. Figura 35 Pantalla de Ajustes Pantalla de Ajustes Nota. La Figura 35 muestra la ruta /ajustes, la cual permite al usuario realizar configuraciones de su usuario de acuerdo a lo requerido. Ayuda. Contiene información general del aplicativo web. Es una guía para el usuario que facilita el uso de la aplicación y lo capacita para que el correcto uso de este pueda beneficiar a la creación de historias de usuario a través de la técnica de las 5W y 2H. Figura 36 Pantalla de Ayuda Pantalla de Ayuda 101 Nota. La Figura 36 muestra la ruta /ayuda, que provee al usuario una guía general para el uso del aplicativo web. Requisitos no funcionales. Contiene una guía de métricas y submétricas detalladas para abstraer requisitos no funcionales basados en la ISO 25010 - ISO/IEC 25000. Esta página será de gran ayuda para el usuario al momento de verificar aquellos requisitos no funcionales que se cumpa o no en un proyecto. Figura 37 Pantalla de Requisitos no funcionales Pantalla de Requisitos no funcionales 102 Nota. La Figura 37 muestra la ruta /requisitos-nf, que provee al usuario una guía general de métricas para elaborar requisitos no funcionales. 103 Capítulo IV Diseño de la evaluación El diseño de la evaluación se enfoca en dos escenarios principales, el primero que es la auditoría de la aplicación web desarrollada y el segundo es la demostración de la aplicación a los estudiantes de las carreras del DCCO. Cabe destacar que estos dos escenarios son fundamentales puesto que permite conocer cómo fue el desarrollo de la aplicación web (si mantiene buenos estándares) y también conocer acerca de su funcionalidad, puesto que si los estudiantes no tienen problemas para manejar la aplicación e incluso ven una mejoría notable con respecto al método tradicional o manual, se puede apreciar que realmente se está proporcionando una aplicación de valor a los estudiantes que les permita entender de mejor manera cómo se aplica la técnica de las 5W+2H dentro de una metodología ágil como Scrum para realizar las HU. Auditoría de la aplicación web La auditoría de la aplicación web se va a realizar a través de la herramienta Lighthouse. Esta es una herramienta potente y útil para realizar auditorías de aplicaciones web, y proporciona información valiosa sobre el rendimiento, la accesibilidad, las mejores prácticas y el SEO de la aplicación web, en este caso, se omitirá la auditoría de SEO debido a que será un aplicativo web interno de la universidad y no se requiere su optimización en el motor de búsquedas. En general, la herramienta Lighthouse nos ayuda a identificar áreas específicas en las que podíamos optimizar la aplicación y mejorar la experiencia del usuario. Siguiendo las recomendaciones proporcionadas por la herramienta, nos aseguramos que la aplicación web sea rápida, accesible, esté bien diseñada y los usuarios puedan encontrarla fácilmente. Funcionalidad de la aplicación web Para evaluar la funcionalidad de la aplicación web se planea realizar dos encuestas mediante preguntas claves para inquirir a los estudiantes acerca de qué tal les pareció la 104 aplicación web y otros aspectos relacionados. La primera encuesta va a ser aplicada a un curso de la carrera de Software pertenecientes a la Unidad Profesional y a un cursos de ITIN pertenecientes a la Unidad Básica o Inicial, esto con el objetivo de tener una muestra de los estudiantes de la carrera del DCCO, porque de esta forma se puede obtener una retroalimentación por parte de los estudiantes quienes son los usuarios reales de la aplicación, además también se puede evaluar cuál fue el rendimiento de la aplicación con n usuarios en tiempo real (esto es un dato importante puesto que, se trabaja con servicios de alojamiento en la nube gratuitos y la concurrencia de usuarios no está garantizada). Y la segunda encuesta será aplicada únicamente al curso de Software para obtener los datos más reales, debido a que, son los estudiantes que tienen mayor conocimiento de Ingeniería de Requerimientos y han trabajado con la matriz de las 5W+2H. Cabe destacar que con los datos recopilados de los cursos a los que se aplique la encuesta se va a realizar una comparación y contrastación de los datos, y de esta manera obtener resultados acerca de si la aplicación fue de ayuda en comparación a métodos tradicionales o herramientas manuales. Escenarios Auditoría de la aplicación web Para la auditoría de la aplicación web se llevará a cabo una revisión exhaustiva de la aplicación web mediante la evaluación de métricas proporcionándonos información detallada sobre las áreas de mejora y las oportunidades para aumentar la calidad y el rendimiento de la aplicación. Cabe mencionar que cada actividad del escenario, será una auditoría diferente. Al llevar a cabo este escenario de evaluación, se puede recopilar valiosos datos y perspectivas que ayudarán a comprender los puntos fuertes y débiles de la aplicación web e identificar oportunidades de mejora. Esto proporcionará una base sólida para las conclusiones y recomendaciones del proyecto de tesis. 105 Funcionalidad de la aplicación web En referencia a los escenarios de la funcionalidad de la aplicación web, se van a realizar encuestas para recopilar las principales opiniones de los estudiantes acerca del funcionamiento de la aplicación web, cada escenario se puede ver detallado en la Tabla 10. Tabla 10 Descripción de escenarios propuestos Descripción de escenarios propuestos No. Escenario Sesión Actividad Descripción Objetivo Auditoría de Aplicación Web 1 Auditoría de Rendimiento Evaluar el rendimiento de la aplicación web, incluyendo métricas como First Contentful Paint (FCP) y Time to Interactive (TTI). Identificar oportunidades para mejorar el rendimiento de la aplicación y la experiencia del usuario. 2 Auditoría de Accesibilidad Evaluar la accesibilidad de la aplicación web, incluido su cumplimiento de las Pautas de Accesibilidad al Contenido en la Web (WCAG) Identificar oportunidades para mejorar la accesibilidad de la aplicación y el cumplimiento de las normas del sector. 106 No. Escenario Sesión Actividad Descripción Objetivo 3 Auditoría de Buenas Prácticas Evaluar las mejores prácticas de la aplicación web, como el uso de HTTPS, el almacenamiento en caché y la minificación. Identificar oportunidades para mejorar la seguridad y el rendimiento de la aplicación. Funcionalidad de Aplicación Web 1 Encuesta dirigida a estudiantes de las carreras de Software e ITIN Los estudiantes van a probar la aplicación web, creando un usuario para poder acceder a la aplicación. Conocer la percepción de los estudiantes acerca de la aplicación web para saber si les parece excelente o al contrario les parece regular. Los estudiantes en base al uso de la aplicación web, van a conocer si la automatización de la matriz les parece de utilidad para identificar requisitos funcionales Conocer si a los estudiantes les parece útil la aplicación para identificar los requisitos funcionales. 107 No. Escenario Sesión Actividad Descripción Objetivo Los estudiantes en base a su experiencia deberán responder el tiempo en el que se demoraban en realizar este proceso con la matriz manual en Excel Conocer el tiempo de elaboración de las HU de forma manual con la matriz de Excel. Una vez que los estudiantes hayan probado la aplicación web y hayan creado HU, se debe conocer el tiempo en el que se demoraron en realizarlas. Conocer el tiempo en el que los estudiantes se demoran en realizar las HU con la aplicación web para comparar con el tiempo anterior de la forma manual y conocer si realmente existe una optimización en el desarrollo de HU. En base a la aplicación web, los estudiantes deben evaluar la navegabilidad de la aplicación para acceder nuevamente a los requisitos ingresados. Conocer la facilidad de uso de la aplicación para que los estudiantes accedan rápidamente a los requisitos y no pierdan tiempo buscándolos. 108 No. Escenario Sesión Actividad Descripción Objetivo Funcionalidad de Aplicación Web 2 Encuesta dirigida a estudiantes de la carrera de Software En base a la aplicación web y el proceso tradicional de Ingeniería de Requisitos los estudiantes deben seleccionar cuál de los dos procesos prefieren Conocer si los estudiantes prefieren la aplicación web sobre el proceso tradicional de Ingeniería de Requisitos En base a la aplicación web, los estudiantes deben valorar que tan importante es la información que se puede observar en la sección No funcionalidad Conocer que tan importante es la información proporcionada acerca de la No Funcionalidad dentro de la aplicación web Los estudiantes deben seleccionar una de las dos formas de identificar requisitos funcionales Conocer si la aplicación web desarrollada fue de utilidad para los estudiantes y determinar si se cumple la hipótesis planteada Nota. La Tabla 10 muestra la descripción de los escenarios propuestos y el detalle de la descripción y objetivo que se espera para cada actividad. 109 Métricas Auditoría de la aplicación web Rendimiento. El rendimiento es una métrica común que se utiliza para evaluar la calidad y el rendimiento de diversos sistemas y aplicaciones. En el contexto de las aplicaciones web, el rendimiento se utiliza normalmente para referirse a la velocidad y capacidad de respuesta de la aplicación, y lo bien que es capaz de manejar diferentes cargas de trabajo y peticiones de los usuarios. Existen métricas de rendimiento que serán evaluadas, tal como se muestra en la tabla 11. Tabla 11 Métricas de Rendimiento Métricas de Rendimiento Métrica Descripción Valor adecuado First Contentful Paint (FCP). Tiempo que tarda una página web en mostrar el primer contenido en pantalla. Menos de 1,0 segundos. Time to Interactive (TTI). Tiempo que tarda una página web en ser totalmente interactiva. Menos de 5,0 segundos. Speed Index Tiempo promedio que tarda el contenido de la página en ser visible en la pantalla. Menos de 3,0 segundos. Total Blocking Time (TBT) Tiempo que tarda la página en responder a la entrada del usuario. Menos de 200 milisegundos. Renderizado del mayor elemento con contenido (LCP) Tiempo que tarda el elemento más pesado en cargarse y mostrarse en la pantalla Menos de 1,5 segundos. 110 Métrica Descripción Valor adecuado Cumulative Layout Shift Desplazamiento o cambio en la disposición de los elementos de una página web mientras se carga Menos de 0,1. Nota. La Tabla 11 muestra la descripción y el valor de tiempo adecuado para cada métrica de rendimiento en aplicaciones web. Accesibilidad. A continuación, la auditoría de accesibilidad evaluará la aplicación web desde la perspectiva de los usuarios con discapacidad y ofrecerá recomendaciones para hacerla más accesible. Esto puede incluir añadir texto alternativo a las imágenes, utilizar jerarquías de encabezados adecuadas y garantizar que la aplicación pueda navegarse con un teclado. Existen métricas que son comúnmente usadas para evaluar la accesibilidad, las cuales se detallan en la tabla 12. Tabla 12 Métricas de Accesibilidad Métricas de Accesibilidad Métrica Descripción Valor adecuado Conformidad con las WCAG. Grado de conformidad de la página web con las Pautas de Accesibilidad al Contenido en la Web (WCAG). WCAG 2.1 Nivel AA. Accesibilidad de los componentes. Porcentaje de componentes accesibles para los usuarios con discapacidades. 100% Problemas de accesibilidad. Número y tipo de problemas de accesibilidad detectados durante la auditoría. 0 problemas. 111 Nota. La Tabla 12 muestra la descripción y el valor adecuado para cada métrica de accesibilidad en aplicaciones web. Buenas Prácticas. La auditoría de buenas prácticas evaluará la aplicación web con respecto a las normas y buenas prácticas del sector, y ofrecerá sugerencias para mejorar su diseño y funcionalidad general. De esta manera garantizamos que la aplicación sea compatible con dispositivos móviles, que utilice tecnologías seguras y actualizadas, y que siga patrones y convenciones de diseño establecidos. Existen métricas que son comúnmente usadas para evaluar la accesibilidad, las cuales se detallan en la tabla 13. Tabla 13 Métricas de Buenas Prácticas Métricas de Buenas Prácticas Métrica Descripción Valor adecuado Uso de HTTPS. Medida en que la página web utiliza conexiones HTTPS seguras. 100% Uso de manifiesto de aplicación web. Presencia de un archivo de manifiesto de aplicación web que define la apariencia y el comportamiento de la aplicación. Sí. Uso de service workers. Presencia de un service worker que permite la funcionalidad offline y mejora el rendimiento. No. Uso de presupuestos de rendimiento. Uso de presupuestos de rendimiento para limitar el tamaño y el número de activos que se cargan en la página. Sí. 112 Nota. La Tabla 13 muestra la descripción y el valor adecuado para cada métrica de buenas prácticas en aplicaciones web. Funcionalidad de la aplicación web Opinión de la aplicación. Es importante conocer la opinión de los estudiantes acerca de la aplicación web, para lo cual, deben crearse una cuenta (únicamente con el correo institucional) para poder acceder a la aplicación y poder ver de primera mano todas las funcionalidades que ofrece el aplicativo y así poder conocer una opinión real por parte de usuarios que van a usar el aplicativo, para evaluar esta métrica se tendrá en consideración 4 calificaciones cualitativas que pueden dar a la aplicación que son (de la más baja a la más alta): i) Regular ii) Bien iii) Muy bien iv) Excelente Utilidad de la aplicación en la identificación de requisitos funcionales. Es importante conocer la opinión de los estudiantes acerca de si les parece útil o no la aplicación web desarrollada para poder identificar requisitos funcionales, puesto que, si les parece inútil o incluso que causa confusión, se podría afirmar que la aplicación no está siendo de ayuda y al contrario está causando confusión y por lo tanto no se está corrigiendo ni cumpliendo el objetivo principal que es automatizar este proceso. Para saber si es de utilidad únicamente deberán responder sí o no. Tiempo de demora en elaborar las HU mediante la forma manual (matriz de Excel). Es importante saber el tiempo con el cual los estudiantes se demoran en realizar las HU en la 113 matriz manual, para responder esto, se debe garantizar que los estudiantes hayan usado previamente la matriz con el objetivo de que los estudiantes respondan con seguridad y certeza a esta pregunta. Por lo tanto, la manera de evaluar esta pregunta será a través de intervalos de tiempo que se definen a continuación (del menor tiempo a mayor tiempo): i) Menos de un minuto ii) Entre dos y cuatro minutos iii) Más de 5 minutos Tiempo de demora en elaborar las HU mediante la aplicación web. Es importante conocer el tiempo de demora de los estudiantes al momento de utilizar la aplicación web para elaborar las HU, puesto que, si se ve que realmente existe una mejora en el tiempo, se puede afirmar que la aplicación desarrollada está optimizando el tiempo de elaboración de HU y al mismo tiempo está haciendo del proceso engorroso un proceso mucho más fácil de entender, comprender y de aplicar. Al igual que la métrica anterior, la forma de evaluar será mediante la escala de tiempo definida ahí. Facilidad para devolverse a los requisitos en la aplicación. Es importante conocer que opinan los estudiantes acerca de la navegabilidad de la aplicación web y uno de los aspectos más importantes es la facilidad de la aplicación para regresar a los requisitos, dado que, es el aspecto más importante con el cual los estudiantes van a trabajar constantemente para desarrollar lo solicitado en las HU. La forma de evaluar esta métrica será mediante escalas cualitativas de dificultad que se definen a continuación (de la más difícil a la más fácil): i) Bastante difícil ii) Difícil iii) Normal iv) Muy fácil 114 Comparación en base a la experiencia en el uso de Ingeniería de Requisitos y de la aplicación web de HU/5W+2H. Es de vital importancia establecer una comparación acerca de la opinión de los estudiantes sobre que proceso les parece mejor, para lo cual se establecerá una pregunta con diferentes aspectos a evaluar que permitirán conocer cuál prefieren realizando una comparación entre la Ingeniería de Requisitos y la aplicación web, la forma de evaluar será la siguiente: i) Ágil – engorroso ii) Fácil – difícil iii) Rápido – lento iv) Todos - uno Por ejemplo, en la encuesta se va dar la opción de que el estudiante seleccione Ágil en la aplicación y engorroso en Ingeniería de Requisitos o viceversa, de esta forma, se puede conocer cual de las dos prefieren y así con cada parámetro de evaluación descrito anteriormente. Información acerca de la No Funcionalidad. Es importante conocer en qué escala la información proporcionada dentro de la aplicación web en relación a las métricas de la No Funcionalidad (obtenidas de la ISO 25010), son de relevancia para los estudiantes, para lo cual se establecen las siguientes métricas: i) Bajo ii) Medio iii) Alto iv) Muy alto Preferencia a futuro entre el proceso tradicional de la Ingeniería de Requisitos con el uso de la aplicación web HU/5W+2H. Finalmente, la última pregunta sirve para conocer si 115 los estudiantes realmente prefieren la aplicación web sobre el proceso de Ingeniería de Requisitos para la determinación de requerimientos funcionales, ya que, de esta manera se puede comprobar la hipótesis planteada anteriormente. La forma de evaluar será mediante la selección de una de las siguientes opciones: i) Aplicación web HU/5W+2H ii) Ingeniería de Requisitos. Resultados Auditoría de aplicación web Resultados de auditoría de rendimiento. En general, tras realizar la auditoría de rendimiento detallada en la tabla 14 nos encontramos con una puntuación de 94/100, las puntuaciones de las métricas están dentro del rango adecuado y nos indican que la aplicación web tiene un buen rendimiento, con interfaces de usuario rápidas y receptivas, está bien optimizada y ofrece una buena experiencia de usuario. Tabla 14 Resultados de auditoría de rendimiento Resultados de auditoría de rendimiento Métrica Puntuación Resultado First Contentful Paint (FCP). 0,4 segundos. Bueno (indica que la página mostró el primer contenido en la pantalla en menos de 1 segundo). Time to Interactive (TTI). 1,2 segundos. Bueno (indica que la página se volvió totalmente interactiva en menos de 5 segundos). Speed Index. 1,0 segundos. Bueno (indica que el tiempo medio que tardó el contenido de la página en ser visible en la pantalla fue inferior a 3 segundos). 116 Métrica Puntuación Resultado Total Blocking Time (TBT). 110 milisegundos. Bueno (indica que el contenido principal de la página era visible en la pantalla en menos de 1,5 segundos). Renderizado del mayor elemento con contenido (LCP). 1,5 segundos. Moderado (indica que el elemento con más peso de la página era visible en la pantalla en 1,5 segundos). Cumulative Layout Shift. 0.039 Bueno (indica que los elementos de la aplicación no ocasionan desplazamiento mientras se carga). Nota. La Tabla 14 muestra los resultados de la auditoría de rendimiento realizada, en donde se especifica la puntuación obtenida y la explicación del resultado. Resultados de auditoría de accesibilidad. En primer lugar, la aplicación ha sido evaluada mediante las Pautas de Accesibilidad al Contenido en la Web (WCAG) en tres niveles diferentes: A, AA y AAA, tal como se muestra en la tabla 15. En cada nivel se muestra el número de criterios, el número de criterios cumplidos y el número de criterios fallidos. Tabla 15 Resultados de auditoría de accesibilidad mediante WCAG 2.1 Resultados de auditoría de accesibilidad mediante WCAG 2.1 Nivel de WCAG Número de criterios Número de criterios de éxito Número de criterios fallidos A 12 9 3 AA 26 20 6 AAA 48 27 21 117 Nota. La Tabla 15 muestra los resultados de la auditoría de accesibilidad realizada mediante WCAG Conformance, en donde se muestra los niveles, el número de criterios por nivel y los criterios con éxito/fallidos. De esta tabla se concluye que el sitio web ha cumplido la mayoría de los criterios de los niveles A y AA, pero no ha cumplido todos los criterios del nivel AAA. Esto indica que el sitio web es accesible en general, pero puede haber algunas áreas que podrían mejorarse para que cumpla plenamente las WCAG. A continuación, se realizó la auditoría de accesibilidad de los componentes, se ha evaluado la accesibilidad de varios componentes del sitio web, como el menú de navegación, el formulario de búsqueda y los botones. Para cada componente, la auditoría ha determinado si el componente es accesible o no, tal como se muestra en la tabla 16. Tabla 16 Resultados de auditoría de accesibilidad de componentes Resultados de auditoría de accesibilidad de componentes Componente Accesibilidad Descripción Menú de navegación Aprobado El menú de navegación se sometió a pruebas de accesibilidad mediante teclado y compatibilidad con lectores de pantalla, y superó todas las pruebas. Incluye enlaces claros y descriptivos, y se puede navegar fácilmente con el teclado o con un lector de pantalla. Formulario de búsqueda Aprobado Se ha comprobado la accesibilidad mediante teclado y la compatibilidad con lectores de pantalla del formulario de búsqueda, y se han superado todas las pruebas. Incluye 118 Componente Accesibilidad Descripción instrucciones claras y concisas para los usuarios y puede rellenarse y enviarse fácilmente con el teclado o un lector de pantalla. Calendario Fallo Se ha comprobado la accesibilidad mediante teclado y la compatibilidad con lectores de pantalla del calendario, pero no se han superado una o varias pruebas. El calendario no es accesible desde el teclado y no puede ser utilizado por usuarios que dependen de un teclado o de un lector de pantalla. Tablas Fallo Se ha comprobado la accesibilidad mediante teclado y la compatibilidad con lectores de pantalla del componente de tabla, pero ha fallado una o varias pruebas. La tabla no está correctamente marcada y los usuarios que utilizan un lector de pantalla no pueden leerla con facilidad. Gráfico de líneas Aprobado Se ha comprobado la accesibilidad mediante teclado y la compatibilidad con lectores de pantalla del gráfico de líneas, y se han superado todas las pruebas. Los usuarios con deficiencias visuales pueden leer fácilmente el gráfico de líneas y navegar por él con el teclado o un lector de pantalla. Botones Aprobado Se ha comprobado la accesibilidad del teclado y la compatibilidad con lectores de pantalla de los botones, y se han superado todas las pruebas. Los botones están claramente etiquetados, son fáciles de pulsar y pueden ser 119 Componente Accesibilidad Descripción utilizados por usuarios que dependen de un teclado o de un lector de pantalla. Nota. La Tabla 16 muestra la auditoría de accesibilidad realizada por accesibilidad de componentes según las métricas de Lighthouse. Podemos deducir que el menú de navegación, el componente de tabla y los botones han superado la auditoría de accesibilidad, lo que significa que son accesibles para usuarios con discapacidad. Sin embargo, el calendario y el componente de tabla no han superado la auditoría de accesibilidad, lo que indica que puede haber algunos problemas con la forma en que están implementados que podrían afectar a su accesibilidad. Esta auditoría ayuda a identificar las áreas de la aplicación web que pueden necesitar mejoras para hacerlo más accesible a los usuarios con discapacidad. Haciendo los cambios necesarios y volviendo a probar los componentes, el sitio web puede ser más accesible y fácil de usar para todos los usuarios. Finalmente, en la tabla 17 se ha realizado un resumen de la métrica de problemas de accesibilidad detectados en la auditoría, esto con el fin de tratar de resolver estos problemas para que el sitio web sea más accesible y fácil de usar para todos los usuarios, incluidos los discapacitados. Esto ayudará a garantizar que el sitio web sea integrador y satisfaga las necesidades de una amplia gama de usuarios. Tabla 17 Resultados de auditoría de problemas de accesibilidad Resultados de auditoría de problemas de accesibilidad 120 Tipo de Problema Número de Problemas Detectados Faltan alternativas de texto 5 Contraste de color insuficiente 3 Uso incoherente del color 4 Uso incorrecto del color para transmitir información 2 Problemas de accesibilidad del teclado 7 Problemas de compatibilidad con lectores de pantalla 10 Falta de etiquetas en los formularios 4 Atributos ARIA no válidos 6 Falta de gestión del enfoque 9 Otros problemas 12 Nota. La Tabla 17 muestra los tipos de problemas y la cantidad de problemas detectados durante la auditoría de accesibilidad. Como se puede visualizar, se ha detectado un total de 46 problemas de accesibilidad en la aplicación web. Estos problemas se clasifican en diferentes categorías, como falta de alternativas de texto, contraste insuficiente de colores, problemas de accesibilidad del teclado y problemas de compatibilidad con lectores de pantalla. También se han detectado otros problemas menos comunes, como el uso incoherente del color, el uso incorrecto del color para transmitir información y la falta de etiquetas en los formularios. Resultados de auditoría de buenas prácticas. Finalmente, en la tabla 18, se realizó la auditoría de buenas prácticas para la aplicación web. La auditoría evaluó el uso de HTTPS, el manifiesto de la aplicación web, los service workers y los presupuestos de rendimiento, y 121 determinó si se superaba o no cada métrica. La tabla también incluye una explicación de por qué se aprobó o suspendió cada métrica y cómo afecta a la experiencia general del usuario. Tabla 18 Resultados de auditoría de buenas prácticas Resultados de auditoría de buenas prácticas Métrica Resultado Explicación Uso de HTTPS Aprobado La aplicación web utiliza HTTPS, que cifra toda la comunicación entre el navegador web del usuario y el sitio web. Esto protege la información sensible de ser interceptada por terceros, y ayuda a mejorar la seguridad del sitio web. También garantiza que el sitio web cumple las normas y mejores prácticas web actuales. Uso del manifiesto de aplicaciones web Aprobado La aplicación web utiliza un manifiesto de aplicaciones web, que permite ofrecer a los usuarios una experiencia coherente y fluida en distintos dispositivos. Esto facilita a los usuarios encontrar y acceder a la aplicación web sobre la marcha, y ayuda a mejorar la experiencia general del usuario. Uso de service workers Fallo El sitio web no utiliza service workers, lo que significa que puede no beneficiarse de un mejor rendimiento y capacidad de respuesta. Esto podría afectar negativamente a la experiencia del usuario, sobre todo en dispositivos móviles. 122 Métrica Resultado Explicación Uso de presupuestos de rendimiento Aprobado El sitio web utiliza presupuestos de rendimiento, que ayudan a garantizar que su rendimiento se mantiene dentro de límites aceptables. Esto ayuda a prevenir problemas como la lentitud en la carga de páginas o el uso excesivo de recursos del sistema, que pueden afectar negativamente a la experiencia del usuario. Nota. La Tabla 18 muestra la auditoría de buenas prácticas con las métricas de Lighthouse con el resultado y su explicación. La aplicación web ha superado la auditoría para tres de las cuatro métricas, pero ha suspendido la métrica "Uso de service workers". Esto indica que el sitio web no está utilizando las mejores prácticas en esta área, y puede estar perdiendo los beneficios de un mejor rendimiento y capacidad de respuesta. Al explicar por qué la aplicación web no ha superado esta métrica y cómo afecta a la experiencia del usuario, esta auditoría proporciona valiosas ideas y recomendaciones para mejorar la aplicación web. Funcionalidad de la aplicación web (Primera encuesta) Se aplica la primera encuesta para conocer la opinión de los estudiantes tanto de las carreras de Software e ITIN, para mayores detalles Ver Tabla 10, escenario de Funcionalidad de la aplicación web, sesión 1. Opinión de la aplicación. Como se puede observar en la Figura 38, la mayoría de estudiantes tanto de Software e ITIN piensan que la aplicación web desarrollada es muy buena, por lo que se intuye que gran parte de los estudiantes se sienten satisfechos con la aplicación. No obstante, existe una persona que puso regular y además existen pocas personas que pusieron que la aplicación les parece excelente, por lo tanto, para evitar que más estudiantes 123 opinen de forma negativa de la aplicación y al contrario aumentar el número de personas que les parece excelente, todavía se puede mejorar aún más la aplicación web añadiendo más funcionalidades, haciéndola más atractiva a la vista o reduciendo la complejidad para que sea más fácil de usar. Figura 38. Resultados de la opinión de la aplicación Resultados de la opinión de la aplicación Nota. La Figura 38 muestra los resultados tanto de los estudiantes de las carreras de Software e ITIN acerca la opinión de la aplicación Utilidad de la aplicación en la identificación de requisitos funcionales. Como se puede observar en la Figura 39, la mayoría de estudiantes tanto de software e ITIN piensan que la aplicación sí es de utilidad en la identificación de requisitos funcionales, sin embargo, existen 3 estudiantes que pusieron que no, por lo tanto, se debería mejorar en ese aspecto la aplicación para que todos los estudiantes consideren que la aplicación web es de utilidad y puedan usarla en su formación académica. Bien Excelente Muy bien Regular Software 5 2 8 ITIN 8 4 12 1 0 2 4 6 8 10 12 14 ¿Qué opina de la aplicación? Software ITIN 124 Figura 39. Resultados acerca de la utilidad de la aplicación Resultados acerca de la utilidad de la aplicación Nota. La Figura 39 muestra los resultados tanto de los estudiantes de Software como de ITIN acerca de su opinión sobre la utilidad de la aplicación en la identificación de requisitos funcionales Tiempo de demora en elaborar las HU mediante la forma manual (matriz de Excel). Como se puede observar en la Figura 40, la mayoría de estudiantes afirman que mediante la forma manual (Matriz de Excel) se demoran más de 5 minutos y de ahí el resto de estudiantes contestaron que se demoran entre 2-4 min o 1 min. Figura 40. Tiempo de demora en elaborar las HU de forma manual Tiempo de demora en elaborar la matriz de HU de forma manual No Sí Software 1 14 ITIN 2 23 0 5 10 15 20 25 ¿Cree que la aplicación es de utilidad en la identificación de requisitos funcionales? Software ITIN 125 Nota. La Figura 40 muestra a los estudiantes de las carreras de Software e ITIN su opinión acerca del tiempo en hacer realizar la matriz de HU de forma manual Tiempo de demora en elaborar las HU mediante la aplicación web. Como se puede observar en la Figura 41, la mayoría de estudiantes contestó que se demoraban entre dos y cuatro minutos, es decir sí existe una disminución de tiempo en comparación a la forma manual. Puesto que, sólo 6 estudiantes piensan que se demoran más de cinco minutos con la aplicación, mientras que 26 estudiantes piensan que se demoran más de cinco minutos de la forma manual como se puede observar en la Figura 40, lo cual da un buen indicio de que la aplicación es de utilidad para los estudiantes, además que reduce el tiempo al momento de elaborar HU que puede llegar a ser un proceso demoroso y engorroso. Figura 41. Tiempo de demora en elaborar la matriz de HU con la aplicación web Tiempo de demora en elaborar la matriz de HU con la aplicación web Forma manual: entre 2 y 4 min Forma manual: más de 5 min Forma manual: menos de 1 min Software 3 11 ITIN 8 15 1 0 2 4 6 8 10 12 14 16 ¿Cuánto tiempo le toma realizarlo de forma manual? Software ITIN 126 Nota. La Figura 41 muestra a los estudiantes de Software e ITIN acerca de su opinión sobre el tiempo de demora en realizar la matriz de HU con la aplicación web Facilidad para devolverse a los requisitos en la aplicación. Como se puede observar en la Figura 42, la mayoría de estudiantes respondió que es no es ni muy fácil ni muy difícil regresar a los requisitos en la aplicación, el principal punto es que únicamente 2 personas respondieron que les parece algo difícil y 7 personas piensan que les parece bastante difícil, por lo tanto, se debe tener en cuenta este aspecto para seguir mejorando la aplicación y que sea muy fácil acceder o regresar a los requisitos. Figura 42. Resultados acerca de la facilidad para devolverse a los requisitos Resultados acerca de la facilidad para devolverse a los requisitos Aplicación: entre 2 y 4 min Aplicación: más de 5 min Aplicación: menos de 1 min Software 7 2 3 ITIN 12 4 6 0 2 4 6 8 10 12 14 ¿Cuánto tiempo le ha tomado realizarlo con la aplicación? Software ITIN 127 Nota. La Figura 42 muestra a los estudiantes de las carreras de Software e ITIN acerca de su opinión sobre devolverse a los requisitos, lo cual da un indicio sobre la navegabilidad de la aplicación web. Funcionalidad de la aplicación web (Segunda encuesta) Se aplica la segunda encuesta para conocer la opinión de los estudiantes únicamente de la carrera de Software, puesto que son estudiantes que aprobaron el curso de Ingeniería de Requisitos, por tal motivo las preguntas están enfocadas hacia una comparación entre la aplicación web con el proceso de Ingeniería de Requisitos, para mayores detalles Ver Tabla 10, escenario de Funcionalidad de la aplicación web, sesión 2. Comparación en base a la experiencia en el uso de Ingeniería de Requisitos y de la aplicación web de HU/5W+2H. Como se mencionó anteriormente, se van a abordar cuatro aspectos diferentes que permitirán realizar la comparación entre la Ingeniería de Requisitos con la aplicación web, por lo tanto, los resultados obtenidos se comentan seguido de la imagen correspondiente. Algo difícil Bastante fácil Muy fácil Normal Software 1 3 2 9 ITIN 1 4 4 16 0 2 4 6 8 10 12 14 16 18 ¿Qué tan fácil es devolverse a los requisitos en la aplicación? Software ITIN 128 Figura 43. Ingeniería de requisitos vs aplicación web, aspecto: Ágil y engorroso Ingeniería de requisitos vs aplicación web, aspecto: Ágil y engorroso Nota. La Figura 43 muestra el porcentaje de estudiantes que piensan que la aplicación web es ágil y la Ingeniería de Requisitos es engorrosa y viceversa. Como se observa en la Figura 43, existe un 85% de estudiantes que opinan que la aplicación web con la técnica de las 5W+2H es más ágil en comparación a la Ingeniería de Requisitos, por lo tanto, en este primer punto se observa que la aplicación web cumple con su objetivo de brindar agilidad en la identificación de requisitos funcionales. Figura 44. Ingeniería de requisitos vs aplicación web, aspecto: Fácil y difícil Ingeniería de requisitos vs aplicación web, aspecto: Fácil y difícil 11, 85% 2, 15% Ágil y engorroso Ágil en el aplicativo web HU/5W2H y engorroso en ingeniería de requisitos Ágil en ingeniería de requisitos y engorroso en el aplicativo web HU/5W2H 129 Nota. La Figura 44 muestra el porcentaje de estudiantes que piensan que la aplicación web es fácil y la Ingeniería de Requisitos es difícil y viceversa. Como se puede observar en la Figura 44, de igual forma existe un mayor porcentaje de estudiantes (77%) que piensan que el proceso de la aplicación web aplicando la técnica de las 5W+2H es más fácil en comparación con la Ingeniería de Requisitos, donde opinan que el proceso es más difícil, por lo tanto, en este segundo punto se refuerza que la aplicación es sencilla de usar, por lo tanto, la usabilidad de la aplicación web es óptima. Figura 45. Ingeniería de requisitos vs aplicación web, aspecto: Rápido y lento Ingeniería de requisitos vs aplicación web, aspecto: Rápido y lento 10, 77% 3, 23% Fácil y díficil Fácil en el aplicativo web HU/5W2H y difícil en ingeniería de requisitos Fácil en ingeniería de requisitos y difícil en el aplicativo web HU/5W2H 130 Nota. La Figura 45 muestra el porcentaje de estudiantes que piensan que la aplicación web es rápida y la Ingeniería de Requisitos es lenta y viceversa. Como se observa en la Figura 45, al igual que en el anterior aspecto, existe un 77% de estudiantes que consideran que la identificación de requisitos funcionales es más rápida de hacerlo con la aplicación web de las 5W+2H en comparación al proceso de Ingeniería de Requisitos, por lo tanto en este tercer punto, los estudiantes lograron ingresar la información del perfil del proyecto y de la técnica de las 5W+2H de forma rápida en la aplicación web. Figura 46. Ingeniería de requisitos vs aplicación web, aspecto: Todos y uno Ingeniería de requisitos vs aplicación web, aspecto: Todos y uno 10, 77% 3, 23% Rápido y lento Rápido en el aplicativo web HU/5W2H y lento en ingeniería de requisitos Rápido en ingeniería de requisitos y lento en el aplicativo web HU/5W2H 131 Nota. La Figura 46 muestra el porcentaje de estudiantes que piensan que la aplicación web identifica todos los requisitos y la Ingeniería de Requisitos se enfoca sólo en una y viceversa. Como se observa en la Figura 46, se tiene el último aspecto a comparar, en la cual, nuevamente la aplicación web tiene mayor porcentaje (69%) con el cual queda claro que la opinión de la mayoría de los estudiantes es positiva respecto al proceso de ingreso de información en la aplicación web, además que permite identificar la gran mayoría de requisitos funcionales en comparación con la Ingeniería de Requisitos que a percepción de los estudiantes se enfoca más en uno dejando de lado los demás. Información acerca de la No Funcionalidad. Como se observa en la Figura 47 y recordando la forma de evaluación definida anteriormente, ningún estudiante seleccionó la escala baja o media y al contrario hubo un 77% de estudiantes que opinan que la escala en que la información proporcionada les ayuda a comprender la no funcionalidad en la aplicación web es alta y un 23% muy alta, esto gracias a toda la información resumida que se puede leer junto con recursos de apoyo incluida la propia fuente de donde se obtuvo. Figura 47. Comprensión de los estudiantes acerca de la No Funcionalidad 9, 69% 4, 31% Todos y uno Identifica todos los requisitos en el aplicativo web y se enfoca en un solo tipo de requisito en ingeniería de requisitos Identifica todos los requisitos en Ingeniería de Requisitos y se enfoca en un solo tipo de requisito en el aplicativo web 132 Comprensión de los estudiantes acerca de la No Funcionalidad Nota. La Figura 47 muestra el porcentaje de estudiantes que opinan que la información que se encuentra en la aplicación web acerca de la No Funcionalidad les ha ayudado en una escala alta y muy alta. Preferencia a futuro entre el proceso tradicional de la Ingeniería de Requisitos con el uso de la aplicación web HU/5W+2H. Finalmente, en la Figura 48 se puede observar que el 92% de estudiantes escogerían a la aplicación web con la técnica de las 5W+2H para desarrollar sus trabajos académicos, esto reforzado con las preguntas anteriores en donde la mayoría de estudiantes escogieron a la aplicación web debido a su agilidad, facilidad, rapidez y que pueden identificar gran parte de los requisitos funcionales para mantener un flujo de trabajo durante todo el proceso de construcción o desarrollo del software. Figura 48. Preferencia para desarrollar trabajos académicos en el futuro Preferencia para desarrollar trabajos académicos en el futuro 10, 77% 3, 23% Comprensión de la No Funcionalidad Alto Muy alto 133 Nota. La Figura 48 muestra el porcentaje de estudiantes que escogerían a la aplicación web de las 5W+2H o la Ingeniería de Requisitos para trabajos académicos futuros. 12, 92% 1, 8% Preferencia para trabajos académicos futuros Aplicativo web HU/5W2H (ERS) Ingeniería de requisitos (ERS) 134 Capítulo V Conclusiones En las auditorías realizadas de la aplicación web, se concluye que el rendimiento mostró buenos resultados en términos de tiempos de carga, interactividad y estabilidad visual. Los resultados obtenidos en la auditoría de rendimiento, presentados en la Tabla 14, son una puntuación general de 94/100. Los resultados de las métricas específicas, como el First Contentful Paint (FCP), Time to Interactive (TTI), Speed Index, Total Blocking Time (TBT) y el Renderizado del mayor elemento con contenido (LCP) son buenos o moderados, cumpliendo con los estándares recomendados. El único punto de mejora identificado fue en el tiempo de carga del elemento con mayor peso de la página, que fue moderado. Por lo tanto, los resultados obtenidos demuestran que la aplicación web tiene un buen rendimiento y es apta para su uso por parte de los usuarios. En la accesibilidad de la aplicación web se mostró que la página cumple con un nivel A en WCAG 2.1, con un 9 de 12 criterios de éxito cumplidos y 3 fallidos. A nivel de AA, la aplicación cumple con 20 de 26 criterios de éxito y 6 fallidos, y en el nivel AAA solo se cumplen 27 de 48 criterios de éxito y 21 fallidos. En cuanto a la accesibilidad de componentes, se encontró que el menú de navegación, el formulario de búsqueda, los botones y el gráfico de líneas tienen accesibilidad aprobada debido a que superaron todas las pruebas de accesibilidad mediante teclado y compatibilidad con lectores de pantalla. Sin embargo, el calendario y las tablas no cumplieron con todas las pruebas de accesibilidad, por lo que no tienen accesibilidad aprobada. La auditoría también identificó problemas de accesibilidad en la aplicación, como falta de alternativas de texto, contraste de color insuficiente, problemas de accesibilidad del teclado y problemas de compatibilidad con lectores de pantalla. En la tabla 16 se presentan los resultados detallados de la auditoría de accesibilidad de componentes. 135 También, en la auditoría de buenas prácticas de la aplicación web mostró que la página cumple con las buenas prácticas en cuanto al uso de HTTPS y del manifiesto de aplicaciones web, lo cual es positivo para la seguridad y la experiencia del usuario. Sin embargo, se identificó una falla en el uso de service workers, lo que podría afectar negativamente el rendimiento de la aplicación, especialmente en dispositivos móviles. Por otro lado, la aplicación cumple con el uso de presupuestos de rendimiento, lo cual garantiza que el rendimiento se mantiene dentro de límites aceptables. En general, los resultados obtenidos demuestran que la aplicación web cumple con buenas prácticas en algunos aspectos, pero hay un área en la que se podría mejorar, específicamente en el uso de service workers. Las auditorías realizadas a la aplicación web han revelado que tiene un buen rendimiento, accesibilidad y cumplimiento de buenas prácticas, pero también se han identificado áreas de mejora. Estas incluyen la mejora en el tiempo de carga del elemento con mayor peso de la página, el aumento del cumplimiento de los estándares de accesibilidad y mejorar el uso de service workers para mejorar el rendimiento de la aplicación. La hipótesis planteada al inicio se cumplió, puesto que, el 85% (Ver Figura 43) y el 77% (Ver Figuras 44 – 45) de estudiantes, consideraron que la aplicación web desarrollada es una herramienta ágil, fácil y rápida. Además, existen otros resultados positivos en ambas carreras tanto de Software e ITIN como la optimización del tiempo de identificación de requisitos funcionales (Ver Figura 41) en donde el 55,88% de estudiantes de ambas carreras opinaron que mediante la aplicación web este proceso se demora entre 2 y 4 minutos mientras que con el proceso tradicional (usando la matriz de Excel) el 76,47% (Ver Figura 40) de estudiantes afirman que con la matriz este proceso toma más de 5 minutos. Cabe destacar que, se cumplió con el objetivo de gestionar y versionar los requisitos funcionales y brindar información a los estudiantes para la comprensión acerca de la no funcionalidad, en donde el 77% (Ver Figura 47) de estudiantes opinaron que la información 136 proporcionada en la aplicación web es de ayuda en una escala alta y el 23% en una escala muy alta y ningún estudiante seleccionó la opción baja o media, lo cual indica que la aplicación web realmente es de gran ayuda para conocer más acerca de la no funcionalidad. Finalmente, la aplicación web desarrollada aplica de forma correcta la técnica de las 5W+2H con el marco de trabajo ágil Scrum, esto se respalda gracias a que el 92% (Ver Figura 48) de estudiantes optaría por utilizar la aplicación web en trabajos académicos futuros. Recomendaciones Si se desea continuar con el desarrollo e implementación del aplicativo en la Universidad de las Fuerzas Armadas ESPE se recomienda analizar las tecnologías utilizadas en el desarrollado de la aplicación web, puesto que, se puede tener en consideración otros lenguajes de programación, bases de datos o servicios de alojamiento distintos a los ocupados en este trabajo, analizando las ventajas y desventajas de cada tecnología detallada en la sección de Materiales, Capítulo 3. De igual forma, se puede tener en cuenta la arquitectura con la que fue diseñada la aplicación, dado que, si se quiere seguir agregando más funcionalidades al aplicativo, que sea escalable y dividir a todos los módulos desarrollados en distintos servicios, se debería optar por una arquitectura de microservicios que brinda más ventajas sobre la empleada actualmente que es la de N Capas. Además, para aumentar la capacidad de concurrencia de usuarios (que será totalmente obligatorio en caso de que se desee implementar en la Universidad) se deberá contratar un servicio en la nube con mejores características del ocupado actualmente, dado que, en el caso de PythonAnywhere únicamente se está trabajando con un servidor gratuito el cual soporta una cantidad muy limitada de usuarios que estén haciendo uso de la aplicación web al mismo tiempo. 137 También, si se aumenta nuevas funcionalidades se debe mantener y continuar con las buenas prácticas de código limpio, que han sido utilizadas tanto en el backend como en el frontend, sin olvidar que se debería realizar pruebas unitarias y de integración para verificar las nuevas funcionalidades que se añadan a la aplicación web. Finalmente, se debe tener en cuenta que la aplicación web ha sido desarrollada con fines académicos para que los estudiantes pertenecientes a los cursos de Análisis y Diseño de Software y Metodologías de Desarrollo de Software de las carreras de Software e ITIN respectivamente, puedan comprender o entender de mejor manera la aplicación de la técnica de las 5W+2H en la identificación de requisitos funcionales a través de HU con el marco de trabajo Scrum, en caso de que se quiera cambiar el enfoque con otra técnica se debería tener en consideración los datos que son necesarios para poder implementarla en la aplicación web y que de igual manera sirva de guía a los estudiantes con el objetivo que puedan comprender otras formas de identificar requisitos funcionales. Trabajos Futuros En cuanto a trabajos futuros, se podría continuar desarrollando la aplicación para incluir una mayor gestión de los requisitos no funcionales. Esto podría incluir la implementación de una herramienta de seguimiento de los requisitos no funcionales, así como la automatización de la evaluación de estos requisitos para garantizar que se cumplan en todo momento. Un enfoque podría ser mejorar la funcionalidad de la aplicación para hacer más fácil la gestión de las versiones de los perfiles de proyecto, así como de las historias de usuario. Por ejemplo, se podría incluir una herramienta de seguimiento de tiempo para mejorar la gestión de las tareas dentro de las historias de usuario y una herramienta de análisis para mejorar la toma de decisiones en cuanto a cambios de versiones de perfiles de proyecto. También podría incluir un sistema de alertas para notificar a los miembros del equipo de cambios o actualizaciones en los perfiles de proyecto e historias de usuario. 138 Además, se podría investigar la posibilidad de integrar la aplicación con otras herramientas para mejorar aún más la eficiencia y eficacia del proceso de gestión de requisitos funcionales y EDT dentro del trabajo SCRUM. Esto podría incluir la integración con herramientas de seguimiento de errores, herramientas de pruebas automatizadas, herramientas de gestión de tiempo, herramientas de análisis de datos y herramientas de colaboración y trabajo en equipo. Específicamente, se podrían investigar herramientas como JIRA, Trello, Asana, entre otras para la gestión de tareas y seguimiento de errores, y herramientas como Selenium, Appium para la automatización de pruebas. Finalmente, se podría continuar investigando y mejorando la aplicación en términos de escalabilidad, seguridad y rendimiento para garantizar que pueda soportar un gran número de usuarios y perfiles de proyectos simultáneamente, y para proteger la información de los usuarios. En resumen, el trabajo futuro podría enfocarse en mejorar la gestión de requisitos no funcionales, mejorando las funcionalidades de la aplicación, integrando con herramientas adicionales y mejorando la escalabilidad, seguridad y rendimiento de la aplicación. 139 Bibliografía ACM. (6 de Octubre de 2010). ACM DL. Obtenido de ACM Digital Library: https://dl.acm.org/ Alvarez, S., Duy, K., Zapata, M., Galarza, J., Martinez, D., & Puco, C. (2021). The Communication Between Client-Developer in the Process of Requirements Elicitation for a Software Project. WorldCIST 2021: Trends and Applications in Information Systems and Technologies, 36-45. Anaconda. (4 de Abril de 2011). PythonAnywhere. Obtenido de PythonAnywhere: https://www.pythonanywhere.com/ Arnau, L., & Josefina, S. (23 de Abril de 2020). La revisión de la literatura científica: Pautas, procedimientos y criterios de calidad. Obtenido de UAB: https://ddd.uab.cat/pub/recdoc/2020/222109/revliltcie_a2020.pdf Blancarte, O. (3 de Diciembre de 2020). Arquitectura en Capas. Obtenido de Reactive Programming: https://reactiveprogramming.io/blog/es/estilos-arquitectonicos/capas Bolloju, N., Alter, S., Gupta, A., Gupta, S., & Jain, S. (2017). Improving Scrum User Stories and Product Backlog Using Work System Snapshots. Twenty-third Americas Conference on Information Systems, 3. Brocke, J. v., Hevner, A., & Maedche, A. (Septiembre de 2020). Introduction to Design Science Research. Obtenido de ResearchGate: https://www.researchgate.net/publication/345430098_Introduction_to_Design_Science_ Research CASP. (17 de Septiembre de 2016). CASP UK. Obtenido de CASP Checklists: https://casp- uk.net/images/checklist/documents/CASP-Systematic-Review-Checklist/CASP- Systematic-Review-Checklist-2018_fillable-form.pdf 140 CES. (2 de Agosto de 2017). RPC-SO-2 7-No. SZ 4-2O 17. San Francisco de Quito , D.M, Pichincha, Ecuador. Corporación ADSI SENA. (18 de Marzo de 2014). Blogspot. Obtenido de ¿QUE ES UN DIAGRAMA DE ENTRADA- PROCESO-SALIDA? : http://corporacionadsisena.blogspot.com/2011/06/que-es-un-diagrama-de-entrada- proceso.html da Silva, D., & Gonçalves, P. (s.f). Devmedia. Obtenido de Herramienta 5W2H para toma de requerimientos y creación de User Stories: https://www.devmedia.com.br/ferramenta- 5w2h-para-levantameto-de-requisitos-e-elaboracao-de-user-stories/25603 Dezhkam, M. (2019). Project portfolio management system, concepts and approach foundations. IOP Conference Series Earth and Environmental Science, 1-12. dos Santos, S. C., Furtado, F., & Lins, W. (2014). xPBL: a Methodology for Managing PBL when Teaching Computing. IEEE. EALDE. (2 de Abril de 2020). EALDE Business School. Obtenido de Dirección de proyectos: Qué es una EDT en Proyectos: https://www.ealde.es/que-es-edt- proyectos/#:~:text=La%20EDT%20es%20una%20representaci%C3%B3n,de%20forma %20adecuada%20el%20proyecto. ESET. (16 de Julio de 2019). ESET-LA. Obtenido de Introducción a la protección de datos: https://www.eset-la.com/pdf/landing/2019/regulacion-de-datos/introduccion-proteccion- datos.pdf Flask. (4 de Agosto de 2022). Pallets Projects. Obtenido de Flask web development: https://flask.palletsprojects.com/en/2.2.x/ 141 Ghimire, D., & Charters, S. (2022). The Impact of Agile Development Practices on Project Outcomes. MDPI. GitHub. (14 de Mayo de 2008). GitHub. Obtenido de GitHub: https://github.com/ Guerrero, D. (2019). Proyecto, portafolios y programas y la PMO. Lima: Repositorio Institucional PIRHUA. Hevner, A., March, S. T., & Park, J. (Marzo de 2004). Design Science in Information Systems Research. Obtenido de ResearchGate: https://www.researchgate.net/publication/201168946_Design_Science_in_Information_S ystems_Research IBM. (24 de 01 de 2021). IBM. Obtenido de What is requirements management?: https://www.ibm.com/topics/what-is-requirements-management IEEE. (27 de Marzo de 2005). IEEE Xplore. Obtenido de Advancing Technology for Humanity: https://ieeexplore.ieee.org/Xplore/home.jsp IEEE. (22 de Octubre de 2008). IEEEE 830. Obtenido de IEEE Standards: https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830.pdf IREB. (01 de Marzo de 2015). GASQ. Obtenido de Profesional Certificado en Ingeniería de Requisitos de IREB: https://www.gasq.org/files/content/gasq/downloads/certification/IREB/IREB%20FL/ireb_c pre_syllabus_fl_es_v22.pdf Janovec, T. (2001). Procedural justice in organizations: A literature map. Nebraska: Unpublished manuscript. 142 Lucassen, G., Dalpiaz, F., van der Werf, J., & Brinkkemper, S. (2016). The Use and Effectiveness of User Stories in Practice. nternational Working Conference on Requirements Engineering: Foundation for Software Quality, 1. Maddern, G., Stoiber, M., Pluckthun, P., Jacobs, E., & Contributors. (13 de Octubre de 2016). Styled-Components. Obtenido de styled components: https://styled-components.com/ Maier, P., Ma, Z., & Bloem, R. (2017). Towards a Secure SCRUM Process for Agile Web Application Development . ACM. Material UI SAS. (5 de Diciembre de 1998). MUI. Obtenido de Material UI: https://mui.com/ MDN. (28 de Octubre de 2022). Developer Mozilla. Obtenido de Control de acceso HTTP (CORS): https://developer.mozilla.org/es/docs/Web/HTTP/CORS MDN. (24 de Octubre de 2022). Developer Mozilla. Obtenido de Javascript: https://developer.mozilla.org/es/docs/Web/JavaScript MDN. (14 de Octubre de 2022). Developer Mozilla. Obtenido de HTML: Lenguaje de etiquetas de hipertexto: https://developer.mozilla.org/es/docs/Web/HTML Meta. (2022). ReactJS. Obtenido de React: https://es.reactjs.org/ Moher, D., Liberati, A., Tetzlaff, J., Altman, D. G., & The PRISMA Group. (2009). Preferred Reporting Items for Systematic Reviews and Meta-Analyses: The PRISMA Statement. PLOS. Molina, N. (Diciembre de 2005). ¿Qué es el estado del arte? Obtenido de ResearchGate: https://www.researchgate.net/publication/317162163_Que_es_el_estado_del_arte Oracle. (13 de Febrero de 2022). MySQL. Obtenido de MySQL Products: https://www.mysql.com/products/ 143 Organización Internacional de Normalización. (1991). ISO 9126 - ISO/IEC 25000. International: Mc Graw Hill. Project Management Institute. (2021). Guía de los fundamentos para la dirección de proyectos. Newtown Square: NISO (National Information Standards Organization). Python. (13 de Octubre de 1996). Python. Obtenido de Python: https://www.python.org/ Real Academia Española. (1 de Octubre de 2014). Diccionario de la lengua española. Obtenido de Consulta: requisito: https://dle.rae.es/requisito Ruiz, J. (2020). Planteamiento de un marco de trabajo para levantar requisitos de software con estudiantes del primer nivel de la carrera de software de la Universidad de las Fuerzas Armadas-ESPE. Sangolquí: Curso Internacional en Cultura de la Investigación UNIR. Salvadori, B. G., Magnano, P. F., & Dutra, A. C. (2021). Project based on Agile Methodologies by DMAIC. ICEIS. SAP. (24 de Octubre de 2016). PowerDesigner. Obtenido de ¿Qué es SAP PowerDesigner?: https://www.powerdesigner.biz/ES/ Schwaber, K., & Sutherland, J. (Noviembre de 2020). La Guía Scrum. Obtenido de Scrum Guides: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish- European.pdf Serna, D. (2021). Matriz 5W2H. Obtenido de Academia: https://www.academia.edu/42075348/Matriz_5W2H Sharma, S., Sarkar, D., & Gupta, D. (2012). Agile Processes and Methodologies: A Conceptual Study. International Journal on Computer Science and Engineering (IJCSE), 892-898. 144 Silvela, M. (7 de Diciembre de 2016). Topodata. Obtenido de Estructura del Desglose del Trabajo EDT: https://topodata.com/wp-content/uploads/2019/10/EDT-Estructura-de- Desglose-del-Trabajo.pdf Sommerville, I. (2011). Ingeniería de Software. Atlacomulco: Pearson Education, Inc. SQLAlchemy. (28 de Noviembre de 2005). SQLAlchemy. Obtenido de The Python SQL Toolkit and Object Relational Mapper: https://www.sqlalchemy.org/ Tecnologías Información. (28 de Julio de 2019). Modelos de datos: Modelo Conceptual, Físico y Lógico. Obtenido de Tecnologías-Información: https://www.tecnologias- informacion.com/modelos-datos.html Vasconcelos, R. (24 de 07 de 2022). Dev.to Community. Obtenido de Clean Architecture: Applying with React: https://dev.to/rubemfsv/clean-architecture-applying-with-react-40h6 Vercel Inc. (9 de Febrero de 2001). Vercel. Obtenido de Vercel: https://vercel.com/ Wong, S. (2017). Continental Edu. Obtenido de Análisis y requerimientos de software: manual autoformativo interactivo: https://repositorio.continental.edu.pe/bitstream/20.500.12394/4281/1/DO_FIN_103_MAI _UC0939_2018.pdf Zayat, W., & Senvar, O. (2020). Framework Study for Agile Software Development Via Scrum and Kanban. Worl Scientific. 145 Apéndices