ticket app - repository.udistrital.edu.corepository.udistrital.edu.co/bitstream/11349/2793/1... ·...

TICKET APP - ADMINISTRACIÓN DE CUENTAS DEUSUARIO PARA BOLETERÍA DE EVENTOS EN

DISPOSITIVOS MÓVILES INTELIGENTES

Especialización en Ingeniería de Software

Universidad Distrital Francisco José de Caldas

John Alex Cortes BustosCarol Jazmín Mejía Montañez

Joan Humberto Rincón Sarmiento

Índice general

I Introducción

1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

II Parte II. Contextualización de la investigación

2 Descripción de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Titulo y definición del tema de investigación 132.2 Estudio del problema de investigación 132.2.1 Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2 Formulación del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.3 Sistematización del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3 Objetivos de la investigación 152.3.1 Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.4 Justificación de la investigación 152.4.1 Justificación practica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 Hipótesis del trabajo 162.6 Marco de referencia 162.6.1 Marco teórico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.6.2 Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6.3 Marco espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.7 Aspectos metodológicos 222.7.1 Tipo de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.7.2 Método de investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7.3 Metodología de Ingeniería . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7.4 Fuentes y técnicas para la recolección de la información . . . . . . . . . . . . . . . 232.7.5 Tratamiento de la información . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.8 Alcances, limitaciones y resultado esperado 242.8.1 Alcances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8.2 Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.8.3 Resultado esperado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.9 Organización del proyecto 252.9.1 Capítulos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.9.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

III Parte III.Desarrollo de la investigación

3 Desarrollo de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.1 Recolección y ordenamiento de la información 293.1.1 Información materia prima para la investigación . . . . . . . . . . . . . . . . . . . . . . 293.1.2 Tabulación, ordenamiento y procesamiento de la información . . . . . . . . . . . 30

3.2 Análisis de los resultados 30

4 Modelamiento del negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1 Contextualización empresa 314.1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.2 Misión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.3 Visión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.4 Función de la empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Modelamiento arquitectura empresarial 324.2.1 Punto de Vista de la Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2.2 Punto de Vista de Cooperación de Actor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2.3 Punto de Vista de Función de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.4 Punto de Vista de Proceso de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.5 Punto de Vista de Cooperación de Proceso de Negocio . . . . . . . . . . . . . . . . 364.2.6 Punto de Vista de Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.2.7 Punto de Vista Comportamiento de la Aplicación . . . . . . . . . . . . . . . . . . . . . 394.2.8 Punto de vista Cooperación de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.9 Punto de vista Estructura de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.10 Punto De Vista uso de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.11 Punto de vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.12 Punto de vista Uso de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.13 Punto de vista Implementación y Organización . . . . . . . . . . . . . . . . . . . . . . . . 454.2.14 Punto de vista de Estructura de Información . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.15 Punto de vista de Servicio de Realización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.16 Punto de vista de Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.17 Punto de vista de Realización de Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.18 Punto de vista de Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.19 Punto de vista de Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.20 Punto de vista de Realización de Requerimientos . . . . . . . . . . . . . . . . . . . . . . 524.2.21 Punto de vista de Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2.22 Punto de vista de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.23 Punto de vista de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.24 Punto de vista de Migración e Implementación . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3 Metodología 57

4.4 Historias de Usuarios 59

5 Modelamiento de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.1 Tecnología utilizada 61

5.2 Modelo entidad relación 62

5.3 Modelo relacional 63

6 Descripción técnica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.1 Contratos de servicio 656.1.1 WebService de login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.1.2 WebService de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.1.3 WebService de pagos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.1.4 WebService de tiquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

6.2 Diagrama de despliegue 68

6.3 Herramientas y tecnologías 69

7 Prototipo Funcional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.1 Login 71

7.2 Menú principal 72

7.3 Listar eventos 72

7.4 Detalle evento 73

7.5 Comprar tiquete de evento 73

7.6 Pago 74

7.7 Consultar tiquetes 74

7.8 Consultar Detalle tiquetes 75

IV Parte IV.Cierre de la investigación

8 Resultados y Discusión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

9 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

10 Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Anexo 1: Encuesta, tabulación y Resultados 83

Anexo 2: Diccionario de Datos 89

Anexo 3: Fuentes e Instaladores 93

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Índice de Tablas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Índice de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

I

1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . 9

Introducción

1. Introducción

La asistencia a conciertos es uno de los planes culturales más frecuente actualmente en la sociedad,y a pesar de ello en la actualidad no existe un sistema integral el cual permita agilizar el proceso deventa de tiquetes, ingreso al evento y soportar la demanda que requiere este tipo de servicio.

Para analizar esta problemática es necesario mencionar que gracias al auge de tecnologías comoel streaming y otros medios de difusión el mercado de la música ha cambiado de forma que losconciertos hacen parte fundamental de los ingresos para los artistas. El crecimiento del mercadoobjetivo y la globalización de la música han generado que estos eventos requieran una mayorgestión por parte de los organizadores para la generación de boletería y el ingreso de los asistentes.

En consecuencia, se presentan congestiones en el ingreso a estos eventos y gastos innecesarios depapelería para la impresión de boletería que no llegan a cumplir a cabalidad el fin de prestar unservicio preferencial y de calidad.

La investigación de esta problemática se realiza para minimizar las evidentes demoras en todoel proceso de ingreso a un concierto y también buscando una solución que permita eliminar elproblema de raíz mediante la implementación de tecnologías de cuarta generación y el uso delos conocimientos adquiridos en el programa de especialización de Ingeniería de Software de launiversidad Distrital Francisco José de Caldas.

En el curso de este documento se realizará el seguimiento a la investigación realizada y procesode creación de un prototipo de software que permitirá administrar una cuenta preferencial paraconsulta y adquisición de boletería para conciertos, el cual permitirá agilizar la generación deboletas mediante códigos QR y proporcionar los servicios que actualmente proporcionan empresascomo TuBoleta, la investigación y desarrollo se centran en la ciudad de Bogotá como modelo deimplementación.

La característica principal de este prototipo es la facilidad y seguridad que ofrece para la compra delas boletas para conciertos y la generación de estas mediante códigos QR

II

2 Descripción de la investigación . . . . . . 132.1 Titulo y definición del tema de investigación2.2 Estudio del problema de investigación2.3 Objetivos de la investigación2.4 Justificación de la investigación2.5 Hipótesis del trabajo2.6 Marco de referencia2.7 Aspectos metodológicos2.8 Alcances, limitaciones y resultado esperado2.9 Organización del proyecto

Parte II. Contextualización dela investigación

2. Descripción de la investigación

2.1 Titulo y definición del tema de investigaciónTicketApp - Administración de cuentas de usuario para boletería de eventos en dispositivos móvilesinteligentes.

2.2 Estudio del problema de investigación2.2.1 Planteamiento del Problema

En la actualidad no existe un sistema integral el cual permite agilizar el proceso de compra ygeneración de boletas para conciertos, los sistemas existentes generan sobre costo al usuariorequiriendo entregas a domicilio de las boletas o desplazamiento para la reclamación de las mismas,este tipo de boletería impresa también genera gastos innecesarios de papelería para la impresiónpor parte de los organizadores de los eventos.

Con la expansión de plataformas web como el streaming y la facilidad para tener acceso a la músicapor medios totalmente diferentes a los discos y el mercado que existía se ha logrado impulsar unnuevo mercado que genera millonarios ingresos. Medios como el streaming han permitido dar aconocer los artistas de formas diferentes y acceder más fácilmente a todo tipo de público lo cual halogrado incentivar a los empresarios para realizar más eventos en vivo, que cada día aumentan suvalor en inversión y ganancias.

Los espectáculos culturales como los conciertos son parte de los planes culturales más frecuenteactualmente en la sociedad, para el 2015 se estimó un crecimiento de un 30% por encima del 2014en asistencia a los diferentes eventos de este tipo programados. (Jaramillo, 2015)[1]

Las empresas de distribución de tiquetes no han desarrollado un sistema donde se pueda integrarla administración de servicios, compra de productos e ingreso a los eventos, ya sea por temasnetamente económicos o por falta de interés de la gerencia de tecnología.

De mantenerse esta problemática, las empresas no podrán solventar la demanda de usuarios deforma óptima generando inconformidades de servicio de estos mismos, lo que podría acarrear a

14 Capítulo 2. Descripción de la investigación

que algunos usuarios puedan desistir del uso de sus servicios. Por otra parte, se mantendrá el gastoeconómico de papel para la impresión de boletas.

Para dar solución a lo mencionado anteriormente es necesario la construcción de un sistema paradispositivos móviles Android donde se permita la consulta de información de conciertos, comprade boletas e ingreso a los eventos por medio de validación de códigos QR en la boleta generada porla aplicación.

2.2.2 Formulación del problema¿Al implementar una aplicación desarrollada para teléfonos inteligentes con sistema operativoAndroid donde se integran la compra y generación de boletas de conciertos se podría optimizar elproceso de forma que se mejore el servicio al usuario y se reduzcan los costos para los organizadoresde estos eventos?

2.2.3 Sistematización del problema1. ¿Cuáles de los servicios ofrecidos por las empresas distribuidoras de boletería pueden ser

incluidos en la implementación de la aplicación móvil?

2. ¿Es posible estimar si al desarrollar esta aplicación móvil se podrá facilitar el proceso paralos asistentes a estos eventos y reducir el costo al eliminar el proceso de la impresión deboletería?

3. ¿Qué tipo de plataformas de desarrollo móvil disponibles en el mercado se utilizarán pararealizar el desarrollo?

4. ¿El modelo puede ser fácilmente adaptable a otras cadenas de negocio?

2.3 Objetivos de la investigación 15

2.3 Objetivos de la investigación

2.3.1 Objetivo General

Crear un prototipo funcional en la ciudad de Bogotá para dispositivos móviles que permita integrarlos diferentes servicios ofrecidos por las empresas organizadoras, como son: consulta de eventos,compra de boletas y generación de boletas con código QR, desarrollando un proyecto de softwarealineado a una metodología enfocada hacia desarrollos ágiles, para minimizar el proceso de comprade boletas, reducir la impresión en papel, contribuir a un desarrollo sostenible y prestar un mejorservicio al usuario.

2.3.2 Objetivos específicos

1. Desarrollar un aplicativo móvil multiplataforma, utilizando tecnologías que permitan laconstrucción de aplicaciones híbridas y así permitir el despliegue en diferentes sistemasoperativos móviles como son Android y IOS.

2. Aplicar principios de Arquitectura de Software por capas, utilizando los conceptos de sistemasorientados a servicios para lograr máxima cohesión con el menor acoplamiento y facilidadde escalabilidad.

3. Identificar las principales necesidades de los asistentes frecuentes de conciertos en Bogotápara implementar las funcionalidades que ofrezcan mayor cobertura haciendo uso de análisisestadísticos.

2.4 Justificación de la investigación

2.4.1 Justificación practica

El auge de desarrollos móviles viene creciendo paulatinamente; Esto proyecta que un alto porcentajede proyectos de software para los próximos años se encuentren enfocados hacia este tipo deplataformas, las diferentes metodologías de desarrollo existentes en la ingeniería de software nose encuentran totalmente orientadas hacia proyectos móviles. Si se busca una metodología dedesarrollo ágil como Scrum o XP y se ajusta a las necesidades y actividades que se deben tenerpara un desarrollo móvil, se puede establecer una metodología la cual se adapte.

Por otro lado, la creación de este prototipo permitirá plantear una solución a la problemáticaplanteada (Boletería de conciertos) y proyectar la aplicación de este prototipo para otros ámbitosdel campo comercial y financiero de nuestro país como tarjetas de cliente, puntos y de serviciospreferenciales y así servir de base para el desarrollo y generación de productos de software ennuestro país adaptados a nuestras necesidades económicas y sociales.

Con el desarrollo de este proyecto busca ofrecer mejor calidad de servicio a los usuarios de estetipo de productos con el uso y aprovechamiento de la tecnología a la mano y la inclusión al manejode tecnologías móviles en personas de cualquier edad.

Finalmente, lo que se busca con la construcción de este aplicativo móvil es la integración deservicios que actualmente ofrecen empresas como TuBoleta integrando la generación de boletasdigitales con códigos QR, esto para detener su producción reduciendo costos considerables a lascompañías y lograr la administración de estos servicios por medio de teléfonos inteligentes.


2.5 Hipótesis del trabajoAl construir una aplicación móvil donde se integren los servicios ofrecidos por los organizadores ydistribuidores como TuBoleta y además se agregan funciones como la administración de una cuentapersonal y la generación de boletas por medio de códigos QR, se podrá reducir el congestionamientode personas en la compra de taquillas y eliminar la producción de boletas físicas.

2.6 Marco de referencia2.6.1 Marco teórico

El presente trabajo plantea toda la investigación, desarrollo y ejecución realizada para la creaciónde un prototipo de aplicación móvil que tiene como principal funcionalidad la venta tickets deeventos bajo el marco de la metodología de desarrollo Scrum y la aplicación de arquitectura MVC,por ello dentro del marco enunciaremos todos los conceptos tecnológicos y arquitectónicos quepermiten dar comprensión de los conceptos teóricos y técnicos requeridos para el desarrollo de esteprototipo, adicionalmente en este marco se desarrollan los conceptos de QR y pagos virtuales comoeje del valor agregado del proyecto.

Para empezar, se debe desglosar los antecedentes que nos permiten plantear la idea y construir unapropuesta de valor como producto para el mercado.

Se tomó como primera referencia un aplicativo que se creó en España en 2013 que se llama BBVAWallet que también opera en Chile, EEUU, México y Turquía. Que es utilizado para gestionar enlínea desde los Smartphone todas las transacciones realizadas con las tarjetas de crédito y efectuarpagos desde el teléfono móvil.

Este aplicativo empezó a reemplazar las tarjetas plásticas que brinda grandes ventajas, la másrepresentativa es el tema de la seguridad blindándola contra fraudes electrónicos y es funcionalsolo con la utilización de un teléfono inteligente.

Una billetera virtual es un programa o aplicación, que permite hacer las transacciones con loscomercios, como si fuera una tarjeta débito o crédito, es decir, en lugar de pasar tu tarjeta en undatafono, o tener que registrar todos los datos de la tarjeta de crédito cada vez que se hace unacompra online, se podrá escanear un código desde el móvil o loguearse en la billetera virtual, elegirla tarjeta con la que se quiere pagar (se puede registrar varias tarjetas de diferentes entidades), yautorizar el pago.

Este sistema nació en el 2011, gracias al lanzamiento de Google Wallet, pero desde septiembredel año 2014 sufrió una verdadera explosión tras el exitoso despegue de Apple Pay. Samsung nose quedó atrás y respondió en agosto del 2015 con su respectiva plataforma similar, mientras queGoogle, en réplica, presentó su Android Pay, una evolución de Google Wallet, que funciona deforma similar a Apple Pay.

“Lo que estamos haciendo con la billetera virtual es llevar la billetera de las personas al celular”,dijo el creador de la billetera virtual. Y agregó que esta aplicación “hará por fin posible el pago conel teléfono móvil”.

Estos aplicativos de billetera virtual empezarán a reemplazar las tarjetas plásticas brindando grandesventajas, la más representativa es el tema de la seguridad contra fraudes electrónicos mediantela utilización de un teléfono inteligente y disponibilidad del servicio para realizar todo tipo detransacciones sin necesidad de cargar tarjetas o efectivo.

2.6 Marco de referencia 17

En Colombia el banco Bancolombia en una prueba piloto con cinco clientes y cinco empleadosentre el 2014 y 2015 implementó con Paypass y una memoria micro SD habilitada con la tecnologíaNear Field Communication (NFC) la posibilidad de que los usuarios de la aplicación hicieran pagossin contacto, de una manera segura, confiable y práctica.

El Grupo Aval (AV Villas, Bogotá, Occidente y Popular) presentó en septiembre de 2015 su nuevodesarrollo tecnológico: la aplicación para ’Smartphone’ Aval Pay. Bancolombia le siguió el paso enel mercado financiero al presentar su servicio tecnológico de pago, todo esto nos permite tener unabase sólida de las necesidades del mercado y así introducirnos en la aplicación de esta tecnologíaen otros campos del mercado.

Sistemas de pagos electrónicosUn sistema de pago electrónico es un sistema de pago que facilita la aceptación de pagos electrónicospara las transacciones en línea a través de internet.

Los EPS o sistemas de pagos electrónicos, realizan la transferencia del dinero entre compradores yvendedores en una acción de compra-venta electrónica a través de una entidad financiera autorizadapor ambos. Es, por ello, una pieza fundamental en el proceso de compra-venta dentro del comercioelectrónico.

Como ejemplos de sistemas de pago electrónico nos encontramos las pasarelas de pago o TPVvirtual para el pago con tarjeta, los sistemas de monedero electrónico y los sistemas que se conectandirectamente con la banca electrónica del usuario. El comercio electrónico por Internet se ofrececomo un nuevo canal de distribución sencillo, económico y con alcance mundial las 24 horas deldía todos los días del año, y esto sin los gastos y limitaciones de una tienda clásica: personal, local,horario, infraestructura, etc.

En el pago con tarjeta, la pasarela de pago válida la tarjeta y organiza la transferencia del dinero dela cuenta del comprador a la cuenta del vendedor. El monedero electrónico, sin embargo, almacenael dinero del comprador en un formato electrónico y lo transfiere al sistema durante el pago. Elsistema de pago valida el dinero y organiza la transferencia a la cuenta del vendedor. También existela posibilidad de que el sistema de pago transfiera el dinero electrónico al monedero electrónicodel vendedor actuando en este caso como un intermediario entre ambos monederos electrónicos.El pago a través de la banca electrónica, enlaza un número de operación o venta realizada en elcomercio o tienda virtual con la cuenta bancaria del cliente en el mismo sitio del banco. Esto,reduce el riesgo de fraude al no transmitir información financiera personal por la red.

Tipos de sistemas de pagos electrónicosLos sistemas de pago empleados en Internet pueden englobarse en varias categorías:

Cajeros ElectrónicosSe trata de sistemas en los cuales los clientes abren unas cuentas con todos sus datos en unasentidades de Internet. Estas entidades les proporcionan algún código alfanumérico asociado a suidentidad que les permita comprar en los vendedores asociados a las entidades.

Dinero Electrónico (Anónimo e Identificado)El concepto de dinero electrónico es amplio, y difícil de definir en un medio tan extenso como el delos medios de pago electrónicos (EPS). A todos los efectos se definirá el dinero electrónico comoaquel dinero creado, cambiado y gastado de forma electrónica. Este dinero tiene un equivalentedirecto en el mundo real: la moneda. Se usará para pequeños pagos.


Puede clasificarse en dos tipos:

Dinero on-line:

Exige interactuar con el banco (vía módem, red o banca electrónica) para llevar a cabo elpago de una transacción con una tercera parte (comercio o tienda online). Existen empresasque brindan esta triangulación con los bancos como SafetyPay o PayPal, también existendivisas comerciales puramente electrónicas como e-gold y las que combinan varias formas depago como Neopago, además debemos incluir aquellas plataformas de pago que funcionansobre una plataforma móvil, lo cual lleva a mayor portabilidad de las soluciones de pago ypor tanto mayor posibilidad de uso sobre todo en lo referente a micro pagos.

Dinero offline:

Se dispone del dinero a través de internet, y puede gastarse cuando se desee, sin necesidad decontactar para ello con un banco. Estos sistemas de dinero electrónico permiten al clientedepositar dinero en una cuenta y luego usar ese dinero para comprar productos o servicios enInternet.

Cheques ElectrónicosLos métodos para transferir cheques electrónicos a través de Internet no están tan desarrolladoscomo otras formas de transferencia de fondos. Los cheques electrónicos podrían consistir algo tansimple como enviar un email a un vendedor autorizando a sacar dinero de la cuenta, con certificadosy firmas digitales asociados. Un sistema de cheques puede ser considerado como un compromisoentre un sistema de tarjetas de crédito y uno de micropagos o dinero electrónico (anónimo).

Tarjetas de Crédito y DébitoLos sistemas de tarjetas de crédito y débito en Internet funcionarán de forma muy similar a comolo hacen hoy en día. El cliente podrá usar si lo desea su tarjeta de crédito actual para comprarproductos en una tienda virtual. La principal novedad consiste en el desarrollo del estándar decifrado SET (Secure Electronic Transaction) por parte de las más importantes compañías de tarjetasde crédito.

Metodologías ágiles de desarrollo de softwareEl desarrollo ágil de software envuelve un nuevo enfoque radical para la toma de decisiones en losproyectos de software, refiere a métodos de ingeniería del software basados en el desarrollo iterativoe incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidaddel proyecto, así el trabajo es realizado mediante la colaboración de equipos auto-organizadosy multidisciplinarios, inmersos en un proceso de toma de decisiones a corto plazo compartido.Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando softwareen lapsos cortos. El software desarrollado en una unidad de tiempo es llamado una iteración, lacual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación,análisis de requisitos, diseño, codificación, revisión y documentación. Una iteración no debe agregardemasiada funcionalidad para justificar el lanzamiento del producto al mercado, sino que la metaes tener una «demo» (sin errores) al final de cada iteración. Al final de cada iteración el equipovuelve a evaluar las prioridades del proyecto.

Desarrollo de aplicaciones móvilesUna aplicación móvil es una aplicación informática diseñada para ser ejecutada en teléfonosinteligentes, tabletas y otros dispositivos móviles. Por lo general se encuentran disponibles a travésde plataformas de distribución, operadas por las compañías propietarias de los sistemas operativos


móviles como Android, iOS, BlackBerry OS, Windows Phone, entre otros. Existen aplicacionesmóviles gratuitas u otras de pago, donde en promedio el 20-30% del costo de la aplicación sedestina al distribuidor y el resto es para el desarrollador.

El desarrollo de aplicaciones para dispositivos móviles requiere tener en cuenta las limitaciones deestos dispositivos. Los dispositivos móviles funcionan con batería, hay que considerar una granvariedad de tamaños de pantalla, datos específicos de software y hardware como también distintasconfiguraciones. El desarrollo de aplicaciones móviles requiere el uso de entorno de desarrollosintegrados. Las aplicaciones móviles suelen ser probadas primero usando emuladores y más tardese ponen en el mercado en periodo de prueba. Actualmente un gran número de empresas se dedicaa la creación profesional de aplicaciones.

Distribución de aplicaciones móvilesPara la distribución de aplicaciones móviles existen diferentes plataformas distribuidoras, lasllamadas tiendas de aplicaciones, existen diferentes tipos de tiendas para descargar aplicaciones,estas pueden ser creadas por el mismo sistema operativo o por independientes. Las tiendas organizanlas aplicaciones y cada una tiene normas diferentes de retribución y publicación.

Algunas de ellas son:

Google PlayApp StoreWindows Phone StoreBlackBerry WorldAmazon AppStoreF-Droid

2.6.2 Marco ConceptualEl desarrollo de nuestro proyecto se ubica dentro del estudio e implementación de tecnologías decuarta generación aplicadas al desarrollo de aplicaciones móviles, específicamente a la aplicaciónde estas tecnologías en el prototipo de una aplicación de billetera virtual para los servicios prestadosen empresas como TuBoleta.

En este contexto se creará un prototipo de aplicación Android con base en los lineamientos delmarco de trabajo Scrum proporcionados por Scrum.org, organización creada en 2009 por KenSchweber. (Scrum.Org, 2016)[2]

Definición de conceptosCódigos QRUn código QR (del inglés Quick Response code, çódigo de respuesta rápida") es un módulo paraalmacenar información en una matriz de puntos o en un código de barras bidimensional. Fue creadoen 1994 por la compañía japonesa Denso Wave, subsidiaria de Toyota. Presenta tres cuadrados enlas esquinas que permiten detectar la posición del código al lector. El objetivo de los creadores (unequipo de dos personas en Denso Wave, dirigido por Masahiro Hara) fue que el código permitieraque su contenido se leyera a alta velocidad. Los códigos QR son muy comunes en Japón, donde esel código bidimensional más popular. (QRcode.com, 2016)[3]

QR utilidad y uso en el comercio electrónicoAunque el desarrollo inicial de los Códigos QR tenía como objetivo principal su utilización enla industria de la automoción, hoy por hoy la posibilidad de leer códigos QR desde teléfonosy dispositivos móviles permite el uso de Qr Codes en un sinfín de aplicaciones completamentediferentes de las que originales como pueden ser:


PublicidadCampañas de marketingMerchandisingDiseño GráficoPapelería corporativa (tarjetas de visita, catálogos)Internet, Webs, blogs

Su uso se ha extendido a múltiples partes del mercado, y que al permitir almacenar informaciónes completamente aplicable a infinitos ámbitos, en el contexto mundial se conocen diferente yamplias aplicaciones como la compra, después de que la subsidiaria de Tesco en Corea lanzaráuna aplicación para Smartphone que permite comprar con códigos QR, se implementaron dosproyectos en Latinoamérica. El primero, en agosto, en Chile, por parte de Hipermercados Jumbo,simplemente enviaba a un sitio móvil desde anuncios en estaciones de subte. El segundo, enseptiembre en Argentina, fue implementado por la subsidiaria de Staples. En este caso el desarrollofueron aplicaciones para iPhone, Blackberry y Android que permiten el uso incluso sin conexión ainternet En España también se ha replicado la campaña de Tesco y la cadena de supermercadosSorli Discau ha creado el primer supermercado virtual de Europa. (Clarin.com, 2016)[4]

AndroidAndroid es un sistema operativo basado en el núcleo Linux. Fue diseñado principalmente paradispositivos móviles con pantalla táctil, como teléfonos inteligentes y tablets; hoy en día se extiendea relojes inteligentes, televisores y todo tipo de dispositivos integrados como los de automóvilesy electrónicos de hogar. Inicialmente fue desarrollado por Android Inc., empresa que Googlerespaldó económicamente y más tarde, en 2005, compró. Android fue presentado en 2007 juntola fundación del Open Handset Alliance (un consorcio de compañías de hardware, software ytelecomunicaciones) para avanzar en los estándares abiertos de los dispositivos móviles. El primermóvil con el sistema operativo Android fue el HTC Dream y se vendió en octubre de 2008.

Android es una pila de software de código abierto para una amplia gama de dispositivos móvilesy un proyecto de código abierto liderado por Google. El sitio oficial ofrece el código fuentede la información y lo que necesita para crear variantes sobre el sistema operativo de Android,dispositivos de puerto y accesorios a la plataforma Android, y asegurarse de que sus dispositivoscumplen con los requisitos de compatibilidad. (Source of Android, 2016)[5]

El MVCEl MVC (Model-View-Controller o Modelo-Vista-Controlador), es un patrón de diseño que separalos datos, la lógica y las interfaces de usuario. Como su nombre indica, está separado en trescomponentes: Modelo, Vista y Controlador. Está basado en la ideología de separación de conceptosy cumple perfectamente con los objetivos de los patrones de diseño.

1. Modelo

Es la capa encargada de los datos, es decir, la que se encarga de hacer peticiones a las basesde datos para enviar o recibir información. Estas bases de datos pueden estar alojadas deforma local en nuestra app o de forma remota en un servidor externo.

2. Vista

Se trata del código que nos permitirá presentar los datos que el modelo nos proporciona,como ejemplo podríamos decir que en una aplicación es el código HTML que nos permitemostrar la salida de los datos procesados.


3. Controlador

Es la capa que sirve de enlace entre la vista y el modelo. Envía comandos al modelo paraactualizar su estado, y a la vista correspondiente para cambiar su presentación. En el casoMVVM (Modelo Vista VistaModelo) la interacción entre la vista y el controlador será en losdos sentidos, el controlador muestra los datos en la vista y si en la vista hay un cambio dedatos, se actualiza el modelo automáticamente.

El framework IonicIonic es una herramienta, gratuita y open source, para el desarrollo de aplicaciones híbridas basadasen HTML5, CSS y JS. Está construido con Sassy optimizado con AngularJS.

2.6.3 Marco espacialEl Marco espacial está limitado al desarrollo de un prototipo de aplicación para Smartphone elcual busca competir con empresas como TuBoleta y los servicios actualmente prestados por losorganizadores de eventos tipo concierto, esta es una compañía colombiana que se dedica a laprestación de servicios de boletería para eventos como conciertos y otros.

Debido a que es un prototipo que surge de una iniciativa académica actualmente no se cuenta conel apoyo de tuBoleta u otra compañía de este tipo para la realización de este prototipo, se cuentacon la información a la cual se tiene acceso como usuarios y se busca desde esta visión generar unvalor agregado con la experiencia.


2.7 Aspectos metodológicos2.7.1 Tipo de estudio

El tipo de estudio a realizar es un estudio descriptivo donde se busca aplicar los conocimientos eningeniería de software a un contexto local mediante la creación de un prototipo de aplicación móvilque permite no solo la implementación de nuevas tecnologías si no la innovación al aplicar estas enun nicho de mercado que actualmente no ha explorado estas opciones.

La investigación y prototipo a realizar nos permitirá estudiar el comportamiento tecnológico delmercado actual y así generar una solución innovadora que pueda ser la base para la aplicación deesta tecnología en otros comercios.

2.7.2 Método de investigaciónMediante el método deductivo se busca analizar el comportamiento del mercado de los eventos y asíllegar a supuestos que permitan generar un prototipo para dar solución a la problemática planteada,estas premisas y conclusiones nos permitirán generar un producto a modo experimental que puedaatender las necesidades encontradas y que sirva como modelo de conocimiento.

2.7.3 Metodología de IngenieríaEs importante mencionar la metodología de desarrollo que se utilizará en la implementación dela investigación, esta se basará en scrum debido a que esta metodología permite el desarrollo deaplicaciones de software de forma ágil basando en iteraciones incrementales en cortos lapsos detiempo.

Scrum permite entregas parciales a medida de cada una de sus entregas se esté completando elproducto final, estas entregas parciales deben estar definidas en un proceso de tiempo muy corto.

Cada iteración debe contemplar las siguientes etapas:

PlanificaciónSelección de requisitosElaboración de tareas necesarias para cumplir la iteraciónEjecución de la iteraciónEntregable de la iteración

2.7 Aspectos metodológicos 23

Figura 2.7.1: Scrum Alliance [2016]. Recuperado de https://www.scrumalliance.org/why-scrum

Esta metodología indica que se deben definir roles a lo largo de proceso de desarrollo del software,entre estos están:

Scrum master: Es el líder del proyecto, encargado de gestionar recursos y la gestión deproyecto, trabaja de la mano con el product owner en el desarrollo del proyecto.

Product owner: Es la representación del cliente, se centra en las necesidades del negocio,transmite estas necesidades a todo el equipo de trabajo.

Desarrolladores: Son los encargados de realizar la implementación de las historias definidaspara cada sprint.

2.7.4 Fuentes y técnicas para la recolección de la información

Técnicas de recolección de información

A continuación, se enumeran las fuentes y técnicas de recolección de información definidaspara el desarrollo del proyecto de acuerdo al planteamiento del problema, el cual requierefuentes teóricas para su desarrollo y unas fuentes de tipo primario que nos permitirán conocerel contexto y el mercado al cual se aplica el prototipo a desarrollar.

• Fuentes primarias:

Observación: Registro visual de lo que ocurre en una situación real, clasificando yconsignando los datos de acuerdo con algún esquema previsto y de acuerdo al problemaestudiado. Se aplicará las modalidades de observación participante de campo de formacolectiva con el fin de generar conclusiones con la experiencia.

Encuestas: Obtención de información a partir de los usuarios del servicio y su experien-cia.

• Fuentes teóricas:

Documentación técnica: Fuentes de documentación técnica proporcionada por losproveedores y distribuidores de software.


Elaboración de instrumentos de recolección de datos

Cuestionario: Se aplicará el mecanismo de cuestionario estructurado el cual es generadomediante utilidades web y estará dirigido a los usuarios de eventos de concierto en la ciudadde Bogotá discriminando las preguntas de acuerdo a la siguiente clasificación: usuarios deconciertos y, usuarios de conciertos y servicios preferenciales como aplicaciones web oempresas intermediarias (TuBoleta).

2.7.5 Tratamiento de la informaciónEl tratamiento de la información obtenida de forma primaria será mediante técnicas estadísticas,de forma que nos permita clasificar y conocer a partir de una muestra el comportamiento generaldel mercado y así tener la información necesaria para determinar las características que requiere elprototipo a desarrollar.

La información obtenida a partir de fuentes teóricas se incluye como marco teórico y bibliografíapara los casos de documentación técnica que hubiese facilitado y guiado la codificación delprototipo.

2.8 Alcances, limitaciones y resultado esperado2.8.1 Alcances

El alcance de la investigación está trazado hasta la creación de un prototipo que se va a manejardesde un dispositivo móvil, emulando el proceso de generación de tiquetería mediante códigos QR.

2.8.2 LimitacionesLa limitación principal es la obtención de información en cuanto a los procesos internos prestadospor los intermediarios para la generación de Boletería, ya que no se cuenta con un contactoque pueda proveer la información necesaria. El alcance fue delimitado con la información yconocimiento que se tiene de los servicios prestados por estas empresas.

2.8.3 Resultado esperadoEl resultado que se espera tener es una aplicación diseñada para dispositivos móviles inteligentes An-droid que permite emular la generación de los tiquetes para conciertos y administrar característicasbásicas de una cuenta preferencial en la aplicación.

2.9 Organización del proyecto 25

2.9 Organización del proyecto2.9.1 Capítulos

Capítulos1. Descripción de la investigación2. Desarrollo de la investigación3. Modelamiento del negocio y prototipo4. Generación del modelo conceptual5. Generación de modelos6. Asignación de tareas7. Presentación del prototipo

2.9.2 ObjetivosDesarrollar una aplicación móvil utilizando el framework ionic el cual permita construccionesmultiplataforma para el despliegue de varios sistemas operativos.

Implementar una metodología de desarrollo ágil como lo es scrum para llevar la gestióny el control dentro del desarrollo de software siguiendo todas las directrices y actividadesindicadas por este método de trabajo.

III3 Desarrollo de la investigación . . . . . . . . 293.1 Recolección y ordenamiento de la información3.2 Análisis de los resultados

4 Modelamiento del negocio . . . . . . . . . . 314.1 Contextualización empresa4.2 Modelamiento arquitectura empresarial4.3 Metodología4.4 Historias de Usuarios

5 Modelamiento de datos . . . . . . . . . . . . . 615.1 Tecnología utilizada5.2 Modelo entidad relación5.3 Modelo relacional

6 Descripción técnica . . . . . . . . . . . . . . . . 656.1 Contratos de servicio6.2 Diagrama de despliegue6.3 Herramientas y tecnologías

7 Prototipo Funcional . . . . . . . . . . . . . . . . . . 717.1 Login7.2 Menú principal7.3 Listar eventos7.4 Detalle evento7.5 Comprar tiquete de evento7.6 Pago7.7 Consultar tiquetes7.8 Consultar Detalle tiquetes

Parte III.Desarrollo de lainvestigación

3. Desarrollo de la investigación

3.1 Recolección y ordenamiento de la información

3.1.1 Información materia prima para la investigaciónFuentes de información primariaLas fuentes primarias son elementos cuyas conclusiones indican los hechos con base a la ex-periencia y están estrechamente relacionadas al tema de estudio, por ello para el desarrollo deesta investigación se usan las siguientes fuentes, seleccionadas a partir del análisis de opcionesdisponibles y calidad de información aportada por estas.

Artículos de revistasArtículos de periódicosEncuesta

Descripción metodológica de las fuentes primarias (Encuesta)Naturaleza metodológica: CuantitativaTécnica metodológica: Encuesta personalTipo de cuestionario: EstructuradoUniverso: Usuarios de Smartphone en Bogotá, con edades comprendidas entre 14 y 60 añosÁmbito geográfico: Ciudad (Bogotá)Elementos del muestreo: Usuarios de redes sociales / contactos en Bogotá, con edadescomprendidas entre 14 y 60 añosTamaño muestral: 100 unidades de muestras validasProcedimiento del muestreo: muestreo aleatorio simpleFecha de recolección de datos: Primer Trimestre de 2016

Para consultar encuesta y resultados remitirse al anexo 1.

Herramientas utilizadasSe apoya la realización de la encuesta mediante la aplicación web e-encuestas.com la cual ensu modalidad gratuita permite creación de encuestas pequeñas con distribución mediante Email,

30 Capítulo 3. Desarrollo de la investigación

web, Social, QR. Adicionalmente nos permite la consulta de resultados y generación de informesresumen.

3.1.2 Tabulación, ordenamiento y procesamiento de la informaciónTabulación y ordenamiento de la información apoyada en la generación de reportes automática dee-encuestas.com.

3.2 Análisis de los resultadosIdentificación de las variables y relacionesSe identificaron bajo el análisis realizado las siguientes variables las cuales tiene estrecha relacióncon la factibilidad de distribución del prototipo TicketApp; la edad, la frecuencia de asistencia a loseventos y la oportunidad de acceso a la información y la boletería de estos.

Bajo el análisis realizado generamos las siguientes conclusiones a las cuales nos podemos acogerpara llegar a la verificación de nuestras preguntas de investigación, objetivos e hipótesis.

1. El 100 por ciento de personas entrevistadas han asistido a algún evento alguna vez lo cualnos dice que el universo de la población es potencialmente un cliente y aún más el 19 porciento que asiste frecuentemente.

2. Las personas prefieren en su mayoría hacer uso de internet y aplicaciones web para comprarboletas de evento y en preferencia sin sobrecargos.

3. Las personas dan un nivel de importancia medio-alto a la seguridad que le proporcionan lasaplicaciones instaladas en sus móviles y equipos.

4. Entre los 21 y 35 años es la población más accesible, lo cual puede generar un foco depoblación potencialmente interesados en la aplicación TicketApp.

5. Internet, televisión y radio son los mejores medios para dar a conocer la aplicación y aumentarlos usuarios.

4. Modelamiento del negocio

4.1 Contextualización empresa4.1.1 Objetivo

Proveer una solución especializada que permitan a corto, mediano y largo plazo optimizar laadquisición de tiquetería para eventos, facilitando la comunicación, colaboración y coordinaciónentre los usuarios y las empresas creadoras de eventos.

4.1.2 MisiónLa Misión de nuestra empresa es la de implementar el uso de tecnologías de códigos QR para lageneración de tiquetería, reducir los costos y a lo largo de cinco años estar prestando el servicio endiferentes nichos del mercado.

Asegurar un servicio ajustado a las necesidades de los usuarios y que contribuya al medio ambiente.

4.1.3 VisiónLa visión de nuestra empresa es que el uso de tecnologías de códigos QR permita automatizarprocesos en diferentes negocios y así mismo contribuya significativamente a la conciencia ecológicay el cambio en el uso de recursos impresos.

4.1.4 Función de la empresaLa función de nuestra empresa es ofrecer soluciones tecnológicas, las cuales ayuden a solventar lasnecesidades que requieren hoy en día las diferentes organizaciones empresariales que se dediquen ala prestación de servicios con boletería.

32 Capítulo 4. Modelamiento del negocio

4.2 Modelamiento arquitectura empresarial

4.2.1 Punto de Vista de la Organización

Este punto de vista se centra en organización interna de una compañía, de un departamento, una redde compañías o cualquier otra entidad que interactúe con la organización.

El punto de vista de organización es muy utilizado para identificar competencias, autoridades y lasresponsabilidades dentro de la organización.

Figura 4.2.1: Metamodelo Punto de Vista de la Organización Fuente: ArchiMate R© 2.0 Specification

Modelo

El punto de vista de Organización muestra la organización de la empresa Ticket Soluciones SASa un nivel general. Representa las partes organizacionales de la empresa con su respectivo nivel.Esta organización está dividida en tres partes; Las operaciones que son las personas encargadasdel proceso comercial, Desarrollo: Son las personas encargadas de la generación de producto yfinalmente Soporte: Son las personas encargadas de atender solicitudes de soporte sobre el productoy servicio de atención al cliente (SAC).

Figura 4.2.2: Modelo Punto de Vista de la Organización. Fuente: C. Mejía

4.2 Modelamiento arquitectura empresarial 33

4.2.2 Punto de Vista de Cooperación de Actor

El punto de vista de cooperación de actor se centra en la relación de los actores con el ambiente.Otro uso importante de este tipo de vista es mostrar como un número de cooperaciones entre losactores y los componentes de aplicaciones realizan un proceso de negocio.

Figura 4.2.3: Metamodelo Punto de Vista de Cooperación de Actor Fuente: ArchiMate R© 2.0 Specification

Modelo

El punto de vista Cooperación de Actor nos muestra los colaboradores ligados a Ticket SolucionesSAS. Los clientes se representa como un colaborador general, estos se relacionan e interactúan conla empresa mediante el producto TicketApp y de acuerdo a sus necesidades con cada uno de losniveles organizacionales de la empresa.

Figura 4.2.4: Modelo Punto de Vista de Cooperación de Actor. Fuente: C. Mejía


4.2.3 Punto de Vista de Función de Negocio

El punto de vista de función de negocio muestra las principales funciones de una organización ysus relaciones en términos de flujo de información, valor. Representa los más resaltantes aspectosde una compañía en términos de sus principales actividades, su comportamiento, independientes dela organización o desarrollos tecnológicos. Este punto de vista provee una visión de alto nivel enlas operaciones generales de la compañía.

Figura 4.2.5: Metamodelo Punto de Vista de Función de Negocio Fuente: ArchiMate R© 2.0 Specification

Modelo

El punto de vista de funciones de negocios muestra las principales funciones de negocio de laorganización, estas representan todas las actividades primarias que se llevan a cabo, cada una deellas se encuentra relacionada a un actor responsable de esta actividad dentro de la organización,adicionalmente se muestra la interacción de los clientes con las soluciones prestadas en TicketSoluciones SAS.

Figura 4.2.6: Modelo Punto de Vista de Función de Negocio. Fuente: C.Mejía


4.2.4 Punto de Vista de Proceso de NegocioEl punto de vista de proceso de negocio es usado para mostrar un alto nivel de estructura ycomposición de uno o más procesos de negocio. Este punto de vista contiene otros conceptosrelacionados:

Los servicios de negocio que ofrecen una salida al mundo, mostrando como un proceso denegocio contribuye a la creación de los productos de la compañía.La asignación de los roles del proceso de negocio, los cuales visualizan las responsabilidadesasociadas a los actores.La información usada por el proceso de negocio

Figura 4.2.7: Vista de Cooperación de Proceso de Negocio Fuente: ArchiMate R© 2.0 Specification


Modelo

El punto de vista de funciones de negocios muestra las principales funciones de negocio de laorganización, estas representan todas las actividades primarias que se llevan a cabo, cada una deellas se encuentra relacionada a un actor responsable de esta actividad dentro de la organización,adicionalmente se muestra la interacción de los clientes con las soluciones prestadas en TicketSoluciones SAS.

Figura 4.2.8: Modelo Vista de Cooperación de Proceso de Negocio. Fuente: C. Mejía

4.2.5 Punto de Vista de Cooperación de Proceso de Negocio

El punto de vista de cooperación de proceso de negocio es usado para mostrar de uno o másprocesos de negocio con cada uno de sus ambientes. Puede ser utilizado para crear un diseño de altonivel del proceso de negocio entre su contexto y proporcionar un director operacional responsablede uno o más procesos, Los aspectos importantes de esta vista son:

Relaciones casuales entre los principales procesos del negocio de la empresa.Mapeo de los procesos del negocio dentro de las funciones del negocio.Creación de servicios por proceso de negocio.Uso de datos compartidos.


Figura 4.2.9: Metamodelo Punto de Vista de Cooperación de Proceso de Negocio Fuente: ArchiMate R© 2.0Specification

ModeloEste modelo detalla los procesos de negocio que son funciones core de la Aplicación TicketApp ysu interacción dentro del proceso de Administración de boletería. Muestra las dos funcionalidadesTiquet QR y Catálogo de eventos como las principales actividades dentro negocio.

Figura 4.2.10: Modelo Punto de Vista de Cooperación de Proceso de Negocio Fuente: C. Mejía


4.2.6 Punto de Vista de Producto

El punto de vista del producto representa el valor que los productos ofrecen a los consumidores oa las partes externas involucradas, muestra la composición de uno o más productos en términosde construcción de servicios, la asociación de contratos y acuerdos. También podría mostrar lasinterfaces a través las cuales el producto es ofrecido, y los eventos asociados con el producto.

Figura 4.2.11: Metamodelo Punto de Vista de Producto. Fuente: ArchiMate R© 2.0 Specification

Modelo

El siguiente modelo nos muestra el valor de la empresa Ticket Soluciones SAS y el valor de losproductos ofrecidos desde el punto de vista de los actores relacionados.

Los actores Organizadores y clientes interactúan con la empresa en el proceso de adquisición yventa de boletería de eventos con el valor agregado de facilitar la compra mediante una aplicaciónmóvil.


Figura 4.2.12: Modelo Punto de Vista de Producto Fuente: C. Mejía

4.2.7 Punto de Vista Comportamiento de la Aplicación

El punto de vista del comportamiento de aplicación describe el comportamiento interno de unasolicitud; por ejemplo, como se da cuenta de uno o más servicios de aplicación. Este punto de vistaes útil en el diseño del principal comportamiento de las aplicaciones, o en la identificación delsolapamiento funcional entre diferentes aplicaciones.

Figura 4.2.13: Metamodelo Punto de Vista Comportamiento de la Aplicación Fuente: ArchiMate R© 2.0Specification


ModeloEl punto de vista del comportamiento de aplicación describe el comportamiento interno de los even-tos generales en aplicación TicketApp, muestra como componentes centrales la compra de boletas,el catálogo de eventos y la seguridad de los cuales se desprenden las actividades correspondientes.

Figura 4.2.14: Modelo Punto de Vista Comportamiento de la Aplicación. Fuente: C. Mejía

4.2.8 Punto de vista Cooperación de AplicaciónEl punto de vista de Cooperación de aplicación describe las relaciones entre las aplicacionescomponentes en términos de los flujos de información, o en términos de los servicios a ofrecery utilizar. Este punto de vista se utiliza típicamente para crear una visión general del entorno deaplicaciones de una organización. Este punto de vista también se utiliza para expresar la cooperación(interno) o la orquestación de los servicios que en conjunto apoyan la ejecución de un proceso denegocio.

Figura 4.2.15: Metamodelo Punto de vista Cooperación Fuente: ArchiMate R© 2.0 Specification


ModeloEl punto de vista de Cooperación de aplicación muestra una visión general del entorno de aplicacio-nes de la empresa Ticket Soluciones SAS. Muestra entonces la orquestación de los servicios queen conjunto apoyan la ejecución de los procesos de negocio que se realizan la aplicación móvilTicketApp, la cual sirve de base para el hacer del negocio.

Figura 4.2.16: Modelo Punto de vista Cooperación de Aplicación. Fuente: C. Mejía

4.2.9 Punto de vista Estructura de AplicaciónEl punto de vista Estructura de la aplicación muestra la estructura de una o más aplicaciones ocomponentes. Este punto de vista es útil en el diseño o la comprensión de la estructura principalde las aplicaciones o componentes y los datos asociados; por ejemplo, para romper la estructurade un sistema en construcción, o para identificar los componentes de aplicaciones legacy que sonadecuados para la migración / integración.

Figura 4.2.17: Metamodelo Punto de vista Estructura Fuente: ArchiMate R© 2.0 Specification

ModeloEl punto de vista Estructura de la aplicación muestra los componentes definidos dentro de ticketApp,se resalta la base de datos oracle alojada en un servicio extermino en la cual hay interacción con


cada uno de los módulos definidos.

Figura 4.2.18: Modelo Punto de vista Estructura de Aplicación. Fuente: C. Mejía

4.2.10 Punto De Vista uso de Aplicación

El punto de vista de uso de aplicación muestra una visión general del entorno de aplicaciones de laempresa Ticket Soluciones SAS. Muestra entonces la orquestación de los servicios que en conjuntoapoyan la ejecución de los procesos de negocio que se realizan la aplicación móvil TicketApp, lacual sirve de base para el hacer del negocio.

Figura 4.2.19: Metamodelo Punto de vista uso Fuente: ArchiMate R© 2.0 Specification


Modelo

El punto de vista de uso de la aplicación nos muestra el flujo del proceso con los servicios ycomponentes que interactúan en la compra de boletería, las entidades financieras se muestran comoun cliente externo que interactúa en el proceso de pagos.

Figura 4.2.20: Modelo Punto de vista uso de Aplicación. Fuente: C. Mejía

4.2.11 Punto de vista de Infraestructura

El punto de vista de infraestructura contiene los elementos de la infraestructura de software yhardware para el apoyo a la capa de aplicación, tales como los dispositivos físicos, redes o softwaredel sistema (por ejemplo, sistemas operativos, bases de datos y middleware).

Figura 4.2.21: Metamodelo Punto de vista de Infraestructura Fuente: ArchiMate R© 2.0 Specification


Modelo

El punto de vista de infraestructura contiene los elementos de la infraestructura de software yhardware para el apoyo a la capa de aplicación de TicketApp, detalla los componentes alojadosen el servicio de hospedaje que permite publicar la aplicación y como estos son accesibles desdeinternet en un dispositivo móvil.

Figura 4.2.22: Modelo Punto de vista de Infraestructura. Fuente: C. Mejía

4.2.12 Punto de vista Uso de Infraestructura

El punto de vista Uso de infraestructura muestra cómo las aplicaciones son compatibles con elsoftware y la infraestructura del hardware: los servicios de infraestructura son entregados por losdispositivos; el software del sistema y las redes que se proporcionan a las aplicaciones. Este puntode vista desempeña un papel importante en el análisis de rendimiento y escalabilidad, puesto que serefiere la infraestructura física a la lógica del mundo de las aplicaciones.

Figura 4.2.23: Metamodelo Punto de vista Uso de Infraestructura Fuente: ArchiMate R© 2.0 Specification


ModeloEl punto de vista Uso de infraestructura muestra cómo los componentes definidos para la aplicaciónTicketApp interactúan con los plugins externos que permitirán completar las funcionalidadesmediante el consumo de servicios independientes a la aplicación.

Figura 4.2.24: Modelo Punto de vista Uso de Infraestructura. Fuente: C. Mejía

4.2.13 Punto de vista Implementación y Organización

El punto de vista Implementación y Organización muestra cómo una o más aplicaciones sonrealizadas con la infraestructura. Este comprende la cartografía de las aplicaciones (lógicas) yComponentes, tales como Enterprise Java Beans, la asignación de la información utilizada por estasaplicaciones y componentes en el almacenamiento subyacente de la infraestructura; por ejemplo,bases de datos o tablas de otros archivos. La vista de implementación juega un papel importante enel análisis de rendimiento y escalabilidad, ya que se refieren a la infraestructura física a la lógica delmundo de las aplicaciones. En seguridad y análisis de riesgo, el punto de vista de implementaciónse utiliza para identificar, por ejemplo, las dependencias críticas y riesgos.

Figura 4.2.25: Punto de vista Implementación y Organización Fuente: ArchiMate R© 2.0 Specification


Modelo

El punto de vista Implementación y Organización muestra cómo una o más aplicaciones sonrealizadas con la infraestructura. Este comprende la cartografía de las aplicaciones (lógicas) yComponentes de TicketApp.

Figura 4.2.26: Modelo Punto de vista Implementación y Organización. Fuente: C. Mejía

4.2.14 Punto de vista de Estructura de Información

El punto de vista estructura de información es comparable a los modelos tradicionales de informa-ción creados en el desarrollo de casi cualquier sistema de información. Se muestra la estructurade la información utilizada en la empresa o en un proceso de negocio específico o aplicación, entérminos de tipos de datos o las estructuras de clase (orientado a objetos). Además, puede mostrarcómo la información a nivel empresarial está representado a nivel de aplicación en la forma de lasestructuras de datos utilizadas allí, y cómo éstas son entonces mapeados sobre la infraestructurasubyacente; por ejemplo, por medio de un esquema de base de datos.

Figura 4.2.27: Metamodelo Punto de vista Implementación y Organización Fuente: ArchiMate R© 2.0 Speci-fication


Modelo

El punto de vista estructura de información muestra el modelo de información básico del procesobasado en los eventos y las entidades de datos involucradas, el contrato permite el ingreso de loseventos al catálogo y a partir de este se generan los procesos de información que generan la ventade tikets y boletas QR.

Figura 4.2.28: Modelo Punto de vista Implementación y Organización. Fuente: C. Mejía

4.2.15 Punto de vista de Servicio de RealizaciónEl punto de vista de servicio de Realización se utiliza para mostrar cómo uno o más servicios denegocios son realizados por los procesos subyacentes (y algunas veces por componentes de laaplicación). Por lo tanto, se forma el puente entre el punto de vista de los productos comerciales yla vista de procesos de negocio. Proporciona una "Vista desde el exterior.en uno o más procesos denegocio.

Figura 4.2.29: Metamodelo Punto de vista de Servicio de Realización. Fuente: ArchiMate R© 2.0 Specifica-tion


Modelo

El punto de vista de servicio de Realización muestra la perspectiva general desde el cliente delproceso de venta de boletería, el cual es el eje del negocio y cómo intervienen los tipos de clientes.

Figura 4.2.30: Modelo Punto de vista de Servicio de Realización. Fuente: C. Mejía

4.2.16 Punto de vista de StakeholderEl punto de vista de Stakeholder le permite al analista modelar las partes interesadas, los conductoresinternos y externos para el cambio, y las evaluaciones (en términos de fortalezas, debilidades,oportunidades y amenazas) de estos controladores. Además, los vínculos con la inicial (alto nivel)objetivos que abordan estas preocupaciones y las evaluaciones pueden ser descritas. Estos objetivosconstituyen a la base para el proceso de ingeniería de requisitos, incluyendo el refinamiento objetivo,análisis de la contribución y el conflicto, y la derivación de los requisitos que dan cuenta de losobjetivos.

Figura 4.2.31: Metamodelo Punto de vista de Stakeholder. Fuente: ArchiMate R© 2.0 Specification


Modelo

El modelo de punto de vista de Stakeholder muestra las partes interesadas en el proyecto y detallalos objetivos y valoraciones relacionadas a cada objetivo con el fin de dimensionar las fortalezas ydebilidades.

Figura 4.2.32: Modelo Punto de vista de Stakeholder. Fuente: C. Mejía

4.2.17 Punto de vista de Realización de ObjetivosEl punto de vista de Realización de Objetivos permite a un diseñador modelar el refinamiento delos objetivos (alto nivel) en objetivos más concretos, y el refinamiento de objetivos concretos enrequisitos o condiciones que describen las propiedades que son necesarias para alcanzar los objetivos.El refinamiento de las metas en sub-objetivos se modela utilizando la relación de agregación. Elrefinamiento de las metas en los requisitos se modela utilizando la relación realización.

Figura 4.2.33: Metamodelo Punto de vista de Realización de Objetivos. Fuente: ArchiMate R© 2.0 Specifica-tion


Modelo

A continuación se modelan los objetivos de alto nivel para la aplicación TicketApp, estos permitiránel refinamiento en objetivos más concretos dentro de los siguientes modelos.

Figura 4.2.34: Modelo Punto de vista de Realización de Objetivos. Fuente: C. Mejía

4.2.18 Punto de vista de ContribuciónEl punto de vista de contribución le permite a un diseñador o analista modelar las relacionesde influencia entre los objetivos y requisitos. Los puntos de vista resultantes se pueden utilizarpara analizar el impacto que tienen sobre los objetivos entre sí o para detectar conflictos entre losobjetivos de las partes interesadas.

Figura 4.2.35: Metamodelo Punto de vista de Contribución. Fuente: ArchiMate R© 2.0 Specification


Modelo

El siguiente punto de vista muestra las relaciones entre objetivos y requisitos de forma general,permite enfocarse en un valor clave del producto el cual es la agilidad en la compra de boletería.

Figura 4.2.36: Modelo Punto de vista de Contribución. Fuente: C. Mejía

4.2.19 Punto de vista de PrincipiosEl punto de vista de principios permite al analista o diseñador modelar los principios que sonrelevantes para el problema de diseño a mano, incluyendo los objetivos que motivan a estosprincipios. Además, las relaciones entre los principios y sus objetivos, pueden ser modelados. Porejemplo, los principios pueden influir entre sí positiva o negativamente.

Figura 4.2.37: Metamodelo Punto de vista de Principios. Fuente: ArchiMate R© 2.0 Specification


Modelo

El siguiente modelo permite describir los principios que atienden al objetivo general de la aplicaciónTicketApp.

Figura 4.2.38: Modelo Punto de vista de Principios. Fuente: C. Mejía

4.2.20 Punto de vista de Realización de RequerimientosEl Punto de vista de Realización de Requerimientos permite al diseñador modelar la realizaciónde los requisitos por parte de los elementos básicos, tales como agentes de negocios, servicios deoficina, los procesos de negocios, servicios de aplicaciones, componentes de la aplicación, etc.Además, este punto de vista se puede usar para refinar requisitos en requisitos más detallados. Larelación de agregación se usa para este propósito.

Figura 4.2.39: Metamodelo Punto de vista de Realización de Requerimientos. Fuente: ArchiMate R© 2.0Specification


Modelo

El siguiente punto de vista permite modelar los objetivos claves para la creación de la aplicaciónTicketApp el cual representa el objetivo general del proyecto.

Figura 4.2.40: Modelo Punto de vista de Realización de Requerimientos. Fuente: C. Mejía

4.2.21 Punto de vista de MotivaciónEl Punto de vista de Motivación permite al diseñador o analista modelar el aspecto de motivación,sin centrarse en determinados elementos dentro de este aspecto. Por ejemplo, este punto de vista sepuede utilizar para presentar una visión completa o parcial del aspecto de la motivación por losinteresados relacionados, sus objetivos principales, los principios que se aplican, y los principalesrequerimientos de servicios, procesos, aplicaciones y objetos.

Figura 4.2.41: Metamodelo Punto de vista de Motivación. Fuente: ArchiMate R© 2.0 Specification


Modelo

El siguiente modelo representa las motivaciones para el proyecto, describe a modo general losobjetivos y la dependencia de riesgo con las actividades de investigación e implementación deldesarrollo del prototipo.

Figura 4.2.42: Modelo Punto de vista de Motivación. Fuente: C. Mejía

4.2.22 Punto de vista de ProyectoEl Punto de vista de Proyecto se utiliza principalmente para modelar la gestión del cambio dearquitectura. La .arquitectura"del proceso de migración de una vieja situación (estado actualArquitectura empresarial) a una nueva situación deseada (estado objetivo arquitectura empresarial)tiene consecuencias importantes en el proceso de toma de decisiones posteriores de la estrategia decrecimiento a largo plazo y mediano plazo.

Figura 4.2.43: Metamodelo Punto de vista de Proyecto. Fuente: ArchiMate R© 2.0 Specification


Modelo

El Punto de vista de Proyecto plasma la gestión del cambio de arquitectura y actores involucrados,detalla el objetivo de la aplicación.

Figura 4.2.44: Modelo Punto de vista de Proyecto. Fuente: C. Mejía

4.2.23 Punto de vista de MigraciónEl Punto de vista de Migración implica modelos y conceptos que se pueden utilizar para especificarla transición de una arquitectura existente a una arquitectura deseada.

Figura 4.2.45: Metamodelo Punto de vista de Migración. Fuente: ArchiMate R© 2.0 Specification


Modelo

El siguiente modelo detalla la transición requerida para pasar del prototipo android al ejecutabledisponible para descargar en el servicio de AppStore

Figura 4.2.46: Modelo Punto de vista de Migración. Fuente: C. Mejía

4.2.24 Punto de vista de Migración e ImplementaciónEl Punto de vista de Migración e Implementación se utiliza para relacionar los programas yproyectos de las partes de la arquitectura que se implementan. Esta vista permite el modelado delalcance de los programas, proyectos, actividades del proyecto en términos de las mesetas que serealizan o los elementos de la arquitectura individuales que se ven afectados. Además, la forma enque se ven afectados los elementos puede ser indicado por la anotación de las relaciones.

Figura 4.2.47: Metamodelo Punto de vista de Migración e Implementación. Fuente: ArchiMate R© 2.0Specification

4.3 Metodología 57

Modelo

El siguiente modelo muestra la relación del prototipo de la aplicación y el proyecto generado,involucra la arquitectura y la relación con los usuarios.

Figura 4.2.48: Modelo Punto de vista de Migración e Implementación. Fuente: C. Mejía

4.3 MetodologíaEn el inicio del proyecto se definió scrum como la metodología a tomar en el desarrollo del proyecto,cada integrante del equipo asumió cada uno los roles sugeridos para la implementación de estametodología, la conformación de los roles se definió de la siguiente manera:

John Alex Cortes: Scrum MasterCarol Mejía: Product OwnerJoan Rincón: Desarrollador

Se programaron reuniones semanales donde se definían tareas a realizar para la semana, el productowner junto al scrum master definieron las necesidades del negocio y estas fueron plasmadas enhistorias de usuario, con cada uno de los requerimientos definidos se comenzaron a definir cadauno de los Sprint.

Cuadro 4.3.1: Sprint TicketApp Fuente: J. Rincón


Debido a que cada interacción genera un entregable, se analizaron herramientas las cuales puedantener controles de versión y cada una de las fases del ciclo de vida del desarrollo de software.

La herramienta utilizada fue la página de internet Github.com donde se creó el repositorio parael control de fuentes identificado con la siguiente url: https://github.com/joanrsar/MyTicketApp. Con esta herramienta se llevó el total control de las versiones y del código en cada uno de losSprint del proyecto.

Figura 4.3.1: Versionamiento del aplicativo en GitHub Fuente: GitHub

4.4 Historias de Usuarios 59

4.4 Historias de Usuarios

Cuadro 4.4.1: Historia de usuario de inicio de sesión. Fuente: J. Rincón

Cuadro 4.4.2: Historia de usuario Listar eventos. Fuente: J. Rincón

Cuadro 4.4.3: Historia de usuario detalle evento. Fuente: J. Rincón


Cuadro 4.4.4: Historia de usuario Comprar tiquete. Fuente: J. Rincón

Cuadro 4.4.5: Historia de usuario listar tiquetes. Fuente: J. Rincón

Cuadro 4.4.6: Historia de usuario detalle tiquete. Fuente: J. Rincón

5. Modelamiento de datos

5.1 Tecnología utilizadaOracle Database 11 g Express Edition (Oracle Database XE)Es un nivel de entrada, una herramienta para la creación de bases de datos de pequeñas dimensiones,basado en el código de base de datos de Oracle 11 g Release 2. Es una herramienta gratuita paradesarrollar, implementar y distribuir; rápido para descargar; y fácil de administrar.

VentajasVa de la mano con el desarrollo de aplicaciones en Node.js, Python, PHP, Java, .NET, XMLy aplicaciones Open Source.Los administradores de bases que necesitan una base de datos libre, motor de arranque parala formación y el despliegueEs útil para proveedores de software independientes (ISV) y proveedores de hardware quequieren una base de datos inicial para distribuir de forma gratuitaEs ideal para las instituciones educativas y estudiantes que necesitan una base de datos librepara su plan de estudios.Con Oracle Database XE, ahora se puede desarrollar e implementar aplicaciones con unainfraestructura comprobada de gran alcance, líder en la industria, y luego actualizar cuandosea necesario sin migraciones costosas y complejas.Oracle Database XE puede instalarse en cualquier máquina host tamaño con cualquier númerode CPU (una base de datos por máquina), pero XE almacenará hasta 11 GB de datos deusuario, utilizar hasta 1 GB de memoria, y utilizar una CPU de la máquina host.

62 Capítulo 5. Modelamiento de datos

5.2 Modelo entidad relación

Figura 5.2.1: Modelo Entidad - Relación. Fuente: J. Rincón

5.3 Modelo relacional 63

5.3 Modelo relacional

Figura 5.3.1: Modelo Relacional. Fuente: J. Rincón

Detalles del diccionario de datos en el Anexo 2

6. Descripción técnica

6.1 Contratos de servicio6.1.1 WebService de login

Cuadro 6.1.1: Descripción Servicio Login. Fuente: J. Rincón

Cuadro 6.1.2: Parámetros Servicio Login. Fuente: J. Rincón

66 Capítulo 6. Descripción técnica

6.1.2 WebService de eventos

Servicio de Visualización y detalle de eventos

Cuadro 6.1.3: Descripción Servicio de Visualización. Fuente: J. Rincón

Cuadro 6.1.4: Parámetros Servicio de Visualización. Fuente: J. Rincón

Servicio de Localidades de eventos

Cuadro 6.1.5: Descripción Servicio de Localidades de eventos. Fuente: J. Rincón

Cuadro 6.1.6: Parámetros Servicio de Localidades de eventos. Fuente: J. Rincón

6.1 Contratos de servicio 67

6.1.3 WebService de pagos

Cuadro 6.1.7: Descripción Servicio de Pagos. Fuente: J. Rincón

Cuadro 6.1.8: Parámetros Servicio de Pagos. Fuente: J. Rincón

6.1.4 WebService de tiquetes

Servicio de creación de tiquetes

Cuadro 6.1.9: Descripción Servicio de creación de tiquetes. Fuente: J. Rincón

Cuadro 6.1.10: Parámetros Servicio de creación de tiquetes. Fuente: J. Rincón


Servicio de consulta de tiquetes

Cuadro 6.1.11: Descripción Servicio de consulta de tiquetes. Fuente: J. Rincón

Cuadro 6.1.12: Parámetros Servicio de consulta de tiquetes. Fuente: J. Rincón

6.2 Diagrama de despliegueLa arquitectura del aplicativo TicketApp se encuentra en divido 3 modelos. El primero una apli-cación móvil la cual puede ser desplegada en cualquier dispositivo con sistema operativo androidversión 4.4 y IOS 9.3. El segundo frente son los Web Services construidos en tecnología JAVA1.7 los cuales se encuentran desplegados en un servidor de aplicaciones weblogic 12c. Finalmentela capa de datos se encuentra construido sobre un motor de base de datos Oracle XE Express.Tanto el servidor web y la base de datos se encuentran sobre un servidor Amazon con ip publica :52.53.218.205.

Cuadro 6.2.1: Diagrama de Despliegue Fuente: J. Rincón

6.3 Herramientas y tecnologías 69

6.3 Herramientas y tecnologías

El entorno de desarrollo integrado seleccionado para realizar los requerimientos se dividió en trespartes aplicativo móvil, los servicios integradores y la capa de base de datos.

Cuadro 6.3.1: Herramientas para el desarrollo móvil Fuente: J. Rincón

Cuadro 6.3.2: Herramientas para el desarrollo de servicios web Fuente: J. Rincón

Cuadro 6.3.3: Herramientas de bases de datos Fuente: J. Rincón

La máquina donde se realizaron los desarrollos, cuenta con las siguientes características:

Cuadro 6.3.4: Maquina de desarrollo. Fuente: J. Rincón

Los dispositivos físicos que se pusieron a disposición para pruebas fueron los siguientes:


Cuadro 6.3.5: Dispositivos físicos Móvil 1. Fuente: J. Rincón

Cuadro 6.3.6: Dispositivos físicos Móvil 2. Fuente: J. Rincón

7. Prototipo Funcional

7.1 LoginFuncionalidad que permite registrarse y/o loguearse como un usuario de la aplicación

Figura 7.1.1: Login de la aplicación Fuente: TicketApp

72 Capítulo 7. Prototipo Funcional

7.2 Menú principalMenú principal de la aplicación, el cual permite acceder a todas las funcionalidades disponibles

Figura 7.2.1: Menú principal Fuente: TicketApp

7.3 Listar eventosFuncionalidad que permite listar los eventos disponibles para compra de tiquetes en la aplicación

Figura 7.3.1: Listar Eventos Fuente: TicketApp

7.4 Detalle evento 73

7.4 Detalle eventoFuncionalidad que permite consultar el detalle de un evento determinado tras seleccionarlo.

Figura 7.4.1: Detalle evento Fuente: TicketApp

7.5 Comprar tiquete de eventoFuncionalidad que permite realizar el proceso de compra el tiquete a partir del botón “COMPRAR”de la pantalla “Detalle evento”.

Figura 7.5.1: Comprar tiquete evento Fuente: TicketApp

74 Capítulo 7. Prototipo Funcional

7.6 PagoFuncionalidad que permite realizar el pago del tiquete mediante medios electrónicos (PSE, tarjetade crédito)

Figura 7.6.1: Pago Fuente: TicketApp

7.7 Consultar tiquetesFuncionalidad que permite consultar los tiquetes comprados.

Figura 7.7.1: Consulta tiquetes comprados Fuente: TicketApp

7.8 Consultar Detalle tiquetes 75

7.8 Consultar Detalle tiquetesFuncionalidad que permite consultar el detalle de los tiquetes comprados, permite visualizar elcódigo QR de ingreso y la información de la fecha y ubicación evento.

Figura 7.8.1: Detalle tiquetes Fuente: TicketApp

IV8 Resultados y Discusión . . . . . . . . . . . . . . . 79

9 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . 81

10 Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Anexos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83Anexo 1: Encuesta, tabulación y ResultadosAnexo 2: Diccionario de DatosAnexo 3: Fuentes e Instaladores

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Índice de Tablas . . . . . . . . . . . . . . . . . . . . . 96

Índice de Figuras . . . . . . . . . . . . . . . . . . . . 99

Parte IV.Cierre de lainvestigación

8. Resultados y Discusión

Los resultados obtenidos del proyecto fue inicialmente el de una aplicación móvil hibrida desarro-llada con el framework ionic el cual permite la instalación en dispositivos móviles Android comoen dispositivos Apple.La arquitectura del aplicativo se estableció a tres capas donde la primera se encuentra la capa móvildesarrollada netamente en javascript utilizando el framework ionic con Angukar, la segunda dondese albergan los diferentes servicios rest desarrollados en Java 1.7 consumidos por la aplicaciónmóvil, esta hace que la aplicación sea orientada a servicios. Finalmente, la tercera capa, la cual esla capa de datos que como se mencionó anteriormente fue construida sobre el motor Oracle 11Gexpress.En cuanto la metodología scrum esta fue bastante útil en el desarrollo proyecto, debido al escasotiempo sirvió la implementación de una metodología ágil que definiera pequeñas tareas o reque-rimientos semanales donde se cumplían pequeños hitos y así llevar una construcción paulatina eincremental del producto, cumpliendo con la fecha fnal establecida para el fin del proyecto.

9. Conclusiones

La principal motivación del desarrollo de esta investigación era la creación de un prototipo funcionalpara dispositivos móviles (Ver prototipo funcional ) identificando las principales necesidades delos asistentes a los conciertos(Ver historias de usuario) y cómo estas podrían aportar para facilitarla gestión , la generación de boletería y los ingresos a esta clase de espectáculos.

Adicionalmente se buscaba la posibilidad de la creación de un aplicación móvil multiplataformacapaz de ser desplegado en dispositivos con sistema operativo Android (Ver anexo 4.Fuentes eInstaladores ) y en dispositivos IOS (ver anexo 5.Fuentes e Instaladores) , gracias al frameworkIonic el cual es un basadas en HTML5, Javascript y CSS que ayudan a la construcción de unaaplicación móvil híbrida permitiendo una alto acople entre las diferentes plataformas móvilesdisponibles en el mercado.

En cuanto a la metodología de trabajo la que más se ajusta a un proyecto móvil el cual deberá cumpliruna cantidad limitada de requerimientos en un periodo de tiempo muy corto fue la metodología dedesarrollo ágil scrum ya que con la definición de roles y de iteraciones incrementales las cualesgeneraban una versión del producto final ayudando al control y gestión a lo largo del ciclo de vidadel proyecto de software cumpliendo los tiempos de entrega establecidos.

10. Anexos

Anexo 1: Encuesta, tabulación y ResultadosEncuesta

1. ¿Asiste frecuentemente a eventos de tipo concierto, teatro, presentaciones, musicales etc.?(*)

a. Nuncab. Casi Nuncac. Algunas Vecesd. Frecuentementee. Todos los posiblesf. Siempre

2. ¿Regularmente cuando adquiere boletas de eventos, por cuál de estos medios las adquiere?(*)

a. Las compro mediante internet y/o aplicacionesb. Me dirijo a los puntos de venta disponiblesc. Pago gastos adicionales por el envío y/o contra entrega

3. Haría uso de una aplicación móvil que permita consultar un catálogo de eventos disponiblesy realizar su compra de boletas mediante esta?

a. Sib. No me interesac. No uso Smartphoned. Si, mientras sea gratuita

4. ¿Confía en la seguridad que proporcionan las aplicaciones móviles en temas de informacióny transacciones? (*)

a. Siempreb. Casi siemprec. Verifico sus orígenes para instalarla

84 Capítulo 10. Anexos

d. No

5. ¿Cuál es su edad? (*)a. 13 - 20 añosb. 21 - 27 añosc. 28 -35 añosd. 35 años en adelante

6. ¿Cómo te enteras de los eventos a los que asistes? (*)a. Internetb. Volantesc. Comerciales radiales o de TVd. Vallas publicitarias

85

Tablas e Histogramas de distribución de frecuencias

1. ¿Asiste frecuentemente a eventos de tipo concierto, teatro, presentaciones, musicales etc.?

Cuadro 10.0.1: Histograma Pregunta 1 Fuente: e-encuestas.com

2. ¿Regularmente cuando adquiere boletas de eventos, por cuál de estos medios las adquiere?


3. ¿Haría uso de una aplicación móvil que permita consultar un catálogo de eventos disponiblesy realizar su compra de boletas mediante esta?


4. ¿Confía en la seguridad que proporcionan las aplicaciones móviles en temas de informacióny transacciones?



5. ¿Cuál es su edad?


6. ¿Cómo te enteras de los eventos a los que asistes?


87

Graficos

1. ¿Asiste frecuentemente a eventos de tipo concierto, teatro, presentaciones, musicales etc.?

Figura 10.0.1: Gráfico Pregunta 1 Fuente: e-encuestas.com

2. ¿Regularmente cuando adquiere boletas de eventos, por cuál de estos medios las adquiere?


3. ¿Haría uso de una aplicación móvil que permita consultar un catálogo de eventos disponiblesy realizar su compra de boletas mediante esta?


4. ¿Confía en la seguridad que proporcionan las aplicaciones móviles en temas de informacióny transacciones?



5. ¿Cuál es su edad?


6. ¿Cómo te enteras de los eventos a los que asistes?


89

Anexo 2: Diccionario de Datos

Nombre de la entidad: MTICKET.ESTADO_TIQUETE Descripción: Descripción del estado delticket

Cuadro 10.0.7: MTICKET.ESTADO_TIQUETE 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.USUARIO Descripción: Descripción de cuentas de usuariosinscritos a TicketApp

Cuadro 10.0.8: MTICKET.USUARIO 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.PERFIL Descripción: Descripción de perfiles de usuarios

Cuadro 10.0.9: MTICKET.PERFIL 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.TIQUETE Descripción: Descripción del tiquete


Cuadro 10.0.10: MTICKET.TIQUETE 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.PERSONA Descripción: Descripción de datos personales usua-rios

Cuadro 10.0.11: MTICKET.PERSONA 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.LOCALIDAD_EVENTO Descripción: Descripción de localida-des de eventos

Cuadro 10.0.12: MTICKET.LOCALIDAD_EVENTO 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.ESCENARIO Descripción: Descripción de escenarios paraeventos

91

Cuadro 10.0.13: MTICKET.ESCENARIO 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.CIUDAD Descripción: Descripción de ciudades

Cuadro 10.0.14: MTICKET.CIUDAD 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.DEPARTAMENTO Descripción: Descripción de los departamen-tos

Cuadro 10.0.15: MTICKET.DEPARTAMENTO 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.EVENTO Descripción: Descripción de los eventos

Cuadro 10.0.16: MTICKET.EVENTO 6 Fuente: C. Mejía


Nombre de la entidad: MTICKET.ORGANIZADOR Descripción: Descripción de los organizadoresde eventos

Cuadro 10.0.17: MTICKET.ORGANIZADOR 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.ESTADO_EVENTO Descripción: Estados de eventos

Cuadro 10.0.18: MTICKET.ESTADO_EVENTO 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.ANEXO_EVENTO Descripción: Descripción de las imágenespublicitarias relacionadas al evento

Cuadro 10.0.19: MTICKET.ANEXO_EVENTO 6 Fuente: C. Mejía

Nombre de la entidad: MTICKET.TIPO_EVENTO Descripción: Tipos de eventos

Cuadro 10.0.20: MTICKET.TIPO_EVENTO 6 Fuente: C. Mejía

93

Anexo 3: Fuentes e Instaladores

1. Fuentes App Móvil : https://github.com/joanrsar/MyTicketApp/tree/master/Movil/currentVersion2. Fuentes Servicios Web Java :https://github.com/joanrsar/MyTicketApp/tree/master/Java3. Fuentes SQL :https://github.com/joanrsar/MyTicketApp/tree/master/SQL/Scripts4. Apk Android :https://github.com/joanrsar/MyTicketApp/tree/master/instalador/android5. App IOS :https://github.com/joanrsar/MyTicketApp/tree/master/instalador/ios/MyTicketApp.app

Bibliografía

Scrum.Org. (Abril de 2016). Scrum.Org. Obtenido de Scrum.Org: //www.scrum.org/About

QRcode.com. (Abril de 2016). What is a QR Code? Obtenido de QRcode.com: www.qrcode.com/en/about/

Source of Android.(Abril de 2016). Source of Android. Obtenido de Source of Android:http://source.android.com

Android History.(octubre 2015). Android History. Obtenido de android central.com: android-central.com /android-history

Android Developers.(octubre 2015). Developer Android. Obtenido de Developer.Android.com:developer.android.com/ develop/index.html

The Ionic Book (Mayo 2016) Obtenido de ionicframework.com: http://ionicframework.com/docs/guide/

Herrera,El maldito libro de los descarrilados.(2010). Ruby on Rails, MVC: http://yottabi.com/mld.pdf

Norbert Bieberstein et al. Service-Oriented Architecture Compass, Pearson 2006, ISBN0-13-187002-5

Referencias1 Jaramillo, J. G. (2015). El boom de los conciertos musicales en Colombia: razones y limitan-

tes. Revista Nova et Vera ISSN: 2422-2216, Vol. 1- Ed 5.

4 Clarin.com. (Abril de 2016). Clarin.com. Obtenido de Clarin.com: http://www.clarin.com/empresas_y_negocios/Marketing-futurista-comprar-camara-celular_0_555544518.html

6 Beneficios de scrum (Abril de 2016) Obtenido de proyectosagiles.Org:www.proyectosagiles.org/beneficios-de-scrum


7 Billeteras virtuales (Octubre 2015) Obtenido de ElTiempo.com: http://www.eltiempo.com/tecnosfera/novedades-tecnologia/billeteras-virtuales-nuevos-sistemas-de-pago/16399831

Índice de cuadros

4.3.1 Sprint TicketApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.4.1 Historia de usuario de inicio de sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.2 Historia de usuario Listar eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.3 Historia de usuario detalle evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.4 Historia de usuario Comprar tiquete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.4.5 Historia de usuario listar tiquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.4.6 Historia de usuario detalle tiquete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.1.1 Descripción Servicio Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.1.2 Parámetros Servicio Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.1.3 Descripción Servicio de Visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.1.4 Parámetros Servicio de Visualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666.1.5 Descripción Servicio de Localidades de eventos . . . . . . . . . . . . . . . . . . . 666.1.6 Parámetros Servicio de Localidades de eventos . . . . . . . . . . . . . . . . . . . . 666.1.7 Descripción Servicio de Pagos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.1.8 Parámetros Servicio de Pagos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.1.9 Descripción Servicio de creación de tiquetes . . . . . . . . . . . . . . . . . . . . . . 676.1.10 Parámetros Servicio de creación de tiquetes. . . . . . . . . . . . . . . . . . . . . . 676.1.11 Descripción Servicio de consulta de tiquetes . . . . . . . . . . . . . . . . . . . . . 686.1.12 Parámetros Servicio de consulta de tiquetes . . . . . . . . . . . . . . . . . . . . . . 686.2.1 Diagrama de Despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 686.3.1 Herramientas para el desarrollo móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.3.2 Herramientas para el desarrollo de servicios web . . . . . . . . . . . . . . . . . . . 696.3.3 Herramientas de bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.3.4 Maquina de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.3.5 Dispositivos físicos Móvil 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.3.6 Dispositivos físicos Móvil 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

10.0.1 Histograma Pregunta 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8510.0.2 Histograma Pregunta 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8510.0.3 Histograma Pregunta 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8510.0.4 Histograma Pregunta 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8610.0.5 Histograma Pregunta 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8610.0.6 Histograma Pregunta 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8610.0.7 Mticket.Estado_Tiquete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.0.8 Mticket.Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.0.9 Mticket.Perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8910.0.10 Mticket.Tiquete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.0.11 Mticket.Persona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.0.12 Mticket.Localidad_Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9010.0.13 Mticket.Escenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.0.14 Mticket.Ciudad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.0.15 Mticket.Departamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110.0.16 Mticket.Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

98 ÍNDICE DE CUADROS

10.0.17 Mticket.Organizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9210.0.18 Mticket.Estado_Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9210.0.19 Mticket.Anexo_Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9210.0.20 Mticket.Tipo_Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Índice de figuras

2.7.1 Scrum Alliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2.1 Metamodelo Punto de Vista de la Organización . . . . . . . . . . . . . . . . . . . 324.2.2 Modelo Punto de Vista de la Organización . . . . . . . . . . . . . . . . . . . . . . . . 324.2.3 Metamodelo Punto de Vista de Cooperación de Actor . . . . . . . . . . . . . 334.2.4 Modelo Punto de Vista de Cooperación de Actor . . . . . . . . . . . . . . . . . . 334.2.5 Metamodelo Punto de Vista de Función de Negocio . . . . . . . . . . . . . . . 344.2.6 Modelo Punto de Vista de Función de Negocio . . . . . . . . . . . . . . . . . . . . 344.2.7 Metamodelo Vista de Cooperación de Proceso de Negocio . . . . . . . . 354.2.8 Modelo Vista de Cooperación de Proceso de Negocio . . . . . . . . . . . . . 364.2.9 Metamodelo Punto de Vista de Cooperación de Proceso de Negocio 374.2.10 Modelo Punto de Vista de Cooperación de Proceso de Negocio . . . 374.2.11 Metamodelo Punto de Vista de Producto . . . . . . . . . . . . . . . . . . . . . . . . 384.2.12 Modelo Punto de Vista de Producto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.2.13 Metamodelo Punto de Vista Comportamiento de la Aplicación . . . . . 394.2.14 Modelo Punto de Vista Comportamiento de la Aplicación . . . . . . . . . 404.2.15 Metamodelo Punto de vista Cooperación . . . . . . . . . . . . . . . . . . . . . . . . 404.2.16 Modelo Punto de vista Cooperación de Aplicación . . . . . . . . . . . . . . . 414.2.17 Metamodelo Punto de vista Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.18 Modelo Punto de vista Estructura de Aplicación . . . . . . . . . . . . . . . . . . 424.2.19 Metamodelo Punto de vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.20 Modelo Punto de vista uso de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . 434.2.21 Metamodelo Punto de vista de Infraestructura . . . . . . . . . . . . . . . . . . . . 434.2.22 Modelo Punto de vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.23 Metamodelo Punto de vista Uso de Infraestructura . . . . . . . . . . . . . . . . 444.2.24 Modelo Punto de vista Uso de Infraestructura . . . . . . . . . . . . . . . . . . . . . 454.2.25 Punto de vista Implementación y Organización . . . . . . . . . . . . . . . . . . . 454.2.26 Modelo Punto de vista Implementación y Organización . . . . . . . . . . . . 464.2.27 Metamodelo Punto de vista Implementación y Organización . . . . . . . 464.2.28 Modelo Punto de vista Implementación y Organización . . . . . . . . . . . . 474.2.29 Metamodelo Punto de vista de Servicio de Realización . . . . . . . . . . . . 474.2.30 Modelo Punto de vista de Servicio de Realización . . . . . . . . . . . . . . . . . 484.2.31 Metamodelo Punto de vista de Stakeholder . . . . . . . . . . . . . . . . . . . . . . 484.2.32 Modelo Punto de vista de Stakeholder . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.2.33 Metamodelo Punto de vista de Realización de Objetivos . . . . . . . . . . . 494.2.34 Modelo Punto de vista de Realización de Objetivos . . . . . . . . . . . . . . . 504.2.35 Metamodelo Punto de vista de Contribución . . . . . . . . . . . . . . . . . . . . . 504.2.36 Modelo Punto de vista de Contribución . . . . . . . . . . . . . . . . . . . . . . . . . . 514.2.37 Metamodelo Punto de vista de Principios . . . . . . . . . . . . . . . . . . . . . . . . 514.2.38 Modelo Punto de vista de Principios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.39 Metamodelo Punto de vista de Realización de Requerimientos . . . . . 524.2.40 Modelo Punto de vista de Realización de Requerimientos . . . . . . . . . . 534.2.41 Metamodelo Punto de vista de Motivación . . . . . . . . . . . . . . . . . . . . . . . 534.2.42 Modelo Punto de vista de Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

100 ÍNDICE DE FIGURAS

4.2.43 Metamodelo Punto de vista de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.44 Modelo Punto de vista de Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.45 Metamodelo Punto de vista de Migración . . . . . . . . . . . . . . . . . . . . . . . . 554.2.46 Modelo Punto de vista de Migración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.47 Metamodelo Punto de vista de Migración e Implementación . . . . . . . 564.2.48 Modelo Punto de vista de Migración e Implementación . . . . . . . . . . . . 574.3.1 Versionamiento del aplicativo en GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.2.1 Modelo Entidad - Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3.1 Modelo Relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7.1.1 Login de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 717.2.1 Menú principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.3.1 Listar Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 727.4.1 Detalle evento Fuente: TicketApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.5.1 Comprar tiquete evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 737.6.1 Pago . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.7.1 Consulta tiquetes comprados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 747.8.1 Detalle tiquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

10.0.1 Gráfico Pregunta 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8710.0.2 Gráfico Pregunta 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8710.0.3 Gráfico Pregunta 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8710.0.4 Gráfico Pregunta 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8810.0.5 Gráfico Pregunta 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8810.0.6 Gráfico Pregunta 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

ticket app - repository.udistrital.edu.corepository.udistrital.edu.co/bitstream/11349/2793/1... ·...

Documents