Propuesta de un videojuego educativo para la enseñanza-aprendizaje de la clasificación de requisitos en ingeniería de software

Abstract

Abstract: One of the most relevant phases in software development process is the analysis phase, in which the scope of the software to be constructed is defined through the specification of functional and non-functional requirements. At the academic level, shortcomings have been identified in the students of the software engineering courses, in terms of the definition and classification of these requirements, which may affect the quality of the software products of these future professionals. Keywords: analysis phase; functional requirements; non-functional requirements; software engineering; video game. i.Introducción La ingeniería del software es una disciplina que comprende los aspectos relacionados con la producción de software, desde las primeras etapas de especificación de requisitos del sistema a construir, hasta el mantenimiento posterior su implementación en su entorno real de operación (Sommerville, 2011; Laird, 2016). Software Requirements Development: A Path for Improving Software Quality.

Headnote

Resumen: Una de las fases más relevantes en el proceso de desarrollo de software es la de análisis, que define el alcance del software mediante la especificación de los requisitos funcionales y no funcionales. Esta fase es crucial puesto que una mala especificación de los requisitos del sistema, pueden generar sobreesfuerzos en fases posteriores. A nivel académico se han evidenciado falencias en los estudiantes de los cursos de ingeniería de software, en cuanto la definición y clasificación de estos requisitos, lo que puede afectar la calidad de los productos de software de estos futuros profesionales. Este artículo propone un videojuego como herramienta para reforzar la identificación y clasificación de requisitos en estudiantes de cursos básicos de ingeniería de software. El videojuego fue concebido usando la metodología Design Thinking, implementado mediante la plataforma GDevelop y evaluado desde la perspectiva de usabilidad, usando las heurísticas para videojuegos de Pinelle.

Palabras clave: fase de análisis; ingeniería de software; requisitos funcionales; requisitos no funcionales; videojuego.

Abstract: One of the most relevant phases in software development process is the analysis phase, in which the scope of the software to be constructed is defined through the specification of functional and non-functional requirements. This phase is crucial since a poor specification of the system requirements can generate an extra effort in subsequent phases. At the academic level, shortcomings have been identified in the students of the software engineering courses, in terms of the definition and classification of these requirements, which may affect the quality of the software products of these future professionals. This paper proposes a videogame as a tool to reinforce students' skills in these courses, in terms of identification and classification of requirements. The video game was conceived using the Design Thinking methodology, implemented through the GDevelop platform and evaluated from the usability perspective, using Pinelle video game heuristics.

Keywords: analysis phase; functional requirements; non-functional requirements; software engineering; video game.

i.Introducción

La ingeniería del software es una disciplina que comprende los aspectos relacionados con la producción de software, desde las primeras etapas de especificación de requisitos del sistema a construir, hasta el mantenimiento posterior su implementación en su entorno real de operación (Sommerville, 2011; Laird, 2016). Así, la ingeniería de software proporciona diversas métricas y metodologías que pueden usarse como especificaciones para la administración de personal involucrado en proyectos de software, ciclos de vida de un proyecto de software, costos de un proyecto, y los demás aspectos administrativos que implica el desarrollo de software. La ingeniería de software ofrece metodologías, herramientas y técnicas para desarrollar software. Estas metodologías son llamadas también modelos de proceso de software y dan pautas para construir un software y generar sus productos asociados como son los manuales técnicos, de usuario y de instalación así el código fuente, entre otros (Jabangwe, Edison, & Nguyen, 2018).

Una de las fases más relevantes en el proceso de desarrollo de software es la de análisis, puesto que en ella se concibe y comprende la naturaleza de la problemática a solucionar a través del software, es decir, en esta fase se define el alcance del software a construir (Buitrón, Flores-Rios, & Pino, 2018). Esta es una etapa crítica, puesto que una definición imprecisa o incompleta del alcance del sistema puede generar un sobreesfuerzo en fases de diseño e implementación para dar cumplimiento a los tiempos definidos inicialmente entre el equipo de desarrollo y el cliente (Berzal, 2006; Mall, 2018). En la fase de análisis se definen por lo general los roles de los usuarios del sistema, se caracteriza el dominio del problema y se especifican los requisitos funcionales y no funcionales del sistema a construir (Buitrón, Flores-Rios, & Pino, 2018). Dentro de la fase de análisis es fundamental que a través de la especificación de requisitos funcionales y no funcionales, el equipo de desarrollo comprenda completamente la naturaleza del sistema a construir, así como su comportamiento (Gasca-Hurtado, Muñoz, Mejia, & Calvo-Manzano, 2014).

En el campo de la Ingeniería Informática o de Sistemas, la temática de requisitos es abordada dentro de los cursos de Ingeniería de Software o afines, como parte de la fase de análisis del proceso de desarrollo de software. En este contexto académico, se han evidenciado dificultades por parte de los estudiantes de estos cursos en cuanto a redacción, reconocimiento y la diferenciación de requisitos funcionales y no funcionales. En este sentido, según (Medina, Hernández, Alonso, & Solis, 2012), la especificación de requisitos es una tarea compleja en los futuros ingenieros porque es necesario realizar tareas fundamentales como: tratar con la naturaleza del sistema y comprender su ambiente, encontrar los componentes y su interacción dentro del sistema, definir los servicios que el sistema debe ofrecer al usuario y definir las restricciones o limitantes del sistema. Así mismo, en el proceso de desarrollo de software se suele hacer énfasis en los requisitos funcionales por sobre los no funcionales, a pesar que estos requisitos definen aspectos relevantes como la usabilidad, la flexibilidad, el rendimiento, la interoperabilidad y la seguridad. Lo anterior hace que en ocasiones se confunda o distinga claramente el alcance de los requisitos no funcionales (Chung & do Prado Leite, 2009).

A partir de lo anterior, este artículo presenta como aporte, el diseño e implementación de un videojuego educativo, que pretende servir de apoyo a los profesores del área de la ingeniería de software en cuanto a la mejor apropiación del concepto de requisitos y de manera específica en lo referente al reconocimiento y clasificación de los requisitos funcionales y no funcionales. Esto se debe a dificultades que presentan los estudiantes en cuanto a la temática de requisitos de software en cuanto a: 1) descripción de requisitos desde el punto de vista del sistema, 2) reconocimiento de los requisitos funcionales como acciones del usuario que debe apoyar el sistema y 3) identificación y descripción de requisitos no funcionales como atributos de calidad del producto relacionados con la experiencia de usuario.

Como respuesta a estas dificultades, el presente artículo propone un videojuego educativo desarrollado en la plataforma libre GDevelop, teniendo en cuenta las diferentes fases propuestas por la metodología Design Thinking (Razzouk & Shute, 2012; Henriksen, Richardson, & Rohit, 2017) como herramienta para la concepción del juego y sus características principales. GDevelop permite la generación de videojuegos haciendo uso de programación orientada a eventos y acciones entre los diferentes elementos y objetos que componen el juego. Así, la intención de este artículo también es dar a conocer las ventajas y potencialidades de plataformas para la creación de recursos educativos en el aula de clase, los cuales por medio de la didáctica contribuyan a la innovación educativa y al afianzamiento de competencias educativas (Pérez-Ortega, 2017), como lo son en este caso la identificación, diferenciación y clasificación de requisitos funcionales y no funcionales.

Con el fin de generar un videojuego más efectivo para ser usado en las clases del área de ingeniería de software, en su proceso de concepción y evaluación se contó con el apoyo de un grupo de profesores con experiencia en ingeniería de software e interacción humano computador, quienes aportaron un listado inicial de requisitos empleados de manera tradicional en sus clases y evaluaron la usabilidad del juego generado a través de un método de inspección, considerando las heurísticas propuestas por (Pinelle, Wong, & Stach, 2008)

El resto del artículo está organizado de la siguiente forma: en la Sección 2 se presentan las diferentes fases metodológicas consideradas en la presente investigación; en la Sección 3 se describen los conceptos relevantes que fundamentan el desarrollo de este trabajo; en la Sección 4 se presenta el diseño y construcción del videojuego propuesto; en la Sección 5 se describe la evaluación de usabilidad realizada al videojuego propuesto mediante un método de inspección; finalmente en la Sección 6 se presentan las conclusiones y trabajos futuros derivados de la presente investigación.

2.Metodología

El desarrollo de esta investigación contempla cuatro fases a saber, adaptadas a partir de la metodología Design Thinking: empatizar y definir, idear, prototipar y evaluar (Serrano & Blázquez, 2015; Razzouk & Shute, 2012; Henriksen, Richardson, & Rohit, 2017) (ver Figura 1).

Fase i - Empatizar y definir: En esta fase se realizó la identificación de la problemática presentada en el proceso de especificación de requisitos (Medina, Hernández, Alonso, & Solis, 2012; Vetterli, Brenner, Uebernickel y Petrie, 2013). A partir de lo anterior, se optó por abordar las dificultades asociadas a la clasificación y/o distinción de requisitos funcionales y no funcionales por parte de los estudiantes mediante el desarrollo de un videojuego educativo para cursos de ingeniería de software.

Fase 2 - Idear: Una vez definido el alcance del videojuego educativo, se hizo uso de interfaces de alto nivel para diseñar la estructura y lógica principal del juego. Las interfaces de alto nivel generadas, permitieron guiar de manera más simple el proceso de desarrollo.

Fase 3 - Prototipar: A partir de los diseños de alto nivel realizados, se procedió con la construcción de un prototipo de videojuego educativo para diferentes plataformas, haciendo uso de la plataforma libre para no programadores GDevelop. El videojuego permite al usuario mediante interacciones sencillas clasificar un requisito aleatorio especificado por el equipo de desarrollo, como funcional o no funcional. En esta fase se contó con la colaboración de un conjunto de profesores del área de ingeniería de software quienes aportaron un listado de requisitos de ejemplo usados en sus cursos, en la fase de análisis de un producto de software.

Fase 4 - Evaluar: Para evaluar la usabilidad del videojuego construido, se condujo una inspección de usabilidad, la cual fue realizada teniendo en cuenta las diez heurísticas de usabilidad para videojuegos propuestas por Pinelle, Wong, & Stach (2008). Esta inspección fue realizada por profesores del área de la ingeniería de software con experiencia en evaluaciones de usabilidad. El propósito de la evaluación realizada fue mirar la pertinencia y utilidad del videojuego de cara a su uso en los cursos del área de ingeniería de software.

3.Marco Conceptual

En esta sección se presentan un conjunto de conceptos relevantes para el desarrollo de la presente investigación: fase de análisis, requisitos funcionales, requisitos no funcionales y plataforma GDevelop.

3.1.Fase de análisis

Esta fase incluye el proceso mediante el cual se pretende concebir lo que realmente el sistema o programa informático debe realizar en un contexto específico. Esta es una fase compleja ya que no siempre el cliente tiene una visión clara del software a construir y cualquier decisión errónea repercute ampliamente en el diseño del producto software. En este sentido, cuanto más precisa sea la caracterización del sistema a construir, mayor probabilidad se tendrá de construir un producto software de calidad, puesto que distintos estudios han demostrado que eliminar un error en las fases iniciales de un proyecto (en la etapa de análisis) resulta de 10 a 100 veces más económico que subsanarlo al final del proyecto (Berzal, 2006; Mall, 2018). En la fase de análisis, a partir de las reuniones con el cliente, el analista del sistema busca obtener los requisitos del software a construir, así como los roles de los diferentes usuarios que interactuarán con este. En ingeniería de software, un requisito es entendido como una característica, restricción o necesidad documentada sobre el contenido, forma o funcionalidad de un producto o servicio (Melegati, Goldman, Kon, & Wang, 2019). En otras palabras, los requisitos identifican el qué debe hacer el sistema, mientras que el diseño establece el cómo del sistema (Borgida, Dalpiaz, Horkoff, & Mylopoulos, 2013). De acuerdo al estándar IEEE 830 los requisitos del sistema pueden ser divididos en funcionales y no funcionales (IEEE Std. 830-1998, 2008).

3.2. Requisitos Funcionales

Los requisitos funcionales describen la interacción entre el sistema y su ambiente, así como la forma en la que el sistema debe comportarse ante determinado estímulo. Estos requisitos son declaraciones de las prestaciones y/o servicios que debe proporcionar el sistema, de la manera en que éste debe reaccionar a entradas particulares y de cómo se debe comportar en situaciones particulares. En ciertas ocasiones, también pueden declarar explícitamente lo que el sistema no debe hacer. Es así como los requisitos funcionales describen de manera precisa lo que el sistema debe hacer (Lauenroth, Kamsties, & Hehlert, 2017). O en otras palabras, los requisitos funcionales describen todas las interacciones que se prevé que los usuarios tendrán con el software (Pytel et al., 2011). Un ejemplo de requisito funcional podría ser: "El sistema debe permitir actualizar el estado de un cliente como moroso cuando no está al día en el pago de sus pedidos".

3.3. Requisitos No Funcionales

Los requisitos no funcionales hacen referencia a los aspectos de calidad de productos de software como son: rendimiento, fiabilidad, exactitud, seguridad y usabilidad (Doerr et al., 2005). Una de las características de estos requisitos es la especificación de ciertos niveles de calidad y, por consiguiente, en muchos casos es posible cuantificarlos (Boehm, 1996). Por lo anterior, los requisitos no funcionales describen una restricción sobre el sistema software, la cual limita las elecciones en la implementación de una solución al problema. En este sentido, estos requisitos restringen las funciones o prestaciones ofrecidas por el sistema, por lo cual dentro de éstos se pueden encontrar restricciones en cuanto al tiempo, el tipo de proceso de desarrollo a utilizar, la fiabilidad del software, los tiempos de respuesta, la capacidad de almacenamiento, el rendimiento, la escalabilidad, la seguridad de la aplicación, entre otros atributos que definen la calidad del software (Chung & do Prado Leite, 2009). Un ejemplo de requisito no funcional podría ser: El sistema debe estar en capacidad de recuperarse de un error en menos de 5 minutos.

3.4. Plataforma GDevelop

GDevelop es una plataforma para la creación de videojuegos en dos dimensiones, destinada al uso de usuarios no programadores. Esta plataforma permite la creación de aplicaciones, mediante la estrategia de programación orientada a eventos y acciones, en la cual no se codifican líneas de código, sino que se define el comportamiento de los objetos agregados al escenario (sprites, tiled layers, etiquetas, etc.) mediante eventos y acciones. La principal ventaja de GDevelop con respecto a otras plataformas similares como Construct 2 o Game Maker, es el hecho de ser libre, lo cual permite exportar el juego creado a diferentes tipos de plataformas: escritorio, web y móvil. Así mismo, GDevelop puede ser ejecutado en línea y permite la publicación de los juegos creados en su repositorio de recursos (Cuartas, 2016). En este artículo se hizo uso de GDevelop para la creación de un videojuego con propósito educativo para la identificación y clasificación de requisitos funcionales y no funcionales.

4.Diseño y Construcción del Videojuego

A partir de la problemática evidenciada por parte de los profesores del área de ingeniería de software, acerca de las dificultades de los estudiantes en cuanto a la identificación y clasificación de requisitos en la fase de análisis del proceso de desarrollo de software, en la etapa de diseño del videojuego se propuso como idea central una interfaz sencilla, en la cual los requisitos ya sea funcionales o no funcionales desciendan de la parte superior de la pantalla y en la parte inferior sean depositados en alguna de las dos canastas disponibles. Por cada requisito depositado de manera correcta el jugador irá sumando un punto, obteniendo al final del juego una relación entre los requisitos acertados y los intentos realizados. La interfaz de alto nivel que representa la idea central del juego se presenta en la Figura 2. Esta interfaz fue realizada con apoyo de la herramienta en línea para la generación de mockups NinjaMock (Mutis, 2016).

En la Figura 3 se presenta un diagrama de flujo que describe de manera gráfica la lógica de interacción entre el usuario y el videojuego de clasificación de requisitos funcionales y no funcionales. Cuando el usuario lanza el juego en alguna de las diferentes distribuciones (escritorio, web, móvil, etc.), se presenta la interfaz principal del juego. Una vez el usuario presiona el botón iniciar, el sistema se encarga de generar un requisito aleatorio a partir de los requisitos definidos y almacenados en el juego, de tal manera que empieza a descender desde la parte superior de la pantalla el requisito escogido. Mientras el requisito desciende por la pantalla, el usuario debe clasificarlo como funcional o no funcional llevándolo a la cesta correcta, de tal modo que en caso que dicho requisito haya sido bien clasificado, el sistema incrementa el puntaje y el número de intentos, en caso contrario solo incrementa el número de intentos. Cada vez que el puntaje y los intentos son desplegados en pantalla del videojuego, el sistema verifica si se han cumplido los diez intentos o no, en caso que no se hayan cumplido se repite el proceso de obtener los requisitos aleatorios, de lo contrario se muestra en pantalla el resultado final y el usuario puede terminar el juego o volverlo a iniciar.

Por otra parte, en la Figura 4 se presenta la interfaz final de escritorio del juego desarrollado en la plataforma libre GDevelop. A diferencia de la etapa de diseño, en la fase de prototipado se optó por cambiar las imágenes de las cestas por imágenes de carpetas, teniendo en cuenta que éstas corresponden a representaciones visuales que el usuario puede asociar de manera más adecuada.

Tal como se aprecia en la Figura 4, los diferentes ítems u objetos del videojuego pueden ser en este caso de dos tipos específicos: sprites (requisito aleatorio, carpetas, botón de iniciar o terminar, fondo del escenario, cesped) o mensajes en pantalla (puntaje, intentos, mensaje en el fondo de la pantalla). Es importante resaltar que los sprites del juego pueden ser asociados con imágenes, como es el caso del postit donde se ubican los requisitos o las carpetas en donde el jugador deposita los requisitos funcionales o no funcionales.

A partir de los sprites cargados en el escenario del videojuego, GDevelop permite programar en la pestaña de eventos, las diferentes acciones o eventos que ocurren cuando estos sprites interactúan. A modo de ejemplo, en la Figura 5 se muestra el evento programado cuando el sprite que contiene el requisito (sprite nota) colisiona con el sprite que está asociado a la carpeta de requisitos funcionales (sprite rf).

El videojuego propuesto se encarga de escoger de manera aleatoria un conjunto de requisitos ya sean funcionales o no funcionales, previamente definidos. A partir del requisito escogido por el sistema de manera aleatoria, el jugador debe depositar dicho requisito en la carpeta adecuada, antes de que dicho requisito toque el suelo. A modo de ejemplo, en la Tabla 1 se muestra un fragmento de los requisitos cargados en el videojuego y aportados por un conjunto de profesores del área de ingeniería de software a partir de los ejemplos usados en sus clases.

5.Evaluación del videojuego

Con el propósito de evaluar la pertinencia del videojuego propuesto como herramienta de apoyo didáctico en los cursos de ingeniería de software, un grupo de profesores de cinco esta área y con experiencia en interacción humano computador evaluaron la usabilidad del juego, haciendo uso de un método de inspección guiado por las heurísticas de videojuegos propuestas por Pinelle, Wong, & Stach (2008). Una inspección de usabilidad es el nombre genérico para un conjunto de técnicas o métodos eficaces de evaluación de las interfaces de usuario con el objetivo de encontrar problemas de usabilidad, son muy informales y fáciles de usar. Este método consiste en la conformación de un grupo de expertos que analizan o inspeccionan una aplicación específica. Estos expertos realizan un informe comentando distintos aspectos de usabilidad de la aplicación, basándose en su experiencia en el área y teniendo en cuenta un conjunto de principios previamente definidos. Este informe es utilizado para realizar los cambios o ajustes necesarios en la aplicación y resolver los problemas indicados (Enriquez & Casas, 2013; Valentim & Conte, 2014).

Adicionalmente, la población para la evaluación de usabilidad del videojuego está conformada por 5 docentes de ingeniería de software con entre 5 y 8 años de experiencia en la enseñanza de esta área a nivel universitaria y con un nivel de conocimiento medio y/o en el área de interacción humano-computador en aspectos de usabilidad.

5.1. Heurísticas de la evaluación

En la Tabla 2 se presenta una descripción de cada una de las diez heurísticas propuestas por Pinelle, Wong, & Stach (2008) las cuales están enfocadas al diseño, construcción y evaluación de videojuegos. Estas heurísticas fueron obtenidas por los autores a partir del análisis y revisión de 108 reportes de problemas de usabilidad realizados en el portal GameSpot. Cabe resaltar que las heurísticas tratan de abordar las diferentes categorías de los videojuegos, por lo que en algún tipo de videojuego pueden no aplicar todas las heurísticas.

5.2. Resultados de la evaluación de usabilidad

Una vez inspeccionado el cumplimiento de las diferentes heurísticas de usabilidad presentadas en la Tabla 2, se obtuvieron a partir de los comentarios de los profesores del área de ingeniería de software un conjunto de aspectos positivos y por mejorar del videojuego para la identificación y clasificación de requisitos de software (ver Tabla 3). Estos aspectos buscan contribuir a mejorar la usabilidad del videojuego y por ende el nivel de aceptación por parte de los estudiantes, de tal modo que el juego sea más cercano al usuario y pueda contribuir a mejorar las habilidades de los estudiantes en la clasificación de los requisitos funcionales y no funcionales.

6.Conclusiones y trabajos futuros

Los requisitos funcionales y no funcionales son conceptos fundamentales en la etapa de análisis del proceso de desarrollo de software, pues definen aspectos que se ven reflejados en el diseño y construcción del producto final. En este sentido es fundamental para los estudiantes de asignaturas de ingeniería de software y afines, reconocer, distinguir y clasificar claramente estos requisitos.

En este trabajo se propuso como aporte el diseño y construcción de un videojuego para el reconocimiento y diferenciación de requisitos funcionales y no funcionales. Este videojuego pretende servir como apoyo didáctico al docente de los cursos asociados a la ingeniería de software, con el fin de mejorar las habilidades de sus estudiantes en la identificación y definición de requisitos.

La metodología empleada para la construcción del videojuego de clasificación de requisitos, permitió identificar ciertos elementos claves a la hora de construir aplicaciones centradas en el usuario. En este sentido, en la fase de diseño además de posibilitar la definición de la lógica funcional del juego, se identificaron elementos que podían ser mejorados en la fase de construcción, como es el caso de la representación visual de las cestas de requisitos, las cuales se cambiaron por carpetas. Así mismo, en la fase de evaluación del videojuego, orientada a una revisión de usabilidad, se identificaron diferentes aspectos funcionales a considerar para hacer más usable la aplicación, como resultado del análisis de las diez heurísticas, para el caso puntual del videojuego descrito en el presente artículo.

La evaluación realizada al videojuego permitió evidenciar según la opinión de los docentes expertos en ingeniería de software, que el juego es sencillo e intuitivo para la interacción con el usuario final. Sin embargo, es posible mejorar ciertos aspectos como la inclusión de las definiciones de requisito funcional y no funcional en la ayuda del juego, así como la discriminación en el puntaje de los aciertos en los dos tipos de requisitos. De este modo, la evaluación de usabilidad realizada busca refinar la calidad del prototipo generado con el fin de que resulte más cercano a los usuarios finales, en este caso los estudiantes del área de ingeniería de software, al momento de hacer uso de este videojuego en el aula en un escenario real.

La plataforma GDevelop demostró ser adecuada para el diseño y construcción de recursos que pueden ser utilizados en el aula de clase. Esta plataforma está dirigida a usuarios no expertos en programación y hace uso de programación orientada a eventos y acciones de manera gráfica, por lo que resulta intuitiva y con una curva de aprendizaje menor a la de los lenguajes de programación convencionales. Adicionalmente esta plataforma permite la exportación del videojuego a diferentes plataformas, aportando ventajas de portabilidad y flexibilidad.

Como trabajo futuro derivado de esta investigación se tiene: 1) incorporar en el videojuego las mejoras sugeridas por los docentes expertos y generar una nueva versión del videojuego, 2) aplicar esta nueva versión del videojuego en diferentes cursos de ingeniería de software para evaluar el aporte a nivel del aprendizaje en los estudiantes del área de ingeniería de software, y 3) incluir en el videojuego la clasificación de requisitos no funcionales en las subcategorías rendimiento, fiabilidad, exactitud, entre otras.

References

Referencias

Berzal, F. (2006). El ciclo de vida de un sistema de información. Granada-España: Universidad de Granada.

Borgida, A., Dalpiaz, F., Horkoff, J., & Mylopoulos, J. (2013). Requirements models for design- and runtime: A position paper. 5th International Workshop on Modeling in Software Engineering (MiSE) (págs. 62-68). San Francisco, CA, USA: IEEE.

Buitrón, S., Flores-Rios, B., & Pino, F. (2018). Elicitación de requisitos no funcionales basada en la gestión de conocimiento de los stakeholders. Revista Ingeniare, 26(1), 142-156.

Chung, L., & do Prado Leite, J. (2009). On Non-Functional Requirements in Software Engineering. En V. Chaudhri, G. P., & E. Yu, Conceptual Modeling: Foundations and Applications. Lecture Notes in Computer Science (págs. 363-364). Springer, Berlin, Heidelberg.

Cuartas, J. (2016). Creación de videojuegos con GDevelop. Bogota, Colombia: Fundación Universitaria Los Libertadores.

Durán, E. (2011). El uso del uml en la fase de análisis del proceso de desarrollo de un software educativo. Revista Ingeniería Solidaria, 7(12-13), 83-91.

Enriquez, J., & Casas, S. (2013). Usabilidad en aplicaciones móviles. Informe Científico Técnico UNPA, 25-47.

Gasca-Hurtado, G., Muñoz, M., Mejia, J., & Calvo-Manzano, J. (2014). Software Requirements Development: A Path for Improving Software Quality. Communications in Computer and Information Science, 425, 194-205.

Henriksen, D., Richardson, C., & Rohit, M. (2017). Design Thinking: A Creative Approach to Educational Problems of Practice. Thinking Skills and Creativity, 26, 140-153.

IEEE Std. 830-1998. (2008). Especificación de Requisitos según el estándar IEEE 830. Obtenido de https://www.fdi.ucm.es/profesor/gmendez/docs/is0809/ieee830. pdf

Jabangwe, R., Edison, H., & Nguyen, A. (2018). Software engineering process models for mobile app development: A systematic literature review. Journal of Systems and Software, 145, 98-111.

Laird, L. (2016). Strengthening the "Engineering" in Software Engineering Education: A Software Engineering Bachelor of Engineering Program for the 21st Century. IEEE 29th International Conference on Software Engineering Education and Training (CSEET) (págs. 128-131). Dallas-USA: IEEE.

Lauenroth, K., Kamsties, E., & Hehlert, O. (2017). Do Words Make a Difference? An Empirical Study on the Impact of Taxonomies on the Classification of Requirements. IEEE 25th International Requirements Engineering Conference (RE) (págs. 273282). Lisbon: IEEE.

Mall, R. (2018). Fundamentals of Software Engineering. Delhi: PHI Learning.

Medina, J., Hernández, V., Alonso, L., & Solis, E. (2012). Análisis de Ingeniería de Requerimientos: Alta de Unidades de Aprendizaje en la UAI-Agro (México). Revista Vinculos, 25-40.

Melegati, J., Goldman, A., Kon, F., & Wang, X. (2019). A model of requirements engineering in software startups. Information and Software Technology, 109, 92-107.

Mutis, E. (2016). Diseño de una Aplicación dirigida al área de la salud para el control de agendamiento de citas y servicios domiciliarios médicos para pacientes. Catalunya: Universitat Oberta de Catalunya.

Pérez-Ortega, I. (2017). Creación de Recursos Educativos Digitales: Reflexiones sobre Innovación Educativa con TIC. International Journal of Sociology of Education, 244-268.

Pinelle, D., Wong, N., & Stach, T. (2008). Heuristic Evaluation for Games: Usability Principles for Video Game Desing. CHI 2008 Proceedings - Game Zone, (págs. 1453-1462). Florencia-Italia.

Razzouk, R., & Shute, V. (2012). What Is Design Thinking and Why Is It Important? Review of Educational Research, 82(3), 330-348.

Serrano, M., & Blázquez, P. (2015). Design Thinking - Lidera el presente, crea el futuro. Madrid: ESIC Editorial.

Valentim, N., & Conte, T. (2014). Improving a Usability Inspection Technique Based on Quantitative and Qualitative Analysis. Brazilian Symposium on Software Engineering (págs. 171-180). Maceio: IEEE.

Vetterli, C., Brenner, W., Uebernickel, F., & Petrie, C. (2013). From palaces to yurts: Why requirements engineering needs design thinking. IEEE Internet Computing, 17(2), 91-94.