trabajo de gradorepository.udistrital.edu.co/bitstream/11349/13638/1... · 2019-07-26 ·...

Universidad Distrital Francisco Jose DeCaldas

Facultad de Ingenierıa

PROTOTIPO DE APLICACIONMOVIL PARA EL CONTROL DE

LOS PRESUPUESTOSPERSONALES, MEDIANTE LA

IMPLEMENTACION DE UN BOTCONVERSACIONAL

TRABAJO DE GRADOPARA OBTENER EL TITULO DE:

Especialista en Ingenierıa de Software

PRESENTA:

Ing. Cristian Jose Sierra CardenasIng. Manuel Alejando Yanez Quintero

DIRECTOR DE TESIS:

Ing. Oswaldo Alberto Romero Villalobos M Sc.

REVISOR DE TESIS:

Ing. Lilian Astrid Bejarano Garzon M Sc.

Bogota, D.C., 2018

Indice general

Indice de figuras VII

Indice de tablas IX

I Contextualizacion de la Investigacion 1

1. Descripcion de la investigacion 31.1. Estudio del problema de investigacion . . . . . . . . . . . . . . . . 3

1.1.1. Planteamiento del problema . . . . . . . . . . . . . . . . . 31.1.2. Formulacion del problema . . . . . . . . . . . . . . . . . . 41.1.3. Sistematizacion del problema . . . . . . . . . . . . . . . . 4

1.2. Objetivos de la investigacion . . . . . . . . . . . . . . . . . . . . . 41.2.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . 41.2.2. Objetivos especıficos . . . . . . . . . . . . . . . . . . . . . 5

1.3. Justificacion de la investigacion . . . . . . . . . . . . . . . . . . . 51.4. Hipotesis del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 51.5. Marco referencial . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.5.1. Marco teorico . . . . . . . . . . . . . . . . . . . . . . . . . 61.5.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . 9

1.6. Aspectos metodologicos . . . . . . . . . . . . . . . . . . . . . . . . 101.6.1. Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . 101.6.2. Metodo de investigacion . . . . . . . . . . . . . . . . . . . 101.6.3. Fuentes y tecnicas para la recoleccion de la informacion . . 111.6.4. Tratamiento de la informacion . . . . . . . . . . . . . . . . 11

1.7. Alcances y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . 111.7.1. Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.7.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 11

iii

INDICE GENERAL

II Desarrollo de la Investigacion 13

2. Fases del diseno del prototipo 152.1. Arquitectura Empresarial . . . . . . . . . . . . . . . . . . . . . . 15

2.1.1. Capa de Aplicacion . . . . . . . . . . . . . . . . . . . . . . 162.1.1.1. Punto de Vista de Comportamiento de la Aplicacion 162.1.1.2. Punto de Vista de Estructura de la Aplicacion . . 172.1.1.3. Punto de Vista de Cooperacion de la Aplicacion . 182.1.1.4. Punto de Vista de Uso de la Aplicacion . . . . . 19

2.1.2. Capa de Infraestructura . . . . . . . . . . . . . . . . . . . 202.1.2.1. Punto de Vista de Infraestructura . . . . . . . . . 202.1.2.2. Punto de Vista de Uso Infraestructura . . . . . . 212.1.2.3. Punto de Vista de Organizacion e Implementacion 222.1.2.4. Punto de Vista de Realizacion del Servicio . . . . 232.1.2.5. Punto de Vista de Capas . . . . . . . . . . . . . . 24

2.1.3. Capa motivacional . . . . . . . . . . . . . . . . . . . . . . 252.1.3.1. Punto de Vista de Realizacion de Requerimientos 252.1.3.2. Punto de Vista de Motivacion . . . . . . . . . . . 26

2.2. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.2.1. Caso de uso Nro. 1 - Registro de usuario . . . . . . . . . . 282.2.2. Caso de uso Nro. 2 - Autenticacion de usuario . . . . . . . 292.2.3. Caso de uso Nro. 5 - Conversaciones . . . . . . . . . . . . 302.2.4. Caso de uso Nro. 6 - Mi Cartera . . . . . . . . . . . . . . . 312.2.5. Caso de uso Nro. 7 - Caso de uso Muesca de conversaciones

(Notch) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.2.6. Caso de uso Nro. 8 - Detalles de Movimientos . . . . . . . 332.2.7. Caso de uso Nro. 9 - Proyecciones . . . . . . . . . . . . . . 34

2.3. Modelo de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352.4. Interfaces de usuario . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.4.1. Prototipo de pantalla de Registro de usuario . . . . . . . . 362.4.2. Prototipo de pantalla de Autenticacion de usuario . . . . . 382.4.3. Prototipo de pantalla de Conversaciones . . . . . . . . . . 392.4.4. Prototipo de pantalla de Detalles de movimientos . . . . . 402.4.5. Prototipo de pantalla de Mi Cartera . . . . . . . . . . . . 412.4.6. Prototipo de pantalla de Muesca de conversaciones (Notch) 42

2.5. Diseno encuesta de validacion de experiencia de usuario . . . . . . 43

3. Desarrollo de funcionalidades del prototipo 473.1. Desarrollo de la interfaz de usuario . . . . . . . . . . . . . . . . . 47

3.1.1. Registro de usuarios . . . . . . . . . . . . . . . . . . . . . 483.1.2. Autenticacion de usuario . . . . . . . . . . . . . . . . . . . 49

iv

INDICE GENERAL

3.1.3. Conversaciones . . . . . . . . . . . . . . . . . . . . . . . . 503.1.4. Detalles de movimientos . . . . . . . . . . . . . . . . . . . 513.1.5. Mi cartera . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.1.6. Muesca de conversaciones (Notch) . . . . . . . . . . . . . . 53

3.2. Controles graficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.3. Reconocimiento de voz . . . . . . . . . . . . . . . . . . . . . . . . 533.4. Procesamiento de datos en plataforma RESTful . . . . . . . . . . 54

3.4.1. Acceso a historicos . . . . . . . . . . . . . . . . . . . . . . 543.4.2. Generacion de proyecciones basados en habitos de consumo 543.4.3. Integracion API para el flujo conversacional . . . . . . . . 553.4.4. Persistencia de datos . . . . . . . . . . . . . . . . . . . . . 57

III Cierre de la Investigacion 59

4. Presentacion de encuesta de opinion 614.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.2. Ficha tecnica de la encuesta . . . . . . . . . . . . . . . . . . . . . 61

4.2.1. Marco muestral . . . . . . . . . . . . . . . . . . . . . . . . 614.2.2. Tecnica de recoleccion de datos . . . . . . . . . . . . . . . 614.2.3. Tamano de la muestra . . . . . . . . . . . . . . . . . . . . 61

4.3. Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5. Conclusiones 67

6. Prospectiva del trabajo de grado 716.1. Lıneas de investigacion futuras . . . . . . . . . . . . . . . . . . . . 716.2. Trabajos de Investigacion futuros . . . . . . . . . . . . . . . . . . 71

Bibliografıa 73

A. Anexo I: Ambiente necesario para Laravel 5.2 77A.1. Requisitos del servidor . . . . . . . . . . . . . . . . . . . . . . . . 77A.2. Configuracion y permisos . . . . . . . . . . . . . . . . . . . . . . . 77

A.2.1. Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . 77A.2.1.1. Permisos de directorio . . . . . . . . . . . . . . . 78A.2.1.2. Clave de aplicacion . . . . . . . . . . . . . . . . . 78

B. Anexo II: Entrenamiento inicial de Watson Assistant 79B.1. Requisitos para la configuracion . . . . . . . . . . . . . . . . . . . 79B.2. Creacion de una Intencion . . . . . . . . . . . . . . . . . . . . . . 79B.3. Creacion de una entidad . . . . . . . . . . . . . . . . . . . . . . . 81

v

INDICE GENERAL

B.4. Configuracion de flujo conversacional . . . . . . . . . . . . . . . . 83B.5. Prueba de flujo conversacional . . . . . . . . . . . . . . . . . . . . 84

vi

Indice de figuras

1.1. Arquitectura de 2 capas . . . . . . . . . . . . . . . . . . . . . . . 9

2.1. Punto de Vista de Comportamiento de la Aplicacion . . . . . . . 162.2. Punto de Vista de Estructura de la Aplicacion . . . . . . . . . . 172.3. Punto de Vista de Cooperacion de la Aplicacion . . . . . . . . . 182.4. Punto de Vista de Uso de la Aplicacion . . . . . . . . . . . . . . 192.5. Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . 202.6. Punto de Vista de Uso de Infraestructura . . . . . . . . . . . . . 212.7. Punto de Vista de Organizacion e Implementacion . . . . . . . . 222.8. Punto de Vista de Realizacion del Servicio . . . . . . . . . . . . . 232.9. Punto de Vista de Capas . . . . . . . . . . . . . . . . . . . . . . 242.10. Punto de Vista de Realizacion de Requerimientos . . . . . . . . . 252.11. Punto de Vista de Motivacion . . . . . . . . . . . . . . . . . . . . 262.12. Modelo relacional de tablas . . . . . . . . . . . . . . . . . . . . . 352.13. Diseno de baja fidelidad para Registro de usuario . . . . . . . . . 372.14. Diseno de baja fidelidad para Autenticacion de usuario . . . . . . 382.15. Diseno de baja fidelidad para Conversaciones . . . . . . . . . . . . 392.16. Diseno de baja fidelidad para Detalles de movimientos . . . . . . 402.17. Diseno de baja fidelidad para Mi Cartera . . . . . . . . . . . . . 412.18. Diseno de baja fidelidad para Muesca de conversaciones (Notch) . 42

3.1. Pantalla de Registro de Usuario . . . . . . . . . . . . . . . . . . . 483.2. Pantalla de Autenticacion de Usuario . . . . . . . . . . . . . . . 493.3. Pantalla de Conversaciones . . . . . . . . . . . . . . . . . . . . . 503.4. Detalles de movimientos . . . . . . . . . . . . . . . . . . . . . . . 513.5. Pantalla Mi Cartera . . . . . . . . . . . . . . . . . . . . . . . . . 523.6. Pantalla de muesca de conversaciones . . . . . . . . . . . . . . . 533.7. Flujo de Watson Assistant . . . . . . . . . . . . . . . . . . . . . . 56

4.1. Encuesta Pregunta No. 1 . . . . . . . . . . . . . . . . . . . . . . 624.2. Encuesta Pregunta No. 2 . . . . . . . . . . . . . . . . . . . . . . 62

vii

INDICE DE FIGURAS

4.3. Encuesta Pregunta No. 3 . . . . . . . . . . . . . . . . . . . . . . 634.4. Encuesta Pregunta No. 4 . . . . . . . . . . . . . . . . . . . . . . 634.5. Encuesta Pregunta No. 5 . . . . . . . . . . . . . . . . . . . . . . 644.6. Encuesta Pregunta No. 6 . . . . . . . . . . . . . . . . . . . . . . 644.7. Encuesta Pregunta No. 7 . . . . . . . . . . . . . . . . . . . . . . 654.8. Encuesta Pregunta No. 8 . . . . . . . . . . . . . . . . . . . . . . 65

B.1. Panel de control de Watson Assistant . . . . . . . . . . . . . . . . 80B.2. Pantalla de intenciones . . . . . . . . . . . . . . . . . . . . . . . . 80B.3. Pantalla de agregacion y edicion de intenciones . . . . . . . . . . . 81B.4. Pantalla de entidades . . . . . . . . . . . . . . . . . . . . . . . . . 82B.5. Pantalla de agregacion y edicion de entidades . . . . . . . . . . . 82B.6. Pantalla de configuracion de Flujo conversacional . . . . . . . . . 83B.7. Pantalla de prueba de flujo de conversacion . . . . . . . . . . . . . 84

viii

Indice de tablas

2.1. Caso de uso Registro de usuario . . . . . . . . . . . . . . . . . . 282.2. Caso de uso Autenticacion de usuario . . . . . . . . . . . . . . . 292.3. Caso de uso Conversaciones . . . . . . . . . . . . . . . . . . . . . 302.4. Caso de uso Mi Cartera . . . . . . . . . . . . . . . . . . . . . . . 312.5. Caso de uso Muesca de conversaciones (Notch) . . . . . . . . . . 322.6. Caso de uso Detalles de Movimientos . . . . . . . . . . . . . . . . 332.7. Caso de uso Proyecciones . . . . . . . . . . . . . . . . . . . . . . 34

ix

Parte I

Contextualizacion de la

Investigacion

1

Capıtulo 1

Descripcion de la investigacion

1.1. Estudio del problema de investigacion

1.1.1. Planteamiento del problema

Se identifico segun el estudio titulado ‘Capacidades Financieras en Colombia’,realizado por el Banco de la Republica, el bajo porcentaje de personas que llevanun control riguroso de sus finanzas. Otros autores como Monica Nunez, asesoraen administracion financiera, expone que la falta de control en las finanzas per-sonales es debido a multiples factores, entre los cuales se pueden identificar lacultura, el desconocimiento del tema, y la carencia de tiempo para la planeacion(Nunez, 2017). Por otra parte, evaluando la oferta de herramientas para apoyar laadministracion de las finanzas personales se evidencio un gran numero deaplica-ciones moviles, sin embargo, ninguna de ellas busca minimizar la falta de tiemporequerido para la planeacion, pues implementan una interfaz de usuario donde lainformacion se ingresa mediante la digitacion de texto o con controles graficos,tan dispendioso como llevar una libreta o libro contable.

Si no se toman medidas respecto a la falta de control sobre los gastos diariosy presupuestos puede llevar a las personas a recurrir al endeudamiento informalel cual es una estrategia habitual para aliviar la insuficiencia de dinero, estefenomeno comprende una serie de factores que resultan en el detrimento de lasituacion economica ya que segun este mismo estudio mas 50 % de los encuestadospresta dinero para pagar otras deudas, hecho que se convierte en un ciclo contantas iteraciones como el endeudamiento se mantenga vigente.

En el contexto de interaccion hombre-maquina, las grandes companıas como

3

1. DESCRIPCION DE LA INVESTIGACION

IBM, Facebook, Google y Amazon le apuntan al desarrollo de tecnologıas cogni-tivas que permiten la comunicacion organica y se proyectan como el futuro de lossistemas, en este orden de ideas, la implementacion de chatbots como herramientade captura y gestion de datos son evidencias de las posibilidades en las interfa-ces de lenguaje natural. Una interfaz de usuario con lenguaje natural por mediode reconocimiento de voz, en aplicativos moviles podra acelerar la interaccionhombre-maquina (Everett,2017) y lograr un incremento del uso de herramientaspara el control de las finanzas personales. Las respuestas emitidas por la maqui-na deben ser interpretadas de forma organica para garantizar la efectividad de lainteraccion.

1.1.2. Formulacion del problema

¿Que tipo de interaccion hombre-maquina facilita un ingreso y acceso rapidoa la informacion para lograr un incremento del uso de herramientas de control delos presupuestos personales?

1.1.3. Sistematizacion del problema

¿Cuales son los medios de captura de informacion para interactuar con elusuario?

¿Como debe ser el procesamiento de la informacion que se recibe y se entregaal usuario?

¿Como debe ser la estructura de preservacion de la informacion para la repre-sentacion apropiada de las interacciones establecidas entre hombre-maquina?

1.2. Objetivos de la investigacion

1.2.1. Objetivo general

Desarrollar un prototipo de una aplicacion movil que implemente un chat-bot conversacional, facilitando el acceso a la informacion historica de los habitosde consumo, como herramienta de control de las finanzas personales utilizandotecnologıas de analisis cognitivo de datos y reconocimiento de voz.

4

1.3 Justificacion de la investigacion

1.2.2. Objetivos especıficos

Disenar una interfaz de usuario que utilice el reconocimiento de voz usandoel API Google Speech y controles graficos desarrollados con React Native deFacebook para la captura de la informacion e interaccion con el usuario.

Desarrollar plataforma REST haciendo uso de Laravel 5.2 para la gestionde servicios que permitan el acceso a la informacion historica de los habitos deconsumo.

Implementar una infraestructura cliente-servidor para el almacenamiento dedatos, presentacion de historicos y generacion de proyecciones basados en habitosde consumo, haciendo uso de bases de datos.

1.3. Justificacion de la investigacion

En el estudio titulado ‘Capacidades Financieras en Colombia’, realizado por elBanco de la Republica, se identifico el bajo porcentaje de personas que llevan uncontrol riguroso de sus finanzas, y se recomienda generar y promover tecnologıasque incrementen el acceso oportuno a informacion financiera personal con el finde mejorar las conductas de planificacion (The World Bank Group, 2013).

Identificada la necesidad de promocion de herramientas de control para me-jorar las conductas de planificacion, y lo engorroso que resulta el proceso deregistrar informacion en las herramientas que existen actualmente, este proyectose oriento al desarrollo de un prototipo de una aplicacion movil, para controlde presupuestos personales que acelera la interaccion hombre-maquina, usandouna interfaz de usuario con lenguaje natural mediante la implementacion de unchatbot conversacional.

1.4. Hipotesis del trabajo

Una aplicacion movil que permita el reconocimiento de voz, e intepretacionde sus comandos en lenguaje natural, agiliza el proceso de la gestion de la infor-macion en la interaccion hombre-maquina, y constituye un factor determinantepara incrementar el uso de herramientas enfocadas al control de presupuestospersonales.

5


1.5. Marco referencial

1.5.1. Marco teorico

Para el desarrollo del prototipo propuesto en esta investigacion es necesa-rio tener en cuenta los ejes tematicos implicados los cuales son; administracionde presupuestos personales, Chatbots conversacionales, reconocimiento de voz,desarrollo de aplicaciones moviles e infraestructura cliente-servidor.

Administracion de presupuestos personales

La administracion de las finanzas personales segun el estudio ’Capacidadesfinancieras en Colombia’ se sustenta en:

1. Manejo de dinero: Planear ingresos contra gastos (haciendo presupuestos),monitorear gastos, priorizar gastos esenciales.

2. Prever las necesidades futuras: Planear para el futuro, prever eventos ines-perados o gastos de vejez, ahorrar.

3. Seleccion y uso de productos financieros: no sobre endeudarse, revisando lascaracterısticas de productos antes de obtenerlos.

4. Mantenerse informado: Buscar informacion antes de tomar decisiones, yMotivaciones: auto -disciplina/no ser impulsivo, una vision de largo plazo,tener espıritu emprendedor

Sin embargo, estos aspectos mencionados no son en su mayorıa aplicados porlas personas, quienes no monitorean de forma apropiada sus gastos y acuden alendeudamiento informal como una estrategia habitual para aliviar la insuficienciade dinero. Segun el analisis del Banco Mundial de la encuesta sobre CapacidadesFinancieras de Colombia, del reporte de 2012, el 43 % de los encuestados no tienenidea acerca de planes financieros o tienen un horizonte temporal de planificacionde una semana o menos. Como paso a seguir en el diagnostico de las Capacida-des Financieras de Colombia, se recomienda generar y promover tecnologıas queincrementen el acceso oportuno a informacion financiera personal con el fin demejorar las conductas de planificacion.

Las herramientas de control de finanzas personales existentes y particularmen-te las aplicaciones moviles, se caracterizan por contar con un modelo tradicional

6

1.5 Marco referencial

de interaccion con el usuario a traves de captura de informacion por medio detextos que se deben ingresar digitando teclas en la pantalla. Como aplicacionesexistentes, encontramos varios ejemplos desarrollos, los cuales se presentan a con-tinuacion.

Fintonic, aplicacion financiera movil lıder en Europa, con mas de 300.000relaciones bancarias conectadas a la plataforma (Gallego,2016) dicha aplicacionganadora de los Premios Start Ups Innovacion Movil 2015, permite introducirla informacion de cuentas bancarias, pudiendo elegir entre varias entidades, ydecirle a la aplicacion los movimientos que se quieren registrar. La aplicacionse encargara entonces de organizar gastos, generar avisos de comisiones y, endefinitiva, e informar hasta que punto se puede permitir un gasto o no.

Mint, aplicativo con 20 millones de usuarios, tiene recordatorios de pagos,sin embargo, presenta el inconveniente para los usuarios de habla hispana de noestar disponible en espanol (Floyd, 2011)

Monefy, aplicacion muy intuitiva y permite registrar los gastos de formarapida anadiendoles categorıas (Yubal,2017). Dicha data se muestra en graficos, laapp tambien permite programar informes periodicos, hacer presupuestos e inclusocopias de seguridad.

Desarrollo de aplicaciones moviles

Segun un estudio realizado por el Ministerio de Tecnologıas de la Informaciony las Comunicaciones, en el paıs hay al menos 92 empresas formales dedicadasal desarrollo de aplicaciones moviles y que facturan US$425 millones en ventas.Samsung reporto que los colombianos descargan en promedio 17 aplicaciones ensus telefonos y que los juegos, las redes sociales y el entretenimiento son lasactividades mas frecuentes. Lo cierto es que cada vez son mas los desarrolloslocales que se integran a plataformas como iOS, Android, Windows Phone yBlackberry.

Bots Conversacionales

En la actualidad existen tecnologıas que permiten un intercambio mas organi-co de informacion usando el reconocimiento de voz y servicios que sintetizan lasentradas recibidas para una posterios gestion de esta informacion. Es ası como laimplementacion de bots conversacionales, posibilitan desarrollar aplicativos queden respuesta a las necesidades del usuario del sistema de informacion. Segun unreporte de la consultora Credence Research: El mercado de los bots conversaciona-

7


les rondo en 2015 un valor total de 88 millones de dolares y algunas estimacionesapuntan que el sector seguira creciendo hasta 2023, esto la configura como unatecnologıa en crecimiento y con alto grado de aceptacion en los consumidores.La tecnologıa de los bots conversacionales se configura bajo un esquema de ser-vicios, que deben ser consumidos por una aplicacion orquestadora que realiza elrespectivo tratamiento de la informacion segun un fin especıfico, es aquı dondese incorpora la aplicacion integradora que se encarga de consumir los serviciosdel API, y almacenar la informacion en base de datos, esta capa corresponde ala infraestructura cliente-servidor.

Reconocimiento de voz

El reconocimiento de voz (“speech recognition” o “speech-to-text”) se refiereal analisis espectral de la voz por una computadora con la intencion de obteneruna respuesta que por lo general, se da en texto plano de lo que se ha escuchado.Algunas aplicaciones conocidas de STT son las interfaces de voz utilizadas entelefonos inteligentes y otros sistemas, mediante los cuales se utilizan comandos(palabras prefijo) seguidos de alguna otra indicacion especıfica. Otras aplicacionesincluyen transcribir charlas o conferencias a un medio escrito o documento (Furui,2004).

Infraestructura cliente-servidor

La arquitectura cliente-servidor es un modelo para el desarrollo de sistemasde informacion (Berson, 1992), en el que las transacciones se dividen en procesosindependientes que cooperan entre sı para intercambiar informacion, servicioso recursos. Se denomina cliente al proceso que inicia el dialogo o solicita losrecursos; y servidor, al proceso que responde a las solicitudes (Quezada,2003) .Esta infraestructura se compone de tres capas que son:

Presentacion: software que permiten presentar en forma adecuada los re-sultados de una aplicacion (Cubillos, 2018), esta capa puede ser tambien unaaplicacion movil, webapp o aplicacion de escritorio.

Aplicacion: software que entrega un resultado util para el usuario (Cubillos,2018). Las respuestas entregadas se basan en una logica del negocio preestableci-da.

Administracion de datos: manejo de los datos (en una BD) que sirven alas aplicaciones de la logica del negocio (Cubillos, 2018).

8

1.5 Marco referencial

A continuacion se presenta de manera grafica el funcionamiento la arquitecturade 2 capas:

Figura 1.1: Arquitectura de 2 capas

Fuente : Claudio Cubillos (2018). Arquitectura Cliente-Servidor.[Online; recuperado en Febrero 17, 2018]http://ocw.pucv.cl/cursos-1/arquitectura-de-sistemas-de-software/materiales-de-clases/web-cliente-servidor

1.5.2. Marco Conceptual

Es importante la comprension de los ejes centrales de la investigacion quepermitiran el desarrollo del prototipo, a continuacion, se presenta la descripcionde los bots conversacionales, e infraestructura cliente-servidor, fundamentos con-ceptuales del desarrollo del trabajo propuesto.

Bots Conversacionales

Los chatbots son agentes de software que emulan conversaciones con un usua-rio utilizando reglas basadas en busqueda por patrones. Este software busca coin-cidencias lexicas entre la consulta del usuario y un modulo se encarga de buscaruna respuesta en la base de conocimientos del chatbot. La conversacion estable-cida con los bots se da a lugar usando texto o reconocimiento de voz.

Para interactuar con el usuario y emitir respuestas, los bots conversacionaleshacen de la sıntesis de voz, siendo esta, el proceso de generacion de una senal devoz teniendo como entrada datos en formato de texto, texto anotado u objetosbinarios. El termino “text-to-speech” o TTS generaliza este concepto abstrayendoel metodo utilizado para transformar el texto en voz(1).

9


Infraestructura cliente-Servidor

La infraestructura cliente-servidor se utiliza generalmente en la implementa-cion de servicios web. Los servicios web han sido un estandar en la industria dela tecnologıa para la comunicacion de mensajes e integracion entre sistemas he-terogeneos. Las API RESTful se han convertido en la tendencia en el desarrollode servicios web luego de SOAP (Chen Xianjun, 2017).

1.6. Aspectos metodologicos

1.6.1. Tipo de estudio

El desarrollo de un prototipo de aplicacion movil para el control de las finanzaspersonales mediante implementacion de un bot conversacional, responde a unestudio de tipo explicativo, dado que, a traves de su implementacion y validacioncon la experiencia de los usuarios, buscara confirmar como la interaccion hombre-maquina con lenguaje natural incrementara el uso de herramientas de control depresupuestos.

1.6.2. Metodo de investigacion

El prototipo producto de la investigacion sera logrado a traves del metodo deanalisis-sıntesis puesto que, mediante el analisis de los requerimientos empleandolos casos de uso implicados se dara respuesta a las funcionalidades de monitoreocontinuo, acceso a historicos y generacion de proyecciones basados en habitos deconsumo.

Las partes involucradas en el proceso de sıntesis seran; la interfaz de usuarioque utilice el reconocimiento y sıntesis voz y controles graficos para captura dela informacion e interaccion con el usuario, la plataforma API haciendo uso deLaravel para gestion de servicios, y la infraestructura cliente-servidor para elalmacenamiento de datos.

10

1.7 Alcances y limitaciones

1.6.3. Fuentes y tecnicas para la recoleccion de la infor-

macion

La informacion para sustentar el diseno del prototipo seguira las directrices dela bibliografıa disponible en las bases de datos de la IEEE, artıculos especializadosen relacion a implementaciones de inteligencia cognitiva, finanzas personales. Seusaran encuestas, para validar la implementacion del prototipo y el grado deaceptacion de los usuarios,

1.6.4. Tratamiento de la informacion

La informacion para sustentar el diseno del prototipo seguira las directrices dela bibliografıa disponible en las bases de datos de la IEEE, artıculos especializadosen implementaciones de inteligencia cognitiva, finanzas personales y para validarla implementacion del prototipo y el grado de aceptacion de los usuarios, se usaranencuestas.

1.7. Alcances y limitaciones

1.7.1. Alcances

El prototipo de aplicacion movil para el control de las finanzas personalesmediante implementacion de un bot conversacional monitoreo continuo, acceso ahistoricos y generacion de proyecciones basados en habitos de consumo, medianteinterfaz de usuario que utilice el reconocimiento y sıntesis voz y controles graficospara captura de la informacion e interaccion con el usuario, la plataforma APIhaciendo uso de Laravel para gestion de servicios, y la infraestructura cliente-servidor para el almacenamiento de datos.

1.7.2. Limitaciones

A continuacion se relacionan las limitaciones dentro de la aplicacion.

La aplicacion no se enlazara con informacion financiera de entidades banca-rias que reposa en los servidores propios de las cuentas con las que cuenteel usuario.

11


El idioma de conversacion sera unicamente espanol.

La aplicacion no va a exportar los reportes generados.

No se generaran notificaciones para sugerir compras.

No se realizaran conversion entre divisas, manejando unicamente pesos co-lombianos.

12

Parte II

Desarrollo de la Investigacion

13

Capıtulo 2

Fases del diseno del prototipo

En concordancia con Pressman, Ingenierıa en general es el analisis, diseno,construccion, verificacion y gestion de entidades tecnicas (Pressman, 2010).

Una vez identificado el problema para el cual el prototipo da respuesta, seconsidero necesario el diseno mediante las fases que se presentan a continuacion.Como primera etapa, se realizo el modelamiento mediante Arquitectura empre-sarial, luego la definicion de casos de uso, el modelo de datos, y elementos deinterfaz de usuario, y finalmente el diseno de la encuesta de validacion.

2.1. Arquitectura Empresarial

Se implemento la metodologıa de arquitectura empresarial que permitio lo-grar concebir el prototipo como la alineacion de procesos, datos, aplicaciones einfraestructura tecnologica. Se hizo uso del lenguaje de modelado Archimate enlas capas de Aplicacion, Infraestructura, y Motivacion.

15

2. FASES DEL DISENO DEL PROTOTIPO

2.1.1. Capa de Aplicacion

2.1.1.1. Punto de Vista de Comportamiento de la Aplicacion

Mediante el comportamiento interno de la aplicacion que se esta modelando,se logra identificar la interaccion del sistema principal con los servicios para elfuncionamiento de los componentes disenados en el prototipo.

Figura 2.1: Punto de Vista de Comportamiento de la Aplicacion

Fuente : Elaboracion propia.

Se tiene entonces el componente de aplicacion Kalu App movil que consumeel API desarrollado como se muestra, dicho API es Kalu Administrador.

16

2.1 Arquitectura Empresarial

2.1.1.2. Punto de Vista de Estructura de la Aplicacion

En la estructura de la aplicacion se identificaron los componentes, lograndoel entendimiento de la estructura de la aplicacion y la asociacion con el modelodatos, como se describe:

Figura 2.2: Punto de Vista de Estructura de la Aplicacion


Del diagrama presentado se identifican los componentes “Conversaciones” y“Transacciones” en la aplicacion movil, asociados con las entidades Conversacio-nes y Transaccion en el modelo de datos.

17


2.1.1.3. Punto de Vista de Cooperacion de la Aplicacion

Definiendo las relaciones entre los principales componentes de la aplicacion,permitio describir los flujos de informacion que se tienen, dichos componentes ycolaboraciones se presentan ası:

Figura 2.3: Punto de Vista de Cooperacion de la Aplicacion


Se identificaron componentes con los cuales la aplicacion tiene cooperacionGoogle Speech y Watson Api para las funcionalidades de reconocimiento de voze implementacion del bot conversacional. Particularmente Watson Api gestionalos eventos en la aplicacion movil. Dichos eventos se amplıan en el punto de Usode la Aplicacion.

18


2.1.1.4. Punto de Vista de Uso de la Aplicacion

Se determino el flujo logico de uso de la aplicacion, identificando en gran escalalas acciones que los componentes a interior de la aplicacion realizan teniendo encuenta las entradas y salidas de informacion, ası:

Figura 2.4: Punto de Vista de Uso de la Aplicacion


El administrador Kalu, componente que se implemento mediante API de servi-cios RESTful gestiona la informacion que consume la aplicacion y que se visualizaen los componentes Conversaciones, Mis Proyecciones y Mi Cartera.

19


2.1.2. Capa de Infraestructura

2.1.2.1. Punto de Vista de Infraestructura

Se presenta la propuesta de infraestructura para la implementacion del pro-totipo mediante el diagrama a continuacion.

Figura 2.5: Punto de Vista de Infraestructura


20


2.1.2.2. Punto de Vista de Uso Infraestructura

Se presenta la propuesta de infraestructura para la implementacion del pro-totipo mediante el diagrama a continuacion.

Figura 2.6: Punto de Vista de Uso de Infraestructura


21


2.1.2.3. Punto de Vista de Organizacion e Implementacion

Con el punto de vista de organizacion e implementacion se diagraman loscomponentes de las aplicaciones involucradas, este acoplamiento comprende lasrutas logicas de la aplicacion y los componentes.

Figura 2.7: Punto de Vista de Organizacion e Implementacion


22


2.1.2.4. Punto de Vista de Realizacion del Servicio

Esta representacion permite ver como servicios expuestos por la aplicacion,resaltando el analisis de audio en el bot para la gestion de conversaciones ymovimientos.

Figura 2.8: Punto de Vista de Realizacion del Servicio


23


2.1.2.5. Punto de Vista de Capas

A continuacion, se presentan las capas para la implementacion del prototipo.

Figura 2.9: Punto de Vista de Capas


24


2.1.3. Capa motivacional

2.1.3.1. Punto de Vista de Realizacion de Requerimientos

El punto de vista de realizacion de requerimientos involucra las restriccionesdel sistema, con el fin del cumplimiento de los requerimientos.

Figura 2.10: Punto de Vista de Realizacion de Requerimientos


25


2.1.3.2. Punto de Vista de Motivacion

En la motivacion se incluyen los objetivos genera y especıficos postulados parala realizacion del prototipo, para mostrar la coherencia de la implementacion conlo que la motiva.

Figura 2.11: Punto de Vista de Motivacion


26

2.2 Casos de uso

2.2. Casos de uso

Dada la importancia de los diagramas de casos de uso para documentar elcomportamiento de un sistema desde el punto de vista del usuario (Jimenez,2018) al momento de determinar los requisitos funcionales del sistema y como larepresentacion de estas funciones que un sistema puede ejecutar. En este sentido,para el diseno de las funcionalidades de la aplicacion se especifican las secuenciasde interacciones entre el usuario y el sistema, siendo los casos de uso desarrolladosası:

Caso de uso Nro. 1 - Registro de usuario

Caso de uso Nro. 2 - Autenticacion de usuario

Caso de uso Nro. 5 - Conversaciones

Caso de uso Nro. 6 - Mi Cartera

Caso de uso Nro. 7 - Caso de uso Muesca de conversaciones (Notch)

Caso de uso Nro. 8 - Historico de Movimientos

Caso de uso Nro. 9 - Proyecciones

27


2.2.1. Caso de uso Nro. 1 - Registro de usuario

Tabla 2.1: Caso de uso Registro de usuario

RF-0001 Registro de usuario

Version 0001 22/11/2017

Autores Kalu Corp.

Objetivos asociados Obj-0001 Gestionar usuarios nuevos

Descripcion

El sistema debera comportarse tal como se describe

en el siguiente caso de uso cuando alguien solicite su

registro como usuario de la aplicacion.

Precondicion N/A

Secuencia Normal

Paso Accion

1

El usuario presiona el

boton de registro en la pantalla principal, luego se muestra una pagina con el

formulario de registro o la opcion de registrarse con Facebook y Google.

2Si el usuario elige el, registro mediante el formulario, debe diligenciar

los siguientes datos: correo, contrasena y confirmacion de contrasena.

3Si el usuario elige el registro mediante Facebook, debe autorizar

a la aplicacion el acceso a los datos.

Postcondicion El usuario es un usuario registrado en la base de datos de la aplicacion.

Excepciones

Paso Accion

2

Se debe verificar que el correo no se encuentre registrado en la base de datos.

Se debe verificar que el correo tenga un formato valido (ej. [email protected]).

La contrasena debe contener al menos 7 caracteres.

La contrasena debe contener al menos 1 letra mayuscula, 1 letra minuscula y 1 numero.

La contrasena debe coincidir con la confirmacion de la contrasena.

Tanto correo electronico como contrasena y confirmacion de contrasena son campos requeridos.

3

Si cualquiera de los API de Facebook falla en el proceso de presentacion de

permisos al usuario debe retornar a la pantalla de registro y mostrar un mensaje

de error en el sistema.

Si el usuario no permite el acceso a los datos a la aplicacion mediante

Facebook se debe mostrar la pantalla de registro.

Rendimiento

Paso Cota de tiempo

1 2 segundos

2 1 segundos

3 3 segundos

Frecuencia esperada 20 veces / dıa

Importancia vital

Urgencia inmediatamente


28

2.2 Casos de uso

2.2.2. Caso de uso Nro. 2 - Autenticacion de usuario

Tabla 2.2: Caso de uso Autenticacion de usuario

RF-0002 Autenticacion de usuario

Version 0001 22/11/2017

Autores Kalu Corp.

Objetivos asociados Obj-0002 Gestionar usuarios registrados

DescripcionEl sistema debera comportarse tal como se describe en el siguiente caso de uso cuando alguien

solicite su ingreso como usuario de la aplicacion.

Precondicion RF-0001

Secuencia Normal

Paso Accion

1Sı el usuario tiene una sesion activa en Kalu, la aplicacion debe direccionar a la vista de

“conversaciones” RF-0005, de lo contrario se debe mostrar la vista de inicio de sesion RF-0002.

2

Segun la forma de inicio de sesion que el usuario seleccione, Facebook o usando el formulario de

Login, en este ultimo caso se deben diligenciar los campos correo electronico y contrasena,

si el proceso es correcto y es la primera vez que el usuario ingresa se ejecuta el RF-0003 sino

el RF-0005.

3

Si el usuario elige la forma de inicio de sesion usando Facebook o Google se toma la informacion

correspondiente de la sesion activa, si el proceso es correcto y es la primera vez que el usuario

ingresa se ejecuta el RF-0003 sino el RF-0005.

PostcondicionEl usuario accede a la aplicacion, en caso de que sea la primera vez se procede al RF-0003 en caso

contrario al RF-0005.

Excepciones

Paso Accion

2

Se debe verificar que el correo tenga un formato valido (ej. [email protected]).

La contrasena debe contener al menos 7 caracteres.

Tanto correo como contrasena deben coincidir con un usuario registrado.

3El usuario debe coincidir con los datos almacenados en la aplicacion.

El usuario debe tener una sesion activa, en caso contrario se redirige al inicio de sesion al login.

Rendimiento

Paso Cota de tiempo

1 2 segundos

2 3 segundos

3 3 segundos


Importancia vital


ComentariosLa frecuencia de inicio de sesion puede presentar picos durante la etapa de aplicacion de encuestas,

probablemente 30 veces/dıa.


29


2.2.3. Caso de uso Nro. 5 - Conversaciones

Tabla 2.3: Caso de uso Conversaciones

RF-0005 Conversaciones

Version 0001 22/11/2017

Autores Kalu Corp.

Objetivos asociados Obj-0003 Interactuar con el usuario

DescripcionEl sistema debera comportarse tal como se describe en el siguiente caso de uso cuando el usuario

inicie sesion en la aplicacion.


Secuencia Normal Paso Accion

1El sistema presenta en pantalla completa al asistente llamado “Kalu” que sera capaz de interpretar

los comandos que el usuario ingrese mediante voz o texto.

2

El sistema mediante el asistente “Kalu”, luego de interpretar los comandos, debera mostrar al

usuario ventanas con la informacion que el usuario requiera si es el caso. Las ventanas a las

que el usuario tendra acceso mediante comando son:

* Mi cartera (RF-0006)

* Ayuda (RF-0004)

* Historicos de movimientos (RF-0008) Proyecciones (RF-0009)

PostcondicionEl usuario es capaz de obtener la informacion concerniente al estado de su cartera, historico de

movimientos.

Excepciones

Paso Accion

1Si el sistema no es capaz de interpretar los comando se debe informar mediante un mensajes

al usuario y solicitar una nueva instruccion.

2

Si el comando interpretado implica dirigirse a la pantalla “Historico de movimientos” y aun

no se cuenta con movimientos, se debe informar mediante mensajes al usuario y

solicitar una nueva instruccion.

Rendimiento Paso Cota de tiempo

1 2 segundos

2 3 segundos


Importancia vital


ComentariosLa frecuencia de inicio de sesion puede presentar picos durante la etapa de aplicacion de encuestas,

probablemente 30 veces/dıa.


30

2.2 Casos de uso

2.2.4. Caso de uso Nro. 6 - Mi Cartera

Tabla 2.4: Caso de uso Mi Cartera

RF-0006 Mi Cartera

Version 0001 22/11/2017

Autores Kalu Corp.



solicite la vista.



1

El sistema presenta en pantalla completa un resumen de ingresos y egresos registrados, estos

discriminados por las siguientes categorıas: constituyendo como ingresos; depositos, salario y

ahorros y como egresos; facturas, ropa, comunicaciones, entretenimiento, comida, salud, hogar

y transporte. Estos pueden ser filtrados por mes y ano.

La informacion sera presentada en una grafica de torta, asociando un ıcono y color a cada categorıa.

2

Cuando el usuario solicite al asistente Kalu detalle de la informacion de una categorıa, se debe

mostrar una pantalla con el gasto total correspondiente a dicha categorıa y un listado de los

elementos agregado a esta con los costos asociados.

Postcondicion El usuario puede visualizar los ingresos y egresos registrados por categorıa.

Excepciones

Paso Accion

1 Si no hay informacion registrada, esta pantalla se deben presentar con los valores en cero (0).

2 Si no hay informacion registrada, esta pantalla se deben presentar con los valores en cero (0).


1 2 segundos

2 2 segundos


Importancia vital



31


2.2.5. Caso de uso Nro. 7 - Caso de uso Muesca de con-

versaciones (Notch)

Tabla 2.5: Caso de uso Muesca de conversaciones (Notch)

RF-0007 Muesca de conversaciones (Notch)

Version 0001 22/11/2017

Autores Kalu Corp.


DescripcionEl sistema debera comportarse tal como se describe en el siguiente caso de uso cuando el usuario solicite

cualquier vista, exceptuando la pantalla de conversaciones (RF-0005).



1

El notch es capaz de interpretar los comandos de voz y ejecutar las acciones dentro o hacia las pantalla,

mi cartera, historico de movimientos, conversaciones y proyecciones garantizando la navegacion entre

pantallas y la actualizacion de la informacion.

PostcondicionEl usuario puede interactuar con el sistema mediante reconocimiento de voz en cualquier pantalla en las puede

mostrarse el notch

Excepciones Paso Accion

1Si el asistente no es capaz de interpretar los comando se debe informar mediante mensajes al usuario

y solicitar una nueva instruccion.


1 2 segundos


Importancia vital



32

2.2 Casos de uso

2.2.6. Caso de uso Nro. 8 - Detalles de Movimientos

Tabla 2.6: Caso de uso Detalles de Movimientos

RF-0008 Detalles de Movimientos

Version 0001 22/11/2017

Autores Kalu Corp.

Objetivos asociados Obj-0003 Reportes


solicite la pantalla de detalles de movimientos.


Secuencia Normal

Paso Accion

1

En esta pantalla se presenta informacion detallada de cada uno de los ıtems o activos

relacionados a un movimiento realizado en la aplicacion,

dentro de los datos que se muestran estan: valores economicos relacionados,

categorıa a la que pertenece un ıtem, etc..

2 Una vez en la vista de historicos, es posible agregar cambiar los meses a la grafica.

Postcondicion El usuario puede visualizar los detalles de los movimientos realizados en la aplicacion.

Excepciones Paso Accion

1 Si no exiten valores se debe mostrar un mensaje informando que no hay datos historicos.


1 2 segundos


Importancia vital



33


2.2.7. Caso de uso Nro. 9 - Proyecciones

Tabla 2.7: Caso de uso Proyecciones

RF-0009 Proyecciones

Version 0001 22/11/2017

Autores Kalu Corp.



solicite la vista de proyecciones.


Secuencia Normal

Paso Accion

1

El sistema presenta en pantalla completa un resumen de ingresos o egresos, estos discriminados

por las siguientes categorıas: constituyendo como ingresos; depositos, salario y ahorros y como

egresos; facturas, ropa, comunicaciones, entretenimiento, comida, salud, hogar y transporte.

Estos pueden ser filtrados por mes y ano.

La informacion sera presentada en una grafica de torta, asociando un ıcono y color a cada

categorıa, segun el criterio de busqueda.

2

Cuando el usuario solicite al asistente Kalu detalle de la informacion de una categorıa, se

debe mostrar una pantalla con el gasto total correspondiente a dicha categorıa y un listado

de los elementos agregado a esta con los costos asociados.

Postcondicion El usuario puede visualizar los ingresos y egresos registrados por categorıa.

Excepciones

Paso Accion

1Si no existen valores se debe mostrar un mensaje informando que no hay datos para realizar

las proyecciones.

2Si no existen valores se debe mostrar un mensaje informando que no hay datos para realizar

las proyecciones.

Rendimiento

Paso Cota de tiempo

1 2 segundos

2 2 segundos


Importancia vital



34

2.3 Modelo de datos

2.3. Modelo de datos

Con referencia a las interacciones descritas en los casos de uso y a la persisten-cia requerida para el almacenamiento de los datos, se define el siguiente modelode datos:

Figura 2.12: Modelo relacional de tablas


35


Descripcion de las tablas:

Tabla ”lista valor”: Esta tabla contiene la informacion concerniente a las cla-ves y los valores que se usan de manera transversal en la aplicacion.

Tabla ”movimientos”: Esta tabla contiene la informacion concerniente a losmovimientos que el usuario puede realizar en la app, entiendase movimiento comoel ingreso de una compra en cualquiera de las categorıas, como el registro de unaegreso tambien, en cualquiera de las categorıas.

Tabla ”detalle movimiento”: Esta tabla contiene la informacion concernientea los ıtems que son agregados por el usuario cuando realiza un movimiento en elchat de la aplicacion.

Tabla user movimientos”: Esta tabla contiene la informacion concernientelos movimientos realizados por el usuario. Tabla “users”: Esta tabla contiene lainformacion concerniente al usuario al momento del registro.

Tabla ”password resets”: Esta tabla contiene el token que se usa para que unusuario puede restablecer su contrasena, cuando se registra mediante de Laravel5.2 (esta opcion no esta habilitada).

Tabla ”migrations”: Esta tabla contiene la informacion concerniente a lasmigraciones que se han realizado en el app y la base de datos (migraciones:concepto que se usa en Laravel 5.2 para hacer actualizacion en la base de datos).

2.4. Interfaces de usuario

Haciendo uso de tecnicas de maquetado se define los criterios de visualizacionde los componentes de cara a la experiencia de usuario organica que se pretendelograr, siendo una muestra del arte de las pantallas de la aplicacion movil lasiguiente:

2.4.1. Prototipo de pantalla de Registro de usuario

El usuario presiona el boton de registro en la pantalla principal, luego semuestra una pagina con el formulario de registro o la opcion de registrarse conFacebook.

36

2.4 Interfaces de usuario

Si el usuario elige el registro mediante el formulario, debe diligenciar los si-guientes datos: correo, contrasena y confirmacion de contrasena.

Si el usuario elige el registro mediante Facebook, debe autorizar a la aplicacionel acceso a los datos.

Figura 2.13: Diseno de baja fidelidad para Registro de usuario


37


2.4.2. Prototipo de pantalla de Autenticacion de usuario

Si el usuario tiene una sesion activa en Kalu, la aplicacion debe direccionar ala vista de “conversaciones” RF-0005, de lo contrario se debe mostrar la vista deinicio de sesion.

Segun la forma de inicio de sesion que el usuario seleccione, Facebook o usandoel formulario de Login, en este ultimo caso se deben diligenciar los campos correoelectronico y contrasena, si el proceso es correcto y es la primera vez que el usuarioingresa se ejecuta la consolidacion del perfil sino se va la vista de conversaciones.

Figura 2.14: Diseno de baja fidelidad para Autenticacion de usuario


38


2.4.3. Prototipo de pantalla de Conversaciones

El sistema presenta en pantalla completa al asistente llamado “Kalu” que seracapaz de interpretar los comandos que el usuario ingrese mediante voz o texto.

El sistema mediante el asistente “Kalu”, luego de interpretar los comandos,debera mostrar al usuario ventanas con la informacion que el usuario requiera sies el caso. Las ventanas a las que el usuario tendra acceso mediante comando son:

Mi cartera

Proyecciones

Figura 2.15: Diseno de baja fidelidad para Conversaciones


39


2.4.4. Prototipo de pantalla de Detalles de movimientos

En esta pantalla se presenta informacion detallada de cada uno de los ıtemso activos relacionados a un movimiento realizado en la aplicacion, dentro de losdatos que se muestran estan: valores economicos relacionados, categorıa a la quepertenece un ıtem, etc.

Figura 2.16: Diseno de baja fidelidad para Detalles de movimientos


40


2.4.5. Prototipo de pantalla de Mi Cartera

El sistema presenta en pantalla completa un resumen de ingresos y egresosregistrados, estos discriminados por las siguientes categorıas: constituyendo comoingresos; depositos, salario y ahorros y como egresos; facturas, ropa, comunicacio-nes, entretenimiento, comida, salud, hogar y transporte. Estos pueden ser filtradospor mes y ano. La informacion sera presentada en una grafica de torta, asociandoun ıcono y color a cada categorıa.

Figura 2.17: Diseno de baja fidelidad para Mi Cartera


41


2.4.6. Prototipo de pantalla de Muesca de conversaciones

(Notch)

El notch es capaz de interpretar los comandos de voz y ejecutar las accionesdentro o hacia las pantalla, mi cartera, historico de movimientos, conversacionesy proyecciones garantizando la navegacion entre pantallas y la actualizacion dela informacion.

Figura 2.18: Diseno de baja fidelidad para Muesca de conversaciones (Notch)


42

2.5 Diseno encuesta de validacion de experiencia de usuario

2.5. Diseno encuesta de validacion de experien-

cia de usuario

La encuesta se disena para ampliar la prospectiva del proyecto con la voz delos usuarios, y para validar la implementacion de las funcionalidades del proto-tipo que se implementa en el proyecto, con las intenciones que se mencionan acontinuacion:

IDENTIFICAR LA DIFICULTAD EN LA ELABORACION DE PRESU-PUESTOS. Pregunta No 1. Que se le dificulta mas en la elaboracion y seguimiento

de sus presupuestos financieros?

1. Identificar las diferencias entre el presupuesto original con lo finalmentegasto

2. Ser constante con el registro de la informacion

RECONOCER LA NECESIDAD DE UNA APLICACION MOVIL QUE GE-NERE REPORTES CON DATA DEL MES EN CURSO E INCLUYA HISTORI-COS CON DISPONIBILIDAD DE CONSULTA EN RED. Pregunta No 2. Como

le parece mas practico llevar un control de sus gastos?

1. Libreta de papel

2. Registro digital offline

3. Usando aplicaciones moviles online

43


Pregunta No 3. Con el metodo de control de su presupuesto usado actualmentepuede identificar cuanto ha gastado durante el transcurso del mes? O en mesesanteriores?

1. Con mucha facilidad

2. Es dispendioso

3. No tengo manera de identificar esta informacion

CORROBORAR LA NECESIDAD DE UNA APLICACION MOVIL QUEGENERE PROYECCIONES/PREDICCIONES BASADAS EN HISTORICOSDE CONSUMO. Pregunta No 4. Con el metodo de control de su presupuesto

usado actualmente, se le hace comodo tener proyecciones de gasto basados en sushabitos de consumo?

1. No

2. Sı

3. No tengo manera de identificar esta informacion

VALIDAR OTROS POSIBLES USOS; LA ACEPTACION DE UNA APLI-CACION DE LA LINEA DEL PROTOTIPO DESARROLLADO QUE APOYELA PRESENTACION DE LA DECLARACION DE RENTA. Pregunta No 5. Le

parecerıa mas comodo usar una aplicacion que le permita validar la elaboracionde su declaracion de renta que confiar ciegamente en su contador?

1. No

2. Sı

3. Algunas veces

44

2.5 Diseno encuesta de validacion de experiencia de usuario

IDENTIFICAR OTROS POSIBLES USOS; LA ACEPTACION DE UNAAPLICACION DE LA LINEA DEL PROTOTIPO DESARROLLADO QUEESTIMULE EL AHORRO. Pregunta No 6. ¿Con el metodo de control de su

presupuesto usado actualmente, le es facil programar su ahorro?

1. No

2. Sı

3. Algunas veces

CORROBORAR EL RECONOCIMIENTO DE VOZ IMPLEMENTADO CO-MO UNA MEJORA DE LA INTERACCION CON EL SISTEMA Pregunta No

7. ¿Considera que las aplicaciones moviles tipo Siri, o La busqueda de Google(Google Voice Search) que permiten comandos de voz aceleran el ingreso y con-sulta de la informacion?

1. No

2. Sı

3. Algunas veces

CORROBORAR EL RECONOCIMIENTO DE VOZ IMPLEMENTADO CO-MO UNA MEJORA DE LA INTERACCION CON EL SISTEMA Pregunta No

8. ¿Si tuviera la posibilidad de hacer uso de una aplicacion que le permitiera elingreso y consulta mediante voz y texto de sus gastos e ingresos, la usarıa?:

1. Frecuentemente

2. No

3. Algunas veces

45

Capıtulo 3

Desarrollo de funcionalidades del

prototipo

3.1. Desarrollo de la interfaz de usuario

Se desarrollaron las pantallas y se garantizo el flujo de navegacion tanto me-diante la digitacion como por comandos de voz.

De los requerimientos RF-001 y RF-002, segun lo esperado, se garantiza lainteraccion con el usuario mediante texto unicamente, ya que al involucrar elingreso de constrasena, se deseo mantener la confidencialidad mediante la mascarade campo y que la informacion no fuera expuesta mediante audio.

La navegacion entre pantallas haciendo uso de comandos de voz se consiguiomediante la implementacion del caso de uso RF-0009 y garantizando la mani-pulacion tactil de los botones correspondientes al avance o retroceso segun co-rrespondıa en cada requerimiento y pantalla. Siguiendo la lınea de concepto deinterfaz y experiencia de usuario plasmada en los disenos, los componentes grafi-cos fueron implementados para lograr el objetivo de una interaccion amigable talcomo se describen en el apartado siguiente.

A continuacion presentan los paginas desarrolladas con base a los disenos debaja fidelidad:

47

3. DESARROLLO DE FUNCIONALIDADES DEL PROTOTIPO

3.1.1. Registro de usuarios

Figura 3.1: Pantalla de Registro de Usuario


48

3.1 Desarrollo de la interfaz de usuario

3.1.2. Autenticacion de usuario

Figura 3.2: Pantalla de Autenticacion de Usuario


49


3.1.3. Conversaciones

Figura 3.3: Pantalla de Conversaciones


50

3.1 Desarrollo de la interfaz de usuario

3.1.4. Detalles de movimientos

Figura 3.4: Detalles de movimientos


51


3.1.5. Mi cartera

Figura 3.5: Pantalla Mi Cartera


52

3.2 Controles graficos

3.1.6. Muesca de conversaciones (Notch)

Figura 3.6: Pantalla de muesca de conversaciones


3.2. Controles graficos

Haciendo uso de la versatilidad de un desarrollo multiplataforma Android yiOS, mediante la tecnologıa de componentes React Native, se implementaron lascaracterısticas graficas de los controles propuestos en el diseno, ası:

Registro de usuario

Autenticacion de usuario

Conversaciones

Muesca de Conversaciones (Notch)

Proyecciones

3.3. Reconocimiento de voz

Se hizo uso del reconocimiento de voz de la tecnologıa Cloud Speech API desa-rrollada por Google, mediante la captura de audio y su posterior procesamientoy se garantizo la correcta identificacion de las entidades correspondientes para elcontrol del flujo de la aplicacion mediante los comandos de voz. Entre las ventajasque se corroboraron en el empleo de dicha API, se destaca el uso de modelos deredes neuronales.

53


3.4. Procesamiento de datos en plataforma REST-

ful

Para la realizacion de la plataforma REST se utilizo el framework Laravelen su version 5.2, se desarrollaron servicios que permiten ser consumidos desdela aplicacion movil Kalu, en algunos solicitando un token de autenticacion yen otros casos no, con el acceso a este Back-end, los usuarios de la aplicacionpueden ingresar informacion y mantener sus datos asegurados mientras poseanun usuario. Esta plataforma realiza toda la integracion e interoperabilidad entrelos API externos usados tanto para el reconocimiento de voz (Google Speech) elcual a su vez retorna una transcripcion del audio a texto, la creacion del flujoconversacional y reconocimiento de intenciones con Watson Assistant y finalmentela persistencia en base de datos de los datos de los usuarios.

Para la implementacion e integracion de los API externos, es necesario generarcredenciales para cada una de las plataformas, para luego consumir los endpointsnecesarios.

3.4.1. Acceso a historicos

Con el fin de garantizar que los usuarios puedan acceder en cualquier momentoa la informacion historica se implemento y pantalla en la que los usuario tenganla posibilidad de visualizar sus historicos, a su vez, que en la plataforma RESTse desarrollo un endpoint que expone dicha informacion.

3.4.2. Generacion de proyecciones basados en habitos de

consumo

Al igual que con el comportamiento de la generacion del endpoint para obtenerinformacion con respecto a los historicos de las transacciones realizadas por elusuario, en este punto se desarrollo un endpoint en la plataforma REST queconsulta los datos del usuario en la base de datos y permite realizar identificarla periodicidad de la insercion de un artıculo al presupuesto de gastos, y tomar

54

3.4 Procesamiento de datos en plataforma RESTful

decisiones acerca de la inquietud que manifieste el usuario acerca si es necesarioo no adquirir ese producto. Dicha decision se presenta en una pantalla llamadaMis Proyecciones en la aplicacion movil Kalu.

3.4.3. Integracion API para el flujo conversacional

Las conversaciones que el usuario sostiene en con el Kalu Assistant se alam-cenan en la base de datos y con esto poder generar un historial de los mesajes ysolicitudes realizadas en la aplicacion, de este mismo modo, cuando un usuariorecuerda un audio en la aplicacion, este audio se envıa a la plataforma RESTfulmediante el consumo de varios servicios web, en la plataforma el audio se mandaal servicio de Google speech que retorna una texto, el texto retornado se envıa aWatson Assistant mediante el uso del API realizando peticiones cURL; la infor-macion es procesada y posteriormente enviada a la aplicacion como respuesta enformato JSON.

En la aplicacion movil (Kalu Assistant) se plasmo una logica en codigo de laaplicacion movil que permite ingresar la informacion en la plataforma RESTful yque puede ser consultada por esta plataforma en la base de datos, ası, las conver-saciones del usuario y otros datos estan disponibles en la aplicacion, siempre quese retorna una respuesta a la aplicacion esta la evalua y define un comportamientoen el flujo conversacional a nivel de aplicacion.

A continuacion se presenta el flujo que lleva Watson Assistant en la integracioncon diversas plataformas:

55


Figura 3.7: Flujo de Watson Assistant

Fuente : Henrik Loeser. 2018. Flujo de Waston[Online; recuperado en Mayo 12, 2018].https://www.ibm.com/blogs/bluemix/2017/06/building-chatbots-tips-tricks/

56

3.4 Procesamiento de datos en plataforma RESTful

3.4.4. Persistencia de datos

En este apartado se garantizo que la informacion del usuario se pudiera al-macenar en una base de datos relacional montada sobre el motor MySQL en suversion 5.6. El modelo de datos se encuentra en coherencia con las descripcionesde las tablas mencionadas en el apartado de diseno. Para persistir los datos se

utiliza laravel 5.2 y el ORM Eloquent que proporciona una implementacion deActiveRecord bella y sencilla para trabajar con su base de datos. Cada tabla debase de datos tiene un “Modelo” correspondiente que se utiliza para interactuarcon esa tabla. Los modelos le permiten consultar datos en sus tablas, ası comoinsertar nuevos registros en la tabla. (Eloquent, 2018)

57

Parte III

Cierre de la Investigacion

59

Capıtulo 4

Presentacion de encuesta de opinion

4.1. Contexto

A continuacion, se presenta la encuesta practicada para validar presentar elimpacto de la implementacion del prototipo, donde se recopilo informacion sobreel grado de aceptacion de las funcionalidades desarrolladas, y una idea de laprospectiva del crecimiento de la aplicacion.

4.2. Ficha tecnica de la encuesta

4.2.1. Marco muestral

Personas ubicadas en rango de edades 25-45, con acceso a dispositivos movilesinteligentes y que perciben fuentes de ingreso provenientes de un salario paraaportar al gasto personal y/o familiar.

4.2.2. Tecnica de recoleccion de datos

Diligenciamiento de formulario en lınea mediante Google Forms.

4.2.3. Tamano de la muestra

La muestra total fue de 118 personas.

61

4. PRESENTACION DE ENCUESTA DE OPINION

4.3. Resultados

Pregunta No 1. ¿Que se le dificulta mas en la elaboracion y segui-miento de sus presupuestos financieros?

Figura 4.1: Encuesta Pregunta No. 1


Pregunta No 2. ¿Como le parece mas practico llevar un control desus gastos?



62

4.3 Resultados

Pregunta No 3. ¿Con el metodo de control de su presupuesto usadoactualmente puede identificar cuanto ha gastado durante el transcursodel mes? O en meses anteriores?



Pregunta No 4. ¿Con el metodo de control de su presupuesto usadoactualmente, se le hace comodo tener proyecciones de gasto basadosen sus habitos de consumo?



63


Pregunta No 5. ¿ Le parecerıa mas comodo usar una aplicacion quele permita validar la elaboracion de su declaracion de renta que confiarciegamente en su contador?



Pregunta No 6. ¿Con el metodo de control de su presupuesto usadoactualmente, le es facil programar su ahorro?



64

4.3 Resultados

Pregunta No 7.¿Considera que las aplicaciones moviles tipo Siri, oLa busqueda de Google (Google Voice Search) que permiten comandosde voz aceleran el ingreso y consulta de la informacion?



Pregunta No 8.¿Si tuviera la posibilidad de hacer uso de una apli-cacion que le permitiera el ingreso y consulta mediante voz y texto desus gastos e ingresos, la usarıa?



65


Validacion de Intencionalidad en resultados de la encuesta

En la Pregunta No.1 : ¿Que se le dificulta mas en la elaboracion y seguimientode sus presupuestos financieros?” , se buscaba identificar la causa raız de la faltade habito del uso de presupuestos personales, y se evidencia ante un 77 % de los118 encuestados que la causa raız de la falta de habito en el uso de presupuestopersonales se presenta como: Ser constante con el registro de la informacion.

Con la Pregunta No.2 : ¿Como le parece mas practico llevar un control de susgastos? se logro confirmar que la falta de uso de aplicaciones o sistemas digitalesno se debe a la resistencia del publico en general por el uso de dichos metodos yaque solo el 31.4 % de los 118 encuestados prefieren el uso de una libreta de papel.

La Pregunta No 3: ¿Con el metodo de control de su presupuesto usado ac-tualmente puede identificar cuanto ha gastado durante el transcurso del mes? Oen meses anteriores?. Se Corroboro que es necesario mejorar el acceso a historicosde la manera como las soluciones de control de presupuestos lo hacen, ya quesolo el 36.4 % de las 118 respuestas obtenidas esta satisfecho con las herramientasusadas previas a Kalu.

Mediante la Pregunta No. 4: ¿Con el metodo de control de su presupuestousado actualmente, se le hace comodo tener proyecciones de gasto basados en sushabitos de consumo? Se pretendio corroborar la necesidad de ir mas alla de unregistro de eventos y permitir que en un futuro aplicaciones como Kalu presentennotificaciones, predicciones.

La Pregunta 7: ¿Considera que las aplicaciones moviles tipo Siri, o La busque-da de Google (Google Voice Search) que permiten comandos de voz aceleran elingreso y consulta de la informacion? Valido el impacto de la utilidad en la inter-accion mediante comando de voz en aplicaciones de alto reconocimiento.

66

Capıtulo 5

Conclusiones

Verificacion, contraste y evaluacion de los objetivos

A continuacion, presentamos la contrastacion de objetivos propuestos, conrelacion al desarrollo del prototipo y los resultados de la encuesta de validacion.

Acerca del Objetivo General:

Kalu siendo un sistema que permite el registro digital de la informacion, dacumplimiento al objetivo general del proyecto de investigacion y tiene un impactopositivo en la forma como la comunidad encuestada considera que deberıa ser unmetodo practico de gestion del presupuesto.

Es ası como se identifico en la Pregunta No. 2: ¿Como le parece mas practicollevar un control de sus gastos?, que la falta de uso de aplicaciones o sistemasdigitales no se debe a la resistencia del publico en general por el uso de dichosmetodos, sino que por el contrario, la preferencia del nicho encuestado es el uso deaplicaciones moviles, dado que mas del 45 % de la muestra, las consideran comola forma mas practica de llevar el control de sus gastos.

67

5. CONCLUSIONES

Acerca del Objetivo Especıfico:

Disenar una interfaz de usuario que utilice el reconocimiento devoz usando el API Google Speech y controles graficos desarrolladoscon React Native de Facebook para la captura de la informacion einteraccion con el usuario

La filosofıa de interaccion en la que esta basada Kalu, con la implementacionde texto y/o audio como medio de ingreso de informacion, aumenta el uso delas aplicaciones de control de finanzas personales, se afirma tal informacion, conreferencia a la gran aceptacion que tiene las aplicaciones que utilizan comandosde voz, tal como se evidencio en las respuestas de la encuesta con relacion a lapregunta No. 7.

Siendo la Pregunta 7: ¿Considera que las aplicaciones moviles tipo Siri, oLa busqueda de Google (Google Voice Search) que permiten comandos de vozaceleran el ingreso y consulta de la informacion? se Valido el impacto de la utilidaden la interaccion mediante comando de voz en aplicaciones de alto reconocimiento.En conclusion, dicha percepcion fue muy positiva al corroborar que solo el 16 % delos encuestados rechazan la idea de que dichas aplicaciones ingresan y consultaninformacion de forma agil, con el prototipo se logro ampliar las posibilidades deinteraccion entre el usuario y el sistema generando valor.


Desarrollar plataforma REST haciendo uso de Laravel 5.2 para lagestion de servicios que permitan el acceso a la informacion historicade los habitos de consumo

Kalu, haciendo uso de las tecnologıas tales como se describen en el objetivoespecıfico en mencion, logra aportar a la resolucion de la dificultad en el accesoa historicos, ya que como se evidencio en la encuesta de impacto, solo el 36.4 %de las 118 respuestas obtenidas en referencia a la Pregunta No. 3, esta satisfechocon las herramientas homologas al prototipo Kalu.


Implementar una infraestructura cliente-servidor para el almace-namiento de datos, presentacion de historicos y generacion de proyec-ciones basados en habitos de consumo, haciendo uso de una bases dedatos

68

El prototipo logra cumplimiento del objetivo propuesto, puesto que se consi-guio desarrollar en coherencia con el diseno propuesto tanto en capa de negociocomo en capa de datos; siendo el entregable, un producto mınimo viable queresponde a una logica de negocio definida que permite el consumo de serviciosweb para operaciones en la capa de datos y a su vez uso de los datos para lapresentacion de informacion historica y toma de decisiones con pronosticos.

69

Capıtulo 6

Prospectiva del trabajo de grado

6.1. Lıneas de investigacion futuras

Inteligencia computacional (Benitez, 2013) en relacion al reconocimiento devoz, y patrones de consumo para generar proyecciones.

Data mining en relacion a las tecnicas de analisis de historicos para sugerirproductos asociados a consumos existentes.

6.2. Trabajos de Investigacion futuros

Se plantea como prospectiva de este proyecto implementaciones de modulos denotificaciones para ampliar la informacion que se presenta sobre eventos futurosen la gestion del presupuesto.

Se identifico ademas que se puede aplicar el desarrollo de una aplicacion comola que se presenta en este prototipo del proyecto, que tenga usos complemen-tarios como lo son; herramientas de comunicacion y apoyo en la elaboracion dedeclaraciones de renta, y herramientas que estimulen el ahorro.

En el componente de predicciones, hay un area de investigacion no solo enel universo de las herramientas de gestion de presupuestos sino tambien en lastecnicas de inteligencia computacional que hacen posibles dichas implementacio-nes.

71

Bibliografıa

Burnett, D. C., Walker, M. R., y Hunt, A. (2004). Speech synthesis markup

language (ssml) version 1.0. Descargado de http://www.w3.org/TR/speech

-synthesis ([Online; recuperado en Febrero 17, 2018])

9

Definicion de entidades. (2018). Descargado de https://watson-assistant

.ng.bluemix.net/us-south/9bf009af-e12b-42ae-b84a-cbe0d8158a14/

workspaces ([Online; recuperado en Noviembre 23, 2017])

81

Definicion de intenciones. (2018). Descargado de https://console.bluemix

.net/docs/services/conversation/intents.html ([Online; recuperado en

Noviembre 23, 2017])

79

Program your chatbot to handle “long-tail” questions with watson conversation

and watson discovery. (2017). ([Online; recuperado en Noviembre 30, 2017])

83

Alvarado Casallas, John Albeiro. (2011). Generador de sistemas de respuestas de voz

interactiva para la venta de tiquetes en el transporte terrestre intermunicipal. Univer-

sidad Distrital Francisco Jose de Caldas. Bogota, Colombia.

73

http://www.w3.org/TR/speech-synthesis

http://www.w3.org/TR/speech-synthesis

https://watson-assistant.ng.bluemix.net/us-south/9bf009af-e12b-42ae-b84a-cbe0d8158a14/workspaces



https://console.bluemix.net/docs/services/conversation/intents.html

https://console.bluemix.net/docs/services/conversation/intents.html

BIBLIOGRAFIA

Berson, Alex (1992). Client/Server Architecture. Editorial McGraw-Hill, Inc., Estados

Unidos.

Beltran Bernal, Nestor Andres (2015). Propuesta metodologica para la planeacion de

costos como indicador de eficiencia en la formulacion de proyectos de ingenierıa. Uni-

versidad Distrital Francisco Jose de Caldas.

Benıtez, Raul (2013) . Inteligencia artificial avanzada. Barcelona. UOC.

De Luca, Damian. (2014). Apps HTML5 para moviles: desarrollo de aplicaciones para

smartphones y tablets basado en tecnologıas web. Bogota, Colombia. Editorial Alfao-

mega.

Dıaz Christian Fabian. (2015). Prototipo de plataforma portable para la atencion de

servicios usando dispositivos moviles. Bogota. Universidad Distrital Francisco Jose de

Caldas

Dıaz Celis, Jorge Andres (2010). Diseno, desarrollo e implementacion de un control

domotico operado por voz mediante protocolo ZigBee. Universidad Distrital Francisco

Jose de Caldas.

Gonzalez Rincon, Karen Yamile. (2013). Formulacion de un modelo matematico para

optimizar las finanzas personales de los estudiantes laboralmente activos de la Univer-

sidad Distrital. Bogota, Colombia.

Herrera Triguero, Francisco. (2014) Inteligencia artificial, inteligencia computacional y

Big Data. Jaen, Espana.: Universidad de Jaen.

Hung, Patrick C. K.. (2012).Web service composition and new frameworks in designing

semantics: innovations. Information Science Reference.

Rodriguez Suarez, Cesar Augusto. (2009). Control de acceso a usuarios en ambientes

74

BIBLIOGRAFIA

web mediante verificacion biometrica por voz. Bogota.: Universidad Distrital Francisco

Jose de Caldas.

Sanchez Cardenas, Heidi Viviana (2011). Diseno y desarrollo de un prototipo de apli-

cacion movil para la administracion de un servidor de correo. Universidad Distrital

Francisco Jose de Caldas.

Everett Stephanie S. (2017). Adding Speech Recognition to a Natural Language

Interface. Recuperado de:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.17.6472&rep=rep1&type=pdf

Gallego, Javier. (2016). Banca: una revolucion en el bolsillo. Tendencias en economıa y

management para la creacion de valor. Valores, noviembre 2016 (19). P. 28-29. Recupe-

rado de: https://home.kpmg.com/content/dam/kpmg/es/pdf/2016/11/valores-19.pdf

IBM. Building Cognitive Applications with IBM Watson Services: Volume 6 Speech to

Text and Text to Speech.

Recuperado de: http://www.redbooks.ibm.com/redbooks/pdfs/sg248388.pdf

I. M. T. Hernandez, A. M. Viveros, E. H. Rubio and B. E. Carvajal-Gamez (2013).

Voice recognition framework for open rich-client mobile applications. 10th Internatio-

nal Conference on Electrical Engineering, Computing Science and Automatic Control

(CCE). DF, Mexico. p. 302-306.

Recuperado de:

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6676053&isnumber=6676004

James Floyd Kelly (2011). SAMS teachs yourself Mint.com in ten minutes. Pearson

Education Inc.

Recuperado de:

75

BIBLIOGRAFIA

http://ptgmedia.pearsoncmg.com/images/9780672335662/samplepages/0672335662.pdf.

Nunez, Monica. (2017). Administracion financiera y finanzas personales.

Recuperado de: https://www.gestiopolis.com/administracion-financiera-y-finanzas-

personales/ S. Furui, T. Kikuchi, Y. Shinnaka, and C. Hori, (2004). Speech-to-text and

speech-to-speech summarization of spontaneous speech. IEEE Transactions on Speech

and Audio Processing, 2004, vol. 12, p. 401– 408. The World Bank Group (2013). Ca-

pacidades financieras en Colombia. Bogota, Colombia. Financial Literacy& Education.

Vindas, Rolando (2018). Evolucion de Watson Conversation a Watson Assistant Recu-

perado de: https://www.cognitiva.la/blog/evolucion-de-watson-conversation-a-watson-

assistant/ Yubal F. (2017). Estas son las 11 mejores apps para controlar tus gastos

en la cuesta de enero. Recuperado de: https://www.xatakandroid.com/aplicaciones-

android/estas-son-las-11-mejores-apps-para-controlar-tus-gastos-en-la-cuesta-de-enero

76

Apendice A

Anexo I: Ambiente necesario para

Laravel 5.2

A.1. Requisitos del servidor

El marco de Laravel tiene algunos requisitos del sistema, para asegurar de quesu servidor cumpla con los siguientes requisitos:

Version de PHP entre 5.5.9 y 7.1.*

Extension de PHP OpenSSL

Extension de PDO PHP

Extension de PHP Mbstring

Extension Tokenizer para PHP

A.2. Configuracion y permisos

A.2.1. Configuracion

Todos los archivos de configuracion para el marco de Laravel se almacenan enel directorio config. Cada opcion esta documentada, ası que no dude en consultarlos archivos y familiarizarse con las opciones disponibles para usted.

77

A. ANEXO I: AMBIENTE NECESARIO PARA LARAVEL 5.2

A.2.1.1. Permisos de directorio

Para el funcionamiento de la aplicacion en Laravel, es posible que deba configu-rar algunos permisos. Los directorios dentro del ”storage 2los directorios ”boots-trap/cache”deben ser editables por su servidor web o Laravel no se ejecutara.

A.2.1.2. Clave de aplicacion

Se bebe establecer una clave de aplicacion en una cadena aleatoria. Para confi-gurar una clave debe usar el comando ”php artisan key:generate”. Normalmente,esta cadena debe tener 32 caracteres de longitud. La clave se puede establecer enel archivo de entorno ”.env”. :

78

Apendice B

Anexo II: Entrenamiento inicial de

Watson Assistant

B.1. Requisitos para la configuracion

Para ejecutar estas configuraciones es necesario crear una cuenta en bluemix ousar una existente y activa. Para crear la cuenta es necesario ingresar a la paginade IBM cloud y seguir los pasos para crear una cuenta. En cualquier de los casos,como si ya tenıa una cuenta o recien ha sido creada, es necesario activar el serviciode Watson Assistant y aceptar los terminos y condiciones.

B.2. Creacion de una Intencion

Las intenciones son objetivos o propositos expresados en una entrada de clien-te, como por ejemplo responder a una pregunta o procesar el pago de una factura.Al reconocer la intencion expresada en una entrada de cliente, el servicio WatsonAssistant puede elegir el flujo de dialogo correcto para responder a la misma (3).

En la consola de administracion de Watson Assistant ver figura B.1 seleccioneel Workspace creado y luego aparecera una pantalla como se aprecia en la figuraB.2, sino ha creado ningun workspace hacer click en el boton crear y llenar losdatos necesarios.

79

B. ANEXO II: ENTRENAMIENTO INICIAL DE WATSON ASSISTANT

Figura B.1: Panel de control de Watson Assistant

A continuacion los pasos para crear una intencion:

1. Creacion de una intencion (Intent): cuando apareza una pantalla similar ala que se muestra en la figura B.2 hacer click sobre el boton create.

Figura B.2: Pantalla de intenciones

80

B.3 Creacion de una entidad

2. Relleno de datos de una intencion (Intent): aparecera a continuacion unapantalla como la que se puede ver en la figura B.3. en la cual se debenrellenar los datos, para este caso se uso informacion de ejemplo.

Figura B.3: Pantalla de agregacion y edicion de intenciones

Con esto quedara creada la intencion o Intent y ya pueden ser reconocidaspor Watson Assistant.

B.3. Creacion de una entidad

Las entidades representan una clase de objeto o un tipo de datos que esrelevante para el objetivo del usuario. Cuando reconoce las entidades mencionadasen la informacion de entrada del usuario, el servicio Watson Assistant puede elegirlas acciones especıficas que debe llevar a cabo para cumplir una intencion (2).

A continuacion los pasos para crear una entidad:

1. Creacion de una entidad (Entity): cuando apareza una pantalla similar a laque se muestra en la figura B.4 hacer click sobre el boton add entity.

81


Figura B.4: Pantalla de entidades

2. Rellenando los datos para una entidad (Entity): aparecera a continuacionuna pantalla como la que se puede ver en la figura B.5. en la cual se debenrellenar los datos, para este caso se uso informacion de ejemplo.

Figura B.5: Pantalla de agregacion y edicion de entidades

Con esto quedara creada la entidad o Entity y ya pueden ser reconocidas porWatson Assistant.

82

B.4 Configuracion de flujo conversacional

B.4. Configuracion de flujo conversacional

La configuracion del flujo de conversacion es de tipo “short tail segun los tiposconfigurados por IBM (4), en este sentido, se presenta en la figura B.6 la formacomo se definieron los flujos para Kalu.

Figura B.6: Pantalla de configuracion de Flujo conversacional

83


B.5. Prueba de flujo conversacional

Watson Assistant en su consola permite probar el flujo conversaciones confi-gurado previamente, ası, a continuacion se presenta una prueba de las respuestasproporcionadas.

Figura B.7: Pantalla de prueba de flujo de conversacion

84

trabajo de gradorepository.udistrital.edu.co/bitstream/11349/13638/1... · 2019-07-26 ·...

Documents