Propuesta metodológica para el análisis y diseño de chatbots basados en texto

Universidad de Valladolid Escuela de Ingenieria Informa´tica TRABAJO DE FIN DE MA ´STER Ma´ster en Ingenierı´a Informa´tica Propuesta Metodolo´gica para el ana´lisis y disen˜o de Chatbots basados en texto Autor: Juan Alonso Astruga Tutores: Alejandra Martı´nez Mone´s Eduardo Go´mez Sa´nchez Titulo: Propuesta metodolo´gica para el ana´lisis y disen˜o de chatbots basados en texto Autor: Juan Alonso Astruga Tutores: Alejandra Martı´nez Mone´s Eduardo Go´mez Sa´nchez ii Agradecimientos Antes de comenzar el trabajo, querı´a dar las gracias a todos los que me han ayudado a terminar esta etapa de mis estudios. En lo acade´mico, gracias a todos los profesionales de la ETSII que se han esforzado para completar nuestra formacio´n como ingenieros. Especialmente querı´a dar las gracias a los tutores de este Trabajo Fin de Ma´ster, Alejandra y Eduardo, por todas las dudas resueltas, el apoyo y el feedback en la realizacio´n de este trabajo. En lo personal, querı´a agradecer a mi familia por tener la comprensio´n y paciencia para apoyarme durante el ma´ster. Gracias a todos. iii iv Resumen Los chatbot basados en texto son agentes conversacionales aplicados ampliamente en la interaccio´n con el usuario, sobre todo para la respuesta a preguntas en torno a productos o servicios. En la actualidad existen muchas propuestas tecnolo´gicas que apoyan el desarrollo de estos sistemas, aportando servicios basados en inteligencia artificial, etc. Sin embargo no hay metodologı´as usadas en la actualidad realmente para llevar a cabo su ana´lisis y disen˜o. Por ello se propone una metodologı´a para la elicitacio´n de requisitos y disen˜o de chatbots de preguntas y respuestas. En este trabajo se presenta IMADTC (Iterative Methodology for the Analysis and Development of Textual Chatbots) que pretende dar respuesta a los problemas relacionados con el desarrollo de un chatbot, de forma que a trave´s de la seleccio´n de te´cnicas necesarias de elicitacio´n de requisitos se pueda llevar a cabo la creacio´n de un chatbot textual orientado a preguntas y respuestas. La propuesta es validada mediante su uso en el disen˜o de un chatbot de este tipo y sobre la que se realizan recomendaciones de aplicacio´n y mejoras a la propuesta. v vi I ´ndice general 1. Introduccio´n 1 1.1. Presentacio´n ................................................. 1 1.2. Motivacio´n .................................................. 1 1.3. Objetivos ................................................... 2 1.4. Metodologı´a.................................................. 2 1.5. Contenidodeldocumento .......................................... 3 2. Chatbots: Concepto y retos de desarrollo 5 2.1. Agentes conversacionales y chatbots: concepto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Uso de chatbots basados en texto en distintos contextos . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Chatbots en el contexto educativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Retos para el desarrollo de chatbots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4.1. RetosTecnolo´gicos.......................................... 7 2.4.2. RetosConceptuales ......................................... 7 2.4.3. Retos especı´ficos al caso VirtualForest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. Ana´lisis de alternativas tecnolo´gicas al uso de Chatbots . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5.1. Criteriosdelana´lisis ......................................... 10 2.5.2. Sistemas considerados y ana´lisis realizado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.3. Conclusio´n del ana´lisis tecnolo´gico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6. Metodologı´as de desarrollo de chatbots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6.1. Metodologı´as orientadas hacia el desarrollo del sistema . . . . . . . . . . . . . . . . . . . . . . 20 2.6.2. Conversation Driven Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.7. Conclusio´ndelcapı´tulo ........................................... 23 3. Ana´lisis de te´cnicas de elicitacio´n de requisitos en chatbots 25 3.1. Clasificacio´n de te´cnicas de elicitacio´n de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2. Seleccio´ndete´cnicas............................................. 26 3.2.1. Te´cnicasdemodelado ........................................ 27 3.2.2. Te´cnicasdeprototipado....................................... 28 3.2.3. Te´cnicasAgile ............................................ 28 3.3. Seleccio´n de te´cnicas de ana´lisis de requisitos para chatbots . . . . . . . . . . . . . . . . . . . . . . . 28 3.3.1. Te´cnicas a aplicar en la variabilidad del lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2. Te´cnicas a aplicar en el control del dia´logo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.4. Criterios de validacio´n de las te´cnicas seleccionadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.4.1. Userstories.............................................. 30 3.4.2. Escenarios............................................... 30 3.4.3. UsodePrototipos .......................................... 31 3.4.4. Laddering............................................... 31 3.5. Conclusio´n de la seleccio´n de te´cnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 vii 4. Propuesta Metodolo´gica 33 4.1. Objetivos a cumplir con la propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.2. Estructura de la Propuesta IMADTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3. Validacio´ndelapropuesta.......................................... 36 4.3.1. Validacio´n de las te´cnicas incorporadas en la metodologı´a . . . . . . . . . . . . . . . . . . . . 36 4.3.2. Validacio´n de la informacio´n obtenida por la aplicacio´n de la metodologı´a . . . . . . . . . . . 38 4.4. Conclusio´ndelametodologı´a ........................................ 38 5. Aplicacio´n y Evaluacio´n de la propuesta 39 5.1. Organizacio´ndeltrabajo........................................... 39 5.2. Contextualizacio´n de los participantes en los test de usuario . . . . . . . . . . . . . . . . . . . . . . . 39 5.3. Artefactos elaborados por la aplicacio´n de la propuesta . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.1. Contextualizacio´n del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.2. Seleccio´n de objetivos a trave´s de user stories . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.3.3. Disen˜odeescenarios......................................... 44 5.3.4. Disen˜o del Flujo Conversacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 5.4. Ana´lisisdelsistema.............................................. 61 5.4.1. Requisitos funcionales del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.4.2. RequisitosNoFuncionales...................................... 64 5.4.3. RequisitosdeInformacio´n...................................... 65 5.4.4. Actoresdelsistema.......................................... 65 5.4.5. CasosdeUso ............................................. 66 5.4.6. Diagramadeclases.......................................... 71 5.5. Desarrollodelsistema ............................................ 71 5.6. Pruebasdelsistema ............................................. 72 5.6.1. PruebasdeCajaBlanca....................................... 72 5.6.2. PruebasdeCajaNegra ....................................... 72 5.7. Evaluacio´ndelapropuesta ......................................... 82 5.7.1. Evaluacio´n de las te´cnicas de elicitacio´n de requisitos utilizadas . . . . . . . . . . . . . . . . . 82 5.7.2. Evaluacio´n general de la aplicacio´n de la propuesta . . . . . . . . . . . . . . . . . . . . . . . . 85 5.8. Discusio´n ................................................... 87 5.9. Conclusio´ndelcapı´tulo ........................................... 89 6. Conclusiones y trabajo futuro 91 Bibliografia 92 Ape´ndice A: Acro´nimos 100 Ape´ndice B: Co´digo del backend del prototipo de VirtualForest 100 viii Tema: Contextualizacio´n de chatbots Te´rminos de bu´squeda: chatbot, application, domain, education.Cadenas de bu´squeda: (chatbot AND domain), (chatbot AND application), (chatbot AND education). Inspeccionados: 30 ([3], [4], [5], [6], [7], [8], [9], [10], [11], [12], [13], [14], [15], [16], [17], [18], [19], [20], [21], [22], [23], [24], [25], [26], [27], [28],[29], [30], [31], [32]). Seleccio´n: 12 ([5], [17], [19], [22], [23], [25], [26], [27], [28], [30], [31], [32]). Tema: Metodologı´as de desarrollo de chatbots Te´rminos de bu´squeda: methodology, dialog, system, agent.Cadenas de bu´squeda: (methodology AND ( dialog AND (system OR agent))) OR (dialog AND (system OR agent)). Inspeccionados: 18 ([33], [34], [35], [36], [37], [38], [39], [40], [41], [42], [43], [44], [45], [46], [47], [48], [49], [50], [51]). Seleccio´n: 5 ([41], [51], [50], [34], [49]). Tema: Problemas asociados al desarrollo de los chatbots Te´rminos de bu´squeda: problem, difficulty, error, chatbot, development, dialog, structure, control, expresion, context, validation.Cadenas de bu´squeda: ((problem OR difficulty OR error) AND chatbot AND development),(dialog AND structure AND control),(context AND (dialog OR expression) AND validation). Inspeccionados: 20 ([52], [53], [54], [55], [56], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [68], [69], [70]). Seleccio´n: 16 ([52], [54], [55], [57], [58], [59], [60], [61], [62], [63], [64], [65], [66], [67], [69], [70].) Tema: Te´cnicas de elicitacio´n de requisitos Te´rminos de bu´squeda: software, requirements, elicitation, techniques, review, user story, prototyping, laddering, escenario.Cadenas de bu´squeda: (software AND requirements AND elicitation) AND (techniques OR review). Inspeccionados: 22 ([71], [72], [73], [74], [75], [76], [77], [78], [79], [80], [81], [82], [83], [84], [85], [86], [87], [88], [89], [90], [91], [92]). Seleccio´n: 12 ([71], [75], [77], [80], [81], [84], [85], [87], [88], [89], [90], [91]). Tabla 1.1: Tabla ana´lisis bibliogra´fico 4 Capı´tulo 2 Chatbots: Concepto y retos de desarrollo Para poder proponer una metodologı´a efectiva para la especificacio´n de requisitos de un chatbot textual se debe conocer previamente que´ papeles va a desarrollar un chatbot como sistema, que´ problemas han de abordarse en esa metodologı´a y co´mo, si es que existe solucio´n, en la bibliografı´a disponible se han abordado estos problemas en posibles alternativas metodolo´gicas. Por ello en este capı´tulo se expone el papel de un chatbot basado en texto dentro del contexto de tareas relacionadas con preguntas y respuestas en el dominio de la educacio´n, ası´ como los retos existentes a la hora de llevar a cabo el desarrollo de un chatbot, las alternativas tecnolo´gicas que se han propuesto para afrontar dichos retos, y las metodologı´as existentes para el desarrollo de un sistema de este tipo. 2.1. Agentes conversacionales y chatbots: concepto Un agente conversacional es un programa de software que interpreta y responde a frases enunciadas por los usuarios en lenguaje natural [93]. Los agentes conversacionales son un sistema de dia´logo que lleva a cabo procesamiento del lenguaje natural (Natural Language Processing) y responde a la solicitud en un lenguaje natural para un humano. Estos se dividen generalmente en dos tipos: agentes de dia´logo orientados a la tarea y chatbots [94]. Los agentes de dia´logo orientados a la tarea [94] son sistemas programados para completar una tarea en especı´fico que utilizan conversaciones cortas con el usuario para ayudar a completar esta tarea. Estos sistemas suelen seguir un flujo de dia´logo, basado en una ma´quina de estados finita, con una estructura programada de antemano para llevar a cabo la conversacio´n, y donde el sistema determina la direccio´n de la conversacio´n, hace preguntas a los usuarios y, por lo general, malinterpreta o ignora una entrada que no sea una respuesta directa a la pregunta previamente realizada. Los chatbot [94] son sistemas conversacionales que, a trave´s de te´cnicas basadas en inteligencia artificial, intentan simular e imitar el flujo no estructurado de la conversacio´n humana. Los chatbots son diferentes a los agentes conversacionales dirigidos a la tarea, ya que aprovechan las posibilidades de las te´cnicas de inteligencia artificial para responder a las conversaciones humanas con un conjunto especı´fico de respuestas predefinidas, coherentes con la situacio´n, para simular comprender la intencio´n del usuario y analizar el contexto del discurso. 2.2. Uso de chatbots basados en texto en distintos contextos Dada la versatilidad de los chatbots a la hora de mantener una conversacio´n y su proliferacio´n durante los u´ltimos an˜os, ha favorecido su aplicacio´n a numerosos contextos de uso. Entre estos contextos se puede citar algunos de los ma´s importantes como servicio al cliente y salud y bienestar fı´sico. Para el uso de un chatbot dedicado a dar soporte al servicio a clientes, muchas empresas utilizan chatbots para 5 la ayuda a sus consumidores. El uso de un chatbot como parte del servicio al cliente permite prestar atencio´n las 24 horas del dı´a a trave´s del chatbot, lo que permite a los consumidores realizar solicitudes independientemente del horario de atencio´n esta´ndar, mejorando la satisfaccio´n del usuario. La incorporacio´n de un chatbot [31] a un modelo tradicional de atencio´n al cliente puede mejorar la experiencia de e´ste, principalmente en la medida de la capacidad de respuesta, mientras mantiene un nivel similar [30] en las dimensiones de calidad de la informacio´n, calidad del sistema y satisfaccio´n del usuario. En el caso del contexto de salud y bienestar fı´sico, la inteligencia artificial (IA) se utiliza cada vez ma´s en la asistencia sanitaria. Aquı´, los sistemas de chatbot basados en inteligencia artificial pueden actuar como agentes conversacionales automatizados, capaces de promover la salud, e incluso [28] diagnosticar enfermedades en una interaccio´n con los usuarios a trave´s de una interfaz de texto. Otras aplicaciones dentro de este campo permiten la prestacio´n de atencio´n sanitaria ra´pida [27] en caso de accidentes que pueden ocurrir en la vida cotidiana, y tambie´n en respuesta a los cambios de las condiciones de los pacientes con enfermedades cro´nicas. Otro a´mbito en el que han despertado intere´s es el de la educacio´n, que se desarrolla en la siguiente seccio´n. 2.3. Chatbots en el contexto educativo Los chatbots se pueden utilizar en entornos de aprendizaje formales e informales y pueden proporcionar a los alumnos un apoyo adaptado a sus necesidades. Se han propuesto diferentes usos potenciales para los chatbots en contextos educativos. Por ejemplo, los chatbots para el apoyo al aprendizaje pueden preservar la informacio´n repitiendo lecciones pasadas cuando los estudiantes no pueden asistir a ellas. Tambie´n pueden recopilar informacio´n durante un curso para la mejora del proceso de aprendizaje y la ensen˜anza. Estos chatbots pueden permitir a los estudiantes el acceso a las lecciones en el momento que mejor les convenga, estando disponibles en cualquier horario de estudio y pudiendo responder preguntas relacionadas con el material educativo. Un chatbot orientado a la educacio´n puede ayudar a los estudiantes con problemas administrativos relacionados con la inscripcio´n y administracio´n de asignaturas de un curso. Estos ejemplos muestran algunos de los papeles que puede adoptar un chatbot en este contexto. De acuerdo a la investigacio´n realizada por Sofie Roos [26], existen roles tı´picos de los chatbots en el contexto educacional: ˂˂conversacio´n natural˃˃,˂˂comunicacio´n con el profesor o el entorno de aprendizaje˃˃,˂˂preguntas y respuestas˃˃, y ˂˂evaluacio´n y correccio´n del estudiante˃˃. En el caso de Chatbots con el rol de Conversacio´n Natural, el chatbot mantiene una conversacio´n en lenguaje natural con el estudiante con el objetivo de mejorar las habilidades del estudiante en torno a escritura y lectura comprensiva de textos. Es decir, el objetivo es simplemente el forzar al estudiante a mantener una conversacio´n simple con el chatbot. Casi siempre esto esta´, en esta tema´tica, asociado al aprendizaje de un lenguaje distinto a la lengua materna del estudiante. Un ejemplo de esto es el sistema interactivo desarrollado por la Universidad Carlos III de Madrid [25] para crear un mundo 3D de interaccio´n multiusuario en el que las interacciones con el chatbot a trave´s de personajes virtuales fuerzan a los estudiantes a mantener conversaciones en una lengua distinta de la propia. En el rol de Comunicacio´n con el Profesorado, el chatbot se usa como medio de interaccio´n de los estudiantes tanto con el medio de aprendizaje como con el profesor. El chatbot tiene dos funciones [23]: La primera es recopilar datos de las conversaciones mantenidas con el estudiante sobre el entorno educativo, para mejorar este, y la segunda es intentar por su propia cuenta contestar en primera instancia las preguntas que le dirije el alumno y si no lo realiza con suficiente confianza, trasladar la pregunta o preguntas al profesor. Bajo el rol de Preguntas y Respuestas el chatbot es preparado para contestar una serie de preguntas sobre una tema´tica concreta que el alumno estudiara´. En ocasiones tambie´n se utiliza para resolver preguntas en torno a cuestiones administrativas [22]. El objetivo aquı´ no es evaluar el conocimiento del alumno, si no resolver las dudas que les surjan durante su proceso de aprendizaje [5] [19]. E ´ste es el rol ma´s documentado, sobre el que ma´s se ha trabajado y con ma´s implementaciones de todos los descritos. El trabajo de estos chatbots suele ser simple porque los conocimientos ya esta´n programados con anticipacio´n. Los me´todos de implementacio´n utilizados en esta aplicacio´n suelen incluir la coincidencia de patrones, el procesamiento del lenguaje natural y la minerı´a de 6 datos. El chatbot harı´a coincidir la oracio´n de entrada del hablante o usuario con ese patro´n existente en la base de conocimientos. Luego, cada patro´n se compara con el conocimiento del chatbot. Para el caso de Evaluacio´n del estudiante [17], el objetivo a perseguir es que se evalu´e el progreso del estudiante en el aprendizaje de una materia en concreto al mismo tiempo que se corrigen los errores cometidos por el alumno en el aprendizaje de la tarea y se da feedback al profesor de los progresos de cada estudiante en la misma. Dado que el trabajo a realizar como parte del TFM esta´ relacionado con un chatbot en el contexto educativo, comprender e´ste supone un punto importante en el trabajo a realizar. Esta informacio´n sobre el rol que puede desempen˜ar el chatbot en el contexto de educacio´n sera´ tenida en cuenta en una parte posterior de este documento sobre la contextualizacio´n del chatbot desarrollado. Nos centraremos en el rol de los chatbots de preguntas y respuestas, por ser el rol del chatbot del caso que ha motivado el trabajo y porque son el tipo de chatbot que ma´s se llega a implementar dentro de los roles que puede llevar a cabo un chatbot como sistema conversacional. 2.4. Retos para el desarrollo de chatbots El desarrollo de chatbots requiere experiencia en a´reas especializadas, como el aprendizaje automa´tico y el procesamiento del lenguaje natural, lo que lo distingue del desarrollo de software tradicional. Es por tanto importante el comprender los problemas a los que se enfrenta un desarrollador de este tipo de sistemas antes de hacer una propuesta para su disen˜o, que permita incrementar la calidad del chatbot y su adopcio´n por usuarios finales. Para ilustrar estos problemas nos vamos a basar en el trabajo presentado por Abdellatif y cols. [52], donde se estudio´ la cantidad de preguntas formuladas por desarrolladores en foros de ayuda en lı´nea como StackOverflow en torno a los problemas ma´s comunes y de mayor dificultad de resolucio´n en el disen˜o de chatbots. Los problemas encontrados se han dividido en dos grupos segu´n su causa: retos tecnolo´gicos y retos conceptuales. Los retos tecnolo´gicos son causados por el uso de la tecnologı´a seleccionada para el desarrollo del chatbot. Los retos conceptuales por el contrario se derivan de una mala interpretacio´n del contexto y la informacio´n relevantes para el chatbot. A continuacio´n se exponen estos dos grupos de problemas y finalmente se exponen los problemas especı´ficos del caso de VirtualForest. 2.4.1. Retos Tecnolo´gicos Los retos tecnolo´gicos abarcan las categorı´as de integracio´n, desarrollo y NLU. Estos incluyen: Problemas derivados de la integracio´n con plataformas tecnolo´gicas, problemas derivados con la programacio´n del desarrollo del propio chatbot y problemas derivados del NLU. La categorı´a de integracio´n recoge los temas de las integraciones entre distintos servicios y la plataforma de chatbot, ası´ como la integracio´n del chatbot desplegado y los entornos web. Dentro de esta categorı´a esta´n los problemas relacionados con integracio´n de tecnologı´as especı´ficas y con el uso de API para realizar la comunicacio´n entre el chatbot y canales externos al mismo. La categorı´a de desarrollo abarca problemas relacionados con la construccio´n de chatbots usando diferentes plataformas y frameworks de desarrollo, problemas sobre configuraciones y caracterı´sticas determinadas de la plataforma escogida, e implementaciones especı´ficas usando esas plataformas. En la categorı´a de NLU se agrupan los problemas relacionados con la especificacio´n de intents yentities, ası´ como su uso y configuracio´n. Tambie´n abarca la personalizacio´n y configuracio´n de te´cnicas de NLU en las plataformas de desarrollo, y de mejora del rendimiento en el entrenamiento de los modelos para NLU. Viendo la naturaleza de los problemas tecnolo´gicos se decidio´ que la forma de evitarlos en la medida de lo posible a la hora de realizar un desarrollo de chatbots basado en estos servicios serı´a el realizar un ana´lisis de las alternativas para el desarrollo de chatbots actualmente existentes (ver seccio´n 2.5). 2.4.2. Retos Conceptuales De los cinco problemas principales identificados, los tres primeros problemas han sido de a´mbito tecnolo´gico, basa´ndose su solucio´n en escoger la tecnologı´a ma´s adecuada para cada situacio´n. Los dos u´ltimos problemas identificados (la variabilidad de las entradas proporcionadas por el usuario y el control del dia´logo en la conversacio´n con el usuario), por el contrario, basan su dificultad no en un problema de la plataforma, como en el caso anterior, 7 sino en la potencial mala comprensio´n de la intencio´n del usuario al interaccionar con el sistema, un problema que se debe tratar en el proceso de ana´lisis del mismo con te´cnicas de elicitacio´n de requisitos y con una metodologı´a de disen˜o adecuada. Variabilidad del lenguaje El primer problema detectado que puede ocasionar errores en un proceso de elicitacio´n de requisitos es la variabilidad de las formas de expresarse que puede usar el usuario para comunicar una accio´n al chatbot, especialmente en el caso de los sistemas basados en el NLU como me´todo de aprendizaje y procesamiento de entradas del usuario. A la hora de controlar la variabilidad del lenguaje hay que tener en cuenta la influencia del contexto en la educacio´n lingu¨ı´stica del usuario. La naturaleza y magnitud de los efectos ambientales, del contexto, tiene diferentes grados de influencia en el desarrollo del lenguaje que adquiere una persona [59]. Al igual que otros aspectos del comportamiento interpersonal, el uso del lenguaje se socializa para que coincida con las expectativas de la comunidad en cada momento. No solo eso, sino que a lo largo de la vida, caracterı´sticas personales, por ejemplo, edad, alfabetizacio´n, habilidades del lenguaje, etc. modulan los efectos del contexto en la comprensio´n y uso del lenguaje por parte de una persona [60] y por tanto influyen en la seleccio´n de expresiones, palabras y la forma de articular una frase para expresar una idea. La variabilidad del tono adecuado con que el chatbot se comunica con el usuario esta´ relacionado con la variabilidad del lenguaje, ya que la introduccio´n de ma´s de un tono y de formas de expresarse dentro de una misma conversacio´n con el usuario puede conducir a que este responda tambie´n en mu´ltiples tonos incrementando no solo la variabilidad de las frases de entrada que el chatbot reciba sino la confusio´n del propio usuario [61]. Esto implica que el uso de un cierto registro [62] en un cierto contexto de conversacio´n pueden aumentar la comprensio´n y satisfaccio´n del usuario al usar el chatbot. La variabilidad de las expresiones usadas para llevar a cabo la comunicacio´n con el chatbot suponen un problema a la hora de realizar una especificacio´n de requisitos. Formas de expresarse en lenguaje natural que son equivalentes para el usuario pueden provocar resultados diferentes bajo la interpretacio´n del chatbot, dependiendo de su preparacio´n previa, que puede causar una especificacio´n de requisitos sobre declaraciones ambiguas por parte del usuario de que´ es lo que quiere conseguir en su interaccio´n con el sistema [63]. Dado que en la mayorı´a de los casos no es posible llevar a cabo una especificacio´n de todas las posibilidades de expresio´n por parte del usuario de una intencio´n al interactuar con el chatbot, una posible solucio´n [64] consiste en asignar una probabilidad como requisito no funcional bajo la que se reconocerı´a un nu´mero de veces determinado la intencio´n del usuario de forma correcta a la hora de comunicarse con el chatbot. Aunque te´cnicamente este es un requisito medible y verificable, puede distar del resultado esperado por el cliente segu´n el conjunto de frases de prueba y las variaciones introducidas en ellas para demostrarlo, por lo que no se puede considerar como una solucio´n completa. Control del dia´logo El segundo problema a solventar es co´mo controlar la variabilidad en la estructura que se da en un dia´logo si se esta´ utilizando e´ste como herramienta para conseguir un objetivo concreto. La mayorı´a de las veces los participantes de un dia´logo lo inician con el objetivo de lograr algu´n objetivo subyacente. Tales metas son de naturaleza no comunicativa, y lograrlas requiere ma´s que utilizar solo la comunicacio´n. Tambie´n requiere sopesar y comparar informacio´n y decidir co´mo se va a guiar la conversacio´n para obtener la meta, en funcio´n de la informacio´n proporcionada y de las sub-metas que se vayan generando en el desarrollo del dia´logo [65]. Al llevar a cabo un proceso de elicitacio´n de requisitos es difı´cil describir de forma clara la necesidad de mantener un contexto de dia´logo con el sistema que determine como evoluciona la conversacio´n. Desde el punto de vista de ana´lisis bajo UML esto se suele reservar a diagramas de actividad o del estilo de ma´quinas de estado [66], o a representaciones donde el dia´logo se desarrolla sobre un contexto especı´fico y el nu´mero de transiciones de informacio´n entre distintos posibles estados es conocido y por tanto controlable con mayor o menor esfuerzo. En estas formas para especificar al completo el dia´logo a llevarse a cabo para conseguir un objetivo concreto, si el dominio del dia´logo es cambiante, la completitud sera´ un problema an˜adido a resolver. El dia´logo adema´s sera´ especı´fico del idioma, dependiente de la cultura, y de otros aspectos contextuales, en particular en aspectos sociales 8 como el marco institucional en el que ocurre el dia´logo, y el tipo de evento comunicativo que representa el dia´logo. Para evitar me´todos en los que haya que encontrar todas las posibilidades de dia´logo, una opcio´n consiste en utilizar me´todos de prediccio´n como los basadas en Markov [67] donde dependiendo del estado anterior del sistema y un conjunto de probabilidades obtenidas que determinan la accio´n a realizar es posible determinar el estado subsiguiente en el dia´logo [69]. Por tanto, el reconocimiento del contexto, cambiante o no, como punto de influencia en la comprensio´n del dia´logo [70] es un factor que se debe tener en cuenta a la hora de resolver este problema. Los dos problemas expuestos a la hora de analizar los requisitos para el desarrollo de un chatbot comparten la caracterı´stica de depender de las circunstancias que influyen en el usuario en el momento determinado de interaccionar con el chatbot. Esto es ası´ tanto para expresarse de una forma especı´fica frente a otras opciones, como para en una conversacio´n decantarse por una opcio´n que guie el dia´logo frente a otras. Es por eso importante que se preste atencio´n al contexto conversacional en el que se encuentra inmerso el usuario para, de esta forma, poder limitar las opciones posibles que baraje a la hora de comunicarse con el chatbot. Esto tendra´ que ser tenido en cuenta a la hora de seleccionar te´cnicas de elicitacio´n de requisitos apropiadas para nuestro problema. 2.4.3. Retos especı´ficos al caso VirtualForest Adema´s de los problemas conceptuales anteriormente descritos, el trabajo a realizar en un desarrollo de sistemas basados en chatbots textuales orientados a una tarea de pregunta y respuesta tiene, en nuestro caso, estos problemas por parte de los clientes que las te´cnicas deben tener en cuenta: Poca claridad a la hora de delimitar las tareas que debe y no debe realizar el chatbot proyectado. Poca claridad a la hora de delimitar que´ informacio´n debe o no conocer el chatbot con respecto a las tareas a realizar. Claridad en cuanto a la especificacio´n del problema a resolver pero no tanto en el co´mo se debe resolver. Poca confianza en cuanto al resultado a obtener mediante el sistema proyectado. Poca disposicio´n en cuanto a tiempo para interactuar resolviendo los problemas anteriores. Una vez hemos examinado los problemas existentes, es conveniente revisar, por un lado, las propuestas tecnolo´gicas existentes para el desarrollo de chatbots, que sera´n necesarias para realizar la implementacio´n de nuestro caso de prueba; y por otro, las metodologı´as propuestas para el disen˜o de chatbots, que necesitamos analizar para valorar y construir sobre ellas nuestra propuesta. Las alternativas tecnolo´gicas se revisan en la seccio´n 2.5. y las metodologı´as existentes, en la seccio´n 2.6. 2.5. Ana´lisis de alternativas tecnolo´gicas al uso de Chatbots Se presenta en esta seccio´n un ana´lisis de las alternativas tecnolo´gicas para el desarrollo de chatbots. Se ha partido de las alternativas presentadas en el documento correspondiente al proyecto ColMOOC [95] de implementacio´n de chatbots para fines de apoyo en la educacio´n. La seleccio´n del estudio de ColMOOC para determinar que´ alternativas se consideran en el ana´lisis se decidio´ debido a que este estudio tiene una tema´tica similar a la de este trabajo, por lo que tiene sentido usar la seleccio´n de alternativas tecnolo´gicas consideradas en e´l. El me´todo seguido para realizar este ana´lisis ha consistido en seleccionar (de acuerdo a criterios relacionados con los problemas de cara´cter tecnolo´gico especificados como relevantes para la problema´tica presentada en este TFM) aquellas alternativas que sean adecuadas para el trabajo a realizar. Se presentan a continuacio´n los criterios utilizados y el resultado y conclusiones del ana´lisis. 9 2.5.1. Criterios del ana´lisis Los criterios utilizados a la hora de analizar las tecnologı´as han sido los siguientes: Disponibilidad: Licencia bajo la que opera el sistema y precios de concesio´n de licencia para uso, desarrollo y comercializacio´n de derivados del producto. Definicio´n del modelo del agente en el sistema: Que´ elementos constituye una definicio´n del agente, si dispone de los elementos tı´picos en un chatbot, es decir, intents, entities y contextos del dia´logo y co´mo es su uso en el sistema. Co´mo se realiza el procesamiento del lenguaje natural en el sistema: Que´ se necesita para que el sistema lleve a cabo el procesamiento del lenguaje natural en el sistema y co´mo se mejora la identificacio´n de secciones clave dentro de una oracio´n como el intent o las entities. Idiomas del sistema: En que´ idiomas esta´ disponible el sistema para llevar a cabo el procesamiento del lenguaje natural, si se requiere entrenar el sistema para que sea capaz de reconocer oraciones en espan˜ol e ingle´s o si requiere software adicional. Interfaces del sistema: interfaces de interaccio´n con el sistema. Tanto interaccio´n a la hora de realizar la programacio´n y creacio´n del agente conversacional como a la hora de interactuar con el sistema a partir de otros sistemas clientes. Tratamiento de datos aportados por los usuarios: Co´mo es el tratamiento que se hace de los datos de los usuarios al hacer estos uso del sistema, se necesita saber si se mantiene la confidencialidad de los datos aportados, si estos datos son usados para la mejora del sistema o si estos datos son cedidos para uso de terceros. 2.5.2. Sistemas considerados y ana´lisis realizado Sistemas considerados El listado completo de alternativas examinadas para llevar a cabo el ana´lisis es el siguiente: Rasa, ChatScript, Chatterbot, PandoraBots, WIT.ai, IBM Watson Conversation Service, DialogFlow, Azure Bot Service, Amazon Lex. Adema´s, del listado del documento original, se han descartado las siguientes alternativas: ChatFuel (https://chatfuel.com/): Descartada debido a que requiere de forma obligatoria el uso de Messenger u otra red social donde se despliega el bot. Octane.ai (https://www.octaneai.com/): Descartada debido a que tiene una orientacio´n de desarrollo demasiado centrada a la venta de productos y atencio´n al cliente. Agentbot (https://es.aivo.co/chatbot-agentbot): Descartada por la misma razo´n que la anterior, demasiado especializada para el servicio al cliente en entornos comerciales. Reply.ai (https://www.reply.ai/): Descartada ya que no parece permitir el desarrollo por parte de developers, no permite la edicio´n de co´digo y su funcionalidad esta´ muy limitada. Ana´lisis Tecnolo´gico Se procede a continuacio´n a mostrar el ana´lisis realizado: 10 Rasa (https://github.com/RasaHQ/rasa) Presentacio´n Rasa es una alternativa tecnolo´gica que proporciona un framework de aprendizaje basado en te´cnicas de Machine Learning para la construccio´n de sistemas conversacionales sobre voz y texto. Rasa utiliza el contenido de las conversaciones para entrenar el sistema de forma que se vuelva ma´s inteligente y responda con mayor precisio´n en las conversaciones con los usuarios. Disponibilidad Rasa es un producto Open Source bajo la licencia Apache 2.04, permite el uso comercial del producto, su modificacio´n, la distribucio´n del producto o de sus modificaciones, ası´ como el uso privado y patentado de productos derivados. Solo exige que se mantenga un aviso que informe a los receptores que en la distribucio´n se ha usado co´digo con la licencia Apache adema´s de la propia licencia. No se ofrecen garantı´as, ni derechos sobre la marca Rasa ni los autores se hacen responsables de perjuicios ocasionados por su uso. Definicio´n del modelo del agente en el sistema La definicio´n del agente conversacional para Rasa consiste en la definicio´n de lo que se llama dominios. Un dominio contiene los intent,entities,actions,slots yforms a los que el agente debe reaccionar y puede estar especificado entre uno o ma´s archivos YAML normalmente utilizando la notacio´n NLU. A mayores existen recursos como las stories y las rules que determinan la generalizacio´n a la hora de encontrar patrones en las conversaciones aportadas por los usuarios y permitir, a trave´s del Machine Learning, reconocer la intencio´n del usuario al hacer preguntas al bot, ası´ como permiten definir escenarios en los que se deben ejecutar una serie de pasos en un orden especifico. Procesamiento del lenguaje natural Rasa utiliza el NLU Training Data. Esto quiere decir que el procesamiento del lenguaje natural se basa en te´cnicas de Machine Learning sobre frases de ejemplo proporcionadas previamente. Los datos de entrenamiento de NLU consisten en expresiones aportadas comu´nmente por los usuarios, que se utilizan como ejemplo de aprendizaje y esta´n categorizadas en los diferentes intent disponibles. Estos ejemplos pueden contener el uso de entities previamente definidas, sino´nimos de te´rminos, expresiones regulares y tablas de referencia de te´rminos asociados. Para el entrenamiento de un intent se deben dar una serie de sentencias de ejemplo en texto plano anotadas con la informacio´n a reconocer sobre ellas y que se asociara´ al intent y posibilitando el incluir metadatos a aportar al intent una vez el agente reconozca sentencias similares. Idiomas en que esta´ disponible Permite el uso de mu´ltiples idiomas (entre ellos el espan˜ol) pero requiere de la aportacio´n de diccionarios de palabras para esos idiomas. Desde la propia pa´gina de Rasa se sugiere el uso de spaCy5o MITIE6para el uso de lenguajes pre-entrenados evitando el comenzar desde cero su entrenamiento. Interfaces de programacio´n disponibles La interfaz disponible para desarrolladores es la consola de comandos del sistema en el que se ha instalado. No existe otra forma de interaccionar con el agente que no sea mediante edicio´n de sus ficheros y la ejecucio´n de scripts a trave´s de la consola del mismo. Interfaces de comunicacio´n disponibles A la hora de comunicarse con el agente conversacional esta´ disponible una API accesible mediante peticiones HTTP que permite, a aplicaciones cliente, interactuar con el sistema. Tratamiento de datos aportados por los usuarios Dado que los datos pasan a ser parte del modelo de entrenamiento del agente. Ha de tenerse cuidado con el tratamiento de los mismos para evitar problemas de privacidad. Sin embargo, dado que el servidor de Rasa es una instalacio´n Open Source bajo nuestro control no es necesario realizar ocultacio´n de datos para terceros. Tabla 2.1: Tabla ana´lisis de Rasa 4https://opensource.org/licenses/Apache-2.0 5https://spacy.io/ 6https://github.com/mit-nlp/MITIE 11 ChatScript (https://github.com/ChatScript/ChatScript) Presentacio´n ChatScript es un framework para la creacio´n de chatbots basados en reglas. Presenta un motor basado en reglas, donde las reglas son creadas por programadores, y se deben ejecutar a trave´s de secuencias de comandos de programas en lo que constituye un flujo de dia´logo. Utiliza un metalenguaje de scripting como co´digo de programacio´n. Disponibilidad ChatScript es un producto Open Source bajo la licencia MIT7, permite el uso comercial del producto, su modificacio´n, la distribucio´n del producto o de sus modificaciones ası´ como el uso privado y patentado de productos derivados. Solo exige que se mantenga un aviso que informe a los receptores que en la distribucio´n se ha usado co´digo con la licencia MIT adema´s de la propia licencia. No se ofrecen garantı´as, ni derechos sobre la marca ChatScript, ni los autores se hacen responsables de perjuicios ocasionados por su uso. Definicio´n del modelo del agente en el sistema No hay un agente como tal en el sistema. Lo que permite crear este sistema es una coleccio´n de lo que llama topics que son una coleccio´n de reglas que determinan una serie de temas de conversacio´n y sentencias asociadas a estos temas. Las reglas se componen de un tipo, una etiqueta, un patro´n y una respuesta a la regla. El tipo de la regla determina si la regla hace referencia a una pregunta, una sentencia o lo que llaman un gambit que es la situacio´n en la que el bot toma la iniciativa en la conversacio´n con el usuario. El sistema busca una secuencia de palabras en la sentencia proporcionada por el usuario para detectar si, en el caso de que este´n, se debe activar la regla asociada. La etiqueta tiene una funcio´n ma´s pensada para el debugging y permite la manipulacio´n de una regla para, en funcio´n de su etiqueta, ser manipulada por otras reglas. La respuesta no es solo el texto que se pretende responder al usuario ya que una vez se produce este texto se permite la activacio´n de sentencias condicionales, bucles y llamadas a otras funciones que implican la ejecucio´n de subsiguientes reglas. Procesamiento del lenguaje natural El procesamiento del lenguaje natural se basa principalmente en detectar cua´ndo hay coincidencias dentro de una oracio´n introducida por el usuario y el patro´n de una regla pre-programada. El sistema normalmente ejecuta las reglas en un orden especı´fico, haciendo que cada regla no solo pase las restricciones de tipo y patro´n, sino que tambie´n genere una salida destinada a llegar al usuario. Una vez que se tiene salida, el sistema concluye su ejecucio´n (a menos que se indique explı´citamente que se deben realizar ma´s acciones). El sistema dispone de reconocimiento de usuarios y puede recordar el contexto de conversaciones mediante una combinacio´n de memoria a corto plazo (solo disponible inmediatamente despue´s de activar una regla) y de largo plazo (solo disponible dentro del mismo dia´logo). Idiomas en que esta´ disponible Esta´ disponible en ingle´s nativo, pero es posible el introducir otros idiomas dentro de su funcionamiento. El inconveniente de esto es que ba´sicamente hay que programar el “paquete” de lenguaje desde cero, incluyendo un diccionario de palabras y la grama´tica del lenguaje a aceptar. Interfaces de programacio´n disponibles La interfaz disponible para desarrolladores es la consola de comandos del sistema en el que se ha instalado. No existe otra forma de interaccionar con el agente que no sea mediante edicio´n de sus ficheros y la ejecucio´n de scripts a trave´s de la consola del mismo. Interfaces de comunicacio´n disponibles El chatbot se instala como un servidor y es capaz de ser integrado dentro de otros programas, reaccionando a las rutinas que estos activen en el, o tambie´n es posible levantar un websocket para que aplicaciones externas se comuniquen con el. Tratamiento de datos aportados por los usuarios Los datos aportados por los usuarios no son utilizados en el proceso de mejora y entrenamiento del chatbot, sin embargo si que se guardan datos de usuario durante la ejecucio´n normal del sistema. Dado que es un sistema de instalacio´n por servidor en nuestras ma´quinas privadas, no se envı´an datos de usuarios a terceros. Tabla 2.2: Tabla ana´lisis de ChatScript 7https://opensource.org/licenses/MIT 12 Chaterbot (https://github.com/gunthercox/ChatterBot) Presentacio´n Chatterbot es una librerı´a Python que permite la creacio´n de software destinado a convertirse en un chatbot, a trave´s del aprendizaje basado en te´cnicas de Machine Learning, capaz de hablar cualquier idioma. Una instancia no entrenada de ChatterBot comienza sin saber co´mo comunicarse. Cada vez que un usuario se comunica con una sentencia, la biblioteca guarda el texto que ingreso´ y el contexto de la respuesta. A medida que ChatterBot recibe ma´s entradas, aumenta la cantidad de respuestas que puede ofrecer y la precisio´n de cada respuesta en relacio´n con la declaracio´n de entrada. Disponibilidad Chatterbot es un software Open Source bajo la licencia BSD 38. Esta versio´n de la licencia BSD permite la redistribucio´n ilimitada para cualquier propo´sito siempre que se mantengan sus avisos de derechos de autor y las renuncias de garantı´a de la licencia. La licencia tambie´n contiene una cla´usula que restringe el uso de los nombres de los contribuyentes para la aprobacio´n de un trabajo derivado sin un permiso especı´fico. Definicio´n del modelo del agente en el sistema El modelo de agente conversacional se construye continuamente con el entrenamiento del chatbot. El sistema de seleccio´n de informacio´n y de preprocesamiento de texto es lo que esta´ disponible a los programadores. Estos dos elementos son los llamados preprocesadores y adaptadores lo´gicos. Los preprocesadores de ChatterBot son funciones simples que modifican la declaracio´n de entrada que recibe un bot de chat antes de que la declaracio´n sea procesada por el adaptador lo´gico. Por otro lado los adaptadores lo´gicos determinan la lo´gica de co´mo ChatterBot selecciona una respuesta a una declaracio´n de entrada determinada. Es posible seleccionar la cantidad de adaptadores lo´gicos que examinara´n la declaracio´n de entrada y en que´ orden la examinara´ cada adaptador de los seleccionados. Si se utilizan varios adaptadores, el bot devolvera´ la respuesta de aquel con el valor de confianza calculado ma´s alto. Si varios adaptadores devuelven la misma confianza, entonces el adaptador que se ingrese en la lista primero tendra´ prioridad. Cada frase utilizada con el chatbot durante el entrenamiento es guardada en la base de datos asociada al chatbot junto con la respuesta esperada para ese tipo de sentencia. No hay por tanto un recurso que permita determinar un intent directamente ni entities. En cuanto al dia´logo, el chatbot creado con ChatterBot es teo´ricamente capaz de aprender informacio´n en la sesio´n que recuerde basa´ndose en su almacenamiento llevado a cabo en la base de datos. El adaptador lo´gico correspondiente deberı´a dar la informacio´n aprendida en base a un criterio de mayor coincidencia encontrada con la informacio´n previamente introducida. Procesamiento del lenguaje natural La forma en la que funciona el procesamiento del lenguaje natural en este sistema consiste en que, tras pre procesar textualmente la cadena de entrada, enfrentarla a un conjunto de adaptadores establecidos por el programador (donde cada adaptador realiza distintos pasos de bu´squeda en la base de datos de frases entrenadas para encontrar la que mejor coincidencia tenga con esa entrada),localiza la que mejor coincidencia tiene con la entrada, selecciona la respuesta asociada a esa entrada de mayor coincidencia y devuelve el resultado al usuario. Idiomas en que esta´ disponible Inicialmente dispone de un corpus en ingle´s, pero esta´n a disposicio´n de los desarrolladores corpus pre entrenados en otros idiomas incluido el espan˜ol. Interfaces de programacio´n disponibles La u´nica interfaz disponible para la configuracio´n del sistema es en base a edicio´n de ficheros y mediante lı´nea de comandos. Interfaces de comunicacio´n disponibles Es posible desarrollar un adaptador que realice peticiones get y post a una API externa. Tratamiento de datos aportados por los usuarios Aunque no envı´a datos a terceros, no queda claro si en base al aprendizaje por una base de datos comu´n, lo aprendido durante una sesio´n con un usuario no se pueda usar en otra sesio´n de usuario con otro distinto pudie´ndose potencialmente filtrar informacio´n confidencial. Tabla 2.3: Tabla ana´lisis de Chaterbot 8https://opensource.org/licenses/BSD-3-Clause 13 2.5.3. Conclusio´n del ana´lisis tecnolo´gico Del ana´lisis presentado se puede concluir que solo las opciones que no se basan en el desarrollo de agentes cuyo funcionamiento depende de reglas son una opcio´n viable para la construccio´n de un bot con interaccio´n avanzada con el usuario. Esto descarto´ las opciones de Rasa, ChatScript, Chatterbot, PandoraBots y WIT. En una segunda inspeccio´n, prestando atencio´n a los criterios de proteccio´n por GDPR, tarifas y facilidad de uso y programacio´n, se descarto´ IBM Watson debido al elevado costo de mantener los datos aportados por los usuarios en su interaccio´n con el chatbot. Amazon Lex fue descartado por no poder asegurar que los datos que manejase el chatbot en territorio europeo fuesen guardados en servidores en ese territorio y Azure Bot Service por la dificultad de programacio´n y modificacio´n del chatbot en comparacio´n con las otras alternativas. Finalmente se selecciono´ DialogFlow porque satisfacı´a los criterios exigidos de privacidad de datos, al mismo tiempo que mantenı´a un precio bajo en sus versiones comerciales y era familiar tanto a los tutores como al alumno implicados por lo que no se requerı´a superar una primera curva de aprendizaje. 2.6. Metodologı´as de desarrollo de chatbots En esta seccio´n se presentan las metodologı´as de desarrollo de chatbots disponibles en la bibliografı´a. El enfoque mayoritario de estas metodologı´as ([34], [41], [50]) orientan la solucio´n propuesta en torno a la fase de desarrollo del sistema que resuelva el problema. Solo una de las propuesta examinadas orienta la solucio´n en cuanto al ana´lisis y captura de la informacio´n para un posible tratamiento de los problemas conceptuales identificados, el Conversation Driven Development [51]. 2.6.1. Metodologı´as orientadas hacia el desarrollo del sistema Las metodologı´as orientadas hacia la solucio´n del problema mediante un desarrollo tecnolo´gico, identifican correctamente los problemas conceptuales anteriormente expuestos pero los abordan a trave´s del desarrollo de una solucio´n tecnolo´gica. Este tipo de metodologı´as se categorizan en tres tipos principalmente: Las orientadas hacia un enfoque basado en reglas, las orientadas hacia un enfoque estadı´stico y las orientadas hacia un enfoque basado en te´cnicas de aprendizaje por inteligencia artificial. Las primeras [34] basan su funcionamiento en seguir reglas de dia´logo rı´gidas de forma que se decide secuencialmente en funcio´n de condiciones lo´gicas como se estructura el dia´logo. Las segundas [41], tienden a utilizar un modelo de ma´quina de estados en el que el dia´logo es controlado en funcio´n de la probabilidad de transicio´n a otro estado calculada sobre el contexto del dia´logo ya existente y sobre el corpus de expresiones disponibles. Algunas de las te´cnicas usadas para resolver los problemas descritos con esta orientacio´n, se basan en el uso de procesos de decisio´n de Markov entre distintos estados [49]. Las terceras [50] surgen como una evolucio´n de las segundas, donde siendo el dia´logo representado mediante una ma´quina de estados, las transiciones entre estados se controlan a trave´s de distintas te´cnicas de clasificacio´n sobre redes convolucionales y regresio´n sobre redes LSTM (Long Short Term Memory). Todas estas opciones, como se ha comentado, identifican correctamente los problemas, pero los tratan en una etapa de desarrollo. La propuesta que los trata en una etapa de ana´lisis es el Conversation Driven Development. 2.6.2. Conversation Driven Development El Conversation Driven Development (CDD), es una metodologı´a planteada por Rasa para el desarrollo de chatbots que permitan llevar a cabo conversaciones ma´s complejas en las que el usuario no tenga por que´ saber como usar el sistema, solo concentra´ndose en su objetivo a conseguir mediante su interaccio´n con e´l. La metodologı´a del CDD se divide en cinco actividades a llevar a cabo iterativamente sobre un prototipo inicial del asistente que se desea desarrollar hasta su ma´xima funcionalidad. Cada una de las actividades se divide en subtareas que hay que llevar a cabo de forma secuencial para poder obtener el resultado requerido. 20 Actividades del CDD El listado de las actividades a desarrollar es el siguiente: Auto-evaluacio´n Presentacio´n del Prototipo Revisio´n de las conversaciones Correcciones y Mejoras Revisio´n de Me´tricas Auto evaluacio´n: La actividad de Auto-evaluacio´n es la actividad inicial a desarrollar, consiste en identificar pra´cticas y ha´bitos de desarrollo dentro del equipo que pueden constituir oportunidades de mejora a la vez que se trabaja en ellas. La actividad de Auto-evaluacio´n esta´ a su vez formada por sub-tareas: La tarea de Discusio´n de objetivos consiste en llevar a cabo una discusio´n centrada en la especificacio´n de los objetivos de mejora o construccio´n para el chatbot. En la tarea de Auto-evaluacio´n como equipo, se puntu´a una serie de tareas a realizar entre las que se incluyen las revisiones de conversaciones llevadas a cabo por usuarios, los datos de entrenamiento, valorando hasta que punto las conversaciones de los usuarios con el chatbot pueden ser clasificadas y utilizadas para ayudar en el proceso de aprendizaje del propio chatbot. Las pruebas con los usuarios, en donde se valora la implicacio´n de los clientes en el desarrollo del chatbot a trave´s de prototipos del mismo, permitie´ndoles interactuar con el y recabar informacio´n de estas interacciones. El flujo de despliegue del sistema, donde se valora si se automatiza el despliegue del chatbot con te´cnicas de CI/CD (Continuous Integration / Continuous Delivery) segu´n se hacen cambios en el mismo o si se evalu´a manualmente el mismo. En la tarea sobre me´tricas, se valora co´mo de avanzadas son las me´tricas utilizadas para la evaluacio´n del e´xito que tiene el chatbot en su interaccio´n con los usuarios. En la tarea de Compartir auto-evaluaciones se comparte la puntuacio´n evaluada por cada participante en el paso anterior para cada categorı´a y se discute las discrepancias en puntuaciones hasta que se llega a un consenso sobre la puntuacio´n. Por u´ltimo en la tarea de Establecer pasos de mejora se identifican las a´reas donde el equipo debe mejorar su puntuacio´n y se identifica una o dos ideas mediante un proceso de Brainstorming que se puedan poner en pra´ctica en el corto plazo. Presentacio´n del Prototipo: La actividad de Presentacio´n del Prototipo trata de incluir a los usuarios finales del producto en el proceso de desarrollo mediante el monitorizado de su interaccio´n con prototipos del sistema a desarrollar para, por un lado, validar el prototipo creado directamente por parte del cliente (obteniendo el feedback requerido para hacer cambios si se necesitase), y por otro lado, para obtener frases de entrenamiento reales que los usuarios usarı´an en una interaccio´n aute´ntica con el sistema. De esta u´ltima forma se pretende enriquecer el entrenamiento del chatbot con frases que realmente se usara´n habitualmente. Al igual que las otras actividades, e´sta se compone de una sucesio´n secuencial de tareas a desarrollar: Preparacio´n para el test de usuarios. Consistente en preparar un listado de tareas que los usuarios que esta´n probando el sistema deben llevar a cabo, mientras un miembro del equipo resuelve las dudas contextuales de las tareas para los usuarios, se pueden tomar notas de estas dudas para registrar que´ puntos del contexto o de la interaccio´n con el sistema no quedan claros. Explicacio´n del proceso. Se da una explicacio´n a los usuarios de en que´ consiste la prueba a realizar ası´ como en aportar explicaciones sobre el background del proyecto. Llevar a cabo el proceso de prueba. Consiste en solicitar a los usuarios que completen las tareas que han descrito y animarles a describir su proceso de pensamiento en voz alta, especialmente si encuentran algo negativo o inesperado. Entrevistar a los usuarios. Consiste en someter a los usuarios que han probado el sistema a la serie de preguntas preparadas previamente para recabar su opinio´n. 21 Discutir y documentar los hallazgos. Discutir los comentarios importantes y poner en comu´n las notas y el resumen de la sesio´n de prueba. Esto se realiza con el objetivo de obtener una lista de mejoras para el sistema. Revisio´n de las conversaciones: En la actividad de Revisio´n de las conversaciones los datos de las conversaciones del asistente con los usuarios que lo han probado son revisados para ver exactamente co´mo fue cada interaccio´n de usuario. Se debe filtrar las conversaciones para ver interacciones en las que se produjeron acciones alternativas, la duracio´n de la conversacio´n, etc. Tambie´n se debe etiquetar conversaciones para realizar un seguimiento de estas e incorporarlas como parte de los datos de entrenamiento para el pro´ximo prototipo del sistema a construir. Al igual que las otras actividades, esta se compone de una sucesio´n secuencial de tareas a desarrollar: Filtrado de conversaciones. Esto permite descartar conversaciones en las que el usuario se desconecto de la conversacio´n con el asistente antes de acabar ası´ como descubrir fallos en la interaccio´n con el agente. Clasificacio´n de conversaciones. Dependiendo del motivo del filtrado aplicado pueden clasificarse conversaciones como fallos, resolucio´n en el ana´lisis de sentimientos, certidumbre de respuesta, u otros motivos. Bu´squeda de conversaciones u´tiles. En funcio´n de la clasificacio´n aplicada reunir un dataset de conversaciones que se puedan usar como motivo de mejora o para su uso en el entrenamiento del chatbot . Anotacio´n de las conversaciones de los usuarios. Buscando en los mensajes erro´neos es posible detectar el error del agente y anotarlo para un entrenamiento correctamente. Documentar cambios a realizar. Documentar los cambios o mejoras a realizar en el sistema. Correcciones y Mejoras: En la actividad de Correcciones y Mejoras dependiendo en la naturaleza del problema o de las mejoras anotadas en la actividad previa se lleva a cabo las correcciones oportunas para obtener una versio´n mejorada del sistema para la pro´xima iteracio´n. Dentro de esta actividad tambie´n se lleva a cabo las actividades relacionadas con el CI/CD. Esto incluye el hacer que cada vez que se modifique el agente se deban superar ciertos test conversacionales antes de que pueda pasar a produccio´n. Esta actividad es dependiente de la tecnologı´a de seguimiento que se utilice y por tanto su implementacio´n concreta es variable en base a ello. Revisio´n de Me´tricas: En la actividad de Revisio´n de Me´tricas se revisa el resultado de las me´tricas obtenidas como resultado de las evaluaciones directas e indirectas sobre las conversaciones de los usuarios que han probado la aplicacio´n. La aplicacio´n de esta actividad consiste en una variacio´n del me´todo de tarjetas de Canvan y comienza con una sesio´n de brainstorming en la que se escriben en estas las preguntas a plantear al agente. A continuacio´n se posicionan las tarjetas con las preguntas en zonas de una pizarra que simbolizan la puntuacio´n asignada a las tarjetas colocadas en esa zona. Posteriormente, mediante otro proceso de brainstorming, se encuentran respuestas a las preguntas plantadas y se deciden me´tricas directas e indirectas para evaluar la adecuacio´n de las respuestas del chatbot a la pregunta en funcio´n de cada una de las respuestas dadas. Por u´ltimo se documentan los hallazgos y se pone en comu´n con el equipo de desarrollo lo averiguado. Ana´lisis del Conversation Driven Development La Metodologı´a del Conversation Driven Development se inspira fuertemente en te´cnicas de gestio´n Agile [103] para estructurarse. En concreto en la primera fase de la misma, Auto-evaluacio´n se lleva a cabo un mapeado de lo que el equipo cree que se debe mejorar tanto como dina´micas de equipo de desarrollo como en cuanto a las caracterı´sticas del chatbot y de los problemas detectados en fases previas del desarrollo del mismo. Esto comparte similitudes con el Scrum Sprint Planning [104] en cuanto a funcionalidad del Product backlog seleccionada para 22 llevar a cabo bajo el Sprint a comenzar. Tambie´n hay similitudes en cuanto a la tema´tica tratada en el Daily Scrum relativo a las dificultades que ha encontrado el equipo de desarrollo, salvo que en el caso del CDD, esta fase no se lleva a cabo todos los dı´as como el Daily Scrum sino que se lleva a cabo u´nicamente una vez al principio de la iteracio´n de desarrollo. En el caso del Sprint Planning se debe planificar co´mo se va a llevar a cabo el proceso de desarrollo de las funcionalidades o cambios introducidos en el sprint ası´ como de su dimensio´n temporal, sin embargo, en el CDD no se hace explı´citamente hincapie´ en estos puntos deja´ndoselos al desarrollador. Otro punto a tener en cuenta de la primera fase del Conversation Driven Development es que hace un planteamiento del trabajo inicial desde el punto de vista del equipo de desarrollo pero no tanto desde el descubrimiento de las necesidades o intenciones del cliente a las que se pretenden dar solucio´n con el sistema. De nuevo, en esta metodologı´a al estar centrada en el punto de desarrollo basado en Agile se omite (erro´neamente, pues Agile no implica olvidarse de esto) todo lo referente a las secciones de Ana´lisis y Disen˜o del Sistema de los proceso de desarrollo software tradicionales. En la segunda fase del Conversation Driven Development se introduce a los clientes mediante prototipos en el proceso de desarrollo del sistema con la recoleccio´n del resultado de su interaccio´n con el chatbot, esto es hasta cierto punto similar a lo que propone Extreme Programming (XP) [105] en su BDD (Behaviour Driven Development) [106] en donde se extiende el TDD (Test Driven Development), junto con ideas del disen˜o guiado por el dominio y el ana´lisis y disen˜o orientado a objetos para proveer al desarrollo de software y a los equipos de administracio´n de herramientas compartidas y un proceso compartido de colaboracio´n en el desarrollo de software. esto se realiza en el CDD involucrando a los usuarios finales del sistema en las pruebas del prototipo construido para conseguir un feedback directo sobre el sistema desarrollado al mismo tiempo que permite a los mismos concretar la idea que tenı´an del sistema a trave´s del prototipo probado permitiendo mejoras y alteraciones a la especificacio´n inicial. En la cuarta fase del Conversation Driven Development se introducen conceptos similares o iguales al Continuous Integration (CI) y Continuous Deployment (CD) que son clave (el CI por lo menos) en planteamientos organizativos como XP donde se prioriza la integracio´n de co´digo continua en un repositorio comu´n, adema´s de ofrecer co´digo disponible para produccio´n y que haya pasado por el proceso de verificacio´n de calidad, ejecutando una serie de test para verificar esta de forma lo ma´s automa´tica que sea posible. Como conclusio´n al ana´lisis, la propuesta del CDD tiene algunos puntos fuertes y serias debilidades. Los puntos fuertes: se inspira fuertemente en te´cnicas de organizacio´n para el desarrollo de software basadas en Agile, pone el foco en la participacio´n del cliente en le evaluacio´n y correccio´n del sistema a trave´s de sucesivos prototipos de forma que se acabe obteniendo un sistema lo ma´s adecuado que sea posible de acuerdo a la especificacio´n del cliente. Como puntos de´biles y amenazando a su validez, esta´ el hecho de que aunque el CDD Playbook es una propuesta de metodologı´a para el tipo de problemas descritos, no pertenece esta a fuentes literarias de conocimiento reconocido (Artı´culos de Investigacio´n Primaria, Secundaria, Especiales, literatura terciara o gris), sino que pertenece a publicaciones en distintos blogs, incluido el de Rasa. Por esta razo´n no se puede afirmar que haya sido verificada (en la actualidad) como va´lida de forma pu´blica por investigadores no pertenecientes a Rasa. Otro punto de´bil es que se justifica en su introduccio´n mediante lo que que llama los 5 niveles de AI conversacional. E ´ste es un concepto introducido por el propio personal de Rasa ([107], [108]) para clasificar la completitud que pueden tener los chatbots en su nivel de interaccio´n con un usuario y poder justificar ası´ la calidad de los chatbots ofrecidos como resultado de esta metodologı´a. Otra debilidad es que, pese a decir en la introduccio´n del CDD Playbook: “CDD isn’t proprietary, and it isn’t tied to a particular framework. It’s a set of activities and design principles that help conversational AI teams build AI assistants that really help users”, en el mismo PlayBook se promociona el uso de su sistema de desarrollo de chatbots de pago, Rasa X, para la aplicacio´n de la metodologı´a. El u´ltimo problema del CDD es que al centrarse en te´cnicas Agile, se centra bastante en el ambiente de trabajo de los desarrolladores del producto pero no tanto en cuanto a la participacio´n del usuario en el mismo. 2.7. Conclusio´n del capı´tulo En este capı´tulo se han revisado los principales retos tecnolo´gicos y conceptuales, a los que se enfrenta un desarrollador de chatbots. Estos u´ltimos han sido atendidos hasta el momento por metodologı´as que enfocan el 23 problema desde un punto de vista centrado en la fase de desarrollo mayoritariamente. La u´nica alternativa que los enfoca desde un punto de vista centrado en la fase de ana´lisis no resulta del todo adecuada. Es por ello necesario proponer una metodologı´a que desde un punto de vista de ana´lisis de la informacio´n necesaria para comprender el contexto de interaccio´n con el usuario muestre su valor y pueda ser verificada por la comunidad informa´tica. 24 Capı´tulo 3 Ana´lisis de te´cnicas de elicitacio´n de requisitos en chatbots En este capı´tulo se realiza una exploracio´n de las te´cnicas de elicitacio´n de requisitos que ma´s relevancia tienen a la hora de proponer soluciones a los problemas expuestos en el capı´tulo anterior. Las te´cnicas que se tendra´n que seleccionar necesitara´n aproximarse al problema de elicitacio´n de requisitos desde un a´ngulo de ana´lisis de informacio´n que preste atencio´n al contexto de comunicacio´n. 3.1. Clasificacio´n de te´cnicas de elicitacio´n de requisitos Basa´ndonos en el ana´lisis realizado por Pacheco [71], es posible clasificar las distintas te´cnicas de elicitacio´n de requisitos en sistemas de informacio´n disponibles en las siguientes categorı´as: Te´cnicas tradicionales Aquellas que fueron utilizadas en las primeras etapas del desarrollo de la ingenierı´a de software. Se centran en la elicitacio´n de datos gene´ricos para la identificacio´n de las necesidades que exponen los clientes y las limitaciones del sistema a desarrollar. Dentro de estas te´cnicas esta´n incluidas las entrevistas, las encuestas, el ana´lisis de tareas y los cuestionarios. Te´cnicas colaborativas Son te´cnicas que promueven el llegar a acuerdos con el cliente mientras se utilizan la dina´mica del equipo de desarrollo. Estas te´cnicas son adecuadas si hay varios tipos de clientes participando en el proyecto. Adema´s, las te´cnicas de esta categorı´a se utilizan para seleccionar y priorizar los requisitos dentro del proceso de elicitacio´n y proporcionar una guı´a para descubrir conceptos ba´sicos y mejorar el conocimiento del dominio de la aplicacio´n. Dentro de esta categorı´a esta´n incluidos los focus group, los talleres de elicitacio´n de requisitos y las sesiones de brainstorming. Te´cnicas de prototipado Son te´cnicas que utilizan prototipos (desde prototipado en papel a productos en beta) porque existe incertidumbre con respecto al funcionamiento del sistema de software en la vida real y se requiere la obtencio´n de informacio´n detallada sobre el sistema a construir y promover la retroalimentacio´n entre las partes interesadas. Te´cnicas de modelado Estas te´cnicas proporcionan un modelo del tipo de informacio´n que se elicitara´, y se utilizan para liderar el proceso de elicitacio´n y obtener una mejor comprensio´n de las necesidades de los clientes, el contexto y el proyecto. Dentro de las te´cnicas agrupadas aquı´, aparecen: escenarios, aproximaciones orientadas al objetivo, modelos de proceso de negocio y casos de uso. Te´cnicas cognitivas Son te´cnicas orientadas a la adquisicio´n de conocimiento en sistemas basados en informacio´n. Ofrecen te´cnicas de elicitacio´n de requisitos destinadas a representar y estructurar el conocimiento de los clientes en base a la definicio´n de un problema y la solucio´n visionada por estos. Dentro de esta categorı´a aparecen te´cnicas como el uso de ontologı´as y el card sorting. 25 Te´cnicas contextuales Son te´cnicas creadas a partir de la combinacio´n del prototipado y las entrevistas centradas en el entorno de trabajo del cliente en que se desplegara´ el sistema. Esto se realiza para recopilar datos sobre las partes interesadas, sus procesos, modelos y flujos de trabajo, el entorno u otro elemento relevante con su entorno de trabajo con el fin de obtener una detallada comprensio´n de los requisitos. Dentro de estas te´cnicas se incluyen aquellas de cara´cter etnogra´fico y etnometodolo´gico. Te´cnicas Agile Este tipo de te´cnicas se centran en la forma de trabajo del equipo de desarrollo, organiza´ndolo para poder adaptarlo a las condiciones del proyecto, consiguiendo flexibilidad e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las circunstancias especı´ficas del entorno. Dentro de las te´cnicas aquı´ consideradas se incluyen: el mind mapping, las user stories y el group storytelling. 3.2. Seleccio´n de te´cnicas En base a la clasificacio´n anterior se llevan a cabo las siguientes observaciones para configurar que´ grupo de te´cnicas es conveniente que formen parte de la metodologı´a: Las te´cnicas tradicionales, aunque permiten prestar atencio´n a las necesidades del cliente, lo hacen desde un punto de vista gene´rico. Los cuestionarios son rı´gidos en cuanto a formato y requieren de un cierto conocimiento y entendimiento del problema a resolver para poder prepararlos antes de enfrentarlos con los clientes. El ana´lisis de tareas implicarı´a en estos sistemas el poder ver co´mo el usuario interactu´a con la institucio´n al realizar las preguntas sobre los temas en los que se le presentan dudas, por lo que no es adecuado para este tipo de problemas. Por u´ltimo las entrevistas presentan el mismo inconveniente que los cuestionarios. Requieren conocimiento previo sobre el dominio que se va a tratar, aunque no sean tan rı´gidas como las anteriores, adema´s de no ser un proceso reproducible por ser un tipo de te´cnica variable en cuanto a estructura, dependiendo de las circunstancias a tratar bajo ellas en cada caso. Por ello, se decidio´ no utilizar las te´cnicas tradicionales como te´cnicas principales de la metodologı´a. Sin embargo, se reconoce que estas te´cnicas permiten obtener informacio´n del cliente de forma eficiente, por lo que se propuso la bu´squeda de una te´cnica que, estando basada en una entrevista tuviese un formato fijo reproducible en otras ocasiones ya que las entrevistas por su caracterı´stica de ser especı´ficas al problema a tratarse en cada momento no permitirı´an llevarse a cabo de forma reproducible (hasta cierto punto) como parte de una metodologı´a. Por ello se ha seleccionado la te´cnica basada en laddering, que consiste en, a trave´s de una serie de preguntas cortas y empezando en un nivel de abstraccio´n bajo, obtener cada vez informacio´n de ma´s nivel de abstraccio´n permitiendo ordenarla de acuerdo a una cierta estructura o jerarquı´a, en concreto Zowghi menciona que se supone, al utilizar el laddering, que la informacio´n que se esta´ elicitando se puede ordenar jera´rquicamente [81]. El uso de entrevistas basadas en laddering viene adema´s justificado porque, algunos autores [90] sen˜alan que son efectivas para capturar requisitos de una forma similar a las entrevistas estructuradas [71]. Las te´cnicas colaborativas, aunque podrı´an ser adecuadas a la hora de abordar el problema desde el punto de vista de los clientes y teniendo en cuenta el contexto, agrupan te´cnicas que requieren sesiones o periodos de involucramiento con los clientes demasiado extensivos en cuanto a tiempo. Dado que en el caso especı´fico de VirtualForest los clientes solo pueden dedicarnos periodos cortos de tiempo no es posible llevar a cabo este tipo de te´cnicas ni por separado ni como parte de una metodologı´a. Las te´cnicas cognitivas no se han seleccionado debido a que, para aplicarse, requieren el haber construido de antemano la informacio´n, o conjunto de informacio´n que caracteriza el sistema. Es en ese punto donde se aplican estas te´cnicas para conseguir estructurar la informacio´n en una representacio´n comprensible para los involucrados en el proyecto. Dado que este no es el caso para el tipo de proyecto tratado, donde es frecuente que el propio cliente no sepa con seguridad que´ informacio´n es necesaria para la construccio´n del chatbot, no es posible la aplicacio´n de este tipo de te´cnicas. Las te´cnicas contextuales, aunque podrı´an parecer ido´neas para el problema que estamos tratando, de abordar un desarrollo de este tipo de sistemas desde un punto de vista contextual, centrado en la interaccio´n y en el cliente, no son aplicables a este caso. Esto es debido a que ambas te´cnicas (ana´lisis etnogra´fico y etnometodolo´gico) conllevan trabajar con poblaciones de usuarios o fuentes de datos muy superiores a las disponibles en este caso. 26 Para poder llevarlas a cabo en este tipo de desarrollos se requerirı´a el estudio de informacio´n derivada de cientos de interacciones de usuarios reales con un sistema similar al proyectado. Cosa que no es posible en las condiciones actuales de realizacio´n de este trabajo. Debido a las caracterı´sticas de los problemas expuestos anteriormente nos concentramos en las te´cnicas basadas en modelado, en el prototipado y en Agile. Nos centramos en modelado para permitir dar solucio´n (a la necesidad especifica del proyecto VirtualForest) de claridad en cuanto a definicio´n del problema pero no en cuanto a co´mo solucionarlo. Estas te´cnicas nos permitirı´an el comprender mejor que´ es lo que se espera del sistema y el contexto de uso del mismo. El prototipado, por su parte, permitirı´a mostrar a los clientes el sistema en desarrollo para acrecentar su confianza en el resultado a obtener con el uso del mismo. Por u´ltimo, las te´cnicas agile podrı´an ayudar a delimitar el problema y tareas a resolver, considerando el tiempo que se dispone para interactuar con el cliente. Nos centraremos tambie´n en el uso de te´cnicas de laddering porque es razonable asumir que en un proceso de dia´logo y negociacio´n con un cliente se necesitara´n te´cnicas similares a entrevistas. Dentro de los tipos de te´cnicas elegidos, vamos a centrarnos en la clasificacio´n de Pacheco [71] para identificar las ma´s apropiadas para nuestros objetivos. 3.2.1. Te´cnicas de modelado En la categorı´a de modelado aparecen las te´cnicas de escenarios, aproximacio´n basada en objetivos y modelos de proceso de negocio. La te´cnica de escenarios, permite usar descripciones de situaciones y procesos en los que el usuario interactu´a con el sistema con un propo´sito especı´fico. El uso de escenarios implica afrontar un proceso iterativo de refinamiento de e´stos, buscando todas las excepciones y casos alternativos en los que el sistema se encuentre debido a dicha interaccio´n [75]. Esto es al mismo tiempo la mayor fortaleza, por su completitud, y la mayor debilidad, por la cantidad de tiempo necesario para llevarla a cabo, a la que se enfrenta esta te´cnica en su ejecucio´n. Los escenarios se relacionan con los modelos mediante un proceso de abstraccio´n y con los prototipos mediante un proceso de disen˜o. Los escenarios que realizan una representacio´n del mundo real son abstraı´dos para formar modelos. Los modelos y especificaciones de requisitos se transforman en disen˜os y finalmente se implementan. Los escenarios permiten servir como inspiracio´n a la hora de llevar a cabo el disen˜o de prototipos. Adema´s los escenarios se pueden utilizar para razonar sobre el disen˜o y como scripts de prueba en me´todos de evaluacio´n. La te´cnica de Aproximacio´n Basada en Objetivos [77], consiste en, a partir de objetivos de alto nivel del sistema, descomponerlos en sub-objetivos de menor taman˜o al mismo tiempo que se elabora una descripcio´n ma´s completa de estos sub-objetivos creados. Esta te´cnica permite representar ma´s fielmente el objetivo del usuario en su interaccio´n con el sistema a partir de una descripcio´n ma´s vaga de un objetivo general, hasta obtener sentencias ma´s concretas y completas que describan uno o ma´s objetivos a conseguir ma´s especı´ficamente. Sin embargo, hay que tener en cuenta que un defecto de esta te´cnica [77] es que los errores introducidos en las fases tempranas de la misma se reproducen y difuminan a medida que se descomponen los objetivos generales con errores en objetivos especı´ficos. Adema´s los frameworks disponibles para la aplicacio´n de la te´cnica (KAOS, i*, etc.) requieren una inversio´n considerable de tiempo para poder aplicarlos. La te´cnica de Modelos de proceso de negocio [80], consiste en realizar un diagrama que represente las actividades del negocio permitiendo el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). Business Process Modeling (BPM) es la actividad de representar los procesos comerciales de una empresa, para que puedan ser analizados. Para garantizar la eficacia de BPM, es importante que se seleccione una notacio´n BPM que sea completa y clara, es decir, capaz de expresar todos los conceptos relevantes del dominio en estudio. Esta te´cnica es u´til para ayudar a las partes interesadas a analizar sus procesos y tareas siendo eficaz en mejorar la comunicacio´n bidireccional entre el analista y los interesados y proporciona una base para una mayor comprensio´n, interpretacio´n y validacio´n de los requisitos obtenidos. 27 3.2.2. Te´cnicas de prototipado La te´cnica de Prototipado [81] aunque costosa en cuanto a tiempo de llevar a cabo, permite obtener de primera mano de los interesados feedback relevante, adema´s de ser especialmente u´til en el caso de que los interesados no tengan del todo clara la finalidad que el sistema pretenda cubrir o cuando se disponen de una serie de prerequisitos de cara´cter general. La te´cnica referida en esta seccio´n al prototipado es el prototipado iterativo. El prototipado iterativo [84] consiste en, a trave´s de sucesivas iteraciones sobre un prototipo funcional, perfeccionar su funcionamiento hasta que en una iteracio´n el cliente valide el alcance y funcionamiento del sistema dando como resultado un producto completo. Esta te´cnica es apropiada en la circunstancia de que el cliente no este´ del todo seguro del funcionamiento final que quiere tenga el producto una vez sea lanzado a la fase de produccio´n. Esta te´cnica le permite a la vez, el comprobar el estado del desarrollo y le da ideas que le permiten concretar que´ es exactamente lo que necesita. 3.2.3. Te´cnicas Agile La te´cnica de Mind Mapping [85] se ha definido como “representaciones visuales, no lineales de ideas y sus relaciones”[87]. Los mapas mentales comprenden una red de conceptos conectados y relacionados donde cualquier idea puede conectarse con cualquier otra. El objetivo de esta te´cnica es encontrar asociaciones creativas entre las ideas expuestas para lo que se requiere un pensamiento esponta´neo e imaginativo al crear el mapa mental. De acuerdo con Pacheco, esta te´cnica es apropiada para trabajar siguiendo la forma en que la gente tiende a pensar, es decir, no linealmente y es eficaz en la organizacio´n y representacio´n de informacio´n dentro de una jerarquı´a radial. Las User Stories [81] son descripciones generales desde el punto de vista del usuario final de una funcionalidad que debe cubrir el sistema. El propo´sito de e´stas, es explicar co´mo proporciona valor una funcionalidad software al usuario o cliente final. Una historia de usuario describe la funcionalidad que sera´ valiosa para un usuario o para el comprador de un sistema o software. De acuerdo con Mike Cohn [109], las user stories se componen de tres aspectos: Una descripcio´n escrita de la historia utilizada para la planificacio´n y como recordatorio. Conversaciones sobre la historia que sirven para desarrollar los detalles de la historia. Pruebas que transmiten y documentan detalles y que se pueden utilizar para determinar cuando una historia esta completa. A estas tres partes se les suele llamar tarjeta, conversacio´n y confirmacio´n. Esta estructura esta´ pensada porque si bien la tarjeta puede contener el texto de la historia, los detalles se resuelven en la Conversacio´n y se verifican con la Confirmacio´n. El enunciado de la user story suele ser: Como (Rol) Quiero (...) Para (...). Esta estructura permite determinar la funcio´n y la intencio´n del usuario para proporcionarle la informacio´n correcta, que corresponde con el propo´sito definido en la story. En la te´cnica del Group Storytelling [88] los participantes informan de sus actividades mediante relatos o narrativas colectivas. Las narrativas se consideran productos sociales dentro de contextos especı´ficos, y un metodo interpretativo a trave´s del cual las personas comunican conocimientos y definen su propia identidad. En esta te´cnica se llevan a cabo discusiones grupales en las que a trave´s de la narracio´n de historias individuales se construye una narracio´n colectiva para unificar el grupo y unir los intereses de todas las partes. Esta te´cnica tiene como objetivo modelar el dominio desde diferentes perspectivas con el fin de desarrollar una descripcio´n completa y coherente del sistema a desarrollar. 3.3. Seleccio´n de te´cnicas de ana´lisis de requisitos para chatbots En esta seccio´n se va a hacer una seleccio´n de las te´cnicas ma´s apropiadas para afrontar los problemas para el desarrollo de chatbots identificados en la seccio´n 2.4, es decir, la variabilidad del lenguaje y el control del dia´logo. 28 3.3.1. Te´cnicas a aplicar en la variabilidad del lenguaje El problema de la variabilidad del lenguaje consiste en que´ hacer con un sistema que acepta entradas equivalentes conceptualmente pero de distinta representacio´n en el lenguaje. Dado que el problema a evitar es el no conseguir abarcar el contexto en que se comunica el usuario en una interaccio´n determinada con el sistema, se propone el centrarse en te´cnicas que nos permitan abstraernos a lo que realmente desea el usuario o que nos permitan reducir la ambigu¨edad de los requisitos resultantes de las mismas. Debido a esto se seleccionaron las siguientes te´cnicas: User Stories Uso de entrevistas basadas en Laddering Uso de Prototipos El uso de user stories viene justificado porque las user stories como herramienta son fa´cilmente adaptables a cambios en los requisitos derivados de las mismas ya que recogen el proceso de conversacio´n que determina la propia user story. Las user stories permiten adema´s adaptarse al desarrollo de chatbots ya que tanto las user stories como los chatbots necesitan pra´cticamente la misma informacio´n que se encuentra en los componentes de la story. El uso de entrevistas basadas en laddering consiste en, a trave´s de una serie de preguntas cortas y empezando en un nivel de abstraccio´n bajo, obtener cada vez informacio´n de ma´s nivel de abstraccio´n encadena´ndola entre sı´ mediante una relacio´n consecuencia-causa. Esto permite llevar acabo un proceso de entrevista, pero ordenada de acuerdo a construccio´n de un modelo o jerarquı´a de informacio´n. Mediante esta te´cnica por tanto se puede llevar a cabo un proceso de entrevista reproducible en circunstancias distintas ya que se posee una estructura comu´n a seguir entre ellas. Por u´ltimo el uso de prototipos permite, a trave´s de las iteraciones, refinar el producto que se esta´ elaborando al mismo tiempo que le permite al cliente verificar co´mo se comportarı´a un sistema real ante la funcionalidad solicitada. Permitirı´a no solo recoger el feedback del cliente al ponerse a e´ste en contacto con el prototipo, concretando su idea sobre la funcionalidad requerida, sino tambie´n nuevas formas de expresio´n de acciones para el chatbot distintas de las elaboradas por el desarrollador y ma´s cercanas al contexto real de uso del sistema. 3.3.2. Te´cnicas a aplicar en el control del dia´logo El problema, expuesto en la seccio´n anterior, del control del dia´logo consiste en co´mo especificar el contexto y la estructura de la conversacio´n que tendra´ un chatbot con el usuario. Dentro de las te´cnicas examinadas en la seccio´n anterior para poder tratar este problema las ma´s relevantes para este problema son: Uso de escenarios. Uso de modelos de proceso de negocio. El uso de escenarios viene justificado por permitir, sin restringirse a la notacio´n de UML, estructurar un dia´logo con el usuario a trave´s de la aparicio´n de condiciones en el flujo de la conversacio´n. Permitirı´a mostrar tambie´n al cliente los caminos alternos al escenario de e´xito planteado. El uso de escenarios permite analizar la interaccio´n entre el software y el usuario, y reducir discrepancias y ambigu¨edades en el flujo de datos de la tarea mediante la el estudio de los posibles canales de comunicacio´n en la conversacio´n. El uso de modelos de proceso de negocio permite a trave´s de los flowcharts estudiar visualmente como se estructura la conversacio´n con el usuario cuando e´ste interacciona con el chatbot para cumplir un objetivo concreto. Permite esta te´cnica observar co´mo fluye la informacio´n entre los distintos nodos de la conversacio´n. Aunque esta te´cnica se basa en el uso de diagramas de flujo no utilizaremos directamente los diagramas de actividades de UML, ya que lo que queremos es modelar la conversacio´n y con los diagramas de actividades nos verı´amos forzados a limitarnos a las acciones que se cumplen en la conversacio´n, pero no mostrarı´amos el intercambio de preguntas y respuestas con el chatbot. 29 diagramas de flujo, por lo que, pese a no seguir las reglas asociadas a un diagrama concreto, un desarrollador que conozca la notacio´n de esta ISO podra´ entender el significado tras esta. Prototipado En la quinta fase, se llevarı´a a cabo la programacio´n del prototipo y se llevarı´an a cabo pruebas de caja negra para verificar que lo programado concuerda con los solicitado por el cliente. Test de usuarios y documentacio´n En la sexta fase, una vez el prototipo ha sido desarrollado y probado desde el punto de vista funcional, (pruebas de caja negra), se debe mostrar al cliente y permitir que el propio cliente interaccione con e´l. En estas pruebas se registran automa´ticamente las conversaciones adema´s de llevar a cabo una pequen˜a entrevista no estructurada despue´s de la interaccio´n del cliente con el sistema para recoger sus opiniones sobre su interaccio´n. El cliente en este punto validarı´a el desarrollo del prototipo y consecuentemente los requisitos que le dan cabida. En caso de validar el trabajo, se pasarı´a a la fase de documentacio´n donde se formalizarı´an los requisitos y se harı´a el desarrollo de la funcionalidad prototipada, si quedasen objetivos sin tratar en el sistema se comenzarı´a una nueva iteracio´n en la fase de preparacio´n de objetivos. En caso de no validarla se pasarı´a a la entrevista no estructurada donde mediante preguntas sucesivamente ma´s especificas (te´cnica de Laddering) se llegarı´a al punto de no concordancia entre el prototipo desarrollado y el objetivo que representa. Esto se documentarı´a para la pro´xima iteracio´n y se comenzarı´a una nueva iteracio´n. 4.3. Validacio´n de la propuesta La validacio´n de la propuesta metodolo´gica se realiza en dos partes. Una primera parte en la que se valora la aplicacio´n de cada una de las te´cnicas que forman parte de la metodologı´a y una segunda parte donde se valora la calidad de la informacio´n obtenida como resultado de la aplicacio´n de la metodologı´a. 4.3.1. Validacio´n de las te´cnicas incorporadas en la metodologı´a En la primera parte se debe valorar la aplicacio´n de las te´cnicas. Para ello se debe seguir los siguientes criterios de calidad. El objetivo es verificar de una forma contrastable que se han aplicado las te´cnicas de la manera adecuada validando el resultado obtenido por la metodologı´a. En caso de no poder validar el resultado obtenido, se tendra´ que acotar que´ no es correcto desde el punto de vista de la te´cnica aplicada y se tendra´ que corregir antes de la siguiente iteracio´n. User stories Para evaluar la aplicacio´n de las user stories seguiremos el criterio INVEST [110]. En concreto el me´todo de evaluacio´n sera´ para determinar si se esta´ aplicando INVEST correctamente. Por ello para cada user story obtenida en el proceso de seleccio´n de objetivos se debe aplicar los siguientes pasos: Evaluacio´n de Independencia (I): determinar el nu´mero de dependencias con otras User Story ya elaboradas detectadas. El objetivo es conseguir que no haya ninguna dependencia con otras user stories. Evaluacio´n de Negociables (N): determinar si hay al menos una nota referida al proceso de conversacio´n con el cliente. Accio´n de correccio´n: exponer lo entendido de la user story al cliente para verificar que ambos tenemos el mismo concepto del objetivo que debe cumplir el chatbot. Evaluacio´n de Valor (V): determinar si la user story esta´ escrita desde el punto de vista del cliente o no. Accio´n de correccio´n: descartar la user story si no es posible reescribirla en te´rminos del valor que aporta la interaccio´n del chatbot al usuario. Si es posible reescribirla en estos te´rminos, reescribirla y validar seguidamente frente al cliente que es el resultado esperado de ese objetivo. Evaluacio´n de Estimable (E): determinar si la user story se puede concretar como trabajo realizable dentro de la duracio´n fijada para la iteracio´n. Accio´n de correccio´n: si no es el caso, determinar si es posible simplificarla, y de serlo, validar con el cliente que se sigue cumpliendo el objetivo final. 36 Evaluacio´n de Pequen˜as (S): determinar si la user story tiene un taman˜o que permita su trabajo durante toda la iteracio´n o debe desagregarse en ma´s. Accio´n de correccio´n: dividirla en varias user stories donde cada una de ellas pueda ser realizada dentro del periodo establecido para la iteracio´n. Evaluacio´n de Testeable (T): determinar si la user story posee test para verificar su completitud de acuerdo a lo establecido por el cliente. Accio´n de correccio´n: cuestionar al cliente sobre co´mo se comprobarı´a que se ha cumplido el objetivo al que se refiere la story. La user story estara´ bien especificada y sera´ valida si podemos responder que las evaluaciones anteriores son positivas, o en el caso del nu´mero de dependencias entre user stories con un nu´mero igual a cero. En el caso de que no podamos contestar afirmativamente a cada una de las preguntas anteriores, dependiendo de a que´ preguntas no se pueda contestar afirmativamente, se debera´ llevar a cabo la accio´n de correccio´n correspondiente. Escenarios Para evaluar la aplicacio´n de los escenarios tendremos que contestar a las siguientes preguntas sobre el modelo de escenario que hemos planteado. El objetivo es conseguir contestar para cada escenario afirmativamente a cada una de las preguntas planteadas: ¿El escenario esta´ referido a un solo objetivo (user story)?. Accio´n de correccio´n: Si esta´ referido a ma´s de una, dividir el escenario en el mismo nu´mero de user stories que esta´n referidas. Si no lo esta´ a ninguna, eliminarlo o bien crear una user story a la que de cabida. ¿Caracteriza el contexto la situacio´n en la que se produce la story?. Accio´n de correccio´n: Elaborar una de los siguientes al menos: Precondicio´n para cumplir el escenario, Contexto Temporal de realizacio´n del escenario, descripcio´n de la situacio´n del actor al llevar a cabo el escenario. ¿Se ha identificado al menos un recurso de informacio´n para llevar a cabo el escenario?. Accio´n de correccio´n: Determinar que´ informacio´n se requiere que exista para poder llevar a cabo el escenario. ¿Se ha identificado al menos a un actor llevando a cabo las tareas del escenario?. Accio´n de correccio´n: Identificar el rol sobre el que se ha especificado la user story a la que da cabida el escenario. ¿Cubren los episodios descritos el caso de e´xito del escenario ?. Accio´n de correccio´n: Determinar cua´l es el resultado que se considera un e´xito y marca la completitud de la user story y traducirlo a episodios para el escenario. ¿Cubren los episodios descritos todos los escenarios alternativos que se pueden dar en la interaccio´n con el usuario: cancelacio´n, interrupcio´n, abandono?. Accio´n de correccio´n: Determinar entre que´ episodios puede haber puntos en los que se den escenarios alternativos y elaborar los episodios de esos escenarios a partir de esos puntos. Al igual que con las user stories, el escenario estara´ bien especificado y sera´ valido si podemos responder afirmativamente a las anteriores cuestiones. En el caso de que no podamos contestar afirmativamente a cada una de las preguntas anteriores, dependiendo de a que´ preguntas no se pueda contestar afirmativamente, se debera´ llevar a cabo la accio´n de correccio´n correspondiente. Prototipado La te´cnica de prototipado se validara´ por nuestra parte mediante la comprobacio´n de que se ha obtenido un prototipo referido a las stories de la iteracio´n. La validacio´n correra´ ma´s a cargo de los test de usuarios en los que el cliente validara´ si el prototipo se corresponde con la funcionalidad solicitada para llevar a cabo en el chatbot. 37 Laddering La te´cnica del laddering se aplica durante el test de usuarios para examinar la causa principal de una incorreccio´n en el prototipo que se ha llevado a cabo. Se debe validar que hemos aplicado la te´cnica correctamente si podemos contestar afirmativamente a las siguientes preguntas para cada uno de los problemas planteados por el usuario en la evaluacio´n: ¿Se han determinado cua´l son los atributos o caracterı´sticas asociados al problema identificado? ¿Se ha determinado su asociacio´n con las consecuencias que los provocan? ¿Se ha determinado la asociacio´n de estas consecuencias con el valor central que no se ha cumplido? Al contestar afirmativamente a estas preguntas y exponer el resultado al cliente para su confirmacio´n se valida el resultado de la te´cnica. 4.3.2. Validacio´n de la informacio´n obtenida por la aplicacio´n de la metodologı´a Se indican aquı´las preguntas objetivo a contestar como parte del proceso de test de usuarios durante la aplicacio´n de la metodologı´a para el desarrollo del sistema. Estas preguntas son las que validan la aplicacio´n de la metodologı´a como un todo y si realmente se esta´ obteniendo informacio´n suficiente para aplicar el posterior ana´lisis consiguiendo la elicitacio´n de los requisitos del sistema. P1: ¿Que´ nu´mero de participantes hemos podido involucrar? P2: ¿Que´ caracterı´sticas poseen estos participantes? P3: ¿Cua´l es el tiempo que hemos necesitado de ellos? P4: ¿Se ha confirmado la mayorı´a de cosas ensen˜adas en el prototipo? P5: ¿Se han propuesto mejoras a lo mostrado en el prototipo? P5: ¿Se ha propuesto an˜adir mayor funcionalidad de lo mostrado en el prototipo? P6: ¿Podemos valorar positivamente el resultado obtenido en la prueba en te´rminos de participacio´n? P7: ¿Han entendido los participantes del test con usuarios lo que se requerı´a de ellos o ha sido necesario aclararlo varias veces? P8: ¿Se requiere recoger ma´s informacio´n de los usuarios tras haber realizado el test de usuario? 4.4. Conclusio´n de la metodologı´a Como conclusio´n a este capı´tulo hay que decir que se ha propuesto una metodologı´a en torno a las te´cnicas anteriormente identificadas y esperando dar respuesta a los problemas asociados al desarrollo de un chatbot textual de preguntas y respuestas. Por u´ltimo se ha propuesto los criterios de validacio´n de la metodologı´a, tanto te´cnica a te´cnica como de forma general para determinar si es viable. 38 Capı´tulo 5 Aplicacio´n y Evaluacio´n de la propuesta En este capı´tulo se presenta el proceso de validacio´n de la metodologı´a propuesta, a trave´s de la aplicacio´n de la misma al caso de VirtualForest que fue descrito en el capı´tulo 1. En total se han identificado 14 user stories, escenarios y diagramas de flujo conversacional. Estos han sido expuestos en las secciones 5.3.2, 5.3.3 y 5.3.4. A continuacio´n se presenta la organizacio´n del trabajo, el perfil de los participantes del sistema, los artefactos elaborados como parte de la metodologı´a, el propio ana´lisis del sistema en funcio´n de estos artefactos, el desarrollo y pruebas del sistema y la discusio´n de los resultados. 5.1. Organizacio´n del trabajo En el transcurso de este TFM se han realizado 4 iteraciones. En esta seccio´n se indica el trabajo llevado a cabo en cada iteracio´n. Cada iteracio´n ha comenzado al dı´a siguiente del test de usuario con los clientes y ha tenido una duracio´n de dos semanas. Primera iteracio´n: Contextualizacio´n del chatbot. User Stories N º 1 y 2 . Escenarios 1 y 2. Diagramas de flujo Conversacional 1 y 2. Prototipo 1. Test de usuario 1. Segunda iteracio´n: User Stories N º 3, 4, 5, 6 y 7 . Escenarios 3, 4, 5, 6 y 7. Diagramas de flujo Conversacional 3, 4, 5, 6 y 7. Prototipo 2. Test de usuario 2. Tercera iteracio´n: User Stories N º 8, 9, 10, 11 . Escenarios 8, 9, 10, 11. Diagramas de flujo Conversacional 8, 9, 10, 11. Prototipo 3. Test de usuario 3. Cuarta iteracio´n: User Stories N º 12, 13, 14 . Escenarios 12, 13, 14. Diagramas de flujo Conversacional 12, 13, 14. Prototipo 4. Test de usuario 4. Los test de usuario han consistido en sesiones de 30 minutos donde en los primeros 5 minutos se ha explicado por parte del desarrollador la funcionalidad prototipada, en los siguientes 10 minutos se ha dejado a los usuarios interaccionar con el chatbot y en el resto del tiempo se ha recogido la opinio´n de los participantes sobre la funcionalidad inspeccionada. 5.2. Contextualizacio´n de los participantes en los test de usuario Bajo el rol de participantes en la aplicacio´n de la metodologı´a y como clientes participaron tres personas pertenecientes a la ETSIIAA (Escuela Te´cnica Superior de Ingenierı´as Agrarias de Palencia). Dos de estas personas son profesores de la ETSIIAA y un alumno de la misma escuela que ha finalizado sus estudios en la misma y colabora como te´cnico en el IUFOR. Los profesores pertenecen tambie´n al IUFOR por lo que poseen los conocimientos suficientes tanto en materia Forestal como en entornos educativos para llevar a cabo un proceso de recogida de datos sobre ellos. 39 5.3. Artefactos elaborados por la aplicacio´n de la propuesta Se presenta en esta seccio´n los artefactos resultantes de la aplicacio´n de la metodologı´a al proyecto VirtualForest. Su organizacio´n, estructura y formato se especifican de acuerdo a lo descrito tanto en los criterios de validacio´n de las te´cnicas aplicadas, como en las fases descritas como parte de la metodologı´a. 5.3.1. Contextualizacio´n del sistema ¿Para que´ propo´sito esta´ desarrollando el chatbot como sistema? El chatbot a desarrollar pretende dar solucio´n a un problema de gestio´n de respuestas a preguntas frecuentemente realizadas por estudiantes de grado a la hora de decidir si esta´n interesados en cursar los estudios de ma´ster disponibles en la ETSIIAA. Para ello se tendra´n que contestar preguntas generales en torno a los ma´steres de Montes, Dataforest y el programa de Doble Ma´ster en Montes y Dataforest. Adema´s se contestara´n preguntas sobre cuestiones relacionadas con el funcionamiento de los procesos administrativos de la universidad. ¿Bajo que´ rol opera el chatbot? El chatbot operara´ bajo un rol consultivo de tutor, respondiendo a las preguntas dirigidas por los estudiantes interesados en cursar un ma´ster del a´mbito forestal al chatbot. Las preguntas que le dirigiran los estudiantes a este chatbot se centrara´n en el contenido general, la organizacio´n y los tra´mites a realizar bajo los cursos que dure el ma´ster en el que esta´n interesados. Adema´s el chatbot no debe utilizar un tono excesivamente coloquial pero debe utilizar un tono y una forma de expresarse cercana con el usuario. El nombre que se ha elegido para el chatbot sera´ VirtualForestBot. ¿Va a interaccionar el chatbot con otros sistemas software? El chatbot tendra´ que interaccionar desde una interfaz web o desde un cliente de aplicacio´n de mensajerı´a instanta´nea como Telegram o WhatsApp con los usuarios. ¿Que´ es lo que el chatbot debe no hacer explı´citamente? El chatbot no debe valorar casos demasiado particulares de un estudiante al ser un sistema destinado a un pu´blico general. Salvo en el caso concreto de que se requiera recabar informacio´n personal del usuario, el chatbot se limitara´ a dar explicaciones que no sean personalizadas para poder abarcar un pu´blico general. 5.3.2. Seleccio´n de objetivos a trave´s de user stories Se muestran a continuacio´n una reproduccio´n de las tarjetas utilizadas para las user story intentando mantener lo ma´s fielmente posible el formato definido previamente: User Story N º 1 Enunciado: Como interesado en cursar un ma´ster quiero conocer la oferta de ma´steres disponibles para informarme sobre uno afı´n a mis intereses. Notas: Nota1: Para conocer la oferta basta con decir que´ ma´steres hay disponibles. Nota2: Los ma´steres disponibles actualmente son Montes, Dataforest, el programa de Doble Ma´ster en Montes y Dataforest, el programa de Doble Ma´ster Internacional en AgroParisTech y Montes y el programa de Doble Ma´ster Internacional en AgroParisTech y Dataforest. Nota3: X Nota4: X Tests: Test1: Se debe listar los ma´steres disponibles cuando se pregunte por la oferta de ma´steres. Test2: X Test3: X Test4: X 40 User Story N º 2 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre requisitos de titulacio´n para el acceso para saber si me puedo apuntar al ma´ster de mi intere´s. Notas: Nota1: En el caso del ma´ster de Montes, en el caso del Doble Ma´ster en Montes y Dataforest y en el Doble Ma´ster Internacional en AgroParisTech y Monte, para que un interesado se apunte debe tener un grado en Ingenierı´a Forestal validado por una universidad espan˜ola. Si un interesado posee un graduado concedido por una entidad extranjera debe homologarlo a un graduado espan˜ol en Ingenierı´a Forestal primero antes de acceder. Si un interesado no posee un graduado en Ingenierı´a Forestal no puede acceder. Nota2: En el caso de Dataforest y el Doble Ma´ster Internacional en AgroParisTech y Dataforest para que un interesado acceda debe tener un grado. Si un interesado posee un graduado concedido por una entidad extranjera no tiene por que´ homologarlo a su correspondiente graduado espan˜ol. Si un interesado no posee un graduado no puede acceder. Nota3: En el caso de Montes o Dataforest los interesados de Francia o Vietnam pueden hacer uso de las colaboraciones con los centros de esos paı´ses. Nota4: En el caso de ma´steres con colaboraciones, se le debe indicar al interesado que pueda acceder la existencia de estas. Tests: Test1: Si el interesado tiene un graduado validado, homologado o que no requiere homologacio´n, que le habilite acceso a un ma´ster que lo requiere, se le debe proporcionar acceso a la preinscripcio´n. Test2: Si el interesado tiene un graduado que le habilite para entrar a un ma´ster que requiere graduado homologado pero expedido por una entidad extranjera y no homologado, se le debe indicar que se homologue. Test3: Si el interesado no posee un graduado que habilite para acceder al ma´ster se le debe indicar que no puede acceder. Test4: Si el interesado ha preguntado por un programa de ma´ster con colaboraciones y tiene un tı´tulo de grado expedido por una entidad de ese pais se le debe informar de esas colaboraciones. User Story N º 3 Enunciado: Como interesado en cursar un ma´ster quiero conocer el cronograma del programa en el que estoy interesado para saber cuanto tiempo necesitarı´a para completarlo. Notas: Nota1: El cronograma del programa se da en an˜os acade´micos o en meses de inicio y fin del programa. Nota2: El nu´mero de cursos acade´micos de duracio´n del ma´ster de Montes es 1,5 , para el de Dataforest es 1,5 , para los ma´steres de AgroParisTech con Montes y con Dataforest son 2 y para el Doble ma´ster en Montes y Dataforest es 2. Nota3: El primer curso del ma´ster de Montes y de Dataforest empezarı´a en Septiembre para acabar en Junio del siguiente an˜o. Y comenzarı´a el segundo curso en Septiembre para acabar en Febrero del siguiente. Nota4: El primer curso de los dobles ma´ster empezarı´a en Septiembre para acabar en Junio del siguiente an˜o. Y comenzarı´a el segundo curso en Septiembre para acabar en Junio del siguiente. Tests: Test1: Se debe dar el cronograma de un programa cuando se solicite tanto en an˜os acade´micos como en meses de inicio y de fin. Test2: X Test3: X Test4: X User Story N º 4 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre cre´ditos ECTS para entender como se pondera cada asignatura dentro del programa de ma´ster. Notas: Nota1: El cre´dito ECTS es el Sistema Europeo de Transferencia de Cre´ditos acade´micos. Nota2: En nuestro caso un ECTS son 25 horas de trabajo del alumno (10 horas de clases + 15 horas de trabajo auto´nomo y estudio del alumno). Nota3: X Nota4: X Tests: Test1:Se debe dar una explicacio´n breve de lo que es un cre´dito ECTS cuando se pregunte por ellos. Test2: X Test3: X Test4: X User Story N º 5 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre los requisitos de idiomas para saber si puedo cursarlo adecuadamente. Notas: Nota1: Todos los ma´steres ofertados tienen un nivel mı´nimo de Ingle´s de B1. En el Dataforest y el Doble ma´ster se recomienda el B2. Nota2: Un ma´ster solo puede tener un u´nico idioma distinto al espan˜ol de imparticio´n. Nota3: X Nota4: X Tests: Test1: Se debe dar una explicacio´n breve de que se requiere mı´nimo un nivel B1 en Ingle´s. Test2: X Test3: X Test4: X 41 User Story N º 6 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre los requisitos de lenguajes de programacio´n que se considera necesarios conocer para cursar el programa sin complicacio´n. Notas: Nota1: Es recomendable programacio´n en R y Python aunque no hay requisitos de programacio´n fijados. Nota2: No se exigirı´an, de exigirse, ma´s que esos dos lenguajes de programacio´n. Nota3: X Nota4: X Tests: Test1: Se debe informar que seria recomendable saber R o Python cuando se pregunte sobre lenguajes de programacio´n pero que no es estrictamente necesario. Test2: X Test3: X Test4: X User Story N º 7 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre la modalidad de presencialidad necesaria en que se imparte el ma´ster para saber si podrı´a asistir a clase o no. Notas: Nota1: Todos los ma´steres ofertados actualmente son presenciales. Nota2: Los niveles de presencialidad son: No presencial, Presencial y Semipresencial. Nota3: X Nota4: X Tests: Test1: Se debe informar de la necesidad de presencialidad 100 % cuando se pregunte por la modalidad de presencialidad de un ma´ster . Test2: X Test3: X Test4: X User Story N º 8 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre el precio de un programa de ma´ster de mi eleccio´n para saber si puedo afrontar cursarlo o no. Notas: Nota1: El precio de los programas de Ma´ster suele variar de an˜o en an˜o pero esta´ en torno a 2800 euros (31,14 Euros/cre´dito * 90 cre´ditos) para Montes, 3600 euros (39,50 Euros/cre´dito * 90 cre´ditos) para Dataforest, 4000 euros (31,14 * 129 cre´ditos) para el Doble Ma´ster de Montes y Dataforest, 3700 (31,14*120) para el de AgroParistech con Montes y 4700 (39,50*120) para el de AgroParisTech con Dataforest. Nota2: Los precios no son calculados, son orientativos y deben incluir una rebaja a aplicar este an˜o, Montes (2800 euros), Dataforest (1940 euros), Doble ma´ster (3000 euros), Montes + AgroParisTech (3700 euros), Dataforest + AgroParisTech (4700 euros). Nota3: X Nota4: X Tests: Test1: Se debe indicar un precio orientativo para el ma´ster seleccionado por le interesado . Test2: X Test3: X Test4: X User Story N º 9 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre el contenido del programa de ma´ster de mi eleccio´n para saber si me interesa cursarlo. Notas: Nota1: La descripcio´n del contenido del ma´ster contiene informacio´n de en que´ consiste el ma´ster, si es un ma´ster simple o doble y que´ convenios con que´ entidades posee. Nota2: Los ma´steres simples otorgan un u´nico tı´tulo mientras que los doble otorgan dos tı´tulos cursando un u´nico programa. Nota3: Los convenios con otras entidades son a nivel de ma´ster y permiten llevar a cabo cursos del programa de ma´ster en estas entidades. Nota4: X Tests: Test1: Se debe indicar una breve descripcio´n del contenido del ma´ster, si es un doble ma´ster o no y de los convenios que posee . Test2: X Test3: X Test4: X 42 User Story N º 10 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre las colaboraciones con entidades externas a la UVa para valorar la calidad del ma´ster Notas: Nota1: Los convenios de colaboracio´n se caracterizan por el ma´ster al que esta´n referidos y por la entidad de acogida. Nota2: Los convenios deben explicarse mediante la identificacio´n de la entidad y descripcio´n de las actividades esperadas para su desarrollo. Nota3: X Nota4: X Tests: Test1: Se debe describir una colaboracio´n indicando el nombre de la entidad de acogida, el ma´ster bajo el que se produce, el paı´s de la entidad de acogida y una descripcio´n de la actividad que se realiza. Test2: X Test3: X Test4: X User Story N º 11 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre la posibilidad de convalidar asignaturas por experiencia previa para no tener que cursar asignaturas cuyo contenido ya conozco. Notas: Nota1: Tanto por experiencia previa, por haber cursado asignaturas similares en otro master o por querer convalidar practicas en empresa se debe presentar antes de la matriculacio´n, una solicitud en la sede electronica de la UVa. Nota2: X Nota3: X Nota4: X Tests: Test1: Se debe informar al usuario cuando pregunte sobre este tema que debe solicitarlo por la sede electro´nica. Test2: X Test3: X Test4: X User Story N º 12 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre la asignatura de pra´cticas en empresa para valorar si me interesa cursar el ma´ster con la oferta disponible. Notas: Nota1: La informacio´n relevante de las pra´cticas en empresa es que son obligatorias y que es posible realizarlas con entidades internacionales. Nota2: X Nota3: X Nota4: X Tests: Test1: Se debe informar al usuario cuando pregunte sobre este tema de la obligatoriedad de las pra´cticas y de su posibilidad de cursarlas en el extranjero. Test2: Se debe proporcionar la URL de la ETSIA donde se explica la oferta disponible Test3: X Test4: X User Story N º 13 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre las ayudas econo´micas disponibles para valorar si puedo solicitar alguna para cursar el ma´ster. Notas: Nota1: La informacio´n relevante a las becas es muy variable de an˜o en an˜o, hay que consultarla y valorarla caso a caso. Nota2: Es mejor que se muestre el listado de becas de la UVa disponibles por la url correspondiente o que se contacte con el coordinador del master. Nota3: X Nota4: X Tests: Test1: Se debe proporcionar la URL de la UVa donde se muestra la oferta disponible. Test2: X Test3: X Test4: X User Story N º 14 Enunciado: Como interesado en cursar un ma´ster quiero informacio´n sobre el correo de contacto de coordinacio´n del ma´ster para consultar informacio´n no presente en el chatbot. Notas: Nota1: Serı´a necesario concoer el correo de coordinacio´n de cada ma´ster. No el personal del responsable actual. Nota2: X Nota3: X Nota4: X Tests: Test1: Se debe proporcionar el correo de coordinacio´n general asociado a cada master. Test2: X Test3: X Test4: X 43 5.3.3. Disen˜o de escenarios Escenario N º 1 Objetivo: User Story N º 1. Se requiere conocer los ma´steres de ciencias forestales disponibles: Contexto: Un interesado en cursar ma´ster quiere conocer los ma´steres relacionados con el a´mbito de la Ingenierı´a Forestal que ofrece la UVa en Palencia. Recursos necesarios: Listado de ma´steres disponibles en la UVa en Palencia para el a´mbito de Ingenierı´a Forestal. Actores: Interesado: Persona con intere´s en cursar un programa de ma´ster oficial en el pro´ximo an˜o. Episodios (ES, EC, EO): ES1: El interesado solicita la oferta de ma´steres disponibles. ES2: Se recupera el listado de ma´steres con docencia disponible para el siguiente curso. EC2.1: Si hay ma´steres disponibles para elaborar el listado se muestra el listado recuperado. EC2.2: Si no hay ma´steres disponibles para elaborar el listado se indica que no se dispone en ese momento de la informacio´n necesaria. Escenario N º 4 Objetivo: User Story N º 4 . Se requiere consultar informacio´n sobre cre´ditos ECTS: Contexto: Un interesado en cursar ma´ster quiere conocer que´ es un cre´dito ECTS. Recursos necesarios: Descripcio´n de un cre´dito ECTS. Actores: Interesado: Persona con intere´s en cursar un programa de ma´ster oficial en el pro´ximo an˜o. Episodios (ES, EC, EO): ES1: El interesado solicita informacio´n sobre los cre´ditos ECTS. ES2: Se aporta informacio´n sobre los cre´ditos ECTS. Escenario N º 3 Objetivo: User Story N º 3 . Se requiere consultar el cronograma de un Ma´ster: Contexto: Un interesado en cursar ma´ster quiere conocer la temporizacio´n del ma´ster en que esta´ interesado antes de empezarlo. Recursos necesarios: Cronogramas para los ma´steres de Montes, el de Dataforest y el programa Dual. Actores: Interesado: Persona con intere´s en cursar un programa de ma´ster oficial en el pro´ximo an˜o. Episodios (ES, EC, EO): ES1: El interesado solicita la temporizacio´n del ma´ster. Restriccio´n:Los ma´steres de los que puede solicitar los cronogramas son el de Montes, Dataforest o Dual. ES2: Se comprueba si el ma´ster posee un cronograma. EC2.1: Si el ma´ster posee un cronograma se informa al interesado con un mensaje indicando la temporizacio´n del ma´ster en an˜os acade´micos y en meses. EC2.2: Si el ma´ster no posee un cronograma se informa al interesado con un mensaje indicando que en ese momento no se dispone de esa informacio´n. 44 Escenario N º 2 Objetivo: User Story N º 2 . Se requiere consultar las condiciones de acceso a un Ma´ster: Contexto: Un interesado en cursar ma´ster quiere conocer las condiciones de acceso de un ma´ster del a´mbito de la Ingenierı´a Forestal que ofrece la UVa en Palencia. Recursos necesarios: Listado de ma´steres disponibles en la UVa en Palencia para el a´mbito de Ingenierı´a Forestal. Actores: Interesado: Persona con intere´s en cursar un programa de ma´ster oficial en el pro´ximo an˜o. Episodios (ES, EC, EO): ES1: El interesado solicita las condiciones de acceso a un ma´ster. Restriccio´n:Los ma´steres de los que puede solicitar las condiciones de acceso son el de Montes, Dataforest, Doble ma´ster en Montes y Dataforest y los programas de Doble ma´ster de AgroParisTech. EC2: Se solicita al interesado el paı´s de la institucio´n que expedio´ el tı´tulo de acceso al ma´ster. ES3.1: Si el interesado cesa la comunicacio´n la conversacio´n se extingue. ES3.2: Si el paı´s indicado por el interesado es Espan˜a se consulta el tı´tulo de grado especı´fico para acceder. EC3.2.1: Se cuestiona al interesado si tiene el tı´tulo especı´fico de grado. ES3.2.1.1: Si el interesado cesa la comunicacio´n la conversacio´n se extingue. ES3.2.1.2: Si el interesado dispone del tı´tulo entonces se recuperan las colaboraciones del programa y se informa al interesado de que cumple las condiciones de acceso. EC3.2.1.2.1: Si el titulo del interesado esta´ expedido por una entidad del mismo paı´s que una colaboracio´n existente se le informa de la colaboracio´n disponible. ES3.2.1.3: Si el interesado no dispone del tı´tulo entonces se indica que no puede acceder a ese ma´ster pero que puede acceder a un ma´ster que no tenga un requerimiento de grado especı´fico. ES3.3: Si el paı´s indicado por el interesado no es Espan˜a se consulta si el programa de ma´ster requiere un tı´tulo de grado homologado. EC3.3.1: Si se requiere un tı´tulo de grado homologado se consulta al interesado sobre si posee el tı´tulo. ES3.3.1.1: Si el interesado cesa la comunicacio´n la conversacio´n se extingue. ES3.3.1.2: Si el interesado no posee el tı´tulo se le indica que debe homologarse para acceder a ese ma´ster o que acceda a un programa que no requiera homologacio´n. ES3.3.1.3: Si el interesado posee el tı´tulo entonces se recuperan las colaboraciones del programa y se le informa de que cumple las condiciones de acceso. EC3.3.1.3.1: Si el titulo del interesado esta´ expedido por una entidad del mismo paı´s que una colaboracio´n existente se le informa de la colaboracio´n disponible. EC3.3.2: Si no se requiere un tı´tulo de grado homologado se consulta al interesado sobre si posee un tı´tulo de grado universitario. ES3.3.2.1: Si el interesado cesa la comunicacio´n la conversacio´n se extingue. ES3.3.2.2: Si el interesado no posee el tı´tulo se le indica que no puede acceder al programa de ma´ster. ES3.3.2.3: Si el interesado posee el tı´tulo entonces se recuperan las colaboraciones del programa y se le informa de que cumple las condiciones de acceso. EC3.3.2.3.1: Si el titulo del interesado esta´ expedido por una entidad del mismo paı´s que una colaboracio´n existente se le informa de la colaboracio´n disponible. Escenario N º 5 Objetivo: User Story N º 5 . Se requiere consultar informacio´n sobre requisitos de idiomas de un ma´ster: Contexto: Un interesado en cursar ma´ster quiere conocer que´ idiomas son necesarios para poder cursar un ma´ster. Recursos necesarios: Nivel de idiomas para cada idioma en que se imparte el ma´ster. Actores: Interesado: Persona con intere´s en cursar un programa de ma´ster oficial en el pro´ximo an˜o. Episodios (ES, EC, EO): ES1: El interesado solicita informacio´n sobre los idiomas del ma´ster. Restriccio´n:Los ma´steres de los que puede solicitar el nivel de idiomas son el de Montes, Dataforest o Dual. ES2: Se recupera informacio´n sobre los idiomas en los que se imparte el ma´ster. ES3: Se recupera el nivel para cada uno de los idiomas en que se imparte el ma´ster. ES4: Se informa al interesado sobre el nivel de idiomas de cada uno de los idiomas del ma´ster. 45 Figura 5.5: Diagrama de Flujo Conversacional 5: Consultar informacio´n sobre requisitos de idioma de un ma´ster 52 Figura 5.6: Diagrama de Flujo Conversacional 6: Consultar informacio´n sobre requisitos de lenguajes de programacio´n de un ma´ster 53 Figura 5.7: Diagrama de Flujo Conversacional 7: Consultar informacio´n sobre modalidad de presencialidad de un ma´ster 54 Figura 5.8: Diagrama de Flujo Conversacional 8: Consultar informacio´n sobre precios orientativos de un ma´ster 55 Figura 5.9: Diagrama de Flujo Conversacional 9: Consultar contenido de un ma´ster 56 Figura 5.10: Diagrama de Flujo Conversacional 10: Consultar colaboraciones de un ma´ster 57 Figura 5.11: Diagrama de Flujo Conversacional 11: Solicitar reconocimiento de asignaturas 58 Figura 5.12: Diagrama de Flujo Conversacional 12: Solicitar informacio´n de pra´cticas en empresa 59 Figura 5.13: Diagrama de Flujo Conversacional 13: Solicitar informacio´n de becas para un ma´ster 60 Figura 5.14: Diagrama de Flujo Conversacional 14: Solicitar informacio´n de contacto para un ma´ster 5.4. Ana´lisis del sistema 5.4.1. Requisitos funcionales del sistema FRQ-001 Consultar oferta de ma´steres Versio´n 1.0 Descripcio´n El sistema debera´ permitir al usuario consultar la oferta de ma´steres disponibles. 61 CU-007 Solicitar informacio´n presencialidad del ma´ster Actor/Actores Interesado (Actor-001) Descripcio´n El caso de uso Solicitar informacio´n presencialidad del ma´ster, ocurre cuando el actor Interesado quiere obtener informacio´n sobre la presencialidad necesaria para cursar un ma´ster de su eleccio´n. Precondicio´n No se requiere. Postcondicio´n Un mensaje informando de la presencialidad requerida en el ma´ster es mostrado. Secuencia Base 1. El actor Interesado solicita informacio´n sobre la presencialidad para cursar el ma´ster en el pro´ximo an˜o. 2. El sistema recupera la informacio´n sobre la presencialidad asociada al ma´ster. 3. El sistema presenta al interesado la presencialidad requerida para cursar el ma´ster . CU-008 Solicitar informacio´n precio del ma´ster Actor/Actores Interesado (Actor-001) Descripcio´n El caso de uso Solicitar informacio´n precio del ma´ster, ocurre cuando el actor Interesado quiere obtener informacio´n sobre el precio aproximado de un ma´ster de su eleccio´n. Precondicio´n No se requiere. Postcondicio´n Un mensaje informando del precio aproximado del ma´ster es mostrado. Secuencia Base 1. El actor Interesado solicita informacio´n sobre el precio de cursar el ma´ster en el pro´ximo an˜o. 2. El sistema recupera la informacio´n sobre el precio asociado al ma´ster. 3. El sistema presenta al interesado el precio del ma´ster, informa´ndole de que es aproximado . CU-009 Solicitar resumen de un ma´ster Actor/Actores Interesado (Actor-001) Descripcio´n El caso de uso Solicitar resumen de un ma´ster, ocurre cuando el actor Interesado quiere obtener informacio´n sobre en que´ consiste un ma´ster de su eleccio´n. Precondicio´n No se requiere. Postcondicio´n Un mensaje informando del contenido del ma´ster es mostrado. Secuencia Base 1. El actor Interesado solicita informacio´n sobre el contenido de un ma´ster. 2. El sistema recupera la informacio´n sobre la descripcio´n del ma´ster . 3. El sistema presenta el resumen elaborado al actor Interesado. CU-010 Solicitar informacio´n colaboracio´n de ma´ster Actor/Actores Interesado (Actor-001) Descripcio´n El caso de uso Solicitar informacio´n colaboracio´n de ma´ster, ocurre cuando el actor Interesado quiere obtener informacio´n sobre las colaboraciones asociadas a un ma´ster de su eleccio´n. Precondicio´n No se requiere. Postcondicio´n Un mensaje informando de las colaboraciones del ma´ster es mostrado. Secuencia Base 1. El actor Interesado solicita informacio´n sobre colaboraciones existentes en un ma´ster. 2. El sistema recupera la informacio´n sobre colaboraciones de ese ma´ster. 3. El sistema presenta al interesado las colaboraciones del ma´ster . 68 CU-011 Solicitar informacio´n convalidacio´n de asignaturas Actor/Actores Interesado (Actor-001) Descripcio´n El caso de uso Solicitar informacio´n convalidacio´n de asignaturas, ocurre cuando el actor Interesado quiere obtener informacio´n sobre el proceso de convalidacio´n de asignaturas asociadas a un ma´ster de su eleccio´n. Precondicio´n No se requiere. Postcondicio´n Un mensaje informando del proceso de convalidacio´n es mostrado. Secuencia Base 1. El actor Interesado solicita informacio´n sobre convalidacio´n de asignaturas de un ma´ster. 2. El sistema recupera la informacio´n sobre el proceso de convalidacio´n. 3. El sistema presenta al interesado un resumen del proceso de convalidacio´n . CU-012 Solicitar informacio´n pra´cticas en empresa Actor/Actores Interesado (Actor-001) Descripcio´n El caso de uso Solicitar informacio´n pra´cticas en empresa, ocurre cuando el actor Interesado quiere obtener informacio´n sobre las pra´cticas en empresa asociadas a un ma´ster de su eleccio´n. Precondicio´n No se requiere. Postcondicio´n Un mensaje informando de pra´cticas en empresa es mostrado. Secuencia Base 1. El actor Interesado solicita informacio´n sobre las pra´cticas en empresa de un ma´ster. 2. El sistema recupera la informacio´n sobre pra´cticas. 3. El sistema presenta al interesado un resumen de las pra´cticas en empresa. CU-013 Solicitar informacio´n becas Actor/Actores Interesado (Actor-001) Descripcio´n El caso de uso Solicitar informacio´n becas, ocurre cuando el actor Interesado quiere obtener informacio´n sobre las becas para cursar un ma´ster de su eleccio´n. Precondicio´n No se requiere. Postcondicio´n Un mensaje informando de becas es mostrado. Secuencia Base 1. El actor Interesado solicita informacio´n sobre las becas de un ma´ster. 2. El sistema recupera la informacio´n sobre becas. 3. El sistema presenta al interesado un resumen de las becas disponibles. CU-014 Solicitar informacio´n de contacto Actor/Actores Interesado (Actor-001) Descripcio´n El caso de uso Solicitar informacio´n de contacto, ocurre cuando el actor Interesado quiere obtener la informacio´n de contacto del coordinador de un ma´ster para un trato personal. Precondicio´n No se requiere. Postcondicio´n Un mensaje con la informacio´n de contacto es mostrado. Secuencia Base 1. El actor Interesado solicita el correo de contacto dle coordinador de un ma´ster. 2. El sistema recupera el correo del coordinador. 3. El sistema presenta al interesado un resumen de informacio´n de contacto con el correo del coordinador. 69 Figura 5.15: Diagrama de casos de uso 70 5.4.6. Diagrama de clases Figura 5.16: Diagrama de clases 5.5. Desarrollo del sistema El sistema esta´ estructurado, en primer lugar por la plataforma tecnolo´gica escogida para el desarrollo del proyecto que es DialogFlow. En segundo lugar por el programa ngrok, instalado en una ma´quina virtual proporcionada por la Escuela Te´cnica Superior de Ingenierı´a Informa´tica. Este programa se encarga de realizar tu´neles http para hacer que la direccio´n local especificada en su inicializacio´n sea expuesta al exterior. En tercer lugar por un servidor web (Apache Tomcat) encargado de recibir y enviar peticiones POST con informacio´n en formato JSON a DialogFlow. En esta misma ma´quina hay un servidor Apache Derby actuando como Base de Datos para el proyecto. La forma actual de interactuar con DialogFlow consiste en utilizar una integracio´n con el cliente de Telegram disponible desde el propio DialogFlow. El motivo de la eleccio´n de Telegram sobre otras alternativas (como directamente integrarlo con una plataforma web) se debe a que, debido a realizar las pruebas sobre la versio´n gratuita de DialogFlow, no es posible llevar a cabo pruebas en un entorno web que requiera el uso de un servidor web de terceros (es decir, en nuestro caso el servidor Tomcat instalado). Por este motivo se utiliza la integracio´n de Telegram adema´s de por ser una de las interfaces de interaccio´n solicitadas en el proyecto. Figura 5.17: Estructura del sistema 71 El flujo de informacio´n, en el funcionamiento normal del sistema, comienza en Telegram (o directamente en DialogFlow si se usa la interfaz propia de esa plataforma) al solicitarle el usuario informacio´n al chatbot. El chatbot transmite la peticio´n del usuario a DialogFlow mediante el envı´o de una peticio´n POST con el JSON conteniendo la informacio´n. En DialogFlow se evaluara´ el intent al que corresponde dicha peticio´n de informacio´n. Si es un intent con webhook habilitado, el agente que representa al chatbot en DialogFlow crea un JSON conteniendo, entre otra informacio´n, el nombre asociado al intent con el que se ha identificado la peticio´n del usuario y, como para´metros en el JSON, los valores de las entities identificadas en la peticio´n. Esta peticio´n se envı´a mediante un me´todo POST a la URL especificada en el apartado Fulfillment del propio agente creado. Esta URL es la proporcionada por ngrok al activarse en la ma´quina virtual de la Escuela, ngrok redirige el tra´fico Https de esa direccio´n a la direccio´n localhost:8080 de la ma´quina virtual de la Escuela. Es en esta direccio´n donde esta´ el servidor Web desplegado en Tomcat escuchando peticiones GET y POST. Al llegar el POST con la peticio´n en formato JSON, se procesa y parsea realiza´ndose peticiones relevantes a la BD de acuerdo con la lo´gica del caso de uso involucrado. Con la respuesta obtenida de la BD se introduce esta en un JSON de respuesta y se contesta a DialogFlow. Al recibir este el JSON con la estructura esperada, envı´a la respuesta (en este caso Telegram aunque como se ha explicado podrı´a ser otra integracio´n o el dia´logo integrado directamente en DialogFlow) al cliente que realizo´ la pregunta inicial. 5.6. Pruebas del sistema En esta seccio´n se describen los me´todos y pruebas utilizados para comprobar la correccio´n del sistema desarrollado. 5.6.1. Pruebas de Caja Blanca Las pruebas de caja blanca son aquellas pruebas realizadas a la vista del co´digo de la aplicacio´n. Para estas pruebas se han utilizado las herramientas de testeo JUnit, JaCoCo y EasyMock. Estas pruebas se han ido realizando al final de cada iteracio´n despue´s de el desarrollo del prototipo en un sistema funcional, para comprobar no solo la funcionalidad de cada uno de los me´todos de cada caso de uso sino la funcionalidad conjunta del sistema, tal y como se describe en la metodologı´a explicada anteriormente. Dado que estas pruebas esta´n relacionadas con el co´digo, no se incluyen en esta memoria. Sin embargo, dado que se ha usado las herramientas SonarLint y SonarQube como medidor de la calidad del co´digo desarrollado, se incluye a continuacio´n el ana´lisis realizado del co´digo final desarrollado en el que se explica, entre otras cosas, la cobertura del co´digo de lo´gica y modelo de la aplicacio´n. 5.6.2. Pruebas de Caja Negra Las pruebas de caja negra se hacen sin ser visible el co´digo de la aplicacio´n, u´nicamente teniendo en cuenta la especificacio´n acordada de la aplicacio´n. Por ello se prueban los casos extremos de acuerdo a la especificacio´n de cada funcionalidad y se contrasta el funcionamiento obtenido con el esperado como parte del proceso de prueba. se muestran a continuacio´n las condiciones de realizacio´n de cada prueba, los resultados esperados y obtenidos (salvo que la respuesta sea excesivamente larga, caso en el que se resume entre pare´ntesis) para esas condiciones. 72 Figura 5.18: Informe Resumen de SonarQube Prueba (P CU01 01) Descripcio´n Prueba para el CU 01 (Consultar oferta de ma´steres). Entrada ¿Que´ ma´steres hay disponibles?. Salida Esperada Un listado de ma´steres ofertados se muestra. Salida Obtenida Un listado de ma´steres ofertados se muestra (Resultado Correcto). Prueba (P CU01 02) Descripcio´n Prueba para el CU 01 (Consultar oferta de ma´steres). Se prueba a interactuar con el sistema sin conexio´n a la BD Entrada ¿Que´ ma´steres hay disponibles?. Salida Esperada El servicio no esta´ disponible en este momento. Salida Obtenida El servicio no esta´ disponible en este momento (Resultado Correcto). 73 Prueba (P CU02 01) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso de ma´ster que requiere tı´tulo de grado especifico, nacionalidad espan˜ola y posesio´n de tı´tulo. Entrada ¿Co´mo puedo acceder al ma´ster de Montes?, Espan˜a, si. Salida Esperada En primer lugar, gracias por tu intere´s en el Ma´ster en Ingenierı´a de Montes. Dado que posees un tı´tulo que permite el acceso al programa de ma´ster es posible tu acceso. https://apps.stic.uva.es/preinsmaster/. Salida Obtenida En primer lugar, gracias por tu intere´s en el Ma´ster en Ingenierı´a de Montes. Dado que posees un tı´tulo que permite el acceso al programa de ma´ster es posible tu acceso. https://apps.stic.uva.es/preinsmaster/ (Resultado Correcto). Prueba (P CU02 02) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso de ma´ster que requiere tı´tulo de grado especifico, nacionalidad espan˜ola y no se posee tı´tulo. Entrada ¿Co´mo puedo acceder al ma´ster de Montes?, Espan˜a, no. Salida Esperada En primer lugar, gracias por tu intere´s en el Ma´ster en Ingenierı´a de Montes. Dado que no posees un tı´tulo va´lido que permite el acceso al programa de ma´ster no es posible tu acceso. Salida Obtenida En primer lugar, gracias por tu intere´s en el Ma´ster en Ingenierı´a de Montes. Dado que no posees un tı´tulo va´lido que permite el acceso al programa de ma´ster no es posible tu acceso (Resultado Correcto). Prueba (P CU02 03) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso de ma´ster que requiere tı´tulo de grado especifico, nacionalidad extranjera y posesio´n de tı´tulo homologado. Entrada ¿Co´mo puedo acceder al ma´ster de Montes?, Vietnam, si. Salida Esperada En primer lugar, gracias por tu intere´s en el Ma´ster en Ingenierı´a de Montes. Dado que posees un tı´tulo que permite el acceso al programa de ma´ster es posible tu acceso. https://apps.stic.uva.es/preinsmaster/ Adema´s, el programa posee las siguientes colaboraciones: Vietnam National University Of Science AgroParisTech. Salida Obtenida En primer lugar, gracias por tu intere´s en el Ma´ster en Ingenierı´a de Montes. Dado que posees un tı´tulo que permite el acceso al programa de ma´ster es posible tu acceso. https://apps.stic.uva.es/preinsmaster/ Adema´s, el programa posee las siguientes colaboraciones: Vietnam National University Of Science AgroParisTech (Resultado Correcto). 74 Prueba (P CU02 04) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso de ma´ster que requiere tı´tulo de grado especifico, nacionalidad extranjera y no se posee tı´tulo homologado. Entrada ¿Co´mo puedo acceder al ma´ster de Montes?, Vietnam, no. Salida Esperada En primer lugar, gracias por tu intere´s en el Ma´ster en Ingenierı´a de Montes. Dado que no posees un tı´tulo va´lido que permite el acceso al programa de ma´ster no es posible tu acceso. Salida Obtenida En primer lugar, gracias por tu intere´s en el Ma´ster en Ingenierı´a de Montes. Dado que no posees un tı´tulo va´lido que permite el acceso al programa de ma´ster no es posible tu acceso. (Resultado Correcto). Prueba (P CU02 05) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso de ma´ster que no requiere tı´tulo de grado especifico, nacionalidad espan˜ola y posesio´n de tı´tulo de grado. Entrada ¿Co´mo puedo acceder al ma´ster de Dataforest?, Espan˜a, si. Salida Esperada En primer lugar, gracias por tu intere´s en el Ma´ster en Dataforest. Dado que posees un tı´tulo que permite el acceso al programa de ma´ster es posible tu acceso. https://apps.stic.uva.es/preinsmaster/ Salida Obtenida En primer lugar, gracias por tu intere´s en el Ma´ster en Dataforest. Dado que posees un tı´tulo que permite el acceso al programa de ma´ster es posible tu acceso. https://apps.stic.uva.es/preinsmaster/ (Resultado Correcto). Prueba (P CU02 06) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso de ma´ster que no requiere tı´tulo de grado especifico, nacionalidad espan˜ola y no se posee tı´tulo de grado. Entrada ¿Co´mo puedo acceder al ma´ster de Dataforest?, Espan˜a, no. Salida Esperada En primer lugar, gracias por tu intere´s en el Ma´ster en Dataforest. Dado que no posees un tı´tulo va´lido que permite el acceso al programa de ma´ster no es posible tu acceso. Salida Obtenida En primer lugar, gracias por tu intere´s en el Ma´ster en Dataforest. Dado que no posees un tı´tulo va´lido que permite el acceso al programa de ma´ster no es posible tu acceso. (Resultado Correcto). 75 Prueba (P CU02 07) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso de ma´ster que no requiere tı´tulo de grado especifico, nacionalidad extranjera y posesio´n de tı´tulo de grado. Entrada ¿Co´mo puedo acceder al ma´ster de Dataforest?, Canada, si. Salida Esperada En primer lugar, gracias por tu intere´s en el Ma´ster en Dataforest. Dado que posees un tı´tulo que permite el acceso al programa de ma´ster es posible tu acceso. https://apps.stic.uva.es/preinsmaster/ Adema´s, el programa posee las siguientes colaboraciones: Vietnam National University Of Science AgroParisTech Salida Obtenida En primer lugar, gracias por tu intere´s en el Ma´ster en Dataforest. Dado que posees un tı´tulo que permite el acceso al programa de ma´ster es posible tu acceso. https://apps.stic.uva.es/preinsmaster/ Adema´s, el programa posee las siguientes colaboraciones: Vietnam National University Of Science AgroParisTech (Resultado Correcto). Prueba (P CU02 08) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso de ma´ster que no requiere tı´tulo de grado especifico, nacionalidad extranjera y no se posee tı´tulo de grado. Entrada ¿Co´mo puedo acceder al ma´ster de Dataforest?, Canada, no. Salida Esperada En primer lugar, gracias por tu intere´s en el Ma´ster en Dataforest. Dado que no posees un tı´tulo va´lido que permite el acceso al programa de ma´ster no es posible tu acceso. Salida Obtenida En primer lugar, gracias por tu intere´s en el Ma´ster en Dataforest. Dado que no posees un tı´tulo va´lido que permite el acceso al programa de ma´ster no es posible tu acceso. (Resultado Correcto). Prueba (P CU02 09) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema para el caso en que no se especifica un ma´ster. Entrada ¿Co´mo puedo acceder al ma´ster?. Salida Esperada Hola, ¿a que´ ma´ster querria acceder? Salida Obtenida Hola, ¿a que´ ma´ster querria acceder? (Resultado Correcto). 76 Prueba (P CU02 10) Descripcio´n Prueba para el CU 02 (Consultar condiciones de acceso a un ma´ster). Se prueba a interactuar con el sistema sin conexio´n con el servidor de BD. Entrada ¿Co´mo puedo acceder al ma´ster?. Salida Esperada El servicio no esta´ disponible en este momento. Salida Obtenida El servicio no esta´ disponible en este momento. (Resultado Correcto). Prueba (P CU03 01) Descripcio´n Prueba para el CU 03 (Solicitar Informacio´n Cre´dito ECTS). Entrada ¿Que´ es un cre´dito ECTS?. Salida Esperada (Explicacio´n del cre´dito ECTS). Salida Obtenida (Explicacio´n del cre´dito ECTS). (Resultado Correcto). Prueba (P CU03 02) Descripcio´n Prueba para el CU 03 (Solicitar Informacio´n Cre´dito ECTS). Se prueba a interactuar con el sistema sin conexio´n con el servidor de BD. Entrada ¿Que´ es un cre´dito ECTS?. Salida Esperada El servicio no esta´ disponible en este momento. Salida Obtenida El servicio no esta´ disponible en este momento. (Resultado Correcto). Prueba (P CU04 01) Descripcio´n Prueba para el CU 04 (Solicitar Resumen de un Ma´ster). Entrada Disponibilidad del ma´ster de Montes. Salida Esperada (Resumen del master). Salida Obtenida (Resumen del master). (Resultado Correcto). Prueba (P CU04 02) Descripcio´n Prueba para el CU 04 (Solicitar Resumen de un Ma´ster). Se prueba a interactuar con el sistema sin conexio´n con el servidor de BD. Entrada Disponibilidad del ma´ster de Montes. Salida Esperada El servicio no esta´ disponible en este momento. Salida Obtenida El servicio no esta´ disponible en este momento. (Resultado Correcto). Prueba (P CU04 03) Descripcio´n Prueba para el CU 04 (Solicitar Resumen de un Ma´ster). Se prueba a interactuar con el sistema sin especificar el master. Entrada Disponibilidad del ma´ster. Salida Esperada Perdona, ¿de que´ ma´ster estamos hablando?. Salida Obtenida Perdona, ¿de que´ ma´ster estamos hablando?. (Resultado Correcto). 77 reflejar caminos alternativos no tenidos en cuenta inicialmente. Se ha tenido que replantear adema´s en que´ puntos es posible que el actor abandone la conversacio´n con el chatbot. Pregunta de verificacio´n de escenario Escenarios con Incumplimiento P1 (Escenarios con mu´ltiples objetivos) Ninguna. P2 (Contexto del escenario no definido) Ninguna. P3 (Recursos de informacio´n no va´lidos) 1, 3, 5, 6, 8. P4 (Actores no identificados) Ninguna. P5 (Caso de e´xito no cubierto) Ninguna. P6 (Escenarios alternativos cubiertos) 2. Tabla 5.2: Tabla de evaluacio´n de escenarios Por los resultados de la tabla se puede ver que la aplicacio´n de los escenarios ha sido mayoritariamente positiva. Solo se han localizado problemas en te´rminos de recursos de informacio´n y de escenarios cubiertos. El problema de los recursos de informacio´n viene heredado de las user stories, al no tener e´stas una especificacio´n ma´s completa que determinase de forma correcta la informacio´n necesaria para llevar a cabo el escenario. El problema de los escenarios alternativos cubiertos solo se ha dado en un solo escenario, en el que hubo un problema de comprensio´n de uno de los requisitos para llevar a cabo el escenario, dando como resultado que se tuviese que reorientar el conjunto de episodios a seguir para llegar a la meta. Esto provoco´ nuevos escenarios alternativos. Dado que el problema es de comprensio´n de la informacio´n, se considera que es derivado de las user stories. Convendrı´a por tanto involucrar al cliente en este punto para, mostra´ndole una versio´n no te´cnica del escenario, confirmar que esta´ de acuerdo con lo requerido. Prototipado En la mayorı´a de funcionalidades prototipadas el cliente se ha mostrado satisfecho con la lo´gica y el funcionamiento de las mismas, indicando sobre todo correcciones relacionadas con la forma de expresar una informacio´n o con la informacio´n en sı´ misma y no con el funcionamiento del sistema prototipado. Se indica aquı´ por tanto las funcionalidades que no han coincidido con lo que el cliente tenı´a en mente al realizar la propuesta de funcionalidad. Estas funcionalidades se referencian sobre la numeracio´n utilizada para los escenarios y las user stories hasta ahora por corresponderse con estas. Funcionalidad Explicacio´n N º 2 (Consultar condiciones de acceso a ma´ster) Se malinterpreto´ en la explicacio´n de la funcionalidad por parte del cliente el concepto de nacionalidad, entendido como la del usuario. En realidad es la nacionalidad de la entidad expedidora del tı´tulo que da acceso al ma´ster. N º 8 (Solicitar informacio´n del precio del ma´ster) El precio no debe ser calculado, debe ser recuperado de almacenamiento estando este precio aproximado al valor real del ma´ster. N º 9 (Solicitar resumen de un ma´ster) No se requiere tanto un resumen del contenido del ma´ster como una indicacio´n de que es posible cursarlo y un enlace a la pagina del ma´ster. Tabla 5.3: Tabla de evaluacio´n de funcionalidades prototipadas La realizacio´n de tests de usuario, tras el prototipado, fue un elemento clave para involucrar a los usuarios, que no respondı´an de otras maneras a nuestra llamada a colaborar. A raı´z de los tests de usuario, se consiguio´ que proporcionaran datos y recursos importantes para continuar con el proceso adema´s de los comentarios de correcciones y mejoras detectados. En esta etapa, los errores surgidos, ma´s que de la propia etapa son, de nuevo, heredados de las etapas anteriores que aportan la informacio´n necesaria para la funcionalidad que 84 se requiere prototipar. La forma de evitar que los errores se propaguen hasta el prototipado serı´a realizar una sesio´n, compartida con el final de la fase anterior de disen˜o de escenarios, para evitar que estos errores de falta de comprensio´n se extiendan hasta el prototipo y se puedan corregir como muy tarde en la fase de escenarios. Laddering Como se ha explicado, la te´cnica del laddering solo se ha aplicado en ocasiones muy concretas para determinar el valor que realmente perseguı´a el cliente con una funcionalidad que no ha sido adecuada. Estas ocasiones coinciden con las funcionalidades cuyo prototipo no se correspondı´a con lo exigido. Al igual que en la subseccio´n anterior, estas aplicaciones del laddering se referencian sobre la numeracio´n utilizada para los escenarios y las user stories hasta ahora. Funcionalidad Resultados de aplicacio´n de laddering N º 2 (Consultar condiciones de acceso a master) Caracterı´stica - Consecuencia: Nacionalidad asociada incorrectamente. Consecuencia - Causa: Necesidad de adquirir la nacionalidad de la entidad expedidora de grado para sabersi cumple con Bolonia. Causa -Valor: Necesidad de Homologacio´n si no cumple con Bolonia. N º 8 (Solicitar informacio´n del precio del ma´ster) Caracterı´stica - Consecuencia: Cifra de precio calculado incorrecta. Consecuencia - Causa: Precio variable entre an˜os pese a mantener nu´mero de cre´ditos. Causa -Valor: Precio fijado por terceros, necesidad de indicar una cifra aproximada almacenada, no calculada. N º 9 (Solicitar resumen de un ma´ster) Caracterı´stica - Consecuencia: Resumen inadecuado para reflejar contenido del ma´ster. Consecuencia - Causa: Contenido dependiente de cambio de planes. Causa -Valor: Mostrar contenido solo como referencia a la pa´gina de la UVa donde se cambiara´. Tabla 5.4: Tabla de evaluacio´n de aplicacio´n de laddering A la vista de la tabla, se puede ver que en los casos que se ha aplicado el laddering se ha conseguido obtener el valor asociado a la funcionalidad que perseguı´a realmente el cliente para la interaccio´n del usuario con el chatbot. Se ha podido identificar desde la conexio´n caracterı´stica - consecuencia hasta la causa - valor, por lo que se considera satisfactoria la aplicacio´n del laddering y los resultados obtenidos por esta te´cnica. De nuevo, serı´a recomendable no permitir que los problemas identificados se propaguen hasta la fase de test de usuario donde se aplica esta te´cnica para no tener que necesitar iteraciones a mayores donde aplicar las correcciones. 5.7.2. Evaluacio´n general de la aplicacio´n de la propuesta Se contestan ahora a las preguntas de evaluacio´n general de la metodologı´a, alineadas con los objetivos de la propuesta, para poder valorar el alcance de esta. P1: ¿Que´ nu´mero de participantes hemos podido involucrar? El nu´mero de participantes ha sido en todas las iteraciones de tres personas. Se ha considerado incluir un nu´mero de participantes mayor, pero dadas las caracterı´sticas del proyecto no es posible conseguir acceso a una poblacio´n de taman˜o ma´s elevado. Se considera importante que se disponga de una poblacio´n mayor para poder identificar y capturar las necesidades ma´s relevantes de los usuarios y las formas ma´s comunes de su interaccio´n con el sistema. P2: ¿Que´ caracterı´sticas poseen estos participantes? Los participantes consisten en dos profesores de la ETSIIAA perteneciente a la Universidad de Valladolid y un alumno de la misma escuela que ha finalizado sus estudios en la misma y colabora como te´cnico en el IUFOR. Los profesores pertenecen tambie´n al IUFOR por lo que poseen los conocimientos suficientes tanto en materia forestal como en entornos educativos para llevar a cabo un proceso de recogida de datos sobre ellos. Estos participantes reu´nen las caracterı´sticas necesarias de conocimiento del a´mbito de ciencias forestales y relacio´n con los programas de grado de este a´mbito como para poder participar en el trabajo. 85 P3: ¿Cua´l es el tiempo que hemos necesitado de ellos? Se han realizado sesiones de treinta minutos por cada iteracio´n para mostrar el prototipo y obtener informacio´n tanto de correcciones como de nuevas funcionalidades, adicionalmente se ha necesitado contactar con los participantes mediante correo electro´nico para realizar aclaraciones. Dadas las conclusiones obtenidas en la aplicacio´n de las te´cnicas, comentadas en la sub seccio´n anterior, serı´a recomendable incorporar una fase inicial de la iteracio´n donde se especifiquen, con detalle, exclusivamente las funcionalidades necesarias a incluir en el prototipado de la iteracio´n. La fase de test de usuario solo se ocuparı´a de correcciones a la funcionalidad que se ha mostrado en el prototipo y de obtener propuestas para nuevas funcionalidades. Estas propuestas se anotarı´an para su posterior especificacio´n por parte del cliente en una reunio´n posterior, al comienzo de la siguiente iteracio´n. Esto otorgarı´a responsabilidad sobre el desarrollo del prototipo al propio cliente, forza´ndole a pensar en las funcionalidades a prototipar, ya que las que no recibiesen informacio´n suficiente en la reunio´n de la fase inicial no se podrı´an llevar a cabo en la iteracio´n a comenzar. P4: ¿Se ha confirmado la mayorı´a de cosas ensen˜adas en el prototipo? Si, se han realizado aclaraciones e indicado correcciones, pero la funcionalidad se ha confirmado como mayormente correcta. Como se ha indicado en la evaluacio´n de las te´cnicas, la causa mayoritaria de no confirmar una funcionalidad es no disponer de descripciones suficientes por parte del cliente de funcionalidades proyectadas para la iteracio´n. Esto se debe a que el propio cliente no esta´ del todo seguro sobre que´ es lo que quiere para que le resuelva el problema que tiene. Es ma´s fa´cil, desde su punto de vista, el plantear correcciones o modificaciones sobre un resultado “palpable” en forma de prototipo, que sobre un concepto. P5: ¿Se han propuesto mejoras a lo mostrado en el prototipo? Si, se han propuesto mejoras tanto en contenido conversacional del chatbot como en cuanto a correcciones funcionales. En las iteraciones iniciales no se dio tanta importancia por parte del cliente al contenido conversacional pero a medida que se ha familiarizado con el sistema, a trave´s de los test de usuario, a partir de la tercera iteracio´n se ha empezado a pedir mejoras conversacionales que modulen el dia´logo del chatbot de una forma ma´s natural. Las correcciones funcionales se han realizado, como se proyectaba, durante el test de usuario al involucrarse ellos mismos en el desarrollo del sistema. P6: ¿Se ha propuesto an˜adir mayor funcionalidad de lo mostrado en el prototipo? Si, en casi todas las iteraciones (salvo en la u´ltima) se ha propuesto nueva funcionalidad para la siguiente iteracio´n que amplia las capacidades del chatbot respecto a los propuesto en el prototipo de la iteracio´n. Aquı´ es donde han surgido algunos de los problema de informacio´n detectados. Al comprobar mediante el test de usuarios los clientes el alcance del prototipo, han podido entender que´ problemas no estaba cubriendo el chatbot en cada iteracio´n. En base a los problemas que no se estaba cubriendo con el chatbot han podido plantear nuevas funcionalidades que diesen respuesta. Han conseguido declarar el problema que no se cubrı´a, pero no han aportado la informacio´n que se necesitaba para cubrirlo, o han quedado en aportar informacio´n pero finalmente no lo han realizado. Esto se debe a que no han dedicado siempre tiempo a pensar en el sistema fuera de las reuniones. Dado que la interaccio´n con ellos es puramente reactiva, es decir, reaccionando en funcio´n de incorrecciones que hayan detectado en algo que les hemos ensen˜ado, no hay respuesta proactiva por su parte. Esto puede deberse a que no perciben que tengan una responsabilidad asignada para cumplir antes del pro´ximo test de usuarios. Para solventar esto se propone, como se ha explicado ya, indicar que solo se pueden implementar las propuestas de funcionalidades de las que se tiene informacio´n. Se necesita por tanto la reunio´n de la fase inicial expuesta para que un representante del cliente exponga la informacio´n y se decida en funcio´n de esta que´ es lo que va a prototiparse en la iteracio´n. P7: ¿Podemos valorar positivamente el resultado obtenido en la prueba en te´rminos de participacio´n? Si, los participantes han colaborado en el test de usuario y han respondido a las preguntas formuladas posteriormente. Solo ha habido problemas en torno a la asistencia en un par de ocasiones donde gente que ha llegado tarde a la reunio´n ha tenido que recibir un resumen de lo hablado hasta el momento. 86 P8: ¿Han entendido los participantes del test con usuarios lo que se requerı´a de ellos o ha sido necesario aclararlo varias veces? Se ha requerido aclarar la necesidad de concretar a mayores el dominio sobre el que opera el chatbot, pero en cuanto a la operativa y la participacio´n en el test de usuarios no se ha requerido repetir las instrucciones a seguir. En una ocasio´n al conocer los usuarios las funcionalidades del prototipo de la iteracio´n anterior se han intentado poner a probar estas funcionalidades por su cuenta, teniendo que redirigirles a las funcionalidades prototipadas a probar en la iteracio´n en la que se estaba. Esto muestra la importancia de seguir un guio´n conocido por todas las partes, para que antes del inicio de la reunio´n de test de usuarios tengan la oportunidad de consultar que´ es lo que se va a tratar en la reunio´n. P9: ¿Se ha requerido recoger ma´s informacio´n de los usuarios tras haber realizado los test de usuario? Se ha requerido realizar aclaraciones sobre la funcionalidad en ocasiones concretas y siempre en la siguiente reunio´n de test de usuarios. En ocasiones se ha necesitado solicitar por correo electro´nico informacio´n para aclarar funcionalidades especı´ficas. Sin embargo, no se han realizado reuniones a mayores para recabar ma´s informacio´n de la funcionalidad a prototipar en la siguiente iteracio´n. 5.8. Discusio´n El resultado presentado mediante la aplicacio´n de la propuesta de metodologı´a al caso VirtualForest muestra que, aunque se cumplen los objetivos de la metodologı´a, se esta´ sufriendo de falta de informacio´n en el prototipado de ciertas funcionalidades porque el cliente no la esta´ aportando en las fases iniciales de cada iteracio´n. Los objetivos que se han podido cumplir y que sı´ han funcionado como parte de la metodologı´a han sido, en primer lugar, el de garantizar que los artefactos obtenidos permiten el ana´lisis y disen˜o del sistema y en segundo lugar, el de mantener informado al cliente obteniendo feedback sobre el sistema. Solo se ha podido cumplir parcialmente el objetivo de la minimizacio´n de los problemas de informacio´n ya que se ha minimizado el riesgo de no obtener la informacio´n pero au´n se puede mejorar ma´s la metodologı´a para obtener toda la informacio´n necesaria para el prototipado de una funcionalidad sin necesidad de arrastrar el problema de falta de informacio´n entre fases. El primer objetivo cumplido ha permitido obtener, como resultado de la aplicacio´n de la metodologı´a, artefactos de informacio´n necesarios para comprender el contexto comunicativo y de interaccio´n con un usuario a la hora de realizar la elicitacio´n de requisitos en el ana´lisis del sistema y posteriormente en la documentacio´n de casos de uso y diagrama de clases elaborados a partir de estos. Los artefactos obtenidos permiten mostrar el disen˜o y lo´gica del sistema sobre el contexto de la comunicacio´n con un usuario. A trave´s de estos artefactos se obtiene la nocio´n de co´mo se comunica el sistema y que´ lo´gica se sigue para cumplir los objetivos del dia´logo. El segundo objetivo cumplido ha sido el involucrar al cliente en el desarrollo del sistema para permitir obtener informacio´n tanto de nuevas funcionalidades, como para permitir realizar correcciones a las ya prototipadas. Como prueba de que se haya cumplido es que, en todas las iteraciones, se ha obtenido informacio´n sobre correcciones o ampliaciones de la funcionalidad para continuar el desarrollo. Por lo tanto el involucrar al cliente en el proceso de aplicacio´n de la metodologı´a ha tenido un resultado satisfactorio. El objetivo cumplido parcialmente de falta de informacio´n ha provocado problemas derivados de esta falta de informacio´n, en una fase inicial de la metodologı´a, que se transforman en problemas de incorreccio´n de funcionalidades al extenderse por las distintas fases hasta que se resuelven en la aplicacio´n de la te´cnica del laddering. Para poder cumplir el objetivo totalmente serı´a necesario un proceso de confirmacio´n y aporte de informacio´n por parte del cliente en las fases tempranas de la metodologı´a. Este impedirı´a que los problemas se propaguen ma´s alla´ de las fase inicial, mejorando la adquisicio´n de informacio´n. Aunque se ha estructurado la sesio´n de test de usuario mediante planes de reunio´n, para dejar tiempo suficiente a plantear funcionalidades para la siguiente iteracio´n, serı´a ma´s conveniente que los clientes plantearan las funcionalidades en esa sesio´n pero que concretasen y aportasen informacio´n en una sesio´n posterior a celebrarse en un momento previo al comienzo de la fase de seleccio´n de objetivos para permitir que los clientes tomen un papel proactivo en al metodologı´a, piensen de forma adecuada y 87 recopilen la informacio´n necesaria para las funcionalidades proyectadas si se han de prototipar en la iteracio´n por comenzar. La propuesta para mejora de la metodologı´a incluirı´a una fase inicial con el cliente donde se especificase la informacio´n de las propuestas de funcionalidad nueva, realizadas como parte de la fase de test de usuarios. En base a la informacio´n recopilada se decidirı´a en la fase de seleccio´n de objetivos si, a la vista de esta, es viable llevar a cabo el prototipado de la funcionalidad o existen demasiadas dudas sobre el posible funcionamiento del prototipo correspondiente como para llevarlo a cabo en esta iteracio´n. La propuesta metodolo´gica con esta modificacio´n se muestra en la figura 5.19. Figura 5.19: Esquema del flujo de fases a llevar a cabo en la propuesta de mejora de metodologı´a final. En azul se muestra la ampliacio´n propuesta. Como se puede observar en la propuesta de mejora, se ha incluido una fase previa a la seleccio´n de objetivos que indica la especificacio´n por parte del cliente de los recursos de informacio´n necesarios para los objetivos que e´ste quiere que se aborden en el prototipo de la iteracio´n por empezar. La contextualizacio´n inicial ya no darı´a paso a la fase de seleccio´n de objetivos, sino que darı´a paso a esta fase donde se solicitarı´a al cliente los recursos de informacio´n iniciales para la primera iteracio´n. Dada la poca capacidad de tiempo disponible del cliente para la atencio´n a este proyecto, la realizacio´n de esta fase se tendrı´a que realizar probablemente a trave´s de medios de comunicacio´n ası´ncronos tal como comunicacio´n a trave´s de correos electro´nicos. Sin embargo, esto tiene el peligro de no ser eficaz, ya que implicarı´a que el cliente proporcionase todos los recursos de informacio´n necesarios para poder llevar a cabo todas las funcionalidades propuestas y que no quedase ninguna duda en torno a esta informacio´n. Por lo tanto, se recomienda una reunio´n sı´ncrona con el cliente en la que, a aprtir de un plan de reunio´n de no ma´s de 10 minutos de duracio´n, se proporcionase al desarrollador un dia´logo de prueba que mostrase la funcionalidad a reproducir con el chatbot en su 88 interaccio´n con el usuario y los recursos de informacio´n necesarios para poder construir ese dia´logo. 5.9. Conclusio´n del capı´tulo Como conclusio´n a este capı´tulo hay que decir que se ha presentado la organizacio´n del trabajo de aplicacio´n de la metodologı´a en cuatro iteraciones separadas, se ha caracterizado a los participantes del proceso de evaluacio´n de prototipos por el test de usuario, se ha mostrado y explicado los artefactos resultantes de la aplicacio´n de la metodolo´gia ,el ana´lisis de la informacio´n que se ha realizado y las pruebas de validacio´n del trabajo realizadas. Por u´ltimo se ha discutido la evaluacio´n del resultado favorable, obtenido por la aplicacio´n de la metodologı´a. 89 90 Capı´tulo 6 Conclusiones y trabajo futuro En este trabajo se ha explicado que los chatbots son agentes conversacionales que a trave´s de distintas te´cnicas, entre ellas el NLU, intentan simular el flujo no estructurado de la conversacio´n humana. Se ha visto que los dominios de aplicacio´n ma´s populares de estos sistemas son la atencio´n al cliente, la salud y bienestar fı´sico y la educacio´n. Dentro de la educacio´n se ha demostrado los roles que puede tomar el chatbot en la comunicacio´n con los alumnos y que el rol ma´s popular es el de preguntas y respuestas. Por la investigacio´n realizada, se ha determinado que los principales problemas que afectan a este tipo de sistema son de naturaleza tecnolo´gica (necesita´ndose un ana´lisis de alternativas de implementacio´n para poderlos evitar) y conceptuales, relacionados con el contexto de comunicacio´n (necesita´ndose un ana´lisis de te´cnicas de elicitacio´n de requisitos para escoger te´cnicas que ayuden a abordarlos). Ante la situacio´n del proyecto VirtualForest, donde se solicito´ un chatbot para responder a problemas administrativos del alumnado de programas de ma´steres de la ETSIIAA, en el que los clientes no tenı´an claro el problema a cubrir, el co´mo cubrirlo, ni la necesidad de definirlo que se les transmitio´, se hizo patente la necesidad de un proceso pensado y refinado, una metodologı´a, cuya aplicacio´n resultase en un chatbot que diese respuesta a las necesidades propuestas por los clientes. Por esta razo´n y ante la falta de alternativas que abordasen el problema desde un punto de vista de ana´lisis y no de desarrollo, en el trabajo presentado se ha realizado la propuesta de IMADTC y los criterios de validacio´n de la misma tanto por la aplicacio´n de las te´cnicas que la componen como por los resultados generales obtenidos en su aplicacio´n. La propuesta de metodologı´a IMADTC, se basa en al realizacio´n iterativa de una serie de tareas para obtener y refinar informacio´n, hasta realizar un prototipo aprobado por el cliente, que de esta forma define el ana´lisis de necesidades del cliente. Como me´todo de validacio´n de la metodologı´a se ha aplicado e´sta al caso del proyecto VirtualForest obtenie´ndose el desarrollo de este sistema como una contribucio´n secundaria del trabajo y que se detalla en el cap. 5. La evaluacio´n de la metodologı´a muestra que la seleccio´n de te´cnicas de elicitacio´n de requisitos es adecuada, pero que algunas debilidades ocasionales a la hora de recoger recursos de informacio´n, provocan a su vez imprecisiones en la funcionalidad prototipada. La forma propuesta de resolverlo serı´a la aplicacio´n de una breve entrevista con el cliente en las fases iniciales de la metodologı´a para aportar estos recursos de informacio´n e impedir que los fallos iniciales se extiendan por fases posteriores de la metodologı´a. Como trabajo futuro, quedarı´a seguir aplicando la propuesta a nuevos casos para por un lado, comprobar la completitud de la propuesta respecto a otros chatbots de caracterı´sticas similares pero no iguales y por otro lado para seguir refina´ndola, aplicando modificaciones y correcciones a la misma y para poder determinar hasta que´ punto es una propuesta metodolo´gica va´lida y eficaz para los objetivos propuestos. 91 92 Bibliografı´a [1] “Virtual forest, virtualization of forest studies, proyecto financiado por la comisio´n europea dentro de las acciones ka2 - cooperation for innovation and the exchange of good practices, ka226 - paternships for digital education readiness. duracio´n: 01/03/2021 al 28/02/2023.” [2] R. Adrion, “Research methodology in software engineering,” Summary of the Dagstuhl Workshop on Future Directions in Software Engineering, volumen 18, pp. 36–37, 1993. [3] A. Xu, Z. Liu, Y. Guo, V. Sinha, and R. Akkiraju, “A New Chatbot for Customer Service on Social Media,” in Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems, CHI ’17, (New York, NY, USA), pp. 3506–3510, Association for Computing Machinery, May 2017. [4] B. R. Ranoliya, N. Raghuwanshi, and S. Singh, “Chatbot for university related FAQs,” in 2017 International Conference on Advances in Computing, Communications and Informatics (ICACCI), pp. 1525–1530, Sept. 2017. [5] F. Colace, M. D. Santo, M. Lombardi, F. Pascale, A. Pietrosanto, and S. Lemma, “Chatbot for e-learning: A case of study,” IJMERR issue 7 n º 5 pp. 528-533, 2018. [6] N. Albayrak, A. Ozdemir, and E. Zeydan, “An overview of artificial intelligence based chatbots and an example chatbot application,” in 2018 26th Signal Processing and Communications Applications Conference (SIU), (Izmir), pp. 1–4, IEEE, May 2018. [7] L. Cui, S. Huang, F. Wei, C. Tan, C. Duan, and M. Zhou, “SuperAgent: A Customer Service Chatbot for Ecommerce Websites,” in Proceedings of ACL 2017, System Demonstrations, (Vancouver, Canada), pp. 97–102, Association for Computational Linguistics, 2017. [8] B. AbuShawar and E. Atwell, “ALICE Chatbot: Trials and Outputs,” in scielomx, vol. 19, pp. 625–632, 12 2015. [9] Y. Zhang, T. Xu, and Y. Dai, “Research on Chatbots for Open Domain: Using BiLSTM and Sequence to Sequence,” in Proceedings of the 2019 International Conference on Artificial Intelligence and Computer Science, AICS 2019, (New York, NY, USA), pp. 145–149, Association for Computing Machinery, July 2019. [10] D. Rooein, “Data-Driven Edu Chatbots,” in Companion Proceedings of The 2019 World Wide Web Conference, WWW ’19, (New York, NY, USA), pp. 46–49, Association for Computing Machinery, May 2019. [11] A. Følstad and M. Skjuve, “Chatbots for customer service: user experience and motivation,” in Proceedings of the 1st International Conference on Conversational User Interfaces, CUI ’19, (New York, NY, USA), pp. 1–9, Association for Computing Machinery, Aug. 2019. [12] P. Kucherbaev, A. Psyllidis, and A. Bozzon, “Chatbots as conversational recommender systems in urban contexts,” in Proceedings of the International Workshop on Recommender Systems for Citizens, CitRec ’17, (New York, NY, USA), Association for Computing Machinery, 2017. 93 [111] J. C. S. do Prado Leite, G. D. S. Hadad, J. H. Doorn, and G. N. Kaplan, “A Scenario Construction Process,” Requirements Engineering, vol. 5, pp. 38–61, July 2000. [112] T. Veludo-de Oliveira, A. Ikeda, and M. Campomar, “Discussing Laddering Application by the Means-End Chain Theory,” The Qualitative Report, Jan. 2015. [113] “Responsible bots: 10 guidelines for developers of conversational AI,” Nov. 2018. [114] “Information processing — documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts,” standard, International Organization for Standardization, Feb. 1985. 100 Ape´ndice A: Acro´nimos AIML (Artificial Intelligence Mark-up Language) API (Application Programming Interface) ASR (Automatic Speech Recognition) CDD (Conversation Driven Development) CD (Continuous Delivery) CI (Continuous Integration) ES (Essential Edition) GDPR (General Data Protection Regulation) HTTP (Hypertext Transfer Protocol) IA (Inteligencia Artificial) IMADTC (Iterative Methodology for the Analysis and Development of Text based Chatbots) LSTM (Long Short Term Memory) MAU (Monthly Active Users) MIT (Massachusetts Institute of Technology) ML (Machine Learning) NLU (Natural Language Understanding) REST (Representational State Transfer) SDK (Software Development Kit) STT (Speech To Text) TTS (Text to Speech) VA (Virtual Assistant) XP (Extreme Programming) YAML (Acro´nimo recursivo: YAML(Yet Another Markup Language) Ain’t Markup Language) 101 102 Ape´ndice B: Co´digo del backend del prototipo de VirtualForest El co´digo se encuentra en formato descargable en https://github.com/juaalon/CodigoPrototipoEntregaTFM. git. A este co´digo se aplican las mismas licencias que al resto del trabajo. 103