Está en la página 1de 33

UNIVERSIDAD NACIONAL FEDERICO VILLARREAL

FACULTAD DE INGENIERÍA INDUSTRIAL Y SISTEMAS

CURSO:
Ingeniería de Software I
DOCENTE:
Dr. Ing. Carlos Miguel Franco Del Carpio
TÍTULO DEL PROYECTO:
IMPLEMENTACIÓN DE UN CHATBOT EN UN INSTITUTO DE
IDIOMAS
APELLIDOS Y NOMBRES:
Paima Martínez, Lucía Araceli
Garro Lugo, Junnior Rodrigo
Sánchez Terrasse, Francisco Javier
Montesinos Gamboa, Gabriel Eduardo

Ciclo y Sección: VI “C”

2021
Nombre del proyecto: CHATBOT en un instituto de idiomas.

1. Organización
1.1 Introducción
Como sabemos, los chatbots son utilizados por las instituciones principalmente para llevar a
cabo tareas y funciones de acuerdo a sus necesidades: realizar pedidos automáticos,
comunicar incidencias técnicas, pedir información sobre un determinado producto o servicio,
dar información, hacer consultas, pedir información por algún curso, etc.

1.2 Reseña histórica


El Centro Universitario de Idiomas de la Universidad Nacional Villarreal, tiene origen en el
año 1980 en la Facultad de Ciencias Económicas, en esa época funcionaba bajo la dirección
del Instituto de Arte. En el año 1992, cambia de ubicación al local del Jr. Chancay, bajo la
dirección del Centro Universitario de Extensión Cultural (CUNEXCU) que posteriormente
cambió de nombre, denominándose Centro de Extensión Universitaria y Proyección Social
(CEUPS)

El día 17 de agosto del 2004, se independiza como órgano de Apoyo Académico


Administrativo, dependiente del Vicerrectorado Académico de acuerdo al Estatuto vigente
2001 y el Reglamento de Organización y Funciones de la universidad, aprobado mediante
Resolución Nº 8463-2004-UNFV de fecha 22 de abril del 2004.

El día 16 de Julio del 2019, mediante resolución Nº 5821-2019-UNFV, deja el nombre


institucional de: “Instituto de Idiomas” para llamarse: “Centro Universitario de Idiomas”.

1.3 Descripción de la empresa

El Centro Universitario de Idiomas, acorde con la visión de la Universidad Nacional


Federico Villarreal, orientada a la excelencia académica; funciona con una comunidad de
reconocidos docentes de idiomas y profesores nativos, contando con moderna tecnología
y nuevos métodos de enseñanza. Los estudiantes son formados en el conocimiento y
práctica de idiomas extranjeros y nativos de acuerdo a las exigencias del proceso de
globalización, que les permitan la inserción en las principales redes del conocimiento
mundial.

2. Estructura organizacional
2.1 Misión y Visión

Misión: “Fomentar el aprendizaje y dominio de lenguas extranjeras y nativas en toda


la comunidad Villarrealina y público en general, certificando el conocimiento de idiomas
con principios de eficiencia, competitividad y valores”.

Visión: “Ser una institución de prestigio, líder en la enseñanza de idiomas,


caracterizada por su excelencia académica y su eficiente gestión administrativa al
servicio de la educación multilingüe en el Perú.”
3. Área de desarrollo
3.1 Problemática
Debido a la concurrencia de información, encontramos que en la portal del Centro
Universitario de Idiomas de la Universidad Nacional Federico Villarreal, al no
contar con un medio directo de consultas, los usuarios tienen como medios el chat
de Facebook, WhatsApp y el correo electrónico para recibir información, sin
embargo; se ha detectado demora al momento de recibir respuesta y lo que se
requiere es una respuesta inmediata para una toma rápida de decisiones.

3.2 Descripción del Proyecto

Con el uso de un chatbot, ya no es necesario acudir a una escuela de idiomas o en su


defecto visitar otro país, para poder entablar una charla en otro idioma y practicar tus
habilidades. Usar un chatbot puede representar diversas ventajas. Primero, la
disponibilidad es ilimitada, no es necesario levantarse temprano si uno no quiere o perder
horas en el tráfico para acudir a un centro de aprendizaje, se puede usar desde donde uno
quiera y cuando quiera. Otra ventaja, definitivamente puede ser el costo, ya que en
ocasiones los chatbots de las aplicaciones están disponibles de manera gratuita.

El chatbot sería una herramienta muy importante para la clasificación de los elementos al
momento de pedir una información. En él, el usuario podría hacer consultas de horarios
según el nivel que desee y con cuántos cupos dispone para poder matricularse.

Posibles preguntas:

● Programa de interés: darle una lista y que seleccione en qué está interesado.
● Cuándo quiere empezar a estudiar (importante): con esta pregunta
sabemos si se trata de alguien que está próximo a tomar la decisión o
solamente está mirando. Con esta información el equipo comercial puede ser
más proactivo o menos.
● Modalidad: virtual, presencial o mixta.
● Horario: ejemplo mañana o tarde.
● Otras más específicas del programa: nivel actual del idioma, si cualifica
para becas o ayudas, si tiene familiares en la institución, etc.

3.3 Integrantes del área

Identificación de Descripción de Responsable


actividad actividad
SQA Gestión de calidad Garro, Montesinos

Verificación Verificación y validación Garro, Montesinos

Gestión Gestión de proyecto Sánchez

Requerimientos Recolección y actualización de Sánchez, Paima, Garro y


requerimientos Montesinos

Diseño Diseño de la arquitectura Paima, Garro y Montesinos

Implementación Implementación de prototipos y Garro y Montesinos


producto final

Configuración Gestión de la configuración y Sánchez


mantenimiento de la línea base

Evaluación Evaluación del proyecto por cada Paima, Garro y Montesinos


fase.

4. Vista general del proyecto

4.1 Alcance del proyecto

Los chatbots para educación están siendo una de las herramientas que están cambiando la
forma en la que los alumnos se relacionan con instituciones educativas en el proceso de
admisiones y venta.

4.2 Limitación del proyecto

El proyecto no puede realizar las siguientes actividades:

● Matrícula directa en los cursos o ciclos.


● Evaluaciones: Examen internacional y examen de clasificación.
● Pagos de mensualidad y matrícula.
● Solicitud directa de certificados.
● Interactuar directamente con algún administrativo o docente.

4.3 Organización del proyecto

Líder de Proyecto

Sánchez Terrasse, Francisco Javier


Analista de Sistemas

Paima Martínez, Lucía Araceli

Analista Programador

Garro Lugo, Junnior Rodrigo

Analista Programador

Montesinos Gamboa, Gabriel Eduardo

4.4 Roles y responsabilidades

Puesto Responsabilidad

Líder de proyecto ● Dirigir las actividades del equipo. Planifica el control


del proyecto.
Sánchez Terrasse, Francisco ● Principal responsable de la finalización del proyecto
Javier según lo previsto.
● Desempeña un papel principal en la planificación
general, ejecución, monitoreo, control y cierre del
proyecto.
● Sus responsabilidades también incluyen la gestión de
riesgos, mediación de conflictos y gestión de
relaciones con las partes interesadas.

Analista de Sistemas ● Elaboración del Modelo de Análisis y Diseño.


● Se encarga de identificar las fallas y proponer
Paima Martínez, Lucía soluciones desde su área, buscando siempre
Araceli alternativas viables.
● Supervisa el óptimo funcionamiento de los sistemas.

Analista programador ● Construcción de prototipos.


● Colaboración en la elaboración de pruebas funcionales,
Garro Lugo, Junnior modelos de datos y validación con el usuario.
Rodrigo ● Hacer levantamiento y análisis de requerimientos,
desarrollo de software, construir aplicaciones y
soluciones tecnológicas.

Analista programador ● Construcción de prototipos.


● Colaboración en la elaboración de pruebas funcionales,
Montesinos Gamboa, modelos de datos y validación con el usuario.
Gabriel Eduardo ● Hacer levantamiento y análisis de requerimientos,
desarrollo de software, construir aplicaciones y
soluciones tecnológicas.

5. Administración del proyecto


5.1 Plan de desarrollo

Actividad Procedimiento Responsable Involucrados

Reunión de Interacción principal Administrador


Requerimientos entre los miembros del Responsable de SQA
equipo en donde se Responsable de la
conoce la Responsable Verificación Analista
realidad del problema y de de DB
se define las analista
características del
sistema a
construir.

Validación Instancia en la cual se Todos los miembros


de llega a un acuerdo de Responsable del equipo
Requerimientos que se entiende cuáles de
son las características analista
del sistema a construir.

Reunión Evaluativa Reunión con el Asesor Todos los miembros


al final de cada Fase del equipo
donde participa todo el
equipo. Se discutirá la
evaluación de la Fase y Asesor
qué aspectos corregir de
ahí en adelante.

Reunión de Equipo Reunión semanal en la Todos los miembros


que se evalúa el estado del equipo
del proyecto, el estado
de los riesgos, las
desviaciones encontradas Administrador
y las acciones a tomar.
Reunión Reunión en la que los Responsable de SQA
de responsables responsables de las Responsable de DBA
por área distintas áreas coordinan Responsable de
sus actividades, por Verificación
ejemplo, se discute la Administrador Coordinador de
planificación de la Desarrollo
siguiente iteración. Responsable de
Analistas Responsable
de Implementación

Verificación Revisión de los Responsable de Asistente


de Productos productos entregables SQA de SQA
para que cumplan con
sus respectivos
REQUERIMIENTOS.

Revisión Revisión de todos los Responsable de Asistente de SQA


de Entregables entregables para SQA
asegurarse de que
cumplan con los
criterios de calidad
planificados.

Revisión Revisión y detección de Responsable de Todos los miembros


Técnica Formal defectos en la función, SQA del equipo
la lógica o la
implementación de los
productos entregables
más importantes.

Presentación Se le presenta el Administrador Arquitecto


del Producto producto construido al Especialista Técnico
cliente para ser evaluado
por el
mismo.

5.2 Plan de iteración

Hito o Evento Significativo Fecha Programada

Identificación de 6 días (Del 18 de febrero – 23 de


requerimientos febrero)

Análisis y Diseño 23 días (Del 27 de febrero – 23 de


marzo)
Desarrollo del software 65 días (Del 23 de marzo – 26 de mayo)

Pruebas 26 días (Del 27 de mayo – 21 junio)

Despliegue 2 días (Del 22 de junio – 23 de junio)

5.3 Gestión de riesgos

ID DESCRIPCIÓN DEL TIPO IMPACTO ACCIONES ACCIONES


RIESGO RIESGO DE PREVENTIVAS CORRECTIVAS
RIESGO

R01 Desviación excesiva No finalizar el Convocar una Implementar el


de las horas de proyecto en la reunión para cambio a través
dedicación estimadas Riesgo del fecha revisar la de control
por parte de los Proyecto. comprometida. planificación. integrado de
integrantes Aumento del cambios.
del proyecto. coste del
proyecto en
horas.

R02 Requisitos poco claros Riesgo del El producto no Implementar Implementar el


y con falta de valor producto. cumple con las medidas de cambio a través
agregado expectativas y control y de control
especificaciones aseguramiento integrado de
requeridas. de calidad del cambios.
producto.

R03 Falta de experiencia Riesgo del No finalizar el Implementar las Implementar el


en tareas de Proyecto. proyecto en la acciones cambio a través
planificación y mala fecha correctivas del de control
gestión. comprometida. caso, en base de integrado de
un análisis cambios.
costo/beneficio
R04 Diseño erróneo. Riesgo del El producto Implementar Implementar el
producto no cumple con medidas de cambio a través
las expectativas control y de control
y aseguramiento integrado de
especificaciones de calidad del cambios.
requeridas. producto.

R05 Afecta el costo Riesgo del Afecta el Ejecutar Implementar el


del proyecto. proyecto. proyecto en acciones cambio a través
general. preventivas que de control
no afecten las integrado de
restricciones del cambios.
proyecto.

R06 Afecta el tiempo Riesgo del Afecta el Ejecutar Implementar el


de ejecución. proyecto. proyecto en acciones cambio a través
general. preventivas que de control
no afecten las integrado de
restricciones del cambios.
proyecto.

R07 Afecta al alcance del Riesgo del Afecta el Ejecutar Implementar el


proyecto. proyecto. proyecto en acciones cambio a través
general. preventivas que de control
no afecten las integrado de
restricciones cambios.
del proyecto.

R08 Afecta la calidad del Riesgo del El producto Verificar De no cumplir


proyecto. proyecto. no cumple las listas con los controles
especificaciones de de aseguramiento
técnicas control de y control de
establecidas. calidad para calidad, se deben
garantizar el ejecutar acciones
cumplimiento de control de
del proceso cambios.
estándar.
6. Métodos y técnicas estructuradas para la identificación de requerimientos

6.1 Entrevista

Las entrevistas realizadas acerca del uso de chatbots en la internet se encuentran con una gran
aprobación por la mayoría de jóvenes que respondieron a las entrevistas. Con comentarios
como “Los chatbots son un amigo más en la agenda de contactos”, “ofrecer al cliente una
nueva herramienta que le facilite la vida”.

6.2 Cuestionario

Los cuestionarios, de igual modo, con preguntas más elaboradas con respecto al área de
respuestas del instituto de idiomas, se cuenta con una aprobación mayor para los jóvenes. Ya
que responden con mayor detalle sobre qué va a responder el chatbot.

7. Plan de gestión de requerimientos

ID Descripción Prioridad Status

RF 01 El chatbot debe responder cuando se inicia Muy alta pendiente


una conversación.

RF 02 El chatbot debe funcionar en un cliente web. Alta pendiente

RF 03 El chatbot debe funcionar en dispositivos móviles Alta pendiente


u ordenadores.

RF 04 El chatbot debe permitir a cualquier usuario Alta pendiente


chatear.

RF 05 El chatbot debe informar al usuario si no hay Alta pendiente


respuesta disponible.

RF 06 El chatbot debe preguntar al usuario si la Media pendiente


respuesta dada es satisfactoria.

RF 07 El chatbot debe indicar un mensaje de ayuda Media pendiente


especificando qué sabe hacer.

RF 09 El chatbot debe entender diferentes formas de Media pendiente


hacer una misma pregunta.

RF 10 El chatbot debe dar guía a preguntas específicas. Alta pendiente

RF 11 El sistema debe guardar cada pregunta con su Media pendiente


respectiva respuesta cuando conteste el usuario.

7.1. Especificación de Requerimientos


7.1.1 Estándares para especificar requerimientos

La Especificación de Requerimientos es un documento que describe las características


que debe cumplir un software que va a ser desarrollado o modificado, y se elabora con el
fin de garantizar su cumplimiento. Tiene como objetivo documentar y analizar los
requerimientos, necesidades y restricciones que presenta el proyecto, de tal forma que el
desarrollo del sistema a implementar sea lo más eficiente posible, y además, que
proporcione una referencia para validar que el sistema final se ajuste a las necesidades de
los usuarios. Para este caso, se ha estructurado como lo estipulan las directrices del
estándar IEEE 830.

El estándar IEEE 830-1998 es un conjunto de recomendaciones para la especificación de


los requerimientos o requisitos de software el cual tiene como producto final la
documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir
con la totalidad de exigencias estipuladas.

7.1.2 Generación de la lista de requerimientos

ID Nombre Necesidad Estado Versión

1 Disponibilidad para PC esencial cerrado 1


y móviles

2 Registro de usuario opcional cerrado 1

3 Reconocimiento de esencial cerrado 1


idioma

4 Reconocimiento de esencial cerrado 1


palabras

7.1.3 Especificación de requerimientos funcionales

Los requerimientos funcionales son aquellos que describen las funciones del
sistema, es decir, los que especifican qué es lo que el sistema debe de hacer de
acuerdo con las características del sistema a desarrollar, el tipo de usuarios del sistema
y del enfoque organizacional del sistema, por ejemplo para nuestro chatbot para un
instituto de idiomas, vamos a especificar los requerimientos funcionales a continuación.

- El usuario podrá consultar acerca de la información del instituto de idiomas,


como precios, horarios, modo de inscripción, etc.
- El chatbot deberá mandar opciones de inscripción, donde el caso se registre,
almacenarlo en una base de datos.
- La información del chatbot sobre registros, pagos de usuarios inscritos quedará
almacenada en la base de datos.
- La base de datos del chatbot deberá ser previamente alimentada por el
administrador encargado.
- El administrador podrá crear, modificar y/o eliminar usuarios.

7.1.3.1. Especificación de casos de uso

Caso de uso 1. Realizar consulta sobre un curso de idioma

Fuentes Estudiante, chatbot

Actores Estudiante 1, chatbot

Descripción El estudiante realiza una consulta de un curso de idioma

Flujo principal Paso 1: El estudiante hace click en el ícono del chatbot para
hacer una consulta.
Paso 2: El chatbot saluda al estudiante y le pregunta sobre qué
quiere consultar.
Paso 3: El estudiante solicita información sobre un curso de
idioma.
Paso 4: El chatbot responde informando sobre los horarios, las
vacantes, precio y modo de inscripción.

Condiciones previas El estudiante debe estar dentro de la página web del instituto

Condiciones El chatbot proporcionará información acerca de las cursos que


posteriores deseen llevar los estudiantes

Requerimientos -El estudiante podrá consultar acerca de la información del


trazados instituto de idiomas, como precios, horarios, modo de
inscripción, etc.
-El chatbot deberá informar todo acerca del curso ( precios,
horarios, modo de inscripción, etc.)

Puntos de inclusión Estudiante, chatbot

Caso de uso 2. Gestión de usuarios

Fuentes Administrador

Actores Administrador 1

Descripción El administrador mediante el módulo de gestión de


usuarios puede crear, buscar, modificar y eliminar
usuarios desde la página web.

Flujo principal Paso 1: El administrador deberá loguearse en el sistema.


Paso 2: El administrador podrá crear usuarios.
Paso 3: El administrador podrá buscar usuarios.
Paso 4: Después de encontrar el usuario, podrá modificarlo o
eliminarlo.

Condiciones previas El administrador debe estar logueado como tal


dentro del módulo

Condiciones El administrador tendrá el control para agregar, modificar y


posteriores eliminar usuarios

Requerimientos -El administrador podrá crear, modificar y/o eliminar usuarios.


trazados

Puntos de inclusión Administrador

Caso de uso 3. Consulta sobre matrícula a algún curso de idioma


disponible

Fuentes Estudiante, Chatbot

Actores Estudiante 1, Chatbot

Descripción El estudiante consulta sobre la matrícula del curso de idioma de


interés

Flujo principal Paso 1: El estudiante realiza la consulta sobre la matrícula de


algún curso de idiomas.
Paso 2: El chatbot responde mandando un link donde
redirecciona a la página web con los cursos disponibles.
Paso 3: El estudiante selecciona el link y es redireccionado a la
página web de matrícula de cursos de idioma.
Paso 4: El chatbot finaliza la consulta con un mensaje de si desea
saber algo más, de caso contrario finaliza la conversación.

Condiciones previas El estudiante debe estar dentro de la página web del instituto

Condiciones El chatbot proporcionará información acerca de las dudas de los


posteriores estudiantes

Requerimientos -El chatbot debe brindar la información requerida sobre la


trazados matrícula (precios, horarios, niveles en el idioma, etc.).
- En caso el estudiante desee matricularse, el chatbot deberá
enviar el link de la página de matrícula donde el estudiante podrá
registrarse.
- En caso de registrarse el chatbot almacenará la información en
la base de datos.

Puntos de inclusión Estudiante, Chatbot


Caso de uso 4. Consulta sobre alguna duda de usuario matriculado

Fuentes Usuario registrado, chatbot

Actores Usuario registrado 1, chatbot

Descripción El usuario registrado consultará sobre horarios, profesores,


niveles, etc.

Flujo principal Paso 1: El usuario consultará sobre alguno de los puntos


mencionados.
Paso 2: El chatbot le solicitará su código de estudiante registrado
o matriculado.
Paso 3: El usuario proporcionará su código correctamente.
Paso 4: El chatbot brindará la información disponible del usuario
registrado como cursos matriculados, nombres de los profesores
a cargo y un link donde se redireccionará información más
precisa como sus horarios, inicio de clases, etc.

Condiciones previas El usuario debe estar registrado o matriculado e ingresar a la


página web de la unfv.

Condiciones El chatbot proporcionará información acerca de las dudas de los


posteriores usuarios registrados.

Requerimientos - El chatbot deberá confirmar que el usuario esté


trazados matriculado solicitando su código de estudiante.
- Una vez confirmado, proporcionará la información
disponible hasta la actualidad sobre cursos, horarios,
profesores, etc en el que esté matriculado el usuario
registrado.

Puntos de inclusión Usuario, Chatbot

Caso de uso 5. Queja o reclamo, sobre algún curso o el proceso de


matrícula en cuestión.

Fuentes Usuario Matriculado, Chatbot

Actores Usuario Matriculado 1, Chatbot

Descripción El usuario matriculado consultará sobre algún problema que se


presente sobre su matrícula, horarios, cursos, etc.

Flujo principal Paso 1: El usuario realiza la queja.


Paso 2: El Chatbot solicita su código de estudiante.
Paso 3: El usuario proporciona su código.
Paso 4: El Chatbot mostrará una lista de posibles quejas o
reclamos durante el proceso de matrícula o sobre algo
relacionado.
Paso 5: En caso su reclamo se encuentre en la lista, el chatbot le
responderá pertinentemente o lo desviará a algún contacto con
un administrador.
Paso 6: Si su queja o reclamo no se encuentra en la lista, el
Chatbot le dirá que no cuenta con dicha información y le enviará
un correo al que podrá escribir y presentar su reclamo.

Condiciones previas El usuario debe estar registrado o matriculado e ingresar a la


página web de la unfv.

Condiciones El chatbot proporcionará información acerca de los reclamos de


posteriores los usuarios registrados o desviar sus reclamos hacía algún
correo de un administrador.

Requerimientos - El chatbot deberá confirmar que el usuario esté


trazados matriculado solicitando su código de estudiante.
- Una vez confirmado, proporcionará la lista de reclamos
disponible por el chatbot y los correos de administradores
si no cuenta con la respuesta que el usuario matriculado
requiere.

Puntos de inclusión Usuario, Chatbot

Caso de uso 6. Alimentación de base de datos del chatbot

Fuentes Administrador

Actores Administrador 1

Descripción El administrador es quien realiza la alimentación y modificación


de las conversaciones del chatbot

Flujo Principal Paso 1: El administrador realiza la alimentación de las


conversaciones del chatbot.
Paso 2: El administrador realiza la modificación de las
conversaciones del chatbot.

Condiciones previas El administrador debe estar logueado como tal dentro del
módulo

Condiciones La base de datos del chatbot tendrá suficiente información para


posteriores contestar las consultas de los usuarios

Requerimientos - La base de datos del chatbot deberá ser previamente alimentada


trazados por el administrador encargado.

Puntos de inclusión Administrador

7.1.4 Especificación de requerimientos no funcionales

Los requerimientos no funcionales definen las propiedades que debe tener el


sistema, como son fiabilidad, tiempo de respuesta y capacidad de almacenamiento,
entre otros. También ayudan a definir las restricciones que tendrá el sistema.

Los requisitos no funcionales se redactan en forma cuantitativa, siempre que sea


posible, con la finalidad de que puedan evaluarse de forma objetiva.

- Se deberá asegurar que cualquier tipo de usuario pueda utilizar la aplicación,


indiferentemente de si es un usuario con o sin conocimientos del contenido de la
web. Para ello, se dispondrá de una interfaz gráfica durante la conversación,
disponible con un solo click, y que no presente dudas de utilización.
- El chatbot deberá ser capaz de responder a distintos chats al mismo tiempo, sin
que haya un cruce de mensajes entre un usuario y otro.
- El tiempo de respuesta del chatbot ideal debería no ser superior a 15 segundos
entre sus diversas respuestas programadas.

7.1.5 Diagrama de Ishikawa


8. Diagramas UML
8.1 Diagrama de clases

8.2 Diagrama de componentes


8.3 Diagrama de despliegue
8.4 Diagrama de secuencias

Caso de uso 1: Realizar consulta sobre un curso de idioma


Caso de uso 2: Gestión de usuarios

Caso de uso 3: Consulta sobre matrícula a algún curso de idioma disponible


Caso de uso 4: Consulta sobre alguna duda de usuario matriculado
Caso de uso 5: Queja o reclamo, sobre algún curso o el proceso de matrícula en cuestión.
Caso de uso 6: Alimentación de base de datos del chatbot
8.5 Diagrama de Actividad

Caso de uso 1: Realizar consulta sobre un curso de idioma

Caso de Uso 2: Gestión de usuarios


Caso de Uso 3: Consulta sobre matrícula a algún curso de idioma disponible

Caso de Uso 4: Consulta sobre alguna duda de usuario matriculado


Caso de uso 5: Queja o reclamo, sobre algún curso o el proceso de matrícula en cuestión.

Caso de Uso 6: Alimentación de base de datos del chatbot


8.5 Diagramas de casos de uso

Caso de Uso 1: Realizar consulta sobre un curso de idioma

Caso de Uso 2: Gestión de Usuarios


Caso de Uso 3: Consulta sobre matrícula a algún curso de idioma disponible

Caso de Uso 4: Consulta sobre alguna duda de usuario matriculado


Caso de Uso 5: Queja o reclamo, sobre algún curso o el proceso de matrícula en cuestión.

Caso de Uso 6: Alimentación de la base de datos

También podría gustarte